3. Архитектура и свойства сетей ENGINE

Настоящий размах в применении описанного выше концепта ожидается с более массовым использованием технологий VoIP (Voice over IP- Речь по сети Интернет) и третьей генерации универсальной системы мобильной связи 3G/UMTS, с самого начала основанных на этом концепте. Однако и в эволюции сетей PSTN/ISDN модель ENGINE также будет очень значительной. Первое решение ENGINE, которое своей архитектурой и функциями полностью приспособлено выше описанной горизонтальной модели, появилось под названием ENGINE Bridgеhead Network (EBN). Преемник EBN, ENGINE Integral Network (EIN), является дальнейшим улучшением, что касается поддержки открытых стандартов и увеличения емкости. Все дальнейшие ссылки, относящиеся на решения ENGINE для миграции стационарных телефонных сетей, подразумевают функциональные возможности, охваченные решениями EIN.

3.1. Архитектура

Согласно модели, решение EIN состоит из нескольких компонентов (рис.4.):

• Сервер речевой нагрузки или телефонный сервер (TeS – Telephony Server)
• многофункциональный шлюз доступа (MSG – Multiservice Gateway)
• быстрая пакетная опорная сеть (например, фирмы Эрикссон PBN – Packet Backbone Network)
• устройства доступа (AN – Access Node), подобно Access Ramp и т.п.
• система надзора и управления.

Центральное место в архитектуре EIN занимает опорная сеть, задачей которой является обеспечение поддержки для режима асинхронной передачи АТМ (Asynchronous Transfer Mode) и передачи IP большой емкости. Решение EIN, для обеспечения высокого качества речевой телефонной услуги, использует АТМ как технологию передачи, т.к. и в настоящее время, несмотря на быстрый темп развития, “чистые“ сети IP не в состоянии предоставить качество услуги (QoS - Quality of Service), требуемое для массовой передачи речевой информации и других типов услуг, в реальном времени. По сегодняшней оценке считается, что действительный переход к сети IP произойдет приблизительно в 2010 году. Одновременная поддержка для пакетной опорной сети Интернет IP позволяет интеграцию остальных услуг и является подготовкой для окончательного перехода традиционной речевой технологии к технологии VoIP.
Основным требованием к пакетной опорной сети является поддержка АТМ со всеми классами услуг, с особым акцентом на услуги в реальном времени, и интеграция с IP, по возможности со встроенной поддержкой для маршрутизации на основании замены меток (MPLS - Multiprotocol Label Switching).
Например, услуга передачи с постоянной скоростью (CBR – Constant Bit Rate) и услуга передачи с переменной скоростью осуществляются в реальном времени (VBR rt – Variable Bit Rate real time).
С опорной сетью со стороны сетей доступа соединяются многофункциональные шлюзы доступа MSG, которые служат для разнообразных целей:

• приспосабливают речевую нагрузку из формата TDM в пакетный;
• прозрачно (transparent) отправляют PSTN/ISDN сигнализацию дальше к серверу TeS;
• зачинают установление и разъединение соединения внутри опорной пакетной сети (или внутри самого MSG) в соответствии с директивами из TeS;
• приспосабливают остальные типы нагрузки (ATM, IP, Frame Relay, TDM) к передаче в пакетной опорной сети.

