Обработка сигнала в NGN

1. Архитектура сетей NGN и обоснованность их построения

1.1 Принципы построения традиционных телефонных сетей

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

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

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

Можно выделить следующие достоинства коммутации каналов:

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

· Низкий и постоянный уровень задержки передачи данных через сеть. Это позволяет качественно передавать данные, чувствительные к задержкам (называемые также трафиком реального времени) — голос, видео, различную технологическую информацию.

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

1.2 Недостатки TDM сетей и предпосылки перехода к NGN

Внедрению систем IP-сигнализации способствует целый ряд факторов. Это и архитектурные ограничения существующих сетей ОКС7, и необходимость операторов связи снижать эксплуатационные расходы, и конвергенция сетей передачи речи и данных, и ускорение процесса развертывания новых услуг связи.

Присущая IP-технологиям высокая эффективность использования полосы пропускания позволяет операторам связи существенно экономить средства. Каналы с временным мультиплексированием (TDM) в традиционных телефонных сетях проектируются с учетом наиболее неблагоприятной ситуации — пиковой нагрузки. Протоколы ОКС7 требуют, чтобы в штатной ситуации загруженность TDM-каналов не превышала 40%. Это приводит к тому, что на практике их средняя загрузка составляет 20—30%. Значит, 70—80% канальных ресурсов постоянно простаивают. Технологии IP обеспечивают динамическое выделение полосы пропускания по требованию, при этом ее стоимость оказывается зачастую на 75% ниже стоимости полосы пропускания TDM-сети с коммутацией каналов.

Ограничения, накладываемые технологией TDM на полосу пропускания, негативно влияют и на работу других элементов сети: серверов приложений, регистров положения, блоков контроля услу. Даже если мощности указанных элементов вполне достаточно для обработки большего объема трафика, ограничения протоколов ОКС7 на TDM-каналы, которые соединяют эти элементы с остальной сетью, не дают им «разогнаться». Поэтому для повышения производительности сети операторам приходится докупать дополнительные устройства, притом, что ресурсы имеющихся еще далеко не исчерпаны. Надо также иметь в виду следующее обстоятельство: добавление каждого нового элемента требует организации канала «точка—точка» и обновления маршрутных таблиц, а значит, дополнительных капитальных и эксплуатационных затрат. Хорошее масштабирование полосы пропускания в IP-сетях позволяет запросто справляться с флуктуациями трафика, упростить архитектуру сети, а различным базам данных работать с максимально возможной производительностью.

В дополнение к той экономии, которая обеспечивается за счет эффективного использования полосы пропускания и других ресурсов, IP-технологии позволяют операторам более экономично развивать сети. Они могут «виртуализировать» большое число серверов, которые будут «выглядеть» для сети ОКС7 как единый объект, работающий под управлением шлюза сигнализации. В случае необходимости добавить в сеть еще один сервер, достаточно будет всего лишь подключить его к ЛВС и, возможно, сделать соответствующие изменения в настройках шлюза сигнализации. Такая схема развития означает отсутствие каких-либо изменений (или их минимизацию) в остальной части сети, следовательно, опять-таки снижение расходов.

Как уже отмечалось, технологии IP гарантируют хорошее масштабирование полосы пропускания, а это как нельзя лучше подходит для служб, генерирующих «взрывной» трафик, объем которого может сильно меняться во времени. К таким службам относится SMS (Short Message Service), используемая сегодня для самых разных приложений, таких, как электронная почта и получение информации с Web-серверов. Операторы мобильных сетей отмечают значительные всплески SMS-трафика в праздничные и выходные дни. Подготовить сеть к подобным всплескам в рамках классической архитектуры ОКС7 сложно и дорого ввиду статического выделения полосы пропускания в TDM-сетях. Эффективным решением проблемы является перевод SMS-трафика из сетей ОКС7 в сети с сигнализацией на базе IP.

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

Можно привести следующую статистику:

— экономия на капитальных затратах до 70%;

— экономия на организации каналов доступа 60−80%;

— экономия на текущем обслуживании и ремонте сети до 50%;

