Additional GPRS Functionality

15 июня 2010  |  Рубрики: Evil Operator

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


Итак, что же мы можем улучшить на пакетной сети операторов…

  1. APN Restriction

    Об это дополнительной функциональности я рассказывал в статье APN Restriction. Вкратце, это функциональность позволяет ограничить поднятие дополнительных PDP Context‘ов для абонентов, которые использую GPRS/EDGE сервисы в качестве доступа к корпоративному сегменту, тем самым предотвращая возможность проникновение пакетов между internet и intranet.

  2. Flow Based Charging [FBC]

    Эта функциональность была добавлена в стандарт 3GPP Rel-6 и позволила расширить методы проведения расчетных операций с абонентами, т.е. методы сбора билинг данных. В частности, сбор биллинг данных возможен не только на SGSN‘е, а также на GGSN‘е, причем он может быть основан не только на количестве принятых/оправленных байт данных абонентом или продолжительности сессии абонента, а также, например на основании количества просмотренных web страниц, локации абонента – географической, либо же локации тайм-зоны абонента, типе радиодоступа абонента – 2G/3G, но как я упоминал в статье о GPRS Billing‘е, это функциональность слегка усложняет саму систему сбора биллинга, т.к. требует более “тщательного” анализа передаваемых TCP/IP пакетов.

    FBC может быть применен в равной степени как к pre-paid абонентам, так и к post-paid контрактным абонентам. Более детальную информации об FBC можно найти в секции 15.1.1a спецификации 3GPP TS 23.060.

    При этом в случае роуминговых абонентов, когда пользователь активирует PDP Context по “стандартной” схеме, т.е. использует свой домашний HGGSN [Home GGSN], Flow Based Charging может быть использован как при условии наличия дополнительных расчетных биллинговых договоренностей между домашней и роуминговой PLMN, так и при их отсутствии, т.к. согласно спецификации FBS формирутся в основном на стороне GGSN, а в этом случае это будет домашний GGSN – HGGSN. Однако, для реализации всех возможностей FBC, SGSN‘у необходимо предоставлять дополнительную информацию при создании или обновлении PDP Context‘ов абонентов, поэтому наличие определенных договоренностей в плане обмена биллинговой информацией и процедурами при активации и обновлении PDP Context’ов между домашней и роуминговой сетью является более приемлемым.

    В случае активации PDP Context‘а через гостевой GGSN [VGGSN] в роуминге, Flow Based Charging может быть использован только по соглашению с домашней сетью – HPLMN. При этом для абонентов, которым домашняя сеть (HPLMN) будет “приписывать” использование FBC, возможно будет “отключить” сбор биллинговых данных на самом гостевом SGSN‘е (VSGSN), а взаиморасчеты проводить лишь на основании FBC, который будет генерироваться на стороне гостевого GGSN‘а, позволив сократить при этом Inter-PLMN биллинг трафик.


Здесь я бы хотел сделать небольшое отступление и немного рассказать о роуминговых сценариях активации PDP Context‘а.

Существует два типа роуминговых сценария* активации PDP Context‘ов:

  1. PDP Context‘ы абонентов терминируются на стороне GGSN‘а, который расположен в домашней сети – HPLMN.
  2. PDP Context‘ы абонентов терминируются на стороне GGSN‘а, который расположен в гостевой сети – VPLMN.

В обоих случаях абонент производит процедуру GPRS Attach через гостевой SGSN – VSGSN.

Сценарий 1 – HGGSN Roaming

Это т.н. “стандартная” схема активации PDP Context‘а, которая является не совсем оптимальной со стороны использования ресурсов сети, но которую зачастую используют многие операторы. В этой схеме роуминговый абонент, проходит процедуру GPRS Attach на гостевом SGSN‘е, а затем активирует PDP Context через свой домашний GGSN, при этом обмен сигнальной информацией между гостевым SGSN‘ом и домашним GGSN‘ом происходит через Gp интерфейс, который может быть основан на одной из Inter PLMN IP Backbone Network, например GRX/IPX. Схема реализации этого сценария представлена на схеме ниже:

HGGSN Roaming

 

Указанный выше сценарий предполагает следующие условия:

  • SGSN и HLR взаимодействуют через сигнальный Gr интерфейс, используя международную сигнальную сеть между двумя PLMN.
  • Абоненту назначается динамический или статический адрес при поднятии PDP Context‘ов.
  • Абонент использует “прозрачный” доступ к сети, т.е. проходит “стандартный” процесс аутентификации при доступе к сети (см. примечание).
  • Inter PLMN DNS взаимодействие происходит посредством международных каналов GRX/IPX Root DNS server соединений.
  • Существуют соглашения между операторами в плане взаимодействия через пограничные шлюзы.

Сценарий 2 – VGGSN Roaming

В этом сценарии, так же как и предыдущем, абонент производит процедуру GPRS Attach через гостевой SGSN, а затем активирует PDP Context также через через гостевой GGSN, не активируя при этом туннель в свою домашнюю сеть, что в некоторой степени позволяет более рационально использовать ресурсы обоих сетей. Структурная схема этого сценария изображена на схеме ниже:

VGGSN Roaming

 

Указанный выше сценарий предполагает следующие условия:

  • SGSN и HLR взаимодействуют через сигнальный Gr интерфейс, используя международную сигнальную сеть между двумя PLMN.
  • Абоненту может быть назначен лишь динамический адрес при активации PDP Context‘а, т.к. в случае статического адреса возможен конфликт адресов в гостевой сети.
  • Абонент использует НЕ “прозрачный” доступ, т.е. проходит дополнительный процесс аутентификации при обращении к сети (см. примечание).
  • Нет необходимости в Inter PLMN DNS взаимодействии.
  • Нет необходимости в Inter PLMN IP Backbone коммуникациях.
  • В процесс коммуникации не задействуются пограничные шлюзы двух операторов.

Примечание: т.н. “не прозрачный” доступ к сети предполагает дополнительную аутентификацию и авторизацию на стороне гостевого GGSN‘а с помощью ААА серверов (RADIUS или DIAMETR), причем данные на этих серверах должны быть синхронизированы с такими же серверами на стороне домашнего GGSN‘а.

Это условие является лишь дополнительным методом аутентификации абонентов и фактически может быть не использован, если домашний оператор сочтет нужным лишь “стандартную” аутентификацию.

* – более подробно преимущества и недостатки обеих роуминговых схем активации PDP Context‘ов рассмотрены в статье Expensive GPRS Roaming.


  1. Automatic Device Detection

    Automatic Device Detection (ADD) – дополнительная функциональность, которая была добавлена в спецификации 3GPP Rel-6 и которая позволяет домашней сети абонента (HPLMN) “запоминать” текущий IMEI код абонента, сопоставляя его с IMSI/MSISDN номером абонента, даже когда он находиться в роуминге, а на основании этого сопоставления адаптировать контент, предоставляемый пользователю в зависимости от возможностей его мобильного терминала. Например, размер и объем WAP/web страниц, размер видео изображения и используемые кодеки.

    Более детально данная функциональность освещена в разделе 15.5 спецификации 3GPP TS 23.060.

    В случае наличия подключений к центральной базе IMEI кодов, т.е. к CEIR (опять же эта схема будет актуальна только для крупных европейских операторов, поддерживающих данную инициативу), отпадает двойная проверка IMEI кода в гостевой и домашней сетях.

  2. Direct Tunnel Functionality

    Direct Tunnel Functionality – это функциональность, которая была анонсирована в спецификации 3GPP Rel-7 и которая позволяет проводить роутинг GTP User plane (GTP-U) пакетов напрямую между RNC контроллером и GGSN‘ом, не задействуя при этом SGSN, при этом роутинг GTP Control plane (GTP-C) пакетов производиться как “обычно” через SGSN. Естественно, что эта функциональность применима лишь только к 3G архитектуре, т.к. для 2G архитектуры не предусмотрена прямая связь между BSS подсистемой и GGSN‘ом, а также потому что BSS (в отличие от RNC контроллера) подсистема не имеет процедур управления GTP-U плоскостью. В то же время такое решение позволяет оптимизировать сеть и освободить емкостные данные по управлению GTP-U трафиком на стороне SGSN‘а.

    Более детально данная функциональность освещена в разделе 15.6 спецификации 3GPP TS 23.060.

    Единственным нюансом, бросающим тень на введение такой функциональности, является необходимость реализации функций “легального” перехвата абонентского GTP-U трафика – LI [Legal Intercept] на стороне GGSN‘а, т.к. SGSN не участвует в его “обработке”.

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

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

    AAA – Authentication, Authorization, Accounting

    APN – Access Point Name

    BSS – Base Station Subsystem

    GGSN – Gateway GPRS Support Node

    GRX – GPRS Roaming Exchange

    GTP – GPRS Tunnelling Protocol

    HLR – Home Location Register

    HPLMN – Home PLMN

    IMSI – International Mobile Subscriber Identity

    IPX – Internetwork Packet Exchange

    MSISDN – Mobile Station Integrated Services Digital Number

    PDN – Packet Data Network

    PDP – Packet Data Protocol

    PLMN – Public Land Mobile Network

    RNC – Radio Network Controller

    SGSN – Serving GPRS Support Node

    VPLMN – Visitors PLMN

    3GPP – 3rd Generation Partnership Project

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

  3. 3GPP TS 23.060 – GPRS. Service description.
  4. Expensive GPRS Roaming
If you enjoyed this post, make sure you subscribe to my RSS feed!
Автор:
0 комментариев | 1 120 просмотров

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

 

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

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

!На хостинг

#Счетчики

Rambler's Top100