для каких услуг необходима sccp маршрутизация

11.26.2009

SCCP routing

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

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

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

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

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

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

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

Источник

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Протокол SCCP

Продвинутый курс по Asterisk

Концентрат редких знаний, для внедрения Asterisk в крупных предприятиях. Все это мы собрали в одном курсе для тебя.

Стоит заметить, что в телефонии существует ещё один протокол с абсолютно идентичной аббревиатурой – SCCP – Signalling Connection and Control Protocol, однако данный протокол относится к сигнализации ОКС-7, тогда как SCCP – (Skinny Client Control Protocol) работает в стеке TCP/IP.

Протокол SCCP занимает то же самое место в VoIP что и SIP, H.323 и MGCP и выполняет те же самые функции. Однако, в отличие от всех перечисленных протоколов, имеет гораздо более простой синтаксис и требует меньше компьютерных ресурсов для обработки своих сообщений.

Как и большинство VoIP протоколов SCCP предназначен для обмена сигнальными сообщениями между клиентом и сервером в процессе установления и завершения звонка.

Как уже было замечено, Протокол SCCP имеет очень простой синтаксис. По заголовку того или иного сообщения можно однозначно определить в каком статусе находится текущее соединение, что делает Протокол SCCP крайне удобным при траблшутинге. Для передачи сообщений SCCP используется TCP (Transmission Control Protocol) well-known порт 2000.

Соединение по SCCP невозможно рассматривать без сервера (чаще всего CUCM). SCCP имеет большое множество сообщений и отправляет их на сервер по каждому поводу, ожидая руководства к дальнейшим действиям. Выглядит это примерно так:

Каждое событие фиксируется вплоть до получения сервером сообщения о том, что телефонная трубка снова в исходном положении.

Обратите внимание, что сообщения SCCP отправляются как в сторону клиента, так и сторону сервера, поэтому для определения источника сообщения используются идентификаторы. StationInit, если источником является клиент и StationIniD, если источником является сервер телефонии. Таким образом появляется возможность в мельчайших деталях отследить любой звонок, совершенный внутри корпоративной сети.

Приведем пример некоторых сообщений SCCP:

Как видно из данного примера, MessageID каждого сообщения крайне точно описывает соответствующее ему событие, поэтому чтение трассировок SCCP обычно не составляет труда.

Стоит также добавить, что некоторые компании, занимающиеся разработкой голосовых решений, такие как: Digium, SocketIP и Symbol Technologies, добавили поддержку протокола SCCP в свои продукты.

Базовый курс по Asterisk

Мы собрали концентрат всех must have знаний в одном месте, которые позволят тебе сделать шаг вперед на пути к экспертному владению Asterisk

Источник

28 Адресация и маршрутирование в sccp

Адресация и маршрутирование в sccp

В подсистеме МТР для целей маршрутизации сообщений используются коды пунктов сигнализации SCP (OPC и DPC).

В подсистеме SCCP для маршрутизации сигнальных сообщений в услугах, ориентированных на соединение, используются коды пунктов виртуальных соединений сигнализации. Также исползуется код исходящего пункта соединения сигнализации и входящего.

В случае услуг, не ориентированных на соединение, адресами для подсистемы SCCP является адрес исходящего пункта сигнализации и адрес входящего пункта сигнализации. Для определения следующего пункта в соединении сигнализации анализируется специальное поле в сообщении SCCP, которое называется адрес вызываемой стороны. В сообщениях SCCP с установлением соединения сигнализации адресная информация не включается, а присутствует только в одном сообщении «Запрос соединения» (CR).

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

1. GT (глобальные заголовки) – адрес, который в явном виде не содержит информации, которая обеспечивает маршрутизацию в сети сигнализации с помощью подсистемы МТР;

2. Адрес, состоящий из DPC и номера подсистемы SSN. В этом случае по коду DPC маршрутирование реализует подсистема МТР по номеру SSN. Трансляция на уровне SCCP не требуется, некоторые объекты сети ОКС будут иметь один и тот же код DPC, но разный код SSN. Например, в сотовых сетях стандарта GSM один и тот же код DPC имеют MSC и VLR.