1.3 Общие принципы построения сетей NGN

Для сетей NGN можно выделить пять характерных особенностей:

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

· применение систем коммутации с распределенной архитектурой, которые отличаются от традиционных (функционально ориентированных) телефонных станций;

· отделение функций, касающихся поддержки услуг, от коммутации и передачи;

· обеспечение возможности широкополосного доступа для любого пользователя;

· реализация функций эксплуатационного управления (в том числе делегированных пользователям) за счет Web технологии.

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

Стандартизацией NGN занимаются несколько международных организаций. Определенный вклад вносят МСЭ и ETSI (Европейский институт телекоммуникационных стандартов). Активно разрабатывает свои стандарты Международный консорциум пакетной связи — IPCC.

Ниже представлена архитектура NGN, предложенная МСЭ в рекомендации Y.1001.

Рис. 1. Архитектура NGN (по рек. Y.1001)

Медиа-шлюз выполняет достаточно простые функции преобразования информационных потоков. Слева от медиа-шлюза показан RTP-поток, который формируется при использовании транспортного протокола реального времени (Real-Time Transport Protocol), а справа — поток, образованный системой передачи с импульсно-кодовой модуляцией (ИКМ). Медиа-шлюз выполняет достаточно простые процедуры, но в крупной сети он должен обладать большой производительностью.

Медиа-шлюз управляется соответствующим контроллером — MGC (Softswitch). Контроллеры могут быть связаны между собой, что показано на рис. 1 пунктирной линией с надписью MGC/MGC. Контроллер взаимодействует также с интеллектуальной базой данных (Intelligent Database ID).

Над контроллером MGC показан шлюз сигнализации (SG). В сторону ТфОП (или сотовой сети) шлюз сигнализации передает и принимает информацию по сети общих каналов сигнализации (ОКС). В российской сети ОКС применяется подсистема пользователя ЦСИО — ISUP. Взаимодействие с контроллером MGC осуществляется через интерфейс, обозначенный как SG/MGC. Для связи с интеллектуальной базой данных определен интерфейс ID/SG. Для поддержки услуг ИС используется прикладной протокол интеллектуальной сети — INAP.

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

Рис. 2. Уровневая архитектура NGN

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

Уровень управления располагается на второй плоскости. В модели NGN этот уровень включает совокупность функций по управлению всеми процессами в телекоммуникационной системе, а также начисление платы за услуги связи и техническую эксплуатацию. Для реализации функций, которые выполняет этот уровень, производители телекоммуникационного оборудования разработали аппаратно-программные средства, именуемые Softswitch.

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

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

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

В сети NGN предполагается применять только открытые (стандартные) протоколы, которые позволяют при необходимости легко менять выполняемые функции. Особенность коммутационных станций ТфОП состоит в том, что они, как правило, имеют стандартные интерфейсы на входе и выходе. Практически все внутренние процессы в коммутационной станции, как в «черном ящике», поддерживались фирменными (нестандартными) протоколами, разработка которых осуществлялась производителем соответствующих аппаратно-программных средств.

Рисунок 3 иллюстрирует различия в архитектуре коммутационных станций ТфОП и Softswitch (NGN). Открытые протоколы и интерфейсы прикладного программирования (API) — неотъемлемая особенность архитектуры Softswitch (NGN).

Рис. 3. Архитектура коммутационных станций ТфОП и Softswitch

Для сети NGN определен ряд новых протоколов, часть из которых была разработана ранее. Целесообразно выделить пять следующих протоколов:

1. Протокол Н.323. Рекомендация МСЭ Н.323 была разработана для обеспечения установления соединения и передачи голосового и видео трафика по пакетным сетям, в частности Интернет и intranet, которые не гарантируют качества обслуживания (QoS). Используется протокол RTP, разработанный IETF (инженерная группа по проблемам Интернет), а также стандартные кодеки, отвечающие требованиям МСЭ, которые изложены в рекомендациях серии G. Протокол Н.323 был первым в технологии IP-телефонии, но сейчас он начал уступать позиции разработанному IETF протоколу SIP (инициирование сеансов связи), который оказался проще и лучше масштабировался.

