ITU-T Q 772-1997 Transaction capabilities information element definitions (Study Group 11 14 pp)《事务处理能力信息单元的定义-系列Q 交换和信令-NO 7信令系统的准则-事务处理能力部分(第11研究》.pdf

《ITU-T Q 772-1997 Transaction capabilities information element definitions (Study Group 11 14 pp)《事务处理能力信息单元的定义-系列Q 交换和信令-NO 7信令系统的准则-事务处理能力部分(第11研究》.pdf》由会员分享，可在线阅读，更多相关《ITU-T Q 772-1997 Transaction capabilities information element definitions (Study Group 11 14 pp)《事务处理能力信息单元的定义-系列Q 交换和信令-NO 7信令系统的准则-事务处理能力部分(第11研究》.pdf（14页珍藏版）》请在麦多课文档分享上搜索。

1、I INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU 4.772 (06197) SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 - Transaction capabilities application part Transaction capabilities information element def i n it i o ns ITU-T Re

2、commendation Q.772 (Previously CCIlT Recommendation) COPYRIGHT International Telecommunications Union/ITU TelecommunicationsLicensed by Information Handling ServicesSTD-ITU-T RECMN P-772-ENGL I997 48b259L 0b1i0755 1i23 ITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING I l For further details,

3、please refer to ITU-T List of Recommendations. SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN SPECIFICATIONS OF SIGNALLING SYSTEMS No. 4 AND No. 5 SPECIFICATIONS OF SIGNALLING SYSTEM No. 6 SPE

4、CIFICATIONS OF SIGNALLING SYSTEM R1 SPECIFICATIONS OF SIGNALLING SYSTEM R2 DIGITAL EXCHANGES INTERWORKING OF SIGNALLING SYSTEMS SPECIFICATIONS OF SIGNALLING SYSTEM No. 7 CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS General Message transfer part (MTP) Signalling connection control part (SCCP) Telepho

5、ne user part (TUP) ISDN supplementary services Data user part Signalling System No. 7 management 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

6、 Q. 76O-Q. 769 ISDN user part Test specification Q.780-Q.799 Q3 interface General Data link layer Network layer User-network management Stage 3 description for supplementary services using DSS 1 DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 PUBLIC LAND MOBILE NETWORK I NTERWORKI NG WITH SATELLITE MOB1

7、LE 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.1099 Q.1100-Q.1199 Q.1200-Q.1999 Q.2000-Q.2999 COPYRIGHT International Telecommunications Union/ITU TelecommunicationsLicensed by Information Handling Servic

8、es- STDWITU-T RECMN 8.772-ENGL 1777 48b257L Ub4075b 3bT ITU-T RECOMMENDATION 4.772 TRANSACTION CAPABILITIES INFORMATION ELEMENT DEFINITIONS Summary This Recommendation describes individual information elements and parameters used within transaction capabilities messages. It has been revised for the

9、definition of result source diagnostic. Source ITU-T Recommendation 4.772 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 TelecommunicationsLicensed by Information

10、 Handling ServicesSTD*ITU-T RECMN Q.772-ENGL 1797 qBb259L Ub1i0757 2Tb 9 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

11、-T 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 s

12、tudy by the ITU-T Study Groups 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. 1. In some areas of information technology which fall within ITU-Ts purview, the nece

13、ssary 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

14、the 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 out

15、side 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 represen

16、t the 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 w

17、riting from the IT. 11 Recommendation Q.772 (06/97) COPYRIGHT International Telecommunications Union/ITU TelecommunicationsLicensed by Information Handling Services1 2 2.1 2.2 3 3.1 4 4.1 4.2 CONTENTS Page General . Transaction portion . Message type Transaction IDS Component Portion . Component typ

18、e Dialogue portion . Dialogue portion information elements Dialogue control APDUs Recommendation Q.772 (06197) 1 . 111 COPYRIGHT International Telecommunications Union/ITU TelecommunicationsLicensed by Information Handling ServicesSTD - ITU-T RECMN Q0772-ENGL 1997 4db259L 0690759 079 9 Recommendatio

19、n 4.772 TRANSACTION CAPABILITIES INFORMATION ELEMENT DEFINITIONS (Melbourne 1988; revised in 1993 and 1997) 1 General This Recommendation describes the individual information elements and parameters used within Transaction Capabilities messages. The encoding and formatting of these elements are show

20、n in Recommendation 4.773. The meaning of each information element is described in general terms. The TCAP message format consists of three parts, namely the transaction portion, the dialogue portion and the component portion. Information in the component portion concerns individual operations and t

21、heir replies. The transaction portion contains protocol control information for the transaction sublayer. The dialogue portion is concerned with the application context and, as an option, user information (i.e. data, which are not components). For a more detailed analysis of the architecture, see Fi

22、gure UQ.771 and associated text. I 2 Transaction portion The transaction portion of a TC message may contain the following information elements, namely: 2.1 Message type Five types of messages are defined for the transaction portion as follows: 2.1.1 unidirectional: This message is used when there i

23、s no need to establish a transaction with another peer TR-User. 2.1.2 begin: This message is used to initiate a transaction with another peer TR-User. 2.1.3 end: This message is used to terminate a transaction with another peer TR-User. 2.1.4 continue: This message is used to complete the establishm

24、ent of a transaction and to continue an established transaction. 2.1.5 abort: This message is used to terminate a transaction following an abnormal situation detected by the transaction sublayer (the service provider), or to abort a transaction by the TR-User (the service user). 2.2 Transaction IDS

25、Transaction IDS are independently assigned by each of the two nodes communicating via a transaction, enabling each node to uniquely identi the transaction and associate the entire contents of the message with that particular transaction. There are two types of Transaction IDS, namely: 2.2.1 originat

26、ing transaction ID: The Originating Transaction ID is assigned by the node sending a message, and is used to identify the transaction at that end. Recommendation 4.772 (06/97) 1 COPYRIGHT International Telecommunications Union/ITU TelecommunicationsLicensed by Information Handling ServicesSTD*ITU-T

27、RECMN Q.772-ENGL 1997 m LiAb2591i Ob1107b0 890 m P-Abort cause Unrecognized message type (syntax error) 2.2.2 receiving end. 2.3 P-Abort cause definitions are as follows: 2.3.1 unrecognized message type: The message type is not one of those defined in 2.1.1 to 2.1.5 above. 2.3.2 unrecognized transac

28、tion ID: A transaction ID has been received for which a transaction does not exist at the receiving node. 2.3.3 badly formatted transaction portion: The transaction portion of the received message does not conform to the X.209 encoding rules as outlined in 4.UQ.773. 2.3.4 incorrect transaction porti

29、on: The elemental structure within the transaction portion of the received message does not conform to the rules for the transaction portion defined in 3.UQ.773. 2.3.5 resource limitation: Sufficient resources are not available to start a transaction. destination transaction ID: The Destination Tran

30、saction ID identifies the transaction at the P-abort cause: This is used when the transaction sublayer aborts a transaction. Example reason The combination of class, form and value does not correspond to a known tag, i.e. message type is not Table UQ.772 - Example mapping of P-Abort scenarios to P-A

31、bort cause values (The Transaction Sublayer has received a message which does not conform to the encoding rules defined in 4. UQ.773) Transaction sublayer Malformed tag for an information element, other than Message Type (e.g. the class and code indicates integer while the form indicates constructed

32、 encoding). Length indicator value does not correspond to length of message. 1 Begin, Continue, End, Uni-directional or Abort. (The message type tag is unknown, i.e. not defined in Recommendation Q.773) I Unrecognized transaction ID A Transaction ID has been received which is derivable, but for whic

33、h a transaction does not exist at the receiving node, i.e. a Continue message has been received with an unrecognized (destination) Transaction ID Destination Transaction ID unassigned. Badly formatted transaction portion (encoding error) Length indicator value has less than 128 octets, but not coded

34、 short form. 2 Recommendation Q.772 (06/97) COPYRIGHT International Telecommunications Union/ITU TelecommunicationsLicensed by Information Handling Services STD-ITU-T RECMN 8.772-ENGL 1777 48b2591 Ob1i07b1 727 = P-Abort cause Table UQ.772 - Example mapping of P-Abort scenarios to P-Abort cause value

35、s (concluded) Example reason Return error Reject Incorrect transaction portion (syntax error) ROER ROW (The elemental structure within the Transaction portion of the received message does not conform to the rules for the Transaction Portion defined in clause 3/Q.773) Resource limitation (Insufficien

36、t resources for this TR andor TR-User) Combination of Origin and Destination Transactions ID does not conform to message type. Component Portion Tag present, but no components. Message does not contain all the mandatory information elements defined in Recommendation 4.773 for the message type. The o

37、rder of the received information elements within the message does not conform to Recommendation 4.773 for the message type. I Congestion No Transaction ID is available for ailocation to the new transaction establishment request. 1 , I 2.4 option, user information .e. data, which are not components).

38、 2.5 information element is not present. dialogue portion: This is used to pass Information related to application context and, as an component portion: This contains components. When no components are transferred, this 3 Component Portion The Component Portion contains the following types of inform

39、ation elements. Components within a message are delivered to the user at the receiving end in the same order in which they were received from the user at the originating end. 3.1 Component type There are five types of components that may be present in the Component Portion of a TC message. The four

40、Protocol Data Units (PDUs) defined in Recommendation X.229 are used, namely: I X.229 PDU TCAP component I Invoke I ROIV I I Return result (last) I RORS I The remaining component type - Return Result (Not Last) - is defined by TCAP. Recommendation Q.772 (06/97) 3 COPYRIGHT International Telecommunica

41、tions Union/ITU TelecommunicationsLicensed by Information Handling ServicesSTD-ITU-T RECMN Q.772-ENGL 1997 = 48b259L Ob1i07b2 bb3 These component types are defined as follows: 3.1.1 invoke: The invoke component requests that an operation be performed. It may be linked to another operation invocation

42、 previously sent by the other end. In this case it is known as a “Linked Invoke“. 3.1.2 return result (not last): When TC uses a connectionless Network Service, it may be necessary for the TC-User to segment the result of an operation if the two peer TC-users use a network service that does not prov

43、ide segmentingheassembling of user data. In this case the Return Result (Not Last) component is used to convey each segment of the result except the last, which is conveyed in a Return Result (Last) component. The Return Result (Not Last) facility is allowed ONLY if the result is too large to fit in

44、to a single Return Result (Last) component. Note that the use of the Return Result (Not Last) facility implies that the operation has completed successfully. 3.1.3 return result (last): The Return Result (Last) component reports successful completion of an operation. It may contain the last segment

45、of a result or, in the case of an unsegmented result, it contains the entire result. 3.1.4 return error: The Return Error component reports that an operation has not been successfully completed. 3.1.5 reject: The Reject component reports the receipt and rejection of an incorrect component, other tha

46、n a Reject component. The possible causes for rejecting a component are defined by the Problem Code element in 3.7. 3.2 invoke ID: An Invoke ID is used as a reference number to identi uniquely an operation invocation. It is present in the Invoke component and in any reply to the Invoke (Return Resul

47、t, Return Error or Reject), enabling the reply to be correlated with the invoke. 3.3 linked ID: A Linked ID is included in an invoke component by a node when it responds to an operation invocation with a linked operation invocation. The node receiving the Linked ID uses it for correlation purposes,

48、in the same way that it uses the invoke ID in Return Result, Return Error and Reject components. 3.4 operation code: The Operation Code element indicates the precise operation to be invoked, and is present in an Invoke component type. It is also present in the Return Result (Lasmot Last) components

49、if the results contain parameters. The operation code may be given a local value (Le. integer) which then identifies the operation within a limited domain; or it may be a global value (Le. object identifier) which makes the operation uniquely identifiable across all applications. The actual operation codes, the definition of the operations and their associated parameters, are defined in relevant ASE specifications. The component sublayer does not set or examine the operation code value, nor parameters which are present, nor the parameter values. 3.5 parameter: The P