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
|
К сообщениям эксплуатационного управления (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).