ETSI TS 103 158 V1.1.1 (2014-11)

Digital Enhanced Cordless Telecommunications (DECT); New Generation DECT; Light Data Services; Software Update Over The Air (SUOTA); Profile Test Specification (PTS) and Test Case Library (TCL)

DTS/DECT-NG270

General Information

• Status: Published
• Publication Date: 19-Nov-2014
• Technical Committee: DECT NewGen - DECT NewGeneration
• Current Stage: 12 - Completion
• Due Date: 18-Nov-2014
• Completion Date: 20-Nov-2014

Standards Content (Sample)

TECHNICAL SPECIFICATION
Digital Enhanced Cordless Telecommunications (DECT);
New Generation DECT; Light Data Services;
Software Update Over The Air (SUOTA);
Profile Test Specification (PTS) and Test Case Library (TCL)

2 ETSI TS 103 158 V1.1.1 (2014-11)

Reference
DTS/DECT-NG270
Keywords
DECT, interoperability, interworking, packet
mode, testing
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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

Important notice
The present document can be downloaded from:
http://www.etsi.org
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2014.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 158 V1.1.1 (2014-11)
Content
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions, symbols and abbreviations . 7
3.1 Definitions . 7
3.2 Symbols . 7
3.3 Abbreviations . 8
4 Test method . 8
4.1 Test platform . 9
4.1.1 PP test platform . 9
4.1.1.1 PP test platform main requirements . 9
4.1.1.2 Test content for HTTP-based applications, Simple profile . 9
4.1.1.2.1 Test url and index page: index.html . 9
4.1.1.2.2 Left page: pages/left.html . 9
4.1.1.2.3 Center page: pages/center.html . 9
4.1.1.2.4 Right page: pages/right.html . 9
4.1.1.3 Test content for HTTP-based applications, Baseline profile . 10
4.1.1.3.1 Test url and index page: index.html . 10
4.1.1.3.2 Left page: pages/left.html . 10
4.1.1.3.3 Center page: pages/center.html . 10
4.1.1.3.4 Right page: pages/right.html . 10
4.1.2 FP test platform . 10
4.1.2.1 FP test platform main requirements . 10
4.1.2.2 Test content for software upgrade (TS_1 + MS) . 11
4.2 Hypothesis . 12
4.3 Test groups . 12
4.3.1 Network features . 12
4.3.2 Application features . 12
5 Test Cases (TCs) . 12
5.1 TC definition conventions . 13
5.1.1 Test equipment implementation requirements . 13
5.1.2 Definitions of used MACROs (PT and FT sides) . 14
5.1.2.1 Basic service MACROs (request from PP to FP) . 14
5.1.2.1.1 Suota C-plane . 14
5.1.2.1.2 Binary content download . 14
5.1.2.1 Handset version indication MACRO (request from PP to FP) . 15
5.1.2.2 Handset version available MACRO (from FP to PP) . 15
5.1.2.3 HTTP related MACROS . 15
5.1.2.3.1 Submacros . 15
5.1.2.3.2 range request MACRO (from PP to FP) . 16
5.1.2.3.3 HTTP range response MACRO (from FP to PP) . 16
5.1.2.3.4 HTTP error MACRO (from FP to PP) . 16
5.2 TC naming conventions . 16
5.3 Portable Part TC purposes . 17
5.3.1 List of New Generation DECT Part 4 PT tests cases . 17
5.4 Fixed Part TC purposes . 19
5.4.1 List of New Generation DECT Part 4 FT tests cases . 19
6 Portable Part Test specification . 22
ETSI
4 ETSI TS 103 158 V1.1.1 (2014-11)
6.1 DPRS PT Procedures. 22
6.2 NGLDS-N.1 General Light Data Service Procedures . 28
6.3 NGLDS-N.2 Software upgrade over the air, C-plane . 31
6.4 NGLDS-A.1 Binary content download . 38
6.5 NGLDS-A.2 Software upgrade over the air . 39
6.6 NGLDS-A.3 HTTP based applications . 46
7 Fixed Part Test specification . 47
7.1 DPRS FT Procedures. 48
7.2 NGLDS-N.1 General Light Data Service Procedures . 55
7.3 NGLDS-N.2 Software upgrade over the air, C-plane . 57
7.4 NGLDS-A.1 Binary content download . 60
7.5 NGLDS-A.2 Software upgrade over the air . 61
7.6 NGLDS-A.3 HTTP based applications . 71
Annex A (normative): Declarations on features and procedures supported . 73
A.1 Declarations for portable part . 73
A.1.1 Optional PT features . 73
A.1.2 Extra information for PT testing . 73
A.1.3 Optional or conditional PT procedures . 74
A.2 Declarations for fixed part . 75
A.2.1 Optional FT features . 75
A.2.2 Extra information for FT testing . 75
A.2.3 Optional or conditional FT procedures . 75
Annex B (informative): List of NG-DECT Part 4 procedures . 76
Annex C (normative): Configuration for testing . 78
C.1 Portable part configuration to be declared by supplier . 78
C.2 Fixed part internal configuration to be declared by supplier . 78
C.3 Test environment configuration to be declared by test house or supplier . 78
Annex D (normative): Amendments to other DECT specifications . 79
Annex E (informative): Bibliography . 80
History . 81

