1、INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU SPECIFICATIONS OF SIGNALLING SYSTEM No. 7 TEST SPECIFICATION Q.784 Annex A (03/93) TTCN VERSION OF RECOMMENDATION Q.784 ITU-T Recommendation (2.784 - Annex A (Previously “CCITT Recommendation”) ITU-T RECMN*Q*
2、784 ANNEX*A 93 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 Recommendations on them with a view to standardizing telec
3、ommunications 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 topics. ITU-T Recommendation Q.784, Annex A was revised b
4、y 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 its place, the ITU Telecommunication Standardiza
5、tion Sector (ITU-T) was created as of 1 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 text to references containing the acronyms “CCITT
6、, 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 operating agency. In this Recommendation, the expre
7、ssion “Administration” is used for conciseness to indicate both a O ITU 1994 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 writing from the ITU. ITU-T R
8、ECMN*Q=784 ANNEX*A 93 H 4862593 0573035 74 CONTENTS Annex A . TTCN version of Recommendation 4.784 . A . 1 A.2 A.3 A.4. AS A.6 A.7 A.8 A.9 Scope Symbols and abbreviations (used in A.2 to A.4.5) . Test methodology . Explanation to the test specification . . ISUP Test list . Test Suite Overview Declar
9、ations Part . Constraints Part Dynamic Part . Recommendation Q.784 . Annex A (03/93) Page 1 1 1 1 2 4 7 12 15 21 1 ITU-T RECMN*Q.784 ANNEX*A 93 W Lid62593 0593036 720 UT Annex A Test Coord. Procedures LT - - TTCN version of Recommendation Q.784 (Helsinki, 1993) A.1 Scope This annex provides the test
10、 specification for the basic call procedures of CCITT SS No. 7 ISUP (Recommenda- tions Q.761-Q.764 and Q.767) based on the CCIT Recommendation X.292 (IS0 IS 9646). This test specification makes use of the Tree and Tabular Combined Notation (TTCN) and reflects the content of the test specification de
11、scribed in Recommendation 4.784. In ail cases of conflict between the text of Recommendation 4.784 and this TTCN annex, then Recommendation 4.784 shall take precedence. A.2 Symbols and abbreviations (used in A.2 to A.4.5) TTCN IUT Implementation Under Test ATS Abstract Test Suite ASP Abstract Servic
12、e Primitive PDU Protocol Data Unit PCO LT Lower Tester Tree and Tabular Combined Notation Point of Control and Observation UT Upper Tester LAB CAB UTA Lower Tester PCO between service provider and signalling point B Circuit PCO between service provider and signalling point B Upper Tester PCO at sign
13、alling point A A.3 Test methodology This test specification in TTCN makes use of the abstract test methodology as described below. The test methodology used for ISUP testing is called the distributed test method (see Figure A.l). With this test method an abstract configuration for testing is establi
14、shed, which does not constrain the implementation of test machines. The configuration consists of the implementation under test (IUT) and the tester. The main functionalities of the tester are seperated into a lower tester (LT) and an upper tester (UT). t 1 IUT SP A - - I t 1 CAB t 1 Serbice Provide
15、r T1163960-94/d01 FIGURE A. 1/Q.784 ISUP test method Recommendation Q.784 - Annex A (03/93) 1 - 1TLJ-T RECMN*Q*764 ANNEX*A 93 = 4662591 0593037 667 In principle, the lower tester has the capabilities to control and observe the implementation under test at its lower boundary via the underlying servic
16、e provider. The upper tester has the capabilities to control and observe the implementation under test at its upper boundary. For ISUP testing in particular, the lower tester controls and observes the implementation under test from the signalling point of view via the underlying service provider MTP
17、 and from the connection point of view via a predefined number of circuits. The upper tester controls and observes the implementation under test by handling calls. In addition the upper tester should control the MML-interface and should observe the indications for maintenance purposes. A.4. Explanat
18、ion to the test specification An abstract test suite (ATS) specification written in TTCN must contain the following four parts: - the overview, giving the structure of the test suite, for general information and understanding; - the declaration part, giving all the objects, e.g. constants, variables
19、, points of control and observation (PCOs), timers, protocol data unit types (PDU types) and abstract service primitive types (ASP types); - the constraints part, giving the actual values for protocol data units (PDUs) and abstract service primitives (ASPS); - the dynamic part, describing each test
20、case behaviour. A.4.1. Test suite overview The test suite overview is a sort of directory. It provides an index to the test suite and can be used for documentation and reference. The overview indicates the name of the test suite; references to the relevant protocol standards; information on the abst
21、ract test method and a test suite structure, an index to the test cases, test steps and defaults contained in the dynamic part. The relation between the testlist of Recommendation Q.784 and the TTCN test groups and test case names are indicated in the test suite structure and test case index tables.
22、 The test suite overview for this ISUP test specification is given in A.6. A.4.2. TTCN declarations The declaration part should mention all the objects used in the dynamic part. The TTCN notation provides a particular format for all sorts of objects to be declared. The declarations for ISUP are give
23、n in A.7. Subclause A.7 identifies: 0 Test suite parameters and test suite constants - These are introduced to enable test case selection procedures. 0 Test suite variables - These are declared for use in test cases, e.g. RSCReceived in test case ISUPB50203 ; 0 Three PCOs. These are used in the ISUP
24、 test suite: - LAB - Lower tester PCO between service provider and signalling point B. By means of this PCO ISUP signalling information is exchanged between the lower tester and the IUT. - CAB - Circuit PCO between service provider and signalling point B. By means of this PCO circuit control procedu
25、res, e.g. connectivity check and echo control check, are accomplished. - UTA - Upper tester PCO at signalling point A. Some kind of stimulus operations to generate and clear calls, to activate circuit supervision procedures, etc., are assumed. All timer identifiers and the corresponding duration. 2
26、Recommendation 4.784 - Annex A (03/93) ITU-T RECMN*d-iB4 ANNEXxA 93 486259L 0593038 5T3 M The ASP types which is an incomplete TTCN declaration. A TTCN ASP declaration consists of the ASP type identifier, the PCO type identifier and the ASP structure. The last part of this declaration is omitted, in
27、 order to create the same level of abstraction as described in the 4.784 test specification using the 4.780 methodology. 0 The PDU types for which the same approach described previously is applied. A.4.3. TTCN constraints The ASPS given in combination with the send and receive events in the dynamic
28、part are references to instances of ASP types. Every instance of an ASP type, called ASP constraint, specifies an actual ASP value. An ASP constraint may carry an PDU constraint. All ASP and PDU constraints are grouped in the TTCN constraints part. The constraints part for ISUP are given in A.8. Due
29、 to the high level of abstraction which is required, only the ASP constraint identifier and its ASP type identifier are described in this test suite. The actual values of the constraints are not envisaged. The ASPS used in this test suite are grouped into: - User ASPs - These ASPS are stimuli to est
30、ablish a call, to release a call, to suspend a call, to resume a call and to check the provision of tones and announcements. Maintenance ASPS - One maintenance ASP is declared to represent a maintenance indication from the IUT. - - mml ASPs - Several mml ASPs are described to enable the activation o
31、f circuit supervision procedures within ISUP. - Circuit ASPs - This catagory ASPS are exchanged by some functionality which enables circuit control procedures, e.g. connectivity check. - Call Set-up ASPs - The call Set-up ASPS represent the corresponding call Set-up PDUs in ISUP. Call release ASPs -
32、 The call release ASPs represent the corresponding call release PDUs in ISUP. - - Circuit supervision ASPs - The circuit supervision ASPs represent the corresponding circuit supervision PDUs in ISUP. A.4.4. TTCN dynamic part The TTCN dynamic part contains the main body of the test suite, i.e.: - The
33、 test cases grouped into test groups - Each test case represents one test purpose. Subclause A.9.1 contains the test cases representing the purposes as mentioned in the ISUP test list (see AS). The test steps grouped into the test step library - A test step can be called by all test cases defined in
34、 the test suite. A test step can be represented as a procedure call or subroutine as defined in a programming language. The ISUP test suite does use this TTCN construct e.g. to achieve pre-test conditions and to check specific circuit operations. The required test steps for the ISUP test suite are c
35、ontained in A.9.2. The default groups - If a test case or a test step refers to a default tree, then the content of the default tree covers additional alternatives to receive events specified in that test case or test step. In that case any received behaviour other than the expected behaviour as spe
36、cified in the test case or test step will be handled by the default tree. A very generic default tree for this ISUP test specification is specified in A.9.3. - - The test specification is based on the test methodology described above. By means of well chosen identifiers for points of control and obs
37、ervation (PCOs) and abstract service primitives (ASPs) the used test methodology is expressed. The identifications of the ASPS are selfexplaining. Although, the TTCN constraints part should clarify the contents of the ASPs, this is not done in order to create the same level of abstraction as describ
38、ed in the Q.784 test specification using the 4.780 methodology (the actual message content is not specified). Recommendation Q.784 - Annex A (03/93) 3 In this test specification only the method of “explicit final verdict” is used (i.e. in each leaf of the behaviour tree an entry occurs in the verdic
39、t column of the dynamic behaviour tables). If the leaf is an ATTACH construct (i.e. test step reference), this verdict has the following meaning: the verdict applies to each leaf of the behaviour tree of the test step. A.4.5. This TTCN version of Recommendation Q.784 is applicable for both validatio
40、n testing (VAT) and compatibility test- ing (CPT). It is a conceptual description of the test process which in noway implies any implementation of the test system. This means that in case of VAT the lower tester (LT) could be a test box or a real exchange with other supporting equipment. In case of
41、CPT the LT is a real exchange (SP B) with supporting equipment. Application of TTCN version for VAT and CPT AS ISUP Test list 1 Circuit supervision 1.1 Non-allocated circuits 1.2 Reset of circuits 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 Circuit group reset received 1.2.6 Circuit group reset sent 1.2.7 RSC rec
42、eived on an idle circuit RSC sent on an idle circuit RSC received on a locally blocked circuit RSC received on a remotely blocked circuit Circuit group reset received on remotely blocked circuits 1.3 Blocking of circuits 1.3.1 Circuit group blocking unblocking 1.3.1.1 CGB and CGU received 1.3.1.2 CG
43、B andCGU sent 1.3.2 Circuit blocking unblocking 1.3.2.1 BLO received 1.3.2.2 BLO sent 1.3.2.3 1.3.2.4 Blocking from both ends removal of blocking from one end IAM received on a remotely blocked circuit 1.4 Continuity check test call 1.4.1 CCR received successful 1.4.2 CCR sent successful 1.4.3 CCR r
44、eceived unsuccessful 1.4.4 CCR sent unsuccessful 1.4.5 Receipt of unreasonable signalling information messages 1.5.1 Receipt of unexpected messages 1 S.2 1.5.3 1.5.4 CCR received unsuccessful verify T27 timer 1.5 Receipt of unexpected messages during call set-up Receipt of unexpected messages during
45、 a call Confusion procedures for further study 4 Recommendation Q.784 - Annex A (03/93) Normal call set-up - Ordinary speech calls 2.1 Both way circuit selection 2.1.1 2.1.2 IAM sent by controlling SP IAM sent by non-controlling SP 2.2 Called address sending 2.2.1 En-bloc operation 2.2.2 Overlap ope
46、ration with SAM 2.3 Successful call set-up 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.3.6 2.3.7 Ordinary call with various indications in ACM Ordinary call with ACM CPG and ANM Ordinary call with various indications in CON Call switched via a satellite Echo control procedure for call set-up Blocking and unbloc
47、king during a call initiated Blocking and unblocking during a call received 3 Normal call release 3.1 3.2 3.3 3.4. 3.5 3.6 3.7 3.8 Collision of REL messages Calling party clears before any backward message Calling party clears before answer Calling party clears after answer Called party clears after
48、 answer Suspend initiated by the network Suspend and resume initiated by a calling party Suspend and resume initiated by a called party 4 Unsuccessful call set-up 4.1 Abnormal situation during a call 5.1 5.2 Timers Validate a set of known causes for release 5 Inability to release in response to an R
49、EL after ANM 5.2.1 T7 waiting for ACM or CON 5.2.2 T9 waiting for an answer message 5.2.3 T1 and T5 failure to receive an RLC 5.2.4 T6 waiting for RES Network message 5.2.5 T8 waiting for COT message if applicable 5.2.6 T12 and T13 failure to receive a BLA 5.2.7 Ti4 and TI5 failure to receive a UBA 5.2.8 T16 and T17 failure to receive an RLC 5.2.9 T18 and T19 failure to receive a CGBA 5.2.10 T20 and T21 failure to receive a CGUA 5.2.1 1 T22 and T23 failure to receive a GRA Reset of circuits during a call 5.3.1 Of an outgoing circuit 5.3.2 Of an incoming circuit 5.3 Rec
