UTM 5
Наиболее распространенной и популярной российской биллинг-системой можно назвать разработанную ЗАО «NetUP» автоматизированную систему расчетов «UTM 5». Данный программный продукт позиционируется на рынке как универсальная система, способная предоставлять услуги доступа в Интернет и телефонии в сетях практически любого масштаба — от небольших офисов до крупных Интернет-провайдеров [5].
NetUP UTM является полноценным решением для организации автоматического расчёта операторов связи с абонентами за предоставляемые услуги. Базовый модуль системы поддерживает обсчёт выделенных линий. Помимо этого, система позволяет создавать и вести учёт как периодических, так и разовых услуг. При использовании дополнительных модулей система может обсчитывать услуги IP-телефонии, коммутируемого доступа с учётом стоимости времени и беспроводного доступа к сети (хотспот).
Система полностью поддерживает работу с предоплаченными картами. Есть возможность экспорта сгенерированных карт во внешний файл формата XML
При необходимости система может блокировать доступ клиента к услугам, например, при исчерпании средств на лицевом счёте.
Пользовательский интерфейс системы построен на основе веб-технологий, что позволяет клиенту получать доступ к своему счёту, выпискам и статистике из любой точки мира с помощью любого браузера через Internet. Использование технологии XML и шаблонов при создании клиентского интерфейса позволяет администратору системы самостоятельно менять внешний вид интерфейса без ущерба его функциональности.
Использование в системе такого понятия, как «класс трафика» позволяет вести учёт трафика из разных сетей, например, разделение трафика на отечественный и зарубежный, пиринговый и локальный. Разделение классов трафика можно производить по самым различным признакам: сети источника и получателя, порты источника и получателя, тип службы (TOS), протокол, автономные системы источника и получателя TOS), протокол, автономные системы источника и получателя, интерфейс маршрутизатора, через который проходит пакет и многое другое.
Как видно из рисунка 4 биллинговая система UTM представляет собой комплекс приложений, составляющий три группы: ядро системы, интерфейс администратора и интерфейс пользователя [6].
 Рисунок 4 – схема работы системы NetUP
