Ну вот скоро и закончится зима… Настанут теплые весенние денечки, захочется сразу же выбраться на природу, а лучше куда-нибудь съездить отдохнуть… в теплые края… стоп, а что же взять с собой в дорогу — свой верный ноут? Но Я ведь еду отдыхать от работы… а возьму ка я свой надежный коммуникатор…
Думаю, многим знакома такая ситуация, когда уезжая заграницу, брать ноутбук как-то не хочется, а связь с внешним миром/корпоративным офисом поддерживать хочется. Поэтому одним из выходов из этой ситуации является взять коммуникатор, а в качестве выхода в сеть воспользоваться одной из технологий пакетной передачи данных — GPRS/EDGE.

Intro

В моей памяти еще свежи несколько ярких историй, на подобие вот этой, от «счастливых» обладателей весьма популярных коммуникаторов одной яблочной компании, которые получили весьма существенные счета за использование пакетной передачи данных из-за границы.

Не будем вдаваться в подробности, правда это или очередная утка, просто примем, чисто гипотетически, что такие факты могли иметь место…

Вот собственно, такие стечения обстоятельств и побудили меня написать эту маленькую заметку.

Итак… Почему же роуминговым пользователям приходят такие жуткие счета за пользование пакетных услуг, почему у операторов такие «космические» тарифы на передачу данных в роуминге?! И все это за download нескольких мегабайт?!

Например, данные по тарифам использования пакетной передачи данных (GPRS/EDGE) в роуминге для трех крупных операторов Украины:

#	Объем скачанных данных, кБ	Стоимость, $ USD
ОпСоС№1	100	1.5
ОпСоС№2	100	1.25
ОпСоС№3	95	1.1

Давайте посмотрим, а как же происходит пакетная передача данных в роуминге. Будем считать, что мы пользуемся GPRS/EDGE.

В данном случае неотъемлемой частью, участвующей в передаче данных будут SGSN и GGSN, при чем как в гостевой сети, так и в Вашей домашней сети. Чтобы упростить задачу, будем считать что абонент:

• уже зарегистрирован в пакетной сети (прошел процедуру GPRS Attach или Combi Attach*)
• имеет в настройках на MS корректную, разрешенную ему APN**
• подключил себе/ему «подключили» роуминговые услуги (метки в профиле на HLR)
• забыл отключить/решил воспользоваться услугами пакетной передачи данных
  

  * — более подробно об этоих процедурах, можно узнать из статьи: «GPRS изнутри. Часть 2»
  ** — более подробно об использовании APN можно прочитать в статье: «Не важно кто ты… важно какая у тебя APN»

Мы также рассмотрим два варианта: когда пользователь запрашивает доступ к сети, доступной только из своей HPLMN — например, VPN доступ к корпоративному intranet'у и когда пользователь просто запрашивает доступ в сеть internet.

Да… еще один не маловажный момент, будем считать, что наш «домашний» оператор имеет роуминговые договоренности с оператором, из гостевой сети которого мы будет получать услугу пакетной передачи данных.

Standart roaming GPRS/EDGE access

Общепринятая схема активации PDP Context'a для абонента, находящегося в гостевой сети, представлена на схеме ниже:



Давайте рассмотрим основные процедуры, которые происходят при активации PDP Context'а для роумингового абонента. Как видим из схемы, для организации доступа из intranet нашей домашней сети используется гостевой SGSN, который проводит процедуры аутентификации и авторизации, резолвит запрошенную APN, а затем устанавливает GTP туннель к нашему «домашнейму» GGSN'у. Аналогичная процедура будет и в случае, если роуминговый пользователь захочет просто выйти в internet.

Procedures flow diagram

Упрощенная диаграмма основных процедур, изображенных на предыдущей схеме, представлена ниже:

1. MS запрашивает GPRS доступ у гостевого SGSN'a, передавая APN в запросе на активацию PDP Context'a. На этом этапе хочу подчеркнуть, что для роуминговых пользователей SGSN автоматически к запрашиваемой APN добавит MNC и MCC, исходя из IMSI абонента и сформирует полный запрос вида: mega.fast.internet.mnc006.mcc255.gprs, для APN — mega.fast.internet.
2. Локальный (гостевой) DNS сервер проверяет (резолвит) APN, т.к. SGSN к запрашиваемой APN добавил MCC и MNC домашней сети пользователя, то гостевой DNS ничего «не знает» об этой зоне — зона mnc006.mcc255.gprs (например, некий виртуальный оператор для Украины), и перенаправит запрос к DSN серверу более высокого уровня.
3. Гостевой DNS сервер отсылает запрос на резолв к DNS серверу более высокого уровня (DNS в зоне GRX(en) — GPRS Roaming eXchange), если он подключен к этой сети.
4. Корневой DNS в зоне GRX, «знает» что обслуживанием зоны mnc006.mcc255 занимается DNS сервер в домашней сети пользователя и передает запрос на него.
5. Гостевой SGSN получает IP адрес GGSN'a, который обслуживает запрашиваемую APN в домашней сети пользователя.
6. Гостевой SGSN перенаправляет запрос на PDP Context активацию к домашнему GGSN'у.
7. Домашний GGSN принимает запрос и устанавливает GTP туннель.

Мы видим, что для того чтобы была возможность пользоваться услугами GPRS в роуминге необходимо в конечном счете, чтобы сети операторов были каким-нибудь способом соединены между собой. Самым простым способом таких подключений является прямая связь каждого оператора друг с другом, но естественно такой способ является не надежным и абсолютно экономически не приемлемым.

Поэтому и была организована всемирная сеть GRX (GPRS Roaming eXchange), позволяющая объединять операторов по всему миру, а вместе с ней появились провайдеры, подключающие крупных операторов к этой сети.

Договоренности по подключению операторов к сети GRX, рекламируются как расширение покрытия GPRS услуг в роуминге.


После установления сессии с домашним GGSN'ом, нас интересует путь, нет не самурая :) а биллинг данных из гостевой сети оператора в нашу домашнюю сеть. Как известно биллинг данные, может накапливать у себя один из сетевых элементов — SGSN или GGSN*, а затем их должен забирать оператор и формировать расчетные операции на CG [Charging Gataway]**. При чем, в случае с роуминговыми абонентами, CDR записи может собирать гостевой SGSN, а затем заграничный оператор может передавать эти данные к домашнему оператору, в силу роуминговых договоренностей.

* — чаще всего, CDR записи все таки накапливаются на стороне SGSN'a, т.к. сбор биллинговых данных на GGSN'е требует более сложной реализации и особо не пользуется популярностью у операторов.
** — в основном, в этой статье речь идет о post-paid абонентах (контрактные абоненты), для который расчетные операции осуществляются в offline режиме, поэтому для таких абонентов необходимо собрать биллинговые данные (CDR записи), а затем произвести расчет по контрактным обязательствам. Существую еще pre-paid абоненты (абоненты предоплаченого сервиса), для которых расчетные операции осуществляются в режиме online, с помощью CAP протоколов и т.н. IN [Intellegent Network] платформ. Биллинг схемы для pre-paid абонентов, практически не зависят от местоположения абонента (гостевая или домашняя сеть), поэтому их рассмотрение не включено в данную статью, но изъяны описанной схемы предоставления выхода в сеть для контрактных абонентов в роуминге, в равной степени соответствуют и схеме предоставления выхода в сеть для абонентов преоплаченного сервиса, находящихся в роуминге.

Продолжаем наши рассуждения…
Как видим из общей схемы активации PDP Context'a выше, GTP туннель «тянется» из-за границы прямиком в нашу домашнюю сеть, к нашему домашнему GGSN'у, который предоставляет нам выход в сеть internet. Что же заставляет домашнего оператора использовать такую неэффективную схему подключения?!

Причин, на самом деле может быть несколько:

• роуминговый абонент запрашивает доступ к корпоративному intranet'у, либо к определенной LAN_over_GPRS, выход на которые есть только через домашний GGSN.
• наш домашний оператор «не доверяет» своему роуминговому партнеру и предпочитает производить сбор биллинговых данных на своем GGSN'е.

Но исходя из того, что мы уже знаем… операторы в основном использует схему сбора CDR записей на самом SGSN, т.е. в случае с роуминговым абонентом это будет гостевой SGSN + опять же, в основном ройминговые абоненты запрашивают простой доступ к сети internet, выход на который в принципе имеет и гостевой GGSN.