Сервер TeS соответствует управляющим серверам в основной модели, в нем собраны функции сигнализации к сетям PSTN/ISDN, анализа вызова и маршрутизации, а также управление шлюзами MSG.
В решении EIN потоки сигнализации и пользовательской информации отделены друг от друга, сигнализация через MSG направляется к телефонному серверу TeS, а речевой канал устанавливается в виде виртуального канала по пакетной опорной сети между оконечными многофункциональными шлюзами доступа.
На рис.5. представлен процесс установления вызова в сети EIN. Оконечные точки соединения здесь местные телефонные станции, точнее абоненты подключенные к ним. Когда абонент А потребует установление соединения, его станция, используя стандартную сигнализацию части пользователя цифровой сети с интеграцией служб ISUP, потребует от сервера TeS установление вызова через сеть EIN. При этом сигнальный канал полностью прозрачно переносится к серверу TeS в виде виртуального канала емкости 64 кбит/с. С точки зрения системы сигнализации SS7 (Signalling System №7) в сети EIN сигнальными узлами являются только серверы TeS. После принятия ISUP сообщений сервер TeS выполнит анализ направлений и определит направление вызова. Эта часть функциональности непосредственно унаследована из традиционной системы АХЕ. В нашем примере вызов нужно направить к станции назначения, точнее к шлюзу MSG, принадлежащему домену, который контролирует другой TeS. По этой причине исходящий сервер TeS использует сигнализацию BICC (Bearer Independent Call Control - протокол управления вызовом независимо от носителя), чтобы от сервера места назначения мог потребовать информацию о том, к какому шлюзу MSG нужно направить вызов.
После определения адреса назначения исходящий сервер TeS, используя сигнализацию Н.248, налагает исходящему многофункциональному шлюзу доступа установление вызова по пакетной опорной сети к шлюзу назначения MSG. Подобным образом, но без использования сигнализации BICC, устанавливается вызов между двумя MSG внутри одного домена или даже внутри одного многофункционального шлюза доступа. Та же модель действительна и в случае, если оконечные устройства используют какую-то другую сигнализацию, поддерживаемую в EIN. Таким методом устанавливается несущий канал между двумя MSG, а обмен управляющей информацией выполняется между двумя серверами TeS.

3.2. Протоколы и интерфейсы в сетях ENGINE

Как уже ранее было подчеркнуто, EIN использует открытые стандартные протоколы, которые приняты всеми важными производителями и операторами.

3.2.1 Протоколы между сетью доступа с TDM и сетью EIN (MSG)

Решение EIN поддерживает дальнейшее сохранение существующих устройств доступа, узлов PSTN/ISDN (местные и транзитные станции). Поэтому в EIN поддержаны все важные современные протоколы из сетей PSTN/ISDN:

• ISUP, согласно многочисленным спецификациям международной организации ITU-T, для связи с существующими местными, междугородными и международными станциями, коммутационными узлами/шлюзами мобильных сетей MSC/GMSC и т.п.;
• Интерфейс первичной скорости передачи ISDN PRI (Primary Rate Interface) и сигнализацию (E)DSS1 (Digital Signalling System 1) для взаимосвязи частных учрежденческих станций (ISPBX – Integrated Services Private Branch Exchange);
• V5.2ML (Multilink) для подключения концентраторов / мультиплексоров доступа;
• RSS сигнализация, для поддержки существующих удаленных абонентских ступеней без использования местных станций АХЕ.

Все эти протоколы прозрачно переносятся, через шлюз MSG и пакетную опорную сеть, к серверу TeS и для всех перечисленных устройств нет никакой разницы по сравнению с соединением в традиционной сети PSTN/ISDN. Нужно напомнить, что более старые протоколы, типа TUP (Telephony User Part- Часть телефонного пользователя) или CAS/R2 (Channel Associated Signalling- Сигнализация по выделенному каналу) не поддерживаются в сети EIN. Если требуется поддержка для этих протоколов, некоторые из существующих более старых станций могут послужить как преобразователи сигнализации.
Возможно применение и специализированных преобразователей сигнализации, например, из CAS/R2 в V5.2, но такие устройства не являются частью стандартного пакета ENGINE.
Физические интерфейсы находятся на многофункциональном шлюзе доступа и выполнены в виде структуры E1/G.703 (30 х 64 кбит/с речевых каналов + по одному каналу для синхронизации и сигнализации). Кроме отдельных первичных каналов Е1, шлюз MSG может принять и Е1 притоки, упакованные в 155 Мбит/с синхронный транспортный модуль первого уровня STM-1, который содержит 63 х Е1 первичных каналов. Этот второй способ особенно выгодный, т.к. существенно уменьшает поверхность (footprint), занимаемую шлюзом MSG и мультиплексором TDM, подключенным к нему.

3.2.2 Коммуникация между сервером TeS и шлюзом MSG – H.248/MEGACO

