ETSI ETS 300 195-6 ed.1 (1998-09)

Integrated Services Digital Network (ISDN); Supplementary service interactions; 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

DE/SPS-05061-Z-6

Digitalno omrežje z integriranimi storitvami (ISDN) - Medsebojno vplivanje dopolnilne storitve - Protokol digitalne naročniške signalizacije št. 1 (DSS1) - 6. del: Abstraktni preskušalni niz (ATS) in delna dodatna informacija za preskušanje izvedbe protokola (PIXIT) - Proforma specifikacije za omrežje

General Information

• Status: Published
• Publication Date: 04-Oct-1998
• Technical Committee: SPS 5 3 - Conformance Testing
• Current Stage: 12 - Completion
• Due Date: 02-Oct-1998
• Completion Date: 05-Oct-1998
• Mandate: BC-T-340
• Ref Project: SIST ETS 300 195-6:1999 - Integrated Services Digital Network (ISDN); Supplementary service interactions; 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

Standards Content (Sample)

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.YSOLYDQMHIntegrated Services Digital Network (ISDN); Supplementary service interactions; 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:ETS 300 195-6 E13SIST ETS 300 195-6:199en01-QRYHPEHU-1993SIST ETS 300 195-6:199SLOVENSKI
STANDARD
EUROPEANETS 300 195-6TELECOMMUNICATIONSeptember 1998STANDARDSource: SPSReference: DE/SPS-05061-Z-6ICS:33.020Key words:ISDN, DSS1, supplementary service, interaction, testing, ATS, PIXIT, networkIntegrated Services Digital Network (ISDN);Supplementary service interactions;Digital Subscriber Signalling System No. one (DSS1) protocol;Part 6: Abstract Test Suite (ATS) and partial ProtocolImplementation eXtra Information for Testing (PIXIT) proformaspecification for the networkETSIEuropean Telecommunications Standards InstituteETSI SecretariatPostal address: F-06921 Sophia Antipolis CEDEX - FRANCEOffice address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCEInternet: [e-mail] - http://www.etsi.fr - http://www.etsi.orgTel.: [phone] - Fax: [phone]Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and theforegoing restriction extend to reproduction in all media.© European Telecommunications Standards Institute 1998. All rights reserved.SIST ETS 300 195-6:1999

Page 2ETS 300 195-6: September 1998Whilst 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 Standards Making Support Dept." at the address shown on the title page.SIST ETS 300 195-6:1999

Page 3ETS 300 195-6: September 1998ContentsForeword.71Scope.92Normative references.93Definitions and abbreviations.103.1Definitions.103.2Abbreviations.104Abstract Test Method (ATM).115Untestable test purposes.116ATS conventions.116.1Declarations part.116.1.1Type definitions.116.1.1.1Simple type definitions.116.1.1.2Structured type definitions.126.1.1.2.1TTCN structured type definitions.126.1.1.2.2ASN.1 structured type definitions.126.1.1.3ASP type definitions.146.1.1.3.1TTCN ASP type definitions.146.1.1.3.2ASN.1 ASP type definitions.156.1.1.4PDU type definitions.156.1.1.4.1TTCN PDU type definitions.156.1.1.4.2ASN.1 PDU type definitions.156.1.2Test suite constants.156.1.3Test suite parameters.156.1.4Variables.166.1.4.1Test suite variables.166.1.4.2Test case variables.166.1.5Test suite operation definitions.166.2Constraints part.176.2.1Structured type constraint declaration.176.2.2ASN.1 type constraint declaration.176.2.2.1Specification of encoding rules.186.2.3ASP type constraint declaration.206.2.3.1ASN.1 ASP type constraint declaration.206.2.3.2TTCN ASP type constraint declaration.206.2.4PDU type constraint declaration.206.2.4.1ASN.1 PDU type constraint declaration.206.2.4.2TTCN PDU type constraint declaration.206.2.5Chaining of constraints.206.2.5.1Static chaining.206.2.5.2Dynamic chaining.216.2.6Derived constraints.216.2.7Parameterized constraints.216.2.8Value assignment.216.2.8.1Specific values.216.2.8.2Matching values.216.3Dynamic part.226.3.1Test cases.226.3.2Test steps.22SIST ETS 300 195-6:1999

