6. Биллинговые системы и маркетинг оператора

Ах, барин, барин, скоро святки.

Для того чтобы узнать, что тот или иной оператор связи к очередному празднику очередной раз делает публике предложение, от которого невозможно отказаться, достаточно включить телевизор. Выше мы имели возможность уже не раз упомянуть о том, что успех любой кампании и, вместе с ней, компании, продающей услуги связи, определяется двумя моментами: наличием покупателей и уровнем потребления, кроме того, численность клиентской базы оператора определяет его рыночную стоимость. В своем стремлении привлечь к себе как можно больше клиентов оператор не может не учитывать их неизбежную разнородность и проводить одну и ту же политику по отношению ко всем возможным «разновидностям» потребителей. Инструментом рыночной политики оператора являются тарифные планы, которые разрабатываются, как правило, с учетом интересов и возможностей различных групп населения, схем расчетов с клиентами, с учетом рода их деятельности и пр. [6.1].

Более того, одной из тенденций развития современной индустрии услуг связи, как мы уже отмечали выше, является все большая «персонализация» этих услуг, т.е. все большая их ориентированность, как на отдельного абонента/клиента компании, так и на отдельных корпоративных клиентов. Это заставляет маркетинговые службы операторов связи искать возможности удовлетворения потребностей более широкого спектра социальных слоев, быстрее реагировать на конъюнктуру рынка и быть более изобретательными при проведении различных кампаний.

Очевидно, что успех маркетинговой политики, конечной целью которой в любом случае является повышение доходов того или иного оператора связи, зависит, прежде всего, от того, насколько далеко может пойти оператор навстречу клиентам. Поскольку здесь обязательно затрагиваются интересы двух сторон, представляется целесообразным обсудить то, что может позволить биллинговая система сделать для клиентов оператора, и что — собственно для оператора. Безусловно, вопросы маркетинга в телекоммуникациях выходят далеко за пределы функционирования биллинговых систем [6.2], но здесь мы остановимся только на этой стороне дела и только на вопросах формирования тарифных планов.

6.1. Тарифные планы

Одной из проблем, с которой сталкивается любой Оператор связи, является проблема определения (назначения) стоимости вызова, зарегистрированного коммутатором. В принципе, практически каждый вызов и соответствующая ему учетная запись являются уникальными. Действительно, если N абонентов одного Оператора могут соединяться с М абонентами других операторов и с N — 1 абонентами своего оператора, то количество типов учетных записей, различающихся хотя бы только номерами абонентов А и В будет равно N(М + N — 1). Если еще учесть, что у Оператора может возникнуть желание различать учетные записи по времени суток, дате, направлению вызова и т.д., то возможное количество вариантов становится неисчерпаемым. Теоретически можно задать тарифную ставку для каждого варианта учетной записи; практически это невозможно и не нужно.

Общие принципы назначения тарифных ставок строятся на том, что абоненты (клиенты) разделяются на группы (типы), время суток разделяется на классы, вызываемые адресаты группируются по направлениям вызова и пр. Каждый оператор сам определяет для себя принципы выделения названных категорий, степень их детализации и правила назначения соответствующих тарифных ставок. Совокупность подходов к решению этих вопросов представляет собой тарифную политику Оператора. В самом простом случае тарифные ставки могут вообще не назначаться, а за пользование связью взиматься только абонентская плата, или на любые вызовы может быть установлена единая тарифная ставка и стоимость звонка будет тогда определяться только его продолжительностью. В действительности же так бывает крайне редко, и в совокупности число задаваемых ставок может измеряться тысячами.

Если оставить в стороне вопрос о качестве предоставляемых услуг связи [6.3] и их наборе (т.к. спектр предоставляемых услуг в большей степени зависит от технических возможностей сети, эксплуатируемой оператором связи, нежели от возможностей установленной у него биллинговой системы, эта сторона дела здесь практически не рассматривается), то основным стрежнем маркетинговой политики может являться известная формула «...числом поболее, ценою подешевле...», т.е. в качестве главного инструмента воздействия на спрос и объем продаж должны рассматриваться тарифные планы, определяющие стоимость услуг и их разнообразие.

Поскольку с понятием тарифного плана сталкивается практически каждый сотрудник оператора и каждый его клиент, попытаемся сформулировать его определение.

Будем называть тарифным планом совокупность услуг (услуг связи), правил их предоставления, правил расчета их стоимости, правил предоставления льгот, которые могут быть поставлены в соответствие тем или иным атрибутам клиента. Тарифный план может устанавливать особенности начисления абонентской платы, методы начислений, минимальный и максимальный объемы времени использования канала связи, зависящих от объема скидок, правила учета этого времени и скидок и т. д.

Из данного определения и того, о чем говорилось в гл. 1, становится понятным, что ни одна биллинговая система немыслима без модуля управления тарифными планами, поскольку в противном случае процессы тарификации становятся практически не контролируемыми. По мнению ряда аналитиков, то, как биллинговые системы поддерживают работу с тарифными планами, является одной из наиболее значимых их характеристик. Для оператора важна возможность управления практически каждым существенным для тарификации компонентом, поскольку даже если клиент и понимает обоснованность расценок, установленных оператором на услуги связи, при прочих равных условиях он отдаст предпочтение тому тарифному плану (или оператору), который обеспечивает более «справедливое», по его мнению, их применение. Это касается правил определения, как абонентской платы, так и стоимости вызова и здесь стоит обратить внимание на то, что в последнее время применяемые для этого в биллинговых системах алгоритмы расчетов стали еще более разнообразными.

Можно поспорить с утверждением, что «Любому из ведущих операторов связи сегодня сложно получить конкурентное преимущество в тарифной политике, поскольку любой выгодный тарифный план может быть легко скопирован конкурентами» [6.4]. Конечно, в том, чтобы скопировать тарифный план или предпринять ответный демарш принципиально нет ничего невозможного. Но, легкость или сложность копирования определяется исключительно возможностями шиллинговых систем, установленных у конкурентов. В одной системе на создание нового тарифного плана могут уйти часы, в другой — месяцы. Этих месяцев может оказаться достаточно для решения тактических или даже стратегических задач, стоящих перед одним из конкурентов. Ценовые войны и рекламные кампании, свидетелями которых мы являемся, еще раз подтверждают тот факт, что биллинговая система — это не арифмометр на микрочипах, а один из главных инструментов воздействия на рынок.

Поскольку вычисление стоимости вызова, как было упомянуто, является многокритериальной задачей, тарифный план должен отражать все используемые критерии и логическую взаимосвязь между ними. Часто такая связь является иерархической, т.е. совокупность тарифных планов представляет собой логическое дерево, с ветвлением по различным атрибутам. То, как будет построена та или иная иерархия, определяется разработчиком биллинговой системы. Отметим, что, среди прочего, формальная модель, описывающая тарифные планы, не в последнюю очередь определяет возможности системы по выпуску консолидированных счетов, поскольку именно здесь может быть описана привязка тарифных планов к различным стандартам связи и к способам передачи информации. На рис. 6.1.1 представлена диаграмма, показывающая пример построения дерева тарифных планов.

Перечислим (точнее говоря, вспомним, потому что они наверняка известны) атрибуты, которые могут формировать облик тарифного плана. Основной отличительной чертой тарифного плана является набор услуг, которые могут быть доступными абоненту, его использующему. Этот набор зависит, с одной стороны, от технических возможностей оператора и от особенностей стандарта в котором он предоставляет услуги (например, для абонентов стандарта GSM доступна услуга SMS, а для абонентов фиксированной связи — нет). С другой стороны этот набор может зависеть от того, что оператор собирается предложить клиентам в зависимости от способов расчета с ними, от принадлежности клиента к той или группе, в зависимости от истории взаимоотношений с клиентом и т. д.

Для каждой из услуг может быть назначена абонентская плата и, в зависимости от того берется ли плата за потребление услуги, должна быть установлена единица измерения потребления (минуты, штуки, килобайты) и назначена тарифная ставка Параллельно с услугами могут быть сформированы пакеты услуг и для услуг, туда входящих, могут быть назначены свои размеры тарифных ставок и абонентской платы. Кроме сведений о тарифных ставках в план может входить список разовых действий, выполняемых по требованию клиента и стоимость таких действий.

Наряду с тарифными ставками за локальные вызовы в тарифном плане назначаются ставки и за вызовы междугородние, причем эти ставки привязываются, как правило, к так называемым «направлениям» или «зонам» междугородной связи.

Принадлежностью тарифного плана могут являться списки бесплатных (льготных) и платных (т.е. таких, за вызовы на которые берется дополнительная плата третьей стороной) телефонов.

Как правило, все операторы связи дифференцируют тарифные ставки за вызовы в пределах суток, выделяя, как минимум, пиковое и внепиковое время. Тарифный план может предусматривать схему разделения суток на классы времени.

Существенное значение для абонентов может иметь и схема округления длительности разговора, используемая при тарификации вызова. Расходы абонента на разговоры могут сильно отличаться при одних и тех же ставках в зависимости от того, считается длительность вызова с точностью до минуты или с точностью до секунды и телефонные компании часто используют изменение схемы округления как маркетинговый шаг в борьбе за клиента.

И, наконец, одним из наиболее важных для оператора маркетинговых компонентов, тарифных планов являются планы скидок, которые позволяют ставить стоимость услуг в зависимость от их потребления и проводить различные кампании по привлечению новых абонентов или по стимулированию потребления услуг.

6.2. О компонентах тарифного плана

Абонентская плата

Абонентская плата назначается, как правило, для того, чтобы можно было бы окупить расходы, связанные с предоставлением доступа к сети оператора в целом или к отдельным услугам. Упрощенно можно считать, что эта составляющая доходов оператора направлена на компенсацию постоянных расходов, связанных с эксплуатацией инфраструктуры сети. Тем не менее, поскольку этот компонент является элементом взаимоотношений с клиентами, правила его расчета могут быть гибкими. Существует несколько методов применения абонентской платы Ниже перечислены некоторые из возможных.

1. Абонентская плата берется сразу за весь месяц. Начисление производится для предоставленной услуги в момент запуска процедуры расчета абонентской платы сразу за весь календарный период в установленном размере. Расчет абонентской платы таким методом возможен как за истекший, так и за предстоящий период.

2. Абонентская плата берется пропорционально заказу. Начисление производится в соответствии с историей предоставления услуги пропорционально длительности периода, на который услуга была заказана независимо от фактического статуса услуг в период заказа. Использование метода невозможно, если не ведется история предоставления услуг.

3. Абонентская плата берется пропорционально подключению (чистое время). Начисление производится пропорционально количеству дней, в течение которых услуга была фактически предоставлена. При использовании второго и третьего метода начисление абонентской платы также происходит в момент запуска процедуры расчета, но учитывается только истекший период. Даты фактического использования услуги определяются по учетным записям.

4. Берется фиксированная абонентская плата с пропорционализацией периоду подключения в течение первого (календарного) месяца. Начисление производится для предоставленной услуги в момент запуска процедуры расчета абонентской платы сразу за весь период. Для первого месяца абонентская плата рассчитывается на основе ее месячного размера пропорционально количеству дней обслуживания (предстоящего обслуживания), для последующих месяцев расчет аналогичен расчету по методу.

5. Авансом с ежедневным приращением. Этот метод расчета аналогичен предыдущему методу, но абонентская плата рассчитывается нарастающим итогом и отражается на балансе клиента, увеличиваясь каждый день.

Кроме применения различных методов начисления, для первого и для последующих месяцев «жизни» абонента могут быть установлены различные ставки абонентской платы. Комбинация дифференцированного размера абонентской платы и различных способов ее начисления позволяет максимально приблизить размеры начислений к фактическому потреблению услуг и, тем самым, сделать условия обслуживания более привлекательными. Так, например, применение 4 — го метода расчета для услуги «Телефония» будет означать, что даже при фиксированном размере месячной платы, за первый месяц обслуживания клиент заплатит только за те дни, в течение которых он реально мог пользоваться услугой. Для такой услуги, как печать подробного счета, напротив, можно установить 1- й метод начисления и сделать абонентскую плату одинаковой для первого и последующих месяцев, поскольку данная услуга предоставляется, практически, один раз в месяц при проведении ежемесячного биллинга.

Жестких правил или предпочтений по соответствию различных услуг и методов начисления абонентской платы не существует. Исходя из логики предоставления услуг, было бы, вероятно, целесообразно начислять абонентскую плату за роуминг с использованием 2-го метода, а за телефонию — с использованием 3-го, хотя многие операторы предпочитают брать абонентскую плату за роуминг авансом (1-й метод), поскольку финансовый риск оператора при предоставлении именно этой услуги является самым высоким.

Логический вызов

Использование понятия логического вызова позволяет дифференцировать стоимость вызова в зависимости от его направления (или в зависимости от того, из какой сети в какую был направлен вызов). Как минимум, это дает возможность различать вызовы, входящие к абоненту, и исходящие от него. В принципе, если параллельно с оператором работают и другие локальные операторы, то количество возможных типов логических вызовов с учетом переадресации и вызова может составить 2(n + 1)²+ 1, где n — количество других локальных сетей. Таким образом, для вызовов на голосовой почтовый ящик, на пейджер, для переадресации вызовов можно установить различные тарифные ставки в рамках одной и той же услуги «Телефония ».

Округление длительности вызова

