Некоммерческое акционерное общество

АЛМАТИНСКИЙ УНИВЕРСИТЕТ ЭНЕРГЕТИКИ И СВЯЗИ

Кафедра Автоматическая Электросвязь

 

 

 

 

СИСТЕМЫ ГИБКОЙ КОММУТАЦИИ

 Конспект лекций

для магистрантов специальности

 6M071900  – Радиотехника, электроника и телекоммуникации

 

 

 

Алматы 2011

СОСТАВИТЕЛИ: Ю.М. Гармашова. Системы гибкой коммутации. Конспект лекций для магистрантов специальности 6М071900 – Радиотехника, электроника и телекоммуникации. - Алматы: АУЭС, 2011.-  70 с.

 

Изложены конспекты шестнадцати лекций по дисциплине "Системы гибкой коммутации". В них представлены принципы построения и функционирования систем гибкой коммутации.

Ил 28, табл.4, библиогр.- 10 назв.

 

Рецензент: канд.техн.наук, проф. К.Х. Туманбаева

 

Печатается по плану издания некоммерческого акционерного общества "Алматинский институт энергетики и связи" на 2010 г.

 

©НАО "Алматинский университет энергетики и связи", 2011 г.

Введение 

Целью преподавания дисциплины является изучение основ построения и функционирования систем гибкой коммутации.

Дисциплина рассматривает принципы построения и функционирования систем гибкой коммутации, особенностей их работы и взаимодействия с другими элементами сетей NGN, протоколы работы систем гибкой коммутации.

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

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

Задачами преподавания дисциплины являются овладение магистрантами принципами построения и функционирования систем гибкой коммутации, особенностями их работы и взаимодействия с другими элементами сетей NGN.

Учебным планом для данной дисциплины отводится 3 кредита, всего -180 часов, из них для аудиторных занятий - 48, для самостоятельной работы – 135 час.

 

Кредиты	Курс	Семестр	Аудиторные занятия	Лекции	Практические занятия	РГР	Экзамен
3	1	1	48 час.	2 (32 час.)	1 (16 час.)	3	1

 

 

1 Лекция.  Понятие систем гибкой коммутации

 

Цель лекции: изучение магистрантами основных понятий гибкой коммутации, гибкого коммутатора – Softswitch, функции.

Содержание:

-           понятия гибкой коммутации;

-           понятие гибкого коммутатора - Softswitch;

-           функции основные;

-           функции дополнительные.

Сеть связи следующего поколения - NGN – Next Generation Network – концепция построения сетей связи, обеспечивающих предоставление неограниченного набора услуг с гибкими возможностями по их управлению, персонализации и созданию новых услуг за счет унификации сетевых решений, предполагающая реализацию универсальной транспортной сети с распределенной коммутацией, вынесение функций предоставления услуг в оконечные сетевые узлы и интеграцию с традиционными сетями связи.

Базовым принципом концепции NGN является отделение друг от друга функций переноса и коммутации, функций управления вызовом и функций управления услугами. NGN, которая потенциально должна объединить существующие сети связи (телефонные сети общего пользования – ТфОП, сети передачи данных – СПД, сети подвижной связи – СПС), обладает следующими характеристиками:

-           сеть на базе коммутации пакетов, которая имеет разделенные функции управления и переноса информации, где функции услуг и приложений отделены от функций сети;

-           сеть компонентного построения с использованием открытых интерфейсов;

-           сеть, поддерживающая широкий спектр услуг, включая услуги в реальном времени и услуги доставки информации (электронная почта), в том числе мультимедийные услуги;

-           сеть, обеспечивающая взаимодействие с традиционными сетями электросвязи;

-           сеть, обладающая общей мобильностью, т.е. позволяющая отдельному абоненту пользоваться и управлять услугами независимо от технологии доступа и типа используемого терминала и предоставляющая абоненту возможность свободного выбора поставщика услуг.

Одним из основных отличий концепции NGN от реализуемых до этого сетевых инфраструктур является переход к принципиально другой функциональной модели [1]. В классической СТОП основными функциональными элементами являлись узлы доступа и узлы коммутации различного уровня. При этом оборудование узла коммутации решало одновременно несколько задач: коммутацию потоков пользовательской  информации, обработка вызова и предоставление услуг. Реализация интерфейсов между этими функциями была внутренним делом производителя системы коммутации и не подлежала регламентации. Развитие классической СТОП, связанное, прежде всего, с появлением технологии ISDN, позволило несколько разделить функции обработки сигнализации и коммутации потоков пользовательской информации. Как результат, появились новые функциональные элементы, такие как выделенные пункты транзита сигнализации (STP), а топология сигнальной сети стала отличаться от топологии сети коммутации. С другой стороны, сигнальная сеть решала вопросы транзита сигнальных сообщений, но задача обработки информации уровня ISUP, а, следовательно, и управления коммутацией, в любом случае решалась в точке совпадения топологий, т. е. в системах коммутации.

Концепция NGN, в первую очередь, характеризуется четким разделением трех уровней соединения в соответствии с их функциональными задачами: для коммутации и передачи речевой информации используется транспортный функциональный уровень, для передачи информации сигнализации - уровень сигнализации, а предоставление услуг, отличных от базовых, осуществляется со стороны уровня услуг. При этом между уровнями определены интерфейсы, которые являются объектом стандартизации. Получив подобную независимость друг от друга, уровни в дальнейшем могут развиваться самостоятельно. Более того, с точки зрения административного деления сети может ставиться вопрос о том, чтобы услуги различных уровней предоставлялись различными операторами.

Второй особенностью инфраструктуры NGN является использование универсаль­ных технологий транспортной сети, базирующихся на технологиях пакетной коммутации. В классических сетях предоставление услуг СТОП базировалось на технологии коммутации каналов, а предоставление услуг доступа к сетям передачи данных и передача данных предполагало либо формирование новой транспортной структуры, либо неэффективное использование существующего транспорта сети с коммутацией каналов. Тогда как в сетях NGN пакетные технологии, определенные для передачи данных, используются для предоставления всех видов услуг.

Гибкий коммутатор – это основной элемент сети NGN, называемый – SoftSwitch. Он управляет всей сетью рисунок 1.1 [2].

Гибкий коммутатор (SoftSwitch) - реализует функции по логике обработки вызова, доступу к серверам приложений, доступу к интеллектуальной сети связи, сбору статистической информации, тарификации, сигнальному взаимодействию с сетью СТОП и внутри пакетной сети, управлению установлением соединения и др. Гибкий коммутатор является основным устройством, реализующим функции уровня управления коммутацией и передачей информации [1].

Softswitch - это устройство управления сетью NGN, призванное отделить функции управления соединениями от функций коммутации, способное обслуживать большое число абонентов и взаимодействовать с серверами приложений, поддерживая открытые стандарты [2].

SoftSwitch является носителем интеллектуальных возможностей IP-сети, он координирует управление обслуживанием вызовов, сигнализацию и

 

Рисунок 1.1 - SoftSwitch

 

функции, обеспечивающие установление соединения через одну или несколько сетей [2].

В оборудовании гибкого коммутатора должны быть реализованы следующие основные функции [1]:

-         функция управления базовым вызовом, обеспечивающая прием и обработку сигнальной информации и реализацию действий по установлению соединения в пакетной сети;

-         функция аутентификации и авторизации абонентов, подключаемых в пакетную сеть как непосредственно, так и с использованием оборудования доступа СТОП;

-         функция маршрутизации вызовов в пакетной сети;

-         функция тарификации, сбора статистической информации;

-         функция управления оборудованием транспортных шлюзов;

-         функция предоставления ДВО. Реализуется в оборудовании гибкого коммутатора или совместно с сервером приложений;

-         функция ОАМ&Р: эксплуатация, управление (администрирование), техническое обслуживание и предоставление той информации, которая не нужна непосредственно для управления вызовом и может передаваться к системе управления элементами через логически отдельный интерфейс;

-         функция менеджмента: обеспечивает взаимодействие с системой менеджмента сети.

Дополнительно в оборудовании гибкого коммутатора могут быть реализованы следующие функции:

-         функция SP/STP сети ОКС7;

-         функция предоставления расширенного списка ДВО. Реализуется самостоятельно или с использованием серверов приложений;

-         функция взаимодействия с серверами приложений;

-         функция SSP;

-         другие.

 

2 Лекция.  Понятие систем гибкой коммутации

 

Цель лекции: изучение магистрантами характеристик Softswitch, протоколов работы Softswitch и интерфейсов.

Содержание:

-          характеристики Softswitch;

-          протоколы работы Softswitch;

-          интерфейсы Softswitch.

Характеристики Softswitch – включают в себя:

-          производительность;

-          надежность.

Производительность - это максимальное количество обслуживаемых базовых вызовов за единицу времени (как правило, за час). Производительность гибкого коммутатора является одной из главных характеристик, на основе которой должен проводиться выбор оборудования и проектирование сети [1].

Следует понимать, что гибкий коммутатор обслуживает вызовы от различных источников нагрузки, каковыми являются:

-         вызовы от терминалов, предназначенных для работы в сетях NGN (терминалы SIP и Н.323, а также IР-УАТС);

-         вызовы от терминалов, не предназначенных для работы в сетях NGN (аналоговые и ISDN терминалы) и подключаемых через оборудование резидентных шлюзов доступа;

-         вызовы от оборудования сети доступа, не предназначенного для работы в сетях NGN (концентраторы с интерфейсом V5) и подключаемого через оборудование шлюзов доступа;

-         вызовы от оборудования, использующего первичный доступ (УАТС) и подключаемого через оборудование шлюзов доступа;

-         вызовы от сети СТОП, обслуживаемые с использованием сигнализации ОКС7, с включением сигнальных каналов ОКС7 либо непосредственно в гибкий коммутатор, либо через оборудование сигнальных шлюзов;

-         вызовы от других гибких коммутаторов, обслуживаемые с использованием сигнализации SIP-T.

Производительность оборудования гибкого коммутатора различна при обслуживании вызовов от различных источников, что объясняется как различным объемом и характером поступления сигнальной информации от разных источников, так и заложенными алгоритмами обработки сигнальной информации.

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

Надежность - свойство объекта сохранять во времени и в установленных пределах значения всех параметров и способность выполнять требуемые функции в заданных режимах и условиях применения [1].  

Требования по надежности к оборудованию гибкого коммутатора:

-     средняя наработка на отказ;

-     среднее время восстановления;

-     коэффициент готовности;

-     срок службы.

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

 

Протоколы. Оборудование гибкого коммутатора может поддерживать следующие виды протоколов [1].  

1  При взаимодействии с существующими фрагментами сети СТОП:

-         непосредственное взаимодействие: ОКС7 в части протоколов МТР, ISUP и SCCP;

-         взаимодействие через сигнальные шлюзы: M2UA, M3UA, М2РА для передачи сигнализации ОКС7 через пакетную сеть; V5UA для передачи сигнальной информации V5 через пакетную сеть; IUА для передачи сигнальной информации первичного доступа ISDN через пакетную сеть;

-         MEGACO (H.248) для передачи информации, поступающей по системам сигнализации, по выделенным сигнальным каналам (2ВСК).

2 При взаимодействии с терминальным оборудованием:

-         непосредственное взаимодействие с терминальным оборудованием пакетных сетей: SIP и Н.323;

-         взаимодействие с оборудованием шлюзов, обеспечивающим подключение терминального оборудования СТОП: MEGACO (H.248) для передачи сигнализации по аналоговым абонентским линиям; IUA для передачи сигнальной информации базового доступа ISDN.

3 При взаимодействии с другими гибкими коммутаторами: SIP-T.

4 При взаимодействии с оборудованием интеллектуальных платформ (SCP): INАР.

5 При взаимодействии с серверами приложений: в настоящее время взаимодействие с серверами приложений, как правило, базируется на внутрифирменных протоколах, в основе которых лежат технологии JAVA, XML, SIP и др.

6 При взаимодействии с оборудованием транспортных шлюзов:

-         для шлюзов, поддерживающих транспорт IP или IP/ATM: H.248, MGCP, IPDC и др.;

-         для шлюзов, поддерживающих транспорт ATM: BICC.

 

Поддерживаемые интерфейсы. Как правило, оборудование гибкого коммутатора поддерживает следующие виды интерфейсов:

-         интерфейс Е1 (2048 кбит/с) для подключения сигнальных каналов ОКС7, включаемых непосредственно в гибкий коммутатор;

-         интерфейсы семейства Ethernet для подключения к IP сети. Через Ethernet-интерфейсы передается сигнальная информация в направлении пакетной сети.

 

3 Лекция. Сети NGN

 

Цель лекции: изучение магистрантами сетей NGN.

Содержание:

-          структура сети NGN;

