ETSI I-ETS 300 697-1 ed.1 (1998-03)

Integrated Services Digital Network (ISDN); Conformance testing for the Euro-ISDN Programming Communication Interface (PCI); Part 1: Test Suite Structure and Test Purposes (TSS&TP) specification for the PCI User Facility (PUF)

DI/TE-02028-2

Digitalno omrežje z integriranimi storitvami (ISDN) – Preskušanje skladnosti programirljivega komunikacijskega vmesnika (PCI) sistema Euro-ISDN – 1. del: Zgradba preskušalnega niza in nameni preskušanja (TSS&TP) – Specifikacija uporabniških pripomočkov vmesnika PCI (PUF)

General Information

• Status: Published
• Publication Date: 07-Apr-1998
• Technical Committee: TE 2 - Telematics: Facsimile, Document Handling and Transfer
• Current Stage: 12 - Completion
• Due Date: 25-Mar-1998
• Completion Date: 08-Apr-1998
• Mandate: T-296
• Ref Project: SIST I-ETS 300 697-1 E1:2003 - Integrated Services Digital Network (ISDN); Conformance testing for the Euro-ISDN Programming Communication Interface (PCI); Part 1: Test Suite Structure and Test Purposes (TSS&TP) specification for the PCI User Facility (PUF)

Standards Content (Sample)

SLOVENSKI STANDARD
01-december-2003
'LJLWDOQRRPUHåMH]LQWHJULUDQLPLVWRULWYDPL,6'1±3UHVNXãDQMHVNODGQRVWL
SURJUDPLUOMLYHJDNRPXQLNDFLMVNHJDYPHVQLND3&,VLVWHPD(XUR,6'1±GHO
=JUDGEDSUHVNXãDOQHJDQL]DLQQDPHQLSUHVNXãDQMD766 73±6SHFLILNDFLMD
XSRUDEQLãNLKSULSRPRþNRYYPHVQLND3&,38)
Integrated Services Digital Network (ISDN); Conformance testing for the Euro-ISDN
Programming Communication Interface (PCI); Part 1: Test Suite Structure and Test
Purposes (TSS&TP) specification for the PCI User Facility (PUF)
Ta slovenski standard je istoveten z: I-ETS 300 697-1 Edition 1
ICS:
33.080 Digitalno omrežje z Integrated Services Digital
integriranimi storitvami Network (ISDN)
(ISDN)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

INTERIM
EUROPEAN I-ETS 300 697-1
TELECOMMUNICATION March 1998
STANDARD
Source: TE Reference: DI/TE-02028-2
ICS: 33.020
Key words: ISDN, PCI, testing, TSS&TP
Integrated Services Digital Network (ISDN);
Conformance testing for the Euro-ISDN Programming
Communication Interface (PCI);
Part 1: Test Suite Structure and Test Purposes (TSS&TP)
specification for the PCI User Facility (PUF)
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE
Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
Internet: [e-mail] - http://www.etsi.fr - http://www.etsi.org
Tel.: [phone] - Fax: [phone]
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 1998. All rights reserved.

Page 2
I-ETS 300 697-1: March 1998
Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to
"ETSI Editing and Committee Support Dept." at the address shown on the title page.

Page 3
I-ETS 300 697-1: March 1998
Contents
Foreword .5
Introduction.5
1 Scope .7
2 References.7
3 Abbreviations.7
4 Coverage.8
4.1 What is covered?.8
4.2 Choices for coverage.8
4.3 Invalid behaviour coverage .9
5 Testability of the PUF .9
6 PUF basic interconnection tests.9
7 Test Suite Structure (TSS) .10
7.1 Presentation.10
7.2 Coverage .11
8 Guidelines used for TP generation.12
8.1 Writing approach.12
8.2 TP identifiers.13
9 User Plane tests.13
10 Test Purposes .13
10.1 PP/AD (Administration Plane).13
10.1.1 PP/AD/CA (capability tests).13
10.1.1.1 PP/AD/CA/C1 (class 1).13
10.1.2 PP/AD/BV (valid behaviour) .15
10.1.2.1 PP/AD/BV/C1 (class 1).15
10.1.3 PP/AD/IV (invalid behaviour).16
10.1.3.1 PP/AD/IV/C1.17
10.2 PP/CO (Control Plane).17
10.2.1 PP/CO/CA (capability tests) .17
10.2.1.1 PP/CO/CA/C1 (class 1) .17
10.2.1.1.1 PP/CO/CA/C1/IC (incoming call
establishment) .17
10.2.1.1.2 PP/CO/CA/C1/OC (outgoing call
establishment) .18
10.2.1.1.3 PP/CO/CA/C1/DI (disconnection) .18
10.2.2 PP/CO/BV (valid behaviour).19
10.2.2.1 PP/CO/BV/C1 (class 1) .19
10.2.2.1.1 PP/CO/BV/C1/IC (incoming call
establishment) .19
10.2.2.1.2 PP/CO/BV/C1/OC (outgoing call
establishment) .19
10.2.2.1.3 PP/CO/BV/C1/DI (disconnection) .21
10.2.3 PP/CO/IV (Invalid behaviour tests).21
10.2.3.1 PP/CO/IV/C1 (class 1).22
10.3 PP/US (User Plane).22
10.3.1 PP/US/CA (capability) .22

