Как работает биллинг сотового оператора? Биллинг телефона. Программа биллинга телефона Что такое биллинговый платеж

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Платформа обрабатывает InitialDP 37 мс; абонент слушал гудки 10 сек; длительность разговора – чуть больше 5 минут.

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

Есть 2 основных типа расчета:

  • Постоплата - выставление счёта за период по его итогам (postpaid)
  • И авансовая система (prepaid), когда деньги заносятся заранее.
Постоплата появилась исторически раньше, но предоплата оказалась удобнее для клиентов (контролируемее – чуть что не так, происходит отключение, а не выставляется большой счёт).

Постоплатная система

Когда абонент постополатной системы расчетов пользуется услугами оператора, то на коммутаторах генерятся специальные CDR (Charging Data Record) файлы. По сути, это обычные логи, в которых указан номер абонента, дата, время разговора/объем скачанного трафика и т.п. Биллинг же, в определенное время, (например, раз в сутки) подключается к коммутатору, закачивает себе CDRы, рассчитывает стоимость услуг и сохраняет всё в базе данных (обычно, Oracle). Затем в конце месяца абоненту выставляется суммарный счет.


Схема взаимодействия Postpaid платформы с ядром сети оператора.
CSN - circuit switching network; Представлена коммутаторами каналов (MSC).
PSN – packet switching network; Представлена коммутаторами пакетов и шлюзами (SGSN и GGSN соответственно).

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

Авансовая система

В случае авансовой тарификации оператору связи, помимо учета предоставленного объема услуг, требуется решать задачу отслеживания текущего счета абонента и в случае достижения нуля, информировать абонента/отключать предоставление услуги. Поэтому такие системы еще называют Online Charging System (OCS).

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


Схема взаимодействия prepaid-платформы с сетью оператора.

Разберем подробнее эти протоколы.

CAP

CAP (CAMEL Application Part) – протокол прикладного уровня стека SS7, реализующий интеллектуальные услуги в GSM/UMTS сетях (например, prepaid).


Место протокола в стеке SS7 . На рисунке также представлен популярный вариант с использованием технологии SIGTRAN (расширение SS7, которое позволяет использовать протоколы “семёрки” поверх IP сети).

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


Диалог тарификации по CAP протоколу, пунктирными линиями показаны ISUP сообщения.

  1. Сначала в биллинг от коммутатора MSC1 приходит сообщение (Initial Detection Point), в котором передаются параметры абонента. Это входящий и исходящий номера, адрес соты вызываемого абонента и прочие. На основе этого возможно начать анализ звонка. Биллинг создает у себя определенный Detection Point - то есть состояние вызова. OCS определяет, можно ли абоненту совершить голосовой вызов (есть ли средства на счете), если можно, то на какое максимальное время.
  2. После этого OCS отвечает коммутатору Request Report BCSM Event (“Detection Point я инициализировал, жду от тебя дальнейшей информации о состоянии вызова”). И посылает Apply Charging (“средства у абонента на счету есть, разрешаю звонок”). Там же пересылается максимальное время, которое может использовать абонент.
  3. Коммутатор, получив разрешение от OCS, инициализует голосовое подключение между абонентами по ISUP протоколу, посылая на MSC2 сообщение IAM (Initial Address Message).
  4. MSC2 отвечает в сторону MSC1 сообщением ACM (Address Complete Message), в данном случае это означает “да, абонент мой, он сейчас в сети, начинаю его вызывать”. Приняв это сообщение, MSC1 включает длинные гудки абоненту А.
  5. Абонент Б берет трубку, MSC2 посылает MSC1 сообщение ANM (Answer Message) – “мой абонент поднял трубку, подключай их”.
  6. MSC1 подключает абонента А и Б, начинается разговор. MSC1 посылает на OCS сообщение Event Report BCSM (O_Answer). OCS изменяет у себя состояние вызова для данного абонента. С этого момента начинается тарификация (с учётом, что первые 3 секунды бесплатны).
  7. Пока абоненты общаются, MSC1 следит за временем на звонок. Если времени остается мало, то MSC предупреждает абонента звуковым сигналом.
  8. В нашем случае первым кладет трубку абонент Б, MSC1 и MSC2 производят дружеское рукопожатие с помощью сообщений REL (Release Message) и RLC (Release Complete Message).
  9. MSC1 отправляет на OCS сообщение Event Report BCSM (O_Disconnect – “абоненты успешно отключились”) и Apply Charging Report (сколько секунд длился разговор).
  10. OCS принимает эти данные и отвечает, что теперь можно закрывать сессию.

