ImageVerifierCode 换一换
格式:PDF , 页数:142 ,大小:756.74KB ,
资源ID:433551      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-433551.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(ANSI ATIS 1000114-2004 Signalling System Number 7 (SS7) C Transaction Capabilities Application Part (TCAP) (Formerly ATIS T1.114).pdf)为本站会员(terrorscript155)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

ANSI ATIS 1000114-2004 Signalling System Number 7 (SS7) C Transaction Capabilities Application Part (TCAP) (Formerly ATIS T1.114).pdf

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

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1