You are here: SwitchKit TCAP Interface User’s Guide > 1 Introduction to SwitchKit TCAP Interface API > TCAP Concepts
Overview
TCAP protocol functionality is divided into two main functional blocks: Component Sub-layer and Transaction Sub-layer. Services provided by these two functional blocks are described in the following sections.
A component is the means by which TCAP conveys a request to perform an operation or reply. An operation is an action performed by the remote end and may have associated parameters. An Invoke ID identifies the invocation of an operation, allowing several invocations of the same or different operations to be active simultaneously. Only one reply may be sent to an operation, indicating success or failure of the operation.
Components are passed individually between a TC-user (or application) and the component sub-layer. The originating TC-user may send several components to the component sub-layer before the message is transmitted to the destination TC-user. When several components are received in a single message, each one is delivered individually to the destination TC-user. Components in a message are delivered to the remote TC-user in the same order they are provided at the originating interface. The importance of the order is established by prior agreement between the TC-users.
The component sub-layer provides two facilities:
1. Association of operations and replies
2. Abnormal situations handling
Association of Operations and Replies
The value of the Invoke ID, which identifies an operation invocation without ambiguity, is returned in a response to that operation invocation. A TC-user may have a number of operations active simultaneously; the maximum number depends on the unique Invoke IDs available to a TC-user. If the response to this operation invocation is another operation invocation from the responding end, the original Invoke ID is returned as a Linked ID indicating that this responding operation invocation is linked to the original operation. Four classes of operations are considered:
• Class 1 Both success and failure are reported
• Class 2 Only failure is reported
• Class 3 Only success is reported
• Class 4 Neither success, nor failure is reported
Where necessary, the TC-user provides segmentation of a successful response. In addition, any number of linked operations may be sent prior to the reply. The reply may be:
• Return result indicating success
• Return error indicating operation failure
• Reject indicating inability to perform the operation
The application protocol designer decides what constitutes success or failure in performing the operation. Any component, except a reject component, may be rejected. Rejection of a result causes termination of the corresponding operation; rejection of a linked operation does not affect the linked-to operation. Rejection of a result segment (that is, rejection of a Return Result — Not Last component) implies the rejection of all subsequent segments and the entire result. A TC-user may cancel an invoked operation; any reply received for this invocation will be rejected.
The Component sub-layer covers a number of abnormal situations in relation to a component:
• Component reject: When the component sub-layer receives a malformed component, or a component that violates the rules of exchange, it informs the TC-user(s)
• Operation expiration: When the component sub-layer detects that a Class 1, 2, or 3 operation has not received a final reply after a certain amount of time (which is specified by the application and depends on the operation), it releases the corresponding Invoke ID and informs the TC-user. Note that this situation is abnormal only in the case of a Class 1 operation. Application of this error to Class 4 operations is a local matter.
• Invocation cancel: A TC-user may decide to release a given Invoke ID and ignore any responses using this identifier
In a situation where the component sub-layer is prevented from providing the expected services, it notifies the TC-user and may terminate pending operations. In addition, a TC-user may decide to abort a dialogue, which ends any pending operations.
Transaction Sub-Layer Services
The Transaction (TR) sub-layer provides capabilities for the exchange of components and dialogue between TR-users. The TR sub-layer also provides the capability to send transaction messages between peer TR sub-layer entities by means of the lower layer network services.
When successive components are exchanged between two TC-users in order to perform an application, this is called a dialogue. The component sub-layer provides dialogue facilities, allowing several dialogues to run concurrently between two TC-users. In addition, dialogue handling allows for the transfer and negotiation of the application context and the transparent transfer of user information (that is, data that are not components) between two TC-users. The component sub-layer provides two dialogue facilities: Unstructured and structured.
Unstructured dialogue infers that TC-users can send components that do not require replies without forming an explicit association. Implicit association always exists between communicating TC-users. An unstructured dialogue is supported by the uni-directional message within the protocol. Use of the unstructured dialogue facility is indicated when one TC-user sends a uni-directional message to its peers. When a TC-user receives a uni-directional message, if a protocol error is reported, it is returned in a uni-directional message.
Structured dialogue infers that TC-users indicate the beginning or the formation of a dialogue, the continuation, and the end of a dialogue. Structured dialogue allows two TC-users to run several dialogues concurrently, each identified by a particular Dialogue ID. Each Dialogue ID has a separate Invoke ID name space, allowing duplication of Invoke IDs in different dialogues. Sequenced delivery of messages is provided by means of application protocols outside the scope of TCAP, or by use of the appropriate SCCP class of service. When using the structured dialogue service, the TC-user indicates one of four possibilities upon sending a component to a peer TC-user:
1. Dialogue begin
2. Dialogue confirmation
3. Dialogue continue - Full-duplex exchange of components is possible
4. Dialogue end - The sending TC-user will not send more components, nor will it accept any more components from the remote TC-user
As an option, in the context of options 1 and 2, an exchange of application context information and user information is possible. When this option is chosen, user information can also be sent during options 3 and 4.