Подсистема средств транзакций

Средства транзакций ТС - Transaction Capabilities - предназначены для поддержки взаимодействия между прикладными процессами (или между разными элементами одного процесса), размещенными в территориально разнесенных узлах сети связи. Любой такой процесс (или элемент процесса) внутри одного узла сети связи является пользователем услугами ТС, размещенных на этом узле. С другой стороны, сами ТС того или иного узла являются пользователем сетевыми услугами, предоставляемыми размещенной на нем подсистемой NSR

ТС могут поддерживать обмен информацией между:

коммутационными станциями и/или узлами сети связи,

станцией (узлом) и базой данных, узлом управления услугами сети IN, центром технической эксплуатации ЦТЭ и т. п.,

специализированными сетевыми центрами. Пользователями ТС могут быть разные приложения, в частности:

приложения услуг мобильной связи,

приложения услуг Интеллектуальной сети IN,

приложения эксплуатационного управления.

Все такого рода приложения можно разделить на две категории:

требующие обмена данными в реальном времени (т.е. без ощутимых задержек); объем данных в этом случае относительно невелик,

не предъявляющие жестких требований в отношении задержек; при этом объем данных может быть очень большим.

Как видно из рис. 8.10, функции ТС образуют два подуровня - подуровень компонентов (CSL) и подуровень транзакций (TSL). Чтобы стало ясно, в чем тут дело, нужно определить ряд понятий, связанных с тем, как разделены функции между этими подуровнями и какие услуги каждый из них предоставляет подуровню, расположенному выше.

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

Рис. 8.10. Подсистема средств транзакций ТС

Запрос (и отклик) представляет собой блок, называемый компонентом. Компонент, связанный с обращением к определенной операции, снабжается идентификатором (ID обращения), благодаря чему одновременно могут быть активными несколько обращений, причем обращения эти могут относиться как к одной и той же, так и к нескольким разным операциям.

Множество функций, связанных с обработкой компонентов, образует верхний подуровень ТС - подуровень CSL. Через границу между этим подуровнем и ТС-пользователем компоненты проходят индивидуально. Пользователь (инициатор) может передать к подуровню CSL один за другим несколько компонентов до того, как они будут переданы (в одном сообщении) второму ТС-пользователю (партнеру). Несколько компонентов, принятых в одном сообщении, всегда передаются пользователю-адресату по одному и в той последовательности, в какой они были переданы пользователем-отправителем.

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

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

При структурированном диалоге связь между двумя ТС-пользователями определяется в явном виде - ТС-пользователь указывает начало, продолжение и окончание этой связи. Два ТС-пользователя могут вести одновременно несколько структури-рованныхдиалогов, идентифицируя каждый из них с помощью уникального 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 и МТР) для двустороннего переноса через сеть ОКС сообщений между двумя взаимодействующими подсистемами ТС, размещенными в разных пунктах этой сети.

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

Поддержка структурированного диалога базируется на том, что каждый TSL-пользователь идентифицирует транзакцию уникальным Ю транзакции, который присутствует во BcexTSL-сообщениях, относящихся к этой транзакции. Для каждой транзакции TSL-пользователь указывает ее начало, продолжение и окончание; на фазе продолжения возможен дуплексный обмен между TSL-пользователями сообщениями «внутри» этой транзакции.

Отметим, что в настоящее время специфицированы средства транзакций, использующие только такие услуги SCCP, которые не предусматривают создание в сети ОКС сигнальных соединений. Использование услуг, ориентированных на сигнальные соединения, изучается ITU-T

Подсистема ISUP

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

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

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

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

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

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

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

МАРШРУТНАЯ ЭТИКЕТКА

ИДЕНТИФИКАТОР КАНАЛА

ТИП СООБЩЕНИЯ

ОБЯЗАТЕЛЬНАЯ ЧАСТЬ ФИКСИРОВАННОЙ ДЛИНЫ

ОБЯЗАТЕЛЬНАЯ ЧАСТЬ ПЕРЕМЕННОЙ ДЛИНЫ

Принципы форматирования сообщений в ISUP подобны принципам, принятым в SCCP и описанным в п. 8.4.2 (в этом легко убедиться, сравнив приводимый ниже рис. 8.11 с рис. 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. В результате между вызывающим и вызываемым пользователями устанавливается соединение.