Ядро системы — основная программа, запускаемая на сервере и отвечающая за функционирование биллинга в целом. Интерфейс администратора представляет собой java-приложение, устанавливаемое на рабочую станцию администратора и позволяющее настраивать систему и управлять ею. Вид интерфейса администратора представлен на рисунке 5. Это приложение является платформенно-независимым и может исполняться под управлением любой ОС: Windows, Linux, FreeBSD. Интерфейс пользователя — это набор программ, работающих совместно с веб-сервером и реализующих виртуальный кабинет пользователя системы.
Ядро биллинговой системы NetUP UTM – это основной модуль, отвечающий за работу с базой данных, обеспечение доступа к ней и обработку входящей информации согласно внутренним правилам (таких как тарификация, периодические списания). Ядро – это отдельный многопоточный процесс, работающий в пользовательском режиме. При запуске ядро, как правило, работает в режиме администраторских привилегий. Структура ядра такова, что оно органично вписывается в многопроцессорные архитектуры и при высоких нагрузках равномерно использует все предоставленные ресурсы.
Рисунок 5 – Интерфейс администратора NetUP
Обработчик запросов URFA (UTM Remote Function Access) является сервером вызовов удалённых процедур. Он принимает соединения от клиентов системы и осуществляет выполнение запрошенных команд внутри ядра. Эта компонента служит в большей степени для организации пользовательских и администраторских интерфейсов. URFA – это модуль доступа к ядру системы из внешних приложений. Он проводит авторизацию пользователей по схеме CHAP и обеспечивает работу удалённого пользователя. Протокол поддерживает передачу данных и вызов функций. URFA проверяет, разрешён ли данному пользователю доступ к вызываемой функции и, если разрешён, пользователю позволяется начать обмен данными. В противном случае система дает отказ в доступе.
Каждой сессии выделяется 128-битный случайный идентификатор (SID), повторение которого исключается. Этот SID может быть использован повторно для открытия доступа. В случае сбоя при восстановлении сессии SID будет удален, и пользователь вновь будет вынужден ввести логин и пароль. SID привязывается к IP-адресу клиента и автоматически удаляется после некоторого времени простоя. Восстановление сессии возможно лишь в случае, когда получен доступ с правами системного пользователя. При открытии сессии создается таблица разрешенных вызовов, состоящая из списка символов, имевшихся на момент генерации в системе, и прав доступа к ним. Если после открытия сессии будет подгружен дополнительный модуль, то эти вызовы будут в числе запрещённых для пользователя. В таком случае, пользователю необходимо подключиться заново. В случае если в момент выгрузки модуля, кто-то работает с ним, операция выгрузки завершится неудачей. Однако все символы этого модуля будут помечены как удаленные и в дальнейшем все вызовы к ним не будут успешными. В тот момент, когда последняя ссылка на символы будет удалена (сессия закрыта), модуль можно окончательно выгрузить. Постоянные модули выгружать нельзя, при попытке их выгрузить будет возвращена ошибка и на работе модуля это никак не скажется. В случае сбоя при проверке лицензий модуль не будет подгружен. Лицензии привязываются к двоичному коду модуля, что гарантирует пользователю то, что загруженный модуль действительно собран в компании NetUP и полностью отвечает требованиям безопасности и корректности работы. Однако это требует, чтобы при обновлении модуля была получена обновленная лицензия.
Буфер NetFlow принимает данные о трафике в формате NetFlow версии 5. Для устройств, не поддерживающих выдачу статистики по этому протоколу, используется преобразователем статистики из любого протокола в NetFlow версии 5 – утилитой get_xyz. Классификатор трафика – модуль ядра, осуществляющий сортировку всего трафика на категории (классы трафика) по признакам, обозначенным в настройках системы. Признаки классификации задаются в центре управления UTM. Модуль бизнес-логики отвечает за тарификацию всех услуг, в том числе и передачу IP-трафика. Он осуществляет перевод количества оказанных оператором услуг в денежный эквивалент, принимая во внимание все зависимости, указанные администратором системы. Системный журнал сообщений ведёт все записи о функционировании UTM. Он позволяет администраторам проводить диагностику системы и получать информацию о сбоях в работе системы. Модуль доступа к базам данных представляет собой унифицированный интерфейс БД и осуществляет перевод внутрисистемных запросов к данным в запросы к внешней базе данных. Это позволяет добиться независимости UTM от какой-либо конкретной системы управления БД. Прием данных происходит посредством буфера NetFlow и URFA. Исходные данные считываются из базы данных при запуске. NetFlow данные поступают на обработку в бизнес-модуль, где рассчитываются все необходимые списания. В случае высокой пиковой загрузки NetFlow поток может быть буферизован, что несколько снизит возможные потери. «Сырые» данные NetFlow сохраняются посредством объектно-ориентированной базы данных GigaBase. При старте модуль этой БД создаётся в отдельной нити и, по возможности, с высоким приоритетом. URFA поддерживает динамическую загрузку модулей (liburfa). Они могут быть как выгружаемыми, так и постоянными. Последние – это модули, содержащие критичные для управления системой вызовы или выгрузка которых может привести к сбоям. Первые - это, обычно, просто библиотеки вызовов.
Модуль коммутируемых соединений представляет собой сервер NetUP RADIUS и предназначен для обработки запросов на авторизацию и учёт потребленных услуг. Сервер NetUP RADIUS представляет собой приложение, которое в реальном времени обрабатывает поступающие к нему запросы по протоколу Remote Authentication Dial In User Service (RADIUS). При обработке запросов сервер NetUP RADIUS обращается к ядру системы по протоколу URFA.
Протокол RADIUS предназначен для обеспечения авторизации, аутентификации и аккаунтинга между сервером доступа и сервером авторизации. Протоколу RADIUS официально присвоен порт UDP 1812. Данный протокол был разработан для облегчения управления большим количеством модемных пулов. Например, когда в сети имеются несколько устройств, к которым должны иметь доступ пользователи, и на каждом устройстве содержится информация обо всех пользователях, то администрирование такой системы значительно усложняется, превращаясь в головную боль администратора. Проблема может быть решена установкой одного центрального сервера авторизации, а все сетевые устройства производили бы запросы к нему по стандартному протоколу RADIUS. При этом в качестве серверов доступа могут выступать устройства любых производителей, поддерживающие протокол RADIUS. RADIUS сервер поддерживает несколько протоколов аутентификации, наиболее частоп применяющиеся из них это протоколы PAP и CHAP [7].
PAP (Password Authentication Protocol) – простейший протокол аутентификации. Он не предусматривает использования шифрования паролей. При аутентификации по этому методу сервер доступа заполняет атрибуты «Имя пользователя» (User-Name) и «Пароль пользователя» (User-Password) и отсылает запрос серверу RADIUS. Протокол PAP крайне ненадежен, поскольку пересылаемые пароли можно легко читать в пакетах PPP (Point-to-Point Protocol), которыми обмениваются стороны в ходе проверки подлинности. Обычно PAP используется только при подключении к старым серверам удаленного доступа на базе UNIX, которые не поддерживают никакие другие протоколы проверки подлинности [1].
CHAP (Challenge Handshake Authentication Protocol) – более сложный и защищённый протокол. Он использует зашифрованные пароли. При аутентификации по этому протоколу сервер доступа генерирует случайное 16-байтное значение (CHAP challenge) и отсылает его на компьютер пользователя. После этого компьютер пользователя отсылает обратно в незашифрованном виде логин пользователя, и зашифрованное значение (hash), полученное из строки вызова, идентификатора сеанса и пароля пользователя с применением алгоритма MD5. После получения данных аутентификации сервер RADIUS проводит их проверку и, если они корректны, то отсылает обратно пакет «Доступ разрешен» (Access-Accept). В противном случае посылается пакет «В доступе отказано» (Access-Reject). В пакете «Доступ разрешен» (Access-Accept) также в поле атрибутов могут передаваться параметры для установки сеанса, например, IP-адрес пользователя (Framed-IP-Address), тип протокола (Framed-Protocol), максимальное количество времени, отведённое на сессию (Session-Timeout). Сервер доступа, получив пакет «Доступ разрешен» (Access-Accept), устанавливает соединение с пользователем. Если данный пакет не получен либо получен пакет «В доступе отказано» (Access-Reject), то соединение разрывается. После успешного установления соединения сервер доступа отсылает на сервер RADIUS пакет «Запрос на учёт» (Accounting-Request), в котором содержится информация о начале предоставления услуги и параметрах сеанса: порт на который подключился пользователь (NAS-Port), идентификатор сессии (AcctSession-Id). Это так называемая стартовая запись. При окончании сеанса отсылается пакет со стоп-записью. В этом пакете содержится информация об окончании предоставления услуги. Также в этом пакете содержится информация о том, сколько времени предоставлялась услуга (Acct-Session-Time), сколько принято или передано байт в ходе работы [1].
В системе пользователи делятся на две категории: конечные пользователи (клиенты, абоненты) и администраторы (системные пользователи). В зависимости от типа пользователя, у него есть некоторый список разрешённых операций. Операции с идентификатором, большим 0x80000000, разрешены на исполнение только клиентам, остальные операции – только администраторам. Разделение ролей администраторов происходит на основе системных групп, которым принадлежит администратор. Существует специальная группа с идентификатором 1 (wheel). Если системный пользователь в неё входит, то ему разрешено исполнение любых операций. Иначе права будут ограничены списком вызовов, разрешенных группам, в которых он состоит. Случаи вызова запрещённых операций заносятся в системный журнал ядра.
Если какому-либо компоненту системы необходимо записать сообщение в журнал, он обращается к модулю журналирования и передает ему уровень и текст сообщения. В системе существуют следующие уровни журналирования, список которых представлен в таблице 1.
Модуль журналирования помещает текст сообщения в зависящий от настроек модуля и уровня события поток журналирования. Поток журналирования ассоциируется с указанным в настройках модуля файлом. По умолчанию все потоки ассоциированы со стандартным потоком ошибок.
Таблица 1 - Уровни журналирования:
Номер уровня
|
Название уровня
|
Описание
|
0
|
*EMBERG
|
Системный сбой, функционирование невозможно
|
1
|
*ALERT
|
Сбои в работе, требующие немедленного рассмотрения
|
2
|
*CRIT
|
Критичные ошибки, сбои в работе
|
3
|
ERROR
|
Некритичные ошибки
|
4
|
Warn
|
Предупреждения
|
5
|
Notice
|
Информация, на которую стоит обращать внимание
|
6
|
Info
|
Информация общего характера
|
7
|
?Debug
|
Отладочная информация
|
8
|
?Trace
|
Дополнительная отладочная информация
|
9
|
-Stats
|
Статистика
|
Для различных задач и ситуаций существует несколько потоков журналирования, которые отличаются приоритетом обработки. Полный список потоков журналирования представлен в таблице 2.
Таблица 2 - Потоки журналирования
-
Название потока
|
Входящие уровни журналирования
|
Критический
|
от 0 до 2
|
Основной
|
от 0 до 3 плюс log_level
|
Отладочный
|
все
|
Некоторые компоненты могут активировать встроенный в модуль журналирования механизм ротации файлов. Если данный механизм активирован, после записи события в файл, модуль проверяет размер файла не превышение размера, указанного в конфигурации модуля. Если размер превышен, файл закрывается, к его имени добавляется суффикс. Если количество файлов ограничено, добавляется суффикс “.0”. Если количество файлов не ограничено, добавляется суффикс “.”, где - время закрытия файла в формате Unix Time Stamp. Если файл с таким суффиксом существует, его суффикс увеличивается на единицу. После переименования всех файлов, проверяется количество файлов на превышение максимального количества, и если оно превышено, старые файлы удаляются.
Подведя итог, хочется заметить, что не удивительно, что многие крупные Интернет провайдеры используют именно эту биллинговую систему. Хорошо продуманная архитектура позволяет сконфигурировать систему в соответствии с самыми притязательными требованиями заказчика и модифицировать её в процессе использования, подключая дополнительные модули. Кроссплатформенность ядра системы тоже является неоспоримым преимуществом, что позволяет не переучивать персонал заказчика при переходе с других аналогичных систем. Идея журналирования событий однозначно является полезной в большой системе, как на стадии отладки и настройки, так и при ежедневном использовании. Однако, на мой взгляд, зависимость от операционной системы пользователя – это большой недостаток данного программного продукта, так как пользователь, для получения доступа в Интернет должен запустить у себя на компьютере программу авторизатор. Это накладывает определенные трудности для пользователей операционных систем, под которые данный авторизатор просто не запускается, а также для пользователей, которым необходимо подключить несколько компьютеров к Интернет. Необходимо отметить и то, что для работы системы требуется дорогостоящее оборудование, с поддержкой таких технологий как NetFlow, которые берут на себя задачи сбора статистики и даже имеют возможность отключать пользователей, и на биллинг систему за счет этого ложится гораздо меньшая нагрузка. Последнее ограничение не является препятствием для больших операторов связи, однако для решение задачи доступа в Интернет в учебном заведении это недопустимо.
LANBilling
Система LANBilling – представляет собой программный комплекс, ориентированный на сбор статистической информации от устройств, посредством которых сервис - провайдеры обеспечивают предоставление услуг пользователям, а также последующую тарификацию предоставленных услуг. Комплекс способен обрабатывать информацию об услугах, оплата за использование которых взимается пропорционально объему услуги (Интернет доступ по выделенной линии) или времени ее использования (коммутируемый модемный доступ, телефонные переговоры), а также услугах, которые носят разовый (любые единовременные услуги) или периодический характер (услуги с абонентской платой). Комплекс предназначен для использования в сетях операторов связи, сервис - провайдеров, организаций, заинтересованных в учете, тарификации, лимитировании услуг, предоставляемых как внешним, так и внутренним потребителям [8].
Автоматизированная система расчетов LANBilling обладает следующими ключевыми возможностями:
Учет, лимитирование и тарификация услуг доступа в IP сети, предоставляемых по выделенным каналам:
учет информационных потоков в распределенной сетевой инфраструктуре (несколько каналов, сетей, серверов доступа);
сбор статистики с NetFlow совместимых устройств, маршрутизаторов Cisco Systems;
сбор статистики с SFlow совместимых устройств, например, маршрутизирующих коммутаторов HP ProCurve серий 93хх, 53хх;
сбор статистики с устройств, поддерживающих SNMP управление;
сбор статистики с Ethernet маршрутизаторов, работающих на базе UNIX;
поддержка конфигурации сетей, в которых применяется маскирование или трансляция сетевых адресов (masquerade/NAT);
регулируемая степень детализации данных, поступающих от аппаратуры.
Учет, лимитирование и тарификация услуг доступа в IP сети, предоставляемых по коммутируемым каналам:
модуль RADIUS протокола, обеспечивающий аутентификацию, а также несколько режимов тарификации (повременная или в зависимости от объема услуги) и управления доступом;
функции сервера RADIUS: мультилогин, выделение IP адресов на сессию, работа с несколькими NAS;
аутентификация VPN сессий, контроль и прерывание активных сессий.
Учет и тарификация услуг классической телефонии:
возможность работы с подключаемыми каталогами телефонных кодов;
повременная тарификация по каталогу и тарификация с фиксированной оплатой за соединение;
поддержка большинства АТС средствами встраиваемого программного кода (Plugin).
Учет и тарификация услуг телефонии, предоставляемых по технологии VoIP:
поддержка голосовой платформы CISCO 53xx через RADIUS протокол посредством CISCO VSA;
возможность работы с различными типами оборудования.
Централизованное WEB управление АСР.
Поддержка кредитной, авансовой, смешанной системы оплаты.
Тарифы с гибкими скидками: в зависимости от объема потребленного клиентом трафика, времени суток, выходного дня, а также с настраиваемыми сценариями списания абонентской платы.
Режим работы на ненадежных каналах связи и каналах с низкой пропускной способностью.
Двунаправленный обмен данными с внешними бухгалтерскими системами, такими как «1С:Бухгалтерия», «Парус» и т.п.
Аутсорсинг услуги «биллинг» провайдерам нижнего уровня – партнерам (возможность делегирования полномочий по управлению группами пользователей оператору партнеру).
Карты предоплаты за услуги связи (режим автоматического создания клиентской записи по вводу pin-кода карты).
Поддержка контроля доступа, в частности прекращение обслуживания по истечении текущего баланса.
Настраиваемые и экспортируемые в универсальные форматы отчеты.
Межоператорские расчеты.
Офф-лайн тарификация (возможность отката/наката балансов)
По представленному списку возможностей можно сказать, что текущая версия LANBilling предназначена провайдерам, операторам связи и организациям, перед которыми стоят задачи учета, контроля и тарификации широкого спектра услуг, предоставляемых клиентам, подключенным к распределенной сетевой инфраструктуре, посредством которой осуществляется предоставление услуг. LANBilling 1.8, реализует в себе понятие конвергентного биллинга, при котором списание денежных средств по различным типам услуг происходит с единого баланса.
Структурно программный комплекс состоит из трех основных компонентов: модуля сбора статистических данных с устройств, обеспечивающих предоставление услуги, который называется в терминах системы LANBilling - сетевой агент; модуля хранения и преобразования статистической информации LANBilling Server; модуля управления системой (управляющий web клиент) со стороны администратора, менеджеров и конечных пользователей системы. Интерфейс администратора изображен на рисунке 6.
Рисунок 6 – Вид интерфейса администратора системы LANBilling
Комплекс программ "LANBilling" ориентирован на применение в распределенных сетях, состоящих из множества узлов, обеспечивающих предоставление услуг абонентам. Узлы могут представлять собой устройства разного типа: от маршрутизаторов IP-трафика, до абстрактного счетчика услуги, имеющей единицу измерения. Услуги разного типа учитываются, контролируются и тарифицируются различными сетевыми агентами. Сетевых агентов может быть несколько. Каждый из них физически может находиться на разных устройствах и получать данные от сетевых компонентов разного типа. Программное обеспечение LANBilling способно обеспечивать учет и контроль услуг, тарификация которых осуществляется в зависимости от объема использованной услуги («объемные» услуги) или времени использования услуги («временные» услуги). А так же разовые и периодические услуги. В случае разовой услуги плата за ее использование взимается единовременно. В случае периодической услуги плата за ее использование взимается регулярно с задаваемым периодом.
АСР LANBilling имеет в своем составе сетевые агенты, обеспечивающие учет, контроль и тарификацию услуг каждого из типов, перечисленных выше.
«Объемные» услуги в контексте применения АСР - это, как правило, предоставление доступа к ресурсам IP-сети по выделенному каналу связи. Для работы с данным типом услуг предназначены следующие сетевые агенты:
Ethernet (LANBilling 1.8 E) – для работы с UNIX серверами;
NetFlow/SFlow (LANBilling 1.8 N/S) – для устройств, поддерживающих экспорт статистических данных посредством протоколов NetFlow (Cisco Systems, Huawei) или SFlow (Hewlett Packard);
SNMP (LANBilling 1.8 M) – для устройств, совместимых с стандартом сетевого управления SNMP;
RADIUS (LANBilling 1.8 R) – для работы с серверами доступа, обеспечивающими экспорт статистических данных о количественных характеристиках использования канала связи по протоколу RADIUS (RADIUS агент используется в данном случае в режиме тарификации по объему услуги).
Агент для Ethernet интерфейсов - программный модуль, осуществляющий учет и тарификацию услуг доступа в сеть Internet (IP услуг), предоставляемых абонентам по выделенному каналу, средствами программно-аппаратного маршрутизатора архитектуры x86. Применяется преимущественно для работы с сетевыми адаптерами Unix маршрутизаторов (Linux и FreeBSD). Агент этого типа получает статистические данные непосредственно от Ethernet интерфейса маршрутизатора, функционируя уровне драйвера сетевого адаптера. Основной задачей агента является регистрация, тарификация и первый уровень агрегирования данных об IP трафике, прошедшем через интерфейс.
Помимо функций регистрации данных, агрегирования и тарификации, агент для Ethernet интерфейсов может осуществлять контроль доступа абонентов в IP сеть. В частности возможно прекращение обслуживания абонентов по истечению балансных средств на расчетном счете абонента. Функции включения/отключения доступа реализованы внешними процедурами, управляемыми системой контроля доступа Ethernet агента для обеспечения максимальной гибкости при интеграции агента с существующими системами управления доступом.
Ethernet агент способен работать в режиме SAFE, когда канал между сервером и агентом ненадежен, или обладает недостаточной пропускной способностью. В этом случае регистрация и хранение первичных данных осуществляется на локальном сервере (доступа) на котором установлен агент. Такой подход минимизирует объем передаваемых данных между сервером и агентом, и позволяет осуществить перехват управления доступом абонентов в сеть в случае отсутствия связи с центральным хранилищем, обеспечивая блокировку и разблокировку абонентов по локальным данным известным на момент пропадания связи с центральной БД. При восстановлении связи происходит автоматическая репликация баз данных агента и сервера.
Агент для протокола NetFlow - программный модуль, осуществляющий учет и тарификацию услуг доступа в сеть Internet (IP услуг), предоставляемых абонентам по выделенному каналу, средствами аппаратуры, поддерживающей экспорт статистических данных по протоколу NetFlow версии 5. Основные задачи, решаемые агентом, аналогичны задачам, решаемым агентом Ethernet типа, а именно: регистрация, тарификация и первый уровень агрегирования данных об IP трафике, прошедшем через маршрутизатор.
В отличие от Ethernet агента данный модуль получает статистические данные о прошедшем трафике в виде NetFlow потока, посылаемого маршрутизатором по протоколу UDP, что предъявляет соответствующие требования к каналу передачи данных между маршрутизатором и сервером, на котором функционирует агент NetFlow.
Основные задачи, решаемые агентом SFlow, и его принципы функционирования аналогичны задачам, решаемым агентами Ethernet и NetFlow типов.
«Временные» услуги тарифицируются в зависимости от времени использования услуги - к таковым можно отнести DialUp доступ абонентов к ресурсам IP-сети, телефонные переговоры, как классической телефонии, так и переговоров, осуществляемых по технологии VoIP, конференц-связь, услуги контакт-центров и т.п. Для работы с данным типом услуг предназначены следующие агенты:
RADIUS (LANBilling 1.8 R) - для работы с серверами доступа, обеспечивающими аутентификацию и экспорт статистических данных о временных и количественных характеристиках использования канала связи по протоколу RADIUS;
PABX (УПАТС) (LANBilling 1.8 A) – для работы с УПАТС, обеспечивающих телефонные переговоры абонентов, подключенных по выделенному каналу;
VoIP (LANBilling 1.8 I) – для учета, контроля и тарификации телефонных переговоров, обеспечиваемых при помощи технологии VoIP;
PCDR (LANBilling 1.8 P) - для учета, контроля и тарификации услуг, информация о которых экспортируется в виде «плоского» (plain) файла, содержащего CDR (Call Detail Records) записи, подготовленного внешней коммутирующей системой, например, SoftSwitch (VOIS), компании VocalData.
Агент для протокола RADIUS - программный модуль, осуществляющий учет, контроль использования и тарификацию услуг доступа в сеть Internet (IP услуг), предоставляемых абонентам по коммутируемым каналам, а также управление (аутентификацию) пользователями, работающих по выделенным каналам, доступ которых к сервису контролируется устройством совместимым с RADIUS протоколом. Агент ориентирован на учет и тарификацию услуг, предоставляемых на повременной основе (классический DialUP доступ), однако имеет возможность тарификации услуг, плата за использование которых, взимается пропорционально объему потребленной услуги (например, объем использованного IP трафика).
Работа агента для RADIUS протокола существенно отличается от функционирования агентов других типов. RADIUS агент взаимодействует с одним или несколькими NAS - серверами доступа к сети (Network Access Server), для выполнения задач учета, контроля и тарификации.
Агент RADIUS способен осуществлять тарификацию абонентского доступа в соответствии с гибкими тарифами, предоставляющими возможность определения нескольких видов скидок: временные скидки (скидка в зависимости от времени в течении которого используется услуга), объемные скидки (скидки, регламентирующие стоимость единицы услуги в случае использования тарификации по объему в зависимости от объема использованной услуги с начала учетного периода) скидки выходного дня и пр.
Периодические услуги – это услуги, предполагающие наличие абонентской платы, списываемой с расчетного счета абонента за задаваемый временной интервал – период. Услуги данного типа могут тарифицироваться как сервером системы LANBilling, так и сетевыми агентами, в зависимости от выбранного сценария списания абонентской платы.
Разовые услуги обрабатываются агентом IVOX, предназначенным для работы с данными об оказанных услугах в табличном виде любого формата, в частности, данный агент необходим для работы с контакт-центрами (contact/call center), услуги которых требуют внешней тарификации.
Управление всеми сетевыми агентами централизованно осуществляется непосредственно из единого центра управления системой. Конфигурация каждого сетевого агента хранится в основной БД и дублируется в БД сетевого агента.
Один установочный комплект программы состоит их серверной части – LANBilling Server 1.8 и, как минимум, одного сетевого агента любого типа.
Важной архитектурной особенностью версии LANBilling 1.8 является то, что абонентом в терминах АСР является объект «пользователь», которому может принадлежать одна и более "учетных записей" разного типа. Введение данного объекта является потребностью конвергентного биллинга, ориентированного на операторов мультисервисных сетей связи. Наличие нескольких учетных записей, ассоциированных с одним объектом типа "пользователь", позволяет абонентам АСР, располагая едиными атрибутами доступа, использовать сервисы различных типов от услуг доступа к IP сети до VoIP, а также иметь единый счет за все предоставленные услуги одному абоненту. В соответствии с обновленной внутренней структурой данных несколько изменился подход к разграничению доступа для менеджеров и администратора к управлению пользователями и учетными записями, которые могут быть ассоциированы как с пользователем, так и с менеджером или администратором. Этот подход позволит упростить взаимодействие с операторами-партнерами, которым оказывается услуга аутсорсинга биллинга (предоставление возможности частичного использования АСР основного оператора для тарификации абонентов партнера), а также существенно расширить возможности по управлению и отчетности.
Итак, LANBilling – очень мощная система, предоставляющая полный спектр коммуникационных услуг, которая может применяться в очень крупных кампаниях, обеспечивающих Интернет доступ, телефонию и прочие услуги связи. Система предоставляет все возможные функции, которые только может осуществлять крупная корпоративная биллинг-система, если дынный программный продукт имеет возможность подключения отдельных модулей, тем самым, конфигурируя систему под конкретные задачи, то систему можно считать отличным решением для провайдера.
BGBilling
Биллинговая система "BGBilling" создана для автоматизации деятельности операторов связи. Большой набор модулей позволяет тарифицировать широкий круг услуг, таких как:
коммутируемый доступ в Интернет;
доступ в Интернет по карточкам;
доступ в Интернет по выделенным линиям;
доступ в Интернет по VPN;
IP – телефония;
услуги классической телефонии;
услуги кабельного телевидения;
услуги цифрового кабельного телевидения;
услуги Wi-Fi доступа.
В связи с тем, что данная АСР по своим функциям похожа на рассмотренные ранее, сведем характеристики системы BGBilling в таблицу 3.
Таблица 3 – Характеристики биллинг-системы BGBilling.
Характеристика системы
|
Описание
|
Платформонезависимость.
|
Благодаря использованию технологии JAVA, программный комплекс (как клиент так и сервер) способен запускаться на любой платформе безо всякой модификации, перекомпиляции кода, смен конфигурации.
|
Клиент-серверное исполнение
|
Программа состоит из сервера, выполняющего все операции по управлению данными и графических клиентов, которые могут подключатся к серверу, вызывая его функции. Подключение может происходить через proxy-server.
|
Клиентский GUI
|
Клиент BGBilling - это полнофункциональное GUI приложение, способное к запуску на любой платформе и обеспечивающее легкое манипулирование данными в привычном Windows оконном режиме.
|
Модульность
|
Построение по модульному типу позволяет собрать оптимальную систему, гибко расширять функциональные возможности.
|
WEB - интерфейс клиента
|
Позволяет клиентам оперативно узнавать о состоянии счета, расходов и платежей через страницу WEB - статистики. Добавление клиенту услуг из различных модулей автоматически модернизирует его страничку, позволив просматривать подробные отчеты по различным услугам, изменять пароли доступа, пополнять баланс интернет-картами.
|
Гибкость и расширяемость
|
Программный комплекс поддерживает модернизацию путём подключения новых модулей
|
Продолжение таблицы 3
|
|
Характеристика системы
|
Описание
|
Встроенный планировщик
|
Для запуска регулярных задач вроде начисления абонентских плат или очистки старых таблиц.
|
Поддержка шаблонов договоров
|
Упрощенное создание новых однотипных договоров. При создании договора в нем уже будет определен тарифный план, набор услуг.
|
Гибкие и наследуемые тарифные планы
|
Позволяют изменять стоимость различных услуг в зависимости от периода, дня недели, дня месяца. Новые тарифные планы имеют древовидную структуру, способны быть наследованы и уточнены для отдельных клиентов.
|
Оперативные и клиентские E-Mail рассылки
|
Оперативные рассылки позволят вам быстро и просто оповещать ваших клиентов о произошедших изменениях. Клиентские рассылки дают клиенту возможность автоматического получения на ящик сводок о состоянии баланса, сессиях, наработках по логинам и т.д. Набор рассылок зависит от состава используемых модулей.
|
Открытость и интегрируемость
|
Открытый и простой протокол обмена Клиент - Сервер (HTTP + XML) позволяет производить простую интеграцию с внешними программами (в т.ч. с бухгалтерскими).
|
Мощная система разграничения доступа и аудита BG-SECURE
|
Позволяет быть уверенным, что пользователь системы обладает только нужными ему возможностями и отследить некорректные действия операторов по логам. Количество ролей пользователей не ограничено.
|
Встроенный язык программирования BGS
|
Предназначен для дополнительной обработки различных событий системы, автоматизации рутинных операций по работе с договорами.
|
CRM Система BG-CRM
|
Удобный учет звонков клиентов, проблем сети и задач. Контроль исполнителей и групп решения. Возможность автоматизации процессов подключения, отключения клиентов, сервисных выездов.
|
Хотя, как уже говорилось система предоставляет стандартный набор функций для данного класса биллинговых систем, однако имеет довольно интересную архитектуру, которая представлена на рисунке 7.
Рисунок 7 – Программная структура BGBilling
Можно выделить несколько основных частей биллинга:
Cерверная часть (BGBillingServer) - обрабатывает запросы клиента и Web-запросы;
Клиентская часть (BGBillingClient), показанная на рисунке 8 - визуализирует работу с сервером, AРМ оператора и администратора биллинга;
Web интерфейс пользователя (Web браузер клиента) - позволяет пользователям просматривать и модифицировать свои параметры а также получать оперативные отчеты по модулям (просмотр сессий, звонков и т.д.);
База данных MySQL - единое хранилище и связующее звено компонентов биллинговой системы.
Приложения BGBillingServer, BGScheduler, BGDataLoader используют общие библиотеки, но физически являются разными процессами.
Рисунок 8 – Внешний вид АРМ администратора
Связь клиента с сервером биллинга осуществляется через HTTP протокол, также к серверу может обращаться браузер клиента провайдера для получения доступа к странице статистики. К серверу биллинга могут одновременно обращаться большое число клиентских приложений. Более того, под видом клиента для получения данных или их модификации к серверу могут обращаться сторонние приложения (например, бухгалтерское ПО). При этом сервер биллинга также производит авторизацию и контроль прав доступа этого клиентского приложения.
Связь между всеми серверными процессами осуществляется исключительно через базу данных. Например, для передачи задания обработчику логов сервер пишет в таблицу задание, которое выбирает процесс планировщика.
Также на схеме изображено, что экземпляр модуля (отдельный пункт в меню Модули) является ни чем иным как обособленным блоком данных в БД.
Преимущества такой технологии заключаются в:
возможности удаленного управления серверной частью с помощью клиента;
одновременном доступе неограниченного количества рассредоточенных операторов к данным биллинговой системы;
автономная работа сервера не требует наличия запущенного клиентского приложения;
наличие единой точки доступа к биллингу, отсутствие базы данных на машине оператора позволяет жестко контролировать права доступа, гарантировать целостность данных биллинга.
На сайте разработчика кроме всего прочего представлены данные о производительности установленных у заказчиков систем:
Клиент: ОАО "Уфанет", г.Уфа
Сервис: PPtP доступ на базе FreeBSD MPD
Нагрузка: 82 000 абонентов, 20 000 одновременных соединений в пике, 5 миллионов сессий за месяц, записей в БД за месяц - 40 миллионов
Условия: 10 минутная тарификация, 35 серверов MPD, разделение трафиков на по NetFlow статистике.
Сервер BGRadiusDialUp: CPU Core Dual 2.6Ггц RAM 4ГБ
Сервер БД + BGBillingServer: 2 2х ядерных Xeon 2.6 ГГц, SCSI RAID*
|
Клиент: ОАО "Уфанет", г.Уфа
Сервис: Доступ с прямым IP адресом
Нагрузка: 10 000 абонентов, 40 000 диапазонов адресов, записей в БД за месяц - 8 миллионов
Условия: Сбор статистики по NetFlow, перетарификация в конце месяца - 20 минут
Сервер - коллектор + тарификатор: CPU Pentium D 3.40ГГц RAM 2ГБ
Сервер БД + BGBillingServer: 2 2х ядерных Xeon 2.6 ГГц, SCSI RAID*
|
Как показывают данные примеры, система показывает очень хорошую производительность, надежность и отказоустойчивость и может применяться для очень крупных провайдеров Интернет доступа и телефонии.
|
