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  . "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. 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. 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