Биллинговые системы в телекоммуникациях - основные тенденции развития. (обзор АСР "ГРАД-2.0")

Введение

Телекоммуникационным операторам в чем-то очень повезло с областью. Все внедряют системы учета – у оператора есть биллинг. Прошел бум CRM – у оператора есть биллинг. Скоро будет повсеместное увлечение workflow – у оператора есть биллинг. (Да, забыл еще OLAP и Web-витрины.) А разработчикам биллинга приходится все это реализовывать ;)

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

О нас - я представляю компанию Град-Софт. Мы разрабатываем ПО. В том числе и Биллинговые Системы. АСР-"Град" разрабатывается с 1998г. и предназначена для операторов связи Internet. Недавно мы выпустили новую версию АСР, соответствующую Украинскому законодательству. Также, совместно с нашими Российскими партнерами, выпущена АСР "ГРАД-Р", адаптированная к Российскому законодательству и соответствующая РД Российской Федерации и типовым ТУ на "тиражируемую комплексную АСР высшего класса". Процесс сертификации на момент написания этих тезисов находится на завершающей стадии.

Наш Web-сайт - http://www.gradsoft.kiev.ua. Там есть довольно много документации, как нашей, так и наших партнеров (NTR-Lab). Также можно заказать demo-версию.

Итак, что такое настоящяя биллинговая система оператора связи ?

Billing - производное от bill, по-русски - счет. Как видно из названия, первоначальная основная функция - выписка счетов. В телекоммуникациях, кстати, как основная принята другая функциональность, главное - снять трафик с оборудования и пересчитать его в деньги. Хорошо, а что БС должна делать сейчас?

Основные объекты представленны на следующей картинке:

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

В центре у нас биллинговая система, которая взаимодействует с оборудованием, управляет веб-интерфейсом пользователя. Некоторые из пользователей могут быть злоумышленниками (в конце - расскажем подробнее). Биллинговая система может иметь шлюзы для автоматического взаимодействия с БС партнеров (так организовывается роуминг). Также мы должны взаимодействовать с финансовой ИС предприятия (вспомним о выписке счетов). Служба поддержки (есть очень хорошее английское словосочетание - customer care) использует CRM подсистему для решения повседневних проблем клиентов, менеджементу нужны отчеты и некоторый анализ, системный администратор организовывает взаимодействия БС и аппаратуры. Юридический отдел прямо с БС не связан, но он очень важен. Почему - юридическая корректность налагает довольно сильные требования к расчетной системе БС - мы должны иметь возможность пересчитать состояние счета абонента при корректировке первичных данных в течение всего срока давности. (подробнее - чуть позже).

Кстати, что еще видно из рисунка – что тиражируемая АСР это явление в определенном роде парадоксальное. Финансовые ИС и схема подключения оборудования у каждого оператора уникальные, поэтому процесс инсталляции и внедрения БС далеко не тривиален, и часто требует написания связующего ПО.

Традиционный набор функций (сокращенный, полный см. в соответствующем РД) БС по отношению к пользователям:

Тут я бы хотел обратить внимание на формулировку "формирование лицевых счетов".

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

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

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

Итак, переходим к основным тенденциям развития

Основные тенденции развития:

Конвергенция услуг.

Усложнение тарифов.

Управление устройствами в реальном времени.

Повышение требований к объему и представлению исторической информации.

Повышение требований к надежности и масштабируемости.

Начнем с конвергенции услуг. Телекоммуникации - это один из немногих конкурентных рынков в нашей стране. Рынок становится все более динамичным, конкуренция - все более острой, постоянно вводятся новые типы услуг.

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

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

В АСР-"ГРАД" эта проблема решена следующим образом:

Таким образом, при добавлении нового сервиса мы просто добавляем в БД его метаописание и, при необходимости, пишем модули взаимодействия с устройсвами доступа, которые обычно достаточно просты. Протокол взаимодействия между драйвером устройсства и ядром БС соответстует стандарту CORBA и полностью документирован на языке IDL.

Такая схема позволяет совместить техническое разнообразие и универсальность.