2. Session Initiation Protocol. Это протокол прикладного уровня, с помощью которого осуществляются такие операции, как установление, изменение и завершение мультимедийных сессий или вызовов по IP-сети. В мультисервисных сетях SIP выполняет функции, аналогичные тем, которые реализованы в протоколе Н.323. Сессии SIP могут включать мультимедийные конференции, дистанционное обучение, Интернет-телефонию и другие подобные приложения. Сегодня SIP рассматривается многими участниками инфокоммуникационного рынка как международный стандарт.

3. Media Gateway Control Protocol. Протокол MGCP используется для управления шлюзами MG. Он разработан для архитектуры, в которой вся логика обработки вызовов располагается вне шлюзов, и управление выполняется внешними устройствами, такими, как MGC или агенты вызовов. Модель вызовов MGCP рассматривает медиа-шлюзы как набор конечных точек, которые можно соединить друг с другом.

4. MEGACO/H.248. Этот протокол, по всей видимости, заменит MGCP в качестве стандарта для управления медиа-шлюзами. MEGACO служит общей платформой для шлюзов, устройств управления многоточечными соединениями, а также устройств интерактивного голосового ответа.

5. Протокол Signalling Transport (SIGTRAN). Это набор протоколов для передачи сигнальной информации по IP-сетям. Он используется как в обоих видах шлюзов, так и в Softswitch. SIGTRAN реализует функции протокола SCTP (Simple ControlTransport Protocol) и уровней адаптации (Adaptation Layers). SCTP отвечает за надежную передачу сигнальной информации, осуществляет управление сигнальным трафиком, обеспечивает безопасность. В функции Adaptation Layers входит передача сигнальной информации от соответствующих сигнальных уровней, использующих услуги SCTP. Эти протоколы ответственны за сегментацию и пакетирование пользовательских данных, защиту от имитации законного пользователя, изменения смысла передаваемой информации и ряд других функций.

Ниже, на рисунке 4 представлен пример обобщенной схемы построения сети NGN:

Рис. 4. Построение NGN

1.4 Задачи дипломной работы

Задачами данной дипломной работы являются:

· разработка алгоритма обработки сигнальных сообщений ОКС № 7 в сетях NGN при использовании технологии SIGTRAN.

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

2. Технология SIGTRAN

2.1 Описание технологии

Архитектура SIGTRAN описывает взаимоотношения между функциональными и физическими объектами, которые обмениваются сигнальной информацией, например, шлюзами сигнализации (Signaling Gateways, SG) и контроллерами транспортных шлюзов (Media Gateway Controllers, MGC) и определяет интерфейсы, на которых может использоваться транспортировка информации сигнализации, а также функциональные и качественные требования, которые предъявляются существующими сигнальными протоколами сети с коммутацией каналов (Switched Circuit Network, SCN).

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

Функции транспортировки сигнальной информации должны использоваться для передачи информации сигнализации ТфОП между блоком шлюза сигнализации (Signaling Gateway Unit) и блоком контроллера транспортного шлюза (Media Gateway Controller Unit). Транспортировка сигнальной информации может также использоваться при передаче сообщений сигнализации между блоком транспортного шлюза (Media Gateway Unit) и блоком контроллера транспортного шлюза (Media Gateway Controller Unit), между рассредоточенными блоками контроллеров транспортных шлюзов и между двумя блоками шлюзов сигнализации (Signaling Gateway Unit), соединяющих оконечные точки сигнализации или STP в сети с коммутацией каналов.

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

Общая функциональная модель, которая разделяет функции SG, MGC и MG, может быть реализована различными способами с функциями, реализованными в отдельных устройствах или объединенными в единые физические блоки (рис.4).

Рис. 5. Функциональная модель SIGTRAN

Интерфейсы транспортировки сигнальной информации: SG-MGC, SG SG и возможно MGC-MGC или MG-MGC в зависимости от требований к транспортировке соответствующего протокола.

Некоторые примеры реализации функций физических объектов, применяемых при взаимодействии сетей ОКС7 и IP показаны на рисунке 5.