ETSI
5 ETSI TS 103 158 V1.1.1 (2014-11)
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 ETSI 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://ipr.etsi.org).
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 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 Digital Enhanced Cordless
Telecommunications (DECT).
The present document is the Test Specification for testing compliance with ETSI TS 102 527-4 [5]. "Digital Enhanced
Cordless Telecommunications (DECT); New Generation DECT; Part 4: Light Data Services; Software Update Over
The Air (SUOTA), content downloading and HTTP based applications".
The information in the present document is believed to be correct at the time of publication. However, DECT
standardization is a rapidly changing area and it is possible that some of the information contained in the present
document may become outdated or incomplete within relatively short time-scales.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "may not", "need", "need not", "will",
"will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms
for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
6 ETSI TS 103 158 V1.1.1 (2014-11)
1 Scope
The present document contains the Profile Test Specification (PTS) and the Test Case Library (TCL) for "New
Generation DECT; Part 4"Digital Enhanced Cordless Telecommunications (DECT); New Generation DECT; Part 4:
Light Data Services; Software Update Over The Air (SUOTA), content downloading and HTTP based applications"
The present document covers both the Portable (PT) and the Fixed (FT) Radio terminations.
The Test Case Library (TCL) covers also some test cases for "DECT Digital Packet Radio Service" [i.4]. This is done
because such test cases are mandatory or especially relevant for New Generation DECT Part 4
(see ETSI TS 102 527-4 [5]).
The objective of the present document is to provide a basis for approval tests of NG-DECT Part 4 [5] equipment giving
a high probability of air interface inter-operability between different manufacturer's DECT equipment.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or non-
specific. For specific references,only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] ETSI EN 300 175-5: "Digital Enhanced Cordless Telecommunications (DECT); Common
Interface (CI); Part 5: Network (NWK) layer".
[2] ETSI EN 300 444: "Digital Enhanced Cordless Telecommunications (DECT); Generic Access
Profile (GAP)".
[3] ETSI TS 102 527-1: "Digital Enhanced Cordless Telecommunications (DECT); New Generation
DECT; Part 1: Wideband speech".
[4] ETSI TS 102 527-3: "Digital Enhanced Cordless Telecommunications (DECT); New Generation
DECT; Part 3: Extended wideband speech services".
[5] ETSI TS 102 527-4: "Digital Enhanced Cordless Telecommunications (DECT); New Generation
DECT; Part 4: Light Data Services; Software Update Over The Air (SUOTA), content
downloading and HTTP based applications".
[6] ETSI TS 102 527-5: "Digital Enhanced Cordless Telecommunications (DECT); New Generation
DECT; Part 5: Additional feature set nr. 1 for extended wideband speech services".
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] World Wide Web Consortium Recommendation XHTML™ 1.1: "Module-based XHTML -
Second Edition" - 23 November 2010.
NOTE: http://www.w3.org/TR/2010/REC-xhtml11-20101123/.
ETSI
7 ETSI TS 103 158 V1.1.1 (2014-11)
[i.2] ISO/IEC 9646-7:1995: "Information technology -- Open Systems Interconnection -- Conformance
testing methodology and framework -- Part 7: Implementation Conformance Statements".
[i.3] ETSI TS 102 841: "Digital Enhanced Cordless Telecommunications (DECT); New Generation
DECT; Extended wideband speech services; Profile Test Specification (PTS) and Test Case
Library (TCL)".
[i.4] ETSI EN 301 649: "Digital Enhanced Cordless Telecommunications (DECT); DECT Packet
Radio Service (DPRS)".
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI TS 102 527-5 [6],
ETSI TS 102 527-3 [4], ETSI TS 102 527-1 [3], ETSI EN 300 444 [2] and the following apply:
GAP (PP, FP, device or equipment): PP, FP or any of them compliant with ETSI EN 300 444 [2].
golden device: ideal example of a device used as reference device for compliance testing and against which later
devices are tested and judged
NG-DECT Part 1 Golden Device: Golden Device, such as the one administered by the DECT Forum, used for
compliance testing of NG-DECT Part 1 [3] equipment
NG-DECT Part 1 (PP, FP, device or equipment), also shortened as Part 1 (PP, FP, device or equipment): PP, FP
or any of them compliant with ETSI TS 102 527-1 [3]
NG-DECT Part 3 (PP, FP, device or equipment), also shortened as Part 3 (PP, FP, device or equipment): PP, FP
or any of them compliant with ETSI TS 102 527-3 [4]
NG-DECT Part 4 (PP, FP, device or equipment), also shortened as Part 4 (PP, FP, device or equipment): PP, FP
or any of them compliant with ETSI TS 102 527-4 [5]
NG-DECT Part 5 (PP, FP, device or equipment), also shortened as Part 5 (PP, FP, device or equipment): PP, FP
or any of them compliant with ETSI TS 102 527-5 [6]
provision mandatory, process mandatory: indicated feature service or procedure are implemented as described in the
present document, and may be subject to testing
provision optional, process mandatory: indicated feature, service or procedure may be implemented, and if
implemented, the feature, service or procedure are implemented as described in the present document, and may be
subject to testing
NOTE: The notation used is based on the notation proposed in ISO/IEC 9646-7 [i.2].
3.2 Symbols
For the purposes of the present document, the following symbols apply:
C conditional to support (process mandatory)
E Test Parameter used in parameterized tests for an HTTP Error
I out-of-scope (provision optional, process optional) not subject for testing
M mandatory to support (provision mandatory, process mandatory)
rd
MSO Test Parameter used in parameterized tests for indicating the MS origin (manufacturer or 3 party)
N/A not applicable (in the given context the present document makes it impossible to use this
capability)
O optional to support (provision optional, process mandatory)
SUF Test Parameter used in parameterized tests for the (variable) suffix of the software version
URLP Test Parameter used in parameterized tests for an URL Parameter
ETSI
8 ETSI TS 103 158 V1.1.1 (2014-11)
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
BCD Binary Content Download
CC Call Control
CI Common Interface
DECT Digital Enhanced Cordless Telecommunications
DLC Data Link Control
DS Download Server
FP Fixed Part
FT Fixed radio Termination
GAP Generic Access Profile
HTTP HyperText Transfer Protocol
IE Information Element
IUT Implementation Under Test
IWU InterWorking Unit
IXIT Implementation eXtra Information for Testing
LDS Light Data Services
MAC Medium Access Control
MS Management Server
NG New Generation
NG-DECT New Generation DECT
NWK NetWorK
PHL PHysical Layer
PP Portable Part
PT Portable radio Termination
PTS Profile Test Specification
RF Radio Frequency
TCL Test Case Library
TS Test System
4 Test method
This clause describes the test method used to test the NG DECT Part 4 devices.

