Что такое LTE

Данная книга, в отличии от предыдущей, нацелена как раз дать ответ на вопрос "Что такое LTE".
Кроме LTE рассматриваются также оба стандарта WiMAX - стационарный и мобильный. Хорошо расскрыты преимущества и недостатки всех технологий, которые приходят на смену 3G. Да и сама технлогия 3G описана очень детально (признаюсь, что пропускал многие моменты, особенно где встречались слова "несущая", "модуляция", "кодирование").

Книга также доступна на Амазоне:


Кстати, рекомендую личный блог автора - WirelessMoves - иногда интересные мысли выкладывает.

Read More..

Evolution of 3G Networks

Эта книга врядли ответит на вопрос "Что такое LTE", но уж точно расскажет о внутренних изменениях устройства мобильных сетей, связанных с эволюцией радио-доступа.
В общем, если есть желание и возможность узнать о сравнительно последних изысканиях 3GPP, но нет желания читать скучную и сухую официальную документацию - эта книга для Вас. Автор не поленился и постарался сделать иллюстрации как можно доступнее, да и текст тоже явно не заумный.

Бумажная версия книги есть на Амазон:

В электронном виде книга частично доступна в Книгах Гугла:

Read More..

IN services

Для чего нужен IN

Эта статья в некоторой мере предисловие к моей предыдущей статье "Основы CAMEL". Здесь я попытаюсь обьяснить зачем нужен IN и что можно с его помощью реализовать.

Основная задача IN это перенос вопросов логики и принятия решений с коммутатора (Service Switching Point в терминологии CAMEL) на внешний узел - SCP (Service Control Point). Благодаря базовой модели вызова, основе CAMEL, есть возможность управлять вызовом на всех его стадиях - установлении, разговоре, разьединении. Т.е. разнообразность услуги и её функционал зависит только от фантазии разработчика.
Ниже я собираюсь описать что уже придумали разработчики и как это работает. Если у Вас есть ещё примеры CAMEL-сервисов - пишите их в поле для комментариев.

1. Prepaid-системы
Пожалуй, самый популярный IN-сервис. Идея состоит в том, что каждый исходящий и входящий вызов абонента должен быть "одобрен" SCP. Благодаря этому есть возможность online-тарификации и ограничения длительности вызова в соответствии с баллансом абонента. Всё это справедливо и для абонентов в роуминге, если гостевая сеть поддерживает CAMEL и обе сети "договорились" о CAMEL-роуминге своих абонентов.
Важное замечание. Наличие CAMEL-подписки ещё не означает, что этот абонент Prepaid. Некоторые операторы в целях борьбы с возможным мошенничеством "подписывают" своих Postpaid абонентов на CAMEL SCP. При этом абонент по-прежнему платит после того, как услуги были оказаны. Т.е. он остается Postpaid, но с технической точки зрения выглядит как Prepaid. Ещё один вариант - у оператора все абоненты с CAMEL-подпиской на тот же SCP. Но часть их них при этом Prepaid, а остальные - Postpaid.

2. RBT-системы. Мелодии вместо КПВ
Этот сервис, наверное, самый близкий к пользователю. Благодаря IN (INAP или CAMEL, не важно) стандартные гудки (КПВ) заменяются мелодией. Правда должен заметить, что есть варианты реализации этого сервиса и на ISUP.
Техническая реализация состоит в установлении временного соединения с IVR (который и проигрывает мелодию) до тех пор, пока не будет получено событие t_Answer (ответ от вызываемого абонента) или событие с ошибкой. В случае получения t_Answer, SCP указывает коммутатору продолжить изначальный вызов.

3. Virtual Private Networks
Услуга, позволяющая организовать аналог мини-АТС на основе сети GSM - со своим номерным планом, ограничениями на звонки, статистикой и прочим. Как пример, посмотрите здесь.

