Сообщения, которыми обмениваются пользователи TCAP, могут состоять из одного или нескольких компонентов.
Компонент сообщения может содержать следующие части:
· запрос действия, которое должен выполнить пользователь TCAP в удаленном пункте сети (remote network node);
· запрос данных (информации);
· ответ на запрос действия или запрос информации.
Часть компонентов сообщения разделяется на:
- информационные элементы;
- длину компонента, которая задает число байтов в компоненте сообщения;
- тип компонента.
Структура информационного элемента не зависит от типа компонента. Используются следующие информационные элементы:
· идентификатор запроса (invoke). Используется как ссылка, например, для согласования результатов с действительным запросом действия (action). Каждый компонент сообщения содержит идентификатор запроса;
· код операции (operation code) задает действие, которое необходимо выполнить. Он содержится в компоненте сообщения с запросом.
· код ошибки (error code) указывает, почему действие не было выполнено. Он содержится в компоненте сообщения с возвратом ошибки.
· код проблемы (problem code) указывает, почему был отвергнут компонент сообщения (заблокирован). Он содержится в компоненте сообщения о браковке.
· параметр. Это поле содержит дополнительную информацию пользователя.
Используются следующие типы компонентов:
1. ЗАПРОС (INVOKE). Запрос на выполнение операции пользователем удаленной подсистемы TCAP.
2. ВОЗВРАТ РЕЗУЛЬТАТА НЕ ПОСЛЕДНИЙ (RETURN RESULT NOT LAST). Информирует получателя сообщения TCAP о том, что результат операции распределен по нескольким сообщениям.
3. ВОЗВРАТ РЕЗУЛЬТАТА ПОСЛЕДНИЙ (RETURN RESULT LAST). Информирует получателя сообщения TCAP о том, что операция завершена.
Компонент может содержать (последние) данные результата:
· ВОЗВРАТ ОШИБКИ (RETURN ERROR). Информирует получателя, что операция не выполнена успешно.
* БРАК (REJECT). Отклонение операции (например, неизвестные/неправильные компоненты).
Сообщения протокола TCAP (TCAP Messages):
DEFINITIONS ::=
BEGIN
EXPORTS OPERATION, ERROR, Component, InvokeId Type (тип идентификатора вызова);
Dialogue PDU ::= CHOICE (варианты блоков данных диалога) {
DialogueRequest (запрос диалога) AARQ-apdu, DialogueResponse (продолжение диалога) AARE-apdu,
DialogueAbort (окончаниедиалога) ABRT-apdu}
END - DialoguePDUs
Dialogue Portion
Dialogue PDUs {ccitt recommendation q 773 modules (2) dialoguePDUs(2) version1 (1) }
DEFINITIONS (определения) ::=
BEGIN
EXPORTS dialogue-as-id, DialoguePDU;
DialoguePDU ::= CHOICE (варианты) {
DialogueRequest (запрос диалога) AARQ-apdu, dialogueResponse (продолжение диалога) AARE-apdu,
DialogueAbort (завершение диалога) ABRT-apdu } END -- DialoguePDUs
Unstructureddialogue (неструктурированный диалог):
UnidialoguePDUs { ccitt recommendation q 773 modules (2) unidialoguePDUs (3) version1 (1) }
DEFINITIONS ::=
BEGIN
EXPORTS uniDialogue-as-id, UniDialoguePDU;
-- Abstract syntax name for unstructured dialogue APDUs
uniDialogue-as-id OBJECT IDENTIFIER ::= { ccitt recommendation q 773 as (1) unidialogue-as (2) version1 (1) }
UniDialoguePDU ::= CHOICE { unidialoguePDU AUDT-apdu }
AUDT-apdu ::= [APPLICATION 0] IMPLICIT SEQUENCE { protocol-version [0] IMPLICIT BIT STRING {version1 (0) } DEFAULT { version1 }, application-context-name [1] OBJECT IDENTIFIER, user-information [30] IMPLICIT SEQUENCE OF EXTERNAL OPTIONAL }
END -- UNIDialoguePDU
General message structure (Общаяструктурасообщения TCAP):
Figure 5/Q.773 – Format of Tag
Table 1/Q.773 – Coding of Tag class
Class |
Coding (HG) |
Universal |
00 |
Application-wide (широкого использования) |
01 |
Context-specific |
10 |
Private use |
11 |
Form of the element:
Table 2/Q.773 – Coding of element form
Element form |
Coding (F) |
Primitive |
0 |
Constructor |
1 |
Tag code:
Bits A to E of the first octet of the Tag plus any extension octets represent a Tag code that distinguishes one element type from another of the same class. Tag codes in the range 00000 to 11110 (0 to 30 decimal) are provided in one octet.
Contents:
The contents is the substance of the element and contains the information the element is intended to convey. Its length is variable, but always an integral number of octets. The contents is interpreted in a type-dependent manner, i.e. according to the tag value.
Transmission order
The following transmission order is assumed:
i) the first octet of a string of octets which result from the encoding of a TCAP message is first transmitted;
ii) the least significant bit of each octet is transmitted first.
Figure 8 shows the detailed TCAP message structure.
Message Type Tag (типтэга) |
|||||||||||||
Total Message Lengtha) (Общаядлинасообщения) |
|||||||||||||
Transaction Portion Information Element (Блокинформационногоэлементатранзакции) |
|||||||||||||
Dialogue Portion Information Element (Блокинформационногоэлементадиалога) |
|||||||||||||
Component Portion Tag (Блоккомпонентатэга) |
|||||||||||||
Component Portion Length (Длинаблокакомпонента) |
|||||||||||||
Component Type Tag (Типкомпонентатэга) |
|||||||||||||
Component Length (Длинакомпонента) |
|||||||||||||
Component Portion Information Element (Блокинформационногоэлемента |
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.