Рис. 6. Примеры реализации Для взаимодействия с сетями SCN, управляемыми средствами ОКС7, SG служит окончанием звена ОКС7 и передает информацию сигнализации в MGC, используя возможности транспортировки сигнализации. MG завершает межстанционную линию и управляет линией согласно сигналам, которые он получает от MGC. В случае а) SG, MGC и MG могут быть реализованы в отдельных физических блоках, в случае б) MGC и MG — в едином физическом блоке.

В варианте в) привязанное к предоставлению услуги звено ОКС7 оканчивается тем же устройством (MGU), которое завершает и межстанционную линию. В этом случае функция SG является совмещенной с функцией MG и транспортировка сигнальной информации используется для «обратного транзита» («backhaul») сигнализации управления в направлении MGCU.

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

Рис. 7. Вариант с несколькими SG

В этой конфигурации может быть несколько MGU, обрабатывающих привязанную к предоставлению услуги сигнализацию (т.е. несколько MGU, содержащих свои собственные функции SG), и лишь один SGU. Так возможна транспортировка сообщений одного уровня ОКС7 между SG1 и SG2, а другого — между SG2 и MGC. Например, SG1 может передавать сообщения MTP3 в направлении SG2, а SG2 — передавать сообщения ISUP в направлении MGC.

2.2 Архитектура SIGTRAN

Технология SIGTRAN подразумевает под собой наличие следующих трех уровней, согласно RFC 2719 (рис. 3):

1. Internet protocol (IP-протокол).

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

3. Уровень адаптации, обеспечивающий интерфейс с протоколами и приложениями верхнего уровня, так что эти приложения не ощущают, что нижележащая транспортировка осуществляется в IP-среде, а не по традиционным протоколам переноса сообщений МТР стека ОКС7, например.

Протокол SCTP предоставляет возможность использовать его для надежной доставки сигнального трафика других типов, не входящего в стек ОКС7. В область интересов Sigtran включены также адаптационные уровни разных протоколов, что дает возможность пересылать по SCTP сигнальные сообщения не только ОКС7, а например, Q.931 ISDN или V5.2.

Рис. 8. Архитектура SIGTRAN

Использование в качестве транспортного протокола именно SCTP объясняется тем, что UDP и TCP не отвечают строгим требованиям ОКС7 к параметрам потерь сообщений и к соблюдению очередности следования сообщений. Эти требования не позволяют всерьез использовать UDP, поскольку он ненадежен в своей основе. Протокол TCP более близок к требованиям, но и он не подходит по своим временным характеристикам: хотя TCP может гарантировать строгую очередность доставки сообщений, доставка происходит недостаточно быстро. Это связано с тем, что блокировка несвоевременно пришедших данных, предлагаемая протоколом TCP, вносит ненужную задержку.

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

Ограниченная область действия TCP-портов усложняет задачу переноса данных с множественной адресацией — весьма важное обстоятельство. Еще один аспект, говорящий в пользу SCTP, уязвимость TCP к атакам злоумышленников, приводящим к отказу в обслуживании.

Уровни адаптации обеспечивают сопряжение SCTP с протоколами верхнего уровня. Большинство из них ориентировано на ОКС7, в первую очередь, на протокол ISUP, но два относятся к сигнализации других типов. В число работающих поверх SCTP модулей адаптации входят следующие:

M2UA (MTP2-User Adaptation Layer) обеспечивает адаптацию SCTP к МТРЗ таким образом, чтобы стандартный протокол МТРЗ мог использоваться в сети IP, реализуя транспортировку сообщений через SCTP и IP вместо МТР2. Например, реализованное в Softswitch стандартное приложение МТРЗ может обмениваться управляющими сообщениями сетевой сигнализации с внешней сетью ОКС7. Таким же образом, как в сети ОКС7 МТР2 предоставляет свои услуги МТРЗ, M2UA предоставляет свои услуги МТРЗ в сети IP. M2UA имеет зарегистрированный номер порта 2904.

Рис. 9. Структура m2ua

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

Рис. 10. Структура m2pa

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

