Lan биллинг что это

Обновлено: 06.07.2024

Агенты знамо дело должны быть инфу и дальше что-то агрегировать и сливать инфу. Но не тут-то было! Агенты еще между делом занимаются изменением блокировок у клиентов. В результате когда их достаточно много СУБД просто медленно помирает. Зачем это сделано не известно. Но видимо после многочисленных тыканий в этот косяк, эту часть наконец-то вынесли из агентов. Правда меньше яростно читать из таблиц агенты знамо дело не перестали. Ну и да если вы такие думаете что агенты обращаются к ядру, а уже оно к СУБД то уверяю вас это не так. Агенты тупо лезут напрямую в базу. Еще у агентов есть такая модная фича как safe база, которая позволяет вести там статистику по клиентам. И что еще веселее эта база должна быть доступна с сервера ядра. Ядро туда ходит за статистикой. Ладно закончим с агентами перейдем к ядру.

Ядро заведует бизнес-логикой. Которая почему-то частично вынесена в СУБД в виде хранимок. Доступ ко всему этому ядру осуществляется исключительно через такой удобный и полезный механизм как SOAP. Против самого SOAP я ничего не имею, кроме того что он никак не описан в документации биллинга. Про ядро плохого можно сказать только одно. Не понятно зачем же оно собственно нужно.

База данных это песня. Еще раз повторюсь посмотрите как сделано и так не делайте. Для начала расскажу про такую гениальную в своем роде вещь как разовые и периодические услуги. Сами услуги и начисления по ним ведут ОТДЕЛЬНО от начислений по абонентской плате за телефон и интернет. Ну и осуществить начисление услуги с произвольной суммой у вас не получится. Начисления возможны только по услугам с конкретной ценой за еденицу. Это очень здорово если надо отобразить на договоре абонента начисление за подключение. Приходится заниматься ерундой и плодить из пачками на каждый чих.
Далее конечно стоит отметить что начисления абонентской платы за интернет и телефон не взирая, на то что они у вас ежемесячные, один черт заводятся на каждое число. В результате за месяц в таблице начислений у каждого абонента имеется число записей по количеству дней в месяце. Причем сами понимаете, что в большинстве случаев это будут замечательные нули.
Начисления же по трафику и по телефонии отображаются в третью таблицу под названием day и содержит агрегированную информацию о трафике и звонках за день.
Ну и да, сводной таблицы куда какие начисления проходили по договору естественно нет. Да и правда а зачем? Ведь и так все здорово. Ходи собирай информацию по трем таблицам.
Так же можно упомянуть про отличнейшее решение с привязкой разовых и периодических услуг к учетной записи. Наслаждаться всеми этими вещами можно тут.

Клиентский интерфейс. А теперь давайте поговорим про чудесное творение сомна разума. А именно про интерфейс ко всем этим чудесам. Интерфейс сей написан на такой "продвинутой" технологии как extjs. Честно говоря зачем он в нем я так и не понял. Все действия в интерфейсе построены исключительно на методах POST, что во первых не позволяет по человечески обновлять страницы и переходить назад и что еще веселее давать какие либо ссылки на договора клиентов и прочее. Далее сей веселый extjs обращается к php коду на web-сервере, который работает чудеснейшим транслятором в SOAP. Как вы понимаете это проводит к потрясающей скорости работы интерфейса, а так к потрясающе быстрой разработке интерфейса. Если интересно, посмотрите как Сетевые решения предлагают добавлять дополнительные отчеты и какие телодвижения для этого надо произвести. Все это еще больше усугубляется отсутствием какой либо эргономики у интерфейса. Я бы сильно хотел посадить того человека что делал интерфейс, на техподдержку с этим самым интерфейсом и не выпускать его оттуда пока он не попользуется этим чудом минимум месяц, а лучше год. Причем личный кабинет клиента выполнен в таком же духе. И в php-код я рекомендую не заглядывать если у вас слабое психическое здоровье.

