ATIS 1000051-2012 TCAP Gateway Functionality.pdf

《ATIS 1000051-2012 TCAP Gateway Functionality.pdf》由会员分享，可在线阅读，更多相关《ATIS 1000051-2012 TCAP Gateway Functionality.pdf（12页珍藏版）》请在麦多课文档分享上搜索。

1、 TECHNICAL REPORT ATIS-1000051 TCAP GATEWAY FUNCTIONALITY As a leading technology and solutions development organization, ATIS brings together the top global ICT companies to advance the industrys most-pressing business priorities. Through ATIS committees and forums, nearly 200 companies address clo

2、ud services, device solutions, M2M communications, cyber security, ehealth, network evolution, quality of service, billing support, operations, and more. These priorities follow a fast-track development lifecyclefrom design and innovation through solutions that include standards, specifications, req

3、uirements, business use cases, software toolkits, and interoperability testing. ATIS is accredited by the American National Standards Institute (ANSI). ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of oneM2M, a member and majo

4、r U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications sectors, and a member of the Inter-American Telecommunication Commission (CITEL). For more information, visit . Notice of Disclaimer in the case of ISUP, a call identifier. The TCAP association is esta

5、blished at two levels: At the component level, there is a need to associate the response to the original request for performance of the TCAP operation. At the transaction level, there is a need to associate all of the TCAP messages of the conversation with each other. This may, for example, include

6、multiple requests for the performance of TCAP operations or responses to requests that invoke TCAP operations in their own right. 2 Normative References The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. At the time of publicatio

7、n, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. ATIS-1000110.1999 ATIS-1000110.1999 (R2010), Signalling S

8、ystem Number 7 (SS7) General Information.1ATIS-1000114 ATIS-1000114.2004 (R2009), Signalling System Number 7 (SS7) Transaction Capabilities Application Part (TCAP).1ATIS-1000679 ATIS-1000679.2004 (R2010), Interworking between Session Initiation Protocol (SIP) and Bearer Independent Call Control or I

9、SDN User Part.1ATIS-1000047 ATIS-1000047, Signaling System 7 (SS7) and Internet Protocol (IP) Transport Networks Signaling Interworking and Compatibility.1RFC 3868 RFC 3868, Signalling Connection Control Part User Adaptation Layer (SUA).21This document is available from the Alliance for Telecommunic

10、ations Industry Solutions (ATIS), 1200 G Street N.W., Suite 500, Washington, DC 20005. 2This document is available from the Internet Engineering Task Force (IETF). ATIS-1000051 2 3 Acronyms ACG Automatic Code Gap AS (IP) Application Server ATM Asynchronous Transfer Mode CLDT Connectionless Data Tran

11、sfer DB Database ID IdentifierIP Internet Protocol ISDN Integrated Services Digital Network ISUP (SS7) ISDN User Part MTP (SS7) Message Transfer Part NGN (IP-based) Next Generation Network SAAL Signaling ATM Adaptation Layer SCCP (SS7) Signalling Connection Control Part SIP Session Initiation Protoc

12、ol SS7 (ANSI) Signalling System 7 SUA SCCP User Adaptation TC Transaction Capabilities TCAP (SS7) Transaction Capabilities Application Part TR Technical Report 4 Scope Interworking between SS7 ISUP and IP for the purposes of call setup is described in ATIS-1000679. This Technical Report (TR) address

13、es the complementary interworking between SS7 TCAP and IP. Therefore, this TR considers the cases of: 1. An IP Application Server transaction to a circuit domain Data Base (DB), where the application information is conveyed in SS7 TCAP. 2. A circuit domain originated transaction to an IP Application

14、 Server (AS), where the application information is conveyed in the circuit domain using SS7 TCAP. The scope of this TR includes inter-domain interoperability under normal and abnormal or error situations. Inter-domain transport protocol interworking between SS7 MTP/SCCP and IP is described in ATIS-1

15、000047. 5 Architecture The SS7 protocol stack is shown in Figure 1. ATIS-1000051 3 MTP 3MTP 2 MTP 1 USERS OF SS No. 7TC USERISDN USER PART (ISDN-UP) TRANSACTIONCAPABILITIES(TC)SIGNALLING CONNECTIONCONTROL PART(SCCP)SAAL/ATM Figure 1 - Architecture of SS7 As detailed in ATIS-1000114, the Transaction

16、Capabilities Application Part is further decomposed into three Portions: 1. The Transaction Portion identifies the ”type” of Remote Operations conversation (or Transaction) and supplies the identifiers that correlate successive messages within the conversation with each other. ANSI TCAP supports sev

17、en Package Types: a. Unidirectional. A message with this Package Type sends information in one direction only with no reply expected. No TCAP Transaction is established. b. Query With Permission. A message with this Package Type initiates a TCAP transaction and informs the destination node (i.e., th

18、e node that receives the message) that it may end the TCAP transaction. c. Query Without Permission. A message with this Package Type initiates a TCAP transaction and informs the destination node that it may not end the TCAP transaction. d. Response. A message with this Package Type ends the TCAP tr

19、ansaction. e. Conversation With Permission. A message with this Package Type is the continuation of a TCAP transaction and informs the destination node that it may end the TCAP transaction. f. Conversation Without Permission. A message with this Package Type is the continuation of a TCAP transaction

20、 and informs the destination node that it may not end the TCAP transaction. ATIS-1000051 4 g. Abort. A message with this Package Type informs the destination node that the sending node has terminated an established TCAP transaction without sending any pending components that may be expected due to a

21、 prior message. Note that, in practice, either side of the Transaction may terminate the Transaction at any time. The concept of “With Permission” and “Without Permission” is purely advisory and application processing of a Query or Conversation “With Permission” is the same as processing of the same

22、 message “Without Permission.” 2. The optional Dialogue Portion may include information that: a. Identifies the version of SS7 being used. b. Provides an Application Context in which the Component Portion may be interpreted. c. Contains User Information e.g., to refine the Application Context. d. Pr

23、ovides a Security Context in which the Confidentiality Information that follows may be interpreted. e. Contains Confidentiality Information that identifies the confidentiality algorithm to be used and provides any additional required information related to the algorithm. 3. The Component Portion car

24、ries the Remote Operation(s) Operation Protocol Data Units (Components) that reflect application activities. ANSI TCAP supports six Component Types: a. Invoke (Last). This is used to invoke an operation (such as requesting a database to perform digit translation). When the Invoke Component contains

25、a Correlation ID, “Last“ indicates no further responding Components. When the Invoke Component does not contain a Correlation ID, it is always coded “Last“. b. Return Result (Last). This is used to return the results of an invoked operation. “Last“ indicates that no further responding Components are

26、 expected. c. Return Error. This reports the unsuccessful completion of an invoked operation. d. Reject. This reports the receipt and rejection of an incorrect Package or Component other than another Reject Component. e. Invoke (Not Last). This is similar to the Invoke described in Item (1), except

27、that further responding Components are expected. f. Return Result (Not Last). This is similar to the Return Result described in Item (2), except that further responding Components are expected. An example of the exchange of multiple Components within one TCAP Transaction is shown in Figure 2. ATIS-1

28、000051 5 Query With Permission (Originating Transaction ID = A)Invoke (Not Last) InvokeID=X1Invoke (Not Last) InvokeID=X2Invoke (Not Last) InvokeID=nullConversation With Permission (Originating Transaction ID=B, Terminating Transaction ID=A)Invoke (Not Last) InvokeID=Y1, CorrelationID=X1Conversation

29、 With Permission (Originating Transaction ID=B, Terminating Transaction ID=A)Return Result (Last) InvokeID=Y2, CorrelationID=X2Invoke (Last) InvokeID=Y1, CorrelationID=X1Response (Originating Transaction ID=A, Terminating Transaction ID=B)Return Result (Last) CorrelationID=X1Figure 2 - Example of th

30、e Exchange of Multiple Components Within One TCAP Transaction 1. Side A sends a single TCAP message (identified at Side A by the Transaction Identifier A) invoking three operations at Side B: a. The operations with the Component identifiers X1 and X2 anticipate responses from Side B. The operation w

31、ith no Component identifier (InvokeID=null) does not anticipate a response from Side B. 2. Side B completes the operation with no Component identifier. No indication is returned to Side A. Side B completes a portion of the operation X1 and returns a partial reply (therefore, using an Invoke, Not Las

32、t), adding its identifier (Y1) to the Component so that any reply from Side A may be correlated appropriately at Side B. This message flow does not include such a reply. 3. Side B completes operation X2 and sends the full reply in a Return Result (Last). Side B closes its state machine for operation

33、 X2 and therefore does not include a Component Identifier from its perspective. At the same time, application processing at Side B of operation X1 calls for involves invoking an additional action from Side A. Therefore, the message from Side B includes an Invoke (Last) (to indicate completion of ope

34、ration X1) with Component Identifier X1 (which Side A will use to idle the state machine for the operation X1) and Component Identifier Y1 (which Side A will use to start a new state machine for this operation.) 4. Side A completes operation Y1 and sends the reply in a Return Result (Last). Through

35、this process, the Transaction Portion Identifiers (A from the perspective of Side A, and B from the perspective of Side B) correlate all of these messages with each other. ATIS-1000051 6 5.1 SS7 TCAP to IP Interworking Considerations SS7 TCAP may be effectively ”encapsulated” and sent to an IP desti

36、nation using SUA RFC 38683. In this case, the Common Header is encoded as follows: The SUA Protocol Version will be 1 (SUA version 1.0). The Message Class will be 7 (Connectionless Messages). The Message Type will be1 Connectionless Data Transfer (CLDT) . The parameters of a CLDT message are encoded

37、 following the guidance in Technical Requirements for SS7 and IP Transport Network Signaling Interworking Technical Report. The Data of the CLDT message is encoded with the complete SS7 TCAP message, comprised of the Component Portion, Dialogue Portion (if received), and Transaction Portion. Routing

38、 Context Derived from SCCP Protocol Class Derived from SCCP Source Address Derived from SCCP Destination Address Derived from SCCP Sequence Control Derived from SCCP SS7 Hop Count Not used Importance Not used Message Priority Derived from MTP and SCCP Correlation ID Not used (Note 1) Segmentation No

39、t used (Note 2) Data Complete SS7 TCAP message, comprised of the Component Portion, Dialogue Portion (if received), and Transaction Portion NOTE 1: This assumes the Gateway is not maintaining the Transaction state. If the Gateway does maintain a Transaction state, this could be populated and the Dat

40、a Portion could be comprised of the Component Portion only. If an SS7 TCAP Conversation or Response message includes a Component with an operation of Automatic Code Gap (ACG) Indicators, the Component will be passed to the destination application in the IP-based Next Generation Network (NGN). Since

41、the ACG is an endpoint-to-endpoint control, this results in the expected congestion mitigation activity in both networks. Since the destination application will act on the ACG (limiting its rate of sending messages toward the sender of the ACG), it is desirable that the Gateway not apply its own cod

42、e gap procedures, even if the Gateway is maintaining the Transaction state. An exception to this rule would apply if the Gateway were to also maintain the status of individual congested SS7 signaling end points, applying the code gap procedures to IP-based messages destined for a congested SS7 signa

43、ling end point, and not mapping received SS7 ACG operations into IP-based signaling. That is, the code gap procedure should be applied only at the Gateway and further congestion controls should not be invoked in the NGN. 33Various mappings of SS7 TCAP messages to IP messages (e.g., SIP INVITE and re

44、lated response headers) may be envisioned. Such mechanisms are simplified if it is known that each TCAP Transaction consists of: a) a single Unidirectional message; or b) a single Query with only one Invoke component, where the invoked operation generates a single Response with one Return Result com

45、ponent. Without such simplifications, the SS7-IP mapping may require maintenance of Transaction and Component level state machines at the Gateway. ATIS-1000051 7 NOTE 2: Segmentation is not used, based on the assumption that the Gateway will reassemble a segmented TCAP message that is received and w

46、ill provide the complete TCAP message in the Data of the CLDT message. Therefore, the Gateway must also support the capability of sending a segmented TCAP message into the SS7 network if the received CLDT contains a long TCAP message in its Data. 5.2 IP to SS7 TCAP Interworking Considerations As not

47、ed in section 5.1, SS7 TCAP may be effectively encapsulated 4. In this case, the Data portion of the CLDT message may be extracted and forwarded to the appropriate SS7 destination. If the encapsulated SS7 TCAP Conversation or Response message includes a Component with an operation of Automatic Code

48、Gap (ACG) Indicators, the Component will be passed to the SS7 destination application. Since the ACG is an endpoint-to-endpoint control, this results in the expected congestion mitigation activity in both networks. The Gateway should not apply its own code gap control, even if it is maintaining the

49、Transaction state. If: a) The Gateway is maintaining the Transaction state, and b) The IP side is not including ACG Indicators operations in its messaging, or the Gateway is removing received ACG Indicators operations from the received Data portion, then it may be desirable for the Gateway to incorporate a Component with an ACG Indicators operation into SS7 TCAP messages from an IP-based node experiencing congestion. The mechanism by which the Gate