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

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