INVOKE --- A1 TAG: A1h 1B LEN: 27 --- INVOKE ID --- 02 TAG: 02h INTEGER 01 LEN: 1 02 INVOKE ID: 2 === CAP === --- INVOKE --- --- OPERATION --- 02 TAG: 02h INTEGER 01 LEN: 1 23 OPERATION: 35 = applyCharging --- APPL CHARG --- 30 TAG: 30h SEQUENCE 13 LEN: 19 --- ACH BCC --- 80 TAG: 80h 0C LEN: 12 --- TDC --- A0 TAG: A0h 0A LEN: 10 --- MAX C P D --- 80 TAG: 80h 03 LEN: 3 01 19 40 MAX C P D: 4370

Это часть трейса. Видим, что по протоколу CAP послано сообщение applyCharging, максимальное время разговора (MAX CPD - Maximum Call Period Duration) равно 437,0 сек.

Продублирую картинку до ката: это пример общения по CAP протоколу. Можно оценить временные метки: платформа обрабатывает InitialDP 37 мс; абонент слушал гудки 10 сек; длительность разговора – чуть больше 5 минут.


А вот тут звонок продолжительный и видно, как система каждые 6 минут сама запрашивает у MSC статус звонка (activityTest). Сделано это для того, что бы, в случае какой-либо ошибки разговор не длился сутками (пока у абонента не спишутся все деньги).

CAP-протокол может тарифицировать не только голосовые звонки – он так же способен тарифицировать интернет-соединения, SMS, MMS и так далее. Хотя на практике чаще всего для этих нужд применяются специально заточенные протоколы (DIAMETER/OSA).

OSA

OSA (Open Service Access) – открытый программный интерфейс разработанный консорциумом 3GPP и ETSI, часто используется для тарификации VAS-сервисов и мобильного интернета.

Рассмотрим работу данного протокола на примере тарификации услуги мобильного интернета:

  1. При попытке активации PDP Context’а (получении телефоном IP-адреса в сети мобильного оператора) GGSN запрашивает платформу, можно ли данному абоненту активировать тарификационную сессию (CreateChargingSessionReq).
  2. В нашем случае все хорошо (абонент есть в базе, денежные средства имеются), платформа создает тарификационную сессию и разрешает активировать PDP Context (CreateChargingSessionResp).
  3. Теперь абонент хочет начать скачивать данные. Что бы позволить ему это делать, GGSN обращается к платформе с запросом на резервацию средств (ReserveUnitReq). Вообще, unit – вещь абстрактная, может быть чем угодно – килобайтом данных, смской, секундой разговора, рублем, пиццей, бочкой и так далее. В нашем случае unit – это 100 кБ.
  4. Платформа проверяет, есть ли для данного абонента, в соответствии с его тарифом, средства на 100 кБ трафика и отвечает сообщением ReserveUnitResp (“средства зарезервированы”). Приняв это сообщение от платформы, GGSN позволяет абоненту качать трафик.
  5. Когда абонент скачал зарезервированную порцию трафика, GGSN обращается к платформе с сообщением DebitUnitReq (“можно списывать зарезервированные средства”).
  6. Платформа списывает средства и отвечает сообщением DebitUnitResp (“средства успешно списаны”).
  7. Цикл ReserveUnitReq-DebitUnitResp повторяется до тех пор, пока абонент не скачает весь интернет закроет интернет сессию.
  8. При деактивации PDP Context’a GGSN посылает на платформу сообщение о завершении тарификационной сессии; память, выделенная под данную сессию освобождается.


Запрос debitUnitReq; Команды OSA обернуты в SOAP протокол, который в свою очередь инкапсулируется HTTP протоколом.

Заключение

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

Если тематика протоколов семейства AAA вам интересна, то позже я расскажу про RADIUS, DIAMETER и другие интересные вещи.

В разделе Биллинг вы можете:

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

Вход и навигация

Переход в раздел Биллинг возможен 4-мя способами:

1. После нажатия на кнопку Тариф… :


2. После выбора пункта меню [ Логин ] Биллинг :



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


При входе в раздел открывается главная страница Баланс :


Баланс счета

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

Если баланс счета приближается к нулю, Roistat отправляет письмо-уведомление на адрес электронной почты и СМС на номер телефона, указанные в вашем аккаунте.

Списания по тарифу прекращаются и функции Roistat блокируются, если значение баланса счета меньше нуля (такое возможно при использовании ) .

Вы можете переносить денежные средства между аккаунтами. Чтобы перенести средства со счета вашего аккаунта на счет другого аккаунта:

Промокод

Бонусный промокод указывается в правом верхнем углу в соответствующем поле и активируется с помощью кнопки Активировать :


Если введен корректный промокод, система запросит подтверждение операции. Для отмены операции нажмите кнопку Вернуться :


Если введен некорректный промокод, система сообщит об ошибке. Для повторного ввода промокода нажмите кнопку Вернуться :

Управление услугами

Тарифы и услуги отображаются на вкладке Баланс в блоке Детализация расходов :


Просмотр и изменение тарифа

Название тарифа и его ежедневная стоимость отображаются в строке Тариф:… .

Для просмотра условий всех тарифов нажмите на эту строку. Для каждого тарифа отображаются следующие параметры:

  • стоимость в день;
  • перечень включенных опций;
  • максимальное число посещений в месяц;
  • максимальное число проектов в месяц.

Тариф, активированный для вашего аккаунта, помечается как Текущий тариф .

Для выбора другого тарифа нажмите кнопку Выбрать .

Просмотр и выбор опций

Количество подключенных опций и их общая стоимость в день отображаются в строке Дополнительные опции .

Для просмотра всех опций нажмите на эту строку.

Те опции, которые включены в текущий тариф, помечены включено в тариф .

Остальные опции доступны для подключения с помощью кнопки подключить . Чтобы отключить данные опции нажмите кнопку отключить .

Детализация расходов за услугу Отслеживание номеров

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

При нажатии на эту строку появится дублирующая строка Абонентская плата :


Соответствующих проектов.

Детализация расходов за услугу Обратный звонок

Размер ежедневной абонентской платы отображаются в строке Обратный звонок .

При нажатии на эту строку появится дублирующая строка Абонентская плата :


Более подробная информация по данной услуге находится в разделе соответствующих проектов.

Итоговая сумма за день

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


Оплата и пополнение баланса

Оплатить услуги или внести деньги на счет можно на вкладке Баланс , нажав кнопку Пополнить баланс :


или на вкладке :


После нажатия кнопки Пополнить баланс откроется окно параметров оплаты:



Минимальная сумма платежа 5000 рублей.

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

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

Безналичный расчет

При выборе безналичного способа оплаты можно:

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


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



    скачать счет сразу же – для этого нажмите ссылку скачать счет


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

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

Оплата банковской картой через интернет

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


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

Оплата c помощью Яндекс.Деньги, Qiwi Кошелек, WebMoney

Для оплаты c помощью Яндекс.Деньги, Qiwi Кошелек, WebMoney установите переключатель в соответствующее положение и нажмите кнопку Перейти к оплате . После этого вы будете автоматически перенаправлены на страницу оплаты:



Оплата через Paypal

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


