All about GSM

Что такое LTE

2010-03-08T13:36:00.001+02:00

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

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

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

Evolution of 3G Networks

2010-03-08T13:17:00.001+02:00

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

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

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

IN services

2010-03-01T17:36:00.000+02:00

Для чего нужен 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. Ещё много-много других сервисов.

Основы CAMEL

2010-02-25T15:32:00.006+02:00

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-х типов:

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

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

Originating CAMEL Subscription Information (O-CSI)
Terminating CAMEL Subscription Information (T CSI)

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

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

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

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

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

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

Вызов начинается с точки T_Null. Входящий вызов поступает на GMSC для обработки (ISUP IAM). Поскольку GMSC ничего не знает о вызываемом абоненте и его местоположении, то он отправляет MAP SendRoutingInformation на HLR. В ответе на запрос содержится текущий MSC абонента, а также его профиль. Происходит проверка запретов на вызовы, а также анализ CAMEL подписки для входящих вызовов - T-CSI.
В 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.
Вызов переходит в PIC "Terminating Call Handling". В этом PIC осуществляется маршрутизация вызова и информирование Б-номера о поступлении вызова.
Далее будет либо ответ вызываемой стороны (по ISUP мы получим ANM), а значит переход в DP15 T_Answer, либо вызов будет неуспешным по одной из причин - занято/абонент недоступен/ошибка установления соединения (DP13), отсутствие ответа в течении заданного времени (DP14), прерывание вызова А-абонентом (DP18).
Если ответа не было, то через PIC T_Exception коммутатор освобождает все ресурсы и закрывает CAMEL диалоги. И мы возвращаемся в самое начало.
Если вызов успешный и у нас был ответ удалённой стороны, то рано или поздно вызов будет завершен (DP17) и мы снова вернёмся в начало.

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

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

MSC при обработке исходящего вызова останавливается в DP2, потому что в профиле абонента "активирован" триггер для DP2.
SSP (MSC в терминологии CAMEL) инициирует CAMEL-запрос InitialDP на адрес SCP из профиля абонента с просьбой указать, что делать с этим вызовом.
SCP анализирует запрос, выполняет внутреннюю логику (например, определяет - есть ли деньги на счету абонента для выполнения вызова) и отвечает сообщением RequestReportBCSM (если есть необходимость "активировать" триггеры), за которым следует одно из сообщений: Continue (продолжить вызов с теми же параметрами), Continue_With_Argument (если несколько параметров в вызове надо изменить) или Connect (внутри этого сообщения содержится новый Б-номер с которым должен быть установлен вызов). Если же вызов не должен быть продолжен, то SCP отвечает сообщением Release.
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 так и не получилось, но я надеюсь что всё описано достаточно просто и понятно. Как обычно, если есть какие либо вопросы или замечания - используйте форму для комметариев.

Want to know more on SS7 - then ask!

2010-02-17T22:07:00.002+02:00

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.

Mobile batteries

2010-01-27T00:10:00.000+02:00

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

SCCP routing (en)

2010-01-05T12:49:00.003+02:00

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.

Hitler and LTE

2009-12-23T11:25:00.000+02:00

Просто не мог не поделиться с Вами приколом о Гитлере и LTE. В шутливой форме рассказывается о текущих недостатках LTE - отсутствии поддержки голоса и смс. Конечно, всё это есть в IMS, но и этот момент удачно обыгран. В общем, что рассказывать - смотрите:

Deployment engineer vacancy

2009-12-10T22:31:00.003+02:00

GlobalLogic Ukraine is looking for Deployment engineer of telecommunication software to work on the full time basis in Kiev office and travel to the customers (mobile operators) in Eastern Europe and post-Soviet countries.

Successful candidates should meet the following requirements:

* Unix administration experience (Solaris, HP-UX)

* Shell scripting (bash) and basic perl scripting

* Oracle experience (databases creation/import/export, SQL queries, etc)

Considered as a strong plus:

* Telecommunication experience (SS7 protocols - MAP, CAMEL)

We offer:

* comfortable office facilities packed with features and happy people

* excellent "white" compensation package, performance bonus program

* sports (soccer, yoga, swimming, gym), medical insurance (after 1st year)

The client is Roamware, global leader in voice and data roaming solutions, whose voice and data roaming solutions are installed in over 400 mobile operators' networks across 146 countries.

Apply now by sending your full CV at jobs@mib.net.ua.

Orange the Best

2009-11-28T11:48:00.002+02:00

На ежегодном World Communication Awards (WCA), который проходил в Лондоне в эту среду (25.11.2009), Orange получил три самые высокие награды в мире телекоммуникаций. Четвёртный год подряд Orange Business Services награждается званием "Best Global Operator" и в третий раз компания отмечена как "Best Mobile Service Provider".

Также совместно с Sorin Group (международная компания по производству медицинского оборудования, лидер в области лечения сердечно-сосудистых заболеваний), Orange Business Services получил награду "Best Change-Maker" за их совместную работу по внедрению M2M и технологии электронного здоровья (e-Health) с целью улучшить качество жизни т.н. сердечников.

"В течении этого года, Orange Business Services представила рынку целую серию внушительных проектов, поэтому их победа полностью заслужена. Жюри оценила последовательную стратегию, которая в результате предложила рынку достаточно сильные сервисы в хорошо управляемой комерческой среде", - отметил David Molony, председатель WCA.

Уже 11 лет World Communication Awards награждает компании, отмечая тем самым их значительные достижения и разработки в международной телеком индустрии.