4. Short numbers
Эта услуга широко применяется для роуминг-абонентов. Мало кто из абонентов помнит полный номер, например, Customer Care. Хотя короткий номер помнят хорошо, а очень часто он ещё и занесён в память SIM-карты. Для реализации коротких номеров внутри своей сети можно обойтись и без IN - короткие номера придётся прописывать на всех коммутаторах. Но что делать, если абонент обслуживается коммутатором другой сети? В этом случае короткие номера либо перестают работать, либо соединяют абонента с совсем другими службами.
Для решения этой проблемы можно использовать CAMEL-подписку на SCP, который при получении IntialDP с коротким номером будет отвечать Connect с полным.
Второй вариант реализации услуги это использовать триггер на коммутаторе - все звонки на короткие номера от абонентов-роумеров (абонентов другой сети) отправлять на SCP. Благодаря наличию IMSI в IntialDP, есть возможность точно определить домашнюю сеть абонента (даже если та использует MNP - Mobile Number Portability) и исправить короткий номер на длинный. При этом для домашней сети изменения останутся невидимы - так, как быдто абонент изначально позвонил на полный номер. Естесвенно, что "втихаря" такие услуги не запускают, а координируют запуск услуги с домшней сетью.


5. Called number correction
Ещё одна услуга, которая широко используется при роуминге. Для примера, ещё недавно в Украине для выхода на международную связь использовалось 2 варианта набора номера - через 8-10 и через "+". Кроме того, для междугородней связи и звонков другим абонентам использовался префикс "80". Если абонент сохранял номера у себя в телефонной книге в таком формате, то в домашней сети всё работало. При выезде в другую страну подобные форматы набора номера уже не работали.
Сейчас Украина использует единую с Европой систему набора номеров. Однако, даже это не поможет если номер сохранён в т.н. национальном формате - без кода страны. Если же в гостевой сети присутствует услуга коррекции набранных номеров, то SCP проведёт анализ IMSI, правил набора в домашней сети абонента и, возможно, исправит номер.
Обычно, такая услуга конфигурируется на коммутаторе с помощью триггера EndOfSelection. Этот триггер позволяет задействовать SCP в случае если не подходит ни один из маршрутов в таблице анализа Б-номера.

6. Ещё много-много других сервисов.

Read More..

Основы CAMEL

CAMEL Application Part (CAP) это протокол, используемый для построения интеллектуальных сетей (IN) внутри сетей GSM. На этом месте должна была быть ссылка на Википедию с описанием принципа IN, чтобы не повторяться. Но так уж вышло что там есть только англоязычное описание, да и то несколько скудноватое. Придётся заполнять пробелы.

Intelligent Networks
Предоплаченная связь (Pay as You Go), мелодии вместо гудков (RBT), звонки за счёт вызываемого абонента, бесплатные номера (Toll Free Numbers), виртуальные УАТС – это далеко не полный перечень услуг, которые появились благодаря IN. Что же такое Интеллектуальные Сети и почему нельзя было обойтись без них?
Основная идея IN состоит в том, чтобы коммутатор (MSC) занимался исключительно коммутацией. А описанные выше услуги организуются с помощью сторонних платформ, которые по сети сигнализации «общаются» с коммутатором, указывая ему что делать с вызовом.
При этом вся логика реализуется на отдельном управляющем узле (SCP, Service Control Point), а на коммутаторе описываются только условия, при которых необходимо отправить запрос на адрес SCP – т.н. «триггер». Процесс добавления триггера довольно прост, а все изменения логики происходят вне коммутатора – теоретически на одном узле (практически же, SCP нередко дублируются). Это позволяет сократить время на развёртывание услуг и сделать их очень гибкими.
Итого, мы уже знаем 2 узла IN – SCP и SSP (Service Switching Point). Первый отвечает за логику, а второй за её выполнение. Ещё один достаточно «популярный» узел это IP (Intelligent Peripheral). Он отвечает за воспроизведение различных сервисных сообщений пользователю (например, «У Вас недостаточно средств для совершения звонка»).

Ближе к CAMEL

IN-архитектура изначально разрабатывалась для PSTN. Затем IN Application Part (INAP) плавно перекочевал в мобильную связь. Основной недостаток архитектуры – её закрытость и, как следствие, несовместимость решений разных производителей друг с другом. В итоге, INAP-сервисы могут быть предоставлены только внутри домашней сети. В роуминге абонент их теряет.
Для решения этой проблемы был разработан протокол CAMEL. Благодаря его открытости, оборудование разных производителей может работать между собой без проблем. Т.е. даже в роуминге, в сети другого оператора, есть возможность пользоваться своими «умными» сервисами.

