ETSI EN 300 093-6 V1.2.4 (1998-06)

Integrated Services Digital Network (ISDN); Calling Line Identification Restriction (CLIR) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 6: Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing (PIXIT) proforma specification for the network

REN/SPS-05145-D-6

Digitalno omrežje z integriranimi storitvami (ISDN) – Dopolnilna storitev: omejitev identifikacije (razpoznavanja) kličočega priključka (CLIR) – 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 specifikacija za omrežje

General Information

• Status: Published
• Publication Date: 24-Jun-1998
• Technical Committee: SPS 5 3 - Conformance Testing
• Current Stage: 12 - Completion
• Due Date: 03-Jul-1998
• Completion Date: 25-Jun-1998
• Ref Project: SIST EN 300 093-6 V1.2.4:2003 - Integrated Services Digital Network (ISDN); Calling Line Identification Restriction (CLIR) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 6: Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing (PIXIT) proforma specification for the network

Standards Content (Sample)

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Integrated Services Digital Network (ISDN); Calling Line Identification Restriction (CLIR) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 6: Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing (PIXIT) proforma specification for the network33.080Digitalno omrežje z integriranimi storitvami (ISDN)Integrated Services Digital Network (ISDN)ICS:Ta slovenski standard je istoveten z:EN 300 093-6 Version 1.2.4SIST EN 300 093-6 V1.2.4:2003en01-december-2003SIST EN 300 093-6 V1.2.4:2003SLOVENSKI
STANDARD
EN 300 093-6 V1.2.4 (1998-06)European Standard (Telecommunications series)Integrated Services Digital Network (ISDN);Calling Line Identification Restriction (CLIR)supplementary service;Digital Subscriber Signalling System No. one (DSS1) protocol;Part 6: Abstract Test Suite (ATS) and partial ProtocolImplementation eXtra Information for Testing (PIXIT)proforma specification for the networkSIST EN 300 093-6 V1.2.4:2003

ETSIEN 300 093-6 V1.2.4 (1998-06)2ReferenceREN/SPS-05145-D-6 (0v1i0iqo.PDF)KeywordsISDN, DSS1, supplementary service, CLIR,testing, ATS, PIXIT, networkETSIPostal addressF-06921 Sophia Antipolis Cedex - FRANCEOffice address650 Route des Lucioles - Sophia AntipolisValbonne - FRANCETel.: [phone]
Fax: [phone]Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/[e-mail]://www.etsi.frhttp://www.etsi.orgCopyright 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 1998.All rights reserved.SIST EN 300 093-6 V1.2.4:2003

ETSIEN 300 093-6 V1.2.4 (1998-06)3ContentsIntellectual Property Rights.5Foreword.51Scope.62Normative references.63Definitions and abbreviations.73.1Definitions.73.2Abbreviations.74Abstract Test Method (ATM).84.1Description of ATM used.84.1.1Conventions for test components and PCOs.84.1.2Conventions for variables and parameters.94.2Alternative ATM.95Untestable test purposes.106ATS conventions.116.1Declarations part.116.1.1Type definitions.116.1.1.1Simple type definitions.116.1.1.2Structured type definitions.116.1.1.2.1TTCN structured type definitions.116.1.1.2.2ASN.1 structured type definitions.116.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.136.1.5Test suite operation definitions.146.2Constraints part.146.2.1Structured type constraint declaration.146.2.2ASN.1 type constraint declaration.146.2.2.1Specification of encoding rules.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.5Chaining of constraints.156.2.5.1Static chaining.156.2.5.2Dynamic chaining.156.2.6Derived constraints.156.2.7Parameterized constraints.156.2.8Value assignment.166.2.8.1Specific values.166.2.8.2Matching values.166.3Dynamic part.166.3.1Test cases.166.3.2Test steps.16SIST EN 300 093-6 V1.2.4:2003