Ну и чтобы подчеркнуть всю "технологичность" решения, я расскажу каким образом в Lanbilling предлагается учитывать услуги телефонной связи по агентской схеме. Кто не знает напомню, это когда оператор местной связи выступает агентом оператора дальней связи. И так.
1. Для такой схемы у клиента заводится два договора. Один на оператора местной связи, второй на оператора дальней связи.
2. Создается тариф услуг телефонной связи который включает в себя, стоимость всех направлений местных и дальных с указанием оператора у направления.
3. Создается учетная запись на тарифе с местной телефонией.
4. Туда заводится телефон и созданный выше тариф услуг.
5. Все.

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

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

Централизация и автономия процесса сбора данных

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

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

Базы данных – коротко о главном

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

Чтобы понять, как работает биллинг, нужно представлять его основной функционал:

От теории к практике

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

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

Сбор данных - основа успешного биллинга

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

Процессу выставления счетов предшествуют другие действия:

Приобретение и заказ продукта;
активация продукта;
подключение и доставка услуг.

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

Данные клиента (в том числе и личная информация);
Данные договора;
Данные продукта (описания и цены);
Данные заказа;
И т.п.

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

Сбор, преобразование и консолидация данных

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

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

Процесс сбора данных должен быть хорошо продуман и точно сопоставлен в соответствии с запросами:

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

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

Безопасность биллинга

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

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

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

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

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

Программа MRTG (The Multi Router Traffic Grapher) предназначена для мониторинга загрузки канала за сутки, неделю, месяц и год. Программа MRTG умеет рисовать красивые картинки в формате PNG, которые отображают состояние канала за определенный период времени. Программа предоставляет очень удобные средства для подсчета трафика: подсчет для всей сети и для отдельного узла, генерирование отчетов и диаграмм в формате HTML и многое другое.

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

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

Если вы используете операционную систему RedHat версии 7 или выше, программа MRTG, скорее всего, будет уже у вас установлена. Мы не будем скачивать исходные тексты программы, а сразу воспользуемся уже собранным пакетом rpm. Установим mrtg командой:

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

Программа MRTG состоит из трех частей:

cfgmaker – утилита для создания конфигурационного файла;
indexmaker – утилита для создания файла index.html – страницы краткого обзора, дающая вам общее представление о всех целях, которые вы контролируете. О целях мы поговорим немного позже;
mrtg – сам mrtg.

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

cfgmaker --global "WorkDir: /var/www/html/mrtg" --global "Options[_]: bits,growright" --output /var/www/html/mrtg/mrtg.cfg community@router

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

Кроме параметра WorkDir имеются также параметры HtmlDir и ImageDir. В эти каталоги будут помещены html-файлы и картинки. При определении этих параметров нужно учитывать, что параметр WorkDir имеет приоритет над параметрами HtmlDir и ImageDir и поэтому, если указан параметр WorkDir, mrtg поместит отчеты и картинки именно в этот каталог, а значения параметров HtmlDir и ImageDir будут проигнорированы.

Группа глобальных параметров Options управляет построением изображения. Параметр bits означает, что мы измеряем трафик в битах, поэтому все числа нужно умножить на 8. Второй параметр, growright, указывает направление оси времени. Позже мы рассмотрим все параметры подробнее.

Параметр output программы cfgmaker задает имя конфигурационного файла, который будет создан.

Нужно отметить, что параметры WorkDir и Options являются параметрами программы mrtg, а параметры global и output – параметрами программы cfgmaker.

Параметр community@router указывает имя сообщества SNMP-устройства. В нашем случае – это наш SNMP-маршрутизатор. Обычно используется имя сообщества public. Параметр community@router как раз и является целью, которую мы будем контролировать.

После выполнения этой команды будет сгенерирован такой файл mrtg.cfg.

Имя цели (r1) пишется в квадратных скобках. Для разных целей можно задавать разные параметры, например:

Title[r1]: Traffic Analysis for first interface

Title[r2]: Traffic Analysis for second interface

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

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

Числа 1 и 2 перед именем сообщества – это номера интерфейсов во внутренней таблице SNMP-устройства. После имени (или IP-адреса) SNMP-устройства можно указать порт SNMP. По умолчанию используется стандартный порт 161.

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

Количество принятых байт.
Количество отправленных байт.
Время работы объекта после включения.
Имя объекта.

Программу нужно записать в обратных кавычках, например:

Очень полезными параметрами являются Refresh и Interval. Первый определяет частоту обновления страниц с отчетами в браузере, а второй – предполагаемый интервал запуска программы MRTG. По умолчанию значения обоих параметров равны 300 секундам. Опции perminute и perhour позволяют измерять трафик в единицах за минуту и час соответственно. Опция noinfo подавляет вывод информации об устройстве и времени его работы. Пример:

Options[_]: bits, perminute, noinfo

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

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

Строка 1 – это входящие байты (принятые), Строка 2 – исходящие байты (отправленные), Строка 3 – время, на протяжении которого работает устройство, Строка 4 – имя цели. Где же взять эту программу? Написать самому! Не буду обременять вас лишними подробностями, которые не относятся к самой MRTG, а больше к программированию сценариев, поэтому рассмотрим готовый листинг программы count.

Листинг 1. Программа count

UPTIME=`/usr/bin/uptime | /bin/awk -F " " "< print $3 >"`

Использовать программу нужно так:

Запустив программу, вы должны увидеть примерно следующие строки:

Во второй строке программы происходит следующее: находится нужная нам запись с именем интерфейса, который мы указали в первом параметре при вызове программы ($1). Затем интерпретатор awk выводит значения первого и девятого полей, содержащие количество принятых и переданных байт.

В третьей строке программы вычисляется время uptime.

Последние две строки выводят время uptime и название интерфейса. Предположим, что у вас имеется два интерфейса: локальный eth0 и выделенная линия (ppp0), идущая к провайдеру.

Теперь узел MRTG сам является маршрутизатором и самостоятельно считает свой трафик. Файл конфигурации mrtg будет выглядеть так, как это показано в листинге 2.

Листинг 2. Файл /var/www/html/mrtg/mrtg.cfg

Target[eth0]: `/usr/bin/count eth0`

Title[eth0]: eth0 Traffic

LegendO[eth0]: eth0 Traffic :

LegendI[eth0]: eth0 Traffic :

Legend1[eth0]: eth1 Traffic in bytes

Target[ppp0]: `/usr/bin/count ppp0`

Title[ppp0]: ppp0 Leased Line

PageTop[ppp0]:ppp0 Leased Line

LegendO[ppp0]: ppp0 Traffic :

LegendI[ppp0]: ppp0 Traffic :

Legend1[ppp0]: ppp0 Traffic in bytes

5,10,15,20,25,30,35,40,45,50,55,59 * * * * root /usr/bin/mrtg /var/www/html/mrtg/mrtg.cfg

0-59/5 * * * * root /usr/bin/mrtg /var/www/html/mrtg/mrtg.cfg

После этого желательно перезапустить демон crond:

Программу mrtg можно запускать в режиме демона (не через crond). Для этого установите значение параметра RunAsDaemon, равное yes. За более подробной информацией обратитесь к документации по mrtg.

Рисунок 1. Статистика для устройства ppp0

Если вы администратор довольно большой сети уровня предприятия, возможно, более удобным решением для вас станет использование программы LAN Billing, которая разработана компанией Network Solutions.

Система LAN Billing предназначена для сбора, преобразования и выдачи информации об IP-трафике. Программа будет полезной интернет-провайдерам, которые хотят вести учет трафика их клиентов, а также директору предприятия, желающего знать, кто из его сотрудников постарался до такой степени, что счет за Интернет увеличился в 2 раза в сравнении с предыдущим месяцем. Кроме того, начальник узнает не только объем переданной и принятой сотрудником информации, а также и узлы, которые сотрудник посещал. Вполне возможно, что сотрудник занимался нужным делом, а может случиться и такое, что подчиненный выкачивал какой-нибудь фильм размером в 800 Мб, и тогда. То, что будет с этим сотрудником, нас не касается, лучше ознакомимся с основными возможностями программы:

Подсчет трафика по нескольким подсетям.
Поддержка конфигурации сетей, в которых применяется маскирование (masquerade).
Детализация данных о трафике с точностью до IP-адреса потребителя и IP-адреса удаленного ресурса, который посещал потребитель за любой промежуток времени.
Сжатие статистики для минимизации объема хранимой информации и ускорения доступа к ней со стороны управляющего клиента.
Два клиента для доступа к статистике: веб-клиент, написанный на PHP, и Windows.
Построение графиков загрузки интернет-канала за отчетный период, а также график распределения нагрузки по сетям и адресам.
Сбор статистики с NetFlow-совместимых устройств, например маршрутизаторов Cisco Systems.
Поддержка виртуальных групп (возможность присвоения группе адресов или сетей учетной записи, под полномочиями которой пользователь может просматривать статистику только о трафике своей группы адресов).
Поддержка контроля доступа для виртуальных групп, в частности прекращение обслуживания по истечении средств на счете клиента.

сетевого агента;
сервера статистики;
управляющего клиента.

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

Сетевой агент может быть двух видов:

Агент для сетевого адаптера Ethernet (для операционных систем Linux, FreeBSD, NetBSD).
Сервер для аппаратного маршрутизатора или коммутатора Cisco, поддерживающего протокол NetFlow.

Существует несколько способов интеграции системы LAN Billing в вашу сеть. Вот четыре основных способа:

Установка системы на Unix-маршрутизатор.
Установка системы на Unix-маршрутизатор, выполняющий NAT/Masquerade.
Система устанавливается в сегмент, в котором находится маршрутизатор, и информация о трафике доступна на сетевом уровне.
Система устанавливается в сегмент, доступный по IP-протоколу (UDP) для NetFlow-совместимого устройства, осуществляющего маршрутизацию.

В первом случае мы выступаем владельцами IP-сети, то есть каждому компьютеру нашей сети назначен реальный IP-адрес. Это самый простой случай.

Второй случай подразумевает под собой наличие одного реального IP-адреса. Естественно, компьютер с настоящим IP-адресом – это маршрутизатор. Все остальные компьютеры получают доступ к Интернету через шлюз с настоящим IP-адресом. Шлюз выполняет NAT (сетевое преобразование адреса), при котором компьютеры нашей сети «думают», что они по-настоящему общаются с узлами Интернета, а последним кажется, что они общаются только с нашим шлюзом. То есть шлюз перезаписывает заголовки IP-пакетов, заменяя фиктивный IP-адрес любого узла нашей сети на свой собственный (реальный адрес) и отправляет пакет в Интернет. Когда пакет приходит обратно, он опять перезаписывает IP-адрес и отправляет его определенному компьютеру нашей сети.

В третьем случае интерфейс маршрутизатора и сервера с установленной системой LAN Billing объединены концентратором.

Мне более близок первый случай, но остановимся на втором, поскольку он более близок к реалии наших дней – не у каждого предприятия есть своя собственная IP-сеть. Программа LAN Billing поставляется в виде пакета RPM, поэтому проблем с ее установкой не возникает.

В дальнейшем будем предполагать, что реальный IP-адрес сервера 193.111.111.1, и что у нас один сегмент сети с фиктивными адресами – 192.168.0.1. Директива serverextip определяет внешний адрес сервера (реальный IP-адрес). Данную директиву нужно использовать, если вы используете NAT, в противном случае, оставьте эту директиву без изменения. Значение по умолчанию – 150.150.150.150.

Директива writemode определяет, какой режим записи данных о трафике мы хотим использовать: db или file. В первом случае мы будем использовать для хранения статистики сервер MySQL, а во втором – данные будут сохраняться в файле. Второй случай нам не интересен, поскольку мы не сможем генерировать отчеты средствами системы LAN Billing, поэтому установите значение db.

Следующая группа директив определяет параметры сервера MySQL: его адрес, имя пользователя, пароль и базу данных.

Директива LogFile определяет месторасположение файла протокола работы системы. Файл, определенный в директиве LogFile будет использоваться, если вы определили режим учета file в директиве writemode.

Директива сегмент описывает наш сегмент сети. В директиве указывается адрес и маска сети. Можно использовать несколько директив – в зависимости от количества сегментов, для которых мы хотим вести учет трафика. При указании маски сети нельзя использовать битовую нотацию (192.168.0.0/24).

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

Директива minter определяет время, за которое нужно объединять статистику об однотипном трафике для последующего хранения. По умолчанию – 100 секунд.