Параметр «адрес вызываемого абонента» в сообщениях SCCP может использовать следующие комбинации адресов:

Источник

Для каких услуг необходима sccp маршрутизация

Програмирование с использованием OpenGL

Подсистема sccp

Рассмотренная в предыдущем разделе подсистема передачи сообщений МТР представляет собой механизм передачи сообщений, который был специфицирован до того, как была разработана семиуровневая модель взаимосвязи открытых систем (OSI). Подсистема МТР полностью обеспечивает функции, соответствующие уровням 1 и 2 модели OSI, но для обеспечения услуг сетевого уровня модели OSI необходим ряд дополнительных функций.

Эти дополнительные функции реализуются подсистемой управления соединениями сигнализации SCCP. Комбинация МТР и SCCP называется подсистемой службы сети NSP.

В контексте семиуровневой модели OSI предполагается, что SCCP должна предлагать услуги более высоким уровням. Связь между SCCP и уровнем 4 осуществляется путем использования примитивов. Рис. 10.5. иллюстрирует примитивы, связанные с интерфейсом между SCCP и уровнем 4.

Рис.10.5. Примитивы 8ССР/пользовательские подсистемы Все услуги 8ССР подразделяются на услуги, ориентированные на соединение, и услуги, не ориентированные на соединение.

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

В услугах, которые не ориентируются на соединение, SCCP обеспечивает возможность передавать данные по сети сигнализации без установления сигнального соединения. Имеются два различных механизма передачи сообщений сигнализации: с контролем последовательности доставки сообщений и без такого контроля. В последнем случае невозможно гарантировать, что два сообщения, посылаемые с одного узла в определенном порядке, будут всегда приниматься другим узлом в том же порядке, т.к. они могут по разному маршрутизироваться в сети сигнализации, особенно с учетом возможных отказов.

Сообщения SCCP передаются в поле сигнальной информации SIF значащих сигнальных единиц MSU. Для MSU, передающей сообщение SCCP, формат SIF состоит из этикетки маршрутизации, типа сообщения и параметров. Структура SIF для сообщений SCCP представлена на рис, 10.6._

Рис.10.6. Структура SIF сообщений SCCP

Код типа сообщения состоит из одного байта и является обязательным для всех сообщений SCCP. Код типа сообщения однозначно определяет функцию каждого сообщения SCCP. Примеры типов сообщений для услуг, ориентированных на соединение, следующие:

• запрос соединения (CR) между двумя узлами;

• подтверждение соединения (СС) в ответ на сообщение CR;

• запрос разъединения (RLSD) со стороны любого из узлов;

• подтверждение разъединения (RLC): этот тип сообщения подтверждает, что процесс освобождения соединения завершен;

• данные для прозрачной передачи данных между двумя узлами после установления соединения (DT) и др.

Примерами типов сообщений для услуг, не ориентированных на соединение, являются следующие сообщения:

• данные без соединения (UDT), используемые для передачи данных без установления соединения между двумя узлами;

• служебное сообщение данных без соединения (UDTS), используемое для индикации невозможности доставки данных, посланных в предыдущем сообщении UDT (если установлена опция «return on error») и др.

Каждое сообщение содержит ряд параметров, которые дополняют информацию, содержащуюся в коде типа сообщения. В общем случае каждый параметр состоит из названия, индикатора длины и поля данных, как показано на рис. 10.7. Название однозначно определяет параметр и кодируется одним байтом. Индикатор длины указывает длину параметра, а поле данных содержит информацию. Однако не все эти поля включаются в каждый параметр. Параметры могут быть обязательными фиксированными, обязательными переменными или необязательными.

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

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

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

Для иллюстрации принципов форматирования БССР рассмотрим сообщение запроса соединения CR, предназначенное для установления соединения при использовании ориентированной на соединение услуги БССР. Пример такого сообщения показан на рис. 10.8. _