сигнальный сеть алгоритм телефонный Рис. 11. Структура m3ua

SUA (SCCP-UserAdaptation Layer) — обеспечивает интерфейс между протоколом SCCP стека ОКС7 и SCTP, благодаря чему такие прикладные подсистемы-пользователи SCCP как ТСАР используют услуги SUA точно так, как они используют услуги SCCP в сети ОКС7, даже не подозревая, что все это происходит в IP-сети.

Рис. 12. Структура SUA

IUA (ISDN Q.921-User Adaptation Layer) тоже работает поверх SCTP и обеспечивает для сигнализации DSS1 по рекомендации Q.931 прозрачную транспортировку сообщений по сети IP точно так, как они передаются уровнем звена данных Q.921 в сети ISDN.

Рис. 13. Структура IUA

V5UA (V5-User Adaptation Layer) является уровнем адаптации для протокола V5.2, также работает поверх SCTP.

Рис. 14. Структура v5ua

2.2.1 Общее описание протокола SCTP

В связи с неспособностью UDP и TCP обеспечить необходимые требования ОКС7, за транспортную основу взят протокол передачи с управлением потоками SCTP (Stream Control Transmission Protocol), специфицированный в документе RFC 2960.

Протокол SCTP реализуют следующие принципы:

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

· сегментация данных для адаптации к размеру максимального

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

· отсутствие обязательного мультиплексирования сообщений в

SCTP-дейтаграммы;

· отказоустойчивость на сетевом уровне;

· исключение перегрузок и противодействие лавинам сообщений

и нелегальным проникновениям в систему, вызывающим перегрузки;

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

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

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

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

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

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

Пакет SCTP состоит из общего заголовка и нескольких фрагментов (chunks), как показано на рис.

Рис. 15. Общий заголовок SCTP

Существуют четыре основные категории идентификаторов:

· идентификаторы переноса данных пользователя SCTP;

· идентификаторы переноса управляющей информации SCTР;

· идентификаторы, которые резервированы IETF;

· идентификаторы переноса расширений, определенных IETF.

Ниже приведены типы фрагментов:

Табл.1

2.2.2 Уровень адаптации M3UA

Задачей M3UA является обеспечение предоставления приложениям в сети IР услуг, аналогичных тем, которые МТРЗ предоставляет приложениям вроде ISUP в сети ОКС7. Более подробно это видно из рис. 11 (приведенном выше), где показан Softswitch, которому необходимо запустить приложение типа ISUP. Softswitch в общем случае может сделать это несколькими способами. Например, он может запустить ISUP поверх МТРЗ поверх M2UA (или М2РА) поверх SCTР или же Softswitch может реализовать ISUP поверх M3UA поверх SCTP. Разница между этими двумя способами определяется тем, где реально расположена функция МТРЗ. В сценарии, который показан на рис. 11, обычный протокол МТРЗ присутствует в шлюзах SG, a M3UA просто обеспечивает приложению ISUP в Softswitch удаленный доступ к функции МТРЗ в SG без ощущения приложением ISUP того, что функция МТРЗ не является локальной.

Softswitch в данном случае может иметь код пункта сигнализации, отличный от кода, который имеет SG. В этом случае SG работает подобно STP и воспринимается внешней сетью ОКС7 как STP. Внешняя сеть ОКС7 рассматривает Softswitch как обычный оконечный пункт сигнализации ОКС7, доступ к которому достигается через один или несколько пунктов SG STP.

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

Под сервером приложений AS понимается логический объект, который обрабатывает сигнализацию (например, ISUP) в определенной области (например, для конкретного диапазона ОКС7 DCP/OPC/CIC).

Процесс сервера приложений ASP (Application Server Process] представляет собой экземпляр AS. Сервер AS содержит набор процессов сервера приложений. Фактически, AS можно рассматривать как список процессов ASР часть которых активна, а часть находится в резерве.

