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

SLOVENSKI STANDARD
SIST I-ETS 300 697-1 E1:2003
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)
SIST I-ETS 300 697-1 E1:2003 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST I-ETS 300 697-1 E1:2003

---------------------- Page: 2 ----------------------

SIST I-ETS 300 697-1 E1:2003
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: secretariat@etsi.fr - http://www.etsi.fr - http://www.etsi.org
Tel.: +33 4 92 94 42 00 - Fax: +33 4 93 65 47 16
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: 3 ----------------------

SIST I-ETS 300 697-1 E1:2003
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: 4 ----------------------

SIST I-ETS 300 697-1 E1:2003
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: 5 ----------------------

SIST I-ETS 300 697-1 E1:2003
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: 6 ----------------------

SIST I-ETS 300 697-1 E1:2003
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: 7 ----------------------

SIST I-ETS 300 697-1 E1:2003
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: 8 ----------------------

SIST I-ETS 300 697-1 E1:2003
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: 9 ----------------------

SIST I-ETS 300 697-1 E1:2003
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: 10 ----------------------

SIST I-ETS 300 697-1 E1:2003
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: 11 ----------------------

SIST I-ETS 300 697-1 E1:2003
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: 12 ----------------------

SIST I-ETS 300 697-1 E1:2003
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: 13 ----------------------

SIST I-ETS 300 697-1 E1:2003
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 diagr
...