-          назначение оборудования сети NGN;

-          шлюзы сети NGN;

-          декомпозиция АТС и Softswitch.

Общая архитектура сети NGN представлена на рисунках 3.1 и 3.2 [1,2].

 

Рисунок 3.1 - Общая архитектура сети на основе решений NGN

 

Основные элементы сети NGN показаны на рисунке 3.1 [1]:

-          гибкие коммутаторы (SoftSwitch);

-          АТС с функциями контроллера шлюзов сигнализации (MGC);

-          шлюзы (Gateways);

-          транспортная пакетная сеть;

-          сервера приложений;

-          терминальное оборудование.

На  сети NGN, рисунок 3.2, представлены [2, 3, 4, 5]:

-          AG (AGW) - Access Gateway – шлюз доступа;

-          Gatekeeper – привратник;

-          SG - Signalling Gateway – шлюз сигнализации;

-          TG (TGW) - Trunking Gateway - транкинговый шлюз;

-          IAD - Integrated Access Device – устройство интегрированного доступа;

 

Рисунок 3.2 - Общая архитектура сети NGN

 

-          AAA – Authorization, Access, Accounts – авторизация, доступ, учет;

-          API – Application Programming Interface –интерфейс прикладного программирования;

-          SCP – Service Control Point – узел управления услугами;

-          WIN - Workstation Interface Node – узел взаимодействия с рабочими станциями;

-          IN – Intelligent network – интеллектуальная сеть.

Шлюзы (Gateways) - устройства доступа к сети и сопряжения с существующими сетями. Оборудование шлюзов реализует функции по преобразованию сигнальной информации сетей с коммутацией пакетов в сигнальную информацию пакетных сетей, а также функции по преобразованию информации транспортных каналов в пакеты IP/ячейки ATM и маршрутизации пакетов IP/ячеек ATM.

Для реализации возможности подключения к мультисервисной сети различных видов оборудования СТОП используются различные программные и аппаратные конфигурации шлюзового оборудования [1]:

-         транспортный шлюз [Media Gateway (MG)] - реализация функций преобразования речевой информации в пакеты IP/ячейки ATM и маршрутизации пакетов IP/ячеек ATM;

-         сигнальные шлюзы [Signalling Gateway (SG)] - реализация функции преобразования систем межстанционной сигнализации сети ОКС7 (квазисвязный режим) в системы сигнализации пакетной сети [SIGTRAN (MxUA)];

-         транкинговый шлюз [Trunking Gateway (TGW)] - совместная реализация функций MG и SG;

-         шлюз доступа [Access Gateway (AGW)] - реализация функции MG и SG для оборудования доступа, подключаемого через интерфейс V5;

-         резидентный шлюз доступа [Residential Access Gateway (RAGW)] - реализация функции подключения пользователей, использующих терминальное оборудование СТОП/ЦСИС, к мультисервисной сети.

АТС с функциями MGC - оборудование АТС, в котором помимо функций коммутации каналов реализованы функции по коммутации пакетов, т. е. функции шлюзов и частично функция гибкого коммутатора. Функционально к такому оборудованию одновременно предъявляются требования, определенные как для гибкого коммутатора, так и для шлюзов. С точки зрения технических характеристик (в пакетной части) для такого оборудования определяются требования по емкости, производительности, надежности, поддерживаемым протоколам и реализованным интерфейсам к пакетной сети.

Терминальное оборудование - терминальные устройства, используемые для предоставления голосовых и мультимедийных услуг связи и предназначенные для работы в пакетных сетях.

Существует два основных типа терминальных устройств, предназначенных для работы в пакетных сетях: SIP-терминалы и Н.323-тсрминалы. Данное оборудование может иметь как специализированное аппаратное (standalone), так и программное исполнение (softphone).

Также используется терминальное оборудование на основе протокола MEGACO. Такое терминальное оборудование совмещает в себе функции аналогового телефонного аппарата и шлюза доступа в части преобразования сигнализации по аналоговым абонентским линиям. Его функциональные возможности ограничиваются возможностями аналогового аппарата, но оно может непосредственно подключаться к пакетной сети.

Еще одним видом терминального оборудования являются интегрированные устройства доступа (IAD). Как правило, IAD обеспечивает подключение терминального оборудования сетей СТОП (аналоговые ТА и терминалы ISDN) и терминального оборудования сетей передачи данных. В IAD реализуются функции по преобразованию протоколов сигнализации СТОП в протоколы пакетных сетей (SIP/H.323) и преобразованию потоков пользовательской информации между сетями с коммутацией каналов и пакетными сетями. Ближайшей аналогией к IAD в сетях СТОП является оборудование малых УАТС.

Терминальное оборудование поддерживает протоколы SIP или Н.323 в направлении гибкого коммутатора для передачи информации сигнализации и управления коммутацией и протоколы RTP/RTCP для передачи пользовательской информации. Для подключения к сети, как правило, используется Ethernet интерфейс.

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

Спецификация выполняемых функций зависит от реализуемой с помощью сервера услуги/группы услуг и не может быть сформулирована на абстрактном уровне.

Серверы приложений, как правило, взаимодействуют с оборудованием гибкого коммутатора с использованием технологий JAVA, XML, OSP. Подключение производится в основном с использованием интерфейсов, базирующихся на Ethernet.

Дорогостоящие традиционные АТС в единой структуре объединяют функции коммутации, функции управления обслуживанием вызовов, услуги и приложения, а также функции биллинга [2, 3]. Такая АТС представляет собой монолитную, закрытую системную структуру, как правило, не допускающую расширения или модернизации на базе оборудования других производителей.

Революционное изменение принес Softswitch. Он в корне изменил традиционную закрытую структуру систем коммутации, используя принципы компонентного построения сети и открытые стандартные интерфейсы между тремя основными функциями: коммутации, управления обслуживанием вызовов, услуг и приложений. В такой открытой, распределенной структуре могут применяться функциональные компоненты разных производителей, рисунок. 3.3.

 

 

Рисунок 3.3 - Декомпозиция АТС и Softswitch

4 Лекция. Структура систем гибкой коммутации

 

Цель лекции: изучение магистрантами структуры эталонной архитектуры Softswitch и функциональных плоскостей эталонной конфигурации.

Содержание:

-          структура эталонной архитектуры Softswitch;

-          транспортная плоскость;

-          плоскость управления обслуживанием вызова и сигнализации;

-          плоскость услуг и приложений;

-          плоскость  эксплуатационного управления.

 

 

 

Рисунок 4.1 - Структура эталонной архитектуры Softswitch

 

Согласно эталонной архитектуре Softswitch, разработанной консорциумом IPCC (International Packet Communication Consortium), в ней предусматривается четыре представленные на рисунке 4.1 функциональные плоскости [2, 3, 4, 5]:

-         транспортная;

-         управления обслуживанием вызова и сигнализации;

-         услуг и приложений;

-         эксплуатационного управления.

 

 

 

4.1 Транспортная плоскость

 

Транспортная плоскость (Transport Plane) отвечает за транспортировку сообщений по сети связи. Этими сообщениями могут быть сообщения сигнализации, сообщения маршрутизации для организации тракта передачи информации или непосредственно пользовательские речь и данные. Расположенный под этой плоскостью физический уровень переноса сообщений может базироваться на любой технологии, которая соответствует требованиям к пропускной способности для переноса трафика этого типа. Транспортная плоскость обеспечивает также доступ к сети IP-телефонии сигнальной и/или пользовательской информации, поступающей со стороны других сетей или терминалов. Как правило, устройствами и функциями транспортной плоскости управляют функции плоскости управления обслуживанием вызова и сигнализации. Сама транспортная плоскость делится на три домена:

-         домен транспортировки по протоколу IP;

-         домен взаимодействия;

-         домен доступа, отличного от IP.

Домен транспортировки по протоколу IP (IP transport domain) поддерживает магистральную сеть и маршрутизацию для транспортировки пакетов через сеть IP-телефонии. К этому домену относятся такие устройства, как коммутаторы, маршрутизаторы, а также средства обеспечения качества обслуживания (QoS).

Домен взаимодействия (Interworking Domain) включает в себя устройства преобразования сигнальной или пользовательской информации, поступающей со стороны внешних сетей, в вид, пригодный для передачи по сети IP-телефонии, а также обратное преобразование. В этот домен входят такие устройства, как шлюзы сигнализации (Signaling Gateways), обеспечивающие преобразование сигнальной информации между разным транспортными уровнями; транспортные шлюзы, или медиашлюзы (Media Gateways), выполняющие функции преобразования пользовательской информации между разными транспортными сетями и/или разными типами мультимедийных данных; шлюзы взаимодействия (Interworking Gateways), обеспечивающие взаимодействие различных протоколов сигнализации на одном транспортном уровне.

Домен доступа, отличного от IP (Non-IP Access Domain), предназначен для организации доступа к сети IP-телефонии различных IP-несовместимых терминалов. Он состоит из шлюзов Access Gateways для подключения учрежденческих АТС, аналоговых кабельных модемов, линий xDSL, транспортных шлюзов для мобильной сети радиодоступа стандарта GSM/3G, а также устройств интегрированного абонентского доступа IAD (Integrated Access Devices) и других устройств доступа. IP-терминалы непосредственно подключаются к домену транспортировки по протоколу IP без участия Access Gateway.

4.2 Плоскость управления обслуживанием вызова и сигнализации

 

Плоскость управления обслуживанием вызова и сигнализации (Call Control & Signaling Plane) управляет основными элементами сети IP-телефонии и, в первую очередь теми, которые принадлежат транспортной плоскости. Она управляет обслуживанием вызова на основе сигнальных сообщений, поступающих из транспортной плоскости, устанавливает и разрушает соединения для передачи пользовательской информации по сети. Эта плоскость включает в себя такие устройства, как контроллер медиашлюзов MGC (Media Gateways Controller), сервер обслуживания вызова Call Agent, привратник Gatekeeper и LDAP-сервер.

 

4.3 Плоскость услуг и приложений

 

Плоскость услуг и приложений (Service & Application Plane) содержит логику выполнения услуг и/или приложений в сети IP-телефонии и управляет этими услугами путем взаимодействия с устройствами, находящимися в плоскости управления обслуживанием вызова и сигнализации. Плоскость услуг и приложений состоит из таких устройств, как серверы приложений Application Servers и серверы дополнительных услуг Feature Servers. Она может также управлять специализированными компонентами передачи пользовательской информации, например, медиасерверами, которые выполняют функции конференц-связи, IVR и т.п.

 

4.4 Плоскость эксплуатационного управления

 

Плоскость эксплуатационного управления (Management Plane) обеспечивает функции включения/выключения абонентов и услуг, эксплуатационной поддержки, биллинга и другие функции технической эксплуатации сети. Плоскость эксплуатационного управления может взаимодействовать с некоторыми или со всеми другими тремя плоскостями либо по стандартному протоколу (например по протоколу SNMP), либо по внутренним протоколам и через интерфейсы API.

  

5 Лекция. Структура систем гибкой коммутации

 

Цель лекции: изучение магистрантами функциональных объектов Softswitch.

Содержание:

-          функциональные объекты Softswitch плоскостей эталонной конфигурации.

 

5.1 Функциональные объекты

 

Функциональными объектами рассмотренной выше эталонной модели архитектуры Softswitch являются логические объекты сети IP-телефонии. В рамках предложенного Консорциумом подхода выделяются 12 основных функциональных объектов, относительно которых следует прежде всего подчеркнуть, что это суть функции, а не физические продукты. Последнее означает, что разные функциональные объекты могут физически располагаться в разных автономных устройствах или на многофункциональных платформах и что существует практически неограниченное число способов размещения функциональных объектов в физических объектах [2, 5].

Существует 12 автономных функциональных объектов (ФО) на плоскостях эталонной архитектуры Softswitch, рисунок 5.1:

 

Рисунок 5.1 - Функциональные объекты Softswitch

Функциональные объекты [2, 3, 4, 5]:

-          AS-F - ФО сервера приложений;

-          SC-F - ФО управления услугами;

-          CA-F - ФО устройства управления шлюзом;

-          MGC-F - ФО контроллера медиашлюзов;

-          SPS-F- ФО прокси-сервера SIP;

-          R-F - ФО маршрутизатора вызова;

-          A-F - ФО учета, авторизации, аутентентификации;

-          MS-F - ФО транспортного сервера;

-          SG-F-ФО шлюза сигнализации;

-          MG-F -ФО медиашлюза;

-          IW-F - ФО взаимодействия;

-          AGS-F-ФО сигнализации шлюза доступа.

 

5.2 ФО контроллера медиашлюзов (MGC-F)

 

