ETSI ETS 300 196-6 ed.1 (1998-04)

SLOVENSKI STANDARD
01-december-1998
'LJLWDOQRRPUHåMH]LQWHJULUDQLPLVWRULWYDPL,6'1*HQHULþQLIXQNFLMVNLSURWRNRO
]DSRGSRURGRSROQLOQLKVWRULWHY3URWRNROGLJLWDOQHQDURþQLãNHVLJQDOL]DFLMHãW
'66GHO$EVWUDNWQLSUHVNXãDOQLQL]$76LQGHOQDGRGDWQDLQIRUPDFLMD]D
SUHVNXãDQMHL]YHGEHSURWRNROD3,;,73URIRUPDVSHFLILNDFLMH]DRPUHåMH
Integrated Services Digital Network (ISDN); Generic functional protocol for the support of
supplementary services; Digital Subscriber Signalling System No. one (DSS1) protocol;
Part 6: Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information
for Testing (PIXIT) proforma specification for the network
Ta slovenski standard je istoveten z: ETS 300 196-6 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.

EUROPEAN ETS 300 196-6
TELECOMMUNICATION April 1998
STANDARD
Source: SPS Reference: DE/SPS-05005-6
ICS: 33.020
Key words: ISDN, DSS1, supplementary service, testing, ATS, PIXIT, network
Integrated Services Digital Network (ISDN);
Generic functional protocol for the support of
supplementary services;
Digital Subscriber Signalling System No. one (DSS1) protocol;
Part 6: Abstract Test Suite (ATS) and partial Protocol
Implementation eXtra Information for Testing (PIXIT) proforma
specification for the network
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 2
ETS 300 196-6: April 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
ETS 300 196-6: April 1998
Contents
Foreword .7
1 Scope .9
2 Normative references.9
3 Definitions and abbreviations .10
3.1 Definitions .10
3.2 Abbreviations .10
4 Abstract Test Method (ATM).11
4.1 Description of ATM used .11
4.1.1 Conventions for test components and PCOs.11
4.1.2 Conventions for variables and parameters .12
4.2 Alternative ATM .13
5 Untestable test purposes.14
6 ATS conventions .14
6.1 Declarations part.14
6.1.1 Type definitions .14
6.1.1.1 Simple type definitions.14
6.1.1.2 Structured type definitions .14
6.1.1.2.1 TTCN structured type definitions .14
6.1.1.2.2 ASN.1 structured type definitions.14
6.1.1.3 ASP type definitions.16
6.1.1.3.1 TTCN ASP type definitions .16
6.1.1.3.2 ASN.1 ASP type definitions .16
6.1.1.4 PDU type definitions .16
6.1.1.4.1 TTCN PDU type definitions.16
6.1.1.4.2 ASN.1 PDU type definitions .16
6.1.2 Test suite constants .16
6.1.3 Test suite parameters .17
6.1.4 Variables .17
6.1.4.1 Test suite variables.17
6.1.4.2 Test case variables.17
6.1.5 Test suite operation definitions.17
6.2 Constraints part.18
6.2.1 Structured type constraint declaration.18
6.2.2 ASN.1 type constraint declaration .18
6.2.2.1 Specification of encoding rules.18
6.2.3 ASP type constraint declaration .18
6.2.3.1 ASN.1 ASP type constraint declaration .18
6.2.3.2 TTCN ASP type constraint declaration.18
6.2.4 PDU type constraint declaration.18
6.2.4.1 ASN.1 PDU type constraint declaration.18
6.2.4.2 TTCN PDU type constraint declaration .18
6.2.5 Chaining of constraints.19
6.2.5.1 Static chaining .19
6.2.5.2 Dynamic chaining .19
6.2.6 Derived constraints.19
6.2.7 Parameterized constraints.19
6.2.8 Value assignment.19
6.2.8.1 Specific values.19
6.2.8.2 Matching values.19
6.3 Dynamic part.20
6.3.1 Test cases.20

Page 4
ETS 300 196-6: April 1998
6.3.2 Test steps . 20
6.3.2.1 PTC1_IN . 20
6.3.2.2 PTC1_OUT . 20
6.3.3 Defaults. 20
7 ATS to TP map . 20
8 PCTR conformance. 20
9 PIXIT conformance. 21
10 ATS conformance. 21
Annex A (normative): Protocol Conformance Test Report (PCTR) proforma . 22
A.1 Identification summary. 22
A.1.1 Protocol conformance test report. 22
A.1.2 IUT identification. 22
A.1.3 Testing environment. 22
A.1.4 Limits and reservations . 23
A.1.5 Comments. 23
A.2 IUT conformance status . 23
A.3 Static conformance summary. 23
A.4 Dynamic conformance summary. 23
A.5 Static conformance review report . 24
A.6 Test campaign report. 24
A.7 Observations. 27
Annex B (normative): Partial PIXIT proforma . 28
B.1 Identification summary. 28
B.2 Abstract test suite summary . 28
B.3 Test laboratory. 28
B.4 Client (of the test laboratory) . 29
B.5 System Under Test (SUT) . 29
B.6 Protocol information. 30
B.6.1 Protocol identification . 30
B.6.2 Parameter values . 30
B.6.3 Actions Required to provoke the IUT . 30
B.6.4 Options supported by the IUT . 30
B.6.5 Timer values. 31
B.7 Basic call PIXIT items. 31
B.7.1 Parameter values - information element codings. 31
Annex C (normative): Abstract Test Suite (ATS). 32
C.1 The TTCN Graphical form (TTCN.GR) .32
C.2 The TTCN Machine Processable form (TTCN.MP) . 32

Page 5
ETS 300 196-6: April 1998
Annex D (informative): General structure of ATS.33
History.34

Page 6
ETS 300 196-6: April 1998
Blank page
Page 7
ETS 300 196-6: April 1998
Foreword
This European Telecommunication Standard (ETS) has been produced by the Signalling Protocols and
Switching (SPS) Technical Committee of the European Telecommunications Standards Institute (ETSI).
This ETS is part 6 of a multi-part standard covering the Digital Subscriber Signalling System No. one
(DSS1) protocol specification for the Integrated Services Digital Network (ISDN) generic functional
protocol for the support of supplementary services, as described below:
Part 1: "Protocol specification";
Part 2: "Protocol Implementation Conformance Statement (PICS) proforma specification";
Part 3: "Test Suite Structure and Test Purposes (TSS&TP) specification for the user";
Part 4: "Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing
(PIXIT) proforma specification for the user";
Part 5: "TSS&TP specification for the network";
Part 6: "ATS and partial PIXIT proforma specification for the network".
Transposition dates
Date of adoption of this ETS: 20 March 1998
Date of latest announcement of this ETS (doa): 31 July 1998
Date of latest publication of new National Standard
or endorsement of this ETS (dop/e): 31 January 1999
Date of withdrawal of any conflicting National Standard (dow): 31 January 1999

Page 8
ETS 300 196-6: April 1998
Blank page
Page 9
ETS 300 196-6: April 1998
1 Scope
This sixth part of ETS 300 196 specifies the Abstract Test Suite (ATS) and partial Protocol Implementation
eXtra Information for Testing (PIXIT) proforma for the Network side of the T reference point or coincident
S and T reference point (as defined in ITU-T Recommendation I.411 [10]) of implementations conforming
to the stage three standard for the generic functional protocol for the support of supplementary services
for the pan-European Integrated Services Digital Network (ISDN) by means of the Digital Subscriber
Signalling System No. one (DSS1) protocol, ETS 300 196-1 [2].
ETS 300 196-5 [4] specifies the Test Suite Structure and Test Purposes (TSS&TP) related to this ATS
and partial PIXIT proforma. Other parts specify the TSS&TP and the ATS and partial PIXIT proforma for
the User side of the T reference point or coincident S and T reference point of implementations
conforming to ETS 300 196-1 [2].
2 Normative references
This ETS incorporates by dated and 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 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 102-1: "Integrated Services Digital Network (ISDN); User-network
interface layer 3; Specifications for basic call control".
[2] ETS 300 196-1: "Integrated Services Digital Network (ISDN); Generic functional
protocol for the support of supplementary services; Digital Subscriber Signalling
System No. one (DSS1) protocol; Part 1: Protocol specification".
[3] ETS 300 196-2 (1996): "Integrated Services Digital Network (ISDN); Generic
functional protocol for the support of supplementary services; Digital Subscriber
Signalling System No. one (DSS1) protocol; Part 2: Protocol Implementation
Conformance Statement (PICS) proforma specification".
[4] ETS 300 196-5: "Integrated Services Digital Network (ISDN); Generic functional
protocol for the support of supplementary services; Digital Subscriber Signalling
System No. one (DSS1) protocol; Part 5: Test Suite Structure and Test
Purposes (TSS&TP) specification for the network".
[5] ISO/IEC 9646-1: "Information technology - OSI Conformance Testing
Methodology and Framework; Part 1: General Concepts".
[6] ISO/IEC 9646-2: "Information technology - OSI Conformance Testing
Methodology and Framework; Part 2: Abstract Test Suite Specification".
[7] ISO/IEC 9646-3: "Information technology - OSI Conformance Testing
Methodology and Framework; Part 3: The Tree and Tabular Combined
Notation".
[8] ISO/IEC 9646-4: "Information technology - OSI Conformance Testing
Methodology and Framework; Part 4: Test realization".
[9] ISO/IEC 9646-5: "Information technology - OSI Conformance Testing
Methodology and Framework; Part 5: Requirements on test laboratories and
clients for the conformance assessment process".
[10] ITU-T Recommendation I.411 (1993): "ISDN user-network interfaces -
Reference configurations".
[11] CCITT Recommendation X.209 (1988): "Specification of Basic Encoding Rules
for Abstract Syntax Notation One (ASN.1)".

Page 10
ETS 300 196-6: April 1998
3 Definitions and abbreviations
3.1 Definitions
For the purposes of this ETS, the following definitions apply:
Abstract Test Suite (ATS): See ISO/IEC 9646-1 [5].
Implementation Under Test (IUT): See ISO/IEC 9646-1 [5].
Lower Tester (LT): See ISO/IEC 9646-1 [5].
Point Of Control And Observation (PCO): See ISO/IEC 9646-1 [5].
Protocol Implementation Conformance Statement (PICS): See ISO/IEC 9646-1 [5].
PICS proforma: See ISO/IEC 9646-1 [5].
Protocol Implementation Extra Information For Testing (PIXIT): See ISO/IEC 9646-1 [5].
PIXIT proforma: See ISO/IEC 9646-1 [5].
System Under Test (SUT): See ISO/IEC 9646-1 [5].
Upper Tester (UT): See ISO/IEC 9646-1 [5].
3.2 Abbreviations
For the purposes of this ETS, the following abbreviations apply:
ASP Abstract Service Primitive
ATM Abstract Test Method
ATS Abstract Test Suite
BER Basic Encoding Rules
CM Co-ordination Message
CP Co-ordination Point
ExTS Executable Test Suite
IUT Implementation Under Test
LT Lower Tester
MOT Means Of Testing
MTC Main Test Component
PCO Point of Control and Observation
PCTR Protocol Conformance Test Report
PDU Protocol Data Unit
PICS Protocol Implementation Conformance Statement
PIXIT Protocol Implementation eXtra Information for Testing
PTC Parallel Test Component
SUT System Under Test
TCP Test Co-ordination Procedures
TP Test Purpose
TTCN Tree and Tabular Combined Notation
UT Upper Tester
Page 11
ETS 300 196-6: April 1998
4 Abstract Test Method (ATM)
4.1 Description of ATM used
The requirement for testing the network IUT is to focus on the behaviour of the network IUT at the user-
network interface where a T reference point or coincident S and T reference point applies. Thus the IUT is
the network DSS1 protocol entity at a particular user-network interface and is not the whole network.
It is possible to specify an ATS based on a Single party (remote) test method for such an IUT. However, it
is considered that an ATS based on such an approach is of limited use as the only way to specify IUT
generated PDUs is to use the "implicit send" statement. Many users of such an ATS would replace the
"implicit send" statements with descriptions of the behaviour at other interfaces.
An ATS based on a multi-party test method is considered to be more useful in that it is closer to how a
real test suite would be constructed. Such a test method specifies behaviour at multiple network
interfaces. One very important limitation here is that tests are focused on one particular interface. Thus
the test system is made up one Main Test Component (MTC) and one or more Parallel Test Components
(PTC), see figure 1.
4.1.1 Conventions for test components and PCOs
Master part Slave part
MTCA
PTC1
CPA1
L0 PCO L1 PCO
IUT
NETWORK
Figure 1: Multi-party test method
In a master/slave arrangement, the MTC is considered to be the master while the PTCs are the slaves.
The "slave" testers are only an explicit description of how to deal with the "other" interfaces during the
testing process, i.e. "how to make the IUT send the required message".

Page 12
ETS 300 196-6: April 1998
This means, in particular, that the verdict will only be assigned from the protocol aspects observed on the
interface under test (i.e. by the "master" tester), as it would be observed by a terminal connected to this
interface. A failure in the correlation between the protocol at the different interfaces to which the different
testers are connected, i.e. in the mechanism of the functional service itself, will not cause a FAIL verdict.
For instance, if the IUT fails to send a message on the tested interface after another interface has
received the proper stimulus, the verdict will be INCONCLUSIVE.
The MTC MTCA has two functions in this configuration. Firstly, it has the MTC function of controlling the
one or more PTCs. Thus it is responsible for starting the PTCs and afterwards co-ordinates activities by
exchanging Co-ordination Messages (CM) with the PTCs. Secondly it is responsible for the behaviour of
the Lower Tester (LT) at PCO L0.
A combination of the remote and multi-party test methods is applied. As can be seen from figure 1,
several PCOs are used. All PCOs reside at the service access points between layers 2 and 3.
MTC SUT PTC1
Layer 3 IUT Layer 3
 L0      L1 
Layer 2 Layer 2
 
        
Layer 1 Layer 1
Service provider
Figure 2: Combination of the remote and multi-party test methods
The MTC PCO is named "L0" ("L" for Lower). PCO L0 is used to control and observe the behaviour of the
IUT and test case verdicts are assigned depending on the behaviour observed at this PCO. The PTC
PTC1 uses PCO L1. This PCO is used to control and, in a limited way, observe the behaviour of the
network equipment at interfaces other than the one under test. No verdicts are assigned at this PCO.
As stated in a previous paragraph, the non-receipt of network generated messages at L0, which are
stimulated by events at the L1, will result in INCONCLUSIVE rather than FAIL verdicts being assigned.
4.1.2 Conventions for variables and parameters
MTCA
call reference CREF1
B channel (basic) bch_num1 (to PTC1)
channel nr (primary) CH_NUM1
PCO L0 IPN0, LIPN0
PTC1
call reference P1CREF
B channel (basic) P1_bch_num
channel nr (primary) P1_CH_NUM
PCO L1 IPN1, LIPN1
Page 13
ETS 300 196-6: April 1998
4.2 Alternative ATM
As stated in subclause 4.1, an ATS based on a single-party (remote) ATM is possible. Such an ATS may
be generated from the one specified in this ETS. The following general steps should be taken:
1) remove all PTC behaviour;
2) remove all CREATE statements;
3) replace CMs which are used to provoke PDUs at the MTC, with implicit send statements.
An example, showing the difference between the multi-party ATM and single-party ATM for a single test
case, is given in tables 1 and 2.
Table 1: Test case dynamic behaviour table using multi-party ATM
TEST CASE DYNAMIC BEHAVIOUR
Test Case Name HOLD_N04_001
Group RemoteUser_ST_OR_T/Holding/
Purpose Ensure that the IUT, while in the Active call state N10, to notify
the non-served user that the call is held
sends a NOTIFY message with a notification indicator coded as
"remote hold" to user B and remains in the Active call state.
Default DF69901(1)
Configuration CONFIG1
Comments 9.2.1 valid optional
Nr | Label| BEHAVIOUR DESCRIPTION | CREF | V | COMMENTS
1 | |CREATE ( PTC1: PTC1_IN_servedUser) | | |
2 | | +PR31002 | | |preamble N10
3 | | CPA1!CP_M START TWAIT |S_HL | |
4 | |  L0?NOTIFYr |A_NO20(CREF1,hold_NID) |(P)|
5 | |  +CS59901(10,1) | | |check N10
6 | |  ?TIMEOUT TWAIT | |(I)|
7 | |  +PO49901(1) | | |postamble N0
DETAILED COMMENTS:
Table 2: Test case dynamic behaviour table using single-party ATM
TEST CASE DYNAMIC BEHAVIOUR
Test Case Name HOLD_N04_001
Group RemoteUser_ST_OR_T/Holding/
Purpose Ensure that the IUT, while in the Active call state N10, to notify
the non-served user that the call is held
sends a NOTIFY message with a notification indicator coded as
"remote hold" to user B and remains in the Active call state.
Default DF69901(1)
Configuration
Comments 9.2.1 valid optional
Nr | Label| BEHAVIOUR DESCRIPTION | CREF | V | COMMENTS
1 | |+PR31002 | | |preamble N10
2 | | |NO20(CREF1,hold_NID) | |
3 | | L0?NOTIFYr |A_NO20(CREF1,hold_NID) |(P)|
4 | |  +CS59901(10,1) | | |check N10
5 | | ?TIMEOUT TWAIT | |(I)|
6 | |  +PO49901(1) | | |postamble N0
DETAILED COMMENTS:
Page 14
ETS 300 196-6: April 1998
5 Untestable test purposes
Only subclause 6.2.2 of ETS 300 196-5 [4] contains testable test purposes. All other test purposes are too
generic and parameterized. These test purposes rather provide a general example for the behaviour that
should be tested in the ATSs for supplementary services which use the generic functional protocol.
Some of the tests contained in subclause 6.2.2 of ETS 300 196-5 [4] are also untestable due to the fact
that the call state in which the test should be performed is unstable. These are:
GFP_N7_01_002, GFP_N7_02_002, GFP_N7_03_002, GFP_N7_04_002, GFP_N7_05_002,
GFP_N7_06_004, GFP_N7_06_010, GFP_N7_06_016, GFP_N7_07_004, GFP_N7_07_010,
GFP_N7_07_017, GFP_N7_07_018, GFP_N7_07_020, GFP_N7_07_027, GFP_N7_08_004,
GFP_N7_08_010, GFP_N7_08_016, GFP_N7_09_004, GFP_N7_09_010, GFP_N7_09_017,
GFP_N7_09_018, GFP_N7_09_019, GFP_N7_09_020, GFP_N7_09_022, GFP_N7_09_026,
GFP_N7_09_032, GFP_N7_09_038, GFP_N7_10_004. GFP_N7_10_004. GFP_N7_10_004.
6 ATS conventions
This clause is structured similarly to the structure of a TTCN ATS. However, the names of the subclauses
are arranged in a way more suitable to this ETS.
6.1 Declarations part
6.1.1 Type definitions
6.1.1.1 Simple type definitions
Where appropriate, simple types have a length, a value list or a range restriction attached.
Simple types defined as being of some string type (e.g. BIT STRING, OCTET STRING), have a length
restriction or a value list attached.
Simple types, defined as being of INTEGER type, have a value list or a range restriction attached.
6.1.1.2 Structured type definitions
6.1.1.2.1 TTCN structured type definitions
All structured type definitions are provided with a full name.
All elements in every structured type definition, defined as being of some string type (e.g. BIT STRING,
OCTET STRING), have a length restriction attached.
If an element in a structured type definition is defined as being of a referenced type, the (possible)
restriction is defined in that referenced type.
For information elements the identifier, which is unique for each element, has its type defined as a simple
type where the value list is restricted to the single value which is the identifier itself. This has the
advantage that it allows a test system derived from this ATS to easily identify information elements
embedded in messages. An ATS where information element identifiers are represented as unrestricted
types can present difficulties for a derived test system in the case where it needs to find one information
element embedded in a number of others and the constraints for the other elements have the any-or-omit
value. In such a case the test system cannot easily find the beginning of each information element.
6.1.1.2.2 ASN.1 structured type definitions
ASN.1 has been used for two major reasons. First, types defined in ASN.1 can model problems that
"pure" TTCN cannot. For instance, data structures modelling ordered or unordered sequences of data are
preferably defined in ASN.1. Second, ASN.1 provides a better restriction mechanism for type definitions
by using sub-type definitions.

Page 15
ETS 300 196-6: April 1998
The fact that ASN.1 provides a better restriction mechanism for type definitions is used for the purpose of
achieving type-compatibility.
In table 3 the ASN.1 type BIT7OR15 is defined as being of type BIT STRING with a size constraint
attached to it. The size is determined by the value of CR_LENGTH, a test suite parameter. It can have the
value of either 7 or 15. The type BIT7OR15 is used in the structured type CR, field cr_r allowing this type
to represent a Basic Access or a Primary Rate Access call reference. By using this type definition the field
cr_r is always type compatible with values of type BIT STRING (SIZE(7)) and BIT STRING (SIZE(15)).
Another approach to solve this problem would be to define the type BIT7OR15 as
BIT STRING (SIZE(7 | 15)). This type has a small disadvantage compared with the previous one. It is
impossible, in run-time, to determine the actual length of any instance of this type.
Table 3: ASN.1 type definition BIT7OR15
ASN.1 Type Definition
Type Name : BIT7OR15
Comments :
Type Definition
BIT STRING(SIZE(CR_LENGTH))
Table 4 shows a typical use of ASN.1. The CHI element will have two different type definitions depending
on whether it represents Basic or Primary-rate access. In TTCN, this shall be defined as two different
types. In ASN.1 this can be done in one, the type being a choice of either BASIC_CHI or PRIMARY_CHI.
These two types are then (locally) defined in the same table.
Table 4: ASN.1 type definition CHI
ASN.1 Type Definition
Type Name : CHI
Comments : Info Element Channel Identification
ETS 300 102-1 clause 4.5.13
Type Definition
CHOICE {
basic  BASIC_CHI,
primary PRIMARY_CHI
}
-- Local Type Definitions --
BASIC_CHI ::= SEQUENCE {
chi_i    CHI_I,          -- Identifier
chi_l    BIT STRING(SIZE(8)),   -- Length
chi_e3_cs  BIT STRING(SIZE(8))    -- Channel selection
}
PRIMARY_CHI ::= SEQUENCE {
chi_i    CHI_I,          -- Identifier
chi_l    BIT STRING(SIZE(8)),   -- Length
chi_e3_p1  BIT STRING(SIZE(4)),   -- First nibble of Channel selection
chi_e3_pe  BIT STRING(SIZE(1)),   -- Preferred/Exclusive Bit
chi_e3_p3  BIT STRING(SIZE(3)),   -- Last three bits of Channel selection
chi_e4   BIT STRING(SIZE(8)),   -- Channel type
chi_e5_chl BIT STRING(SIZE(1)),
chi_e5_ch2 BIT STRING(SIZE(7))    -- Channel number
}
The possibility to use TTCN and ASN.1 in combination is used, i.e. referring to an ASN.1 type from a
TTCN type.
Page 16
ETS 300 196-6: April 1998
6.1.1.3 ASP type definitions
6.1.1.3.1 TTCN ASP type definitions
TTCN ASP type definitions only contain one PDU or no PDU at all. The relationship between an ASP type
and a PDU type is one-to-one. That is, there exists one ASP type definition for each PDU type definition (if
that ASP type contains a PDU).
All TTCN ASP type definitions are provided with a full identifier.
Some ASPs are not parameterized as shown in the example in table 5. Such ASPs are only used for
requesting or receiving service from the lower layer.
Table 5: TTCN ASP type definition DL_REL_IN
TTCN ASP Type Definition
ASP NAME : DL_REL_IN
(DL_RELEASE_INDICATION)
PCO Type : SAP
Comments :
Parameter Name           |   Parameter Type    |    Comments
Detailed Comments :
Table 6 shows an example of a parameterized ASP. All ASPs containing PDUs contain only that PDU and
no other parameters.
Table 6: TTCN ASP type definition DL_DATA_RQ_ALERT
TTCN ASP Type Definition
ASP NAME : DL_DATA_RQ_ALERT
(DL_DATA_REQUEST)
PCO Type : SAP
Comments :
Parameter Name           |   Parameter Type    |    Comments
mun (MessageUnit)         |ALERT_PDU         |
Detailed Comments :
6.1.1.3.2 ASN.1 ASP type definitions
There are no ASN.1 ASP type definitions in the ATS.
6.1.1.4 PDU type definitions
6.1.1.4.1 TTCN PDU type definitions
The TTCN PDU type reflects the actual data being transferred or received. All PDUs are embedded in
ASPs.
If a specific PDU type definition contains elements defined in terms of a pre-defined type, that element has
a restriction attached to it.
6.1.1.4.2 ASN.1 PDU type definitions
There are no ASN.1 PDU type definitions in the ATS.
6.1.2 Test suite constants
No test suite constants are used or defined in this ATS.

Page 17
ETS 300 196-6: April 1998
6.1.3 Test suite parameters
Each test suite parameter is defined in terms of a predefined type or a referenced type. A referenced type
is used when it is necessary to attach restrictions to these type definitions (it is not allowed to include
restrictions directly in the test suite parameter table). The referenced type can have a length or value
restriction attached to it in its declaration table.
6.1.4 Variables
6.1.4.1 Test suite variables
No test suite variables are used or defined in this ATS.
6.1.4.2 Test case variables
Each test case variable is defined in terms of a predefined type or a referenced type. A referenced type is
used when it is necessary to attach restrictions to these type definitions (it is not allowed to include
restrictions directly in the test case variable table). The referenced type can have a length or value
restriction attached to it in its declaration table.
Where test case variables are used in constraints, they are passed as formal parameters.
6.1.5 Test suite operation definitions
The description part of a test suite operation definition uses either natural language or meta C.
Table 7: Test suite operation definition ASSIGN_CHI
Test Suite Operation Definition
Operation Name : ASSIGN_CHI(basic, primary : CHI; basic_flag : BOOLEAN)
Result Type  : CHI
Comments    : This operation is used to assign a correct Channel identification information
element to PDUs dependent on the type of access that is tested.
Description
{
if(basic_flag)
return basic;
else
return primary
}
Detailed comments :
The test suite operation definition shown in table 7 is used in the constraints part when assigning an
element of type CHI a value. As previously described, the CHI type can be defined in two ways depending
on whether the ATS is testing basic or primary rate access. To avoid duplicate types and thereby duplicate
test cases the CHI type is defined in ASN.1. This operation is used to assign a value to an element of CHI
type. It takes three parameters:
SULPDU\DFRQVWUDLQWRIW\SH&+,YDOLGIRUSULPDU\UDWHDFFHVV
EDVLFDFRQVWUDLQWRIW\SH&+,YDOLGIRUEDVLFDFFHVV
EDVLFBIODJD%RROHDQYDOXH758(LIEDVLFDFFHVVLVDSSOLFDEOH)$/6(RWKHUZLVH
This operation returns the correct constraint according to the Boolean flag basic_flag. That constraint will
then be assigned to the specific element of type CHI.

Page 18
ETS 300 196-6: April 1998
6.2 Constraints part
6.2.1 Structured type constraint declaration
For every structured type definition there exists one or more structured type constraint.
6.2.2 ASN.1 type constraint declaration
Constraints of this type are used to assign the corresponding type a specific value. These constraints are
used for the purpose of modelling unordered data or specific types that cannot be expressed in TTCN.
6.2.2.1 Specification of encoding rules
All ASN.1 constraints contained in this ATS are encoded according to ISDN, i.e. the ASN.1 data types are
a representation of structures contained within the ISDN specification (basic call, Generic functional
protocol or individual supplementary service). For example, if octets of an information element are
specified in ASN.1 as a SEQUENCE then this should be encoded in an Executable Test Suite (ExTS) as
any other ISDN information element specified using tabular TTCN. Encoding associated with the Basic
Encoding Rules (BER), as specified in CCITT Recommendation X.209 [11], should not be applied to any
of the ASN.1 constraints specified in this ATS.
6.2.3 ASP type constraint declaration
6.2.3.1 ASN.1 ASP type constraint declaration
No ASN.1 ASP type constraint declaration exists in this ATS.
6.2.3.2 TTCN ASP type constraint declaration
For TTCN ASP constraint declarations there is a one-to-one relationship between its type and the
constraint. That is, there is only one constraint for each TTCN ASP Type Declaration. The reason for this
is that the ASPs are used only for carrying a specific PDU value. The many ASP constraints (and types)
could have been avoided by using the meta type PDU, but that was not suitable as values inside a specific
PDU have to be referenced. To reference elements inside a value of meta type PDU is not allowed
according to ISO/IEC 9646-3 [7], so each ASP has to be defined as having a parameter of a specific PDU
type.
In all ASP constraints the embedded PDU constraint is either chained static or "semi-dynamic". That is,
the PDU constraint is always fixed to a specific ASP constraint but it (the PDU) may be parameterized.
All ASP constraints have a specific value for its parameter. No matching symbols are used in ASPs.
6.2.4 PDU type constraint declaration
6.2.4.1 ASN.1 PDU type constraint declaration
No ASN.1 PDU type constraint declaration exists in this ATS.
6.2.4.2 TTCN PDU type constraint declaration
PDU constraints are used for assigning values or patterns to the data being sent or received.

Page 19
ETS 300 196-6: April 1998
6.2.5 Chaining of constraints
6.2.5.1 Static chaining
Static chaining, that is a fixed reference to a specific constraint, is used in this ATS. The static chaining is
used for static binding of both variables and sub-structures.
6.2.5.2 Dynamic chaining
Dynamic chaining is achieved when having a reference to a value which is unknown. The only thing
known (before run-time) is the type of that reference. The reference is passed as a parameter. Strict
dynamic chaining is not used in this ATS. What is used is something that is called "semi-dynamic
chaining". The definition of semi-dynamic chaining is that the fixed reference is parameterized with an
unknown value. That value is received as a parameter.
Table 8: TTCN ASP constraint declaration A_RST1
TTCN ASP Constraint Declaration
Constraint Name : A_RST1(FLAG : INTEGER)
ASN.1 Type   : DL_DAT_IN_RESTARTr
Derivation Path :
Comments    :
Parameter Name Parameter Value Comments
mun RST1(FLAG) RST1(FLAG)
Detailed comments :
Table 8 is an example of semi-dynamic chaining. The TTCN ASP constraint is parameterized with an
INTEGER value named FLAG. That value is passed further down in the structure as a parameter to a
static named PDU constraint reference.
6.2.6 Derived constraints
No derivation of any constraints is used. All constraints are considered to be base constraints.
6.2.7 Parameterized constraints
Parameterized constraints are used in this ATS.
6.2.8 Value assignment
6.2.8.1 Specific values
For specific value assignment both explicit values and references to explicit values are used.
6.2.8.2 Matching values
As matching values the following mechanisms are used:
Instead of Value:
AnyOrOmit "*"
AnyValue "?"
SuperSet SUPERSET
Omit "-"
Inside value:
AnyOne "?"
AnyOrNone "*"
Page 20
ETS 300 196-6: April 1998
6.3 Dynamic part
6.3.1 Test cases
Each test case contains the test purpose text from ETS 300 196-5 [4]. To be able to read and understand
the test case dynamic behaviour it is recommended that the test steps are understood first.
6.3.2 Test steps
6.3.2.1 PTC1_IN
This test step describes the behaviour of the PTC1 for support of an incoming call at the MTC (served
user side). Thus PTC1 is the originator of the call. The PTC1 receives a CM from the MTC in order to
send the SETUP message which begins the call establishment. The test step is terminated by receipt of a
RELEASE message or by appropriate CM from the MTC.
6.3.2.2 PTC1_OUT
This test step describes the behaviour of the PTC1 for support of an outgoing call at the MTC (served
user side). Thus PTC1 is at the destination side of the call. The test step is terminated by receipt of a
RELEASE message or by appropriate CM from the MTC.
The behaviour is regulated from the MTC by means of CMs sent via CPA1 co-ordination point. Thus if the
PTC is expected to receive a message it receives a CM beforehand telling it what message to expect. On
the other hand if the MTC wishes to receive a message from the IUT it may do this by first sending a CM
to PTC1. Depending on the contents of the CM PTC1 may then send a message to the IUT eventually
provoking the IUT to send a message at the side of the MTC.
6.3.3 Defaults
Note the use of the RETURN statement which is defined in DAM1 of ISO/IEC 9646-3 [7]. This allows valid
background behaviour to be handled in the default tree with a possibility to return to the original set of
alternatives in the test case.
7 ATS to TP map
The identifiers used for the TPs are reused as test case names. Thus there is a straightforward one-to-
one mapping.
8 PCTR conformance
A test laboratory, when requested by a client to produce a PCTR, is required, as specified in
ISO/IEC 9646-5 [9], to produce a PCTR conformant with the PCTR template given in annex B of
ISO/IEC 9646-5 [9].
Furthermore, a test laboratory, offering testing for the ATS specification contained in annex C, when
requested by a client to produce a PCTR, is required to produce a PCTR conformant with the PCTR
proforma contained in annex A of this ETS.
A PCTR which conforms to this PCTR proforma specification shall preserve the content and ordering of
the clauses contained in annex A. Clause A.6 of the PCTR may contain additional columns. If included,
these shall be placed to the right of the existing columns. Text in italics may be retained by the test
laboratory.
Page 21
ETS 300 196-6: April 1998
9 PIXIT conformance
A test realizer, producing an executable test suite for the ATS specification contained in annex C, is
required, as specified in ISO/IEC 9646-4 [8], to produce an augmented partial PIXIT proforma conformant
with this partial PIXIT proforma specification.
An augmented partial PIXIT proforma which conforms to this partial PIXIT proforma specification shall, as
a minimum, have contents which are technically equivalent to annex B. The augmented partial PIXIT
proforma may contain additional questions that need to be answered in order to prepare the Means Of
Testing (MOT) for a particular IUT.
A test laboratory, offering testing for the ATS specification contained in annex C, is required, as specified
in ISO/IEC
...