8.4. Общеканальная сигнализация № 7
Итак, существует два принципа организации межстанционной сигнализации в коммутируемых сетях связи. Один из них, принцип CAS, основан на том, что для обмена между станциями сигналами, нужными для создания, поддержания и разрушения соединения, в котором участвует определенный межстанционный канал, используется ресурс, закрепляемый именно за этим каналом. Другой принцип основан на том, что для обмена между станциями служебными сигналами используется сигнальный канал, общий для некоторой группы межстанционных соединительных линий. Этот принцип по-английски называется CCS (Common Channel Signaling), а по-русски — общеканальной сигнализацией.
В разные годы MKKTT разработал стандарты для нескольких разных систем межстанционной сигнализации, присвоив каждой из них свой порядковый номер. Системы с номерами от 1 до 5 устроены по принципу CAS, а системы № 6 и №7 — по принципу CCS. В системах МККТТ 1-5 существует разделение сигналов на линейные и регистровые, а для их передачи используются выделенные сигнальные каналы в ИКМ-трактах или частоты из диапазона 300-4000 Гц (разные в разных системах). В системах №№ 6 и 7 такое разделение сигналов, если и существует, то разве лишь по традиции, поскольку все без исключения сигналы передаются одинаково в виде сигнальных сообщений — и воспринимаются одними и теми же устройствами. Обе эти системы реализуются только на станциях с программным управлением, а система сигнализации ОКС7 стала за последнее время универсальной в том смысле, что она применяется в телефонных сетях, в сетях передачи данных, на стыках тех и других сетей с ISDN и в самой ISDN, а также в сетях мобильной связи, в интеллектуальной сети и др.
Функциональная архитектура ОКС7 является многоуровневой, причем функции трех нижних уровней, которые вместе обеспечивают перенос сигнальных сообщений от станции-отправителя до станции-получателя, образуют платформу MTP (Message Transfer Part — подсистема переноса сообщений), необходимую во всех вариантах использования системы, а функции более высоких уровней, в каждом варианте специфические, выполняются соответствующими подсистемами-пользователями этой платформы. В частности, при использовании в ТФОП и в ISDN платформа МТР дополняется «сверху» подсистемой-пользователем ISUP, а также подсистемой управления сигнальными соединениями SCCP, которая предусматривает создание в сети ОКС виртуальных соединений для переноса через эту сеть информации, вообще говоря, не только сигнальной. Разные прикладные подсистемы, встраиваемые в систему ОКС7 (ТСАР, ОМАР, INAP и другие), обеспечивают техническую эксплуатацию сети ОКС, обмен информацией между узлами управления услугами и узлами коммутации услуг в Интеллектуальной сети и т. п. Очень ценное свойство системы № 7 — она является открытой в том смысле, что разрешает, по мере необходимости, вводить в нее новые (в том числе, вновь создаваемые) подсистемы.
Сеть связи, использующая систему ОКС7, состоит из множества узлов коммутации, связанных между собой цифровыми ИКМ-трактами. Чтобы имелась возможность при управлении соединениями пользоваться услугами ОКС7, каждый из этих узлов должен содержать средства, благодаря которым он мог бы выполнять функции пункта сигнализации (SP — Signaling Point), способного формировать, передавать, принимать и интерпретировать сигнальные сообщения. Пункты сигнализации SP должны быть связаны между собой цифровыми каналами, обеспечивающими двухстороннюю передачу сигнальной информации, т.е. выполняющими функции сигнальных звеньев. Совокупность пунктов сигнализации и сигнальных звеньев образует сеть общеканальной сигнализации — сеть ОКС7.
Кроме коммутационных станций и узлов, функции пункта сигнализации SP могут выполнять:
• центры эксплуатационного управления сетью связи (OA&MC- Operation, Administration and Maintenance Centres),
• узлы управления услугами Интеллектуальной сети,
• транзитные пункты сигнализации (STP — Signaling Transfer Points).
Каждому SP присваивается свой уникальный код.
Любые два SP, между которыми возможен обмен сигнальной информацией, являются сигнально связанными. Сигнальная связь двух SP может обеспечиваться либо прямым пучком сигнальных звеньев, либо средствами сети ОКС с организацией транзита. В первом случае пункты сигнализации (с точки зрения структуры сети ОКС) являются смежными, во втором — несмежными.
Наличие в сети ОКС и смежных, и несмежных SP обусловлено тем, что в такой сети возможно, в принципе, использование трех режимов сигнализации: связанного, несвязанного и квазисвязанного. В связанном режиме сигнальная информация, относящаяся к сигнальной связи определенных SP, передается по сигнальному звену, которое соединяет эти SP непосредственно. В несвязанном режиме для передачи аналогичной информации используется последовательно несколько сигнальных звеньев, а к организации сигнальной связи привлекаются пункты сигнализации, выполняющие функции транзитных (STP). Квазисвязанный режим представляет собой частный случай несвязанного режима, а именно случай, когда путь, по которому сигнальная информация проходит через сеть, назначается заранее и является на данный период времени фиксированным. Система ОКСО поддерживает связанный и квазисвязанный режим сигнализации.
Возможны разные варианты структуры сети ОКС. На выбор того или иного варианта могут влиять как структура сети связи, обслуживаемой сетью ОКС, так и другие факторы. Если сеть OKC призвана формировать сигнальные связи, нужные исключительно для управления коммутацией, наиболее подходящей структурой, скорее всего, будет структура, ориентированная преимущественно на поддержку связанного режима сигнализации и лишь в небольшой степени — квазисвязанного режима (для малонагруженных сигнальных связей). Если же сеть ОКС создается как общий ресурс для удовлетворения всех потребностей в ее возможностях, то высокая производительность сигнальных звеньев в сочетании с необходимостью их резервирования для обеспечения высокой надежности приводит к структуре, ориентированной, главным образом, на квазисвязанный режим, и дополненной при этом относительно небольшим количеством прямых (и сильно загруженных) пучков сигнальных звеньев, используемых в связанном режиме сигнализации.
При использовании только связанного режима сигнализации структура сети ОКС совпадает со структурой обслуживаемой ею сети связи. При использовании же только квазисвязанного режима наиболее рациональной оказывается структура сети ОКС, в упрощенном виде показанная на рис. 8.5.
В такой структуре любой пучок сигнальных звеньев поддерживает несколько сигнальных связей (а не одну, как в структуре, которая ориентирована только на связанный режим). Следовательно, в этой структуре пучки сигнальных звеньев более нагружены, т.е. лучше используются. Кроме того, начиная с некоторого количества SP, структура рис. 8.5 обеспечивает уменьшение общего количества сигнальных звеньев в сети ОКС по сравнению со структурой, оптимальной для связанного режима, и сеть ОКС оказывается дешевле.
Можно заметить также, что при такой структуре сеть ОКС более устойчива к локальным перегрузкам, имеет лучшие характеристики надежности и оказывается более живучей» благодаря тому, что для каждой сигнальной связи имеется несколько возможных путей ее организации, т.е. существует несколько разных сигнальных маршрутов. Если, например, в нормальных условиях для обмена сигнальной информацией между SP1 и SP3 используется маршрут SP1-STP1-STP3-SP3, то при перегрузке (или даже при выходе из строя) одного из его элементов (предположим, пучка звеньев SP1-SТР1, или, скажем, транзитного пункта STP1) для той же сигнальной связи может быть использован другой маршрут (SP1-STP4-STP3-SP3 или SP1-STP4-STP2-SP3).
Выше упоминалось о том, что возможности сети ОКС не ограничены лишь функциями сигнализации, связанной с управлением коммутацией. Для поддержки сигнализации этого рода наиболее естественным является связанный режим, что обусловлено спецификой организации коммутируемых связей в сетях коммутации каналов, в частности, в телефонных сетях, где соединение всегда устанавливается последовательными «шагами». Исходящая станция, выбрав направление к станции назначения, обменивается сигнальной информацией с ближайшей (в этом направлении) транзитной станцией, например, с узлом исходящих сообщений (УИС); затем УИС обменивается сигнальной информацией с другой транзитной станцией — узлом входящих сообщений (УВС), а та, в свою очередь, — со станцией назначения. То же самое происходит и при разрушении соединения: на каждом «шаге» разъединения обмен сигнальной информацией происходит только между смежными станциями. Ясно, что при таком алгоритме наиболее естественна такая структура сети ОКС, при которой SP, размещенные в смежных станциях телефонной сети, тоже являются смежными.
Другое дело, если через сеть ОКС станут обмениваться информацией несмежные SP. Поскольку, как мы увидим ниже, функции транзита могут быть предусмотрены в любом SP (а не только в STP), структура сети ОКС, ориентированная на связанный режим сигнализации, обеспечит и такой обмен. Однако по мере роста его доли в общем объеме информации, проходящей через сеть ОКС, эта структура будет становиться все менее и менее экономичной, и все более целесообразной будет структура, предполагающая несвязанный (квазисвязанный) режим.
Назовем примеры ситуаций, когда сеть OKC должна обеспечивать обмен сигнальной информацией между несмежными SP. Одна группа таких примеров связана с введением в цифровую телефонную сеть функций ISDN и с вытекающей из этого необходимостью поддержки ряда дополнительных услуг. Так, в частности, дополнительная услуга CUG (Closed User Group, то есть замкнутая группа пользователей) предполагает, что члены этой группы могут оказаться абонентами разных АТС, причем не обязательно смежных. Процедуры предоставления услуги CUG предусматривают ряд действий (проверку принадлежности одной и той же CUG, прав связи и т.п.), для выполнения которых требуется обмен сигнальной информацией между SP, встроенными в те ATC, абонентами которых являются разные члены группы, в том числе, между несмежными SP. Аналогичное положение имеет место при предоставлении абонентам услуг конференцсвязи. И, наконец, обмен сигнальной информацией между несмежными SP прямо связан с предоставлением такой дополнительной услуги как UUS (User-to-User Signaling, то есть сигнализация пользователь-пользователь).
Другая группа примеров связана с организацией интеллектуальной сети IN. Для предоставления услуг IN необходим обмен сигнальной информацией между узлами коммутации услуг (SSP — Service Switching Points) и узлом управления услугами (SCP — Service Control Point). Поскольку IN устроена так, что один SCP обслуживает большое число SSP, то пункты сигнализации сети ОКС, встроенные в эти элементы IN, во многих случаях могут оказаться несмежными.
Из всего сказанного следует, что в больших сетях структура сети ОКС должна быть ориентирована на то, что в ней, стечением времени, все более широко будет использоваться квазисвязанный режим сигнализации.
Все эти идеи общеканальной сигнализации внедрялись постепенно. В конце 1970-х годов американская AT&T внедрила во всей своей сети систему сигнализации ОКСО. Более совершенная система ОКС7 была специфицирована AT&T в 1980 году, и в том же году она была утверждена МККТТ (теперь — ITU-Т) в качестве международного стандарта. Перечень Рекомендаций МККТТ для ОКС7 приведен в таблице 8.4. Необходимо, однако, отметить, что в разных странах внедряются разные версии ОКС7. Например, США, Канада, Япония и, частично, Китай внедрили у себя версию Американского национального института стандартов ANSI. В Европе реализована версия Европейского института стандартизации электросвязи ETSI. Российские спецификации ОКС7, хотя и следуют стандартам ETSI, имеют свои национальные особенности.
Рекомендации ITU-Т, приведенные в таблице 8.4, специфицируют все аспекты стека протоколов ОКСО (см. рис. 8.6), а также определяют требования к рабочим характеристикам ОКСО и методы их тестирования, для чего используются уже упоминавшиеся в предыдущей главе в связи с интерфейсом V5 протокол-тестеры, внешний вид которых представлен на рис. 8.7.
8.4.1. Подсистема переноса сообщений MTP
Как показано на рис. 8.6, подсистема MTP содержит три функциональных уровня. Два нижних уровня MTP соответствуют уровням 1 и 2 семиуровневой модели взаимодействия открытых систем (OSI). Уровень 3 MTP соответствует уровню 3 модели OSI лишь частично, т.к. не предоставляет услуг, которые предусматривают создание в сети ОКС виртуальных соединений. Он обеспечивает транспортировку сигнальных сообщений подсистем-пользователей услугами MTP через сеть ОКС в дейтаграммном режиме от подсистемы-отправителя, размещенной в одном SP, к подсистеме-получателю, размещенной в другом (не обязательно смежном с первым) SP.
Информация переносится от одного SP к другому в информационных блоках, имеющих переменную длину и называемых сигнальными единицами. Существует три типа сигнальных единиц:
• значащая сигнальная единица (MSU), которая предназначена для переноса сигнальных сообщений, формируемых подсистем амии пользователями МТР,
• сигнальная единица статуса звена (LSSU), предназначенная для переноса информации о статусе сигнального звена, по которому она передается,
• заполняющая сигнальная единица (FISU), обеспечивающая фазирование звена и передаваемая при отсутствии сигнальных единиц MSU и LSSU.
Для идентификации типа сигнальной единицы используется один из ее элементов — индикатор длины LI, разным значениям которого соответствуют:
• LI=O — заполняющая сигнальная единица,
• LI=1 или 2 — сигнальная единица статуса звена,
• LI)2 — значащая сигнальная единица.
Наиболее сложной по своей структуре является значащая сигнальная единица MSU. Ее формат представлен на рис. 8.8. MSU содержит ряд полей, в которых размещается фиксированное количество битов. Уровень 2 MTP обеспечивает присвоение значения каждому биту внутри каждого поля при передаче и анализ этих значений при приеме (исключение составляет поле сигнальной информации, которое имеет переменную длину, и содержание которого определяется функциями более высоких уровней).
Приведем краткие сведения о каждом поле.
Флаг выполняет функцию разделителя сигнальных единиц. Как правило, закрывающий флаг одной сигнальной единицы является открывающим флагом следующей сигнальной единицы. Последовательность значений битов в поле флага следующая: 01111110.
Чтобы избежать имитации флага другой частью сигнальной единицы, MTP, передающая MSU, вставляет ноль после каждой последовательности из пяти следующих друг за другом единиц, содержащихся в любом поле MSU, кроме флага. Этот ноль изымается на приемном конце сигнального звена после обнаружения и отделения флагов.
Биты индикации направления FIB и BIB говорят о содержании MSU в том смысле, несет ли она собственно сигнал (FIB — прямое направление) или выполняет функции подтверждения (BIB — обратное направление). Вместе с полями FSN и BSN (см. ниже) биты индикации направления служат для контроля того, совпадает ли последовательность сигнальных единиц на приеме с последовательностью их на передаче, и используются в одном из двух предусмотренных в системе ОКСО методов исправления ошибок.
Поля порядковых номеров FSN и BSN используются таким образом. FSN передается в прямом направлении (то есть в направлении передачи сигнала) и несет информацию о порядковом номере той MSU, в состав которой оно входит. BSN передается в обратном направлении в составе подтверждающей сигнальной единицы (ею может быть MSU или FISU) и несет информацию о порядковом номере той MSU, к которой это подтверждение относится.
Индикатор длины LI указывает, сколько байтов содержит сигнальная единица в полях, расположенных между резервными битами и проверочной комбинацией СК. Заметим, что формат заполняющей сигнальной единицы в промежутке между LI и СК не содержит никаких полей (О байтов), формат сигнальной единицы статуса звена содержит в этом промежутке только поле статуса (либо 1 байт, либо 2 байта), а формат значащей сигнальной единицы предусматривает, как это видно на рис. 10.2, наличие между LI и СК двух полей — имеющего длину 1 байт поля SIO и имеющего переменную длину поля сигнальной информации SIF. Из сказанного сам собой вытекает способ идентификации типа сигнальной единицы, о котором говорилось выше.
Байт служебной информации SIO содержит два элемента — сервисный индикатор, указывающий, к какой из подсистем пользователей MTP относится содержащаяся в сигнальной единице информация, и индикатор вида сети (международная, междугородная, местная).
Поле сигнальной информации SIF содержит целое число байтов (от 2 до 272). Форматы этого поля определены отдельно для каждой подсистемы-пользователя.
Поле проверочной комбинации СК содержит 16 битов. Значения битов вычисляются путем применения образующего полинома к информации, которая содержится в подготавливаемой к передаче сигнальной единице. Полином имеет вид х16+ х12+ х5+ 1. Он выбран таким образом, чтобы оптимизировать процесс обнаружения пакетов ошибок при передаче.
Проверочные биты образуются из остатка от деления (по модулю 2) величины хk (х15+ х14+ х13+ х12+ .... х2+ х + 1), (где k — число битов в сигнальной единице между последним битом открывающего флага и первым проверочным битом, кроме битов, введенных, чтобы исключить имитацию флага) на образующий полином х16+ х 12+ х5 +1 и остатка от деления на тот же полином умноженного на х16 содержимого сигнальной единицы между последним битом открывающего флага и первым проверочным битом (не считая битов, введенных с целью исключить имитацию флага).
Передаваемые проверочные биты являются дополнением до «1» образовавшего остатка 16-битового поля, то есть «1» меняются на «0» и наоборот. Это изменение производится для того, чтобы минимизировать вероятность ошибки в работе оборудования принимающей стороны.
Принимаемые биты анализируются на предмет соответствия между ними и остальной частью принятой сигнальной единицы. Если соответствия не обнаружено, регистрируется ошибка, а сигнальная единица стирается. Стирание MSU приводит в действие механизм исправления ошибок.
В ОКС7 предусмотрены два метода исправления ошибок.
Основной метод исправления ошибок применяется для сигнальных звеньев со временем распространения сигнала в одном направлении, не превышающем 15 мс. В противном случае используется метод превентивного циклического повторения. Примером использования метода превентивного циклического повторения может служить случай, когда связь организуется по спутниковым каналам. Сообщения, которые были приняты с искажениями (например, из-за пакетов ошибок при передаче), передаются повторно в той же последовательности, в какой они передавались первый раз, так что для функций уровня 3 не возникает никаких проблем с доставкой сообщений подсистемам-пользователям без потерь и дублирования.
Если имеют место постоянные ошибки, уровень 3 уведомляется об этом для того, чтобы он мог принять соответствующее решение, например, решение изменить маршрут с использованием в нем другого сигнального звена.
Основной метод исправления ошибок — это метод с положительным и отрицательным подтверждением и повторной передачей сигнальных единиц, принятых с искажениями.
Метод исправления ошибок посредством превентивного циклического повторения предусматривает положительное подтверждение, циклическое повторение и упреждающее исправление ошибок. При этом отрицательное подтверждение не применяется, а индикацией искажения сообщения служит отсутствие позитивного подтверждения. Исправление ошибок достигается программируемым циклическим повторением неподтвержденных MSU. Каждая сигнальная единица содержит FSN и BSN (как и в основном методе), но FIB и BIB не используются, и им присваивается значение «1».
Функции обработки сигнальных сообщений представлены в уровне 3 MTP тремя функциональными блоками:
• блоком сортировки сообщений, приходящих в информационном поле сигнальных единиц уровня 2, то есть разделения их на сообщения, адресованные в «свой» SP, и на сообщения, адресованные в другой SP,
• блоком распределения сообщений, адресованных в «свой» SP, по подсистемам-пользователям услугами МТР,
• блоком маршрутизации сообщений, адресованных другому SP (как тех, которые пришли от подсистем уровня 4 или от функций эксплуатационного управления сетью ОКС, размещенных в своем SP, так и тех, которые поступили от уровня 2.
Работа всех этих блоков базируется наследующем. Обязательной частью сообщения, которое MTP получает от своего пользователя, является маршрутная этикетка, содержащая два поля с данными об SP-отправителе (OPC — Originating Point Code) и об SP-получателе (DPC — Destination Point Code). Анализируя этикетку сообщения, принятого от уровня 2, блок сортировки определяет, куда его нужно направить — к блоку распределения (если DPC совпадает с кодом «своего» SP) или к блоку маршрутизации (если совпадения нет). Блок распределения, приняв от блока сортировки сообщение с этикеткой, содержащей в поле DPC код «своего» SP, направляет сообщение к подсистеме-адресату. Блок маршрутизации, приняв сообщение от блока сортировки (или от подсистемы-отправителя, размещенной в «своем» SP), использует DPC для выбора маршрута, по которому нужно направить это сообщение к SP-получателю. Третьим элементом маршрутной этикетки является поле селектора сигнального звена (SLS — Signaling Link Selection), которое служит для выбора звена, по которому должно пересылаться данное сообщение. Это звено MTP либо выбирает сама, либо делает выбор, следуя указанию «сверху», т.е. от подсистемы-пользователя.
Функции эксплуатационного управления сетью ОКС тоже представлены в уровне 3 MTP тремя функциональными блоками: блоком управления сигнальным трафиком, блоком управления сигнальными звеньями, блоком управления сигнальными маршрутами, о чем еще будет упомянуто в главе 10.
8.4.2. Подсистема управления сигнальными соединениями SCCP
Подсистема SCCP дополняет уровень 3 MTP функциями, которых тому не достает для того, чтобы соответствовать уровню 3 модели OSI. Подсистемы МТР И SССР образуют т.н. подсистему сетевых услуг NSP (Network Service Part). NSP поддерживает создание между SP как сигнальных связей, нужных для управления соединениями в сети коммутации каналов, которую обслуживает сеть ОКСО, так и связей, не относящихся к таким соединениям — в том числе сигнальных связей между несмежными SP. Важную роль здесь играет наличие в SCCP собственной системы адресации, не привязанной, как в МТР, к номерам телефонных каналов.
SCCP предоставляет своим пользователям как услуги, не предусматривающие создания в сети ОКС виртуального соединения, так и услуги, ориентированные на соединение. Имеется четыре класса услуг SCCP:
0 — базовый класс услуг без соединения; доставка сигнальных сообщений в заданной последовательности не гарантируется.
1 — класс услуг без соединения; доставка сигнальных сообщений в заданной последовательности гарантируется.
2 — базовый класс услуг, ориентированных на соединение, без управления потоком сообщений.
3 — класс услуг, ориентированных на соединение, с управлением
потоком сообщений.
Заметим, что класс 1 сохраняет порядок следования сообщений, используя упомянутый в п.8.4.1 механизм присвоения сверху» значения SLS в маршрутной этикетке. Благодаря этому на каждом участке маршрута от SCCP-отправителя к SCCP-получателю все сообщения SCCP, принадлежащие одному потоку, проходят через одно и то же сигнальное звено, что гарантирует сохранение очередности их следования по всему маршруту.
Сообщение SCCP содержит маршрутную этикетку, код типа сообщения и параметры. Параметры дополняют данные, определяемые кодом типа сообщения. В общем случае параметр состоит из названия, индикатора длины и поля данных. Название кодируется одним байтом и однозначно определяет параметр. Индикатор длины указывает количество байтов в параметре, а поле данных содержит информацию (заметим, что не в каждом параметре имеются все эти поля).
Существуют параметры трех видов — обязательные с фиксированной длиной, обязательные с переменной длиной и необязательные. Обязательные параметры с фиксированной длиной содержатся в сообщениях любого типа. Положение и длина каждого из этих параметров определяются типом сообщения, а поэтому их названия и индикаторы длины в сообщения не включаются. Обязательные параметры переменной длины также содержатся в сообщениях всех типов. Название любого такого параметра тоже определяется типом сообщения. Необязательные параметры могут включаться или не включаться в сообщение того или иного типа. Каждый необязательный параметр содержит название (один байт) и индикатор длины (один байт) перед полем данных, передающим содержание параметра.
Формат сообщения SCCP в общем виде показан на рис.8.9. Всего на сегодня специфицировано 19 сообщений (пять из них - для нужд эксплуатационного управления). Из экономии места сообщения здесь не описываются и перечень их не приводится; сведения об этом можно почерпнуть, например, из [41]. Автор считает более важным обратить внимание читателя на то обстоятельство, что принцип свободного использования в формате сообщения полей необязательных параметров позволяет гибко модифицировать как перечень сообщений СССР, так и содержание любого из них, когда и если в будущем возникнет потребность в такой модификации.
8.4.3. Подсистема средств транзакций
Средства транзакций ТС — Transaction Capabilities — предназначены для поддержки взаимодействия между прикладными процессами (или между разными элементами одного процесса), размещенными в территориально разнесенных узлах сети связи. Любой такой процесс (или элемент процесса) внутри одного узла сети связи является пользователем услугами ТС, размещенных на этом узле. С другой стороны, сами ТС того или иного узла являются пользователем сетевыми услугами, предоставляемыми размещенной на нем подсистемой NSP.
ТС могут поддерживать обмен информацией между:
• коммутационными станциями и/или узлами сети связи,
• станцией (узлом) и базой данных, узлом управления услугами сети IN, центром технической эксплуатации ЦТЭ и т. п.,
• специализированными сетевыми центрами.
Пользователями ТС могут быть разные приложения, в частности:
• приложения услуг мобильной связи,
• приложения услуг Интеллектуальной сети IN,
• приложения эксплуатационного управления.
Все такого рода приложения можно разделить на две категории:
• требующие обмена данными в реальном времени (т.е. без ощутимых задержек); объем данных в этом случае относительно невелик,
• не предъявляющие жестких требований в отношении задержек; при этом объем данных может быть очень большим.
Как видно из рис. 8.10, функции ТС образуют два подуровня — под уровень компонентов (CSL) и подуровень транзакций (TSL). Чтобы стало ясно, в чем тут дело, нужно определить ряд понятий, связанных с тем, как разделены функции между этими подуровнями и какие услуги каждый из них предоставляет подуровню, расположенному выше.
Взаимодействие между пользователями услугами средств транзакции (для краткости назовем их TC-пользователями) может быть представлено в виде обмена командами и ответами, составляющего диалог ТС-пользователя, находящегося в одном пункте сети ОКС и инициирующего взаимодействие, с ТС-пользователем, находящимся в другом пункте этой сети и являющимся партнером инициатора. Инициатор передает запрос выполнения партнером определенной операции, а отклик партнера на этот запрос содержит сведения о результате выполнения (невыполнения) операции. По отношению ко всем этим действиям принято говорить, что они связаны с обращением к одной и той же операции.
Запрос (и отклик) представляет собой блок, называемый компонентом. Компонент, связанный с обращением к определенной операции, снабжается идентификатором (ID обращения), благодаря чему одновременно могут быть активными несколько обращений, причем обращения эти могут относиться как к одной и той же, так и к нескольким разным операциям.
Множество функций, связанных с обработкой компонентов, образует верхний подуровень ТС — подуровень CSL. Через границу между этим подуровнем и ТС-пользователем компоненты проходят индивидуально. Пользователь (инициатор) может передать к подуровню CSL один за другим несколько компонентов до того, как они будут переданы (в одном сообщении) второму ТС-пользователю (партнеру). Несколько компонентов, принятых в одном сообщении, всегда передаются пользователю-адресату по одному и в той последовательности, в какой они были переданы пользователем отправителем.
Последовательность компонентов, которыми обмениваются два ТС-пользователя при выполнении одного приложения, образует диалог. Компоненты содержат параметр, идентифицирующий диалог (так называемый ID диалога); у всех компонентов одного диалог этот ID имеет одно и то же значение.
Диалоги могут быть неструктурированными и структурированными. При неструктурированном диалоге ТС-пользователь передает компоненты, на которые не ожидается откликов, так что связь между двумя TC-пользователями в явном виде не определена. Компоненты передаются в однонаправленных сообщениях, и сам факт передачи однонаправленного сообщения говорит о неструктурированном диалоге. Пользователь может иметь дело сразу с несколькими операциями; максимальное число операций зависит от количества доступных в данное время уникальных значений идентификатора ID обращения. Если при приеме однонаправленного сообщения обнаружена ошибка протокола, для уведомления об этом факте отправителя также используется однонаправленное сообщение.
При структурированном диалоге связь между двумя TC-пользователями определяется в явном виде — TC-пользователь указывает начало, продолжение и окончание этой связи. Два ТС-пользователя могут вести одновременно несколько структурированных диалогов, идентифицируя каждый из них с помощью уникального ID диалога. Поскольку для каждого ID диалога существует свое пространство имен ID обращений, один и тот же ID обращения может повторяться в разных диалогах. Структурированный диалог предполагается двусторонним — на фазе его продолжения возможен дуплексный обмен компонентами.
Подуровень CSL предусматривает организацию соответствия между запросами и откликами. Связанное с запросом операции значение ID обращения вводится в отклик на этот запрос. Возможны 4 класса операций:
• класс 1 — предусматривается отклик и при удаче, и при неудаче,
• класс 2 — предусматривается отклик только в случае неудачи,
• класс 3 — предусматривается отклик только в случае удачи,
• класс 4 — отклик не нужен ни в том, ни в другом случае.
Смысл и содержание каждого компонента определяется его типом. Существуют компоненты следующих пяти типов.
• INVOKE — обращение. Этот компонент запрашивает выполнение встречной стороной определенной операции. Он может быть связан с другой операцией, к которой обращалась встречная сторона.
• RETURN RESULT (NOT LAST) — часть данных с информацией о результате выполнения операции. Имеется в виду, что все данные с информацией о результате не могут быть целиком размещены в одном компоненте, так что ТС-пользователю пришлось разделить их на несколько сегментов. Данный компонент содержит один из этих сегментов, за которым последуют другие.
• RETURN RESULT (LAST) — последняя (или единственная) часть данных с информацией о результате выполнения операции. Этот компонент свидетельствует о том, что операция успешно завершена.
• RETURN ERROR — успешно завершить операцию не удалось. Этот компонент содержит информацию о причине того, что операция не была завершена.
• REJECT — отказ в приеме к обработке компонента, поступившего от встречной стороны. Компонент содержит информацию о причине отказа — либо отсутствие ресурсов, нужных для выполнения операции, либо наличие в поступившем компоненте той или иной ошибки (компонент неизвестного типа, с нестандартной или не соответствующей случаю структурой, с недопустимым или используемым для другой операции идентификатором обращения, с неизвестным кодом операции, и т. п.)
Рассмотрим теперь функции и услуги подуровня транзакций (TSL). Очевидно, что расположенный выше подуровень CSL является пользователем подуровня TSL (или, для краткости, TSL-пользователем); другие TSL-пользователи в настоящее время не определены, однако подуровень TSL устроен так, что они, в принципе, могут существовать.
TSL предусматривает средства, поддерживающие обмен компонентами между TSL-пользователями и обеспечивающие использование услуг нижележащих уровней (подсистем SCCP и MTP) для двустороннего переноса через сеть OKC сообщений между двумя взаимодействующими подсистемами ТС, размещенными в разных пунктах этой сети.
Поддержка неструктурированного диалога TSL-пользователей заключается в том, что TSL обеспечивает передачу сообщения, содержащего один или несколько компонентов (связанных с операциями класса 4), от «своего» TSL-пользователя, являющегося отправителем, к TSL-пользователю, являющемуся адресатом. Если для поддержки такого диалога требуется передать несколько TSL-сообщений, логическая связь между ними (то есть их принадлежность одной и той же транзакции) в явном виде не определяется.
Поддержка структурированного диалога базируется на том, что каждый TSL-пользователь идентифицирует транзакцию уникальным ID транзакции, который присутствует во всех TSL-сообщениях, относящихся к этой транзакции. Для каждой транзакции TSL-пользователь указывает ее начало, продолжение и окончание; на фазе продолжения возможен дуплексный обмен между TSL-пользователями сообщениями «внутри» этой транзакции.
Отметим, что в настоящее время специфицированы средства
транзакций, использующие только такие услуги SCCP, которые не предусматривают создание в сети ОКС сигнальных соединений. Использование услуг, ориентированных на сигнальные соединения, изучается ITU- T.
Подсистема ISUP — это подсистема-пользователь MTP, поддерживающая межстанционную сигнализацию в ТФОП и в ISDN. При поддержке сигнализации в ISDN ISUP пользуется также услугами SCCP, как это показано на рис. 8.6.
Средства адресации МТР дополнены в ISUP идентификатором канала, поскольку для того, чтобы указать, к какому телефонному соединению относится сообщение, ISUP указывает номер того канала, который занят в этом соединении. Дело в том, что ISUP реализует два метода сигнализации — эстафетный, когда сообщение передается от одной станции к другой и на промежуточных станциях может изменяться, и сквозной, когда обмен сообщениями происходит между конечными точками соединения. Сквозной метод обычно использует услуги SССР — либо без создания сигнального соединения, либо ориентированные на соединение; в последнем случае процедуры значительно упрощаются.
Сообщений ISUP слишком много, чтобы рассмотреть их все в этой, и так самой длинной главе учебника. Назовем лишь основные категории сообщений:
• Сообщения управления базовым соединением
• Сообщения управления дополнительными услугами
• Сообщения модификации соединения во время связи
• Сообщения эксплуатационного контроля и управления
• Сквозные сообщения.
Принципы форматирования сообщений в ISUP подобны принципам, принятым в SCCP и описанным в п. 8.4.2 (в этом легко убедиться, сравнив приводимый ниже рис. 8.11 с рис. 8.9). Однако SCCP устроена так, что маршрут, по которому проходит «сквозное» сигнальное сообщение, никак не связан с маршрутом, по которому проходит соединение телефонных каналов, а ISUP опирается на канальный» подход идентификации транзакции.
Теперь рассмотрим пример установления базового соединения в ISDN. В этом примере (рис. 8.12) терминал вызывающего пользователя А передает по каналу 0 в интерфейсе UNI сообщение Q.931 SETUP в сторону своей АТС (исходящей), которая анализирует его, удостоверяется в его правильности и передает начальное адресное сообщение IAM протокола ISUP к той транзитной АТС, через которую, согласно таблице маршрутизации исходящей ATC, должно пройти устанавливаемое соединение. Одновременно исходящая АТС передает вызывающему абоненту сообщение Q.931 CALL PROCEEDING.
Транзитная АТС находит в своей таблице маршрутизации входящую ATC и переправляет ей сообщение IAM. Предположим, что в сообщение IAM не был включен адрес вызываемого пользователя (CPA), а входящей АТС этот CPA необходим для завершения установления соединения. Тогда входящая ATC направляет к транзитной АТС сообщение протокола ISUP «Запрос информации» (INR), содержащее параметр (индикатор запроса), который говорит о том, что требуется CPA. Транзитная АТС переправляет это сообщение к исходящей ATC.
Исходящая АТС формирует сообщение протокола ISUP «Информация» (INF) с недостающим CPA и направляет его к входящей ATC. Входящая АТС передает сообщение Q.931 SETUP к оборудованию вызываемого пользователя Б, которое отвечает на это сообщением Q.931 ALERTING. Входящая ATC передает в обратном направлении сообщение протокола ISUP о приеме всего адреса (ACM). Когда исходящая ATC получает это сообщение, она передает к оборудованию вызывающего пользователя сообщение Q.931 ALERTING.
Когда вызываемый абонент отвечает на вызов, его оборудование передает сообщение Q.931 CONNECT к входящей ATC, которая, в свою очередь, передает на транзитную АТС сообщение протокола ISUP «Ответ» (ANM). Транзитная ATC пересылает сообщение ANM к исходящей АТС, а та передает к оборудованию вызывающего пользователя сообщение Q.931 CONNECT. В результате между вызывающим и вызываемым пользователями устанавливается соединение.
8.5. Сигнализация при переходе к NGN
В последнее время система ОКСО стала универсальным ключом, своего рода Bluetooth сигнализации для более тесного объединения различных сетевых инфраструктур мобильной связи, проводной связи и 1Р составляющих в процессе их конвергенции сеть связи следующего поколения NGN, которая была рассмотрена в главе 5. Именно этим объединяющим свойством ОКСО вызвана ассоциация с прозвищем Голубой зуб» (Bluetooth), которое носил король Дании Гарольд 11, собиратель датских земель в Х веке н.э., и которое, к сожалению, уже получил другой интерфейс с такими же объединяющими свойствами.
Эффективное и повсеместное развёртывание мультимедийных и других услуг зависит от успешной реализации всего стека протоколов ОКСО (а также ОКС7-по-IP, о чем речь пойдет чуть ниже), протоколов IP-телефонии Н.323, SIP, MGCP, MEGACO/Н.248, MPLS, RSVP и др., рассмотренных в книге [50]. Эти протоколы, в первую очередь MGCP и ОКС7-по-IP, не только решают задачи собственно IP-телефонии, но и обеспечивают взаимодействие между IР-сетью и телефонной сетью общего пользования в составе NGN.
Что же касается переноса сообщений ОКС7 через IP-сеть, то это является одним из направлений деятельности рабочей группы Sigtran, входящей в IETF. Протоколы Sigtran (рис. 8.13) обеспечивают надежную транспортировку сообщений OKCО по IP-сетям. Во-первых, это протокол передачи информации для управления потоками ВСТР (Stream Control Transmission Protocol), который Протокол адаптации M2UA, MЗUA, М2РА, SUA, IUA Транспортный протокол сигнализации SCTP Протокол Internet (IP) поддерживает перенос сигнальных сообщений между конечными пунктами сигнализации SP в lp-сети. Для организации сигнальной связи один конечный пункт предоставляет другому перечень своих транспортных адресов (IP-адреса в сочетании с портом SCTP). Протокол SCTP позволяет независимо упорядочивать сигнальные сообщения в разных потоках и обеспечивает перенос сигнальной информации с подтверждением приема, без ошибок и дублирования, доставку сообщений каждого потока в заданной последовательности, возможность объединения нескольких сообщений в один пакет SCTP, фрагментацию данных по мере необходимости, устойчивость к перегрузкам и т.п.
Во-вторых, для выполнения функциональных и качественных
требований к MTP рабочая группа Sigtran рекомендовала три новых протокола: M2UA, M2PA и MЗUA. Каждый из них будет кратко
рассмотрен ниже, но прежде приведем установленные ITU-Т требования к переносу сообщений MTP как по сетям с временным разделением каналов, так и по IP-сетям:
• Для одноранговых процедур уровня 3 MTP требуется время отклика в пределах от 500 мс до 1200 мс.
• Допускается потеря из-за транспортных сбоев не более одного из 10 миллионов сообщений.
• Вследствие транспортных сбоев допускается несвоевременная доставка (включая дублированные сообщения) не более одного из 10 миллиардов сообщений.
• Не более одного из 10 миллиардов сообщений может содержать ошибку, не выявленную транспортным протоколом (согласно спецификациям ANSI — не более одного из миллиарда сообщений).
• Доступность любого пучка сигнальных маршрутов (полная совокупность разрешенных сигнальных путей от любого пункта сигнализации в направлении любого пункта назначения) должна быть не ниже 0.999998 (что соответствует времени простоя приблизительно до 10 минут в течение года).
• Длина сообщения (принимаемая к обслуживанию полезная нагрузка) должна составлять 272 байта для узкополосной ОКС7 и 4091 байтов для широкополосной ОКС7.
Протокол M2UA уровня адаптации для пользователей уровня 2
MTP (MTP Level-2 User Adaptation Layer) предусматривает набор услуг, эквивалентный тому, который предоставляет уровень 2 MTP уровню 3 MTP в обычной сети ОКС7. Протокол используется между шлюзом сигнализации и контроллером транспортного шлюза в VolP-сетях. Шлюз сигнализации принимает сообщения ОКС7 через интерфейс уровня 1 и уровня 2 MTP от конечного или транзитного пункта сигнализации. Он служит окончанием для звена ОКС7 на уровне 2 MTP и транспортирует информацию уровня 3 MTP и вышележащих уровней к контроллеру транспортного шлюза или к другому конечному пункту сети IP, используя протокол M2UA поверх SCTP/IP.
Протокол M2UA уровня адаптации для пользователей MTP2 (MTP2 User Peer-to-Peer Adaptation Layer), в отличие от протокола M2UA, используется для полномасштабной обработки сообщений уровня 3 MTP, которыми обмениваются любые два узла сети ОКС7, взаимодействующие через IP-сеть. Пункты сигнализации IP-сети функционируют как обычные узлы ОКС7, используя IP-сеть вместо сети ОКС7. Каждый пункт сигнализации сети с коммутацией каналов или IP-сети имеет код пункта сигнализации ОКС7. Протокол M2PA предусматривает тот же набор услуг, который предоставляет уровень 2 MTP уровню 3 MTP. Протокол может использоваться между шлюзом сигнализации и контроллером транспортного шлюза, между шлюзом сигнализации и пунктом сигнализации IP-сети, а также между двумя пунктами сигнализации IP-сети. Пункты сигнализации могут использовать протокол M2PA для передачи и приёма сообщений уровня 3 MTP по IP или уровень 2 МТР для обмена этими сообщениями по стандартным звеньям ОКСО. М2РА облегчает интеграцию сетей OKCО и IP благодаря тому, что он позволяет узлам сети с коммутацией каналов иметь доступ к базам данных IP-телефонии и к другим узлам IP-сетей, используя сигнализацию OKCО. И, наоборот, протокол М2РА позволяет приложениям IP-телефонии получать доступ к базам данных сети OKC7.
Итак, протоколы М2РА и M2UA имеют следующие различия:
• М2РА — шлюз сигнализации является узлом ОКСО с кодом пункта сигнализации;
• M2UA — шлюз сигнализации не является узлом ОКСО и не имеет кода пункта сигнализации.
• М2РА — соединение между шлюзом сигнализации и пунктами сигнализации IP-сети представляет собой звено OKCО;
• M2UA — соединение между шлюзом сигнализации и контроллером транспортного шлюза не является звеном OKCО. Оно представляет собой расширение МТР от шлюза сигнализации к контроллеру транспортного шлюза.
• М2РА — шлюз сигнализации может содержать функции верхних уровней OKCО, например SCCP.
• M2UA — шлюз сигнализации не содержит функций верхних уровней ОКС7, поскольку он не содержит функций уровня 3 МТР;
• М2РА — для выполнения функций эксплуатационного управления опирается на соответствующие процедуры уровня 3 МТР;
• M2UA — использует собственные процедуры эксплуатационного управления;
• М2РА: пункты сигнализации IP-сети обрабатывают примитивы уровня 3 MTP и уровня 2 МТР;
• M2UA: контроллер транспортного шлюза переносит примитивы уровня 3 МТР и уровня 2 МТР к уровню 2 МТР шлюза сигнализации для их последующей обработки.
Протокол MЗUA уровня адаптации для пользователей уровня 3 MTP (MTP Level-3 User-Adaptation Layer) связан с переносом по IP-сети средствами протокола ВСТР сигнальных сообщений подсистем-пользователей уровня 3 МТР (например, ISUP, SCCP). Подсистема SCCP может переносить сообщения своих пользователей ТСАР или INAP, с помощью либо протокола MЗUA, либо другого продукта группы Sigtran — протокола SUA, который рассматривается ниже. Протокол MЗUA используется между шлюзом сигнализации и контроллером транспортного шлюза или базой данных IP-телефонии. С концептуальной точки зрения, он расширяет доступ к услугам уровня 3 MTP шлюза сигнализации, охватывая удаленные конечные пункты IP-сети.
К тому же, протокол MЗUA не ограничивает длину сообщения 272-мя октетами, как это установлено уровнем 2 MTP ОКС7. По этой причине M3UA/SCTP позволяет переносить крупные блоки информации, не прибегая к процедурам сегментации/сборки в верхнем уровне. Шлюз сигнализации будет устанавливать 272-октетное ограничение только тогда, когда он подключен к обычной сети ОКС7.
Протокол SUA уровня адаптации для пользователей БССР поддерживает перенос по IP-сети средствами протокола SCTP сигнальных сообщений пользователей SCCP ОКС7 (например, TCAP или INAP). Протокол SUA используется между шлюзом сигнализации и конечным пунктом сигнализации IP-сети и между конечными пунктами сигнализации IP-сети. Пример применения SUA приведен на рис. 8.14.
SUA поддерживает как услуги SCCP без соединения с неупорядоченной и упорядоченной доставкой, так и услуги, ориентированные на соединение, с управлением или без управления потоком данных и с обнаружением потерь сообщений и ошибок вследствие несвоевременной доставки сообщений (т.е. классы услуг SCCP c 0 по 3). В случае услуг без соединения SCCP и SUA стыкуются в шлюзе сигнализации. С точки зрения пункта сигнализации ОКСО, пользователь SCCP находится в шлюзе сигнализации. Сообщения ОКСО направляются к этому шлюзу на основании кода пункта сигнализации и номера подсистемы СССР, а тот направляет сообщения SCCP к удаленному конечному пункту IP-сети.
Протокол уровня адаптации для ISDN-пользователя (IUA) поддерживает перенос через IP-сеть сообщений Q.931. Протокол IUA исключает использование в системе сигнализации части протокола МТР. Протокол IUA позволяет приложениям верхнего уровня непосредственно взаимодействовать с транспортным протоколом АСТР.
Sigtran является не единственной рабочей группой IETF, участвующей в определении новых протоколов для обеспечения интеграции сетей ТФОП и IP. Следует еще упомянуть PINT(PSTN and Internet Interworking — взаимодействие ТФОП и Интернет) и SPIRITS (Service in the PSTN/IN Requesting Internet Service — запросы услуг Интернет в ТфОП/!Н). В PINT услуги ТФОП активизируются путем запросов из IP-сети. Java-клиент SIP, встроенный в сервисное Java-приложение на Web-сервере, создает запросы инициировать телефонные вызовы в ТФОП. Цель состоит в том, чтобы обеспечить Web-доступ к речевому конвенту и осуществлять телефонную/факсимильную связь из Интернет. В SPIRITS услуги IP-сети активизируются путем запросов из ТФОП. SPIRITS, в первую очередь, касается таких услуг, как уведомление о поступлении нового вызова в сети Интернет, предоставление идентификатора вызывающего абонента из сети Интернет и переадресация Интернет вызовов.
Желательно также упомянуть рабочую группу ENUM в составе IETF, которая разрабатывает схему преобразования телефонных номеров Е.164 в Ip-адреса, используя сервер доменных имён DNS сети Интернет таким образом, что любое приложение, включая SIP, может найти ресурсы, связанные с уникальным телефонным номером [118].
Рабочая группа IPTEL разрабатывает протокол TRIP маршрутизации телефонных вызовов по IР-сети (telephony routing over IP), который представляет собой управляемый стратегией меж административный доменный протокол, информирующий серверы адресов о доступности телефонных адресатов и объявляющий атрибуты маршрутов к этим адресатам. TRIP позволяет поставщикам, во избежание избыточного назначения ресурсов или дублирования шлюзов, обмениваться информацией маршрутизации, используя стандартные Интернет протоколы. Не без участия таких рабочих групп протоколы сигнализации и передачи данных для управления соединениями и потоками данных, проходящими через сеть, продолжают развиваться прямо на глазах.