1、 STD.ITU-T RECMN Q.754-ENGL 1797 48b2571 Ob38523 481 INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Q.754 SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System No. 7 - Signalling System No. 7 management (06197) Signalling System No. 7 man
2、agement Application Service Element (ASE) definitions ITU-T Recommendation Q.754 (Previously CCIlT Recommendation) ITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN SPECIFICATIONS OF SIGNALL
3、ING 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 INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING CLAUSE
4、S APPLICABLE TO ITU-T STANDARD SYSTEMS General Message transfer part (MTP) Signalling connection control part (SCCP) Telephone user part (TUP) ISDN supplementary services Data user part Q.1-Q.3 Q .4-Q . 59 Q .60-Q . 99 Q. I OO-Q. I 1 9 Q. 120-Q.249 Q .250-Q. 309 Q.310-Q.399 Q.400-Q.499 Q.500-Q.599 Q
5、.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 ISDN user part Transaction capabilities application part Test specification Q3 interface DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. I PUBLIC LAND MOBILE NETWORK INTERWORKING WITH SATELLITE MOBILE SYSTEMS INTELL
6、IGENT NETWORK BROADBAND ISDN Q. 760-Q. 769 Q.770-Q.779 Q.780-Q.799 Q.800-Q.849 Q ,850-Q . 999 Q.1000-Q.1099 Q. 1 1 00-Q. 1 1 99 Q. 1200-Q. I999 Q.2000-Q.2999 For further details, please refer to ITU-T List of Recommendations. STD-ITU-T RECMN d.754-ENGL 1977 48b2571 Ob38525 254 ITU-T RECOMMENDATION Q
7、.754 SIGNALLING SYSTEM No. 7 MANAGEMENT APPLICATION SERVICE ELEMENT (ASE) DEFINITIONS Summary This Recommendation defines the application service element used by the management functions MRVT, SRVT and CVT defined in Recommendation Q.753. The ASE defines the management information used by these func
8、tions in messages across the SS No. 7 network. The ASE interfaces with Transaction Capabilities (TCs) to provide the services used by the OMASE-User (defined in Recommendation Q.753), to allow inter-nodal SS No. 7 communication by MRVT, SRVT or CVT. The main revisions to the 1993 version of this Rec
9、ommendation are: a) b) c) d) e) 0 revision of the compatibility rules to allow transparent transport of unrecognized parameters; definition of a new MRVT and SRVT message parameter to speci what information is required in any respective MRVR or SRVR message; definition of a new MRVR and SRVR message
10、 to be used if information is required beyond that specified for the 1993 MRVR and SRVR messages; definition of new MRVT and MRVR message parameters to indicate the route priorities; definition of new MRVA, MRVR, SRVA and SRVR parameters to allow parameters unrecognized in the MRVT or SRVT messages
11、to be returned; definition of a new MRVT parameter requesting nodes to check if they have a route to the test initiator through the node from which they received the MRVT message (this allows checking for symmetrical routes). Source ITU-T Recommendation Q.754 was revised by ITU-T Study Group 11 (199
12、7-2000) and was approved under the WTSC Resolution No. 1 procedure on the 5th of June 1997. 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
13、of the ITU. The ITU-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, establish
14、es the topics for study 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-T
15、s purview, the necessary 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
16、draws attention to 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 me
17、mbers or others outside of the Recommendation development process. As of the date of approval of this Recommendation, the ITU hadihad not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementors are cautioned that t
18、his may not represent the latest information and 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, wit
19、hout permission in writing from the ITU. I1 Recommendation 4.754 (06/97) 1 2 2.1 3 3.1 4 4.1 5 6 6.1 6.2 6.3 STD-ITU-T RECMN Q-754-ENGL 1777 m 48b2591 Ob38527 027 CONTENTS Page Introduction MTP MTP Routing Verification Test (MRVT) . 2.1.1 testRoute Action 2.1.2 routeTrace Event . 2.1.3 routeTraceNew
20、 SCCP SCCP Routing Verification Test (SRVT) ASE 3.1.1 testRouteAction . 3.1.2 routeTrace Event 3.1.3 routeTraceNew Event Circuit management Circuit Validation Test (CVT) ASE . 4.1.1 cktValidTest CnfAction 4.1.2 Action arguments 4.1.3 Action results . 4.1.4 Specific Error Transaction capabilities Gen
21、eral definitions . Objects and operations . Primitives and procedures of the OMASE protocol . 6.2.1 General 6.2.2 OM-EVENT-REPORT . 6.2.3 OM-CONFIRMED-ACTION . 1 9 9 9 14 17 20 20 20 20 20 21 21 22 22 22 22 22 24 Abstract syntax ofthe OMASE protocol 29 Annex A . Use of primitive interfaces 40 Recomm
22、endation 4.754 (06/97) . 111 STDmITU-T RECMN Q-754-ENGL 1997 D 48b259L Ob38528 Tb3 D Recommendation Q.754 SIGNALLING SYSTEM No. 7 MANAGEMENT APPLICATION SERVICE ELEMENT (ASE) DEFINITIONS (revised in 1997) 1 Introduction Note that in the event of a conflict between Recommendations 4.753 and 4,754, Re
23、commendation 4.754 will take precedence. This Recommendation defines the OMAP ASE, OMASE. OMASE provides the services invoked using the OM-EVENT-REPORT and OM-CONFIRMED-ACTION primitives across the OMASE-User to OMASE boundary. (See Recommendation 4.753 for a diagram and mapping between the services
24、 invoked in the OMASE-User and those of OMASE.) The OMASE services are derived from those defined in CMIPl. The OMASE primitives are defined in clause 6, the formal syntax defined in Figure 3 uses Transaction Capabilities (TCs) OPERATION and ERROR. The intenvorking between OMASE and TC is also given
25、 in clause 6. OMASE provides operations allowing the network administration, via the OMAP Management Process and the OUSE-User, to perform MTP and SCCP Routing Verification Tests (MRVT and SRVT), and Circuit Validation Tests (CVTs). This Recommendation contains the ASE definition for MRVT, SRVT and
26、CVT. The SRVT referred to here is for the specific test in 3.2.2/Q.753. The arguments used for primitives across the OMAP Management Process to OUSE-User boundary, and for primitives across the OMASE-User to OMASE boundary, and between OMASE and TC contain the same information if they have the same
27、name. Those arguments are defined in this Recommendation. Messages between Signalling Points are encoded using the ASN. 1 Basic Encoding Rules (BER), and octet string parameters are encoded as primitive (not constructed) elements. 2 MTP 2.1 The MRV Test initiated at the test origin results in an OM-
28、CONFIRMED-ACTION primitive being used from the OMASE-User to OMASE, which includes the testRoute command as a parameter. If a trace of the routes is requested, or a fault exists, the OM-EVENT-REPORT primitive is invoked at the test originator from OMASE, which includes the routeTrace or routeTraceNe
29、w event as a parameter. MTP Routing Verification Test (MRVT)2 CMIP is defined in ISOIEC 9596 and in Recommendation X.7 1 1. * See Recommendations X.680 through X.683 and Recommendation X.690 for the description of the formal notation (also Recommendations X.208 and X.209). Recommendation Q.754 (06/9
30、7) 1 STD-ITU-T RECNN Q-754-ENGL 1977 48b2591 Ob38527 7TT Parameter initiatingSP testRoute is specified using the CNF-ACTION macro defined in Figure 3, routeTrace is specified using the EVENT macro defined in Figure 3. Figure 3 is the definition of the OMASE module, and defines all parameters used in
31、 the protocol. For MRVT, the Objectclass indicates MTP Routing Tables, and the ObjectInstance contains the Point Code of the test destination. The testRoute Action makes use of the BEGIN (MRVT) message with result (MRVA) returning in an END. The routeTrace Event (MRVR) uses a BEGIN message with pre-
32、arranged end. Code 10000000 2.1.1 testRoute Action Parameter traceRequested The testRoute Action is invoked to initiate an MTP routing verification test. At the initiator node, this invocation is requested by the Administration via the MIS-User or a local interface, through the OMAP Management Proce
33、ss and OMASE-User. At subsequent nodes, the Action is requested implicitly by the receipt of a testRoute Action invocation. A successful reply indicates successful completion of the test at the point it was invoked and, implicitly, at all subsequent points where the test was invoked. A failure indic
34、ation is returned to indicate that the test failed in this or in a sebsequent node. Code 1000000 1 See Figure 3. TRUE (= i) FALSE (= O) 2.1.1.1 testRoute Action Arguments trace was requested, return trace information on success and failure. trace not requested, return trace information only on failu
35、re. 2.1.1.1.1 initiatingSP The initiatingSP identifies the original requester of the test. It is of type PointCode, defined as an octet string. Contents l I Bit O contains the first bit of the Point Code. Bit 1 contains the second bit of the Point Code, etc. 2.1.1.1.2 traceRequested traceRequested i
36、ndicates that a trace of all routes used to reach the destination should be reported to the originator (the routeTraceEvent is described in 2.1.2). It is of type BOOLEAN. I Contents I Meaning I 2.1 J.1.3 threshold The originator sets a maximum threshold level of Signalling Points (SPs) which are all
37、owed to be crossed in the course of the test (including the initiator if it is an STP). This aids in detecting overly long routes. This threshold is an integral number of SPs, thus it is of type INTEGER, 2 Recommendation 4.754 (06/97) Parameter threshold 2.1.1.1.4 pointCodesTraversed As each interme
38、diate SP is crossed, it adds its own Point Code to the list of Point Codes traversed. This aids in detecting loops and is also useful information in case of a failure or if a route trace is requested. It is a list of Point Codes, thus of type PointCodeList. Code 100000 1 o I Parameter I Code I point
39、CodesTraversed 1010001 1 Sequence of Point Codes, tagged as “PointCode“ with the contents indicating the exact Point Code. routePriorityList 2.1.1.1.5 routePriortyList If the infoRequest parameter is included and requests it, as each SP is traversed it adds the priority of the route to the next SP i
40、nto routePriorityList. 10101 100 I Parameter I Code Parameter - in foReque s t Code 10001 101 Sequence of Priority, tagged as “Priority“ with the contents indicating unknown, or first choice, or second choice, etc. 2.1.1.1.6 infoRequest This optional parameter inserted, if at all, only by the SP ini
41、tiating the test, indicates that the initiator can recognize MRVR messages occasioned by the routeTraceNew event type. The infoRequest parameter indicates which information is requested if an MRVR message should be sent to the initiator. It also can indicate which parameters should be updated as the
42、 MRVT messages traverse the network. Current values can be pointlode (bit O = i), and/or pointcodelist (bit i), and/or routePriorityList (bit 2). Contents Bit string containing any or all of the indicated values. 2.1.1.1.7 returnUnknownParams This optional parameter is inserted, if at all, only by t
43、he SP initiating the test (and only if the infoRequest parameter is also included). It indicates which MRVT parameters a following node should return, if the following node does not recognize those parameters. The unrecognized MRVT parameters are to be copied into the (new) MRVR message (routeTraceN
44、ew) if the following node has occasion to return an MRVR (or in an MRVA message in the copyData parameter if the initiator is unknown to it). Bit O in returnUnknownParams indicates an MRVT parameter with tag value 15, bit 1 an MRVT parameter with tag value 16, etc. Recommendation 4.754 (06/97) 3 STD
45、-ITU-T RECMN 8-754-ENGL 1797 48b257L Ob38531 558 I returnUnknownParams I parameter I Code 10001 110 Specific Error failure Bit string containing any indicated values. Code 00000001 2.1 .1 .1.8 directRouteCheck This optional parameter indicates when TRUE that following nodes are requested to check th
46、at they have a route to the test initiator through the SP from which they received the prompting MRVT message. I Parameter I code 1 I directRouteCheck I 10001111 I Boolean, TRUE indicates that the check is required. 2.1.1.2 Action results There are no contents in a successful return indication. 2.1.
47、1.3 Action Errors SpecificErrors are possible errors which can occur during this test, and which are unique to this test. These specific errors are in addition to the errors already identified in the OM-CONFIRMED-ACTION service and appear as parameters to the Processing Failure Error. 2.1.1.3.1 fail
48、ure failure indicates a condition of total failure, where no route worked correctly. Most often this will be used as a failure indication from the point which detects the error and does not invoke any further testRoute Actions. The failure SpecificError has with it a parameter to indicate the error
49、condition causing the failure. This parameter, failureType, is represented as a bit string. The second parameter is to be used when failureType indicates the error unknownInitiatingSP. traceSent indicates whether or not a routerrrace Event has been invoked to report trace information. It is necessary to indicate this for this error since the node detecting the error cannot send the routeTrace, thus the previous node must. traceSent has type BOOLEAN. The third parameter is optional, it is present if failureType is “unknodnitiating SP“ traceSent is FALSE, and the p
