CAMEL in GPRS prepaid service

24 августа 2010  |  Рубрики: Theory

В силу появившихся вопросов и дополнений к статье о GPRS billing‘е, решил копнуть немного глубже в этом вопросе, в частности рассмотрел применение протокола CAP для pre-paid абонентов, а также несколько ключевых моментов при формировании биллинговых операций.


Как нам уже известно из статьи об основных протоколах и интерфейсах GSN элементов пакетной сети (GPRS изнутри. Часть 3), за предоставление биллинговых операций абонентов, в частности абонентов pre-paid сервисов, отвечает Ge интерфейс, который связывает SGSN с платформами SCP (IN платформами), предоставляя возможность отслеживать биллинговые изменения в режиме реального времени (см. схему ниже).

SGSN Interfaces

Как мы знаем на этом интерфейсе используется CAP протокол, который реализует механизмы CAMEL [Customized Application for Mobile Network Enchanced Logic], стандарта поддержки услуг IN в сетях стандарта GSM, т.е. это своеобразное специализированное приложение для расширенной логики мобильной связи по взаимодействию с платформами биллинга – SCP [IN] платформами.

В общем случае схема предоставления сервисов с “вовлечением” CAP представлена на рисунке ниже, из которого мы можем заметить, что фактически CAP протокол используется для организации связности между элементами gsmSCF со стороны SCP платформы и gprsSSF – со стороны SGSN‘а.

gprsSSF

Эти элементы (gsmSCF, gprsSSF) физически являются частью SCP платформы и SGSN‘а, соответственно, но выделяются в отдельный логический блок, определяющий взаимодействие именно с протоколом CAP.

gsmSCF

Следует отметить, что CAMEL-GPRS был анонсирован лишь в спецификации CAMEL Phase 3 (R99) и тем самым позволил реализовать online charging для абонентов GPRS услуг. В качестве протокола, использующего механизмы CAMEL используется CAP протокол модели SS7. Сам CAP [CAMEL Application Part] весьма схож по своему стеку протоколов с МАР протоколом, используемым на Gr интерфейсе, а также Gd, Gf интерфесах (см. схему ниже).

CAP Stack

Процесс расчетных операций основывается на анализе событий, совершаемых в основном со стороны абонента, при этом эти события зациклены на “срабатывании” определенных триггеров/точек на стороне биллинг платформы, по некоторым явно выраженным GPRS событиям, фиксируемых с помощью т.н. контрольных точек – Detection Points (DPs).

При этом DPs могут быть либо задействованы, т.е. “привлекут” к взаимодействию gsmSCF элемент платформы SCP, тем самым предоставляя SCP платформе влияние на процесс, либо эти же DPs не задействуются – предоставляя процессу/событию возможность протекать без вмешательства SCP платформы. Например, если pre-paid абонент активирует PDP Context, то срабатывает определенная DP на стороне SGSN‘а, которая “говорит” о том, что необходимо обязательное участие в этом событии (активации PDP Context‘а) SCP платформы, т.к. необходим контроль текущего баланса абонента для следующих операций.

Существует несколько видов DPs:

  • Trigger Detection Point-Request (TDP-R)

    Активируются статически, инициируя CAMEL взаимодействие. После наступления события, которое инициировало активацию данной DP, это событие приостанавливается.

  • Event Detection Point-Request (EDP-R)

    Активируются динамически, внутри CAMEL взаимодействие. После наступления события, которое инициировало активацию данной DP, это событие приостанавливается и gprsSSF блок ожидает дальнейших инструкций от gsmSCF, т.е. от SCP платформы.

  • Event Detection Point-Notification (EDP-N)

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

Существуют также базовые DPs для ключевых GPRS процессов:

  1. GPRS Attach/Detach State Model
    GPRS MS Model State

    Основные DPs:

    • DP Attach
    • DP Change of Position GPRS session
    • DP Detach
  2. GPRS PDP Context State Model
    GPRS PDP Context

    Основные DPs:

    • DP PDP Context Establishment
    • DP PDP Context Establishment Ack
    • DP PDP Context Disconnection
    • DP Change of Position Context

При этом, каждой определенной DP/группе DP соответствует своя IN (SCP) платформа, которая знает как “посчитать” стоимость услуги, запрошенной абонентом. Соответствие DP и SCP платформ, которые их “обслуживаю” хранится в HLR‘е домашней сети абонента. Если быть точным, группе параметров, отвечающих за контрольные биллинговые точки – DPs, в HLR‘е соответствует т.н. GPRS-CSI (GPRS-CAMEL Subscription Information) поле, в котором хранятся:

  • адреса gsmSCF, т.е. Global Titles (GT) адреса SCP платформ, по “обслуживанию” определенных DPs.
  • Service Key ключи, которые непосредственно указывают SCP платформе на использование определенного “набора” логики для обработки событий, совершаемых абонентами.
  • Default Call Handling процедуры, определяющие поведение ключевых элементов (gprsSSF/SGSN и gsmSCF/SCP) при ситуациях обработки ошибок в диалоге, например, какое действие должен совершить gprsSSF/SGSN в случае отказа продолжения события от gsmSCF/SCP – пытаться продолжить повторять запросы, либо оборвать диалог и уведомить абонента. При этом каждому Service Key ключу соответствует т.н. Default модель поведения (модель поведения по-умолчанию) со стороны платформ.
  • TDP (Trigger Detection Point) List список, который указывает при каких именно событиях будет задействовано CAMEL триггирование.

Рассмотрев основные положения и ситуации использования CAP протокола, приступим к основной теме статьи – применение CAMEL для pre-paid абонентов в роуминге.

В общем случае существует два GPRS CAMEL сценария развития событий:

  • SCP платформе разрешено CAMEL управление множественными GPRS сессиями внутри одного GPRS диалога, т.е. разрешена активация множественных PDP Context‘ов “внутри” одного GPRS диалога.
    SGSN and SCP

  • SCP платформе разрешено CAMEL управление лишь одиночными GPRS сессиями, т.е. на каждый PDP Context “открывается” новый диалог между SCP платформой и SGSN‘ом.
    SGSN and SCP

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

Как мы знаем из статьи Expensive GPRS Roaming, существует два сценария активации контекстов для абонентов, находящихся в роуминге – через домашний GGSN (HGGSN) и через гостевой GGSN (VGGSN), причем оба варианта одинаково приемлемы как для pre-paid абонентов, так и для post-paid абонентов.

GPRS Roaming

Для упрощения, рассмотрим типичный случай – абонент pre-paid сервиса находясь в роуминге активирует PDP Context через свой домашний GGSN. Причем, как мы помним, довольно важное значение при активации контекстов будет играть DNS сервера, как гостевые, так и рутовые в зоне GRX.

GPRS Roaming

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

Roaming APN

Так как же все таки происходит “включение” биллинга для pre-paid абонента в роуминге…

Допустим абонент уже совершил операцию регистрации в гостевой сети роуминг оператора, т.е. произвел GPRS Attach, в профиле на HLR‘е у него запрещено использование гостевого GGSN‘а (флаг “vplmn allowed” = no) и при этом он начинает активацию PDP Context‘а.

Во время активации PDP Context‘а абонент передает запрос на SGSN, при этом как мы знаем для модели GPRS PDP Context State Model (см. выше) “срабатывают” определенные DPs (контрольные точки) и SGSN “знает”, что для гостевых pre-paid абонентов нужен online контроль текущего баланса при использовании пакетных услуг. Для этого SGSN “обращается” к HLR‘у за данными о SCP (IN) платформах, которые смогут произвести расчетные операции за пользование услугами, т.е. SGSN использует международную сеть взаимодействия роуминг партнеров – GRX, открывая диалог с соответствующей SCP (IN) платформой в домашней сети (HPLMN) абонента и ожидает дальнейших инструкций от этой платформы (адресация происходит с помощью Е.164 плана нумерации, a.k.a GTGlobal Titles), в случае положительного текущего баланса у абонента и отсутствия запретов на использование пакетных услуг в роуминге в профиле абонента в HLR‘е – абонент получает доступ к использованию GPRS\EDGE. Все расчетные операции для этого абонента будут проходить в режиме online, причем IN платформа, проверяет через определенные временные интервалы (таймеры) состояние баланса абонента, дабы избежать отрицательного счета.

Проиллюстрируем все вышесказанное с помощью упрощенной схемы:

GPRS Roaming

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

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

CAMEL – Customised Applications for Mobile networks Enhanced Logic
CAP – CAMEL Application Part
DNS – Domain Name System
EDGE – Enhanced Data Rates for GSM Evolution
GGSN – Gateway GPRS Support Node
GPRS – General Packet Radio Service
GRX – GPRS Roaming Exchange
HLR – Home Location Register
IN – Intelligent Networks
MAP – Mobile Application Part
PDP – Packet Data Protocol
SCF – Service Control Function
SCP – Service Control Point
SGSN – Serving GPRS Support Node
SSF – Service Switching Point

Ссылки по теме (ru):

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

Комментарии (2) к статье: "CAMEL in GPRS prepaid service"

  • Спасибо за статью – когда-то возникал вопрос по поводу онлайн тарификации GPRS, но разбираться не стал.
    Есть некоторые замечания:
    “Для этого SGSN «обращается» к HLR’у за данными о SCP (IN) платформах, которые смогут произвести расчетные операции за пользование услугами, т.е. SGSN использует международную сеть взаимодействия роуминг партнеров – GRX, открывая диалог с соответствующей SCP (IN) платформой в домашней сети (HPLMN) абонента и ожидает дальнейших инструкций от этой платформы”

    Что-то тут явно не то. Разве SGSN не получает список DP и соответствующим им gsmSCF при регистрации абонента, как часть GPRS-CSI? И тогда при переходе состояния сессии в DP (например, активация контекста), автоматически идёт запрос на SCP. Только мне кажется не через GRX, а через “обычную” сеть SS7. По-крайней мере именно так всё происходит с голосовыми вызовами.

    • Все верно, список DP можно получить и в запросе на аутентификацию абонента, но все зависит от роуминговых настроек для конкретного оператора, т.е. возможно список будет получен сразу в запросе GPRS Attach, либо же в дальнейшем путем обращения к домашнему HLR’у абонента, а SS7 в роуминге как раз и идет через GRX, т.к. она предполагает взаимные подключения роуминговых операторов как для пакетных данных, так и для сигнализации.


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

 

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

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

!На хостинг

#Счетчики

Rambler's Top100