Barbara Dalibard, президент и исполнительный директор Orange Business Services, так прокоментировала награду:

"В первую очередь, это победа всех наших сотрудников, которые каждый день обслуживают клиентов с неиссякаемым энтузиазмом и помогают нам придерживаться нашего курса. Нам видится светлое будущее, поскольку мы расширяем наше портфолио в таких областях как видеоконференции, контак-центры, М2М приложения и распределённое вычисление".

Что ж, остаётся поздравить Orange и пожелать им оставаться "двигателями" прогресса на телеком рынке.

SCCP routing

2009-11-26T01:07:00.009+02:00

Итак, обещанная статья об SCCP маршрутизации. Сразу предупреждаю - писалась в небольшой, но спешке, да ещё и после лёгкой, но болезни.

Для начала небольшая картинка (все книги и статьи по SS7 обязательно её вставляют, не буду отходить от традиции и я):

А теперь посмотрим на ISUP. Хороший протокол, отлично работает без SCCP (есть какие-то варианты работы поверх SCCP, но я их не встречал). Зачем же было тогда придумывать SCCP?
А всё дело в задачах. ISUP предназначен для установления голосового канала между двумя заранее определёнными узлами сети. Эти узлы могут быть как внутри одной сети (2 MSC), так и в двух разных сетях (2 GMSC операторов-конкурентов). Кроме того, протокол изначально ориентирован на одну задачу - установить голосовой канал.
Что же делать, если узлы находятся непонятно где и необходимо сделать запрос, который к голосу не имеет никакого отношения? Вот для таких задач и придумали SCCP.
Для использования SCCP, каждому узлу кроме адреса на уровне MTP3 (Point Code, который), назначается ещё и т.н. Global Title (GT). GT - это адрес, например, набранный абонентом номер, который не обязательно явно содержит информацию, позволяющую маршрутизировать сообщение в сети SS7.
Вместе с MTP3, SCCP образует третий уровень эталонной модели взаимодействия открытых систем (OSI RM). Т.е. как и протокол IP, обеспечивает функции по маршрутизации сообщений в сети. Происходит это примерно так:

1. Приложение на узле A отправляет сообщение узлу B.
2. Узел А проверяет свою таблицу маршрутов и:

2.1. находит его. Фактически происходит GTT (об этом ниже) - определяется Point Code для узла B и номер подсистемы (если необходимо). Это значит, что сообщение может быть отправлено с использованием MTP3-маршрутизации: узел А ставит Point Code узла B в DPC и ищет подходящий маршрут (linkset).

2.2. не находит "прямого" маршрута. Если задан маршрут по-умолчанию, то сообщение отправляется на указанный в нём Point Code (Узел C). Ожидается, что узел C знает, что делать с сообщением.

2.3. не находит вообще никакого маршрута. Приложению может быть отправлена ошибка - Message type:UDTS, Return cause:No translation for this specific address.

Пункты 2.1 и 2.3 нас особо не интересуют, поскольку мы рассматриваем случаи SCCP маршрутизации. Поэтому считаем, что сообщение поступило на узел C.

3. Узел С проводит аналогичную процедуру, что и узел А. И снова возможны 3 варианта. Есть смысл рассматривать вариант 1, тот который GTT. Его и рассмотрим.

Итак, узел С получил сообщение и проанализировал SCCP Called Party Address (CdPA). Из чего состоит этот адрес описывать не буду (в Интернет достаточно информации по этому поводу). Выделю только ключевые для этой статьи поля:

Routing Indicator (в составе Address Indicator). Указывает на тип маршрутизации - по GT или PC+SSN.
Translation Type. Обычно это значение 0. ITU-T определило некоторые возможные значения и как их следует интерпретировать. На практике, эти значения можно использовать под свои нужды (об этом в примере).
Numbering Plan (детальнее смотрите на GSM numbering plans)
Address Information. Непосредственно номер.

Узел С начинает анализ сообщения. RI у нас точно указывает на Route on GT, потому что это мы собираемся делать окончательную трансляцию. В зависимости от значения поля TT, можно выбрать узел получателя сообщения. Например, если ТТ=0, отправить на узел B, а если ТТ=10, то отправить на узел D.
В зависмости от Numbering Plan маршрутитизация также может быть разной. Например, отправлять все сообщения с NP E.214 (такие как MAP Update Location) на роуминг-платформу для принятия решения (пускать абонента в эту сеть или нет). Роуминг платформа после обработки может вернуть сообщение обратно без каких-либо изменений (ну, только OPC и DPC поменяет местами). А чтобы узел C снова не отправил сообщение на роуминг-платформу, то она при отправке установит значение TT отличным от 0. Таким образом можно избежать петель маршрутизации. Хотя сравнительно новые STP могут дополнительно анализировать с какого направления (linkset или свой внутренний указатель) пришло сообщение, поэтому второй раз его на роуминг-платформу не отправят даже если ТТ=0.
Если все предыдущие проверки пройдены, но получатель так и не определён, то осталось поле Address Information. По нему узел C и определяет, что это сообщение для узла B и его подсистемы такой-то (это в случае, если подсистема не была указана в оригинальном сообщении в поле SSN). Point code узла B известен, сообщение отправляется через соответствующий linkset. Дело сделано, GTT осуществлёна.

Теперь немного о классах SCCP:

Class 0- Basic connectionless class
Class 1- In-sequence delivery connectionless class
Class 2- Basic connection-oriented class
Class 3- Flow control connection-oriented class

Не имел возможности работать с Class 2 и 3, потому что TCAP (а следовательно MAP, CAMEL, INAP) их не используют. Литература гласит, что Class 3 пока-что вообще не используется, а Class 2 используется для "Some BSSMAP messages (Setup)", с которым тоже не имел чести работать.
Что касается отличий Class 0 и Class 1, то тут могу рассказать. Для увеличения надёжности сети, её ключевые элементы, такие как STP, дублируют. Дублируются также и подключения узлов к сети - узлы подключаются к двум STP одновременно. При этом стараются распределить нагрузку между STP равномерно. Это значит, что узел А, отправляя сообщения, часть их отправляет через STP1, а часть через STP2. Иногда бывает так, что на запрос нужно ответить двумя, а то и тремя сообщениями. Если очередность доставки не важна (а это Class 0), то можно смело разбрасывать сообщения между STP. Но если получателю важен порядок сообщений (например, мы отправили TCAP Continue и TCAP End. Очень важно сохранить очередность), то используется Class 1 и все сообщения из цепочки будут отправлены через один и тот же linkset (читай STP), да ещё и через тот же линк (SLS).
Могу подтвердить, что это важная вещь. На практике встречал ситуации, когда 2 сообщения отправленные с интервалом в 10 мс через разные STP, приходили в неправильном порядке и в итоге "ничего не рапотает, насяльника". Картину прояснил только трейс снятый на конечной точке маршрута - коммутаторе. Почему второй STP доставлял сообщение до коммутатора быстрее осталось загадкой.

Настройка Wireshark для SS7

2009-11-22T00:08:00.009+02:00

Давно я не писал чего-то общественно полезного. Пылится "на полке" запрос написать о GTT и прочей SCCP магии. А пока-что расскажу о том, как можно упростить свою жизнь с помощью простой настройки Wireshark.

Не вдаваясь в историю и детали, скажу просто - Wireshark это свободнораспространяемый анализатор пакетов. Долгое время его прародитель (Ethereal) использовался сетевыми (и не только) администраторами для анализа TCP/IP. Постепенно к нему добавляли поддержку множества других сетевых протоколов, в том числе и протокол сигнализации ОКС-7.

Вообще, весь этот блог начинался с идеи рассказать о том, как использовать Wireshark для "просмотра" SS7 трафика, проходящего через стек Dialogic. Статья об этом - декодер Septel. Со временем всё больше и больше проектов реализовывались на SigTRAN. И снова помощник тот же - Wireshark. Включил snoop (снифер в Solaris), скачал файл, открыл его в Wireshark и сразу понял, почему ничего не работает. Ну, или не сразу. Ладно, признаюсь - иногда даже это не помогает :)

Но я отвлёкся. Почему-то оказалось, что Wireshark требует некой начальной настройки для нормальной работы с SS7. О них и статья.

1. Настройка SSN для GSM MAP.

Если вместо прелестных смс-ок ни о чём не подозревающих абонентов, Вы видите кашу в 16-тиричном виде, то значит Wireshark не распознал GSM MAP. Для устранения досадной неприятности заходите в Edit->Preferences. Нажимайте на Protocols и ищите GSM_MAP. Далее заменяйте "6-9" на "6,7,8,9" так, как это показано на рисунке:

2. Настройка CAMEL

Аналогичным образом следует настроить Wireshark для протокола CAMEL. Выбирайте его в списке протоколов (надеюсь Вы уже догадались, что можно набрать имя протокола и он выберется?) и ставьте значение 146. Я остальные поля не трогаю и всё работает:

3. Настройка отображения пакетов в Wireshark

Это достаточно спорный вопрос, но я постараюсь обьяснить почему мой вариант мне нравится больше остальных. Снова заходим в Edit->Preferences. И теперь выбираем Layout:

Почему именно третий вариант? Потому что:

в окне 1 я вижу пакеты в порядке их прихода (в этом месте слышен хи-хи)
в окне 2 я "разворачиваю" пакет по протоколам, чтобы рассмотреть что там и как
в окне 3 (которое я делаю узким) спокойно читаем текст смс-ок (попались?! так и знал - ничего путнего, кроме чтения чужих смс Вы на работе не делаете)

Итого, картина выглядит примерно вот так:

Скажете неудобно? Форма для комментариев ниже :)
4. Раскраска пакетов по протоколам.
Когда в первом окне список из тысячи пакетов, найти проблему бывает трудно и утомительно. Чтобы упростить себе жизнь, можно воспользоваться чудесной функцией раскраски пакетов. Она позволяет сделать раскраску на основе фильтров Wireshark. Читать документацию и придумывать фильтры не обязательно - в окне 2 нажимаете на нужную часть пакета (например, GSM Mobile Application), а в левом нижнем углу читаете фильтр - gsm_map:

Когда фильтр в ваших руках, спокойно идёте в View->Coloring Rules и нажимаете New. Дальше и сами разберётесь. Что хотелось бы добавить - не забудьте создать такой вот фильтр и окрасьте его в ярко красный цвет: tcap.abort. Очень полезный фильтр. Ещё не помешал бы фильтр для UDTS, но что-то я его в своей конфигурации не наблюдаю.
На этом пока-что всё. Если у кого есть полезные фильтры - пишите в комментарии.

LTE - мифы и реальность

2009-11-04T20:47:00.003+02:00

