Подсистема ISUP

Подсистема ISUP - это подсистема-пользователь МТР, поддер­живающая межстанционную сигнализацию в ТфОП и в ISDN. При поддержке сигнализации в ISDN ISUP пользуется также услугами SCCP, как это показано на рис. 8.6.

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

Сообщений ISUP слишком много, чтобы рассмотреть их все в этой, и так самой длинной главе учебника. Назовем лишь основ­ные категории сообщений:

• Сообщения управления базовым соединением

• Сообщения управления дополнительными услугами

• Сообщения модификации соединения во время связи

• Сообщения эксплуатационного контроля и управления

• Сквозные сообщения

Принципы форматирования сообщений в ISUP подобны принци­пам, принятым в SCCP и описанным в п. 8.4.2 (в этом легко убедить­ся, сравнив приводимый ниже рис.8.1 1 с рис.8.9). Однако SCCP уст­роена так, что маршрут, по которому проходит «сквозное» сигналь­ное сообщение, никак не связан с маршрутом, по которому прохо­дит соединение телефонных каналов, a ISUP опирается на «каналь­ный» подход идентификации транзакции

Рис. 8.11 Структура сообщения ISUP

Теперь рассмотрим пример установления базового соединения в ISDN. В этом примере (рис.8.12) терминал вызывающего пользова­теля А передает по каналу D в интерфейсе UNI сообщение Q. 931 SETUP в сторону своей АТС (исходящей), которая анализирует его, удосто­веряется в его правильности и передает начальное адресное сооб­щение IAM протокола ISUP к той транзитной АТС, через которую, со­гласно таблице маршрутизации исходящей АТС, должно пройти уста­навливаемое соединение. Одновременно исходящая АТС передает вызывающему абоненту сообщение Q.931 CALL PROCEEDING.

Рис. 8.12 Пример установления базового соединения ISDN Транзитная АТС находит в своей таблице маршрутизации входя­щую АТС и переправляет ей сообщение IAM. Предположим, что в со­общение IAM не был включен адрес вызываемого пользователя (СРА), а входящей АТС этот СРА необходим для завершения уста­новления соединения. Тогда входящая АТС направляет к транзитной АТС сообщение протокола ISUP «Запрос информации» (INR), содер­жащее параметр (индикатор запроса), который говорит о том, что требуется СРА. Транзитная АТС переправляет это сообщение к ис­ходящей АТС.

Исходящая АТС формирует сообщение протокола ISUP «Инфор­мация» (INF) с недостающим СРА и направляет его к входящей АТС. Входящая АТС передает сообщение Q.931 SETUP к оборудованию вызываемого пользователя Б, которое отвечает на это сообщением Q.931 ALERTING. Входящая АТС передает в обратном направлении сообщение протокола ISUP о приеме всего адреса (АСМ). Когда ис­ходящая АТС получает это сообщение, она передает к оборудова­нию вызывающего пользователя сообщение Q.931 ALERTING.

Когда вызываемый абонент отвечает на вызов, его оборудование передает сообщение Q.931 CONNECT к входящей АТС, которая, в свою очередь, передает на транзитную АТС сообщение протокола ISUP «Ответ» (ANM). Транзитная АТС пересылает сообщение ANM к исходящей АТС, а та передает к оборудованию вызывающего поль­зователя сообщение Q.931 CONNECT. В результате между вызываю­щим и вызываемым пользователями устанавливается соединение.

8.5 Сигнализация при конвергенции сетей связи

В последнее время система ОКС7 стала универсальным ключом, своего рода Bluetooth сигнализации для более тесного объедине­ния различных сетевых инфраструктур мобильной связи, проводной связи и IP. Именно этим объединяющим свойством ОКС7 вызвана ассоциация с прозвищем «Голубой зуб» (Bluetooth), которое носил король Дании Гарольд II, собиратель датских земель в X веке н.э., и которое, к сожалению, уже получил другой интерфейс с такими же объединяющими свойствами.

Эффективное и повсеместное развёртывание мультимедийных и других услуг зависит от успешной реализации всего стека прото­колов ОКС7 (а также ОКС7-по-1Р, о чем речь пойдет чуть ниже), про­токолов IP-телефонии Н.323, SIP, MGCP, MEGACO/H.248, MPLS, RSVP и др., рассмотренных в книге [50]. Эти протоколы, в первую очередь MGCP и ОКС7-по-1Р, не только решают задачи собственно IP-теле­фонии, но и обеспечивают взаимодействие между IP-сетью и теле­фонной сетью общего пользования.