ФО контроллера медиашлюзов MGC-F (Media Gateways Controller Function) представляет собой конечный автомат логики обслуживания вызова и сигнализации управления его обслуживанием для одного или более транспортных шлюзов. MGC-F определяет состояние процесса обслуживания каждого вызова в медиашлюзе и состояния информационных каналов интерфейсов MG-F, передает информационные сообщения пользователя от одного MG-F к другому, а также от/к MG-F к/от IP-телефонам или терминалам, отправляет и принимает сигнальные сообщения от портов, от других MGC-F и от внешних сетей, взаимодействует с AS-F для предоставления услуг пользователю, имеет возможность управлять некоторыми сетевыми ресурсами (например портами MGF, полосой пропускания и т.д.) и устанавливать правила для портов пользователя, взаимодействует с R-F и A-F для обеспечения маршрутизации вызова, аутентификации и учета, а также может участвовать в задачах эксплуатационного управления в мобильной среде (т.к. управление мобильностью обычно является частью CA-F). Функциональный объект MGC-F обычно использует протоколы H.248 и MGCP.

 

5.3 ФО устройства управления и взаимодействия (CA-F) и функциональный объект взаимодействия (IW-F)

 

ФО устройства управления шлюзом CA-F (Call Agent Function) и функциональный объект взаимодействия IW-F (Interworking Function) являются подмножествами MGC-F. Первый из них, CA-F, существует, когда MGC-F управляет обслуживанием вызова и определяет состояние процесса его обслуживания. Протоколами этого функционального объекта могут являться SIP, SIP-T, BICC, H.323, Q.931, Q.SIG, INAP, ISUP, TCAP, BSSAP, RANAP, MAP и CAP, а в качестве интерфейсов API используются любые открытые API типа JAIN или Parlay. Второй функциональный объект, IW-F, существует, когда MGC-F обеспечивает взаимодействие между разными сетями сигнализации, например, IP и ATM, ОКС7 и SIP/H.323 и т.п.

 

5.4 ФО маршрутизации и учета стоимости (R-F и A-F)

 

ФО маршрутизации и учета стоимости R-F и A-F (Call Routing и Accounting Functions) работают следующим образом. Функциональный объект R-F предоставляет информацию о маршрутизации вызова функциональному объекту MGC-F. Функциональный объект A-F собирает учетную информацию о вызовах для целей биллинга, а также может выполнять более широкий спектр функций AAA, т.е. обеспечивать аутентификацию, идентификацию и учет в удаленных сетях. Основная роль обоих объектов – реагировать на запросы, поступающие от одного или более MGC-F, направляя вызов или учетную информацию о нем к входящим портам (другим MGC-F) или услугам (AS-F). Функциональный объект R-F/A-F обеспечивает маршрутизацию локальных и межсетевых вызовов (R-F), фиксирует детали каждого сеанса связи для целей биллинга и планирования (A-F), обеспечивает управление сеансом и управление мобильностью, может узнавать о маршрутной информации от внешних источников, может взаимодействовать с AS-F для предоставления услуги пользователю, может функционировать прозрачно для других элементов в тракте сигнализации. Здесь R-F и A-F могут сцепляться друг с другом последовательно или иерархически и к тому же R-F/A-F часто объединяется с MGC-F, причем объединенный R-F/A-F/MGC-F может также запрашивать услуги внешнего R-F/A-F. Сам A-F собирает и передает учетную информацию по каждому вызову, а AS-F передает учетную информацию по предоставлению дополнительных сервисов, таких как конференц-связь или платные информационные услуги. Функция маршрутизации локальных и межсетевых вызовов R-F может использовать протоколы ENUM и TRIP, а функция стоимости вызовов A-F может использовать протоколы RADIUS и AuC (для сетей подвижной связи).

 

5.5 ФО SIP-прокси-сервера (SPS-F)

 

ФО SIP-прокси-сервера SPS-F (SIP Proxy Server Function) выделен в отдельный функциональный объект по той причине, что чаще всего R-F и A-F конструктивно оформляются в виде прокси-сервера SIP.

 

5.6 ФО шлюза сигнализации (SG-F)

 

ФО шлюза сигнализации SG-F (Signaling Gateway Function) поддерживает обмен между сетью IP-телефонии и СТОП u1089 сигнальной информацией, которая может передаваться, например, на базе ОКС7/TDM или BICC/ATM. Для беспроводных сетей подвижной связи SG-F также поддерживает обмен сигнальной информацией между транзитной пакетной IP-сетью и сетью сотовой подвижной связи (СПС) с коммутацией каналов на базе стека ОКС7. Основная роль SG-F заключается в пакетировании и транспортировке информации протоколов сигнализации ОКС7 в СТОП (ISUP или INAP) или в СПС (MAP или CAP) по сети с коммутацией пакетов IP. Для этого функциональный объект SG-F пакетирует и транспортирует сигнализацию ОКС7 к MGC-F или другому SG-F, используя методы SIGTRAN. Один SG-F может обслуживать много MGC-F, а интерфейсом между SG-F и другими функциональными объектами служат протоколы SIGTRAN типов TUA, SUA и M3UA over SCTP, за исключением ситуаций, когда SG-F и MGC-F или другой SG-F объединены.

 

5.7 ФО сигнализации шлюза доступа (AGS-F)

 

ФО сигнализации шлюза доступа AGS-F (Access Gateway Signaling Function) поддерживает обмен сигнальной информацией между сетью IP-телефонии и сетью доступа с коммутацией каналов на базе интерфейсов V5.1/V5.2. Для беспроводных сетей подвижной связи AGS-F поддерживает также обмен сигнальной информацией между транзитной сетью подвижной связи с коммутацией пакетов и сетью СПС на базе TDM или ATM. Основная роль AGS-F заключается в пакетировании и транспортировке информации протоколов сигнализации интерфейсов V5, или ISDN (для проводных сетей), или BSSAP, или RANAP (для беспроводных сетей) по сети с коммутацией пакетов IP. AGS-F пакетирует и транспортирует к MGC-F эту информацию протоколов сигнализации V5, ISDN или ОКС7, используя протоколы SIGTRAN типов M3UA, IUA и V5UA over SCTP.

 

5.8 ФО сервера приложений (AS-F)

 

ФО сервера приложений AS-F (Application Server Function) поддерживает логику и выполнение услуг для одного или более приложений [2]. AS-F может запрашивать у MGC-F прекращение вызовов или сеансов связи для определенных приложений (например речевой почты или конференц-связи), запрашивать у MGC-F повторное инициирование услуг связи (например сопровождающего вызова или вызовов по предоплаченной телефонной карте), может изменять описания потоков пользовательских данных, участвующих в сеансе, используя протокол SDP, может управлять MS-F для обслуживания потоков пользовательской информации, может компоноваться с web-приложениями или иметь web-интерфейсы, может использовать открытые API типа JAIN или Parlay для создания услуг, может иметь внутренние интерфейсы алгоритма распределения ресурсов, биллинга и регистрации сеансов, взаимодействовать с функциональными объектами MGC-F или MS-F, вызывать другой AS-F для предоставления дополнительных услуг или для построения составных сервисов, ориентированных на компоненты приложений, использовать функциональные возможности MGC-F для управления внешними ресурсами. Для всех этих целей применяются протоколы SIP, MGCP, H.248, LDAP, HTTP, CPL и XML. Совместное использование функциональных объектов AS-F и MGC-F обеспечивает поддержку составных услуг, таких как сетевые записанные объявления, трехсторонняя связь, уведомление о поступлении нового вызова и т.д. В ситуациях, когда AS-F и MGC-F реализованы в одной системе, вместо подключения AS-F к MGC-F по одному из вышеуказанных протоколов производители часто используют API типа JAIN или Parlay. При такой организации AS-F называют сервером дополнительных услуг (Feature Server).

 

6 Лекция. Структура систем гибкой коммутации

 

Цель лекции: изучение магистрантами функциональных объектов Softswitch и реализация функциональных объектов Softswitch в структуре сети NGN. Структура Softswitch.

Содержание:

-          функциональные объекты Softswitch плоскостей эталонной конфигурации;

-          реализация функциональных объектов Softswitch в структуре сети NGN;

-          структура Softswitch.

 

6.1 ФО управления услугами (SC-F)

 

ФО управления услугами SC-F (Service Control Function) существует, когда AS-F управляет логикой услуг. SC-F использует протоколы INAP, CAP и MAP, а также открытые API типа JAIN и Parlay [2, 3, 4, 5].

 

6.2 ФО медиашлюза (MG-F)

 

ФО медиашлюза MG-F (Media Gateway Function) обеспечивает сопряжение IP-сети с портом доступа, соединительной линией либо с совокупностью портов и/или соединительных линий, т.е. служит шлюзом между пакетной сетью и внешними сетями с коммутацией каналов, такими как СТОП, СПС или ATM. Его основная роль состоит в преобразовании пользовательской информации из одного формата в другой, чаще всего – из канального вида в пакетный и обратно, из ячеек ATM в пакеты IP и обратно. MG-F имеет следующие характеристики:

-          всегда состоит в отношениях "ведущий/ведомый" с MGC-F, используя протокол управления MGCP или MEGACO/H.248;

-          может выполнять функции обработки пользовательской информации, такие как кодирование, пакетирование, компенсацию эха, управление буферами, устранения джиттера, корректирующие действия при потерях пакетов и др.;

-          может выполнять функции обслуживания пользовательских соединений, такие как генерирование акустических сигналов, генерирование сигналов DTMF, генерирование комфортного шума и др., а также выполнять анализ цифр на базе таблицы, загружаемой от MGC-F;

-          может выполнять функции сигнализации и обнаружения событий, такие как обнаружение сигналов DTMF, обнаружение состояний отбоя/ответа абонента, детектирование наличия речевых сигналов и др.

Таким образом, MG-F обеспечивает механизм, позволяющий MGC-F контролировать состояние и функциональные возможности портов, а сам не требует знать состояния процессов обслуживания вызовов, проходящих через него, поддерживая только состояния соединений. Используемые протоколы: RTP/RTCP, TDM, H.248 и MGCP. Кстати, SIP-телефон или шлюз с поддержкой SIP с этой точки зрения представляет собой MG-F и MGC-F в одном блоке.

 

6.3 ФО медиасервера MS-F

 

ФО медиасервера MS-F (Media Server Function) обеспечивает управление обработкой пользовательского пакетного трафика от любых приложений. В основном он функционирует в качестве сервера, обслуживающего запросы от AS-F или MGC-F, касающиеся обработки пользовательской информации в пакетированных потоках мультимедиа. MS-F поддерживает различные кодеки и схемы кодирования, может управляться либо AS-F или MGC-F непосредственно (управление ресурсами), либо косвенно (вызов функции) с использованием протоколов SIP, MGCP и H.248.. Функциональный объект MA-F может параллельно поддерживать обнаружение набираемых цифр, генерирование и передачу акустических сигналов и записанных сообщений, регистрацию и запись мультимедийных потоков, распознавание речи, речевое воспроизведение текста, микширование для конференц-связи, обработку факсимильных сообщений, определение наличия речевых сигналов и передачу информации о громкости.

 

6.4 Реализация функциональных объектов Softswitch в структуре сети NGN

 

Softswitch или контроллер медиашлюзов MGC (Media Gateway Controller) имеет множество реализаций, в связи с чем он может называться: Softswitch, Call Agent, Call Controller, Telephone Server и др [2, 3, 4, 5].

На рисунке 6.1 представлены только некоторые из множества возможностей функциональной компоновки Softswitch.

В Softswitch кроме MGC-F реализуются и другие функциональные объекты, например, на рисунке 6.1 показаны функциональные блоки:

- менеджер сеансов соединения Connection Session Manager (MGC-F);

- управление обслуживанием вызова и сигнализацией (CA-F);

- менеджер взаимодействия Interworking/Border Connection Manager  (IW-F);

- менеджер сеансов доступа Access Session Manager (R-F/A-F);

- шлюз доступа к открытым услугам Open Service Access Gateway;

- модули-посредники приложений (Proxies),

- агенты системы эксплуатационной поддержки OSS и OEM.

Все рассмотренные функциональные объекты могут совмещаться в одной физической платформе, рисунок 6.1, или распределяться по разным устройствам, рисунок 6.2, которые в совокупности дают техническое решение Softswitch.

Рисунок 6.1 – Функциональные объекты Softswitch совмещенные в одной физической платформе

 

На рисунке 6.2 Softswitch управляет шлюзами между сетью СТОП/IN и IP-сетью, транспортными шлюзами и транспортными серверами посредством функционального объекта MGC-F, используя соответствующие протоколы управления шлюзами. Также MGC обменивается сигнальными сообщениями с портами, другими Softswitch и внешними сетями. Эту функцию выполняет

 

