Обработка сигнала в NGN
1. Архитектура сетей NGN и
обоснованность их построения
.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-сети, основанные на
распределенной модели, по своей природе являются открытыми системами, готовыми
к развертыванию приложений, разрабатываемых третьими фирмами.
Можно привести следующую статистику:
- экономия на капитальных затратах до 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,
фрагментацию данных по мере необходимости, устойчивость к перегрузкам и т.п.
. Уровень адаптации, обеспечивающий интерфейс с протоколами и
приложениями верхнего уровня, так что эти приложения не ощущают, что
нижележащая транспортировка осуществляется в 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
UA
(V5-User Adaptation Layer) является уровнем адаптации для протокола V5.2,
также работает поверх SCTP.
Рис.
14. Структура v5ua
.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 association) - это протокольная связь между двумя
SCTP-портами, содержащая протокольную информацию о состоянии, включая тэги
верификации и активный в данный момент набор порядковых номеров передачи TSN.
Два SCTP-порта в любой момент времени не должны иметь между собой более одного
SCTP-соединения. Прежде чем приложения двух оконечных пунктов смогут
обмениваться информацией, необходимо установить соединение. Когда коммуникация
закончена, соединение можно прекратить. Протоколы верхнего уровня ISUР, SCCP,
ТСАР и др. не осведомлены о таких соединениях, более того, они не обнаруживают
того факта, что сигнальные сообщения переносятся не стандартной МТР, а чем-то
иным.
В каждом потоке SCTP
производится упорядочение данных. Если фрагмент пакета, принадлежащего
некоторому потоку, потерян, то фрагменты этого пакета, следующие за потерянным,
будут сохраняться в буфере приемника потока, пока потерянный фрагмент не будет
передан источником повторно.
Однако фрагменты пакетов из других потоков могут по-прежнему проходить в
приложение верхнего уровня, иначе говоря каждый поток обрабатывается отдельно,
так что доставка сообщений одного потока не задерживается из-за ожидания
следующего по порядку сообщения другого потока.
Пакет SCTP состоит из общего заголовка и нескольких фрагментов (chunks),
как показано на рис.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
Номер порта источника
|
Номер порта адресата
|
|
Тэг верикации
|
|
Контрольная сумма
(Adler-32)
|
|
ID фрагмента
|
Флаг
|
Длина фрагмента
|
|
Значение фрагмента
|
|
ID фрагмента
|
Флаг
|
Длина фрагмента
|
|
Значение фрагмента
|
|
…
|
|
ID фрагмента
|
Флаг
|
Длина фрагмента
|
|
Значение фрагмента
|
Рис.
15.Общий заголовок SCTP
Существуют
четыре основные категории идентификаторов:
· идентификаторы переноса данных пользователя SCTP;
· идентификаторы переноса управляющей информации SCTР;
· идентификаторы, которые резервированы IETF;
· идентификаторы переноса расширений, определенных IETF.
Ниже приведены типы фрагментов:
Табл.1
|
Имя фрагмента
|
Описание применения
|
|
DATA (0)
|
Фрагменты с данными,
передаваемыми портами терминалов после того, как между ними установлено
SCTP-соединение. Чтобы обеспечить раннюю передачу данных, фрагменты DATA
могут объединяться в группы с управляющими фрагментами COOKIE-ECHO и
COOKIE-ACK, пока управляющие фрагменты идут в сообщении первыми. Сообщения
могут сегментироваться, чтобы не превышался заданный максимальный размер
передаваемого блока информации MTU. Если это имеет место, то флаг фрагмента
указывает начало и конец сегмента исходного сообщения. Фрагменты DATA могут
доставляться в порядке их приема (и тогда они могут быть неупорядоченными),
или же перед доставкой сообщения к протоколу верхнего уровня может
производиться полная сборка исходного сообщения. Тип обслуживания,
запрашиваемый потоком, указывается флагом фрагмента
|
|
INIT(1)
|
Это первый фрагмент,
который инициирует установление SCTP-co-единения между двумя терминалами. Он
переносит такие параметры, как транспортный адрес соединения (может быть
более одного адреса и может быть адрес протокола IPv4, IPv6 или их
сочетание], количество входящих потоков, которое может поддерживать
отправитель, и количество исходящих потоков, которое желает поддерживать
отправитель в данном SCTP-соединении. Здесь же удаленному порту сообщается о
резервировании ресурсов отправителем (размер входного буфера в байтах)
|
|
INITACK(2)
|
Подтверждает прием
фрагмента INIT и содержит переменную состояния cookie. Может также
идентифицировать неопознанные параметры в сообщении INIT и, подобно INIT, задает
количество выходных и входных потоков для SCTP-соединения с портом терминала,
а также транспортные адреса, которые могут использоваться в этом соединении
|
|
SACK (3)
|
Подтверждает получение
фрагментов DATA или информирует о том, что в последовательности принятых
фрагментов DATA имеется разрыв
|
|
HEARTBEAT REQUEST (4)
|
Передается периодически для
подтверждения доступности порта получателя
|
|
HEARTBEAT ACK (5)
|
Подтверждает запрос
HEARTBEAT ACK. Должен передаваться на исходный IP-адрес отправителя фрагмента
HEARTBEAT REQUEST
|
|
ABORT (6)
|
Немедленно закрывает
SCTP-соединение и может содержать параметры, которые указывают причину
|
|
SHUTDOWN (7)
|
Передается, чтобы
инициировать постепенное закрытие SCTP-соединения
|
|
SHUTDOWN ACK (8)
|
Получатель сообщения SHUTDOWN
передает это сообщение как подтверждение
|
|
ERROR (9)
|
Указывает разные
неисправности на порте. Ошибки могут быть внутренними или ошибками протокола,
такими как некорректные параметры при управлении фрагментами DATA
|
|
COOKIE ECHO (10)
|
Используется только в фазе
установления SCTP-соединения и завершает процесс установления соединения у
отправителя данных. Может объединяться в группу с фрагментом DATA, но должен
быть первым фрагментом в такой связке
|
|
COOKIE-ACK(11)
|
Подтверждает получение
COOKIE-ECHO в фазе установления SCTP-соединения. Может объединяться в группу
с фрагментом DATA, но должен быть первым фрагментом в такой связке
|
|
ECNE(12) и CWR (13)
|
Уведомление о явной
перегрузке и уменьшенное окно перегрузки, резервированы для будущего
использования
|
|
SHUTDOWN COMPLETE (14)
|
Подтверждает получение
SHUTDOWN ACK
|
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 того, что функция МТРЗ не
является локальной.в данном случае может иметь код пункта сигнализации,
отличный от кода, который имеет 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.1 Сообщения уровня адаптации M3UA
Общий заголовок сообщения:
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
версия
|
резерв
|
класс
|
тип
|
|
длина сообщения
|
|
тело сообщения
|
Рис.
16. Общий
заголовок m3ua
1. Поле версии содержит версию уровня адаптации M3UA.
2. Последующие 8 бит зарезервированы для дальнейшего использования.
. Все сообщения M3UA разделяются по следующим классам:
· 00000000- MGMT (сообщения
управления);
· 00000001- сообщения переноса информации;
· 00000010- SSNM
(сообщения эксплуатационного управления сетью SS7);
· 00000011- ASPSM
(сообщения эксплуатационного управления состоянием ASP);
· 00000100- ASPTM
(сообщения эксплуатационного управления трафиком ASP);
· 00000101- резерв для класса сообщений, относящихся к IUA;
· 00000110- резерв для класса сообщений адаптации пользователя,
относящихся к M2UA;
· 00000111- резерв для класса сообщений без установления соединения,
относящихся к SUA;
· 00001000- резерв для класса сообщений, ориентированных на
соединение и относящихся к SUA;
· 00001001- RKM
(сообщения эксплуатационного управления ключом маршрутизации);
· 00001010- резерв для класса сообщений эксплуатационного управления
идентификатором интерфейса M2UA;
· 00001011- резерв для класса сообщений M2PA;
· 00001100- 01111111-
зарезервированы
комитетом
IETF;
· 10000000- 11111111- зарезервированы для определяемых IETF расширений класса сообщений.
4. Каждый класс сообщений подразумевает под собой следующие типы:
o Для MGMT:
· 00000000- ошибка (ERR);
· 00000001- уведомление (NTFY);
· 00000010- 01111111- зарезервированы комитетом IETF;
· 10000000- 11111111- зарезервированы для определяемых IETF расширений класса сообщений.
o Для сообщений переноса информации:
· 00000000- резерв;
· 00000001- данные (DATA);
· 00000010- 01111111- зарезервированы комитетом IETF;
· 10000000- 11111111- зарезервировано для IETF для расширений.
o Для SSNM:
· 00000000- резерв;
· 00000001- адресат недоступен (DUNA);
· 00000010- адресат доступен (DAVA);
· 00000011- проверка состояния пункта назначения (DAUD);
· 00000100- сообщение перегрузки сети (SCON);
· 00000101- подсистема-пользователь в пункте назначения
недоступна (DUPU);
· 00000110- доступ к пункту назначения ограничен (DRST);
· 00000111- 01111111- зарезервированы комитетом IETF;
· 10000000- 11111111- зарезервированы для определяемых IETF расширений класса сообщений.
o Для ASPSM:
· 00000000- резерв;
· 00000001- включение ASP (ASPUP);
· 00000010- выключение ASP (ASPDN);
· 00000011- сообщение о работоспособности (BEAT);
· 00000100- подтверждение включения ASP (ASPUP ACK);
· 00000101- подтверждение выключения ASP (ASPDN ACK);
· 00000110- подтверждение работоспособности (BEAT ACK);
· 00000111- 01111111- зарезервированы комитетом IETF;
· 10000000- 11111111- зарезервированы для определяемых IETF
расширений класса сообщений.
o Для ASPTM:
· 00000000- резерв;
· 00000001- активное состояние ASP (ASPAC);
· 00000010- неактивное состояние ASP (ASPIA);
· 00000011- подтверждение активного состояния ASP (ASPAC ACK);
· 00000100- подтверждение неактивного состояния ASP (ASPIA
ACK);
· 00000101- 01111111-
зарезервированы комитетом IETF;
· 10000000- 11111111- зарезервированы для определяемых IETF
расширений класса сообщений.
o Для RKM:
· 00000000- резерв;
· 00000001- запрос регистрации (REG REQ);
· 00000010- подтверждение регистрации (REG RSP);
· 00000011- запрос отмены регистрации (DEREG REQ);
· 00000100- подтверждение отмены регистрации (DEREG RSP);
· 00000101- 01111111- зарезервированы комитетом IETF;
· 10000000- 11111111- зарезервированы для определяемых IETF
расширений класса сообщений.
5. Поле длина сообщения определяет длину сообщения в октетах, включая
общий заголовок и дополнительные параметры.
Ниже приведена сводная таблица всех сообщений M3UA.
Табл.2
|
Имя сообщения
|
Класс сообщения
|
Код класса сообщения
|
Код типа сообщения
|
|
Error (ERR)
|
MGMT
|
00000000
|
00000000
|
|
Notify (NTFY)
|
MGMT
|
00000000
|
00000001
|
|
Data
|
Transfer
|
00000001
|
00000001
|
|
Destination Unavailable
(DUNA)
|
00000010
|
00000001
|
|
Destination Available
(DAVA)
|
SSNM
|
00000010
|
00000010
|
|
Destination State Audit
(DAUA)
|
SSNM
|
00000010
|
00000011
|
|
SS7 Network
Congestion State {SCON)
|
SSNM
|
00000010
|
00000100
|
|
Destination User
Part Unavailable (DUPU)
|
SSNM
|
00000010
|
00000101
|
|
Destination Restricted
(DRST)
|
SSNM
|
00000010
|
00000110
|
|
ASPUp(ASPUP)
|
ASPSM
|
00000011
|
00000001
|
|
ASP Down (ASPDN)
|
ASPSM
|
00000011
|
00000010
|
|
Heartbeat (BEAT)
|
ASPSM
|
00000011
|
00000011
|
|
ASP Up
Acknowledgment (ASPUP ACK)
|
ASPSM
|
00000011
|
00000100
|
|
ASP Down
Acknowledgment (ASPDN ACK)
|
ASPSM
|
00000011
|
00000101
|
|
Heartbeat Acknowledgment
(BEAT ACK)
|
ASPSM
|
00000011
|
00000110
|
|
ASP Active (ASPAC)
|
ASPTM
|
00000100
|
00000001
|
|
ASP Inactive (ASPIA)
|
ASPTM
|
00000100
|
00000010
|
|
ASP Active
Acknowledgment (ASPAC ACK)
|
ASPTM
|
00000100
|
00000001
|
|
ASP Inactive
Acknowledgment (ASPIA ACK)
|
ASPTM
|
00000100
|
00000010
|
|
Registration Request (REG
REQ)
|
RKM
|
00001001
|
00000001
|
|
Registration Response (REG
RSP)
|
RKM
|
00001001
|
00000010
|
|
Deregistration Request
(DEREG REQ)
|
RKM
|
00001001
|
00000011
|
|
De registration
Response (DEREG RSP)
|
RKM
|
00001001
|
00000100
|
Сообщения M3UA помимо общего заголовка могут
содержать или не содержать параметры переменной длины. Это определяется типом
передаваемого сообщения. Структура приведена ниже
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор
|
длина
|
|
значение параметра
|
Рис.
17. Параметра переменной длины m3ua
Параметры в сообщении могут следовать в любом порядке, кроме случая,
когда получатель строго задал последовательность.
1. Идентификатор может принимать значения от 0 до 65534.
· Значения 0х00- 0х3f-
являются общими, т.е. используются всеми уровнями адаптации;
Табл.3
|
Зарезервировано
|
0x0000
|
|
Не используется в M3UA
|
0x0001
|
|
Не используется в M3UA
|
0x0002
|
|
Не используется в M3UA
|
0x0003
|
|
Информационная Строка
|
0x0004
|
|
Не используется в M3UA
|
0x0005
|
|
Контекст маршрутизации
|
0x0006
|
|
Информация диагностики
|
0x0007
|
|
Не используется в M3UA
|
0x0008
|
|
Данные о работоспособности
|
0x0009
|
|
Не используется в M3UA
|
0x000a
|
|
Режим передачи трафика
|
0x000b
|
|
Код Ошибки
|
0x000c
|
|
Статус
|
0x000d
|
|
Не используется в M3UA
|
0x000e
|
|
Не используется в M3UA
|
0x000f
|
|
Не используется в M3UA
|
0x0010
|
|
Идентификатор ASP
|
0x0011
|
|
Код задействованного пункта
|
0x0012
|
|
Идентификатор корреляции
|
0x0013
|
· Значения 0х0200- 0х02ff- специфицированы только для уровня
адаптации M3UA.
Табл.4
|
Отображение сети
|
0x0200
|
|
Зарезервировано
|
0x0201
|
|
Зарезервировано
|
0x0202
|
|
Зарезервировано
|
0x0203
|
|
Пользователь/Причина
|
0x0204
|
|
Индикация перегрузки
|
0x0205
|
|
Код пункта с перегрузкой
|
0x0206
|
|
Ключ маршрутизации
|
0x0207
|
|
Результат регистрации
|
0x0208
|
|
Результат отмены
регистрации
|
0x0209
|
|
Локальный идентификатор
ключа маршрутизации
|
0x020a
|
|
Код пункта назначения (DPC)
|
0x020b
|
|
Индикатор службы
|
0x020c
|
|
Зарезервировано
|
0x020d
|
|
Список кодов пунктов
отправителей
|
0x020e
|
|
Зарезервировано
|
0x020f
|
|
Данные протокола
|
0x0210
|
|
Зарезервировано
|
0x0211
|
|
Статус регистрации
|
0x0212
|
|
Статус отмены регистрации
|
0x0213
|
|
Зарезервировано для IETF
|
0x0214 - 0xffff
|
2. Поле длина сообщения определяет длину сообщения в октетах, включая
общий заголовок и дополнительные параметры.
3. Поле значения параметра содержит фактическую информацию, которая
должна быть передана при помощи данного сообщения.
Сообщение
переноса информации.
DATA:
Данное сообщение предназначено для упаковки сообщений пользователя.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x0200
|
длина = 8
|
|
Отображение сети
|
|
идентификатор = 0x0006
|
длина=8
|
|
Контекст маршрутизации
|
|
идентификатор = 0x0210
|
длина
|
|
Данные протокола
|
|
идентификатор = 0x0013
|
длина = 8
|
|
Идентификатор корреляции
|
Рис.
18. Сообщение DATA
Контекст маршрутизации определяет адрес получателя данного сообщения,
формируется на основании ключа маршрутизации в процессе регистрации нового
маршрута (ASP).
Идентификатор корреляции уникально идентифицирует MSU, в которой
передаются данные протокола в пределах одного AS.
В поле данные протокола помещается информация оригинального сообщения
ОКС7 подсистемы МТР3 в следующем виде.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
OPC
|
|
DPC
|
|
SI
|
NI
|
MP
|
SLS
|
|
Данные протокола верхнего
уровня (например, ISUP)
|
Рис.
19. Данные протокола в сообщении DATA
Где - SI (индикатор службы), NI (индикатор сети), MP (приоритет сообщения), SLS (поле выбора звена сигнализации), OPC (код исходящего пункта), DPC (код пункта назначения).
Незадействованные биты заполняются нулями.
Сообщения
эксплуатационного управления сетью SS7 (SSNM).:
Сообщение передается из SG во все заинтересованные процессы ASP, чтобы
уведомить их о недоступности одного или нескольких пунктов назначения в сети
ОКС7. DUNA может являться ответом на сообщение DAUD, описанное ниже. При получении
сообщения DUNA трафик перенаправляется по другому
маршруту, в случае его отсутствия, передача информации прекращается.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x0200
|
длина = 8
|
|
Отображение сети
|
|
идентификатор = 0x0006
|
длина
|
|
Контекст маршрутизации
|
|
идентификатор = 0x0012
|
длина
|
|
маска
|
код задействованного пункта
№1
|
|
…
|
|
маска
|
код задействованного пункта
№n
|
|
идентификатор = 0x0004
|
длина
|
|
Информационная Строка
|
Рис.
20. Сообщение DUNA
Параметр маска задает диапазон кодов пунктов.
Параметр код задействованного пункта указывает коды пунктов ОКС7, которые
в данный момент недоступны.
DAVA:
Сообщение о доступности адресата, которое в ASP преобразуется в примитив
MTP-Resume indication. Формат данного сообщения аналогичен DUNA.
DAUD:
Служит для проверки состояния пункта назначения. В ответ от проверяемого
пункта должно прийти сообщение о доступности (DAVA), недоступности (DUNA) или ограничении доступа (DRST) к адресату. Формат данного сообщения аналогичен
DUNA.
SCON:
Сообщение передается в случае перегрузки сети ОКС7. Структура данного
сообщения представлена ниже.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x0200
|
длина = 8
|
|
Отображение сети
|
|
идентификатор = 0x0006
|
длина
|
|
Контекст маршрутизации
|
|
идентификатор = 0x0012
|
длина
|
|
Маска
|
код задействованного пункта
№1
|
|
…
|
|
Маска
|
код задействованного пункта
№n
|
|
идентификатор = 0x0206
|
длина = 8
|
|
Резерв
|
код пункта с перегрузкой
|
|
идентификатор = 0x0205
|
длина = 8
|
|
Резерв
|
Индикация перегрузки
|
|
идентификатор = 0x0004
|
длина
|
|
Информационная Строка
|
Рис.
22. Сообщение SCON
Параметр код пункта с перегрузкой присутствует только если сообщение SCON
посылается от ASP до SGP и содержит адрес пункт отправителя сообщения SCON,
далее этот параметр включается в поле сообщения TFC MTP3.
Параметр индикация перегрузки указывает на текущий уровень перегрузки:
· 0 Неопределенный уровень;
· 1 Уровень Перегрузки 1;
· 2 Уровня Перегрузки 2;
· 3 Уровня Перегрузки 3.
·
Рис.
23. Перегрузка сети ОКС7
:
Сообщение, оповещающее о том, что подсистема-пользователь в пункте
назначения недоступна, которое в ASP отображается в примитив MTP-Status
indication.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x0200
|
длина = 8
|
|
Отображение сети
|
|
идентификатор = 0x0006
|
длина
|
|
Контекст маршрутизации
|
|
идентификатор = 0x0012
|
длина
|
|
Маска=0
|
код задействованного пункта
|
|
идентификатор = 0x0204
|
длина = 8
|
|
Причина
|
Пользователь
|
|
идентификатор = 0x0004
|
длина
|
|
Информационная Строка
|
Рис.
24. Сообщение DUPU
Ниже приведен пример согласования mtp3 - m3ua при недоступности
подсистемы-пользователя.
Рис.
25. Недоступность подсистемы-пользователя
:
Сообщение ограничения доступа к пункту назначения. Формат данного
сообщения аналогичен DUNA.
Рис.
26. Ограничение доступа к пункту назначения
Сообщения
эксплуатационного управления состоянием ASP (ASPSM).Up:
ASP включен. Сообщение используется для того, чтобы указать удаленному M3UA, что уровень адаптации готов принять любые ASPSM/ASPTM
сообщения (для всех ключей маршрутизации, сконфигурированных в ASP на обслуживание).
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x0011
|
длина = 8
|
|
Идентификатор ASP
|
|
идентификатор = 0x0004
|
длина
|
|
Информационная Строка
|
Рис.
27. Сообщение ASP Up
ASP
Up Ack:
Сообщение подтверждает принятие ASP Up.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x0011
|
длина = 8
|
|
Идентификатор ASP
|
|
идентификатор = 0x0004
|
длина
|
|
Информационная Строка
|
Рис.
28. Сообщение ASP Up Ack
ASP
Down:
ASP выключен. Сообщение используется для того, чтобы указать удаленному M3UA, что уровень адаптации не готов принять данные, SSNM, RKM
или ASPTM сообщения.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x0004
|
длина
|
|
Информационная Строка
|
Рис.
29. Сообщение ASP Down
Down Ack:
Подтверждение принятия ASP Down.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x0004
|
длина
|
|
Информационная Строка
|
Рис.
30. Сообщение ASP Down Ack
: Сообщения о
работоспособности ASP. Используется опционально, чтобы гарантировать, что
встречные точки M3UA все еще доступный друг другу. Данная функция заложена в SCTP, поэтому ВЕАТ рекомендуется
применять при использовании другого транспортного протокола.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x0009
|
длина
|
|
данные о работоспособности
|
Рис.
31. Сообщение BEAT
Ack:
В подтверждение приема сообщения BEAT посылается идентичное сообщение
BEAT Ack.
Сообщения
эксплуатационного управления ключом маршрутизации RKM.REQ:
Запрос регистрации. Сообщение посылает ASP в сторону удаленного уровня M3UA для возможности регистрации на нем одного или более новых ключей
маршрутизации (новых пунктов сигнализации). После отправки данного сообщения ASP переходит в состояние ожидания
подтверждения запроса. Получатель данного запроса должен зарегистрировать новые
ключи маршрутизации и присвоить каждому уникальное значение контекста
маршрутизации.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x0207
|
длина
|
|
Ключ маршрутизации 1
|
|
идентификатор = 0x0207
|
длина
|
|
Ключ маршрутизации n
|
Рис.
32. Сообщение REG REQ
Параметр
ключ маршрутизации выглядит следующим образом:
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x020a
|
длина = 8
|
|
Локальный идентификатор
ключа маршрутизации
|
|
идентификатор = 0x0006
|
длина = 8
|
|
Контекст маршрутизации
(optional)
|
|
идентификатор = 0x000b
|
длина = 8
|
|
Режим передачи трафика
(optional)
|
|
идентификатор = 0x020b
|
длина = 8
|
|
маска = 0
|
Код пункта назначения
|
|
идентификатор = 0x0200
|
длина = 8
|
|
Отображение сети (optional)
|
|
Индикатор службы (optional)
|
|
Список кодов пунктов
отправителей (optional)
|
|
…
|
|
DPC
|
|
Индикатор службы (optional)
|
|
Список кодов пунктов
отправителей (optional)
|
Рис.
33. Параметр ключ маршрутизации в REG REQ
Параметр локальный идентификатор ключа маршрутизации используется в
данном сообщении для однозначного соответствия запроса и ответа регистрации.
Значение идентификатора должно остаться уникальным до получения REG RSP
(подтверждение регистрации).
Параметр режим передачи трафика идентифицирует режим трафика процесса ASP
в пределах AS, может принимать следующие значения:
· Override
· Loadshare
· Broadcast
Индикатор службы:
Это опциональное поле может содержать один или несколько параметров SI.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x020c
|
длина
|
|
SI #1
|
SI #2
|
SI #3
|
SI #4
|
|
…
|
|
SI #n
|
дополняется нулями до
полного формата (по необходимости)
|
Рис.
34. Параметр SI в REG REQ
Формат
поля список кодов пунктов отправителей:
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x020e
|
длина
|
|
Маска = 0
|
Код исходящего пункта #1
|
|
Маска = 0
|
Код исходящего пункта #2
|
|
…
|
|
Маска = 0
|
Код исходящего пункта #n
|
Рис.
35. Формат поля список кодов пунктов отправителей в REG REQ
RSP:
Подтверждение регистрации.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x0208
|
длина
|
|
результат регистрации 1
|
|
…
|
|
идентификатор = 0x0208
|
длина
|
|
результат регистрации n
|
Рис.
36. Сообщение REG RSP
Формат поля результат регистрации:
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x020a
|
длина = 8
|
|
Локальный идентификатор
ключа маршрутизации
|
|
идентификатор = 0x0212
|
длина = 8
|
|
состояние регистрации
|
|
идентификатор = 0x0006
|
длина = 8
|
|
Контекст маршрутизации
|
Рис.
37. Формат поля результат регистрации
Параметр состояние регистрации может принимать следующие значения:
· 0 - регистрация прошла успешно
· 1 - неизвестная ошибка
· 2 - ошибка DPC
· 3 - ошибка в параметре отображение сети
· 4 - ошибка ключа маршрутизации
· 5 - ошибка - отклонение регистрации
· 6 - ошибка - не поддерживается уникальная маршрутизация
· 7 - ошибка - данный ключ маршрутизации в настоящее время не
предоставляется
· 8 - ошибка - Недостаточное количество ресурсов
· 9 - ошибка - Неподдерживаемый RK параметр в поле
· 10 - ошибка - Неподдерживаемый/Недопустимый режим обработки
информационных потоков
· 11 - ошибка - отказ в изменении ключа маршрутизации
· 12 - ошибка повторной регистрации (ключ маршрутизации уже был
зарегистрирован)
DEREG REQ:
Запрос отмены регистрации.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x0006
|
длина = 8
|
|
Контекст маршрутизации
|
Рис.
38. Сообщение DEREG REQ
RSP:
Подтверждение отмены регистрации.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x0209
|
длина
|
|
Результат отмены
регистрации 1
|
|
идентификатор = 0x0209
|
длина
|
|
Результат отмены
регистрации n
|
Рис.
39. Сообщение DEREG REQ
Формат
поля результат отмены регистрации:
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x0006
|
длина = 8
|
|
Контекст маршрутизации
|
|
идентификатор = 0x0213
|
длина = 8
|
|
Состояние отмены
регистрации
|
Рис.
40. Формат поля результат отмены регистрации
Параметр состояние отмены регистрации может принимать следующие значения:
· 0 - отмена регистрации выполнена успешно
· 1 ошибка - Неизвестное
· 2 ошибка - Недопустимый контекст маршрутизации
· 3 ошибка - Отклонение отмены регистрации
· 4 ошибка - Отменяемый ASP не зарегистрирован.
· 5 ошибка - ASP с указанным контекстом маршрутизации в
настоящее время находится в активном состоянии.
Сообщения
эксплуатационного управления трафиком ASP (ASPTM).
С помощью данной группы сообщений организуется передача трафика между SG
и одним или несколькими ASP (распределение нагрузки).
ASPAC:
Активное состояние ASP.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x000b
|
длина = 8
|
|
Режим передачи трафика
|
|
идентификатор = 0x0006
|
длина
|
|
Контекст маршрутизации
|
|
идентификатор = 0x0004
|
длина
|
|
Информационная Строка
|
Рис.
41. Сообщение ASPAC
ASPAC Ack:
Подтверждение активного состояния ASP.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x000b
|
длина = 8
|
|
Режим передачи трафика
|
|
идентификатор = 0x0006
|
длина
|
|
Контекст маршрутизации
|
|
идентификатор = 0x0004
|
длина
|
|
Информационная Строка
|
Рис.
42. Сообщение ASPAC Ack
ASPIA:
Неактивное состояние ASP.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x0006
|
длина
|
|
Контекст маршрутизации
|
|
идентификатор = 0x0004
|
длина
|
|
Информационная Строка
|
Рис.
43. Сообщение ASPIA
Ack:
Подтверждение неактивного состояния ASP.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x0006
|
длина
|
|
Контекст маршрутизации
|
|
идентификатор = 0x0004
|
длина
|
|
Информационная Строка
|
Рис.
44. Сообщение ASPIA Ack
Сообщения
управления (MGMT).
ERR:
Сообщение об ошибке, связанное со входящим сообщением. Говорит о том, что
принято непредвиденное сообщение или сообщение с неверным содержимым.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x000c
|
длина = 8
|
|
Код ошибки
|
|
идентификатор = 0x0006
|
длина
|
|
Контекст маршрутизации
|
|
идентификатор = 0x0012
|
длина
|
|
Маска
|
код заинтересованного
пункта 1
|
|
…
|
|
Маска
|
код заинтересованного
пункта n
|
|
идентификатор = 0x0200
|
длина = 8
|
|
Отображение сети
|
|
идентификатор = 0x0007
|
длина
|
|
Информация диагностики
|
Рис.
45. Сообщение ERR
Значения параметра код ошибки:
· 0x01 Недопустимая Версия
· 0x02 Не используется в M3UA
· 0x03 Неподдерживаемый класс сообщения
· 0x04 Неподдерживаемый тип сообщения
· 0x05 Неподдерживаемый режим передачи трафика
Поле параметра информация диагностики содержит дополнительную информацию,
соответствующую произошедшей ошибке.
NTFY:
Информация об изменении состояния в ASP.
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
0
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
|
идентификатор = 0x000d
|
длина = 8
|
|
Тип статуса
|
Статус информации
|
|
идентификатор = 0x0011
|
длина = 8
|
|
Идентификатор ASP
|
|
идентификатор = 0x0006
|
длина
|
|
Контекст маршрутизации
|
|
идентификатор = 0x0004
|
длина
|
|
Информационная Строка
|
Рис.
46. Сообщение NTFY
Поле тип статуса может принимать значения:
· 1- изменение состояния AS
· 2- другое
Поле статус информации содержит более детальную информацию уведомления.
При значении типа статуса =1 принимает значения:
· 1- резерв
· 2- AS- неактивен
· 3- AS- активен
· 4- AS- в ожидании.
При значении типа статуса =2 принимает значения:
· 1- недостаточное количество активных ASP в AS
· 2- активны резервные ASP
· 3- авария ASP.
Рис.
47. Установление и разрушение соединения в m3ua
3.
Общее описание ОКС7
Основными подсистемами ОКС7 являются:
o Подсистема переноса сообщений (MTP - Message Transfer Part)
o Подсистемы-пользователи услугами MTP:
· SCCP - подсистема управления соединением сигнализации;
· TUP - подсистема пользователя телефонии;
· ISUP - подсистема пользователя ISDN;
· MUP - подсистема пользователя подвижной связи (NMT);
· HUP - подсистема эстафетной передачи сигналов управления в
процессе разговора (NMT);
· TCAP - подсистема возможностей транзакций;
· MAP - прикладная подсистема пользователя подвижной связи
(GSM);
· INAP - прикладная подсистема интеллектуальной сети;
· OMAP - подсистема технического обслуживания и эксплуатации.
формирует и предоставляет услуги переноса сигнальной информации (в виде
сигнальных сообщений) от пункта-отправителя через сеть ОКС к пункту-адресату.
Пользователи услугами MTP - это подсистемы, которые предоставляют свои
услуги либо подсистемам, расположенным выше (как это делает SCCP), либо (как
это делает ISUP) прямо пользователям системы ОКС7, каковыми являются
разнообразные прикладные процессы (это, в частности, процесс управления
коммутацией, процессы управления предоставлением тех или иных дополнительных
услуг, процессы эксплуатационного управления и др.).
На рис. 48 представлена архитектура протоколов ОКС7.
сигнальный
сеть алгоритм телефонный
Рис.
48. Архитектура протоколов ОКС7
Сеть
связи, использующая ОКС7, состоит из множества узлов коммутации, связанных
между собой цифровыми ИКМ-трактами.
Для
использования услуг ОКС7, каждый из узлов коммутации должен содержать
встроенные средства, позволяющие выполнять функции пункта сигнализации (SP -
Signalling Point). Пункт сигнализации способен формировать, передавать,
принимать и интерпретировать сигнальную информацию.
Каждому
пункту сигнализации присваивается свой уникальный адрес в сети ОКС-7 - код
пункта сигнализации (SPC, signalling point code).
Пункты
сигнализации SP должны быть связаны между собой цифровыми каналами,
выполняющими функции сигнальных звеньев.
Совокупность
пунктов сигнализации и звеньев сигнализации образуют сеть общеканальной
сигнализации - сеть ОКС7.
В
качестве основных понятий следует выделить следующие:
Пункты
сигнализации (SP-signalling point) - узлы сети связи, использующие ОКС-7, которые
могут передавать и/или принимать сигнальный трафик, т.е. генерировать и/или
обрабатывать сигнальные сообщения.
Транзитный
пункт сигнализации (STP-signalling transfer point) - пункт сигнализации,
который передает принятые сигналы на другой SP или STP, не обрабатывая при этом
сигнальные сообщения.
Код
пункта сигнализации (SPC - Signalling Point Code) - это уникальный номер пункта
сигнализации в сети ОКС-7.
Звено
сигнализации (signalling link) - звено сигнализации в системе ОКС-7
используется для передачи сигнальных сообщений между двумя пунктами
сигнализации.
Пучок
звеньев сигнализации (signalling link set) - представляет собой несколько
звеньев сигнализации между двумя соединенными напрямую пунктами сигнализации.
Группа
звеньев сигнализации (group of links) - это группа сигнальных звеньев в пучке,
имеющих идентичные характеристики. Пучок звеньев может включать одну или более
групп звеньев.
В
ОКС7 сигнальная информация организуется в виде пакетов, которые передаются
между пунктами сигнализации в виде сообщений переменной длины, называемых
сигнальными единицами. Существует три типа сигнальных единиц:
· значащая сигнальная единица (MSU) - используется для передачи сигнальной
информации, формируемой подсистемами-пользователями или SCCP; повторяется в
случае ошибки;
· сигнальная единица состояния звена (LSSU) - используется для
контроля состояния звена сигнализации; не повторяется в случае ошибки;
· заполняющая сигнальная единица (FISU) - используется для
обеспечения фазирования звена при отсутствии сигнального трафика; не
повторяется в случае ошибки.
MSU
|
8
|
16
|
8n,n>2
|
8
|
2
|
1
|
7
|
1
|
7
|
8
|
|
F
|
CK
|
SIF
|
SIO
|
|
LI
|
FIB
|
FSN
|
BIB
|
BSN
|
F
|
Рис.
49. Структура MSU
|
8
|
16
|
8или16
|
2
|
6
|
1
|
7
|
1
|
7
|
8
|
|
F
|
CK
|
SF
|
|
LI
|
FIB
|
FSN
|
BIB
|
BSN
|
F
|
Рис.
50. Структура LSSU
|
8
|
16
|
2
|
6
|
1
|
7
|
1
|
7
|
8
|
|
F
|
CK
|
|
LI
|
FIB
|
FSN
|
BIB
|
BSN
|
F
|
Рис.
51. Структура FISU
Флаг
- ограничитель сигнальных единиц - 8-битовая последовательность вида: 01111110.
Обычно закрывающий флаг одной сигнальной единицы является открывающим флагом
следующей сигнальной единицы.
Индикатор
длины указывает на число октетов между полем LI и полем CK. Тип сигнальной
единицы идентифицируется индикатором длины (LI) следующим образом: = 0 (FISU),
заполняющая сигнальная единица;= 1 или 2 (LSSU), сигнальная единица состояния
звена;> 2 (MSU), значащая сигнальная единица.
Индикатор
длины может принимать значения в интервале от 0 до 63.
Прямой
порядковый номер (FSN) - это порядковый номер сигнальной единицы, в составе
которой он передается на противоположный пункт сигнализации.
Обратный
порядковый номер (BSN) - это номер подтверждаемой сигнальной единицы. Прямой и
обратный порядковые номера - это двоичные числа в циклически повторяющейся
последовательности от 0 до 127.
Биты
индикации прямого (FIB) и обратного (BIB) направления вместе с прямым и
обратным порядковыми номерами используются в базовом методе исправления ошибок,
для осуществления контроля последовательности сигнальных единиц и функций
подтверждения.
Проверочные
биты (СК) формируются пунктом сигнализации, передающим сигнальную единицу.
Каждая сигнальная единица содержит 16 проверочных битов для обнаружения ошибок.
Байт
служебной информации (SIO):
|
7
|
6
|
5
|
4
|
3
|
2
|
1
|
0
|
|
поле подвида службы (SSF)
|
индикатор службы (SI)
|
Рис.
52. Структура SIO
o Индикатор службы (SI):
· 0000- управление сетью сигнализации;
· 0001- тест звена сигнализации;
· 0010- резерв;
· 0011- подсистема SCCP;
· 0100- подсистема TUP;
· 0101- подсистема ISUP;
· 0110- подсистема DUP (вызовы/каналы);
· 0111- подсистема DUP (регистрация/дерегистрация);
· остальные - резерв.
o Поле подвида службы (SSF):
· 00хх- международная сеть;
· 01хх- резерв (для международного применения);
· 10хх- национальная сеть;
· 11хх- резерв (для национального применения).
Индикатор службы SI занимает 4 старших бита SIO, содержится только в
значащих сигнальных единицах MSU и указывает, к какой подсистеме пользователя
относится сообщение.
Поле подвида службы SSF занимает 4 младших бита SIO и содержит индикатор
сети NI и два резервных бита. Индикатор сети позволяет отличить, какой сети
принадлежат сообщения: международной национальной.
Поле сигнальной информации (SIF) предназначено для передачи полезной
информации по сети сигнализации и может состоять максимум из 272 байтов,
форматы и коды которых определяются подсистемой пользователей. Поле SIF
содержит информацию, которая должна передаваться между подсистемами
пользователей двух пунктов сигнализации. Поле SIF содержит этикетку, которая
позволяет:
· осуществлять маршрутизацию сообщений при помощи функций уровня 3 MTP по
сети сигнализации к определенному пункту назначения; эта часть этикетки
называется этикеткой маршрутизации.
· ассоциировать сообщение на приемной стороне конкретной
подсистемы пользователя с определенным каналом, вызовом, управлением или
другими транзакциями, к которым относится сообщение.
МТР не распознает содержимое SIF, кроме этикетки маршрутизации, т.е.
прозрачно передает содержащуюся в SIF информацию от уровня 4 одного пункта
сигнализации к уровню 4 другого.
Структура поля SIF в общем случае:
|
8n
|
32
|
|
Информация управления МТР
или сигнальная информация
|
Этикетка маршрутизации
|
Рис.
53. Структура поля SIF
Для
некоторых подсистем пользователя, кроме этикетки маршрутизации, в состав
этикетки входит дополнительная информация, при этом поле SIF будет выглядеть
следующим образом:
Структура
поля SIF для сообщений ISUP (этикетка типа С):
|
8n
|
16
|
8
|
14
|
14
|
|
Сигнальная информация
|
CIC
|
SLS
|
OPC
|
DPC
|
Рис.
54. Этикетка типа С
Структура
поля SIF для сообщений управления MTP (этикетка типа А):
|
8n
|
8
|
14
|
14
|
|
Информация управления МТР
|
SLC
|
OPC
|
DPC
|
Рис.
55. Этикетка типа А
Код
пункта назначения (DPC) указывает пункт назначения сообщения.
Код
исходящего пункта (OPC) определяет исходящий пункт сообщения. Поле выбора звена
сигнализации (SLS) используется, в случае необходимости, для осуществления
разделения нагрузки. Это поле существует во всех типах сообщений и всегда в
одном и том же месте. Единственное исключение из этого правила касается
некоторых сообщений подсистемы передачи сообщений уровня 3 (например, команда
перехода на резерв), для которых функция маршрутизации сообщений в исходящем
пункте сигнализации не зависит от поля SLC: в этом случае поля, как такового,
не существует, оно заменено другой информацией (например, в случае команды
перехода на резерв, идентификация отказавшего звена сигнализации). Код
идентификации канала (CIC) используется в качестве этикетки для сообщений
сигнализации, ориентированных на соединение.
Поле
информации управления МТР выглядит следующим образом
|
8n
|
7
|
6
|
5
|
4
|
3
|
2
|
1
|
0
|
|
Информация
|
Заголовок Н1 (тип
сообщения)
|
Заголовок Н0 (группа
сообщений)
|
Рис.
56. Структура поля информации управления МТР
Поле
состояния (SF) не рассматривается, т.к. оно находится только в сигнальных
единицах состояния звена (LSSU) и интереса в данном случае не представляет.
3.1 Сообщения подсистемы МТР3
Все сообщения МТР3 разделяются по следующим группам (Н0=хххх):
· 0001- сообщения перехода на резерв и обратно (группа CHM);
· 0010- сообщения аварийного перехода на резерв (группа ECM);
· 0011- сообщения управляемой передачи и перегрузки пучка
маршрутов сигнализации (группа FCM);
· 0100- сообщения запрещения и разрешения передачи (группа
TFM);
· 0101- сообщения тестирования пучка маршрутов сигнализации (группа
RSM);
· 0110- сообщения запрещения звена системой управления (группа
MIM);
· 0111- сообщение разрешения восстановления трафика
сигнализации (группа TRM);
· 1000- сообщения соединения звена данных сигнализации (группа
DLM);
· 1010- сообщение управления потоком сигнального трафика от
подсистем пользователя (группа UFC);
Каждая группа сообщений делится на следующие типы (Н1=хххх):
o Для CHM:
· 0001- сообщение перевода трафика на резервное звено (COO - Changeover order);
· 0010- подтверждение перевода трафика на резервное звено (COA - Changeover acknowledgement);
· 0101- сообщение о возврате трафика на исходное звено (CBD - Changeback Declaration);
· 0110- подтверждение возврата трафика на исходное звено (CBA - Changeback Acknowlegement).
o Для ECM:
· 0001- сообщение аварийного перевода трафика на резервное звено (ECO - Emergency Changeover Order);
· 0010- подтверждение аварийного перевода трафика на резервное
звено (ECA - Emergency Changeover
Acknowledgement);
o Для FCM:
· 0001- сообщение тестирования уровня перегрузки пучка сигнальных маршрутов
(RCT -
Signalling-route-set-congestion-test signal);
· 0010- сообщение управления переносом (TFC - Transfer control);
o Для TFM:
0001- сообщение о запрещении переноса (TFP - Transfer prohibited);
· 0011- сообщение ограничения переноса (TFR - Transfer restricted);
· 0101- сообщение о разрешении переноса (TFA - Transfer allowed);
o Для RSM:
· 0001- сообщение тестирования пучка маршрутов для пункта назначения,
перенос сигнальной информации к которому запрещен (RST - Signalling-route-set-test signal for prohibited
destination);
· 0010- сообщение тестирования пучка маршрутов для пункта
назначения, перенос сигнальной информации к которому ограничен (RSR - Signalling-route-set-test signal
for restricted destination);
o Для MIM:
· 0001- запрет доступа к звену (LIN - link inhibit);
· 0010- отмена запрета доступа к звену (LUN - link uninhibit);
· 0011- подтверждение запрета (LIA- link inhibited ack.);
· 0100- подтверждение отмены запрета (LUA - link uninhibited ack.);
· 0101- отклонение запрета (LID - link inhibit denied);
· 0110- принудительная отмена запрета (LFU - link force uninhibit);
· 0111- проверка состояния запрета с ближнего конца (LLT - link local inhibit test);
· 1000- проверка состояния запрета с дальнего конца (LRT - link remote inhibit test).
o Для TRM:
· 0001- сообщение о разрешении перезапуска трафика (TRA - Traffic restart allowed).
o Для DLM:
· 0001- сообщение о подключении звена передачи данных (DLC - Signalling data link connection
order);
· 0010- подключение произведено (CSS -
Connection-successful);
· 0101- подключение не произведено (CNS - Connection-not-successful);
· 0110- подключение невозможно (CNP -
Connection-not-possible).
o Для UFC:
· 0010- сообщение о том, что подсистема-пользователь недоступна (UPU).
3.2 Функции и процедуры MTP3
Функции подсистемы MTP3
Функции сети сигнализации составляют часть любого пункта сигнализации, но
в отличие от функций уровня 2 МТР, выполняемых индивидуально для каждого звена,
функции уровня 3 МТР относятся к сети ОКС7 в целом.
Главной задачей данной группы функций является обеспечение
гарантированной доставки сообщений, поступающих от подсистемы пользователя
исходящего пункта сигнализации к соответствующей подсистеме пользователя в
пункте сигнализации назначения, в условиях возможных отказов элементов сети.
Аналогично сообщениям, поступающим на уровень 3 МТР от подсистем
пользователей, производится перенос по сети сообщений, генерируемых самим
уровнем 3 МТР.
Функции сети сигнализации:
· Обработка сигнальных сообщений
· Управление сетью сигнализации
Обработка сигнальных сообщений подразумевает выполнение функций
маршрутизации, отбора и распределения сообщений в каждом пункте сигнализации.
Управление сигнальной сетью включает управление сигнальным трафиком,
сигнальными маршрутами и звеньями сигнализации. Эти функции нужны для
переконфигурирования сигнальной сети в случае возникновения отказов звеньев или
пунктов сигнализации, а также для управления трафиком при перегрузках или
блокировках.
Обработка сигнальных сообщений:
· Отбор сообщений
Отбор сообщений (принятых от уровня 2 МТР) используется в пункте
сигнализации для определения на основе анализа кода пункта назначения DPC,
предназначено или нет принятое сообщения данному пункту.
· Распределение сообщений
Используется в каждом пункте сигнализации для доставки принятых
сообщений, предназначенных данному пункту, соответствующей подсистеме пользователя
(или уровню 3 MTP).
· Маршрутизация сообщений
Используется в каждом пункте сигнализации для определения на основе
анализа этикетки маршрутизации исходящего сигнального звена, по которому
сообщение должно быть отправлено к соответствующему пункту назначения.
Управление сетью сигнализации:
· Функция управления звеньями сигнализации
· Функция управления сигнальным трафиком
· Функция управления маршрутами сигнализации
Функции управления сетью сигнализации обеспечивают действия и процедуры,
требуемые для поддержания работоспособности системы сигнализации и для
восстановления нормальных условий при отказах в сети, звеньях или пунктах
сигнализации.
Сообщения управления сетью сигнализации передаются по звену сигнализации
в значащих сигнальных единицах.
Звено сигнализации
Может рассматриваться уровнем 3 МТР как доступное или недоступное для
переноса сигнального трафика.
Сигнальный маршрут
Может рассматриваться уровнем 3 МТР как доступный, ограниченно доступный
или недоступный.
Пункт сигнализации
Может быть доступным/недоступным и досягаемым/недосягаемым.
Пучок маршрутов, ведущий к пункту сигнализации может быть в состоянии
перегрузки или отсутствия перегрузки.
Функция управления звеньями сигнализации используется для:
· восстановления отказавших звеньев сигнализации
· для включения в работу недействующих звеньев сигнализации
· для выведения звеньев сигнализации из работы
Функция управления звеньями сигнализации предоставляет средства по
созданию и технической эксплуатации пучков сигнальных звеньев.
Автоматическое назначение звеньев данных сигнализации, т.е. выполнение
процедур включения и восстановления сигнальных звеньев осуществляется при
помощи команды на соединение звена данных сигнализации DLC.
Формат данного сообщения:
Н0=1000; Н1=0001
|
4
|
12
|
4
|
4
|
32
|
|
Идентификатор звена данных
сигнализации
|
Код заголовка Н1
|
Код заголовка Н0
|
Этикетка
|
Рис.
57. Сообщение DLC
В
ответ на сообщение DLC встречный пункт сигнализации посылает сообщение о
результате попытки проведения соединения звена данных сигнализации, которое
содержит в своем составе один из трех возможных сигналов:
|
4
|
4
|
32
|
|
Код заголовка Н1
|
Код заголовка Н0
|
Этикетка
|
Рис.
58. Структура ответных сообщений на DLC
· сигнал успешного соединения (CSS), Н0=1000; Н1=0010;
· сигнал неуспешного соединения (CNS), Н0=1000; Н1=0011;
· сигнал невозможности соединения (CNP), Н0=1000; Н1=0100.
Функция управления сигнальным трафиком включает в себя следующие
процедуры:
· переход на резерв;
· восстановление исходного состояния;
· вынужденная ремаршрутизация;
· управляемая ремаршрутизация;
· перезапуск МТР;
· запрет от системы управления;
· управление потоком сигнального трафика.
Изменение пути прохождения сигнального трафика в случаях недоступности
или ограниченной доступности звеньев или маршрутов производится посредством
выше перечисленных процедур:
недоступность сигнального звена (отказ, деактивация, блокировка или
запрещение): используется процедура перехода на резерв для перевода сигнального
трафика на одно или несколько альтернативных звеньев.
При этом используется связка сообщений команды перехода на резерв СОО
(Н0=0001; Н1=0001) и подтверждения перехода на резерв СОА (Н0=0001; Н1=0010).
Ниже представлен формат данных сообщений:
|
1
|
7
|
4
|
4
|
32
|
|
FSN последней принятой MSU
|
Код заголовка Н1
|
Код заголовка Н0
|
Этикетка
|
Рис.
59. Сообщения COO, COA
Также
в случае, когда невозможно будет определить прямой порядковый номер (FSN)
последней сигнальной единицы (MSU), принятой по недоступному звену применяется
процедура аварийного перехода на резерв с использованием сообщений ECO
(Н0=0010; Н1=0001) и ECA (Н0=0010; Н1=0010).
|
4
|
4
|
32
|
|
Код заголовка Н1
|
Код заголовка Н0
|
Этикетка
|
Рис.
60. Сообщения ECO, ECA
Доступность сигнального звена
(восстановление, активация, разблокировка или разрешение): используется
процедура возврата на исходное звено для перевода сигнального трафика обратно
на звено, ставшее вновь доступным. Для данной процедуры существуют сообщения восстановления
исходного состояния CBD (Н0=0001; Н1=0101) и подтверждения восстановления работы
CBA (Н0=0001; Н1=0110). Формат аналогичен ECO.
Недоступность сигнального
маршрута: применяется процедура вынужденной ремаршрутизации для перевода
сигнального трафика на резервный маршрут. Процедура инициируется в SP в
момент приема сообщения о запрещении передачи TFP (Н0=0100; Н1=0001), со
стороны смежного STP, посредством которого STP указывает на невозможность
доставки сообщения к пункту назначения, то есть на недоступность сигнального
маршрута.
|
2
|
14
|
4
|
4
|
32
|
|
Адрес пункта назначения, к
которому относится сообщение
|
Код заголовка Н1
|
Код заголовка Н0
|
Этикетка
|
Рис.
61. Сообщение TFP
Доступность сигнального маршрута:
применяется процедура управляемой ремаршрутизации для перевода сигнального
трафика на маршрут, ставший вновь доступным. Процедура инициируется в SP в
момент приема сообщения о разрешении передачи TFA (Н0=0100; Н1=0101) со стороны
смежного STP, посредством которого он указывает на восстановление
возможности доставки сообщений к SP назначения, то есть на доступность сигнального
маршрута. Формат аналогичен TFP.
Ограниченная доступность
сигнального маршрута: используется процедура управляемой ремаршрутизации для
перевода сигнального трафика на маршрут, бывший недоступным и ставший
ораниченно доступным.
Доступность пункта сигнализации:
используется процедура перезапуска МТР для перевода сигнального трафика в
направлении пункта сигнализации, ставшего доступным, для обновления в нем
динамических маршрутных данных. Процедура использует сообщение о разрешении
перезапуска трафика TRA. Каждый смежный SP после
завершения передачи всех необходимых сообщений о запрещении передачи в сторону SP,
производящего перезапуск MTP, посылает сообщение TRA (Н0=0111; Н1=0001),
которое указывает, что вся информация о недоступных направлениях передана. По
количеству принятых сообщений TRA система управления перезапускающегося SP
оценивает степень завершенности процесса обновления данных маршрутизации.
|
4
|
4
|
32
|
|
Код заголовка Н1
|
Код заголовка Н0
|
Этикетка
|
Рис.
62. Сообщение TRA
Процедура запрета сигнального звена системой
управления
Цель
процедуры запрета звена сигнализации со стороны системы эксплуатационного
управления - ограничить сигнальный трафик от подсистем пользователей
посредством объявления сигнального звена недоступным именно для этого вида
трафика. Процедура может применяться для решения задач технической эксплуатации
звеньев или для проведения тестирования звена. В результате действий процедуры
не происходит изменения состояния звена сигнализации на уровне МТР2, а звено
лишь помечается как “запрещенное” системой управления, что позволяет передавать
по нему специальные сообщения тестирования. Данная процедура осуществляется при
помощи сообщений группы MIM. Формат аналогичен TRA.
Процедура
управления потоком сигнального трафика
Цель
процедуры управления потоком сигнального трафика - ограничение трафика на
стороне его источника, когда сеть сигнализации не способна передать весь объем
трафика, поступающего от подсистемы пользователя из-за отказов элементов сети
или их временной перегрузки.
Операции
управления потоком могут применяться при следующих событиях:
.
Отказы в сети сигнализации (в звеньях или пунктах), повлекшие недоступность
пучка маршрутов сигнализации.
.
Перегрузка звена или пункта привела к ситуации, при которой осуществление
реконфигурации не целесообразно.
.
Подсистема пользователя из-за отказа не способна обрабатывать сообщения,
доставляемые подсистемой MTP.
При
недоступности подсистемы пользователя применяется сообщение UPU
(Н0=1010; Н1=0001):
|
4
|
4
|
2
|
14
|
4
|
4
|
32
|
|
Причина недоступности
|
Идентификатор подсистемы
пользователя
|
00
|
Адрес пункта назначения, к
которому относится сообщение
|
Код заголовка Н1
|
Код заголовка Н0
|
Этикетка
|
Рис.
63. Сообщение UPU
Функция
управления сигнальными маршрутами.
Данная
функция используется для обмена информацией между SP о доступности сигнальных
маршрутов и включает в себя следующие процедуры:
· процедура управляемой передачи;
· процедура запрещения передачи;
· процедура разрешения передачи;
· процедура ограничения передачи;
· процедура испытания пучка маршрутов;
· процедура проверки перегрузки пучка сигнальных маршрутов.
Цель функции управления маршрутами - отклонение сигнального трафика от
проблемного маршрута. Цель достигается посылкой сообщений управления передачей,
идентифицирующих проблемное направление указанием кода SP назначения.
Восстановление информации о состоянии маршрута производится процедурой
испытания пучка маршрутов, а информации о перегрузке пучка маршрутов - в рамках
процедуры проверки состояния перегрузки пучка.
Процедура управляемой передачи.
На международной сети процедура управляемой передачи используется с одной
целью: с помощью сообщения управления передачей (TFC) доставить индикацию о
перегрузке от SP, где обнаружена перегрузка, к исходящему SP.
В национальных сетях, применяющих назначение приоритетов в случае
перегрузки, ограничивается прием сообщений с приоритетом равным или ниже
заданного.
В национальной сети, где не используется назначение приоритетов,
процедура управляемой передачи служит для доставки с помощью сообщения TFC
индикации о перегрузке от SP, где обнаружена перегрузка, к исходящему SP.
В национальных сетях, использующих несколько статусов перегрузки (до 4) и
не применяющих назначение приоритетов, резервные биты, содержащиеся в сообщении
TFC, используются для обозначения текущего уровня перегрузки звена.
Формат сообщения TFC (Н0=0011; Н1=0010) представлен ниже
|
2
|
14
|
4
|
4
|
32
|
|
Адрес пункта назначения, к
которому относится сообщение
|
Код заголовка Н1
|
Код заголовка Н0
|
Этикетка
|
Рис.
64. Сообщение TFC
Процедура
запрещения передачи.
Выполняется
в STP, когда этот пункт должен известить один или несколько смежных SP о том,
что через него сигнальные сообщения больше передаваться не должны.
Процедура
разрешения передачи.
Процедура
осуществляется в STP, когда этот STP должен сообщить одному или нескольким
смежным SP о возможности передавать через него сообщения, адресованные
определенным SP назначения, при этом используется сообщение TFA. Действия
смежного SP аналогичны, как при запрещении передачи.
Процедура
ограничения передачи.
Процедура
выполняется в STP для сообщений, предназначенных определенному SP, когда этот
STP должен указать смежным SP о прекращении, по-возможности, маршрутизации
сообщений через этот STP. Применение процедуры помогает избежать дальнейшей
перегрузки уже перегруженного участка сети.
Процедура
применяется только в национальных сетях, при этом используется сообщение
ограничения передачи (TFR) (Н0=0011; Н1=0100). Формат данного сообщения
аналогичен TFC.
Процедура
испытания пучка маршрутов.
Процедура
испытания пучка маршрутов сигнализации позволяет SP определить, возможность
передачи сигнального трафика к определенному SP через смежный STP.
Процедура
использует группу сообщений тестирования пучка маршрутов сигнализации (RSM) и
процедуры разрешения и запрещения передачи. Процедура применяется для
восстановления информации о досягаемости направлений, которая потенциально
могла быть утеряна вследствие отказов в сети сигналзации.
Сообщения
тестирования пучка маршрутов для ограниченного назначения (RSR) (Н0=0101;
Н1=0010), или запрещенного назначения (RST) (Н0=0101; Н1=0001) передаются
исходящим SP после приема сообщений TFR или TFP, соответственно, относительно
SP назначения со стороны смежного STP.
Сообщения
RSR и RST посылаются с периодичностью Т10 (30-60 c) до приема сообщения TFA,
указывающего на вновь возникшую досягаемость пункта назначения.
По
приему сообщения TFP, означающего недоступность тестируемого маршрута, смежный
SP начинает процедуру вынужденной ремаршрутизации, и при необходимости сам
формирует сообщения TFP к другим SP.
По
приему от STP сообщения TFA, означающего доступность тестируемого маршрута,
смежный SP выполняет процедуру управляемой ремаршрутизации, и при необходимости
сам посылает сообщения TFA другим смежным пунктам сигнализации.
Формат
сообщений RSR, RST:
|
2
|
14
|
4
|
4
|
32
|
|
Адрес SP
назначения, к которому относится сообщение
|
Код заголовка Н1
|
Код заголовка Н0
|
Этикетка
|
Рис.
65. Сообщения RSR, RST
Процедура
проверки перегрузки пучка сигнальных маршрутов.
Процедура
проверки перегрузки пучка сигнальных маршрутов используется в исходящем SP для
коррекции уровня перегрузки, связанного с маршрутом к определенному SP
назначения. Процедура предназначена для определения возможности передачи к
этому SP сообщения с заданным или более высоким уровнем приоритета перегрузки.
В
случае перезапуска МТР уровень перегрузки всех пучков сигнальных маршрутов в SP
инициализируется нулевым значением. Для проверки текущего состояния пучков
процедура использует сообщение проверки уровня перегрузки пучка сигнальных
маршрутов (RCT) (Н0=0011; Н1=0001).
|
4
|
4
|
32
|
|
Код заголовка Н1
|
Код заголовка Н0
|
Этикетка
|
Рис.
66. Сообщение RCT
Исходя
из выше перечисленных возможностей m3ua и mtp3
можно подвести итог: m3ua - это только адаптационный уровень между протоколами
верхнего уровня и SCTP, он не является полной копией МТРЗ в IP-сети и не
реализует некоторые стандартные управляющие сообщения сетевой сигнализации
mtpЗ.
3.3 Расчет
пропускной способности канала для базового вызова
Расчет объема трафика в ЧНН:
Расчет будет производиться для сравнения объема информации, требуемого
для осуществления базового вызова при использовании протокола Sigtran (m3ua) и SIP.
Рис.
67. Алгоритм обмена сообщениями sigtran - SIP
Исходные
данные для расчета:
= 480
(количество абонентов);
= 3
выз/аб. (количество вызовов от одного абонента в час);
Рассчитываем
количество вызовов в ЧНН:
выз.
o Для Sigtran (m3ua):
Для осуществления базового вызова при использовании sigtran (m3ua)
требуется обмен 5 сообщениями (IAM,ACM,ANM,REL,RLC). При этом данные
упаковываются в пакеты следующих протоколов: Ethernet, IP, SCTP, m3ua. Каждый из этих протоколов имеет свои заголовки.
Размеры заголовков:
Заголовок
Ethernet: 
Байт;
Заголовок
IP: 
Байт;
Заголовок
SCTP: 
Байт;
Заголовок
m3ua: 
Байт.
Общий
размер заголовков:
Байт.
Размер
сообщений:
Приведенные
ниже цифры являются усредненными, т.к. размер сообщений может варьироваться за
счет необязательных параметров.
Сообщение
IAM (m3ua): 
Байт;
Сообщение
ACM (m3ua): 
Байт;
Сообщение
ANM (m3ua): 
Байт;
Сообщение
REL (m3ua): 
Байт;
Сообщение
RLC (m3ua): 
Байта.
Общий
размер сообщения с учетом заголовков:
IAM (m3ua): 
Байта;
ACM (m3ua): 
Байта;
ANM (m3ua): 
Байт;
REL (m3ua): 
Байта;
RLC (m3ua): 
Байт.
В
итоге на один базовый вызов приходится:
Байт
При
этом объем информации из расчета ЧНН:
Байт.
o Для SIP:
Для осуществления базового вызова при использовании протокола SIP требуется обмен 7 сообщениями (INVITE,100,180,200,ACK,BYE,200).
При этом данные упаковываются в пакеты следующих протоколов: Ethernet, IP, UDP. Каждый из
этих протоколов имеет свои заголовки.
Размеры заголовков:
Заголовок
Ethernet: Байт;
Заголовок
IP: Байт;
Заголовок
UDP: 
Байт;
Общий
размер заголовков:
Байта.
Размер
сообщений:
Приведенные
ниже цифры являются усредненными, т.к. размер сообщений может варьироваться за
счет необязательных параметров.
Сообщение
INVITE: 
Байт;
Сообщение
100: 
Байт;
Сообщение
180: 
Байт;
Сообщение
200: 
Байт;
Сообщение
ACK: 
Байт.
Сообщение
BYE: 
Байт.
Общий
размер сообщения с учетом заголовков:
INVITE: 
Байта;
:
Байта;
:
Байт;
:
Байт;
ACK: 
Байт.
BYE: 
Байт.
В
итоге на один базовый вызов приходится:
Байт
При
этом объем информации из расчета ЧНН:
Байта.
Сравнительный
анализ:
Табл.5
|
Объем информации в ЧНН (sigtran(m3ua))
|
Объем информации в ЧНН (SIP)
|
|
928800 Байт
|
5855040 Байт
|
При использовании базового протокола ISUP ОКС7 и технологии Sigtran(m3ua) для использования его в IP-сетях, экономия пропускной
способности в 6 раз.
Подход к точному расчету объема трафика в канале при использовании m3ua предполагает под собой следующие факторы, влияющие на итог
вычислений:
· статистическую оценку общего количества передаваемых сообщений в ЧНН,
включая не только объем информации, требуемый под процедуры установления и
разрушения соединения, но и трафик управления, в случаях перегрузки сети,
недоступности пунктов сигнализации и т.д.
· расчет в соответствии с объемом информации, создаваемым
другими протоколами IP-сети.
· расчет с учетом речевого трафика.
Рис.
68. SDL-диаграмма сравнительного анализа Sigtran(m3ua) -
SIP
Расчет
пропускной способности канала:
Для
расчета требуемой пропускной способности канала воспользуемся моделью М/М/1. Данная
система подразумевает под собой обслуживание простейшего потока вызовов
однолинейным пучком при показательном законе распределения длительности
обслуживания и бесконечном числе мест для ожидания. Т.е. изначально
предполагаем, что закон распределения длительности обслуживания близок к
показательному, что в большинстве случаев отвечает действительности.
T-
среднее время пребывания в системе (
)
μ- среднее время обслуживания (пропускная способность)
λ- интенсивность поступления вызовов на систему
Задаемся
следующими исходными данными:
= 480
(количество абонентов);
= 3
выз/аб. (количество вызовов от одного абонента в час);
Рассчитываем
количество вызовов в ЧНН:
выз.
При
этом на каждый вызов приходится по 5 сообщений:
сообщений/чнн
сообщений/с
Размер
сообщений рассчитываем исходя из среднего » 135 Байт или 1080
бит.(
)
Исходя
из выше рассчитанных данных можно говорить об интенсивности поступления.
бит/с
Что
бы посчитать пропускную способность необходимо задаться временными рамками, в
частности таймером Т1=0,5с
-
коэффициент использования однолинейных систем
Далее
выражая 
, получаем:
,
бит/с
Для
сравнения в SIP получается:
сообщений/чнн
сообщений/с
бит/с
бит/с
Данная
пропускная способность включает в себя только трафик сигнализации, без учета
речевого трафика и информации других протоколов. Поэтому в качестве подхода к
точному расчету пропускной способности канала следует выделить следующие
моменты:
· следует привести доказательство показательного распределения длительности
обслуживания;
· для расчета общей пропускной способности канала следует
учесть речевой трафик и трафик нижележащих и равноуровневых протоколов.
4.
Алгоритм взаимодействия NGN и
ТфОП сетей при использовании Sigtran
Ниже представлены алгоритмы взаимодействия (ОКС7(ISUP) - Sigtran(ISUP)) - SIP.
4.1 Вызов
со стороны SIP
Рис.
69. SDL-диаграмма взаимодействия при поступлении вызова со стороны SIP
4.2 Вызов
со стороны Sigtran(m3ua)ISUP
Рис.
70. SDL-диаграмма взаимодействия при поступлении вызова со стороны сети на базе
ОКС7
4.3 Алгоритмы обмена информацией в m3ua
Рис.
71. SDL-диаграмма включения ASP
Рис.
72. SDL-диаграмма обмена трафиком между ASP и SGP.
Рис.
73. SDL-диаграмма выключения ASP
В данной главе был разработан алгоритм обмена сообщениями уровня
адаптации m3ua. Данные алгоритмы могут быть применены на практике для
написания программного обеспечения при реализации m3ua, к примеру в
сигнальном шлюзе SG или в SoftSwith