Что же касается переноса сообщений ОКС7 через IP-сеть, то это является одним из направлений деятельности рабочей группы Sigt-ran, входящей в IETF. Протоколы Sigtran (рис.8.13) обеспечивают на­дежную транспортировку сообщений ОКС7по IP-сетям. Во-первых, это протокол передачи информации для управления потоками SCTP (Stream Control Transmission Protocol), который поддерживает пере­нос сигнальных сообщений между конечными пунктами сигнализа­ции SP в IP-сети. Для организации сигнальной связи один конечный пункт предоставляет другому перечень своих транспортных адре­сов (IP-адреса в сочетании с портом SCTP). Протокол SCTP позво­ляет независимо упорядочивать сигнальные сообщения в разных потоках и обеспечивает перенос сигнальной информации с подтвер­ждением приема, без ошибок и дублирования, доставку сообщений каждого потока в заданной последовательности, возможность объ­единения нескольких сообщений в один пакет SCTP, фрагментацию данных по мере необходимости, устойчивость к перегрузкам и т.п.

Во-вторых, для выполнения функциональных и качественных тре­бований к МТР рабочая группа Sigtran рекомендовала три новых про­токола: M2UA, М2РА и M3UA. Каждый из них будет кратко рассмот­рен ниже, но прежде приведем установленные ITU-T требования к пе­реносу сообщений МТР как по сетям с временным разделением ка­налов, так и по IP-сетям:

• Для одноранговых процедур уровня 3 МТР требуется время отклика в пределах от 500 мс до 1200 мс.

• Допускается потеря из-за транспортных сбоев не более одного из 10 миллионов сообщений.

• Вследствие транспортных сбоев допускается несвоевременная доставка (включая дублированные сообщения) не более одного из 10 миллиардов сообщений.

• Не более одного из 10 миллиардов сообщений может содержать ошибку, не выявленную транспортным протоколом (согласно спецификациям ANSI - не более одного из миллиарда сообщений).

• Доступность любого пучка сигнальных маршрутов (полная совокупность разрешенных сигнальных путей от любого пункта сигнализации в направлении любого пункта назначения) должна быть не ниже 0.999998 (что соответствует времени простоя приблизительно до 10 минут в течение года).

• Длина сообщения (принимаемая к обслуживанию полезная нагрузка) должна составлять 272 байта для узкополосной ОКС7 и 4091 байтов для широкополосной ОКС7.

Протокол M2UA уровня адаптации для пользователей уровня 2 МТР (МТР Level-2 User Adaptation Layer) предусматривает набор ус­луг, эквивалентный тому, который предоставляетуровень 2 МТР уров­ню 3 МТР в обычной сети ОКС7. Протокол используется между шлю­зом сигнализации и контроллером транспортного шлюза в VoIP-се­тях. Шлюз сигнализации принимает сообщения ОКС7 через интер­фейс уровня 1 и уровня 2 МТР от конечного или транзитного пункта сигнализации. Он служит окончанием для звена ОКС7 на уровне 2 МТР и транспортирует информацию уровня 3 МТР и вышележащих уровней к контроллеру транспортного шлюза или к другому конеч­ному пункту сети IP, используя протокол M2UA поверх SCTP/IP.

Протокол М2РА уровня адаптации для одноранговых пользова­телей МТР2 (МТР2 User Peer-to-Peer Adaptation Layer), в отличие от протокола M2UA, используется для полномасштабной обработки сообщений уровня 3 МТР, которыми обмениваются любые два узла сети ОКС7, взаимодействующие через IP-сеть. Пункты сигнализа­ции IP-сети функционируют как обычные узлы ОКС7, используя IP-сеть вместо сети ОКС7. Каждый пункт сигнализации сети с комму­тацией каналов или IP-сети имеет код пункта сигнализации 0КС7.

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

Итак, протоколы М2РА и M2UA имеют следующие различия:

• М2РА - шлюз сигнализации является узлом ОКС7 с кодом пункта сигнализации;

• M2UA - шлюз сигнализации не является узлом ОКС7 и не имеет кода пункта сигнализации.

• М2РА - соединение между шлюзом сигнализации и пунктами сигнализации IP-сети представляет собой звено ОКС7;

• M2UA - соединение между шлюзом сигнализации и контроллером транспортного шлюза не является звеном ОКС7. Оно представляет собой расширение МТР от шлюза сигнализации к контроллеру транспортного шлюза.

• М2РА - шлюз сигнализации может содержать функции верхних уровней ОКС7, например SCCR

• M2UA - шлюз сигнализации не содержит функций верхних уровней ОКС7, поскольку он не содержит функций уровня 3 МТР;

• М2РА - для выполнения функций эксплуатационного управления опирается на соответствующие процедуры уровня 3 МТР;

• M2UA - использует собственные процедуры эксплуатационного управления;

• М2РА: пункты сигнализации IP-сети обрабатывают примитивы уровня 3 МТР и уровня 2 МТР;

M2UA: контроллер транспортного шлюза переносит примитивы уровня 3 МТР и уровня 2 МТР к уровню 2 МТР шлюза сигнализа­ции для их последующей обработки.