Оплата через PayOnline

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

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

История счетов

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

Созданные счета отображаются на вкладке Счета и подразделяются на 3 категории:

  • Все – все счета пользователя;
  • Неоплаченные – счета, по которым еще не было зачислений;
  • Оплаченные – счета с завершенными транзакциями.


Каждому счету соответствует одна строка в табличной части:


В таблице отображается следующая информация по счетам:

    Номер – номер счета;

    Дата создания – дата создания счета;

    Сумма – сумма к оплате;

    Статус – текущий статус проведения платежа: Новый или Оплачен ;

    Дата изменения статуса – дата последнего изменения статуса счета;

    Способ оплаты – способ оплаты счета. Возможны 4 статуса:

    • Счет не оплачен – устанавливается для неоплаченных счетов;

      Отправка счета на email – устанавливается для оплаченных счетов при безналичном способе оплаты;

      Пластиковая карта (Visa, MasterCard) – устанавливается для оплаченных счетов при оплате банковской картой через интернет;

      С помощью PayPal – устанавливается для оплаченных счетов при оплате через систему PayPal.

Неоплаченные счета можно оплатить на данной вкладке. Напротив таких счетов справа отображаются:



История платежей

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

Платежи могут быть сгруппированы по периоду:

В таблице отображается следующая информация по счетам:

    Дата – день месяца, в который была проведена хотя бы 1 платежная операция;

    Операция – тип платежной операции;

    Сумма, р . – сумма платежа в рублях;

    Остаток, р . – остаток средств на счету в рублях.

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

Настройки платежей

Для ускорения процесса оплаты и пополнения баланса вы можете:

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


Данные параметры настраиваются на вкладке Настройки платежей

Автоматическое пополнение счета

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

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

Сохранение способа оплаты

В блоке Способ оплаты выберите способ оплаты:

  • Пластиковая карта :
    1. Установите переключатель Пластиковая карта .
    2. Нажмите кнопку Выбрать .
      Вы будете направлены на страницу Яндекс Кассы, на которой требуется ввести данные карты, с которой будут списываться средства. Для сохранения данных карты будет совершен тестовый платеж 10 р.
  • Отправка счета на email .
    1. Установите переключатель Отправка счета на email .
    2. Введите адрес электронной почты. Можно указать несколько электронных адресов ([email protected] , [email protected] и т.д.)
      На введенные адреса электронной почты будут приходить счета для банковского перевода.



Чтобы изменить адрес электронной почты или данные пластиковой карты:


Изменение и удаление способа оплаты

Чтобы изменить или удалить установленный способ оплаты, нажмите на соответствующие иконки:


Ограничение по рекламному бюджету

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

Что случится, если не пополнять счет Roistat

Если долгое время не пополнять счет Roistat, то деньги на балансе закончатся.

Что случится с проектом:

Интеграции с CRM Аналитика Коллтрекинг Емейлтрекинг Ловец лидов Сплит-тестирование События Управление ставками
  1. Заявки из CRM будут собираться.
  2. Заявки из CRM будут передаваться еще 14 дней.
  3. По истечении 14 дней вы получите уведомление о том, что заявки перестали отправляться в CRM-систему.
Нельзя смотреть отчет.

Будет нельзя добавлять новые номера (как свои номера, так и номера от Roistat).

Перестанет работать Перестанет работать Перестанет работать Перестанет работать Перестанет работать

Аналитика будет собираться в проекте. Номера будут закреплены за проектом еще 7 дней.





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




Пополняйте ваш счет вовремя!

  • No labels

Платформа обрабатывает InitialDP 37 мс; абонент слушал гудки 10 сек; длительность разговора – чуть больше 5 минут.

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

Есть 2 основных типа расчета:

  • Постоплата - выставление счёта за период по его итогам (postpaid)
  • И авансовая система (prepaid), когда деньги заносятся заранее.
Постоплата появилась исторически раньше, но предоплата оказалась удобнее для клиентов (контролируемее – чуть что не так, происходит отключение, а не выставляется большой счёт).