Период записи информации о трафике можно определить с помощью директивы flush. По умолчанию – 600 секунд.

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

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

Директива device определяет интерфейс, на котором нужно считать трафик. Как правило, нужно считать трафик внешнего интерфейса. Например, если вы подключаетесь к Интернету через интерфейс ppp0 (выделенная линия), а к своей домашней сети через eth0, но вести нужно учет интерфейса ppp0.

Директива ignoremask указывает маску подсети, трафик которой мы будем игнорировать. Эта директива нужна, чтобы мы не считали локальный трафик. При учете пакетов на интерфейсе, подключенном к Интернету, нужно задать маску 255.255.255.255:

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

Директивы debug и debugfile относятся к отладке программы. Директивы headers и Disable пользователем (читайте – администратором) не используются. Директивы duser, dgroup используются для определения учетных записей пользователя и группы, под полномочиями которых выполняется сетевой агент Cisco. Директива dport определяет номер порта агента Cisco.

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

killall –HUP nfbcd

killall –HUP nfbccd

Но более корректной будет команда:

Обычно сетевой агент LAN Billing запускается автоматически, но вы можете запустить его вручную с помощью команды:

Остановить агента можно командой:

Теперь можно просмотреть результат нашей работы. Управляющий клиент системы выполнен в виде веб-интерфейса. Для доступа к статистике вы можете использовать любой браузер. В поле ввода адреса браузера введите:

Биллинг. Какие ассоциации вызывает этот термин? Может быть, есть какая-то связь с Биллом Гейтсом? Нет, к счастью он еще не «сунул свой нос» в область телекоммуникаций. Ну это так — шутка. А если быть серьезным, то давайте рассмотрим происхождение слова биллинг. Английское слово «bill» можно перевести как «счет» (другие переводы: вексель, банкнота). «Billing» переводится выражением «выписывание счета».

Что такое биллинговая система?

Системы, вычисляющие стоимость услуг связи для каждого клиента и хранящие информацию обо всех тарифах и прочих стоимостных характеристиках, которые используются телекоммуникационными операторами для выставления счетов абонентам и взаиморасчетов с другими поставщиками услуг, носят название биллинговых; цикл выполняемых ими операций именуется биллингом. Биллинговая система (БС) — это бухгалтерская система, программное обеспечение, иными словами — «софт», разработанный специально для операторов. Каких операторов? Телекоммуникационных. Т. е. речь не идет лишь об операторах сотовой связи. БС используются также операторами обычной (стационарной, проводной) связи. В малых офисах, например, можно вести биллинг телефонии (анализировать: кто звонил, когда, сколько длился разговор). IP-телефония — другая область применения БС. А интернет-провайдеры? Они тоже используют БС, например, для формирования счетов, учета трафика. Любая БС создается на основе определенной системы управления базами данных (СУБД). Большинство БС в мире создавалось на основе СУБД Oracle. Среди других СУБД можно выделить Sybase и Informix как рассчитанные на большие объемы информации. А вот названия некоторых биллинговых систем: BIS, Flagship, CBOSS, Arbor, Bill-2000-prepaid. Стоит упомянуть, что под БС может подразумеваться и аппаратное обеспечение, участвующие в организации биллинга.

Терминология

Я постараюсь рассмотреть все основные понятия и определения, относящиеся к БС. Основной упор буду делать на БС, используемые операторами сотовой связи. Но большинство определений также подходит и к БС, используемым в других сферах. Постараюсь объяснять как можно проще, чтобы большинству читателей материал был понятен. Если у Вас будет что добавить к введенным мною терминам, пишите на e-mail.

Существуют несколько названий биллинговой системы: АСР — автоматизированная система расчетов; ИБС — информационная биллинговая система.

