ITU/ANSI Conversion

От одного из читателей блога поступил интересный вопрос - как происходит конвертация планов нумерации, если необходимо передать сообщение из европейской (ITU) в американскую (ANSI) сеть SS7?

Если Вы не очень хорошо помните о планах нумерации в сетях GSM, то можете почитать мою старую статью здесь. Вопрос читателя относился конкретно к процедуре регистрации абонента одной из американских сетей в европейской. "Европейская" процедура регистрации включает в себя конвертацию IMSI абонента (E.212) в гибридный номерной план - E.214, который легко маршрутизируется по префиксу (аналогично E.164) в сетях транзитных операторов. Конвертация осуществляется на VLR (или MSC?) и состоит в замене MCC на CC и MNC на NDC.

Всё хорошо, пока мы в Европе, где операторам выделены отдельные (не географические) телефонные коды. В Северной Америке ситуация более запутанная - изначально у каждого оператора была масса географических кодов (area codes), которые они используют для нумерации абонентов из разных регионов. Если я не ошибаюсь, то сейчас операторы дополнительно используют не географические коды. В любом случае, простой конвертации MNC в area code осуществить нельзя - кодов слишком много. Вместо этого американский оператор "просит" транслировать MNC в какой-то один свой код.

Если бы не отличия в ANSI/ITU протоколах SS7, достаточно было бы отправить E.214 сообщение в сеть и ожидать ответа. Но в данном случае необходима конвертация между форматами с помощью какого-либо промежуточного узла. Таких узлов много, но каждый конкретный оператор работает только с определёнными узлами. Например, один из крупнейших американских операторов AT&T пользуется услугами 2х узлов - Syniverse и TELEGLOBE (сейчас Tata Communications). В европейской части сети SS7 эти узлы подключены ко многим большим операторским и транзитным сетям, таким как France Telecom, Deutche Telecom, Belgacom, British Telecom и др. В американской части сети они подключены напрямую к GSM операторам.

Следовательно, вся процедура регистрации американского абонента в европейской сети выглядит так:

1. IMSI абонента транслируется в MGT, используя предварительную информацию от американского оператора;
2. сообщение в формате E.214 (ITU) с CountryCode=1 маршрутизируется на ITU/ANSI conversion point;
3. модифицированное в ANSI-формат сообщение отправляется американскому оператору.
4. американский оператор отвечает через предпочтительный ITU/ANSI conversion point (не обязательно тот, с которого пришёл запрос).

Read More..

Приграничный роуминг - зло под контролем

Приграничный роуминг - что это такое и как с ним бороться.
В отличии от обычного роуминга, скандальные истории с которым происходят довольно часто, проблема приграничного роуминга не очень популярна в Интернет. Тем не менее, проблема существует достаточно долго и затрагивает куда большее количество пользователей.
Так что же это за проблема?
Существует несколько видов приграничного роуминга:

• Случайный/неумышленный роуминг
• Удержание путешественников, которые возвращаются домой
• Национальный роуминг

Рассмотрим их по-порядку.

Случайный/неумышленный роуминг

Это наиболее распространенный вид приграничного роуминга. При нахождении вблизи государственной границы, возможна ситуация отсутствия покрытия Вашего домашнего оператора, но зато присутствие покрытия оператора из соседней страны. Здесь я бы хотел особенно подчеркнуть факт отстутствия покрытия домашнего оператора, поскольку любой телефон (если он работает согласно стандартов) обязан отдавать предпочтение своей домашней сети при поиске. Поскольку большая часть телефонов по-умолчанию настроены на автоматический поиск сети, то Вы даже не заметите как зарегистрируетесь в чужой сети. При этом, в течении длительного времени (обычно 30 минут) телефон даже не будет пытаться "вернуться" в домашнюю сеть (если, конечно, покрытие зарубежного оператора не пропадёт).

Всё это время за услуги придется платить по роуминговым тарифам, которые существенно превышают домашние.

Удержание путешественников, которые возвращаются домой

Если путешественники возвращаются из соседней страны автомобильным или железнодорожным транспортом, то какое-то время они могут быть "удержаны" зарубежной сетью, в которой они были зарегистрированы во время поездки.

Поскольку проблема затрагивает не только жителей приграничных областей (которые более информированы о проблеме приграничного роуминга), то количество жалоб от абонентов может быть большим.

Национальный роуминг

Региональные (реже национальные) операторы используют национальный роуминг для обеспечения связью своих абонентов за пределами покрытия собственной сети. Иногда такой "роуминг" даже бесплатен для абонентов, хотя домашний оператор будет вынужден оплатить расходы. Особенно грустно оплачивать подобные расходы, если абонент находился в зоне покрытия домашней сети, но его телефон выбрал сеть роуминг партнёра.

С самой проблемой разобрались, а теперь про методы её "лечения". 

Как ни странно, но это проблема не только для абонентов, но и для операторов. Заработанные таким "нехитрым" способом деньги, оборачиваются большими нематериальными потерями - ухудшается имидж оператора, снижается лояльность абонентов и т.д.

Поэтому сами операторы предпринимают ряд таких мероприятий для уменьшения влияния приграничного роуминга:

• обучение абонентов
• СМС-нотификация при регистрации в чужой сети (Welcome SMS)
• изменение настроек таймеров в телефонах
• использование роуминг-платформ (SS7 steering)
• профилирование абонентов
• биллинг-решения