Page 4ETS 300 195-6: September 19986.3.3Defaults.227ATS to TP map.228PCTR conformance.229PIXIT conformance.2210ATS conformance.23Annex A (normative):Protocol Conformance Test Report (PCTR) proforma.24A.1Identification summary.24A.1.1Protocol conformance test report.24A.1.2IUT identification.24A.1.3Testing environment.24A.1.4Limits and reservations.25A.1.5Comments.25A.2IUT conformance status.25A.3Static conformance summary.25A.4Dynamic conformance summary.25A.5Static conformance review report.26A.6Test campaign report.26A.7Observations.30Annex B (normative):Partial PIXIT proforma.31B.1Identification summary.31B.2Abstract test suite summary.31B.3Test laboratory.31B.4Client (of the test laboratory).32B.5System Under Test (SUT).32B.6Protocol information.33B.6.1Protocol identification.33B.6.2Parameter values.33B.6.3Codings of information elements.34B.6.4Called party number and Calling party number values.35B.6.5Actions required to configure the IUT.35B.6.6Options supported by the IUT.36B.6.7Timer values.36B.7Basic call PIXIT items.37B.7.1Parameter values - information element codings.37Annex C (normative):Abstract Test Suite (ATS).38C.1The TTCN Graphical form (TTCN.GR).38C.2The TTCN Machine Processable form (TTCN.MP).38SIST ETS 300 195-6:1999

Page 5ETS 300 195-6: September 1998Annex D (informative):General structure of ATS.39History.40SIST ETS 300 195-6:1999

Page 6ETS 300 195-6: September 1998Blank pageSIST ETS 300 195-6:1999

Page 7ETS 300 195-6: September 1998ForewordThis European Telecommunication Standard (ETS) has been produced by the Signalling Protocols andSwitching (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) supplementary serviceinteractions, 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 forTesting (PIXIT) proforma specification for the network".Transposition datesDate of adoption of this ETS:18 September 1998Date of latest announcement of this ETS (doa):31 December 1998Date of latest publication of new National Standardor endorsement of this ETS (dop/e):30 June 1999Date of withdrawal of any conflicting National Standard (dow):30 June 1999SIST ETS 300 195-6:1999

Page 8ETS 300 195-6: September 1998Blank pageSIST ETS 300 195-6:1999

Page 9ETS 300 195-6: September 19981ScopeThis sixth part of ETS 300 195 specifies the Abstract Test Suite (ATS) and partial Protocol ImplementationeXtra Information for Testing (PIXIT) proforma for the Network side of the T reference point or coincidentS and T reference point (as defined in ITU-T Recommendation I.411 [11]) of implementations conformingto the stage three standard for the supplementary service interactions for the pan-European IntegratedServices Digital Network (ISDN) by means of the Digital Subscriber Signalling System No. one (DSS1)protocol, ETS 300 195-1 [2].ETS 300 195-5 [4] specifies the Test Suite Structure and Test Purposes (TSS&TP) related to this ATSand partial PIXIT proforma specification. Other parts specify the TSS&TP and the ATS and partial PIXITproforma for the User side of the T reference point or coincident S and T reference point ofimplementations conforming to ETS 300 195-1 [2].2Normative referencesThis ETS incorporates by dated and undated reference, provisions from other publications. Thesenormative references are cited at the appropriate places in the text and the publications are listedhereafter. For dated references, subsequent amendments to or revisions of any of these publications applyto this ETS only when incorporated in it by amendment or revision. For undated references the latestedition of the publication referred to applies.[1]ETS 300 102-1: "Integrated Services Digital Network (ISDN); User-networkinterface layer 3; Specifications for basic call control".[2]ETS 300 195-1 (1995): "Integrated Services Digital Network (ISDN);Supplementary service interactions; Digital Subscriber Signalling System No. one(DSS1) protocol; Part 1: Protocol specification".[3]ETS 300 195-2 (1996): "Integrated Services Digital Network (ISDN);Supplementary service interactions; Digital Subscriber Signalling System No. one(DSS1) protocol; Part 2: Protocol Implementation Conformance Statement(PICS) proforma specification".[4]ETS 300 195-5: "Integrated Services Digital Network (ISDN); Supplementaryservice interactions; Digital Subscriber Signalling System No. one (DSS1)protocol; Part 5: Test Suite Structure and Test Purposes (TSS&TP) specificationfor the network".[5]ETS 300 196-1: "Integrated Services Digital Network (ISDN); Generic functionalprotocol for the support of supplementary services; Digital Subscriber SignallingSystem No. one (DSS1) protocol; Part 1: Protocol specification".[6]ISO/IEC 9646-1: "Information technology - Open Systems 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 Suitespecification".[8]ISO/IEC 9646-3: "Information technology - Open Systems Interconnection -Conformance testing methodology and framework - Part 3: The Tree andTabular Combined Notation (TTCN)".[9]ISO/IEC 9646-4: "Information technology - Open Systems Interconnection -Conformance testing methodology and framework - Part 4: Test realization".[10]ISO/IEC 9646-5: "Information technology - Open Systems Interconnection -Conformance testing methodology and framework - Part 5: Requirements ontest laboratories and clients for the conformance assessment process".SIST ETS 300 195-6:1999