Page 4
I-ETS 300 697-1: March 1998
10.3.1.1 PP/US/CA/C1 (class 1) . 22
10.3.1.1.1 PP/US/CA/C1/ICPC (incoming
connection PUF co-ordination). 23
10.3.1.1.2 PP/US/CA/C1/ICNC (incoming
connection NAF co-ordination). 23
10.3.1.1.3 PP/US/CA/C1/OCPC (outgoing
connection, PUF co-ordination). 23
10.3.1.1.4 PP/US/CA/C1/OCNC (outgoing
connection NAF co-ordination). 23
10.3.1.1.5 PP/US/CA/C1/ DI(disconnection). 24
10.3.1.1.6 PP/US/CA/C1/DA (data). 24
10.3.1.1.7 PP/US/CA/C1/ED (expedited data). 25
10.3.1.1.8 PP/US/CA/C1/RE (Reset) . 25
10.3.2 PP/US/BV (valid behaviour). 26
10.3.2.1 PP/US/BV/C1 (class 1) . 26
10.3.2.1.1 PP/US/BV/C1/IC (incoming call) . 26
10.3.2.1.2 PP/US/BV/C1/OC (outgoing call) . 26
10.3.2.1.3 PP/US/BV/C1/DI (disconnection) . 27
10.3.2.1.4 PP/US/BV/C1/DA (data). 27
10.3.3 PP/US/IV (invalid behaviour) . 27
10.3.3.1 PP/US/IV/C1 . 28
10.4 Miscellaneous. 28
10.4.1 Untestable Test Purposes . 28
Annex A (informative): Bibliography . 29
History. 30

Page 5
I-ETS 300 697-1: March 1998
Foreword
Part 1 of this Interim European Telecommunication Standard (I-ETS) has been produced by the Terminal
Equipment (TE) Technical Committee of the European Telecommunications Standards Institute (ETSI).
An ETSI standard may be given I-ETS status either because it is regarded as a provisional solution ahead
of a more advanced standard, or because it is immature and requires a "trial period". The life of an I-ETS
is limited to three years after which it can be converted into an ETS, have its life extended for a further two
years, be replaced by a new version, or be withdrawn.
This is the first part of an I-ETS which comprises four parts:
"Integrated Services Digital Network (ISDN); Conformance testing for the Euro-ISDN Programming
Communication Interface (PCI):
Part 1: "Test Suite Structure and Test Purposes (TSS&TP) for the PCI User Facility (PUF);
Part 2: "Abstract Test Suite (ATS) for the PCI User Facility (PUF);
Part 3: "Test Suite Structure and Test Purposes (TSS&TP) for the Network Access Facility (NAF);
Part 4: "Abstract Test Suite (ATS) for the Network Access Facility (NAF)".
Announcement date
Date of adoption of this I-ETS: 6 March 1998
Date of latest announcement of this I-ETS (doa): 30 June 1998
Introduction
I-ETS 300 697, Parts 1 to 4 comprises the Test Suite Structure and Test Purposes (TSS&TP) and the
Abstract Test Suites (ATS) to ETS 300 325 [1]. The Euro-ISDN PCI is a PCI which provides access to the
Euro-ISDN. The basic model of the ISDN PCI consists of two entities, a service user called the PCI User
Facility (PUF) and a service provider called the Network Access Facility (NAF). For the purposes of
conformance testing, the PUF and the NAF are treated separately. This is because the PUF manufacturer
and the NAF manufacturer may be completely different and their testing needs should be treated
separately. Each Part is tested to ensure that they each meet the conformance requirements of the I-ETS
and to increase their probability of inter-operating. This is the reason why a separate TSS&TP and a
separate Abstract Test Suite has been produced for both the PCI User Facility (PUF) and the Network
Access Facility (NAF).
All parts have been produced according to ISO/IEC 9646 [2] and ETS 300 406 [6].
As stated above, this I-ETS is structured in four parts:
- part 1 contains the TSS&TP for the PUF;
- part 2 contains the ATS for the PUF;
- part 3 contains the TSS&TP for the NAF;
- part 4 contains the ATS for the NAF.

Page 6
I-ETS 300 697-1: March 1998
Part 1 (TSS&TP for the PUF) contains all Test Purposes (TPs) for the PUF (PCI messages). It describes
what is covered by the TPs for the PUF and what areas of the I-ETS are not covered. The Test Suite
Structure (TSS) is described and the convention followed in naming the TPs is described. A list of basic
interconnection tests is given.
Part 2 (ATS for the PUF) contains the Abstract Test Suite (ATS) for the PUF (PCI messages). The test
method used is described in detail and diagrams explaining the test method are presented. The reasons
for choosing the test method are also given. The ATS is written in Tree and Tabular Combined Notation
(TTCN) and the TTCN is contained in annex A. Annex B contains the Protocol Conformance Test Report
(PCTR), annex C contains the Implementation eXtra Information for Testing (IXIT) and annex D contains
an Implementation Conformance Statement (ICS).
Part 3 (TSS&TP for the NAF) contains all TPs for the NAF (PCI messages and Exchange Mechanism). It
describes what is covered by the TPs for the NAF and what areas of the I-ETS are not covered. The TSS
is described and the TPs are given. A list of basic interconnection tests is given.
Part 4 (ATS for the NAF) contains the ATS for the NAF (PCI messages and Exchange Mechanism). The
test method used is described in detail and a diagram explaining the test method is given. The reasons for
choosing that test method is also given. The ATS is written in concurrent TTCN and the TTCN is
contained in annex A. Annex B contains the PCTR, annex C contains the IXIT and annex D contains an
ICS.
NOTE: The ICS in annexes D of Part 2 and Part 4 are informative as ETS 300 325 [1] already
contains an ICS. However, the ICS in ETS 300 325 [1] is not adequate for these ATSs
and should, eventually, be replaced by annexes D of Part 2 and Part 4 of this I-ETS.

Page 7
I-ETS 300 697-1: March 1998
1 Scope
Part 1 of this I-ETS contains the Test Suite Structure and the Test Purposes (TSS&TP) of the
conformance testing to ETS 300 325 [1] for a PUF. It indicates the choices of coverage which have been
made, makes some remarks about the testability of a PUF, describes the TSS in a general way and
contains all TPs, structured in accordance with the TSS.
2 Normative references
Part 1 of this I-ETS incorporates by dated or undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed
hereafter. For dated references, subsequent amendments to or revisions of any of these publications
apply to this I-ETS only when incorporated in it by amendment or revision. For undated references the
latest edition of the publication referred to applies.
[1] ETS 300 325 (1994): "Integrated Services Digital Network (ISDN); Programming
Communication Interface (PCI) for Euro-ISDN".
[2] ISO/IEC 9646 (1994): "Information technology - Open Systems Interconnection -
Conformance Testing Methodology and Framework".
[3] ISO/IEC 8208 (1990): "Information technology; Data communications; X.25
Packet Layer Protocol for Data Terminal Equipment".
[4] ETS 300 080 (1992): "Integrated Services Digital Network (ISDN); ISDN lower
layer protocols for telematic terminals".
[5] ETS 300 102-1: "Integrated Services Digital network (ISDN); User-network
interface layer 3; Specifications for basic call control".
[6] ETS 300 406 (1995): "Methods for Testing and Specification (MTS); Protocol
and profile conformance testing specifications; Standardisation methodology".
3 Abbreviations
For the purposes of this I-ETS the following abbreviations apply:
AD Administration Plane
AOC-D Advice Of Charge During call
AOC-E Advice Of Charge at the End of call
ATS Abstract Test Suite
BV Valid behaviour
CA Capability tests
Ci Control Plane state i
CLIR Calling Line Identification Restriction
CO Control Plane
DA Data transfer
DDI Direct Dialling In
DI Disconnection
ED Exchange Mechanism (DOS)
ED Expedited Data
EU Exchange Mechanism (Unix)
EW Exchange Mechanism (Windows)
IC Incoming Call establishment
ICS Implementation Conformance Statement
ISDN Integrated Services Digital Network
IUT Implementation Under Test
IV Invalid behaviour
IXIT Implementation eXtra Information for Testing
NAF Network Access Facility
NC NAF co-ordination
NCO Network Connection Object
Page 8
I-ETS 300 697-1: March 1998
NCOID NCO Identifier
NMA Network layer Message Access
NUi User Plane state i in case of NAF co-ordination
OC Outgoing Call establishment
OP Optional
PC PUF co-ordination
PCI Programming Communication Interface
PCTR Protocol Conformance Test Report
PP Euro-ISDN PCI PUF
PUF PCI User Facility
PUi User Plane state i in case of PUF co-ordination
RE Reset
TE Terminal Equipment
TMA Transparent Message Access
TP Test Purpose
TSS Test Suite Structure
TSS&TP Test Suite Structure & Test Purposes
TTCN Tree and Tabular Combined Notation
US User Plane
4 Coverage
In this first version, only the most important parts of ETS 300 325 [1] are covered and other parts have
been ignored. These parts are described below. Moreover, the final test campaign should be limited to a
duration of one day. This implies that some choices were necessary which are outlined below.
4.1 What is covered?
All mandatory conformance requirements in ETS 300 325 [1] are covered, except the Exchange
Mechanism. The purposes cover the following parts of the ETS:
- Administration Plane (class 1);
- Control Plane (class 1);
- User Plane (ISO/IEC 8208 [3], ETS 300 080 [4], ITU-T Recommendation T.70, NULL, ETS 300 325
[1]: Transparent Message Access (TMA).
The TPs do not cover the following parts of ETS 300 325 [1]:
- Exchange Mechanism;
- Administration Plane (classes 2, 3);
- Control Plane (classes 2, 3, 4, 5, 6).
4.2 Choices for coverage
Because of the nature of conformance testing, everything cannot be fully tested. In addition, because of
the limitation on the time required for execution of the test suite, further choices have been made.
All messages and all mandatory parameters for the elements of the ETS 300 325 [1] listed above, are
tested. Some of the optional functions are tested, i.e. in the Exchange Mechanism.
Not all optional parameters have been tested in all of the messages where they are optional, instead a
representative sample has been tested where use of the parameter is most likely to occur, e.g. the Facility
parameter which deals with charging information is tested in the CConnectReq message and not in the
CAlertReq message.
In addition, the optional Control Plane parameters are tested in the context of the use of supplementary
services, if possible. Also more testing is performed in the PUF to NAF direction than in the direction from
NAF to PUF because the behaviour of the PUF at the interface can be observed and assigned final
verdicts. All parameters relevant for covered parts of ETS 300 325 [1], described in the previous
subclause, are tested at least once.

Page 9
I-ETS 300 697-1: March 1998
4.3 Invalid behaviour coverage
Although the behaviour of the PUF on receiving messages which are invalid e.g. mandatory parameter
missing, is not specified in ETS 300 325 [1], a limited number of tests are included in order to check the
operation of the PUF. Because ETS 300 325 [1] does not specify how the PUF shall react to such
messages, the verdicts from these tests may only be INCONCLUSIVE or PASS. This topic is further
explained in a later clause.
5 Testability of the PUF
The lower interface of the PUF is defined in ETS 300 325 [1], i.e. it is the interface with a NAF, therefore
behaviour at this interface can be both controlled and observed without any difficulty. Since PUFs are
application specific, they may vary a lot in their actual implementation. The upper interface of the PUF is
not specified in ETS 300 325 [1] and is a high level interface, e.g. a human interface. The nature of this
interface makes testing of the PUF difficult because of the problems observing and controlling the
behaviour of the PUF here.
Control
Where control of the upper interface is necessary in order to initiate some action, the means of control
shall be stated in the IXIT in answer to a specific question. The control shall be by means of an implicit
send statement in the test case. Control shall be necessary when the PUF is the initiator of some action,
e.g. to initiate a user connection the IXIT asks: how does the IUT send a U3ConnectReq message in
order to initiate an outgoing user connection?
Observation
Where observation of the upper interface is necessary in order to assign a verdict, the behaviour which
should be observed is stated in the IXIT in answer to a specific question, e.g. how does the IUT react on
receiving a CConnectCnf message in state 1? In such a case, behaviour at the lower interface cannot be
used to assign the verdict because nothing observable occurs here (e.g. an internal change of NCO state
is not observable). This verdict shall be assigned by the test suite operator. If the observation is not that
specified in the IXIT, then the only possible verdict shall be an INCONCLUSIVE verdict, as a FAIL verdict
cannot be assigned because the PUF has not failed to meet what is stated in ETS 300 325 [1].
Although it may not be normal practice to rely on observations at such an upper interface, this was the
only way found to test many of the messages of the PUF, in particular when the PUF is receiving incoming
messages. Sometimes where no specific observation at the upper interface can be made the IXIT answer
could be "IUT does not react", this might mean that the IUT has not crashed for example. A simple
mechanism shall be provided to de-select all test cases relying on observation at the upper interface
where such de-selection is deemed necessary. These test cases might be optional conformance
requirements. The corresponding TPs are marked by the key word "OP" (optional).
However, in most cases, even if the result of a received message is not immediately observable at the
lower interface, it is implicitly tested in TPs which deal with other messages. For example, the result of an
ACreateNCOCnf message is implicitly tested in Control and User Plane groups: if the IUT is able to
manage these planes, this means that it understood the Network Connection Object IDentifier (NCOID)
parameter of the previous ACreateNCOCnf. In the same way, if the capability tests for the User Plane (in
PUF co-ordination case), pass in case of an outgoing call, this means that the transition to the active state
in the Control Plane succeeded. When a "OP" TP is in fact covered by a TP concerning another message,
this shall be indicated. This may be used as another criterion to de-select it.
6 PUF basic interconnection tests
There is no basic interconnection test group in the TSS. However, a list of basic interconnection tests is
provided here. These tests may be executed on the IUT prior to execution of the test suite in order to give
the IUT implementor confidence that the IUT can perform certain basic tasks. The tests have been
chosen to check that the IUT can perform simple tasks on each of the three planes, i.e. create a Network
Connection Object (NCO), set up a D-channel and transfer data on the B-channel. Some operations from
the Exchange Mechanism are specifically included and other operations from the Exchange Mechanism
are exercised in the other test cases.

Page 10
I-ETS 300 697-1: March 1998
PCI Message Test case identifier
ACreateNCOReq TP411006
ACreateNCOReq TP411008
CConnectRsp TP511103
CConnectReq TP511201
CConnectCnf TP511204
CDisconnectReq TP511301
CDisconnectRsp TP511305
U3ConnectInd TP611101
U3ConnectReq TP611201
U3DisconnectReq TP611302
U3DataReq TP611401
U3DataInd TP611402
U1DataReq TP611410
U1DataInd TP611411
7 Test Suite Structure (TSS)
7.1 Presentation
The test suite is structured as a tree in accordance with ISO/IEC 9646 [2]. There are two main reasons for
structuring the test suite as a tree. Firstly, so that part of the tree can be selected for testing, e.g. the
capability tests and secondly, to be able to see clearly the type of coverage of the base standard that is
provided by the test suite.
The first level of the tree is the identifier of the ETS, Euro-ISDN PCI, PUF.
The second level represents the major divisions of the ETS, i.e. the Exchange Mechanism and the three
planes.
The third level represents the nature of the tests to be performed, capability tests which show a basic
capability of the ETS to operate, i.e. a message containing mandatory parameters only, valid behaviour
tests where some additional features are tested, i.e. optional parameters, and invalid behaviour tests
where the response of the Implementation Under Test (IUT) to invalid behaviour by the tester is checked.
The fourth level represents the class of the messages.
The fifth level represents the functionality of the ETS covered by the test and is relevant only to the Control
and User Planes.
The TSS is now detailed. For each branch a two/four character identifier is given as a number which shall
be used to generate unique identifiers for the TPs.
First level: it is the identifier of the ETS.
Euro-ISDN PCI PUF (PP)
Second level: it represents the major divisions of the ETS, the Exchange Mechanism and the three
planes:
- Exchange Mechanism (Windows) (EW) (1) Not covered;
- Exchange Mechanism (DOS) (ED) (2) Not covered;
- Exchange Mechanism (Unix) (EU) (3) Not covered;
- Administration Plane (AD) (4);
- Control Plane (CO) (5);
- User Plane (US) (6).
Third level: the nature of the tests to be performed:
capability tests (CA) (1);
Page 11
I-ETS 300 697-1: March 1998
valid behaviour tests (BV) (2);
invalid behaviour tests (IV) (3).
Fourth level: the class of the messages. This level is not relevant for the Exchange Mechanism.
class 1 (C1) (1);
class 2 (C2) (2) Not covered;
class 3 (C3) (3) Not covered;
class 4 (C4) (4) Not covered;
class 5 (C5) (5) Not covered;
class 6 (C6) (6) Not covered.
Fifth level: a functionality of the standard covered by the class (depending on the class).
For Control Plane class 1:
incoming call establishment (IC) (1);
outgoing call establishment (OC) (2);
disconnection (DI) (3).
For the User Plane class 1: groups about incoming and outgoing calls establishment are duplicated, one
for PUF co-ordination and one NAF co-ordination (for more details see clause 8). They have the same
digit as identifier, but the type of co-ordination shall be indicated in brackets, at the end of TP identifiers:
incoming call establishment, PUF co-ordination (ICPC) (1 [P]);
incoming call establishment, NAF co-ordination (ICNC) (1 [N]);
outgoing call establishment, PUF co-ordination (OCPC) (2 [P]);
outgoing call establishment, NAF co-ordination (OCNC) (2 [N]);
disconnection (DI) (3);
data transfer (DA) (4);
expedited data (ED) (5);
reset (RE) (6).
7.2 Coverage
This subclause indicates the number of TPs per level.
First level:
Euro-ISDN PCI PUF: 99.
Second level:
- Administration Plane: 31;
- Control Plane: 32;
- User Plane: 36.
Third level:
capability tests: 51;
valid behaviour tests: 42;
invalid behaviour tests 6.
Fourth level: not relevant for coverage aspects.
Fifth level: a functionality of the standard covered by the class (depending on the class).
For Control Plane class 1:
incoming call establishment: 4;
outgoing call establishment: 17;
disconnection: 8.
Page 12
I-ETS 300 697-1: March 1998
For the User Plane class 1:
incoming call establishment: 3;
outgoing call establishment: 8;
disconnection: 4;
data transfer: 13;
expedited data: 2;
reset: 4.
NOTE: There are 22 (OP) TPs.
8 Guidelines used for TP generation
8.1 Writing approach
In writing the TPs, a uniform approach has been adopted, in order to facilitate their understanding.
Common phrases are used throughout all TPs, depending on two cases:
- for the TPs where the IUT is the initiator, i.e. control on the upper interface (e.g. test operator
action):
ensure that the IUT in < initial state>,
in order to ,
.
- for the TPs where the IUT is not the initiator, i.e. control on the lower interface (message from the
NAF):
ensure that the IUT in < initial state>,
on receiving ,
.
initial state ::= Ci | PUi | .< and additional information> (see below for more details)
goal ::= e.g. initiate an outgoing call .
observable-action1 ::=
observable-action2 ::= |
send action ::= sends (lower interface observation)
react action ::= reacts as stated in IXIT.pper interface observation)
message ::= message [containing parameter with
encoded as ]
EXAMPLE: Ensure that the IUT in state C0, in order to initiate an outgoing call activating the
Advice Of Charge at the End of the call (AOC-E) supplementary service, sends
a CConnectReq message containing the Facility parameter with a FacilityTag
field encoded as chargingend and no FacilityValue field.
Remarks about initial state:
- whenever it is written that the IUT is in state CX, this in fact means that the NCO connection is in
state CX. Since there are state diagrams described for both the Control Plane and the User Plane
and the same numbers are used in both diagrams, states of the Control Plane are prefixed with a
'C', e.g. Control Plane, and states of the User Plane are prefixed with a "U", e.g. U4. When it is
necessary to distinguish PUF co-ordination and NAF co-ordination cases, they are prefixed by "PU"
or "NU", e.g. PU1 is state 1 where PUF co-ordination is present and NU2 is state 2 where NAF co-
ordination is present;
Page 13
I-ETS 300 697-1: March 1998
- only the state of the tested plane is mentioned. The state of other relevant planes are implicit. For
example, if the initial state of a TP concerning an outgoing call on the Control Plane is Control Plane
(Control Plane, idle), it is implicit that on the Administration Plane, a NCO with the relevant
CDirection was created. For the PUF co-ordination User Plane tests, it is implicit that the Control
Plane is in the active state.
8.2 TP identifiers
The following convention is used to give unique identifiers to the TPs:
TPabcdxy - where a, b, c and d correspond to the digits associated with each branch of the TSS:
a for the second level of the TSS tree;
b for the third level of the TSS tree;
c for the fourth level of the TSS tree;
d for the fifth level of the TSS tree;
xy for two digit identifier.
NOTE: When a level is not relevant, 0 is used.
EXAMPLE: TP511213. This TP is the 13th test belonging to the PP/CO/CA/C1/OC group.
The code of this group expands out to:
PCI PUF/CO/CA/class 1/Outgoing Call.
9 User Plane tests
PUF co-ordination and NAF co-ordination cases are treated separately, except for capability tests about
connection establishment. For these tests, the co-ordination notion is important. For the others TPs, the
aim is to test messages or parameters for which the co-ordination type is not important. This is why, in
that case, the TPs are not duplicated.
NOTE: When a TP is not duplicated, only one test case exists in the ATS. The preamble
executed differs according to the co-ordination type, and is chosen according to a
global variable.
10 Test Purposes
This clause contains the TPs, presented according to the TSS described previously.
10.1 PP/AD (Administration Plane)
Test group objective: To check the use of the Administration Plane messages by the IUT.
Subgroups:
- CA (capability);
- BV (valid behaviour);
- IV (invalid behaviour).
10.1.1 PP/AD/CA (capability tests)
Test group objective: To check the capability of the IUT to use Administration Plane messages, in order
to manage NCOs.
Subgroup: Only class 1 is treated:
- C1 (class 1).
10.1.1.1 PP/AD/CA/C1 (class 1)
Test group objective: To check the capability of the IUT to use Administration Plane class 1 messages.

Page 14
I-ETS 300 697-1: March 1998
Test Purposes:
TP411001 (reference ETS 300 325 [1], subclause 6.2.1).
key words: ACreateNCOReq, C.
Ensure that the IUT, in order to request creation of an NCO of type C, sends an ACreateNCOReq
message containing an NCOType parameter with an Identifier encoded as cset.
TP411002 (reference ETS 300 325 [1], subclause 6.2.1).
key words: ACreateNCOReq, C/U1.
Ensure that the IUT, in order to request creation of an NCO of type C/U1 (TMA), sends an
ACreateNCOReq message containing an NCOType parameter with an Identifier encoded as
s1u1set.
TP411003 (reference ETS 300 325 [1], subclause 6.2.1).
keywords: ACreateNCOReq, NCOType, C/U3.
Ensure that the IUT, in order to request creation of an NCO of type C/U3, sends an
ACreateNCOReq message containing an NCOType parameter with an Identifier encoded as
s1/u3set.
TP411004 (reference ETS 300 325 [1], subclause 6.2.1).
keywords: ACreateNCOReq, NCOType, U3.
Ensure that the IUT, in order to request creation of an NCO of type U3, sends an ACreateNCOReq
message containing an NCOType parameter with an Identifier encoded as u3set.
TP411005 (reference ETS 300 325 [1], subclause 6.2.1).
keywords: ACreateNCOReq, NCOType, U3G.
Ensure that the IUT, in order to request creation of an NCO of type U3G, sends an
ACreateNCOReq message containing an NCOType parameter with an Identifier encoded as
u3group and a GroupID parameter of a previously created NCO.
TP411006 (reference ETS 300 325 [1], subclause 6.7.1).
keywords: AcreateNCOReq, CDirection, incoming.
Ensure that the IUT, in order to be able to receive an incoming call, sends an ACreateNCOReq
message, containing a UDirection parameter with Direction field encoded as listen or both, and/or
containing a CDirection parameter with Direction field encoded as listen or both.
TP411007 (reference ETS 300 325 [1], subclause 6.7.1).
keywords: AcreateNCOReq, UDirection, UDirection, incoming.
Ensure that the IUT, in order to be able to receive an inco.ming call, sends an ACreateNCOReq
message, containing a CDirection parameter with Direction field encoded as listen or both.
TP411008 (reference ETS 300 325 [1], subclause 6.7.1).
keywords: AcreateNCOReq, CDirection, outgoing.
Ensure that the IUT, in order to be able to initiate outgoing call, sends an ACreateNCOReq
message, containing a CDirection parameter with Direction field encoded as call or both.
TP411009 (reference ETS 300 325 [1], subclause 6.7.1).
keywords: AcreateNCOReq, UDirection, outgoing.
Ensure that the IUT, in order to be able to initiate outgoing user connection, sends an
ACreateNCOReq message, containing a UDirection parameter with Direction field encoded as call
or both.
TP411010 (reference ETS 300 325 [1], subclause 6.2.4).
keywords: ADestroyNCOReq.
Ensure that the IUT, in order to destroy an NCO, sends an ADestroyNCOReq message containing
the correct NCOID parameter.
TP411011 (reference ETS 300 325 [1], subclause 6.2.5)(OP).
keywords: ADestroyNCOCnf.
Ensure that the IUT, after having sent a ADestroyNCOReq message containing a NCOID, on
receiving an ADestroyNCOCnf message containing the same NCOID, reacts as stated in IXIT.