А теперь подробнее о каждом.

Обучение абонентов

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

Об эффективности подобного обучения я рассуждать не буду. Скажу только, что единожды заплатив за приграничный роуминг, абонент усвоит теорию намного быстрее.

Welcome SMS
Более продвинутый и эффективный (на первый взгляд) метод борьбы. Казалось бы, достаточно предупредить абонента о регистрации в роуминг-сети и он не будет жаловаться когда получит шокирующий счёт за использование услуг.
Однако не всё так просто. Во-первых, дополнительные СМС сообщения от оператора не всегда  восторженно воспринимаются абонентами - для многих абонентов это очередной спам. Т.е. часто такие сообщения отправлять не получится. В итоге, в определённый момент абонент окажется не проинформирован о регистрации в "чужой" сети.
Во-вторых, быстрая доставка смс может быть невозможна из-за проблем покрытия у роуминг-партнёра.

Изменение настроек таймеров в телефонах
Основная проблема приграничного роуминга состояит не в том, что абонент зарегистрировался в сети другого оператора - как я уже говорил, это случается из-за проблем с покрытием домашней сети, а значит силами своей сети обеспечить связь для абонента просто невозможно. Проблема состоит в том, чтобы вернуть абонента обратно в свою сеть. По-умолчанию, это может произойти в двух случаях:
- исчезло покрытие зарубежной сети, в которой зарегистрировался абонент. Телефон абонента вынужден осуществить поиск, который может обнаружить домашнюю сеть. В этом случае телефон сразу же её и выберет;
- телефон абонента провёл периодическую процедуру сканирования и обнаружил домашнюю сеть.
Первый случай не очень интересен, потому что повлиять на ситуацию нет возможности. А вот во втором случае есть возможность влияния. По-умолчанию, период составляет 30 минут (чем он больше, тем лучше с т.зр. экономии ресурсов батареи), но у оператора есть возможность уменьшить этот период (и тем самым сократить время жизни батареи).

Использование роуминг-платформ (SS7 steering)
В "обычном" международном роуминге довольно распространена практика заключения договоров с несколькими операторами из одной страны. С одной стороны это даёт возможность обеспечить абонента связью на большей территории (провалы в покрытии одного оператора могут быть компенсированы покрытием другого оператора), а с другой - позволяет поторговаться за межоператорские тарифы. При этом хорошую скидку можно получить только если брать "оптом" - обеспечить большое количество роуминг-трафика в определённой сети.
При этом сами абоненты обычно ничего не знают о межоператорских расценках - для них установлена единая цена за услуги в любой сети из определённой страны. Задача домашнего оператора - "заставить" абонентов регистрироваться в сети с более низкими тарифами, может быть выполнена с помощью роуминг платформ - систем управления международным сигнальным трафиком.
В задачу подобных систем входит анализ данных, извлечённых из сообщения MAP update location. По номеру VLR есть возможность определить сеть, а затем исходя из настроек системы - разрешить или отказать в регистрации абонента в этой сети. В случае отказа, телефон выберет следующую доступную сеть и попытается зарегистрироваться в ней. Таким образом, у оператора появляется возможность "зарегистрировать" абонентов в определенной сети роуминг-партнёра.
Подобные системы могут быть дополнены модулем для специальной обработки сообщений update location от приграничных VLR в соседних странах. Идея состоит в том, чтобы отказать в попытке регистрации, выиграть немного времени (порядка 90 сек) и тем самым увеличить вероятность возвращения в домашнюю сеть.
Хотел бы отметить, что современные системы противодействия приграничному роумингу достаточно интеллектуальные и могут определять местоположение абонента (с точностью до соты), удалять и восстанавливать регистрацию абонента в сети роуминг-партнёра, отслеживать факт возвращения абонента в домашнюю сеть и ещё кучу плюшек. Если у Вас возник интерес к подобным решениям - обратите внимание на Border Roaming Gateway от Roamware .
Главный недостаток такого решения очевиден - абонент лишается связи в течении всего процесса принудительной регистрации.

Профилирование абонентов
Врага нужно знать в лицо, а абонента - в профиль. Собирая и анализируя данные по активности абонента, его местоположению, количеству жалоб и т.п. можно отнести его к одному из предустановленных профилей. Этот профиль затем может быть определен на системе рассылки смс (Welcome SMS ), системе изменения таймеров, роуминг-платформе.
Например, бизнес-клиенты не так чувствительны к расходам, но зато не любят лишние смс и очень не любят ситуаций недоступности услуг. Поэтому для них можно создать профиль с минимальным влиянием на процесс регистрации в зарубежной сети.

Биллинг-решения
Вместо решения проблемы, операторы могут договориться друг с другом об отсутствии дополнительной оплаты за услуги, предоставленные в приграничном роуминге. Это более вероятно, если оба оператора входят в состав одной большой компании.

Вместо заключения
Данная статья является вольным переводом этой статьи. Компания Evolved intelligence предлагает своё уникальное решение проблемы приграничного роуминга. Решение базируется на использовании ресурсов сети и самого телефона (SIM based application). Насколько эффективна такая связка - покажет время. Я же могу только сказать, что решения на базе роуминг-платформ, которые я разворачивал, довольно эффективны и уже установлены у многих операторов.