Теория, теория, теория.
Я бы с удовольствием не рассписывал всякие теоретические моменты, которые Вы можете прочесть ниже, но без них понимание CAMEL будет очень ограниченным. В своё время я без труда разбирал трейсы CAMEL-диалогов, не задумываясь почему возникает то или иное сообщение. Со временем захотелось большего. Ниже я постарался расписать минимум, который необходим для понимания что и почему происходит при вызове. Информация, в основном, взята из 23.078 и головы.
Если же Вам лень читать теорию, переходите сразу к практике.


Базовая модель состояния вызова (BCSM, Basic Call State Model)
Для эффективного управления, вызов разбивается на отдельные элементы (состояния):

DP (Detection Point) это своеобразный указатель на текущее состояние. Например, DP2 (Collected Info) указывает на то, что это исходящий вызов в самом начале его обработки. Point In Call - это действия, которые выполняются в этом месте вызова. DP бывают 3-х типов:

1. Trigger Detection Point - Request (TDP-R). Это как раз тот триггер, о котором я уже упоминал. Устанавливается статически (до того как начался вызов), создаёт CAMEL запрос на SCP и ждёт ответа. Обработка звонка при этом приостанавливается.
2. Event Detection Point - Request (EDP-R). Это динамический точка (устанавливается во время вызова по запросу от SCP). Обработка звонка приостанавливается и SSP ждёт инструкций от SCP.
3. Event Detection Point - Notification (EDP-N). Тоже динамическая точка. Отличие в том, что звонок не прерывается (хотя SCP информируется о достижении этой точки, как и в предыдущем случае).

CAMEL-подписки
Для того, чтобы абонент использовал CAMEL-услугу, его надо "подписать" на неё. Сделать это можно в двух местах - на HLR (в профиле абонента) и непосредственно на самом MSC. Второй вариант (Network Service CAMEL Subscription Information, N-CSI) я рассматривать не буду (в виду ограниченности статьи), хотя вещь безусловно интересная.
Что касается варианта размещения подписок в профиле абонента, то здесь остановлюсь на 2х типах:

1. Originating CAMEL Subscription Information (O-CSI)
2. Terminating CAMEL Subscription Information (T CSI)

Первый используется при исходящих звонках от абонента (а также в случае срабатывания переадрессации), второй - для входящих звонков.
Обе подписки содержат в себе такие данные:

1. TDP List - список Detection Point, в которых будет срабатывать триггер.
2. Адрес SCP (gsmSCF address) - фактически Global Title SCP. Пояснение, SCF - Service Control Function - так называется SCP на другом логическом уровне.
3. Service Key - номер, указывающий на определённую логику, которую должен применить SCP.
4. Default Call Handling - что делать со звонком в случае неответа SCP. Варианта два - продолжить или прекратить обработку.
5. DP criteria, CAMEL Capability Handling, CSI state, Notification flag - параметры, которые я не рассматриваю, хотя они и есть.

Модель исходящего вызова (Originating Basic Call State Model, O-BCSM)
Обработка исходящего вызова происходит на Vistor MSC, т.е. на коммутаторе в котором абонент зарегистрирован в данный момент. VLR этого MSC уже содержит копию профиля абонента, а значит и O-CSI (если таковой у абонента имеется). В CAMEL определена такая модель исходящего вызова:

Надеюсь, Вы не закрыли эту страницу и читаете дальше. Если так, то постараюсь обьяснить на пальцах что же такое изображено на рисунке.