ПРИМЕЧАНИЕ. Пунктирные линии представляют реализацию информационных потоков, полученную в результате выбора протокола и интерфейсов в соответствии с требованиями к обслуживанию.

 

Рисунок 6.2 - Функциональные объекты Softswitch распределенные по разным устройствам

модуль управления обслуживанием вызова и сигнализации (CA-F), который также сохраняет данные о состоянии процесса обслуживания каждого вызова.

Также на схеме Softswitch реализованы функциональные объекты: маршрутизации и учета стоимости вызовов (R-F/A-F), SIP-прокси-сервера (SPS-F) и менеджера пограничных соединений (IW-F). Кроме того, Softswitch взаимодействует через модуль шлюза открытых услуг Open Service Gateway Block с серверами приложений для поддержки услуг, которые не являются "родными" для Softswitch, а подключаются посредством различных протоколов управления услугами и API, таких как SIP, JAIN и Parlay.

Функциональная схема гибкого коммутатора представлена на рисунке 6.3 [1].

Рисунок 6.2 - Функциональная схема гибкого коммутатора

 

7 Лекция. Протоколы работы системы гибкого коммутатора

 

Цель лекции: изучение магистрантами протоколов RTP, RTCP и SIP.

Содержание:

-          протокол RTP, назначение;

-          протокол RTСP, назначение;

-          пакет RTP;

-          протокол SIP, принципы, адресация;

 

7.1 Транспортные протоколы RTP/RTCP

 

Протокол реального времени (Real-Time Transfer Protocol - RTP) или транспортный протокол реального времени RTP (Real-Time Transport Protocol), этот протокол регламентирует передачу мультимедийных приложений в пакетах на транспортном уровне и дополняется протоколом управления передачей данных в реальном масштабе времени RTCP (Real-Time Control Protocol) [2, 3, 5]. Протокол RTCP, в свою очередь, обеспечивает контроль доставки мультимедийного трафика, контроль качества обслуживания, передачу информации об участниках текущего сеанса связи, управление и идентификацию, и иногда считается частью протокола RTP.

Транспортный протокол реального времени RTP обеспечивает сквозную передачу в реальном времени пакетов с кодированными речевыми сигналами по IP-сети. Этот протокол реализует распознавание типа трафика, нумерацию последовательности пакетов, работу с метками времени и контроль передачи. Хотя протокол RTP считается протоколом транспортного уровня, он функционирует обычно поверх другого протокола транспортного уровня UDP (User Datagram Protocol), работающего также поверх IP, рисунок 7.1. Оба протокола вносят свои доли в функциональность транспортного уровня. Следует отметить, что RTP и RTCP являются независимыми от нижележащих уровней - транспортного и сетевого, поэтому протоколы RTP/RTCP могут использоваться с другими подходящими транспортными протоколами.

Рисунок 7.1 – Уровни протоколов RTP/UDP/IP

 

Протокольные блоки данных RTP/RTCP называются пакетами. Пакеты, формируемые в соответствии с протоколом RTP и служащие для передачи мультимедийного трафика (речевого), называются информационными пакетами или пакетами данных (data packets), а пакеты, генерируемые в соответствии с протоколом RTCP и служащие для передачи служебной информации, требуемой для надежной работы телеконференции, называют

пакетами управления или служебными пакетами (control packets).

Пакет RTP, рисунок 7.2, включает в свой состав фиксированный заголовок, необязательное расширение заголовка переменной длины и поле данных.

 

Рисунок 7.2 - Заголовок пакета RTP

 

Пакет RTP состоит, как минимум, из 12 байтов:

- поле V - 2 бита. Это поле идентифицирует версию протокола RTP;

- поле P - 1 бит (Заполнитель) – указывает, были ли добавлены в конце поля  с полезной нагрузкой  символы-наполнители  (они используются, если транспортный протокол или алгоритм кодирования требует использования блоков фиксированного размера);

- поле Х - 1 бит – используется ли расширенный заголовок. Если бит Х=1, далее следует фиксированный заголовок, за которым размещается одно расширение заголовка;

- поле CC - 4 бита – определяет число CSRC–полей в конце RTP-заголовка, т.е. число источников формирующих поток;

- поле M - 1 бит – маркерный бит определяет существенные события, такие как границы кадра, начало слова в аудиоканале и т.п.;

- поле PT - 7 бит – определяет тип данных (например: 8-битовое аудио МР3, канал 64 кбит/с PCM и т.п.);

- поле номер по порядку - 16 бит;

- поле временная метка - 32 бита;

- поле SSRC - 32 бита - идентифицирует источник синхронизации. Этот идентификатор выбирается случайным образом, так чтобы в пределах одной RTP-сессии не было двух равных SSRC-кодов. Все приложения должны быть способны выявлять случаи равенства SSRC-кодов. Если отправитель изменяет свой транспортный адрес, он должен также сменить и SSRC-идентификатор.

 - поле CSRC - от 0 до 15 элементов, по 32 бита каждый - идентифицирует источники данных, которые внесли свой вклад в поле данных пакета. Число идентификаторов задается полем CC. Если число источников больше 15, только 15 из них могут быть идентифицированы.

 

7.2 Протокол SIP

 

SIP (Session Initiation Protocol) - Протокол инициирования сеансов связи – это текст-ориентированный протокол прикладного уровня и предназначен для организации, модификации и завершения различных сеансов связи, в том числе мультимедийных. Мультимедийные сеансы включают в себя мультимедийные конференции, Интернет-телефонию и другие аналогичные приложения. SIP - это протокол сигнализации, определяющий установление, контроль и прекращение сеансов связи в IP-сети. SIP является одним из ключевых протоколов, используемых для реализации передачи речи по сетям IP (Voice over IP - VoIP) [2, 6].

Принципы протокола SIP:

-          Предоставление услуг в независимости от местоположения пользователя, т. е. персональная мобильность пользователей;

-          Определение готовности пользователей участвовать в сеансе связи;

-          масштабируемость сети, построенной на базе протокола SIP;

-          взаимодействие с другими протоколами сигнализации H 323, MGCP, MEGACO/H 248, DSS1, ОКС7;

-          расширяемость протокола SIP, характеризуемая возможностью дополнять протокол функциями поддержки новых услуг и его адаптации к работе с различными приложениями.

Адресация SIP: SIP использует в качестве адресов специальные универсальные указатели ресурсов URL (Univercal Resource Locators), называемые SIP URL [2, 6].

SIP-адреса бывают четырех типов:

-          имя@домен;

-          имя@хост;

-          имя@IP-адрес;

-          №телефона@шлюз.

Адрес состоит из двух частей. Первая часть – это имя пользователя, зарегистрированного в домене или на рабочей станции. Если вторая часть адреса идентифицирует какой-либо шлюз, то в первой указывается телефонный номер абонента. Во второй части адреса указывается имя домена, рабочей станции или шлюза. Для определения IP-адреса устройства необходимо обратиться к службе доменных имен - Domain Name Service (DNS). Если же во второй части SIP-адреса размещается IP-адрес, то с рабочей станцией можно связаться напрямую.

В начале SIP адреса ставится слово ’sip:’, указывающее, что это именно SIP-адрес, т.к. бывают и другие (например, ‘tel:’). Примеры SIP-адресов:

          sip: Alexander@niits.ru.

          sip: user1@192.168.0.215

          sip: 387-75-47@sip-gateway.ru

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

Для организации сеанса связи с помощью протокола SIP, используется архитектура клиент-сервер, рисунок 7.3.

 

 

 

 

 

Рисунок 7.3 – Архитектура "Клиент-Сервер"

 

Установление сеанса связи включает в себя пять этапов:

-          определение местоположения пользователя (user location);

-          определение готовности пользователя (User availability);

-          определение функциональных возможностей пользователей (User capabilities), определяется тип информации которой они могут обмениваться;

-          установление сеанса связи (Session setup), определяются параметры сеанса связи вызываемой и вызывающей сторон;

-          управление сеансом связи (Session management), включая поддержание и завершение.

Согласно протоколу SIP, на сети должны быть 4 функциональных элемента:

-          терминалы SIP (User Agents)– агенты пользователей;

-          прокси-серверы обеспечивают обработку запросов (Proxy Servers), поступающих от терминалов клиентов, с целью предоставления услуг связи;

-          серверы перенаправления (Redirect servers), определяют текущий IP-адрес терминала вызываемого пользователя;

-          серверы регистрации местоположения пользователей (Registrars или Location servers), позволяют клиентам регистрировать своё местоположение  для предоставления услуг.

Структура сообщений протокола SIP, рисунок 7.4. Все сообщения протокола SIP – запросы и ответы – представляют собой последовательности текстовых строк.

Рисунок 7.4 - Структура сообщения протокола SIP

 

Стартовая строка представляет собой начальную строку любого SIP-

сообщения. Если сообщение является запросом, в этой строке указывается тип запроса, адресат и номер версии протокола. Если сообщение является ответом на запрос, в стартовой строке указывается номер версии протокола, тип ответа и его короткая расшифровка, предназначенная только для пользователя.

Заголовки сообщений служат для передачи информация об отправителе, адресате, пути следования и других сведений, т.е. переносят необходимую для обслуживания данного сообщения информацию. О типе заголовка можно узнать из его имени. Сообщения  протокола SIP могут содержать так называемое тело сообщения. В запросах ACK, INVITE и OPTIONS тело сообщения содержит описание сеансов связи, например, в формате протокола SDP, а запрос BYE не содержит тело сообщения.

Команды SIP – запросы, предназначены широкому кругу задач при предоставлении базовых и дополнительных услуг.

Типы запросов: INVITE, АСК, CANCEL, BYE, REGISTER, OPTIONS.

Ответы SIP – посылаются на полученный запрос. Ответы подтверждают установление соединения, передают запрашиваемую информацию, сообщения о неисправностях и т.д.

На рисунке 7.5 приведен алгоритм установления соединения с участием сервера перенаправления.

Рисунок 7.5 - Алгоритм установления соединения с участием сервера перенаправления

 

8 Лекция. Протоколы работы системы гибкого коммутатора

 

Цель лекции: изучение магистрантами протокола MGSP.

Содержание:

-          протокол MGSP; назначение;

-          основные понятия;

-          команды и ответы MGSP;

-          сеанс связи в MGCP, режимы соединения.

 

8.1 Протокол MGCP

 

MGCP - Media Gateway Control Protocol - протокол управления транспортными шлюзами [2, 7].

Для описания процесса обслуживания вызова с использованием протокола MGCP рабочей группой MEGACO разработана модель организации соединения - Connection model. Базой модели являются компоненты двух основных видов: порты (Endpoints) и подключения (Connections).

Endpoints - это порты оборудования, являющиеся источниками и приемниками информации. Connection – подключение это связь, устанавливаемая между оконечным пунктом и сеансом RTP/IP. Если между собой связываются два оконечных пункта, используются два подключения. При этом связь между портами разных шлюзов через IP-сеть или связь между портами внутри одного шлюза является условием организации сеанса связи и называется соединением.

 

8.2 Команды и ответы протокола MGCP

 

MGCP определяет девять команд, одни передаются от Softswitch к шлюзу, а другие от шлюза к Softswitch, таблица 8.1.

Команда MGCP содержит командную строку, несколько строк параметров и, необязательно, описание сеанса. Командная строка и параметры являются текстом, использующим набор символов ASCII.  MGCP поддерживает инкапсуляцию, при которой одна команда может быть включена в состав другой. MGCP предусматривает только один уровень инкапсуляции. Также MGCP позволяет передавать несколько команд  в одном и том же пакете UDP.

Команда протокола MGCP обязательно содержит заголовок, за которым может следовать описание сеанса связи (session description). Заголовок команды и описание сеанса связи представляют собой набор текстовых строк. Описание сеанса отделено от заголовка команды пустой строкой. Заголовок содержит командную строку, например, вида CRCX 1204 ts/1@protei.loniis.net MGCP 0.1. и список параметров.

Командная строка состоит из нескольких информационных полей.

Таблица 8.1- Команды протокола MGCP

