SIST EN 301 061-4 V1.1.4:2005

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Integrated Services Digital Network (ISDN); Digital Subscriber Signalling System No. one (DSS1) protocol; Generic functional protocol for the support of supplementary services at the b service entry point for Virtual Private Network (VPN) applications; Part 4: Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing (PIXIT) proforma specification for the user33.080Digitalno omrežje z integriranimi storitvami (ISDN)Integrated Services Digital Network (ISDN)ICS:Ta slovenski standard je istoveten z:EN 301 061-4 Version 1.1.4SIST EN 301 061-4 V1.1.4:2005en01-januar-2005SIST EN 301 061-4 V1.1.4:2005SLOVENSKI
STANDARD
ETSIETSI EN 301 061-4 V1.1.4 (1999-10)2ReferenceDEN/SPS-05110-4 (9tp00ieo.PDF)KeywordsATS, DSS1, generic, ISDN, PIXIT,supplementary services, VPN, userETSIPostal addressF-06921 Sophia Antipolis Cedex - FRANCEOffice address650 Route des Lucioles - Sophia AntipolisValbonne - FRANCETel.: +33 4 92 94 42 00
Fax: +33 4 93 65 47 16Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/88Internetsecretariat@etsi.frIndividual copies of this ETSI deliverablecan be downloaded fromhttp://www.etsi.orgIf you find errors in the present document, send yourcomment to: editor@etsi.frImportant noticeThis ETSI deliverable may be made available in more than one electronic version or in print. In any case of existing orperceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).In case of dispute, the reference should be the printing on ETSI printers of the PDF version kept on a specific networkdrive within ETSI Secretariat.Copyright NotificationNo 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 1999.All rights reserved.SIST EN 301 061-4 V1.1.4:2005

ETSIETSI EN 301 061-4 V1.1.4 (1999-10)3ContentsIntellectual Property Rights.5Foreword.51Scope.62References.63Definitions and abbreviations.73.1Definitions.73.1.1Definitions related to conformance testing.73.1.2Definitions related to EN 301 061-1.73.2Abbreviations.84Abstract Test Method.84.1Description of ATM used.84.1.1Functional subsets.94.1.2PINX role and Test Component Configuration considerations.94.1.2.1Single PCO testing.94.1.2.2Multi PCO testing.94.2Conventions for test components and PCOs.105Untestable 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.126.1.1.3.1TTCN ASP type definitions.126.1.1.3.2ASN.1 ASP type definitions.136.1.1.4PDU type definitions.136.1.1.4.1TTCN PDU type definitions.136.1.1.4.2ASN.1 PDU type definitions.136.1.2Test suite constants.136.1.3Test suite parameters.136.1.4Variables.136.1.4.1Test suite variables.136.1.4.2Test case variables.146.1.5Test suite operation definitions.146.2Constraints part.146.2.1Structured type constraint declaration.146.2.2ASN.1 type constraint declaration.146.2.3ASP type constraint declaration.146.2.3.1ASN.1 ASP type constraint declaration.146.2.3.2TTCN ASP type constraint declaration.156.2.4PDU type constraint declaration.156.2.4.1ASN.1 PDU type constraint declaration.156.2.4.2TTCN PDU type constraint declaration.156.2.4.3Special coding.156.2.5Derived constraints.156.2.6Parameterized constraints.156.2.7Value assignment.156.2.7.1Specific values.156.2.7.2Matching values.166.3Dynamic part.16SIST EN 301 061-4 V1.1.4:2005

ETSIETSI EN 301 061-4 V1.1.4 (1999-10)46.3.1Test cases.166.3.2Test steps.166.3.3Defaults.167ATS to TP map.168PCTR conformance.169PIXIT conformance.1710ATS Conformance.17Annex A (normative):Protocol Conformance Test Report (PCTR) proforma.18A.1Identification summary.18A.1.1Protocol conformance test report.18A.1.2IUT identification.18A.1.3Testing environment.18A.1.4Limits and reservations.19A.1.5Comments.19A.2IUT Conformance status.19A.3Static conformance summary.19A.4Dynamic conformance summary.20A.5Static conformance review report.20A.6Test campaign report.21A.7Observations.23Annex B (normative):Partial PIXIT proforma.24B.1Identification summary.24B.2Abstract test suite summary.24B.3Test laboratory.24B.4Client (of the Test Laboratory).25B.5SUT.25B.6Protocol information.26B.6.1Protocol identification.26B.6.2Configuration to be tested.26B.6.3Test management timers.27B.6.4Parameter Values.27Annex C (normative):The TTCN Graphical and Machine Processable forms.29C.1The TTCN Graphical form (TTCN.GR).29C.2The TTCN Machine Processable form (TTCN.MP).29Annex D (informative):General structure of ATS.30Annex E (informative):TTCN MP and GR version history.31History.32SIST EN 301 061-4 V1.1.4:2005

ETSIETSI EN 301 061-4 V1.1.4 (1999-10)5Intellectual Property RightsIPRs essential or potentially essential to the present document may have been declared to ETSI. The informationpertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be foundin SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respectof ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server(http://www.etsi.org/ipr).Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guaranteecan be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server)which are, or may be, or may become, essential to the present document.ForewordThis European Standard (Telecommunications series) has been produced by ETSI Technical Committee Services andProtocols for Advanced Networks (SPAN).The present document is part 4 of a multi-part standard covering the Digital Subscriber Signalling System No. one(DSS1) protocol specification for the Integrated Services Digital Network (ISDN) Generic functional protocol for thesupport of supplementary services for Virtual Private Network (VPN) applications, 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 forTesting (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 datesDate of adoption of this EN:1 October 1999Date of latest announcement of this EN (doa):31 January 2000Date of latest publication of new National Standardor endorsement of this EN (dop/e):31 July 2000Date of withdrawal of any conflicting National Standard (dow):31 July 2000SIST EN 301 061-4 V1.1.4:2005

ETSIETSI EN 301 061-4 V1.1.4 (1999-10)61ScopeThis fourth part of EN 301 061 is applicable to the Generic functional protocol for the support of supplementaryservices for Virtual Private Network (VPN) applications for the pan-European Integrated Services Digital Network(ISDN) by means of the Digital Subscriber Signalling System No. one (DSS1) protocol, EN 301 061-1 [1].The present document specifies the Abstract Test Suite (ATS), and partial Protocol Implementation eXtra Informationfor Testing (PIXIT) proforma for the network side of the T reference point or coincident S and T reference point ofimplementation conforming to EN 301 061-1 [1] in compliance with the relevant requirements and in accordance withthe relevant guidance given in ISO/IEC 9646.2ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the presentdocument.·References are either specific (identified by date of publication, edition number, version number, etc.) ornon-specific.·For a specific reference, subsequent revisions do not apply.·For a non-specific reference, the latest version applies.·A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the samenumber.[1]EN 301 061-1: "Integrated Services Digital Network (ISDN); Subaddressing (SUB) supplementaryservice; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocolspecification".[2]EN 301 061-2: "Integrated Services Digital Network (ISDN); Subaddressing (SUB) supplementaryservice; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 2: ProtocolImplementation Conformance Statement (PICS) proforma specification".[3]ISO/IEC 9646-1: "Information technology - Open Systems Interconnection - Conformance testingmethodology and framework - Part 1: General concepts".[4]ISO/IEC 9646-2: "Information technology - Open Systems Interconnection - Conformance testingmethodology and framework - Part 2: Abstract test suite specification".[5]ISO/IEC 9646-3: "Information technology - Open Systems Interconnection - Conformance testingmethodology and framework - Part 3: The Tree and Tabular Combined Notation (TTCN)".[6]EN 300 403-1: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling SystemNo. one (DSS1) protocol; Signalling network layer for circuit-mode basic call control; Part 1:Protocol specification (ITU-T Recommendation Q.931 (1993), modified)".[7]ITU-T Recommendation I.112 (1993): "Vocabulary of terms for ISDNs".[8]ITU-T Recommendation E.164: "The international public telecommunication numbering plan".[9]ITU-T Recommendation I.210 (1993): "Principles of telecommunication services supported by anISDN and the means to describe them".[10]ETS 300 239: "Private Integrated Services Network (PISN); Inter-exchange signalling protocol;Generic functional protocol for the support of supplementary services [ISO/IEC 11582 (1995),modified]".[11]ISO/IEC 9646-4: "Information technology - Open Systems Interconnection - Conformance testingmethodology and framework - Part 4: Test realization".SIST EN 301 061-4 V1.1.4:2005

ETSIETSI EN 301 061-4 V1.1.4 (1999-10)7[12]ISO/IEC 9646-5: "Information technology - Open Systems Interconnection - Conformance testingmethodology and framework - Part 5: Requirements on test laboratories and clients for theconformance assessment process[13]EN 301 061-3: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling SystemNo. one (DSS1) protocol; Generic functional protocol for the support of supplementary services atthe "b" service entry point for Virtual Private Network (VPN) applications; Part 3: Test SuiteStructure and Test Purposes (TSS&TP) specification for the user".3Definitions and abbreviations3.1DefinitionsFor the purposes of the present document, the following terms and definitions apply:3.1.1Definitions related to conformance testingabstract test case: refer to ISO/IEC 9646-1 [3].Abstract Test Suite (ATS): refer to ISO/IEC 9646-1 [3].active test: test case where the IUT is required to send a particular message, but not in reaction to a received message.This would usually involve the use of PIXIT information to see how this message can be generated and quite often isspecified in an ATS using an implicit send event.Implementation Under Test (IUT): refer to ISO/IEC 9646-1 [3].implicit send event: refer to ISO/IEC 9646-3 [5].lower tester: refer to ISO/IEC 9646-1 [3].passive test: test case where the IUT is required to respond to a protocol event (e.g. received message) with anotherprotocol event (e.g. send message) which normally does not require any special operator intervention as associated withthe implicit send event.point of control and observation: refer to ISO/IEC 9646-1 [3].Protocol Implementation Conformance Statement (PICS): refer to ISO/IEC 9646-1 [3].PICS proforma: refer to ISO/IEC 9646-1 [3].Protocol Implementation eXtra Information for Testing (PIXIT): refer to ISO/IEC 9646-1 [3].PIXIT proforma: refer to ISO/IEC 9646-1 [3].system under test: refer to ISO/IEC 9646-1 [3].Test Purpose (TP): refer to ISO/IEC 9646-1 [3].3.1.2Definitions related to EN 301 061-1Dummy call reference: see EN 300 403-1 [6], subclause 4.3.Integrated Services Digital Network (ISDN): see ITU-T Recommendation I.112 [7], definition 308.ISDN number: number conforming to the numbering and structure specified in ITU-T Recommendation E.164 [8].service; telecommunication service: see ITU-T Recommendation I.112 [7], definition 201.SIST EN 301 061-4 V1.1.4:2005

ETSIETSI EN 301 061-4 V1.1.4 (1999-10)8supplementary service: see ITU-T Recommendation I.210 [9], subclause 2.4.T: DSS1 protocol entity at the User side of the user-network interface where a T reference point applies (User is aPrivate ISDN).3.2AbbreviationsFor the purposes of the present document, the following abbreviations apply:ASPAbstract Service PrimitiveATMAbstract Test MethodATSAbstract Test SuiteBABasic AccessCESConnection Endpoint SuffixCICSCustomer Information Control System (IBM)CMCo-ordination MessageDSEData Switching ExchangeExTSExecutable Test SuiteGFTCGeneric Functional Transport ControlIE(Signalling) Information ElementISDNIntegrated Services Digital NetworkIUTImplementation Under TestLTLower TesterMOTMeans Of TestingMTCMain Test ComponentNCICSNetwork Call Independent Connection-oriented SignallingNFENetwork Facility ExtensionPCOPoint of Control and ObservationPCTRProtocol Conformance Test ReportPDUProtocol Data UnitPICSProtocol Implementation Conformance StatementPINXPrivate Integrated Network ExchangePIXITProtocol Implementation eXtra Information for TestingPRAPrimary Rate AccessPTCParallel Test ComponentSUTSystem Under TestTPTest PurposeTSSTest Suite StructureTTCNTree and Tabular Combined NotationVPNVirtual Private Network4Abstract Test Method4.1Description of ATM usedClause 4.1 describes the different Abstract Test Methods (ATM) used for testing the Generic Functional Protocol. Twomethods are applied; the Remote test method, and the Multi-Party test method.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 suitewould be constructed. Such a test method specifies behaviour at multiple network interfaces. One very importantlimitation here is that tests are focused on one particular interface. Thus the test system is made up one Main TestComponent (MTC) and one or more Parallel Test Components (PTC), see figure 1.SIST EN 301 061-4 V1.1.4:2005

ETSIETSI EN 301 061-4 V1.1.4 (1999-10)94.1.1Functional subsetsThe Generic Function Protocol is divided into a number of entities as shown in figure 1. This ATS is principallyconcerned with the testing of the Protocol Control and Generic Functional Transport Control entities, Coordinationfunctions and ROSE entities.NOTE:Valid behaviour of the application layer is supplementary service specific and its testing is specified intest specifications for individual supplementary services (if any). DSE requirements are excluded from thescope of the present document.The testing of all these layers is performed using a PCO at the SCM/Network layer boundary.SSControlGeneric FunctionalCoordinationProtocol ControlLayer 2Layer 1 FunctionNetworkTransport ControlApplicationLayerGFPROSEDSELayerSCMACSENOTE:Grey shading indicates entities not part of the GenericFunctional Protocol.Figure 1: GFP functional subsets4.1.2PINX role and Test Component Configuration considerationsA PINX may act either in the role of an End PINX or in the role of a Transit PINX. A particular PINX may be capableof acting in one or both roles. Whereas the Generic Functional Transport Control (GFTC) requirements generallydepend on which role is involved, the Protocol Control (PC) requirements do not.Depending on the role of the PINX, it may be necessary to use different procedures in the preambles to achieve thepre-condition in some TPs concerned with PC requirements. For these cases, which will require different test componentconfigurations, there may be two separate Test Cases (TCs), one for each role, generated from each relevant TP.The different configurations used are depending on the role of the PINX, in the sense that the slave part will use adifferent access point to the public network.4.1.2.1Single PCO testingSingle PCO testing is used for the tests when events at the outgoing side are not required to be tested and when noactivity is expected at the outgoing side, i.e. only one interface is reacting.CONFIG_MONO: this configuration is mainly used for NCICS connection.4.1.2.2Multi PCO testingMulti PCO testing is used for the tests when events at the outgoing side are required either to be tested or to provoke areaction of the IUT at the tested interface. the configuration defined i depending on the role of the PINX at the testedinterface.CONFIG_DUAL: The remote access for this configuration is directly dependant on the role of the PINX, transit or end.SIST EN 301 061-4 V1.1.4:2005

ETSIETSI EN 301 061-4 V1.1.4 (1999-10)104.2Conventions for test components and PCOsMaster partSlave partMTCAPTC1CPA1L0 PCOL1 PCOIUTNETWORKFigure 2: Multi-party test methodIn a master/slave arrangement, the MTC is considered to be the master while the PTCs are the slaves. The "slave" testersare only an explicit description of how to deal with the "other" interfaces during the testing process, i.e. "how to makethe IUT send the required message".This means, in particular, that the verdict will only be assigned from the protocol aspects observed on the interfaceunder test (i.e. by the "master" tester), as it would be observed by a terminal connected to this interface. A failure in thecorrelation between the protocol at the different interfaces to which the different testers are connected, i.e. in themechanism of the functional service itself, will not cause a FAIL verdict. For instance, if the IUT fails to send a messageon 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 morePTCs. Thus it is responsible for starting the PTCs and afterwards coordinates activities by exchanging CoordinationMessages (CM) with the PTCs. Secondly it is responsible for the behaviour of the Lower Tester (LT) at PCO L0.SIST EN 301 061-4 V1.1.4:2005

ETSIETSI EN 301 061-4 V1.1.4 (1999-10)11A combination of the remote and multi-party test methods is applied. As can be seen from figure 2, several PCOs areused. All PCOs reside at the service access points between layers 2 and 3.MTCSUTPTC1Layer 3¾¾¾¾Layer 2¾¾¾¾Layer 1¾L0¾¾¾¾¾¾¾¾¾IUT¾¾¾¾¾¾¾¾¾
¾¾
¾¾¾¾¾¾¾¾¾¾¾¾¾¾L1¾¾¾¾¾Layer 3¾¾¾¾Layer 2¾¾¾¾Layer 1Service providerFigure 3: Combination of the remote and multi-party test methodsThe MTC PCO is named "L0" ("L" for Lower). The L0 PCO is used to control and observe the behaviour of the IUTand test case verdicts are assigned depending on the behaviour observed at this PCO. The PTCs PTC1, use PCOs L1.These PCOs are used to control and, in a limited way, observe the behaviour of the network equipment at interfacesother than the one under test. No verdicts are assigned at these PCOs.As stated in a previous paragraph, the non-receipt of network generated messages at L0, which are stimulated by eventsat the L1, will result in INCONCLUSIVE rather than FAIL verdicts being assigned.The capability of the IUT to send INFORMATION and PROGRESS messages is tested in different call states. Implicitsend events have to be used in this small set of test cases, as the sending of those messages cannot be triggered via aPTC. Separate PIXIT questions are asked for each call state, if and how it is possible for the test operator to cause thesending of the messages.5Untestable test purposesThere are no untestable test purposes in this ATS.6ATS conventionsClause 6 is structured similarly to the structure of a TTCN ATS. However, the names of the subclauses are arranged in away more suitable to the present document.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 length restriction or avalue list attached.Simple types, defined as being of INTEGER type, have a value list or a range restriction attached.SIST EN 301 061-4 V1.1.4:2005

ETSIETSI EN 301 061-4 V1.1.4 (1999-10)126.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 definedin that referenced type.For information elements the identifier, which is unique for each element, has its type defined as a simple type where thevalue list is restricted to the single value which is the identifier itself. This has the advantage that it allows a test systemderived from this ATS to easily identify information elements embedded in messages. An ATS where informationelement identifiers are represented as unrestricted types can present difficulties for a derived test system in the casewhere it needs to find one information element embedded in a number of others and the constraints for the otherelements have the any-or-omit value. In such a case the test system cannot easily find the beginning of each informationelement.6.1.1.2.2ASN.1 structured type definitionsASN.1 types corresponding to Information Elements, have identifiers according to subclause 7.2.3. Other ASN.1 typestaken from ETS 300 239 [10] have, whenever possible, the same identifier names as the ASN.1 type names used in thosestandards. In some cases it is necessary to replace a hyphen character ('-') with an underscore character ('_') to satisfy theTTCN syntax. Where an ASN.1 type is used to replace an ASN.1 macro, the identifier is the name of the macro with thefirst letter in upper case and the remainder of the name in lower case (the macro name is specified with all upper casecharacters).In other cases the identifier consists of one or more words, with the first letter of each word in upper case, and theremaining letters in the word, in lower case.EXAMPLE 1:privateTypeOfNumber is the ASN.1 PrivateTypeOfNumber type from ETS 300 239 [10].EXAMPLE 2:operation is the ASN.1 type replacing the OPERATION macro.The identifier of an ASN.1 named type (i.e. the name of a field within a type defined in ASN.1), the identifier of anASN.1 named number or the identifier of a value of an ASN.1 enumerated type is composed of a string of concatenatedwords, all but the first word (which begins with a lower case letter), beginning with an uppercase letter, with theremainder of the word in lower case. Where these named types, named numbers or values of enumerated types are takenfrom ETS 300 239 [10] the same identifiers have been used as in those standards, subject to the same restrictions as fortype identifiers.EXAMPLE 3:sourceEntity is the identifier of the ASN.1 named type sourceEntity in the ASN.1NetworkFacilityExtension type from ETS 300 239 [10].EXAMPLE 4:discardAnyUnrecognizedInvokePdu is the identifier of one named number of the ASN.1InterpretationAPDU enumerated type from ETS 300 239 [10].NOTE:Due to the TTCN static semantics, it has been necessary to define new intermediate ASN.1 types(e.g. RoseErrors), consisting of some named numbers from INTEGER types or values of ENUMERATEDtypes, in order to avoid multiple definitions of items with the same name.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.All TTCN ASP type definitions are provided with a full identifier.SIST EN 301 061-4 V1.1.4:2005

ETSIETSI EN 301 061-4 V1.1.4 (1999-10)13Some ASPs are not parameterized as shown in the example in table 1. Such ASPs are only used for requesting orreceiving service from the lower layer.Table 1: 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:Table 2 shows an example of a parameterized ASP. All ASPs containing PDUs contain only that PDU and no otherparameters.Table 2: TTCN ASP type definition DL_DATA_RQTTCN ASP Type DefinitionASP NAME: DL_DATA_RQ(DL_DATA_REQUEST)PCO Type: SAPComments:Parameter Name
|
Parameter Type
|
Commentsmun (MessageUnit)
|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 in ASPs.If a specific PDU type definition contains elements defined in terms of a pre-defined type, that element has a restrictionattached 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 constantsEach test suite constant is defined in terms of a predefined type or a referenced type. The values given in the valuecolumn will remain unchanged throughout the test suite.6.1.3Test suite parametersEach test suite parameter is defined in terms of a predefined type or a referenced type. A referenced type is used when itis necessary to attach restrictions to these type definitions (it is not allowed to include restrictions directly in the testsuite parameter table). The referenced type can have a length or value restriction attached to it in its declaration table.6.1.4Variables6.1.4.1Test suite variablesNo Test Suite Variables are used or defined in this ATS.SIST EN 301 061-4 V1.1.4:2005

ETSIETSI EN 301 061-4 V1.1.4 (1999-10)146.1.4.2Test case variablesEach test case variable is defined in terms of a predefined type or a referenced type. A referenced type is used when it isnecessary to attach restrictions to these type definitions (it is not allowed to include restrictions directly in the test casevariable 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.5Test suite operation definitionsThe description part of a test suite operation definition uses either natural language or meta C.Table 3: 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.DescriptionCHI ASSIGN_CHI(basic,primary,basic_flag)If the value of the basic_flag is set to TRUE, the result of the operation ASSIGN_CHI will bethe value represented by the parameter basic which is of type CHI. Else the operation results inthe value represented by the parameter primary.Examples:ASSIGN_CHI(CHI1b_R1, CHI1p_R1, TRUE) = CHI1b_R1ASSIGN_CHI(CHI1b_R1, CHI1p_R1, FALSE) = CHI1p_R1Detailed comments:The test suite operation definition shown in table 3 is used in the constraints part when assigning an element of type CHIa value. 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 this operation is used to assign a value to an element of CHItype. 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 beassigned to the specific element of type CHI.6.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 declarationFor every ASN.1 type definition there exists one or more ASN.1 type constraint.6.2.3ASP type constraint declaration6.2.3.1ASN.1 ASP type constraint declarationThere are no ASN.1 ASP type constraint declarations in the ATS.SIST EN 301 061-4 V1.1.4:2005

ETSIETSI EN 301 061-4 V1.1.4 (1999-10)156.2.3.2TTCN ASP type constraint declarationThe PDUs to be sent or received are passed to the TTCN ASP constraint declarations Ms and Mr as parameters of metatype PDU. Only if values inside a specific PDU have to be referenced, the use of the meta type PDU is not allowedaccording to ISO/IEC 9646-3 [5]. In such cases different TTCN ASP constraint declarations are used, that are defined tocarry only a specific type of PDU (e.g. SETUP). Table 4 shows an example of such a TTCN ASP constraint declaration.Table 4: TTCN ASP constraint declaration SrTTCN ASP Constraint DeclarationConstraint Name : Sr(PARAM: SETUP_PDU)ASP Type
: DL_DAT_IN_SETUPDerivation Path:Comments
: ASP to indicate the receipt of SETUP messages.Parameter Name
|
Parameter Value
|
Commentsmun
|PARAM
|Detailed Comments:All ASP constraints have a specific value for its parameter. No matching symbols are used in ASPs.6.2.4PDU type constraint declaration6.2.4.1ASN.1 PDU type constraint declarationThere are no ASN.1 PDU type constraint declarations in the ATS.6.2.4.2TTCN PDU type constraint declarationPDU constraints are used for assigning values or patterns to the data being sent or received.6.2.4.3Special codingThe information element transit counter, present in the SETUP PDU, shall be defined in codeset 4, for this purpose theATS is coding this IE with a locking shift (codeset 4) at the end of the PDU SETUP.6.2.5Derived constraintsDerived constraints are used in this ATS only for SETUP.6.2.6Parameterized constraintsParameterized constraints are used in this ATS.6.2.7Value assignment6.2.7.1Specific valuesFor specific value assignment both explicit values and references to explicit values are used.SIST EN 301 061-4 V1.1.4:2005

ETSIETSI EN 301 061-4 V1.1.4 (1999-10)166.2.7.2Matching valuesAs matching values the following mechanisms are used:Instead of Value:AnyOrOmit"*"AnyValue"?"Omit"-"Inside value:AnyOne"?"AnyOrNone"*"6.3Dynamic part6.3.1Test casesEach test case contains the test purpose text from EN 301 061-3 [13]. To be able to read and understand the test casedynamic behaviour it is recommended that the test steps are understood first.6.3.2Test stepsMuch use has been made of test steps to avoid needless repetition of dynamic behaviour.6.3.3DefaultsNote the use of the RETURN statement which is defined in DAM1 of ISO/IEC 9646-3 [5]. This allows validbackground behaviour to be handled in the default tree with a possibility to return to the original set of alternatives in thetest case.7ATS to TP mapThe identifiers used for the TPs are reused as test case names. Thus there is a straightforward one-to-one mapping.8PCTR conformanceA test laboratory, when requested by a client to produce a PCTR, is required, as specified in ISO/IEC 9646-5 [12], toproduce a PCTR conformant with the PCTR template given in annex B of ISO/IEC 9646-5 [12].Furthermore, a test laboratory, offering testing for the ATS specification contained in annex C, when requested by aclient to produce a PCTR, is required to produce a PCTR conformant with the PCTR proforma contained in annex A ofthe present document.A PCTR which conforms to this PCTR proforma specification shall preserve the content and ordering of the clausescontained in clause A.6 of the PCTR may contain additional columns. If included, these shall be placed to the right ofthe existing columns. Text in italics may be retained by the test laboratory.SIST EN 301 061-4 V1.1.4:2005

ETSIETSI EN 301 061-4 V1.1.4 (1999-10)179PIXIT conformanceA test realizer, producing an executable test suite for the Abstract Test Suite (ATS) specification contained in annex C,is required, as specified in ISO/IEC 9646-4 [11], to produce an augmented partial PIXIT proforma conformant with thispartial 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 containadditional questions that need to be answered in order to prepare the Means Of Testing (MOT) for a particularImplementation Under Test (IUT).A test laboratory, offering testing for the ATS specification contained in annex C, is required, as specified inISO/IEC 9646-5 [12], to further augment the augmented partial PIXIT proforma to produce a PIXIT proformaconformant with this partial PIXIT proforma specification.A PIXIT proforma which conforms to this partial PIXIT proforma specification shall, as a minimum, have contentswhich are technically equivalent to annex B. The PIXIT proforma may contain additional questions that need to beanswered in order to prepare the test laboratory for a particular IUT.10ATS ConformanceThe test realizer, producing a Means Of Testing (MOT) and Executable Test Suite (ExTS) for this Abstract Test Suite(ATS) specification, shall comply with the requirements of ISO/IEC 9646-4 [11]. In particular, these concern therealization of an Executable Test Suite (ExTS) based on
...