МСС_К2_7
.pdfется, что РАТС сохраняются в качестве концентраторов абонентского трафика (рис. 4.4). Также сохранение РАТС упрощает размещение шлюзов соединительных линий TGW. Если в городе отсутствуют абоненты VoIP, то программный коммутатор работает только в режиме управления шлюзами MGC (Media Gateway Controller). Такое решение принято называть построением сети NGN
на базе MGC Class 4.
|
MGC |
ТфОП |
SIP-T |
|
к другим SX |
ОКС №7 |
SIGTRAN |
|
|
SGW1 |
TGW1 |
||
|
|||
H.248/MEGACO |
H.248/MEGACO |
|
|
TGW1 |
|
TGW3 |
|
|
|
||
РAТС1 |
|
|
|
H.248/MEGACO |
IP/MPLS |
|
|
|
|
||
TGW1 |
|
|
ОКС №7
РAТС3
РAТС2
Рисунок 4.4 Сеть NGN на базе MGC Class 4
Более радикальным является сценарий, при котором из телефонной сети города исключаются также устаревшие РАТС, которые по западной терминологии называются узлами 5-го класса
(Class 5).
Вэтом случае, на сети устанавливаются шлюзы доступа AGW,
вкоторые включаются УПАТС и мультисервисные узлы доступа MSAN с сигнализацией V 5.2 (рис. 4.5).
Аналоговые и цифровые абоненты включаются непосредственно в абонентские шлюзы RGW. Шлюзы доступа взаимодействуют с MGC по протоколу H.248/MEGACO, а сигнализация Q.931 передается в программный коммутатор с помощью протокола адаптации IUA (ISDN User Adaptation), входящего в состав группы протоколов SIGTRAN. Аналогично для транзита сигнализации V5.2 используется протокол V5UA. Абонентские шлюзы могут взаимодействовать с MGC по протоколам SIP или MEGACO. Такое решение обычно называется построением сети NGN на базе
71
MGC Class 5.
MGC
SIP-T
к другим SX
УПAТС
PRT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
AЛ |
|
|
|
|
V5.2 |
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
УПAТС |
SIGTRAN (IUA) |
|
|
SIGTRAN (IUA) |
PRT |
|
|
|
|
|
AGW |
|
SIP |
H.248/MEGACO |
|
|
MEGACO |
|
||
H.248/MEGACO |
|
|
|
|
|
|
IP/MPLS |
|
RGW
БД |
RGW |
|
AЛ |
AЛ |
БД |
БД |
|
Рисунок 4.5 Сеть NGN на базе MGC Class 5
Собственно вид сценария перехода от ТфОП к NGN на практике диктуется уровнем развития транспортной сети. Если междугородная сеть IP/MPLS конкретного оператора может обеспечивать передачу значительного телефонного трафика с соответствующим качеством обслуживания, то замена АМТС на MGC Class 4 происходит быстро и безболезненно. Замена устаревших РАТС (координатных, квазиэлектронных, электронных) является актуальной задачей для многих городов РФ, однако, для успешного перехода к NGN на базе MGC Class 5 требуется как хорошо развитая городская транспортная сеть, так и достаточный уровень развития широкополосной сети доступа. Только при наличии этих двух факторов замена РАТС на группу абонентских шлюзов и шлюзов доступа дает необходимый эффект. В работах [8, 12] достаточно подробно рассмотрены варианты перехода от ТфОП РФ к NGN с учетом особенностей построения существующих городских и сельских телефонных сетей, однако все они могут быть сведены
72
крассмотренным вариантам MGC Class 4 или Class 5.
4.4Функциональная схема программного коммутатора SX
Вкачестве аппаратной базы для построения SX обычно используется серверные платформы ведущих компаний производителей (Hewlett Packard, IBM...). Собственно характеристики платформы (производительность, объем дисковой памяти, наличие кластера) определяются требованиями по числу обслуживаемых вызовов в час наибольшей нагрузки (ЧНН) и по надежности.
Программное обеспечение SX формируется из стандартных модулей, которые составляют 3-х уровневую структуру (рис. 4.6). Основу этой архитектуры составляет ПО управления вызовами и сеансами (Call/Session Control), которое обеспечивает реализацию различных сценариев обработки вызовов и организации сеансов связи.
ПО управляющих процессов (менеджеров)
OAM |
VPN |
Location |
AAA |
Service |
Manager |
Manager |
Manager |
Manager |
Manager |
|
Call\Session Control |
|
Inter- |
||
|
|
|
|
|
Softswich |
|
|
|
|
|
Manager |
SS7 |
IPDC |
H.323 |
H.248 |
MGCP |
SIP |
Interface |
Interface |
Interface |
Interface |
Interface |
Interface |
Интерфейсы для протоколов
Рисунок 4.6 Архитектура программного обеспечения SX
Нижний уровень составляют программные модули поддержки различных интерфейсов:
∙стек протоколов ОКС №7;
∙программная поддержка протоколов управления шлюзами
MGCP, H.248/MEGACO;
∙программные реализации протоколов сигнализации для VoIP:
73
SIP, H.323.
Верхний уровень составляют так называемые функциональные менеджеры:
∙менеджер эксплуатации и техобслуживания;
∙менеджер виртуальных частных сетей;
∙менеджер расположения;
∙менеджер авторизации, аутентификации и тарификации;
∙менеджер служб.
Программные модули поддержки протокольных интерфейсов
(ОКС №7, MGCP, H.248/MEGACO, H.323, SIP) могут быть уни-
кальными разработками производителей SX, но чаще используются стандартные программные модули, поставляемые производителями серверных платформ (HP, IBM...).
Программные модули управления вызовами и сеансами всегда разрабатываются создателями SX с использованием различных вариантов операционной системы UNIX (True 64, LINUX..) и составляют основу ПО программного коммутатора.
Реализация законченного набора функций возложена на функциональные менеджеры.
Менеджер эксплуатации и техобслуживания (OAM Manager) обеспечивает круглосуточно возможность конфигурирования SX, мониторинга основных параметров функционирования программного коммутатора, а также поддержку процедур эксплуатации и техобслуживания.
Менеджер виртуальных частных сетей (VPN Manager) обеспечивает формирование и управления VPN сетями (см. также главу
7).
Менеджер расположения (Location Manager) расширяет возможности маршрутизации SX за счет оптимизации используемых маршрутов по критериям наименьшей цены или используемых ресурсов.
Менеджер авторизации, аутентификации и тарификации (AAA Manager) осуществляет процедуры авторизации и аутентификации абонентов. Он также формирует детальные тарификационные записи CDR (Call Detailed Records) по каждому осуществленному сеансу связи. Если для реализации этих функций используются выделенные платформы, то модуль взаимодействует с ними по протоколам RADIUS и LDAP.
74
Менеджер служб (Service Manager) обеспечивает взаимодействие между SX и серверами приложений, которые могут поддерживать функции трансляции номера (Number Translation), поддержки маршрутизации (Clearing House), функций авторизации и аутентификации (на выделенных платформах).
Менеджер внутренних процедур (InterSoftswitch Manager) обеспечивает поддержку процедур взаимодействия между отдельными программными модулями. Например, выполнение функции взаимодействия между абонентами VoIP c разными типами сигна-
лизации: SIP и H.323 (Inter Working Function).
Модульное построение ПО позволяет легко адаптировать его для конкретных сетевых проектов. Например, существенное снижение стоимости проекта возможно, если оператор планирует использовать SX только в режиме контроллера шлюзов MGC, поскольку не потребуется покупать ПО поддержки протокольных интерфейсов SIP и H.323. Точно также, если оператор планирует использовать SX только для управления сеансами VoIP абонентов, то ему не нужно приобретать ПО управления шлюзами. Кроме этого, модульная структура облегчает расширение функций SX за счет включения новых функциональных менеджеров.
Контрольные вопросы и задания
1.Перечислите основные функции программного коммутатора?
2.Укажите разницу в функциях разных типов транспортных шлюзов: TGW, AGW, RGW.
3.Может ли программный коммутатор MGS Class 4 управлять абонентскими шлюзами RGW?
4.В каком случае необходима реализация функции IWF?
5.Поясните, зачем в программном коммутаторе используется менеджер частных виртуальных сетей (VPN Manager)? (см. также главу 7).
75
Глава 5.
ПРОТОКОЛЫ ТРАНЗИТА СИГНАЛИЗАЦИИ SIGTRAN
Основой взаимодействия объектов сетей NGN с существующими сетями ТфОП остается сигнализация ОКС №7 [1, 4, 11]. Являясь наиболее развитой, а часто и единственной системой сигнализации между цифровыми коммутационными станциями как в сетях ТфОП, так и сетях связи с подвижными объектами стандарта GSM, данная система сигнализации вполне вписывается в идеологию сетей NGN по своей функциональности.
Однако, возникают существенные проблемы при практическом внедрении ОКС №7 в сети следующего поколения, поскольку вместо синхронного цифрового канала для передачи сигнальных сообщений приходится использовать пакетную сеть, в которой могут возникать как существенные задержки, так и потери пакетов. Для решения вопросов транспортировки сигнальных сообщений ОКС №7, DSS1 в IP-сетях и решения вопросов взаимодействия сетевых элементов (MGC, SGW) с центрами коммутации различных сетей с коммутацией каналов в рамках IETF была разработана группа протоколов SIGTRAN.
В соответствии с концепцией SIGTRAN, при обеспечении транзита сигнальных сообщений сами сообщения не изменяются, тогда как протоколы более низких уровней (1-3) заменяются на протоколы из мира IP. Между исходными уровнями сигнализации и IP-стеком появляются промежуточные протоколы, называемые в SIGTRAN протоколами адаптации. В зависимости от заменяемого уровня эти протоколы выполняют адаптацию на 2-ом, 3-ем или более высоких уровнях модели OSI. Кроме протоколов адаптации в концепции SIGTRAN используется специальный транспортный протокол управления потоками SCTP (Stream Control Transmission Protocol), обеспечивающий надежную доставку сигнальных сообщений.
5.1 Архитектура протоколов SIGTRAN
На рис. 5.1 представлен стек протоколов SIGTRAN. Как видно из рисунка, в стандартном стеке протоколов ОКС №7 протоколы адаптации могут заменять различные протоколы, начиная с МТР 2
76
и заканчивая SCCP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Протоколы OKC 7 |
|
|
|
|
|
MAP |
|
|
|
Протокол ISDN |
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Протоколы |
|
|
|
|
TCAP |
|
|
|
|
|
|
||||
адаптации |
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ISUP |
|
|
|
SCCP |
|
|
SUA |
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Q.931 MTP3
M3UA
MTP2 |
|
M2UA |
|
M2PA |
|
|
IUA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SCTP
Протоколы IP-
сети
MTP1
IP
Рисунок 5.1 Архитектура протоколов SIGTRAN
Для надежной передачи сигнальных сообщений через мультисервисные IP-сети используется стек SCTP/IP, который фактически заменяет гарантированную передачу сообщений по синхронному каналу (MTP1-2). Задачи преобразования передаваемой информации протоколов более высокого уровня к возможностям протокола SCTP решаются протоколами адаптации.
Протокол M2UA (MTP-2 User Adaptation Layer) обеспечивает передачу сообщений MTP-3 через канальный уровень таким образом, что MTP-3 не ощущает, что его пакеты передаются через стек SCTP/IP, а не через обычный MTP-2. При использовании этого протокола сигнальный шлюз не имеет своего кода сигнализации (Point Code) и других атрибутов 3-его уровня, которые реализуются непосредственно в программном коммутаторе (Softswitch). Протокол M2UA имеет зарегистрированный номер порта 2904.
Протокол M2PA (MTP-2 Peer-to-Peer Adaptation Layer) [3]
также обеспечивает передачу пакетов MTP-3 аналогично MTP-2. Однако, в случае использования этого протокола сигнальный шлюз выполняет функции транзитного пункта сигнализации ОКС №7 STP и, соответственно, имеет собственный код пункта сигнализации (Point Code), а также может выполнять функции более высоких уровней.
77
Протокол M3UA (MTP-3 User Adaptation Layer) обеспечивает передачу сигнальных сообщений ISUP и SCCP через стек SCTP/IP. Данный протокол не поддерживает некоторые стандартные функции MTP-3. Например, отсутствует часть функций эксплуатационного управления сетью.
Протокол SUA (SCCP User Adaptation Layer) обеспечивает передачу сообщений протокола MAP/TCAP через стек SCTP/IP с сохранением всех функций протокола SCCP (Signalling Connection Control Protocol).
Протокол IUA (ISDN Q.931 User Adaptation Layer) выполняет прозрачную передачу сигнальных сообщений протокола Q.931 через стек SCTP/IP, имитируя работу протокола канального уровня Q.921 в ЦСИС. Расширением протокола IUA является V5UA (V5.2 User Adaptation Layer), который обеспечивает поддержку универсального интерфейса доступа V5.2, построенного на базе расши-
рения Q.931/Q.921.
Содержимое рис. 5.1 наглядно показывает многовариантность выбора для построения стека протоколов SIGTRAN. Так, например, для поддержки надежной передачи сообщений ISUP могут использоваться следующие варианты:
1.ISUP/MTP-3/M2UA/SCTP/IP;
2.ISUP/MTP-3/M2PA/SCTP/IP;
3.ISUP/M3UA/SCTP/IP.
Каждый из представленных вариантов обладает своими преимуществами и недостатками. Однако обсуждение различных свойств представленных вариантов стеков протоколов SIGTRAN мы продолжим в параграфе 5.3 после более детального знакомства
спротоколом SCTP.
5.2Транспортный протокол с управлением потоками SCTP
Необходимость разработки нового транспортного протокола в рамках технологии SIGTRAN была вызвана особыми требованиями, которые предъявляет передача сигнальных сообщений к IPсетям. В первую очередь эти требования касаются строгих ограни-
78
чений на время передачи сигнальных сообщений, соблюдение их порядка и надежной доставки сообщений адресату. Несоблюдение этих требований будет приводить к сбоям сигнализации и, соответственно, к отказам в установлении соединений. Учитывая, что из 2-х широко известных транспортных протоколов UDP и TCP, только последний обеспечивает надежную доставку, приведем аргументы разработчиков SCTP [3], которые не позволили им использовать ТСР:
1.Протокол ТСР может вносить значительные задержки при передаче сегментов данных. Это происходит из-за того, что пока не осуществлена повторная передача потерянного сегмента, вся информация не может быть передана на обработку в вышележащий уровень. Такая ситуация называется бло-
кировкой начального сегмента (head-of-line blocking) и мо-
жет разрешаться разделением общего потока данных на отдельные потоки (streams), в пределах которых осуществляются раздельные процедуры восстановления сегментов. Аналогичная ситуация разрешается в современных браузерах путем открытия нескольких параллельных TCP сессий.
2.Протокол ТСР является байт-ориентированным. Деление на сегменты данных определяется только размером максимального блока MTU и никак не связано с размерами передаваемых сигнальных сообщений. Поэтому сигнальные приложения должны вставлять дополнительные разделители границ сообщений и использовать операцию push для своевременной отправки сигнальных сообщений.
3.Протокол ТСР не имеет встроенных функций обеспечения высокой надежности при сбоях на канальном уровне.
4.Протокол ТСР не имеет встроенных механизмов защиты от атак типа переполнения за счет поступления SYN (SYN flooding).
Таким образом, разработчики протокола SCTP (RFC 2960) постарались решить перечисленные проблемы ТСР в своем новом транспортном протоколе. Рассмотрим последовательно основные свойства протокола SCTP как надежной транспортной среды передачи сигнальных сообщений SIGTRAN.
79
Важнейшей особенностью протокола SCTP является возможность использования множественной адресации. В этом случае, каждому объекту может присваиваться несколько IP-адресов (multihoming) с одним и тем же номером порта. Один IP-адрес считается активным (primary), а остальные резервными (secondary). Если активный адрес становится недоступным, то используются другие транспортные адреса из списка резервных. Этим существенно повышается надежность передачи сигнальных сообщений. Использование множественной адресации наглядно представлено на рис. 5.2.
Клиент |
|
Клиент |
|
TCP |
|
TCP |
|
port |
IP - cеть |
port |
|
IP |
|
IP |
|
|
TCP-соединение |
|
|
Клиент |
|
Клиент |
|
SCTP |
|
||
IP - cеть |
SCTP |
||
|
|||
IP |
|
IP |
|
Port |
|
Port |
|
IP |
|
IP |
Ассоциация SCTP
Рисунок 5.2 Множественная адресация и ассоциации SCTP
В отличие от TCP в рамках протокола SCTP вводится понятие не соединения, а ассоциации (association) между двумя узлами. В рамках ассоциации могут использоваться несколько сетевых интерфейсов с различными IP-адресами. При этом, ассоциации соответствует один номер порта. Каждый интерфейс в принципе может
80