ETSI TS 101 804-2-2004 Methods for Testing and Specification (MTS) Conformance Test Specification for ITU-T H 225 0 (Terminal Gatekeeper and Gateway) Part 2 Test Suite Structure an.pdf

《ETSI TS 101 804-2-2004 Methods for Testing and Specification (MTS) Conformance Test Specification for ITU-T H 225 0 (Terminal Gatekeeper and Gateway) Part 2 Test Suite Structure an.pdf》由会员分享，可在线阅读，更多相关《ETSI TS 101 804-2-2004 Methods for Testing and Specification (MTS) Conformance Test Specification for ITU-T H 225 0 (Terminal Gatekeeper and Gateway) Part 2 Test Suite Structure an.pdf（57页珍藏版）》请在麦多课文档分享上搜索。

1、 ETSI TS 101 804-2 V2.1.1 (2004-11)Technical Specification Methods for Testing and Specification (MTS);Conformance Test Specification for ITU-T H.225.0(Terminal, Gatekeeper and Gateway);Part 2: Test Suite Structure and Test Purposes (TSS Essential, or potentially Essential, IPRs notified to ETSI in

2、respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to

3、 the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specification (TS) has been produced by ETSI Technical Committee Methods for Testing and Specificatio

4、n (MTS). The present document is part 2 of a multi-part deliverable covering the H.225.0 protocol for Terminal, Gatekeeper and Gateway as identified below: Part 1: “Protocol Implementation Conformance Statement (PICS) proforma“; Part 2: “Test Suite Structure and Test Purposes (TSS Part 3: “Abstract

5、Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing (PIXIT) proforma“. ETSI ETSI TS 101 804-2 V2.1.1 (2004-11) 6 1 Scope The present document specifies the Test Suite Structure and Test Purposes (TSS Conformance Test Specification for ITU-T H.225.0 (Terminal, Gatekeepe

6、r and Gateway); Part 1: Protocol Implementation Conformance Statement (PICS) proforma“. 2 ITU-T Recommendation H.323: “Packet-based multimedia communications systems“. 3 ITU-T Recommendation H.225.0 (2000): “Call signalling protocols and media stream packetization for packet-based multimedia communi

7、cation systems“. 4 ITU-T Recommendation Q.931: “ISDN user-network interface layer 3 specification for basic call control“. 5 ISO/IEC 9646-1: “Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts“. 6 ISO/IEC 9646-2: “Informat

8、ion technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 2: Abstract Test Suite specification“. 7 ISO/IEC 9646-3: “Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 3: The Tree and Tabular Combined

9、 Notation (TTCN)“. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions given in ITU-T Recommendation H.323 2, ITU-T Recommendation H.225.0 3, ISO/IEC 9646-1 5, ISO/IEC 9646-2 6, ISO/IEC 9646-3 7 and the following apply: Basic Call Contr

10、ol (BCC): signalling protocol associated with the DSS1 - ISDN Basic Call control procedures of ITU-T Recommendation Q.931 4 ETSI ETSI TS 101 804-2 V2.1.1 (2004-11) 7 inopportune: test purpose covering a signalling procedure where an inopportune message (type of message not expected in the IUT curren

11、t state) is sent to the IUT syntactically invalid: test purpose covering a signalling procedure where a valid (expected in the current status of the IUT) but not correctly encoded (unknown or incorrect parameter values) message is sent to the IUT, which shall react correctly and eventually reject th

12、e message test purpose: non-formal test description, mainly using text NOTE: This test description can be used as the basis for a formal test specification (e.g. Abstract Test Suite in TTCN). See ISO/IEC 9646-2 6. valid: test purpose covering a signalling procedure where all the messages sent to or

13、received from the IUT are valid (expected in the current status of the IUT) and correctly encoded 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: ACF Admission ConFirm ADM ADMission APDU Application Protocol Data Unit ARJ Admission ReJect ARQ Admission

14、ReQuest ATS Abstract Test Suite BCC Basic Call Control BCF Bandwidth ConFirm BND Bandwidth BRJ Bandwidth ReJect BRQ Bandwidth ReQuestDCF Disengage ConFirm DGK Destination GateKeeper DIS DISengage DRJ Disengage ReJect DRQ Disengage ReQuest DRQ Disengage Request GCF Gatekeeper ConFirm GDR Gatekeeper D

15、iscovery Request GK GateKeeper GRJ Gatekeeper ReJect GRQ Gatekeeper ReQuest GW GateWay I InopportuneIUT Implementation Under Test LAN Local Area Network LCF Location ConFirmLOC LOCation LRJ Location ReJect LRQ Location ReQuest MCU Multipoint Control Unit MSI Manufacturer Specific Information PDU Pro

16、tocol Data Unit PER Packed Encoding Rules PHA PHase A: call setup signalling procedures PHE PHase E: call termination signalling procedures PICS Protocol Implementation Conformance Statement PIXIT Protocol Implementation eXtra Information for Testing RAS Registration, Admission and Status RCF Regist

17、er ConFirm REG REGistration RIP Request In Progress RRJ Register ReJect ETSI ETSI TS 101 804-2 V2.1.1 (2004-11) 8 RRQ Register ReQuest S Syntactically invalid STA STAtus TCP Transmission Control Protocol TE TErminalTP Test Purpose TSS Test Suite Structure TTCN Testing and Test Control Notation U0 Nu

18、ll call state U1 Call Initiated call state U10 Active call state U2 Overlap Sending call state U3 Outgoing Call Proceeding call state U4 Call Delivered call state U7 Call Received call state U9 Incoming Call Proceeding call state UCF Unregistration ConFirm UDP User Datagram Protocol URG UnReGistrati

19、on URJ Unregistration ReJect URQ Unregistration ReQuest 4 Architecture and Test Suite Structure (TSS) 4.1 Architecture The items to be tested can be one of the following: Terminal, Gatekeeper, Gateway or Destination Gatekeeper. They are a part of a Packet Based Network using a LAN with TCP/IP (see f

20、igure 1). Terminal Gatekeeper Gateway Destination Gatekeeper LAN TCP/IP Figure 1: Network architecture ETSI ETSI TS 101 804-2 V2.1.1 (2004-11) 9 The Implementation Under Test (IUT, see ISO/IEC 9646-1 5) for which this Test purpose specification applies consists of the H.225.0 terminal to gatekeeper

21、signalling (RAS) and the H.225.0 call signalling (BCC) (see figure 2). IUT H.225.0 Terminal to Gatekeeper signalling RAS H.225.0 call signalling BCC UDP TCP IP (LAN) Figure 2: Protocol architecture 4.2 Test Suite Structure (TSS) The Test Suite Structure follows the network architecture and the proto

22、col architecture. The first level is divided into 2 groups according to the protocol: RAS and BCC. The second level describes the IUT, for RAS either endpoint or gatekeeper, for BCC either endpoint (terminal or gateway), gatekeeper or destination gatekeeper. For the RAS protocol, each process is inc

23、luded in a corresponding sub-group: Gatekeeper Discovery Request (GDR), Registration (REG), Admission (ADM), LOC (Location), BND (Bandwidth), URG (Unregistration), DIS (Disengage), STA (Status) and Request in Progress (RIP). For BCC, 2 call phases are considered: phase A and phase E, each one formin

24、g a sub-group of BCC. Inopportune behaviour and syntactically invalid messages are tested in the sections I and S which are sub-divided according to the call states. Protocol IUT type Process/Phase/ Test type Call state RAS Endpoint (TE) GDR REG ADM LOCBND URG DIS STA RIP Gatekeeper (GK) GDR REG ADM

25、 LOC BND URG DIS STA RIP BCC Endpoint (TE) PHA PHE I S Gatekeeper (GK) PHA PHE I S ETSI ETSI TS 101 804-2 V2.1.1 (2004-11) 10Protocol IUT type Process/Phase/ Test type Call state Destination Gatekeeper (DGK) PHA PHE I S 5 Test Purposes (TP) 5.1 Introduction 5.1.1 TP naming convention Table 1: TP ide

26、ntifier naming convention scheme Identifier: _ = type of IUT TE = terminal or endpoint GK, DGK RAS or BCC if RAS: GDR, REG, ADM, LOC, BND, URG, DIS, STA or RIP if BCC: PHA, PHE, I, S U00, U01, U02, U03, U04, U07, U09 or U10 = sequential number (01-99) 5.1.2 State definitions 5.1.2.1 State definition

27、 for BCC For the BCC protocol, the call states of ITU-T Recommendation Q.931 4 for the user side are followed. 5.1.3 TP structure Each TP has been written in a manner, which is consistent with all other TPs. The intention of this is to make the TPs more readable and checkable. A particular structure

28、 has been used and this is illustrated in table 2. This table should be read in conjunction with any TP, i.e. use a TP as an example to fully understand the table. ETSI ETSI TS 101 804-2 V2.1.1 (2004-11) 11Table 2: Structure of a single TP for H.225.0 TP part Text Example Header tab TE_RAS_GDR_01 (s

29、ee table 1) clause 0.0.0 Stimulus Ensure that the IUT in the idle state having sent a XXX message see below for message structure on receipt of a YYY message or to request a . Reaction sends, does, etc. . if the action is sending see below for message structure , etc. Message structure message conta

30、ining a GRQ, RRQ, SETUP, FACILITY, CONNECT, etc. a) b) or encoded as or including and back to a or b, RasAddress, callServices, etc. Bearer capability, Facility, etc. NOTE: Text in italics will not appear in TPs and text between is filled in for each TP and may differ from one TP to the next. 5.1.4

31、Test strategy As the base standard ITU-T Recommendation H.225.0 3 contains no explicit requirements for testing, the TPs were generated as a result of an analysis of the base standard and the corresponding PICS proforma. The TPs are only based on conformance requirements related to the externally ob

32、servable behaviour of the IUT, over the TCP or UDP interface, and are limited to conceivable situations to which a real implementation is likely to be faced. As indicated by the existence of TS 101 804-3 (see foreword), the intention is to derive the test purposes to an abstract test suite in TTCN.

33、Consequently the test purposes are written in a manner, which fit the TTCN methodology, and will consist of the textual documentation of the test cases. 5.2 TPs for H.225.0 All PICS items referred to in this clause are as specified in TS 101 804-1 1. Unless specified otherwise, the messages indicate

34、d are valid and contain at least the mandatory parameters and possibly optional parameters. 5.2.1 RAS 5.2.1.1 Endpoint (TE) 5.2.1.1.1 Gatekeeper Discovery Request (GDR) NOTE: When multicast or unicast is not specified, both modes are accepted for GRQ message. Selection: IUT supports Discovery messag

35、es, PICS T_RM1 RAS_TE_GDR_01 clauses 7.2.1 2 and 7.8 3 Ensure that the IUT having sent a valid GRQ message in unicast mode, with the gatekeeper Identifier set to a value other than NULL, on receipt of a GCF message, considers to have completed the GKDiscovery procedure successfully. ETSI ETSI TS 101

36、 804-2 V2.1.1 (2004-11) 12RAS_TE_GDR_02 clauses 7.2.1 2 and 7.8 3 Ensure that the IUT having sent a valid GRQ message in multicast mode to the well-known Discovery Multicast Address and gatekeeperIdentifier missing or set to NULL, on receipt of a GCF message, considers to have completed its GKDiscov

37、ery procedure successfully. RAS_TE_GDR_03 clauses 7.2.1 2 and 7.8 3 Ensure that the IUT having sent a valid GRQ message in multicast mode to the well-known Discovery Multicast Address and with gatekeeperIdentifier missing or set to NULL, on receipt of multiple GCF message from different gatekeepers,

38、 considers to have completed its GKDiscovery procedure successfully with one of them. RAS_TE_GDR_04 clauses 7.2.1 2 and 7.8 3 Ensure that the IUT having sent a valid GRQ message, on receipt of a GRJ message with a value in the rejectreason field, does not consider to have completed its GKDiscovery p

39、rocedure successfully. RAS_TE_GDR_05 clauses 7.2.1 2, 7.8 3 and 7.19 3 Ensure that the IUT having sent a GRQ message, upon the first expiry of default timer for GRQ message, re-sends the same GRQ message. Selection: IUT supports GRQ timer, PICS T_TI1 RAS_TE_GDR_06 clauses 7.2.1 2, 7.8 3 and 7.19 3 E

40、nsure that the IUT having sent a GRQ message for the second time, on receipt of GCF message before the expiry of timer for a GRQ message, considers to have completed its GKDiscovery procedure successfully. Selection: IUT supports GRQ timer, PICS T_TI1 RAS_TE_GDR_07 clauses 7.2.1 2, 7.8 3 and 7.19 3

41、Ensure that the IUT having already sent a GRQ message for two times, on the expiry of the timer for a GRQ message, does not re-send the same GRQ message again. Selection: IUT supports GRQ timer, PICS T_TI1 5.2.1.1.2 Registration phase (REG) RAS_TE_REG_01 clauses 7.2.2 2 and 7.9 3 Ensure that the IUT

42、 before attempting a call, sends a RRQ message. RAS_TE_REG_02 clauses 7.2.2 2 and 7.9 3 Ensure that the IUT having sent a valid RRQ message on receipt of a RCF message, considers to have completed its Registration procedure successfully. RAS_TE_REG_03 clauses 7.2.1 2, 7.2.2 2 and 7.9 3 Ensure that t

43、he IUT having sent a valid RRQ message on receipt of a RRJ message, restarts a gatekeeper discovery procedure. RAS_TE_REG_04 clauses 7.2.2.1 2 and 7.9 3 Ensure that the IUT, having previously registered successfully, to keep the registration alive, sends a lightweight RRQ with the KeepAlive field se

44、t to TRUE. Selection: IUT supports the use of lightweight RRQ, PICS T_CSC8 RAS_TE_REG_05 clauses 7.2.2 2, 7.9 3 and 7.19 3 Ensure that the IUT having sent a RRQ message, upon the first expiry of timer for a RRQ message, re-sends the same RRQ message. Selection: IUT supports RRQ timer, PICS T_TI2 ETS

45、I ETSI TS 101 804-2 V2.1.1 (2004-11) 13RAS_TE_REG_06 clauses 7.2.2 2, 7.9 3 and 7.19 3 Ensure that the IUT having sent a RRQ message for the second time, on receipt of RCF message before the expiry of timer for a RRQ message, considers to have completed its Registration procedure successfully. Selec

46、tion: IUT supports RRQ timer, PICS T_TI2 RAS_TE_REG_07 clauses 7.2.2 2, 7.9 3 and 7.19 3 Ensure that the IUT having already sent a RRQ message for two times, upon the second expiry of timer for a RRQ message, does not re-send the same RRQ message again. Selection: IUT supports RRQ timer, PICS T_TI2

47、5.2.1.1.3 Admission phase (ADM) RAS_TE_ADM_01 clauses 7.2.4 2, 8 2 and 7.11 3 Ensure that the IUT, when it is registered with the gatekeeper, sends a valid ARQ before attempting a call. RAS_TE_ADM_02 clauses 7.2.4 2, 8 2 and 7.11 3 Ensure that the IUT, when it is registered with the gatekeeper, on r

48、eceipt of a SETUP message, sends a valid ARQ. RAS_TE_ADM_03 clauses 7.2.4 2, 8 2 and 7.11 3 Ensure that the IUT, when it is registered with the gatekeeper having sent an ARQ message in response to a SETUP message, on receipt of an ACF, proceeds with the call. RAS_TE_ADM_04 clauses 7.2.4 2, 8 2 and 7

49、.11 3 Ensure that the IUT, when it is registered with the gatekeeper, on receipt of a SETUP message, having sent an ARQ message, on receipt of an ARJ, releases the call. RAS_TE_ADM_05 clauses 7.2.4 2 and 7.11 3 Ensure that the IUT, when it is registered with the gatekeeper on receipt of a SETUP message, having sent an ARQ message, on receipt of an ACF with the irrFrequency, proceeds with the call and sends an IRR message in the requested frequency. RAS_TE_