ITU-T Q 775-1997 Guidelines for Using Transaction Capabilities - Series Q Switching and Signalling Specifications of Signalling System No 7 - Transaction Capabilities Application P.pdf

《ITU-T Q 775-1997 Guidelines for Using Transaction Capabilities - Series Q Switching and Signalling Specifications of Signalling System No 7 - Transaction Capabilities Application P.pdf》由会员分享，可在线阅读，更多相关《ITU-T Q 775-1997 Guidelines for Using Transaction Capabilities - Series Q Switching and Signalling Specifications of Signalling System No 7 - Transaction Capabilities Application P.pdf（66页珍藏版）》请在麦多课文档分享上搜索。

1、- STDSITU-T RECMN Q-775-ENGL 1777 M Li8b2571 Ob39333 bb8 m INTERNATIONAL TELECOMMUNICATION UNION ITU=T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Q.775 (06197) SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 - Transaction capabilities application part Guidelines for

2、 using transaction capabilities ITU-T Recommendation Q.775 (Previously CCllT Recommendation) COPYRIGHT International Telecommunications Union/ITU TelecommunicationsLicensed by Information Handling ServicesITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING II SIGNALLING IN THE INTERNATIONAL MANU

3、AL SERVICE INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS SPECIFICATIONS OF SIGNALLING SYSTEMS No. 4 AND No. 5 SPECIFICATIONS OF SIGNALLING SYSTEM No. 6 SPECIFICATIONS OF SIGNALLING SYSTEM RI SP

4、ECIFICATIONS OF SIGNALLING SYSTEM R2 DIGITAL EXCHANGES INTERWORKING OF SIGNALLING SYSTEMS SPECIFICATIONS OF SIGNALLING SYSTEM No. 7 General Message transfer part (MTP) Signalling connection control part (SCCP) Telephone user part (TUP) ISDN supplementary services Data user part Signalling System No.

5、 7 management ISDN user part .Transaon,:capabilities . II, , _-_:_, :? .,_, application part Test specification Q3 interface DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 ,T; “ ,*. .,. , _i . , I, I PUBLIC LAND MOBILE NETWORK INTERWORKING WITH SATELLITE MOBILE SYSTEMS INTELLIGENT NETWORK BROADBAND ISDN

6、 Q.l-Q.3 Q.4-Q.59 Q.60-Q.99 Q.100-Q.119 Q. 120-Q.249 Q.250-Q.309 Q.310-Q.399 Q.400-Q.499 Q.500-Q.599 Q.600-Q.699 Q.700-Q.849 Q.700 Q.701-Q.709 Q.711-Q.719 Q.720-Q.729 Q.730-Q.739 Q.740-Q.749 Q.750-Q.759 Q.760-Q.769 Q.770-Q.779 Q.780-Q.799 Q.800-Q.849 Q.850-Q.999 Q. 1000-Q.l O99 Q.1100-Q.1199 Q.1200-

