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

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

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

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

Обмен APDU на протяжении этого типа транзакции отсутствует. Если в течение установления диалога был реализован APDU, то имя контекста приложения (Application Context Name), переданное в AARE 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.

Процедуры, выполняемые при аномальных ситуациях

Какая-либо аномальная ситуация, обнаруженная компонентным подуровнем, являющаяся следствием не своевременно и, соответственно, некорректно принятыми и сформированными компонентами, обуславливают непринятие компоненты и извещение местного пользователя ТС. Прерывание диалога всегда отражает следующие решения:

- компонентного подуровня в случае, когда принята некорректная диалоговая часть ТСАР сообщения, т.е. синтаксически некорректная или не совместимая с состоянием передаваемой далее транзакции. Последний случай соответствует ситуации, когда диалоговая часть теряется, если ее присутствие является обязательным (т.е. APDU AARQ было передано в сообщении begin, но APDU AARE (диалоговый отклик) в первом обратном сообщении Continue отсутствовал, или диалоговая часть принята несвоевременно (например, диалоговая часть APDU принята в течение активного состояния транзакции)

На стороне, где обнаружена аномальная ситуация, примитив индикации ТС-P-ABORT генерируется к местному пользователю ТС с параметром “P-ABORT”, установленным в значение “Аномальный диалог”. Одновременно с этим, примитив запроса TR-U-ABORT генерируется к подуровню транзакций с блоком пользовательских данных типа ABRT. Поле источника прерывания APDU ABRT принимает значение “организатор диалоговой услуги” и поле пользовательской информации отсутствует. На приемной стороне индикации ТС-P-ABORT генерируется компонентным подуровнем, при приеме APDU ABRT, в качестве пользовательских данных в примитиве индикации TR-U-ABORT с полем источника прекращения APDU ABRT, установленным в значении “организатор услуги диалога”.

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

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

- решение пользователя ТС прервать диалог. На исходящей стороне запрос ТС-U-ABORT принимается от ТС пользователя: активный конечный автомат состояний диалога освобождения и запрос TR-U-ABORT передается к подуровню транзакций. На стороне пункта назначения соответствующая индикация TR-U-ABORT принимается от подуровня транзакций, соответствующий активный конечный автомат состояний этого диалога освобождается и индикация ТС-U-ABORT передается к пользователю ТС. Если примитив запроса ТС-U-ABORT вводится в течение активной фазы диалога, то параметр “причина прекращена” отсутствует или установлен в значение “определяется пользователем, APDU “прекращение диалога (ABRT)” формируется только в случае, если APDU “запроса/отклика” AARQ/AARE были использованы в течение состояния установления диалога. Пользовательские данные, предусмотренные в примитиве, переносятся затем в поле пользовательской информации APDU ABRT.

Когда диалог находится в состоянии “инициирование передано”, т.е. сообщение begin было передано, но никакого обратного сообщения на эту транзакцию не принято, результат примитива запроса TC/TR-U-Abort является чисто местным.

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

Рассматриваются следующие аномальные ситуации:

- никакой реакции на вызов операции класса 2;

- прием некорректно сформированной компоненты – тип компоненты и/или идентификатор вызова не могут быть распознаны (т.е. не идентифицируется состояние конечного автомата)

- корректный прием компоненты, но в нарушение допустимой последовательности переходов

Действия, предпринимаемые компонентным подуровнем для доклада об ошибках в части компонент, представлены в таблице 5. При осуществлении выборов, указанных в таблице, руководствуются следующим:

- когда ошибка протокола обнаружена местным ТС пользователем, этот ТС пользователь далее не информируется посредством ТС-Reject, т.к. он уже знает о ее существовании

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

- когда компонента не принята, соответствующий конечный автомат состояний переходит в исходное состояние

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

Об ошибках протокола в компонентной части сообщения ТСАР, сообщается посредством использования компоненты reject. Компонента reject. Передается как отклик на некорректную компоненту, отличную от самой компоненты reject.

Когда идентификатор вызова (Invoke Id), имеющийся в компоненте подлежит удалению (reject), этот идентификатор отражается в компоненте reject.

Сокращения типов компонент представлены выше. В случае, если в сообщении содержится множество компонент и одна из них обнаружена компонентным подуровнем, то все последующие компоненты, содержащиеся в сообщении, удаляются из системы.

Действия, предпринимаемые при ошибках протокола в части компонент