ITU-T Q 755-1993 SIGNALLING SYSTEM NO 7 PROTOCOL TESTS (Study Group XI)《NO 7信令系统规程测试-NO 7信令系统的准则-NO 7信令系统管理(第11研究组)13页》.pdf

《ITU-T Q 755-1993 SIGNALLING SYSTEM NO 7 PROTOCOL TESTS (Study Group XI)《NO 7信令系统规程测试-NO 7信令系统的准则-NO 7信令系统管理(第11研究组)13页》.pdf》由会员分享，可在线阅读，更多相关《ITU-T Q 755-1993 SIGNALLING SYSTEM NO 7 PROTOCOL TESTS (Study Group XI)《NO 7信令系统规程测试-NO 7信令系统的准则-NO 7信令系统管理(第11研究组)13页》.pdf（13页珍藏版）》请在麦多课文档分享上搜索。

1、ITU-T RECMN*Q-?55 93 = 48b259L 0585908 779 INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Q.755 (03193) SPECIFICATIONS OF SIGNALLING SYSTEMS No. 7 SIGNALLING SYSTEM No. 7 MANAGEMENT SIGNALLING SYSTEM No. 7 PROTOCOL TESTS ITU-T Recommendation Q.755 (Previo

2、usly “CCITT Recommendation“) ITU-T RECMN*d.755 93 W 4862591 0585909 605 FOREWORD The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of the International Telecom- munication Union. The ITU-T is responsible for studying technical, operating and tariff questions and issuing R

3、ecommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Conference (WTSC), which meets every four years, established the topics for study by the ITU-T Study Groups which, in their turn, produce Recommendations on these

4、topics. ITU-T Recommendation Q.755 was prepared by the ITU-T Study Group XI (1988-1993) and was approved by the WTSC (Helsinki, March 1-12, 1993). NOTES 1 As a consequence of a reform process within the International Telecommunication Union (ITU), the CCITT ceased to exist as of 28 February 1993. In

5、 its place, the IT Telecommunication Standardization Sector (ITU-T) was created as of i March 1993. Similarly, in this reform process, the CCIR and the IFRB have been replaced by the Radiocommunication Sector. In order not to delay publication of this Recommendation, no change has been made in the t

6、ext to references containing the acronyms “CCIT, CCIR or IFRB or their associated entities such as Plenary Assembly, Secretariat, etc. Future editions of this Recommendation will contain the proper terminology related to the new ITU structure. 2 telecommunication administration and a recognized oper

7、ating agency. In this Recommendation, the expression “Administration” is used for conciseness to indicate both a Ali 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 permiss

8、ion in writing from the “U. ITU-T RECMN*d.755 93 48b259L 0585910 327 CONTENTS Page 1 Introduction 1 2 MTP tester (MT) 1 2.1 Functions 2.1.1 Objectives and scope . 2.1.2 Main functions 2.1.3 Architectural model . 2.1.4 Implementation . 2.1.5 Traffic modes 2.1.6 Functional blocks 2.1.7 Identification

9、of test sequences . 2.1.8 Message rate considerations 2.2 Procedures 2.2.1 Test Set-up . 2.2.2 Test duration . 2.2.3 Termination . 2.2.4 Reaction to MTP management primitives and MTP restari 2.3 Formats and codes 2.3.1 SI0 2.3.2 Label . 2.3.3 Header codes . 2.3.4 Timers . 2.3.5 Interface requirement

10、s . 1 1 3 3 3 3 3 4 4 4 4 5 5 6 7 7 7 7 9 9 3 SCCP tester (ST) 10 4 References 10 Recommendation Q.755 (0393) I Recommendation Q.755 SIGNALLING SYSTEMS No. 7 PROTOCOL TESTS (Helsinki, 1993) 1 Introduction The protocol testers may be used as an aid when testing the Message Transfer Part (MTP and the

11、Signalling Connection Control Part (SCCP) of Signalling System No. 7 (SS No. 7), either when performing validation testing of an implementation or compatibility testing between two implementations. The testers main function is simulation of an ordinary user part or sub-system, as seen from the MTP o

12、r SCCP respectively, for the generation of test traffic. Recommendations 1.320 and 1.321 specify the ISDN protocol reference model to be used for N-ISDN and B-ISDN. User plane (U-plane), Control plane (C-plane) and Management plane (M-plane) are identified. The layering principles apply in each of t

13、hese planes. The U-plane provides the user information flow transfer with associated controls. The C-plane handles the call and connection control information. The M-plane is divided into two portions, the Layer Management functions and the Plane Management functions. The Plane Management performs m

14、anagement functions related to a system as a whole, it provides coordination between all the planes and has no layered structure. The Layer Management plane contains Layer Management Entities (LME). Each of them provides management functions relating to resources and parameters residing in its own p

15、rotocol entity. Layer Management handles the operation and maintenance information flows. The interface between adjacent layers within a plane and between LME and its associated layer have to be defined in terms of service primitives. The interface between the LMEs and Plane Management has not to be

16、 specified, it is implementation dependent. Thus the MT is contained in the LME of the MTP-3 (MTP-3 LME) and the ST is within the LILE of the SCCP (SCCP LME). The service primitives between MTP-3 LME and the MTP-3, and between SCCP LME and the SCCP is described, as well as the procedures, the messag

17、es and the MT and ST substructures. The undefined primitives between the Plane Management (MIB) and the MT and ST are only required to activateldeactivate the concerned testing functions (see Figure 1). 2 MTP tester (MT) The MT is connected to the MTP as a user part, i.e. identified by a service ind

18、icator. It generates Message Signal Units (MSUs) containing a serial number (and possibly additional information) in the Signalling Information Field (SIF). On reception of these messages a check is performed to verify that the messages are delivered according to the defined performance criteria for

19、 the MTP. 2.1 Functions 2.1.1 Objectives and scope The MT is: - a possible tool for validation testing when traffic generation is needed whilst performing tests. However. other traffic generators may be used and not all test cases may be covered with the MT when performing validation tests; - the pr

20、eferred traffic generator for compatibility tests between different network operators. However, other traffic generators may be used for compatibility testing between different versions of the same system inside one national network; - a useful possible tool when performing network performance verif

21、ication tests for SS No. 7 networks which are in service. If international network performance verification should be needed, it would be the preferred traffic generator. Recommendation 4.755 (W3) 1 ITU-T RECMN*Q=755 73 4862573 05859L2 LTT Part d OMAP . . - . . . . . . Call Carol applicatknseniices

22、ag. MAP M I B FIGURE UQ.755 SS Na 7 marmgement and internai -LMI:#,.N- r. 14 I M M LMI E ASE ASE - LMI c (Note 6) (Me 6) X El 2 Recommendation 4.755 (W3) SCCP (Level 4) bL LM1 M E Y m L MTP (WlS 1-3) M E ITU-T RECMN*Q*755 93 = 48b259L 0585933 O36 MTP T1136720-91/d02 2.1.2 Main functions The main fun

23、ction is the generation of bidirectional test traffic, giving the possibility at the receiving node of analysing the received test traffic (e.g. detection of missequencing, duplication or loss of messages, verification of transfer delays . . .). Errors may be introduced in the SS No. 7 network (by e

24、xternal means to the testers) during the transmission of test traffic. 2.1.3 Architectural model The architectural model is as given in Figure 1. All procedures are located in the Layer Management Entity (LME), all other functions are located within the Management Information Base (MIB) and the Mana

25、gement Process (MP). 2.1.4 Implementation Only one implementation mode is to be described, and this will perform message generation, “turn around”, verification and termination. 2.1.5 Traffic modes There will be only one traffic mode, the “turn around” mode. However, the tester performing the “turn

26、around” function will fulfil basic message verification such as sequence checking and message counting. 2.1.6 Functional blocks Whilst keeping the single implementation mode, there are two functional roles which are identified during a test; the tester generating the traffic and the tester turning a

27、round the test messages. It is perfectly possible for a tester to be generating traffic towards one signalling point whilst performing the “turn around” role in another test to a different signalling point. 2.1.6.1 Generator The Generator role uses the services of various blocks within the MT. The t

28、est control function will confirm that the remote end is ready and able to start a test, then control the duration and termination of the test. The message generation function will then generate the appropriate traffic messages at the rate requested in the test Set-up. The generator will also contro

29、l the message lengths. The message verification function receives the messages returning from the turn around end and checks them for corruption, loss, missequencing and duplication. The MTP specific portion deals with generating the MTP transfer primitives and handling the incoming MTP primitives.

30、The OMM interface handles test requests from TMN, test supervision and control and the presentation and interpretation of test results. Recommendation Q.755 (03193) 3 ITU-T RECMN*Q.755 93 48b259L 0585934 T72 = 2.1.6.2 Turn around The turn around role uses the test control function to control the acc

31、eptance and supervision of a test. Test traffic arriving from the generator is checked by the message verification block, before being returned to the generator via the turn around function. The MTP specific portion again deals with the sending and receiving of MTP primitives. The OMM interface deal

32、s with test acceptance, test control and the presentation and interpretation of results. 2.1.7 Identification of test sequences A particular test sequence is identified by the point codes and network indicators of the two testers involved. Thus it is only possible to have one test at a time running

33、between two point codes. The GPC, the point code of the generating tester is included as an additional security feature. 2.1.8 Message rate considerations To secure delivery in sequence via MTP all test traffic messages use the identical code within the SLS-field. Thus they will use only one link of

34、 every linkset passed. This should be considered when defining the actual message rate. Using the same SLS-code after turn-around may or may not define the same links in the backward direction as in the forward direction as the load-sharing key is implementation dependent. 2.2 Procedures 2.2.1 Test

35、Set-up There are three possible phases during test Set-up: test request, test acceptance and test refusal. 2.2.1.1 Test request Once a test request has been received by the tester from OMAP a check will be made to ensure that no test already exists for the requested point code (turn around point cod

36、e TPC). If a clash is detected an error is returned to OMAP with an appropriate reason, the test already in place will not be affected. If a valid request is received then the necessary counters are initialized, and a guard timer is started to control test Set-up Ti. A test request message is then s

37、ent to the TPC. The information provided by the OMAP will include an indication of the required response to the receipt of an MTP status with cause network congestion. The conditions applying to the setting of this indication are to be defined within Recommendation 4.751. The default action is to st

38、op the test. It may be specifically requested by OMAP to report congestion indications, but continue the test. The indication is passed in the test request message and must be accepted by the turn around tester. NOTE - This procedure should only be used with extreme caution. 2.2.1.2 Test acceptance

39、2.2.1.2.1 By the turn around tester On reception of a test request message a check is performed to ensure that a test with the originating tester is not already in progress. If a test is found to be in progress then a test termination request message is sent, a report is made to OW and the original

40、test is terminated. If no test is found to be in progress then the turn around tester will request from OMAP to start a test from the respective point code. On receiving a negative response from OW (e.g. due to local conditions), a test refusal message is sent. A positive response will initiate the

41、sending of a test acceptance message and the initialization of the necessary counters. OMAP also specifies criteria for test termination. See 2.2.2. i apart from a). 2.2.1.2.2 By the generator The reception of a test acceptance message by the generator will cause the termination of the set-up timer

42、T1. The OMAP will be informed that a test is in progress, the generation of test traffic will begin. 4 Recommendation Q.755 (03/93) ITU-T RECMN*Q.755 93 48b259L 0585935 909 2.2.1.3 Test refusal If a test refusai message is received then the Set-up timer T1 is terminated, any counters initialized wil

43、l be cleared and a report is made to OMM. 2.2.1.4 Timer T1 Expiry If timer TI expires then any counters initialized will be cleared and a report is made to OMAP. It is assumed that the test request was lost and any subsequent test acceptance or refusal messages will be dealt with as an unexpected me

44、ssage. 2.2.2 Test duration 2.2.2.1 At the generator On receipt of a test acceptance message the test duration timer T2 is started, the messages are generated according to the rate information supplied by OMM. As each message is sent, the Messages Sent count is incremented. The value of this count is

45、 given as the serial number field within the test traffic message. The need for a supervision timer for each message is implementation dependent. The generating tester may place further information (e.g. a time stamp) in the additional data field of the test traffic message, this is not looked at by

46、 the turn around tester, however the additional data field should contain sufficient filler octets (coded all zeros) to give an overall message length as requested during test set-up by OW. When test traffic messages are received at the generator, the messages are checked by comparing the Generating

47、 Point Code field (GPC) with the testers own point code. As messages are terminated at the MT the messages received counter is incremented, and the message serial number is checked as a means of sequence validation. Any further checking may be done using the information in the additional octets fiel

48、d. 2.2.2.2 At the turn around tester Incoming messages are checked as in the generating tester. If the GPC is not the testers own point code, and a current test to the relevant point code is in existence, then the messages are turned around. The messages received counter is incremented and the seria

49、l number checked for missequencing. The OX and DPC of the MTP transfer indication are then swapped and the message formed into an MTP transfer request. 2.2.2.3 Response to missequencing If on checking the message serial number an error in sequence is detected then a report is made to OMAP which includes the message serial number and any additional filler octets. However, to stop a message loss causing all remaining messages to be seen as missequenced the message counter must be reset to the serial number of the message detected as missequenced. 2.2.3 Termination 2.2.3.1 By the