Home
dump -0f - /dev/mind
Баечки о мобильной связи (GSM, CDMA) и IT индустрии
GSM: нет верблюда - нету роуминга для pre-paid-а :) 
22nd-Nov-2006 05:57 pm
В предыдущем посте я рассказал об основах функционирования 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 или задавать вопросы прямо тут
Comments 
22nd-Nov-2006 04:23 pm (UTC)
Как страшно жить.
22nd-Nov-2006 07:13 pm (UTC)
Ага. Т.е. палку с техническими деталями я таки перегнул? :)
22nd-Nov-2006 08:51 pm (UTC)
Похоже. Я уже давно запутался в этом трёхбуквенном лесу:)
23rd-Nov-2006 06:44 am (UTC)
Кто бы говорил!

Перечитай свои последние посты про циски :)
22nd-Nov-2006 10:03 pm (UTC)
Адепт, я тебе скоро от своего ИТ буду пивом выставляться.
Очень неплохо удается отсылать читать твой ЖЖурнал заместо проведения ликбезов :)

Впрочем, по VAS-related топикам таки приходится расхлебывать...
23rd-Nov-2006 06:43 am (UTC)
Ха! Ловлю на слове :)
22nd-Nov-2006 10:44 pm (UTC)
Ну, перегнул или не перегнул - вопрос субъективный. Но тут я, пардон, сел на жопу и стал моргать глазами %)
23rd-Nov-2006 06:43 am (UTC)
Надо было papercast делать. В смысле, рисовать ручкой на бумажке и сопровождать голосом :)

В таком режиме оно гораздо легче воспринимается.
22nd-Nov-2006 04:49 pm (UTC)
При прочтении сего у меня встают перед глазами обучающие материалы CBOSS. К счастью, я их давно выкинул :-)
Вот только я, ежли честно, не особо понимаю полезности данной информации для простых людей. Ну т.е. кому надо - они и так по ссылкам давно прочитали. А хлры-влры - это, знаете ли... :)
23rd-Nov-2006 06:42 am (UTC)
Ну, как минимум - если гугл заиндексирует этот пост, то будет что-то на русском про CAMEL :)

Единственная страница, которую я нашел, была в стиле "CAMEL - это круто, но очень сложно. Что это такое, мы не расскажем, зато мы продаем системы, которые поддерживают CAP2" :)
22nd-Nov-2006 05:11 pm (UTC)
во, а расскажи, на чём написан софт обычно, который гоняется для работы всех эти сервисов? У меня просто знакомые писали что-то на java, что обрабатывало какую-то безумную тучу данных (кажется, CDR'ы) из оракловой базы в soft real-time, но как-то сомнительно что java там сильно распространена.

И, собственно, не только про то на чём написано, но и вообще, что за софт, что за (возможно) жутко-специализированные компании его производят, насколько используемые в этой области технологии up-to-date и т.п.
22nd-Nov-2006 10:46 pm (UTC)
Софт какой угодно. Я когда-то CDR'ы на bash'e колбасил. Правда.:)
23rd-Nov-2006 06:49 am (UTC)
CDR-то небось были "plain text, fixed width, CR-delimited" :)

А вот если оно BER-encoded, а ASN.1 спека на него - на 5 листов, то тут уже на баше будет слабо :)
23rd-Nov-2006 11:03 am (UTC)
Ес-но plaintext'ы:)
23rd-Nov-2006 12:56 pm (UTC)
Я колбасил binary АМА на дельфях - диплом у меня такой в институте был. И, IACHASTA, и QOS-TGRP-и т.д. тоже :)
24th-Nov-2006 02:29 pm (UTC)
Нифига себе :)

А BER-декодер для всего этого добра ты тоже на дельфи писал? Герой :)
24th-Nov-2006 03:01 pm (UTC)
Если я правильно понял (исходя из знаний гугла), то BER имеет отношение к криптографии. В нашем случае такого не требовалось.
А вот с описаниями форматов у моих работодателей косяк вышел - не закупили эти документы при покупке коммутатора. Так что пришлось мне некоторое время попрошайничать в инете, пока один добрый человек из Запорожья не соблаговолил отсканить мне куски своей бумажной доки и прислать картиночки. Ну а ж я потом сидел и ковырялся в своих бинарях. До сих пор ему благодарен.
24th-Nov-2006 09:21 pm (UTC)
BER, он же ITU-T X.208, он же близкий родич DER и XER - это способ кодирования в бинарное представление данных, представленых (или описаных) в нотации ASN.1

BER - это пресловутые "сначала длина, потом тэги, потом контент, закодированый опять-таки BER", тот самый способ, которым кодированы данные в AMA, IACHASTA, ...

Соответственно, можно взять описание структуры записей того же EWSD в нотации ASN.1 и при помощи, например, snacc и сгенерировать им C/C++/Java код decoder-ов/encoder-ов записей такой структуры.

В принципе, по EWSD-шной документации описание в синтаксисе ASN.1 восстанавливается достаточно легко.
24th-Nov-2006 09:51 pm (UTC)
А. Ну так тогда да - на дельфях как раз и разбирал всё это барахло. А потом в базу складывал. Ораклом я тогда только начал заниматься, поэтому в рамках диплома записи клались не в оракл. Во что - говорить не буду, ибо стыдно :) Сделаем скидку на далёкий 1999-2000 год. Хотя в те времена уже был 8.0.6...
24th-Nov-2006 09:53 pm (UTC)
Что такое ASN.1 - я тогда не знал. А С/С++ для меня и по сей день темный лес :)
24th-Nov-2006 10:22 pm (UTC)
А С/С++ для меня и по сей день темный лес :)
И слава богу :)
1st-Dec-2006 10:05 pm (UTC)
С/С++ - темный лес as designed
23rd-Nov-2006 06:45 am (UTC)
А вот следующий пост будет про hot billing, там будет и про это тоже.
23rd-Nov-2006 07:46 am (UTC)
1. И на джаве тоже бывает...
2. Нет совершенного биллинга...
23rd-Nov-2006 06:14 am (UTC)
Кстати для разрешения проблем с румингом раньше были ещё страшные dial-around системы, когда исходящие звонки разрешались только после набора предопределённого префикса, плюс номера кредитки, на которую весь разговор и чарджился :)
23rd-Nov-2006 06:44 am (UTC)
пасиб за освежение знаний, а то уже позабывал все :)
p.s. до встречи завтра в поле :->
23rd-Nov-2006 06:47 am (UTC)
Хехе :)

Какая команда? :)
23rd-Nov-2006 06:54 am (UTC)
та, которая смс-ы из колодца шлет быстро-быстро на прямую оргам :)



облом
24th-Nov-2006 02:18 pm (UTC)
о. surprise :) Знакомая рожа в кадре :)

будем знать
23rd-Nov-2006 08:54 am (UTC)
"тот коммутатор, в зоне обслуживания которого регистрируется телефон, определяет по номеру телефона адрес HLR-а и отправляет туда запрос на получение почти всех данных об абоненте"

А вот "почти все" - это какие ?
И заодно - а какие "все" данные об абоненте знает HLR ?
24th-Nov-2006 03:23 pm (UTC)
25th-Nov-2006 03:02 pm (UTC)
Anonymous
Чрезвычайно интересно читать ваш журнал :) Можно попросить как-нибудь рассказать о механизме работы коротких номеров Куда именно, попадает, скажем, SMS, отправленная на короткий номер, и как тарифицируется (в частности, в роуминге)
26th-Nov-2006 01:20 am (UTC)
Так как это уже второй подобный вопрос - будет отдельный пост.
27th-Nov-2006 09:25 am (UTC)
Операторов у которых есть CAMEL3 роуминг очень мало относительно общей массы(штук 100 из ~750-ти возможных. Поэтому роуминг для припейда всеравдо достаточно ограничен(количеством стран возможного посещения).
Все намного интересней когда такой(prepaıd) юзер пытается активировать GPRS;)
27th-Nov-2006 11:29 pm (UTC)
Для звонков в роуминге достаточно CAP2, если не будет CAP3 - будут абоненты в роуминге без SMS-ов/GPRS-а. А вот CAP2-capable операторов уже существенно больше.
20th-Jan-2007 05:18 pm (UTC) - CAP3 for GPRS/SMS
Ну, необязательно...

Можно иметь и то, и другое и без CAP2 даже. В отличии от исходящих звонков и GPRS и SMS идут через домашнюю сеть. И именно поэтому, я думаю, CAP3 так и не приживется.
22nd-Jan-2007 09:10 pm (UTC) - Re: CAP3 for GPRS/SMS
Мнэээ.. Ну, допустим про SMS - можно согласиться. Если SMSC умеет организовать online charging (via RADIUS/DIAMETR)?