Постоплатная система

Когда абонент постополатной системы расчетов пользуется услугами оператора, то на коммутаторах генерятся специальные CDR (Charging Data Record) файлы. По сути, это обычные логи, в которых указан номер абонента, дата, время разговора/объем скачанного трафика и т.п. Биллинг же, в определенное время, (например, раз в сутки) подключается к коммутатору, закачивает себе CDRы, рассчитывает стоимость услуг и сохраняет всё в базе данных (обычно, Oracle). Затем в конце месяца абоненту выставляется суммарный счет.


Схема взаимодействия Postpaid платформы с ядром сети оператора.
CSN - circuit switching network; Представлена коммутаторами каналов (MSC).
PSN – packet switching network; Представлена коммутаторами пакетов и шлюзами (SGSN и GGSN соответственно).

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

Авансовая система

В случае авансовой тарификации оператору связи, помимо учета предоставленного объема услуг, требуется решать задачу отслеживания текущего счета абонента и в случае достижения нуля, информировать абонента/отключать предоставление услуги. Поэтому такие системы еще называют Online Charging System (OCS).

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


Схема взаимодействия prepaid-платформы с сетью оператора.

Разберем подробнее эти протоколы.

CAP

CAP (CAMEL Application Part) – протокол прикладного уровня стека SS7, реализующий интеллектуальные услуги в GSM/UMTS сетях (например, prepaid).


Место протокола в стеке . На рисунке также представлен популярный вариант с использованием технологии SIGTRAN (расширение SS7, которое позволяет использовать протоколы “семёрки” поверх IP сети).

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


Диалог тарификации по CAP протоколу, пунктирными линиями показаны ISUP сообщения.

  1. Сначала в биллинг от коммутатора MSC1 приходит сообщение (Initial Detection Point), в котором передаются параметры абонента. Это входящий и исходящий номера, адрес соты вызываемого абонента и прочие. На основе этого возможно начать анализ звонка. Биллинг создает у себя определенный Detection Point - то есть состояние вызова. OCS определяет, можно ли абоненту совершить голосовой вызов (есть ли средства на счете), если можно, то на какое максимальное время.
  2. После этого OCS отвечает коммутатору Request Report BCSM Event (“Detection Point я инициализировал, жду от тебя дальнейшей информации о состоянии вызова”). И посылает Apply Charging (“средства у абонента на счету есть, разрешаю звонок”). Там же пересылается максимальное время, которое может использовать абонент.
  3. Коммутатор, получив разрешение от OCS, инициализует голосовое подключение между абонентами по ISUP протоколу, посылая на MSC2 сообщение IAM (Initial Address Message).
  4. MSC2 отвечает в сторону MSC1 сообщением ACM (Address Complete Message), в данном случае это означает “да, абонент мой, он сейчас в сети, начинаю его вызывать”. Приняв это сообщение, MSC1 включает длинные гудки абоненту А.
  5. Абонент Б берет трубку, MSC2 посылает MSC1 сообщение ANM (Answer Message) – “мой абонент поднял трубку, подключай их”.
  6. MSC1 подключает абонента А и Б, начинается разговор. MSC1 посылает на OCS сообщение Event Report BCSM (O_Answer). OCS изменяет у себя состояние вызова для данного абонента. С этого момента начинается тарификация (с учётом, что первые 3 секунды бесплатны).
  7. Пока абоненты общаются, MSC1 следит за временем на звонок. Если времени остается мало, то MSC предупреждает абонента звуковым сигналом.
  8. В нашем случае первым кладет трубку абонент Б, MSC1 и MSC2 производят дружеское рукопожатие с помощью сообщений REL (Release Message) и RLC (Release Complete Message).
  9. MSC1 отправляет на OCS сообщение Event Report BCSM (O_Disconnect – “абоненты успешно отключились”) и Apply Charging Report (сколько секунд длился разговор).
  10. OCS принимает эти данные и отвечает, что теперь можно закрывать сессию.

