Системы сигнализаций в сетях связи Подсистема управления

Системы сигнализаций в сетях связи

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

Место подсистемы TCAP в стеке протоколов ОКС 7 MAP INAP OMAP MUP TCAP SCCP. . .

Назначение подсистемы TCAP TC могут поддерживать обмен информацией между: ‒ коммутационными станциями и/или узлами сети связи; ‒ станцией (узлом) и базой данных, узлом управления услугами сети IN, центром технической эксплуатации ЦТЭ и т. п. ; ‒ специализированными сетевыми центрами. Пользователями TC могут быть разные приложения, в частности: ‒ приложения услуг мобильной связи; ‒ приложения услуг Интеллектуальной сети IN; ‒ приложения эксплуатационного управления. Все такого рода приложения можно разделить на две категории: ‒ требующие обмена данными в реальном времени, объем данных в этом случае относительно невелик; ‒ не предъявляющие жестких требований в отношении задержек; при этом объем данных может быть очень большим.

Функции TC образуют два подуровня: – подуровень Компонентов (CSL); ‒ подуровень Транзакций (TSL).

Взаимодействие TC-пользователями может быть представлено в виде обмена командами и ответами, составляющего диалог. Инициатор передает запрос выполнения партнером определенной операции, а отклик партнера на этот запрос содержит сведения о результате выполнения. Запрос (и отклик) представляет собой блок, называемый компонентом. Компонент, связанный с обращением к определенной операции, снабжается ID обращения, благодаря чему одновременно могут быть активными несколько обращений, причем обращения эти могут относиться как к одной и той же, так и к нескольким разным операциям. Множество функций, связанных с обработкой компонентов, образует верхний подуровень TC – подуровень CSL.

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

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

Подуровень CSL предусматривает организацию соответствия между запросами и откликами. Связанное с запросом операции значение ID обращения вводится в отклик на этот запрос. Возможны 4 класса операций: ‒ класс 1 – предусматривается отклик и при удаче, и при неудаче; ‒ класс 2 – предусматривается отклик только в случае неудачи; ‒ класс 3 – предусматривается отклик только в случае удачи; ‒ класс 4 – отклик не нужен ни в том, ни в другом случае. Смысл и содержание каждого компонента определяется его типом. Существуют компоненты следующих пяти типов. ‒ INVOKE – обращение. Этот компонент запрашивает выполнение встречной стороной определенной операции. Он может быть связан с другой операцией, к которой обращалась встречная сторона.

‒ RETURN RESULT (NOT LAST) – часть данных с информацией о результате выполнения операции. Все данные с информацией о результате не могут быть целиком размещены в одном компоненте, так что TC-пользователю пришлось разделить их на несколько сегментов. ‒ RETURN RESULT (LAST) – последняя (или единственная) часть данных с информацией о результате выполнения операции. Свидетельствует о том, что операция успешно завершена. ‒ RETURN ERROR – успешно завершить операцию не удалось. ‒ REJECT – отказ в приеме к обработке компонента, поступившего от встречной стороны. Компонент содержит информацию о причине отказа – либо отсутствие ресурсов, нужных для выполнения операции, либо наличие в поступившем компоненте той или иной ошибки.

Структура сообщения TCAP Сообщения TCAP состоят из двух основных частей : ‒ транзакционная часть; ‒ часть компонентов. Транзакционная часть включает протокольную управляющую информацию для подуровня транзакции. Информация в части компонентов касается отдельных операций и их ответов.

Транзакционная часть сообщения TCAP может содержать следующие элементы информации: ‒ тип сообщения – определены следующие типы: 1. однонаправленное – используется в случае, если нет необходимости организовать транзакцию с другим равноправным TP-пользователем; 2. начало – для начала транзакции с другим TP-пользователемучастником; 3. окончание – для прекращения транзакции с другим TPпользователем-участником; 4. продолжение – для окончания организации транзакции и возобновления организованной транзакции; 5. сброс – для прерывания транзакции, которая следует после того как подуровень транзакции (поставщик услуг) определил ненормальную ситуацию, или чтобы прервать транзакцию со стороны TP-пользователя (потребителя услуг).

‒ общая длина сообщения – указывает число байтов в сообщении; ‒ информационные элементы сообщения – используются только для структурированного диалога. Часть компонентов – содержит один или более компонентов сообщения. Формат части компонентов содержит длину этой части и отдельные компоненты сообщения. Когда часть компонентов свободна, данный элемент информации не присутствует. Компонент сообщения состоит из следующих типов элементов информации: ‒ тип компонента; ‒ длина компонента – указывает число байтов в компоненте сообщения; ‒ информационные элементы – зависят от типа компонента.

Сообщение ТСАР состоит из двух частей: 1. Порция транзакций, содержит информацию, необходимую для идентификации природы транзакции, является необходимым полем. 2. Компонентная часть ‒ является элементом содержимого для различных применений. Содержимое может состоять и из единственной величины. В этом случае элемент информации называется примитивом. Один элемент порции транзакции содержит компонентную часть и состоит из тега компонентной части, длины компонентной части и содержимого компонентной части. В расширенном варианте рекурсивного подхода содержимое компонентной части состоит из ряда элементов информации компоненты, в начале каждого из которых стоит тег типа компоненты и поле длины компоненты.

Принцип организации формата сообщения ТСАР

Подсистема SCCP в различных сетевых элементах MSC MAP TCAP BSSAP SCCP MTP TUP NUP ISUP PSTN exchange SCCP MTP MAP BSC BSSAP SCCP MTP TUP NUP ISUP TCAP SCCP MTP HLR