Протокол M3UA

7.4.1. Функции M3UA

В параграфе 7.1 отмечалось, что задача M3UA - обеспечить пре­доставление приложениям в сети IP услуг, аналогичных тем, которые MTP3 предоставляет приложениям вроде ISUP в сети ОКС7. Пояс­ним это на рис. 7.8, где показан Softswitch, которому необходимо запустить приложение типа ISUP. Вообще говоря, Softswitch может сделать это несколькими способами. Например, он может запус­тить ISUP поверх MTP3 поверх M2UA (или M2PA) поверх SCTP, как это обсуждается в двух следующих параграфах. Или же Softswitch может реализовать ISUP поверх M3UA поверх SCTP, как показано на рис. 7.8. Разница между этими двумя способами определяется тем, где реально расположена функция MTP3. В сценарии, который показан на рис. 7.8, обычный протокол MTP3 присутствует в шлю­зах SG, а MSUA просто обеспечивает приложению ISUP в Softswitch удаленный доступ к функции MTP3 в SG без ощущения приложени­ем ISUP того, что функция MTP3 не является локальной.

Рис. 7.8. Функции M3UA в Softswitch

Softswitch на рис. 7.8 может иметь код пункта сигнализации, отличный от кода, который имеет SG. В этом случае SG работает подобно STP и воспринимается внешней сетью ОКС7 как STP. Вне­шняя сеть ОКС7 рассматривает Softswitch как обычный оконечный пункт сигнализации ОКС7, доступ к которому достигается через один или несколько пунктов SG STP.

7.4.2. Терминология

Прежде чем мы перейдем к более подробному рассмотрению M3UA, необходимо оговорить некоторые термины, применимые

также и к другим адаптационным уровням. Прежде всего, под­черкнем разночтение между термином сервер приложений AS (Application Server), использованным ранее в этой книге в контексте VoIP и Softswitch, и тем же термином в понимании рабочей группы Sigtran для протоколов адаптационного уровня. В последнем слу­чае под сервером приложений AS понимается логический объект, который обрабатывает сигнализацию в определенной области. Например, AS может быть логическим объектом в Softswitch, обра­батывающим сигнализацию ISUP для конкретного диапазона ОКС7 DCP/OPC/CIC. В равной степени, AS может быть логическим объек­том в приложении базы данных, обрабатывающим сигнализацию.

Процесс сервера приложений ASP (Application Server Process) представляет собой экземпляр AS, что напоминает концепцию процессов в языке спецификаций и описаний SDL, обсуждающуюся в [4]. Сервер AS содержит набор процессов сервера приложений. Фактически, AS можно рассматривать как список процессов ASP, часть которых активна, а часть находится в резерве. ASP может быть, например, процессом в Softswitch, который в это время об­рабатывает сигнализацию ISUP. В устойчивой сети должен быть, по крайней мере, один активный ASP и, по крайней мере, один резерв­ный ASP для каждого приложения. Один ASP может обслуживать не­сколько серверов AS. Например, Softswitch может иметь несколько серверов AS, каждый из которых соответствует уникальной комби­нации OPC/DPC. Этот же самый Softswitch может иметь только один ASP, обрабатывающий всю сигнализацию ISUP (или два процесса ASP для резервирования или для разделения нагрузки).

Ключ маршрутизации (Routing Key) представляет собой набор таких параметров ОКС7, как SLS, DPC, OPC или диапазон CIC, кото­рые определяют сигнализацию для некоторого AS. Например, если какой-то AS должен обрабатывать сигнализацию ISUP для опре­деленной комбинации OPC/DPC/диапазон CIC, то эта комбинация и является ключом маршрутизации для такого AS. В пределах SG каждый ключ маршрутизации обычно указывает на один опреде­ленный AS. Иначе говоря, между ключами маршрутизации и AS, как правило, существует однозначное соответствие.

Отображение сети (Network Appearance) - это такое ее представ­ление, которое позволяет отделить часть сигнального трафика, нуж­ную для связи между SG и ASP, от всего трафика, использующего одно и то же соединение SCTP. Представим себе, например, международ­ный SG. Этот SG будет иметь, по крайней мере, один национальный и один международный код пункта сигнализации. SG использует на­циональный вариант MTP для связи в национальной сети и вариант ITU-T MTP - для связи в международной сети, а потому он должен видеть и различать соответствующие сигнальные потоки. Для связи между SG и Softswitch передаваемые и принимаемые сообщения

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

7.4.3. Код пункта сигнализации

Каждый ASP необходимо ассоциировать с кодом пункта сиг­нализации. Однако назначение кодов пунктов для процессов ASP является абсолютно гибким. Например, все ASP, подсоединенные к определенному SG, могут совместно использовать тот же код пункта, что и этот SG. В таком случае комбинация SG и процессов ASP видна сети ОКС7 как единый оконечный пункт сигнализации. Или же все ASP, подсоединенные к одному SG, могут иметь один и тот же код пункта, который отличается от кода пункта сигнализации, присвоенного этому SG. В таком случае SG будет виден сети ОКС7 как STP, а объединенные общим кодом ASP - как единый оконечный пункт сигнализации, расположенный за этим STP.

