Dmitry Astapov (_adept_) wrote,
Dmitry Astapov
_adept_

Category:
  • Music:

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 или задавать вопросы прямо тут
Tags: gsm
Subscribe

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 49 comments