Команда	Код	Направление передачи	Назначение
EndpointConfiguration (Конфигурация оконечного порта)	EPCF	Softswitch -> MG	Softswitch инструктирует шлюз, каким образом ему нужно обрабатывать получаемые речевые сигналы
CreateConnection (Создать подключение)	CRCX	Softswitch -> MG	Softswitch дает указание шлюзу создать соединение
ModifyConnection (Модифицировать подключение)	MDCX	Softswitch -> MG	Softswitch дает указание шлюзу изменить параметры существующего подключения
DeleteConnection (Разрушить подключение)	DLCX	Softswitch -> MG, MG -> Softswitch	Softswitch и шлюзы завершают подключение
NotificationRequest (Запрос уведомления)	RQNT	Softswitch -> MG	Softswitch инструктирует шлюз, какие события необходимо обнаруживать и уведомлять о них
Notify (Уведомление)	NTFY	MG -> Softswitch	Шлюз информирует Softswitch о том, что произошло событие из числа тех, которые были специфицированы в команде NotificationRequest
AuditEndpoint (Проверить порт)	AUEP	Softswitch -> MG	Softswitch запрашивает информацию о каком-либо порте шлюза
AuditConnection (Проверить подключение)	AUCX	Softswitch -> MG	Softswitch запрашивает параметры соединения
ReStartlnProgress (Идёт рестарт)	RSIP	MG -> Softswitch	Шлюз информирует Softswitch о том, что один или несколько портов выводятся из рабочего состояния или возвращаются в рабочее состояние

 

Первое поле - название команды – представлено в виде кода из четырех букв (таблица 8.1). Далее следует идентификатор транзакции.

Протокол MGCP предусматривает корреляцию команд и ответов. Команда и ответ на нее образуют транзакцию, имеющую уникальный идентификатор (TransactionIdentifier). Идентификатор транзакции включается

в заголовок, и команды, и ответа. Значения идентификаторов выбираются из диапазона чисел 1-999999999, причем значение идентификатора текущей транзакции на единицу больше идентификатора предыдущей транзакции.

Идентификатор порта определяет тот порт шлюза, которому надлежит выполнить команду, за исключением команд Notify и ReStartlnProgress, в которых идентификатор определяет порт, передавший команду. Идентификаторы портов кодируются также, как кодируются адреса электронной почты (в соответствии с RFC 821). Например, возможен идентификатор ts/1@protei.loniis.net, который идентифицирует первый порт (временной канал) шлюза «protei», расположенного в домене loniis. Замыкает пример, версия протокола, которая кодируется так: MGCP 1.0.

Заголовок команды может иметь список параметров. Параметры команд идентифицируются кодом, который состоит из одной или двух заглавных букв. За кодом параметра следует одно двоеточие, один символ пробела и значение параметра. Например, параметр К (подтверждение транзакции): 6234-6255, 6257 подтверждает завершение транзакций, имеющих идентификаторы с 6234 по 6255, 6257.

На каждую команду MGCP передается ответ [2, 7]. Структура ответа на команды идентична структуре самих команд. Строку ответа составляет код возврата, идентификатор транзакции, далее фраза комментария или причины.

В таблице 8.2 приведены возможные варианты кода ответа на команды протокола MGCP.

 

Таблица 8.2- Коды ответов на команды протокола MGCP

Код	Значение кода
100	Полученная команда в данный момент обрабатывается, сообщение о выполнении команды будет передано позже
200	Полученная команда выполнена
250	Соединение разрушено
400	Транзакция не может быть выполнена из-за временной ошибки
401	Трубка телефона уже снята
402	Трубка телефона уже повешена
403	Команда не может быть выполнена из-за отсутствия в данный момент необходимых ресурсов

 

8.3 Сеанс связи в MGCP

 

При установлении соединений Softswitch предоставляет портам шлюзов, участвующим в этих соединениях, необходимую информацию друг о друге - описание сеансов связи. Описание сеанса связи вводится в состав некоторых команд и ответов протокола MGCP и включает в себя IP-адрес, UDP/RTP порт, вид информации, алгоритм кодирования информации, размер речевых пакетов и т.д. Синтаксис описания сеанса связи в протоколе MGCP соответствует синтаксису протокола описания сеансов связи - session description protocol (SDP), предложенному в RFC 2327 [2, 7].

Рассмотрим синтаксис протокола SDP только в части описания сеанса речевой связи. Для описания такого сеанса в протоколе SDP предусмотрено несколько информационных полей:

-          Версия протокола SDP кодируется следующим образом: v=0.

-          IP-адрес шлюза. Это поле содержит IP-адрес, который будет использоваться для обмена пакетами RTP. Если это поле включено в команды протокола MGCP, то оно означает адрес удаленного шлюза, если поле включено в ответы, то - адрес шлюза, передающего ответ.

-          Поле описания речевого канала кодируется буквой "m". Данное поле

содержит индикацию вида передаваемой или принимаемой информации (в нашем случае - речи), номер порта, используемого для приема RTP пакетов удаленным шлюзом (если поле описания речевого канала включено в команды протокола MGCP) или локальным шлюзом (если это поле включено в ответы), индикацию использования протокола RTP для передачи речи и алгоритмы кодирования речевой информации. Поле кодируется буквой «т».

-          Режим соединения. Режимы соединений представлены в таблице 8.3.

 

Таблица 8.3- Режимы соединения

Кодировка режима	Функционирование шлюза
sendonly	Шлюзу надлежит только передавать информацию
recvonly	Шлюзу надлежит только принимать информацию
sendrecv	Шлюзу надлежит передавать и принимать информацию
inactive	Шлюз не должен ни передавать, ни принимать информацию
loopback	Шлюз должен передавать принимаемую информацию в обратном направлении
contest	Шлюзу надлежит перевести порт в режим тестирования

 

Кроме вышеуказанных полей, для описания сеанса речевой связи в протоколе SDP предусмотрено еще несколько необязательных информационных полей. Отметим, что если в команду или в ответ протокола MGCP включены описания нескольких сеансов связи, то они отделяются друг от друга строкой с указанием версии протокола SDP. Типичный пример описания сеанса речевой связи с использованием протокола SDP приведён ниже:

v = О

с = IN IP4 128.96.41.1

m = audio 3456 rtp/avp 0

 

Для описания сеанса связи в примере используется протокол SDP, версия 0, в сети используется протокол IP, версия 4, IP адрес шлюза - 128.96.41.1, передается или принимается речевая информация, упакованная в пакеты RTP, номер порта RTP - 3456, алгоритм кодирования речи - G.711, закон m

 

9 Лекция. Протоколы работы системы гибкого коммутатора

 

Цель лекции: изучение магистрантами протокола Megaco/H.248.

Содержание:

-          протокол Megaco/H.248, назначение;

-          основные понятия;

-          модель обслуживания вызовов в протоколе Megaco/H.248;

-          команды протокола Megaco/H.248;

-          дескрипторы протокола Megaco/H.248.

 

9.1 Протокол управления транспортным шлюзом MEGACO/H.248

 

Протокол управления транспортным шлюзом Megaco/H.248 является дальнейшим развитием протокола MGCP и ряда других разработок как IETF, так и ITU-T [2, 8, 9].

Для переноса сигнальных сообщений Megaco/H.248 могут использоваться следующие транспортные протоколы: UDP, TCP, SCTP (Stream Control Transport Protocol) и технология ATM. Поддержка протокола UDP является обязательным требованием для контроллера шлюзов MGC. Протокол TCP должен поддерживаться как контроллером, так и шлюзом. Поддержка протокола SCTP и технологии ATM для обоих устройств необязательна.

Сообщения протокола Megaco/H.248 могут кодироваться двумя способами. Комитетом IETF предложен текстовый способ кодирования сигнальной информации, причем для описания сеансов связи используется протокол SDP.  Кодирование текста пишется в соответствии с формами Бэкуса-Наура ABNF (Augmented Backus-Naur Form). ITU-Т предусматривает бинарный способ представления сигнальной информации по спецификациям абстрактного синтаксиса ASN.1 (Abstract Syntax Notation One), а для описания сеансов связи рекомендует специальный инструмент формата Tag-Length-Value (TLV). Softswitch должен поддерживать оба способа кодирования, а шлюз MG - только один из них.

Протокол Megaco/H.248 является внутренним протоколом, который работает между функциональными блоками распределенного шлюза, а именно между Softswitch и MG. Принцип действия этого протокола - master/slave, то есть, ведущий/ведомый. Устройство управления Softswitch является ведущим, а транспортный шлюз MG - ведомым, который выполняет команды, поступающие к нему от устройства управления.

При описании алгоритма установления соединения с использованием протокола Megaco/H.248 комитет IETF опирается на специальную модель процесса обслуживания вызова, отличную от модели MGCP. Протокол MEGACO оперирует с двумя логическими объектами: порт (termination) и контекст (context) [2, 8, 9].

Окончания (terminations) - порты являются источниками и приемниками

медиаинформации и логическими объектами транспортного шлюза. Определено два вида портов: физические и виртуальные.

Физические порты, существующие постоянно с момента конфигурации шлюза, это аналоговые телефонные интерфейсы оборудования, поддерживающие одно телефонное соединение или цифровые каналы, также поддерживающие одно телефонное соединение и сгруппированные по принципу временного разделения каналов в тракт Е1.

Виртуальные порты, существующие только в течение разговорного сеанса, являются портами со стороны IP сети (RTP-порты), через которые ведутся передача и прием пакетов RTP. Виртуальные порты создаются шлюзом при получении от Softswitch команды Add и ликвидируются при получении команды Subtract, тогда как физические порты при получении команды Add или Subtract, соответственно, выводятся из нулевого контекста или возвращаются обратно в нулевой контекст.

Порт имеет уникальный идентификатор (TerminationID), который назначается шлюзом при конфигурации порта. Например, идентификатором порта может служить номер тракта Е1 и номер временного канала внутри тракта. Иногда команды могут относиться ко всему шлюзу, тогда используется специальный идентификатор порта (TerminationID) - «Root».

Порты обладают рядом свойств (properties), каждое из которых имеет уникальный идентификатор (propertylD). Например, порты могут обладать свойствами генерировать речевые подсказки, акустические и вызывные сигналы, а также детектировать сигналы DTMF.

Контекст (context) - это отображение связи между несколькими портами, то есть абстрактное представление соединения двух или более портов одного шлюза. В любой момент времени порт может относиться только к одному контексту, который имеет свой уникальный идентификатор. Существует особый вид контекста - нулевой. Все порты, входящие в нулевой контекст, не связаны ни между собой, ни с другими портами. Например, абстрактным представлением свободного (незанятого) канала в модели процесса обслуживания вызова является порт в нулевом контексте.

В общем случае для присоединения порта к контексту служит команда Add. При этом, если контроллер не специфицирует существующий контекст, к которому должен быть добавлен порт, то шлюз создает новый контекст. Если шлюз поддерживает конференцию, то контекст определяет топологию связей между портами, участвующими в конференции, то есть возможные направления потоков информации для каждой пары портов.

Атрибутами контекста являются: идентификатор контекста ContextID, топология контекста (кто кому передает и от кого принимает информацию), приоритет (один из 16 уровней), индикатор "аварийного вызова" (высший приоритет в обслуживании). Протокол имеет средства, чтобы управлять параметрами контекста.

 

 

9.2 Команды протокола Megaco

 

Megaco/H.248 определяет восемь команд, которые обеспечивают возможность управлять и манипулировать контекстами и окончаниями. Большинство команд предназначено для того, чтобы передаваться из Softswitch  в транспортные шлюзы MG, за исключением команд Notify ServiceChange. Команды приведены в таблице 9.1.

 

Таблица 9.1 - Команды протокола Megaco/H.248

Команда	Направление передачи	Назначение
Add (Добавить)	Softswitch -> MG	Softswitch дает указание шлюзу добавить порт к контексту и в то же время может использо-ваться для создания нового контекста
Modify (Изменить)	Softswitch -> MG	Softswitch дает указание шлюзу изменить свойства порта
Subtract (Отключить)	Softswitch -> MG	Softswitch удаляет порт из контекста
Move (Перевести)	Softswitch -> MG	Softswitch переводит порт из одного контекста в другой в одно действие
AuditValue (Проверить порт)	Softswitch -> MG	Softswitch запрашивает текущие свойства порта, произошедшие события или сигналы, передаваемые в канал, а также статистику, собранную на текущий момент времени
AuditCapabilities (Проверить возможности порта)	Softswitch -> MG	Softswitch запрашивает возможные значения свойств порта, список событий, которые могут быть выявлены портом, список сигналов, которые порт может посылать в канал, статические данные
Notify (Уведомить)	MG -> Softswitch	Шлюз информирует Softswitch о произошедших событиях
ServiceChange (Рестарт)	MG -> Softswitch, Softswitch -> MG	Шлюз информирует Softswitch о том, что один или несколько портов выходят из рабочего состояния или возвращаются в рабочее состояние. Softswitch может предписать порту или группе портов выйти из обслуживания или вернуться в обслуживание

 

9.3 Дескрипторы Megaco/H.248

 

При создании портов некоторые свойства присваиваются им по умолчанию. При помощи протокола Megaco/H.248 контроллер может изменять свойства портов шлюза. Свойства портов группируются в дескрипторы, которые включаются в команды и ответы управления портами [2, 8, 9].

