Signaling System No.7 Protocol Architecture And Sevices part 35 pdf

Components
Components are a means of invoking an operation at a remote node. A TCAP
message can contain several components, thereby invoking several operations
simultaneously. The TCAP component is based on the ITU X.410 specification for
Remote Operations in Message Handling Systems. ITU X.229 has replaced this
specification. The specification defines the following four Operational Protocol
Data Units (OPDUs):
• 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
Each of the TCAP component types directly correlates to one of the previous
OPDU types. The Invoke and Return Result component types are used for carrying
out the normal operations between TCAP users. The Return Error and Reject
component types are used for handling error conditions.
The contents of the Invoke and Return Result components include the following
information:
• Component Type
• Component ID
• Operation Code (Invoke Component only)
• Parameters
The contents of the Return Error and Reject components are similar to the Invoke
and Return Result components, except that the Operation Code used in an Invoke
component is replaced by an Error/Problem code. The following sections discuss
the contents of the components listed previously. The "Error Handling
" section
later in this chapter addresses the Return Error and Reject components.
Invoke and Return Result Components
Under normal circumstances, Invoke and Return Result Components are sent to

carry out and verify operations between two communicating entities. For example,
an SSP might "invoke" a number translation at an SCP, resulting in a new number
being returned. A number of services, such as Toll-free, Premium Rate, and Local
Number Portability, use TCAP to look up numbers in this manner. The application
layer for these services and others use a standardized set of operations that is
recognized by the network nodes involved in the communication. The information
from the application layer is passed to the TCAP layer and encoded into
components. Each Invoke Component is generally structured as an "instruction"
and "data." The instructions are in the form of Operation Codes, which represent
the operations that are being requested. The data is in the form of Parameters.
ITU Q.771 defines four classes of operations that determine how to handle Invoke
replies. The TCAP message does not explicitly contain operation class
information. Instead, it specifies the operation class using primitives between the
application (TC-User) and the component sublayer.
NOTE
As used in this context, a primitive is a software indication that is used to pass
information between software layers.

In other words, the indication of whether a reply is required and the tracking of
whether that reply has been received are performed within the software. The main
point is that operations can be handled differently, depending on the application
logic. The four classes of operations are:
• Class 1— 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.
The application logic is also responsible for determining whether an operation is a
success or a failure. Based on the operation's results, a reply might be required. If a
reply is required, one of the following components is sent:
• Return Result— Indicates a successfully invoked operation

• Return Error— Indicates a problem
• Reject— Indicates an inability to carry out an operation
Here we focus only on the Return Result component; the "Error Handling" section
discusses the Return Error and Reject components. The following are the two types
of Return Result components:
• Return Result Last
• Return Result Not Last
The Return Result Last indicates that an operation's final result has been returned.
The Return Result Not Last indicates that further results will be returned. This
allows the result to be segmented across multiple components.
ANSI TCAP also allows the use of an Invoke to acknowledge a previous Invoke.
Because ANSI allows an Invoke to be used in response to another Invoke where a
Return Result would otherwise be used, the Invoke also has two types: Invoke Last
and Invoke Not Last. There is only a single Invoke type in ITU networks, and it is
the equivalent of the ANSI Invoke Last component type.
The details of segmenting results using the "Not Last" designation for both the
Return Result and Invoke (ANSI Only) component types are more easily
understood after a discussion of component IDs. We revisit this topic in a later
section, after introducing correlation and linked-component IDs.
Component IDs
As mentioned previously, a message can contain several components. Each Invoke
Component is coded with a numeric Invoke ID, which must be unique for each
operation in progress because the ID is used to correlate the exchange of
components for a particular operation. Just as a message can have several
components, an operation can also have several parameters associated with it.
Figure 10-8
shows an example of how Component IDs are used in an ANSI
network message exchange. Node A sends a message to Node B that contains two
Invoke Components indicating that two remote operations are being requested.
Node B processes the incoming components, carries out the requested operations,

and sends an Invoke Component and a Return Result Component back to Node A.
The Invoke component contains two IDs: an Invoke ID and a Correlation ID
(linked ID in ITU-T networks). As shown in this example, an Invoke ID can be
used to respond to another Invoke ID, rather than using a Return Result. Node B is
requesting an operation from Node A using Invoke ID 2 in response to the
previously received Invoke, reflecting ID 1 in the Correlation ID. The Return
Result Component in the message contains a Correlation ID of 0 to reflect the
previous Invoke with a Component ID of 0 from Node A. Node A then replies to
the Invoke ID 2 with a Return Result and also invokes another operation using
Invoke ID 3 in the same Conversation message. Finally, Node B answers with a
Return Result Not Last Component for Invoke ID 3, followed by a Return Result
Last for the same Component ID. This completes the component exchange
between the communicating nodes. Notice that for each Invoke, a reply was
received using either another Invoke with a "Reflecting" ID (the correlation or
linked ID) or a Return Result (Last) Component. The Correlation ID shown in the
figure is used as the "Reflecting" ID in ANSI networks; for ITU networks, the
Linked ID serves as the "Reflecting" ID.
Figure 10-8. Component ID Association (ANSI Protocol)


Operation Codes
The Operation Code identifies the operation to be invoked at the node that receives
the message. Operation Codes are context-dependent, meaning that they are
understood only within the context of a particular service. For example, consider a
caller who dials a toll-free number that is not supported in the region from which
the caller is dialing. The SCP sends an Operation Code to the SSP for "Play an
Announcement," instructing it to connect the subscriber to an announcement
machine. The component that contains the "Play Announcement" Operation Code
contains a parameter for identifying the proper announcement to be played. In this
case, the caller hears an announcement that is similar to "The number you have

dialed is not supported in your area."
ANSI defines a number of national Operation Codes in the ANSI TCAP
specifications. In ITU networks, these definitions are typically relegated to layers
above the TCAP protocol, such as INAP. Examples of these can be found in
Chapter 11
.
Parameters
Components can have parameters associated with them. The parameters are the
data that is necessary to carry out the operation requested by the component
Operation Code. For example, a component containing a "Play Announcement"
Operation Code also contains an announcement parameter. The announcement
parameter typically provides the announcement ID so the correct recording is
played to the listener. Just as a TCAP message can contain multiple components, a
component can contain multiple parameters.
The ITU-T does not define any specific parameters. This responsibility is relegated
to national or regional standards bodies, such as ANSI and ETSI. Parameters can
be defined as part of the TCAP standards (for example, ANSI standards) or
relegated to the definition of the protocol layers above TCAP, such as INAP (for
example, ETSI standards). ANSI defines a number of national parameters in the
ANSI T1.114 specification. Application processes can use these parameters
directly.
Chapter 11
, "Intelligent Networks" provides examples of TCAP parameters that
are defined by protocols above the TCAP layer. The AIN and INAP parameters
described here are used in TCAP messages for ANSI and ITU-T networks,
respectively.
ANSI parameters are specified either as part of a set or a sequence. A parameter set
is used when parameters are delivered with no particular order and can be
processed in any order.
A parameter sequence specifies that the parameters should be processed in the

order in which they are received.
ITU-T does not use parameter sequencing, so there is no designation of set or
sequence. Parameters are handled in the same manner as an ANSI parameter set,
with delivery occurring in no particular order.
ITU Parameters
Figure 10-9
shows a component with multiple ITU parameters.
Figure 10-9. Component with Multiple ITU Parameters

