Сейчас мы рассмотрим вопросы аспекты реализации IN-протокола мобильной сети CAMEL и то, как на его основе функционирует услуга фиксировано-мобильной конвергенции FMC. Полезно для тех, кого прагматично интересует телефония в офисе или более теоретически — работа некоторых аспектов мобильной связи в принципе.
Что это значит?
- Простые номера: больше не нужно запоминать или записывать длинные DEF-номера. Любому сотруднику можно дозвониться, зная его очень короткий офисный номер.
- С FMC можно просто набрать номер и сразу соединяется с нужным фиксированным телефоном, не набирая никаких дополнительных на мини-АТС. Время соединения сокращается примерно на минуту.
- Можно создавать индивидуальные правила на входящую и исходящую связь: например, больше никаких «лишних» звонков в нерабочее время.
Начнём с аспектов реализации IN-протокола мобильной сети CAMEL.
Как это работает?
Если вспомнить основы построения сети GSM, то принципиально её структуру можно изобразить следующим образом.
- BTS (Base Transceiver Station) – базовая станция. В её функции входит формирование радиосигнала, шифрование, установка и поддержание сигнала на физическом уровне.
- BSC (Base Station Controller) – контроллер базовых станций. Данный узел отвечает за управление группой базовых станций, регулирование уровня сигнала и проведение handover’а (переключение вызова с одной базовой станции на другую в режиме разговора).
- MSC (Mobile Switching Center) – центр мобильной коммутации. В его функции входит непосредственно проключение вызова между двумя (или более) абонентами. На практике, данный узел часто совмещают с VLR (Visitor Location Register) – гостевым регистром местоположений, базой данных, отвечающей за хранение всей пользовательской информации об абонентах, зарегистрированных в зоне действия данного коммутатора.
- HLR (Home Location Register) – домашний (опорный) регистр местоположений. Распределённая база данных, в которой хранится вся информация об абонентах сотового оператора: их услуги, настройки и текущий статус.
- АuC – (Authentication Center) – центр аутентификации, отвечающий за проверку подлинности абонента при его регистрации в сети.
Если рассмотреть их взаимодействие с точки зрения сигнализации, то изначально взаимодействие элементов было построено на базе протокола сигнализации ОКС7 (Общеканальная Сигнализация №7).
Затем, в свете развития IP-сетей, этот протокол был доработан и превратился в SigTRAN (Signaling Transport, протокол транспортной сигнализации на базе сетей TCPIP)
Более подробно со структурой сети GSM и сигнализаций ОКС7 можно ознакомиться вот в этом и этом постах (отдельное спасибо за пару взятых у авторов картинок).
А теперь перейдём непосредственно к особенностям реализации протоколов интеллектуальных услуг INAP/CAMEL. INAP (Intellectual Network Application Part, прикладной протокол интеллектуальной сети) – протокол компании Ericsson, пришедший в мобильные сети из фиксированных, CAMEL (Customized Applications for Mobile Enhanced Logic) – протокол, разработанный исключительно для мобильных сетей, расширяющий их функционал. Спецификациями (в первую очередь, 3GPP TS 23.078), на данный момент, описаны 4 версии данного протокола.
Если коснуться технической стороны реализации, то в упрощённом виде она выглядит следующим образом:
При подключении в биллинге абоненту любых CAMEL-услуг, в HLR’е прописываются O-CSI (Originating CAMEL Subscription Information, информация о CAMEL подписках для исходящих вызовов) и/или T-CSI (Terminating CAMEL Subscription Information, информация о CAMEL подписках для входящих вызовов) подписки, которые отвечают за логику обработки исходящих и входящих вызовов соответственно. В параметрах подписки указывается адрес gsmSCF платформы, содержащей в себе логику дальнейшей обработки вызова, service key – уникальный идентификатор каждой из имеющихся CAMEL-услуг и Default call handling (сценарий обработки вызова «по умолчанию») – действие, которое нужно совершить с вызовом в случае срабатывания bypass. Значение может настраиваться в зависимости от функционала и логики услуги. К примеру, если необходимо, чтобы в случае зависания или перегрузки CAMEL-платформы вызов по-прежнему проходил, то необходимо выставить значение данного параметра «Continue». А если необходимо остановить обработку данного вызова – «Release».
Классический пример – это отключение тарификации для prepaid абонентов в случаях перегрузов. В этом случае Default call handling имеет значение «Continue», т.е. происходит установление соединения без формирования CDR’ов (Call Data Records) в биллинге.
Данной особенностью с успехом пользовались студенты одного Ростовского университета, приехавшие из какой-то банановой республики Центральной Африки. В момент срабатывания bypass (его они определяли постоянными запросами баланса – когда падает препейдный биллинг, на запросы *102# начинает возвращаться ошибка) студенты начинали названивать домой, родственникам и знакомым. А поскольку явление падения биллинга – событие редкое (новый год, 8 марта да пара аналогичных праздников), пообщаться они старались с запасом.
CSE – CAMEL service environment (Сервисная платформа CAMEL). IN-платформа, которая хранит в себе всю логику услуг.
SSF – Service Switching Function (Функция услуги на коммутационной составляющей). Данный функционал активируется на коммутаторах и его основная задача состоит в том, чтобы «триггерить» вызовы во всех случаях активности мобильных абонентов. Проще говоря, если коммутатор «видит», что у звонящего абонента есть O-CSI подписка, он инициирует обращение к IN-платформе.
SCF – Service Control Function (Функция контроля услуги). Функционал на стороне IN-платформы, занимающийся обработкой запроса, ответом на него и корректным завершением диалогами между узлами.
При поступлении входящего вызова на CAMEL-абонента, сеть инициирует последовательность действий, называемую Two step HLR interrogation (двухшаговое внедрение на HLR). Схематически, она показана на картинке ниже.
На MSC поступает входящий вызов.
В первую очередь MSC отправляет MAP (Mobile Application Part)-запрос Send Routing Info (запрос информации маршрутизации) в сторону HLR’а. В ответном сообщении должна быть предоставлена информация о текущем статусе абонента (включен, выключен, находится в режиме разговора и т.д.), которую HLR, в свою очередь, запрашивает в MSC/VLR сообщением Provide Subscriber Info (предоставление пользовательской информации), а также информация об имеющихся T-CSI подписках.
После этого на уровне протокола CAP (CAMEL Application Part, прикладная часть протокола CAMEL) происходит инициация сессии в сторону IN-платформы. Ниже приведу один из возможных сценариев такого диалога между MSC и IN-платформой.
Сообщение UDT BEGIN initialDP (DP – Detection Points, инициация точек определения) описывает процесс первичного запроса в сторону IN-платформы. В качестве входных параметров используются called (вызываемый)(2)и calling (вызывающий) (3) номера, а также информация из T-CSI подписки: global title (адрес) платформы и service key (1). Помимо этого указан и тип диалога – входящее соединение (4).
--- INITIAL DP ---
--- SERV KEY ---
SERV KEY : 51 (1)
--- CALLED NO ---
--- CALLED NO ---
NOA : .0000011 = National (significant) number (national use)
INN IND : 1....... = Routing to internal network number not allowed
NUMB PLAN : .001.... = ISDN (Telephony) numbering plan (Rec. E.164)
ADDRESS : 903041ХХХХ (2)
--- CALLING NO ---
--- CALLING NO ---
NOA : .0000011 = National (significant) number (national use)
NI : 0....... = Complete
NUMB PLAN : .001.... = ISDN (Telephony) numbering plan (Rec. E.164)
PRESENT IN : ....00.. = Presentation allowed
SCREENING : ......11 = Network provided
ADDRESS : 906361УУУУ (3)
--- CLG PTY C ---
--- CLG PTY C ---
CATEGORY : 10 = Ordinary Calling Subscriber
--- LOC NO ---
--- LOC NO ---
NOA : 04h = International number
INN IND : 0....... = Routing to internal network number allowed
NUMB PLAN : .001.... = ISDN (Telephony) numbering plan (Rec. E.164)
PRESENT IN : ....00.. = Presentation allowed
SCREENING : ......11 = Network provided
ADDRESS : 7962ZZZZZZZ
--- BEARER CAP ---
--- BEARER CAP ---
--- BEARER CAP ---
CODING STD : .00..... = CCITT standardized coding
INFO TC : ...00000 = Speech
TRANS MODE : .00..... = Circuit mode
INFO TR : ...10000 = 64 kbit/s
LAYER ID : .01.....
USRINFO L1 : ...00011 = Recommendation G.711 A-law
--- E TYP BCSM ---
E TYP BCSM : 12 = termAttemptAuthorized (4)
Сообщение UDT CONTINUE requestReportBCSMEvent connect (BCSM – Basic Call State Model, базовая модель установки вызова) описывает все возможные события, которые могут произойти при попытке установить голосовое соединение: абонент занят, недоступен, не отвечает. Они-то и являются теми «Detection points», которые инициировались предыдущим сообщением. В самом конце в сообщении Connect указывается номер, на который необходимо проключить данный вызов. Это может быть как непосредственно DEF номер абонента, так и различные технологические номера, использующиеся для реализации дополнительного функционала. На этом же этапе, в случае наличия у абонента ограничений на входящую связь, обработка вызова прервётся с cause=ReleaseCall.
--- OPERATION ---
OPERATION : 23 = requestReportBCSMEvent
--- RQ RP BCSM ---
--- BCSM EVTS ---
--- BCSM EVENT ---
--- E TYP BCSM ---
E TYP BCSM : 17 = tDisconnect
--- MONIT MODE ---
MONIT MODE : 0 = interrupted
--- LEG ID ---
--- SEND SD ID ---
LEG TYPE : 02h = leg2
--- BCSM EVENT ---
--- E TYP BCSM ---
E TYP BCSM : 15 = tAnswer
--- MONIT MODE ---
MONIT MODE : 1 = notifyAndContinue
--- LEG ID ---
--- SEND SD ID ---
LEG TYPE : 02h = leg2
--- BCSM EVENT ---
--- E TYP BCSM ---
E TYP BCSM : 13 = tBusy
--- MONIT MODE ---
MONIT MODE : 0 = interrupted
--- LEG ID ---
--- SEND SD ID ---
LEG TYPE : 02h = leg2
--- BCSM EVENT ---
--- E TYP BCSM ---
E TYP BCSM : 14 = tNoAnswer
--- MONIT MODE ---
MONIT MODE : 0 = interrupted
--- LEG ID ---
--- SEND SD ID ---
LEG TYPE : 02h = leg2
--- DP SP CRIT ---
--- APP TIMER ---
APP TIMER : 60
--- INVOKE ---
--- INVOKE ID ---
INVOKE ID : 1
=== CAP ===
--- INVOKE ---
--- OPERATION ---
OPERATION : 20 = connect
--- CONNECT ---
--- DST RT ADR ---
--- CALLED NO ---
--- CALLED NO ---
NOA : .0000010 = Unknown (national use)
INN IND : 0....... = Routing to internal network number allowed
NUMB PLAN : .001.... = ISDN (Telephony) numbering plan (Rec. E.164)
ADDRESS : 9031234567
Следующее сообщение UDT CONTINUE eventReportBCSM указывает, какое из описанных событий, в итоге, наступило
=== CAP ===
--- INVOKE ---
--- OPERATION ---
OPERATION : 24 = eventReportBCSM
--- EV RP BCSM ---
--- E TYP BCSM ---
E TYP BCSM : 13 = tBusy
--- E S I BCSM ---
--- T BSY ---
--- BUSY CAUSE ---
--- CAUSE ---
CODING STD : .00..... = CCITT standardized coding
LOCATION : ....0000 = User
CAUSE VAL : .0010001 = User busy
--- REC SIDEID ---
--- REC SIDEID ---
LEG TYPE : 02h = leg2
--- MISC C INF ---
--- MSG TYPE ---
MSG TYPE : 0 = request
После того, как в сообщении UDT CONTINUE requestReportBCSMEvent connect пришёл номер, на который необходимо проключить вызов, инициируется Second Interrogation (второе обращение к HLR), а затем идёт обращение к MSC/VLR’у на выделение MSRN (Mobile Station Roaming Number, временный номер, использующийся исключительно для проключения вызова в сторону входящего коммутатора). Затем данный номер в ответном сообщении возвращается на MSC и инициируется вызов на уровне протокола ISUP.
Сценарии вызовов
Если рассмотреть функционал CAMEL непосредственно в разрезе услуги FMC, то сценарии вызовов можно разделить на 3 основные категории:
1. Вызовы с мобильного телефона на мобильный телефон.
Данный сценарий нельзя в полной мере отнести к конвергентной услуге, но, всё-таки, предлагаю его рассмотреть. Звонящий абонент набирает заранее известный короткий номер, соответствующий В-абоненту. В ходе обработки на CAMEL платформе, он преобразуется в полноценный DEF номер, на который и происходит проключение вызова.
2. Вызовы с мобильного телефона на фиксированный телефон.
В данном сценарии мобильный абонент также набирает короткий номер, и, в ходе анализа, становится ясно, что это номер из фиксированной сети. В таком случае в начало номера подставляется уникальный префикс, по которому прописана маршрутизация в стык MSC-АТС. На оконечном MSC префикс отрезается и до АТС доходит непосредственно тот номер, который был набран изначально. А затем, уже внутри фиксированной сети, вызов маршрутизируется до нужного офисного телефона.
Особенностью этих сценариев является то, что мобильным номерам можно присвоить короткие номера, которые будут схожи по структуре с офисными номерами.
Пример из жизни: у сотрудника есть офисный телефон с номером 5577 и мобильный телефон с номером 15577. На него можно позвонить как по первому номеру (зазвонит офисный телефон), так и по второму (зазвонит мобильный).
Стоит также добавить, что фиксированное соединение может быть организовано и как классическое TDM-соединение, и посредством SIP/RTP.
3. Вызовы с фиксированного телефона на мобильный телефон.
В данном сценарии вызов поступает с АТС в сторону мобильного коммутатора, который инициирует сессию до CAMEL платформы и в ответном сообщении возвращает DEF номер вызываемого мобильного абонента.
Преимущества тарификации
- Вызовы между мобильными по короткой нумерации совершаются по цене звонка внутри закрытой группы.
- Вызовы с мобильного на фиксированный совершаются по цене звонка внутри закрытой группы.
- Вызовы из внутрисетевого роуминга совершаются по цене звонка внутри закрытой группы.
Дополнительную экономию могут получить клиенту, обладающие собственной распределённой телефонной сетью и готовые организовать несколько стыков с коммутаторами на сети «Билайн».
Автор:
