1、 AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-1000114.2004(R2014) Signalling System Number 7 (SS7) Transaction Capabilities Application Part (TCAP) As a leading technology and solutions development organization, ATIS brings together the top global ICT companies to advance the industrys mos
2、t-pressing business priorities. Through ATIS committees and forums, nearly 200 companies address cloud services, device solutions, emergency services, M2M communications, cyber security, ehealth, network evolution, quality of service, billing support, operations, and more. These priorities follow a
3、fast-track development lifecycle from design and innovation through solutions that include standards, specifications, requirements, business use cases, software toolkits, and interoperability testing. ATIS is accredited by the American National Standards Institute (ANSI). ATIS is the North American
4、Organizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of oneM2M, a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications sectors, and a member of the Inter-American Telecommunication Commission (CITEL)
5、. For more information, visit. AMERICAN NATIONAL STANDARD Approval of an American National Standard requires review by ANSI that the requirements for due process, consensus, and other criteria for approval have been met by the standards developer. Consensus is established when, in the judgment of th
6、e ANSI Board of Standards Review, substantial agreement has been reached by directly and materially affected interests. Substantial agreement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and that a concerted ef
7、fort be made towards their resolution. The use of American National Standards is completely voluntary; their existence does not in any respect preclude anyone, whether he has approved the standards or not, from manufacturing, marketing, purchasing, or using products, processes, or procedures not con
8、forming to the standards. The American National Standards Institute does not develop standards and will in no circumstances give an interpretation of any American National Standard. Moreover, no person shall have the right or authority to issue an interpretation of an American National Standard in t
9、he name of the American National Standards Institute. Requests for interpretations should be addressed to the secretariat or sponsor whose name appears on the title page of this standard. CAUTION NOTICE: This American National Standard may be revised or withdrawn at any time. The procedures of the A
10、merican National Standards Institute require that action be taken periodically to reaffirm, revise, or withdraw this standard. Purchasers of American National Standards may receive current information on all standards by calling or writing the American National Standards Institute. Notice of Disclai
11、mer (2) Exchanges and network service centers - e.g., databases, service control points, Operation, Administration, Maintenance and Provisioning (OAM and (3) Subscribers and network service centers (in conjunction with the subscriber access protocol - e.g., CCITT Recommendation Q.9311. Although Tran
12、saction Capabilities in a SS7 network could be considered for use between subscribers, the standardization of subscriber-to-subscriber information content is outside the scope of SS7. Furthermore, Transaction Capabilities in a SS7 network may interwork with a transaction-oriented information transfe
13、r originated in or destined for networks using other data communications protocols. Transaction Capabilities provides a set of procedures that can be used for a variety of services, thereby avoiding the inefficiency of creating specific procedures tailored to a particular need. Thus, Transaction Cap
14、abilities provides a framework for a common approach to new services within a network as well as a framework for service architecture for cooperative internetwork services. 1T1.607 corresponds to CCITT Recommendation Q.931. All CCITT (now ITU-T) Recommendations are available from the International T
15、elecommunications Union. . ATIS-1000114.2004 Chapter T1.114.1 T1.114.1-2 1.4 Scope of the Specification of Transaction Capabilities This specification is intended to provide, in an open-ended manner, the capabilities needed to support present and near-term ISDN and non-ISDN services requiring transa
16、ctions among exchanges, service control points, and databases. Extension to other cases should be straightforward within the framework of Transaction Capabilities. This specification addresses TC procedures relying on a connectionless network service. The specification itself is general in nature. S
17、ome internetwork services are seen to have sufficient interest across multiple networks that common agreements as to how they will operate across network boundaries are seen as desirable. 2 ARCHITECTURAL CONCEPTS AND TERMINOLOGY 2.1 Application of OSI Reference Model The layered reference model is r
18、ecognized as a useful tool in developing protocol specifications. From an end user point of view, Transaction Capabilities for initially planned services lie within the Network layer of the OSI model. For example, from the point of view of an exchange querying a database, the exchange and the databa
19、se may also be seen as “end users“. The nature of anticipated services to be supported suggests that the protocol may require the equivalent of many of the functions provided in OSI layers 6, 5, and 4, called the Application Service Part (ASP) in SS7. The ASP consists of Presentation, Session, and T
20、ransport layers. Hence there should be advantages in adopting these concepts to a protocol for network transactions. Processes providing a transaction-oriented service may appear at more than one signalling point. The architecture shall be able to support global addressing of a transaction service a
21、nd provide the functions needed to route signals to the appropriate points. The architecture shall also provide management functions to handle congestion and failure of transaction processes. Figure 1/T1.114.1 illustrates two ways in which the architecture of Transaction Capabilities may be modeled.
22、 Part (a) of Figure 1/T1.114.1 shows separate ASP entities for each process supported. Part (b) of Figure 1/T1.114.1 shows a common TCAP and ASP supporting more than one transaction process. 2.2 Considerations 2.2.1 Addressing of Upper Layer Entities The model uses the subsystem number (SSN) at the
23、SCCP layer to identify the particular Application Process. This allows the SCCP global title translation functions to be used to support global addressing of transaction services, in addition to point code and subsystem number addressing. 2.2.2 Management of Upper Layer Entities Use of SSNs allows t
24、he SCCP management procedures to be used to handle independently failing or congesting Application Processes. ATIS-1000114.2004 Chapter T1.114.1 T1.114.1-3 2.2.3 Layered vs. Nonlayered Some transaction-oriented services may not require any functions of the ASP. This suggests that a nonlayered approa
25、ch may be preferable. However, as new transaction-oriented services are defined, a nonlayered approach may complicate the protocol design. As well, with a nonlayered approach, the benefits of commonality with other protocols could be lost. Transaction Capabilities have therefore been specified so as
26、 to allow inclusion of ASP functions readily when required. Since not all defined Presentation, Session, and Transport functions are likely to be required at any one node in the network, it is not necessary to provide all the possible ASP functions at every node. Suitable classes, options, and funct
27、ional units should be selected for each node as the needs of that node dictate. These can be expanded as required. 2.2.4 Architecture Model vs. Implementation From the OSI point of view, a particular process has its own Application, Presentation, Session, and Transport layers. This is illustrated in
28、 part (a) of Figure 1/T1.114.1. Each “stack“ is independent of the other “stacks“. This concept is applied to the Transaction Capabilities protocol. Note that there is an implicit agreement to use the MTP and SCCP as common elements in this structure. Within any particular implementation, it is poss
29、ible to implement each block shown independently or to combine blocks vertically or horizontally or both where desired. Thus part (b) of Figure 1/T1.114.1 may represent an example of an implementation in which all the blocks are combined horizontally, while retaining the protocol model of part (a) o
30、f Figure 1/T1.114.1. As stated in 1.3, the approach is not intended to constrain any implementation of a service, whether it be intranetwork or internetwork. 3 OVERVIEW OF TC FUNCTIONS AND PROCEDURES 3.1 Framework for Transaction Capabilities Protocol The initial Transaction Capabilities protocol, c
31、onsisting of TCAP and the ASP, is based on the following CCITT Red Book Recommendations: Application: X.409, X.410 Presentation: X.409, X.410 Session: X.225 Transport: X.224 3.2 Discussion 3.2.1 Application Section 2 (Remote Operations) of CCITT Recommendation X.410-1984, Message Handling Systems: R
32、emote Operations and Reliable Transfer Server, provides the basis for TCAP for foreseen services. It provides four Operation Protocol Data Units (OPDUs): ATIS-1000114.2004 Chapter T1.114.1 T1.114.1-4 Invoke: Invoke ID, Correlation ID,2Operation, Argument Return Result: Correlation ID,3Result Return
33、Error: Correlation ID,3 Error, Parameter Reject: Correlation ID,3)Problem, Parameter4)The Invoke OPDU requests that an operation be performed. The Return Result OPDU reports the successful completion of an operation. The Return Error OPDU reports the unsuccessful completion of an operation. The Reje
34、ct OPDU reports the receipt and rejection of an incorrect OPDU. These OPDUs may be viewed as tools for constructing a Transaction Capabilities Application Protocol. An OPDU as extended for TCAP is referred to as a Component. Zero, one, or more Components are carried in a TCAP message. The interpreta
35、tion of the operations, parameters, and errors carried in a component is determined by the Application Context. The Dialogue Portion of TCAP may identify the version of T1.114 and the Application Context used during an interaction between two peer applications. The Dialogue Portion of TCAP also may
36、contain Security information. 3.2.2. Presentation The purpose of the Presentation layer is to provide functions to negotiate and select a transfer syntax and carry-out transfer syntax transformations. These capabilities are not required for presently envisaged services. 3.2.3 Session Services to be
37、supported using Transaction Capabilities are not expected to require any Session layer services. Hence, TC may operate in a connectionless mode in this case. 3.2.4 Transport Transport Class 0 service (simple, i.e., no enhancements to the service provided by the Network Layer) may be appropriate sinc
38、e, for many transaction-oriented services, the SS7 network layer (provided by the MTP and SCCP) will provide a sufficiently high degree of reliability. 3.3 Identifying Services Required of Each Layer Figure 2/T1.114.1 illustrates the general concept of how services of the various layers are activate
39、d. As a message passes down through the layers, each layer places a header - and possibly a trailer - on it 2In TCAP, Remote Operations, as described in CCITT Recommendation X.410-1984, has been extended to include an optional ID to allow correlation of Invoke OPDUs to other Invoke OPDUs. 3Section 2
40、 of CCITT Recommendation X.410-1984 calls this ID the Invoke ID; it is being understood that it is the reflection of the Invoke ID appearing in the Invoke OPDU. For TCAP, it is renamed Correlation ID for the OPDUs noted. 4In TCAP, Remote Operations, as described in CCITT Recommendation X.410-1984, h
41、as been extended to include a mandatory parameter for the Reject OPDU. ATIS-1000114.2004 Chapter T1.114.1 T1.114.1-5 that is specific to the functions that layer performs. These functions may be grouped into classes or functional sets. The original Protocol Data Unit (PDU), plus headers of higher la
42、yers, are treated as user information and are not examined by lower layers as the message is passed down. Similarly, when a message is being passed to a higher layer, each layer strips off its header before passing the message up as user data using the appropriate primitives. Some of the information
43、 contained in the headers is preserved as parameters in the interlayer primitives - for example, the called and calling addresses. For some transaction services, some layers will be null. If a particular transaction service does not require any of the Presentation, Session, or Transport layer servic
44、es, then layer protocol headers are not required. This is the case when a connectionless mode of operation is used. 3.4 General Description of TCAP Procedures 3.4.1 Types of Transactions Transactions can be viewed at two levels: 1) Application-Process-to-Application-Process; and 2) TCAP-to-TCAP. An
45、Application Process transaction is defined by the Application Process. A TCAP transaction consists of one or more TCAP messages between two Application Processes. TCAP transactions include one-way and two-way transactions - i.e., the transaction involves communication in one direction only, or inter
46、active communication. The Application Process initiating the TCAP transaction indicates which case applies, from its point of view, at the start of the transaction. 3.4.2 Initiation of Transactions An Application Process transaction is initiated with the assignment of a Transaction ID. A TCAP transa
47、ction is initiated by sending or receiving an initiating TCAP message. 3.4.3 Termination of Transactions An Application Process transaction is terminated with the release of the Transaction ID. A TCAP transaction is terminated by either a terminating TCAP message or at the discretion of the Applicat
48、ion Processes at both ends (without an explicit message being sent) by informing their respective TCAPs. 3.4.4 Association of Application Process Transactions Application Process transactions are identified through Transaction IDs. These are carried in the TCAP message. Each Application Process invo
49、lved in the TCAP transaction may assign Transaction IDs in any manner convenient to it. 3.4.5 Correlation of Components Within a single transaction, one or more operations may take place. For each operation, one or more Components may be involved. Return Result, Return Error, and Reject Components are correlated with Invoke Components through a Correlation ID that is set equal to the Invoke ID appearing in the Invoke Component (see 3.2.1). In the case where an Invoke Component must refer to another Invoke Component, it also contains a
