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

Задачи

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

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

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

Схема системы

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

Рис. 1. Структура биллинговой системы ISP

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

Коллекторы

Услуги могут быть разными (например - VPN-доступ, dial-up пул, обычный неинкапсулированный трафик, Proxy, VoIP, etc), надо обеспечить доставку ядру системы в единообразном виде информации о том, какой тип услуги, какой абонент, в каком объеме, и в какое время потребил. В худшем случае для каждого из типов услуг придется разрабатывать свой коллектор, но если повезет - что-то удастся унифицировать. Технологии, которые могут помочь при создании коллекторов - SNMP, Radius, NetFlow.

Многоуровневая база данных

Многоуровневая БД нужна для того, чтобы не работать все время с массивами максимально детальной информации, т.к. это значительно может снизить быстродействие всей системы. Логично выделить 3 уровня: 1. максимально детализированная информация без какой-либо обработки 2. классифицированная и первично агрегированная информация 3. оперативная информация База первого уровня может понадобиться для разрешения спорных моментов с клиентами. Важно сохранять ее в исходном виде, т.к. возможно будет необходимо постфактум произвести перерасчет выставленных к оплате счетов с учетом скорректированных тарифов или, например, уточненных границ сетей, по которым делится трафик. Не для каждого сервиса можно получить детализированную информацию о соединениях, но к этому надо стремиться. По крайней мере, при подсчете трафика через Web Proxy это решается автоматически, использование NetFlows тоже позволяет делать полную детализацию. Минусом является значительный объем, требующийся для хранения всех этих данных. Однако, т.к. эта информация нужна не очень часто, ее более логично хранить в виде обычных файлов, а не в базе - это уменьшит нагрузку на ваш сервер БД и является более компактным способом хранения. База второго уровня компактнее, чем первая, поэтому ее можно хранить за более продолжительный период времени. Например, после классификации трафика можно не хранить информацию о локальном трафике, если за него не взимается плата. Также с большой долей вероятности можно считать одним соединением несколько соединений с одним и тем же хостом, произошедшие в приблизительно одно время (типичная ситуация с многопоточными сетевыми клиентами). Оперативная информация - наиболее грубая по отношению к остальным двум базам, но зато операции с ней можно совершать очень быстро, что позволяет сократить время реакции системы, которое будет обсуждаться ниже. На основе этой базы осуществляется принятие решений о предоставлении или прекращении предоставления услуг конкретному клиенту.

Учет перспективы

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

Погрешность расчетов

Как показывает практика, учет трафика может работать с ненулевой погрешностью, а при больших объемах потребления даже доли процента - это уже значительные деньги. Чтобы застраховаться от подобных неприятных особенностей, можно учитывать это в тарифах, хотя это уже не технический вопрос. Помимо всего прочего, есть еще паразитный трафик. Ничего с ним поделать нельзя, нужно просто помнить о нем, если у вас много реальных IP-адресов. Если вы перепродаете трафик, не забудьте при расчетах о том, что ваш головной ISP может под мегабайтом понимать вовсе не 1048576 байт, а, например, 1000000, что в результате дает почти 5% расхождения. Дополнительные проблемы могут составлять направления - некоторые головные провайдеры выставляют счета за входящий трафик, некоторые - за исходящий, а в ряде случаев учитывается превышающее направление.

Время реакции системы

Принятие решения о блокировке абонента при окончании средств на его счету на практике происходит не мгновенно, этот факт тоже надо учитывать. Например, если блокировка срабатывает раз в минуту – при скорости соединения 1 Мбит/с абонент может скачать лишних 7,5 мегабайт в худшем случае.

Устойчивость к сбоям

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

Актуальность данных

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

Статистические отчеты

Помимо классического уже веб-интерфейса к статистической информации о потребленных услугах и состоянии счета неплохо предоставлять клиентам услугу рассылки наиболее важной для него информации на e-mail или посредством SMS.

Отключение абонентов

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

Тарифы

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

Бухгалтерия

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

Лицензирование