1. Вызов начинается с "O_Null & Authorise_Origination_Attempt_Collect_Info". В этом месте (Point In Call) производится проверка запретов (пользовательских и со стороны оператора) на исходящие вызовы и анализ O-CSI.
2. В DP Collected Info у нас уже есть обработанная информация из O-CSI. Если в O-CSI, в поле TDP List содержится DP Collected Info (а для исходящих звонков там может быть только DP Collected_Info и DP Route_Select_Failure), то инициируется запрос в SCP.
3. Далее вызов переходит в состояние "Analyse_Information".  На входе (в DP Collected Info) содержится обработанная информация из O-CSI, потом производится "разбор" вызываемого номера (например определяется его тип -международный/национальный/неопределённый).
4. Предположим, что разбор номера произошёл успешно и вызов переходит в точку DP Analysed_Information. На этом этапе тоже возможен запрос к SCP (хотя детали мне не известны). 
5. Далее происходит переход в состояние "Routing & Alerting". Здесь нам доступна информация о вызываемом номере и его типе (Nature of address - национальный, международный, неопределённый). Происходит непосредственный вызов абонента Б, в телефоне звучит ответ от удалённого коммутатора (КПВ или мелодия сервиса RBT). Исключением является событие Route_Select_Failure с последующим вызовом DP4. Это происходит если на коммутаторе не нашлось подходящего маршрута для установления соединения (в результате т.н. B-number analysis). 
6. Далее будет либо ответ вызываемой стороны (по ISUP мы получим ANM), а значит переход в DP7 O_Answer, либо вызов будет неуспешным по одной из причин - занято (DP5), отсутствие ответа в течении заданного времени (DP6, время задаётся параметром в сообщении Request Report BCSM, но об этом позже), прерывание вызова А-абонентом (DP10).
7. Если ответа не было, то через PIC O_Exception коммутатор освобождает все ресурсы и закрывает CAMEL диалоги. И мы возвращаемся в самое начало.
8. Если вызов успешный и у нас был ответ удалённой стороны, то рано или поздно вызов будет завершен (DP9) и мы снова вернёмся в начало. 

Модель входящего вызова (Terminating Basic Call State Model, T-BCSM)
Перед тем, как начать рассматривать входящие вызовы, я напомню, что мы имеем дело с мобильной сетью. А значит местоположение Б-номера заранее неизвестно. Задача определения текущего MSC вызываемого абонента в классической GSM сети (без CAMEL) была возложена на GMSC домашней сети. С введением CAMEL, именно на GMSC возложили задачу обработки T-CSI (Примечание. Согласно стандарту возможен также CAMEL диалог между VMSC и SCP). Как происходит обработка вызова на GMSC показано на рисунке ниже:

1. Вызов начинается с точки T_Null. Входящий вызов поступает на GMSC для обработки (ISUP IAM). Поскольку GMSC ничего не знает о вызываемом абоненте и его местоположении, то он отправляет MAP SendRoutingInformation на HLR. В ответе на запрос содержится текущий MSC абонента, а также его профиль. Происходит проверка запретов на вызовы, а также анализ CAMEL подписки для входящих вызовов - T-CSI.
2. В DP12 Terminating_Attempt_Authorised у нас уже есть обработанная информация из T-CSI. Если в T-CSI, в поле TDP List содержится DP Terminating_Attempt_Authorised (а для исходящих звонков там может быть только DP Terminating_Attempt_Authorised, DP T_Busy, и DP T_No_Answer), то инициируется запрос в SCP.
3. Вызов переходит в PIC "Terminating Call Handling". В этом PIC осуществляется маршрутизация вызова и информирование Б-номера о поступлении вызова.
4. Далее будет либо ответ вызываемой стороны (по ISUP мы получим ANM), а значит переход в DP15 T_Answer, либо вызов будет неуспешным по одной из причин - занято/абонент недоступен/ошибка установления соединения (DP13), отсутствие ответа в течении заданного времени (DP14), прерывание вызова А-абонентом (DP18).
5. Если ответа не было, то через PIC T_Exception коммутатор освобождает все ресурсы и закрывает CAMEL диалоги. И мы возвращаемся в самое начало.
6. Если вызов успешный и у нас был ответ удалённой стороны, то рано или поздно вызов будет завершен (DP17) и мы снова вернёмся в начало.

Ближе к практике, ближе к SS7

Теперь рассмотрим как вызов выглядит с точки зрения сети SS7. Начнём с исходящего вызова.

1. MSC при обработке исходящего вызова останавливается в DP2, потому что в профиле абонента "активирован" триггер для DP2.
2. SSP (MSC в терминологии CAMEL) инициирует CAMEL-запрос InitialDP на адрес SCP из профиля абонента с просьбой указать, что делать с этим вызовом.
3. SCP анализирует запрос, выполняет внутреннюю логику (например, определяет - есть ли деньги на счету абонента для выполнения вызова) и отвечает сообщением RequestReportBCSM (если есть необходимость "активировать" триггеры), за которым следует одно из сообщений: Continue (продолжить вызов с теми же параметрами), Continue_With_Argument (если несколько параметров в вызове надо изменить) или Connect (внутри этого сообщения содержится новый Б-номер с которым должен быть установлен вызов). Если же вызов не должен быть продолжен, то SCP отвечает сообщением Release.
4. SSP продолжает обработку вызова и если в профиле абонента или в RequestReportBCSM были активированы триггеры, то с помощью сообщения EventReportBCSM SCP информируется о срабатывании DP.

