Исследования протокола M3UA. Лабораторная работа №11

1.

Лабораторная работа №11
Исследования протокола M3UA
Работу выполнили :
Студенты гр. С1-12
Ларев Владимир Николаевич
Трофимов Юрий Владимирович

2.

Цель работы:Исследовать протокол M3UA
Задание:
1.Изучить протокол
M3UA,функции,терминология,код пункта
сигнализации,примитивы,сообщения.

3.

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

4.

Softswitch на рис. может иметь код пункта сигнализации, отличный
от кода, который имеет SG. В этом случае SG работает подобно STP
и воспринимается внешней сетью ОКС7 как STP. Вне­шняя сеть ОКС7
рассматривает Softswitch как обычный оконечный пункт
сигнализации ОКС7, доступ к которому достигается через один или
несколько пунктов SG STP
Оконечный
пункт
сигнализации
Сигнальный
шлюз SG
IP
ОКС7
Пользоват
ель MTP3
MTP3
MTP
1,2
IP
ОКС7
Пользоват
ель MTP3
NIF
MTP3
MTP
1,2
Сигнальный
шлюз SG
M3UA
SCTP
IP
M3UA
SCTP
IP
Оконечный
пункт
сигнализации
NIF
M3UA
SCTP
IP
MTP3
MTP
1,2
Пользоват
ель MTP3
MTP3
MTP
1,2

5.

Терминология
Прежде чем мы перейдем к более подробному рассмотрению 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 для резервирования или для
разделения нагрузки).

6.

Ключ маршрутизации (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.

Код пункта сигнализации
Каждый 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

8.

Примитивы
Чтобы предоставлять услуги верхнему уровню прозрачно (так, чтобы приложение не
ощущало факт использования функций 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, таких как перегрузка
или недоступность под­системы-пользователя в пункте назначения

9.

Рассмотрим пример приложения ISUP в Softswitch, которому требуется
передать сообщение в сеть ОКС7. Приложение передает запрос MTPTransfer 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

10.

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

11.

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