Протокол M3UA уровня адаптации для пользователей уровня 3 МТР (МТР Level-3 User-Adaptation Layer) связан с переносом по IP-сети средствами протокола SCTP сигнальных сообщений подсис­тем-пользователей уровня 3 МТР (например, ISUP, SCCP). Подсистема SCCP может переносить сообщения своих пользователей ТСАР или INAP, с помощью либо протокола M3UA, либо другого продукта группы Sigtran - протокола SUA, который рассматривается ниже. Протокол M3UA используется между шлюзом сигнализации и кон­троллером транспортного шлюза или базой данных IР-телефонии. С концептуальной точки зрения, он расширяет доступ куслугам уров­ня 3 МТР шлюза сигнализации, охватывая удаленные конечные пунк­ты IP-сети.

К тому же, протокол M3UA не ограничивает длину сообщения 272-мя октетами, как это установлено уровнем 2 МТР ОКС7. По этой причине M3UA/SCTP позволяет переносить крупные блоки инфор­мации, не прибегая к процедурам сегментации/сборки в верхнем уровне. Шлюз сигнализации будет устанавливать 272-октетное ог­раничение только тогда, когда он подключен к обычной сети 0КС7.

Протокол SUA уровня адаптации для пользователей SCCP под­держивает перенос по IP-сети средствами протокола SCTPсигналь­ных сообщений пользователей SCCP 0KC7 (например, ТСАР или INAP). Протокол SUA используется между шлюзом сигнализации и конечным пунктом сигнализации IP-сети и между конечными пунк­тами сигнализации IP-сети. Пример применения SUA приведен на рис. 8.14.

Рис. 8.14 Уровень адаптации SUA для пользователя SCCP

SUA поддерживает как услуги SCCP без соединения с неупоря­доченной и упорядоченной доставкой, так и услуги, ориентирован­ные на соединение, с управлением или без управления потоком дан­ных и с обнаружением потерь сообщений и ошибок вследствие не­своевременной доставки сообщений (т.е. классы услуг SCCP с 0 по 3). В случае услуг без соединения SCCP и SUA стыкуются в шлюзе сигнализации. С точки зрения пункта сигнализации ОКС7, пользо­ватель SCCP находится в шлюзе сигнализации. Сообщения ОКС7 направляются к этому шлюзу на основании кода пункта сигнализа­ции и номера подсистемы SCCP, а тот направляет сообщения SCCP к удаленному конечному пункту IP-сети.

Протокол уровня адаптации для ISDN-пользователя (IUA) поддер­живает перенос через IP-сеть сообщений Q.931. Протокол IUA ис­ключает использование в системе сигнализации части протокола МТР. Протокол IUA позволяет приложениям верхнего уровня непо­средственно взаимодействовать с транспортным протоколом SCTR

Sigtran является не единственной рабочей группой IETF, участвую­щей в определении новых протоколов для обеспечения интеграции сетей ТфОП и IP Следует еще упомянуть PINT (PSTN and Internet In-terworking - взаимодействие ТфОП и Интернет) и SPIRITS (Service in the PSTN/IN Requesting Internet Service - запросы услуг Интернет в ТфОП/IN). В PINT услуги ТфОП активизируются путем запросов из IP-сети. Java-клиент SIP, встроенный в сервисное Java-приложение на Web-сервере, создает запросы инициировать телефонные вызо­вы в ТфОП. Цель состоит в том, чтобы обеспечить Web-доступ к ре­чевому контенту и осуществлять телефонную/факсимильную связь из Интернет. В SPIRITS услуги IP-сети активизируются путем запро­сов из ТфОП. SPIRITS, в первую очередь, касается таких услуг, как уведомление о поступлении нового вызова в сети Интернет, предос­тавление идентификатора вызывающего абонента из сети Интернет и переадресация Интернет-вызовов.

Желательно также упомянуть рабочую группу ENUM в составе IETF, которая разрабатывает схему преобразования телефонных номеров Е.164 в IP-адреса, используя сервер доменных имён DNS сети Ин­тернет таким образом, что любое приложение, включая SIR может найти ресурсы, связанные с уникальным телефонным номером.

Рабочая группа IPTEL разрабатывает протокол TRIP маршрутиза­ции телефонных вызовов по IP-сети (telephony routing over IP), кото­рый представляет собой управляемый стратегией межадминистра­тивный доменный протокол, информирующий серверы адресов о доступности телефонных адресатов и объявляющий атрибуты мар­шрутов к этим адресатам. TRIP позволяет поставщикам, во избежа­ние избыточного назначения ресурсов или дублирования шлюзов, обмениваться информацией маршрутизации, используя стандарт­ные Интернет-протоколы. Не без участия таких рабочих групп про­токолы сигнализации и передачи данных для управления соедине­ниями и потоками данных, проходящими через сеть, продолжают развиваться прямо на глазах.