Протокол SUA

SUA - протокол транспортировки информации SCCP через сеть IP (Transporting SCCP over IP) определен рабочей группой Sigtran для транспортировки по сети IP с использованием SCTP сигналь­ных сообщений подсистемы SCCP стека ОКС7 (несущих, в первую очередь, информацию TCAP и RANAP). В сущности, SUA дублирует услуги SCCP путем поддержки надежной пересылки сообщений пользователя SCCP, включая поддержку услуг как без соединения (класс 0 и 1), так и ориентированных на соединение (класс 2 и 3). SUA поддерживает также услуги эксплуатационного управления SCCP, предназначенные для управления состоянием удаленных пунктов назначения и подсистем SCCP. Кроме того, в некоторых конфигурациях SUA выполняет еще и функции преобразования ад­реса и маршрутизации.

Таким образом, протокол SUA обеспечивает взаимодействие с сетью ОКС7 на более высоком уровне, чем это делает M3UA (и, тем более, M2UA, M2PA). В сигнальном шлюзе завершают работу (терминируются) протоколы МТР и SCCP, а до ASP передается лишь полезное содержимое сообщений SCCP. Протокол SUA имеет за­регистрированный IANA номер порта 14001. Он имеет также заре­гистрированный IANA идентификатор протокола полезной нагрузки SCTP, равный 4.

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

Оконечный пункт сигнализации

Оконечный пункт сигнализации

Сигнальный шлюз SG

ОКС7

Сигнальный шлюз SG

ОКС7

IP

Пользова­тель SUA

IP

Пользова­тель SUA

Пользова­тель SUA

SUA

MTP 1, 2, 3

SCTP

IP

SCCP

MTP 1, 2, 3

MTP3

SCCP	SUA
MTP 1, 2, 3	SCTP
IP

NIF = узловая функция взаимодействия

SUA	SCCP
SCTP	MTP 1, 2, 3
IP

Рис.7.12. Функции SUA в Softswitch

Заметим, что при распределении нагрузки, создаваемой сооб­щениями TCAP, выбор оконечного пункта пересылки происходит только для первого сообщения в диалоге TCAP. Следующие сооб­щения в том же диалоге TCAP всегда передаются в оконечный пункт, который выбран для первого сообщения, пока не будет получена информация о состоянии оконечных пунктов, и сигнальный шлюз не будет информирован о стратегии распределения сообщений оконечных пунктов IP.

Формат общего заголовка сообщения и TLV, ранее определен­ный для M3UA, в равной мере применяется и для SUA. В табл. 7.3 приводится список классов и типов сообщений SUA.

Таблица 7.3. Классы и типы сообщений SUA Код класса сообщения Наименования класса и типа сообщения Код типа сообщения   Management (MGMT) messages     Error message     Notify message     SS7 Signaling Network Management (SSNM) messages     Destination Unavailable (DUNA)     Destination Available (DAVA)     Destination State Audit (DAUD)     Signaling Congestion (SCON)     Destination User Part Unavailable (DUPU)     Destination Restricted     ASP State Maintenance (ASPSM) messages     ASP Up     ASP Down     Heartbeat     ASP Up Acknowledge     ASP Down Acknowledge     Heartbeat Acknowledge     ASP Traffic Maintenance (ASPTM) messages     ASP Active     ASP Inactive     ASP Active Acknowledge     ASP Inactive Acknowledge     Connectionless (CL) Messages     Connectionless Data Transfer (CLDT)     Connectionless Data Response (CLDR)     Connection-oriented (CO) messages     Connection Request (CORE)     Connection Acknowledge (COAK)     Connection Refused (COREF)     Release Request (RELRE)     Release Complete (RELCO)     Reset Confirm (RESCO)     Reset Request (RESRE)     Connection-oriented Data Transfer (CODT)     Connection-oriented Data Acknowledge (CODA)     Connection-oriented Error (COERR)     Inactivity Test (СОИ)     Routing Key Management (RKM) messages     Registration Request     Registration Response     Deregistration Request     Deregistration Response

13. Б.С. Гольдштейн

Сообщения без соединения используются для трафика класса 0

и класса 1 протокола.

Существуют два сообщения без соединения: CLDT и CLDR:

• Сообщение Connectionless Data Transfer соответствует сооб­щениям unitdata (UDT), extended unitdata (XUDT) и long unitdata (LUDT) в SCCP. Оно используется для пересылки данных между одноранговыми SUA для трафика класса 0 и класса 1.

• Сообщение Connectionless Data Response соответствует сооб­щениям услуги unitdata (UDTS), услуги extended unitdata (XUDTS) и услуги long unitdata (LUDTS) в SCCP. Оно передается как ответ в CLDT, чтобы информировать об ошибках в сообщении CLDT, если используется соответствующая опция.

Сообщения, ориентированные на соединение, используются для

трафика протокола класса 2 и класса 3:

• Connection Request (CORE) используется, чтобы запросить сиг­нальное соединение между двумя оконечными пунктами. Это сообщение соответствует сообщению Connection Request (CR) в SCCP.

• Connection Acknowledgement (COAK) используется для положи­тельного ответа на Connection Request. Это сообщение соот­ветствует сообщению Connection Confirm (CC) в SCCP.

• Connection Refusal (COREF) используется для отрицательного ответа на запрос Connection Request. Это сообщение соответс­твует сообщению Connection Refusal (CREF) в SCCP.

• Connection-oriented Data Transfer (CODT) используется для пе­редачи данных по сигнальному соединению. Оно соответствует сообщениям Data Form 1 (DT1), Data Form 2 (DT2), и Expedited Data (ED) в SCCP.

• Connection-oriented Data Acknowledgement (CODA) используется одноранговым оконечным пунктом для подтверждения получе­ния данных. Это сообщение используется только для сообще­ний протокола класса 3. Оно соответствует сообщению Data Acknowledgement (AK) в SCCP.

• Release Request (RELRE) используется для запроса разрушить сигнальное соединение. Это сообщение соответствует сообще­нию Connection Released (RLSD) в SCCP.

• Release Complete (RELCO) используется для подтверждения разрушения сигнального соединения. Все ресурсы, отведенные соединению, должны быть освобождены. Это сообщение соот­ветствует сообщению Release Complete (RLC) в SCCP.

• Reset Request (RESRE) используется для запроса начать заново присвоение порядковых номеров сообщениям в пункте-отпра­вителе и в пункте-получателе, которые ассоциированы с сиг­нальным соединением. Это сообщение соответствует сообще­нию Reset Request (RSR) в SCCP.

• Connection-oriented Error (COERR) используется для того, чтобы указать, что в протокольном блоке данных была ошибка. Это со­общение соответствует сообщению Protocol Data Unit Error (ERR) в SCCP.

• Connection-oriented Inactivity Test (COIT) соответствует сообще­нию Inactivity Test (IT) в SCCP.

SUA поддерживает те же сообщения MGMT, что и M3UA, но предоставляет также информацию о состоянии подсистемы SCCP. Сообщения DUNA, DAVA, DRST, SCON и DAUD могут опционально содержать номер подсистемы SubSystem Number (SSN). Кроме того, сообщения DUNA, DAVA, DRST и SCON могут опционально со­держать параметр SubSystem Multiplicity Indicator (SMI).

SUA поддерживает те же сообщения RKM, что и M3UA, но пара­метр Routing Key отличается тем, что он содержит опции для адре­сов источника и пункта назначения и для диапазонов адресов.

В заключение отметим, что, с одной стороны, за счет терминиро­вания в сигнальном шлюзе «лишнего» протокола достигается более эффективное использование полосы пропускания IP-сети, но, с другой стороны, по этой же причине теряется возможность пере­дачи через SUA информации протокола ISUP, так как для адресации SUA использует уровень МТРЗ ОКС7.

Сигнальный шлюз может выполнять преобразование глобаль­ных адресов GTT (Global Title Translation) для определения пункта назначения сообщения SCCP. Сигнальный шлюз маршрутизирует сообщения по глобальному адресу, который представляет собой такие цифры, присутствующие во входящем сообщении, как номер вызываемой стороны или идентификационный номер мобильного абонента. Для транспортировки сообщений, ориентированной на соединение, SCCP и SUA сопрягаются в сигнальном шлюзе, чтобы объединить два участка соединения, необходимых при ориентиро­ванной на соединение пересылке данных между оконечным пунк­том сигнализации ОКС7 и оконечным пунктом IP. Маршрутизация сообщений производится сигнальным шлюзом к сигнальным пунк­там ОКС7 на основе кода пункта назначения (в поле адреса MTP3) и к оконечным пунктам IP на основе IP-адреса (в заголовке SCTP).

7.8. Протокол IUA

В ISDN сигнальную информацию пользователя, например, со­общения Q.931, переносит звеньевой уровень Q.921. Эквивален­тной спецификацией Sigtran в сети IP является IUA. Кадры Q.921 могут пропускаться из ISDN в сеть IP с идентичными реализациями Q.931 в каждой сети, причем ни одна из них не распознает никаких различий в лежащей в основе транспортировке. Протокол IUA оп­ределен в документе RFC 3057 для поддержки протоколов Q.931 и QSIG, причем, эта поддержка распространяется как на доступ ISDN на первичной скорости (PRA), так и на базовый доступ ISDN (BRA). Предложены также расширения IUA для DPNSS/DASS2. Регистра­ционный номер порта для IUA равен 9000.

7.9. Протокол V5UA

Универсальный интерфейс сети доступа V5.2 поддерживает подключение к местной АТС аналоговых телефонных линий, доступ ISDN на базовой скорости, доступ ISDN на первичной скорости и абонентский доступ других типов, как это описано в [5] и, более де­тально, в [11]. Т.к. в процессе конвергенции сетей связи и перехода к NGN местные АТС заменяются управляемыми Softswitch медиа- шлюзами, то между системой доступа и Softswitch понадобится SG, как показано на рис. 7.13. Протокол V5UA дает возможность прило­жениям V5.2 в Softswitch использовать в шлюзе SG на стороне сети доступа собственные функции V5.2. Протокол V5UA имеет регист­рационный номер порта 5675.

Оконечный NIF = узловая функция взаимодействия Рис. 7.13. Функции V5UA в Softswitch