GPRS Charging

24 августа 2010  |  Рубрики: Theory
    Еще одна статья, продолжающая тему рассмотрение принципов взаиморасчетов оператора со своими абонента, которую мы начали в двух предыдущих заметках: GPRS billing и CAMEL in GPRS prepaid service.


    В сегодняшней статье мы рассмотрим принципы формирования биллинговых операций, которые в основном применяются для post-paid абонентов, т.е. системы offline биллинга, основанные на сборе CDR файлов по предоставляемым услугам.

    Intro

    Принципы формирования расчетных операций для GPRS/EDGE слегка отличаются от принципов формирования биллинговых данных для “обычных” голосовых GSM сервисов, т.к. здесь уже фокус внимая больше смещен в сторону объема скачанных данных, нежели продолжительности сессии, хотя и этот параметр может быть учтен. Сами биллинговые данные могут формироваться как на одном из SGSN‘ов, либо GGSN‘ов, так и на обоих этих сетевых элементах одновременно.

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

    • местоположение абонента
    • предоставляемый QoS
    • продолжительность GPRS/EDGE сессии
    • используемая APN для активирования PDP Context‘а
    • объем переданных/полученных данных
    • события по передаче SMS over GPRS*

    * – более подробно об услуге SMS over GPRS можно прочесть в статье Запасной путь для SMS.

    Следует также отметить, что в добавок к основным параметрам, указанным выше может быть добавлен фактор т.н. рейтинга (rating), который может быть:

    • постоянный (flat rate)
    • повременной (time-dependent)
    • нерегулируемый (free of charge)

    GPRS Charging

    Типичный пример, применения системы рейтингов, можно привести например, когда оператор предоставляет возможность использование определенного лимита мобильного интернета по одной цене, например первый 1GB за n$, а следующее 5GB по цене m$.

    Последнее время все чаще проскакивают новости о конкурсах/внедрениях различными операторами систем, позволяющих отслеживать тип используемого абонентом трафика (HTTP, ICQ, Skype, P2P, etc.) и соответственно, реализовывать тарифы разделяющие эти типы трафика.

    Одной из реализаций таких систем является использование дополнения к системам биллинга – DPI (Deep Packet Inspection), которое позволяет в режиме реального времени отслеживать тип используемого абонентом трафика и соответственно рассчитывать стоимость такой передачи по определенному тарифу. Причем со слов людей имеющих дело с такими системами, они позволяют “распознавать” туннельные протоколы (VPN, IPSec, etc.) и запрещать/тарифицировать их по определенным правила.

    Еще одним возможным вариантом градации мобильного трафика является использование FBC [Flow Based Charging] – функциональности, позволяющей расширить методы проведения расчетных операций с абонентом. Например, сбор биллинг данных становиться возможным на основании количества просмотренных web-страниц, локации абонента – географической, либо же локации тайм-зоны абонента, типе радиодоступа абонента – 2G/3G и т.д. Частично о FBC упоминается в статье Additional GPRS Functionality.

    CDR types

    Вернемся к нашей основной теме – системам offline биллинга… для формирования биллинг данных SGSN/GGSN’у теперь не нужно связываться в режиме реального времени с платформой SCP (IN) как для pre-paid абонентов, рассмотренной нами в предыдущей статье (см. CAMEL in GPRS prepaid service), поэтому биллинг данные собираются в специальных файлах на стороне SGSN‘а, либо GGSN‘а – CDR [Call Detail Record] файлах.

    Для GPRS биллинга выделяют следующие основные виды этих файлов:

    • M-CDR
    • S-CDR
    • S-SMO-CDR
    • S-SMT-CDR
    • G-CDR

    GPRS CDR Types

    M-CDR, S-CDR, S-SMO-CDR, S-SMT-CDR относятся к файлам, генерирующимся на SGSN‘е, а G-CDR генерятся на GGSN‘е. Причем M-CDR используются для сбора биллинговой информации, относящейся к Mobility Management – GMM (см. статью GPRS MS State Model) и обычно открываются для каждой GPRS сессии при GPRS Attach‘е, а предназначаются для сбора информации о Record Type, Served IMSI, Sequence Number, и т.п. S-SMO-CDR и S-SMT-CDR записи формируются на SGSN‘е для исходящих и входящих SMS сообщений, переданных через пакетную сеть соответственно.

    Механизм начала формирования CDR файлов остается такой же как и для online биллинговых систем, т.е. в случае инициирования определенных действий со стороны абонента, на стороне SGSN/GGSN‘а “срабатывают” определенные тригерры/контрольные точки, которые предоставляют дальнейшие инструкции для сетевого элемента и обычно свидетельствуют о начале формирования CDR файла.

    После того как файлы достигают определённого объема, они передаются с помощью tftp/ftp протоколов в системы биллинга, где на их основании формируются взаиморасчетные операции для абонентов. Упрощенно, эта схема представлена ниже:

    CGF

    Также как и для взаимодействия с помощью протокола CAP с SCP (IN) платформами в режиме реального времени в SGSN‘е, либо GGSN‘е выделяют специальный логический блок – gprsSSF, физически являющийся одним целым с сетевым элементом, но занимающийся именно обработкой биллинг данных. Аналогична ситуация с offline системами биллинга – для SGSN/GGSN‘а выделяют логический блок – CGF (Charging Gateway Function).

    Причем CGF может быть реализован в виде части одного из сетевых элементов – SGSN, GGSN и тогда целостный CDR файл (имеющий определенную структуру) формируется на самом SGSN/GGSN‘е, а затем передается по tftp/ftp на систему биллинга.

    Такая ситуация обычно приемлема, если пакетная сеть и биллинговые системы оператора построены на оборудовании различных вендоров, тогда есть смысл “просто” передавать CDR файлы по tftp/ftp на биллинг системы (см. схему ниже).

    GPRS Billing

    Возможна также ситуация когда CGF выступает в качестве отдельного сетевого элемента. В этом случае в действие вступает Ga интерфейс** и биллинговая информация будет передаваться с помощью протокола GTP`, формируя целостные CDR файлы уже на самом CGF. Ga интерфейс может быть дополнен Gz интерфейсом, который также основан на GTP` протоколе (см. статью Опциональные интерфейсы GSN’ов).

    SGSN billing

    ** – более подробно об основных интерфейсах можно почитать в статье GPRS изнутри. Часть 3.

    Такая ситуация более приемлема, в случае построения сети оператора на оборудовании одного вендора, т.к. вендор скорее всего предоставит целостное решение, позволяющее максимально эффективно связать SGSN/GGSN и CGF используя свой проприетарный Ga интерфейс.

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

    • передача CDR записей между смежными нодами (сетевыми элементами)
    • надежные методы обнаружения ошибок в передаче данных
    • механизмы избежания дублирования CDR записей

    К тому же, т.к. GTP` основан на GTP протоколе он может быть реализован на стеке UDP/IP, либо TCP/IP, что довольно выгодно в реализации на основании пакетных PDN сетей.

    Другими вариантами для реализации передачи биллинг данных могли выступать: hot billing, hot operation, FTP push…

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

    GTP`

    CDR from Roaming

    Ситуация с передачей CDR файлов довольна ясна, если абонент находится в своей домашней сети (HPLMN), т.е. и SGSN, и GGSN передают CDR файлы на одну и ту же платформу.

    Roaming CDR

    Но ситуация меняется если абонент оказывается в гостевой PLMN (VPLMN), т.е. абонент находится в роуминге. В этом случае если оператор реализует активацию абонентом PDP Context’а через гостевой SGSN и домашний GGSN (см. статью Expensive GPRS Roaming), то CDR записи будут формироваться на гостевом SGSN‘е и необходимо как то передать CDR файлы в домашнюю PLMN сеть на платформы биллинга. Обычно эти процедуры оговариваются в роуминговых договоренностях.

    Roaming CDR

    Outro

    Таким образом, подводя небольшой итог, можно отметить, что для т.н. offline систем биллинга характерно генерирование CDR файлов, которые могут “собираться” на SGSN‘е или GGSN‘е, либо на обоих сетевых элементах одновременно. Затем эти файлы передаются в системы биллинга – CGF, выполняющие следующие основные функции:

    • фильтрация и препроцессинг биллинг данных
    • объединение CDR файлов для формирования целостных событий
    • контроль целостности передачи данных на Ga, Gz интерфейсах
    • формирование начальных расчетных операций перед передачей в биллинговые центры

    Время начала генерации CDR файлов на SGSN‘е и GGSN‘е не синхронизируется автоматически между этими стевыми элементами, поэтому для корреляции данных в случае сопоставления двух файлов с SGSN‘а и GGSN‘а используют идентификатор CDRCID (Charging ID). Причем CID обычно генерируется на стороне GGSN‘а во время активации PDP Context‘а, а затем значение передается на SGSN и “сопровождает” все операции по RAU, включая inter-SGSN перемещения абонента (см. статью Routing Area Update procedures). Связка CID и адреса GGSN‘а является уникальной для всего времени существования CDR файла, даже между различными PLMN сетями операторов.

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

    APN – Access Point Name
    CAMEL – Customised Applications for Mobile networks Enhanced Logic
    CAP – CAMEL Application Part
    EDGE – Enhanced Data Rates for GSM Evolution
    GGSN – Gateway GPRS Support Node
    GPRS – General Packet Radio Service
    GTP – GPRS Tunnelling Protocol
    IMSI – International Mobile Subscriber Identity
    IN – Intelligent Network
    PDN – Packet Data Network
    PDP – Packet Data Protocol
    PLMN – Public Land Mobile Network
    QoS – Quality of service
    RAU – Routing Area Update
    SCP – Service Control Point
    SGSN – Serving GPRS Support Node
    VPN – Virtual Private Network

    Ссылка в тему (en):

    If you enjoyed this post, make sure you subscribe to my RSS feed!
0 комментариев | 2 596 просмотров

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

 

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

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

!На хостинг

#Счетчики

Rambler's Top100