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