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

N/A – не принимается

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

в) невозможно определить существует ли конечный автомат вызова или нет, и, таким образом, никаких действий не предпринимается

Note: Какие-либо действия на удаленном окончании зависят от местного пользователя, вводящего примитив диалога, чтобы послать компоненту reject, сформулированную местным CSL. Некоторые пользователи могут выбрать - не вводить диалоговый примитив в некоторых или всех случаях. В этих случаях на удаленном окончании не предполагается никаких действий.

Неприем какой-либо части сегментированного результата эквивалентно неприему всего результата. Соответствующий конечный автомат переходит в исходное состояние. Последующие части аналогичного переданному ранее конечного результата, также должны быть не приняты (на базе пассивного конечного автомата). Механизм неприема, при обнаружении компонентным подуровнем ситуации (не на местном уровне), где должен быть инициирован “неприем”, компонентный подуровень образует компоненту reject, сохраняет ее и информирует местного ТС пользователя посредством примитива индикации TC-L-Reject. ТС пользователь может далее принять следующие решения:

а) продолжить диалог

в) закончить диалог, используя базовый сценарий

с) прервать диалог

В случаях а) и в) первый примитив управления диалогом (запрос TC-Continue или TC-END, соответственно), введенные пользователем ТС, переключают передачу сохраненных компонент «reject», образованных для этого диалога компонентным подуровнем. Удаленный подуровень компонент принимает компоненты reject, образованные для этого диалога, освобождает соответствующие конечный(е) автомат(ы) состояний компонентного подуровня, если это возможно (согласно таблице 5) и информирует ТС пользователя удаленного неприема посредством примитива (примитивов) информации «TC-R-Reject».

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

Обработка аномальных ситуаций, связанных с операциями

Процедуры подуровня транзакций

В случае структурированного диалога, подуровень транзакций обеспечивает соединение из конца в конец между TR пользователями. Это соединение из конца в конец называется транзакцией.

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

Подуровень транзакций обрабатывает часть транзакции (тип сообщения и идентификатор транзакции) сообщения ТСАР. Идентификаторы транзакции идентифицируют транзакцию. Каждое окончание присваивает местную идентификацию транзакции, как указывается в Рекомендациях Q.773, эти локальные идентификаторы транзакции передаются в транзакционный части сообщений.

Компонентная часть сообщения ТСАР передается между компонентным подуровнем и транзакционным подуровнем как пользовательские данные в примитивах подуровня транзакций. В случае неструктурированного диалога, идентификатор транзакции не присваивается. Компонентная часть сообщения Unidirectional принимается как пользовательские данные в примитиве запроса TR-UNI. Часть транзакции сообщение Unidirectional формируется, после чего производится передача сообщения.

Сопоставление примитивов услуги tr по типам сообщения

Рекомендации Q.771 описывает услуги, выполняемые подуровнем транзакций посредством определения интерфейса услуг между пользователем ТС и подуровнем транзакций и подуровнем транзакций и SCCP. Аналогично, диаграммы переходов состояний, представленные в Рекомендации Q.771, базируются на примитивах услуг. В этом разделе, описание протокола базируется на сообщениях. Сопоставление TR-примитивов с блоками данных протокола подуровня транзакций, указывается в следующей ниже таблице.

1. Нормальные процедуры

   1. Передача сообщения без установления транзакции

      1. Действия на передающем окончании

Примитив запроса TR-UNI используется, когда TR пользователь передает сообщение к другому TR пользователю, но его нет необходимости вводить в транзакцию. В этом случае, используется однонаправленное сообщение Unidirectional, которое не имеет идентификатора транзакции.

Действия на приемном окончании

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

Передача сообщения, вложенного в транзакцию

Начало транзакции

А – передающий узел, В – принимающий узел

Действия на инициирующем окончании

Пользователь TR в узле А инициирует транзакцию посредством использования примитива запроса TR-Begin, что вызывает передачу сообщения Begin от узла А в узел В. Сообщение Begin содержит идентификатор исходящей транзакции. Это значение идентификатора транзакции, при ее включении в какие-либо последующие сообщения от узла А, считается идентификатором исходящей транзакции, а в сообщениях к узлу А идентификатором транзакции пункта назначения, идентифицируя транзакцию к узлу А. Как только подуровень транзакций в узле А передает сообщение Begin, данный подуровень не может передать другое сообщение к подуровню транзакций узла В, пока на это сообщение от узла В не будет получено сообщение Continue

Действия на приемном окончании

Прием сообщения Begin вызывает передачу примитива индикации TR-Begin к пользователю TR в узле В. В ответ на примитив индикации TR-Begin, TR пользователь в узле В решает установить или же нет, транзакцию.

Если пользователь TR желает устанавливать транзакцию, то он передает к подуровню транзакций примитив запроса TR-Continue, в противном случае, он завершает транзакцию (ссылка) эти условия определяются TR пользователем.

Сообщение «Begin» содержит только идентификатор исходящей транзакции. Если, после приема сообщения «Begin» с данным идентификатором исходящей транзакции, подуровень транзакций принимает другое сообщение с тем же идентификатором исходящей транзакции, то подуровень транзакций не рассматривает это как аномальную ситуацию: вторая транзакция инициирована в узле В.

Продолжение транзакции

Сообщение Continue передается от одного узла к другому, когда примитив запроса «TR-Continue» передается от пользователя TR к подуровню транзакций в передающем узле.

Сообщение «Continue» включает в себя идентификатор транзакции пункта назначения, который является идентичным, т.е. октет аналогичного значения и длины идентификатору исходящей транзакции. Идентификаторы транзакций остаются постоянными на все время существования транзакции.

Сообщение «Continue» включает в себя как идентификатор исходящей, так и входящей транзакции. Id исходящей транзакции в последующих сообщениях Continue не проверяется. Прием сообщения Continue вызывает передачу примитива индикации «TR»- Continue к TR пользователю пункта назначения.

Как только пользователь в узле В подтверждает сообщение Begin посредством примитива запроса TR- Continue, необходимого для установления транзакции, все последующие взаимодействия между TR пользователем и подуровнем транзакций реализуются посредством примитива TR- Continue до завершения транзакции. В терминах сообщений, как только сообщение Continue передается от узла В, все последующие сообщения будут сообщениями Continue до момента завершения транзакции.

Завершение транзакции

Базовый метод – TR пользователь на любом окончании может завершить транзакцию посредством передачи примитива запроса TR-END (указывается основное окончание) к подуровню транзакций. Сообщение End передается к подуровню взаимодействия (подуровню транзакций), который в свою очередь, передает примитив индикации TR-End к соответствующему подуровню компонент. Сообщение END содержит идентификатор транзакции пункта назначения, который является идентичным в части октета значения и длины, идентификатору исходящей транзакции, принятой в первом сообщении от соответствующей подсистемы взаимодействия.

Предварительное организованное окончание

В этот метод заключается в том, что соответствующая подсистема взаимодействия априори знает, что в данной точке, согласно описанию приложения – транзакция будет освобождена. В этом случае TR пользователь передает примитив запроса TR-End (указывающий на предварительно организованное окончание) к подуровню транзакций и никакого сообщения “окончание” не передается.

Прерывание TR пользователем