Device Under
Test System
Test
Application
Tester NWK PDUs
DECT NWK
IUT
DECT DLC DECT DLC
DECT MAC DECT MAC
DECT PHL DECT PHL
Figure 1: New Generation DECT remote test method
A tester (see figure 1) is located in a remote DECT test system. It controls and observes the behaviour of the
Implementation Under Test (IUT). The Test System behaves as a FP (or a PP) when testing a PP (respectively a FP).
Figure 1 illustrates the layered architecture of the test method.
ETSI
9 ETSI TS 103 158 V1.1.1 (2014-11)
4.1 Test platform
4.1.1 PP test platform
4.1.1.1 PP test platform main requirements
The PP test platform is outlined in figure 2.

Test
T
P
S
P
System
DUT
Figure 2: PP Test Platform
The first RF front-end of Test system "TS_1" plays the role of a LDS FP to which the PP under test is registered.
The DUT supplier shall also supply new software revision file/files for installation on the Test System.
4.1.1.2 Test content for HTTP-based applications, Simple profile
NOTE : This test content was designed for TC_PT_NGLDS.A3_BV_109 and is reused for test
TC_FT_NGLDS.A.2_BV_105 on FT side.
4.1.1.2.1 Test url and index page: index.html
Test url1 = http:// ${SERVER_HOSTNAME}/http-based-application-1/
rd
The SERVER_HOSTNAME variable value shall be provided by the 3 party providing the server.
Home_page=Test url1 + 'index.html' shall target the following resource.