Но про GPRS ... Разве в роуминге не будет использоваться гостевой SGSN?
23rd-Jan-2007 06:48 am (UTC) - Re: CAP3 for GPRS/SMS
"Если SMSC умеет организовать online charging (via RADIUS/DIAMETR)?"

Ну, понятно, что его надо "учить" :)


"Разве в роуминге не будет использоваться гостевой SGSN?"

Будет. Гостевой SGSN и домашний GGSN. И его тоже нужно будет "учить" :)

Но если CAP2 нужен, чтобы "зарулить" исходящие звонки через домашнюю сеть, то в случае SMS и GPRS можно заняться решением другой задачи - просто научить их OLC. Что дешевле, чем открывать CAP3 со всеми подряд. Тем более, что CAP3 сейчас у 2% операторов и вряд ли их количество увеличится.
20th-Jan-2007 05:29 pm (UTC)
"При регистрации мобильного телефона в сети тот коммутатор, в зоне обслуживания которого регистрируется телефон, определяет по номеру телефона адрес HLR-а..."

И это говорит главный архитектор :)

Есть мнение, что номер регистрируемого телефона VLR-у знать совсем необязательно. И есть подозрение, что он его таки и не знает.

Аналогично: "Сначала коммутатор (SSP1), который обслуживает звонок[1] абонента A, найдет по номеру B тот HLR, в котором живут данные B, и спросит этот HLR о том, в каком VLR-е сейчас "прописан" B[2]".

Что-то я не уверен, что коммутатору абона A надо искать HLR абона B :) Заметим, что во многих случаях у абона B вообще нет никакого HLR.

Что-то ты людям голову задурил :)
22nd-Jan-2007 03:37 pm (UTC)
С первым согласен. Sloppy writing - должно быть IMSI вместо MSISDN. Fixed.

А со вторым - ты таки неправ. Во-первых, текст иллюстрирует конкретную картинку, а не все возможные случаи (в т.ч. когда B-party у нас в PSTN или в других местах, где HLR-ы не ростут). А во-вторых - таки MSC зоны обслуживания A-party нужен HLR, в котором живет B-party, чтобы узнать оттуда адрес VLR-а, в зоне которого проживает (camping) абонент В.

Впрочем, я почти такими словами это и описал.
11th-Jan-2008 10:20 am (UTC) - конечно всё это здорово
и вообще интересно почитать, но сразу возникает простой вопрос из трёх (не букв) а слов

ОТКУДА ТАКИЕ СЛОЖНОСТИ?

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

Телефонисты что, не могли нанять грамотных челов для разработки системы?
11th-Jan-2008 10:38 am (UTC) - Re: конечно всё это здорово
В tcp/ip есть провода. Точка.

Про то, как пытаются сделать глобальный tcp/ip без проводов - можно наблюдать сейчас в реальном времени.
11th-Jan-2008 11:56 am (UTC) - Re: конечно всё это здорово
тсп/айпи абсолютно плевать какова транспортная физическая среда )

11th-Jan-2008 06:41 pm (UTC) - Re: конечно всё это здорово
Но если рассматривать картину в целом, то на затраты на поддержание этой среды нельзя просто закрыть глаза.

Ладно, забудем про среду. Если уж мы говорим про tcp/ip, уместней была бы аналогия с клиентом, у которого ноутбук, но в мир он выходит _всегда_ через vpn на свой конторский сервер. Картина сразу становится менее простой и менее радужной, ага?
12th-Jan-2008 12:03 am (UTC) - Согласен
но всё ж к счастью в реале большинство выходит через прова (а кое кто и не через одного) :)

Касательно затрат на инетские провода и пр инфру, даже не будучи специалистом можно сказать, что они весьма умеренные. Т.к. плата за инет копейки, ну даже если это и не копейки, в любом случае не сравнить с платой за мобилку.

Ну точнее будет сказать так: если бы я пользовал сот связь так же активно, как "проводной интернет", то расходы на неё были бы много выше, чем расходы на т.н. "проводной интернет".
12th-Feb-2009 11:00 am (UTC) - Re: конечно всё это здорово
а вот на перемещение конкретной айпишки по сетям ему не плевать :)

14th-Feb-2009 11:47 am (UTC) - Re: конечно всё это здорово
И что с того? роутинг никто не отменял естессно...
This page was loaded Jul 12th 2009, 10:06 am GMT.