Теперь подробно о каждом из сообщений.
Сообщение InitialDP содержит такие важные поля (подробное описание всех полей в 29.078):

• serviceKey - указатель на определённую логику в SCP. Например, SCP может предоставлять несколько разных услуг. Поле ServiceKey явно указывает какая именно CAMEL-услуга должна быть предоставлена для этого вызова.
• callingPartyNumber - номер вызывающего абонента (A-party number)
• locationNumber - номер MSC с которого происходит вызов
• eventTypeBCSM - описание триггера, который сработал. В нашем случае это DP2 
• locationInformation - текущий VLR абонента и возраст этой информации
• calledPartyBCDNumber - вызываемый номер в BCD формате

Ответное сообщение RequestReportBCSM содержит список триггеров (bcsmEvents), которые необходимо установить в модели звонка. Для этого каждый триггер задаётся следующими параметрами:

• eventTypeBCSM - DP, в котором необходимо активировать триггер
• monitorMode - что делать SSP в случае срабатывания триггера. Варианты такие: interrupted (EDP-R, останов и ожидание инструкции от SCP); notifyAndContinue (EDP-N, просто информирование SCP о наступлении события); transparent (не сообщать о наступлении события).
• legID - указатель на "часть вызова" от которой ожидается получить нотификацию. Вызов условно разделяется на Исходящую (Originating, legID 1) и Входящую (Terminating, legID 2) части. В каждой из этих частей будет, например, своё событие Disconnect. Указатель legID позволяет понять от какой из частей вызова пришло извещение о событии.
• applicationTimer - параметр, который определяет значение таймера No_Answer для события No_Answer (DP6/DP14). Если вызываемый номер не ответил в течении заданного времени, то SSP должен сообщить об этом на SCP. Тут есть один ньюанс, который мне доводилось видеть на практике - значение этого таймера должно быть меньше чем соответствующий таймер неответа на MSC. Иначе вместо события No_Answer можно получить Busy.

Сообщение Continue особого интереса не представляет, поскольку не содержит никаких параметров - SCP просто указывает продолжить вызов.
Continue_With_Argument описано в спецификации, но в реальной жизни я этого сообщения никогда не видел. Поэтому писать о нём не рискну. Если у Вас имеется полезная информация об этом сообщении - милости прошу в комментарии.
CAMEL Connect. Самый главный параметр в этом сообщении это destinationRoutingAddress. Фактически, это новый номер на который должен пойти вызов. Пример, Вы пользователь услуги виртуальной АТС и позвонили на короткий номер Вашего босса - 777. SCP преобразует этот номер в "полный" MSISDN 380671234567 и отправит его в сообщении Connect.
Есть ещё сообщение ConnectToResource, которое очень похоже на Connect, только позволяет совершить соединение с новым номером до соединения с набранным номером. Обычно в качестве нового номера выступает Intelligent Peripheral. Таким образом, например, Вас могут предупредить о том, что средства на счету или срок их действия истекают. После предупреждения вызов будет продолжен.

Если в сообщении RequestReportBCSM были активированы триггеры, то SSP информирует об их срабатывнии с помощью сообщения EventReportBCSM. Это соощение будет содержать тип события (DP), которое произошло, и дополнительную информацию по этому событию. Например, в случае события Busy будет указано точная причина занятости (Subscriber absent, User busy).

Практически всё тоже самое происходит и при входящем вызове. Главным отличием, пожалуй, будет наличие поля calledPartyNumber в IntialDP.

Вот и всё. К сожалению кратко описать CAMEL так и не получилось, но я надеюсь что всё описано достаточно просто и понятно. Как обычно, если есть какие либо вопросы или замечания - используйте форму для комметариев.

Read More..

Want to know more on SS7 - then ask!

I wasn't writing anything in blog for a long time, but since there are still visitors here I'd like to ask you - what kind of SS7/GSM stuff are you interested in? I can't promise that my answer will completely satisfy you, but it's more then possible that I can give you a right direction.
So take your chance - ask by posting a comment.

Read More..

Mobile batteries

Интересная статья о том как развивались источники питания для мобильных устройств - начиная от опытов Гальвани и Вольта, и до современных дней. Читать (на англ) тут - Mobile Phone Batteries: Past, Present and Future.

Read More..

SCCP routing (en)

In one of my previous posts, I was asked to share my knowledge about SCCP routing. This article is my attempt to do that.
First of all, please tale a look on below picture (all SS7 books and articles have it, so I also don’t want to be exclusion):

Now take a look on ISUP. Nice protocol, perfectly working without SCCP (there are some cases, where SCCP is required, but I’ve never seen them). So the question is – why SCCP was developed?
This is because of different tasks. ISUP is designed to establish voice channel between 2 predefined network nodes. These nodes might be inside 1 network (2 MSC), but also in different networks (2 GMSCs of competitive networks). Also this protocol is initially developed to solve only one problem – establish a voice channel. 
But what to do if you don’t know exact location of network nodes and also you need to create request, which has no relation to voice? SCCP was designed exactly for this purpose. 
In order to use SCCP, each node is given an additional address - Global Title (in addition to MTP3 layer address – Point Code). A global title is an address, such as dialed-digits, which does not explicitly contain information that would allow routing in the SS7 network. 
Together with MTP3, SCCP forms third layer of OSI reference model. So it’s like Internet Protocol (IP), which gives the ability to correctly route messages in network. This happens in such a way:

1. Application on Node A sends message to node B. 

2. Node A checks routing table and: 

2.1. Finds the route. Actually, GTT happens (more about GTT is below) – Point Code and Subsystem number (if required) of Node B is determined. This means, that message can be sent using MTP3 routing: Node A puts Point Code of node B into DPC filed (Destination Point Code) and checking for suitable route (SS7 linkset). 

2.2. Doesn’t find “strict” route. If routing table has default route, then message is sent using it (to Node C). It is expected that Node C knows what to do with this message. 

2.3. Doesn’t find any route. Application might be informed about routing error, like “Message type:UDTS, Return cause:No translation for this specific address” 

Options 2.1 and 2.3 aren’t interesting for us, because we’re talking about SCCP routing. So let’s assume that message came to node C.
3. Node C performs the same procedure as Node A did. 3 options available again. There is a reason to discuss option 1, which is GTT. 
Node C got the message and started analysis of SCCP Called Party Address (CdPA). I’m not going to describe whole structure of this address (Internet is full of such details), but some fields should be mentioned: 

• Routing Indicator (as a part of Address Indicator). Points to routing type – GT-based or PC+SSN-based. 

• Translation Type. Usually it’s 0. ITU-T has defined some possible values and how they should be interpreted, but in practice all such values might be used for own routing purpose (check examples below). 

• Numbering Plan (see details in GSM numbering plans article) 

• Address Information. Number itself. 

Node C is starting to analyse received message. RI has “Route on GT” value, because it’s our node is going to perform final translation. TT value can be used to choose destination node. E.g., Node B if TT=0, or Node D if TT=10. 
Routing also might depend on Numbering Plan value. E.g., route all messages with NP=E.214 (like MAP Update Location) to roaming platform, which performs decision allow/disallow subscriber’s registration in particular network. Roaming platform might return the message back to network without any modifications (just OPC and DPC will be swapped). But this means that Node C might again send this message back to roaming platform (since it has routing rule – route all messages with NP=E.214 there). In order to not create loop of messages, roaming platform can set TT value, which differs from 0. Routing table on Node C can be modified to not send messages with TT != 0 to roaming platform even if NP=E.214. Modern STPs can additionally analyze source direction of message (linkset or some internal identifier), so even if TT=0 they won’t send message again to roaming platform. If all previous checks passed, but routing decision wasn’t done, the Address Information filed is analyzed. Node C uses this information to decide that message is for node B with subsystem XX (if subsystem wasn’t mentioned in original message). Point code of node B is already defined, message is sent via corresponding linkset. Routing is dome, GTT performed.

Read More..