dastapov | GSM: нет верблюда - нету роуминга для pre-paid-а :)

В предыдущем посте я рассказал об основах функционирования IN в сетях GSM и организации предоплаченного сервиса на основе IN.

Если вам довелось быть пользователем такого сервиса и ездить за границу покрытия GSM-сети вашего оператора, то вы могли столкнуться с тем, что вы остались без возможности совершать исходящие звонки. И лишь сравнительно недавно GSM-операторы стали предоставлять (анонимным) prepaid абонентам в роуминге все те же услуги, что и абонентам контрактным.

В этом посте: почему IN-сервисы не работают в роуминге, как жить без них, что нужно для того, чтобы они работали в роуминге, и при чем тут верблюд?

Начать придется с рассказа о том, что такое HLR

HLR - это такая база данных, в которой хранится информация о базовых GSM сервисах, доступных пользователю, в чей телефон вставлена сим-карта с таким-то IMSI. Под базовыми GSM-сервисами понимается передача голоса, данных, факсимильная связь, посылка и прием SMS-ов и разнообразные финты ушами со звонками - удержание, переадресация, конференц-связь, ....

Основная черта HLR - он работает быстро. Настолько быстро, чтобы успевать отвечать на запросы по SS7 в течении, кажется, 125 ms, при очень большом кол-ве конкурентных (одновременных) запросов.

Понятно, что чем больше записей в HLR - тем тяжелее ему работать в режиме real-time. Поэтому в HLR обычно помещается до 1 млн. абонентов. Соответственно, у больших операторов в сети существует много HLR-ов - иногда до нескольких десятков.

Протоколы маршрутизации сети GSM позволяют по номеру абонента узнать "адрес" (global title) того HLR-а, в котором живет информация о абоненте.

Раз уж сказали про HLR, прийдется сказать и про VLR

Чтобы повысить надежность сети и снизить нагрузку на HLR, коммутаторы "кешируют" информацию, запрошенную из HLR-ов.

При регистрации мобильного телефона в сети тот коммутатор, в зоне обслуживания которого регистрируется телефон, определяет по номеру SIM-карты адрес HLR-а и отправляет туда запрос на получение почти всех данных об абоненте. Полученные данные MSC складывает в свою локальную базу под названием VLR (visitor location register), при этом в VLR-записи для данного абонента будет указано, из какого HLR-а она взята, а HLR отметит у себя, в каком VLR зарегистрировался абонент. Кроме того, HLR уведомит "место предыдущей регистрации абонента" (какой-то другой VLR) о том, что данные об абоненте можно удалить.

Схематически это можно представить так:

Соответственно, когда абонент перемещается в пределах своей "домашней" сети, информация о нем "кочует" по VLR-ам домашней сети.

HLR и VLR нужны для маршрутизации звонков

Допустим этому абонент (назовем его B) звонит другой абонент этой же сети (назовем его A). Каким образом звонок A->B достигнет своего получателя?

Сначала коммутатор (SSP1), который обслуживает звонок[1] абонента A, найдет по номеру B тот HLR, в котором живут данные B, и спросит этот HLR о том, в каком VLR-е сейчас "прописан" B[2]. В свою очередь, HLR обратится к VLR-у и спросит о том, как связаться с MSC, в зоне обслуживания которого сейчас живет живет B[3]. После получения ответа ([4,5]) коммутатор, обслуживающий абонента A, передает "бразды правления" коммутатору, обслуживающему абонента B[6]. Это коммутатор (SSP2), в свою очередь, опрашивает VLR на предмет того, в какой location area в последний раз регистрировался абонент B и просит радиосеть осуществить paging (поиск телефона) в этой LA ([7,8,9]). Если абонента найден ([10,11]), то происходит создание "голосового канала" и собственно разговор.

Понятно изложил? :)

Все это очень интересно, но когда же будет про роуминг?

Роуминг - это когда абонента обслуживает сеть "не родного" ему оператора. Абонент регистрируется в "чужой" сети, чужой MSC опрашивает "родной" HLR абонента и кэширует данные в "чужом" VLR-е.