My service

Left

Center

Right

4.1.1.2.2 Left page: pages/left.html

Left page

Link for this page was on the left

4.1.1.2.3 Center page: pages/center.html

Center page

Link for this page was centered

4.1.1.2.4 Right page: pages/right.html

Right page

Link for this page was on the right

ETSI
10 ETSI TS 103 158 V1.1.1 (2014-11)
4.1.1.3 Test content for HTTP-based applications, Baseline profile
4.1.1.3.1 Test url and index page: index.html
Test url2 = http:// ${SERVER_HOSTNAME}/http-based-application-2/
rd
The SERVER_HOSTNAME variable value shall be provided by the 3 party providing the server.
Home_page=Test url2 + 'index.html' shall target the following resource.

My service

• 
  Left
  
  
  
• 
  Center
  
  
  
• 
  Right
  
  

4.1.1.3.2 Left page: pages/left.html

Left page

Link for this page was on the left

4.1.1.3.3 Center page: pages/center.html

Center page

Link for this page was centered

4.1.1.3.4 Right page: pages/right.html

Right page

Link for this page was on the right

4.1.2 FP test platform
4.1.2.1 FP test platform main requirements
The fixed part under test shall be connected to a network when running the tests suite. It shall be ready to support the
SUOTA feature. An example of FP test platform is depicted in figure 3.
ETSI
11 ETSI TS 103 158 V1.1.1 (2014-11)

Download
Server (DS)
T
S
Test
F
NET
P
System
T
S
DUT
Management
Server (MS)
Figure 3: Example of FP Test platform
The Test System shall include 2 separate PP entities (TS_1 and TS_2).
Management server. The FP IUT may be presented for conformance testing with an IP addressable Management
Server. In that case, every test involving a MS shall be performed twice. More specifically:
rd
• The test shall at least be performed once with the 3 party MS, that shall implement Basic SUOTA.
• If the FP manufacturer provides another MS, the test shall additionally be performed a second time with this
MS. This MS implementation may be either basic or enhanced.
Both MSs shall be populated with the data provided in clause 4.1.2.2.
rd
Download server. The FP manufacturer shall not provide any Downloading Server. Only the 3 party DS shall be
used.
rd
party together with the
Two mock firmware files (image.bin and checksum.bin) shall be provided by the 3
Downloading Server, to be used for the upgrade of TS_1 and TS_2 (see clause 4.1.2.2).
Set of XHTML pages and server for HTTP based application tests. The third party shall provide a server for hosting
the set of test pages (the download server could be reused for this purpose) and shall reuse the set of XHTML test pages
described in clause 4.1.1.2 for PT test platform (see parameterized testTC_FT_NGLDS.A3_BV_104(URLP) and
corresponding test instance TC_FT_NGLDS.A3_BV_105 for more details).
4.1.2.2 Test content for software upgrade (TS_1 + MS)
Table 1 describes the data to be used for populating TS_1 (PT), the Management Server (MS) or both when testing the
FT (multiple file upgrade with two files is used).
The values listed below for populating the MS (or for populating both the MS and TS_1) shall apply whether the MS
rd
used for a given test is provided by a third party (3 party Basic SUOTA MS), or by the FP manufacturer (either basic
or enhanced SUOTA enabled).
As an exception and for convenience, the value of URL1 depends on the MS used (see below and FT_IXIT_2 and 3 in
table A.4 of clause A.2.2).
The tester supplier shall supply the mock files image.bin and checksum.md5 as described in table 1 below.
Table 1: Test content for software upgrade
Description Name Value Comment
Variables populating both TS_1 and MS at test start
MS entry point URL1 note 1
rd
FT_IXIT_2 for 3 party Basic SUOTA MS
FT_IXIT_3 for Manufacturer MS
IUT hardware version HWV "YOU'RTALKINGTOME?" 17 IA5 characters
(assumed to be
stable over the
whole test):
ETSI
12 ETSI TS 103 158 V1.1.1 (2014-11)
Description Name Value Comment
Variables populating both TS_1 and MS at test start
IUT EMC value at test start EMC '01ab'H 2 octets
IUT SW version installed at test start SWV0 "SWV-BEFORE-TEST" " + number_str (note 3) 20 IA5 characters
Variables populating MS only at test start
IUT SW version installed at test end SWV1 "SWV-AFTER-TEST" 19 IA5 characters
Nb of files to be downloaded Nf 2
st
Url of 1 file URL2 'image.bin' file size
http://${DS_HOSTNAME}/download/image.bin
shall be100010
(note 2)
octets
nd
Url of 2 file URL2 'checksum.bin' file
http://${DS_HOSTNAME}/download/checksum
size shall
.md5
be100010 octets
(note 2)
Variables populating TS_1 only at test start
Number of file chunks used M 101 Used for both files