Ключ маршрутизации (Routing Key) представляет собой набор таких параметров ОКС7, как SLS, DPC, ОРС или диапазон СIC, которые определяют сигнализацию для некоторого AS. Например, если какой-то AS должен обрабатывать сигнализацию ISUP для определенной комбинации OPC/DPC/диапазон CIC, то эта комбинация и является ключом маршрутизации для такого AS. В пределах SG каждый ключ маршрутизации обычно указывает на один определенный AS. Иначе говоря, между ключами маршрутизации и AS, как правило, существует однозначное соответствие.

Отображение сети (Network Appearance) — это такое ее представление, которое позволяет отделить часть сигнального трафика, нужного для связи между SG и ASР от всего трафика, использующего одно и то же соединение SCTP, например поток с национальным кодом пункта сигнализации от потока с международным.

Каждый ASP необходимо ассоциировать с кодом пункта сигнализации. Однако назначение кодов пунктов для процессов ASP является абсолютно гибким. Например, все ASP, подсоединенные к определенному SG, могут совместно использовать тот же код пункта, что и этот SG. В таком случае комбинация SG и процессов ASP видна сети ОКС7 как единый оконечный пункт сигнализации. Или же все ASP, подсоединенные к одному SG, могут иметь один и тот же код пункта, который отличается от кода пункта сигнализации, присвоенного этому SG. В таком случае SG будет виден сети ОКС7 как STР, а объединенные общим кодом ASP — как единый оконечный пункт сигнализации, расположенный за этим STP.

Еще одним вариантом назначения кодов может быть присвоение каждому ASP своего кода пункта, или группам ASP — разных общих кодов, отличных от кода, присвоенного SG. В этом случае SG виден как STP, а каждый ASP (или группа процессов ASP) — как один оконечный пункт сигнализации. Дело в том, что если некий ASP или некая группа ASP может связываться с сетью ОКС7 не через один, а через два SG, то этот ASP или эта группа ASP должны иметь код пункта, который отличается от кодов этих двух SG. В таком сценарии шлюзы SG работают как транзитные пункты сигнализации STP.

Чтобы предоставлять услуги верхнему уровню прозрачно (так, чтобы приложение не ощущало факт использования функций МТРЗ, встроенных в SG, вместо функций локальной МТР), M3UA должен предоставлять верхнему уровню те же самые примитивы, которые предоставляет МТРЗ. Это следующие примитивы:

· MTP-Transfer request передается из верхнего уровня в M3UA, чтобы запросить перенос сообщения в определенный пункт назначения.

· MTP-Transfer indication используется M3UA, чтобы пропустить

входящее сообщение в верхний уровень.

· MTP-Pause indication передается M3UA в верхний уровень, чтобы указать, что передача сигналов в определенный пункт назначения должна быть приостановлена. Этот примитив используется, например, когда пункт назначения недостижим.

· MTP-Resume indication передается M3UA в верхний уровень,

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

· MTP-Status indication передается M3UA в верхний уровень, чтобы информировать этот уровень о некоторых изменениях, возникших в сети ОКС7, таких как перегрузка или недоступность подсистемы-пользователя в пункте назначения.

2.2.2.1 Сообщения уровня адаптации M3UA

Общий заголовок сообщения:

Рис. 16. Общий заголовок m3ua

1. Поле версии содержит версию уровня адаптации M3UA.

2. Последующие 8 бит зарезервированы для дальнейшего использования.

3. Все сообщения M3UA разделяются по следующим классам:

· 0- MGMT (сообщения управления);

· 1- сообщения переноса информации;

· 10- SSNM (сообщения эксплуатационного управления сетью SS7);

· 11- ASPSM (сообщения эксплуатационного управления состоянием ASP);

· 100- ASPTM (сообщения эксплуатационного управления трафиком ASP);

· 101- резерв для класса сообщений, относящихся к IUA;

· 110- резерв для класса сообщений адаптации пользователя, относящихся к M2UA;

· 111- резерв для класса сообщений без установления соединения, относящихся к SUA;

· 1 000- резерв для класса сообщений, ориентированных на соединение и относящихся к SUA;

· 1 001- RKM (сообщения эксплуатационного управления ключом маршрутизации);

· 1 010- резерв для класса сообщений эксплуатационного управления идентификатором интерфейса M2UA;

