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

The Invoke and Return Result component types are used for carrying out the normal operations between TCAP users.. The contents of the Invoke and Return Result components include the foll

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