Файл: Основные особенности протокола TCAP,ОКС7 (начало).doc

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

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

Местно, ID может быть освобожден пользователем ТС. ID также может быть освобожден при таймауте вызова. Это указывается на рис.1

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

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

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

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

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

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

Примечание 1 (Note 1) Это аномальные ситуации. Так как в данном случае должна поступать информация только об ошибке.

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

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

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

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

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

Сопоставление примитивов управления диалогом с прикладными блоками данных APDU приводится ниже.

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

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

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

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

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