HTTP range sizes C , …, C 1000 Used for both files
1 M-1
Last HTTP range size C 10 Used for both files
M
rd
NOTE 1: If the test uses the 3 party Basic SUOTA MS, then URL1=FT_IXIT_2; else if the test uses the MS provided by
the manufacturer, URL1=FT_IXIT_3 (see Table A.1 of clause A.2.2).
NOTE 2: DS_HOSTNAME is declared through FT_IXIT_4 (see table A.4 of clause A.2.2).
NOTE 3: TS_1 shall use a different SWV0 value for each test, formed with "SWV-BEFORE-TEST" prefix immediately
followed by a string representing a number between 1 and 1 000 in decimal. This avoids the case of a FP not
requesting the MS in step 2 (see SUOTA upgrade description) because it already has the needed information in
cache.
4.2 Hypothesis
Protocol layers tested
Network and application features are only tested. DLC, MAC and PHY procedures used by new DECT generation
standard are supposed to be tested when testing network features.
Speech services tested
The device under test is required to support only mandatory speech services. Optional codecs are out of the scope of the
present document.
Length of a NWK layer message
The test equipment shall not send NWK layer messages longer than 63 bytes (see ETSI EN 300 444 [2], clause 6.9.3).
In the other direction, the test equipment shall be capable of receiving and processing NWK layer messages of at least
63 octets long. A received NWK layer message longer than 63 bytes shall be discarded.
4.3 Test groups
4.3.1 Network features
Network features are described in clauses 5.2, 6.4 and 6.10 of ETSI TS 102 527-5 [6].
4.3.2 Application features
Application features are described in clauses 5.7, 6.9 and 6.13 of ETSI TS 102 527-5 [6].
5 Test Cases (TCs)
Each test case is allocated directly under a defined TC.
ETSI
13 ETSI TS 103 158 V1.1.1 (2014-11)
5.1 TC definition conventions
The TCs are defined following particular rules as shown in table 2.
Table 2: TC definition rules
TC Id according to the Test case objective
TC naming conventions
Main test purpose: Optional detailed description of test case objective for complex test cases
Reference: The reference should contain the references of the subject to be validated by the actual
TC (specification reference, clause, paragraph, flow chart number, etc.).
Initial condition: The condition defines in which initial state the IUT has to be to apply the actual TC.
Time sequence:
The time sequence is the description of the test case, including messages exchanged
between IUT and tester and user actions. In other words, it defines the sequence of
stimuli experienced by the IUT and its expected response(s).
Pass criteria: Definition of the verifications that the tester shall perform on the responses expected
from the IUT in order to ascertain conformance of the latter with the base specification.
Comments: (optional)
Additional information or comments on test case content.
Display_n Optional list of tester display messages description

The device under test and the test equipment shall meet the features and procedures specified in "New Generation
DECT; Part 4: Light Data Services; Software Updates Over The Air (SUOTA), content downloading and HTTP based
applications" (see ETSI TS 102 527-4 [5]).
TC Id
The TC Id is a unique identifier; it shall be specified according to the TC naming conventions defined in the clause 5.2.
Reference
When a flowchart number is given in reference, this flowchart is only a recommendation to implement the test case. As
a result, the TS shall be flexible enough to deal with several IUT implementations (dynamic behaviour).
Initial condition
It is stipulated when a test necessitates another registered PP (NG PP or legacy GAP PP).
By default (i.e. when no other PP is specified), the TS_1 and the IUT are involved together in the CC instance whose
CC control state is stipulated in the initial condition.
A test case reference is given when this TC has to be run to reach the initial condition (for example: "Run
TC_FT_NG1.N.16_BV_1802"). That means that this test case shall be run before the current one.
Pass criteria
• Criterion for checking "end-to-end U-plane connection": this is an operation to detect the state of the U−plane
connection. The acoustical path will be checked in both directions. When testing a PP, Test system could
perform an audio loopback and introduce a delay (e.g. 1 s) to create an echo. When testing a FP, Test system
could use a tone generation. In both cases, Test system could also use a handset receiver plugged in the
equipment.
• Some parameters used in TCs can be allocated by the IUT (e.g. call id, terminal identity number, session id,
line id, etc.) or be network dependant (line type information for each line). As a consequence a generic
notation is used in the TC description (respectively "call id A", "IA5 coding of terminal identity number in
decimal of PP1", session id n, line 0, lt0, etc.).
5.1.1 Test equipment implementation requirements
This clause specifies the general requirements to be implemented by the test equipment. The requirements listed below
can be valid either for several features on one side, or for one feature on both sides, PP and FP side. Specific
requirements for a single feature are given in the related clause describing the sub tests suite for this feature.
ETSI
14 ETSI TS 103 158 V1.1.1 (2014-11)
Order of information elements in NWK layer messages
• The IUT shall send Information elements in the correct order within a NWK layer message (as defined in
ETSI EN 300 175-5 [1], clause 7.5.1 "Coding rules"). This is valid for PT and FT sides.
NOTE 1: If this requirement is not respected, some test cases may fail on PT and FT side (as the test equipment will
expect the correct order).
Segmentation of information in CC procedures
• The IUT shall not use segmentation of NWK messages (defined in ETSI EN 300 175-5 [1], clause 9.9
"Segmentation of information in CC procedures").
NOTE 2: If this requirement is not respected, some test cases may fail on PT and FT side (as the test equipment will
expect only one segment).
NOTE 3: "Segmentation of information in CC procedures" is not mandatory for NG-DECT Part 3 [4] devices. So
such implementations may face interoperability problems in case the peer party does not support the same
mechanism.
Basic service used by the test equipment when initiating a call (external, internal, or list access service call)
• Within PT and FT test cases the test equipment shall behave as follows:
Rule 1: When behaving as a NG DECT device, the test equipment shall use by default the "Wideband speech
default setup attributes" basic service in IE <> at call setup (as required in
ETSI TS 102 527-1 [3], ETSI TS 102 527-3 [4] and ETSI TS 102 527-5 [6]). This is the default
behaviour for all test cases and especially in those where "TS_x is a NG PP" is mentioned. This basic
service shall also be used even in the test cases where outgoing calls to narrow band phones are
performed.
Rule 2: When behaving as a GAP device the test equipment shall use by default the "Basic speech default
setup attributes" basic service in IE <> at call setup (as required in
ETSI EN 300 444 [2]). This is the default behaviour for all test cases where "TS_x is a GAP PP" is
mentioned.
NOTE 4: The "automatic" rule 1 applies because in all the test cases of the current test specification, the test
equipment initiates calls only in front of NG-DECT PART5 IUTs (PP or FP) but not in front of GAP
IUTs. As a consequence the test equipment does not need to check the NG DECT capabilities of the
remote party (IUT) to define the basic service to be used.
NOTE 5: When receiving a call on the test equipment (internal calls for example), it is the IUT that will use the
correct basic service depending if the test equipment behaves as a NG DECT or GAP device.
5.1.2 Definitions of used MACROs (PT and FT sides)
The following Macros are used for the test body definition, for frequently re-used test chunks.
5.1.2.1 Basic service MACROs (request from PP to FP)
5.1.2.1.1 Suota C-plane
None.
5.1.2.1.2 Binary content download
The following values are defined binary content download in ETSI TS 102 527-4 [5], clause 7.6.1.4.
<> =
<< Basic-Service ,