Megaco/H.248 определяет ряд дескрипторов, предназначенных для использования вместе с командами и ответами [2]. Эти дескрипторы образуют параметры команды и/или ответа и содержат дополнительную информацию об из свойствах. В зависимости от команды или ответа тот или иной дескриптор бывает обязательным, опциональным или запрещенным.

Общий формат дескриптора такой:

Descriptorname=<someID>{parm=value, parm=value, …}.

 

Дескриптор модема – Modem - идентифицирует тип и параметры модема, которые следует использовать в соединениях модема при передаче аудио, видео или данных.

Дескриптор мультиплексирования – Mux - Описывает тип мультиплексирования в мультимедийном терминале. Протокол поддерживает тип мультиплексирования Н.221, Н.223, Н.226. V.76 и Nx64K.

Дескриптор среды – Media – описывает различные информационные потоки. Это иерархический дескриптор. Он содержит общий дескриптор – дескриптор состояния окончания, который применим к окончанию в общем, и ряд дескрипторов потоков, применимых к каждому медиа-потоку отдельно. Дескриптор среды содержит три подчиненных дескриптора локальный дескриптор управления, локальный дескриптор и удаленный дескриптор, иерархию можно представить так:

Дескриптор среды

Дескриптор потока

Локальный дескриптор управления

Локальный дескриптор

Удаленный дескриптор

Дескриптор состояния окончания – TerminationState - Специфицирует свойства порта шлюза.

Дескриптор содержит два параметра:

- ServiceStates;

- EventBufferControl.

Параметр ServiceStates описывает статус порта (работает в тестовом режиме - test, находится в нерабочем состоянии - out of service, по умолчанию указывается, что порт работает в нормальном режиме - in service).

Параметр EventBufferControl описывает реакцию шлюза на событие, о котором не надо немедленно оповещать контроллер. Определены две реакции на событие: игнорировать или обработать.

10 Лекция. Протоколы работы системы гибкого коммутатора

 

Цель лекции: изучение магистрантами протокола Megaco/H.248.

Содержание:

-          дескрипторы протокола Megaco/H.248;

-          транзакции в Megaco/H.248;

-          структура сообщения Megaco/H.248;

-          наборы сигналов и событий в Megaco/H.248.

 

10.1 Дескрипторы Megaco/H.248

 

Дескриптор потока – Stream - включает в себя ряд дескрипторов:  LocalControlDescriptor,  LocalDescriptor, RemoteDescriptor и идентифицируется с помощью StreamID.  Значения StreamID используются между MG и Softswitch, чтобы указывать какие медиа-потоки взаимосвязаны [2, 8, 9].

LocalControlDescriptor – содержит сведения об особых характеристиках медиа-потока:

1) Mode – режим - режим работы и ряд свойств порта. Параметр Mode может принимать значения только передача, только прием, передача/прием, неактивный, закольцован, удален (send-only, receive-only, send/receive, inactive, loop-back и delete). Дескриптор передается на участке между шлюзом и Softswitch.

2) ReserveGroup резервирование ресурсов для группы характеристик.

3) ReserveValue резервирование ресурсов для определенной характеристики.

LocalDescriptor – содержит параметры, описывающие информационный поток, передаваемый или принимаемый данным шлюзом. Информация, содержащаяся в этом дескрипторе, переносится от одного шлюза к другому.

RemoteDescriptor - содержит параметры, описывающие информационный поток, передаваемый или принимаемый удаленным шлюзом. Информация, содержащаяся в этом дескрипторе, переносится от одного шлюза к другому.

Дескриптор событий – Events – содержит список событий, которые шлюз должен обнаруживать и сообщать в Softswitch, и реакцию на эти события. Определены следующие реакции: NotifyAction (известить Softswitch), Accumulate (сохранить информацию о событии в буфере), AccumulateByDigitMap (накопить цифры номера в соответствии с планом нумерации), KeepActive (известить Softswitch, и продолжить передачу сигнала).

Дескриптор сигнала - Signals - содержит список сигналов, передачу которых порт шлюза должен начать или прекратить.

Дескриптор проверки – Audit Descriptor - содержит информацию (в виде ряда дескрипторов), которую необходимо  передавать из шлюза в Softswitch. Посылается в командах AuditValue и AuditCapabilities.

Дескриптор ServiceChangeDescriptor   - содержит информацию, относящуюся к изменению состояния порта шлюза, такую как причина, метод изменения и др.

Тип изменения обслуживания относится к параметру ServiceChangeMetod, который может принимать значения: Graceful – постепенно, Forced – принудительное, Restart – перезапуск, Disconnected – отключено, Handoff – передача управления, Failover – неисправность.

Дескриптор - DigitMap - описание плана нумерации. При помощи этого дескриптора Softswitch информирует шлюз об используемом плане нумерации.

Дескриптор StatisticsDescriptor - содержит статистическую информацию, собранную портом за время соединения.

Дескриптор Observed Events        - содержит информацию о произошедших событиях. Передается в командах Notify и AuditValue

Дескриптор ошибки - Error – предается в ответе, когда не может быть выполнена команда.

Дескриптор топологии – Topology – соответствует только контексту. Указывает как должны протекать в контексте медиа-потоки.

Транзакции – это совокупность команд и ответов на команду, относящиеся к одному контексту, передаются между Softswitch и шлюзом.

Команды передаваемые между Softswitch и шлюзом, группируются в структуры, которые устроены так, что за набором команд, относящихся к одному контексту, может следовать набор команд, относящихся к другому контексту [2, 8, 9]. Сгруппированные команды передаются вместе в едином блоке TransactionRequest, рисунок 10.1.

 

Рисунок 10.1

 

После приема TransactionRequest получатель выполняет вложенные команды. Команды выполняются последовательно, в том порядке, в каком они указаны в TransactionRequest. После выполнения всех команд передается ответ TransactionReply, рисунок 10.2. Он имеет структуру, аналогичную структуре TransactionRequest.

 

Рисунок 10.2

 

Если получателю TransactionRequest потребуется некоторое время для выполнения запроса, он может передать отправителю этого запроса предварительный ответ, чтобы тот не считал запрос потерянным. Этот предварительный ответ TransactionPending – означает команда обрабатывается, рисунок 10.3.

 

Рисунок 10.3

 

10.2 Структура сообщения Megaco/H.248

 

Несколько транзакций протокола могут помещаться в сообщение. Сообщение снабжается заголовком идентифицирующим отправителя. Идентификатором сообщения - MID Message Identifier -  служит назначенное имя объекта, передающего сообщение, по умолчанию используется доменовое имя. Объекты протокола шлюзы и Softswitch должны использовать один и тот же MID во всех создаваемых ими сообщениях в течении всего времени взаимодействия между ними. Кроме того каждое сообщение содержит номер версии протокола, создавшего сообщение. Структура сообщения Megaco/H.248 представлено на рисунке 10.4.

Рисунок 10.4 - Структура сообщения Megaco/H.248

 

10.3 Наборы сигналов и событий в Megaco/H.248

 

Шлюзы разных типов могут использовать порты с сильно отличающимися характеристиками [2, 8, 9]. Чтобы обеспечить возможность взаимодействия шлюзов с гибким коммутатором, протокол Megaco/H.248 определяет типовые наборы (packages) характеристик, сигналов и событий для Softswitch и шлюзов разных типов. Softswitch может запросить у шлюза сведения , необходимые, чтобы знать, с какими из таких наборов он может работать. Определяемые в наборе характеристики, события, сигналы или статистические данные, а  также их параметры снабжаются идентификаторами. Типовой набор характеризуется базовым описанием, свойствами, предусматриваемые событиями, поддерживаемыми сигналами, предоставляемыми статистическими данными, годными для интерпретации и анализа, любыми процедурами, относящимися к надлежащей поддержке набора. Пример типового набора приведен на рисунке 10.5.

Рисунок 10.5 - Примеры типовых наборов Megaco/H.248

  

11 Лекция. Протоколы работы системы гибкого коммутатора

 

Цель лекции: изучение магистрантами протокола Megaco/H.248.

Содержание:

-          процесс установления и разрушения соединения по протоколу Megaco/H.248.

На рисунке 11.1 приведен пример установления соединения с использованием протокола Megaco/H.248 между двумя шлюзами типа Residential Gateway, управляемыми одним Softswitch [2].

 

 

Рисунок 11.1 - Алгоритм установления и разрушения соединения протоколу Megaco/H.248

 

В данном примере вызывающий шлюз MG1 - имеет IP-адрес 212.86.42.1, адрес вызываемого шлюза MG2 - 218.68.122.41, адрес Softswitch – 216.44.88.1. Порт сигнализации для связи по протоколу Megaco/H.248 для всех трех устройств по умолчанию имеет значение 55555.

1 Шлюз MG1 регистрируется у Softswitch при помощи команды ServiceChange. Использование нулевого контекста означает, что порт в настоящий момент не участвует ни в каком соединении, а использование идентификатора порта ROOT означает, что команда относится ко всему шлюзу, а не к какому-нибудь определенному порту.

2 Softswitch подтверждает регистрацию шлюза:

3 Шлюз имеет свободные аналоговые порты, которые должны быть запрограммированы для отслеживания изменения сопротивления абонентского шлейфа, означающего поднятие абонентом трубки, после чего шлюз должен передать абоненту акустический сигнал «Ответ станции». Программирование производится при помощи команды Modify с соответствующими параметрами, причем программируется порт, находящийся в нулевом контексте. В команде указывается идентификатор порта (terminationid) -А4444, идентификатор информационного потока (streamid) -1, транспортный адрес оборудования, передавшего команду - [216.44.88.1]: 55555, специфицируется режим -дуплексный (SendReceive).

4 Шлюз MG1 подтверждает выполнение команды Modify:

 

5 Подобным же образом программируется аналоговый порт шлюза MG2, в нашем примере имеющий идентификатор А5555. Далее шлюз MG1 обнаруживает, что абонент А поднял трубку и извещает об этом событии Softswitch при помощи команды Notify.

 

6 Softswitch подтверждает получение команды Notify

 

7 На следующем шаге Softswitch дает шлюзу инструкцию накапливать цифры номера вызываемого абонента в соответствии с выбранным планом нумерации. Кроме того, после получения первой цифры номера необходимо остановить передачу акустического сигнала «Ответ станции».

 

8 Шлюз подтверждает получение команды Modify:

9 Цифры номера вызываемого абонента накапливаются шлюзом MG1, после чего они сравниваются с планом нумерации и передаются в Softswitch.

10 полученное сообщение подтверждается шлюзом:

 

11 Далее Softswitch анализирует цифры номера вызываемого абонента, полученные от шлюза MG1 и определяет, что соединение должно проходить через шлюз MG2, к которому подключен вызываемый абонент. К вновь образованному контексту в шлюзе MG1 добавляются при помощи команды Add физическое окончание А4444 (аналоговый абонентский интерфейс - абонентА) и виртуальный порт RTP. Так как в этот момент шлюз, к которому прикреплен вызывающий абонент, не имеет информации о шлюзе MG2, то Softswitch предписывает шлюзу MG1 только принимать информацию (режим receive-only). Также Softswitch специфицирует в команде Add предпочтительные для использования алгоритмы кодирования.

 

 

 

12 Лекция. Протоколы работы системы гибкого коммутатора

 

Цель лекции: изучение магистрантами протокола Megaco/H.248.

Содержание:

-          процесс установления и разрушения соединения по протоколу Megaco/H.248.  

12 Шлюз MG1 создает новое виртуальное окончание RTP-порт указывает его транспортный адрес: 212.86.42.1 и UDP/RTP-порт (22220).

13 Softswitch создает в шлюзе MG2 контекст для установления дуплексного соединения (режим SendReceive) с вызывающим пользователем.

14 Создание контекста подтверждается, физический порт шлюза MG2 А5555 соединяется с UDP/RTP-портом А5556.  Отметим, что RTP-порт имеет номер 1111, т.е. отличный от номера порта Megaco/H.248 - 55555.

15 Softswitch предписывает шлюзу MG1 начать передачу вызывающему абоненту А акустического сигнала "Контроль посылки вызова":

16 Шлюз MG1 подтверждает передачу КПВ в порт А4444.

17 Softswitch предписывает порту А5555 шлюза MG2 начать передачу вызывного сигнала.

18 Шлюз MG2 подтверждает передачу сигнала «Посылка вызова» вызываемому абоненту.

19 На этом этапе обоим абонентам, участвующим в соединении, посылаются соответствующие сигналы, и шлюз MG2 ждет, пока вызываемый абонент примет входящий вызов, после чего между двумя шлюзами будут организованы двунаправленные разговорные каналы. Шлюз MG2 обнаружил, что вызываемый абонент поднял трубку, и извещает об этом Softswitch.

20 Softswitch подтверждает получение команды Notify.

