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

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

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

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

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

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

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

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

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

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

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

3. 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 кода в гостевой и домашней сетях.

4. 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):

5. 3GPP TS 23.060 – GPRS. Service description.
6. Expensive GPRS Roaming