7、Q.1999 Q.2000-(2.2999 For further details, pIease refir to ITU-T List of Recommendations. COPYRIGHT International Telecommunications Union/ITU TelecommunicationsLicensed by Information Handling ServicesITU-T RECOMMENDATION 4.775 GUIDELINES FOR USING TRANSACTION CAPABILITIES Summary Revised Recommend

8、ation 4.775 provides guidance to TC-Users on defining TC-User ASES. Source ITU-T Recommendation 4.775 was revised by ITU-T Study Group 11 (1997-2000) and was approved under the WTSC Resolution No. 1 procedure on the 5th of June 1997. COPYRIGHT International Telecommunications Union/ITU Telecommunica

9、tionsLicensed by Information Handling ServicesFOREWORD ITU (International Telecommunication Union) is the United Nations Specialized Agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of the ITU. The ITU-T is responsible for study

10、ing technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Conference (WTSC), which meets every four years, establishes the topics for study by the ITU-T Study Gro

11、ups which, in their turn, produce Recommendations on these topics. The approval of Recommendations by the Members of the ITU-T is covered by the procedure laid down in WTSC Resolution No. l. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepare

12、d on a collaborative basis with IS0 and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. INTELLECTUAL PROPERTY RIGHTS The ITU draws attention to the possibility that the pr

13、actice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. The ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation

14、development process. As of the date of approval of this Recommendation, the ITU hadlhad not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest information a

15、nd are therefore strongly urged to consult the TSB patent database. O ITU 1997 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU. 11 Re

16、commendation Q.775 (06/97) COPYRIGHT International Telecommunications Union/ITU TelecommunicationsLicensed by Information Handling ServicesCONTENTS Page 1 Introduction 1 . 1 General . 1.2 Environment . 2 Operations . 2.1 Definition 2.2 Examples 2.2.1 Simple operation handlings . 2.2.2 More complex o

17、peration handling 2.3 Component-related facilities offered to TC-users 2.3.1 Invocation 2.3.2 Cancel (by the TC-user) 2.3.3 Reject (by the TC-user) . 2.3.4 Remote cancel (by the TC-user) 2.3.5 Reset of operation timer by the TC-user . 2.4 Component-related abnormal situations . 2.4.1 Component loss

18、. 2.4.2 Component duplication . 2.4.3 Component missequencing . 2.4.4 Reject of a component by TC 2.4.5 Operation timer expiry 3 Dialogues 3.1 Grouping of components in a message . 3.2 Dialogue handling facilities 3.2.1 Structured dialogue . 3.2.2 Unstructured dialogue . 3.3 Enhanced dialogue contro

19、l facilities . 3.3.1 Overview . 3.3.2 Use of the Application-Context . 3.3.3 Transfer of user data 3.3.4 Backward compatibility issues . 4 Guidance for writing TC-users protocol specifications 4.1 Introduction 4.2 Decomposition of functionality 4.2.1 Application process and application entity . 4.2.

20、2 Application service element Recommendation 4.775 (06/97) 1 i 1 2 2 3 3 3 5 5 6 7 8 10 11 11 12 14 15 16 16 16 18 18 27 27 27 27 28 29 30 30 30 30 30 . 111 COPYRIGHT International Telecommunications Union/ITU TelecommunicationsLicensed by Information Handling ServicesSTD-ITU-T RECMN Q-775-ENGL L797

21、 m qBb2571 Ob393L8 L4T m 4.3 4.4 4.5 4.6 4.7 4.8 5 5.1 5.2 5.3 5.4 5.5 5.6 4.2.3 Communications between peer AEs/ASEs . How to specify an application context . How to specify an ASE How to specify Operations and Errors . 4.5.1 General considerations 4.5.2 Use of the OPERATION MACRO notation . 4.5.3

22、Use of the ERROR MACRO notation 4.5.4 Use of the (information object) CLASS notation 4.5.5 The ERROR (information object) CLASS 4.5.6 Examples of Operations and Errors description 4.5.7 Moving from the MACRO notation to the (information object) CLASS notation and use of ASN . 1 modules 4.5.8 Allocat

23、ion and Management of Operation and Error Codes . Data types specifications 4.6.1 General 4.6.2 Use of tags . 4 h.3 Instances and types 4.6.4 Exporting and importing data types How to specify abstract syntaxes Encoding rules Mapping of the generic ROS concepts onto TC services . 5 . 1 . 1 Notation a

24、nd concept for the generic ROS model . Remote operation service realization . 5.2.1 Basic services (stub) 5.2.2 Bind and unbind operations . Overview 5.1.2 Communication model Information transfer 5.3.1 Association realizations 5.3.2 Transfer realization. TC-based application context . Abstract synt

25、axes 5.5.1 Dialogue control . . 5.5.2 User-defined syntaxes . Notation extension Page 31 32 33 33 33 34 35 36 39 39 41 43 46 46 46 47 47 47 48 49 49 49 50 51 51 52 54 54 54 54 55 55 56 57 iv Recommendation Q.775 (06/97) COPYRIGHT International Telecommunications Union/ITU TelecommunicationsLicensed

26、by Information Handling Services STD-ITU-T RECMN Q.775-ENGL 1977 m 48b2571 Ob37317 ClBb 9 Recommendation Q.775 GUIDELINES FOR USING TRANSACTION CAPABILITIES (revised in 1997) 1 Introduction l. 1 General The purpose of this Recommendation is to provide guidelines to potential users of Transaction Cap

27、abilities (TC-users). The examples given are illustrations only; they indicate how an application may use TCAP, not how TC must be used in all cases. The technical basis of this Recommendation are Recommendations 4.771 to 4.774; in case of misalignment, these should be considered as the primary refe

28、rence. The main purpose of TC is to provide support for interactive applications in a distributed environment. TC is based on the Remote Operations concept defined in Recommendation X.880 (ROS) together with some enhancements and additions specific to the Signalling System No. 7 environment to provi

29、de the services needed by TC-users. Interactions between distributed application entities are modelled by Operations. An operation is invoked by an (originating) entity: the other (destination) entity attempts to execute the operation and possibly returns the outcome of this attempt. The semantics o

30、f an operation (represented by its name and parameters) is not relevant to TC; TC provides facilities which are independent of any particular operation. The TC-user, when defining an application, must: 1) select operations (this involves defining the semantics and syntax of the data exchanged 2) sel

