SIST EN 300 497-9 V0.3.2:2003

SLOVENSKI STANDARD
01-december-2003
'LJLWDOQHL]EROMãDQHEUH]YUYLþQHWHOHNRPXQLNDFLMH'(&7±6NXSQLYPHVQLN&,±
.QMLåQLFDSUHVNXãDOQLKSULPHURY7&/±GHO$EVWUDNWQLSUHVNXãDOQLQL]$76]D
RPUHåQRSODVW1:.±)LNVQDUDGLMVND]DNOMXþLWHY)7
Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI); Test
Case Library (TCL); Part 9: Abstract Test Suite (ATS) for Network (NWK) layer - Fixed
radio Termination (FT)
Ta slovenski standard je istoveten z: EN 300 497-9 Version 0.3.2
ICS:
33.070.30 'LJLWDOQHL]EROMãDQH Digital Enhanced Cordless
EUH]YUYLþQHWHOHNRPXQLNDFLMH Telecommunications (DECT)
'(&7
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

European Standard (Telecommunications series)
Digital Enhanced Cordless Telecommunications (DECT);
Common Interface (CI); Test Case Library (TCL);
Part 9: Abstract Test Suite (ATS) for Network (NWK) layer -
Fixed radio Termination (FT)
2 ETSI EN 300 497-9 V0.3.2 (1999-09)
Reference
REN/DECT-040131-9 (4lq9011c.PDF)
Keywords
DECT, network, FT, testing, ATS, TTCN
ETSI
Postal address
F-06921 Sophia Antipolis Cedex - FRANCE
Office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Internet
secretariat@etsi.fr
Individual copies of this ETSI deliverable
can be downloaded from
http://www.etsi.org
If you find errors in the present document, send your
comment to: editor@etsi.fr
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1999.
All rights reserved.
ETSI
3 ETSI EN 300 497-9 V0.3.2 (1999-09)
Contents
Intellectual Property Rights.5
Foreword .5
1 Scope.6
2 References.6
3 Definitions and abbreviations .7
3.1 Definitions . 7
3.2 Abbreviations. 7
4 Abstract Test Method (ATM) .8
4.1 ATM . 8
4.2 DLC primitives . 9
4.2.1 S-SAP primitives. 9
4.2.2 B-SAP primitives . 12
4.3 TC execution sequence . 12
5 Untestable Test Purposes (TP).12
5A Control protocol .12
6 ATS Conventions.13
6.1 Naming conventions . 13
6.1.1 Declarations part . 13
6.1.1.1 Test suite type, ASP and PDU type definitions . 13
6.1.1.2 Test Suite Operations (TSO) definitions. 13
6.1.1.3 Test Suite Parameter (TSP) declarations . 13
6.1.1.4 Test Case Selection (TCS) expression definitions. 14
6.1.1.5 Test Suite Constant (TSC) declarations. 14
6.1.1.6 Test Suite Variable (TSV) declarations. 14
6.1.1.7 Test Case Variable (TCV) declarations. 14
6.1.1.8 Point of Control and Observation (PCO) declarations. 14
6.1.1.9 Timer declarations . 14
6.1.1.10 ASP type definitions . 15
6.1.1.11 PDU type definitions . 15
6.1.1.12 Alias definitions. 15
6.1.2 Constraints part . 15
6.1.3 Dynamic part. 16
6.1.3.1 Test Case (TC) identifier . 17
6.1.3.2 Test Step (TS) identifier . 17
6.1.3.3 Default identifier. 17
6.1.3.4 General aspects. 17
6.1.3.5 ATS abbreviations . 17
6.2 Implementation conventions . 18
6.2.1 Declaration part. 18
6.2.2 Constraint part. 18
6.2.3 Dynamic part. 18
6.2.4 Documentation . 19
6.2.5 Coding of some information elements. 19
6.2.6 Order of information elements . 19
ETSI
4 ETSI EN 300 497-9 V0.3.2 (1999-09)
Annex A (normative): Abstract test suite for NWK testing.20
A.1 The TTCN Graphical form (TTCN.GR).20
A.2 The TTCN Machine Processable form (TTCN.MP) .20
Annex B (normative): Partial PIXIT proforma.21
B.1 Identification summary .21
B.2 ATS summary .21
B.3 Test laboratory .21
B.4 Client identification .21
B.5 SUT .22
B.6 Protocol layer information .22
B.6.1 Protocol identification. 22
B.6.2 IUT information. 23
Annex C (normative): Protocol Conformance Test Report (PCTR) Proforma for DECT
NWK .32
C.1 Identification summary .32
C.1.1 Protocol conformance test report . 32
C.1.2 IUT identification . 32
C.1.3 Testing environment . 32
C.1.4 Limits and reservation. 33
C.1.5 Comments . 33
C.2 IUT Conformance status .33
C.3 Static conformance summary.33
C.4 Dynamic conformance summary.34
C.5 Static conformance review report .34
C.6 Test campaign report.35
C.7 Observations.37
Bibliography.38
History.39
ETSI
5 ETSI EN 300 497-9 V0.3.2 (1999-09)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect
of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server
(http://www.etsi.org/ipr).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in 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 European Standard (Telecommunications series) has been produced by ETSI Project Digital Enhanced Cordless
Telecommunications (DECT).
The present document is part 9 of a multi-part EN covering the Common Interface (CI) Test Case Library (TCL), as
identified below:
Part 1: "Test Suite Structure (TSS) and Test Purposes (TP) for Medium Access Control (MAC) layer";
Part 2: "Abstract Test Suite (ATS) for Medium Access Control (MAC) layer - Portable radio Termination (PT)";
Part 3: "Abstract Test Suite (ATS) for Medium Access Control (MAC) layer - Fixed radio Termination (FT)";
Part 4: "Test Suite Structure (TSS) and Test Purposes (TP) - Data Link Control (DLC) layer";
Part 5: "Abstract Test Suite (ATS) - Data Link Control (DLC) layer";
Part 6: "Test Suite Structure (TSS) and Test Purposes (TP) - Network (NWK) layer - Portable radio Termination
(PT)";
Part 7: "Abstract Test Suite (ATS) for Network (NWK) layer - Portable radio Termination (PT)";
Part 8: "Test Suite Structure (TSS) and Test Purposes (TP) - Network (NWK) layer - Fixed radio Termination
(FT)";
Part 9: "Abstract Test Suite (ATS) for Network (NWK) layer - Fixed radio Termination (FT)".
National transposition dates
Date of adoption of this EN: 27 August 1999
Date of latest announcement of this EN (doa): 30 November 1999
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 May 2000
Date of withdrawal of any conflicting National Standard (dow): 31 May 2000
ETSI
6 ETSI EN 300 497-9 V0.3.2 (1999-09)
1 Scope
The present document contains the Abstract Test Suite (ATS) to test the Network (NWK) layer, Fixed radio
Termination (FT).
The objective of this test specification is to provide a basis for approval tests for DECT equipment giving a high
probability of air interface inter-operability between different manufacturer's DECT equipment. This test specification
contains the Abstract Test Suite for testing of the NWK layer at the FT.
The ISO standard for the methodology of conformance testing (ISO/IEC 9646) as well as the ETSI rules for
conformance testing (protocol and profile conformance testing specifications, standardization methodology
ETS 300 406 [7]) are used as basis for the test methodology.
Annex B provides the partial Protocol Implementation Extra Information for Testing (PIXIT) proforma.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
•
For a non-specific reference, the latest version applies.
• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same
number.
[1] EN 300 175-1: "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI);
Part 1: Overview".
[2] EN 300 175-4: "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI);
Part 4: Data Link Control (DLC) layer".
[3] EN 300 175-5: "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI);
Part 5: Network (NWK) layer".
[4] EN 300 175-6: "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI);
Part 6: Identities and addressing".
[5] EN 300 175-7: "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI);
Part 7: Security features".
[6] EN 300 497-1: "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI)
Test Case Library (TCL); Part 1: Test Suite Structure (TSS) and Test Purposes (TP) for Medium
Access Control (MAC) layer".
[7] ETS 300 406: "Methods for Testing and Specification (MTS); Protocol and profile conformance
testing specifications; Standardization methodology".
[8] EN 300 444: "Digital Enhanced Cordless Telecommunications (DECT); Generic Access Profile
(GAP)".
[9] ISO/IEC 9646-1: "Information technology; Open Systems Interconnection; Conformance testing
methodology and framework; Part 1: General concepts".
[10] ISO/IEC 9646-2: "Information technology; Open Systems Interconnection; Conformance testing
methodology and framework; Part 2: Abstract Test Suite Specification".
ETSI
7 ETSI EN 300 497-9 V0.3.2 (1999-09)
[11] ISO/IEC 9646-3: "Information technology; Open Systems Interconnection; Conformance testing
methodology and framework; Part 3: The Tree and Tabular Combined Notation (TTCN)".
[12] ISO/IEC 9646-6: "Information technology; Open Systems Interconnection; Conformance testing
methodology and framework; Part 6: Protocol Profile Test Specification".
[13] ETR 141: "Methods for Testing and Specification (MTS); Protocol and profile conformance
testing specifications; The Tree and Tabular Combined Notation (TTCN) style guide".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ISO/IEC 9646-1 [9], ISO/IEC 9646-2 [10],
EN 300 175-1 [1], EN 300 175-5 [3], EN 300 175-6 [4] and EN 300 175-7 [5] apply.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AC Authentication Code
ASP Abstract Service Primitive
ATS Abstract Test Suite
AU Authentication
BI Invalid Behaviour
BO Inopportune Behaviour
BV Valid Behaviour
CC Call Control
CH Ciphering
CI Call Information
CR Call Release
DECT Digital Enhanced Cordless Telecommunications
DLC Data Link Control
FT Fixed radio termination
HP Handover Procedure
IC Incoming Call
ID Identification
IPEI International Portable Equipment Identity
IPUI International Portable User Identity
IUT Implementation Under Test
IWU Interworking Unit
KA Key Allocation
LC Link Control
LE Connection oriented Link Establishment
LO Location
LR Connection oriented Link Release
LT Lower Tester
MAC Medium Access Control
ME Management Entity
MM Mobility Management
NWK Network layer
OC Outgoing Call
PARK Portable Access Rights Key
PCO Point of Control and Observation
PDU Protocol Data Unit
PHL Physical Layer
PICS Protocol Implementation Conformance Statement
ETSI
8 ETSI EN 300 497-9 V0.3.2 (1999-09)
PIXIT Protocol Implementation Extra Information for Testing
PR Parameter Retrieval
PT Portable radio Termination
RPN Radio fixed Part Number
RS Call Related Supplementary Services
SUT System Under Test
TCS Test Case Selection
TCV Test Case Variable
TP Test Purposes
TSO Test Suite Operations
TSP Test Suite Parameter
TSV Test Suite Variable
TTCN Tree and Tabular Combined Notation
UAK User Authentication Key
UT Upper Tester
4 Abstract Test Method (ATM)
Clause 4 describes the ATM, the Point of Control and Observation (PCO) used to test the NWK layer of the FT.
4.1 ATM
SUT
Test System
Fixed termination
Upper
LT
Layers
NWK-PDUs
DECT NWK
DLC-
IUT
PCO/DSAP
DLC-
Primitives
DECT DLC layer DECT DLC layer
DECT MAC layer
DECT MAC layer
DECT PHL and radio communication
Figure 1: Remote single layer test method embedded variant
ETSI
9 ETSI EN 300 497-9 V0.3.2 (1999-09)
LT: a Lower Tester (LT) is located in a remote DECT test system. It controls and observes the
behaviour of the Implementation Under Test (IUT).
DSAP: a unique Data Link Control (DLC) SAP is defined at the DECT interface and used to
exchange service data of the NWK protocol.
PCO: the PCO for Network Layer testing is located on the DSAP. All test events at the PCO are
specified in terms of DLC Abstract Service Primitives (ASPs) and NWK Protocol Data
Units (PDUs).
Upper layers/tester: no explicit Upper Tester (UT) exists in the test system. However, the System Under Test
(SUT) needs to carry out some UT functions to achieve some effects of test co-ordination
procedures. Designing ATS, the capability of the Interworking Unit (IWU), such as PSTN,
ISDN or GSM IWUs might be taken into account. An example of such controls could be to
provoke restarting of the IUT through the Q interface.
4.2 DLC primitives
In subclause 4.2 the DSAP primitives are defined according to EN 300 175-4 [2], subclause 8.3.2 (S-SAP primitives)
and EN 300 175-4 [2], subclause 8.3.3 (B-SAP primitives).
4.2.1 S-SAP primitives
Table 1: DL_DATA_IND primitive
ASP Declaration
ASP NAME PCO TYPE COMMENTS
DL_DATA_IND S-SAP EN 300 175-4 [2], subclause 8.3.2.3
Service control information
Parameter name Type Comments
data_link_endpoint_identifier DATA_LINK_ENDPOINT_IDENTIFIER EN 300 175-4 [2], subclause 7.3.6
(INTEGER)
message_unit PDU EN 300 175-4 [2], subclause 8.3.1
Table 2: DL_DATA_REQ primitive
ASP Declaration
ASP NAME PCO TYPE COMMENTS
DL_DATA_REQ S-SAP EN 300 175-4 [2], subclause 8.3.2.3
Service control information
Parameter name Type Comments
data_link_endpoint_identifier DATA_LINK_ENDPOINT_IDENTIFIER EN 300 175-4 [2], subclause 7.3.6
(INTEGER)
message_unit PDU EN 300 175-4 [2], subclause 8.3.1
Table 3: DL_ENCRYPT_CNF primitive
ASP Declaration
ASP NAME PCO TYPE COMMENTS
DL_ENCRYPT_CNF S-SAP EN 300 175-4 [2], subclause 8.3.2.8
Service control information
Parameter name Type Comments
data_link_endpoint_identifier DATA_LINK_ENDPOINT_IDENTIFIER EN 300 175-4 [2], subclause 7.3.6
(INTEGER)
encription_status CIPHER_STATUS EN 300 175-4 [2], subclause 8.3.1
(INTEGER(0,1))
ETSI
10 ETSI EN 300 497-9 V0.3.2 (1999-09)
Table 4: DL_ENCRYPT_IND primitive
ASP Declaration
ASP NAME PCO TYPE COMMENTS
DL_ENCRYPT_IND S-SAP EN 300 175-4 [2], subclause 8.3.2.8
Service control information
Parameter name Type Comments
data_link_endpoint_identifier DATA_LINK_ENDPOINT_IDENTIFIER EN 300 175-4 [2], subclause 7.3.6
(INTEGER)
connection_identities CONNECTION_IDENTITIES EN 300 175-4 [2], subclause 8.3.1
(OCTETSTRING)
encription_status CIPHER_STATUS EN 300 175-4 [2], subclause 8.3.1
(INTEGER(0,1)
Table 5: DL_ENCRYPT_REQ primitive
ASP Declaration
ASP NAME PCO TYPE COMMENTS
DL_ENCRYPT_REQ S-SAP EN 300 175-4 [2], subclause 8.3.2.8
Service control information
Parameter name Type Comments
data_link_endpoint_identifier DATA_LINK_ENDPOINT_IDENTIFIER EN 300 175-4 [2], subclause 7.3.6
(INTEGER)
connection_identities CONNECTION_IDENTITIES EN 300 175-4 [2], subclause 8.3.1
(OCTETSTRING)
encription_status CIPHER_STATUS EN 300 175-4 [2], subclause 8.3.1
(INTEGER(0,1)
Table 6: DL_ENC_KEY_REQ primitive
ASP Declaration
ASP NAME PCO TYPE COMMENTS
DL_ENC_KEY_REQ S-SAP EN 300 175-4 [2], subclause 8.3.2.7
Service control information
Parameter name Type Comments
data_link_endpoint_identifier DATA_LINK_ENDPOINT_IDENTIFIER EN 300 175-4 [2], 7.3.6
(INTEGER)
connection_identities CONNECTION_IDENTITIES EN 300 175-4 [2], 8.3.1
(OCTETSTRING)
encription_key ENCRYPTION_KEY EN 300 175-4 [2], 8.3.1
(BITSTRING[64])
Table 7: DL_ESTABLISH_CNF primitive
ASP Declaration
ASP NAME PCO TYPE COMMENTS
DL_ESTABLISH_CNF S-SAP EN 300 175-4 [2], subclause 8.3.2.1
Service control information
Parameter name Type Comments
data_link_endpoint_identifier DATA_LINK_ENDPOINT_IDENTIFIER EN 300 175-4 [2], subclause 7.3.6
(INTEGER)
ETSI
11 ETSI EN 300 497-9 V0.3.2 (1999-09)
Table 8: Void
Table 9: DL_ESTABLISH_REQ primitive
ASP Declaration
ASP NAME PCO TYPE COMMENTS
DL_ESTABLISH_REQ S-SAP EN 300 175-4 [2], subclause 8.3.2.1
Service control information
Parameter name Type Comments
data_link_endpoint_identifier DATA_LINK_ENDPOINT_IDENTIFIER EN 300 175-4 [2], subclause 7.3.6
(INTEGER)
establish_mode ESTABLISH_MODE EN 300 175-4 [2], subclause 8.3.1
(INTEGER(0,1,2)
radio_fixed_part_number RADIO_FIXED_PART_NUMBER EN 300 175-4 [2], subclause 8.3.1
(INTEGER)
message_unit PDU EN 300 175-4 [2], subclause 8.3.1
Table 10: DL_ESTABLISH_RES primitive
ASP Declaration
ASP NAME PCO TYPE COMMENTS
DL_ESTABLISH_RES S-SAP EN 300 175-4 [2], subclause 8.3.2.1
Service control information
Parameter name Type Comments
data_link_endpoint_identifier DATA_LINK_ENDPOINT_IDENTIFIER EN 300 175-4 [2], subclause 7.3.6
(INTEGER)
Table 11: DL_RELEASE_CNF primitive
ASP Declaration
ASP NAME PCO TYPE COMMENTS
DL_RELEASE_CNF S-SAP EN 300 175-4 [2], subclause 8.3.2.2
Service control information
Parameter name Type Comments
data_link_endpoint_identifier DATA_LINK_ENDPOINT_IDENTIFIER EN 300 175-4 [2], subclause 7.3.6
(INTEGER)
release_mode RELEASE_MODE EN 300 175-4 [2], subclause 8.3.1
(INTEGER(0,1)
Table 12: DL_RELEASE_IND primitive
ASP Declaration
ASP NAME PCO TYPE COMMENTS
DL_RELEASE_IND S-SAP EN 300 175-4 [2], subclause 8.3.2.2
Service control information
Parameter name Type Comments
data_link_endpoint_identifier DATA_LINK_ENDPOINT_IDENTIFIER EN 300 175-4 [2], subclause 7.3.6
(INTEGER)
release_mode RELEASE_MODE EN 300 175-4 [2], subclause 8.3.1
(INTEGER(0,1)
ETSI
12 ETSI EN 300 497-9 V0.3.2 (1999-09)
Table 13: DL_RELEASE_REQ primitive
ASP Declaration
ASP NAME PCO TYPE COMMENTS
DL_RELEASE_REQ S-SAP EN 300 175-4 [2], subclause 8.3.2.2
Service control information
Parameter name Type Comments
data_link_endpoint_identifier DATA_LINK_ENDPOINT_IDENTIFIER EN 300 175-4 [2], subclause 7.3.6
(INTEGER)
release_mode RELEASE_MODE EN 300 175-4 [2], subclause 8.3.1
(INTEGER(0,1)
4.2.2 B-SAP primitives
Table 14: DL_BROADCAST_IND primitive
ASP Declaration
ASP NAME PCO TYPE COMMENTS
DL_BROADCAST_IND B-SAP EN 300 175-4 [2], subclause 8.3.3.1
Service control information
Parameter name Type Comments
cluster_address_list CLUSTER_ADDRESS_LIST EN 300 175-4 [2], subclause 8.3.1
(OCTETSTRING)
message_unit PDU EN 300 175-4 [2], subclause 8.3.1
extended_message_flag BIT_1 EN 300 175-4 [2], subclause 8.3.1
(BITSTRING[1])
error_flag BIT_1 EN 300 175-4 [2], subclause 8.3.1
(BITSTRING[1])
Table 15: Void
4.3 TC execution sequence
The test cases can be executed in any order, there are no restrictions on this matter.
5 Untestable Test Purposes (TP)
Clause 5 gives a list of TP which are not implemented in the ATS (annex A) due to the chosen ATM or other
restrictions.
5A Control protocol
The following test purposes are not implemented in the ATS due to unknown reaction of the IUT after testing the TP:
Table 16: Untestable TP's (1)
Test Purpose Reference to EN 300 497-9
TP/FT/MM/BV/PR-01
TP/FT/IS/BV-01
TP/FT/IS/BV-02
TP/FT/IS/BV-03
TP/FT/CL/BV-01
TP/FT/CL/BV-02
TP/FT/CL/BV-03
TP/FT/MM/BV/LO-52
ETSI
13 ETSI EN 300 497-9 V0.3.2 (1999-09)
6 ATS Conventions
The ATS conventions are intended to give a better understanding of the ATS but they describe also the conventions
made for the development of the ATS. Thus for any later maintenance purposes or further development of the ATS the
conventions described in clause 6 shall be considered.
The ATS conventions contain two clauses, the naming conventions and the implementation conventions. The naming
conventions describe the structure of the naming of all ATS elements. The implementation conventions describe the
functional structure of the ATS.
To define the ATS the guidelines of the documents ETS 300 406 [7] and ETR 141 [13] were considered.
6.1 Naming conventions
6.1.1 Declarations part
Subclause 6.1.1 describes the naming conventions chosen for the elements of the ATS declarations part. The following
general rules apply:
- identifiers shall be written in lowercase;
- type declarations shall be written in uppercase;
- constraints shall be written with the first letter in uppercase, and the rest in lowercase.
Information elements are coded in the order from top to bottom and from right to left, in order to make the encoding and
decoding easier.
6.1.1.1 Test suite type, ASP and PDU type definitions
The test suite type-definitions, the ASP type definitions and the PDU type definitions shall be written in uppercase.
Identifier names of structured type definitions and of the ASP and PDU type definitions, shall be written in lowercase.
Types related to a certain higher layer entity shall commence with a protocol identifier to define which entity they
belong to.
EXAMPLE 1: Call Control: cc e.g. CC_SETUP.
Id names of structured types which are used for invalid tests commence with "bi":
EXAMPLE 2: Bi_cc_setup_rx01.
6.1.1.2 Test Suite Operations (TSO) definitions
The TSO identifiers are composed of a string in uppercase letters starting by the string "TSO_"
(e.g. TSO_INTEGER_TO_O_1).
6.1.1.3 Test Suite Parameter (TSP) declarations
The TSP identifiers are composed of a string in uppercase letters starting by the string "TSP_"
(e.g. TSP_WINDOW_SIZE).
If the TSP references a Protocol Implementation Conformance Statement (PICS) item, the letter "C" is added to the
standard prefix (e.g. TSPC_PICS_ITEM_S23).
If the TSP references a PIXIT item, the letter "X" is added to the standard prefix (e.g. TSPX_PIXIT_ITEM_2).
Exception: if the TSP represents a system parameter or value, only the name defined in the specifications is used
(e.g. V_S = send sequence variable).
ETSI
14 ETSI EN 300 497-9 V0.3.2 (1999-09)
Complete names as defined in the specifications are used.
6.1.1.4 Test Case Selection (TCS) expression definitions
The naming conventions for the TCS expression definitions use almost the same rules as the TSPs, except for the prefix
that is "TCS_". Also they are logical combinations of the TSP definitions.
6.1.1.5 Test Suite Constant (TSC) declarations
The TSC identifiers are composed of a string in uppercase letters starting by the string "TSC_" (e.g. TSC_retry).
Exception: if the TSC represents a system parameter or value, only the name defined in the specifications is used
(e.g. N250).
Complete names as defined in the specifications are used.
6.1.1.6 Test Suite Variable (TSV) declarations
The TSV identifiers are composed of a string in uppercase letters starting by the string "TSV_".
Complete names as defined in the specifications are used.
6.1.1.7 Test Case Variable (TCV) declarations
The TCV identifiers are composed of a string in uppercase letters starting by the string "TCV_".
EXAMPLE: TCV_crvalue.
Complete names as defined in the specifications are used.
6.1.1.8 Point of Control and Observation (PCO) declarations
The PCO identifiers are composed of two or four capital letters, beginning with "L", as there are only LTs.
EXAMPLE: LMAC represents a PCO on Medium Access Control (MAC) interface as LT in the test equipment;
LDLC represents a PCO on DLC interface as LT in the test equipment.
6.1.1.9 Timer declarations
Two types of timers can be identified:
1) standardized:
- those defined in the standard, e.g. T302. They use exactly the same name as in the standard, beginning with a
capital "T";
- as there is a tolerance margin accepted for these timers, three values are needed:
- the maximum value allowed, which will use the suffix "_max";
- the minimum value allowed, which will use the suffix "_min";
- the value actually implemented, with no suffix.
EXAMPLE 1: T302_max, T302_min, and T302.
2) not standardized:
- those not defined in the standard, i.e. for execution use, e. g. a timer waiting for a response. These timers
begin with the prefix "T_", followed by a string in capital letters.
EXAMPLE 2: T_RESP represents a timer for controlling the response time of the IUT.
ETSI
15 ETSI EN 300 497-9 V0.3.2 (1999-09)
6.1.1.10 ASP type definitions
The identifier of an ASP uses exactly the same name as the name defined in the specifications. It is written in
uppercases, finishing by an underscore character ("_"), and three capital letters indicating whether it is a request, an
indication, a response or a confirmation primitive.
EXAMPLE: DL-RELEASE_REQ for an ASP containing a layer 3 release request passed to layer 2;
MAC-CO_DATA_REQ for an ASP containing a layer 2b PDU passed to layer 2a.
6.1.1.11 PDU type definitions
The identifier of a PDU is given in a string in uppercase letters, representing the layer message.
EXAMPLE 1: rr for the Receive Ready layer 2 message;
disconnect for the DISCONNECT layer 3 message.
Where the message is a composite word, an underscore character ("_") appears in the string.
EXAMPLE 2: release_complete is the RELEASE COMPLETE layer 3 message.
Id names of PDUs commence with a protocol identifier to define which protocol they are belonging to. The following
identifiers are used:
- Call Control: cc e.g. CC-SETUP.
Id names of PDUs which are used for invalid tests commence with "bi":
EXAMPLE 3: BI-CC-SETUP.
6.1.1.12 Alias definitions
These are used to make the sending and receiving of PDUs within ASPs more understandable when writing the dynamic
part of the test suite. This is done by giving the ASP an alias. The alias name indicates the PDU carried by the ASP and
whether it is sent or received by the tester.
The identifier of an alias consists of a string in capital letters indicating the message, followed by two lower case letters
"r" or "s" indicating if the message should be sent or received by the tester.
6.1.2 Constraints part
Subclause 6.1.2 describes the naming conventions chosen for the elements of the ATS constraints part.
Constraint identifiers commence with uppercase. The remaining part of the Id name is written in lowercase.
Identifier names of elements concerning the same subject have equivalent names in the Declaration and the Constraint
part:
- Declaration Part: cc_setup;
- Constraint Part: Cc_setup.
The name of the modified constraint describes the particularity of the modified constraint:
EXAMPLE: Cc_setup_mand_only (modified Cc_setup with only the mandatory Information Elements).
If formal parameter lists are used, the variable names are written in lowercase. The variable name is the same as the
name of the element it is representing.
ETSI
16 ETSI EN 300 497-9 V0.3.2 (1999-09)
Structured type constraints declarations are divided into:
- receive constraints:
- the receive constraints are noted down as "name_rx*". The receive constraints are subdivided into:
- receive base constraints:
- they are noted down as "name_rx_base";
- receive special constraints:
- they are noted down as "name_rx_", where is a descriptive name
(e.g. "Signal_rx_alerting_on");
- transmit constraints:
- the transmit constraints are noted down as "name_tx_", where is a descriptive name.
(e.g. "Signal_tx_alerting_off").
If a certain structured type constraint is valid for both receiving and transmitting, because it contains no wildcards, and
the receiving constraint should exactly match, the constraint will be noted down as:
- "_extention";
EXAMPLE: "Portable_id_ipui".
PDU Constraints Declarations are divided into:
- receive constraints:
- the receive constraints are noted down as "name_rx*". The receive constraints are subdivided into:
- receive base constraints:
- they are noted down as "name_rx_base". They constrain all allowed values, and for the optional
fields, the "IF_PRESENT" keyword is added;
- receive special constraints:
- they are noted down as "name_rx0n", where n is a sequence number;
- transmit constraints:
- the transmit constraints are noted down as "name_tx", where n is a sequence number. They can be subdivided
into:
- transmit base constraints:
- they are noted down as "name_tx_base". They constrain all mandatory fields to all allowed values
in the standard, and they constrain all optional fields to "OMIT";
- transmit special constraints:
- they are noted down as "name_tx0n" where n is a sequence number. They shall not contain any
wildcards.
Derived constraints shall not be more than 1 level deep. They shall only be derived directly from the base constraint.
The test suite is not ready yet to handle PDU's with empty information elements. For every receive constraint, also a
information element constraint with an empty parameter list should be added.
6.1.3 Dynamic part
Subclause 6.1.3 describes the naming conventions chosen for the elements of the ATS dynamic part.
ETSI
17 ETSI EN 300 497-9 V0.3.2 (1999-09)
6.1.3.1 Test Case (TC) identifier
The identifier of the TCs is built in the same way as for the TP described in EN 300 497-1 [6], subclause 5.1.1, with the
exception that "TP" is replaced by "TC_FT":
- TP identifier: TP/CC/BI-04;
- TC identifier: TC_FT_CC_BI_04.
6.1.3.2 Test Step (TS) identifier
The TS identifier is built with two strings of capital letters joined by underscore character. The first string indicates the
main function of the TS; e.g. PR for preamble, PO for postamble, CS for check state and STP for general step. The
second string indicates the meaning of the step.
In some TCs, test steps as well as local trees can be used. To allow an easy distinguishing of them the following naming
applies:
- LTS_[local_tree_name] local tree;
- STP_[test_step_name] test step.
6.1.3.3 Default identifier
The default identifiers begin with the prefix "DF_", followed by a string in capital letters.
6.1.3.4 General aspects
All verdict assignments are labelled. To allow an exact identification in which table the verdict was assigned, the
following name convention is applied:
B test Body
CS Check State test steps
D Default
E Error handling test steps
PO Postamble
PR Preamble
S test Step
Also combinations of labels are possible:
EXAMPLE: DPR ˘ label which is used in a default for preambles.
6.1.3.5 ATS abbreviations
These abbreviations are used to shorten identifier names:
ack acknowledgement
auth authentication
algo algorithm
cc call control
cfm confirm
est establish
ext extension
id identification
ind indication
info information
max maximum
min minimum
prop proprietary
req request
res response
ETSI
18 ETSI EN 300 497-9 V0.3.2 (1999-09)
The following keywords will NOT be abbreviated in identifier names:
address(es);
attribute(s);
identity;
number(s);
character(s).
6.2 Implementation conventions
6.2.1 Declaration part
The comment line of single element Tree and Tabular Combined Notation (TTCN) tables (e.g. test suite constants) is
used to give a reference where the format and content of the element is described in the relevant protocol specifications.
Any particularity of the element format or content is described in the comment line.
The comment line in the header of multi element TTCN tables (e.g. ASPs) is used to reference to the protocol
specification. The detailed comments are used to describe any particularity of the table.
In the ASP and PDU declarations, the comments column is used to identify if an element is mandatory or optional:
-m:mandatory;
- o: optional.
In the ASP and PDU declarations the comments column is further used to give information about the element value, in
particular if the element contains a fixed spare value.
In tables where structure types are used the information element and the relevant structured type have always the same
name, that allows to have the same structure as in the protocol standards is used to document the relation between
information elements in a table and their specific description in an other subclause of the protocol standard.
The following conventions apply to identifier names in the structured type definitions part:
- bits of bit sequences having a fixed value, meant to fill up the octet, are called fn, where n stands for the octet
number;
- extension flags, will be called extn, where n stands for the octet number.
6.2.2 Constraint part
The ASPs and PDUs are defined in a way that all relevant element are parameterized. That improves the transparency of
the constraints in the dynamic part, as all values which are relevant for the test are always present.
Generally no modified constraints are used, this allows an easier reuse and adaptation of constraints if they are reused in
other DECT profile test specifications.
The Comment line of a constraint contains always the reference to the used specifications.
The detailed comments sector is used to describe any particularity of the table.
6.2.3 Dynamic part
Some TCs need a particular initialization of the IUT environment conditions to run the actual test, e.g. for testing
re-provisioning procedures. Such message sequence can be quite complicated and long. In cases where a Local Test
Step (LTS) facilitates the TC structure, the preamble and the condition setting are described in a LTS called
LTS_pre_step. All LTS_pre_steps are described in the detailed comment part of the TTCN table.
ETSI
19 ETSI EN 300 497-9 V0.3.2 (1999-09)
Some TCs need after the actual test a particular re-initialization of the IUT, e.g. after re-provisioning. Such message
sequence can be quite complicated and long. In cases where a Local Test Step (LTS) facilitates the TC structure, the
postamble and the re-initialization are described in a LTS called LTS_post_step. All LTS_post_steps are described in
the detailed comment part of the TTCN table.
All events which are defined as a conformance requirements by the TP, cause a preliminary verdict PASS if the
requirement is met.
All invalid events are handled in the default tree. FAIL verdicts are only assigned in the default tree.
The preamble, the test body and the postamble have different defaults, what allows a specific verdict handling, e.g. only
INCONC verdicts are assigned in the preamble.
Test steps do not contain a default. That allows to apply them with no restrictions regarding the error handling.
All verdict assignments are labelled. According to ISO/IEC 9646-3 [11], clause E.2, labels should be written to the
conformance log. This allows to identify were the test failed. To allow an exact identification in which table the verdict
was assigned, the naming convention as described i
...