Архитектура сети, базирующейся на протоколе MGCP

Протокол контроля медиашлюзов. Является протоколом связи в распределённых VoIP системах передачи голоса по протоколу IP.

Протокол предложен рабочей группой MEGACO (Media Gateway Control Protocol) комитета IETF.

Основная идея MGCP очень проста. Она состоит в том, что управление сигнализацией (Call Control) сосредоточено на центральном управляющем устройстве, называемом контроллером сигнализаций (Call Agent, CA), и полностью отделено от медиа-потоков. Эти потоки обрабатываются шлюзами или абонентскими терминалами, которые способны исполнять лишь ограниченный набор команд, исходящих от управляющего устройства. В архитектуре протокола MGCP-сети можно выделить два основных функциональных компонента. Первый может быть представлен транспортным шлюзом (Media Gateway, MG) или IP-телефоном, а второй - устройством управления вызовами, которое может называться контроллером сигнализаций (CA), контроллером шлюза (Media Gateway Controller, MGC) или программным контроллером (Softswitch, SS). Иногда контроллер сигнализаций представляют в виде двух компонентов - собственно контроллера (Call Agent), выполняющего функции управления шлюзами, и шлюза сигнализации (Signaling Gateway), обеспечивающего обмен сигнальной информацией и согласование между традиционной телефонной сетью и сетью IP.

При разработке протокола управления шлюзами рабочая группа MEGACO опиралась на принцип декомпозиции, согласно которому шлюз разбивается на отдельные функциональные блоки :

• транспортный шлюз - Media Gateway, который выполняет функции преобразования речевой информации, поступающей со стороны ТфОП с постоянной скоростью, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP: кодирование и упаковку речевой информации в пакеты RTP/UDP/IP, а также обратное преобразование;

• устройство управления - Call Agent, выполняющее функции управления шлюзом;

• шлюз сигнализации - Signaling Gateway, который обеспечивает доставку сигнальной информации, поступающей со стороны ТфОП, к устройству управления шлюзом и перенос сигнальной информации в обратном направлении.

4.2.4 Протокол MEGACO/H.248

Рабочая группа MEGACO комитета IETF, продолжая исследования, направленные на усовершенствование протокола управления шлюзами, создала более функциональный (по сравнению с рассмотренным протоколом MGCP) протокол MEGACO. Но разработкой протоколов управления транспортными шлюзами, кроме комитета IETF, занималась еще и исследовательская группа SG 16 Международного союза электросвязи. Важной особенностью нововведения ITU-T явилось то, что управление транспортными шлюзами - Media Gateway (MG) - осуществляется контроллером транспортных шлюзов - Media Gateway Controller (MGC) - при помощи протокола MEGACO, адаптированного под сетевое окружение Н.323. Спецификации адаптированного протокола приведены в недавно утвержденной рекомендации ITU-T H.248. На рис. представлено дерево эволюции протокола MEGACO/H.248.

Рассмотрим кратко основные особенности протокола MEGACO/ H.248. Для переноса сигнальных сообщений MEGACO/H.248 могут использоваться протоколы UDP, TCP, SCTP или транспортная технология ATM. Поддержка для этих целей протокола UDP - одно из обязательных требований к контроллеру шлюзов. Протокол TCP должен поддерживаться и контроллером, и транспортным шлюзом, а поддержка протокола SCTP, так же, как и технологии ATM, является необязательной.

Еще одной особенностью протокола MEGACO/H.248 является то, что сообщения этого протокола могут кодироваться двумя способами. Комитет IETF предложил текстовый способ кодирования сигнальной информации, а для описания сеанса связи предложил использовать протокол SDP. ITU-T предусматривает бинарный способ представления сигнальной информации - ASN. 1, а для описания сеансов связи рекомендует специальный инструмент - Tag-length-value (TLV). Контроллер шлюза должен поддерживать оба способа кодирования, в то время как шлюз - только один из этих способов.

4.2.5 Протокол BICC

Протокол BICC

Для взаимодействия Softswitch между собой теоретически должен применяться протокол BICC (Bearer Independent Call Control), разработанный МСЭ. И хотя на практике более популярным становится второй протокол – SIP (SIP-T), разработанный IETF, протокол BICC успешно используется до сих пор.

При разработке данного протокола обязательным требованием являлась поддержка сигнальных сообщений ISUP, поскольку протокол должен был облегчить операторам переход к ССП и обеспечить взаимодействие новой мультисервисной сети с существующими сетями ISDN. Фактически протокол BICC рассматривался как еще одна прикладная подсистема сигнализации ОКС7, обеспечивающая экономичный переход к мультисервисной сети с сохранением большей части сигнального оборудования ISUP сетей с временным разделением каналов TDM. В свое время данный протокол позволил операторам, не желавшим вкладывать инвестиции в дальнейшее развитие TDM-сетей, предоставлять уже существующие услуги ТфОП/ISDN в пакетных сетях, а также поддерживать взаимодействие имеющихся узлов коммутации TDM узлами пакетной сети и взаимодействие узлов коммутации TDM через пакетную сеть.

Архитектура BICC предусматривает, что вызовы будут входить в сеть и выходить из нее с поддержкой BICC через интерфейсы узлов обслуживания – Interface Serving Nodes (ISN), – предоставляющие сигнальные интерфейсы между узкополосной ISUP (сетью ТфОП/ISDN с коммутацией каналов) и одноранговым узлом ISN (находящимся в пакетной сети). Также определены:

• транзитный узел обслуживания (Transit Serving Node (TSN)) – этот тип узла обеспечивает транзитные возможности в пределах одной сети. Служит для обеспечения возможности предоставления услуги ТфОП/ISDN внутри своей сети;
• пограничный узел обслуживания (Gateway Serving Node (GSN)) – этот тип узла обеспечивает выполнение функций межсетевого шлюза для информации вызова и транспортировки, используя BICC-протокол. Обеспечивает соединение двух областей BICC, принадлежащих двум разным операторам, и это соединение состоит из двух узлов GSN, непосредственно связанных друг с другом.

На рисунке представлены узлы всех рассмотренных типов. Имеются также промежуточные коммутаторы, через которые тракт проключается при помощи сетевой сигнализации. Эти коммутаторы характерны для сетей АТМ и в терминах BICC называются узлами ретрансляции носителя – Bearer Relay Nodes (BRN) или коммутирующими узлами – Switching Nodes (SWN), но не все сетевые технологии требуют их наличия.

4.2.6 Протокол SIGTRAN

Архитектура протоколов SIGTRAN

Название образованно от слов signaling и transport .

Транспортировка информации сигнализации по технологии SIGTRAN предназначена для передачи сообщений протокола сигнализации сети с коммутацией каналов через сеть с коммутацией пакетов и должна обеспечивать:

1. передачу сообщений разнообразных протоколов сигнализации, обслуживающих соединения сетей с коммутацией каналов (CSN), например протоколов прикладных и пользовательских подсистем ОКС7 (включая уровень 3 МТР, ISUP, SCCP, TCAP, MAP, INAP и т. д.), а также сообщений уровня 3 протоколов DSS1/PSS1 (т. е. Q.931 и QSIG);
2. средства идентификации конкретного транспортируемого протокола сигнализации сети с коммутацией каналов;
3. общий базовый протокол, определяющий форматы заголовков, расширения в целях информационной безопасности и процедуры для транспортировки сигнальной информации, а также (при необходимости) расширения для введения конкретных индивидуальных протоколов сигнализации сети с коммутацией каналов;
4. функциональные возможности (с участием нижележащего сетевого протокола, например IP), соответствующие нижнему уровню конкретной сети с коммутацией каналов.

Все протоколы передачи ОКС7 через IP, разрабатываемые группой SIGTRAN, используют в качестве транспорта протокол SCTP (Stream Control Transmission Protocol) с его широкими возможностями по обеспечению отказоустойчивости. Функционально протокол SCTP заменяет уровни MTP1 и MTP2 в традиционной архитектуре ОКС7.

Протокол передачи информации управления потоком (SCTP) обеспечивает транспортировку сообщений сигнализации через сеть IP между двумя оконечными пунктами, с избыточностью доставки информации и повышенной степенью надежности. Для этого применяется стандартизованный метод, отличающийся встраиванием в протокол повышенной надежности доставки в реальном времени информации от нескольких источников по нескольким информационным потокам.

Также обеспечивается самоотключение в случае перегрузки соединения Интернет, по которому функционирует этот протокол. Интерфейс между SCTP и его сигнальными приложениями управляется через адаптационные уровни, которые образуют промежуточный уровень таким образом, чтобы сигнальные протоколы высших уровней конкретной архитектуры стека протоколов не меняли свой интерфейс с транспортной средой и внутренние функциональные возможности, когда начинают использовать SCTP вместо другого транспортного протокола. Другой аспект состоит в том, что поддерживаемая архитектура стека протоколов согласована с архитектурой Интернет без нарушения собственных правил.

Услуги в NGN