После принятия запроса на установление вызова и выполнения анализа и маршрутизации, сервер TeS посылает исходящему шлюзу доступа MSG директиву об установлении соединения и при этом использует протокол H.248/MEGACO, общепринятый для такого применения во всех пакетных речевых сетях – VoIP, 3G и тому подобным. Предшественником сигнализации H.248 был протокол MGCP, разработанный организацией IETF (Internet Engineering Task Force - Группа инженерной поддержки сети Интернет), а который все еще используется в подобных решениях других изготовителей. Протокол MGCP послужил как образец для совместной работы IETF и ITU-T, а результат их работы совместный протокол H.248 (или RFC 3015). От протокола MGCP (RFC 2885 и RFC 2886) отказались обе организации.
Протокол, прежде всего предназначенный для управления мультимедийными приложениями, H.248/MEGACO первоначально был определен для передачи сигнализации с помощью протоколов UDP (User Datagram Protocol- Дейтаграммный протокол пользователя) и ТСР (Transport Control Protocol - Протокол управления передачей), или передачи по сетям Интернет IP. Существует возможность определения дополнительных транспортных протоколов, так в ENGINE протокол H.248 для режима асинхронной передачи АТМ используется SAAL (Signalling ATM Adaptation Layer – Уровень адаптации сигнализации АТМ). Кроме IP и АТМ, протокол H.248 содержит определяющие элементы для применения сетей с технологией ретрансляции кадров Frame Relay для мультимедийной коммуникации. Таким образом, охвачены практически все способы для построения мультимедийных сетей, используемые в настоящее время.
Определено два способа кодирования сообщений H.248 – текстовый и бинарный. Кроме того, надежность, одна из возможностей, может быть улучшена добавлением заголовка приложения АН (Application Header). AH чаще всего используется вместе с защитными механизмами, подобно IPSec.
Протокол H.248 в своей первоначальной версии поддерживает, и протоколы IРv4 и IРv6, что значительно расширяет его применяемость и облегчает миграцию сетей IP к IРv6, которая ожидается с ростом популярности мобильной сети Интернет и вообще мобильных сетей третьей генерации.
Протокол H.248 используется для управления одним или несколькими сопрягающими / классическими шлюзами доступа, точнее, передачи управляющей информации между внешним управляющим устройством сопрягающего шлюза доступа (MGC – Media Gateway Controller), в котором находится вся логика для маршрутизации и установления вызова (в таком случае это сервер TeS), и сопрягающим шлюзом доступа, который выполняет действительное установление вызова. При этом нужно иметь в виду, что протокол H.248 не определяет способы и кодирование данных пользователя (например, телефонного вызова) и их передачу по сети. В терминологии H.248 для управляющего шлюза доступа MGC используется еще одно название “Call Agent” (рис.6.).
В терминологии протокола H.248 содержатся следующие основные понятия: “context” – контекст и “termination”- окончание.
Под понятием “termination”- окончание, подразумевается крайняя точка соединения и она может быть физическая, например, один канал 64 кбит/с в потоке Е1(2048 кбит/с), или логическая, которая создается при установлении соединения. Особый тип окончания “ROOT”, представляет собой сопрягающий шлюз доступа в целости.
“Сontext” – контекст, представляет собой соединение между окончаниями и описывает топологию, смешение и адаптацию сопрягающих элементов, а также способ коммутации, если контекст содержит больше двух окончаний (например, при соединении точка - много точек).
Особый тип контекста, так называемый нулевой контекст (“NULL CONTEXT”), содержит все окончания, которые не используются в данный момент. В нулевом контексте нет соединений между окончаниями, однако, можно генерировать сигналы и регистрировать события на них.
Существуют несколько сценариев, в которых применяется H.248:

• на переходе из среды «классической» телефонии в пакетную среду, т.е. для управления сопрягающим шлюзом доступа на границе TDM/ATM и TDM/IP (рис.7. и рис.8.);
• на границе между двумя пакетными мультимедийными сетями, для управления функциями межсетевой защиты, т.н. брандмауэра (firewall), или доступом в сеть и выходом из нее (рис. 9.);
• для управления услугами конференц-связи (рис.10.).

Типичными представителями клиентов H.248 являются:

• Сопрягающий шлюз доступа, подобно шлюзам, применяемым в решении ENGINE.
• Узкополосный сервер доступа NAS (Narrowband Access Server), подобно модемским серверам (Tigris) и т.п.
• Резидентные устройства доступа, подобно резидентному цифровому шлюзу DRG (Digital Residential Gateway).
• IP телефоны с H.248 клиентом (в этом случае пока неизвестно победит ли H.248 или H.323 и SIP).

Первая модель была применена в решении ENGINE, а следующие реализации стандарта (Unified VoIP, ENGINE Multi-Media) расширят диапазон применений H.248.
В применении H.248 важно иметь в виду, что одно управляющее устройство сопрягающего шлюза доступа может управлять несколькими сопрягающими шлюзами доступа, а одним сопрягающим шлюзом доступа может управлять только одно управляющее устройство. Однако, можно определить сопрягающий шлюз доступа таким образом, что в случае неисправности первичного управляющего устройства управление переносится на вторичное устройство.
По этой причине сети ENGINE разделены на домены, или группы многофункциональных шлюзов доступа, а каждой такой группой управляет отдельный сервер TeS. Если нужно установить вызов между двумя доменами, прежде всего, должна быть установлена взаимосвязь между двумя или несколькими серверами TeS с применением протокола Q.1901 (BICC). Затем каждый сервер TeS, используя H.248, посылает требование об установлении вызова к шлюзу MSGw в своем домене.
В решении EIN сервер TeS использует особый элемент – логику сопряжения ML (Mediation Logic) для передачи сигнализации H.248 к группе MSG/MGW шлюзов, которыми управляет.

3.2.3 Коммуникация между двумя серверами TeS

Как представлено на рис. 4., в сетях EIN может быть несколько серверов TeS. Каждый из них управляет группой многофункциональных шлюзов доступа, т.е. доменом. Если нужно установить вызов между многофункциональными шлюзами, принадлежащими разным доменам, коммуникация между управляющими ими серверами TeS будет выполняться с помощью сигнализации Q.1901 (BICC).
В стандарте Q.BICC СS1 (Bearer Independent Call Control Capability Set 1- Возможности управления вызовом независимо от носителя, набор 1) одобренном международной организацией ITU-T, как производной из протокола ISUP (ISDN user protocol – протокол пользователя сети ISDN), установление и контроль вызова отделены от управления над носителем, которым вызов устанавливается. Таким способом выделенное управление вызовом применимо для передачи речи по сети АТМ (согласно СS1), а позднее и в сетях IP (с усваиванием СS2 - Q.1902 спецификации).
Между организациями по стандартам и влиятельными группами промышленников существуют несколько приступов такому разделению, самый известный среди которых – архитектура MEGACO, которую предлагает Группа инженерной поддержки сети Интернет IETF - статья объявлена в нашем журнале Revija 13 (2001) 1.
В структуре концепта ENGINE применен приступ, предложенный исследовательской комиссией SG 11 (Study Group 11) при международной организации ITU-T, а усвоенный и Проектом сотрудничества в создании мобильных сетей третьей генерации 3GPP (3G Partnership Program). И в случае архитектуры BICC также выполнено разделение на два объекта (рис. 11.). Первый объект это функция обслуживания вызова (CSF - Call Serving Function), а второй - функция управления носителем (BCF – Bearer Control Function). Такое разделение выбрано для обеспечения независимости функции CSF от способа передачи информации, т.е. от носителя передачи между объектами BCF. Дополнительно еще определяется и функция носителя (BF – Bearer Function), точнее, функция приспосабливания носителей, например, между ИКМ кодированной речью (PCM – Pulse-Code Modulation) и речью в режиме синхронной передачи ATM на уровне адаптации AAL2.
Важно напомнить, что не существует параллели между функцией BCF и функцией сопрягающего шлюза доступа в модели MEGACO. В архитектуре BICC функция приспосабливания носителей принадлежит слою, который расположен ниже BCF и не видима функции CSF.
Для обеспечения связи между объектами и управления вызовами определены два протокола, один из которых сам BICC, определяющий коммуникацию между двумя CSF (Q.1901), а для коммуникации между CSF и BCF используется протокол H.248/ MEGACOР, согласно Q.1950.
Основой для стандарта BICC послужил протокол ISUP, модифицированный для обеспечения возможности разделения вызова от носителя. Основная рекомендация для BICC, Q.1901, написана как так называемый delta документ, или документ, в который внесены только различия в отношении на существующие рекомендации ISUP, Q.761- Q.764.
Кроме того, стандарт BICC также поддерживает прозрачную передачу сообщений ISUP, связанных с услугами, которые не встроены в него, из чего проистекает, что при переходе на пакетную коммуникацию сохранится полный набор сегодняшних услуг.
Подобно протоколу ISUP, протокол BICC определяет несколько различных типов узлов сигнализации в сети:

• основной узел-интерфейс ISN (Interface Serving Node), который служит как узел доступа между традиционной сетью PSTN/ISDN и пакетной сетью. ISN содержит функции CSF и BCF (рис. 11.);
• в более крупных сетях может появиться и посреднический узел CMN (Call Mediation Node), основной функцией которого является передача и маршрутизация BICC сообщений (рис. 11.);
• транзитный обслуживающий узел TSN (Transit Serving Node), с обеих сторон протокол BICC, может использоваться для преобразования между разными носителями (например, АТМ <-> IP) или для предоставления услуг интеллектуальных сетей (IN) (рис.12.);
• шлюзовой узел поддержки GSN (Gateway Serving Node) подобно TSN с обеих сторон использует протокол BICC, а находится на границе между двумя операторами в полном окружении BICC (рис.13.).

Принимая во внимание, что типичный узел ISN в архитектуре BICC находится на границе между традиционной сетью PSTN/ISDN и пакетной сетью, протокол BICC предусматривает два типа установления вызовов:

• “forward setup”, направление установления вызова вперед, обеспечивает возможность договора о типе кодер-декодера, что особенно важно в Интернет и мобильных сетях;
• “backward setup”, обратное направление к услугам сетей PSTN/ISDN.

На рис. 14. представлена разница между этими двумя подходами. В обоих случаях, прежде всего, устанавливается сам вызов (между соответствующими CSF), а затем и носитель (между BCF). В случае обратного направления, идентификация оконечной точки, с которой устанавливается вызов, содержится в сообщении “сall SETUP request” - “запрос на установление вызова”. В случае направления вперед, в сообщении “сall SETUP confirmation” - “подтверждение установления вызова” содержится адрес в сети передачи данных, с которым нужно установить вызов.
BICC содержит еще некоторые функции, с помощью которых приспосабливается установлению вызова в сетях передачи данных. Например, используется процедура “early call + bearer setup”, в которой исходящий узел ISN не ждет установления носителя, а сразу после принятия запроса об установлении вызова от сети PSTN/ISDN направляет вызов, точнее сигнализацию к станции назначения. Когда закончится установление носителя, исходящий узел ISN посылает еще одно сообщение с запросом об установлении вызова к сети PSTN/ISDN. Предотвращение активирования телефонного звонка на стороне Б прежде времени осуществляется с помощью процедуры “continuity checking” - “непрерывная проверка”. Таким образом, вызов устанавливается быстрее, особенно в ситуации, когда вызов проходит через много узлов TSN и GSN.
Во избежание установления вызова в сети PSTN/ISDN прежде, чем будет установлен носитель в сети BICC, как опция, может использоваться BICC сообщение с подтверждением об установленном носителе. В так устроенной BICC сети, исходящий узел ISN начнет процедуру установления вызова к сети PSTN/ISDN только после принятия такого сообщения.
Стандартизация архитектуры BICC и сопровождающих протоколов развертывалась в два этапа, а результатом являются два определенных набора возможностей (Capability Set – CS1и CS2). Набор CS1 больше ориентирован на АТМ, а CS2 расширяет возможности применения BICC в сетях Интернет IP. 
Набор CS2 (.1902) вводит возможность передачи BICC по сети Интернет, а возможно и туннелирование СВС протокола (Н.248) через BICC с помощью протокола Q.BCTP (Bearer Control Tunnelling Protocol). Протокол Q.BCTP воспринимается как дополнение к протоколу Н.248 в форме пакета функций. Рекомендации протокола Н.248 позволяют добавление функций в составе пакетов, чем обеспечивается целостность основы протокола и совместимость.
Непосредственным результатом такой архитектуры, логически применяемой в решении ENGINE, является то, что функция CSF для управления вызовом использует одни и те же процедуры, независимо от типа носителя, либо это ATM с уровнем адаптации ААL1 (ATM Adaptation Layer 1), либо ATM с AAL2 (ATM Adaptation Layer 2), либо транспортный протокол в реальном времени RTP/IP (Real-Time Transfer Protocol). Благодаря этому, ENGINE в настоящее время в состоянии мигрировать к применению технологии IP в целом. Функция CSF реализована в сервере TeS, а функции BCF и адаптации носителя находятся в многофункциональном шлюзе доступа.
Как и в технологии VoIP (Речь по сети Интернет), протокол для инициирования сессии SIP (Session Initiation Protocol) играет аналогичную роль и служит для установления коммуникации между сервером TeS и эквивалентной функцией. В сети VoIP другого оператора, например, нужно будет использовать функцию сигнализационного шлюза доступа (Signalling Gateway).