21 Далее Softswitch предписывает шлюзу MG2 прекратить передачу вызывного сигнала.

22 Шлюз MG2 подтверждает выполнение команды.

23 Далее Softswitch разрешает шлюзу MG1 не только принимать, но и передавать информацию (режим SendReceive), и останавливает передачу вызывающему абоненту акустического сигнала «КПВ».

24 Шлюз MG1 подтверждает выполнение команды:

25 После этого начинается разговорная фаза соединения, в течение которой участники обмениваются речевой информацией. Следующим шагом Softswitch принимает решение проверить RТР-порт в шлюзе MG2.

26 Шлюз MG2 выполняет команду. В ответе на команду AuditValue передается вся запрашиваемая информация, в том числе статистика, собранная за время соединения. Кроме того, из ответа видно, что не произошло никаких событий и не передавалось никаких сигналов.

13 Лекция. Протоколы работы системы гибкого коммутатора

 

Цель лекции: изучение магистрантами протоколов Megaco/H.248 и SIGTRAN.

Содержание:

-          процесс разрушения соединения по протоколу Megaco/H.248;

-          протокол SIGTRAN, архитектура, уровни, протоколы.

 

13.1 Разрушение соединения по протоколу Megaco/H.248

 

27 Вызываемый абонент первым разрушает связь и шлюз MG2 извещает об этом Softswitch:

28 Softswitch подтверждает получение сообщения Notify.

29 Получив информацию от любого из шлюзов о том, что один из абонентов положил трубку, Softswitch завершает соединение. К обоим шлюзам передается команда Subtract. Алгоритм завершения соединения предусматривает одинаковый обмен сигнальными сообщениями между Softswitch и обоими шлюзами, поэтому рассматривается на примере MG2.

30 Каждый из портов шлюза MG2, участвующих в соединении (A5555 и A5556), возвращает статистику, собранную за время соединения.

31 После завершения соединения Softswitch предписывает шлюзам MG1 и MG2 быть готовыми к тому, что кто-то из обслуживаемых ими абонентов поднимет трубку. Примечательно, что портам шлюза, отображаемым окончаниями в нулевом контексте, по умолчанию может быть предписано обнаруживать, что абонент поднял трубку, при этом Softswitch не передает шлюзам специальные команды, как это было показано ранее.

 

13.2 Протокол SIGTRAN

 

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

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

2) средства идентификации конкретного транспортируемого протокола сигнализации сети с коммутацией каналов;

3) общий базовый протокол, определяющий форматы заголовков, расширения в целях информационной безопасности и процедуры для транспортировки сигнальной информации, а также (при необходимости) расширения для введения конкретных индивидуальных протоколов сигнализации сети с коммутацией каналов;

4) вместе с нижележащим сетевым протоколом (например, IP) обеспечивать функциональные возможности, соответствующие нижнему уровню конкретной сети с коммутацией каналов.

Архитектура протокола Sigtran, рисунок 13.1, определенная RFC2719,  предусматривает уровни:

-          стандартный протокол IP;

 

Рисунок 13.1 -  Архитектура протоколов SIGTRAN

 

-          общая транспортировка сигнальной информации через инфраструктуру сети Интернет без ошибок и в должном порядке, независимо от сети IP по протоколу передачи информации управления потоком (Stream Control Transmission Protocol - SCTP);

-          уровень адаптации обеспечивающий интерфейс с протоколами и приложениями верхних уровней.

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

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

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

Пользовательский уровень адаптации ISDN (IUA) – отвечает за необходимость доставки сообщений сигнальных протоколов сети с коммутацией каналов (Circuit Switched Network - CSN) от сигнального шлюза (SG) ISDN к Softswitch. Механизм доставки должен поддерживать:

-         транспортировку пограничных примитивов Q.921/Q.931;

-         связь между модулями управления уровнями SG и Softswitch;

-         управление активными связями между SG и Softswitch.

Данным уровнем предусматривается поддержка первичного и базового доступов ISDN (PRA и BRA) как для режима «точка - точка», так и для разветвленного режима «точка - несколько точек». Процедуры уровня адаптации QSIG не отличаются от аналогичных процедур Q.931.

Пользовательский уровень адаптации МТР уровня 2 (M2UA – MTP2 –User Adaptation Layer) - обеспечивает эмуляцию одного звена МТР между двумя узлами ОКС7, рисунок 13.2. Избыточность звеньев достигается посредством многоточечного подключения собственно в пределах SCTP. В направлении к DPC (Destination Point Code – Код пункта назначения ОКС7) может иметься несколько звеньев. Избыточность приложений поддерживается на пользовательских уровнях адаптации посредством переключения с одного соединения на другое при необходимости.

Рисунок 13.2 - Функции M2UA в Softswitch

 

При необходимости доставки сообщений сигнальных протоколов сети КК от сигнального шлюза (SG) к Softswitch или пункту сигнализации IP (IPSP) механизм доставки должен поддерживать:

-         интерфейс на границе МТР уровня 2 и МТР уровня 3;

-         связь между модулями управления уровнями SG и Softswitch;

-         управление активными связями между SG и Softswitch.

Другими словами, SG будет иметь возможность транспортировать сообщения МТР уровня 3 к MGC или IPSP. В случае доставки от SG к IPSP, SG и IPSP функционируют как традиционные узлы ОКС7, используя сеть IP в качестве нового типа звена ОКС7. Этим обеспечивается полномасштабная обработка сообщений МТР уровня 3 и соответствующие возможности управления сетью.

14 Лекция. Протоколы работы системы гибкого коммутатора

 

Цель лекции: изучение магистрантами протоколов  SIGTRAN и BICC.

Содержание:

-          протокол SIGTRAN – протоколы;

-          протокол BICC.

 

14.1 Протокол SIGTRAN

 

Пользовательский уровень адаптации М2РА (MTP2 Peer-to-Peer Adaptation Layer) - обеспечивает адаптацию SCTP к МТР3, но уже в другой области. Аналогично случаю с M2UA, уровень МТР3 в узле сети IP (Softswitch, в частности) обменивается информацией с М2РА, как если бы он был обычным МТР2. Различия между М2UA и М2РА определяются их ролями в сетевой архитектуре: если Softswitch соединяется с сетью ОКС7 просто на правах терминала сигнализации ОКС7, то достаточно применения М2UA. Шлюз SG, который использует М2РА, сам фактически является транзитным пунктом сигнализации STP на базе IP, у него есть собственный код пункта сигнализации (DCP), он может также выполнять функции сигнализации верхнего уровня, такие как функции SCCP [2].

Пользовательский уровень адаптации МТР уровня 3 (M3UA) - обеспечивает интерфейс между SCTP и теми протоколами ОКС7, которые используют услуги МТР3, например ISUP и SCCP. Благодаря M3UA эти протоколы не ощущают, что вместо типичной транспортировки МТР3 применяется транспортировка SCTP поверх IP. Однако M3UA – просто адаптационный уровень между протоколами верхнего уровня и SCTP, он не является полной копией МТР3 в IP-сети и не реализует некоторые стандартные управляющие сообщения сетевой сигнализации МТР3, рисунок 14.1.

 

Рисунок 14.1 - Протокол M3UA

Для выхода на нужный сервер приложений (Application Server – AS) в SG должна осуществляться строгая процедура присвоения.

Уровень M3UA должен обслуживать несколько соединений SCTP (или по крайней мере одно). Выбор соединения SCTP может производиться по одной или нескольким частям полей DPC (код пункта назначения ОКС7).

Пользовательский уровень адаптации SCCP (SUA)

Средствами сети IP возможна доставка сообщений подсистем пользователей SCCP. Архитектура такой доставки может представлять собой связь от SG OKC7 к сигнальному узлу IP (например резидентной базе данных IP) или связь между двумя оконечными точками, расположенными в пределах сети IP рисунок 14.2. Механизм доставки должен поддерживать:

 

Рисунок 14.2 - Протокол SUA

 

-          передачу сообщений пользователей SCCP;

-          услугу SCCP, неориентированную на соединение;

-          услугу SCCP, ориентированную на соединение;

-          взаимодействие равноуровневых объектов пользователей SCCP в полном объеме;

-          управление транспортными связями SCTP между SG и одним или несколькими сигнальными узлами IP;

-          функционирование сигнальных узлов IP с распределенной структурой;

-          в целях управления – выдачу отчетов об изменении состояний конфигурации в асинхронном режиме.

 

14.2 Протокол BICC

 

Для взаимодействия Softswitch между собой теоретически должен

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

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

 

 

Рисунок 14.3 - Протокол BICC

 

На рисунке 14.3 представлены узлы всех рассмотренных типов.

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

 

15 Лекция. Примеры реализации Softswitch

 

Цель лекции: изучение магистрантами примеров реализации Softswitch.

Содержание:

-          примеры различных платформ Softswitch;

-          Softswitch в сетях подвижной связи.

 

15.1    «Протей-МКД»

 

Компания «НТЦ Протей» предлагает мультисервисный коммутатор доступа (МКД) на базе программного коммутатора 5 класса [2]. На рисунке 15.1 показана архитектура мультисервисной сети, построенной на основе российского программно-аппаратного комплекса и предоставляющая такие услуги, как передача речи, видео и данных. Коммутатор «ПРОТЕЙ-МКД» может использоваться в городских, сельский и корпоративных телефонных сетях и дает возможность плавной миграции от TDM к IP.

Рисунок 15.1 - Архитектура сети NGN на базе «Протей-МКД»

 

«Протей-МКД» осуществляет управление вызовами в сети NGN, предоставляет интеллектуальные услуги, а также классические функции оконечной цифровой АТС:

-         поддержка СОРМ, протоколирование информации о вызовах, управление правами

-         пользователей и т.д.

Программный коммутатор Softswitch может взаимодействовать со следующим оборудованием:

-          сети с коммутацией каналов (по интерфейсам E1): цифровые АТС, узлы управления услугами (протокол INAP-R);

-          сети с пакетной коммутацией по интерфейсам Ethernet 100/1000 Мбит/c;

-          другие программные коммутаторы по протоколам SIP/SIP-T, H.248/MEGACO;

-          оборудование мультисервисного доступа (например, мультисервисный абонентский концентратор «Протей-МАК»);

-          прокси-серверы и другие узлы SIP-доменов;

-          серверы приложений по протоколу Parlay;

-          IP-телефоны, шлюзы IP-телефонии.

 

15.2 IskraTEL SI3000 CS

 

Компанией Iskratel разработано полнофункциональное семейство оборудования для сетей NGN – SI3000 NG, рисунок 15.2 [2].

Программный коммутатор SI3000 Call Server играет центральную роль в технических решениях современных сетей. Он обеспечивает предоставление голосовых услуг, услуг передачи данных и мультимедийных услуг. Используя различные протоколы, он управляет сетевыми элементами NGN, услугами, вызовами и соединениями.

Функциональность программного коммутатора SI3000 Call Server обеспечивает использование системы на уровне местной станции (класс 5), а также на уровне транзитной станции (класс 4), либо в сочетании этих двух уровней.

Программный коммутатор SI3000 Call Server можно применять в качестве сервера SIP как для домашних, так и для корпоративных пользователей. Его применение на сетях IMS не вызовет никаких затруднений. Поддержка традиционных сетей, реализация функций, требуемых регуляторными органами, превосходная масштабируемость – все эти качества, присущие программному коммутатору SI3000 Call Server, делают его идеальным выбором для заказчиков, намеренных построить сеть с прицелом на будущее и при этом сохранить уже созданную инфраструктуру.

Преимущества программного коммутатора SI3000 Call Server:

-        развитие сети, движимое стремлением к получению новых доходов;

-        беспрепятственное внедрение новых услуг;

-        функциональная совместимость с оборудованием различных производителей;

-        решение с прицелом на будущее.

 

15.2    ZTE ZXSS10 SS1

 

Китайская компания ZTE предлагает собственное Softswitch-решение - программный коммутатор ZXSS10 SS1. Также в состав NGN-оборудования компании входят: шлюз сигнализации (ZXSS10 S100), транспортный шлюз (ZXSS10 T200, M100), шлюз доступа (ZXSS10 A200), IAD (ZXSS10 1500, 1600), Сервер приложений (ZXSS10 APP), медиа-сервер (ZXSS10 MeS) и другие.

Система ZTE Softswitch представляет собой открытую программную систему с распределенной реализацией коммуникационных функций. Она предоставляет интегрированные сетевые услуги, объединяющие в себе функции передачи речи, данных и видео; поддерживает также традиционные протоколы коммутации и обеспечивает взаимодействие между сетями различных типов посредством преобразования протоколов.

Система рассчитана на предоставление базовых услуг связи, услуг интеллектуальной сети, услуг с добавленной стоимостью и мультимедийных услуг.