ETSIEN 300 093-6 V1.2.4 (1998-06)46.3.2.1PTC1_IN.166.3.2.2PTC1_OUT.166.3.3Defaults.167ATS to TP map.178PCTR conformance.179PIXIT 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.19A.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.20A.7Observations.20Annex B (normative):Partial PIXIT proforma.22B.1Identification summary.22B.2Abstract test suite summary.22B.3Test laboratory.22B.4Client (of the test laboratory).23B.5System Under Test (SUT).23B.6Protocol information.24B.6.1Protocol identification.24B.6.2Parameter values.24B.6.3Number information parameter values.24B.6.4Configuration of IUT.25B.6.5Timer values.25B.7Basic call PIXIT items.26B.7.1Parameter values - information element codings.26Annex C (normative):Abstract Test Suite (ATS).27C.1The TTCN Graphical form (TTCN.GR).27C.2The TTCN Machine Processable form (TTCN.MP).27Annex D (informative):General structure of ATS.28Annex E (informative):Changes with respect to the previous ETS 300 093-6.29History.30SIST EN 300 093-6 V1.2.4:2003

ETSIEN 300 093-6 V1.2.4 (1998-06)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 found inSR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respectof ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on theETSI Web server (http://www.etsi.fr/ipr or http://www.etsi.org/ipr).Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee canbe given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) whichare, or may be, or may become, essential to the present document.ForewordThis European Standard (Telecommunications series) has been produced by ETSI Technical Committee SignallingProtocols and Switching (SPS).The present document 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) Calling Line Identification Restriction (CLIR)supplementary service, 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".The present version updates the references to the basic call specifications.National transposition datesDate of adoption of this EN:19 June 1998Date of latest announcement of this EN (doa):30 September 1998Date of latest publication of new National Standardor endorsement of this EN (dop/e):31 March 1999Date of withdrawal of any conflicting National Standard (dow):31 March 1999SIST EN 300 093-6 V1.2.4:2003

ETSIEN 300 093-6 V1.2.4 (1998-06)61ScopeThis sixth part of EN 300 093 specifies the Abstract Test Suite (ATS) and partial Protocol Implementation eXtraInformation for Testing (PIXIT) proforma for the Network side of the T reference point or coincident S and T referencepoint (as defined in ITU-T Recommendation I.411 [10]) of implementations conforming to the stage three standard for theCalling Line Identification Restriction (CLIR) supplementary service for the pan-European Integrated Services DigitalNetwork (ISDN) by means of the Digital Subscriber Signalling System No. one (DSS1) protocol, EN 300 093-1 [2].EN 300 093-5 [4] specifies the Test Suite Structure and Test Purposes (TSS&TP) related to this ATS and partial PIXITproforma specification. Other parts specify the TSS&TP and the ATS and partial PIXIT proforma for the User side of theT reference point or coincident S and T reference point of implementations conforming to EN 300 093-1 [2].2Normative referencesReferences may be made to:a)specific versions of publications (identified by date of publication, edition number, version number, etc.), in whichcase, subsequent revisions to the referenced document do not apply; orb)all versions up to and including the identified version (identified by "up to and including" before the versionidentity); orc)all versions subsequent to and including the identified version (identified by "onwards" following the versionidentity); ord)publications without mention of a specific version, in which case 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 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]".[2]EN 300 093-1 (V1.2): "Integrated Services Digital Network (ISDN); Calling Line IdentificationRestriction (CLIR) supplementary service; Digital Subscriber Signalling System No. one (DSS1)protocol; Part 1: Protocol specification".[3]EN 300 093-2 (V1.2): "Integrated Services Digital Network (ISDN); Calling Line IdentificationRestriction (CLIR) supplementary service; Digital Subscriber Signalling System No. one (DSS1)protocol; Part 2: Protocol Implementation Conformance Statement (PICS) proforma specification".[4]EN 300 093-5 (V1.2): "Integrated Services Digital Network (ISDN); Calling Line IdentificationRestriction (CLIR) supplementary service; Digital Subscriber Signalling System No. one (DSS1)protocol; Part 5: Test Suite Structure and Test Purposes (TSS&TP) specification for the network".[5]ISO/IEC 9646-1: "Information technology - OSI Conformance Testing Methodology and Framework;Part 1: General Concepts".[6]ISO/IEC 9646-2: "Information technology - OSI Conformance Testing Methodology and Framework;Part 2: Abstract Test Suite Specification".[7]ISO/IEC 9646-3: "Information technology - OSI Conformance Testing Methodology and Framework;Part 3: The Tree and Tabular Combined Notation".[8]ISO/IEC 9646-4: "Information technology - OSI Conformance Testing Methodology and Framework;Part 4: Test realization".[9]ISO/IEC 9646-5: "Information technology - OSI Conformance Testing Methodology and Framework;Part 5: Requirements on test laboratories and clients for the conformance assessment process".[10]ITU-T Recommendation I.411 (1993): "ISDN user-network interfaces - Reference configurations".SIST EN 300 093-6 V1.2.4:2003

ETSIEN 300 093-6 V1.2.4 (1998-06)7[11]CCITT Recommendation X.209 (1988): "Specification of Basic Encoding Rules for Abstract SyntaxNotation One (ASN.1)".3Definitions and abbreviations3.1DefinitionsFor the purposes of the present document, the following definitions apply:Abstract Test Suite (ATS): See ISO/IEC 9646-1 [5].Implementation Under Test (IUT): See ISO/IEC 9646-1 [5].Lower Tester (LT): See ISO/IEC 9646-1 [5].Point Of Control And Observation (PCO): See ISO/IEC 9646-1 [5].Protocol Implementation Conformance Statement (PICS): See ISO/IEC 9646-1 [5].PICS proforma: See ISO/IEC 9646-1 [5].Protocol Implementation Extra Information For Testing (PIXIT): See ISO/IEC 9646-1 [5].PIXIT proforma: See ISO/IEC 9646-1 [5].System Under Test (SUT): See ISO/IEC 9646-1 [5].Upper Tester (UT): See ISO/IEC 9646-1 [5].3.2AbbreviationsFor the purposes of the present document, the following abbreviations apply:ASPAbstract Service PrimitiveATMAbstract Test MethodATSAbstract Test SuiteBERBasic Encoding RulesCLIRCalling Line Identification RestrictionCMCo-ordination MessageCPCo-ordination PointExTSExecutable Test SuiteIUTImplementation Under TestLTLower TesterMOTMeans Of TestingMTCMain Test ComponentPCOPoint of Control and ObservationPCTRProtocol Conformance Test ReportPDUProtocol Data UnitPICSProtocol Implementation Conformance StatementPIXITProtocol Implementation eXtra Information for TestingPTCParallel Test ComponentSUTSystem Under TestTCPTest Co-ordination ProceduresTPTest PurposeTTCNTree and Tabular Combined NotationUTUpper TesterSIST EN 300 093-6 V1.2.4:2003

ETSIEN 300 093-6 V1.2.4 (1998-06)84Abstract Test Method (ATM)4.1Description of ATM usedThe requirement for testing the network IUT is to focus on the behaviour of the network IUT at the user-network interfacewhere a T reference point or coincident S and T reference point applies. Thus the IUT is the network DSS1 protocolentity at a particular user-network interface and is not the whole network.It is possible to specify an ATS based on a Single party (remote) test method for such an IUT. However, it is consideredthat an ATS based on such an approach is of limited use as the only way to specify IUT generated PDUs is to use the"implicit send" statement. Many users of such an ATS would replace the "implicit send" statements with descriptions ofthe behaviour at other interfaces.An ATS based on a multi-party test method is considered to be more useful in that it is closer to how a real test 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.4.1.1Conventions for test components and PCOsMaster partSlave partMTCAPTC1CPA1L0 PCOL1 PCOIUTNETWORKFigure 1: 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 make theIUT send the required message".This means, in particular, that the verdict will only be assigned from the protocol aspects observed on the interface undertest (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 theSIST EN 300 093-6 V1.2.4:2003

ETSIEN 300 093-6 V1.2.4 (1998-06)9mechanism 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 co-ordinates activities by exchanging Co-ordinationMessages (CM) with the PTCs. Secondly it is responsible for the behaviour of the Lower Tester (LT) at PCO L0.A combination of the remote and multi-party test methods is applied. As can be seen from figure 1, several PCOs 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 2: Combination of the remote and multi-party test methodsThe MTC PCO is named "L0" ("L" for Lower). PCO L0 is used to control and observe the behaviour of the IUT and testcase verdicts are assigned depending on the behaviour observed at this PCO. The PTC PTC1 uses PCO L1. This PCO isused to control and, in a limited way, observe the behaviour of the network equipment at interfaces other than the oneunder test. No verdicts are assigned at this PCO.As stated in a previous paragraph, the non-receipt of network generated messages at L0, which are stimulated by events atthe L1, will result in INCONCLUSIVE rather than FAIL verdicts being assigned.4.1.2Conventions for variables and parametersMTCAcall referenceCREF1B channel (basic)bch_num1(to PTC1)channel nr (primary)CH_NUM1PCO L0IPN0, LIPN0PTC1call referenceP1CREFB channel (basic)P1_bch_numchannel nr (primary)P1_CH_NUMPCO L1IPN1, LIPN14.2Alternative ATMAs stated in subclause 4.1, an ATS based on a single-party (remote) ATM is possible. Such an ATS may be generatedfrom the one specified in the present document. The following general steps should be taken:1)remove all PTC behaviour;2)remove all CREATE statements;SIST EN 300 093-6 V1.2.4:2003

ETSIEN 300 093-6 V1.2.4 (1998-06)103)replace CMs which are used to provoke PDUs at the MTC, with implicit send statements.An example, showing the difference between the multi-party ATM and single-party ATM for a single test case, is given intables 1 and 2.Table 1: Test case dynamic behaviour table using multi-party ATMTEST CASE DYNAMIC BEHAVIOURTest Case NameHOLD_N04_001GroupRemoteUser_ST_OR_T/Holding/PurposeEnsure that the IUT, while in the Active call state N10, tonotify the non-served user that the call is heldsends a NOTIFY message with a notification indicator coded as"remote hold" to user B and remains in the Active call state.DefaultDF69901(1)ConfigurationCONFIG1Comments9.2.1validoptional Nr| Label| BEHAVIOUR DESCRIPTION| CREF| V| COMMENTS1||CREATE ( PTC1: PTC1_IN_servedUser)|||2|| +PR31002|||preamble N103||
CPA1!CP_M START TWAIT|S_HL||4||
L0?NOTIFYr|A_NO20(CREF1,hold_NID)|(P)|5||
+CS59901(10,1)|||check N106||
?TIMEOUT TWAIT||(I)|7||
+PO49901(1)|||postamble N0DETAILED COMMENTS:Table 2: Test case dynamic behaviour table using single-party ATMTEST CASE DYNAMIC BEHAVIOURTest Case NameHOLD_N04_001GroupRemoteUser_ST_OR_T/Holding/PurposeEnsure that the IUT, while in the Active call state N10, tonotify the non-served user that the call is heldsends a NOTIFY message with a notification indicator coded as"remote hold" to user B and remains in the Active call state.DefaultDF69901(1)ConfigurationComments9.2.1validoptional Nr| Label| BEHAVIOUR DESCRIPTION| CREF| V| COMMENTS1||+PR31002|||preamble N102|| |NO20(CREF1,hold_NID)||3||
L0?NOTIFYr|A_NO20(CREF1,hold_NID)|(P)|4||
+CS59901(10,1)|||check N105||
?TIMEOUT TWAIT||(I)|6||
+PO49901(1)|||postamble N0DETAILED COMMENTS:5Untestable test purposesThere are no untestable test cases associated with this ATS and ATM.SIST EN 300 093-6 V1.2.4:2003

ETSIEN 300 093-6 V1.2.4 (1998-06)116ATS conventionsThis clause is structured similarly to the structure of a TTCN ATS. However, the names of the subclauses are arranged ina way 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.6.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 inthat 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 information elementidentifiers are represented as unrestricted types can present difficulties for a derived test system in the case where itneeds to find one information element embedded in a number of others and the constraints for the other elements have theany-or-omit value. In such 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 two major reasons. First, types defined in ASN.1 can model problems that "pure" TTCN cannot.For instance, data structures modelling ordered or unordered sequences of data are preferably defined in ASN.1. Second,ASN.1 provides a better restriction mechanism for type definitions by using sub-type definitions.The fact that ASN.1 provides a better restriction mechanism for type definitions is used for the purpose of achieving type-compatibility.In table 3 the ASN.1 type BIT7OR15 is defined as being of type BIT STRING with a size constraint attached to it. Thesize is determined by the value of CR_LENGTH, a test suite parameter. It can have the value of either 7 or 15. The typeBIT7OR15 is used in the structured type CR, field cr_r allowing this type to represent a basic access or a primary rateaccess call reference. By using this type definition the field cr_r is always type compatible with values of typeBIT STRING (SIZE(7)) and BIT STRING (SIZE(15)). Another approach to solve this problem would be to define thetype BIT7OR15 as BIT 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.SIST EN 300 093-6 V1.2.4:2003

ETSIEN 300 093-6 V1.2.4 (1998-06)12Table 3: ASN.1 type definition BIT7OR15ASN.1 Type DefinitionType Name : BIT7OR15Comments
:Type DefinitionBIT STRING(SIZE(CR_LENGTH))Table 4 shows a typical use of ASN.1. The CHI element will have two different type definitions depending on whether itrepresents basic or primary rate access. In TTCN, this shall be defined as two different types. In ASN.1 this can be donein one, the type being a choice of either BASIC_CHI or PRIMARY_CHI. These two types are then (locally) defined in thesame table.Table 4: ASN.1 type definition CHIASN.1 Type DefinitionType Name : CHIComments
: Info Element Channel Identification
EN 300 403-1 subclause 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}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.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 type and a PDUtype is one-to-one. That is, there exists one ASP type definition for each PDU type definition (if that ASP type contains aPDU).All TTCN ASP type definitions are provided with a full identifier.Some ASPs are not parameterized as shown in the example in table 5. Such ASPs are only used for requesting orreceiving service from the lower layer.Table 5: 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 6 shows an example of a parameterized ASP. All ASPs containing PDUs contain only that PDU and no otherparameters.SIST EN 300 093-6 V1.2.4:2003

ETSIEN 300 093-6 V1.2.4 (1998-06)13Table 6: 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 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 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 type is used when itis necessary to attach restrictions to these type definitions (it is not allowed to include restrictions directly in the test suiteparameter 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.6.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.SIST EN 300 093-6 V1.2.4:2003

ETSIEN 300 093-6 V1.2.4 (1998-06)146.1.5Test suite operation definitionsThe description part of a test suite operation definition uses either natural language or meta C.Table 7: 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 identificationinformation
element to PDUs dependent on the type of access that is tested.Description{if(basic_flag)
return basic;else
return primary}Detailed comments :The test suite operation definition shown in table 7 is used in the constraints part when assigning an element of type CHI avalue. As previously described, the CHI type can be defined in two ways depending on whether the ATS is testing basicor primary rate access. To avoid duplicate types and thereby duplicate test cases the CHI type is defined in ASN.1. Thisoperation is used to assign a value to an element of CHI type. It takes three parameters: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 declarationConstraints of this type are used to assign the corresponding type a specific value. These constraints are used for thepurpose of modelling unordered data or specific types that cannot be expressed in TTCN.6.2.2.1Specification of encoding rulesAll ASN.1 constraints contained in this ATS are encoded according to ISDN, i.e. the ASN.1 data types are arepresentation of structures contained within the ISDN specification (basic call, Generic functional protocol or individualsupplementary service). For example, if octets of an information element are specified in ASN.1 as a SEQUENCE thenthis should be encoded in an Executable Test Suite (ExTS) as any other ISDN information element specified using tabularTTCN. Encoding associated with the Basic Encoding Rules (BER), as specified in CCITT Recommendation X.209 [11],should not be applied to any of the ASN.1 constraints specified in this ATS.6.2.3ASP type constraint declaration6.2.3.1ASN.1 ASP type constraint declarationNo ASN.1 ASP type constraint declarations exist in this ATS.SIST EN 300 093-6 V1.2.4:2003

ETSIEN 300 093-6 V1.2.4 (1998-06)156.2.3.2TTCN ASP type constraint declarationFor TTCN ASP constraint declarations there is a one-to-one relationship between its type and the constraint. That is, thereis only one constraint for each TTCN ASP Type Declaration. The reason for this is that the ASPs are used only forcarrying a specific PDU value. The many ASP constraints (and types) could have been avoided by using the meta typePDU, but that was not suitable as values inside a specific PDU have to be referenced. To reference elements inside avalue of meta type PDU is not allowed according to ISO/IEC 9646-3 [7], so each ASP has to be defined as having aparameter of a specific PDU type.In all ASP constraints the embedded PDU constraint is either chained static or "semi-dynamic". That is, the PDUconstraint 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.4PDU type constraint declaration6.2.4.1ASN.1 PDU type constraint declarationNo ASN.1 PDU type constraint declaration exists in this 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.5Chaining of constraints6.2.5.1Static chainingStatic chaining, that is a fixed reference to a specific constraint, is used in this ATS. The static chaining is used for staticbinding of both variables and sub-structures.6.2.5.2Dynamic chainingDynamic 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 thefixed reference is parameterized with an unknown value. That value is received as a parameter.Table 8: TTCN ASP constraint declaration A_RST1TTCN ASP Constraint DeclarationConstraint Name : A_RST1(FLAG : INTEGER)ASN.1 Type
: DL_DAT_IN_RESTARTrDerivation Path :Comments
:Parameter NameParameter ValueCommentsmunRST1(FLAG)RST1(FLAG)Detailed comments :Table 8 is an example of semi-dynamic chaining. The TTCN ASP constraint is parameterized with an INTEGER valuenamed FLAG. That value is passed further down in the structure as a parameter to a static named PDU constraintreference.6.2.6Derived constraintsNo derivation of any constraints is used. All constraints are considered to be base constraints.6.2.7Parameterized constraintsParameterized constraints are used in this ATS.SIST EN 300 093-6 V1.2.4:2003

ETSIEN 300 093-6 V1.2.4 (1998-06)166.2.8Value assignment6.2.8.1Specific valuesFor specific value assignment both explicit values and references to explicit values are used.6.2.8.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 300 093-5 [4]. To be able to read and understand the test casedynamic behaviour it is recommended that the test steps are understood first.6.3.2Test steps6.3.2.1PTC1_INThis test step describes the behaviour of the PTC1 for support of an incoming call at the MTC (served user side). ThusPTC1 is the originator of the call. The PTC1 receives a CM from the MTC in order to send the SETUP message whichbegins the call establishment. The test step is terminated by receipt of a RELEASE message or by appropriate CM fromthe MTC.6.3.2.2PTC1_OUTThis test step describes the behaviour of the PTC1 for support of an outgoing call at the MTC (served user side). ThusPTC1 is at the destination side of the call. The test step is terminated by receipt of a RELEASE message or by appropriateCM from the MTC.The behaviour is regulated from the MTC by means of CMs sent via CPA1 co-ordination point. Thus if the PTC isexpected to receive a message it receives a CM beforehand telling it what message to expect. On the other hand if theMTC wishes to receive a message from the IUT it may do this by first sending a CM to PTC1. Depending on the contentsof the CM PTC1 may then send a message to the IUT eventually provoking the IUT to send a message at the side of theMTC.6.3.3DefaultsNote the use of the RETURN statement which is defined in DAM1 of ISO/IEC 9646-3 [7]. This allows valid backgroundbehaviour to be handled in the default tree with a possibility to return to the original set of alternatives in the test case.SIST EN 300 093-6 V1.2.4:2003

ETSIEN 300 093-6 V1.2.4 (1998-06)177ATS 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 [9], toproduce a PCTR conformant with the PCTR template given in annex B of ISO/IEC 9646-5 [9].Furthermore, a test laboratory, offering testing for the ATS specification contained in annex C, when requested by a clientto produce a PCTR, is required to produce a PCTR conformant with the PCTR proforma contained in annex A of thepresent document.A PCTR which conforms to this PCTR proforma specification shall preserve the content and ordering of the clausescontained in annex A. Clause A.6 of the PCTR may contain additional columns. If included, these shall be placed to theright of the existing columns. Text in italics may be retained by the test laboratory.9PIXIT conformanceA test realizer, producing an executable test suite for the ATS specification contained in annex C, is required, as specifiedin ISO/IEC 9646-4 [8], to produce an augmented partial PIXIT proforma conformant with this partial PIXIT proformaspecification.An augmented partial PIXIT proforma which conforms to this partial PIXIT proforma specification shall, as a minimum,ha
...