ITU-T Q 780-1995 Signalling System No 7 Test Specification - General Description - Specifications of Signalling System No 7 (Study Group 11) 31 pp《7号信令系统测试准则-一般描述-NO 7信令系统的准则(第11研究.pdf

《ITU-T Q 780-1995 Signalling System No 7 Test Specification - General Description - Specifications of Signalling System No 7 (Study Group 11) 31 pp《7号信令系统测试准则-一般描述-NO 7信令系统的准则(第11研究.pdf》由会员分享，可在线阅读，更多相关《ITU-T Q 780-1995 Signalling System No 7 Test Specification - General Description - Specifications of Signalling System No 7 (Study Group 11) 31 pp《7号信令系统测试准则-一般描述-NO 7信令系统的准则(第11研究.pdf（31页珍藏版）》请在麦多课文档分享上搜索。

1、m Yb2CL Obi15653 521 m INTERNATIONAL TELECOMMUNICATION UNION ITU=T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU SPECIFICATIONS OF SIGNALLING SYSTEM No. 7 Q.780 (1 0/95) SIGNALLING SYSTEM No. 7 TEST SPECIFICATION - GENERAL DESCRIPTION ITU-T Recommendation Q.780 (Previously “CCITT Recommendation”)

2、= 4b2591 0635654 4b8 FOREWORD The IT-T (Telecommunication Standardization Sector) is a permanent organ of the International Telecommunication Union (ITU). The ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommen- dations on them with a view to standardizin

3、g telecommunications on a worldwide basis. The World Telecommunication Standardization Conference (WTSC), which meets every four years, establishes the topics for study by the IT-T Study Groups which, in their turn, produce Recommendations on these topics. The approval of Recommendations by the Memb

4、ers of the ITU-T is covered by the procedure laid down in WTSC Resolution No. 1 (Helsinki, March 1-12, 1993). ITU-T Recommendation 4.780 was revised by ITU-T Study Group 11 (1993-1996) and was approved under the WTSC Resolution No. 1 procedure on the 17th of October 1995. NOTE In this Recommendation

5、, the expression “Administration” is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. O ITU 1996 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including

6、photocopying and microfilm, without permission in writing from the IT. m 4862593 0635655 3T4 m CONTENTS Page 1 2 3 4 5 6 7 . 1 General 1 1 General principles of test specifications . Scope of the test specification Field of application 1 Method of application 2 5.1 Test principles . 2 5.2 Categories

7、 of tests 2 5.3 Structure of test Recommendations 3 5.4 Test configurations 3 Functional requirements imposed by the test specification 6.1 MTP Level 1 4 6.2 MTP Level 2 . 4 6.3 MTP Level 3 5 . . 4 . . 6.4 i“ 6 6.5 ISDN User Part 6 . . 6.6 UNI-to-uNI 7 6.7 SCCP 7 6.8 TC 8 Signalling link monitor(s)

8、8 . Recommendation Q.780 (10/95) 1 SUMMARY This Recommendation is an introductory overwiew of Signalling System No. 7 test specifications contained in Recommendations 4.781 to 4.788. It defines the scope and purpose of those test specifications. It also propose both general guidelines and guidelines

9、 specific to the particular protocol under test. 11 Recommendation Q.780 (10/95) 4862591 0635657 I177 D Recommendation Q.780 SIGNALLING SYSTEM NO. 7 TEST SPECIFICATION - GENERAL DESCRIPTION (Melbouume, 1988; modified ar Helsinki, 1993; revised in 1995) 1 General This Recommendation is an introductor

10、y Recommendation to the test specifications of Signalling System No. 7. The test specifications are contained in Recommendations 4.781 to 4.788. This Recommendation defines the scope and purpose of the test specification and identifies guidelines that are either specific to the particular protocol u

11、nder test, or are more general. In addition, it identifies functional requirements imposed by the test specification. 2 General principles of test specifications There are two types of testing - validation and compatibility. Validation testing aims to verify a given implementation of a protocol in a

12、ccordance with the relevant Recommendation. Compatibility testing aims to verify the proper interworking of two or more protocol implementation. The specification is independent of a given implementation and does not generally imply any modification of the signalling point under test. However, it is

13、 recognized that certain tests require capabilities of the system that are not explicitly defined in the relevant Recommendation, and these capabilities may not be present in all implementations. As a consequence, certain tests may not be possible in ail implementations. Therefore, for validation te

14、sting individual Administrations may unilaterally choose the tests to be performed, for compatibility testing bilateral agreement is required. 3 Scope of the test specification The test specification is intended to cover all aspects of Signalling System No. 7. The following Recommendations are initi

15、ally produced as follows: - 4.781 covers MTP Level 2. See Q.703. - - - - - - - 4.782 covers MTP Level 3. See Q.704-4.707. 4.783 covers “UP. See 4.721-Q.724. Q.784 covers ISDN User Part for basic call control part. See Q.761-Q.764. Q.785 covers ISDN User Part for supplementary service part. See 4.730

16、. 4.786 covers SCCP. See 4.711-4.714. 4.787 covers TC. See Q.771-4.775. Q.788 covers UNI to UNI compatibility testing. See Q.699, 4.767 and 4.931. The test specification is not a definition of the protocol. The protocol Recommendations are as noted above. 4 Field of application The test specificatio

17、n applies in the international network, and if appropriate in the national network. In the international network, the actual tests to be performed will be the subject of appropriate bilateral agreements between the two or more AdministrationsROAs concerned. Recommendation 4.780 (10/95) 1 m 4862573 0

18、635658 003 = 5 Method of application The test specifications fulfil the requirements for both Validation and compatibility testing and are specific to only the given protocol under test. This clause further identifies the principles and configurations as well as the structure of the test specificati

19、ons themselves. 5.1 Test principles For a given protocol test specification, it is assumed that the underlying layers have been implemented correctly and therefore the tests specified are only concerned with the given protocol under test. In so far as is practical, tests are intended to test the maj

20、or aspects of the given protocol and associated call control functions including normal and abnormal behaviour. It is understood that testing all aspects of abnormal behaviour is not realizable. Compatibility aspects include the processing of spare fields as defined in 6.2/Q.701, and validation test

21、s should be made to check that they are ignored when received. The following criteria are used in defining test requirements in subsequent Recommendations: a) Tests should not imply an implementation To improve the functional description and understanding of the behaviour of the signalling system, t

22、he test specifications model the internal behaviour of the protocols using functional groupings. The functional groupings are only used to facilitate understanding and do not impose constraints on an implementation. Compatibility is only measured against the external behaviour of the protocol, as de

23、scribed in the protocol specifications. If exceptions to this rule are identified they are specified in the corresponding test specification. b) Testing requirements should be independentfrom the testing environment Test requirements are not meant to dictate a specific test environment. Hence, those

24、 executing tests should not feel constrained to any specific test generation mechanism (see Recommendation Q.755), traffic simulator or monitoring equipment solely because of the given test specification. c) Test Recommendations are intended to be test specification guidelines It is possible to extr

25、act from a test Recommendation, a subset of the tests which are appropriate for testing within a selected domain of functionality. These tests may need to be supplemented with specific user/system tests. In order to achieve this, guidance is given to the tester wherever possible, e.g. the purpose of

26、 the test, how it could be performed, how tests are selected, etc. Tests which are conditional on the presence of optional items should also be identified. 5.2 Categories of tests The test specification fulfils the requirements for both validation and compatibility testing. All tests are identified

27、as either Validation Tests (VAT) andor Compatibility Tests (CPT). All tests in the test specification are validation tests (VAT), and in addition those marked with an asterisk are also Compatibility Tests (CPT). Since the UNI-to-UNI tests in Recommendation Q.788 are all compatibility tests, the aste

28、risk is implied. The explanation of these categories follows. 5.2.1 Validation testing The function of validation testing is to give a level of confidence that a given implementation in accordance with the relevant Recommendations of the Signalling System No. 7. These validation tests could apply bo

29、th in the national and international networks. The validation test is a prerequisite of compatibility testing (see 5.2.2) and is performed under the responsibility of each AdministratiodROA. These tests will generally be performed without the cooperation of another AdministrationROA, although this i

30、s not precluded should this arrangement prove convenient. Validation testing will be performed on a signalling point that is not in service. 2 Recommendation Q.780 (10195) 4862593 Ob35659 T4T The validation test is performed on a signalling point. In the case of SCCP, testing is performed on a signa

31、lling node. It is suggested that the validation test, or subset, is repeated when the implementation is upgraded or modified in any functional way. Validation testing may require the use of a simulator to check the operation of the signalling pointhode under test. The specification of this simulator

32、 is not explicitly covered by these Recommendations although the general requirements are implicit in the test specification. In validation testing, the signalling pointhode under test is called SP “A”. 5.2.2 Compatibility testing The objective of compatibility testing is to give a level of confiden

33、ce that two different implementations are able to interwork. To perform compatibility testing, the various nodes involved are interconnected. The specification is written for the interconnection of two given implementations for the first time. For subsequent interconnections of the same two implemen

34、tations, a subset of tests may prove sufficient. These tests will not only be performed on a new signalling pointhode, but also on a signalling poinlnode already in service. Each Recommendation identifies a list of tests that may be suitable for compatibility testing, but the actual tests to be perf

35、ormed will be bilaterally agreed between the AdministrationsROAs concerned. Certain of the tests identified in the test list as compatibility tests may disturb the operation of the exchange, whereas others may not. Any tests which may cause disturbance to the exchange should be carefully selected to

36、 meet the operational criteria of the two Administrations/ROAs. The satisfactory completion of compatibility testing should be bilaterally agreed. When a change to the signalling network is made, tests selected from those identified as compatibility tests may be appropriate. In general the tests per

37、formed under these circumstances will be the minimum number to ensure that compatibility between points in the network is still maintained. In compatibility testing, all signalling pointdnodes are simultaneously under test. 5.3 Structure of test Recommendations The individual test Recommendations sh

38、ould contain the following: - Introduction - This clause describes the outline of the individual test specification. - Scope of test - This clause mentions the functions to be tested. - Objective of test - This clause explains the basic concept for deciding test items or test configurations. - Test

39、environment - This clause describes the nature of the facilities necessary to perform testing such as traffk generatorheminator and logging equipment for test traffic. Test configuration - This clause describes the configurations of SPs and link(s) or signalling relations which are necessary to perf

40、orm tests. Presentation of test traffic - This clause illustrates the format of the messages for testing such as address type and the content of individual data fields. Test list - This clause presents test items categorized on a certain criterion. Test script - This clause illustrates the flows of

41、messages transferred to perform the required test. It includes test numbers, reference to protocol Recommendations, title, subtitle, purpose, pre-test conditions, configuration, SP types, test type, message sequence described by arrow diagrams and test description. - - - - 5.4 Test configurations Th

42、e test configurations required for both types of tests are similar but not identical. Recommendation Q.780 (10/95) 3 462593 O635660 763 W 5.4.1 Validation test configuration For validation testing, the point under test is connected to the test environment and becomes part of the “test configuration”

43、. The test configuration satisfies all of the following three criteria: - the point under test will be connected by one or more signalling link sets (real or simulated), which may or may not be interconnected; the capability of generation and reception of test traffk, where applicable; the ability t

44、o perform the described test, notably the facility to store and analyse messages to the appropriate degree. - - 5.4.2 Compatibility test configuration For compatibility testing all the signalling points are combined into one large system under test satisfying all of the following four criteria: - -

45、- the nodes of the system under test will be interconnected by one or more real signalling link sets; the capability of generation and reception of test and real traffic, where applicable; the ability to perform the described test, notably the facility to store and analyse messages to the appropriat

46、e degree; the ability to monitor call control and circuit supervision activities, where applicable. - 6 The functional description that follows is intended to identify the functional requirements imposed by the test specification. It does not imply any physical partitioning of equipment in real syst

47、ems. See also 2.2.UQ.701. Functional requirements imposed by the test specification 6.1 MTP Level 1 The test specification assumes the availability of a suitable signalling data link with the parameters identified in the relevant Q. Recommendations, e.g. Q.702 (referring to Recommendation G.82 1). I

48、n validation testing the signalling data link may be a pseudo-signalling data link, in which case it should preferably have similadidentical characteristics to the signalling data links likely to be encountered in service. Simulation of deterioration of the transmission link may not be necessary if

49、the emulator includes the capability to simulate abnormal conditions on the signalling data link. In compatibility testing, the signalling data link is a real signalling data link. 6.2 MTPLevel2 6.2.1 MTP Level 2 validation testing The MTP Level 2 validation test environment consists of the following items (see Figure 1): - the MTP Level 3 simulator; - the test simulator; - - the signalling data link. the Signalling link monitor (see clause 7); 6.2.2 MTP Level 2 Compatibility testing MTP Level 2 compatibility testing assumes both MTP Level 2 implementations have been validated.