Одним из важных качеств БС является ее гибкость, то есть способность приспосабливаться к изменившимся обстоятельствам. Гибкая система адаптирована не только к сиюминутным потребностям оператора; за счет таких качеств, как настраиваемость, модульность и открытость она позволяет решать перспективные задачи. Чем больше у системы возможностей для настроек, тем лучше. А что такое модульность? Модульный принцип построения системы — это такой принцип, при котором вся система собирается из отдельных частей (модулей), как дом собирается по кирпичикам. БС тоже состоит из таких модулей — подсистем. БС включает в себя, например, подсистему предварительной обработки данных, подсистему оперативного управления биллингом, подсистему оповещения клиентов (читайте ниже о структуре и функциях БС). Под открытостью системы подразумевается открытость исходного кода программного продукта, что позволяет оператору не зависеть от разработчика в будущем и самостоятельно обслуживать и модернизировать систему. Тесно связано с гибкостью БС и следующее качество автоматизированных систем расчета — масштабируемость.

Масштабируемость по нагрузке. При росте абонентской базы, появлении дополнительных услуг не должна появляться необходимость изменять или дорабатывать программную часть БС. Увеличение возможностей БС должно достигаться за счет модернизации аппаратной части системы. Что важно учитывать при проектировании масштабируемых систем? Необходимо использовать СУБД, рассчитанные на большие объемы данных. СУБД должна быть совместима с различными компьютерными платформами, чтобы обеспечивать поддержку многопроцессорного режима работы.

Надежность — одно из основных требований, предъявляемым к любой системе. Надежность БС определяется надежностью СУБД и технологий, используемых при разработке системы. Далеко не последнее место занимает надежность поставщика (разработчика) прикладного программного обеспечения: время его работы на рынке и, как косвенный показатель, процент присутствия разработанных им систем на телекоммуникационном рынке. Почему показатель косвенный? А разве Microsoft Windows самая лучшая и надежная операционная система?… И при этом она занимает значительную долю рынка. Однако надежность БС обеспечивается также соблюдением определенных стандартов при их разработке (об этом читайте ниже).

Мультиязычность — возможность устанавливать различные языки для представления информации.

Мультивалютность — возможность работать с любыми валютами

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

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

Оптимизация биллинга — улучшение, совершенствование оператором своей БС.

Большие БС — системы, применяемые крупными операторами.

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

Что может, что должна или за что отвечает БС?

Вы пользуетесь услугой prepaid? Вы задумывались, как так получается, что сразу после звонка можно узнать об изменении баланса на Вашем счету? Вас обслуживают по кредитной системе? Кто подсчитывает сумму, которую Вы должны заплатить за предоставленные услуги? Все это «обязанности» биллинговой системы. Вы подключены по авансовой системе? Когда-нибудь замечали «исчезновение» незначительных сумм с Вашего счета? У Вас было такое: хотите узнать остаток Вашего счета, а автоинформатор предоставляет Вам сведения вчерашней свежести? Все это «глюки» биллинговой системы.

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

Структура и функции БС

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

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

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

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

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

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

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

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

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

Подсистема предварительной обработки данных.

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

Подсистема оперативного управления биллингом.

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

Подсистема оповещения клиентов.

Перечисленное деление на функциональные подсистемы не является «строгим» для всех БС. Это лишь пример «классической» АСР.

Стандарты биллинга

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

В 1998 г. было опубликовано описание первого североамериканского биллингового стандарта CIBER, который в настоящее время поддерживается фирмой CIBERNET и ее комитетом CAC-IS. Этот комитет объединяет разработчиков биллинговых систем и телекоммуникационных операторов. Главная область применения CIBER — сотовые сети стандарта AMPS.

Европейский (по происхождению) стандарт ТАР появился в 1992 г. Он поддерживается рабочей группой TADIG. Большинство операторов Европы используют ТАР2, хотя существует и третья версия. С 1995 г. модификация ТАР2, известная как спецификация TD.27, или NAGTAP2, начала применяться и в США.

Вместо заключения

Вы достаете из кармана свой сотовый, набираете номер, жмете «вызов» и… разговор состоялся. Теперь Вам не терпится узнать остаток на Вашем счете. Если биллинг системы «горячий», Вам тут же сообщают эту сумму. «Все точно подсчитала, хорошая биллинговая система», — думаете Вы. А в это время другой абонент узнает, что он только что исчерпал лимит времени и его отключили. «Зачем мне этот «горячий» биллинг! Глупая биллинговая система!», — сетует он… Да, одновременно всем не угодить!

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

Читайте также: