Transaction Capabilities Application Part (TCAP)

ITU -T Q 771
A basic introduction
What is TCAP???
The Transaction Capabilities Application Part (TCAP) of
the SS7 protocol allows services at network nodes to
communicate with each other using an agreed-upon set
of data elements.

TCAP is at level 4 of the SS7 protocol stack.

It depends upon the SCCP's transport services because

TCAP itself does not contain any transport
information.
Role of TCAP in Call Control
TCAP is used to provide information to SSPs
information is often used to enable successful call
completion, but TCAP is not involved in the actual
call-setup procedures.
TCAP is at level 4 of the SS7 protocol stack. It
depends upon the SCCP's transport services because
TCAP itself does not contain any transport
information.
FUNCTIONAL DESCRIPTION OF TRANSACTION CAPABILITIES

"Transaction Capabilities" refers to a set of

communication capabilities that provide an interface
between applications and a network layer service.

Transaction Capabilities (TC) provide functions and

protocols to a large variety of applications distributed
over switches and specialized centers in
telecommunication networks (e.g. databases).
Scope of Transaction Capabilities:
1) exchanges
2) an exchange and a network service centre (e.g. database,
specialized facility unit, OA&M Centre)
3) network service centers‘
Applications:
mobile service application (e.g. location of roamers);
registration, activation and invocation of supplementary
services involving specialized facility units (e.g. free phone
service, credit card service);
 non-circuit control-related exchange of signaling information
(e.g. closed user group, look-ahead procedure);
 operation and maintenance applications (e.g. query/response).
 Structure of TC
TC lie above the network layer of the OSI model.
TC is structured in two sub layers:
 the component sub layer deals with components which are
the Application Protocol Data Units (APDUs) that convey
remote operations and their responses and, as an option, the
dialogue portion protocol for conveying information related to
application context or user information;
 the transaction sub layer, which deals with the exchange of
messages containing components and optionally, a dialogue
portion, between two TC-users.
Service provided by the Component sub
layer

Component
Dialogue
Component correlation
Error handling
Component
A component is the means by which TC conveys a
request to perform an operation, or a reply

An operation is an action to be performed by the remote

end.
A reply carries an indication of success or failure in
carrying out the operation.

Components in a message are delivered to the remote

TC-user in the same order as they are provided at the
originating interface.
Types of components
Invoke— Requests an operation to be performed
Return Result— Reports the successful completion of
a requested operation
Return Error— Reports the unsuccessful completion of
a requested operation
Reject— Reports a protocol violation, such as an
incorrect or badly-formed OPDU
The contents of the Invoke and Return Result
components include:

Component Type
Component ID
Operation Code (Invoke Component only)
Parameters
Dialogue
Successive components exchanged between two TC-
users in order to perform an application constitute a
dialogue.

Dialogue handling also allows, as an option, for the

transfer and negotiation of the application context, and
the transparent transfer of user information (i.e. data
which are not components) between two TC-users.
Dialogue
Two kinds of facilities are provided: unstructured and
structured.
Unstructured dialogue
TC-users can send components that do not expect
replies without forming an explicit association
between themselves
Structured dialogue
TC-users indicate the beginning, or the formation of a
dialogue, the continuation, and the end of a dialogue
Dialogue handling
TC-UNI: Requests/indicates an unstructured dialogue.
TC-BEGIN: Begins a dialogue.
TC-CONTINUE: Continues a dialogue.
 TC-END: Ends a dialogue
TC-U-ABORT: Allows a TC-user to terminate a
dialogue abruptly, without transmitting any pending
components.
– TC-P-ABORT: Informs the TC-user that the
dialogue has been terminated by the service provider
(i.e. TC Transaction sub layer) in reaction to a
transaction abort by the Transaction sub layer. Any
pending components are not transmitted.
– TC-NOTICE: Informs the TC-user that the Network
Service Provider has been unable to provide the
requested service.
Component correlation
The Component sub layer provides the following
facilities:
Association of operations and replies
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.
Abnormal situations handling:
Component reject
Operation expiry
Invocation cancel

Error handling
When the Component sub layer is informed of a situation
which
prevents it from providing the service expected by the TC-
users, it will notify the TC-user, and may terminate the
pending operations .
Errors at the Component Layer
Protocol errors at the component sub layer are reported
using a Reject Component. The error component's
Component ID is reflected in the Reject Component. A
number of different errors can be detected and reported.

Another type of error is a component that is simply coded

with an incorrect value, such as an unrecognized
component type.
Service provided by the Transaction sub
layer
Two types of service are provided:

Unstructured dialogue
Structured dialogue
The following facilities are provided( Structured dialogue):

Transaction begin
Transaction continuation
Transaction end
Transaction abort by TCAP
Exception reporting
Errors at the Transaction Layer

Protocol Errors that occur at the transaction sub layer are

reported to the remote node by sending an Abort
message type with a P-Abort cause—in other words, a
Protocol Abort.

The Abort message is sent only when a transaction must

be closed and a Transaction ID can be derived from the
message in which the error occurred
Message Types
Beginning of a dialogue
The purpose of this primitive is:
– to indicate to the Component sub layer that a new
dialogue starts, identified by the "dialogue ID"
parameter of the primitive;

– to request transmission of any component(s)

previously passed to the Component sub layer by
means of component handling primitives of the
"request" type with the same dialogue ID
Confirmation of the dialogue ( new user)

A TC-user indicates that it wants to continue a dialogue

by issuing a TC-CONTINUE request primitive.

The TC-CONTINUE primitive requests transmission

of any component(s) that have been passed to the
Component sub layer for this dialogue, since the TC-
BEGIN indication primitive was received for this
dialogue
TC-CONTINUE primitives
Continuation of the dialogue
End of a dialogue
Three scenarios are provided to TC-users to end a dialogue:
 prearranged end
In this scenario, TC-users have decided by prior
arrangement when to end the dialogue: the No component
can be sent or received for the dialogue once the TC-END
request primitive has been issued.
 basic end
In this scenario, the ending causes transmission of any
pending components at the side which initiates it. Note,
however, that any components for which transmission
would be pending in the reverse direction will not be
delivered.
Abort of a dialogue by a TC-user
The TC-user has the ability to request immediate
ending of a dialogue without taking into account any
pending operation invocation (abort).

An abort request by the TC-user causes all pending

operations for that dialogue to be terminated

Before the dialogue is established (i.e. before the first

TC-CONTINUE), the TC-user may also decide to
abort a dialogue
 Exception reporting and message return

The ability for TC-users to be notified of non-delivery

of components is provided by the TC-NOTICE
indication primitive.

A TC-NOTICE indication primitive is only passed to

the TC-user if the requested service cannot be
provided
TC-NOTICE primitive
Message layout
Transaction portion
Dialogue portion
Component portion
Transaction portion
message length
Total TCAP message length
Transaction id identifier
Transaction id length
Transaction id(optional)
Dialogue portion

Dialogue portion identifier

Dialogue portion length
Dialogue portion
Component portion
Component sequence identifier
Component sequence length
Component type identifier
Component length
Component id identifier
Component id
Component id length
Operation code
Example of transaction scenario
THANK YOU