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

Вследствие аномальной ситуации, нижеследующий уровень может решить прервать связь между пользователями, после чего делает необходимо прекратить. Все ассоциированные операции прекращаются и пользователи ТС извещаются посредством примитивов индикации TC-P-Abort.

Параметр P-Abort содержит в себе причину прерывания диалога. Компонентный подуровень решений относительно прерывания диалога не принимает.

Состояния компонент и переходные состояния

Для данного идентификатора компоненты корреляция компонент имеет место только на стороне, которая инициирует операцию. Для этого идентификатора состояния компонент и диаграммы переходных состояний определяются только для этой стороны. Другая сторона просто отражает значение идентификатора компоненты в вызове или идентификатора связанной операции.

Определяются следующие состояния:

• исходное: никакой активности, связанной с идентификацией компонент;

• задержка операции: операция была передана к компонентному подуровню, но запрос на передачу отсутствует;

• передача операции: операция была передана к удаленному окончанию, но результат ее выполнения отсутствует;

• ожидание неприема: был принят результат. ТСАР ожидает возможность неприема пользователем ТС;

• задержка неприема: ТС пользователем был запрошен неприем результата, но запрос на передачу отсутствует.

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

Примечание 2. Запрос TC-END или примитивы индикации, запрос TC-U-Abort или примитивы индикации, или примитив индикации TC-P-Abort вызывает переход в исходное состояние какого-либо идентификатора компоненты, связанного с диалогом. Соответствующие переходы на диаграмме не представлены.

Соотношение компонент с подуровнем транзакций

При сопоставлении подуровня компонент с подуровнем транзакций между диалогом и транзакциями существует однозначное соответствие, что при структурированном диалоге выражается в явном виде, при неструктурированном диалоге, это соответствие выражено неявно. Отсюда следует, что примитивами управления диалогом компонентного подуровня и примитивами управления транзакциями подуровня транзакций имеется однозначное соответствие. Для отображения этого соответствия были выбраны аналогичные базовые названия примитивов (generic names). Примитивы управления компонентами подуровня компонент на подуровне транзакций никаким образом не представлены.

Классы диалога

Всего протокол TCAP поддерживает 4 класса операций:

Не структурированный диалог

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

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

Когда пользователь TC вводит примитив запроса TC-UNI с аналогичным идентификатором диалога, все компоненты, имеющие аналогичный идентификатор, передаются как пользовательские данные к подуровню транзакций. Передача компонент реализуется компонентным подуровнем посредством примитива TR-UNI. На уровне сообщения подуровня транзакций, однонаправленное сообщение не содержит какого-либо идентификатора транзакций и таким образом, каких-либо связей между транзакцией и сообщениями данного типа не предусматривается. Идентификатор диалога используется для передачи группы компонент в сообщении UNI по определенному адресу пункта назначения.

Некоторые особенности операций классов протокола tcap:

Операции класса 1. Характеризуются подтверждением успешного и неуспешного завершения операции. В случае ошибки протокола может также иметь место не прием подтверждающего сообщения. При вызове операции класса 1, на вызывающей стороне идентификатор операции (i) остается активным до приема “последнего” отклика и далее, не может быть не принят.

Идентификатор операции может быть освобожден пользователем ТС на местном окончании. Идентификатор также может быть освобожден при таймауте вызова операции, что указывается на нижеследующей диаграмме конечного автомата функционирования протокола подсистемы транзакционных возможностей ОКС 7 класса 1.

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

При операциях класса 3 докладывается только об успехе операции. В случае ошибки протокола, может иметь место неприем. При вызове операции класса 3 на вызывающей стороне идентификатор вызова сохраняется активным до приема отклика и не может более быть не принятым или до отклика или ситуации завершения. Конечный автомат функционирования протокола подсистемы транзакционных возможностей класса 3 представлен на диаграмме ниже.