Read More..

SMS Forwarding

В предыдущем посте "Home Rerouting" меня попросили рассказать о том, как работает смс переадресация. Эта статья должна ответить на вопросы: что такое смс-переадресация и как она работает.

Наверняка многим знакома услуга переадресации звонков (о ней я писал в статьях "Call forwarding" и "Основы переадресации вызовов в GSM"), которая позволяет смело выключить телефон и получать все вызовы на другой номер. Однако, рано или поздно возникнет проблема с получением входящих смс на выключенный номер. Поскольку переадресация вызовов работает только для голосовых (и data/fax) звонков, то смс так и не будут доставлены - они будут скапливаться на SMSC (SMS Centre).
Для решения этой проблемы некоторые операторы начали предоставлять дополнительную услугу - переадресация смс. Суть услуги в том, что абонент может переадресовывать все свои смс на другой номер. И хотя с виду услуга простая, тем не менее у разных операторов она реализована по-разному.
Например, часть операторов позволяют выполнять подобную переадресацию только для смс отправленных абонентами своей сети. Т.е. если абонент другой сети отправит Вам смс, то она переадресована не будет.
Другие же операторы предоставляют услугу переадресации для всех входящих смс, независимо от сети отправителя.

Почему так происходит и какие принципиальные отличия в реализации услуги? Читайте дальше.

Во-первых, необходимо разобраться как происходит доставка смс в сетях GSM.
В процессе отправки/доставки участвуют следующие элементы сети:

• MS (Mobile Station) - телефоны отправителя и получателя смс;
• MSC (Mobile Switching Centre) - коммутатор, который обслуживает подвижных абонентов - получателя и отправителя смс;
• SMSC (SMS Centre) - центр коротких сообщений. Находится в сети отправителя;
• HLR (Home Location Register) - узул сети GSM, коотрый среди прочего хранит информацию о текущем коммуаторе (MSC) получателя смс

В общем случае процесс выглядит так (некоторые детали не указаны, чтобы не усложнять схему):

Немного пояснений к рисунку:

1. Абонент А отправляет смс абоненту B.
2. В MS абонента А указан номер центра коротких сообщений (SMSC), через который и будет произведена доставка смс.
3. Сообщение отправляется на коммутатор абонента А, оттуда на SMSC.
4. SMSC не знает текущий коммутатор абонента B, поэтому запрашивает эту информацию у HLR. поскольку адрес HLR тоже не известен, то сообщение Send Routing Info for SM отправляется на адрес абонента B. Сеть получателя отвечает за то, что сообщение SRI-SM будет смаршрутизировано на соответсвующий HLR (в одной сети их может быть несколько).
5. HLR возвращает в качестве ответа текущий MSC абонента, а также его мобильный номер - IMSI.
6. SMSC отправляет смс на коммутатор абонента B, а тот в свою очередь на терминал получателя.
7. Если абонент А запросил отчёт о доставке и доставка була успешной, то SMSC генерирует отчёт о доставке и отправляет его абоненту А.

Главный вывод из представленной схемы состоит в том, что за доставку смс отвечает SMSC абонента отправителя. Если отправитель и получатель смс обслуживаются одной сетью, то услугу переадресации смс можно реализовать непосредственно на SMSC своей сети.

Для этого в логике работы SMSC необходимо реализовать дополнительный интерфейс для связи с оборудованием услуги переадресации смс:

SMSC, перед отправкой смс абоненту из своей сети, запрашивает у внешнего приложения что делать с смс для абонента B. Вариантов 2 - продолжить доставку на номер B (если переадресация не установлена) или инициировать доставку на номер С (указанный при установке переадресации).

Главный минус такой реализации состоит в том, что все смс, отправленные из других сетей (а значит через другие SMSC), будут по-прежнему доставляться на номер B. Ведь другие сети ничего не знают о наличии платформы переадресации смс.

Другой способ реализации услуги переадресации смс состоит в использовании специального узла в сети SS7 - SMS Router. При этом процесс доставки смс будет выглядить так:

В задачи SMS Router входит:

• Обработать входящий запрос Send Routing Info for SM, определить фактического получателя смс (если установлена смс переадресация) и сделать запрос в HLR от своего имени.
• Если HLR вернул ошибку, то возвратить эту же ошибку для SMSC.
• Если от HLR был получен позитивный ответ, то в ответном сообщении для SMSC будет указан MT Correlation ID вместо реального IMSI и адрес SMS Router вместо MSC. При этом соответствие между адресами будет сохранено в памяти SMS Router.
• Обработать входящий запрос MT Forward SM и проверить валидность MT Correlation ID. Этот ID считается невалидным, если не найден в списке выданных (в этом случае нет возможности найти реальный IMSI и MSC получателя). Дополнительно ID может быть отклонён, если MT Forward SM отправлен не из той же сети, что и Send Routing Info for SM (подозрение на спам).
• Отправить смс на реальный адрес коммутатора, а отчёт о доставке на SMSC.

MT Correlation ID это специальный идентификатор, состоящий из трёх частей:

• Mobile Country Code (MCC) сети получателя. 
• Mobile Network Code (MNC) сети получателя. Поскольку многие сети используют только 2х-значные MNC, то третья цифра берётся из MSIN (MSIN это часть IMSI).
• Sender ID. Уникальный случайный номер.

Фактически, MT-SMS Correlation ID содержит первые 6 цифр из IMSI получателя, а остальные 9 цифр это случайный номер, уникальный для каждого запроса.

Таким образом, благодаря использованию SMS Router появляется возможность переадресовывать смс, отправленные с любой сети.

P.S. SMS Router изначально был "придуман" для борьбы с смс спамом (см. статью "Home Rerouting"), однако "лёгким движением руки" может быть расширен для предоставления услуги смс переадресации.

Статьи по теме:
Call forwarding
Основы переадресации вызовов в GSM
Home rerouting

Read More..

Home Rerouting

В данной статье я вкратце расскажу, что такое Home Rerouting для SMS. Если есть желание узнать о подобном сервисе для голосовых вызовов - дайте знать через комментарии.

Стандарт GSM определяет сеть отправителя SMS ответственной за за доставку сообщения получателю.Это означает, что SMSC (SMS-центр) в сети отправителя обязан "найти" местоположение получателя сообщения (фактически найти коммутатор, на котором зарегистрирован получатель) и доставить сообщение на этот коммутатор.

Получатель сообщения при этом может находиться либо в своей домашней сети (наиболее вероятное событие), либо в сети оператора-партнёра в той же стране (если между сетями разрешён национальный роуминг) или же в любой другой сети, с которой подписано роуминг-соглашение.
Для того, чтобы определить адрес коммутатора получателя сообщения, SMSC использует протокол MAP, а конкретно операцию sendRoutingInfoForSM (opCode 45). Операция представляет собой запрос от SMSC к домашнему HLR получателя SMS. В общем случае, SMSC не знает адрес HLR-а абонента, поэтому запрос посылается с использованием MSISDN получателя, в качестве адреса. Сеть получателя обязана транслировать MSISDN в адрес соответствующего HLR. В ответ на запрос, HLR обязан вернуть адрес текущего коммутатора абонента (MSC) и IMSI. Возможны варианты, когда HLR ответит, что такого абонента не существует, либо он не зарегистрирован в сети.
Следующий этап это отправка сообщения на коммутатор используя операцию mt-ForwardSM/mo-ForwardSM (opCode 44/46).
В чём проблема такого подхода? Во-первых, любая сеть, с которой есть соглашение об обмене SMS, может запросто получить данные о местоположении абонентов (с точностью до MSC). Информация о местоположении может быть использована при организации массовых санкционированных и несанкционированных рассылок. Поскольку каждый коммутатор отвечает за определённый географический регион, у организатора рассылки появляется возможность отправлять различные варианты рекламного текста в зависимости от местоположения абонента.
Также, если внимательно взглянуть на рисунок выше, то можно заметить, что абонент получит SMS даже в том случае, если mt-ForwardSM Ack (подтверждение о доставке SMS) не будет доставлен к SMSC. Это позволяет организовывать мошенничества, в которых адреса отправителя и SMSC заменяются на чужие и таким образом счёт за терминацию SMS будет выставлен совсем другому оператору.
Чтобы решить эти, а также ряд других проблем, организация 3GPP разработала спецификацию TR 23.840.
Основная идея этого документа состоит в том, чтобы именно домашняя сеть отвечала за доставку смс на текущий MSC абонента. Для минимизации изменений в существующих сетях, домашняя сеть должна отвечать адресом виртуального MSC на все запросы sendRoutingInfoForSM из других сетей. Таким образом все входящие сообщения будут поступать на этот виртуальный коммутатор, а с него уже на настоящий.

Такая схема позволяет решить все проблемы с минимальными изменениями в существующей инфраструктуре. При этом появляется возможность не только контролировать текст получаемых сообщений (борьба со спамом), но также и блокировать работу многих “хитрых” сервисов, использующих sendRoutingInfoForSM для получения информации об абоненте.

P.S. Хотя документ написан и утверждён довольно давно, мне не доводилось встречать его практических реализаций. Если Вы используете такие системы или есть сведения об их использовании другими операторами – оставляйте комментарии.

Статьи по теме:
Call forwarding
Основы переадресации вызовов в GSM
SMS Forwarding

Read More..

Работа в телекоме

В просторах Интернета обнаружил занятную вакансию одного известного вендора:


Requirements:

• Experience in telecommunication field at least 4 years.
• Knowledge in basic construction GSM/GPRS/CDMA networks. Protocols SSN7 (CAP, MAP, INAP, ISUP, MTP), 3GPP.
• Knowledge and work experience in Windows and Linux OS installation and maintenance, Database fundamentals. Oracle experience is a plus.
• Knowledge and work experience in IP networks design and implementations. Experience in network equipment configuration.
• Knowledge and work experience in basic internet services configuration: web server, proxy server, mail server, RADIUS server, etc.
• Know the application and trend of three big operators (KS, Life, and MTS): Intelligent Network (Prepaid, MVPN, and FPH Services), WAP Gateway, SMS Center, MMS Center, AAA server, RBT (Ring Back Tone Service), LBS (Location Base Service), etc.
• Fluent English.

Responsibilities:

• Project implementation of RBT\VAS equipment in Ukraine; include RBT/WIN/UIN which includes installation, testing and maintenance.
• Learning Software products.
• Provide technical support or services to customer, enhance the customer satisfaction.
• Provide training to customers to improve their familiarity to our products.

