Сердцем сети провайдера принято считать биллинг. Из определения: биллинг — комплекс процессов и решений на предприятиях связи, ответственных за сбор информации об использовании телекоммуникационных услуг, их тарификацию, выставление счетов абонентам, обработку платежей. В документах Министерства связи РФ вместо понятия биллинг используется термин «автоматизированная система расчетов» — АСР. С 2003 года биллинговая система стала частью сети на законодательном уровне. Принятый федеральный закон ввел понятие биллинговых данных, которые включают следующую информацию:
- Фамилия, имя, отчество или псевдоним абонента-гражданина.
- Наименование (фирменное наименование) абонента — юридического лица, фамилия, имя, отчество руководителя и работников этого юридического лица.
- Адрес абонента или адрес установки оконечного оборудования.
- Является ли пользователь юридическим лицом.
- Абонентские номера и другие данные, позволяющие идентифицировать абонента или его оконечное оборудование.
- Дата заключения договора, подключения, перечень предоставляемых услуг с историей тарифных планов для каждой услуги.
- Баланс лицевого счета и как он пополнялся, когда и в каком размере, а также списания.
- Протоколирование доступа — какой IP-адрес был выдан клиенту и куда производился доступ; на какой номер осуществлялся вызов (для телефонии).
Разумеется, операторы связи и ранее оперировали этими данными, однако с 2003 года их наличие стало обязательным.
Понятие Bill (счет) возникло в конце XIX века благодаря системе кредитования. Если доверенный человек не платил за оказанные услуги, он получал счет. Примечательно, что первыми эту идею поддержали отели. Кульминацией по праву можно считать развитие телефонной связи, когда в счете начали указывать, за какие конкретно услуги он выставлен. Таким образом, уже тогда биллинг содержал список оказанных услуг, их стоимость и итоговую сумму для оплаты.
Расцвет биллинговых систем пришелся на 90-е годы XX века — времена Dial-up. Основной задачей АСР являлся учет времени, пока сессия клиента была активна (напомню: тарификация была почасовой). По мере наполнения клиентской базы и дальнейшего развития компании-провайдера, а также для создания конкурентных условий стали появляться так называемые ночные тарифы — сессия дешевела до 70 % от стоимости дневной. Отдельного внимания заслуживали операторы связи, которые не округляли минуты до часа. На закате эпохи Dial-up АСР могли генерировать коды для карт экспресс-оплаты и распространять их через розничную сеть.
Дальнейший этап развития биллинговых систем связан с повсеместным введением xDSL-технологий — сессии уже не тарифицировались по часам и дням, счет выставлялся за принятую и переданную информацию. Стали появляться тарифные планы, тарификация которых была разделена по времени суток и по предоплаченному трафику, а также по скорости доступа к Сети — чем выше скорость и больше «пакет мегабайт», тем дороже. Наряду с услугой доступа к сети Интернет стали появляться услуги доступа к разного рода контенту. Этот трафик не тарифицировался либо тарифицировался, но со значительными скидками (один из федеральных операторов даже запустил собственный файлообменник — тогда это было возможно на безвозмездной основе и относительно законно). Отметим, что на момент написания статьи данный этап развития остается актуальным для операторов спутникового Интернета.
Листовка компании Ростелеком. 2009 год
Следующим витком развития биллинга (актуальным на момент написания статьи) стало появление технологии FTTx. Сейчас провайдеры для предоставления услуги доступа к сети Интернет используют как коммутируемые протоколы (PPtP, PPPoE, L2TP), так и современную модель — IPoE с аутентификацией по mac, ip, опции 82 DHCP, qinq vlan тегам. Провайдер получил программный продукт, способный:
- Взаимодействовать с оборудованием BRAS для динамического управления параметрами сессий клиентов (изменение скоростных политик, ISG-сервисов, ограничение доступа).
- Взаимодействовать с инфраструктурой классической и IP-телефонией, предоставляя возможность постоплатной тарификации — тарификация по факту вызова. Модули АСР для IP-телефонии позволяют управлять маршрутизацией вызовов.
- Взаимодействовать с инфраструктурой IPTV — CAS и middleware, а также интегрироваться с ТВ- и видеосервисами.
- Организовывать программную инфраструктуру для сетей Wi-Fi.
- Создавать гибкие настройки тарифных планов и группировать услуги.
- Вести детальный учет лицевого счета пользователя с возможностью создания срезов за определенный период.
- Формировать квитанции об оказанных услугах для последующей оплаты.
- Предоставлять пользователю возможность самостоятельно контролировать и менять тарифный план, подключать услуги, а также получать детальные выписки по состоянию лицевого счета.
- Предоставлять пользователю возможность оплаты услуг с помощью платежных систем и банковскими картами.
- Вести учет заявок и наряд-заказов для технических подразделений.
- Организовывать шаблонное заполнение договоров с прикреплением к ним необходимой документации.
- Организовывать доступ к биллинговой информации для государственных служб.
Некоторые биллинговые системы оснащены избыточными функциями:
- мониторинг состояния оборудования;
- составление карты сети;
- инвентаризация активного, пассивного, находящегося в работе, в ремонте или на складе оборудования;
- интеграция с системами ЖКХ для включения счета за услуги интернет-провайдера в общий счет за услуги ЖКХ.
Техническая реализация первого биллинга представляла собой базу данных пользователей с набором скриптов, зачастую на языке Perl. Встречались реализации без скриптов — использовался view-запрос самой СУБД.
Современный биллинг — это комплекс программных средств, способный взаимодействовать с другими сервисами провайдера, если не имеет собственных реализаций, например RADIUS или DHCP. Схема включения сервера АСР в сеть провайдера одинакова. Для начинающих провайдеров сервер биллинга может быть объединен с сервером доступа — такой подход допустим, но нежелателен.
Схема включения биллинга UTM5 в сеть оператора. Телефония, Интернет, беспроводной доступ
Типовая схема построения сети IPTV на базе АСР LANBilling с использованием программно-аппаратного комплекса LBView
Рынок биллинговых систем готов предложить решения для всех типов провайдеров, от малых и средних до крупных. Отметим, что, помимо производителей брендовой продукции, есть организации, занимающиеся разработкой программного обеспечения под заказ, в том числе и биллинговых систем. Разработка АСР выполняется под конкретные задачи и представляет собой узкоспециализированное ПО с достаточно высокой стоимостью. Такие решения могут себе позволить только очень крупные операторы связи. Подобные продукты рассматриваться не будут по причине их высокой стоимости и фактического отсутствия на рынке.
Как видно из опроса на форуме nag.ru, рынок предлагает большой выбор биллинговых систем. Каждый продукт имеет свои преимущества и недостатки
Для справки: АСР оснащены демоверсиями как конечного продукта, устанавливаемого на сервер, так и демодоступом к интерфейсу администратора. Некоторые компании предоставляют такую услугу только по запросу. Для удобства пользователей упомянутые выше продукты оснащены модулями личного кабинета и модулями для интеграции с популярными платежными и эквайринговыми системами. Несмотря на схожий функционал биллинговых систем, различия, хоть и не существенные, имеются.
| UTM5 | Felix 2 | Гидра | BGBilling.ru | АСР LANBilling | Carbon Billing 5 | |
| Наличие сертификата ССС | + | + | + | + | + | + |
| Поддерживаемые ОС | Debian, CentOS, FreeBSD | Debian (собственный дистрибутив) либо Debian/Ubuntu, Red Hat/ CentOS | Debian (добавление репозитория) | Linux или Windows под управлением JDK | Debian, CentOS, FreeBSD | CentOS (собственный дистрибутив) |
| Поддерживаемые СУБД | MySQL (рекомендуется) или PostgreSQL | — | Oracle Database 11g или 12c в одной из редакций: Standard, Enterprise. | MySQL | MySQL | Firebird |
| Служебный интерфейс доступа к системе | Кроссплатформенные Java-приложения — интерфейсы администратора, дилера и кассира | Веб-интерфейс администратора | ? | Кросс-платформенное Java-приложение | Веб-интерфейс администратора | Веб-интерфейс администратора и кассира |
| Возможность доработки под нужды провайдера | + | Только модуль 1С | Не заявлена | Не заявлена | + | Не заявлена |
| Лимит лицензии | Лимиты отсутствуют | Зависит от количества абонентов | Зависит от количества абонентов | Зависит от количества абонентов, возможен безлимит | Зависит от количества абонентов | Зависит от количества абонентов |
| Возможность создания резервной копии БД | Раз в 6 часов, платный модуль | — | Облачная версия — раз в 10 минут. В коробочной версии — самостоятельно | — | Есть как возможность резервного копирования, так и построения отказоустойчивого кластера АСР | + |
Как и любой продукт, биллинговые системы имеют изъяны и технические проблемы в эксплуатации.
Первый и, возможно, главный недостаток Более вероятно, что это проблема отсутствия унифицированного решения, которого в принципе быть не может.
Второй недостаток — отсутствие самостоятельной системы резервного копирования. Разработчики возлагают эту обязанность на системных администраторов и администраторов баз данных. Стандартное решение — выгрузка дампа БД в sql-файл, оптимальное решение — репликация баз данных на отдельный сервер — в случае отказа главной БД данные берутся из ведомой.
Третий изъян — отсутствие возможности создания справочника домов: адрес подключения клиента указывается в произвольной форме, а человеческий фактор порождает ошибки в заполнении. Проблема решаема в некоторых системах, но самостоятельная доработка — дорогостоящий и долгий процесс.
Четвертый недостаток — ведение учета трафика абонента биллинговой системой в БД биллинга, как это делалось в ранних версиях UTM5. С одной стороны, такой подход позволяет индексировать трафик пользователя и, в случае следственного запроса, предоставить необходимые данные оперативнее. С другой стороны, объем базы данных будет постоянно увеличиваться. Для справки: объем создаваемого файла flow-статистики составляет около 52 Мб при полосе пропускания приблизительно равной 2200 мбит/с. Итоговый размер flow-статистики за месяц при такой же пропускной способности аплинка равен 132 Гбайт. Закон обязывает оператора связи хранить эту информацию 3 года, а по возможности и больше.
Каким будет размер БД — остается загадкой. Восстановление БД в случае краха системы из sql-файла займет продолжительное время. Хранение таких резервных копий тоже затруднительно. Следует обратить внимание, что детализация телефонных звонков также сохраняется в базе данных. Разумеется, информация о трафике конкретного абонента нужна только по запросу соответствующих органов власти, а за ее отсутствие предусмотрены различные санкции — от административных и отзыва лицензии до уголовного преследования.
Отметим, что сотрудники спецслужб не регламентируют правила предоставления данных — данные должны быть, а в особых случаях требуют обеспечить доступ средствами API, минуя сотрудников провайдера.
Строительство сети интернет-провайдера невозможно без использования сервиса биллинга и его интеграции с другими компонентами. О том, как настроить систему, чтобы получить максимальную эффективность, вы можете узнать у специалистов компании VAS Experts, разработчика и поставщика системы анализа трафика СКАТ DPI.