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

Что называют предбиллингом. Основные функции предбиллинга

Разнородность и фрагментарность учетной информации, безусловно, представляют проблему для бизнеса операторов связи и для их расчетов с клиентами. Проблема заключается в том, что, хотя понятия NSS, OSS и BSS стали практически стандартными, до сих пор не создан и с большой вероятностью не будет создан универсальный формат обмена информацией о потреблении услуг между сетевым оборудованием в NSS, отвечающим за их предоставление, и биллинговыми системами в OSS/BSS, контролирующими начисления и расчеты. Причин тому несколько. Одна из них заключается в том, что аппаратно-программные решения, реализованные в сетевых устройствах, весьма многообразны, и ориентированы они на собственные системы микрокоманд (для каждого производителя свои). К тому же в сетях одновременно могут эксплуатироваться новые и старые устройства, интерфейсы с которыми строятся по-разному. Даже один и тот же производитель может выпускать оборудование одного и того же назначения с различными интерфейсами. Так, например, версии коммутаторов Siemens и Ericsson для сетей сотовой связи могут генерировать учетные записи в формате ASN.1, чего не могут их аналоги для сетей фиксированной связи.

Тем не менее, попытка сформулировать общие требования к формату и содержанию CDR сделана - их можно найти в рекомендациях ITU (ITU-T Q.825). Кроме того, в рамках концепции TMN в документе ITU-T M3400 (Series M: TMN and network) описаны также и базовые функции сбора, обработки и выдачи данных об использовании сети.

Однако история "происхождения видов" в телекоммуникациях, безбрежная номенклатура оборудования и соответствующее разнообразие настроек и способов обработки информации приводят к тому, что общие требования не всегда соблюдаются. Прежде всего, у "аутсайдеров" рынка. Несмотря на шаги к унификации учетной информации, создание в сетях устройств для предоставления новых услуг приводит к появлению записей все новых форматов, не вписывающихся в уже разработанные рекомендации ITU. И это хождение по кругу будет продолжаться, поскольку в целом приоритеты NSS ориентированы на обеспечение связи как таковой и отличаются от приоритетов BSS -передача вспомогательной информации (CDR, в частности) из NSS в BSS и тем более поддержка единых форматов в их число не входят. Для BSS, в свою очередь, приоритетно понятие услуги, являющееся не только техническим, но и маркетинговым. Оно плохо формализуется и вряд ли может быть поставлено в заранее заданные рамки форматов и протоколов.

Все это приводит к тому, что между сетью и биллинговыми системами появляется промежуточный слой, получивший название Mediation Devices (MD), в задачу которого входит "стыковка" выполняемых биллинговыми системами функций с процессами, происходящими в телекоммуникационной сети. В почти уже классической схеме обслуживания, работающей под вывеской postpaid, где применимы понятия "после", а стало быть, и "до", используется еще один термин, употребляемый в некоторой степени как синоним - предбиллиг (в англ. яз. -prebilling) [1].

Как правило, в такой схеме под предбиллингом понимают операции, связанные с форматированием и преобразованием исходных данных об услугах, предоставленных телекоммуникацион-ной сетью в универсальную форму, приемлемую для последующей обработки в различных информационных комплексах (биллинговые системы, системы защиты от fraud, CRM-системы, системы анализа данных и пр.). Здесь к задачам предбиллинга обычно относят также и накопление, валидацию, модификацию, сопоставление (корреляцию) и агрегацию данных [2].

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

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

Типовая схема обработки учетной информации

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

Рис.1. Postpaid-цепочка операций при обработке учетной информации

Термин postpaid в противоположность термину prepaid мы рассматриваем как кредитную схему расчетов, так и схему, основанную на авансовых платежах.