Page 15
I-ETS 300 697-1: March 1998
TP411012 (reference ETS 300 325 [1], subclause 6.2.7).
keyword: AGetNCOInfoReq.
Ensure that the IUT, in order to get information about an NCO, sends an AGetNCOInfoReq
message containing the correct NCOID
TP411013 (reference ETS 300 325 [1], subclause 6.2.8) (OP).
keyword: AGetNCOInfoCnf.
Ensure that the IUT, on receiving an AGetNCOInfoCnf message in response to a previously sent
AGetNCOInfoReq message, reacts as stated in the IXIT.
10.1.2 PP/AD/BV (valid behaviour)
Test group objective: To check the use of Administration Plane messages by the IUT, in specific
conditions, e.g. parameter variation.
Subgroups: Only class 1 is treated:
- C1 (class 1).
10.1.2.1 PP/AD/BV/C1 (class 1)
Test group objective: To check the use of Administration Plane class 1 messages by the IUT, in specific
conditions, e.g. parameter variation.
Test Purposes:
TP421001 (reference ETS 300 325 [1], subclause 6.2.1, table 10).
keywords: ACreateNCOReq, RequestID.
Ensure that the IUT, in order to request creation of an NCO indicating a RequestID, sends an
ACreateNCOReq message containing a RequestID parameter.
TP421002 (reference ETS 300 325 [1], subclause 6.2.1, table 10).
key words: ACreateNCOReq, CAttribute.
Ensure that the IUT, in order to request creation of an NCO indicating the CAttribute, sends an
ACreateNCOReq message containing a CAttributeName parameter or (XOR) a CAttribute
parameter.
TP421003 (reference ETS 300 325 [1], subclause 6.2.1, table 10).
key words: ACreateNCOReq, UAttribute.
Ensure that the IUT, in order to request creation of an NCO indicating the UAttribute, sends an
ACreateNCOReq message containing a UAttributeName parameter or (XOR) a UAttribute
parameter.
TP421004 (reference ETS 300 325 [1], subclause 6.2.1, table 10).
keywords: ACreateNCOReq, CAddress.
Ensure that the IUT, in order to request creation of an NCO indicating the C address, sends an
ACreateNCOReq message containing a CAddress parameter.
TP421005 (reference ETS 300 325 [1], subclause 6.2.1, table 10).
keywords: ACreateNCOReq, UAddress.
Ensure that the IUT, in order to request creation of an NCO indicating the user address, sends an
ACreateNCOReq message containing a UAddress parameter.
TP421006 (reference ETS 300 325 [1], subclause 6.2.1).
key words: ACreateNCOReq, Several.
Ensure that the IUT, in order to create 2 NCOs to be able to handle 2 connections, sends 2
ACreateNCOReq messages.
TP421007 (reference ETS 300 325 [1], subclause 5.7, 6.2.1).
key words: ACreateNCOReq, SelectorId.
Ensure that the IUT, in order to create 2 NCOs with the same SelectorId, sends a ACreateNCOReq
message with a SelectorId parameter and sends a ACreateNCOReq message with the same
SelectorId.
Page 16
I-ETS 300 697-1: March 1998
TP421008 (reference ETS 300 325 [1], subclause 6.2.1).
key words: ACreateNCOReq, NMA, ISO/IEC 8208 [3].
Ensure that the IUT, in order to create an NCO permitting an ISO/IEC 8208 [3] connection, sends
an ACreateNCOReq message containing a UAttribute parameter with U3protocol encoded as
ISO/IEC 8208 [3].
TP421009 (reference ETS 300 325 [1], subclause 6.2.1).
key words: ACreateNCOReq, NMA, ETS 300 080 [4].
Ensure that the IUT, in order to create an NCO permitting an ETS 300 080 [4] connection, sends an
ACreateNCOReq message containing a UAttribute parameter with U3protocol encoded as ETS 300
080 [4] or an AttributeName parameter encoded as U_TELEMATIC_TERM.
TP421010 (reference ETS 300 325 [1], subclause 6.2.1).
key words: ACreateNCOReq, NMA, T.70.
Ensure that the IUT, in order to create an NCO permitting an ISO/IEC 8208 [3] connection, sends
an ACreateNCOReq message containing a UAttribute parameter with U3protocol encoded as T.70.
TP421011 (reference ETS 300 325 [1], subclause 6.2.1).
key words: ACreateNCOReq, NMA, NULL.
Ensure that the IUT, in order to create an NCO permitting an connection with a NULL layer 3
protocol, sends an ACreateNCOReq message containing a UAttribute parameter with U3protocol
encoded as NULL.
TP421012 (reference ETS 300 325 [1], subclause 6.2.1, table 10).
keywords: ACreateNCOReq, NCOType, C, prohibited parameters.
Ensure that the IUT, in order to request creation of an NCO of type C, sends an ACreateNCOReq
message, containing no UAttributeName, no UAttribute parameters, no UAddress parameters, no
GroupID.
TP421013 (reference ETS 300 325 [1], subclause 6.2.1, table 10).
key words: ACreateNCOReq, C/U1, prohibited parameters.
Ensure that the IUT, in order to request creation of an NCO of type C/U1 (TMA), sends an
ACreateNCOReq message containing no UAddress parameters, no GroupID.
TP421014 (reference ETS 300 325 [1], subclause 6.2.1, table 10).
keywords: ACreateNCOReq, NCOType, C/U3, prohibited parameters.
Ensure that the IUT, in order to request creation of an NCO of type C/U3, sends an
ACreateNCOReq message containing no GroupId parameter.
TP421015 (reference ETS 300 325 [1], subclause 6.2.1, table 10).
keywords: ACreateNCOReq, NCOType, U3, prohibited parameters.
Ensure that the IUT, in order to request creation of an NCO of type U3, sends an ACreateNCOReq
message containing no GroupId parameter.
TP421016 (reference ETS 300 325 [1], subclause 6.2.1, table 10).
keywords: ACreateNCOReq, NCOType, U3G, prohibited parameters.
Ensure that the IUT, in order to request creation of an NCO of type U3G, sends an
ACreateNCOReq message containing no CAttributeName, no CAttribute parameters, no CAddress
parameters.
TP421017 (reference ETS 300 325 [1], subclause 6.23) (OP).
keyword: ACreateNCOCnf, CompletionStatus, NAFnotAvailable.
Ensure that the IUT, on receiving an ACreateNCOCnf message containing a CompletionStatus
parameter with the Status field coded as NAFnotAvailable (255), in response to a previously
ACreateNCOReq sent, reacts as stated in IXIT.
10.1.3 PP/AD/IV (invalid behaviour)
Test group objective: To check the reaction of the IUT on invalid behaviour of the NAF when using
Administration Plane messages. The behaviour of the IUT is not specified in ETS 300 325 [1], thus this is
an 'OP' group.
Page 17
I-ETS 300 697-1: March 1998
Subgroups: Only one class is treated:
C1 (class 1).
10.1.3.1 PP/AD/IV/C1
Test group objective: To check the reaction of the IUT on invalid behaviour of the NAF when using
Administration Plane class 1 messages. The behaviour of the IUT is not specified in ETS 300 325 [1], thus
this is an 'OP' group.
Test Purposes:
TP431001 (reference ETS 300 325 [1], subclause 6.2.5) (OP).
keywords: mandatory parameter missing.
Ensure that the IUT, on receiving an ADestroyNCOCnf message without the CompletionStatus
parameter, in response to a previously sent ADestroyNCOReq message, reacts as stated in IXIT.
10.2 PP/CO (Control Plane)
Test group objective: To check the use of Control Plane messages by the IUT, in order to manage
ETS 300 102-1 [5] calls These messages are used only in the PUF co-ordination case.
Subgroups:
- CA (capability);
- BV (valid behaviour);
- IV (invalid behaviour).
Selected only in PUF co-ordination case.
10.2.1 PP/CO/CA (capability tests)
Test group objective: To check the capability of the IUT to use Control Plane messages.
Subgroups: only class 1 is treated:
- C1 (class 1).
10.2.1.1 PP/CO/CA/C1 (class 1)
Test group objective: To check the capability of the IUT to use Control Plane class 1 messages.
Subgroups:
- IC (incoming);
- OC (outgoing);
- DI (disconnection).
10.2.1.1.1 PP/CO/CA/C1/IC (incoming call establishment)
Test group objective: To check the capability of the IUT to use Control Plane class 1 messages, in the
case of incoming call establishment. This group deals with CConnectInd, CAlertReq and CConnectRsp
messages.
Page 18
I-ETS 300 697-1: March 1998
Test Purposes:
TP511101 (reference ETS 300 325 [1], subclauses 6.3.2 and 6.3.5, figure 9).
key words: CConnectInd, CAlertReq.
Ensure that the IUT in state Control Plane, on receiving a CConnectInd message containing
CalledNumber, CalledSubaddress, BearerCap, LLC, HLC parameters encoded as stated in IXIT, in
order to indicate its compatibility with the incoming call, sends a CAlertReq message, containing the
correct NCOID.
TP511102 (reference ETS 300 325 [1], subclauses 6.3.5 and 6.3.6, figure 9).
Key words: CAlertReq, C3.
Ensure that the IUT in state C3, in order to accept the incoming call, sends a CConnectRsp
message, containing the correct NCOID.
TP511103 (reference ETS 300 325 [1], subclauses 6.3.5, and 6.3.6, figure 9).
Key words: CConnectInd, CConnectRsp, C0.
Ensure that the IUT in state C0, on receiving a CConnectInd message containing CalledNumber,
CalledSubaddress, BearerCap, LLC, HLC parameters encoded as stated in IXIT, in order to accept
the incoming call, sends a CConnectRsp message, containing the correct NCOID.
...