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

Основы протокола тсар

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

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

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

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

Процедуры подуровня компонент

Подуровень компонент обеспечивает два типа процедур:

- управление диалогом;

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

Нормальная процедура

Процедура управления компонентами

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

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

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

Управление идентификаторами вызова («Invoke Ids»)

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

Каждое значение идентификатора вызова связано с вызовом операции и соответствующим ей состоянием конечного автомата вызова. Управление этим конечным автоматом состояний осуществляется исключительно на стороне (окончании), которая вызывает операцию. Другое окончание отражает этот идентификатор вызова и это относится к вызову операции, при этом управление состоянием конечного автомата для этого идентификатора не происходит. Отметим, что оба окончания могут вызывать операции полностью в дуплексном режиме: каждое окончание управляет состоянием конечного автомата для вызванных операций и является свободным для распределения идентификаторов вызовов независимо друг от друга.

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

Категории операций

Для каждого класса операции определены различные типы конечных автоматов, соответствующие переходные состояния которых представлены ниже.

Состояния каждой компоненты конечного автомата определены следующим образом:

- Idle – значение идентификатора вызова не присвоено к какой-либо операции задержки;

- Operation sent (операция передана) – значение идентификатора вызова присвоено к операции, которая была завершена или не принята. Состояние (“op. sent”) инициируется (т.е. в него производится переход), когда передана компонента вызова.

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

- примитив, принятый от пользователя ТС, вызывает необходимость создания компоненты «примитив передан».

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

- следующие ситуации:

cancel (отмена)- с вызовом операции связан таймер. Этот таймер вызова операции устанавливается, когда компонента вызова передается к подуровню транзакций.

Примитив запроса TC-Invoke указывает на значение таймера. Ситуация отмены имеет место, когда вызывающий пользователь ТС решает отменить операцию (примитив запроса TC-U-Cancel) перед приемом конечного результата (если он имеется) или истечением таймера.

При приеме запроса TC-U-Cancel подуровень компонент останавливает таймер, какие-либо дальнейшие отклики не передаются к пользователю ТС, действия ТСАР соответствуют обработке аномальных ситуаций.

Ситуация завершена – когда принимаются сообщения END или ABORT или используется предварительно организованное завершение, ТСАР возвращает какие-либо операции, ожидающие выполнения в исходные состояния.

Таймаут вызова (invocation timeout) – ситуации таймаута происходят, когда таймер, связанный с вызовом операции, истекает: конечный автомат переходит в исходное состояние с уведомлением пользователя ТС посредством индикации TC-L-Cancel (в случае операций классов 1,2 или 3). Эта индикация указывает на аномальную ситуацию для операций класса 1 или дает определенный исход операций классов 2 или 3, для которых никакой результат не был принят (нормальная ситуация)

таймаут неприятия сообщения (reject timeout) – соответствующая ситуация имеет место, когда таймер, связанный с состоянием “wait for reject”, истекает. Если это происходит, то подуровень компонент допускает, что ТС пользователь принял компоненту.

На рис.1-4 компоненты содержат либо отдельные значения идентификаторов или упорядоченные пары идентификаторов Ids (i,y), где i – является идентификатором вызова, а y – связанным идентификатором. Диаграммы состояний моделируются для одиночных вызовов операций с Idi. Значение “y” не соотносится с идентификатором i. Операция связанного вызова может приниматься, если конечный автомат находится в состоянии “операция передана”.

Компоненты могут приниматься “корректного содержания и формы” и “некорректного содержания и формы”. На диаграммах отображается, где это имеет место. Если это не имеет значения, то на диаграмме указывается только “прием”.

Эти рисунки также указывают на нормальные и аномальные переходы. Аномальные переходы имеют место в рамках аномальных процедур. Например, при истечении таймаута операции класса 1, это указывает на аномальную ситуацию. Подуровень компонент освободит идентификатор вызова и информирует приложение. Далее, уже от приложения зависит, прервать ли транзакцию или доложить об ошибке аналогичному приложению, с которым происходит взаимодействие.

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