Прежде всего, задача заключается в том, чтобы зафиксировать информацию о произошедшем событии. Соответствующие данные включают в себя записи о самих соединениях и сведения о том, как и когда они получены. Данные могут, например, аккумулироваться в оперативной памяти коммутатора и по мере занятости ее объема переноситься в накопитель. Таковым может быть жесткий диск или магнитная лента. Как правило, выполнение этой задачи берет на себя производитель телекоммуникационного оборудования, и первичный сбор информации происходит в сетевых устройствах (коммутаторах, маршрутизаторах, узлах IN), На практике подобную информацию стараются накапливать в виде файлов. Если в сетевом устройстве не поддерживается файловая операционная система, может появиться дополнительный элемент (иногда его называют host collector), получающий данные непосредственно из ОЗУ коммутатора, с блоков ленты или диска и преобразующий их в файлы. Для станций РВХ, в частности, распространено взаимодействие через последовательный порт с внешним компьютером, накапливающим CDR, а для IP-телефонии типична ситуация, при которой маршрутизатор взаимодействует с RADIUS-сервером, а тот сохраняет данные об имевших место соединениях в текстовый файл. Далее сформированные файлы через определенные интервалы времени поступают на обработку в MD (отметим, что некоторые RADIUS-серверы могут записывать учетную информацию непосредственно в базы данных за счет работы драйверов ODBC).

Mediation Device (MD)

Перед тем как обратиться к описанию работы MD, отметим, что данная область в силу своей особенности является пограничной территорией между производителями телекоммуникационного оборудования, а также биллинговых систем и независимыми производителями MD, на которой все три стороны пробуют свои силы. В числе первых стоит упомянуть компанию Ericsson, которая ранее выпускала биллинговый шлюз Ericsson Billing Gateway, а ныне предлагает систему Multi Mediation, поддерживающую сбор данных обо всех современных услугах связи. Ко второй группе относятся компании Intec Telecom Systems и "Петер-Сервис", включающие MD для работы с широким спектром сетевых устройств в состав своих биллинговых продуктов. В качестве третьей стороны выступает компания Hewlett-Packard, предлагающая такой известный mediation-продукт, как Internet Usage Manager (IUM), входящий в семейство программных продуктов Open View.

На рис. 2 показано положение MD в технологической последовательности обработки информации для кредитной схемы и указаны основные действия, выполняемые на предварительной стадии. Отметим, что далеко не все, что поступает на вход MD из сети, содержит полезные с точки зрения биллинга сведения. Во входных данных имеется много служебной информации, попадаются и CDR, которые потом не могут быть корректно обработаны, дублирующие записи. Все это после соответствующей валидации должно быть отфильтровано. Объем входных данных может сократиться при этом во много раз. С другой стороны, каждое достойное биллинга событие - это деньги оператора, пусть пока и виртуальные, и важно эти события не пропустить.

Рис.2. Положение MD в технологической последовательности CDR (кредитная схема)

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

Так, например, для IT-персонала будет ясно, как обрабатывать информацию о мультимедийном сообщении, переданном напрямую между мобиль-ными станциями, при условии если обе они поддерживают прием и передачу MMS. Однако сообщение может быть послано и абоненту, мобильная станция которого принимать MMS не в состоянии, но позволяет через WAP получить доступ к URL, через который, в свою очередь, можно получить доступ и к посланному сообщению. Если MD не настроен таким образом, чтобы правильно интерпретировать и такой сценарий, соответствующие данные могут быть отвергнуты на этом уровне как служебные, и деньги за сообщение получить будет уже невозможно. Ряд экспертов считает, что масштабы такой проблемы гораздо значительнее, чем принято думать [3].

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

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

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

Похожая проблема возникает и при генерации учетной информации об использовании GPRS в сетях GSM. В данном случае вызов от базовой станции направляется не на коммутатор, а в узлы SGSN или GGSN (работа которых, впрочем, напоминает работу коммутатора), соединяющие мобильную станцию с сетями пакетной передачи данных. Узел SGSN присваивает каждой сессии уникальный номер (ID), используемый в дальнейшем при начислениях. CDR считываются с упомянутых узлов при помощи процедуры, называемой Charging Gateway Function (CGF), при этом в GPRS генерируются пять типов CDR, используемых для расчетов с абонентами:

• S-CDR, содержащие информацию, относящуюся к работе мобильной станции;
• G-CDR, содержащие информацию, относящуюся к использованию услуги в удаленной сети;
• M-CDR содержит информацию, относящуюся к мобильности и положению абонента;
• короткие сообщения (SMS), передаваемые через каналы GPRS, порождают еще два типа записей, относящихся к входящим и исходящим сообщениям.