Page 10ETS 300 195-6: September 1998[11]ITU-T Recommendation I.411 (1993): "ISDN user-network interfaces -references configurations".[12]CCITT Recommendation X.209 (1988): "Specification of basic encoding rules forAbstract Syntax Notation One (ASN.1)".3Definitions and abbreviations3.1DefinitionsFor the purposes of this ETS, the following 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 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].Upper Tester (UT): See ISO/IEC 9646-1 [6].3.2AbbreviationsFor the purposes of this ETS, the following abbreviations apply:ASPAbstract Service PrimitiveATMAbstract Test MethodATSAbstract Test SuiteBERBasic Encoding RulesExTSExecutable Test SuiteFIEFacility Information ElementIUTImplementation Under TestLTLower TesterMOTMeans Of TestingPCOPoint of Control and ObservationPCTRProtocol Conformance Test ReportPDUProtocol Data UnitPICSProtocol Implementation Conformance StatementPIXITProtocol Implementation eXtra Information for TestingSUTSystem Under TestTCPTest Co-ordination ProceduresTPTest PurposeTTCNTree and Tabular Combined NotationUTUpper TesterSIST ETS 300 195-6:1999

Page 11ETS 300 195-6: September 19984Abstract Test Method (ATM)The remote test method is applied for the supplementary service interactions network ATS. The Point ofControl and Observation (PCO) resides at the service access point between layers 2 and 3. This PCO isnamed "L" (for Lower). The L PCO is used to control and observe the behaviour of the ImplementationUnder Test (IUT) and test case verdicts are assigned depending on the behaviour observed at this PCO.TesterSUTLTIUTPCOLayer 2Layer 2Layer 1Layer 1Service providerFigure 1: Remote test methodISO/IEC 9646-2 [7] allows the informal expression of Test Co-ordination Procedures (TCP) between theSystem Under Test (SUT) upper layer(s) and the Lower Tester (LT). In the ATS contained in annex C,TCP is achieved by use of a second "informal" PCO, called "O" (for Operator). This PCO is used tospecify control but not observation above the IUT and consequently, events at this PCO are never used togenerate test case verdicts. The use of this O PCO is regarded as a preferred alternative to the use of theimplicit send event, in that it allows the ATS to specify in a clear and meaningful way what actions arerequired to be performed on the IUT.5Untestable test purposesThere are no untestable test purposes associated with this ATS.6ATS conventionsThis clause is structured similarly to the structure of a TTCN ATS. However, the names of the subclausesare arranged in a way more suitable to this ETS.6.1Declarations part6.1.1Type definitions6.1.1.1Simple type definitionsWhere 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 lengthrestriction or a value list attached.Simple types, defined as being of INTEGER type, have a value list or a range restriction attached.SIST ETS 300 195-6:1999

Page 12ETS 300 195-6: September 19986.1.1.2Structured type definitions6.1.1.2.1TTCN structured type definitionsAll 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 simpletype where the value list is restricted to the single value which is the identifier itself. This has the advantagethat it allows a test system derived from this ATS to easily identify information elements embedded inmessages. An ATS where information element identifiers are represented as unrestricted types canpresent difficulties for a derived test system in the case where it needs to find one information elementembedded in a number of others and the constraints for the other elements have the any-or-omit value. Insuch a case the test system cannot easily find the beginning of each information element.6.1.1.2.2ASN.1 structured type definitionsASN.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 arepreferably defined in ASN.1. Second, ASN.1 provides a better restriction mechanism for type definitions byusing sub-type definitions. Third, it is necessary to use ASN.1 to reproduce the type definitions for remoteoperation 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 ofachieving type-compatibility.In table 1, the ASN.1 type BIT7OR15 is defined as being of type BIT STRING with a size constraintattached to it. The size is determined by the value of CR_LENGTH, a test suite parameter. It can have thevalue of either 7 or 15. The type BIT7OR15 is used in the structured type CR, field cr_r allowing this typeto represent a Basic Access or a Primary Rate Access call reference. By using this type definition the fieldcr_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 asBIT STRING (SIZE(7 | 15)). This type has a small disadvantage compared with the previous one. It isimpossible, in run-time, to determine the actual length of any instance of this type.Table 1: ASN.1 type definition BIT7OR15ASN.1 Type DefinitionType Name : BIT7OR15Comments
:Type DefinitionBIT STRING(SIZE(CR_LENGTH))Table 2 shows a typical use of ASN.1. The CHI element will have two different type definitions dependingon whether it represents basic or primary rate access. In TTCN, this needs to be defined as two differenttypes. 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.SIST ETS 300 195-6:1999

Page 13ETS 300 195-6: September 1998Table 2: ASN.1 type definition CHIASN.1 Type DefinitionType Name : CHIComments
: Info Element Channel Identification
ETS 300 102-1 clause 4.5.13Type DefinitionCHOICE { 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}Table 3 shows an example of how ASN.1 can be used to model unordered sequences.SIST ETS 300 195-6:1999

Page 14ETS 300 195-6: September 1998Table 3: ASN.1 type definition FIESASN.1 Type DefinitionType Name : FIESComments
:Type DefinitionSET OF FIEThe possibility to use TTCN and ASN.1 in combination is used, i.e. referring to an ASN.1 type from a TTCNtype.6.1.1.3ASP type definitions6.1.1.3.1TTCN ASP type definitionsTTCN ASP type definitions only contain one PDU or no PDU at all. The relationship between an ASP typeand a PDU type is one-to-one. That is, there exists one ASP type definition for each PDU type definition (ifthat 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 4. Such ASPs are only used forrequesting or receiving service from the lower layer.Table 4: TTCN ASP type definition DL_REL_INTTCN ASP Type DefinitionASP NAME : DL_REL_IN(DL_RELEASE_INDICATION)PCO Type : SAPComments :Parameter Name
|
Parameter Type
|
CommentsDetailed Comments :SIST ETS 300 195-6:1999

Page 15ETS 300 195-6: September 1998Table 5 shows an example of a parameterized ASP. All ASPs containing PDUs contain only that PDU andno other parameters.Table 5: TTCN ASP type definition DL_DATA_RQ_ALERTTTCN ASP Type DefinitionASP NAME : DL_DATA_RQ_ALERT(DL_DATA_REQUEST)PCO Type : SAPComments :Parameter Name
|
Parameter Type
|
Commentsmun (MessageUnit)
|ALERT_PDU
|Detailed Comments :6.1.1.3.2ASN.1 ASP type definitionsThere are no ASN.1 ASP type definitions in the ATS.6.1.1.4PDU type definitions6.1.1.4.1TTCN PDU type definitionsThe TTCN PDU type reflects the actual data being transferred or received. All PDUs are embedded inASPs.If a specific PDU type definition contains elements defined in terms of a pre-defined type, that element hasa restriction attached to it.6.1.1.4.2ASN.1 PDU type definitionsThere are no ASN.1 PDU type definitions in the ATS.6.1.2Test suite constantsNo test suite constants are used or defined in this ATS.6.1.3Test suite parametersEach test suite parameter is defined in terms of a predefined type or a referenced type. A referenced typeis used when it is necessary to attach restrictions to these type definitions (it is not allowed to includerestrictions directly in the test suite parameter table). The referenced type can have a length or valuerestriction attached to it in its declaration table.SIST ETS 300 195-6:1999

Page 16ETS 300 195-6: September 19986.1.4Variables6.1.4.1Test suite variablesNo test suite variables are used or defined in this ATS.6.1.4.2Test case variablesEach test case variable is defined in terms of a predefined type or a referenced type. A referenced type isused when it is necessary to attach restrictions to these type definitions (it is not allowed to includerestrictions directly in the test case variable table). The referenced type can have a length or valuerestriction attached to it in its declaration table.Where test case variables are used in constraints, they are passed as formal parameters.6.1.5Test suite operation definitionsThe description part of a test suite operation definition uses either natural language or meta C.Table 6: Test suite operation definition ASSIGN_CHITest Suite Operation DefinitionOperation Name : ASSIGN_CHI(basic, primary : CHI; basic_flag : BOOLEAN)Result Type
: CHIComments
: 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 6 is used in the constraints part when assigning anelement of type CHI a value. As previously described, the CHI type can be defined in two ways dependingon whether the ATS is testing basic or primary rate access. To avoid duplicate types and thereby duplicatetest cases the CHI type is defined in ASN.1. This operation is used to assign a value to an element of CHItype. It takes three parameters:This operation returns the correct constraint according to the Boolean flag basic_flag. That constraint willthen be assigned to the specific element of type CHI.SIST ETS 300 195-6:1999

Page 17ETS 300 195-6: September 19986.2Constraints part6.2.1Structured type constraint declarationFor every structured type definition there exists one or more structured type constraint.6.2.2ASN.1 type constraint declarationConstraints of this type are used to assign the corresponding type a specific value. These constraints areused 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 receiveconstraint.Table 7: ASN.1 type constraint declaration fIEs (send constraint)ASN.1 Type Constraint DeclarationConstraint Name : fIEs(comp : Component)ASN.1 Type
: FIEDerivation 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:The last element in the constraint, named components, is of type SET OF Componentwhere Component is structured data of some type.If the constraint is a send constraint (as in table 7) 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 SETOF value which is correct according to that element's type definition.SIST ETS 300 195-6:1999

Page 18ETS 300 195-6: September 1998Table 8: ASN.1 type constraint declaration fIEr (receive constraint)ASN.1 Type Constraint DeclarationConstraint Name : fIEr(comp : Component)ASN.1 Type
: FIEDerivation 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:The last element in the constraint, named components, is of type SET OF Componentwhere Component is structured data of some type.If the constraint is a receive constraint (as in table 8) the corresponding matching value is assigned byusing SUPERSET. The key-word SUPERSET has an argument that is type compatible with the typedefinition of that field. In table 8, the element named components is defined as "SET OF Component" andthis implies that the argument to SUPERSET should be of type SET OF Component. This is achieved thesame way as for send constraints, enclosing the value in curly brackets.The semantic of SUPERSET is stated in ISO/IEC 9646-3 [8], subclause 11.6.4.7. In short it defines thesemantic as follows: "A value that uses SUPERSET matches the incoming value if, and only if, theincoming value contains at least all of the elements defined within the SUPERSET, and may containmore elements." This is exactly the semantic definition used in this ATS.6.2.2.1Specification of encoding rulesAt the time of specifying this ATS the mechanisms related to encoding of ASN.1 types, specified in DAM-2of ISO/IEC 9646-3 [8], were not yet stable. Nevertheless as there is a variation in the encoding rules asapplied to ASN.1 types and constraints specified in this ATS, a mechanism is used to differentiate thedifferent encoding rules. Given the non-finalized status of DAM-2, a solution which is broadly in the spirit ofDAM-2 has been created. Comment fields have been used as a means of including the encoding rules.SIST ETS 300 195-6:1999

Page 19ETS 300 195-6: September 1998For ASN.1 used in this ATS, two variations of encoding rules are used. One is the commonly known BasicEncoding Rules (BER) as specified in CCITT Recommendation X.209 [12]. In the second case theencoding is according to ISDN, i.e. the ASN.1 data types are a representation of structures containedwithin 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 shouldbe encoded in an Executable Test Suite (ExTS) as any other ISDN information element specified usingtabular TTCN. This ISDN encoding variation is the default encoding rule for this ATS. This means that allASN.1 constraint tables are encoded using ISDN (non-BER) encoding unless stated otherwise. BERencoding should never be applied to an ASN.1 constraint where BER encoding has not been specified.For BER encoding, an indication is given in the comments field of the table header. For this ATS suchindications appear in the ASN.1 type constraint declaration tables only. In the first line of the table headercomment field, the notation "ASN1_Encoding: BER" is used.Note that within BER, there are a number of variations for the encoding of lengths of fields. According toETS 300 196-1 [5], an IUT should be able to interpret all length forms within BER for received PDUs.When sending PDUs containing BER encoding, ETS 300 196-1 [5] gives guidelines but makes norestrictions on the length forms within BER which an IUT may
...

SLOVENSKI STANDARD
01-julij-1999
'LJLWDOQRRPUHåMH]LQWHJULUDQLPLVWRULWYDPL,6'10HGVHERMQRYSOLYDQMH
GRSROQLOQHVWRULWYH3URWRNROGLJLWDOQHQDURþQLãNHVLJQDOL]DFLMHãW'66
GHO$EVWUDNWQLSUHVNXãDOQLQL]$76LQGHOQDGRGDWQDLQIRUPDFLMD]DSUHVNXãDQMH
L]YHGEHSURWRNROD3,;,73URIRUPDVSHFLILNDFLMH]DRPUHåMH
Integrated Services Digital Network (ISDN); Supplementary service interactions; 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 195-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 195-6
TELECOMMUNICATION September 1998
STANDARD
Source: SPS Reference: DE/SPS-05061-Z-6
ICS: 33.020
Key words: ISDN, DSS1, supplementary service, interaction, testing, ATS, PIXIT, network
Integrated Services Digital Network (ISDN);
Supplementary service interactions;
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: [e-mail] -
http://www.etsi.fr - http://www.etsi.org
Tel.: [phone] - Fax: [phone]
Copyright Notification:
No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1998. All rights reserved.

Page 2
ETS 300 195-6: September 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 Standards Making Support Dept." at the address shown on the title page.

Page 3
ETS 300 195-6: September 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
5 Untestable test purposes . 11
6 ATS conventions . 11
6.1 Declarations part. 11
6.1.1 Type definitions. 11
6.1.1.1 Simple type definitions . 11
6.1.1.2 Structured type definitions. 12
6.1.1.2.1 TTCN structured type definitions. 12
6.1.1.2.2 ASN.1 structured type definitions. 12
6.1.1.3 ASP type definitions. 14
6.1.1.3.1 TTCN ASP type definitions. 14
6.1.1.3.2 ASN.1 ASP type definitions. 15
6.1.1.4 PDU type definitions. 15
6.1.1.4.1 TTCN PDU type definitions. 15
6.1.1.4.2 ASN.1 PDU type definitions. 15
6.1.2 Test suite constants . 15
6.1.3 Test suite parameters. 15
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 . 16
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. 20
6.2.3.1 ASN.1 ASP type constraint declaration. 20
6.2.3.2 TTCN ASP type constraint declaration. 20
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. 21
6.2.6 Derived constraints. 21
6.2.7 Parameterized constraints. 21
6.2.8 Value assignment. 21
6.2.8.1 Specific values . 21
6.2.8.2 Matching values. 21
6.3 Dynamic part . 22
6.3.1 Test cases. 22
6.3.2 Test steps . 22

Page 4
ETS 300 195-6: September 1998
6.3.3 Defaults.22
7 ATS to TP map .22
8 PCTR conformance .22
9 PIXIT conformance.22
10 ATS conformance.23
Annex A (normative): Protocol Conformance Test Report (PCTR) proforma.24
A.1 Identification summary .24
A.1.1 Protocol conformance test report .24
A.1.2 IUT identification.24
A.1.3 Testing environment.24
A.1.4 Limits and reservations.25
A.1.5 Comments.25
A.2 IUT conformance status.25
A.3 Static conformance summary .25
A.4 Dynamic conformance summary .25
A.5 Static conformance review report .26
A.6 Test campaign report.26
A.7 Observations.30
Annex B (normative): Partial PIXIT proforma.31
B.1 Identification summary .31
B.2 Abstract test suite summary.31
B.3 Test laboratory.31
B.4 Client (of the test laboratory).32
B.5 System Under Test (SUT).32
B.6 Protocol information.33
B.6.1 Protocol identification.33
B.6.2 Parameter values.33
B.6.3 Codings of information elements.34
B.6.4 Called party number and Calling party number values.35
B.6.5 Actions required to configure the IUT .35
B.6.6 Options supported by the IUT.36
B.6.7 Timer values .36
B.7 Basic call PIXIT items.37
B.7.1 Parameter values - information element codings .37
Annex C (normative): Abstract Test Suite (ATS).38
C.1 The TTCN Graphical form (TTCN.GR) .38
C.2 The TTCN Machine Processable form (TTCN.MP).38

Page 5
ETS 300 195-6: September 1998
Annex D (informative): General structure of ATS. 39
History. 40

Page 6
ETS 300 195-6: September 1998
Blank page
Page 7
ETS 300 195-6: September 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) supplementary service
interactions, 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".
Transposition dates
Date of adoption of this ETS: 18 September 1998
Date of latest announcement of this ETS (doa): 31 December 1998
Date of latest publication of new National Standard
or endorsement of this ETS (dop/e): 30 June 1999
Date of withdrawal of any conflicting National Standard (dow): 30 June 1999

Page 8
ETS 300 195-6: September 1998
Blank page
Page 9
ETS 300 195-6: September 1998
1 Scope
This sixth part of ETS 300 195 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 supplementary service interactions for the pan-European Integrated
Services Digital Network (ISDN) by means of the Digital Subscriber Signalling System No. one (DSS1)
protocol, ETS 300 195-1 [2].
ETS 300 195-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 ETS 300 195-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 195-1 (1995): "Integrated Services Digital Network (ISDN);
Supplementary service interactions; Digital Subscriber Signalling System No. one
(DSS1) protocol; Part 1: Protocol specification".
[3] ETS 300 195-2 (1996): "Integrated Services Digital Network (ISDN);
Supplementary service interactions; Digital Subscriber Signalling System No. one
(DSS1) protocol; Part 2: Protocol Implementation Conformance Statement
(PICS) proforma specification".
[4] ETS 300 195-5: "Integrated Services Digital Network (ISDN); Supplementary
service interactions; Digital Subscriber Signalling System No. one (DSS1)
protocol; Part 5: Test Suite Structure and Test Purposes (TSS&TP) specification
for the network".
[5] 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".
[6] ISO/IEC 9646-1: "Information technology - Open Systems 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".
[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".

Page 10
ETS 300 195-6: September 1998
[11] ITU-T Recommendation I.411 (1993): "ISDN user-network interfaces -
references configurations".
[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 this ETS, the following 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 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].
Upper Tester (UT): See ISO/IEC 9646-1 [6].
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
ExTS Executable Test Suite
FIE Facility Information Element
IUT Implementation Under Test
LT Lower Tester
MOT Means Of Testing
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
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 195-6: September 1998
4 Abstract Test Method (ATM)
The remote test method is applied for the supplementary service interactions network ATS. The Point of
Control and Observation (PCO) resides at the service access point between layers 2 and 3. This PCO is
named "L" (for Lower). The L PCO is used to control and observe the behaviour of the Implementation
Under Test (IUT) and test case verdicts are assigned depending on the behaviour observed at this PCO.
Tester SUT
LT IUT
PCO
Layer 2 Layer 2
Layer 1 Layer 1
Service provider
Figure 1: Remote test method
ISO/IEC 9646-2 [7] allows the informal expression of Test Co-ordination Procedures (TCP) between the
System Under Test (SUT) upper layer(s) and the Lower Tester (LT). In the ATS contained in annex C,
TCP is achieved by use of a second "informal" PCO, called "O" (for Operator). This PCO is used to
specify control but not observation above the IUT and consequently, events at this PCO are never used to
generate test case verdicts. The use of this O PCO is regarded as a preferred alternative to the use of the
implicit send event, in that it allows the ATS to specify in a clear and meaningful way what actions are
required to be performed on the IUT.
5 Untestable test purposes
There are no untestable test purposes associated with this ATS.
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.

Page 12
ETS 300 195-6: September 1998
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.
In table 1, 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 1: ASN.1 type definition BIT7OR15
ASN.1 Type Definition
Type Name : BIT7OR15
Comments :
Type Definition
BIT STRING(SIZE(CR_LENGTH))
Table 2 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 needs to 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.

Page 13
ETS 300 195-6: September 1998
Table 2: 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
}
Table 3 shows an example of how ASN.1 can be used to model unordered sequences.

Page 14
ETS 300 195-6: September 1998
Table 3: 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 4. Such ASPs are only used for
requesting or receiving service from the lower layer.
Table 4: 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 :
Page 15
ETS 300 195-6: September 1998
Table 5 shows an example of a parameterized ASP. All ASPs containing PDUs contain only that PDU and
no other parameters.
Table 5: 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.

Page 16
ETS 300 195-6: September 1998
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 6: 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 6 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
EDVLF DFRQVWUDLQWRIW\SH&+,YDOLGIRUEDVLFDFFHVV
EDVLFBIODJ D%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 17
ETS 300 195-6: September 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.
A value assigned to an element of type SET OF differs depending on whether it is a send or receive
constraint.
Table 7: 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: 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 send constraint (as in table 7) 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.