INVOKE --- A1 TAG: A1h 1B LEN: 27 --- INVOKE ID --- 02 TAG: 02h INTEGER 01 LEN: 1 02 INVOKE ID: 2 === CAP === --- INVOKE --- --- OPERATION --- 02 TAG: 02h INTEGER 01 LEN: 1 23 OPERATION: 35 = applyCharging --- APPL CHARG --- 30 TAG: 30h SEQUENCE 13 LEN: 19 --- ACH BCC --- 80 TAG: 80h 0C LEN: 12 --- TDC --- A0 TAG: A0h 0A LEN: 10 --- MAX C P D --- 80 TAG: 80h 03 LEN: 3 01 19 40 MAX C P D: 4370

Это часть трейса. Видим, что по протоколу CAP послано сообщение applyCharging, максимальное время разговора (MAX CPD - Maximum Call Period Duration) равно 437,0 сек.

Продублирую картинку до ката: это пример общения по CAP протоколу. Можно оценить временные метки: платформа обрабатывает InitialDP 37 мс; абонент слушал гудки 10 сек; длительность разговора – чуть больше 5 минут.


А вот тут звонок продолжительный и видно, как система каждые 6 минут сама запрашивает у MSC статус звонка (activityTest). Сделано это для того, что бы, в случае какой-либо ошибки разговор не длился сутками (пока у абонента не спишутся все деньги).

CAP-протокол может тарифицировать не только голосовые звонки – он так же способен тарифицировать интернет-соединения, SMS, MMS и так далее. Хотя на практике чаще всего для этих нужд применяются специально заточенные протоколы (DIAMETER/OSA).

OSA

OSA (Open Service Access) – открытый программный интерфейс разработанный консорциумом 3GPP и ETSI, часто используется для тарификации VAS-сервисов и мобильного интернета.

Рассмотрим работу данного протокола на примере тарификации услуги мобильного интернета:

  1. При попытке активации PDP Context’а (получении телефоном IP-адреса в сети мобильного оператора) GGSN запрашивает платформу, можно ли данному абоненту активировать тарификационную сессию (CreateChargingSessionReq).
  2. В нашем случае все хорошо (абонент есть в базе, денежные средства имеются), платформа создает тарификационную сессию и разрешает активировать PDP Context (CreateChargingSessionResp).
  3. Теперь абонент хочет начать скачивать данные. Что бы позволить ему это делать, GGSN обращается к платформе с запросом на резервацию средств (ReserveUnitReq). Вообще, unit – вещь абстрактная, может быть чем угодно – килобайтом данных, смской, секундой разговора, рублем, пиццей, бочкой и так далее. В нашем случае unit – это 100 кБ.
  4. Платформа проверяет, есть ли для данного абонента, в соответствии с его тарифом, средства на 100 кБ трафика и отвечает сообщением ReserveUnitResp (“средства зарезервированы”). Приняв это сообщение от платформы, GGSN позволяет абоненту качать трафик.
  5. Когда абонент скачал зарезервированную порцию трафика, GGSN обращается к платформе с сообщением DebitUnitReq (“можно списывать зарезервированные средства”).
  6. Платформа списывает средства и отвечает сообщением DebitUnitResp (“средства успешно списаны”).
  7. Цикл ReserveUnitReq-DebitUnitResp повторяется до тех пор, пока абонент не скачает весь интернет закроет интернет сессию.
  8. При деактивации PDP Context’a GGSN посылает на платформу сообщение о завершении тарификационной сессии; память, выделенная под данную сессию освобождается.


Запрос debitUnitReq; Команды OSA обернуты в SOAP протокол, который в свою очередь инкапсулируется HTTP протоколом.

Заключение

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

Если тематика протоколов семейства AAA вам интересна, то позже я расскажу про RADIUS, DIAMETER и другие интересные вещи.

Случайные статьи

Вверх