Существенное отличие этих учетных записей от CDR, образуемых в сетях с коммутацией каналов, состоит в том, что S-CDR и G-CDR содержат блоки информации об объеме трафика, переданного при определенных ценовых условиях (traffic data volumes, TVD). Условия (тарифные ставки) могут изменяться, при изменении качества предоставленной услуги или, например, при начале нового тарификационного периода. Узлы GSN записывают соответствующие данные в одно из TVD-полей CDR, независимо от того завершено соединение или нет. Эти поля могут непрерывно обновляться в течение, например дня, или же S-CDR и G-CDR могут быть "закрыты" и переданы для обработки, в то время как начнут генерироваться новые учетные записи.

Все эти необходимые для тарификации данные собираются при помощи упомянутой выше функции CGF, которая и осуществляет задачи MD для сетей GPRS. Функция CGF может выполняться как централизованно, так и распределенно. Возможны и комбинированные решения - распределенное выполнение на узлах GSN основных операций, к которым относятся сбор, сохранение и преобразование CDR, и централизованное выполнение расширенных операций [4].

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

В цепочке операций, о которой мы говорили выше, были обозначены начало и конец. Для классической схемы postpaid эта цепочка относительно проста и состоит из понятных этапов. Отметим, что в ней операции обработки CDR в MD и тарификация являются смежными; взаимодействие этих модулей между собой и другими компонентами биллинга во многом определяют его информационную структуру. Особенности терминологии мы обсудим позже, заметив на данном этапе, что в ряде публикаций - особенно в американской периодике - эти операции зачастую объединяются под общим понятием prebilling [5] или рге-billing употребляется просто как синоним тарификации.

Трансформация MD. Реализация предбиллинга

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

Сейчас наметились тенденции, меняющие привычное распределение ролей. В проводной связи все заметнее становятся VoIP, IP-VPN, работа служб IP Centrex, сюда же можно отнести игры, рассылку сообщений и другие услуги с добавленной стоимостью. Еще сильнее новые тенденции заметны в мобильной связи, где появились такие услуги, как мобильный офис, загрузка экранных заставок, мелодий звонка, LBS. Эти услуги не вписываются в парадигму тарификации "расстояние - время" и при расчете их стоимости используются совсем другие наборы данных, нежели предоставляемые коммутаторами по завершении вызова. Кроме того, все чаще предлагаются различные услуги посредством передачи пакетов, что делает необходимым не просто рассчитывать стоимость услуги, а определять ее именно в контексте пакета, и это сильно отличается от старой доброй обработки CDR, где одновременно требовалось определять только какой-то один тип услуги.

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

Абоненты же все больше предпочитают получать быстрый доступ к текущей информации о состоянии их баланса. Это означает, что до, во время и после предоставления услуги сеть и устройства OSS/BSS должны оперативно провести необходимые расчеты и предоставить абоненту требуемую информацию. В первую очередь это относится к тарификации в реальном времени и услугам на основе prepaid-модели. Латентность при обработке учетной информации становится все более и более критичной для операторов.

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

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

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

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

2. Модуль тарификации отделяется от биллинговой системы, образуя промежуточный слой в OSS/BSS. При таком решении модуль тарификации как бы завершает технологическую цепочку обработки учетной записи и вместе с модулем предбиллинга образует своего рода самостоятельную систему, которая интегрируется с "оставшейся" частью биллинговой системы. Последняя же практически превращается в CRM-систему. В своем предельном воплощении такой подход приводит к созданию единого программного пакета (устройства, модуля), выполняющего сразу и предобработку и тарификацию учетных записей.

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

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

Растущая популярность предоплаченных сервисов и конвергентных технологий предоставления услуг и названные выше тенденции в целом заставляют производителей говорить о разделении MD на две категории: активные MD и апостериорные (post-event) MD и в соответствии с этим рассматривать различные концепции их применения. Подробнее эти концепции будут рассмотрены во второй части настоящей публикации в одном из следующих выпусков журнала.

Список литературы:

1. С. Терешкин Mediation в телекоммуникациях или что такое предбиллинг.//IT news.- № 1. - 2004.

2. И. Миронова Предбиллинг как требование рынка//ИнформКурьер-Связь.- № 3.- 2004.

3. Lucas, Matthew. Where should rating be implemented // Billing World. 2004. № 10.

4. Ekerton L., Hedstr?m P-M. GPRS support nodes // Ericsson Review. 2000. № 3. Р. 156--169.

5. Schwartz, S. Prepaid's Untapped Potential// Billing World. 2003. № 7

6. В. Лезин. Практичная мода.//Сети.- № 2.- 2004.