Здесь правильнее было бы говорить не собственно об округлении в математическом смысле этого слова, сколько о возможности рассчитывать длительность вызова с точностью до установленной дискреты (counter'а). Многие операторы и мобильной, и фиксированной связи применяют в настоящее время поминутную тарификацию, при которой каждая начавшаяся минута вызова считается равной целой минуте состоявшегося разговора. Для человека, ведущего преимущественно короткие деловые разговоры, такой подход к тарификации может показаться чрезмерно жестким. Во многих системах предусмотрен большой набор параметров, позволяющих менять дискретность определения длительности разговора. Параметры округления могут быть применены как к конкретной услуге при любом типе логического вызова, так и к конкретному типу логического вызова.

Кроме назначения в биллинговой системе тарифной ставки, применяемой к длительности вызова, можно установить ставку и за установление соединения, что позволяет производить тарификацию следующим образом. Вызов условно разделяется на две части, за начальную часть вызова, длительность которой может устанавливаться, произвольно взимается фиксированная плата как за установку соединения, а к оставшейся части применяется тарификация с произвольным counter'ом. Так, например, может быть реализована посекундная тарификация после первой минуты разговора. Точность, как недавно стало известно, «никогда не бывает лишней»...

Следует учитывать, также, что управлять ставками можно не только за счет применения тех или иных правил округления, но и за счет изменения «единицы измерения» услуги. Как правило, такие услуги, как телефония, факс, данные тарифицируются исходя из длительности вызова, SM тарифицируются «поштучно», т.е. плата берется только за факт вызова. За услуги роуминга, предоставление выхода на междугородные или международные линии, определение входящего номера, печать подробного счет берется только абонентская плата. Тем не менее, если по каким — либо соображением Оператор считает возможным брать плату только за вызов при предоставлении услуги телефонии, он может это сделать, указав соответствующую единицу измерения. В этом случае длительность вызова будет игнорироваться, а за вызов будет браться фиксированная плата в размере заданной тарифной ставки.

Зоны базовых станций

Операторы мобильной связи имеют возможность построить не несколько более развитую систему тарифных планов, за счет учета «географии вызова» в собственной сети. Поскольку идентификатор базовой станции, через которую прошел вызов, фиксируется в учетной записи, стоимость вызова может быть рассчитана в зависимости от того, как он был маршрутизирован дальше. Если вызов (например, до другой базовой станции) был пропущен по собственным каналам оператора, он может стоить одну сумму, если эти каналы были арендованы, вызов может стоить дороже. Вызов типа «мобильный — мобильный» в пределах зоны действия одной и той же станции может стоить совсем дешево, поскольку необходимости в использовании других каналов связи не возникает. Оператор, таким образом, имеет возможность построить систему тарифных планов с учетом топологии собственной сети и сделать эти планы более привлекательными для клиентов.

Теоретически, аналогичный подход может использовать и оператор фиксированной связи, если топология его сети не является односвязной. Здесь, опять таки, в зависимости от того, были или не были использованы каналы других операторов, тарифная ставка может зависеть от географии соединения.

Тарифные ставки

Как уже упоминалось, количество вариантов вызовов, которые может оказаться необходимым тарифицировать, весьма велико. Если в учетной записи анализируются k полей и i-е поле может иметь т_i значений, то общее количество вариантов определяется произведением П^k т_i. Одним из возможных подходов к тарификации могло бы стать задание тарифной ставки для каждого возможного типа учетной записи. Тогда при ее анализе всегда можно было бы найти запись в таблице базы данных, в точности соответствующую обрабатываемой записи, и однозначно определить тарифную ставку. Очевидно, что такой образ действий дает преимущества только при небольшом количестве реализуемых вариантов.

Другим возможным вариантом является разбиение всего множества вариантов на некоторое относительно небольшое количество непересекающихся подмножеств и назначение единых тарифных ставок для всех вызовов, входящих в подмножество. Например, все вызовы можно разделить на «входящие» и «исходящие» и для каждого из этих случаев назначить свою ставку. Или, с учетом времени суток, можно выделить четыре подмножества: «входящие, пиковое время», «входящие, внепиковое время», «исходящие, пиковое время», «исходящие, внепиковое время», и т. д. (рис. 6.2.1).

Тогда выбор тарифной ставки сводился бы к проверке того, в какое из названных подмножеств «попадает» учетная запись. Потенциальным недостатком такого подхода является возможность появления учетной записи, которая не попадет ни в одно подмножество, если весь их набор описан недостаточно корректно.

Возможен и третий подход. Вместо непересекающихся подмножеств все варианты можно разбить на подмножества, «вложенные» друг в друга (рис. 6.2.2). При этом каждое «вложенное» подмножество описывает частный случай (или, если угодно, исключение из правила) по отношению к более широкому подмножеству. Самое широкое подмножество должно быть универсальным, т.е. описывать все возможные варианты и задавать соответствующую тарифную ставку.

Так, например, такое универсальное множество может соответствовать звонкам условного типа «любой» и задавать для них тарифную ставку t₁. Если не описывать ничего дополнительно, эта ставка будет применяться абсолютно ко всем учетным записям. Оператор может захотеть сделать из этого исключения и, например, отдельно тарифицировать звонки типа «исходящий на ММТ». Тогда можно для этого случая назначить тарифную ставку t₂. Для всех остальных типов звонков будет использована ставка t₁.

Можно сузить выделенное множество и назначить ставку t₂ для звонков типа «исходящий на ММТ, первая половина суток». Тогда только к этим звонкам будет применена ставка t₂, а к остальным — ставка t₁. Можно поступить иначе и выделить звонки типа «исходящий на ММТ, первая половина суток» из подмножества «исходящий не ММТ», назначив для них ставку t₃. .В этом случае, если УЗ соответствует выделенному подмножеству, будет применена ставка t₃, если звонок является исходящим на ММТ, но совершен не в первую половину суток, будет применена ставка t₂ во всех остальных ситуациях — ставка t₁. Такая детализация может быть продолжена как угодно далеко и данный подход гарантирует, что учетная запись не останется «неопознанной»; для нее всегда будет выбрана тарифная ставка. При таком способе описания тарифных планов можно задать тарифные ставки только для тех ситуаций, которые интересуют конкретного Оператора, все остальные случаи автоматически попадут а разряд «любой». Такой подход в силу его гибкости и надежности используется во многих биллинговых системах.

Использование пакетов

Продажа услуг пакетами является одной из разновидностей оптовой торговли и применяется операторами довольно часто. Получая пакет, абонент приобретает не одну выбранную услугу, а сразу несколько. При этом, как правило, для услуг, входящих в пакет, устанавливаются более привлекательные расценки, — может быть снижена абонентская плата за услуги или тарифные ставки за использование эфирного времени. Такой подход выгоден и для абонента, и для оператора, поскольку для первого появляется возможность получить услуги дешевле, а для второго — увеличить объем продаж. Так, например, можно объединить в пакет услуги телефонии, входящих и исходящих SM и определение входящего номера или создать пакет с услугами телефония, национальный роуминг, международный роуминг.

Для услуг, описанных в пакете, может быть установлено ограниченное время действия, в течение которого для абонента, которому назначен пакет, будут применяться ставки из пакета, а после окончания срока действия ставок из пакета начнут действовать ставки из тарифного плана. Срок действия может быть установлен и для ставок в тарифном плане, при этом можно задать своего рода «расписание на будущее», в соответствии с которым, в определенные моменты времени значения ставок будут меняться. Назначая, таким образом, пакеты, можно предоставлять выбранным клиентам разовые скидки, не зависящие от объема потребления услуг.

6.3. Скидки

По поводу того, что такое скидки и как они применяются в маркетинге вообще и в телекоммуникациях — в частности написаны тома. Вряд ли здесь можно добавить что-то новое о самих скидках, можно лишь констатировать утверждение: поскольку скидки затрагивают финансовые отношения клиента и оператора, биллинговая система должна поддерживать работу с любой моделью скидок, которую маркетинговая служба оператора сочтет необходимым применить.

Скидки могут предоставляться безотносительно к объему потребления услуг и носить, в частности, сезонный характер (например, первого числа каждого месяца все новые клиенты получают по десять минут бесплатных разговоров) или зависеть от объема потребления, либо какого-то другого условия (например, скидка начинает действовать совершения двадцати исходящих вызовов или после того, как клиент наговорил 100 минут, после чего каждые следующие 100 минут стоят все дешевле и дешевле).

Практически, скидки могут быть увязаны с любым из параметров, учитываемых в тарифном плане (поддержка такой возможности отмечается аналитиками как весьма положительное качество биллинговой системы) и быть предоставлены в соответствие с объемом потребленного эфирного времени, объемом начислений или с количеством разговоров; при этом параметры, определяющие правила накопления объема могут гибко меняться.

Безусловно, расчет скидок привносит определенную сложность в работу биллинговой системы, поскольку если скидка представляет собой функциональную зависимость стоимости от потребления, то данные о потреблении необходимо хранить, извлекать при обработке учетной записи на каждый вызов, вычислять стоимость вызовы без скидки, вычислять стоимость вызова со скидкой, проверять валидность условия на право предоставления скидки и пр. Поскольку информация о том, что клиенту был предоставлен вызов со скидкой очень важна для последнего, она должна быть доступна сотрудникам отдела обслуживания и самому клиенту (например, — в распечатке вызовов, прикладываемом к счету).

Количество информации, содержащееся в учетных записях, позволяет строить систему скидок весьма гибко. Рассмотрим пример.

Пусть оператор стремится построить скидку, зависящую от суммарной длительности вызовов (объем потребления накапливается в единицах времени). При работе модуля тарификации по установленным правилам округлен ия рассчитывается длительность вызова, скажем, в минутах и стоимость вызова. Исходно информация о длительности вызова в учетной записи дается в секундах и: доступна для других расчетов. Поэтому, в зависимости от желания оператора и экономической целесообразности, можно накапливать объем либо по расчетной длительности (в минутах), либо — по полной (в секундах).

Приоритеты скидок

Рассмотрим еще один аспект, связанный с особенностями расчета скидок, который, возможно и не носит универсального характера, но позволяет понять, насколько гибко можно подходить к построению скидок.

Оператор может задать в системе несколько планов скидок одновременно. Тогда запрос к базе данных, который должен возвращать значения скидок, применимые к параметрам вызова, может вернуть несколько таких значений, из которых необходимо выбирать одно, пусть — наиболее благоприятное для клиента. Может, однако, сложиться и такая ситуация, при которой у Оператора связи возникнет желание специфичной расстановки акцентов или изменения приоритетов параметров, в соответствии с которыми, клиенты пользуются скидками. Возьмем конкретный пример.

Пусть требуется предоставить разовую скидку на услугу «Телефония» в размере х бесплатных минут и на услугу «Голосовая почта» — в размере у бесплатных минут. Вызов на голосовую почту может рассматриваться как частный случай вызова в рамках услуги «Телефония». Дифференцировать эти скидки можно на уровне логических вызовов. Оператор хотел бы иметь возможность выбора: либо учитывать скидку, предоставленную на услугу «Голосовая почта» в общем объеме скидки по услуге «Телефония», либо — нет.

Вопрос о том, будет ли учтен объем скидки по голосовой почте в объеме скидки по телефонии, может быть в общем случае решен за счет выбора соответствующего типа учета скидки по т. н. нити скидки: при выборе одного типа учета объем будет учтен, при выборе другого — нет. Но, ситуация может оказаться и более сложной. В каждую из названных нитей могут входить и другие «нижние» нити, а особенности учета объемов скидки по дополнительным нитям могут потребовать применения такого типа учета объемов для обеих нитей, при котором объем потребления накапливается только вдоль одной нити и не учитывается в других. В этом случае возникает неоднозначность с учетом объемов по голосовой почте и телефонии, поскольку последний тип учета, жестко заданный для каждой из нитей, не оставляет, казалось бы, возможностей для дальнейшей настройки при использованных в настоящем примере коэффициентах скидки. Тем не менее, резервы еще есть.

Вспомним еще раз, что при прочих равных условиях мы решили выбор коэффициента скидки производить в пользу клиента. Caм жe коэффициент можно задавать с точностью до i-того знака после запятой и решение о выборе может быть принято на уровне именно этого знака. С другой стороны, при расчете стоимости вызова финальное округление производиться с точностью до второго зная после запятой, поэтому для расстановки приоритетов могут быть использованы последние знаки коэффициента скидки, которые не ведут к изменению реально предоставляемой льготы. Безусловно, данный пример носит очень локальный характер и иллюстрирует как разнообразие возможных вариантов, так и гибкость настроек, необходимых в биллинговой системе.

Персонализация скидок

Помимо тарифных планов и планов скидок существуют и другие механизмы, позволяющие строить отношения с клиентами так, что бы эти отношения воспринимались клиентами, как персональные. Ниже такие механизмы кратко описаны.

В рамках подхода, условно называемого Call Credit реализуется механизм, позволяющий предоставлять персональные скидки произвольным клиентам/абонентам, на вызовы, которые будут совершены после назначения такой скидки. Например, клиенту, который был недоволен несвоевременной доставкой счета и пришел не это жаловаться может быть предоставлена скидка в качестве компенсации в размере N минут бесплатного эфирного времени.

Скидки могут предоставляться как в денежном исчислении, так и в минутах эфирного времени, при этом объем скидки может задаваться в момент ее назначения непосредственно сотрудником отдела обслуживания. При этом в приложении, отвечающем за работу с тарифными планами, обеспечивается возможность применения такой скидки к любому клиенту, независимо от того, плана, по которому тот обслуживается.

Другая концепция, получившая распространение, известна как Friends & Family и заключается в возможности поддерживать тарификацию вызовов на телефоны, входящие в индивидуально задаваемый для каждого клиента список, с некоторыми понижающими коэффициентами. Так, например, клиент может указать оговоренное количество телефонов по списку «Друзья» (Friends) и оговоренное количество телефонов по списку «Семья» (Family), вызовы на которые/с которых могут стоить дешевле, чем вызов на любой другой телефон. Уменьшение стоимости вызова происходит за счет применения понижающих коэффициентов, на которые умножается рассчитанная подсистемой тарификации стоимость вызова. Предельное количество телефонов, которые могут быть включены в каждый из списков и значения соответствующих понижающих коэффициентов (или правила расчета их значений) задаются в тарифных планах оператором связи по каждому списку. Количество различных категорий списков (и набор возможных коэффициентов по этим спискам) определяется в тарифном плане. Условия, на которых абонент может потребовать формирования списка Friends & Family, также определяются в тарифном плане. А именно, по каждому из возможных списков определяется максимальное количество телефонов в списке, метод назначения коэффициентов и сам их набор, при этом операция включения телефона в список, исключения телефона из списка, смена телефона и смена метода расчета может быть платной.

Subscriber Price Groups (SPG) — объединение абонентов биллинговой системы в группу с едиными правилами тарифицирования эфирных и ММТ составляющих (вариант понятия Closed User Group). Для абонентов, входящих в такую группу, может быть создан специальный тарифный план, позволяющий, например, производить вызовы внутри группы и по заданным направлениям ММТ на льготных условиях.

 Абоненты могут входить в несколько SPG групп попарно (т.е. если абонент А совершает звонок абоненту В; то абоненты А и В могут одновременно быть членами более чем в одной SPG), в этом случае применимость ставок из тарифных планов регулируется назначаемым приоритетом SPG групп абонента. При тарификации, если абоненты входят в одну группу, происходит «замещение» тарифного плана абонента на тарифный план группы.

 Модификация тарифных ставок может быть направлена и на создание алгоритмов обслуживания клиентов, группируемых оператором связи по признаку принадлежности их к некоторому конгломерату («объединению», образуемому ими в соответствии с их собственными заявлениями).

Такие «объединения» создаются для того, чтобы сгруппировать клиентов для последующего предоставления им скидок на стоимость услуг. Например, в одно объединения могут быть включены различные компании одного холдинга, каждая из них самостоятельно оплачивает оказанные ей услуги связи, но скидки, которые предоставляются этим компаниям, зависят от общего объема услуг, оказанных всем компаниям холдинга.

Перечисленные способы персонализации дают возможность построения иерархической объектной модели клиента. Модели, в которой предусмотрены различные уровни агрегирования клиентов и абонентов, с точки зрения специфики работы с ними. В качестве возможных направлений дальнейшего развития можно рассматривать общности клиентов на основании получения счета — фактуры (платит один, учитывает другой), COS — центров (за ряд услуг, оказанных абоненту, платит один клиент, а за остальные услуги — другой) и т.д.

Cross discounts

Упомянем еще один способ предоставления скидок. Дело в том, что право на получение скидки на какую-либо услугу вовсе не обязательно должно быть обусловлено определенным уровнем потребления этой же услуги. Многие эксперты полагают, что более эффектным и эффективным является подход, при котором потребление одной услуги позволяет получить скидку на другую, т е. при этом реализуется т. н. механизм cross service discounts. Особенно интенсивно эти механизмы обсуждаются в связи с предполагаемым широким развитием электронной и мобильной коммерции, при котором, на фоне сильного снижения стоимости обычного телефонного трафика операторы должны будут искать новые способы повышения доходов. Одним из способов стимулирования клиентов оператора связи могут быть скидки на покупаемые товары, предоставляемые при определенном уровне трафика.

Безусловно, система построения таких скидок гораздо более сложна и требует затрат вычислительных ресурсов. Но, с другой стороны, считается, что возможность работы с такими скидками и является доказательством истинной конвергентности биллинговых систем [6.5].

6.4. Трафик

Ввод новых тарифных планов и проведение акций должны сопровождаться анализом эффективности этих мероприятий [0] и для этих целей оператор должен иметь в своем распоряжении инструменты статистического анализа.

Для такого анализа могут использоваться протарифицированные учетные записи за заданный период, по которым формируются статистические отчеты в соответствии с поставленными условиями. В результате построения отчетом могут быть получены распределения количества вызовов, продолжительности вызовов, их стоимости по:

• направлениям ММТ,

• по типам зон,

• по типам логических вызовов,

• по использованным услугам, в зависимости от времени суток, тарифных планов и пр.

Так, например, на рис. 6.4.1 параметры заданы так, что выборка анализируется с учетом классов времени и типов логического вызова по отношению к стоимости вызовов, отнесенных на балансы клиентов. В соответствии с тем, что задано выявить 3 «лучших» варианта, оказывается рис. 6.4.1, что наибольший вклад в сумму дает комбинация признаков «пиковое время + вызов, входящий с ГТС», следующий по величине вклад дает комбинация «пиковое время + вызов, исходящий на ГТС» и т. д. Меняя выборки вызовов, комбинацию признаков, тип диаграмм и количество вариантов можно получить практически полную картину поведения трафика и наглядное отображение его «срезов».

6.5. Анализ тарифных планов

Анализ результатов тарификации может служить не только инструментом, позволяющим следить за динамикой изменения потребления услуг, но и, в известной степени, за корректностью построения тарифных планов. Рассмотрим пример.

Пусть для тарифных планов задана общая схема направлений, изображенная на рис. 6.5.1

Сформируем для месячной выборки звонков диаграмму, показывающую распределение количества вызовов по направлениям. Полученные данные представлены на рис. 6.5.2.

Не требуется даже сколько-нибудь детального разбора, для понимания того, что схема направлений составлена неудачно, поскольку более 90% вызовов попадают в направление «Остальные страны», тогда как на большинство остальных приходятся лишь доли процентов. При таком распределении Оператор лишен возможности гибко модифицировать тарифную политику, поскольку все что он может сделать в этой ситуации — это изменить тарифную ставку для направления «Остальные страны», которая повлияет практически на все вызовы сразу. Снижение стоимости вызовов для, скажем, Европейской части России с целью сделать это направление более популярным вряд ли приведет к радикальному изменению распределения вызовов и изменению доходов компании в силу мизерного количества звонков по этому направлению. Более целесообразным представляется изменение самой схемы направлений.

Например, все существующие направления связи, на которые приходится менее 1% вызовов можно было бы объединить в одно направление с условным названием «Прочие», а то, что собрано под заголовком «Остальные страны» — разбить на несколько. Более удачным является, вероятно, такое распределение вызовов, при котором разброс по их количеству между направлениями не будет столь резким.

Сразу оговоримся, что возможности построения отчета по результатам уже произведенной тарификации дают возможность делать на сегодняшний день только апостериорный анализ, т.е.— изучать распределение вызовов по тем направлениям, которые были сформированы на момент их совершения, и не позволяют пока отвечать на вопросы: «Что будет, если...?» — и прогнозировать изменение параметров трафика в зависимости от той или иной структуры тарифного плана. Тем не менее, даже такой анализ может оказаться мощным инструментом для заметного улучшения этой структуры.

Таким образом, если биллинговая система позволяет, с одной стороны, менять тарифные планы настолько гибко, насколько у оператора для этого хватает фантазии и, с другой стороны, позволяет анализировать последствия принятых маркетинговых решений и, при необходимости, корректировать их, то она, помимо выполнения функций АСР и АСУ становится еще и системой управления бизнесом.

ЛИТЕРАТУРА К ГЛАВЕ 6

6.1. Концепция развития рынка телекоммуникационных услуг Российской Федерации.// Вестник связи, 2001. № 1, с. 9 — 25.

6.2. Разроев Э.А. «Третье поколение» — уникальный шанс для развития отечественной электронной промышленности. // Mobile Communications International/RE, 2000, N 6, с. 12 — 17.

6.3. Аристархов Д. Будет ли тарифная война на рынке IP — телефонии. // Компьютерная телефония, 2000, № 2, с. 42 — 50.

6.4. Кантарджян Б., Бойко А. Текущая тарифная политика операторов рынка. // Мобильный мир. 2002, № 1, с. 26 — 32.

6.5. О'Меара Т. Гибкий биллинг // Mobile Communications International/RE, 2000, N 4, с. 48-50.

6.6. Гринберг М. Маркетинг услуг интеллектуальной сети. // Мобильные системы, 2001, № 3, с. 52 — 54.

7. Оператор и партнеры: проблемы интерконнекта

О нашей встрече — что там говорить,

Я ждал ее, как ждут стихийных бедствий...

В. Высоцкий

Никакая сеть не способна автономно доставить вызов из любой точки в любую, используя лишь собственные ресурсы. При рассмотрении концепций построения сетей мобильной связи, например, их часто принято называть "сетями доступа" [7.1]. Поэтому операторы связи (а сотовые операторы в большей степени, чем остальные) напоминают двуликого Януса, одна голова которого обращена в сторону клиентов, а другая — в сторону других операторов, предоставляющих им каналы связи. Для большинства видимой стороной деятельности оператора является лишь та, что связана с его взаимоотношениями с клиентами. Но существует и dark side of the Moon: необходимость взаимодействия с операторами-партнерами и расчета с ними за трафик, пропущенный через их каналы связи — то, что называется словом «интерконнект» (калька с английского interconnect).

Интерконнект является весьма емким понятием и к основным его функциям можно отнести:

• Управление поступлением денег за проданный трафик за счет быстрого и точного выставления счетов.

• Увеличение собираемости платежей за счет снижения времени на оплату счетов.

• Снижение расходов на эксплуатацию сети за счет автоматизации взаиморасчетов.

• Снижение ошибочности взаиморасчетов.

• Управление «оптовой продажей» трафика.

• Выявление маршрутов и пунктов адресации вызовов, приносящих прибыль или убытки.

• Выявление избыточных или недостаточных канальных ресурсов.

• Выявление тенденций.

• Моделирование влияния новых тарифных планов на потребление.

Отношения оператора связи и его партнеров не сводятся только к проблемам интерконнекта, и содержание интерконнекта не сводится только лишь к улаживанию взаимных финансовых обязательств между операторами, но, в контексте данной публикации нас будут интересовать именно взаиморасчеты. Когда-то давным-давно подобные расчеты между телефонными компаниями были чрезвычайно легким делом. Трафик был невелик, в каждой стране существовала только одна (государственная) телефонная компания, которая и занималась вопросами интерконнекта. Предания гласят, что часто вопросы взаимного погашения задолженности решались просто «хлопаньем по рукам» за столом переговоров или, если суммы, о которых шла речь, были малы, — они попросту игнорировались. Что касалось радиотелефонии, то весь существующий трафик практически порождался радиообменом с морскими судами, при этом сообщения часто маршрутизировались через несколько «перевалочных» пунктов, нередко расположенных в разных странах. Именно тогда Международным Союзом Электросвязи (МСЭ) была впервые изобретена несуществующая денежная единица — Золотой Швейцарский Франк, для того, чтобы преодолеть сложности взаиморасчетов с использованием валют нескольких государств; но в целом, процедура была крайне проста.

В России в течение длительного времени существовал т. н. «косвенный метод» расчетов через перераспределения доходов, для которого использовался такой параметр, как «объем продукции». Рыночные отношения побудили ввести в начале 90-х годов новый метод перераспределения средств, — практику взаиморасчетов, которая и используется сегодня всеми операторами связи. Формально, под взаиморасчетами (если говорить о России) понимается «метод прямого перераспределения доходов, полученных от предоставления услуг, между операторами сетей электросвязи, образующих сеть общего пользования, за непосредственно предоставляемые ими друг другу сетевые ресурсы и участие в передаче нагрузки этих сетей» [7.2].

Несложно понять, что когда операторов связи становится не два, а больше, структура связей между ними резко усложняется, к этому можно добавить еще и техническую диверсификацию современных услуг (обычная телефония, мобильная телефония, сети АТМ, Frame Relay и пр.). Либерализация рынка связи, которая происходит сейчас в мире, меняет отношения в области интерконнекта непредсказуемым образом; происходит спорадическое (самое подходящее слово, с учетом сетевой природы телекоммуникаций) размножение операторов и каналов и финансовые отношения между участниками рынка все меньше напоминают идиллию. В такой ситуации роль автоматизированных систем для расчета стоимости трафика, переданного по интерконнекта, сильно возрастает и роль эта заключается в генерации счетов за передачу вызовов, принятых от сторонних операторов и в сверке счетов, выставленных этими, операторами за вызовы, переданные к ним [7.3].

7.1. Взаимоотношения операторов

Традиционная форма расчетов по интерконнекту была, в свое время, одобрена МСЭ и получила название Accounting Rate System (ARS). Модель, положенная в основу ARS, была работоспособна в период монополизма операторов и основывалась на проведении т. н. «прямых расчетов». Все строилось на предпосылке, что операторам заранее известен маршрут, по которому будет доставлен вызов и они с ним согласны. Стоимость вызова определялась из условия рынка того оператора, в чьей сети этот вызов был инициирован, а участники цепочки согласовывали пропорции, в которых должен был быть поделен платеж за вызов (рис. 7.1.1). Как правило, счета оплачивались раз в месяц или даже раз в квартал, но если случались разногласия, проследить за тем, как в действительности был пропущен вызов, было невозможно. Дискуссии по таким вопросам часто заканчивались соглашением поделить убытки пополам и продолжать бизнес.

В настоящее время большинство голосовых вызовов фиксированной связи и вызовов, связанных с доступом в Интернет, передается через известное число операторов. Расчеты проводятся на основе стоимости вызова за единицу времени. При этом, международные операторы связи рассчитываются, как правило, с национальной компанией международной связи (РТТ), а сотовые операторы при передаче вызовов на дальние расстояния взаимодействуют либо с крупными компаниями фиксированной связи, либо, опять-таки, с РТТ. Но, несмотря, на такую относительно несложную схему расчетов, редкий счет по интерконнекту, оказывается, выпущен без ошибок. В этой связи не существует оператора связи, который бы не полагал, что не переплачивает своим партнерам за интерконнект. Кроме того, почти все такие счета в настоящее время выпускаются в бумажном виде и операции по их погашению проводятся вручную.

С появлением в результате либерализации и дерегуляции рынка связи новых его участников стала сильнее заметна роль двух из них: операторов транзитной связи (carriers' carriers) и их клиентов, многие из которых возникли лишь недавно в результате изменения правил игры. Только в одной Германии в последнее время было выдано около 30 новых лицензий.

Задача транзитного оператора заключается, как правило, в том, чтобы купить определенную полосу пропускания подешевле и продать ее подороже, однако для успешной деятельности ему необходимо точно знать каковы будут его собственные затраты на каждый маршрут, соединяющий его с оператором-партнером. Сущеественно, что для такого оператора система его расчетов с клиентами  должна быть «ресурсо-ориентированной».

На более низком уровне операторам приходится иметь дело с более тонкой структурой интерконнекта, когда вопрос заключается не просто в регистрации факта занятости канала и знании длины маршрута, но и в том, какая услуга была предоставлена. Например, может оказаться необходимым учитывать качество предоставления услуги (QoS) или ее класс.

В настоящее время конкуренция между компаниями стала приводить к тому, что появилось много возможностей для альтернативной передачи трафика и операторы стали заниматься его «переманиванием». Так, например, если оператор Х платит оператору Y сколько-то за передачу вызова и оператор Z платит сколько-то оператору У за передачу такого же вызова (но платит больше), то oпeратор Х может предложить Z пропускать трафик к Y через него, но за меньшие деньги.

Возникающая ситуация предъявляет весьма специфические требования к биллинговым системам. Они должны быть теперь способными поддерживать не просто взаиморасчеты, а стратегию поведения оператора на рынке, включая обеспечение маршрутизации с наименьшей стоимостью, определение тенденций и прогнозирование, точный и, главное, поддающийся аудиту расчет сумм, и быть Достаточно динамичными для работы в среде, где соглашения, ставки, топология сетей меняются ежедневно, иногда — ежечасно.

Отметим некоторые особенности биллинга в области «оптовой» трафика по сравнению с «розничной» [7.4].

• Особое внимание обращается на скорость тарификации и на скорость и удобство манипулирования со ставками. В отличие от расчетов при розничной продаже трафика на первый план выходит не выставление счетов, а именно тарификация и ее гибкость.

• В отличие от ситуации с «розничными» клиентами здесь практически отсутствуют стандартные условия и стандартные тарифные планы. С каждым покупателем трафика договариваются отдельно и устанавливают отдельные ставки.

• Широко используются форвардные ставки, которые применяются, если покупающая сторона берет на себя обязательство за временной интервал Х пропустить трафик Y.

Сейчас во всем мире число операторов связи уже оценивается цифрой 500 000 (!) [7.6] (из них — в России насчитывается уже тысячи [7.6]). Общее число соглашений по интерконнекту между ними достигло отметки, за которой следует неуправляемость, что требует поиска новых моделей взаимоотношений. В настоящее время используется две: прямые, уже упоминавшиеся, и каскадные расчеты.

Основной проблемой, возникающей при применении первого метода, является маршрутизация. В силу ошибок в конфигурации и непредсказуемых пиковых нагрузок вызов не всегда может быть пропущен по предопределенному маршруту. Это делает невозможным для оператора, в чьей сети вызов был инициирован, рассчитать полученную от него прибыль, в частности — из-за того, что оператор может и не иметь договоров с теми сетями, через которые был пропущен «нештатный» вызов. Кроме того, оператор, получающий входящий трафик, не знает ничего о том, как вызов дошел к нему, за исключением предыдущего в цепочке оператора и может быть, места инициации вызова.

При каскадных расчетах требуется лишь соглашение оператора со смежным ему, тот заключает соглашения со следующими и т. д. И оплата производится за трафик, фактически пропущенный по каналам той или иной сети. Преимущества такого подхода сводятся к следующему:

• Создаются только двусторонние соглашения и только с ближайшими «соседями».

• Каждый оператор может проводить расчеты независимо от других.

• Нет необходимости в информации обо всем маршруте вызова.

С другой стороны, при подобном подходе оператор оказывается жестко связанным с теми же ближайшими соседями, и это лишает его свободы маневра при поисках более выгодных условий. В этой связи от биллинговой системы требуется способность поддерживать расчеты с каждым из операторов в отдельности. Многие аналитики полагают, что при небольшом количестве партнеров с такой задачей может справиться система, занимающаяся обслуживанием клиентов оператора, поскольку в учетных записях, поступающих от коммутатора, содержится информация о транках, через которые был пропущен вызов.

При больших объемах передаваемого через оператора транзитного трафика или при заметном количестве смежных операторов для взаиморасчетов может потребоваться отдельная система. Отметим, что если операторы передают трафик в противоположных направлениях, то могут применяться две схемы расчетов: обычная, при которой предполагается, что стоимость единицы учета может зависеть от общего объема по направлению и классу времени, и схема расчетов по разности объемов, при которой предполагается, что стоимость единицы учета может зависеть от некоторой разности объемов по направлению, классу, времени или абоненту. В последнем случае механизм взаиморасчетов может быть существенно упрощен при встречной передаче однородного трафика.

Известно, что объем платежей за интерконнект весьма значителен. Так, например, операторы междугородней и международной связи в США платят в общей сложности иностранным компаниям около 5 млрд. долларов ежегодно.

Из-за роста потребности в расчетах по интерконнекту, в частности, предполагается, что к 2006 г. объем сделок в области биллинга достигнет $10 млрд. против 2.5 в 1997 г. В Европе используются т.н. «каскадные» или двусторонние соглашения между оператора. В Азии и Южной Америке оператор платит другому оператору определенный процент от дохода, полученного от продажи услуг конечным потребителям. Кроме того, что для операторов, которые торгуют "оптом" роль биллинговой системы не просто важна, а критична, поскольку наблюдается значительный рост транзитного трафика и число транзитных CDR (Call Details Record) начинает приближаться к числу «розничных» CDR. Операторы транзитной связи стали появляться и в России. В качестве одного из наиболее свежих примеров можно назвать компанию Петербург Транзит Телеком (ПТТ), которая начала действовать в 2000 г. и для которой компанией Петер-Сервис была разработана специальная версия Информационно-Биллинговой Системы, рассчитанная на обработку больших объемов трафика.

В связи с этим, интерконнект стал рассматриваться не только как статья расходов, но и как второй, после клиентов, источник доходов (для крупных/старых компаний). Так, существуют оценки, в соответствии с которыми расходы на интерконнект могут составлять до 75% расходов оператора, а доходы — до 50% от общих доходов [7.5, 7.7]. При работе с интерконнектом узким местом многих биллинговых систем является разумный баланс между их гибкостью и способностью обрабатывать большие объемы данных. Ряд операторов применяет для расчетов по интерконнекту параллельные биллинговые системы: данные, получаемые с mediation device, передаются сразу и на систему расчета с клиентами и на систему расчета с оператором-провайдером. Однако такая модульность не всегда обеспечивает возможность обработки больших объемов информации, которые передаются через крупных операторов связи. С ростом электронной коммерции и пакетной передачи трафика важность расчетов по интерконнекту может вырасти, поскольку заинтересованных сторон становится гораздо больше и проблема может производительности биллинговых систем может обостриться.

Суммируя сказанное и принимая во внимание, что оператор может пользоваться услугами нескольких операторов-провайдеров одновременно, что маркетинговая политика провайдера может строиться на применении «скидок» или, иначе говоря, нелинейной зависимости платы за трафик от его объема, плата за локальный трафик может ставиться в зависимость от объема трафика междугороднего, существует роуминг, переадресация вызовов и другие «хитрые» особенности современной связи, то при расчетах по интерконнекту, шиллинговая система должна:

• идентифицировать вызов, как пропущенный через канал связи того или иного оператора;

• обеспечивать сохранение информации обо всех параметрах вызова, необходимых для расчетов;

• обеспечивать возможность ввода и хранения информации обо всех данных, принимаемых провайдером во внимание при расчете стоимости трафика;

• обеспечивать корректный расчет полного за заданный период объема трафика и его стоимости с учетом ставок, установленных провайдером для различных значений объема;

• дифференцировать при расчете объемы трафика для локальных, междугородних, переадресованных, роуминговых и других вызовов.

Как это может быть реализовано?

• В системе ведется списка провайдеров, через каналы которых работает оператор связи.
• Предусматривается возможность «привязки» диапазонов номерной емкости к провайдерам.
• Предусматривается возможность «привязки» к провайдерам префиксов междугородных и международных вызовов. Предусматривается возможность ведения списка транков (транковых групп), через которые пропускаются вызовы и обработки информации при определении объема трафика с учетом транка.
• Предусматривается возможность задания для каждого провайдера собственной схемы разделения времени суток на классы времени и назначения тарифных ставок, соответствующих такому разделению.
• Предусматривается возможность задания для каждого провайдера своей схемы зон (направлений) междугородных и международных вызовов.
• Предусматривается возможность задания различных тарифных ставок для различных объемов междугородного и международного трафика.
• Предусматривается возможность задания тарифных ставок, применяемых провайдером для различных объемов локального трафика, в том числе — и с учетом зависимости локальной составляющей трафика от междугородной.

Поскольку сопоставимость данных, получаемых при расчете общего объема трафика, существенно зависит от того, как округляется продолжительность вызова при тарификации, должна быть предусмотрена возможность задания правил округления при определении длительности локальной составляющей вызова и, если необходимо, — правил округления для расчета длительности междугороднего вызова отдельно для каждого направления.

Учет роуминговых и переадресованных вызовов Известно, что при переадресации вызова к абоненту оператора, находящемуся в роуминге, учет таких вызовов может производиться двояко:

• может быть использована учетная запись коммутатора (запись с типом 4: «вызов к абоненту, находящемуся в роуминге») может быть использована информация о входящих вызовах к абоненту, содержащаяся в ТАР-файле.

Ряд биллинговых систем позволяет использовать оба способа расчета. Для того, чтобы избежать двойных начислений, в настроечной таблице подсистемы тарификации задается параметр, определяющий необходимость тарификации учетных записей типа 4.

Если параметр имеет значение, соответствующее необходимости расчета стоимости на основе информации из ТАР файла, подсистема тарификации не будет рассчитывать начисления на абонента. Или, наоборот, при другом значении параметра будет игнорироваться информация из ТАР файла, а начисления будут сделаны модулем тарификации.

 В этом случае, независимо от того, производились модулем тарификации начисления на абонента или нет, учетная запись о таком вызове обрабатывается и сохраняется в базе данных. Поэтому, при подготовке отчета по трафику эта запись не будет потеряна и суммарная информация по роуминговым звонкам будет учтена в суммарном трафике при взаиморасчетах.

При переадресации вызова от одного абонента к другому вызов, прошедший через транк Х от абонента А к абоненту В может быть пропущен дальше к абоненту С через транк У (или опять через транк Х). В этом случае возникает необходимость учесть трафик, пропущенный по каждому из транков. В этом случае плечо вызова от абонента А до коммутатора интерпретируется ИБС как исходящий вызов (локальный или междугородний), а плечо вызова от коммутатора до абонента С классифицируется отдельно, как входящая часть переадресованного вызова (как некоторое самостоятельное «направление») и отображается в специальной строке отчета по трафику.

Проблема взаиморасчетов возникает не только перед телефонными компаниями, имеющих абонентов в классическом смысле, но и перед таксофонными компаниями при т. н. «таксофонном роуминге», при котором операторы должны рассчитываться друг с другом за разговоры по «чужим» картам» [7.8].

Для учета трафика используется система управления таксофонами, которая собирает всю информацию, необходимую для контроля работоспособности и доходности таксофонов, проведения взаиморасчетов между компаниями по роуминговым звонкам и анализа продаж таксофонных карт. При этом взаиморасчеты проводятся на основе количества тарифных единиц считанных с "чужих" карточек в таксофонах регионального оператора и просуммированных системой управления. Во многих странах Запада для компаний, предоставляющих услуги междугородной и международной связи, существуют правила «равного доступа», которые предоставляют абонентам локальные операторов возможность выбирать того оператора дальней связи, через которого они предпочитают звонить в другой город (рис. 7.1.2).

Для того, чтобы сделать выбор оператора, абонент при наборе номера должен, помимо прочих атрибутов вызова, набрать т.н. Dial-Around Code (DAC), который позволяет коммутатору локального оператора произвести правильную маршрутизацию вызова. Для того чтобы не набирать каждый раз длинную последовательность цифр, абонент может попросить зафиксировать на коммутаторе код (Pre-selected Inter-exchange Carrier Соде, PIC) того оператора, через которого он собирается совершать вызовы постоянно.

С другой стороны, оператор дальней связи может решать, «принимать» или нет вызов от абонента той или иной локальной телефонной компании. Если поступивший на его коммутатор вызов будет принят, то учетная запись о таком вызове будет впоследствии тарифицирована оператором дальней связи, а соответствующая информация будет передана в локальную компанию, для учета в счете, выставляемом абоненту.

Таким образом, оператор локальной связи должен, в такой ситуации, решить для себя, как он будет тарифицировать междугородные вызовы. Он может ввести информацию обо всех тарифных планах всех операторов дальней связи в свою биллинговую систему и использовать DAC как идентификатор при проведении тарификации вызова в своей биллинговой системе, или задача тарификации может распадаться на две части. Локальный оператор тарифицирует локальной плечо вызова, оператор дальней связи тарифицирует свое плечо, а воедино эта информация сводится при проведении биллинга. При этом взаиморасчеты между операторами производятся по суммарному трафику, пропущенному через гранки, а для расчетов с абонентами может использоваться процедура, схожая с процедурой расчетом между партнерами по роумингу [7.1].

7.2. Интерконнект и новые технологии

С появлением новых технологий, таких как SMS, GPRS и услуги, реализуемые через WAP, для предоставления которых используются каналы сигнализации или каналы передачи данных GSM, становится очевидной необходимость замены текущей практики расчетов на более гибкие и сложные решения. Уже сейчас в Северной Европе до 10% дохода операторов образуется за счет передачи SMS сообщений по сигнальным сетям. В недалеком прошлом передача информации по сетям сигнализации была для операторов бесплатной, однако, с развитием IP-телефонии и услуг, характерных для мобильного сектора телекоммуникаций нагрузка на эти сети возрастает, и концепции расчетов по интерконнекту должны измениться. Операторам потребуется единая система, способная регистрировать события в сети, собирать статистику, обрабатывать CDR и информацию сетей SS7. Скорее всего, эта потребность приведет к интеграции OSS и биллинговых систем.

Рост трафика, связанного с передачей данных, привносит свои особенности в процедуры взаиморасчетов операторов. В табл. 7.1, приведенной ниже показаны отличия, характерные для обработки обычного и IP трафика [7.9].

Сейчас большинство систем, работающих в области интерконнекта, работают, лишь опираясь на CDR. Многие соглашения по взаиморасчетам носят скорее декларативный характер и допускают довольно большой (от 5 до 10%) процент расхождений между данными, которые сопоставляются с двух сторон, однако бурный рост числа операторов делает такую низкую точность расчетов недопустимой, слишком большие деньги оказываются вовлеченными в этот процесс.

В качестве примера, позволяющего оценить масштабы операций при передаче обычного и IP-вызова можно привести следующие цифры: для обычной телефонии один 5-ти минутный вызов — это одно событие; для IP-телефонии при таком вызове генерируется от 10 до 100 Мбайт данных, которые должны быть переданы по сети. Принимая средний размер пакета, равным 100 байт, получаем от 100 тыс. до 1 млн. пакетов на один вызов (при условии, что ни один пакет не потеряется). В первую очередь, это создает проблемы для буферных устройств (mediation devices), которые должны агрегировать множество промежуточной информации для получения в итоге одной учетной записи на событие.

С постепенным переходом на пакетную коммутацию пользователи будут иметь дело с десятками, если не сотнями IP сетей, которые будут предлагать услуги разного качества (и стоимости!). Интеграция различных возможностей в одном и том же мобильном терминале, когда в зависимости от места совершения вызова абонент сможет получить доступ к сети через аналоговый канал (1G), через цифровой канал (2G) или через высокоскоростной цифровой канал (3G) лишь усугубит сложность отношений между операторами.

В настоящее время разрабатывается стандарт IPDR (IP Detail Records), в соответствие с которым должны будут формироваться учетные записи при передаче данных. В отличие от «плоских» файлов фиксированного формата, которые, как правило, генерируют коммутаторы, IPDR будет построен на основе языка XML, который придаст ему гибкость и который, с другой стороны, потребует затрат гораздо больших вычислительных ресурсов. Возможно, формат XML будет применяться только для передачи учетных записей, а для хранения они будут преобразовываться в более компактный вид.

Использование языка XML приобретает все более широкие Масштабы для обмена биллинговой информацией между операторами и это видно, в частности, из следующего.

Десять лет назад двадцать телефонных компаний из 16 европейских государств основали исследовательскую организацию EURESCOM, в задачу которой входили исследования и стратегическое планирование развития по всем направлениям телекоммуникаций. Благодаря усилиям таких компаний как ВТ, KPN, Telecom Italia, Eircom, Sonera, GEGXS, Hewlett-Packard, Quintessent, входящих в EURESCOM был выработан ряд рекомендаций-стандартов, касающихся вопросов интерконнекта. В своем последнем проекте P908 EURESCOM сформулировал ряд требований в области интерконнекта на основе т. н. Common Interconnect Gateway Platform (CIGP). Эти требования касаются не только функциональности шлюзов интерконнекта, но и регламентируют некоторые бизнес- процессы. Несмотря на то, что при разработке этих рекомендаций 6ыл учтен опыт США, в основу разработки были положены все же особенности, характерные для европейского рынка. Так, например, было предложено отказаться от интерфейсов EDI и использовать XML, который, помимо того, о чем уже было сказано выше, позволит еще использовать некоторые стандартные подходы, выработанные в области электронной торговли и инструменты, подобные CommerceOne.

Это тем более важно, что, как предполагается [7.10, 7.11], традиционный интерконнект, опирающийся на межоператорские соглашения, в которых стоимость ставится в зависимость от времени и расстояния довольно скоро уступит дорогу другим механизмам расчетов, при которых оператор будет выступать как перепродавец контента и процессы взаиморасчетов станут гораздо более сложными. Здесь важно учитывать не только стоимость передаваемого контента самого по себе, но и строить отношения со всеми участниками, вовлеченными в процесс генерации и передачи контента, и их будет не один-два, как считали первобытные люди, а много (т. е.— больше двух), и попытки редукции задачи, т. е. разбиение всей цепочки на элементы, для которых возможно заключение двусторонних соглашений, вряд ли окажутся успешными.

Отметим, в заключение, что уже сейчас наблюдается резкий рост тарфика, обрабатываемого в рамках интерконнекта. Некоторые компании сообщают о том, что за год такой трафик увеличился в несколько раз (!) [7.12]. Поэтому в самом ближайшем будущем могут появиться новые подходы к решению задач тарификации в целом и тарификации при интерконнекте — в частности.

ЛИТЕРАТУРА К ГЛАВЕ 7

7.1. Mouly М., М-В Pautet. The GSM — System for Mobile Communication. 1992.

 7.2. Жигульская Г.М. Основные принципы взаиморасчетов между операторами сетей электросвязи.// Вестник связи. 1998, № 1

7.3. Turner К. Interconnect Isn'1 What it Used to Ве: Accounting Systems Need to Change in Competitive Europe // Billingworld. 1999, № 11.

7.4. Slavic F. Handling wholesale.// Billing, 2001, January/February, р. 56-61. 7.5. Schwartz S. Next-Generation lnterconnect// Billing World, 2000, N 4.

7.6. Концепция развития рынка телекоммуникационных услуг Российской Федерации.// Вестник связи, 2001, № 1, с. 9 — 25.

7.7. Lucas J. Why Have an IP Carrier-to-Carrier Billing Reconciliation Strategy? // Billing World 1999, N 11.

7.8. Антоновская Е.Е. Таксофонный роуминг на Северо-Западе России //Вестник Связи 1999, № 3.

7.9. McBride R., Gibbs G. Overcoming the Challenges of Billing for IP Interconnect // Billing Systems 2000 Conference Paper. London. 10-13 April.

7.10. Haeffner А., Donahue J. OSS interconnection In Europe and Asia // TelOSSource Magazine, 2000, № 8. www.telossource.com.

7.11. Jackson В. The correct way to bill // European Communications. Winter 2000/2001, р. 67-69.

7.12. Chester J. The size of billing to соте — handling scalability // Billing, 2001, March, р. 17-20.

8. Оператор и партнеры: проблемы роуминга

Я ищу тебя в знойной пустыне,

Я брожу по расколотой льдине,

Ну, скажи, хотя бы, как тебя зовут.

Под роумингом понимается возможность абонента какого-либо оператора путешествовать из города в город и из страны в страну и совершать вызовы из сети другого оператора. При этом различают три разновидности роуминга: ручной, полуавтоматический и автоматический.

При ручном роуминге в «чужой» сети абоненту выдается телефонный аппарат и назначается временный телефонный номер, принадлежащий этой сети, роуминг при этом возможен между сетями разных стандартов. При полуавтоматическом роуминге абонент может пользоваться своим аппаратом, но в «чужой» сети ему присваивается временный номер. Наконец, при автоматическом роуминге абонент может пользоваться и своим аппаратом и номером, назначенным ему в его собственной сети. Именно возможность автоматического роуминга для абонентов стандарта GSM и предопределила его необычайную популярность. До недавнего времени один лишь факт того, что с телефоном можно путешествовать и быть досягаемым уже воспринимался как чудо; все, что для этого требовалось от операторов — подписать роуминговое соглашение и провести необходимое тестирование; остальное было заложено в стандарт. Основными услугами, востребованными при роуминге, являлись, — да и до сих пор являются — передача голосовых сообщений и SMS, переадресация вызовов, получение справок, за которые и должен платить клиент. Однако процедуры расчетов с клиентами при роуминге значительно усложняются, поскольку здесь неизбежно, помимо пары оператор-клиент появляются и другие участники взаимоотношений — те операторы, из сети которых совершаются роуминговые вызовы. Эти взаимоотношения и процедуры расчета за такие вызовы регулируются специальными соглашениями и документами; при этом существуют как двухсторонние договоренности, так и договоренности, общие для определенного стандарта связи [8.1, 8.2]. Напомним, что когда роуминг мобильных абонентов еще только начинался, была предложена специальная процедура расчетов за услуги мобильной связи, полученных при роуминге, которая получила название TAP (Transferred Account Procedure) — так именуется метод оплаты, когда вызовы в «чужой» сети совершает визитер (или роумер, т.е. клиент, пользующийся услугами связи вне собственной сети), но за пользование связью в этой сети платит не он сам <визитер>, а оператор, с которым у роумера, заключен договор, и который, в свою очередь, получает эти деньги со странника, не побоявшегося затребовать услугу (если быть точным, эта процедура использовалась еще до появления роуминга в банковском деле, но для расчетов за роуминг оказалась очень подходящей).

Поскольку наиболее развитым в этом отношении роуминга является стандарт GSM, имеет смысл познакомиться с особенностями обработки соответствующей информации в биллинговых системах именно на его основе. Несколько слов об общей нормативной базе, действующей в области роуминга, уже было сказано в гл. 2, здесь мы остановимся на специфике стандарта GSM немного подробнее.

8.1. Основные положения MoU GSM

Для понимания идеологии роуминга и расчетов, производимых в его рамках, важно понимание того, что сеть отдельно взятого оператора не является изолированным объектом, а входит в единую глобальную систему (например, стандарта GSM), дающую своим абонентам возможность практически повсеместного пользования связью, в какой бы другой сети они не находились, операторы должны иметь инструмент, позволяющий фиксировать и тарифицировать вызовы независимо от их географии. При этом обработка информации о вызовах своих абонентов, находящихся в сети другого оператора, или о вызовах чужих абонентов в своей сети не может опираться только на внутренние правила, установленные для своих клиентов, и должна основываться на некоторых общих для всех операторов данного стандарта принципах. Эти же принципы с необходимостью должны найти свое отражение и в работе биллинговой системы. Все они детально описаны в официальных документах MoU и часть из них воспроизведена ниже.

Право на использование роуминга в сети GSM дает договор, заключенный клиентом с одним из операторов стандарта GSM. Договор дает право на использование услуг связи в любой сети стандарта GSM, если это не вступает в противоречие с законодательством той страны, где владелец мобильной станции хочет воспользоваться услугами связи при роуминге.

Счет за предоставление права доступа к сети при роуминге выставляется оператору, с которым у визитера заключен договор.

• Счет за использование услуг связи выставляется оператору, в сети которого вызов был инициирован или в сеть которого вызов был адресован.

• Правила национального роуминга строятся на основе законодательства соответствующей страны.

8.2. Основные принципы начислений

Каждый оператор свободен в выборе своих тарифов и условий их применения. Детали начисления являются объектом стандартизации (для адекватного составления счета и обмена информацией о начислениях).

Взаимоотношения с операторами, через сети которых происходит маршрутизация вызовов, строятся на двухсторонней основе.

• Инициатор вызова оплачивает его полную стоимость. Исключения:

• вызов к абоненту, находящемуся в роуминге;

• переадресация вызова.

• Если визитер совершает вызовы только внутри той сети, в которой он в данный момент находится, он платит точно так же, как и «свой абонент». При этом должен применяться стандартный тарифный план. Дополнительное увеличение стоимости использования сети определяется коэффициентом, который не должен превышать значения 1.15. Вызовы всех визитеров должны тарифицироваться одинаково.

• Счет за роуминговые вызовы выставляет оператор, заключивший с клиентом договор на основе информации, получаемой через ТАР.

• Применение ставок, зависящих от времени, за звонки типа «Входящий на мобильный», должно быть согласовано на двусторонней основе.

• Если оператор, эксплуатирующий сеть, предоставляет своим абонентам право на бесплатное получение входящих вызовов, то это право распространяется также и на визитеров.

• При роуминге вызываемая сторона, которая находится в данный момент времени «не по своему адресу», несет все дополнительные расходы, связанные с переадресацией вызова (оплачивает т.н. плечо роумингового вызова).

• Для снижения влияния колебания курсов валют, информация о начислениях передается от оператора к оператору в SDR. Если для передачи информации используются магнитные ленты, пересылаемые по почте, общий объем суммы подлежащей уплате за вызовы, содержащиеся в файле дополнительно сообщается Оператору. Уведомление о доставке (Delivery Note), которым сопровождается почтовое отправление, содержит информацию, необходимую для идентификации конкретного файла (его номер и дату создания файла — Individual Transfer). Обмен информацией при помощи магнитных лент допустим только при исключительных обстоятельствах или при соответствующей двусторонней договоренности.

• При электронном обмене EDI (Electronic Data Interchange— электронный способ обмена информацией о транзакциях между организациями), ежедневно или через взаимно согласованные промежутки времени, уведомление о доставке не применяется. Если записи, подлежащие включению в TAP- файл, отсутствуют, передается файл содержащий только заголовок, включающий Individual Transfer, и строку, закрывающую файл.

• Уведомление о доставке не заменяет собой счет. Периодически, оператор, отправляющий TAP-информацию, должен выставлять счет, в котором должна быть указана вся информация, необходимая для идентификации ранее переданных файлов, включая и файлы без начислений (номер и дату создания файла). Счет должен полностью соответствовать налоговому законодательству страны отправителя. Это может означать, что сумма к оплате в счете будет включать в себя НДС, хотя ранее переданные файлы могли не содержать такой информации. Для того чтобы облегчить последующую обработку счета и возможный возврат НДС, суммы в счете должны быть указаны как в SDR, так и в национальной валюте оператора. В TAP-файле обычно указывается примененный курс SDR в каждой учетной записи, для того, чтобы можно было бы восстановить стоимость вызова в национальной валюте и сопоставить эту стоимость со счетом.

8.3. Состав TAP-файла

В соответствии со сказанным ранее, TAP-файл должен содержать следующую информацию:

• Имя оператора-отправителя.

• Имя оператора-получателя.

• Время отсечки учетных записей.

• Информацию об учете налогов.

• Идентификатор файла.

• Дату создания файла.

• Информацию о вызовах, включающую в себя:

Для звонков типа «исходящий мобильный»:

• IMSI вызывающего абонента.

• Идентификатор коммутатора (места), где мобильная станция находилась в момент вызова.

• Идентификатор страны и сети, в которую был адресован вызов.

• Класс мобильной станции.

• Дата и время начала вызова (с точностью до секунды). Оплачиваемую продолжительность вызова (с точностью до секунды).

• Объем переданных данных (в сегментах по 64 октета). Стоимость вызова в SDR.

• Курс SDR с точностью до пяти десятичных знаков. Ставку налога с точностью до двух знаков.

Для вызовов типа «входящий мобильный»: IMSI вызываемого абонента.

• Код страны и сети инициации вызова.

• Идентификатор вызывающего абонента (там, где это возможно технически и разрешено законодательно).

• Идентификатор коммутатора (места), где мобильная станция находилась в момент приема вызов Класс мобильной станции.

• Дата и время начала вызова (с точностью до секунды). Оплачиваемую продолжительность вызова (с точностью до секунды).

• Объем переданных данных (в сегментах по 64 октета). Стоимость вызова в SDR.

• Курс SDR с точностью до пяти десятичных знаков. Ставку налога с точностью до двух знаков.

Строка, закрывающая файл, содержит:

• Полное количество вызовов, включенных в файл.

• Дату и время начала первого и последнего вызовов в файле.

• Сумму к оплате по данному файлу в SDR.

ТАР-файл должен также включать в себя и частичные учетные записи, относящие к вызовам, незавершенным в момент отсечки. Каждой частичной учетной записи должна соответствовать своя строка в ТАР-файле. ТАР-файлы, в которых пропущена указанная информация, рассматриваются как недействительные.

Если в TAP-файле налоги учтены в стоимости каждой учетной записи, то в заголовке файла присутствует символ Y ("Yes"). Символ N ("No") означает, что либо налоги будут учтены только в выставленном счете (тогда в TAP-файле будет указана ненулевая ставка налога), либо налоги не учитываются вообще (тогда в TAP- файле будет указываться нулевая ставка налога).

Сейчас жесткая конкуренция заставляет операторов искать все новые источники дохода и предлагать все новые услуги. Уже сегодня требуется поддерживать такие опции для клиентов, как индивидуальные схемы расчетов, работу с закрытыми группами пользователей, IP-услуги, скоростную передачу данных и многое другое.

Информацию о потреблении появляющихся услуг стало затруднительно передавать в виде «плоского» файла со строкой фиксированной длины. Поэтому Ассоциация GSM разработала новый стандарт передачи биллинговой информации при роуминге — TAPА. В рамках этого стандарта возможна передача данных различного типа и объема и этот стандарт является более гибким, чем применявшиеся ранее.

8.4. О формате TAPА

Перечислим требования, которым TAPА должен удовлетворять, по мнению его создателей.

• Поддержка работы с высокоскоростной передачей данных HSCSD (High Speed Circuit Switched Data). Подразумевается использование до 4-х временных интервалов (слотов), со скоростью передачи информации 14,4 Кбит/с и увеличение общей скорости передачи до 57,6 Кбит/с. За время вызова скорость передачи может меняться. Возможность изменения скорости передачи влечет за собой изменение принципов начисления за вызов и, в свою очередь, информации, передаваемой в TAP-файле.

• Поддержка работы технологии GPRS (General Packet Radio Service). Подразумевается использование до 8-ми временных слотов с общей скоростью передачи 115 Кбит/с, возможность виртуальных соединений (снижение стоимости передачи для пользователя и повышение эффективности эксплуатации сети для оператора), немедленная коммутация по мере готовности пакетов.

• Поддержка работы технологии CAMEL (Customized Application for Mobile Enhanced Logic). Подразумевается появление роуминга для клиентов, обслуживающихся по prepaid-схеме (планируются также и другие применения CAMEL) за счет использования интеллектуальных сетей, возможность использования сокращенного набора, возможность организации VPN (Virtual Private Network). Если услуги CAMEL были использованы в течение вызова, могут применяться начисления по принципу «за каждое использование».

• Поддержка услуг MSP (Multiple Subscriber Profile). Предполагается возможность использования нескольких MSISDN для телефонии, связанных с одной SIM-картой. Это даст возможность получать на один и тот же телефон вызовы, связанные со служебной деятельностью, личные вызовы, вызовы от различных знакомых и пр. и тарифицировать эти вызовы по различным тарифным планам.

• Поддержка PNP (SPNP = Support of Private Numbering Plan). Предполагается использование короткого набора, правила которого устанавливаются пользователем.

• Поддержка расширенных возможностей работы с SIM- картами. Предполагается возможность загрузки в SIM-карту информации, хранящейся в «домашней» сети. Роль TAPА в поддержке этих возможностей состоит в передаче флага, свидетельствующего о том, что вызов был инициирован SIM Toolkit application.

• Поддержка системы кодирования, повышающей качество передачи голосовой информации EFR (Enhanced Full Rate Codec). Подразумевается применение новых систем кодирования звуковой информации и улучшенная помехозащищенность (в частности - борьба с эхом). Задача нового формата заключается при этом, в передаче информации о затребованной и полученной версии Codec'а.

• Поддержка системы сбора fraud информации (Fraud Information Gathering System, FIGS). TAPА предусматривает передачу флага, означающего то, что вызов был учтен во Fraud-отчете.

• Поддержка новой процедуры возврата файлов ВЮЙАР (Return and Reject Procedure).

8.5. Отличительные черты формата TAP3

В отличие от своих предшественников, файлы формата TAPА не являются текстовыми файлами, не имеют ни фиксированной спины строки, ни фиксированной структуры. В соответствии с принятой договоренностью, для описания данных, содержащихся в этих файлах, используется специальный язык — т.н. Abstract Syntax Notation (ASN.1). Этот язык оказался удобным потому, что его формализм поддерживается международными стандартами, он широко используется в различных протоколах телекоммуникаций и позволяет описывать структурированную информацию. ASN.1 позволяет также описать набор данных, отражающих предметную область, идентифицировать тип данных при передаче и присваивать данным значения. Другими словами, ASN.1 дает возможность построить модель данных, включающую в себя:

• описание структуры самого TAP-файла,

• сведения об отдельных вызовах,

• группы атрибутов и отдельные атрибуты вызовов,

• вспомогательную (необязательную) для TAP-файла информацию

и допускающую неограниченную вложенность атрибутов, при этом не существует ограничений на размер записей; нет необходимости передавать «пустые» символы, если необходимая информация в файле отсутствует, существует возможность добавления новых элементов, безболезненная для стороны, обрабатывающей информацию из файла.

Для того, чтобы существующие биллинговые системы смогли обрабатывать информацию, содержащуюся в файле TAPА, требуются программы-компиляторы и синтаксические анализаторы ASN.1, кроме того, должны учитываться требования, накладываемые на синтаксис формата TAPА как такового и оговариваемые документом TADIG TD.57. Еще одной особенностью формата TAPА является то, что применяемое там представление данных опирается на объектно-ориентированный подход, что для эффективной обработки информации требует применения соответствующих средств, таких как, например, объектно-реляционная СУБД Oracle 8. В противном случае, преимущества, получаемые от перехода на работу с форматом TAPА, могут быть утеряны на этапе перевода описания объекта в стандартное табличное представление.

8.6. Что требует ТАРЗ?

Для реализации всех возможностей, заложенных в новый формат, требуется программный комплекс, позволяющий на основе анализа входящего файла:

• производить корректное (т.е. без потери данных) преобразование формата полученного файла в другой формат, удобный для работы,

• строить некоторую «внутреннюю» объектную структуру, адекватно отображающую структуру TAP-файла,

• производить т.н. «валидацию» файлов, т.е. — оценку полноты и корректности содержащейся там информации,

• формировать внутреннюю логическую структуры, описывающий каждый вызов в отдельности,

• производить расчет составляющих стоимости вызова (например, markup),

• при внедрении процедуры R8 RP производить формирование RAP-файлов в случае обнаружения ошибок во входящих TAP-файлах,

• сохранять полученную объектную структуры по каждому вызову.

При подготовке исходящей информации должны производиться обратные действия. На основе результатов тарификации CDR должна быть построена объектная структура для каждого вызова, а потом — объектная структура файла в целом и должен быть скомпилирован исходящий TAP-файл в формате ASN.1

Освоение формата TAPА еще только-только начинается. Но, чисто формальный, казалось бы, аспект обработки информации может оказаться фактором, заметно влияющим на маркетинговый климат в рыночной нише оператора. Чем раньше оператор связи перейдет на использование формата TAPА, тем больше преимуществ он получит на рынке.

Однако, на сегодняшний день известно об очень ограниченном количестве решений, способных поддерживать работу с новым форматом. Во всяком случае, автору достаточно подробной информации по этому вопросу найти не удалось. С другой стороны, учитывая важность и актуальность этой темы, было бы обидным оставить ее совсем без внимания. Поэтому автор берет на себя смелость описать процессы, происходящие при обработке файлов формата TAPА опираясь на технические особенности того решения, которое было предложено его коллегами, не преследуя при этом никаких маркетинговых целей.

8.7. Система поддержки роуминга «Петер-Сервис»

8.7.1. Архитектура и функции

Система для обработки файлов TAPА построена как автономный программный комплекс, который может быть интегрирован с любой биллинговой системой. Интерфейс между системой и биллинговой системой оператора строится на основе технологии CORBA, а в качестве формата обмена данными между этими двумя системами использован XML формат данных. С учетом того, что портирование XML пакетов является одной из стандартных операций, поддерживаемых СУБД Oracle, эти два упомянутые обстоятельства позволяют использовать систему в автономном режиме на любом из компьютеров сети, где весь интерфейс обмена данными происходит по ORB шине.

В целях повышения производительности, а также снижения нагрузки на сервер базы данных биллинговой системы, система имеет свой сервер БД, построенный на основе СУБД ORACLE Si. Использование данной СУБД позволяет также более эффективно использовать ее объектные возможности для работы с данными, в том числе поддержку XML формата.

Основным модулем биллинговой системы, с которым взаимодействует CAP является модуль тарификации. Это взаимодействие осуществляется через интерфейсы CORBA или DCOM. В данной схеме CAP всегда работает как сервер по отношению к модулю тарификации  все действия по инициализации необходимых процессов осуществляются по запросу клиента (т.е. модуля тарификации). При этом каждое обращение к серверу предусматривает запуск отдельной цепочки (нити) обработки входных данных. Допустимое количество запускаемых в CAP нитей определяется свободными ресурсами компьютера, на котором работает система.

Функции, поддерживаемые системой, могут быть условно разделены на внешние, реализуемые при интерфейсе с внешней средой, и внутренние, организующие работу самой системы. К внешним функциям можно отнести:

• получение и обработку входящих TAP-файлов; подготовку исходящих TAP-файлов;

• подготовку детальных данных о вызовах для дальнейшей их обработки в биллинговой системе и сохранение этой информации в собственной базе данных;

• поддержку всех операций с тестовыми TAP-файлами;

• выпуск счетов для партнеров по роумингу за обслуживание визитеров, обработку

• счетов, выставленных за обслуживание собственных клиентов, сверку счетов;

• подготовку статистических отчетов о расчетах за вызовы, сделанные в роуминге;

• поддержку операций, связанных со fraud-контролем (мониторинг, генерация и рассылка fraud-отчетов);

• генерацию статистических отчетов о предоставленных при роуминге услугах и визитерах, определение рейтинга партнеров по роумингу;

• поддержку процедуры R8 RP;

• поддержку возможности предоставления скидок на уровне отдельных вызовов и расчет надбавок (markup) в соответствии с новыми правилами IOT;

• выпуск счетов-фактур для партнеров по роумингу.

К внутренним функциям относятся:

• поддержка работы со справочной информацией (данные о партнерах, курсах валют и пр.);

• контроль целостности информации в базе данных;

• архивирование неактуальной информации;

• управление доступом к информации, защита информации от несанкционированного доступа.

Биллинговую систему и автономную систему роуминга ТАР3 можно рассматривать как распределенную вычислительную структуру, в которой независимость операций, связанных с поддержкой роуминга обеспечивается за счет стандарта CORBA/DCOM и применения языка XML для описания объектной структуры файла.

Схематически, взаимосвязь биллинговой и роуминговой систем иллюстрируется рис. 8.7.1.

8.7.2. Взаимодействие системы роуминга с модулем тарификации

Система TAPА использует для подготовки отправляемой информации учетные записи уже обработанные модулем тарификации биллинговой системы. В этом модуле может производиться тарификация всех вызовов как по единому для всех партнеров тарифному плану, так и по различным планам (в зависимости от собственных надстроек модуля) с учетом скидок. Предполагается, что вся информация, необходимая для тарификационных расчетов, находится внутри биллинговой системы.

Данные по начислениям в обработанных учетных записях могут содержать информацию о примененных налогах или нет. В системе существует возможность произвести расчет по любым видам налогов, если он не был выполнен на предшествующих стадиях обработки, или аннулировать те или иные налоги, в точном соответствии с условиями договора о роуминге с конкретным оператором (в соответствии с законодательством страны-оператора VPLMN и предусмотренными возможностями возврата налогов).

Если тарификацию учетных записей необходимо производить в различных валютах для разных партнеров по роумингу, то на вход системы может быть передана дополнительная информация о валюте, в которой произведены расчеты.

Процесс связи системы TAPА с биллинговой системой инициализируется по следующим событиям:

Завершение тарификации новых учетных записей визитеров.

Передача группы учетных записей визитеров, которую по каким-либо причинам (например, неготовность системы, отсутствие канала связи, сбои, ошибки в исходной информации и т.д.) необходимо передать повторно.

Требование замены группы ранее переданных учетных записей в результате их неправильной тарификации или отката результатов ранее произведенной тарификации.

Обработка поступающей информации производится по мере поступления тарифицированных записей. При этом производится синтаксическая и аналитическая обработка поступающей информации, в том числе проверки на возможное дублирование информации. В результате обработки формируется либо подтверждение успешного завершения операции, либо сообщение об отказе в приеме данных с кодом ошибки.

Взаимодействие модуля тарификации оператора с системой ТАРЗ происходит в режиме пакетной передачи данных. Каждый пакет содержит собственный идентификатор и содержательную часть. Минимальной (единичной) порцией содержательной информации является тарифицированная учетная запись по одному вызову.

Каждый полученный на вход системы пакет данных загружается в исходном виде в БД системы. Срок хранения входных пакетов данных определяется настроечным параметром и самостоятельно устанавливается оператором. Независимо от значения этого настроечного параметра минимальное время хранения пакета данных составляет 72 часа.

Операция приема данных в системе сопровождается заполнением протокола результатов обработки (файл). Место размещения файла протокола в файловой структуре сети оператора настраивается в блоке администрирования системы.

Рис. 8.7.2 иллюстрирует процесс получения учетных записей из биллинговой системы.

8.7.3. Передача данных из системы роуминга в биллинговую систему оператора

При таком взаимодействии в биллинговую систему передается информация об использовании услуг международного и национального роуминга собственными абонентами оператора для послеведении биллинга (например, для детализации биллинговых счетов, отражения стоимости роуминговых звонков на балансах клиентов, получение различных справок по требованию абонентов и т.д.).

Процесс передачи данных в биллинговую систему («выгрузка») инициализируется либо при наступлении определенного события в системе роуминга, либо на основании запроса от системы/подсистемы, получающей информацию. В каждом из этих случаев применяется один и тот же алгоритм выгрузки. Если выгрузка инициируется по запросу, то процесс выгрузки запускается с учетом параметров запроса.

В процессе выгрузки доступны следующие возможности:

1. Оператором сам, при помощи специальной системы конфигурирования выходной информации, определяет объем выгружаемых данных с вызовами абонентов. Частным случаем является выгрузка всех данных по всем вызовам. Данные, при этом, могут дополняться сведениями о начислениях или скидках, примененных в системе роуминга.

2. Выгружаемая информация может передаваться как потока данных или как файл оговоренного формата.

3. При выгрузке может быть использована опция передачи только новых данных по всем абонентам.

4. Выгрузка может производиться повторно по одному или по всем абонентам с учетом заданных параметров. В качестве таких параметров для отбора повторно выгружаемых данных служат: IMSI абонента, заданный период времени, номер ранее выгруженного пакета, название сети того или иного партнера по роумингу.

5. Доступна выгрузка в биллинговую систему данных о корректировках по начислениям, связанных с ранее выгруженными вызовами абонентов.

6. Поддерживается протоколирование результатов выгрузки данных.

Для согласования процедур обмена информацией между различными системами выгрузка данных производится в формате XML (рис. 8.7.3).

8.7.4. Взаимодействие с внешними, по отношению к биллинговой системе оператора, источниками данных

Под внешними источниками данных по отношению к биллинговой системе оператора понимаются поставщики услуг (платные

телефонные справочные службы, службы доставки и т.д.). Ввод указанной информации осуществляется в ручном или в полуавтоматическом режиме (из файла, но с ручной корректировкой и подтверждением). К взаимодействию с внешними подсистемами можно отнести также процедуры формирования исходящих и обработку входящих файлов.

8.7.5. Исходящие TAP файлы

Исходящие TAP-файлы формируются в формате ASN.1 Запуск процедуры формирования происходит в соответствии с настраиваемым расписанием или непосредственно по команде пользователя системы.

Для каждого партнера по роумингу может быть задано индивидуальное расписание подготовки исходящих TAP-файлов. Соответственно, выгрузка подготовленных данных исходящих TAP-файлов может, в зависимости от параметров запуска процесса, производиться как для всех партнеров по роумингу одновременно, так и отдельно для каждого из них. Инициализация выгрузки данных производится специальным диспетчером выгрузки данных (рис. 8.7.4).

В случае совпадения в расписании времени формирования исходящих TAP-файлов для нескольких (или даже для всех) партнеров по роумингу диспетчер может запустить один или несколько параллельных

процессов выгрузки, указывая при этом для каких партнеров по роумингу должен выгружать записи каждый из экземпляров процесса. Управление количеством запускаемых диспетчером процессов выгрузки данных производится с помощью настроечных параметров из специального блока конфигурирования. При запуске каждого экземпляра процесса диспетчер делает запись в рабочий журнал.

Процесс выгрузки отбирает записи, подлежащие отправке указанным партнерам по роумингу, в индексированном порядке. По мере выборки данных, записи по каждому партнеру в отдельности передаются в модуль формирования собственно исходящих ТАР- файлов. При этом процесс выгрузки сообщает модулю формирования все данные, необходимые для формирования исходящего файла. При получении ответа от модуля формирования о завершении обработки порции данных по одному партнеру процесс выгрузки завершает свою работу или передает модулю формирования данные о следующем партнере и т.д.

Каждая неучтенная в ранее сформированных исходящих ТАР- файлах запись подается на вход модуля формирования исходящих ТАР-файлов. Данные по каждому из вызовов поступают на вход этого модуля в виде объектной структуры, сформированной в системе на этапе загрузки данных из модуля тарификации. Задачей модуля формирования является. создание на основе объектной структуры вызова целостной объектной структуры всего исходящего файла. Объектная структура, собственно и представляющая собой исходящий TAP-файл, подвергается предварительной валидации и преобразуется затем в файл формата ASN.1.

Сформированный исходящий TAP-файл передается для отправки партнеру по роумингу. Адрес получателя сформированного файла указывается модулем формирования. В качестве адреса могут быть использованы либо имя каталога и путь доступа к нему, либо адрес электронной почты, по которому файл должен быть отправлен.

8.7.6. Входящие TAP файлы

Инициализация процесса обработки входящих TAP-файлов производится:

• при поступлении сообщения от операционной системы, о том, что поступил очередной файл;

• по заданному расписанию;

• непосредственно по команде пользователя;

и включает в себя следующие действия:

• сохранение в БД системы оригинала входящего TAP- файла;

• преобразование входящего двоичного TAP-файла в формате ASN.1 во внутреннюю объектную структуру, формат которой аналогичен формату ASN.1;

• валидацию входящего TAP-файла;

• формирование внутренней структуры по каждому вызову в отдельности, которая впоследствии будет использована в процессе передачи данных биллинговой системе оператора;

• расчет дополнительных составляющих стоимости (markup)

• запись объектной структуры каждого вызова в отдельности в БД системы;

• формирование RAP-файлов при обнаружении ошибок во входящих файлах.

Схема процесса обработки входящих TAP-файлов представлена на рис. 8.7.5.

Поступающий файл подается на вход приемника TAP-файлов, выполняющего следующие задачи:

• передачу входящего файла на вход декодера данных;

• передачу декодированного файла модулю валидации (в формате ASN.1);

• при успешной валидации приемник передает файл на вход преобразователя файлов формата ASN.1 во внутреннюю объектную структуру, передача файла производится частями по каждой записи отдельно;

• при неудачной валидации процесс обработки файла завершается, в протокол обработки производится запись о возникновении ошибки;

• фиксацию (COMMIT) принятых вызовов роумеров в БД системы.

Перед выполнением операции декодирования приемник входящих TAP-файлов может производить сохранение исходного файла в БД системы. Опция сохранения оригинала входящего TAP-файла в БД системы задается специальным настроечным параметром.

При валидации входящих TAP-файлов производятся следующие проверки:

• проверка синтаксиса элементов TAP-файлов;

• проверка правильности оформления служебной части файла (наименование, заголовок, итоги и т.д.), а также правильность составления и использования в файле кодировочных таблиц (налоги, скидки, и т.д.);

• проверка дублирования записей о вызовах внутри файла. 

Проверка правильности представления данных по каждому вызову в отдельности в соответствии с документом 7057 в модуле валидации ТАР-файлов не производятся.

При преобразовании вызовов роумеров во внутреннюю объектную структуру, процесс валидации входящих ТАР-файлов продолжается, но уже на уровне отдельного вызова. Полученная объектная структура сохраняется в БД системы. Процесс преобразования может включать в себя также и расчет дополнительных начислений (markup) на вызовы роумеров.

В случае обнаружения ошибок по какому-либо вызову этот вызов возвращается приемнику как ошибочный, при этом делаются соответствующие записи в протокол обработки данных.

При отбраковке отдельных записей в составе файла могут быть выполнены следующие действия:

• прекращение операций по приему файла в целом;

• отбраковка только ошибочных записей в составе файла и продолжение обработки только "хороших" записей.

8.7.7. Скидки

Выше мы уже коснулись некоторых аспектов взаимосвязи операций по обмену информацией и проблем маркетинга (справедливости ради следует сказать, что переход на использование нового формата ТАР-файлов затрагивает не только службы маркетинга и, естественно, роуминга, но и другие подразделения оператора). Pacсмотрим теперь немного подробнее то, что, помимо открытия новых услуг, описываемая система ТАР3 может дать оператору связи с точки зрения влияния на текущую рыночную ситуацию.

Есть два аспекта роуминга, с которыми службе маркетинга приходится иметь дело. Это:

• изучение собственной абонентской базы для выяснения того, какие именно услуги окажутся востребованными при роуминге и для обоснованного заключения соответствующих роуминговых соглашений;

• изучение потенциальных визитеров с точки зрения выявления их потребностей и максимально широкого их привлечения в собственную сеть.

Если деятельность, связанная с анализом абонентской базы, затрагивает, в основном, функционирование биллинговой системы в целом и выпадает за рамки настоящей публикации, то второй аспект напрямую связан с работой системы TAPА. Известно, в частности, что одним из наиболее эффективных инструментов маркетинга является система скидок, которые могут быть связаны с теми или иными условиями.

Система роуминга TAPА позволяет предоставлять скидки визитерам из других сетей, причем эти скидки могут назначаться по-разному для различных партнеров по роумингу (некоторые опции будут включены в следующий релиз системы). В соответствии с новыми принципами расчета IOT система позволяет работать не только со скидками, но и надбавками на роуминговые вызовы.

Не менее важна для оператора и возможность предоставлять скидки за роуминг своим собственным абонентам. Для полномасштабной реализации такой функции необходим доступ к информации об абонентах, хранимой в биллинговой системе. Автономно работающая система TAPА такого доступа к этой информации не имеет, поэтому скидки, дифференцированные по клиентам должны предоставляться непосредственно в биллинговой системе. Однако, предоставление скидок, рассчитываемых по общим для всех клиентов правилам, может быть реализовано и в системе TAPА.

8.7.8. Отчеты

Другим важным инструментам является возможность получения аналитической информации, на основе которой могут приниматься решения в области рыночной политики. В рамках уже доступного релиза система дает возможность получить следующие отчеты:

1. По сформированным TAP файлам.

2. По сформированным Fraud-отчетам с возможностью настройки вида отчета.

3. По полученным TAP файлам.

4. Счета партнерам по роумингу с возможностью настройки вида отчета.

5. Отчет по вызовам абонентов.

6. Отчет по вызовам роумеров.

7. Отчет по объемам оказанных услуг между партнерами по роумингу.

8. Отчеты по взаиморасчетам с партнерами по роумингу (выставленные счета, сроки оплаты, информация по задолженности и т.д.).

9. Отчет по партнерам (название, диапазоны IMSI, номер тарифного плана, другая информация общего характера).

10. Отчет по начисленным в системе скидкам на звонки роумеров.

11. Отчет по предоставленным кредитам для роумеров.

При решении вопроса о том, по какой цене будут продаваться роуминговые услуги не последнюю роль играет их себестоимость, в которую входят и затраты на приобретение и эксплуатацию оборудования, поддерживающего необходимые операции. Заметим, что система автоматического роуминга TAPА может быть развернута на любой аппаратной платформе, в частности — на платформе Intel, что, в совокупности с весьма умеренной стоимостью программного обеспечения системы TAPА, позволяет получить определенные преимущества в ценовой политике оператора.

8.7.9. Технические возможности системы

С учетом общих качеств системы, о которых было упомянуто выше (автономность, масштабируемость в широких пределах, использование технологий распределенных вычислений, возможность работы на любой платформе) система роуминга поддерживает весь комплекс операций, необходимость в которых может возникать при предоставлении услуг роуминга. К этим операциям можно, в частности, отнести:

• текущую работа с базой данных партнеров по роумингу;

• контроль работы подсистем формирования и обработки исходящих (входящих) TAP-файлов;

• формирование, выставление и контроль оплаты счетов партнерам по роумингу;

• ввод в систему и контроль оплаты счетов, полученных от партнеров по роумингу;

• предоставление информации об обработанных вызовах, полученных от партнеров по роумингу, для их последующего учета в биллинговой системе;

• формирование отчетности по взаиморасчетам с партнерами по роумингу;

• контроль работы подсистемы генерации fraud-отчетов.

В качестве минимальной конфигурации, поддерживающей работу подсистемы, может быть использована следующая:

• Процессор Pentium2-200.

• RAM = 128М.

• HDD = 18G для поддержки работы БД+ .

• 9G для поддержки работы самой системы и ПО.

Система обеспечивает возможность работы 24 часа в сутки, позволяет осуществить временные остановки работы по команде пользователя после завершения текущих операций и возобновлять работу по команде пользователя без потери информации.

Система устойчива к возможным сбоям операционной системы и неправильным действиям оператора. При перезапуске система способна возобновить работу с места, на котором операции были прерваны, без потери информации.

В целях облегчения мониторинга и удаленного администрирования система имеет в своем составе специальный интерфейс, который отвечает за автоматическое информирование администратора о текущем состоянии системы и о возникновении каких-либо критических ситуаций. Для этих целей используется протокол SNMP.

Особенностью системы является также наличие специальной внутренней подсистемы протоколирования результатов работы всех процессов. Такая подсистема протоколирования позволяет значительно улучшить контроль за работой системы в целом. Администратор и пользователи системы получают удобный интерфейс для диагностики нештатных ситуаций на всех этапах работы.

Кроме перечисленного система ТАРА, в отличие от существующих подсистем ИБС, отвечающих за поддержку роуминговых операций, поддерживает также и выставление счетов-фактур партнерам по роумингу.

Пользователи могут взаимодействовать с системой, используя экранный графический интерфейс, В системе роуминга ТАРА используется единое приложение, как для ввода и модификации информации о партнерах по роумингу, так и для обработки файлов. При этом, наличие собственной базы данных в системе позволяет освободить часть ресурсов сервера биллинговой системы (любой) от необходимости хранить на нем информацию, связанную с роумингом. Эти ресурсы можно выделить для решения более актуальных задач.

8.8. Clearing houses

Расчеты путем прямого обмена ТАР-файлами — это наиболее очевидный способ взаиморасчетов, но когда число операторов начинает исчисляться сотнями такой способ может оказаться неработоспособным. По оценкам Ассоциации GSM уже сейчас количество роуминговых вызовов достигает 750 млн. в месяц при ежегодном приросте на 40%. Еще на заре развертывания сетей GSM было предложено создать для этой цели специальные органы — клиринговые центры, которые позволили бы проводить взаиморасчеты централизовано. Подобные организации и были созданы, но в мире существует лишь очень небольшое количество международных центров клиринга; к которым можно отнести компании MAHH в Люксембурге, EDS в Германии, Etisalat в Объединенных Арабских Эмиратах, Swiss Clearline в Швейцарии, Dan Net А/S в Дании и GTE в Соединенных Штатах (роль последнего не совсем идентична роли европейских центров) [8.3, 8.4].

При двусторонних расчетах каждый оператор должен заплатить своему партнеру причитающуюся сумму в валюте той страны, под юрисдикцией которой этот партнер находится. Для операторов с большим числом клиентов это может вылиться в серьезную проблему, поскольку для расчетов придется покупать значительные суммы валюты соответствующего государства. Учитывая, что сегодня сети GSM существуют и в самых экзотических местах, с покупкой валюты могут возникнуть трудности. Очевидность выгоды от использования услуг клиринговых центров для операторов заключается в том, что клиринговый центр производит взаимозачеты, в результате которых вместо сотен счетов должны быть оплачены единицы и проблема с перечислением валюты значительно упрощается.

Помимо финансовых расчетов, клиринговые центры предлагают большое количество услуг по валидации как отсылаемых, так и получаемых файлов. Операторы, при этом, могут посылать файлы как с учетом услуг с добавочной стоимостью, так и без нее. Клиринговые центры, как правило, проверяют правильность применения тарифов (имея в своем распоряжении копии тарифных планов операторов), налогов, наличие в файлах дублирующих записей, а также — старых записей, которые однажды уже были включены в файлы. Кроме того, эти центры предлагают также операторам услуги аутсорсинга. Так, если оператор не в состоянии конвертировать записи, генерируемые модулем тарификации его собственной биллинговой системы в TAP-файл надлежащего формата, он может послать «сырые» данные в клиринговый центр с тем, чтобы TAP-файл был сгенерирован там. Аналогичная операция делается и в обратную сторону. Несмотря на удобства такой организации обмена, есть операторы, которые предпочитают строить отношения друг с другом на двухсторонней основе. Это — Vodafone в Англии, China Telecom в Китае, Panafon в Греции и Telefonica в Испании.

Еще одна проблема связана со скоростью обработки информации, пересылаемой между партнерами. Многие операторы не в состоянии выдерживать сроки ее доставки при международном роуминге. Уже сейчас существуют проблемы в отношении получения сведений о вызовах абонента в роуминге если не в реальном, то хотя бы в квазиреальном масштабе времени. В некоторых случаях ответа на соответствующий запрос приходится ждать месяцами. Такие задержки могут оказаться пагубными для операторов, поскольку во многих случаях локальное законодательство позволяет не оплачивать счета, если они не были получены клиентом в течении месяца или другого, не слишком большого срока. Операторы платят друг другу все больше за разговоры своих абонентов, но заплаченные деньги возвращаются назад медленно. В данном случае, технология, поддерживающая межоператорские расчеты отстает от того, что в принципе предусмотрено межоператорскими соглашениями.

Например, по условиям стандарта GIBER (Cellular Intercarrier Billing Exchange Roamer Record) необходимо, чтобы оператор, обслуживающий абонента обрабатывал учетные записи и передавал их в клиринговые центры не позднее 30 суток с момента совершения вызова, в противном случае записи бракуются, отсылаются обратно, и оператор теряет доход. Однако, проблемы, которые могут возникать на коммутаторах, их модернизация, продолжают приводить к задержкам, которые и могут достигать двух-трех месяцев. Считается, что процедура TAP имеет определенное преимущество перед GIBER, поскольку в последнем лишь сейчас производится модернизация для поддержки функций SMS и IP.

Одним из возможных путей решения проблемы считается более широкое использование Prepaid'а, поскольку сама логика работы этой схемы обслуживания заставляет учитывать все начисления в реальном масштабе времени.

Считается, что новые биллинговые системы (или модернизированные существующие) как раз и должны будут работать в реальном масштабе времени и реагировать на каждое событие в сети. Мало того, что это не просто само по себе, грядущая передача мобильных данных вносит дополнительную сложность или дополнительное «измерение» в процедуры взаиморасчетов между операторами. Если в традиционной телефонии расчет идет между двумя сторонами, то здесь возникает еще и третья сторона — поставщик контента. Оператор не может контролировать все визиты абонента на сайты каких-либо компаний, поэтому возникает предложение трактовать участие третьей стороны как виртуальный роуминг и распространить на него все действующие механизмы.

С 1 апреля 2001 года в формате TAPА введено понятие «Rejects and Returns» и возможность работать с т.н. RAP-файлами (Return Account Procedure). Ошибочные записи при использовании процедуры Rejects and Returns автоматически исключаются из файла и отсылаются назад; отправитель должен подтвердить получение при помощи т. н. «АСК-файла». Такой подход позволяет значительно уменьшить «скрытое» время и снизить количество ошибок. В перспективе предполагается переход от применения надбавок (mark-up) к анализу поведения клиента в роуминге и соответствующей адаптации тарифных планов. Ожидается, что это вызовет сильное увеличение нагрузки на клиринговые центры, которым придется выполнять аналитическую работу. Уже сейчас Dan Net предлагает программный продукт для анализа трафика, который могут использовать операторы не имеющие такой функциональности в своих биллинговых системах.

По мере того, как операторы накапливают все больше и больше данных, все они лучше понимают, как следует производить начисления за роуминг, точнее — какие детали должны учитываться. Одна из таких деталей — качество предоставления услуг (Quality of Service, QoS). Проблема состоит в том, что при роуминге клиенты оператора должны иметь возможность получать услуги того же качества и за те же деньги, что и дома. Однако сейчас, как правило, определенный уровень качества может быть гарантирован оператором только в собственной сети. Пока что при расчетах за роуминг операторы полагаются лишь на свое понимание QoS, поскольку стандарты отсутствуют, а сами начисления за услуги GPRS крайне просты: берется абонентская плата и устанавливается порог на трафик. Иногда еще берут начисления за объем (в килобайтах) полученной информации.

Год назад мобильные аппараты, поддерживающие работу в стандарте GPRS, выпускались лишь отдельными производителями (Nokia, Ericsson, Motorola), причем никто не выпускал их в большом объеме из опасения резкого изменения стандартов. Выпускаемые телефоны имели т.н. формат 2/1 или 3/1, что означало возможность использования двух или трех каналов для загрузки информации и одного — для выгрузки. На начало 2002 выпускалось уже около двух десятков моделей, поддерживающих GPRS. Полоса, предлагаемая производителями в этих аппаратах также пока далека от обещанных 115 Kbps. Что касается обмена роуминговой информацией, то в рамках GPRS его предполагается производить, в частности, с использованием стандарта (GPRS Roaming Exchange, GRX; подробнее об этом сказано в гл. 11).

Обмен через файлы формата ТАРА в GSM, который позволяет описывать как нынешние, так и будущие услуги, является GPRS- совместимым. В соответствии с требованиями ассоциации GSM операторы обязаны поддерживать процедуру обмена в соответствии с регулярно выпускаемыми (дважды в год) релизами; т. е. должна производится своевременная настройка биллинговой системы на работу с измененными версиями формата TAPА. Ранние версии процедуры ТАР (ТАР1, TAP2, ТАР2+) были основаны на формате ASCII, тогда как TAPА имеет более сложную структуру и при преобразовании информации в ранние форматы возможна потеря информации. Ожидается, поэтому, что услуги по перекодированию возьмет на себя третья сторона (Clearing House). Если ранние версии форматов ТАР можно было читать и редактировать при помощи стандартных текстовых редакторов, то TAPА кодируется в формате ASN.1, что требует применения специальных редакторов, а это затрудняет генерацию ТАР-файлов, не содержащих ошибок. В этой связи Clearing House Dan Net предлагает услугу outsourcing'а, называемую TFG (ТАР FILES GENERATION).

Более одного миллиарда мобильных абонентов пользуются сейчас в мире услугами роуминга; из них около 60% являются обладателями телефонов стандарта GSM. Даже США, где до сих пор доминируют сети ТОМА и СОМА, готовятся к более широком внедрению данного стандарта. Для абонентов это будет означать более дешевые мобильные аппараты и возможность международного роуминга. Для международных операторов, однако, GSM может означать проблемы, вызванные усложнением обслуживания роуминга и проблемы биллинга. Существуют также и нерешенные проблемы, касающиеся выпуска GPRS телефонов, обеспечения роуминга между операторами, работающими в разных стандартах (например, между стандартами GSM и IS-41 в Северной Америке; компания предлагает комплекс программ Global Roam, который позволяет производить обмен биллинговой и роуминговой информацией), вопросы, связанные с Revenue assurance и с качеством предоставляемых услуг (QoS).

До последнего времени роуминг строился на двусторонней основе, и роль клиринговых центров сводилась, в основном, к упрощению расчетов между операторами. Однако сравнительно недавно появилась концепция т. н. «роумингового брокера». В рамках Ассоциации GSM по инициативе компании МАСН был организован [8.5] Roamer Broker Forum, в рамках которого обсуждаются концепции развития компаний, выполняющих посреднические миссии между операторами мобильной связи. На упомянутом форуме было принято следующее определение роумингового брокера: «Роуминговым брокером является организация, позволяющая абонентам мобильных операторов совершать роуминг в одну или более сетей мобильной связи в том случае, когда прямые двусторонние роуминговые соглашения отсутствуют. Роуминг в этом случае возможен за счет соглашений, которые каждый из операторов заключает с роуминговым брокером». Предполагается, что при многостороннем роуминге обмен служебной информацией между сетями, заключение соглашений и процедуры расчетов будут упрощены и, скорее всего, свидетелями именно такой тенденции развития роуминга мы станем в ближайшее время.

ЛИТЕРАТУРА К ГЛАВЕ 8

8.1. Евдокименко Е. Кому платить — вот в чем вопрос. // Сети, 1999, № 4.

8.2. Зимин К., Шагурина Н. Проблемы развития телекоммуникационной отрасли в России. // Сетевой журнал. 2001, № 3.

8.3. Swartz S. Roaming Won' t Соте Easy in the Global Village. // Billing World, 2001, N 2, р. 30 — 34.

8.4. Charming I. Paying the bills. // Mobile Communication International. 2000, Nov., р. 80 — 82.

8.5. МАСС — а Roaming Broker? // The МАСС connection. 2000, vol. 4, Issue 1, March, // www.mach.com.