Биллинговая система — это программное обеспечение для компаний сотовой связи

Биллинговая система это

Доброго вам времени суток, друзья.

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

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

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

Биллинговые системы: основные понятия

Английское слово «bill» можно перевести как «счет» (другие переводы: вексель, банкнота). «Billing» переводится выражением «выписывание счета».

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

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

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

IP-телефония — другая область применения БС. А интернет-провайдеры? Они тоже используют БС, например, для формирования счетов, учета трафика. Любая БС создается на основе определенной системы управления базами данных (СУБД).

Большинство БС в мире создавалось на основе СУБД Oracle. Среди других СУБД можно выделить Sybase и Informix как рассчитанные на большие объемы информации.

А вот названия некоторых биллинговых систем: BIS, Flagship, CBOSS, Arbor, Bill-2000-prepaid. Стоит упомянуть, что под БС может подразумеваться и аппаратное обеспечение, участвующие в организации биллинга.

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

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

Постараюсь объяснять как можно проще, чтобы большинству читателей материал был понятен. Если у Вас будет что добавить к введенным мною терминам, пишите на e-mail.

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

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

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

А что такое модульность? Модульный принцип построения системы — это такой принцип, при котором вся система собирается из отдельных частей (модулей), как дом собирается по кирпичикам. БС тоже состоит из таких модулей — подсистем.

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

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

Тесно связано с гибкостью БС и следующее качество автоматизированных систем расчета — масштабируемость.

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

Внимание!Увеличение возможностей БС должно достигаться за счет модернизации аппаратной части системы.

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

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

Надежность — одно из основных требований, предъявляемым к любой системе. Надежность БС определяется надежностью СУБД и технологий, используемых при разработке системы.

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

Почему показатель косвенный? А разве Microsoft Windows самая лучшая и надежная операционная система?… И при этом она занимает значительную долю рынка.

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

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

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

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

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

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

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

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

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

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

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

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

Некоторые БС позволяют абонентам оформлять заказы на подключение и производить оплату услуг через Интернет.

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

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

Совет!Расчетной системе «известны» тарифы. Она идентифицирует вызов и выполняет необходимые расчеты, формируя тем самым счет абонента.

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

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

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

Эту функцию БС можно еще назвать защитной, так как она не позволяет пользоваться услугами сотовой связи тем, кто за них не платит.

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

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

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

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

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

Но существует и стандартный набор функций, поддерживаемых практически всеми БС. В него входят:

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

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

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

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

В состав данной подсистемы входит декодер исходной информации о соединениях. Одна из сложнейших процедур этой подсистемы — поддержка роуминга.

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

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

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

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

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

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

Подсистема оповещения клиентов. Неотъемлемая часть современного биллинга — подсистема оповещения клиентов с помощью голосовых или электронных сообщений.

Информацию для рассылки уведомлений и объявлений данная подсистема берет из таблиц базы.

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

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

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

Совет!В 1998 г. американский институт стандартов ANSI утвердил стандарт ANSI 124. Дальнейшим усовершенствованием и поддержкой ANSI 124 занимается ассоциация TIA.

После этого компания CIBERNET создала рабочую группу для определения спецификаций бизнес-процессов при передаче сообщений в стандарте ANSI 124, которые получили название NSDP-B&S.

Данные спецификации устанавливают однозначное соответствие между бизнес-процессами телекоммуникационных операторов и информацией, передаваемой при обмене данными между коммутаторами по стандарту ANSI 124.

В 1998 г. было опубликовано описание первого североамериканского биллингового стандарта CIBER, который в настоящее время поддерживается фирмой CIBERNET и ее комитетом CAC-IS.

Этот комитет объединяет разработчиков биллинговых систем и телекоммуникационных операторов. Главная область применения CIBER — сотовые сети стандарта AMPS.

Европейский (по происхождению) стандарт ТАР появился в 1992 г. Он поддерживается рабочей группой TADIG.

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

Источник: http://finvopros.com/www.ixbt.com/mobile/review/billing.shtml

Биллинговая система

Биллинговая система — это программное обеспечение, разработанное специально для операторов (провайдеров).

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

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

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

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

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

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

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

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

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

Traffic Inspector – это расширяемая платформа. Документированный интерфейс автоматизации и встроенного веб-сервера с поддержкой современных технологий .NET и C# для генерации динамического контента позволяет легко расширять его возможности под различные задачи.

Источник: http://finvopros.com/www.smart-soft.ru/billing-system/

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

Биллинг — английское слово «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.

Мобильная сеть с DPI и биллинговой системой

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

То есть в данном случае это будет информация не о времени и направлении звонка, а об объёме трафика и запрошенных ресурсах.

Один из минусов CDR — невозможность через них управлять оборудованием — блокировать, снижать скорость.

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

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

Внимание!Одни хвалят коммерческие, другие не принимают ничего, кроме бесплатных, третьи не смогут дышать, если сами не напишут свою биллинговую систему.

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