· 1 011- резерв для класса сообщений M2PA;

· 1 100- 1 111 111- зарезервированы комитетом IETF;

· 10 000 000- 11 111 111- зарезервированы для определяемых IETF расширений класса сообщений.

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

o Для MGMT:

· 0- ошибка (ERR);

· 1- уведомление (NTFY);

· 10- 1 111 111- зарезервированы комитетом IETF;

· 10 000 000- 11 111 111- зарезервированы для определяемых IETF расширений класса сообщений.

o Для сообщений переноса информации:

· 0- резерв;

· 1- данные (DATA);

· 10- 1 111 111- зарезервированы комитетом IETF;

· 10 000 000- 11 111 111- зарезервировано для IETF для расширений.

o Для SSNM:

· 0- резерв;

· 1- адресат недоступен (DUNA);

· 10- адресат доступен (DAVA);

· 11- проверка состояния пункта назначения (DAUD);

· 100- сообщение перегрузки сети (SCON);

· 101- подсистема-пользователь в пункте назначения недоступна (DUPU);

· 110- доступ к пункту назначения ограничен (DRST);

· 111- 1 111 111- зарезервированы комитетом IETF;

· 10 000 000- 11 111 111- зарезервированы для определяемых IETF расширений класса сообщений.

o Для ASPSM:

· 0- резерв;

· 1- включение ASP (ASPUP);

· 10- выключение ASP (ASPDN);

· 11- сообщение о работоспособности (BEAT);

· 100- подтверждение включения ASP (ASPUP ACK);

· 101- подтверждение выключения ASP (ASPDN ACK);

· 110- подтверждение работоспособности (BEAT ACK);

· 111- 1 111 111- зарезервированы комитетом IETF;

· 10 000 000- 11 111 111- зарезервированы для определяемых IETF расширений класса сообщений.

o Для ASPTM:

· 0- резерв;

· 1- активное состояние ASP (ASPAC);

· 10- неактивное состояние ASP (ASPIA);

· 11- подтверждение активного состояния ASP (ASPAC ACK);

· 100- подтверждение неактивного состояния ASP (ASPIA ACK);

· 101- 1 111 111- зарезервированы комитетом IETF;

· 10 000 000- 11 111 111- зарезервированы для определяемых IETF расширений класса сообщений.

o Для RKM:

· 0- резерв;

· 1- запрос регистрации (REG REQ);

· 10- подтверждение регистрации (REG RSP);

· 11- запрос отмены регистрации (DEREG REQ);

· 100- подтверждение отмены регистрации (DEREG RSP);

· 101- 1 111 111- зарезервированы комитетом IETF;

· 10 000 000- 11 111 111- зарезервированы для определяемых IETF расширений класса сообщений.

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

Ниже приведена сводная таблица всех сообщений M3UA.

Табл.2

Сообщения M3UA помимо общего заголовка могут содержать или не содержать параметры переменной длины. Это определяется типом передаваемого сообщения. Структура приведена ниже

Рис. 17. Параметра переменной длины m3ua

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

1. Идентификатор может принимать значения от 0 до 65 534.

· Значения 0×00- 0х3fявляются общими, т. е. используются всеми уровнями адаптации;

Табл.3

· Значения 0×0200- 0×02ffспецифицированы только для уровня адаптации M3UA.

Табл.4

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

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

Сообщение переноса информации.

DATA:

Данное сообщение предназначено для упаковки сообщений пользователя.

Рис. 18. Сообщение DATA

Контекст маршрутизации определяет адрес получателя данного сообщения, формируется на основании ключа маршрутизации в процессе регистрации нового маршрута (ASP).

Идентификатор корреляции уникально идентифицирует MSU, в которой передаются данные протокола в пределах одного AS.

В поле данные протокола помещается информация оригинального сообщения ОКС7 подсистемы МТР3 в следующем виде.

Рис. 19. Данные протокола в сообщении DATA

Где — SI (индикатор службы), NI (индикатор сети), MP (приоритет сообщения), SLS (поле выбора звена сигнализации), OPC (код исходящего пункта), DPC (код пункта назначения). Незадействованные биты заполняются нулями.