Рис. 10.8. Структура сообщения запроса соединения Тип сообщения в этом примере указывает, что это сообщение о запросе соединения CR. За типом сообщения следуют четыре параметра. Первый параметр является обязательным фиксированным и представляет собой местный условный номер источника, который присвоила исходящая БССР для идентификации сообщений, относящихся к конкретной транзакции. Второй параметр также является обязательным фиксированным параметром и указывает класс протокола, т.е. тип запрошенной услуги. Третий параметр является обязательным переменным и содержит адрес вызываемой стороны, т.е. указывает, к какой БССР направлено сообщение. Этот параметр включает индикатор длины, чтобы показать количество цифр адреса, включенных в поле данных параметра. Четвертый параметр является необязательным и содержит адрес вызывающей стороны, т.е. указывает, от какой БССР передается сообщение. Этот параметр включает индикатор длины и название.

Для БССР определены четыре класса протокола.

Первые два класса протокола (класс 0 и класс 1) не ориентированы на соединение и не содержат фаз установления и освобождения соединений. Максимальная длина поля данных составляет 256 байтов, поскольку протоколы, не ориентированные на соединение, не обеспечивают сегментирование и сборку.

Другие два класса ориентированы на соединение и включают установление и освобождение сигнальных соединений. В

этих классах протокола, ориентированных на соединение, устанавливается соединение сигнализации, передаются данные, а после завершения передачи данных сигнальное соединение освобождается. Данные передаются блоками, которые называются блоками данных службы сети (КББи) длиной до 256 байтов. Для более длинных сообщений данные сегментируются на блоки по 256 байтов в исходящем узле, после чего каждый блок может передаваться отдельно. Эти блоки затем собираются в узле назначения.

Класс 1 также является услугой, не ориентированной на соединение. Он подобен классу 0, но включает механизм контроля последовательности блоков данных. Это позволяет исходящему узлу запрашивать доставку блоков КББИ в узел назначения в заданной последовательности. Порядок следования устанавливается подсистемой МТР в ответ на выбор подсистемой БССР поля селекции звена сигнализации (БЬБ). Такая процедура работает при нормальных условиях; однако при возникновении отказов в сети отсутствие соединения может, тем не менее, привести к нарушению последовательности сообщений.

Классы 2 и 3 ориентированы на соединение. В классе 2 потоки КББИ могут передаваться в обоих направлениях в фазе передачи данных установления соединения. Для класса 3 возможности класса 2 дополняются путем введения услуги, гарантирующей прием сообщений в том же порядке, в каком они были переданы, даже при наличии отказов.

Пример [121] последовательности сообщений для услуг, ориентированных на соединение, показан на рис. 10.9. В этом примере функции верхнего уровня в узле А требуется связь с соответствующими функциями в узле Б. БССР-А принимает запрос от функции верхнего уровня в узле А на установление соединения с БССР-Б. БССР-А анализирует адреса вызываемой стороны (т.е. адреса БССР-Б). В результате этого анализа должно устанавливаться соединение сигнализации по соответствующему звену к узлу Б через МТР. Для этого через МТР к БССР-Б передается сообщение запроса соединения СЯ. При приеме этого сообщения СЯ в узле Б МТР доставляет его к БССР-Б. Анализируя адрес вызываемой стороны, БССР-Б определяет, что сообщение СЯ достигло своего пункта назначения, а также необходимость установления соединения. В сторону БССР-А передается сообщение подтверждения соединения СС.

Рис. 10.9. Пример последовательности сообщений: услуга, ориентированная на соединение Когда произведен обмен сообщениями СЯ и СС, устанавливается соединение сигнализации и производится передача данных. После окончания передачи данных БССР-А или БССР-Б могут инициировать процедуру освобождения путем передачи сообщения запроса разъединения ЯЬББ. Прием сообщения ЯЬББ узлом подтверждается сообщением подтверждения разъединения ЯЬС.

Во время установления соединения (рис. 10.10) присваиваются местные условные номера источника и назначения. Местный условный номер источника выбирается каждой БССР-А из пула номеров, а местный условный номер назначения выбирается подсистемой БССР-Б. Комбинация этих местных условных номеров затем действует как справочный номер для однозначной идентификации соединения БССР. Местные условные номера являются обязательными полями в сообщениях БССР. После освобождения соединения местные условные номера возвращаются в общий пул на каждом узле и могут использоваться снова для другого соединения.

Класс протокола может быть назначен во время установления соединения. Исходящая функция высшего уровня выбирает предпочтительный класс протокола, и он включается в сообщение СЯ, передаваемое подсистемой БССР-А. БССР-Б может изменить текущий класс протокола на класс

Рис. 10.10. Упрощенная ББЬ-диаграмма процедуры БСОС установления соединения БССР процесса ОТЬОС обработки исходящего вызова с меньшими ограничениями (например, перевести из класса 3 в класс 2) путем маркировки поля в сообщении СЯ состоянием, для которого узел Б разрешает только класс 2. Это может понадобиться, если, например, класс 3 недоступен в узле Б.

Если узлы А и Б не имеют прямого звена сигнализации и для установления соединения нужно привлекать третий узел, как показано на рис. 10.11, то БССР-А анализирует адрес вызываемой стороны и, определив отсутствие прямого звена сигнализации с БССР-Б, передает сообщение СЯ в промежуточный БССР-В. Получив сообщение СЯ, БССР-В анализирует адрес вызываемой стороны и определяет, что сообщение предназначено для БССР-Б. Поскольку БССР-В имеет прямое звено сигнализации с БССР-Б, она передает сообщение СЯ к БССР-Б. В свою очередь, БССР-Б возвращает сообщение СС к БССР-А через БССР-В. В данном контексте БССР-В будет считаться пунктом переприема, поскольку его роль состоит в переприеме сообщений между БССР-А и БССР-Б.

Рис. 10.11. Пример последовательности сообщений: услуга, ориентированная на соединение, с промежуточным узлом

SCCP дает ОКС7 возможность организовать интерфейс по модели OSI между уровнями 3 и 4 и с его помощью предложить сетевые услуги для ряда функций высшего уровня. В более далекой перспективе комбинацию МТР и SCCP можно использовать для обеспечения возможности передачи для ряда протоколов высших уровней, соответствующих 7уровневой модели OSI, безотносительно к тому, специфицированы ли протоколы как часть ОКС7 или нет, позволяя тем самым операторам сети оптимизировать технические решения в соответствии с конкретными условиями и обеспечивая тем самым большую гибкость в применении различных протоколов.

Источник

Про GPRS Блог о пакетной передаче данных в мобильных сетях

SCCP routing in SS7

Решил написать небольшую заметку, тем кто только начинает свое знакомство с Системой Общеканальной Сигнализации №7 (ОКС№7) или SS7, как ее принято называть. Скажу сразу, что в большей степени эта заметка писалась для собственного понимания некоторых моментов, связанных с роутингом сообщений, но если она будет полезна еще кому-нибудь, то буду очень рад.

Хочу также отметить, что в заметке центр внимания будет немного смещен в сторону осуществления коммуникации между элементами PS Core Network мобильной сети.

Итак… в этой статье речь пойдет о роутинге сообщений в сети SS7 на сетевом уровне, если же проводить некую аналогия со стеком протоколов модели OSI, то сетевой уровень в системе SS7 немного размыт и будет представлен двумя уровнями: MTP3 [Message Transfer Part – MTP ] и SCCP [Signalling Connection Control Part].

Чтобы понять о каких уровнях стека протоколов системы SS7 идет речь, давайте взглянем на общую структуру стека модели SS7 в сравнении с моделью OSI (см. рисунок ниже):

Как видим, модель SS7 может быть реализована на нескольких физических средах: PCM, ATM, IP. В этой же статье, мы будем рассматривать «классический» стек протоколов SS7, т.е. основанный на PCM линиях связи и соответственно, нижележащие уровни перед SCCP будут представлены в виде: MTP-1,2,3.

Как нам известно, с помощью базового стека протоколов SS7 возможно организовавывать сигнальные подключения, управлять ими и осуществлять роутинг в сигнальной сети.

Мы также знаем, что в пределах сети SS7 используется три типа сообщений или сигнальных юнитов (SU – Signalling Unit): FISU [Fill In SU], LSSU [Link Status SU], MSU [Message SU] — см. рисунок ниже:

Нас будут интересовать сообщения, несущие полезную нагрузку пользователей (MSU), т.к. именно в них содержится роутинговая информация для уровня SCCP.

Не буду описывать все поля и заголовки MSU, описание которых можно найти в любой толковой книге по SS7 (например, «Общеканальная система сигнализации №7» – Росляков А.В.,1999 г.), остановлюсь только на ключевых моментах, чтобы понять принципы роутинга этих сообщений.

Итак, в сообщениях MSU присутствуют поля SIO (Service Information Octet) и SIF (Service Information Field). В поле SIO (см. схему ниже) содержится информация о протоколе верхнего уровня (SCCP, ISUP и т.д.), которому адресовано это сообщение (поле Service Indicator – SI), а также информация о подвиде службы (SubService Field – SSF), которое в свою очередь включает в себя индикатор сети (Network Indicator – NI).

В поле SIF содержится информация о вышестоящий уровнях, которым адресована информация, а также роутинговые данные для уровней MTP – Label (т.н. этикетка маршрутизации). Следует отметить, что уровень MTP не «распознает» содержимое SIF, кроме этикетки маршрутизации (Label).

Теперь давайте разберемся, как эти поля в сообщениях применяются на т.н. Сетевом уровне модели системы SS7 – SCCP + MTP3.

SCCP была впервые представлена CCITT в т.н. «Красной книге» [Red Book] – 1984, как протокол для non-circuit сигнализации сообщений, например в ситуациях когда между сигнальными точками передается не речевая (non speech circuit) информация. SCCP принимает сервисы от нижележащих MTP уровней и предоставляет сервисы для, т.н. пользователей SCCP (SCCP-users: например, TCAP, ISUP).

Одной из основных особенностей SCCP является гибкий подход для предоставления адресации с помощью GT [Global Title]. Этот механизм адресации предоставляет возможность осуществлять end-to-end коммуникацию между географически отдаленными сетевыми элементами, что особенно важно в архитектуре мобильных сетей.

Еще одним сервисом, который предоставляет уровень SCCP, является сигнализация ориентированная на соединение (CO – Connection Oriented), с помощью которого оконечные элементы, могут осуществлять виртуальные соединения (virtual connection).

Уровни MTP и SCCP вместе называют Network Service Part (NSP).

Сообщения, отправляемые в режиме CL, не соотносятся друг с другом, при этом в каждом из них содержится адрес получателя. В режиме СО, между узлами, которые осуществляют взаимодействие устанавливается логическая связь (virtual connection) между уровнями SCCP. В этом случае, наличие адреса необходимо только в начале установления коммуникации, а более поздние сообщения содержат лишь порядковые номера, назначаемые им в процессе коммуникации.

Уровень SCCP определяет четыре класса для протоколов передачи сообщений:

Давайте рассмотрим каждый из двух основных классов (CL и CO) в отдельности (см. Рис. 4).

В классе СL используются в основном сообщения UDT [Unidata], при этом каждое сообщение содержит адрес получателя, т.е. каждое сообщение — это фактически «самодостаточная» коммуникационная единица. Коммуникации, основанные на классе СО, используются между сетевыми элементами, которые фактически могут быть разнесены в архитектуре(ах) оператора, например между :SGSN ↔ HLR, SGSN ↔ SCP (IN Platforms).

Во втором основном классе сервисов CO, между двумя сетевыми элементами, которые осуществляют коммуникацию, устанавливается виртуальный канал, при этом адрес получателя нужен только в начальных сообщения на установление коммуникации. Такой класс, в основном используется между «смежными» элементами, такими как: MSC ↔ BSC, MSC ↔ RNC, SGSN ↔ RNC. Схематично оба класса представлены на рисунке ниже:

Роутинг по этикеткам маршрутизации (Label) и по GT (Global Title)

Сообщение «приходящие» от уровня SCCP, на приемной стороне должны обрабатываться также уровнем SCCP. Например, если сообщение содержит только этикетку маршрутизации, то уровень SCCP не будет предпринимать никаких действий по обработке этого сообщения, а успешно передаст его для маршрутизации на нижний уровень MTP3 (см. схему ниже – маршрут от подсистемы CAP). Это тип роутинга называют роутинг по этикеткам маршрутизации – SCCP routing on label.

С другой стороны, если сообщение будет содержать адрес сетевого элемента (a.k.a. GT) вместо этикетки маршрутизации, то уровень SCCP будет использовать этот адрес для роутинга сообщения. В этом случае роутинг будет осуществляться по GT – SCCP routing on Global Title.

GT — это адрес, который используется для определения получателя сигнального сообщения, при этом GT определяется на уровне приложения, а анализируется на уровне SCCP. Большинство GT представляются в виде E.164 плана нумерации, но также могут быть представлены в виде E.212.

Возможны также варианты группировки двух методов маршрутизации:

Для определения корректного адреса сетевого элемента, которому нужно передать сообщение, применяется GT Analysis, т.к. уровень SCCP использует нижние уровни MTP, то одним результатом GT Analysis будет DPC сетевого элемента, а вторым Routing Indicator (RI), который используется для указания следующему сетевому элементу, о необходимости проводить GT Analysis для полученного сообщения или нет (см. схему ниже).

Давайте рассмотрим несколько типичных коммуникаций между элементами, чтобы понять принципы роутинга сообщений.

Процедура Location Update

Если SGSN еще не получал ни каких данных от абонента, то он может располагать только IMSI абонента. Чтобы определить расположение HLR абонента и выполнить запрос данных об абоненте, SGSN должен произвести IMSI Analysis. В этом случае “ответственной” за запрос Update Location будет подсистема MAP-H, которая воспользуется уровнем SCCP с Connectionless (не ориентированным на соединение) подключением.

Как мы уже знаем на уровне SCCP существует два типа маршрутизации:

Выбор типа маршрутизации будет зависеть от того где находиться абонент, в домашней сети либо в гостевой сети (т.е. в роуминге).

В случае когда абонент находиться в роуминге, SGSN не знает DPC домашнего HLR‘a абонента, поэтому SGSN будет использовать IMSI Analysis (см. рисунок ниже), чтобы транслировать IMSI из E.212 в E.214 (a.k.a. Hybrid Numbers) и роутинг будет естественно осуществляеться по GT.

Затем транслированный в E.214 номер абонента, пройдет через GT Analysis, результатом которого обычно является DPC Gateway, которому отправляется сообщения для доставки в домашнюю сеть абонента, а также RI, который будет указывать нужен ли GT Analysis (в случае если RI = GT) на следующем сетевом элементе или нет (в случае если RI = SSN).

Если же абонент находиться в домашней сети, то использование IMSI Analysis основанного на роутинге по этикеткам маршрутизации или роутинге по GT будет зависеть от того, знает ли SGSN DPC HLR‘a абонента. Если SGSN знает (имеет запись в своей таблице о DPC «домашних» HLR) DPC HLR‘a, то будет использоваться роутинг по этикеткам маршрутизации, в противном случае (SGSN не знает DPC HLR), будет использоваться роутинг по GT.

Вот собственно, с помощью таких методов осуществляется роутинг сообщений в сети SS7.

Небольшой помощник:

ATM – Asynchronous Transfer Mode

BSC – Base Station Controller

BSSAP – Base Station System Application Part

CAP – CAMEL Application Part

DPC – Destination Point Code

HLR – Home Location Register

IMSI – International Mobile Subscriber Identity

IN – Intelligent Networks

ISDN – Integrated Services Digital Network

ISUP – ISDN User Part

MAP – Mobile Application Part

MCC – Mobile Country Code

MNC – Mobile Network Code

MSC – Mobile Switching Center

MSIN – Mobile Station Identification Number

PCM – Pulse-Code Modulation

RANAP – Radio Access Network Application Part

RNS – Radio Network Controller

SCCP – Signalling Connection Control Part

SCP – Service Control Point

SGSN – Serving GPRS Support Node

TCAP – Transaction Capabilities Application Part

Источник