GPRS billing…

7 июня 2010  |  Рубрики: Theory

Давайте обратим наше внимание на формирование расчетных операций у оператора, применительно к пакетной передаче данных, т.е. рассмотрим GPRS billing…


В GERAN (en) архитектуре, т.е. архитектуре предоставляющей сервисы GPRS/EDGE основной сбор биллинговых данных может ложиться на сетевые элементы SGSN и GGSN. Эти сетевые элементы собирают всю биллинговую информацию пользователя в специальные файлы CDR – Charging Data Record, а затем передают на ее т.н. CG – Charging Gateway (Биллинг Центр). Причем зачастую, в сетях мобильных операторов сбором биллинговых данных в основном занимается SGSN, который затем передает CDR файлы на CG (зачастую посредством tftp/ftp протоколов), т.к. для реализация системы сбора биллинговых данных на стороне GGSN’а необходимо более детально анализировать IP траффик, сопоставляя его с информацией от SGSN’а, что лишь в общем усложняет систему биллинга.

Биллинг GPRS сервисов может быть организован на основании следующих параметров:

  1. Объем данных (количество переданных/принятых данных).
  2. Продолжительность (продолжительность PDP сессии).
  3. Время доступа к сети (число, время суток, день недели — предоставление дешевых тарифов, например, в ночное время).
  4. Конечный пункт данных (биллинг для пользователя может быть организован по доступу пользователя к определенной сети).
  5. Местонахождение абонента (текущее географическое положение пользователя).
  6. QoS – Quality Of Service (по уровню обслуживания абонента).
  7. SMS (SGSN может организовать биллинг SMS over GPRS по определенным тарифам).
  8. IMSI/Subscriber (различные классы/группы пользователей – business/privat/vip пользователи).
  9. Зарезервированный биллинг (своеобразный аналог звонков на номера 800/900 в фиксированной связи, когда расчет за услуги взимается с приемной стороны).
  10. Фиксированная месячная абонплата.

Интервал тарификации пакетных данных различен для роуминговых и домашних пользователей. В основном для домашних пользователей установлен интервал тарификации 10KB (WAP, GPRS), хотя здесь оператора вправе выбрать свои собственные интервалы тарификации.

Для роуминговых пользователей интервал тарификации может быть от 50KB или 100KB.

Хочется отметить, что интервал тарификации в 100KB является крайне выгоден для оператора, т.к. например, использование GPRS услуг для проверки почты и незначительно серфа на просторах интернета, представляют собой большое количество маленьких сессий, размер трафика которых значительно меньше 100KB, а т.к. происходит округление каждой сессии до 100KB, счет за услуги значительно растет. К тому же, если во время использования пакетных услуг к Вам поступает входящий звонок, то сессия обрывается, а переданные/принятые данные снова округляются по 100KB.

Даже при малейшем рассмотрении такого «округления», можно заметить ощутимую прибыль со стороны оператора (см. таблицу ниже).

image

Как видим, оператор практически в двойном выиграше от округления трафика абонента, а если учесть, что абонент может воспользоваться пакетной передачей данных, находясь в роуминге, то такое “округление” может привести к значительно возросшему счету за использование услуг GPRS\EDGE.

Небольшой помощник:

EDGE – Enhanced Data Rates for GSM Evolution
GERAN – GSM EDGE Radio Access Network
GGSN – Gateway GPRS Support Node
IMSI – International Mobile Subscriber Identity
PDP – Packet Data Protocol
QoS – Quality of Service
SGSN – Serving GPRS Support Node
SMS – Short Message Service
WAP – Wireless Application Protocol

If you enjoyed this post, make sure you subscribe to my RSS feed!
Автор:
13 комментариев | 4 834 просмотров

Комментарии (13) к статье: "GPRS billing…"

  • нормальок, но думаю нужно ещё тут розьяснить разницу между онлайн и офлайн билингом, ИМХО)

    • Да особо и разъяснять нечего…

      Для pre-paid абонентов биллинг осуществляется в режиме реального времени, т.е. при поднятии (а также перед активацией) PDP Context’ов от SGSN’a через Ge интерфейс происходит запрос по CAP протоколу на IN платформы (MSCP) – платформы биллинга, о текущем остатке на балансе абонента, а затем (в случае наличия необходимого остатка на счету) через определенные интервалы времени (таймеры, которые устанавливает оператор) производятся повторные запросы на возможное продолжение активной PDP сессии абонента предоплаченного сервиса…

      Для post-paid абонентов, т.е. контрактных абонентов, сбор биллинг данных осуществляется на самом SGSN’е (хотя есть системы биллинга, осуществляющие сбор данных и на GGSN’е), т.е. на SGSN по каждому абоненту генерируются т.н. CDR файлы, которые затем по tftp/ftp протоколу передаются на системы биллинга и по которым происходит расчет счетов абонентов…

      Главное отличие этих двух типов абонентов в том, что для pre-paid производится т.н. online биллинг, а для post-paid – offline биллинг.

      Вот собственно и все!

      • Насколько я знаю, CAP3 для он-лайн тарификации с SGSN’ов поднят в единицах сетей в мире, в большинстве сетей тарификация идёт с GGSN’ов (например, по Диаметру, по Gy). В этом много плюсов – можно тарифицировать GPRS-роумеров для припейда, можно тарифицировать по результатам анализа трафика и т.д.

        (“Да особо и разъяснять нечего…” от (предполагаю) GPRS’ника звучит примерно так же как “Да что там той GPRS-сети – SGSN, GGSN и толпа G-интерфейсов вокруг…” от биллера. 🙂 )

        • Насчет CAP я с Вами не соглашусь, т.к. на моей практике как раз знаю достаточно моб. операторов, у которых реализована схема биллинга через CAP на IN платформы (я говорю о pre-paid 🙂

          Тарификация на GGSN требует анализа уже TCP данных в связке сданными от SGSN’а, поэтому как говорит вендор более сложна в реализации, но с ее преимуществами перед рассказанной схемой я с Вами абсолютно согласен.

          Фраза “Да особо и разъяснять нечего” была отнесена к различию в pre-paid и post-paid абонентам, но от части Вы правы 🙂 со стороны PS Core все так и выглядит…

  • IN платформы (MSCP) – платформы биллинга))

    Корректней было бы написать просто SCP – Service Control Point) А MSCP – эт ток в МТС) И на ней так же проверяется наличие активных услуг)

    ну такое) Мелочи)

  • Добрый день! есть вопросы которые хотела бы обсудить тет-а- тет если можно на почту пришлите способ как это можно сделать. спасибо. Очень нужна помощь.

  • По моему мнению Вы не правы. Я уверен. Могу это доказать. Пишите мне в PM, обсудим.

  • Совершенно верно! Идея отличная, согласен с Вами.


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

 

?Раньше искали

CombiSGSN GGSN SGSN GPRS Attach PDP Context SMS over GPRS SMSC GTP-C GTP-U IMSI 

!На хостинг

#Счетчики

Rambler's Top100