Немного о биллинговых системах для провайдеров

Биллинг — английское слово «bill» переводится на русский как счёт, квитанция. Billing — это процесс выписывания счёта (отсюда, кстати и Billing Address на всяких ибеях и амазонах). Применительно к телекоммуникациям, это выставление счёта абоненту за пользование услугами. А вся та когорта бабушек из бухгалтерии, которая считает ваши мегабайты — Биллинговая система. По-русски это называется Автоматизированная Система Расчётов АСР или ещё иначе ИБС — Информационная Биллинговая Система.

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

Расплатились с фрилансером через Яндекс-деньги? У вас со счёта они списались, у фрилансера появились, в историю платежей информация добавилась. Это всё биллинговая система. Пришёл вам счёт за трёхчасовой звонок в Израиль — тоже его заслуга.

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

Небольшая локальная сеть организации

Начнём, пожалуй, с крохотных SOHO (Small Office/Home Office).

У небольших компаний тоже часто стоит вопрос подсчёта трафика: кто, куда и сколько. Чтобы бухгалтеры не пересиживали на фишках, чтобы инженеры не перекачивали торренты, чтобы директор не смотрел пор… Впрочем, что директор? — ему всё можно. Скорее всего, сейчас такого не осталось, но в мою бытность младшим помощником старшего инженера по контролю пинга до базовых станций, нам выделяли по 200 мегабайтов на месяц, а всё, что свыше мы оплачивали сами по 50 коп/МБайт.

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

В общем, всё это сети, где в качестве шлюза или, по крайней мере NAT-сервера, выступает Unix-компьютер с iptables и, возможно, прокси-сервером.

Здесь правят бал бесплатные микробиллинговые системы: WinRoute Spy, Squid2mysql, StarGazer Billing System, ipq_traffic. Есть и представители платных, конечно, вроде, Lingate, например.

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

Сети крупных предприятий или небольшие провайдеры

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

Как правило, в качестве сетевого оборудования для маршрутизации трафика здесь используются полноценные аппаратные маршрутизаторы (Cisco/Huawei/HP/Juniper итд) либо, гораздо реже, высокопроизводительные сервера.

Требования к АСР здесь уже несравнимо выше.

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

Во-вторых, АСР в таких сетях — это очень важное для бизнеса приложение (busines-critical по-буржуйски). Соответственно за его статусом нужно следить неусыпно. То есть это регулярные бэкапы, актуальные обновления. И уже маячит на горизонет вопрос аппаратного резервирования.

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

В один прекрасный пятничный вечер на почту ТП начали сыпаться непонятные сообщения. Ну кому хочется тревожить по пустяками уставших инженеров в священный вечер пятницы?

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

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

В-третьих, АСР должна хранить в БД всех клиентов с их атрибутами (счёт, реквзиты, адрес, комментарии, баланс, тариф, квоты), обеспечивать работу сразу нескольких операторов, иметь пользовательский интерфейс для клиентов.

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

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

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

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

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

Обычно данные третьего уровня (деление на эти уровни весьма условно) хранятся не в БД как таковой, а в виде файлов на носителе, потому что имеют очень большой объём — отсюда ещё вытекает и вопрос с дисковым пространством.

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

В случае аппаратных маршрутизаторов для сбора данных используется специальный протокол, такой, например, как NetFlow у Сisco или NetStream у Huawei. Суть его в том, что через определённые промежутки времени будут отправляться данные о трафике на указанный в настройках хост. А можно и то же самое зеркалирование.

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

Не вдаваясь в детали, зеркалирование — это полное клонирование всех данных, проходящих через порт. То есть если у вас аплинк к провайдеру нагружен на 85 Мбит, то те же самые 85 Мбит пойдут ещё и на биллинг сервер.

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

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

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

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

Обычно, помимо биллинга используется ещё специальный анализатор, который позволяет более гибко работать с трафиком, рисовать красивые картинки и создавать годные отчёты. Для Cisco, например, есть Netflow Analyzer.

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

Надо быть внимательным при такой схеме работы. Если путь трафика изменится, то, вероятно, вы подарите своим абонентам пару десятков гигабайт трафика). В моей практике была ситуация, когда резко просела статистика по трафику абонентов. Несколько дней попыток найти в чём проблема, общения с техподдержкой производителя АРС, обновлением, чистка логов на сервере. Несколько тестов. Я вынес тогда мозг всем — и ТП биллинговой системы, и старшим коллегам, и начальнику. Спрашивал даже просто у знакомых. Никто ничего сказать не мог.

Тогда я стал спрашивать у коллег, что они делали в тот день (удалось установить именно тот день, когда просела статистика по некоторым абонентам). И когда я уже было отчаялся, вдруг всплывает, что в тот день они подключали по BGP нового провайдера. Часть трафика ушла на него, через, конечно же, другой интерфейс, который они не догадались настроить для передачи данных netflow. Две команды, и проблема, которая висела почти 2 недели, решилась.

Следует отметить, что к тому моменту уже все были на взводе, ибо биллинг — это бизнес критикал. И если вдруг кто-то придёт с проверкой (у нас же сертифицированная АРС), нам зададут резонный вопрос: «Почему статистика не соответствует действительности?» — и накажут.

Самые яркие представители АРС данного класса: АСР Ideco, UTM NetUp, Bill-Master, Traffic Inspector итд.

Все они платные и все они сертифицированные. Но если с последним вопрос не стоит, то, возможно, вам будут интересны следующие варианты: Tmeter, NetProfile, Katrin, NeTAMS.

Монстры

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

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

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

Здесь остро встают вопросы межоператорского взаимодействия, роуминга, когда АСР должна уметь интерпретировать данные не только из своей сети, от своих устройств, но и предоставленные третьей стороной, со всеми параметрами и полями, которые важны всем втянутым операторам. ITU (Международный Союз Электросвязи) разработал универсальные стандарты, которых должны придерживаться разработчики систем биллинга.

Основные требования к комплексам такого уровня:

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

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

Резервирование, высокая устойчивость к сбоям. АСР работают на базе кластеров или в режиме Hot/Backup, когда резервный сервер подхватывает все сервисы в случае падения активного. Все данные находятся в хранилищах в RAID.

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

Решения в виде пропуска всего трафика через сервер или netflow тут никак не годятся. Это же десятки, а то и сотни гигабит. Нет, друзья, тут другой подход.

Есть такое понятие как CDR. Расшифровывается это как Call Detail Record.

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

Ну а она в свою очередь на основе этих данных формирует счета.

Это принцип работы в первом приближении.

Несмотря на название сейчас этот термин используется в более широком смысле. CDR сейчас генерируются не только АТС, SGSN и прочим оборудованием голосовой связи, но и устройствами пакетной передачи: GGSN, DPI, маршрутизаторы и прочее.

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

В такой ситуации и SGSN, и GGSN, и DPI могут генерировать CDR, выкладывать их в определённый каталог в хранилище, а биллинговая система будет их забирать и выкатывать счета на основе тарифов (дополнительные данные также содержатся в CDR). То есть в данном случае это будет информация не о времени и направлении звонка, а об объёме трафика и запрошенных ресурсах.

Один из минусов CDR — невозможность через них управлять оборудованием — блокировать, снижать скорость. Для этого существуют системы OCS (Online Charging Service), которые имеют обратную связь с оборудованием, но это тема совсем другой статьи.

Схема сети с системой OCS (*картинка из официальной документации Huawei)

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

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

http://telekomza.ru