Источник: https://telekomza.ru/2013/04/07/nemnogo-o-billingovyx-sistemax-dlya-provajderov/

Как работает биллинг?

Биллинг — автоматизированная система учёта предоставленных услуг, их тарификации и выставления счетов для оплаты.

В телекоммуникации биллинг официально именуется «Автоматизированная Система Расчётов» (АСР).

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

Если на счете 0 рублей, то ничего не списывается, счет в «минус» не уходит, интернет не включается. Для включения надо пополнить счет.

Если на счете сумма меньше выбранного тарифа (например: на счете 5 рублей, а услуга стоит 9 рублей в сутки) эта сумма остается у вас на счету.

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

Если на счете сумма больше выбранного тарифа (например: на счете 50 рублей, а услуга стоит 30 рублей в сутки) то сумма тарифа (30 рублей) спишется в полночь, интернет будет работать.

Пример: Вы положили на счет 50 рублей в 23:00 часа. У вас стоит тариф 512. При включении услуги у вас сразу спишется 9 рублей, за предоставление услуги за текущие сутки.

Далее в 00:00 часов спишется еще 9 рублей за следующие сутки. Таким образом, уже в 01:00 у вас на счете будет 32 рубля.

Чтобы избежать этих моментов: Пополняйте счет раз в месяц, умножив количество суток в месяце на тариф. Пополняйте счет сразу после 00:00 часов или рано утром.

Система не делает перерасчет по часам. ПОМНИТЕ! При включении VPN система сразу списывает деньги за текущие сутки!

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

Источник: http://finvopros.com/vneha.ru/chavo/kak-rabotaet-billing/

Принципы разработки биллинговой системы

Биллинговая система — программный комплекс, осуществляющий учет объема потребляемых абонентами услуг, расчет и списание денежных средств в соответствии с тарифами компании.

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

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

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

Итак, постараемся подумать над тем, как создать биллинг на базе Linux и open source ПО.

Задачи

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

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

Кстати, не стоит путать аутентификацию и авторизацию — это разные понятия.

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

Авторизация — процесс принятия решения о правомерности доступа пользователя к какому-то конкретному ресурсу (например, к файлу на диске или к определенной услуге связи).

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

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

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

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

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

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

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

В худшем случае для каждого из типов услуг прийдется разрабатывать свой коллектор, но если повезет — что-то удастся унифицировать. Технологии, которые могут помочь при создании коллекторов — SNMP, Radius, NetFlow.

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

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

Логично выделить 3 уровня:

1. максимально детализированная информация без какой-либо обработки
2. классифицированная и первично агрегированная информация
3. оперативная информация

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

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

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

По крайней мере, при подсчете трафика через Web Proxy это решается автоматически, использование NetFlows тоже позволяет делать полную детализацию. Минусом является значительный объем, требующийся для хранения всех этих данных.

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

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

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

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

На основе этой базы осуществляется принятие решений о предоставлении или прекращении предоставления услуг конкретному клиенту.

Технические характеристики

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

Основные технические требования, диктуемые бизнесом: гибкость, точность расчетов, устойчивость к сбоям.

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

Задумайтесь над тем, какие с какими услугами ваш биллинг должен будет уметь работать, при этом планируйте на будущее.

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

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

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

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

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

Совет!Помимо всего прочего, есть еще паразитный трафик. Ничего с ним поделать нельзя, нужно просто помнить о нем, если у вас много реальных IP-адресов.

Если вы перепродаете трафик, не забудьте при расчетах о том, что ваш головной ISP может под мегабайтом понимать вовсе не 1048576 байт, а, например, 1000000, что в результате дает почти 5% расхождения.

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

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

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

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

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

Биллинг считает деньги, поэтому нужно быть предельно аккуратным.

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

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

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

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

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

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

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

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

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

Экономические характеристики

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

Тарифы

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

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

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

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

Бухгалтерия

Полезно подумать об интеграции вашего биллинга в общую бухгалтерию вашей организации, например — с 1С или еще чем-то, что у вас используется для этих целей.

Важно!При планировании структуры базы данных учтите тот факт, что у одного абонента может быть несколько разных счетов (на разные услуги), и он по идее должен иметь возможность либо объединять, либо изолировать их.

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

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

Если у вас 100% легальный бизнес, необходимо использовать только сертифицированные в Министерстве связи РФ решения.

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

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

Практический пример

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

Один из часто используемых способов простого учета трафика — использование счетчиков iptables на пограничном маршрутизаторе.

Совет!Плюсы такого решения — простота и гибкость, возможность разграничения типов трафика на уровне правил пакетного фильтра.

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

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

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

Структура цепочек правил iptables

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

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

Аналогичным образом можно организовать авторизацию для dial-up соединений.

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

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

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

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

Источник: http://finvopros.com/citforum.ck.ua/operating_systems/linux/billing/