В сети бродит множество мифов о том, что такое LTE и какие недостатки у этой технлогии. Организация 3GPP, которая активно занимается стандартизацией LTE, решила развеять часть из мифов.

Миф 1: LTE только для передачи данных
Реальность: LTE поддерживает передачу голоса и эта поддержка была среди ключевых задач при проектировании. Голос в сетях LTE передаётся благодаря IMS VoIP, которое имеет чёткую спецификацию.
Решение 3GPP для передачи голоса поверх LTE это обьединенная работа по нескольким направлениям:

Работы в Rel 7 по оптимизации сигнализации в IMS и кодеков VoIP таким образом, чтобы качество и эффективность передачи было таким же или лучше чем в сетях с коммутацией каналов
Работы в Rel 8 по разработке новых поколений радио и опорной сети, оптимизированных для передачи пакетных данных
Работы в Rel 7 по добавлению требований к экстренным вызовам в IMS и адаптации их к законодательству.
Работы в Rel 8 по добавлению к LTE требований постоянного подключения по IP.

Ключевой момент здесь это то, что для LTE голос это всего лишь один из многих потенциальных медийных потоков, который может быть передан. Это становится возможным благодаря сетям с коммутацией пакетов и технологии VoIP, которые эффективно используют радио и сетевые ресурсы.
Тем не менее, 3GPP понимает что адаптация LTE и IMS не може произойти за одну ночь. Для этого 3GPP предлагает переходной механизм, называемый "CS Fallback". Он позволит устройству LTE подключится к традиционной сети 3G или 2G, если в IMS нет требуемой поддержки VoIP. Этот механизм является промежуточным решением для упрощения перехода на IMS и VoIP.

Миф 2: В LTE нет поддержки SMS

Реальность: LTE и EPS (Evolved Packet System) будут поддерживать большое множество технологий передачи сообщений, SMS также поддерживается в LTE. Двойственное решение позволит обеспечить передачу SMS как в сетях с полноценным IMS, так и в сетях без поддержки IMS.

SMS поверх IP было полностью специфицировано в 3GPP Rel 7. Базируясь на IMS, это решение главным образом направлено на обеспечение совместимости между традиционными сотовыми сетями и сетями, которые предлагают более широкие возможности в обменене сообщениями.

Для сетей без IMS было специфицировано переходное решение, называемое SMS over SGs (ранее называемое SMS over CS). Это гибридное решение, которое позволяет передавать SMS из инфрастуктуры с коммутацией каналов по радио сети LTE. SMS over SGs было определено как часть Rel 8. Т.к. это решение требует наличия инфрастуктуры с коммутацией каналов для передачи SMS, то оно рассматривается как переходное.

Миф 3: IMS ещё не готово к использованию

Реальность: Разработка IMS ведётся уже долгое время. Впервые эта система была представлена как часть Rel 5 в 2002 году. Она основана на протоколах IETF, таких как SIP и SDP, которые уже известны давно. Эти технологии были избраны индустрией как сигнальные механизмы для мультимедийных приложений.

В Rel 7 основной упор был сделан на оптимизацию IMS и сопутствующих протоколов для того, чтобы сделать поддержку голоса и других носителей такой же эффективной как и в сетях с коммутацией каналов.
IMS полностью описан и готов к использованию. Проблемы в разворачивании IMS не из-за протоколов или спецификаций. Ведь рассматриваются не только технические аспекты, но и смена взглядов во всей индустрии - отказ от коммутации каналов и полный переход на IP. А это миграция сервисов, политик и взаемодействие с традиционными сетями. Однако все это стоит того, чтобы предоставить пользователям широкий спектр сервисов. Эта работа происходит во многих сообществах, за пределами 3GPP.

Миф 4: LTE не поддерживает экстренные вызовы

Реальность: Поддержка экстренных вызовов в VoIP (в т.ч. поддержка определения местоположения) указана как часть Rel 9. Она полностью удовлетворяет последним требованиям, что позволяет отделить VoIP от сетей с коммутацией каналов. Также есть переходной механизм, позволяющий перейти в сеть 3G/2G для совершения экстренного вызова. Такое решение было предложено до появления IMS (Rel 5).

Тем не менее, для решения ситуаций где обратно-совместимые сети недоступны, и был предложен Rel 9. Это позволяет оператору обеспечить выполнение требований LTE для VoIP звонков как для телефонов, которые могут зарегистрироваться для обычных сервисов, так и для устройств с ограниченным набором сервисов (в т.ч. устройства без USIM).
Описан также обратный звонок из PSAP (public safety answering point) и его взаимодействие с дополнительными сервисами, которые могут быть активированы.

Традиционная услуга	Переходное решение	Решение EPS
Коммутация голоса	CS Fallback (Rel 8)	IMS VoIP (Rel 7)
SMS	SMS over SGs (used to be called SMS over CS) (Rel 8)	SMS over IP (Rel 7)
Дополнительные сервисы	CS Fallback (Rel 8)	Multimedia Telephony (Rel 7)
Экстранные вызовы с Пооддержкой определения местоположения	CS Emergency Calls (Rel 5)	IMS Emergency Calls w Location Support (Rel 9)

The Future of 4G: A Reality Check

2009-10-28T16:21:00.026+02:00

The Future of 4G is an interactive virtual event. You can access the event from your desk, home office, cubicle—it's up to you. The Future of 4G is accessible anywhere there's a working Internet connection and phone line.
The Future of 4G offers all of the benefits of a live event...without the hassle of having to travel. You don't even need to leave your office.

And did I mention it's FREE?

Just have a look on below screenshots to understand that it's new generation of telco events:

Don't miss a chance to at least have a look on this. Register now!

IPv6 ready

2009-10-15T10:34:00.004+03:00

Are you ready? Are you IPv6 ready? Or didn't ever hear about it? If so, then I don't understand how you found my blog :)
Just few weeks ago I wrote an article how to disable IPv6. Since that time I realized that IPv6 is closer then I was thinking about it. I even decided to start new blog - IPv6 in Ukrainian, which contains a lot of information about IPv6, it's history, advantages, transition mechanism, etc. And all this information in Ukrainian. You may say - "so what? all this information is available in English. Why to translate it?". I'm agree with you. Also, reading technical articles, books and other materials is a good way to improve English (at least reading and writing skills). But at the same time, there is a problem with huge amount of this information. And this problem becomes tragedy if have to use English/Russian dictionary to read any document. This means that you can't read first part of the document and decide whether to continue reading or not. All this result in hours and hours of useless reading. Trust me - I know how it's to read hundreds of RFCs, books, articles about IPv6 and then put this information in one document.

So I hope my new blog will help IPv6-beginners to make first step into interesting world of Next Generation Internet. Step, that will move forward Ukraine into international community of IPv6 designers and programmers.

BTW, I'd like to recommend you IPv6 certification program. It requires working IPv6 connection. But you're IPv6-ready, aren't you?

Disable IPv6

2009-09-26T17:17:00.015+03:00

Short preface. In May 2005, I successfully graduated Kyiv Politechnical Institute with master degree work "Transition mechanism for IPv6 protocol". The main idea there was to start transition from small networks by assigning routable (in future) IPv6 addresses to these networks. After some time, these networks would create more and more pressure on their ISP to enable IPv6 routing between them. Later this would bring big telcos to enable IPv6 on main routers. The way from small networks to big group of interconnected networks – the way to Internet II.

And what do we have now, after 17 years of developing? All we have is 1,690,000 pages, cached by Google with keyword disable ipv6.
And I'm not joking... Of course, number of articles, posts and forum threads with enable IPv6 is 2 times higher. But why so many people are trying to disable Next Generation Internet Protocol? Why to disable protocol, which was designed to make networks bigger, simpler, more reliable and faster (here I mean enhanced routing capabilities of IPv6 protocol - hierarchical address space, which allows to make routing decisions more quickly)? The answer is simple and complicated at the same time. Regular users disable IPv6, because modern software trying to use it in wrong way. Why this happens?
Let’s see. Most of the computers, connected to Internet, are connected to IPv4 part of Internet only. But at the same time, it might be that Operating Systems (OS) of their computers already support IPv6 (and all modern ones do support IPv6). It's not a problem till that time you're trying to make any network connection. Of course, it’s stupid be connected to Internet and not use it. So you’re starting to type www.mib.net.ua in web browser, checking for new emails in your favourite Email client, etc. What happens then? Name resolving – application (browser, Email client) sends request to OS in order to get IP address of desired hostname. Remember, we have OS with IPv4/IPv6 support, so resolver libraries (part of OS, responsible for interaction with DNS servers) requesting IPv4 and IPv6 addresses. Imagine, that DNS returned 2 addresses, like on image below:

What then? Then we may read RFC2893:
DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling both A6/AAAA and A records. However, when a query locates an A6/AAAA record holding an IPv6 address, and an A record holding an IPv4 address, the resolver library MAY filter or order the results returned to the application in order to influence the version of IP packets used to communicate with that node.
…
If it returns both addresses, the application will have the choice which address to use, and thus which IP protocol to employ.
If it returns both, the resolver MAY elect to order the addresses - IPv6 first, or IPv4 first. Since most applications try the addresses in the order they are returned by the resolver, this can affect the IP version "preference" of applications.

Check image above again. As you can see there, this is FreeBSD and it returns IPv4 address followed by IPv6. So application running on FreeBSD will first try to connect using IPv4 address. Usually, this connection will be successful. But if OS returns IPv6 address first, then application will try to connect using it. Since we’re not connected to IPv6 network, connection will fail. But anyway some time will be lost. For user this means slower speed of application. And this speed can be increased by… disabling IPv6. Yes, this is true. If you disable IPv6 on OS level, it won’t request IPv6 address of hostname via DNS. No IPv6 address – no connection attempt via IPv6 network – no loss of time – no speed loss. Yes, so simple and so sad.
More complicated way is to develop software more carefully. It's possible to add IPv6 settings in Configuration menu and allow user to decide - how application should behave if IPv4 and IPv6 addresses returned by resolver. This is done in some applications, like Mozilla, already. Hope that soon this becomes de-facto for all software.

Make Internet smarter - leave a comment :)

Indoor LTE

2009-09-23T00:15:00.004+03:00

NSN claims that they did industry’s first indoor implementation of LTE. This was done by NSN in cooperation with China Mobile Communications Corporation (China Mobile).

The idea was to show how to create excellent indoor coverage for future mobile broadband by using LTE. LTE base station in this case can be truly called Femtocell. This coverage will be widely used by subscribers in future, because "the majority of mobile broadband capacity will be consumed inside homes and offices where coverage is typically lower than outdoor spaces,” said Huang Xiaoqing, General Manager of China Mobile Research Institute.
Research team of Nokia Siemens Networks’ Beijing have demonstrated a live streaming video downlink application using a compact experimental Femtocell prototype in China Mobile’s Research Institute laboratory. The demonstration achieved throughputs which exceed the typical xDSL speed currently possible via residential broadband connections.
The main question, that I have here - which technology to use as IP backhaul for such Femtocells? The main purpose of outdoor LTE is to bring new range of access speeds to customers - speeds that can't be achieved by any of cable technologies at the moment. Plus you're getting mobility - the ability to move where you want and when you want. In case of Femtocell you'll get good coverage inside buildings, but not the speed of LTE (which is main advantage of new technology, as for me), because cell will give the speed of backhaul connection and nothing more.
Also, I suspect that for a long time we're going to have handsets (and other types of access devices) with support of both technologies - 3G and LTE. 3G Femtocells are already available and ready to become very popular in next few years (at the moment vendors, like Ubiquisys, are preparing for upsurge in Femto market). So it looks like this demo is only to show for other vendors and potential customers - "see, we did first LTE Femtocell". My congratulations to NSN - this is great, but it will take years for us to understand the great value of this moment.

You can read official press-release here.

About Nokia Siemens Networks
Nokia Siemens Networks is a leading global enabler of telecommunications services. With its focus on innovation and sustainability, the company provides a complete portfolio of mobile, fixed and converged network technology, as well as professional services including consultancy and systems integration, deployment, maintenance and managed services. It is one of the largest telecommunications hardware, software and professional services companies in the world. Operating in 150 countries, its headquarters are in Espoo, Finland.

New dialing rules in Ukraine

2009-09-19T16:13:00.010+03:00

Ukraine is about to change dialing rules for mobile and fixed networks. Such activity is step 2 in "Program of transition to next-generation numbering plan" (text in Ukrainian is available here)

At the first step, which was done during 3-18 of February 2009, emergency short numbers were changed. Numbers like 01, 02, 03, 04 were used for emergency services in Soviet union and later in independent Ukraine. On February 2009 they were replaced with 101, 102, 103, 104 and so on. This was done in order not to have "0" as first digit in any number.
Next step, which is planned on 14th of October 00:00 by Kyiv (Kiev) time (EEST, GMT+2), contains several tasks, explained below:

1. Changing format of national destination zones from 0XX to XX. Actually, this is formal task, because 0XX codes were used only by humans and not by equipment. Here I should explain further. Soviet union's fixed network used 3 digits codes. International numbers in this case were like +7XXX. Hopefully, all Ukrainian zones got their codes with heading 0 - like 0XX. After Ukraine became independent and got it's own country code (CC) - 380, it was decided to keep first digit of zone code as last digit of country code. For example, international code of Kyiv is 38044, where 380 is country code and 44 national destination code (NDC). But for a long time people treated 044 as NDC of Kyiv. The same was with others cities. So formally all zones already have only 2 digits, but in human's habit 3 digits were used.
Here I suppose, that probably some network elements are using 3 digits also. But as I explained already, formally this was wrong.

2. Changing national dialing prefix from "8" to "0".
Again, some explanation is required here. Since people used to treat zone code as 3 digits (0XX), national dialing prefix was "8". But as I explained before, all zones had 2 digits (XX), so formally prefix was "80".
To understand this, please review an example. Imagine that you want to dial Kyiv's number YYY-YY-YY from another city. For this you had to dial "8" as national dialing prefix, then NDC of Kyiv (which is formally 44, but people continued to use 044) and then subscriber's number. So whole dial looks like:
8-044-YYY-YY-YY
Since correct NDC of Kyiv was (and continue to be) "44", national dialing prefix formally was "80":
80-44-YYY-YY-YY

So actually, on this step national dialing prefix changing from "80" to "0".

3. Changing international dialing prefix from "10" to "00".
Previously, in order to call abroad, "8-10" prefix was used, where "8" - national dialing prefix.

4. Implementing of new zone code for Kyiv's region - "45".
At the moment Kyiv city and Kyiv region are using the same zone code - "44". On second step of transition, Kyiv's region will get it's own zone code. This means that all region's codes should be changed also.

About the country.
Ukraine is a country in Eastern Europe with population of 46.2 millions of people. Fixed phone service is mainly offered by state-owned company - Ukrtelecom, which also has 3G UMTS license and offers mobile services using Utel trademark. Mobile networks are mostly 2.5G, but 3G UMTS and WCDMA are also present.

MiFi от 3 UK

2009-09-03T11:45:00.013+03:00

Mobile WiFi (MiFi), так называется новый сервис от британского оператора 3. Насколько нова услуга и что она из себя представляет, я попытаюсь раскрыть в этой статье.

С 17 Сентября онлайн и с 18 Сентября в 3х магазинах, британский оператор "3" начинает продажи небольшого устройства, которое (по заверениям самого оператора) станет хитом. Технически, устройство представляет из себя обычный 3G-модем со встроенным WiFi. Это позволяет создавать WiFi hot-spot повсюду, где есть покрытие 3G-сети ("3" является саммым большим 3-G оператором в UK). Всё что остается пользователю - включить модем, который автоматически войдёт в 3G-сеть, и затем ввести цифровой код доступа на ноутбуке, мобильном телефоне или любом другом WiFi-устройстве. И всё - вы в Интернет.
Заплатить за такое удобство можно исходя из 2х вариантов:
1. £69.99 (~1000 гривен) за модем + £15 каждый месяц абонплаты за 5GB трафика
2. £99.99 (~1400 гривен) за модем и безлимитный трафик в течении 3х месяцев. После этого можно перейти на любой тариф с оплатой трафика

Как говорит Marc Allera, директор по маркетингу и продажам, "Мобильный WiFi это будущее мобильного доступа в Интернет и мы предоставляем его пользователям по доступной цене. В комплекте с ноутбуком и iPod touch это обеспечит настоящий мобильный беспроводный доступ в Интернет - прекрасный подарок, который окажется во многих списках рождественных покупок в этом декабре".

Если же отвлечьсяя от маркетинга и рекламы, то можно обнаружить, что на рынке уже давно присутствует масса подобных устройств (например это). Правда, цены существенно выше и иногда требуется нетривиальное участие пользователя в настройке. Тут же предлагается безусловно "user-friendly" устройство по невысокой цене, да ещё и с предоплаченным трафиком. Что ж, выбор за вами, вернее за ними :) Нам остаётся ждать, пока что-то подобное и по вменяемым ценам появится на нашем рынке.

Информация о компании.
Название сети: 3
Название оператора: Hutchison 3G UK Limited
Владелец (группа компаний):
Сайт оператора: http://www.three.co.uk
Количество абонентов: 4.4 миилиона в UK и более 20 миллионов по всему миру
MCC: 234
MNC: 20
CC: 44
NDC: более 30 диапазонов
Технология: 3G 2100 (есть HSDPA)

Femtocell - long way to become de-facto

2009-08-25T14:51:00.007+03:00

Femtocell's market is growing fast, but this isn't enough to become mainstream in nearest future, according to a new study from Berg Insight.

In it's latest report, Berg announced femtocell shipments will grow from 200,000 units this year, to 12 million units globally in 2014, with success mostly based in Europe, North America and "advanced markets in the Asia-Pacific region".
"By 2014, there will be almost six femtocells per macro base station and the number of users that connect to a femtocell on a regular basis is estimated to surpass 70 million," it said.
At the same time report noted, that "the femtocell concept is still at an early stage with few commercial deployments. It will take several years before shipments of femtocells become substantial".
The main constraint in femtocell usage growth is competition with WiFi. More and more user devices are WiFi-capable, so there is only small need to buy and deploy another device in Home environment. At the moment, femtocell has advantage by providing Voice connectivity for 3G users. But with growth of IMS, there will be no needs to have Voice connection other then VoIP.
Marcus Persson, telecom analyst at Berg, said femtocells need to bring "significant value" beyond Wi-Fi to persuade consumers to hop on it. This may be better (if compare with WiFi) radio spectrum usage and interference resistance. "Femtocells also need to become sufficiently standardized to ensure efficient integration and low cost per unit," Marcus Persson added.
Concluding all above, I can say that it's a long way until femtocells come into our live as WiFi did.

O2 Germany снял ограничения на VoIP

2009-08-20T13:33:00.007+03:00

В Германии произошёл мини-прорыв на телеком рынке - O2, первым из ведущих мобильных операторов, разрешил использование мобильных VoIP приложений на телефонах пользователей без каких-либо ограничений и абонплаты. До этого момента все 4 ведущих оператора (O2, T-Mobile Deutschland, Vodafone Germany и E-Plus Mobilfunk) пытались блокировать VoIP приложения (такие как Skype) мотивируя это заботой об абонентах - VoIP трафик может перегрузить 3G сеть и тем самым препятствовать нормальной работе других пользователей. Как хорошо, когда во главу угла ставится забота о качестве услуг, а не то, что пользователи могут значительно сэкономить на международных звонках (а в случае Европы и на локальных звонках на стационарные телефоны). Вообще, вопрос IP-телефонии и других IP-услуг (начиная web-серфингом и заканчивая IPTV) стоит очень остро для 3G-сетей. Предлагая пользователям высокие скорости доступа в сеть Интернет, оператор мобильной связи превращается в простого провайдера Интернет. Да, стоимость доступа в Интернет с использованием 3G-сети пока-что выше, чем у тех же ADSL-"конкурентов". Но:
1. Цены на доступ в Интернет постепенно снижаются, а значит со временем придётся забыть о сверх прибылях.
2. Цены на голосовой трафик, который был основным источником дохода мобильных операторов, падают очень медленно и тенденций к их резкому снижению не видно.
3. Мобильные операторы "неплохо зарабатывали" на продаже дополнительных услуг, которых практически нет в провайдерском бизнесе (речь идёт о классических провайдерах Интернет).
Отсюда и нежелание пускать тот же Skype в свою сеть. Операторы хотят быть чем-то большим, нежели простым средством доступа к услугам сторонних компаний - они сами желают предоставлять эти услуги. И брать за это плату, естественно.
Пока-что это выражалось в виде €9.95 абонентской платы за разрешение пользоваться VoIP приложениями в сети T-Mobile Germany. Мера явно временная и врядли сможет продержаться на рынке в связи с заявлением O2. Остаётся только ждать, что будет дальше и какие ухищрения придумают операторы. Но то, что они не захотят просто так отдать жирный кусок пирога - это факт.

Гиганты телеком рынка и кризис

2009-08-17T17:42:00.006+03:00

Тема кризиса уже настолько приелась, что было приятно видеть отчёт Reuters о состоянии рынка телеком. Оказывется, не все плачутся "как всё плохо" и "как же дальше жить?". Как говорится, кому кризис, а кому - мать родная.

И так, по-порядку.
Первое место. Ericsson.
Лидер рынка не изменил своих позиций по итогам второго квартала и по-прежнему удерживает 32% рынка. Изменился только отрыв от ближайшего конкурента - тепер Эрикссон бесспорный лидер рынка с отрывом в 12%.
Пока конкуренты рассказывают на сколько процентов уменьшится рынок из-за влияния кризиса, председатель правления (CEO) Эрикссон Carl-Henric Svanberg, смело говорит правду - операторы не уменьшали своих капитальных расходов.
А это значит, что и выручка вендоров не должна была уменьшиться. Куда же она тогда девалась? Читаем дальше.

Второе место. Nokia Siemens Networks.
Компания во втором квартале 2009 года потеряла 6% по-сравнению с аналогичным периодом прошлого года и теперь владеет 20% рынка. В итоге, разрыв с Ericsson увеличился с 6 до 12%. По прогнозам компании, телеком рынок в 2009 году уменьшится на 10%.

Третье место. Huawei.
Китайцы кризиса не испугались и смело отобрали ещё 7% рынка, увеличив долю до 17%. Если тенденция сохранится, то NSN не поможет даже 10% сокращение рынка. Честно говоря, до момента написания статьи даже и не подозревал, что китайцы уже настолько близко. Европейские операторы вовсю переводят радио-часть на оборудование Huawei, потому что "Ericsson дорого", а некоторые и коммутаторы китайские в core network ставят. Вот так, понемногу, рынок и отбирают.
Говорят также, что Huawei и ZTE активно спонсируются государственными банками Китая, что помогает им демпинговать. Так в Европе и Штатах тоже ведь банки есть. Кто мешает?

Четвертое место. Alcatel-Lucent.
12% рынка против 14 год назад. Компания пргнозирует уменьшение обьёмов рынка на 8-12%.

Пятое место. ZTE.
Ещё одни китайцы, которым приписывают 25% глобального рынка CDMA сетей. Если же не ограничиваться технологиями, то ZTE занимает 8% мирового рынка. Это удвоенный показатель, по-сравнению с прошлым годом.

По итогам отчёта мне одно непонятно - куда девались 11%? Может их обанкротившийся Nortel забрал? :) Или кто-то из читателей блога? Признавайтесь по-хорошему!

Vodafone Access Gateway

2009-08-10T11:17:00.009+03:00

Vodafone UK, который первым из известных операторов запустил Femtocell в коммерческую эксплуатацию, заявил о низком уровне продаж в этом направлении. Устройство уже месяц (с первого июля) доступно во всех отделениях продаж оператора, но как заявлется - один из магазинов в Лондоне продал всего 20 устройств.

Следует отметить тот факт, что устройство практически не рекламируется и не продвигается (попробуйте найти его на сайте оператора). Не нашли? :)
Кроме того, с самого запуска услуги, Vodafone заявил что условия тарификации при использовании "своего" Femtocell такие же как и при использовании "обычной" 3G-сети. Единственное преимущество, которое получает пользователь - это улучшенное покрытие в пределах своего дома/квартиры.
Заплатить за такое преимущество предлагалось £160 сразу или £30 сразу и £10 каждый месяц на протяжении 10 месяцев. Сейчас же, с целью увеличения продаж, устройство продаётся по цене £100 или £5 в месяц на протяжении двух лет.
Несмотря на низкие уровни продаж, отзывы об устройстве исключительно положительные. Устойчивая работа, хороший уровень сигнала, высокая пропускная способность для Data-трафика.
Теперь немного о самом устройстве.
Видео о том, как просто установить и настроить:

Внутри femto-соты стоит Линукс. Исходный код доступен для общественности, его обсуждение на сайте Betavine.

2020

2009-07-16T16:34:00.002+03:00

Хотите узнать, что будет представлять из себя мир гаджетов в 2020-м году? Многие хотят, даже компания Эрикссон, которая выставила своё виденье мира будущего на обозрение. "Мир" этот доступен по ссылке. Неплохая попытка не только заглянуть в будущее, но и обрисовать его для всех желающих (да ещё и с удобной навигацией и красивой прорисовкой).
Что мне больше всего запомнилось:
INDIEBANK - мечта любого начальника любого отделения по работе с клиентами. Хотя я, как клиент, всё-таки за "живое" общение.
SOUND WALLS - работаю в open space, поэтому хочу такую штуку уже сейчас и немедленно! :))
R&D->EDUCATION - учиться, учиться и ещё раз учиться. И это всё через одно окно - "EVERLASTING SCHOOLBOOK". Хочу отметить, что это будущее уже совсем рядом. Например, детище Amazon - Kindle:

BIOLOGICAL ALARM CLOCK - ещё одна вещь, задатки которой уже есть на рынке. И мне не хватает её каждое утро :(

А что понравилось Вам?

World's first LTE Internet connection

2009-06-17T07:18:00.007+03:00

TeliaSonera sub NetCom said it used a laptop with a 4G modem to make the first mobile broadband Internet connection over a live commercial LTE network in Oslo, Norway. Check it out here.

As for me, it's hard to understand there anything. They better show laptop's screen. Also it's really strange, that a lot of Chinees engineers/managers present on video. It was announced previously (see my post First commercial LTE), that network is built using Ericsson equipment. Don't think that all these guys there due to laptop's modem.
I'd also recommend you to read comments on youtube. There are comments about technical details there. So - have fun watching World's first LTE in live.
Source: www.fiercewireless.com