Какое отношение верблюд имеет к услуге роуминга для pre-paid абонентов?
(Предполагается, что вы прочли статью об основах функционирования IN в сетях GSM и организации предоплаченного сервиса на основе IN)
Если вам довелось быть пользователем сервиса предоплаченной связи (prepaid) и ездить за границу покрытия 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-ами в “родной” абонента.
Иллюстрация в тему:
Тут показано, как абонент из “Home network” поехал в роутиг в “Visiting network”, а ему делает звонок абонент из сети “Interrogating network”. Пунктир - это сигнализация, а сплошные линии - это голосовой канал. Словом “gsmSSF” на этой картинке обзывают SCP :)
CAMEL бывает разный
Самая первая версия протокола CAP позволяла просто совершать звонки, вторая (CAP2) - совершать звонки и пользоваться дополнительными сервисами, связанными со звонками, а третья версия (CAP3) позволяет посылать SMS-ы и пользоваться GPRS-ом в роуминге.
Единственное условие: для того, чтобы CAP-based roaming работал, обе сети - “родная” и “вражеская” должны поддерживать CAP нужной версии или выше.
Литература:
Извините, что все в акронимах и технических подробностях, но по-другому не получится рассказать :)