Файл: Лекция 1 (Определения и терминология, форматы сообщений).doc

Начало диалога

Примитив запроса TC-BEGIN обуславливает примитив запроса TR-BEGIN, который начинает транзакцию и передает какие-либо компоненты (0 или более), пропущенных к соответствующему интерфейсу (TC-TR), имеющих аналогичный идентификатор диалога. Если контекстно-зависимый параметр приложения был включен в примитив запроса TC-BEGIN, то также переданный диалога (AARQ) APDU непосредственно связывается с компонентной частью.

Адреса пунктов исходящей и входящей стороны, обеспечиваемые примитивом запроса TC-BEGIN, сохраняются подуровнем транзакций до передачи сообщения BEGIN.

На стороне пункта назначения примитив индикации TR-BEGIN принимается компонентным подуровнем, который, в свою очередь, обеспечивает передачу примитива индикации TC-BEGIN к пользователю услуг подсистемы транзакций. При этом, с частью компоненты связываются примитивы управления компонентой, которым предшествует начальная диалоговая информация (если она присутствует).

Подуровень транзакций на входящей стороне сохраняет принятый адрес пункта исходящей стороны, как адрес пункта назначения для этой транзакции.

ТС пользователь принимает примитив индикации TC-BEGIN, содержащий принятые адреса пунктов исходящей и входящей стороны.

Подтверждение диалога

Если ТС пользователь принял параметр имени контекста приложения в примитиве индикации ТС и этот контекст приложения является приемлемым, то пользователь ТС должен включить аналогичное значение в первый примитив запроса на продолжение диалога в обратном направлении, а именно, TC-CONTINUE. Это вызывает связь APDU диалогового отклика (AARE) с какой-либо компонентой в сообщении «Continue».

Если предложенное имя контекста приложения является не приемлемым, то ТС пользователь еще может желать продолжить диалог, но с другим предлагаемым контекстно-зависимым именем приложения в первом примитиве запроса в обратном направлении «TC-CONTINUE». При этом, APDU диалогового отклика («dialogue response») связывается с какой-либо компонентой в сообщении «CONTINUE». В обоих случаях, приведенных выше, поле “результат” - отклик прикладного блока данных управления диалогом (AARE) устанавливается в значении “принято”, в то время, как поле “диагностика источника результата” устанавливается либо в “пользователь диалоговых услуг-ноль” или “пользователь диалоговых услуг (причины не дано)”. Выбор того или иного значения зависит от конкретной реализации ТСАР и в рамках этих рекомендаций является эквивалентным. Соответствующий пользователь ТС вводит примитив запроса TC-CONTINUE с альтернативной возможностью включения параметра «пункт стороны исходящего адреса», который используется только, если пользователь ТС принимает решение об изменении собственного адреса (исх. адрес на стороне В).

---

Подуровень транзакций сохраняет новый адрес пункта исходящей стороны и передает сообщение continue к пользователю, инициирующему транзакцию.

Подуровень транзакций на окончании, инициирующем транзакцию, принимает сообщение «continue» и, так как это сообщение является первым сообщением в обратном направлении, сохраняет адрес пункта исходящей стороны в принятом примитиве N-UNITDATA, как адрес стороны пункта назначения для этой транзакции. Адрес исходящей стороны, сохраненный для этой транзакции, остается неизменным. Эти адреса будут использованы для всех последующих сообщений для этой транзакции и сохраняются неизменными в течение ее существования.

---

Продолжение диалога

Примитив запроса TC-CONTINUE обуславливает примитив запроса TR-CONTINUE, который передает какие-либо компоненты, переданные к интерфейсу TC-TR с аналогичным идентификатором диалога. Если компоненты не неприема были образованы компонентным подуровнем для этого диалога, то их также передают.

На стороне пункта назначения, индикация TR-CONTINUE, принятая компонентным подуровнем, обуславливает передачу TC-CONTINUE к пользователю ТС, за чем следует примитивы управления компонентой, связанные с каждой из принятых компонент.

Обмен блоками данных прикладного протокола (APDU) на протяжении этого типа транзакции отсутствует. Если в течение установления диалога был реализован APDU, то имя прикладного контекста (Application Context Name), переданное в APDU управления откликом диалогового запроса, считается контекстом приложения, действующим на участке между пользователями ТС на фазе диалога. ТС не производит верификацию контекста приложения, исключая отслеживание присутствия APDU управления диалогом на этой фазе диалога, что считается аномальной ситуацией. В течение этой фазы диалога альтернативно может присутствовать часть диалога с семантикой, определенной пользователем.

Завершение диалога

Если пользователь ТС генерирует примитив запроса TC-END для основного завершения диалога, что реализуется как непосредственный отклик на примитив индикации TC-BEGIN, содержащий имя контекста приложения, то это вызывает формирование APDU диалогового отклика (AARE) с полем “результат”, установленным в значение “принято”, в то время как поле “результат диагностики источника” устанавливаются либо в значение ‘диалоговые пользовательские услуги (“ноль” или “диалоговые пользовательские услуги («причина не известна»). Выбор того или иного значения поля “результат диагностики источника” зависит от конкретной реализации и в рамках данных рекомендаций является семантически эквивалентным.

APDU AARE, связанное с какими-либо компонентами, передается для передачи в примитиве запроса TR-END. Примитив индикации TC-END вызывает освобождение конечного автомата диалога.

В случае базового завершения диалога какие-либо компоненты, переданные на интерфейс TC-TR плюс какие-либо компоненты неприема, образованные компонентным подуровнем для этого диалога, транслируются для передачи к подуровню транзакций в примитиве TR-END, затем диалог завершается.

---

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

Если пользователь TС принял примитив индикации TC-BEGIN с параметром названия контекста приложения, который оказывается неприемлемым, вследствие чего ТС пользователь принимает решение не продолжать не продолжать диалог, то он (пользователь) планирует примитив запроса TC-U-ABORT. В примитиве запроса TC-U-ABORT установка параметра “причина прерывания диалога” в значение “название контекста приложения не обеспечивается”, вызывает формирование APDU диалогового отклика AARE. Установка значений различных полей в APDU AARE является следующей:

- результирующее поле соответствует значению “постоянный неприем” и “результат диагностики источника” является диалоговой службой пользователя (название контекста приложения не обеспечивается). Эта APDU передается связанной с какими-либо компонентами в поле пользовательских данных примитива запроса TR-U-ABORT.

---

Состав сообщений tcap

Сообщения TCAP состоят из элементов информации, каждый из которых состоит из трех полей, располагаемых в фиксированном порядке и аналогичных по своей структуре («название, индикатор длины и информация»), описанной для SCCP и ISUP. Для TCAP аналогичные поля именуются тег, длина и содержимое.

Тэг идентифицирует тип передаваемого информационного элемента и влияет на значение поля содержимого. Тэг занимает один байт и кодируется следующим образом: значение класса занимает два бита, форма один бит, а код тега занимает 5 бит. Структура тэга приведена на нижеследующем рисунке.

Структура тэга

Класс тэга может принимать следующие значения:

• «00» - универсальный;

• «01» - прикладной;

• «10» - контекстно-зависимый;

• «11» - частное использование, что подразумевает ориентацию на определенный национальный стандарт.

Форма используется для указания является ли элемент «примитивом» (значение «0» - примитив, значение «1» - конструктор). Значение «конструктор» подразумевает, что каждая компонента строится с помощью другой компоненты, что отражается в нижеследующем рисунке «Возможные варианты структур элементов информации» взятом из рекомендации ITU-T Q.733.

Возможные варианты структур элементов информации

Код тэга может занимать и более пяти разрядов. Тогда он находится в следующем байте. Однако, в большинстве применений значение кода умещается в 5 разрядах в первом байте.

Поле длины указывает размер поля содержимого. Поле содержимого состоит из серии информационных элементов порции транзакции (TPIEs – Transaction Portion Information Elements), каждый из которых соответствует общему формату «тэг, длина, содержимое». В случае, когда более чем один информационный элемент находится в поле содержимого, то и он использует аналогичную структуру и сам состоит из тэга, длины и содержимого.

---