К примеру, ниже приведена очень небольшая часть типовых конфигураций подкулючения сервиса типа Internet
1. Web-доступ через прокси: клиенты обращаются к прокси-серверу, часть биллинговой системы инсталлированна на сайте прокси сервера
2. Выделенные линии с подсчетом трафика с помощью SNMP. Есть 3 различных сущности:
- устройство, предоставляющее нам SNMP статистику. Определяется IP адресом.
- интерфейс выделенной линии клиента, трафик по которой мы считаем. Также определяется IP адресом.
- площадка, где размещен модуль АСР, считывающий эту статистику. Также определяется IP адресом.
3. Выделенные линии с подсчетом трафика на UNIX-маршрутизаторе. На маршрутизаторе работает модуль PCAPCollector, передающий тарифицирующую информацию в основоной модуль БС.
4. Выделенные линии с подсчетом трафика с помощью CISCO NetFlow. Все также, только вместо SNMP или PCAPCollector у нас NetFlowCollector

А так же: коммутируемые линии на основе серверов доступа, поддерживающих протокол Radius (MAX6000, CISCO, системы на основе UNIX); некоммутируемые линии на основе протокола ppoe; настройка авторизации сервиса с помощью Radius; и другие конфигурации.

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

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

Таким образом мы можем заказать Voip, интернет и хостинг, оплатить хостинг и не бояться, что наш веб-сайт отключится, если мы исчерпаем баланс переговорами.

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

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

Усложнение тарифов.

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

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

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

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

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

Еще одно важное новшество – разбиение трафика по областям маршрутизации.

Это, кстати, особенность специфична для рынка стран СНГ. Дороже всего стоит зарубежный трафик, местный трафик (UA-IX) - намного дешевле, локальный - совсем ничего.

Управление устройствами.

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

Именно БС определяет:

давать ли клиенту доступ к определенному сервису ? когда давать устройству сигнал прекращения предоставления сервиса ?

В состав АСР "Град" входит как средства интеграции авторизации и аутентификации, подключаемые к стандартным API (например pam-модуль для UNIX-совместимого системного ПО [RADIUS, ftp, sh, etc...]) так и модуль авторизации, предназначенный для использования в пользовательских скриптах.

Повышение требований к объему и представлению требуемой информации.

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

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

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

Свои требования на представление информации накладывает и необходимость интеграции с другими комплексами. В первую очередь это интеграция с ИС финансового учета и планирования и с другими БС.

Начнем с обмена данными между БС:

В телефонии был когда-то стандартизирован формат CDR (CALL DESCRIPTION RECORD) и БС могли обмениваться этими данными между собой.

В IP-сервисах дело обстоит немножко сложнее.

Существует консорциум IPDR (www.ipdr.org) цель которого - стандартизировать форматы обмена информацией между аппаратурой и различными БС. Было принято несколько версий этого стандарта, но - в стандарте IPDR просто нет информации, от которой зависят тарифы отечественных операторов. К примеру - области маршрутизации трафика. Поэтому в СНГ IPDR-совместимые системы практически не используются.

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

Ни одного реального применения этих стандартов в реальной жизни я пока не видел.

Поэтому наиболее распространенный способ связывания двух биллинговых систем - это написание связующего ПО, производящий обмен данными либо на уровне файлов, либо на уровне Web API.

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

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

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

Да, если мы уже заговорили о представлении данных – пару слов о том, как в АСР ГРАД организованы отчеты: Есть предопределенное множество отчетов, и вместе с АСР поставляется документация о том, как добавлять в стандартное меню свои отчеты и графики, редактируя соответствующие SQL-таблицы метаинформации.

Повышение требований к надежности и масштабируемости.

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

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

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

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

Масштабируемость – это способность програмной системы расти так-же быстро, как и бизнес. Архитектура АСР "Град" основанна на стандартах, в которых масштабируемоcть и надежность были заложены с начала проектирования. Мы используем СУБД Oracle (кстати, 87% биллингов используют именно ее) и четырехуровневую архитектуру удаленных взаимодействий, основанную на стандарте CORBA. Соответственно, можно использовать средства балансировки нагрузки как Oracle, так и CORBA. Существует распространенный миф, что решения на базе Oracle дорого стоят и пригодны лишь для крупного бизнеса. Это не так - минимальная конфигурация СУБД Oracle вполне конкурентноспособна в цене и поддерживает 5 соединений - следователно мы можем поддерживать до 3-х разных устройств ввода данных (типа серверов доступа или маршрутизаторов) , работающих одновременно в online режиме - не каждому большому ISP это необходимо.

Заключение

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

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