Еще одним вариантом назначения кодов может быть присвоение каждому ASP своего кода пункта, или группам ASP - разных общих кодов, отличных от кода, присвоенного SG. В этом случае SG ви­ден как STP, а каждый ASP (или группа процессов ASP) - как один оконечный пункт сигнализации. Дело в том, что если некий ASP или некая группа ASP может связываться с сетью ОКС7 не через один, а через два SG, то этот ASP или эта группа ASP должны иметь код пункта, который отличается от кодов этих двух SG. В таком сценарии шлюзы SG работают как транзитные пункты сигнализации STP.

7.4.4. Примитивы

Чтобы предоставлять услуги верхнему уровню прозрачно (так, чтобы приложение не ощущало факт использования функций MTP3, встроенных в SG, вместо функций локальной МТР), M3UA должен предоставлять верхнему уровню те же самые примитивы, которые предоставляет MTP3. Это следующие примитивы:

• MTP-Transfer request передается из верхнего уровня в M3UA, чтобы запросить перенос сообщения в определенный пункт на­значения.

• MTP-Transfer indication используется M3UA, чтобы пропустить входящее сообщение в верхний уровень.

• MTP-Pause indication передается M3UA в верхний уровень, чтобы указать, что передача сигналов в определенный пункт назначе­ния должна быть приостановлена. Этот примитив используется, например, когда пункт назначения недостижим.

• MTP-Resume indication передается M3UA в верхний уровень, чтобы указать, что передачу сигналов в пункт назначения можно возобновить.

• MTP-Status indication передается M3UA в верхний уровень, чтобы информировать этот уровень о некоторых изменениях, возник­ших в сети ОКС7, таких как перегрузка или недоступность под­системы-пользователя в пункте назначения.

Рассмотрим пример приложения ISUP в Softswitch, которому требуется передать сообщение в сеть ОКС7. Приложение передает запрос MTP-Transfer request в M3UA, а M3UA передает его в SCTP как фрагмент DATA, который необходимо передать по определенно­му соединению SCTP и в определенном потоке. SCTP обеспечивает поступление фрагмента DATA в SG, где содержимое этого фраг­мента проходит в M3UA, который передает его к функции взаимо­действия в SG. Функция взаимодействия пропускает его в MTP3 на стороне сети ОКС7 шлюза SG, который берет на себя корректную маршрутизацию сообщения дальше в сеть ОКС7.

В противоположном направлении процесс проходит аналогично. Сообщение приходит в SG и проходит от MTP3 к функции взаимо­действия, а от функции взаимодействия поступает в M3UA. На ос­нове параметров DPC/OPC/диапазон CIC сообщения ОКС7 выби­раются подходящий AS и подходящий ASP. Если активны более од­ного ASP, то выбирается один из них (в соответствии с алгоритмом разделения нагрузки). M3UA формирует сообщение для передачи SCTP как фрагмента DATA по соответствующему соединению SCTP и в соответствующем потоке. В пункте назначения фрагмент DATA проходит в M3UA, который пропускает информацию этого фраг­мента в приложение, используя примитив MTP-Transfer indication.

7.4.5. Сообщения M3UA

В состав M3UA входит ряд сообщений между одноуровневы­ми объектами M3UA, общий формат которых показан на рис. 7.9. Формат содержит заголовок и содержимое сообщения. Заголовок является общим для всех уровней адаптации. Для уровня M3UA версия протокола равна 0000 0001. Класс сообщения может быть следующим:

• 00 Сообщение управления;

• 01 Сообщение пересылки;

• 02 Сообщение эксплуатационного управления сетью

сигнализации ОКС7 (SSNM);

• 03 Сообщения эксплуатационного управления состоянием

ASP (ASPSM);

• 04 Сообщение эксплуатационного управления трафиком ASP

(ASPTM);

• 05 Резерв для класса сообщений, относящихся к IUA и

обеспечивающих транспортировку пограничных примити­вов Q.921/Q931;

• 06 Резерв для класса сообщений адаптации пользователя,

относящихся к M2UA;

• 07 Резерв для класса сообщений без установления соедине­

ния, относящихся к SUA;

• 08 Резерв для класса сообщений, ориентированных на со­

единение и относящихся к SUA;

• 09 Сообщение эксплуатационного управления ключом марш­

рутизации (RKM);

• 10 Резерв для класса сообщений эксплуатационного управ­

ления идентификатором интерфейса M2UA;

• 11 Резерв для класса сообщений M2PA;

• от 12 до 127 резервированы комитетом IETF;

• от 128 до 255 резервированы для определяемых IETF

/ / /

расширений класса сообщений.

Версия	Резерв	Класс сообщения	Тип сообщения
Длина сообщения

0 8 16 24 31

/

/

Содержимое сообщения

Рис. 7.9. Общий формат сообщения M3UA

Когда M3UA пересылает информацию пользователя между SG и Softswitch, как было описано ранее, он выполняет это путем пе­редачи сообщений M3UA DATA. Эти сообщения формируются как фрагменты SCTP DATA. При передаче сообщения DATA поле класса сообщения имеет значение 1, и тип сообщения имеет значение 1, как это показано в табл. 7.2.

Помимо упаковки сообщений пользователя в формат сообще­ний M3UA DATA, M3UA предусматривает другие сообщения между одноуровневыми M3UA-объектами, так что эти объекты могут об­мениваться информацией, относящейся к сети ОКС7 в целом. На­пример, если пункт назначения становится недоступным, то SG уве­домляется об этом с помощью сообщений эксплуатационного уп­равления сетью сигнализации ОКС7. Приложение ISUP в Softswitch

тоже должно уведомляться об этом событии, чтобы оно не пыталось передавать сообщения, которые не могут достичь своего пункта на­значения. M3UA в Softswitch может предупреждать о таком событии с помощью примитива MTP-Pause indication. Но M3UA - не MTP3, и сообщения эксплуатационного управления сетью сигнализации не проходят прямо от SG к SG. Поэтому M3UA в Softswitch узнает, что пункт назначения недоступен, с помощью другого сообщения M3UA, помимо сообщения DATA. В табл. 7.2 приводится список ти­пов сообщений M3UA.

Таблица 7.2. Сообщения M3UA Имя сообщения Класс сообщения Код класса сообщения Код типа сообщения Error (ERR) MGMT     Notify (NTFY) MGMT     Data Transfer     Destination Unavailable (DUNA) SSNM     Destination Available (DAVA) SSNM     Destination State Audit (DAUA) SSNM     SS7 Network Congestion State (SCON) SSNM     Destination User Part Unavailable (DUPU) SSNM     Destination Restricted (DRST) SSNM     ASP Up(ASPUP) ASPSM     ASP Down (ASPDN) ASPSM     Heartbeat (BEAT) ASPSM     ASP Up Acknowledgment (ASPUP ACK) ASPSM     ASP Down Acknowledgment (ASPDN ACK) ASPSM     Heartbeat Acknowledgment (BEAT ACK) ASPSM     ASP Active (ASPAC) ASPTM     ASP Inactive (ASPIA) ASPTM     ASP Active Acknowledgment (ASPAC ACK) ASPTM     ASP Inactive Acknowledgment (ASPIA ACK) ASPTM     Registration Request (REG REQ) RKM     Registration Response (REG RSP) RKM     Deregistration Request (DEREG REQ) RKM     Deregistration Response (DEREG RSP) RKM

К сообщениям эксплуатационного управления (Management Messages) относится сообщение ERR-ошибка (Error) о том, что принято непредвиденное сообщение или сообщение с неверным содержимым, а также сообщение NTFY-уведомление (Notify) для передачи информации об определенных событиях, относящих­ся к M3UA. Например, сообщение NTFY можно использовать, чтобы информировать об изменении состояния в ASP. В состав сообщений эксплуатационного управления сетью сигнализации (Signaling Network Management Messages) M3UA входят: сообщение DUNA - адресат недоступен (Destination Unavailable), передаваемое из SG во все заинтересованные процессы ASP, чтобы уведомить их о недоступности пункта назначения в сети ОКС7, сообщение DAVA - ад­ресат доступен (Destination Available), которое в ASP преобразуется в примитив MTP-Resume indication, сообщение DAUD - проверка состояния пункта назначения (Destination State Audit), сообщение SCON о перегрузке сети ОКС7 (SS7 Network Congestion), сообще­ние DUPU - подсистема-пользователь в пункте назначения недо­ступна (Destination User Part Unavailable), которое в ASP отобража­ется в примитив MTP-Status indication, и сообщение DRST - доступ к пункту назначения ограничен (Destination Restricted).

В состав сообщений M3UA входят следующие сообщения эксплу­атационного управления состоянием ASP (ASP State Management Messages): ASPUP - ASP включен (ASP Up) и ASPUP ACK - под­тверждение включения ASP (ASP Up Acknowledgment), ASPDN - ASP выключен (ASP Down) и ASPDN ACK - подтверждение выключения ASP (ASP Down Acknowledgment), BEAT и BEAT ACK - сообщения о работоспособности (Heartbeat messages), а также сообщения экс­плуатационного управления трафиком ASP (ASP Traffic Management Messages), с помощью которых организуется передача трафика между SG и одним или несколькими ASP (распределение нагрузки), а также сообщения эксплуатационного управления ключами марш­рутизации (Routing Key Management Messages).