ETSI
15 ETSI TS 103 158 V1.1.1 (2014-11)
5.1.2.1 Handset version indication MACRO (request from PP to FP)
The 'Handset version indication' command is defined in ETSI TS 102 527-4 [5], clause 7.5.5.2.1.
hsv_ind(emc=EMC, url1=URL1, fileNumber=FN, flags=F, reason=R, swv=SWV1, hwv=HWV1)=
local variables: n, N1(N1: fix integer value chosen by sender)
{FACILITY} message with IE <> with:
- Handset version indication (0H):
- emc=EMC
- URL1 to follow=N1
- fileNumber=FN
- flags
- reason
- SW Version id=SWV1
- HW Version id=HWV1
(followed in the same direction, for 1 ≤ n ≤ N1, by)
{FACILITY} message with IE <> with:
- URL indication (2H):
- URL to follow=N1-n
- URL content= cu ('URL1 content chunk' number u)
n
such that cu + cu +  + cu = URL1 (where '+' operator stands for string concatenation)
1 2 N1
5.1.2.2 Handset version available MACRO (from FP to PP)
The 'Handset version available' command is defined in ETSI TS 102 527-4 [5 ], clause 7.5.5.2.2. This is the answer to
command 'Handset version indication'.
hsv_avail(dm=DM, url2=URL2, u_inter=UI, swv=SWV)=
local variables: n, N2(N2: fix integer value chosen by sender)
{FACILITY} message with IE <> with:
- Handset version available (1H):
- DelayMinutes=DM
- URL2 to follow=N2
- User interaction=UI
- SW Version id=SWV
(followed in the same direction, for 1 ≤ n ≤ N2, by)
{FACILITY} message with IE <> with:
- URL indication (2H):
- URL to follow= N2-n
- URL content= cu ('URL2 content chunk' number n)
n
such that cu + cu + + cu = URL2 (where '+' operator stands for string concatenation)
1 2 N2
5.1.2.3 HTTP related MACROS
5.1.2.3.1 Submacros
filesize(url): size of the targeted resource (as a string)
request_uri(url): resource identifying part of the url (identification within the server)
EXAMPLE 1: request_uri("http://suota.example.com/Suota/suota1?test=2") = "/Suota/suota1?test=2"
hostname(url): server identifying part of the url
EXAMPLE 2: hostname("http://suota.example.com/Suota/suota1?test=2") = " suota.example.com"
ETSI
16 ETSI TS 103 158 V1.1.1 (2014-11)
5.1.2.3.2 range request MACRO (from PP to FP)
range request MACRO (from PP to FP)
range_http_req(target=URL2, r_low=RL, r_high=RH)=
GET request_uri(URL2) + " " + "HTTP1.1"\r\n
Host: hostname(URL2)\r\n
Accept: application/octet-stream\r\n
Range: bytes=RL-RH\r\n
\r\n
EXAMPLE: range_http_request("http://suota.example.com/Suota/suota1?test=2", 1000, 1999) =
GET /Suota/suota1?test=2 HTTP/1.1\r\n
Host: suota.example.com\r\n
Accept: application/octet-stream\r\n
Range: bytes=1000-1999\r\n
\r\n
5.1.2.3.3 HTTP range response MACRO (from FP to PP)
range_http_resp(target=URL2, r_low=RL, r_high= RH)=
HTTP/1.1 206 Partial Content
Content-Range: bytes=RL-RH/filesize(URL2) \r\n
Content-Length: value_of(RL-RH+1)\r\n
Content-Type: application/octet-stream\r\n
\r\n

5.1.2.3.4 HTTP error MACRO (from FP to PP)
http_error(e=HTTP_ERROR, text=TEXT)=
"HTTP/1.1" + " " + HTTP_ERROR + \r\n
\r\n
TEXT
5.2 TC naming conventions
Each feature to be tested corresponds to a group of test cases identified by its standard feature number.
The identifier of the TC is built according to table 3.
Table 3: TC naming convention
TC____
= type of radio termination FT Fixed radio Termination
PT Portable radio Termination
= feature number NG1.N.x New generation Network feature
GAP.N.x GAP Network feature
NG1.A.x New generation Application feature
GAP.A.x GAP Application feature
= Type of testing BV Valid Behaviour Tests
GC GAP backward compatibility Tests (see note 1)
WC NG-DECT Part 1 [3] backward compatibility Tests (note 2)
nn> = sequential number (01 to 99) Test Purpose Number
NOTE 1: GAP backward compatibility tests concern only the FP. These tests check FP specific behaviours for NG
features in front of GAP PPs.
NOTE 2: These tests are to ensure interoperability in front of legacy NG-DECT Part 1 "Wideband speech" devices.
NOTE 3: The procedure number refers to the number given to each procedure in Annex B. For example the
procedure "NG1.N.1_3 Codec Negotiation during call establishment" is the procedure number '3' of
NG1.N.1 Codec Negotiation feature. If several procedures are involved in the TS, the procedure number
refers to the procedure mainly tested.
...