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
Теория, теория, теория.
Я бы с удовольствием не расписывал всякие теоретические моменты, которые Вы можете прочесть ниже, но без них понимание CAMEL будет очень ограниченным. В своё время я без труда разбирал трейсы CAMEL-диалогов, не задумываясь почему возникает то или иное сообщение. Со временем захотелось большего. Ниже я постарался расписать минимум, который необходим для понимания что и почему происходит при вызове. Информация, в основном, взята из 23.078 и головы.
Если же Вам лень читать теорию, переходите сразу к практике.
Базовая модель состояния вызова (BCSM, Basic Call State Model)
Для эффективного управления, вызов разбивается на отдельные элементы (состояния):
DP (Detection Point) это своеобразный указатель на текущее состояние. Например, DP2 (Collected Info) указывает на то, что это исходящий вызов в самом начале его обработки. Point In Call - это действия, которые выполняются в этом месте вызова. DP бывают 3-х типов:
CAMEL-подписки
Для того, чтобы абонент использовал CAMEL-услугу, его надо "подписать" на неё. Сделать это можно в двух местах - на HLR (в профиле абонента) и непосредственно на самом MSC. Второй вариант (Network Service CAMEL Subscription Information, N-CSI) я рассматривать не буду (в виду ограниченности статьи), хотя вещь безусловно интересная.
Что касается варианта размещения подписок в профиле абонента, то здесь остановлюсь на 2х типах:
Обе подписки содержат в себе такие данные:
Модель исходящего вызова (Originating Basic Call State Model, O-BCSM)
Обработка исходящего вызова происходит на Vistor MSC, т.е. на коммутаторе в котором абонент зарегистрирован в данный момент. VLR этого MSC уже содержит копию профиля абонента, а значит и O-CSI (если таковой у абонента имеется). В CAMEL определена такая модель исходящего вызова:
Надеюсь, Вы не закрыли эту страницу и читаете дальше. Если так, то постараюсь обьяснить на пальцах что же такое изображено на рисунке.
Модель входящего вызова (Terminating Basic Call State Model, T-BCSM)
Перед тем, как начать рассматривать входящие вызовы, я напомню, что мы имеем дело с мобильной сетью. А значит местоположение Б-номера заранее неизвестно. Задача определения текущего MSC вызываемого абонента в классической GSM сети (без CAMEL) была возложена на GMSC домашней сети. С введением CAMEL, именно на GMSC возложили задачу обработки T-CSI (Примечание. Согласно стандарту возможен также CAMEL диалог между VMSC и SCP). Как происходит обработка вызова на GMSC показано на рисунке ниже:
Ближе к практике, ближе к SS7Теперь рассмотрим как вызов выглядит с точки зрения сети SS7. Начнём с исходящего вызова.
Сообщение InitialDP содержит такие важные поля (подробное описание всех полей в 29.078):
Continue_With_Argument описано в спецификации, но в реальной жизни я этого сообщения никогда не видел. Поэтому писать о нём не рискну. Если у Вас имеется полезная информация об этом сообщении - милости прошу в комментарии.
CAMEL Connect. Самый главный параметр в этом сообщении это destinationRoutingAddress. Фактически, это новый номер на который должен пойти вызов. Пример, Вы пользователь услуги виртуальной АТС и позвонили на короткий номер Вашего босса - 777. SCP преобразует этот номер в "полный" MSISDN 380671234567 и отправит его в сообщении Connect.
Есть ещё сообщение ConnectToResource, которое очень похоже на Connect, только позволяет совершить соединение с новым номером до соединения с набранным номером. Обычно в качестве нового номера выступает Intelligent Peripheral. Таким образом, например, Вас могут предупредить о том, что средства на счету или срок их действия истекают. После предупреждения вызов будет продолжен.
Если в сообщении RequestReportBCSM были активированы триггеры, то SSP информирует об их срабатывнии с помощью сообщения EventReportBCSM. Это соощение будет содержать тип события (DP), которое произошло, и дополнительную информацию по этому событию. Например, в случае события Busy будет указано точная причина занятости (Subscriber absent, User busy).
Предоплаченная связь (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 будет очень ограниченным. В своё время я без труда разбирал трейсы CAMEL-диалогов, не задумываясь почему возникает то или иное сообщение. Со временем захотелось большего. Ниже я постарался расписать минимум, который необходим для понимания что и почему происходит при вызове. Информация, в основном, взята из 23.078 и головы.
Если же Вам лень читать теорию, переходите сразу к практике.
Базовая модель состояния вызова (BCSM, Basic Call State Model)
Для эффективного управления, вызов разбивается на отдельные элементы (состояния):
- 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
- 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 формате
- 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_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 так и не получилось, но я надеюсь что всё описано достаточно просто и понятно. Как обычно, если есть какие либо вопросы или замечания - используйте форму для комметариев.
Вот и всё. К сожалению кратко описать CAMEL так и не получилось, но я надеюсь что всё описано достаточно просто и понятно. Как обычно, если есть какие либо вопросы или замечания - используйте форму для комметариев.