31、ect TC facilities to support these operations. Such facilities include the handling of during the operation invocations and its responses); individual operations, and the ability to have a number of related operations attached to an association between TC-users, called a dialogue; of message exchang

32、e that constitutes the dialogue between the peer TC-users, and their reactions to abnormal situations). This Recommendation describes the selection process of defining and using operations. The operations appearing hereafter are fictitious, and are taken for illustration purposes only. Also describe

33、d are the facilities offered by TC for handling one or a sequence of operations in a dialogue. The definition of specific sequences of operations belongs to the application protocol definition and is beyond the scope of this Recommendation; however, clauses 4 and 5 give a brief indication of what in

34、formation an application specification should contain. TC services are made accessible to TC-users via primitives; these primitives model the interface between TC and its users, but do not constrain any implementation of this interface. 3) define the application script (e.g. which of the two peers i

35、nvokes which operations, the order 1.2 Environment TC defines the end-to-end protocol between TC-users located in a Signalling System No. 7 network. At present, there is no standard interface defined for the use of TC over any other underlying protocol or network (e.g. X.25) than the SCCP of Signall

36、ing System No. 7. TC considers users which are real-time sensitive and do not need to exchange large amounts of data. It is considered that for these users, the standard protocols defined for OS1 layers 4 to 6 in the Recommendation Q.775 (06/97) 1 COPYRIGHT International Telecommunications Union/ITU

37、 TelecommunicationsLicensed by Information Handling Services STD.ITU-T RECMN Q.775-ENGL 1797 q8b2.571 Ob37320 BTB X-Series of Recommendations would result in excessive overheads and hence are not used. As a result, TC cannot support all kinds of applications, and a number of applications will still

38、require more elaborate services such as specified in the X-Series of Recommendations. Beside indicating what TC can do, this Recommendation indicates what it cannot do, in order to help the application designer choose how to support an application. 2 Operations 2.1 Definition An operation is invoked

39、 by an originating TC-user to request a destination TC-user to perform a given action. Each operation belongs to a particular class. This indicates whether either a successful outcome (result), or an unsuccessful outcome (error), or both, or none have to be reported by the destination. The class of

40、an operation is not signalled to the remote TC-user at the time the operation is invoked; it is assumed that the applications at both ends have a common understanding of the class of each operation in use. As well as the class, the definition of the operation includes a timer value indicating the ma

41、ximum time in which the operation should be completed and the result reported. This timer value is a local matter; it is not conveyed to the remote end through any protocol. It is chosen by the TC-user when defining the operation based on expectations of the round trip time fiom one TC-user to anoth

42、er and processing delays. An operation is defined by: - its operation code and the type of any parameters associated with the operation request; - its class; - if the class requires report of success, the possible results corresponding to successful - if the class requires report of failure, the pos

43、sible results corresponding to situations where executions are defined by a list of parameters; the operation could not be executed completely by the remote TC-user. Each such situation is identified by a specific error cause; the list of these error causes is part of the operation definition. Diagn

44、ostic information can be added to the error cause: if present, it is part of the definition; for this operation. Linked operations have to be described separately; returned. This timer value can be one of the factors that is used by an implementation to manage the invoke ID associated with the opera

45、tion invocation. (When the timer associated with an operation invocation has expired, the invoke ID is returned to the pool of invoke IDS after a suitable, implementation-dependent “freezing“ period.) - the list of possible linked operations, if replies consisting of linked operations are allowed -

46、a timer value indicating the interval by which the operation has to be completed, if any, As a general rule, the choice of the class of an operation should be based on the semantics associated with an operation and operations should not be designed to be carried in any particular message. For instan

47、ce, if the invoker of the operation does not require any acknowledgement of whether an operation could actually be performed or not, then an operation of Class 4 may be the most appropriate. If an operation invoker does not require explicit acknowledgement that an operation has been performed succes

48、sfully, but wishes to know if it could not be performed at all, then an operation of Class 2 is suitable. For example, defining an operation such as “Play Announcement“ as 2 Recommendation 4.775 (06/97) COPYRIGHT International Telecommunications Union/ITU TelecommunicationsLicensed by Information Ha

49、ndling ServicesClass 2 or 4 suggests different intentions of the operation invoker even though the actions of the operation performer may be identical. 2.2 Examples 2.2.1 Simple operation handlings NOTE - The operation invocation should ft into one message, and so should the report of a successful outcome, Reports of success may be segmented using Return Result - Not last and Return Result - Last. Class 1 (both success and failure reported) Translate a freephone number into a called subscriber number; return the called number if the translation can be performed, otherwis