Про GPRS Блог о пакетной передаче данных в мобильных сетях

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)

Типичный пример, применения системы рейтингов, можно привести например, когда оператор предоставляет возможность использование определенного лимита мобильного интернета по одной цене, например первый 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

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 протоколов в системы биллинга, где на их основании формируются взаиморасчетные операции для абонентов. Упрощенно, эта схема представлена ниже:

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

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

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

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

** – более подробно об основных интерфейсах можно почитать в статье 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 механизмов.

CDR from Roaming

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

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

Outro

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

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

Время начала генерации CDR файлов на SGSN‘е и GGSN‘е не синхронизируется автоматически между этими стевыми элементами, поэтому для корреляции данных в случае сопоставления двух файлов с SGSN‘а и GGSN‘а используют идентификатор CDR – CID (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):

• 3GPP TS 12.15 – GPRS Charging