![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Подсистема 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. В результате между вызывающим и вызываемым пользователями устанавливается соединение.
В последнее время система ОКС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 позволяет поставщикам, во избежание избыточного назначения ресурсов или дублирования шлюзов, обмениваться информацией маршрутизации, используя стандартные Интернет-протоколы. Не без участия таких рабочих групп протоколы сигнализации и передачи данных для управления соединениями и потоками данных, проходящими через сеть, продолжают развиваться прямо на глазах.
|