Nội dung

Signaling in Telecommunication Networks. John G. van Bosse Copyright  1998 John Wiley & Sons, Inc. ISBNs: 0-471-57377-9 (Hardback); 0-471-22415-4 (Electronic) 15 TRANSACTION CAPABILITIES APPLICATION PART 15.1 INTRODUCTION The transaction capabilities application part (TCAP) of signaling system No.7, in conjunction with the signaling control connection part (SCCP) and the message transfer part (MTP) [l-3], enables application service elements (ASE) at two nodes (the TCAP term for signaling points) to conduct transact ions. TCAP is similar in many respects to the protocols defined by CCITT/ITU-T for data communication networks, which are documented in X-series recommendations. The first CCITT Recommendations on TCAP were published in 1989 [4], and have been revised in 1993 by ITU-T [5-91. The U.S. version of TCAP has been specified by ANSI [lo]. The work on this version started before the publication of the initial CCITT recommendations. As a consequence, there are pronounced differences in terminology, and some differences in coding, between the two versions. Sections 15.1-15.4 of this chapter follow the CCITI’ version. Section 15.5 describes the main differences of the U.S. version. 15.1 .l Transactions and Remote Operations During a transaction, one (usually) or more (rarely) remote operations are executed. The operation is requested by an ASE at one node, and executed by an ASE at another node. Transaction ASEs are application-specific, and involve “peer” ASEs (dedicated to the same application) at the two nodes. 417 418 TRANSACTION CAPABILITIES APPLICATION PART Some remote operations provide information to the requesting ASE. For example, in the “800 number calling” application, an ASE at an exchange requests its peer to translate an 800 number into a routing number. Other remote operations provide instructions to the requesting ASE. In the chapters that follow, we shall encounter operations of both types. 15.1.2 Components and Messages Fig. 15.1-1 shows the SS7 entities involved in a transaction between ASE-1 and ASE-2. The physical message path traverses the TCAPs, SCCPs, and MTPs at the nodes, and a path in the signaling network, which transfers the message signal units (MSU) between the nodes. This section describes transactions at the component and the messagelevel. A component is a communication between ASEs. It can contain a requested operation, or the results of the operation. A message (containing one or more components) is the unit of communication between two TCAPs-see Fig.Kl-2. 15.1.3 TCAP Interfaces In the CCITT/ITU-T model of TCAP [4,8], TC-primitives are the interface between ASE and TCAP in a node, and N-unitdata primitives are the interface between TCAP and SCCP [4,9]. To send a message, an ASE passes a series of TC-requests to the TCAP at its node, and TCAP passes the message to its SCCP, in a N-unitdata request. When a TCAP receives a message from its SCCP, it passes the contents to the destination ASE in its node, with a series of TC-indications. Node B Node A 1 ASE-1 b --w-----B-Components TC-Primitives TC-Primitives TCAP-A 4 TCAP Messages -t TCAP-B N-Primitives N-Primitives SCCP-B SCCP-A MTP-Primitives MTP-Primitives I e-- MTP-A MSUs Physical -) Logical Message Message Figure 15.1-I Path Paths Messages and message paths. ) Components Portion Figure 15.1-2 15.1.4 TCAP TCAP message. Messages As shown in Fig. 15.1-2, a TCAP message consists of a TCAPportion, which is processed by TCAP, and a components portion with one or more components, which is passed transparently. There are several TCAP message types. They represent the status of the transaction, as perceived by the sending ASE and TCAP. transfer. The Unidirectional. This is a message for one-way information sender does not expect a response, and the message does not initiate a transaction. Begin. This message initiates a transaction. Continue. This message is sent in response of a begin or continue message, and continues the transaction. End. This message is sent terminates the transaction. response to a begin or continue message, This message is sent when a fatal problem has been encountered during the transaction, and terminates the transaction. An abort message can originate at an ASE or a TCAP. The other messages always originate at an ASE. Abort. 15.1.5 Components CCITT/ITU-T has specified the following components: Invoke. This component specifies the requested operation. A Begin message always includes one (or more) invokes. Continue and End messages sometimes include invokes. TRANSACTION CAPABILITIES APPLICATION PART Return Result, Last (RR-L). This component is a final response to an invoke. It contains the information obtained in a successful operation. Return Result, Not Last (RR-A/L). This component is a non-final response to an invoke, and contains a part of the information generated by the operation. This component is necessary because the maximum length of a message signal unit (MSU) is 272 octets. Since the MSU contains the component, and information for TCAP, SCCP, and MTP, the maximum length of a component is about 240 octets. Most operations yield information that fits within one component. If the information is too voluminous, it is segmented, and carried in one or more RR-NL components, and a final RR-L component. Return Error. This component is a final response to an invoke, and indicates that the requested operation was executed, and has failed. Reject. This component is a final response to a received component. It indicates that the component cannot be processed, because its syntax is not correct. 15.1.6 Application-independence TCAP serves all (application-specific) ASEs in a node. TCAP messages are specified in an application-independent manner [4-8 and lo]. TCAP specifies the structure (syntax) of components, but does not cover their information content. We shall discuss the contents of components in the TCAP application examples of Chapters 16 and 17. 15.1.7 TCAP Message Sequences Figure 15.1-3 shows examples of TCAP message sequences in transactions that involve ASE-1 and ASE-2. The transactions are initiated by ASE-1, which sends a Begin message with an invoke 1. The vast majority of transactions require just two messages (Begin and End)-see cases (a) and (b). In case (a), the invoked operation results in information, which is conveyed in an End message with a RR-L component. In case (b), the operation results in an instruction, which is conveyed in an End message with invoke 2. In case (c), ASE-2 needs more information from ASE-1 before it can execute invoke 1. It therefore returns a Continue message, whose invoke 2 requests the information. After executing the invoke, ASE-1 sends a Continue message, in which RR-L 1 holds the requested information. ASE-1 now executes invoke 1, and returns a RR-L or an invoke in an End message. Figure 15.1-4 shows a chain of two transactions, involving three ASEs. ASE2 cannot execute invoke 1 without information from ASE-3. It therefore TCAP INFORMATION ELEMENTS 421 Node B Node A BEGIN [Invoke l] 0a END [RR-Last] BEGIN [Invoke END [Invoke BEGIN l] @I 21 [Invoke l] CONTINUE [Invoke 21 CONTINUE [RR-Last l] END [RR-Last Figure 15.1-3 2 or Invoke 0C 31 Transaction examples. Node B Node A Node C E ASE-3 TCAP-C BEGIN [Invoke l] w BEGIN N END [RR-Last [Invoke END [RR-Last 21 w l] 21 1 Figure 15.1-4 Chain transaction. initiates a transaction with ASE-3, sending invoke 2. ASE-3 executes invoke 2, obtains a result, and includes it in the RR-last 1 of its End message. ASE-2 then executes invoke 1, and sends an End message with the result in RR-last 2. 15.2 TCAP INFORMATION ELEMENTS TCAP messages consist of a number of mandatory (M) and/or optional (0) information elements (IE). We shall see that the term parameter is used also, but has a restricted meaning. This section describes the TCAP information elements [7]. Each IE has a reference number (IE.1, etc). These numbers are used in the sections that follow. 422 TRANSACTION Table 15.2-l CAPABILITIES Information APPLICATION PART elements in TCAP portion of message. Message Information Element IE.l IE.2 IE.3 IE.4 IE.5 IE.6 IF.7 IE.8 IE.9 IE.10 Type Unidirectional Begin Continue End Abort Originating-TID Destination-TID P-Abort-Cause U-Abort-Information Component-Portion C C C C C P P P C C CONT: Continue. UNIDIR: Unidirectional. Primitive. Source: Rec. Q.773. Courtesy of ITU-T. 15.2.1 Information Elements U N I D I R B E G I N C 0 N T E N D A B 0 R T M M M M M M M TID: Transaction-ID in the Transaction M M M M M M M 0 0 0 (identity). C: Constructor. P: Portion Table 15.2-1 lists the IEs in the transaction portion of TCAP messages. IE.l through IE.5 represent the individual message types. The TCAP at a node has a pool of transaction-identities (TID), which are reference numbers that identify individual transactions at the node. When a transaction is initiated, a TID is allocated. When the transaction ends, the TID is returned to the pool. IE.6 Originating-T/D (OTID). In Begin and Continue messages, OTID specifies the TID of the transaction at the originating (sending) node. IE7 Destination-T/D (DUD). In Continue and End messages, DTID the transaction at the destination (receiving) node. IE.8 P-Abort-Cause. This IE appears in Abort messages originated and indicates why TCAP has aborted the transaction. specifies by TCAP, IE.9 U-Abort-information. Appears in Abort messages originated by an ASE, and indicates why the ASE has aborted the transaction. This IE separates the transaction and component IE. 7 0 Component-Portion. portions of a TCAP message. All messages except Abort messages have a component portion. TCAP Table 15.2-2 INFORMATION 423 ELEMENTS Information elements in components. Component I N V R E T R S L 0 K E Information Element IE.ll IE.12 IE.13 IE.14 IE.15 IE.16 IE.17 IE.18 IE.19 IE.20 IE.21 IE.22 IE.23 IE.24 IE.25 IE.26 TYPe Invoke C Return-Result-Last C Return-Result-Not-Last C Return-Error C Reject C Invoke-ID P Linked-ID P Operation-Code P Error-Code P P General-Problem Invoke-Problem P Return-Result-Problem P Return-Error-Problem P Parameter-Sequence C Parameter-Set C P Parameter R E T R S N L RR E T E RC R E J E T M M M M M M M M M M M M M @ @ 0 @I @ 0 @ e 0 @ @ 0 # # # # @ @ 0 RETRSL: Return-Result-Last (RR-L). RETRSNL: Return-Result-Not-Last (RR-NL). RETERR: Return-Error. C: Constructor. P: Primitive. #: One of the IEs is mandatory in reject components. @: One of the IEs is mandatory if the component includes more than one parameter. Source: Rec. Q.713. Courtesy of ITU-T. 15.2.2 Information Elements in Components The mandatory (M) and optional (0) IEs in the various components are listed in Table 15.2-2. Elements IE.ll through IE.15 represent the component types. IE. 76 Invoke-D. This IE is mandatory in all component types. In invoke components, it is a reference number that identifies an invoke in a transaction. A return-result, return-error, and reject component is a response to a received invoke, and has the IE.16 value of that invoke. IE. 7 7 Linked-ID. This IE is mandatory in an invoke component that is sent as the response to a received invoke. In this case, IE.16 identifies the sent invoke, and IE.17 identifies the received invoke. IE. 78 Operation-Code. This is a mandatory specifies the requested operation. IE in invoke components, and TRANSACTION CAPABILITIES APPLICATION PART IE.79 Error-Code. This IE is mandatory in return-error indicates why a requested operation has failed. IE.20 General-Problem. be processed. This IE indicates that a received component IE.27 Invoke-Problem. processed. This IE indicates IE.23 Return-Error-Problem. cannot be processed. cannot that a received return- This IE indicates that a received return-error has to include IE.20, or IE.21, or IE.22, or IE.23. IE.24 Parameter-Sequence. IE.25 Parameter-Set. and This IE indicates that a received invoke cannot be HZ.22 Return-Result-Problem. result cannot be processed. A reject component components, An ordered sequence of parameters. A set (not ordered) of parameters. If a component contains more than one parameter, or IE.25. it has to include an IE.24 IE.26 Parameter. A parameter contains additional information in a component. In invoke components, parameters specify the operands for the requested operation. In return-result components, parameters hold the results of the operation. In return-error and reject components, the parameters are the information elements that respectively caused the failure of the operation, and the rejection of a received component. 15.3 TCAP FORMATS AND CODING This section describes the formats and coding of the TCAP messages defined by CCITT/ITU-T [ 71. 15.3.1 Information Elements The information elements (IE) in TCAP messages have three fields-see Fig. 15.3-1. The tag field indicates the IE type, and the length field indicates the number of octets in the value (or contents) field. A TCAP IE can be a primitive IE or a constructor IE. The value field of a primitive IE contains the information of the IE. Primitive IEs should not be confused with the primitives that pass information between the SS7 protocols in a node (Section 7.3.2). Tw/c-q TCAP - Bits - Length Value (Information of DE) (a) FORMATS AND Bits 425 CODING - Bits /I I/ ---- Value --- l (b) I I I I I Cc) Figure 15.3-l Structure of information elements. (a): primitive IE. (b) constructor IE. (From Rec. Q.773. Courtesy of IT&T.) The value field of a constructor IE holds one or more other IEs, which may be primitives or constructors. The concepts “primitive” and “constructor” have been carried over from CCITT Recommendation X.209 (data communication networks). In Tables 15.2-l and 15.2-2, the primitive and constructor IEs are marked (P) and (C). The constructor IEs, and the information in their value fields, are listed below. /E.I-/ES. The tag fields of these IEs identify a message type, and the value fields hold all other IEs in the message. The value field of this IE holds applicationIE.9 U-Abort-Information. specific IEs with information on why the ASE (TCAP user) has aborted the transaction. IE. 70 Component-Portion. components in the message. The value field of this IE holds the IEs of all IE.1 IIIF.15. The tag fields of these IEs identify a component value fields hold all other IEs of the component. type, and the IE.24 Parameter-Sequence. The value field of this IE holds all parameter IEs in the component, in a predetermined order. IE.25 Parameter-Set. The value field of this IE holds all parameter IEs in the component, in any order. As an example, Fig. 15.3-2 shows the format of a begin message with one 426 TRANSACTION IE.2 (T) ,/ IE.2 (L) / / CAPABILITIES ’ APPLICATION IE.6 (T) I IE.6 (L) / IE.6 (V) / IE.10 (T) IE.10 (L) / I PART IE. 11 (T) IE.11 (L) / / / IE.26 (T) (L) IE.26 I L IE.26 I I IE.26 I IE.26 I I ’ I I IE.11 (V) IE.2 (V) ; I (V) (T) (L) IE.26 (V) IE.26 (T) IE. 10 (V) IE.26 (L) IE.26 (V) -- -- Information elements in Begin message. IE.2: Begin message. Figure 15.3-2 transaction ID. IE.10: Components-portion. IE.11: Invoke component. IE.16: Operation code. IE.24: Parameter sequence. IE.26: Parameters. IE.6: Originating Invoke ID. IE.18: invoke. The TCAP portion consists of IE.2 (begin message), whose value field holds an IE.6 (originating-TID), and an IE.10 (component-portion). The value field of IE.10 holds an IE.ll (invoke component), whose value field holds an IE.16 (invoke-ID), an IE.18 (operation-code), and an IE.24 (parameter-sequence). Finally, the value field of IE.24 holds three 1E.26~ (parameters). 153.2 Coding of Tag Fields An IE tag field consists of one, two, or three octets, and has three fields-see Fig. 15.3-3. C/ass Field. Bits H,G of octet 1 indicate the IE class: Class Universal Aplication-wide Context-specific Private use KG 009 01 110 191 The class implies where the IE is specified. Universal IEs are specified in CCITT/ITU-T Recommendation X.409. IEs in this class are used primarily in data communication networks, and some are also used in TCAP. Applicationwide IEs are specified by CCITT/ITU-T in Recommendation [7]. They are used in all TCAP applications defined by CCITT/ITU-T. Context-specific IEs are specified within the context of the next higher constructor IE. A contextspecific tag value thus has different meanings, which depend on the class of the constructor. Private use IEs are defined by various national organizations.