Давайте порассуждаем, как же можно упростить существующую «неэффективную» схему и снизить тарифы на использование пакетной передачи данных в роуминге…

Alternative roaming GPRS/EDGE access

В случае если, роуминговому абоненту нужен всего лишь выход в инет, а в большинстве случаев так и есть, то существует альтернативная схема активации PDP Context'a, которая имеет свои нюансы, но позволяет снизить затраты абонента на пакетную передачу данных в роуминге:



Основные процедуры для этой схемы представлены ниже:

1. MS запрашивает GPRS доступ, передавая гостевому SGSN’у APN в запросе на активацию PDP Context'a. При этом на гостевом SGSN'е настроена функциональность для «подмены» запрошенной APN абонента — Override of roaming APN (в сочетании с использование функциональности DEFAPN); на APN, предназначенную специально для роуминговых абонентов, которые запрашиваю доступ в сеть интернет.
2. Гостевой SGSN посылает запрос локальному DNS серверу (с уже подмененной APN в запросе) на определения гостевого GGSN, который будет обслуживать роумингового абонента.
3. Гостевой DNS сервер возвращает IP адрес GGNS’a (или нескольких GGSN'ов), который обслуживает роуминговых абонентов.
4. Гостевой SGSN передает запрос на активацию PDP контекста локальному GGSN.
5. Гостевой GGNS принимает запрос и устанавливает GTP туннель, предоставляю абоненту доступ в сеть.

Мы видим, что схема в данном случае становиться значительно проще, но она имеет свои

требования:

• для гостевых абонентов роумингового партнера, на SGSN'е должна быть настроена функциональность т.н. Default APN в сочетании с настройкой о перезаписи запрошенной APN (Override of roaming APN), которая позволит заменить APN запрошенную в запросе на активацию PDP Context'a и предоставит пользователю просто доступ к сети internet, а также будет тарифицироваться, как если бы абонент пользовался пакетными услугами в своей домашней сети.
• в профиле пользователя на HLR’е, в поле разрешенных APN должна стоять «*», позволяющая использовать любые корректные APN в сети оператора.
• в профиле пользователя на HLR'е должно быть разрешено использование VPLMN — параметр «vplmn allowed -> yes».
• в гостевом SGSN'е, для PLMN роуминговых абонентов должно быть разрешено использование гостевых PLMN — параметр «vplmn allowed -> yes».
• домашний оператор в дополнение к роуминговым соглашениям с гостевым оператором, должен иметь некие договоренности с провайдерами интернет услуг, через которые гостевой GGSN (гостевой оператор) имеет выход в сеть internet, либо согласовывать взаиморасчеты со своим роуминговым партнерам по свои абонентам.

и ограничения:

• наша оптимальная схема предоставления выхода в сеть internet для роуминговых абонентов, не позволит предоставить абоненту доступ к сети (VPN доступ к intranet/LAN_over_GPRS), доступной только через домашний GGSN.
• решение, также не приемлемо в случае, если домашний оператор использует схему сбора биллинг данных со своего домашнего GGSN'а для роуминговых абонентов.

Summary

Будьте внимательными при использовании пакетной передачи данных заграницей, т.к. большинство операторов использует первую схему подключения абонентов через «домашний» GGSN, которая в случае «обычного» выхода в сеть internet является не эффективной, но финансово выгодной для оператора. Соотвественно и тарифы на пакетную передачу данных в роуминге оставляют желать лучшего. Альтернативой за границей, ИМХО я вижу использование бесплатных Wi-Fi точек доступа, либо покупку роуминговой SIM карты именно под выход в сеть с помощью GPRS/EDGE.

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

APN — Access Point Name
CDR — Call Detail Record
CAMEL — Customized Applications for Mobile Enhanced Logic
CAP — CAMEL Application Part
GTP — GPRS Tunnelling Protocol
HGGSN — Home GGSN
HPLMN — Home PLMN
HSGSN — Home SGSN
MS — Mobile Station
PDP — Packet Data Protocol
PLMN — Public Land Mobile Network
VGGSN — Visiting GGSN
VPLMN — Visited PLMN
VSGSN — Visiting SGSN
WAP — Wireless Application Protocol