1、STD-ITU-T RECMN Q.774-ENGL 1997 I 4862591 Ob42593 25T E INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Q.774 (06197) SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 - Transaction capa bi I it es a p p I cat ion part Transactio
2、n capabilities procedures ITU-T Recommendation Q.774 (Previously CCITT Recommendation) ITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE i NTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN S
3、PECIFICATIONS OF SIGNALLING SYSTEMS No. 4 AND No. 5 SPECIFICATIONS OF SIGNALLING SYSTEM No. 6 SPECIFICATIONS OF SIGNALLING SYSTEM RI SPECIFICATIONS OF SIGNALLING SYSTEM R2 DIGITAL EXCHANGES INTERWORKING OF SIGNALLING SYSTEMS SPECIFICATIONS OF SIGNALLING SYSTEM No. 7 SLAUSES APPLICABLE TO ITU-T STAND
4、ARD SYSTEMS General Message transfer part (MTP) Signalling connection control part (SCCP) Telephone user part (TUP) ISDN supplementary services Data user part Signalling System No. 7 management ISDN user Dart Q.1-Q.3 Q.4-Q.59 Q.100-Q.119 Q. 60-Q . 99 Q. 120-Q.249 Q .250-Q . 309 Q.310-Q.399 Q.400-Q.4
5、99 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 Q3 interface General Data link layer Network layer User-network management Stage 3 description for supplementary services using DSS 1 DIGITAL SUBSCRIBER SIGNALLING SY
6、STEM No. I PUBLIC LAND MOBILE NETWORK INTERWORKING WITH SATELLITE MOBILE SYSTEMS INTELLIGENT NETWORK BROADBAND ISDN Q.800-Q. 849 Q.850-Q.999 Q.850-Q.919 Q. 920-Q. 929 Q. 930-Q. 939 Q. 940-Q.949 Q ,950-Q . 999 Q. 1000-Q. 1 O99 Q.1100-Q.1199 Q.1200-Q.1999 Q .2000-Q . 2999 For further details, please r
7、efer to ITU-T List of Recommendations STD-ITU-T RECMN Q.774-ENGL 1777 H 4862573 Ob42595 O22 W ITU-T RECOMMENDATION Q.774 TRANSACTION CAPABILITIES PROCEDURES Summary This Recommendation has been revised for some additional clarifications (both in the text as well as the SDLs) on dialogue control proc
8、edures related to normal and abnormal dialogue ending. It also amends the SDLs to properly represent the dynamic creation and stopping of procedures. Source ITU-T Recommendation 4.774 was revised by ITU-T Study Group 11 (1997-2000) and was approved under the WTSC Resolution No. 1 procedure on the 5t
9、h of June 1997. STDeITU-T RECMN Q.774-ENGL 1997 O 4862591 Ob42596 Tb9 FOREWORD 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
10、is responsible for studying 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 stud
11、y by the ITU-T Study Groups which, in their turn, produce Recommendations on these topics. The approval of Recommendations by the Members of the IT-T is covered by the procedure laid down in WTSC Resolution No. 1. In some areas of information technology which fall within ITU-Ts purview, the necessar
12、y standards are prepared 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
13、possibility that the practice 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
14、 of the Recommendation development process. As of the date of approval of this Recommendation, the ITU hadhad 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 th
15、e latest information and are therefore strongly urged to consult the TSB patent database. O ITU 1998 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 writi
16、ng from the ITU. ii Recommendation Q.774 (06/97) 1 1 . 1 1.2 2 3 3.1 3.2 3.3 CONTENTS Page Introduction Basic guideline . Overview Addressing Transaction capabilities based on a connectionless network service . Sub-layering in TCAP Component sub-layer procedures . 3.2.1 Normal procedure 3.2.2 Abnorm
17、al procedures 3.2.3 Compatibility issues Transaction sub-layer procedures . Mapping of TR service primitives to message types 3.3.3 Normal procedures Abnormal procedures relating to transaction control 3.3.1 General 3.3.2 3.3.4 Annex A . Transaction capabilities SDLs . A.l General . A.2 Drafting con
18、ventions Dynamic creation of processes . A.3 A.4 Abbreviations used in the SDL diagrams . Recommendation 4.774 (06197) 1 2 2 13 16 17 17 17 18 21 24 24 28 28 60 . 111 STD=ITU-T RECMN Q.774-ENGL 1997 M 48b259L Ob42598 831 M Recommendation Q.774 TRANSACTION CAPABILITIES PROCEDURES (Melbourne, 1988; re
19、vised in I993 and 1997) 1 Introduction Transaction Capabilities (TC) allows TC-users to exchange components via Transaction Capabilities Application Part (TCAP) messages. It also allows, as an option, the transfer of Application Context Name and user information (Le. data which are not components) b
20、etween two TC-users. Procedures described in this clause speci the rules governing the information content and the exchange of TCAP messages between TC-users. 1.1 Basic guideline To maximize flexibility in service architecture and implementation style, TCAP procedures restrict themselves to supporti
21、ng the exchange of components and, as an option, Application Context Name and user information (i.e. data which are not components) between TC-users. Application specific (TC-user) procedures are not part of TCAP. When the selection of a parameter value associated with a primitive that is required b
22、y a lower layer (sub-layer) is not relevant to that layer (sub-layer), the value is simply passed down through the primitive interface. The same assumption applies to the parameters received from a lower layer through the primitive interface which are not required for TCAP functions. 1.2 Overview Cl
23、ause 2 describes addressing rules for TC messages. Clause 3 describes transaction capabilities based on a connectionless network service. 2 Addressing In a Signalling System No. 7 environment using a connectionless network service, TC messages will use any of the addressing options afforded by the S
24、ignalling Connection Control Part (SCCP). Assignment and use of global titles may be network and/or application specific. They are not a part of this protocol specification and are not discussed further here. Addressing options when other network providers are used are for further study. 3 Transacti
25、on capabilities based on a connectionless network service 3.1 Sub-layering in TCAP TCAP procedure is divided into component sub-layer procedure and transaction sub-layer procedure. The component sub-layer procedure provides a TC-user with the capability of invoking remote operations and receiving re
26、plies. The component sub-layer also receives dialogue control information and user information from a TC-user and generates dialogue control APDUs as appropriate. It uses transaction sub-layer capabilities for transaction control which is the ability to cany a sequence of components and, optionally,
27、 a dialogue portion, in transaction sub-layer messages over an end-to-end connection between two TC-users. Recommendation Q.774 (06197) 1 - STD-ITU-T RECMN Q.774-ENGL II997 S 4b259L Ob42599 778 I 3.2 Component sub-layer procedures The component sub-layer provides two kinds of procedures: - dialogue
28、handling; - component handling. 3.2.1 Normal procedure 3.2.1.1 Component handling procedure 3.2.1.1.1 Recommendation 4.77 1 describes the services provided by the component sub-layer by defining the service interface between the TC-user and the component sub-layer and the interface between the compo
29、nent sub-layer and the transaction sub-layer. Component handling refers to the ability of the TC-user to invoke a remote procedure and receive its response. Component handling procedures map component handling service primitives onto components, which constitute the Protocol Data Units (PDUs) of the
30、 component sub-layer. A mapping of these primitives to component sub-layer PDUs is indicated in Table 1. Mapping of TC component handling service primitives to component types Table VQ.774 - Mapping of TC component handling service primitives to components Service Primitive TC-INVOKE TC-RESULT-L TC-
31、U-ERROR TC-U-REJECT TC-R-REJECT TC-L-REJECT TC-RESULT-NL TC-L-CANCEL TC-U-CANCEL Abbreviation INV RR-L RE RJ RJ (Note 2) RR-NL (Note 3) (Note 3) Component Type Invoke (Note 1) Return Result (Last) (Note 1) Return Error (Note 1) Reject (Note 1) Reject (Note 1) Return Result (Not Last) NOTE 1 - X.219
32、and X.229 Compatible. NOTE 2 - Treatment of this primitive is described in 3.2.2.2. NOTE 3 - There is no component type associated with this primitive since the effect is purely local. 3.2.1.1.2 Management of invoke IDS Invoke IDS are assigned by the invoking end at operation invocation time. A TC-u
33、ser need not wait for one operation to complete before invoking another. At any point in time, a TC-user may have any number of operations in progress at a remote end (although the latter may reject an invoke component for lack of resources). Each invoke ID value is associated with an operation invo
34、cation and its corresponding invoke state machine. Management of this invoke ID state machine takes place only at the end which invokes the operation. The other end reflects this invoke ID in its replies to the operation invocation, and does not manage a state machine for this invoke ID. Note that b
35、oth ends may invoke operations in a full-duplex manner: each end manages state machines for the operations it has invoked and is free to allocate invoke IDS independently of the other. 2 Recommendation Q.774 (06/97) STD=ITU-T RECMN d-774-ENGL II997 W 48b259L Ob42bOO 2IIT = Operation class 1 2 3 4 An
36、 invoke ID value may be reallocated when the corresponding state machine returns to idle. However, immediate reallocation could result in difficulties when certain abnormal situations arise. A released ID value (when the statemachine returns of idle) should therefore not be reallocated immediately;
37、the way this is done is implementation-dependent, and thus is not described in this Recommendation. The two peer applications must have a priori knowledge of the classes and timers associated with each operation. Component states and state transitions are described in 3.2.1.1.3. Description Reportin
38、g success or failure Reporting failure only Reporting success only Outcome not reported 3.2.1.1.3 Operation classes See Table 2. Table 2/Q.774 -Operation classes A different type of state machine is defined for each class of operation, the state transitions of which are represented by Figures 1 to 4
39、. These state machines are described here from a protocol point of view (sentreceived components), whereas they are described in Recommendation 4.77 1 from a service (primitives) point of view. The states of each component state machine are defined as follows: - - Idle: The invoke ID value is not as
40、signed to any pending operation. Operation Sent: The invoke ID value is assigned to an operation which has not been completed or rejected. The “operation sent“ state is triggered when the invoke component is transmitted. Waitfor Reject: When a component indicating the completion of an operation is r
41、eceived, the receiving TC-user may reject this result. The Wait for Reject state is introduced so that the invoke ID is retained for some time, thereby making the rejection possible. - State transitions are triggered by: - - - a primitive received from the TC-user, causing a component to be built, a
42、nd eventually sent; receipt of a component from the peer entity; a number of situations indicated on Figures 1 to 4, corresponding to the following situations: Cancel - A timer is associated with an operation invocation. This invocation timer is started when the invoke component is passed to the tra
43、nsaction sub-layer. The TC-INVOKE request primitive indicates a timer value. A cancel situation occurs when the invoking TC-user decides to cancel the operation (TC-U-CANCEL request primitive) before either the final result (if any) is received, or a timeout situation occurs. On receipt of a TC-U-CA
44、NCEL request, the component sub-layer stops the timer; any further replies will not be delivered to the TC-user, and TCAP will react according to abnormal situations as described in 3.2.2.2. End situation - When an End or Abort message is received, or when prearranged end is used, TCAP returns any p
45、ending operations to Idle. Recommendation 4.774 (06/97) 3 STDmITU-T RECMN Q-77Y-ENGL 1997 S 4862593 Ob42603 356 S Invocation timeout - A timeout situation occurs when the timer associated with an operation invocation expires: the state machine returns to Idle, with notification to the TC-user by mea
46、ns of a TC-L-CANCEL indication (in the case of a class 1, 2 or 3 operation). This notification indicates an abnormal situation for a class 1 operation, or gives the definite outcome of a class 2 or 3 operation for which no result has been received (normal situation). Reject timeout - A Reject timeou
47、t situation occurs when the timer associated with the Wait for Reject state expires. If this occurs, the component sub-layer assumes that the TC-user has accepted the component. In Figures 1 to 4, components contain either single ID values, or ordered pairs of IDS (i, y), where i is the invoke ID an
48、d y is the linked ID. The state diagrams are modelled for a single operation invocation with ID i. The value of y is not relevant to the ID i. A linked invoke operation can only be accepted if the linked to state machine is in the Operation Sent state. Components can be received “well-formed“ or “ma
49、lformed“. The diagrams show where this is significant. If it does matter whether the component is received “well-formed“ or “malformed“, then the diagram indicates “receive“ only. These figures also indicate normal and abnormal transitions. Abnormal transitions result in the abnormal procedures discussed in 3.2.2. For instance, if a class 1 operation times out, this indicates an abnormal situation. The component sub-layer will release the invoke ID and inform the application. It is now up to the application to decide whether to abort the transaction or to report an error