Сообщения эксплуатационного управления сетью SS7 (SSNM).

DUNA:

Сообщение передается из SG во все заинтересованные процессы ASP, чтобы уведомить их о недоступности одного или нескольких пунктов назначения в сети ОКС7. DUNA может являться ответом на сообщение DAUD, описанное ниже. При получении сообщения DUNA трафик перенаправляется по другому маршруту, в случае его отсутствия, передача информации прекращается.

Рис. 20. Сообщение DUNA

Параметр маска задает диапазон кодов пунктов.

Параметр код задействованного пункта указывает коды пунктов ОКС7, которые в данный момент недоступны.

DAVA:

Сообщение о доступности адресата, которое в ASP преобразуется в примитив MTP-Resume indication. Формат данного сообщения аналогичен DUNA.

DAUD:

Служит для проверки состояния пункта назначения. В ответ от проверяемого пункта должно прийти сообщение о доступности (DAVA), недоступности (DUNA) или ограничении доступа (DRST) к адресату. Формат данного сообщения аналогичен DUNA.

Рис. 21. Действия SGP при рестарте mtp (недоступности/доступности абонента).

SCON:

Сообщение передается в случае перегрузки сети ОКС7. Структура данного сообщения представлена ниже.

Рис. 22. Сообщение SCON

Параметр код пункта с перегрузкой присутствует только если сообщение SCON посылается от ASP до SGP и содержит адрес пункт отправителя сообщения SCON, далее этот параметр включается в поле сообщения TFC MTP3.

Параметр индикация перегрузки указывает на текущий уровень перегрузки:

· 0 Неопределенный уровень;

· 1 Уровень Перегрузки 1;

· 2 Уровня Перегрузки 2;

· 3 Уровня Перегрузки 3.

·

Рис. 23. Перегрузка сети ОКС7

DUPU:

Сообщение, оповещающее о том, что подсистема-пользователь в пункте назначения недоступна, которое в ASP отображается в примитив MTP-Status indication.

Рис. 24. Сообщение DUPU

Ниже приведен пример согласования mtp3 — m3ua при недоступности подсистемы-пользователя.

Рис. 25. Недоступность подсистемы-пользователя

DRST:

Сообщение ограничения доступа к пункту назначения. Формат данного сообщения аналогичен DUNA.

Рис. 26. Ограничение доступа к пункту назначения

Сообщения эксплуатационного управления состоянием ASP (ASPSM).

ASP Up:

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

Рис. 27. Сообщение ASP Up

ASP Up Ack:

Сообщение подтверждает принятие ASP Up.

Рис. 28. Сообщение ASP Up Ack

ASP Down:

ASP выключен. Сообщение используется для того, чтобы указать удаленному M3UA, что уровень адаптации не готов принять данные, SSNM, RKM или ASPTM сообщения.

Рис. 29. Сообщение ASP Down

ASP Down Ack: Подтверждение принятия ASP Down.

Рис. 30. Сообщение ASP Down Ack

BEAT: Сообщения о работоспособности ASP. Используется опционально, чтобы гарантировать, что встречные точки M3UA все еще доступный друг другу. Данная функция заложена в SCTP, поэтому ВЕАТ рекомендуется применять при использовании другого транспортного протокола.

Рис. 31. Сообщение BEAT

BEAT Ack:

В подтверждение приема сообщения BEAT посылается идентичное сообщение BEAT Ack.

Сообщения эксплуатационного управления ключом маршрутизации RKM.

REG REQ:

Запрос регистрации. Сообщение посылает ASP в сторону удаленного уровня M3UA для возможности регистрации на нем одного или более новых ключей маршрутизации (новых пунктов сигнализации). После отправки данного сообщения ASP переходит в состояние ожидания подтверждения запроса. Получатель данного запроса должен зарегистрировать новые ключи маршрутизации и присвоить каждому уникальное значение контекста маршрутизации.

Рис. 32. Сообщение REG REQ

Параметр ключ маршрутизации выглядит следующим образом: