ETSI EN 300 286-6 V1.4.1 (2003-01)

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.VWRULWHYIntegrated Services Digital Network (ISDN); User-to-User Signalling (UUS) 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 network33.080Digitalno omrežje z integriranimi storitvami (ISDN)Integrated Services Digital Network (ISDN)ICS:Ta slovenski standard je istoveten z:EN 300 286-6 Version 1.4.1SIST EN 300 286-6 V1.4.1:2005en01-januar-2005SIST EN 300 286-6 V1.4.1:2005SLOVENSKI
STANDARD
ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 2
Reference REN/SPAN-130308-2 Keywords ATS, DSS1, ISDN, network, PIXIT, supplementary service, UUS ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00
Fax: +33 4 93 65 47 16
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://portal.etsi.org/tb/status/status.asp If you find errors in the present document, send your comment to: editor@etsi.org 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 2003. All rights reserved.
DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTM and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. SIST EN 300 286-6 V1.4.1:2005

ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 3
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 Special conventions for the UUS supplementary service.12 4.1.4 Conventions for point-to-multipoint configurations.12 4.2 Alternative ATM.13 5 Untestable Test Purposes (TPs).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.15 6.1.1.2.1 TTCN structured type definitions.15 6.1.1.2.2 ASN.1 structured type definitions.15 6.1.1.3 Abstract Service Primitive (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.17 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.17 6.2.1 Structured type constraint declaration.17 6.2.2 ASN.1 type constraint declaration.18 6.2.2.1 Specification of encoding rules.19 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.20 6.2.4.1 ASN.1 PDU type constraint declaration.20 6.2.4.2 TTCN PDU type constraint declaration.20 6.2.5 Chaining of constraints.20 6.2.5.1 Static chaining.20 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.21 6.3 Dynamic part.21 SIST EN 300 286-6 V1.4.1:2005

ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 4
6.3.1 Test cases.21 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.22 9 PIXIT conformance.22 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.25 A.7 Observations.29 Annex B (normative): Partial PIXIT proforma.30 B.1 Identification summary.30 B.2 ATS summary.30 B.3 Test laboratory.30 B.4 Client (of the test laboratory).31 B.5 System Under Test (SUT).31 B.6 Protocol information.32 B.6.1 Protocol identification.32 B.6.2 Parameter values.32 B.6.3 Codings of information elements.32 B.6.4 Configuration of IUT.33 B.6.5 Timer values.33 B.7 Basic call PIXIT items.34 B.7.1 Parameter values - information element codings.34 Annex C (normative): Abstract Test Suite (ATS).35 C.1 The TTCN Graphical form (TTCN.GR).35 C.2 The TTCN Machine Processable form (TTCN.MP).35 Annex D (informative): General structure of ATS.36 Annex E (informative): Change record.37 E.1 Changes between EN 300 286-6 V1.2.4 and V1.3.3.37 E.2 Changes between ETS 300 286-6 Edition 1 and EN 300 286-6 V1.2.4.37 SIST EN 300 286-6 V1.4.1:2005

ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 5
E.3 Changes between EN 300 286-6 V1.4.1 and V1.3.3.37 E.4 Changes between EN 300 286-6 V1.2.4 and V1.3.3.38 History.39
ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 6
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://webapp.etsi.org/IPR/home.asp). All published ETSI deliverables shall include information which directs the reader to the above source of information. 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 standard covering the Integrated Services Digital Network (ISDN); User-to-User Signalling (UUS) 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: 27 December 2002 Date of latest announcement of this EN (doa): 31 March 2003 Date of latest publication of new National Standard or endorsement of this EN (dop/e):
30 September 2003 Date of withdrawal of any conflicting National Standard (dow): 30 September 2003
ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 7
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 User-to-User Signalling (UUS) 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 286-1 [3]. EN 300 286-5 [5] 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 286-1 [3]. 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 and/or edition number or version number) or non-specific. • For a specific reference, subsequent revisions do not apply. • For a non-specific reference, the latest version applies. Referenced documents which are not found to be publicly available in the expected location might be found at http://docbox.etsi.org/Reference. [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 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] ETSI EN 300 286-1: "Integrated Services Digital Network (ISDN); User-to-User Signalling (UUS) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol;
Part 1: Protocol specification". [4] ETSI EN 300 286-2: "Integrated Services Digital Network (ISDN); User-to-User Signalling (UUS) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol;
Part 2: Protocol Implementation Conformance Statement (PICS) proforma specification". [5] ETSI EN 300 286-5 (V1.2.4): "Integrated Services Digital Network (ISDN); User-to-User Signalling (UUS) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 5: Test Suite Structure and Test Purposes (TSS&TP) specification for the network". [6] ISO/IEC 9646-1: "Information technology - Open System Interconnection - Conformance testing methodology and framework - Part 1: General concepts". [7] ISO/IEC 9646-2: "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 2: Abstract Test Suite specification". [8] ISO/IEC 9646-3: "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 3: The Tree and Tabular Combined Notation (TTCN)". [9] ISO/IEC 9646-4: "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 4: Test realization". SIST EN 300 286-6 V1.4.1:2005

ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 8
[10] ISO/IEC 9646-5: "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: "ISDN user-network interfaces - Reference configurations". [12] ITU-T Recommendation X.209: "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].
PICS proforma: See ISO/IEC 9646-1 [6]. PIXIT proforma: See ISO/IEC 9646-1 [6]. Point of Control and Observation (PCO): See ISO/IEC 9646-1 [6]. Protocol Implementation Conformance Statement (PICS): See ISO/IEC 9646-1 [6]. Protocol Implementation Extra Information for Testing (PIXIT): See ISO/IEC 9646-1 [6]. System Under Test (SUT): See ISO/IEC 9646-1 [6]. Upper Tester (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 CM Co-ordination Message CP Co-ordination Point DSS1 Digital Subscriber Signalling System No. one ExTS Executable Test Suite ISDN Integrated Services Digital Network IUT Implementation Under Test LT Lower Tester MOT Means Of Testing MTC Main Test Component PCO Point of Control and Observation PDU Protocol Data Unit PICS Protocol Implementation Conformance Statement PIXIT Protocol Implementation eXtra Information for Testing PTC Parallel Test Component SUT System Under Test TP Test Purpose TTCN Tree and Tabular Combined Notation UT Upper Tester SIST EN 300 286-6 V1.4.1:2005

ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 9
UUS User-to-User Signalling 4 Abstract Test Method (ATM) 4.1 Description of ATM used The requirement for testing the network Implementation Under Test (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 Abstract Test Suite (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 Protocol Data Units (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 (PTCs), see figure 1. 4.1.1 Conventions for test components and PCOs
Master part
Slave part
MTCA
PTC2
CPA2
PTC1
CPA1
L0 PCO
L1 PCO L2 PCO
IUT
NETWORK
Figure 1: Multi-party test method SIST EN 300 286-6 V1.4.1:2005

ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 10 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 (CMs) with the PTCs. Secondly it is responsible for the behaviour of the Lower Tester (LT) at Point of Control and Observation (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  Layer 2  Layer 1
L0


IUT 








L1,2

Layer 3  Layer 2  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 clause, 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. SIST EN 300 286-6 V1.4.1:2005

ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 11 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
PTC2
call reference P2CREF
B channel (basic) P2_bch_num
channel nr (primary) P2_CH_NUM
PCO L2 IPN2, LIPN2
ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 12 4.1.3 Special conventions for the UUS supplementary service To begin a conference from the Null Call State, a remote user is not required. The CREF1 will be used without the PTC1. To add a party to the conference, a remote user with CREF2 using PTC2 is called. Some remote user test cases use 2 parties. To do that the first party is added by using the CREF2 with PTC1. After the party has been added to the conference, CREF2 will be released. Then it is possible to add the second party by using CREF2 with PTC2. 4.1.4 Conventions for point-to-multipoint configurations For this group, PTC2 is connected to the same basic access as the MTC. Thus messages sent to the MTC via the broadcast data link will be received at PTC2 via PCO L2 as well. Both the MTC and PTC2 will send messages on the same access using the same call reference value. A distinction between the two message flows related to the PCOs L0 and L2 can still be made, as they use different data link entities. This approach, representing a slight modification in the test method, is illustrated in figure 3. This shows that the part of the network considered to be the IUT is connected to both the MTC and PTC2. SIST EN 300 286-6 V1.4.1:2005

ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 13
Master part
Slave part
MTCA
PTC1
CPA1
CPA2
PTC2
L0 PCO
L2 PCO
CES1
CES2
L1 PCO IUT Basic access point-to-multipoint
NETWORK
Figure 3: Multi-party test method - modified for point-to-multipoint configurations 4.2 Alternative ATM As stated in clause 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. 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. SIST EN 300 286-6 V1.4.1:2005

ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 14 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 UUSIG1 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:
5 Untestable Test Purposes (TPs) None. 6 ATS conventions This clause is structured similarly to the structure of a Tree and Tabular Combined Notation (TTCN) ATS. However, the names of the clauses are arranged in a way more suitable to the present document. 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. SIST EN 300 286-6 V1.4.1:2005

ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 15 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. 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 [2]. Table 3: ASN.1 type definition FIE ASN.1 Type Definition Type Name : FIE Comments
: Facility information element taken from EN 300 196-1; 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
[2] IMPLICIT GeneralProblem,
invokeProblem
[1] IMPLICIT InvokeProblem,
returnResultProblem [2] IMPLICIT ReturnResultProblem,
returnErrorProblem
[3] IMPLICIT ReturnErrorProblem } }
ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 16 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 Abstract Service Primitive (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. 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. SIST EN 300 286-6 V1.4.1:2005

ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 17 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. 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. SIST EN 300 286-6 V1.4.1:2005

ETSI ETSI EN 300 286-6 V1.4.1 (2003-01) 18 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 :
NOTE 1: The last element in the constraint, components, is of type 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". Description {
informationElementIdentifier
'00011100'B,
length
'????????'B,
extBit
'1'B,
spareBits
'00'B,
protocolProfile
'10001'B,
components
SUPERSET({comp}) } Detailed comments :
NOTE 2: The last element in the constraint, named components, is of type SET OF Component where Component is structured data of some type. If the constraint is a receive constraint (as in table 10) the corresponding matching value is assigned by using SUPERSET. The key-word SUPERSET has an argument that is type compatible with the type definition of that field. In table 10, the element named components is defined as "SET OF Component" and this implies that the argument to SUPERSET should be of type SET OF Component. This is achieved the same way as for send constraints, enclosing the value in curly brackets. The semantic of SUPERSET is stated in ISO/IEC 9646-3 [8], clause 11.6.4.7. In short it defines the semantic as follows: "A value that uses SUPERSET matches the incoming value if, and only if, the incoming value contains at least all of the elements defined within the SUPERSET, and may contain more elements." This is exactly the se
...