Если у вас 100% легальный бизнес, необходимо использовать только сертифицированные в Министерстве связи РФ решения. Проблема в том, что иногда они не доступны по цене, выбор их не богат, да и зачастую эти решения далеки от идеала. В целом, вопрос с наличием лицензии на биллинг каждый решает для себя сам. Разберем теперь конкретные варианты технической реализации такой системы. Например - биллинг для небольшой локальной сети, продающей трафик. Один из часто используемых способов простого учета трафика - использование счетчиков iptables на пограничном маршрутизаторе. Плюсы такого решения - простота и гибкость, возможность разграничения типов трафика на уровне правил пакетного фильтра. Минусы - придется весь трафик, который вы хотите учитывать, маршрутизировать через один PC, что, в общем-то, не сильно критично при небольшой загрузке. В качестве коллектора в таком случае может выступать небольшой PERL-скрипт, анализирующий вывод iptables. При этом рекомендую использовать флаг -Z, который обнуляет счетчики iptables после вывода их значений – так вы избежите потенциально возможного переполнения счетчиков, регистрируя лишь разницу между измерениями.

Рис. 2. Структура цепочек правил iptables

Модуль разграничения доступа, по сути, является простым скриптом, модифицирующий набор правил файрвола, что в результате открывает или закрывает доступ определенному клиенту. В случае использования VPN (например, для продажи трафика это одно из наиболее оптимальных решений, т.к. в сетях, построенных на дешевых хабах без возможности Port Security, идентификация пользователя по IP является крайне ненадежным решением) вполне логично интегрировать модуль авторизации клиентов в скрипты /etc/ppp/ip-up и /etc/ppp/ip-down, которые вызываются демоном pppd при подъеме и опускании ppp интерфейса (а зачастую VPN-соединения представляют собой по сути, соединения, использующие PPP как транспорт для инкапсулированного трафика). Аналогичным образом можно организовать авторизацию для dial-up соединений. Завершает основную часть системы небольшой демон (или просто программа, с определенной периодичностью вызываемая средствами crond), который анализирует оперативную информацию и на ее основе принимает решения об отключении абонентов, если у них на счету закончились средства (в таком случае просто соответствующее правило файрвола меняется на запрещающее). По сути, этот компонент и заключает в себя основную часть бизнес-логики, т.к. именно он ответственен за финансовые расчеты. Модуль административного интерфейса и веб-статистики являются достаточно тривиальными задачами, и их вряд ли стоит подробно рассматривать. Единственное, на чем хочется акцентировать внимание - это то, что эти модули должны быть разработаны с максимальным учетом бизнес-спефики, которая обсуждалась выше.

Биллинговые системы в условиях эволюции мобильных сетей

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

Расширение функциональных возможностей биллинговых систем

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

Сети следующего поколения, такие как UMTS , CDMA 2000 или даже так называемые переходные стандарты EDGE и CDMA 450 подразумевают создание и предоставление большого количества разнообразных сервисов в дополнение к голосовым, что непременно приведёт к изменению структуры сетевого трафика.

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

• потоковое видео;
• видеоконференция;
• видеопочта;
• on-line покупки;
• сервисы, основанные на местоположении;
• on - line банкинг, биржевая торговля, спортивные репортажи и т.д.

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

Пакетно-коммутируемые сети изменят требования к составным элементам биллинга, поскольку:

1. пользователи получат доступ к контенту через визуальный пользовательский интерфейс, а также будут способны получать/отправлять текст, картинки и видео;

2. статус абонентов будет всегда on - line (это означает, что ценовые модели, основанные на времени соединения, применяемые в сетях GSM , не подходят для GPRS). Отсюда появится необходимость тарификации в зависимости от:

• контента;
• объёма информации;
• качества сервиса (QoS);
• местоположения и т.д.

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

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

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

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

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

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

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

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

С запуском сетей третьего поколения станет возможным предоставление неголосовых услуг в роуминге. В этой связи от биллинговой системы потребуется ещё одна способность - умение работать со стандартом TAP 3. Этот стандарт поддерживает обработку данных в таких последователях GSM, как HSCSD (High Speed Circuit Switched Data), GPRS, а вскоре и UMTS . Поэтому разработчиками предусмотрено, что TAP 3 будет эффективен для биллинга между GSM оператором и сервис-провайдером, поскольку поддерживает любые VAS , в том числе и контент.

Например, процедура открытия роуминга GPRS аналогична процедуре открытия GSM роуминга и хорошо знакома операторам. К стандартной схеме при роуминге GPRS добавится трафик данных, но при этом сигнальный, речевой и трафик данных будут передаваться по различным маршрутам.

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

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

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

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