Сразу подумал - раз столько всего требуется, значит работа и уровень оплаты точно на высоте. Подал своё резюме, проснулся ни свет ни заря, приехал и установил личный рекорд по длительности собеседования - 8 минут. Ровно столько мне понадобилось, чтобы понять кого на самом деле ищут - инженера поддержки RBT-платформ аж у целых двух операторов.

Только вот зачем человеку, который будет собирать логи, ставить патчи и, возможно в перспективе, внедрять новые сервисы/платформы, знать столько всего??? Неужели непонятно, что подобные знания и опыт стоят дорого, а значит не могут быть оплачены на позиции инженера тех-поддержки? Или это я чего-то не понимаю?

Read More..

I'm ready to buy a platform, solution, or service - please contact me

Немного отвлечённая (от основной тематики) статья.

Я не sales expert и, возможно, что-то не понимаю в продажах. Вот уже почти 3 недели, как я оставил запрос на сайте HP с просьбой указать, кто из sales отвечает за продажи недешёвого продукта (HP Open Call Media Platform) в определенном регионе. Не получив ответа, продолжил самостоятельные поиски и по неявным данным определил, что за продажи в этом регионе отвечает российский офис HP. Опять же, через сайт HP написал запрос конкретному sales в России. Снова тишина. Подождал неделю и повторил запрос через общий сайт - результата всё ещё нет.

Понятно, что 100% гарантии покупки у меня нет и поэтому бегать и труситься надо мной не стоит.  Но разве задача sales не в том, чтобы связаться с потенциальным покупателем для выяснения деталей?

Read More..

Основы переадресации вызовов в GSM

Вкратце о том, как работает переадресация, я уже рассказал в статье Call forwarding. В этой же статье речь пойдёт о тонких технических моментах реализации этого дополнительного сервиса.

Предварительно необходимо ответить на вопрос:
Что такое переадресация вызова?
Определимся с терминологией.
Абонент А: это инициатор вызова - вызывающий абонент
Абонент B: получатель вызова - вызываемый абонент
Абонент С: получатель вызова после срабатывания переадресации. В частном случае это может быть ящик голосовой почты абонента В.

Сервис переадресации предоставляет возможность по условию (занято, нет ответа в течении Х секунд, абонент вне сети) или безусловно (т.е. всегда) преобразовать вызов А->B в вызов A->C. При этом все остаются довольны:
А - всё таки куда-то дозвонился :)
В - рано или поздно узнает от абонента С, что ему был вызов (например, прослушает голосовую почту). А в случае с переадресацией по неответу дополнительно увидит пропущенный вызов.
С - поговорит с абонентом А.

Как это происходит?
Если не вдаваться в подоробности, то коммутатор просто делает исходящий вызов от абонента В к абоненту С, а затем соединяет 2 вызова в конференцию.
Далее с подоробностями.

Кто и за что платит?
Абонент А всегда платит только за исходящий вызов абоненту В независимо от того - была переадресация или нет. Началом тарификации является ответ абонента С.
Абонент С платит только за входящий вызов от абонента В. Обычно такие вызовы бесплатны.
С абонентом В сложнее всего. Всё зависит от того, какой именно коммутатор выполнит переадресацию.


Какой именно коммутатор выполняет переадресацию?
Для начала хотел бы отметить, что всё рассмотрение будет происходить относительно номера В. Это входящий вызов и он обслуживается так, как изображено на рисунке ниже (взят из 23.018):

В GSM входящие вызовы обслуживает GMSC (Gateway Mobile Switching Centre), либо MSC с функционалом GMSC. Задача GMSC при поступлении вызова - определить текущее положение абонента (с точностью до коммутатора) и отправить вызов далее. Информация о местоположении хранится на HLR, поэтому туда и отправляется запрос (MAP sendRoutingInformation). HLR хранит у себя данные о текущем VLR абонента и его "доступности". Возможны такие варианты (с последствиями):

• у абонента установлена безусловная переадресация. HLR без выяснения прочих подробностей "попросит" GMSC сделать переадресацию;
• абонент давно не в сети, его профиль удалён из VLR, а номер VLR удалён из HLR. Если установлена (и активна) переадресация по событию "не в сети", то вывод напрашивается сам собой - HLR "попросит" GMSC сделать переадресацию;
• номер VLR указан в профиле абонента. HLR инициирует запрос к текущему VLR абонента с целью получить временный номер для дозвона (MAP provideRoamingNumber). VLR проверяет в своём локальном профиле статус абонента. Статусов всего 2 - активный (imsiAttached) и неактивный (imsiDetached). Если статус активный, то VLR выделяет временный номер (MSRN) из пула и возвращает его на HLR. Если же статус неактивный (например, абонент выключил свой телефон), то возвращается ошибка - Absent Subscriber. Здесь важно отметить, что телефон должен быть именно выключен. Только в такой ситуации терминал обязан отправить в сеть сообщение, что он выключается. Если из телефона вынута батарея или она разряжена, то, естественно, никаких сообщений в сеть терминал не отправляет и VLR считает такого абонента зарегистрированным в сети. В случае ошибки Absent Subscriber, HLR обновит профиль абонента (выставит флаг imsiDetached) и "попросит" GMSC сделать переадресацию (естественно, если установлена переадресация по событию "не в сети");
• номер VLR указан в профиле абонента, но дополнительно установлен флаг imsiDetached. Это означает, что предыдущая попытка дозвониться до абонента не увенчалась успехом т.к. он был вне сети. Запроса на VLR не будет, а HLR сразу же "попросит" GMSC сделать переадресацию (опять же, если установлена переадресация по событию "не в сети").