Если после этого абоненту B (который в роуминге) звонит "с родины" абонент А, то процесс установления звонка происходит точно так же, как показано на предыдущей картинке, только SSP1 и SSP2 оказываются в сетях разных операторов.

Я бы даже уточнил: абонент A, SSP1 и HLR находятся в "родной сети", а абонент B, SSP2, VLR и все прочее - в "чужой" сети.

Если все так красиво, то почему у prepaid-а не работают исходящие звонки в роуминге?

А не работают они потому, что коммутатор "вражеской" сети не знает о том, что у роумингового абонента есть какие-то detection point-ы (см. предыдущий пост), что надо связываться с каким-то IN-ом (чтобы тот считал деньги) и т.п.

Погодите-ка, но ведь информация о detection point-ах и адресе соответствующего IN-а хранится в HLR-е. В чем же причина такого "незнания"?

А причина в том, что до определенного момента стэк протоколов сети GSM не предоставлял "вражескому" MSC возможности извлечь эту информацию из HLR и сохранить в своем VLR, и кроме того - у IN-ов не было "глобальных" (всемирных) адресов, по которым "вражеский" MSC мог связаться с "родным" IN-ом.

Получается, что prepaid-пользователи не могли осуществить исходящий звонок так же, как у себя "на родине" - с online тарификацией и контролем остатка денег на счету. А делать звонки без этого контроля и "уходить в минус" оператор им не давал - боялся, что они не станут платить и уйдут в бега :)

Есть ли способ обойти это ограничение?

Ряд операторов реализовывал у себя функцию под названием USSD callback. Она позволяла prepaid абоненту A, находящимуся в роуминге, "попросить" свой родной IN инициировать звонок указанному абоненту B, потом инициировать звонок абоненту A, а потом объединить звонки (IN->A) и (IN->B) в конференцию.

Впрочем, все понимали, что этот костыль не может называться "нормальным решением проблемы".

Решение - это верблюд!

И вот где-то в середине девяностых годов прошлого века GSM consortium родил нормальное решение, позволяющее предоставлять IN-based сервисы в роуминге. Решение получило название CAMEL - Customized Applications for Mobile Enhanced Logic.

За словом CAMEL скрывается ряд усовершенствований в стандартах на HLR и VLR, расширение ряда протоколов и введение нового протокола CAP (CAMEL Application Part), который позволил "вражеским" MSC работать с IN-ами в "родной" абонента.

Иллюстрация в тему:
36,70 КБ

Тут показано, как абонент из "Home network" поехал в роутиг в "Visiting network", а ему делает звонок абонент из сети "Interrogating network". Пунктир - это сигнализация, а сплошные линии - это голосовой канал. Словом "gsmSSF" на этой картинке обзывают SCP :)

CAMEL бывает разный

Самая первая версия протокола CAP позволяла просто совершать звонки, вторая (CAP2) - совершать звонки и пользоваться дополнительными сервисами, связанными со звонками, а третья версия (CAP3) позволяет посылать SMS-ы и пользоваться GPRS-ом в роуминге.

Единственное условие - для того, чтобы CAP-based roaming работал, обе сети - "родная" и "вражеская" должны поддерживать CAP нужной версии или выше.

UDP:
Литература:
* http://www.c7.com/ss7/whitepapers/meskauskas_camel.pdf (обзор CAMEL)
* http://www.cnp-wireless.com/ArticleArchive/Wireless%20Review/200103%20CAMEL.html (обзор CAMEL)
* http://www.3gpp.org/ftp/Specs/archive/02_series/02.78/0278-720.zip (GSM 02.78 - стандарт на CAMEL/CAP1)

PS
Извиняйте, что все в акронимах и технических подробностях, но по-другому не получится рассказать :)

Если текст непонятен - пробуйте почитать мои предыдущие посты (если вы этого еще не делали), использовать google или задавать вопросы прямо тут