Page 18
ETS 300 195-6: September 1998
Table 8: 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: 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 8) 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 8, 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], subclause 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 semantic definition used in this ATS.
6.2.2.1 Specification of encoding rules
At the time of specifying this ATS the mechanisms related to encoding of ASN.1 types, specified in DAM-2
of ISO/IEC 9646-3 [8], were not yet stable. Nevertheless as there is a variation in the encoding rules as
applied to ASN.1 types and constraints specified in this ATS, a mechanism is used to differentiate the
different encoding rules. Given the non-finalized status of DAM-2, a solution which is broadly in the spirit of
DAM-2 has been created. Comment fields have been used as a means of including the encoding rules.

Page 19
ETS 300 195-6: September 1998
For ASN.1 used in this ATS, two variations of encoding rules are used. One is the commonly known Basic
Encoding Rules (BER) as specified in CCITT Recommendation X.209 [12]. In the second case the
encoding is 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. This ISDN encoding variation is the default encoding rule for this ATS. This means that all
ASN.1 constraint tables are encoded using ISDN (non-BER) encoding unless stated otherwise. BER
encoding should never be applied to an ASN.1 constraint where BER encoding has not been specified.
For BER encoding, an indication is given in the comments field of the table header. For this ATS such
indications appear in the ASN.1 type constraint declaration tables only. In the first line of the table header
comment field, the notation "ASN1_Encoding: BER" is used.
Note that within BER, there are a number of variations for the encoding of lengths of fields. According to
ETS 300 196-1 [5], an IUT should be able to interpret all length forms within BER for received PDUs.
When sending PDUs containing BER encoding, ETS 300 196-1 [5] gives guidelines but makes no
restrictions on the length forms within BER which an IUT may apply.
In relation to components sent by the tester to the IUT, implementors of this ATS shall use a variety of
length forms such that at least one of each of the length forms is sent to the IUT during a test campaign.
The variations of length forms to be used are indefinite, short definite and long definite.
In this particular ATS all ASN.1 type constraints which are of type "Component" are to be encoded using
BER.
Table 9: ASN.1 type constraint declaration showing use of encoding variation
ASN.1 Type Constraint Declaration
Constraint Name : Beg3PTYinv
ASN.1 Type   : Component
Derivation Path :
Comments    : ASN1_Encoding: BER
Receive component: Begin3PTY invoke component
Description
begin3PTY_Components
begin3PTY_InvokeComp
{ invokeID      ? ,
operation_value  localValue  4}
Detailed comments :
Page 20
ETS 300 195-6: September 1998
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 [8], 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.
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.

Page 21
ETS 300 195-6: September 1998
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 10: 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 10 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 constraint 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 22
ETS 300 195-6: September 1998
6.3 Dynamic part
6.3.1 Test cases
Each test case contains the test purpose text from ETS 300 195-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
Much use has been made of test steps to avoid needless repetition of dynamic behaviour. Many test steps
are based on those used for the ISDN basic call ATS.
6.3.3 Defaults
Note the use of the RETURN statement which is defined in DAM1 of ISO/IEC 9646-3 [8]. 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 [10], to produce a PCTR conformant with the PCTR template given in annex B of
ISO/IEC 9646-5 [10].
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.
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 [9], 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 9646-5 [10], to further augment the augmented partial PIXIT proforma to produce a PIXIT
proforma conformant with this partial PIXIT proforma specification.
A PIXIT proforma which conforms to this partial PIXIT proforma specification shall, as a minimum, have
contents which are technically equivalent to annex B. The PIXIT proforma may contain additional questions
that need to be answered in order to prepare the test laboratory for a particular IUT.

Page 23
ETS 300 195-6: September 1998
10 ATS conformance
The test realizer, producing MOT and ExTS for this ATS specification, shall comply with the requirements
of ISO/IEC 9646-4 [9]. In particular, these concern the realization of an ExTS based on each ATS. The
test realizer shall provide a statement of conformance of the MOT to this ATS specification.
An ExTS which conforms to this ATS specification shall contain test groups and test cases which are
technically equivalent to those contained in the ATS in annex C. All sequences of test events comprising an
abstract test case shall be capable of being realized in the executable test case. Any further checking
which the test system might be capable of performing is outside the scope of this ATS specification and
shall not contribute to the verdict assignment for each test case.
Test laboratories running conformance test services using this ATS shall comply with ISO/IEC 9646-5 [10].
A test laboratory which claims to conform to this ATS specification shall use an MOT which conforms to
this ATS.
Page 24
ETS 300 195-6: September 1998
Annex A (normative): Protocol Conformance Test Report (PCTR) proforma
Notwithstanding the provisions of the copyright clause related to the text of this ETS, ETS
...