В случае операции класса 4 положительное или отрицательное подтверждение выполнения операции отсутствует и идентификатор вызова сохраняется на вызывающей стороне активным до приема компоненты «Reject», или до событий отмены таймаута или ситуации завершения. Конечный автомат функционирования протокола подсистемы транзакционных возможностей класса 4 представлен на диаграмме ниже.

Сокращения рисунка:

«Note» - примечание;

«Idle» - исходное;

«Wait for reject» - ожидание отторжения компоненты;

«Operation sent» - операция передана;

«RR-L» - Return Result – Last (возврат результата выполнения операции – последняя компонента);

«RR-NL» - Return Result – Not Last (возврат результата выполнения операции – не последняя компонента);

RE – Return Error (возврат ошибки);

Cancel – Отмена;

Invocation Timeout – таймаут вызова операции;

End Situation – ситуация завершения операции;

Inv (i, y) –связанный вызов операции y;

«Receive malformed» - прием искаженной информации компоненты результата.

«Receive well-formed” – прием корректной информации компоненты результата.

Конечный автомат подсистемы транзакционных возможностей ОКС 7 класса 1.

Note 1: В этих ситуациях ТС пользователь информируется и переход осуществляется, когда инициируется передача сообщения «reject».

Note 2: Эти ситуации являются аномальными.

Note 3: Когда принимается примитив, указывающий на связанный вызов, проверяется существование конечного автомата i, чтобы гарантировать нахождение в состоянии “operation sent”, что не оказывает влияния на состояние конечного автомата.

Переходы состояний конечного автомата TCAP класса 1,a

Переходы состояний конечного автомата TCAP класса 1, b

Конечный автомат подсистемы транзакционных возможностей ОКС 7 класса 2.

Примечание 1 (Note 1) Это аномальные ситуации приема сообщений RR-NL и RR-L, так как в данном случае должна поступать информация только об ошибке.

Примечание 2 (Note 2) В данных ситуациях ТС пользователь информируется. Переход осуществляется, когда инициируется передача «reject».

Примечание 3. (Note 3) Ситуация аналогична предыдущей, рассмотренной в примечании 2 (т.е. не может приходить запрос выполнения связанной или другой операции).

Конечный автомат подсистемы транзакционных возможностей ОКС 7 класса 3.

Конечный автомат подсистемы транзакционных возможностей ОКС 7 класса 4.

Примечание:

Прием компонент результатов выполнения операции RR-NL (i), RR-L (i) и компоненты сообщения об ошибке RE (i) относятся к аномальным ситуациям.

Управление диалогом посредством тс примитивов

Примитивы запросов TC-UNI, TC-BEGIN, TC-CONTINUE и TC-END используются пользователем ТС для управления передачей компонент.

Определенные примитивы запроса управления диалогом ТС (пользователей) могут также обуславливать построение APDU, в случае, если контекстно-зависимый параметр приложения включен в примитив запроса TC-BEGIN.

Сопоставление примитивов управления диалогом с блоками данных прикладного протокола (APDU –Application Protocol Data Unit) приводится ниже.

PDU управления диалогом передаются в диалоговой части сообщения ТС. Диалоговая часть, если она присутствует, связывается с компонентной частью и переносится к подуровню транзакций как пользовательские данные, соответствующие примитиву услуг TR.

Компоненты в сообщении доставляются к удаленному пользователю ТС в порядке, аналогичному порядку приема от местного ТС пользователя на исходящей стороне компонентного подуровня. Соответствующие указательные примитивы используются компонентным подуровнем для информирования ТС пользователя на приемном окончании о состоянии диалога.

ТС пользователь использует примитив запроса управления диалогом (TC-UNI, TC-BEGIN, TC-CONTINUE или TC-END) для переключения передачи всех ранее переданных компонент с аналогичным идентификатором диалога, исключая примитивы TC-U-ABORT, которые обуславливают удаление из системы компонент, находящихся на ожидании. Примитивы управления диалогом подуровня компонент, в свою очередь, переключают соответствующий запрос услуги к подуровню транзакций. Сопоставление компонент соответствующего подуровня с примитивами управления транзакциями на подуровне транзакций, представлено ниже: