SIST EN 300 359-6 V1.3.6:2005

• Abstract:

  To handle comments and incorporate appropriate corrections into the ATS of DSS1 L2

• Status: Published
• Publication Date: 31-Mar-2005
• ICS: 33.080 - Integrated Services Digital Network (ISDN)
• Technical Committee: SPN - Services and Protocols for Networks
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Apr-2005
• Due Date: 01-Apr-2005
• Completion Date: 01-Apr-2005
• Ref Project: ETSI EN 300 359-6 V1.3.6 (2000-06) - Integrated Services Digital Network (ISDN); Completion of Calls to Busy Subscriber (CCBS) supplementary service; 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

SIST EN 300 359-6 V1.3.6:2005 is the Slovenian standard published by SIST and identical to ETSI EN 300 359-6 V1.3.6. It specifies the Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing (PIXIT) proforma for the network side of the Completion of Calls to Busy Subscriber (CCBS) supplementary service over the Digital Subscriber Signalling System No. one (DSS1) protocol in Integrated Services Digital Network (ISDN). Test laboratories and implementers use it to assess network implementations at the T reference point or coincident S and T reference point against EN 300 359-1.

What does SIST EN 300 359-6 V1.3.6:2005 specify?

SIST EN 300 359-6 V1.3.6:2005 specifies the network-side conformance test material for CCBS on DSS1. It covers the ATS and the partial PIXIT proforma needed to test implementations that conform to the CCBS protocol specification.

The standard is organized into 10 clauses and 5 annexes. Clause 4 explains the Abstract Test Method (ATM), clause 5 lists untestable test purposes, clause 6 gives ATS conventions, clause 7 maps ATS items to test purposes, and clauses 8 to 10 state conformance rules for PCTR, PIXIT and ATS use.

Annex	What it covers
Annex A	Protocol Conformance Test Report (PCTR) proforma
Annex B	Partial PIXIT proforma
Annex C	Abstract Test Suite (ATS)
Annex D	General structure of the ATS
Annex E	Change record

What are the key requirements of SIST EN 300 359-6 V1.3.6:2005?

Test method and verdict handling

SIST EN 300 359-6 V1.3.6:2005 uses a combination of remote and multi-party testing in clause 4. The Main Test Component (MTC) controls one or more Parallel Test Components (PTCs), and verdicts are assigned from the interface under test at the L0 Point of Control and Observation (PCO).

That matters because the test suite does not judge the whole network as one block. If a stimulus on another interface fails to provoke a message on the interface under test, the result can be INCONCLUSIVE rather than FAIL.

Clause 4.1.3 also adapts the method for the Network B group. In that case PTC1 is used to observe network B while the MTC remains on the served user side. This allows reuse of test steps, but it also means the served user side must still behave conformantly.

Clause 4.2 describes how a single-party ATS can be derived from the multi-party version by removing PTC behavior, removing CREATE statements and replacing coordination messages with implicit send statements. In practice, that tells a test realizer how to turn the abstract test design into a simpler execution model if needed.

Untestable test purposes and test case structure

Clause 5 identifies test purposes that are untestable in this ATS. For a test campaign, that means some CCBS behaviors are listed for traceability but are not expected to produce executable verdicts in the ATS as written.

Clause 6.3 states that each test case contains the test purpose text from EN 300 359-5. The test cases are therefore traceable back to the network TSS&TP document, which helps reviewers understand why each test exists.

Data types, constraints and matching

Clause 6.1 defines how the ATS is written. Simple types can have length, value or range restrictions, and structured types are given full names. ASN.1 is used where ordered or unordered data structures, better subtype restriction, or remote operation components are needed.

That matters in practice because the ATS depends on precise message typing. A derived test system must be able to identify information elements inside messages and keep their types compatible with the protocol data being tested.

Clause 6.2 defines the constraints. Send constraints and receive constraints are handled differently, especially for SET OF data, where receive matching uses SUPERSET so that a received structure may contain additional components as long as it includes the required ones.

The same clause also uses static chaining and semi-dynamic chaining. In practical terms, some values are fixed by reference while others are passed in as parameters, which lets the same ATS cover more than one access configuration or channel selection case.

Encoding rules and test execution details

Clause 6.2.2.1 sets the encoding approach for ASN.1. The default for this ATS is ISDN-style encoding, and BER is used only where a table comment explicitly says so. For Component types, BER encoding is used, and the test campaign should include different BER length forms.

That is important for interoperability testing because the IUT must cope with the encoding form expected by the ATS, not just with abstract values. A tester must also choose appropriate length forms during execution.

Clause 6.3.2 describes the PTC1_IN and PTC1_OUT test steps. These steps define how the PTC behaves for incoming and outgoing call support, and coordination messages from the MTC control what the PTC sends.

Clause 7 gives a one-to-one ATS to TP map by reusing the TP identifiers as test case names. That makes it straightforward to trace each executable test back to the corresponding test purpose.

Clauses 8, 9 and 10 define the conformance expectations for the PCTR, PIXIT and ATS. They tie the document to the ISO/IEC 9646 conformance-testing framework and define how labs and test realizer developers are expected to use the annexes.

What terms does SIST EN 300 359-6 V1.3.6:2005 define?

• Abstract Test Suite (ATS) - The set of abstract test cases, test steps and declarations used to specify how conformance is tested.
• Implementation Under Test (IUT) - The network implementation being checked against the CCBS protocol specification.
• Point of Control and Observation (PCO) - The interface where test stimuli are sent and protocol behavior is observed.
• Main Test Component (MTC) - The test component that controls the test execution and assigns verdicts.
• Parallel Test Component (PTC) - A supporting test component used to stimulate or observe other interfaces during a multi-party test.
• Protocol Conformance Test Report (PCTR) - The report form used to record the outcome of a conformance test campaign.
• Protocol Implementation eXtra Information for Testing (PIXIT) - The implementation-specific test information needed to prepare and run the ATS.

Who uses SIST EN 300 359-6 V1.3.6:2005?

SIST EN 300 359-6 V1.3.6:2005 is used by test laboratories, test realizer developers, and network equipment vendors working on ISDN CCBS over DSS1. Quality teams and conformance engineers use it to prepare the Means Of Testing (MOT), run ATS-based campaigns, complete the PCTR, and collect the implementation details needed in the PIXIT.

It is also relevant to buyers or technical evaluators who need evidence that a network-side CCBS implementation can be tested against a recognized ETSI conformance suite.

What changed in SIST EN 300 359-6 V1.3.6:2005 from the previous edition?

SIST EN 300 359-6 V1.3.6:2005 replaces EN 300 359-6 V1.2 and the previous ETS 300 359-6. The change record states that the ATS was corrected, the document was converted to EN layout, references to ETS 300 102 were replaced by EN 300 403-1, and non-specific references to basic standards were updated to point to the latest version.

Which standards are used with SIST EN 300 359-6 V1.3.6:2005?

• ETSI EN 300 359-1 - The protocol specification for CCBS on DSS1 that this ATS tests against.
• ETSI EN 300 359-2 - The PICS proforma that supplies the implementation profile used during conformance assessment.
• ETSI EN 300 359-5 - The network-side TSS&TP specification that supplies the test purposes reused in the ATS.
• ETSI EN 300 403-1 - The DSS1 signalling network layer protocol specification for circuit-mode basic call control used as a base reference.
• ETSI EN 300 196-1 - The generic functional protocol for supplementary services, used for shared protocol structures and components.
• ISO/IEC 9646-1 to ISO/IEC 9646-5 - The conformance-testing framework covering concepts, ATS specification, TTCN, test realization, and test-laboratory requirements.
• ITU-T Recommendation I.411 - The ISDN reference configuration used to define the T reference point and related network interfaces.
• CCITT Recommendation X.209 - The Basic Encoding Rules reference used for BER encoding of ASN.1 where specified.

What does the SIST EN 300 359-6 V1.3.6:2005 document contain?

The ATS in annex C is presented in both TTCN Graphical form (TTCN.GR) and TTCN Machine Processable form (TTCN.MP). The main body also contains the ATM description, conventions for test components, variables, parameters, constraints, defaults, and the test case dynamic behavior.

Annex A gives the PCTR proforma with identification, conformance summaries, static and dynamic review sections, a test campaign report and observations. Annex B gives the partial PIXIT proforma with questions on IUT configuration, timers, parameter values and basic call information element codings.

Annex D provides a guide to the general structure of a typical supplementary service ATS, which helps readers find declarations, constraints and dynamic parts quickly. Annex E records the change history, which is useful when comparing editions or checking why a correction was made.

SLOVENSKI STANDARD
01-april-2005
'LJLWDOQRRPUHåMH]LQWHJULUDQLPLVWRULWYDPL,6'1±'RSROQLOQDVWRULWHY
GRNRQþDQMHNOLFDQMD]DVHGHQHJDQDURþQLND&&%6±3URWRNROGLJLWDOQHQDURþQLãNH
VLJQDOL]DFLMHãW'66±GHO$EVWUDNWQLSUHVNXãDOQLQL]$76LQGRGDWQD
LQIRUPDFLMD]DSUHVNXãDQMHGHOQHL]YHGEHSURWRNROD3,;,7±3URIRUPD
VSHFLILNDFLMD]DRPUHåMH
Integrated Services Digital Network (ISDN); Completion of Calls to Busy Subscriber
(CCBS) supplementary service; 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: EN 300 359-6 Version 1.3.6
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 Standard (Telecommunications series)
Integrated Services Digital Network (ISDN);
Completion of Calls to Busy Subscriber (CCBS)
supplementary service;
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
�
2 ETSI EN 300 359-6 V1.3.6 (2000-06)
Reference
REN/SPS-05169-6
Keywords
ISDN, DSS1, supplementary service, CCBS,
ATS, PIXIT, network
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.:[phone] Fax:[phone]
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network
drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at http://www.etsi.org/tb/status/
If you find errors in the present document, send your comment to:
[e-mail]
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 2000.
All rights reserved.
ETSI
3 ETSI EN 300 359-6 V1.3.6 (2000-06)
Contents
Intellectual Property Rights.6
Foreword .6
1 Scope.7
2 References.7
3 Definitions and abbreviations .8
3.1 Definitions.8
3.2 Abbreviations .8
4 Abstract Test Method (ATM) .9
4.1 Description of ATM used.9
4.1.1 Conventions for test components and PCOs .9
4.1.2 Conventions for variables and parameters .11
4.1.3 Conventions for the Network B group .12
4.2 Alternative ATM .12
5 Untestable test purposes.13
6 ATS conventions.13
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.15
6.1.1.3.1 TTCN ASP type definitions.15
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 .16
6.1.4 Variables.16
6.1.4.1 Test suite variables.16
6.1.4.2 Test case variables .16
6.1.5 Test suite operation definitions.17
6.2 Constraints part.17
6.2.1 Structured type constraint declaration.17
6.2.2 ASN.1 type constraint declaration .17
6.2.2.1 Specification of encoding rules .18
6.2.3 ASP type constraint declaration.19
6.2.3.1 ASN.1 ASP type constraint declaration .19
6.2.3.2 TTCN ASP type constraint declaration.19
6.2.4 PDU type constraint declaration .19
6.2.4.1 ASN.1 PDU type constraint declaration.19
6.2.4.2 TTCN PDU type constraint declaration .19
6.2.5 Chaining of constraints .19
6.2.5.1 Static chaining.19
6.2.5.2 Dynamic chaining.20
6.2.6 Derived constraints .20
6.2.7 Parameterized constraints .20
6.2.8 Value assignment.20
6.2.8.1 Specific values .20
6.2.8.2 Matching values .20
6.3 Dynamic part .20
ETSI
4 ETSI EN 300 359-6 V1.3.6 (2000-06)
6.3.1 Test cases.20
6.3.2 Test steps .21
6.3.2.1 PTC1_IN.21
6.3.2.2 PTC1_OUT.21
6.3.3 Defaults.21
7 ATS to TP map.21
8 PCTR conformance.21
9 PIXIT conformance.21
10 ATS conformance .22
Annex A (normative): Protocol Conformance Test Report (PCTR) proforma.23
A.1 Identification summary .23
A.1.1 Protocol conformance test report.23
A.1.2 IUT identification.23
A.1.3 Testing environment.23
A.1.4 Limits and reservations.24
A.1.5 Comments.24
A.2 IUT conformance status .24
A.3 Static conformance summary.24
A.4 Dynamic conformance summary.24
A.5 Static conformance review report .25
A.6 Test campaign report.26
A.7 Observations.28
Annex B (normative): Partial PIXIT proforma.29
B.1 Identification summary .29
B.2 Abstract test suite summary .29
B.3 Test laboratory .29
B.4 Client (of the test laboratory).30
B.5 System Under Test (SUT).30
B.6 Protocol information .31
B.6.1 Protocol identification .31
B.6.2 IUT information .31
B.6.2.1 Parameter values.31
B.6.2.2 Configuration of IUT .32
B.6.2.3 Timer values .33
B.7 Basic call PIXIT items .33
B.7.1 Parameter values - information element codings.33
ETSI
5 ETSI EN 300 359-6 V1.3.6 (2000-06)
Annex C (normative): Abstract Test Suite (ATS).34
C.1 The TTCN Graphical form (TTCN.GR).34
C.2 The TTCN Machine Processable form (TTCN.MP) .34
Annex D (informative): General structure of ATS.35
Annex E (informative): Change record.36
E.1 Changes with respect to EN 300 359-6 V1.2.36
E.2 Changes with respect to the previous ETS 300 359-6 .36
History.37
ETSI
6 ETSI EN 300 359-6 V1.3.6 (2000-06)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://www.etsi.org/ipr).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This European Standard (Telecommunications series) has been produced by ETSI Technical Committee Services and
Protocols for Advanced Networks (SPAN).The present document is part 6 of a multi-part EN covering the Integrated
Services Digital Network (ISDN); Completion of Calls to Busy Subscriber (CCBS) supplementary service; Digital
Subscriber Signalling System No. one (DSS1) protocol, 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: "Test Suite Structure and Test Purposes (TSS&TP) specification for the network";
Part 6: "Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing
(PIXIT) proforma specification for the network".
National transposition dates
Date of adoption of this EN: 19 May 2000
Date of latest announcement of this EN (doa): 31 August 2000
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 28 February 2001
Date of withdrawal of any conflicting National Standard (dow): 28 February 2001
ETSI
7 ETSI EN 300 359-6 V1.3.6 (2000-06)
1 Scope
The present document 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 [11]) of implementations conforming to the stage three standard for the
Completion of Calls to Busy Subscriber (CCBS) supplementary service for the pan-European Integrated Services Digital
Network (ISDN) by means of the Digital Subscriber Signalling System No. one (DSS1) protocol, EN 300 359-1 [2].
EN 300 359-5 [4] specifies the Test Suite Structure and Test Purposes (TSS&TP) related to this ATS and partial PIXIT
proforma specification. 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 EN 300 359-1 [2].
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies.
• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same
number.
[1] ETSI EN 300 403-1: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling
System No. one (DSS1) protocol; Signalling network layer for circuit-mode basic call control;
Part 1: Protocol specification [ITU-T Recommendation Q.931 (1993), modified]".
[2] ETSI EN 300 359-1 (V1.2): "Integrated Services Digital Network (ISDN); Completion of Calls to
Busy Subscriber (CCBS) supplementary service; Digital Subscriber Signalling System No. one
(DSS1) protocol; Part 1: Protocol specification".
[3] ETSI EN 300 359-2 (V1.2): "Integrated Services Digital Network (ISDN); Completion of Calls to
Busy Subscriber (CCBS) supplementary service; Digital Subscriber Signalling System No. one
(DSS1) protocol; Part 2: Protocol Implementation Conformance Statement (PICS) proforma
specification".
[4] ETSI EN 300 359-5 (V1.2): "Integrated Services Digital Network (ISDN); Completion of Calls to
Busy Subscriber (CCBS) supplementary service; Digital Subscriber Signalling System No. one
(DSS1) protocol; Part 5: Test Suite Structure and Test Purposes (TSS&TP) specification for the
network".
[5] ETSI EN 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".
[6] ISO/IEC 9646-1 (1994): "Information technology; Open Systems Interconnection; Conformance
testing methodology and framework; Part 1: General concepts".
[7] ISO/IEC 9646-2 (1994): "Information technology; Open Systems Interconnection; Conformance
testing methodology and framework; Part 2: Abstract Test Suite specification".
[8] ISO/IEC 9646-3 (1998): "Information technology; Open Systems Interconnection; Conformance
testing methodology and framework; Part 3: The Tree and Tabular Combined Notation (TTCN)".
[9] ISO/IEC 9646-4 (1994): "Information technology; Open Systems Interconnection; Conformance
testing methodology and framework; Part 4: Test realization".
ETSI
8 ETSI EN 300 359-6 V1.3.6 (2000-06)
[10] ISO/IEC 9646-5 (1994): "Information technology; Open Systems Interconnection; Conformance
testing methodology and framework; Part 5: Requirements on test laboratories and clients for the
conformance assessment process".
[11] ITU-T Recommendation I.411 (1993): "ISDN user-network interfaces - Reference configuration".
[12] CCITT Recommendation X.209 (1988): "Specification of Basic Encoding Rules for Abstract
Syntax Notation One (ASN.1)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply.
Abstract Test Suite (ATS): see ISO/IEC 9646-1 [6]
Implementation Under Test (IUT): see ISO/IEC 9646-1 [6]
Lower Tester (LT): see ISO/IEC 9646-1 [6]
Point of Control and Observation (PCO): see ISO/IEC 9646-1 [6]
Protocol Conformance Test Report (PCTR): see ISO/IEC 9646-1 [6]
Protocol Implementation Conformance Statement (PICS): see ISO/IEC 9646-1 [6]
PICS proforma: see ISO/IEC 9646-1 [6]
Protocol Implementation eXtra Information for Testing (PIXIT): see ISO/IEC 9646-1 [6]
PIXIT proforma: see ISO/IEC 9646-1 [6]
System Under Test (SUT): see ISO/IEC 9646-1 [6]
UpperTester(UT): see ISO/IEC 9646-1 [6]
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ASP Abstract Service Primitive
ATM Abstract Test Method
ATS Abstract Test Suite
BER Basic Encoding Rules
CCBS Completion of Calls to Busy Subscriber
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
ETSI
9 ETSI EN 300 359-6 V1.3.6 (2000-06)
TP Test Purpose
TSS Test Suite Structure
TTCN Tree and Tabular Combined Notation
UT Upper Tester
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
ETSI
10 ETSI EN 300 359-6 V1.3.6 (2000-06)
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".
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,2
Layer 3 IUT Layer 3
 L0    L1,2 
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). The L0 PCO 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 PTCs PTC1, PTC2 etc. use
PCOs L1, L2 etc. These PCOs are 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 these PCOs.
As stated in a previous paragraph, the non-receipt of network generated messages at L0, which are stimulated by events
at the L1, L2 etc., will result in INCONCLUSIVE rather than FAIL verdicts being assigned.
ETSI
11 ETSI EN 300 359-6 V1.3.6 (2000-06)
4.1.2 Conventions for variables and parameters
MTCA
call reference CREF1
B channel (basic) bch_num1 (to PTC1)
channel nr (primary) CH_NUM1
call reference CREF2
B channel (basic) bch_num2 (to PTC2)
channel nr (primary) CH_NUM2
PCO L0 IPN0, LIPN0
PTC1
call reference P1CREF
B channel (basic) P1_bch_num
channel nr (primary) P1_CH_NUM
PCO L1 IPN1, LIPN1
ETSI
12 ETSI EN 300 359-6 V1.3.6 (2000-06)
4.1.3 Conventions for the Network B group
For this group, the side of the network which is being tested is network B. The most convenient approach here is to
connect PTC1 to the IUT. The MTC is, as for the served user group test cases, connected at the served user side of the
network. This approach allows the reuse of test steps developed for the served user group tests. This approach,
representing a slight modification in the test method, is illustrated in figure 3. This shows as an example that the part of
the network considered to be the IUT is connected to PTC1 rather that MTC1.
Master part Slave part
MTCA
PTC1
CPA1
L0 PCO L1 PCO
IUT
NETWORK
Figure 3: Multi-party test method - modified for remote user tests
The PTC1 is used to observe the behaviour at network B. Some test steps (for example PTC1_N08_001) are used to
control the behaviour at network B and depending on the result sends a CM back to the MTC. The MTC then issues a
verdict depending on the CM received from the PTC1. This is done in order to maintain the convention that the MTC is
only allowed to issue verdicts. However, one consequence of this is that any behaviour at the served user side which is
non-conforming will result in a Fail verdict being issued even though the focus of the tests is at the remote user side.
This constraint is viewed as acceptable given the fact that in any case the Network shall provide a conforming served
user interface as well as one or more conforming remote user interfaces.
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 the present document. 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.
ETSI
13 ETSI EN 300 359-6 V1.3.6 (2000-06)
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| | | | |
2 | | +PR31002 | | |preamble N10
3 | | |NO20(CREF1,hold_NID) | |
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:
5 Untestable test purposes
The untestable test cases associated with this ATS and ATM are: CCBS_N07_002, CCBS_N8_004, CCBS_N08_008,
CCBS_N09_004, CCBS_N09_008, CCBS_N13_004, CCBS_N13_005 and CCBS_N13_008.
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 the present document.
ETSI
14 ETSI EN 300 359-6 V1.3.6 (2000-06)
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 three 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. Third, it is
necessary to use ASN.1 to reproduce the type definitions for remote operation components as specified in the base
standards.
The fact that ASN.1 provides a better restriction mechanism for type definitions is used for the purpose of achieving
type-compatibility.
ETSI
15 ETSI EN 300 359-6 V1.3.6 (2000-06)
Tables 3 and 4 show the typical use of ASN.1. The FIE type in table 3 is written in ASN.1 to permit the use of the SET
OF construction in the components field. Constraints of the FIE type can therefore be written using the SUPERSET
function which allows to match a single component which may be delivered together with a set of other components.
Table 4 shows the reject component type which is defined following the ASN.1 declaration in EN 300 196-1 [5].
Table 3: ASN.1 type definition FIE
ASN.1 Type Definition
Type Name : FIE
Comments : Facility information element taken from EN 300 196; 11.2.2.1.
Specified here for both send & receive event.
Type Definition
SEQUENCE {
informationElementIdentifier FIE_I,
length FIE_LengthType,
extBit BIT STRING (SIZE (1)),
spareBits BIT STRING (SIZE (2)),
protocolProfile BIT STRING (SIZE (5)),
components SET OF Component }
Table 4: ASN.1 type definition RejectComponent
ASN.1 Type Definition
Type Name : RejectComponent
Comments : Reject Component is not specific to any particular operation. The invokeID may be
used to identify a specific operation.
Type Definition
SEQUENCE {
invokedID CHOICE {
invokeID InvokeIDType,
null NULL },
problem CHOICE {
generalProblem [0] IMPLICIT GeneralProblem,
invokeProblem [1] IMPLICIT InvokeProblem,
returnResultProblem [2] IMPLICIT ReturnResultProblem,
returnErrorProblem [3] IMPLICIT ReturnErrorProblem } }
Table 5 shows an example of how ASN.1 can be used to model unordered sequences.
Table 5: ASN.1 type definition FIES
ASN.1 Type Definition
Type Name : FIES
Comments :
Type Definition
SET OF FIE
The possibility to use TTCN and ASN.1 in combination is used, i.e. referring to an ASN.1 type from a TTCN type.
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 6. Such ASPs are only used for requesting or
receiving service from the lower layer.
ETSI
16 ETSI EN 300 359-6 V1.3.6 (2000-06)
Table 6: 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 7 shows an example of a parameterized ASP. All ASPs containing PDUs contain only that PDU and no other
parameters.
Table 7: 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.
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.
ETSI
17 ETSI EN 300 359-6 V1.3.6 (2000-06)
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 8: 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 8 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. This operation is used to assign a value to an element of CHI type. It takes three
parameters:
primary: a constraint of type CHI valid for primary rate access;
basic: a constraint of type CHI valid for basic access;
basic_flag: a Boolean value: TRUE if basic access is applicable, FALSE otherwise.
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.
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.
A value assigned to an element of type SET OF differs depending on whether it is a send or receive constraint.
Table 9: ASN.1 type constraint declaration fIEs (send constraint)
ASN.1 Type Constraint Declaration
Constraint Name : fIEs(comp : Component)
ASN.1 Type : FIE
Derivation Path :
Comments : Send FIE which will contain one component "comp".
Description
{
informationElementIdentifier '00011100'B,
length CALC_FIE_LENGTH(comp),
extBit '1'B,
spareBits '00'B,
protocolProfile '10001'B,
components {comp}
}
Detailed comments :
ETSI
18 ETSI EN 300 359-6 V1.3.6 (2000-06)
NOTE 1: The last element in the constraint, components,isoftype SET OF Component where Component is
structured data of some type.
If the constraint is a send constraint (as in table 9) the value for the component element is stated as "{comp}" where
comp is an argument received as a parameter. The "{" and "}" turns the value into a SET OF value which is correct
according to that element's type definition.
Table 10: ASN.1 type constraint declaration fIEr (receive constraint)
ASN.1 Type Constraint Declaration
Constraint Name : fIEr(comp : Component)
ASN.1 Type : FIE
Derivation Path :
Comments : A received FIE which can contain several components, but which contains at
least "comp".
Descripti
...