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

На приемной стороне указанный примитив ТC-Continue ind информирует пользователя о следующем:

- что диалог может быть продолжаем;

- что компоненты доставлены (если параметр “компоненты присутствуют” не указывают “пусто”)

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

Для ТС пользователя обеспечивается три сценария, позволяющие ему завершить диалог:

- специально организованное завершение диалога;

- основное завершение диалога;

- прерывание диалога ТС пользователем.

Окончание диалога использует запрос TC-END и соответствующий указательный примитив. Примитив запроса TC-ENE указывает, какой сценарий будет использован для завершения диалога.

а) Предварительно организованное завершение диалога.

В этом сценарии ТС пользователь, по предварительному соглашению решил, когда заключать диалог: влияние примитива TC-END является чисто локальным. К ТС пользователю на приемной стороне пункта назначения никакая индикация TC-END не предусматривается.

Никаких компонент не может быть передано или принято для диалога, как только пользователем был передан примитив управления диалогом TC-END.

в) основной сценарий

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

Базовый сценарий использует примитивы TC-END со следующей целью:

- доставка какой-либо компоненты (компонент), которые были переданы к подуровню транзакций и для которых передача была задержана. (//* на подуровне транзакций допускается образование очереди)

- индикация к ТС пользователю, что обмен компонентами в любом направлении будет для инициированного диалога прекращен.

с) прекращение диалога ТС пользователем

ТС пользователь имеет возможность запросить немедленное прекращение диалога, не принимая во внимание какие-либо задержанные вызовы операций. При этом, пользователь ТС может обеспечить “сквозную” (End-to-End) передачу информации, указывающую на причину прерывания диалога, а так же определенную диагностическую информацию. Эта информация ТСАР не анализируется.

Запрос TC-U-Abort и соответствующая индикация примитива предназначены для выполнения соответствующих функций.

Управление компонентами.

Определение параметров.

Этот раздел определяет параметры, использующиеся с примитивами управления компонентами.

“класс”, “идентификатор диалога” – соотносит компоненты с определенным диалогом;

“идентификатор вызова” – идентифицирует вызов операции;

“идентификатор связанной операции” – связывает текущий вызов операции;

“ошибка” – содержит информацию, обеспечиваемую пользователем ТС, при ошибке возврата операции. Эти информация ТСАР не анализируется.

“последний компонент” – используется только в примитивах типа “индикация”, для обозначения последней компоненты сообщения. Заметим, что индикация последней части результата операции реализуется посредством названия примитива.

“операция” – идентифицирует действие, выполняемое пользователем ТС по запросу другого пользователя ТС.

“параметры”- содержат какие-либо параметры, сопровождающие операцию или предусмотренные в отклике на операцию.

“код проблемы” – идентифицирует причину неприема компоненты.

“таймаут” – указывает на максимальное время действия (существование) идентификатора компоненты. Данный параметр используется для обработки ситуаций неприема ожидаемого результата выполнения ситуаций.

“вызов операции” – запрашивается компонентным подуровнем посредством примитива запроса TC-Invoke. Если этот вызов связан с предыдущей операцией, то используется параметр идентификатора связанной операции. Соответствующий примитив индикации TC-Invoke используется для индикации активации операции к пользователям ТС пункта назначения.

Доклад об успехе операции

Доклад об успешном выполнении операции (класс 1 или 3) является подтверждением выполнения операций удаленным ТС пользователем.

Эта операция идентифицируется в параметре идентификатора вызова. Для доклада об успешном выполнении операции может быть использовано несколько откликов. С этой целью используются следующие примитивы:

• ТС-Result-L указывает на последний сегмент результата (//* может присутствовать только один сегмент)

• ТС-Result-NL – указывает на сегмент результата (имеются еще сегменты)

На количество сегментов ограничений не имеется.

Примитив типа “запрос” используется для передачи результата от ТС пользователя к компонентному подуровню. Примитив типа “индикация” используется для доставки результата к ТС пользователю.

Доклад об ошибке

ТС пользователь, принимающий операцию (класс 1 или 2), которую он не может выполнить, “понимает” это и вводит примитив запроса ТС-U-Error, указывающий на причину ошибки (параметр ошибки). Соответствующая операция идентифицируется параметром идентификатора вызова. ТС пользователь, вызвавший операцию, информируется указательным примитивом TC-U-Error.

Неприем сообщения пользователем ТС

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

Любой неприем вызова или результата завершает операцию. Если связанная операция не принята, то на операцию, с которой она связана, влияния не оказывается.

ТС пользователь не принимает компоненту посредством примитива запроса TC-U-Reject. Удаленный пользователь информируется о неприеме компоненты, посредством примитива указательного типа TC-U-Reject.

Отмена операции

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

Соответствующими компонентами являются указательные компоненты.

TC-L-Cancel – таймер, установленный подуровнем компонент, истекает и соответствующий примитив выдается к ТС пользователю от уровня компонент.

TC-U-Cancel – решение о прекращении диалога исходит от ТС пользователя к подуровню компонент.

Никаких компонент не передается

Группирование компонент в пределах сообщения.

Последовательность компонент получается посредством передачи одной или нескольких компонент с данным идентификатором диалога к компонентному подуровню, что реализуется между двумя успешными запросами на передачу. (TC-Begin, TC-Continue или примитива запроса TC-End). Последовательность компонент также образуется (на исх. стороне) перед первым примитивом управления диалогом TC-Begin, использующим аналогичный идентификатор диалога (//* имеется в виду аналогичный идентификатору примитива управления компонентами *//), или только при запросе на передачу (TC-UNI)

На исходящей стороне список компонент ограничен примитивами запроса TC-UNI, TC-Begin, TC-Continue или TC-End.

На стороне пункта назначения последовательность компонент начинается с примитива, указывающего на передачу; на завершение передачи указывается посредством параметра “последняя компонента” примитивов, которые доставляют компоненты к ТС пользователю. Параметр “компоненты присутствуют” в примитиве передачи указывают на то, является последовательность сообщений пустой или нет.

Аномальные ситуации

1. Неприем компонент на компонентном подуровне. При обнаружении недостоверной принятой компоненты, компонентный подуровень извещает местного ТС пользователя посредством примитива индикации TC-L-Reject.

Этот примитив указывает на причину неприема (параметр “код проблемы”). Во всяком случае указываются тип компоненты и идентификатор компоненты, либо причина “основная проблема”. Эта информация передается к ТС пользователю и также сохраняется на компонентном подуровне, который использует ее для формирования компоненты неприема. Любой тип компоненты может быть не принят. Если непринятой компонентой является сама компонента Reject, то процедура неприема выполняется только на местном уровне, если непринятая компонента идентифицируется как вызов (TC-Invoke req) или результат, то соответствующая операция считается законченной (term). Если это связанная ситуация, то она завершается, однако на последующую идентифицируемую операцию влияния не оказывается. ТС пользователь, приняв компоненту неприема, может принять решение продолжить обмен компонентами. Если это происходит, то удаленный ТС пользователь информируется посредством передачи компоненты Reject (//* с TC-Continue req передается примитив управления компонентами TC-Reject-L*//) о том, что местный пользователь вводит следующий примитив управления диалогом.

Если компонентный подуровень сформировал reject, скомбинированный с аккумулир. компонентами от пользователя ТС и это сгенерированное сообщение превышает ограничения на длину сообщения, то пользователь ТС, знающий о компоненте reject, должен инициировать два примитива управления диалогом. Компонентный подуровень, также уведомленный о проблеме превышения длины, передаст все компоненты, за исключением reject, с первым примитивом. Reject будет передан со следующим примитивом управления диалогом, наряду с какими либо дополнительными компонентами, обеспеченными ТС пользователем.

Прерывание диалога

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

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