3.2.4 Протоколы и интерфейсы между многофункциональным шлюзом доступа и основой пакетной опорной сети передачи данных

Т.к. первичной задачей многофункционального шлюза доступа является установление виртуальных каналов через опорную пакетную сеть передачи данных, для достижения этой цели применяется сигнализационный протокол частных сетей PNNI 1.0 (Private Network to Network Interface). С помощью этого протокола выполняется сигнализация для установления коммутированных SVC (Switched Virtual Circuits) и полупостоянных SPVC (Soft-Permanent Virtual Circuits) виртуальных каналов.
Протокол PNNI также содержит функции обнаружения топологии и маршрутизации виртуальных каналов, вследствие чего сеть может реагировать на прерывания отдельных ветвей и направить соединения на другие, активные ветви. Благоприятность сигнализации PNNI особенно выражена на примере каналов SPVC, или соединений, которые установлены постоянно. В случае неисправности в какой-то части сети на первичном маршруте, соединения могут быть повторно установлены по другому, исправному маршруту. Кроме того, сеть может направить вызов по наиболее выгодному доступному направлению, избегая перегрузки и эффективно используя имеющиеся в распоряжении емкости передачи.
Чтобы интерфейс PNNI мог опознать топологию сети, он поддерживает активные связи с другими узлами в сети и разменивает информацию о доступности направлений. Поэтому PNNI не пригоден для соединения многофункционального шлюза доступа или другого АТМ узла к сети другого оператора. Для такой цели используются другие протоколы, которые не выявляют топологию частной сети, которой принадлежат, примерами таких протоколов являются UNI и AINI.

3.2.5 INAP и IN услуги

Для обеспечения пользователям сети EIN возможность дальнейшего использования услуг интеллектуальных сетей IN, сервер TeS поддерживает функции INAP и SSP и соединение с существующими и будущими платформами IN. Подобно классической системе AXE, сервер TeS, если располагает достаточной емкостью процессора, может послужить как комбинированный узел коммутации SSP и управления SCP - SSCP.
Как IN платформа может использоваться и JAMBALA, которая кроме обычных IN услуг обеспечивает открытый интерфейс API к дополнительным услугам, которые могут быть разработаны самими операторами или любым независимым производителем.

3.2.6 Остальные протоколы и интерфейсы

Поддержка для остальных интерфейсов и протоколов, по правилу, находится в многофункциональном шлюзе доступа. Шлюз поддерживает различные типы АТМ доступа, как перечислено ниже: Интерфейс пользователь-сеть АТМ UNI (User-to-Network Interface), Интерфейс частных сетей PNNI (Private Network to Network Interface) и АТМ межсетевой интерфейс А-INI (ATM Inter-Network Interface), сигнализации для соединения с сетями доступа АТМ и устройствами и сетями других операторов. Кроме того, многофункциональный шлюз доступа содержит поддержку для Frame Relay доступа и функцию для адаптации FR-ATM, функциональность MPLS Core-LSR (Label Switch Router), протоколы LDP/CR-LDP (Label Distribution Protocol/Constant-Based LDP) и MPLS RSVP-TE (Resource Reservation Protocol with Traffic Engineering Extensions) для связи с другими элементами сети MPLS, как, например, с граничными маршрутизаторами (Edge-LSR или Label Edge Router, LER) или другими центральными маршрутизаторами Core LSR в основе сети.
Таким образом, сеть EIN может предоставлять и услуги IP виртуальных частных сетей (IP VPN – Virtual Private Network), согласно RFC2547bis, или других типов виртуальных частных сетей.