Программный коммутатор ZXSS100 SS1 является ключевым устройством NGN сети ZTE, он выдерживает максимальную нагрузку в 2 млн вызовов в ЧНН и максимальную сигнальную нагрузку по ОКС7 - 200 000 каналов.

ZXSS100 SS1 поддерживает довольно стандартный набор протоколов:

-          сигнализация: ISUP/TUP через IP, Q.931, BICC, SIP-T, H.323;

-          транспорт: TCP, UDP, SCTP, TCAP/SCCP, M3UA;

-          медиа-связь: H.248, SIP, MGCP.

 

15.4 Softswitch  в подвижных сетях - MSOFTX3000

 

MSOFTX3000 от компании HUAWEI – это программный (гибкий) коммутатор мобильной связи большой емкости компании Huawei [10].

На уровне управления домена CS (Circuit switched – Домен с коммутацией каналов) в опорной сети WCDMA узел MSOFTX3000 выступает в качестве сервера MSC. Он обеспечивает исполнение таких функций, как управление вызовами и соединениями для услуг передачи речи и данных на базе IP или TDM. При поддержке протоколов и функций как GSM, так и WCDMA, MSOFTX3000 обеспечивает плавный переход от GSM к WCDMA MSOFTX3000 может функционировать как следующие сетевые элементы (NE):

-          Сервер VMSC/VLR (цVisited Mobile Switching Center – Визитный центр коммутации мобильной связи/Visitor Location Register - Визитный регистр местоположения)

-          Сервер GMSC4 (Gateway Mobile Switching Center - Шлюз центра коммутации мобильной связи)

-          Сервер TMSC

-          MSC/SSP (Центр программной коммутации мобильной связи/ Service Switching Point - Пункт коммутации услуг).

MSOFTX3000 поддерживает протоколы и функции как GSM, так и WCDMA. Кроме того, он работает в качестве разных типов NE и предоставляет следующие услуги:

-          Основные: передача речи, SMS, факсов GSM, несущая GSM и несущая UMTS.

-          Вспомогательные: переадресация вызовов, запрет вызовов, определение номера, завершение вызовов, многоадресная связь, неструктурированная передача данных, закрытая группа пользователей, принудительная передача вызова, улучшенное многоуровневое прерывание и организация приоритетов.

-          Определяемые оператором услуги запрета: запрет исходящих вызовов, запрет исходящих международных вызовов, запрет исходящих международных вызовов за исключением вызовов в родную страну PLMN, запрет всех входящих вызовов, запрет дополнительного управления, запрет входящих вызовов при выезде абонента за пределы родной страны PLMN.

-          IN-услуги: предоплата и виртуальная частная сеть мобильной связи.

-          Дополнительные: мультимедийная передача, определение местоположения мобильной станции, обратный вызывной сигнал, равный доступ, тарификация на базе времени и зоны, усовершенствованный запрет роуминга, услуга альтернативной линии, двойной номер для речи и видео.

 

16 Лекция. Примеры реализации Softswitch

 

Цель лекции: изучение магистрантами примеров реализации Softswitch.

Содержание:

-          Softswitch в сетях подвижной связи - MSOFTX3000.

 

16.1 Структура аппаратного обеспечения MSOFTX3000

 

Аппаратное обеспечение MSOFTX3000 состоит из трех подсистем [10]:

-          Полка OSTA (телекоммуникационная платформа с открытыми стандартами);

-          BAM;

-          iGWB (Платформа iGateway Bill - шлюз биллинга).

-          «BAM» - сокращение от Back Administration Module (вспомогательный модуль управления).

Полки OSTA формируют хост MSOFTX3000. Этот хост предоставляет функции обработки сигнализации и услуг, управления ресурсами. BAM, локальные терминалы техобслуживания (LMT) и iGWB формируют подсистему O&M MSOFTX3000. Эта подсистема обеспечивает функции эксплуатации и поддержки, а также предоставляет функцию управления CDR.

Структура аппаратного обеспечения MSOFTX3000 показана на рисунке 16.1.

 

FE: Fast Ethernet

LMT: локальный терминал техобслуживания

 

Рисунок 16.1 -  Структура аппаратного обеспечения MSOFTX3000

16.2 Организация связи между устройствами системы MSOFTX3000

 

Полки связываются между собой через внутренний Ethernet. Каждая полка подключается к коммутаторам LAN 0 и 1 двумя сетевыми кабелями.

Полки связываются с BAM и iGWB через внутренний Ethernet. BAM и iGWB подключаются к коммутаторам LAN 0 и 1 двумя сетевыми кабелями.

BAM и iGWB подключаются к концентратору LAN сетевым кабелем. Терминалы LMT взаимодействуют с BAM и iGWB по протоколам TCP/IP в режиме «клиент-сервер».

 

16.3 Логическая структура системы аппаратного обеспечения MSOFTX3000

 

Логическая структура включает пять модулей [10]:

-          системный модуль поддержки (SSM);

-          интерфейсный модуль (IM);

-          модуль обработки сигнализации низкого уровня (SLLPM);

-          модуль обработки услуг (SPM);

-          модуль эксплуатации и техобслуживания (OMM).

Логическая структура аппаратного обеспечения MSOFTX3000 показана на рисунок 16.2.

 

 

Рисунок 16.2 -  Логическая структура аппаратного обеспечения MSOFTX3000

 

Системный модуль поддержки SSM реализует следующие функции:

-          загрузка ПО и данных;

-          управление и техническое обслуживание устройств;

-          обеспечение связи между платами.

-          SSM включает следующие модули:

-          модуль управления системой (WSMU);

-          модуль системных интерфейсов (WSIU);

-          модуль управления горячей заменой (WHSC);

-          базовый коммутатор LAN.

WSMU является платой главного управления полки. С помощью системных шин и последовательного порта она может обеспечивать следующие функции для всех устройств системы:

-          контроль загрузки;

-          конфигурирование данных;

-          контроль рабочего состояния.

WSIU реализует следующие функции:

-          интерфейс Ethernet, предоставляемый для WSMU;

-          преобразование уровня для сигнала с последовательного порта асинхронной передачи от WSMU;

-          два физических интерфейса, предоставляемые последовательному порту синхронной передачи;

-          определение номера полки по настройке DIP-переключателя.

WHSC реализует следующие функции:

-          мостовое соединение правой и левой шин совместно используемых ресурсов;

-          управление горячим переключением плат;

-          переключение шин LAN внутри полки.

Потоки трафика сигнализации проходят через шину LAN, предоставляемую WHSC. Конфигурация WHSC не имеет CPU. Поэтому, WHSC конфигурируется и поддерживается непосредственно модулем WSMU через шину Ethernet.

Базовый коммутатор LAN реализует следующие функции:

-          взаимосвязь нескольких полок;

-          соединение между полками и устройствами управления.

 

16.4 Интерфейсный модуль

 

Для соответствия требованиям к системной организации сети IM предоставляет различные физические интерфейсы, включая:

-          интерфейс узкополосной передачи: для реализации кадрирования и функции интерфейсов линий (функция MTP1) интерфейсный модуль E1_pool (WEPI) обеспечивает 8 интерфейсов E1. WEPI взаимодействует с модулем обработки MTP2 WCPC (плата расширения WCSU) модуля обработки сигнализации низкого уровня через внутренний HW.

-          интерфейс ATM-2M: для соединения с WEAM WEPI предоставляет 8 интерфейсов E1 и 2 кабеля сигнализации 8 Мбит/с HW. WEAM, сегментирует и заново собирает соты ATM в потоках данных, передает сигнализацию модулю WBSG через внутреннюю шину LAN.

-          интерфейс FE: WIFM предоставляет электрический интерфейс 100 Мбит/с Ethernet путем конфигурирования платы расширения FEP и WBFI. Он сводит информационные потоки широкополосной сигнализации и распределяет их по соответствующим модулям обработки, на основании IP-адреса и номера порта.

 

16.5 Модуль обработки сигнализации низкого уровня

 

SLLPM обеспечивает функции обработки протоколов нижнего уровня. В модуль входят блок обработки ОКС-7 MTP2 (WCPC) и блок обработки SCTP (WBSG).

WCPC обрабатывает ОКС-7 MTP2 узкополосной передачи через каналы E1 и связывается с блоком обработки услуг (WCSU) по внутренней шине. WCPC – это плата расширения WSCU.

WBSG обрабатывает сигнализацию низкого уровня, передаваемую через IP и ATM (с помощью интерфейса ATM 2 Мбит/с), направляет ее плате обработки услуг верхнего уровня.

 

16.6 Модуль обработки услуг

 

SPM состоит из блока обработки услуг (WCCU/WCSU), блока центральной базы данных (WCDB), блока базы данных VLR (WVDB) и блока управления медиа-шлюзом (WMGC).

WCCU обрабатывает протоколы сигнализации на 3-м или более высоком уровне (MTP3, M3UA, ISUP, SCCP, TCAP, MAP и CAP), необходимые в виду особенностей услуг. Кроме того, он реализует управление вызовами на прикладном уровне и обрабатывает интеллектуальные услуги CAMEL. В этой системе две платы WCPC, установленные на плате WCCU, формируют WCSU.

Как модуль центральной базы данных, WCDB организует централизованное хранение ресурсов, таких как ресурсы соединительных линий межстанционной связи, абонентские данные локальной станции, данные о статусе возможностей шлюза. Также он предоставляет услугу запроса ресурсов вызова для модуля обработки услуг.

WVDB – это динамическая база данных, предоставляющая функции VLR.

WMGC управляет медиа-шлюзами H.248.

 

16.7 Модуль эксплуатации и техобслуживания

 

OMM реализует следующие функции:

-          выполняет операции эксплуатации, техподдержки и техобслуживания оборудования;

-          предоставляет пользователям интерфейсы «человек-машина» для операций локального O&M;

-          предоставляет интерфейсы системе сетевого управления (NMS).

Список  литературы

 

1. Семенов Ю.В. Проектирование сетей связи следующего поколения. – Санкт-Петербург, - 2005.-366 с.

2. Гольштейн А.Б. Гольштейн Б.С. Softswitch. – Санкт-Петербург, БХВ- Санкт-Петербург - 2006.-366 с.

3. Сети следующего поколения NGN/ под ред.А.В.Рослякова. - М.: Эко-Трендз, 2009. – 424 с.

4. И.Г. Бакланов. NGN: принципы построения и организации. Под ред.Ю.Н. Чернышова. – М.: Эко-Трендз, 2008. – 400 с.

5. Гулевич Д.С. Сети связи следующего поколения. Интернет-университет информационных технологий - ИНТУИТ.ру, БИНОМ. Лаборатория знаний, 2007 г. 

6. Internet Communications Using SIP: Delivering VoIP and Multimedia Services with Session Initiation Protocol, Second Edition Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256, www.wiley.com

7. N. Greene, M. Ramalho, and B. Rosen, “Media Gateway Control Protocol Architecture and Requirements,” RFC 2805, April 1999: http://www.ietf.org/rfc/rfc2805.txt (accessed in August 2002).

8. P. Blatherwick, R. Bell, and P. Holland, “Megaco IP Phone Media Gateway Application Profile,” RFC 3054, January 2001: http://www.ietf.org/rfc/rfc3054.txt (accessed in August 2002).

9. F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, and J. Segers, “Megaco Protocol Version 1.0,” RFC 3015, November 2000: http://www.ietf.org/rfc/rfc3015.txt (accessed in August 2002).

10. Центр коммутации мобильной связи MSOFTX3000 производства компании HUAWEI. Техническое руководство – архитектура и принципы. V100R002 - Huawei Technologies Co., Ltd., 2009.

 

Содержание

 

Введение	3
1 Лекция. Понятие систем гибкой коммутации	4
2 Лекция. Понятие систем гибкой коммутации	8
3 Лекция. Сети NGN	11
4 Лекция. Структура систем гибкой коммутации	15
5 Лекция. Структура систем гибкой коммутации	18
6 Лекция. Структура систем гибкой коммутации	23
7 Лекция. Протоколы работы системы гибкого коммутатора	27
8 Лекция. Протоколы работы системы гибкого коммутатора.	32
9 Лекция. Протоколы работы системы гибкого коммутатора	36
10 Лекция. Протоколы работы системы гибкого коммутатора	40
11 Лекция. Протоколы работы системы гибкого коммутатора	44
12 Лекция. Протоколы работы системы гибкого коммутатора	48
13 Лекция. Протоколы работы системы гибкого коммутатора	52
14 Лекция. Протоколы работы системы гибкого коммутатора	56
15 Лекция. Примеры реализации Softswitch	60
16 Лекция. Примеры реализации Softswitch	64
Список литературы	68

 

Сводный план 2010г., поз 280