JAIN TCAP Requirements Specification

2 Introduction

TCAP is a layer of the SS7 communications protocol that was developed to add transaction based functionality, such as maintaining a dialogue with a database, providing the mechanism to access remote switches and activating features within those switches, to the existing telephone network. The TCAP layer is designed for signaling related messages and provides a means for transfer of information from one application at a switch to another application within another network entity. The information passed through the TCAP layer must be transferred between applications, transparently through the network.

The objective of the JAIN TCAP API specification is to specify a Java API that will provide the interfaces and classes required to initialize and terminate a TCAP session, manage TCAP dialogue identifiers, retrieve, build and send dialogue and component primitives.

2.1 System Overview

TCAP captures the general essence of Transaction processing, which is a sequence of gathering and transferring information. A logical example of transaction processing [Also see Appendix IV] in every day life is the interaction between an ATM and a person, see Figure 2.1:

In this example the person interfaces to the ATM machine and has no idea how the ATM is talking to the Bank. The ATM presents a single interface to what are multiple interfaces. A SS7 TCAP protocol stack operates the same way. TCAP provides one interface to the application, when in reality, there may be numerous underlying interactions taking place. All the details of the transaction are not sent to the far node until the final piece of information has been gathered and checked.

In the ATM example, the transaction is not completed until the person has collected the card and walked away. This is analogous to a structured dialogue in TCAP, which is not deleted until the dialogue is complete. The ATM machine handles all the error processing, similarly TCAP has to handle all possible error conditions.

In the ATM example, the person could enter wrong values, enter different accounts to draw from, different amounts of money, etc. or the Bank had the option to reject the request based on any of the data provided.

This simple ATM example does not take into account all the complexities of money transactions, but the basic idea is to interact with a bank to exchange information, and hopefully get money. In the same way, there are many complexities needed to support SS7 TCAP processing, but the goals are the same, interact with a foreign entity to which you send and retrieve information, and hopefully get results.

Although the interactions between the banking system and the ATM are quite complex, the interface to the human is quite simple. Similarly this specification and the resultant API specification only deal with the simple interface to the functions of TCAP. While the TCAP layer and the SS7 Network are quite complex, the API specification hides the complexities so applications can focus on services. The TCAP API is only concerned with the application interface, not the SS7 implementation.

2.1.1 Transaction Capabilities Application Part

The purpose of TCAP is to provide the means for the transfer of information between signaling point nodes and to provide generic services to applications such as mobile telephony and free phone service, while being independent of any of these. TCAP is used in the real world today, by a variety of applications including:

"0800" Number Translation – One of the first usage’s of TCAP, where a "0800" phone number is converted into a different routable phone number. [See Figure 2.1]
Call Forwarding – A subscriber can forward their phone calls, to another subscribers phone number.
Automatic Callback – A subscriber dials a number, which is busy, enters a feature code and hangs up. When the dialed number becomes free the subscriber is called back.

Figure 2.2 shows where TCAP resides in the functional representation of an SS7 stack.

In the SS7 stack diagram the other layers included are:

ISUP: - A protocol of SS7 which provides the signaling functions necessary to basic bearer services and supplementary services for voice and non-voice applications in the Integrated Services Digital Network. It defines the protocol and procedures used to set-up, manage and release trunk circuits that carry voice and data call over the Public Switched Telephone Network (PSTN).

SCCP: - Additional functions to the Message Transfer Part to cater for both connectionless as well as connection-orientated network service and to achieve an Open Standards Interconnection compatible network service. The SCCP transfers signaling data units across the SS7 network, with or without using a logical signaling connection.

MTP: - The functional part of a common channel signaling system which transfers signaling messages as required by all the users, and which performs the necessary subsidiary functions, for example error control and signaling.

MTP Level 1: - defines the physical, electrical and functional characteristics of a signaling data link and the means to access it.
MTP Level 2: - defines the functions and procedures related to transferring signaling messages over a single signaling data link.
MTP Level 3: - defines the functions and procedures that are related to routing the messages between the signaling points.

The dialogue between two TCAP users is initiated by one of the users with a 'BEGIN' primitive, and terminated by one of the users with an 'END' primitive. Data and commands are passed in the dialogue by 'component's. Once a dialogue has been established between two TCAP users successive components are exchanged between both users. A TCAP user may pass a number of components into the TCAP layer. However only when the TCAP user employs a dialogue request primitive will the transmission of all previously passed components with the same dialogue identifier are triggered. The most common component primitives include:

INVOKE: - requests an operation invocation to the component sub-layer, a corresponding INVOKE indication primitive is used to indicate operation activation to the destination user.
RESULT: - reports the result of the successful completion of an operation execution by the remote user.

Where a component is a protocol data unit exchanged between TC-Users, via the TCAP layer. The most common dialogue primitives include:

BEGIN: - initiates a dialogue with a remote TCAP user. Figure 2.4 is an example of the use of this primitive.
CONTINUE: - without terminating a dialogue this primitive forces the transmission of the collected components to the remote TCAP user. Figure 2.6 illustrates how this primitive is used in a Dialogue.
END: - terminates a dialogue. Figure 2.4 illustrates how a user terminates a dialogue.
UNIDIRECTIONAL (UNI): - the simplest of dialogues, this primitive forces the transmission of the transaction without a BEGIN, an END, or any dialogue processing. A UNI simply sends a message in an unstructured dialogue. Figure 2.5 illustrates how this primitive is used in a Dialogue.

Where a dialogue is an association established between two TC-Users exchanging components, as opposed to a transaction which is an association between two Transaction Capabilities providers.

A typical message exchange sequence between two nodes in a network during a structured dialogue is illustrated in Figure 2.4. The signaling between a User and the TCAP within a node, is the Component and Dialogue handling primitives passed between them. The diagram uses JAIN terminology when referring to the TCAP Component and Dialogue handling primitives. The mapping of these JAIN Events to protocol specific primitives is outlined in Table 2.1

A User passes a number of Component primitives to the TCAP followed by a Dialogue primitive (bold). The receipt of a Dialogue handling primitive by TCAP from a User triggers the transmission of all previously passed components to the destination node. At the receiving node TCAP passes a Dialogue handling Indication primitive to the user along with any associated Component Indication primitives. Indication primitives are passed from TCAP to the User, while request primitives are passed from the User to TCAP. It should be noted that the time sequence of invocation/result pairs in Figure 2.4 is just an example of such a sequencing.When multiple invocations are received in a BEGIN, they are handed up to the User one after another with no implication that you wait for results of a previous one before handing up the next invocation. According to the TCAP specifications the invocations are handed up to the remote User in the same order in which they were handed down to the local User.

*JainEvent*	No	*ITU Primitive*	*ANSI Primitive*	*Event Properties*
Invoke	1, 2	TC_INVOKE	TC_INVOKE_NL	isLastInvoke() == false
Invoke	3	TC_INVOKE	TC_INVOKE	isLastInvoke() == true
Begin		TC_BEGIN	TC_QWP TC_QWOP	isAllowedPermission() == true isAllowedPermission() == false
Result	2, 1	TC_RESULT_NL	TC_RESULT_NL	isLastResult() == false
Result	3	TC_RESULT_L	TC_RESULT_L	isLastResult() == true
End		TC_END	TC_RESPONSE

Table 2.1 - Mapping of JAIN Events to protocol primitives for Figure 2.4

A typical message exchange sequence between two nodes in a network during an unstructured dialogue is illustrated in Figure 2.5. In contrast to a structured dialogue, there is no initiation or termination associated with an unstructured dialogue in that there is no response expected from the remote node. The mapping of these JAIN Events to protocol specific primitives is outlined in Table 2.2

*JainEvent*	No	*ITU Primitive*	*ANSI Primitive*	*Event Properties*
Invoke	1, 2	TC_INVOKE	TC_INVOKE_NL	isLastInvoke() == false
Invoke	N	TC_INVOKE	TC_INVOKE	isLastInvoke() == true
Unidirectional		TC_UNI	TC_UNI

Table 2.2 - Mapping of JAIN Events to protocol primitives for Figure 2.5

A typical message exchange sequence between two nodes in a network during a continued structured dialogue is illustrated is Figure 2.6. The Continue Dialogue handling primitive indicates the continuation of the dialogue. The mapping of these JAIN Events to protocol specific primitives is outlined in Table 2.3

*JainEvent*	No	*ITU Primitive*	*ANSI Primitive*	*Event Properties*
Invoke		TC_INVOKE	TC_INVOKE	isLastInvoke() == true
Begin		TC_BEGIN	TC_QWP TC_QWOP	isAllowedPermission() == true isAllowedPermission() == false
Result	1	TC_RESULT_NL	TC_RESULT_NL	isLastResult() == false
Continue		TC_CONTINUE	TC_CWP TC_CWOP	isAllowedPermission() == true isAllowedPermission() == false
Result	2	TC_RESULT_L	TC_RESULT_L	isLastResult() == true
End		TC_END	TC_RESPONSE

Table 2.3 - Mapping of JAIN Events to protocol primitives for Figure 2.6

If you have any comments or queries, please mail them to [email protected]