В результате, HLR ответит на GMSC либо временным номером абонента В (MSRN), либо номером С, с указанием причины переадресации.
Во втором случае всё просто - GMSC в домашней сети совершит исходящий вызов на номер С из профиля абонента, а затем соединит оба вызова в конференцию. Как указано выше, подобный сценарий возможен в следующих случаях:

• у абонента В установлена безусловная переадрссация;
• абонент В правильно выключил свой телефон;
• абонент В недоступен (разрядилась батарея, вне покрытия сети) НО ему уже поступали входящие вызовы, а значит HLR уведомлен о его недоступности.

Все 3 описанных случая принято назвать одним термином - early call forwarding (ECF).

Вернемся к случаю, когда HLR возвращает временный номер абонента В. GMSC ничего не остаётся как начать процедуру установления вызова к коммутатору абонента В (VMSCB). Получив MSRN, коммутатор спрашивает у VLR о том, какому абоненту назначен этот номер и в каком состоянии сейчас этот абонент. Состояния абонента могут быть такими:

• абонент зарегистрирован в сети (imsiAttached), активных голосовых вызовов в данный момент у него либо нет, либо вызов уже установлен и активирован сервис ожидания вызова (Call waiting). Теоретически абонент может принять вызов;
• у абонента В сейчас активный голосовой вызов, но вызов в процессе установления или установлен и при этом сервис ожидания не активирован. Таким образом принять второй вызов абонент не может

Во втором случае VLR укажет коммутатору на необходимость установления нового вызова - от абонента В к абоненту С, а затем 2 вызова будут соединены в конференцию.
В первом случае VLR попросит коммутатор "поискать" абонента в группе сот (LAC). Поиск осуществляется с помощью широковещательного запроса (paging). Если терминал абонента "отозвётся", то абоненту А в голосовом канале будет отправлен сигнал КПВ (контроль посылки вызова, гудок 1 сек, пауза 3 сек, повтор), а коммутатор начнёт подсчёт времени до состояния неответа. В случае, если абонент В не ответит в течении заданного периода времени, коммутатор отправит запрос в VLR и тот укажет на необходимость установить связь с номером С и соединить оба вызова в конференцию.
Для первого случая также возможен вариант, когда терминал абонента В не ответит на paging. И вновь коммутатор отправит запрос в VLR и получит команду установить вызов с номером С.
Если переадресацию осуществляет текущий коммутатор абонента В, то такой вид переадресации называется late call forwarding (LCF).

Как это активировать/деактивировать?
Активация и деактивация переадресации может быть выполнена либо через меню телефона, либо с помощью комманд MMI (Man Machine Interface).

Почему нельзя поставить переадресацию на на номера с префиксом и платить меньше?
Во многих сетях есть возможность с помощью специальных префиксов совершать международные звонки по сниженным тарифам. Например, украинский оператор Kyivstar GSM предлагает использовать для таких вызовов префикс 015. Логично предположить, что может возникнуть идея установить в качестве номера переадресации что-то вида 015-код страны-код сети-номер абонента. Однако любопытных ждёт разочарование - сеть не примет такой номер и не установит переадресацию. Детальное обьяснение Вы можете найти в статье Call forwarding.
Если кратко - подобные правила набора номера работают только в домашней сети. Если абонент В будет в роуминге, то гостевая сеть не сможет осуществить переадресацию на такой номер. Почему так важно сохранить возможность переадресации в роуминге? Читайте дальше.

Как всё это происходит, когда абонент в роуминге?
В том случае, когда абонент В зарегистрирован в гостевой сети (роуминг-партнёре), схема вызова не меняется. В общем случае, домашней сети всё равно где сейчас зарегистрирован абонент - на домашнем или гостевом VLR. Но в случае, если необходимо произвести переадресацию, вопрос роуминга становится важным. В зависимости от типа переадрессации - late или early call forwarding, существенно меняется стоимость. В случае ECF, абонент В будет протарифицирован только за один вызов - от В к С по местным тарифам связи.
Если же имела место "поздняя" переадресация (LCF), то оплатить придётся как входящий вызов (А-В), так и исхоящий (В-С), причём оба по роуминг-тарифам. Самоё обидное для абонента это то, что в большинстве случаев о факте переадресации он узнает только при получении счёта об оплате услуг (или из смс от голосовой почты, если переадресация на ящик голосовой почты).

Инициатива EU, или почему европейцы не платят за переадресации в роуминге.
Подобное положение дел с LCF долго не давало покоя Европейской комиссии. Поэтому с 01.07.2010 всем европейским операторам мобильной связи запрещено взымать дополнительную плату за переадресацию в роуминге по Европе. Т.е. если произошло событие поздней переадресации при роуминге в европейской сети, то вместо оплаты 2х роуминг-звонков европеец оплатит только вызов от В к С по местным тарифам. Если же европейский абонент зарегистрировался в не-европейской сети, то платить придётся за всё. Аналогично, не-евпропейские абоненты по-прежнему будут оплачивать два роуминг-вызова при срабатывании переадресации в в европейской сети.
Думаете мобильные операторы при этом терпят огромные убытки? Как бы не так - некоторые на этом ещё и зарабатывают! Если Вам интересно каким образом, то оставляйте комментарии - я обязательно напишу о том, как я провёл это лето :)

Статьи по теме:
Call forwarding
SMS Forwarding
Home rerouting

Read More..

Call Forwarding

Поступил вопрос: рассказать как работает переадресация вызовов в мобильных сетях, где происходит проверка и что именно проверяется при установке переадресации? Почему невозможно установить переадресацию на международный номер с префиксом услуги дешёвых звонков зарубеж?
Начал писать статью и понял, что получается уж слишком заумно (много терминов, куча всяких разных сценариев). Поэтому ту статью решил пока отложить, а ответить вкратце на поставленные вопросы.

Если абонент не в роуминге, то переадресация всегда происходит в домашней сети. Если же последняя регистрация была в роуминге, то в зависимости от состояния абонента, переадресация может произойти либо в домашней, либо в гостевой сети.
В простейшем случае переадресация происходит так:
1. Абонент А звонит абоненту В.
2. Текущий статус абонента не позволяет принять вызов или абонент не отвечает в течении установленного времени.
3. Коммутатор инициирует новый вызов на номер С из профиля абонента.
4. Как только абонент С отвечает (в качестве абонента С может выступать голосовая почта), оба вызова соединяются в конференцию.

Для того, чтобы переадресация сработала её необходимо установить в меню телефона или используя специальные коды. (например, *21*ХХХXXXX#).
При этом коммутатор отправляет запрос в домашний HLR с целью проверки правильности этого самого ХХХXXXX.
Что из себя представляет эта проверка? Во-первых, во многих сетях абонентам разрешено ставить переадресаци. только на номера голосовой почты. Во всех остальных сетях проверяется чтобы ХХХXXXX соответствовал таким правилам:

1. номер в национальном формате (начинается с префикса оператора, например, 67XXXXXXX у Киевстар). Должен отметить, что Киевстар не позволяет задать номер в таком формате;
2. префикс выхода на межгород, а затем номер в национальном формате. Например 067XXXXXXX;
3. международный префикс, код страны, номер в национальном формате. Например, +38067ХХХХХХХ

В HLR номер переадрессации должен быть сконвертирован и сохранён в международном формате. Всяческие варианты с префиксами для дешёвых звонков зарубеж запрещёны, потому что не попадают ни под одно из приведённых правил. В основном это сделано с целью обеспечить срабатывании переадресации в роуминге. Откуда гостевой сети знать, что украинские абоненты любят экономить, а поэтому вместо + или 00 набирают 015 (Kyivstar GSM) или 000 (MTS Ukraine)?

Статьи по теме:
Основы переадресации вызовов в GSM
SMS Forwarding
Home rerouting

Read More..

CAMEL and IVR

Читатели спрашивают (оставляйте вопросы по GSM здесь): как реализовать проигрывание голосового сообщения при звонке на CAMEL-абонента. Вызов при этом не должен быть полностью установлен (не должно быть тарификации А-абонента). После проигрывания сообщения вызов нужно прекратить.

Я вижу 3 варианта реализации. В любом из случаев предполагается, что в профиле абонента (T-CSI) указан "наш" SCP.
Вариант 1.
Ответить CAP RequestReportBCSM + Connect. Внутри Connect содержится номер IVR с которым надо установить соединение и не установлен параметр oCSIApplicable. Об этом IVR ниже.
Далее подождать некоторое время и отправить CAP releaseCall. Ожидается, что IVR не будет отвечать на вызов, поэтому никаких событий от SSP (MSC) не будет. Но на всякий случай лучше предусмотреть логику отправки releaseCall на события типа tAnswer.
Что касается IVR, то это должно быть устройство с голосовыми потоками и подключением по ISUP. Как только приходит ISUP IAM, логика IVR должна проверить А и Б номера и подготовить голосовой канал. Номер этого канала (CIC) приходит в сообщении IAM. Как только ISUP модуль отвечает ACM, можно начинать проигрывать запись в голосовом канале. Т.к. мы не будем отправлять ANM по ISUP, то и тарификации не будет.
Что касается диалога между SCP и SSP (MSC), то в RequestReportBCSM нужно активировать нотификацию на событие tNoAnswer и прерывание вызова (interrupted) для tAnswer. В случае получения ответа от нашего IVR вызов нужно завершить с помощью releaseCall.

Вариант 2.
На любой InitialDP отвечать releaseCall с release cause code, который точно на сети не используется. Далее, насколько мне известно, на MSC можно указать какой локальный автоответчик будет проигрываться при том или ином коде. Хотя согласно спецификации (для CAMELv2 - ETSI 03.78) коммутатор не должен ничего проигрывать, а только разорвать вызов и передать по ISUP на коммутатор абонента А сообщение REL с неким кодом (маппинг между кодами в CAMEL и ISUP не определён).
Только в этом варианте для всех абонентов получаем одинаковый автоинформатор (или очень ограниченное их число). Хочу сразу сказать, что я не сильно уверен в этом варианте - далёк от коммутаторов.

Вариант 3.
Использовать CAP "Connect to resource". Так делают Prepaid системы, когда перед вызовом необходимо проиграть системное сообщение типа "у Вас скоро закончатся все-все деньги". Callflow при этом такой:

-> IntialDP
<- RequestReportBCSMEvent + ConnectToResource + PlayAnnouncement
играет запись
-> Specialized Resource Report
<- DisconnectForwardConnection + ReleaseCall

Только для такого варианта нужен "умный" IVR, который будет выступать в роли Intelligent Peripheral.

Read More..

CAMEL trace

В комментарии к статье "Основы CAMEL" меня попросили добавить трейс. Трейс я добавил, однако хотел бы подробнее описать что там и к чему.

Для начала откройте трейс CAMEL с помощью Wireshark (если у Вас есть другая любимая программа - просьба сообщить в комментарии). Данный трейс взят с живой системы, но все важные адреса заменены на вымышленные. И кстати, при осуществлении этого вызова ни одно животное не пострадало.

Обмен сообщениями происходит между поинт кодом 1 и 2 (разверните поле MTP3 в Wireshark). На уровне SCCP диалог происходит между 111111111111 и 222222222222.

111111111111 это Global Title (GT) коммутатора, а точнее SSP (service switching point), который инициирует запрос в SCP (service control point) с GT=222222222222. Для этого создаётся TCAP транзакция с номером 11111111 (в HEX). Внутри этой транзакции находится т.н. application-context-name: 0.4.0.0.1.0.50.1 (CAP-v2-gsmSSF-to-gsmSCF-AC). Т.е. это CAMEL версии 2, диалог между SSF и SCF (Service Switching и Control Function, соответственно).

Если Wireshark не декодирует сообщение дальше SCCP, то надо ему явно указать что SSN=146 это протокол CAMEL.
Для этого в меню "Edit" выбрать "Preferences". Перейти к последнему пункту "Protocols", развернуть список и начать набирать CAMEL.
При этом отобразятся свойства протокола такого вида:

В поле TCAP SSNs надо через запятую указать значения 146 и 12. нажать ОК и теперь всё будет отображаться корректно.

Перейдём непосредственно в сам запрос. Первое, на что стоит обратить внимание, это opcode - InitialDP. Если Вы внимательно читали статью "Основы CAMEL", то должны знать что такой запрос посылается при срабатывании триггера. В данном случае это был триггер на "eventTypeBCSM: collectedInfo (2)" - исходящий вызов абонента. В отичии от Вас, SCP также "обратит" внимание на значение поля serviceKey, т.к. оно отвечает за выбор логики внутри SCP.

Теперь поля, которые имеют отношение непосредственно к вызову:

1. Calling Party Number: 38067220XXXX. Это вызывающий номер - т.н. А-номер.
2. Location number: 111111111111. Адрес коммутатора, с которого происходит вызов. Очень важное поле с точки зрения тарификации абонентов в роуминге.
3. vlr-number и mscAddress. Тут я думаю, что всё понятно.
4. calledPartyBCDNumber - а это номер вызываемого абонента, т.н. Б-номер. Новый Wireshark уже декодирует это поле из формата BCD в "человеческий", поэтому если Вы видите что-то отличное от номера 380674660466, то обновляйте Wireshark.

В ответ на InitialDP SCP отправляет сообщение applyCharging. Посмотрите сперва на TCAP часть. Это сообщение является продолжением уже начатой TCAP транзакции (11111111), со стороны SCP ей присваивается номер 22222222.

Механизм ApplyCharging/ApplyChargingReport (AC/ACR) используется как для тарификации, так и для ограничения длительности вызова. SCP, после получения InitialDP, может расчитать максимальную длительность вызова (на основании текущего балланса абонента и его местоположения) и тем самым указать коммутатору (SSP) разорвать вызов при достижении этого значения.

Однако есть SCP, которые ведут статистику на основании событий oAnswer и oDisconnect. Время между этими событиями и будет занесено в биллинговую систему. В случае необходимости SCP использует сообщение ReleaseCall чтобы прервать вызов.

Таким образом существует 2 метода подсчёта длительности вызова - на основании AC/ACR и на основании CAMEL событий.

Следующее сообщение это RequestReportBCSM и Connect в одном TCAP-сообщении. С помощью RRB активируются триггеры, о срабатывании которых необходимо уведомить SCP. Сообщение Connect информирует коммутатор о том, что соединение необходимо установить на другой номер - 380674660467.

Как только вызов был установлен - SSP отправляет нотификацию об этом (eventTypeBCSM: oAnswer).

Через некоторое время (44 сек), вызов прекращается и SSP информирует об этом SCP (eventTypeBCSM: oDisconnect). Также передаётся сообщение ApplyChargingReport с длительностью вызова. В данном случае это был простой вызов - без переподключений к автоинформаторам и пр. Поэтому внутри ACR содержится параметр timeIfNoTariffSwitch с длительностью вызова (описание полей в 09.78). Я не нашёл описания в стандарте, но почему-то значение параметра timeIfNoTariffSwitch в 10 раз больше актуальной длительности вызова.

И последнее сообщение - TCAP End для транзакции 11111111. На этом всё - вызов успешно завершён и обслужен.

Если есть вопросы - задавайте.

Read More..

Что такое 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..

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..

Orange the Best

На ежегодном 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 и пожелать им оставаться "двигателями" прогресса на телеком рынке.

Read More..