ETSI EN 301 934-2 V1.1.1 (2003-01)
Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Abstract Test Suite (ATS) and Partial Protocol Implementation eXtra Information for Testing (PIXIT) proforma specification; Part 2: Call Party Handling (CPH)
Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Abstract Test Suite (ATS) and Partial Protocol Implementation eXtra Information for Testing (PIXIT) proforma specification; Part 2: Call Party Handling (CPH)
DEN/SPAN-120063-4-2
Inteligentno omrežje (IN) – Tretji nabor zmožnosti inteligentnega omrežja (CS3) – Abstraktni preskušalni niz (ATS) in delna dodatna informacija za preskušanje izvedbe protokola (PIXIT) – Proforma specifikacija – 2. del: Ravnanje z udeležencem klica (CPH)
General Information
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Inteligentno omrežje (IN) – Tretji nabor zmožnosti inteligentnega omrežja (CS3) – Abstraktni preskušalni niz (ATS) in delna dodatna informacija za preskušanje izvedbe protokola (PIXIT) – Proforma specifikacija – 2. del: Ravnanje z udeležencem klica (CPH)Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Abstract Test Suite (ATS) and Partial Protocol Implementation eXtra Information for Testing (PIXIT) proforma specification; Part 2: Call Party Handling (CPH)33.040.35Telefonska omrežjaTelephone networksICS:Ta slovenski standard je istoveten z:EN 301 934-2 Version 1.1.1SIST EN 301 934-2 V1.1.1:2005en01-januar-2005SIST EN 301 934-2 V1.1.1:2005SLOVENSKI
STANDARD
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 2
Reference DEN/SPAN-120063-4-2 Keywords ATS, CS3, CTM, IN, INAP, PIXIT, TTCN ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00
Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88
Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, send your comment to: editor@etsi.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2003. All rights reserved.
DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTM and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. SIST EN 301 934-2 V1.1.1:2005
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 3
Contents Intellectual Property Rights.5 Foreword.5 1 Scope.6 2 References.6 3 Definitions and abbreviations.7 3.1 Definitions.7 3.2 Abbreviations.7 4 Test architecture.8 4.1 Abstract Test Method (ATM).8 4.2 Overall configuration.8 4.3 Test of SSF-SCF interface using INAP.9 4.4 Points of control and observation (PCOs).9 4.5 Test system.9 4.6 Functional configurations.10 4.6.1 SSF-SCF interface.10 4.6.2 Reference to product implementation.11 4.7 Protocol primitives.11 4.7.1 Protocol primitives at PCO_1 and PCO_2.11 4.7.2 Protocol primitives at PCO_3_1 and PCO_3_2.12 5 ATS naming conventions.13 5.1 Declarations part.13 5.1.1 Test suite type and structured type definitions by reference.13 5.1.2 Test suite operations definitions.13 5.1.3 Test suite parameter declarations.13 5.1.4 Test case selection expression definitions.13 5.1.5 Test suite constant declarations by reference.13 5.1.6 Test suite variable declarations.13 5.1.7 Test case variable declarations.14 5.1.8 Timer declarations.14 5.1.9 ASP type definitions.14 5.1.10 Alias definitions.14 5.2 Constraints part.14 5.3 Dynamic part.15 5.3.1 Test case identifier.15 5.3.2 Preambles and their naming conventions.15 5.3.3 Postamble identifier.16 6 Implementation conventions.16 6.1 TC and TP mapping.16 7 ATS generalities.16 7.1 ATS design.16 7.1.1 Methodology.16 7.2 Test Configuration.18 7.2.1 Example.19 7.3 ATS restrictions.19 Annex A (normative): ATS for INAP CS3 Call Party Handling.20 A.1 The TTCN Graphical form (TTCN.GR).20 A.2 The TTCN Machine Processable form (TTCN.MP).20 Annex B (normative): Partial PIXIT proforma for INAP CS3 CPH.21 SIST EN 301 934-2 V1.1.1:2005
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 4
B.1 Identification summary.21 B.2 ATS summary.21 B.3 Test laboratory.21 B.4 Client identification.21 B.5 SUT.22 B.6 Protocol layer information.22 B.6.1 Protocol identification.22 B.6.2 IUT information.22 B.6.2.1 Implicit send events.22 B.6.2.2 PICS and PIXIT Values required by the ATS.23 Annex C (normative): Protocol Conformance Test Report (PCTR) proforma for INAP INAP CS3 CPH.27 C.1 Identification summary.27 C.1.1 Protocol conformance test report.27 C.1.2 IUT identification.27 C.1.3 Testing environment.27 C.1.4 Limits and reservation.28 C.1.5 Comments.28 C.2 IUT conformance status.28 C.3 Static conformance summary.28 C.4 Dynamic conformance summary.29 C.5 Static conformance review report.29 C.6 Test campaign report.29 C.7 Observations.34 Annex D (informative): Bibliography.35 History.36
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 5
Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http://webapp.etsi.org/IPR/home.asp). All published ETSI deliverables shall include information which directs the reader to the above source of information. Foreword This European Standard (Telecommunications series) has been produced by ETSI Technical Committee Services and Protocols for Advanced Networks (SPAN). The present document is part 2 of a multi-part deliverable. Full details of the entire series can be found in part 1 [3].
National transposition dates Date of adoption of this EN: 27 December 2002 Date of latest announcement of this EN (doa): 31 March 2003 Date of latest publication of new National Standard or endorsement of this EN (dop/e):
30 September 2003 Date of withdrawal of any conflicting National Standard (dow): 30 September 2003
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 6
1 Scope The present document contains the Abstract Test Suite (ATS) and Partial PIXIT for Call Party Handling (CPH), part of CoreINAP CS-3. The present document provides the Abstract Test Suite (ATS) and Partial PIXIT for the testing of the Call Party Handling (CPH) operations of the Service Switching Function (SSF), defined for the Intelligent Network Application Protocol (INAP) of Intelligent Network (IN) Capability Set 3 (CS3) according to ETSI EN 301 931-1 [1] and ETSI EN 301 931-2 [2]. Annex A provides the Tree and Tabular Combined Notation (TTCN). Annex B provides the Partial Protocol Implementation eXtra Information for Testing (PIXIT) Proforma. Annex C provides the Protocol Conformance Test Report (PCTR) Proforma. The present document is completed by other parts constituting the testing of the CS3 Core INAP specifications: ETSI EN 301 934-1 [3] (Basic capability set of CS-3). ISO/IEC 9646-1 [4] and ISO/IEC 9646-2 [5] are used as the basis for the testing methodology. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. • References are either specific (identified by date of publication and/or edition number or version number) or non-specific. • For a specific reference, subsequent revisions do not apply. • For a non-specific reference, the latest version applies. Referenced documents which are not found to be publicly available in the expected location might be found at http://docbox.etsi.org/Reference. [1] ETSI EN 301 931-1: "Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Protocol specification; Part 1: Common aspects". [2] ETSI EN 301 931-2: "Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Protocol specification; Part 2: SCF-SSF interface". [3] ETSI EN 301 934-1: "Intelligent Network (IN); Intelligent Network Capability Set 3 (CS-3); Abstract Test Suite (ATS) and Partial Protocol Implementation eXtra Information for Testing (PIXIT) proforma specification; Part 1: Basic capability set of CS3". [4] ISO/IEC 9646-1: "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts". [5] ISO/IEC 9646-2: "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 2: Abstract Test Suite specification". [6] ISO/IEC 9646-3: "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 3: The Tree and Tabular Combined Notation (TTCN) ". [7] ETSI ETS 300 374-1: "Intelligent Network (IN); Intelligent Network Capability Set 1 (CS1); Core Intelligent Network Application Protocol (INAP); Part 1: Protocol specification". [8] ITU-T Recommendation Q.771: "Functional description of transaction capabilities". SIST EN 301 934-2 V1.1.1:2005
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 7
3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions defined in ETSI EN 301 931-1 [1], ISO/IEC 9646-1 [4] and ISO/IEC 9646-2 [5] apply. 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: ASP Abstract Service Primitive ATM Abstract Test Method ATS Abstract Test Suite BI Invalid Behaviour tests BO Inopportune Behaviour tests BV Valid Behaviour tests CS Call Segment CS Capability Set IN Intelligent Network INAP Intelligent Network Application Protocol IP Intelligent Peripheral IUT Implementation Under Test LE Local Exchange
LT Lower Tester
MPyT Multy Party Testing
MSC Message Sequence Chart NWK NetWork Layer PCO Point of Control and Observation PDU Protocol Data Unit PICS Protocol Implementation Conformance Statement PIXIT Protocol Implementation eXtra Information for Testing SAP Service Access Point SCF Service Control Function SCP Service Control Point SDF Service Data Function SDL Specification and Description Language SRF Specialized Resource Function SSF Service Switching Function SSP Service Switching Point SUT System Under Test TC Test Case TCAP Transaction Capabilities Application Part TE Transit Exchange
TP Test Purpose TSS Test Suite Structure TTCN Tree and Tabular Combined Notation SIST EN 301 934-2 V1.1.1:2005
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 8
4 Test architecture 4.1 Abstract Test Method (ATM) This clause describes the ATM used for testing the INAP protocol. It is the embedded variant of the remote test method used in Multy Party Testing (MPyT) context, as defined in ISO/IEC 9646-2 [5]. This test method has been selected, because: - this test method implies no specific requirements from the Implementation Under Test (IUT); - the upper Service Access Point (SAP) of the IUT cannot be directly observed; - this test method places minimum limitations in the realization of conformance testing. 4.2 Overall configuration Figure 1 describes the test architecture which will be used for the definition of the ATS. A single test architecture covers all testing configuration requirements. Test Co-ordination and main test programLT1LT2PCO_1PCO_2Protocols PzPzPmPnIUTLT3_1LT3_2PCO_3_1PCO_3_2Protocols PnProtocols Pm Figure 1: Multi-party, single-layer testing context: one IUT and 4 types of LTs Figure 1 shows the multi-party, single layer testing context. The same architecture can be used for testing several interfaces. The roles of IUT and LTs change according to the protocol to be tested in the IUT. Table 1 gives the nature of the IUT and LTs according to the protocol under test. Table 1: possible testing configurations Test Config Tested Interface IUT LT1 LT2 LT3_1 LT3_2 Functional Configuration 1 SSF-SCF SSF SCF SRF Sig con A Sig con B A 2 SSF-SCF SSF SCF - Sig con A Sig con B B
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 9
4.3 Test of SSF-SCF interface using INAP The test program contains the program of the main LT1 main tester as well as the co-ordination points to co-ordinate the tasks with the other testers LT2 and LT3. IUT: Is the SSF-INAP. LT1: Test program is the SCF. LT2: Test program is the SRF-INAP when required. LT3: Informal test program for actions and observation at the signalling control points, to play the role of end users A,
B and C for instance.
There are as many LT3 as required by the test configuration (LT3_1, LT3_2, etc.) according to the number of
end users A, B and C involved in a service scenario for instance, using different types of protocols). Pz: Contains the protocols used below the INAP between SCP and SSP, also between SSP and SRF. They could be
e.g. TCAP, SCCP and MTP of SS7 etc. Pm: Contains the protocols used below the LT3_1 between the IUT and the Signalling control point. It could be the
DSS1 protocols or ISUP SS7 protocol (in the case of having a transit exchange). Pn: Contains the used protocols below the LT3_2 between the IUT and the Signalling control point. It could be the
DSS1 protocols or ISUP SS7 protocol (in the case of having a transit exchange). 4.4 Points of control and observation (PCOs) PCO-Declarations. 1) PCO_1:
This PCO is at the core INAP interface between SSP and SCP. The lower layer protocol is Pz. It could be e.g. TCAP. 2) PCO_2:
This PCO is at the core INAP interface between SSP and SRF. The lower layer protocol is Pz. It could be e.g. TCAP, ISUP, B-ISUP, TUP or the NWK of DSS1. 3) PCO_3_1: This PCO is at the interface between SSP and Signalling Control A. The lower layer protocol is Pm. It could be e.g. ISUP, B-ISUP, TUP or the NWK of DSS1. 4) PCO_3_2: This PCO is at the interface between SSP and Signalling Control B. The lower layer protocol is Pn. It could be e.g. ISUP, B-ISUP, TUP or the NWK of DSS1. 4.5 Test system It is expected that the test system supports the protocols Pz, Pz-1, Pz-2 and the protocols for Pm and Pn. It is expected that the test system supports the PCO Requirements of PCO_1, PCO_2, PCO_3_1 to PCO_3_n. SIST EN 301 934-2 V1.1.1:2005
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 10 4.6 Functional configurations 4.6.1 SSF-SCF interface SCPSSPIPNon-integrated SRFSCFSSFCCFSRFSDF Figure 2: SCP with single SSP Configuration A: IUT = SSF (non integrated with SRF) SCPSSPIntegrated SRFSCFSSFCCFSRFSDF Figure 3: SCP with single SSP Configuration B: IUT = SSF (integrated with SRF) SIST EN 301 934-2 V1.1.1:2005
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 11 4.6.2 Reference to product implementation The SUT can either be a Local Exchange (LE) or a Transit Exchange (TE). The exact number of testers (LT3 alone or LT3_1 and LT3_2) will depend upon the type of exchange and the configuration of the exchange, as explained by the following examples of implementation. SCPSRFParty AParty CParty BINAPDSS1 or ISUPSSFLESUTISUPISUPTELEDSS1DSS1 Figure 4: Configuration with Local Exchange as SUT Figure 4 shows a configuration where the SUT is a Local Exchange. In this case, signalling of a call may be done either with DSS1 and ISUP (A and B involved) or only with DSS1 (A and C involved).
SCPSRFParty AParty CParty BINAPDSS1 or ISUPSSFLESUTISUPISUPTELEDSS1DSS1 Figure 5: Configuration with Transit Exchange as SUT Figure 5 shows a configuration where the SUT is a Transit Exchange. In this case, signalling uses ISUP protocol only.
4.7 Protocol primitives 4.7.1 Protocol primitives at PCO_1 and PCO_2
The transmission of INAP messages at the interface between SCF and SSF or SSF and SRF uses TCAP primitives. The LT1, LT2 communicate with the lower protocols via the SAPs with the TCAP-primitives shown in tables 2 and 3 according to clause 10 of ETS 300 374-1 [7] and ITU-T Recommendation Q.771 [8]. SIST EN 301 934-2 V1.1.1:2005
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 12 Table 2 Primitives for dialogue handling Abstract Service Primitive Type TC_BEGIN Request or Indication TC_CONTINUE Request or Indication TC_END Request or Indication TC_U_ABORTa Request or Indication TC_U_ABORTb Request or Indication TC_P_ABORTa Indication TC_P_ABORTb Indication TC-NOTICE Indication
Table 3 Primitives for components handling Abstract Service Primitive Type TC_INVOKE Request or Indication TC_U_ERROR Request or Indication TC_U_REJECT Request or Indication TC_L_REJECT Indication TC_R_REJECT Indication TC_U_CANCEL Request or Indication
4.7.2 Protocol primitives at PCO_3_1 and PCO_3_2 In order to be protocol independent, a set of primitives is defined at this interface, and the next table is an example of the mapping between this generic interface and the possible signalling protocols like ISUP and DSS1.
Here follows the list of these primitives for the generic interface and a table giving the mapping of the generic primitives into real protocols. Table 4 Mapping table for the interface between SSP and signalling control point PCO_3-1 or 3-2 interface primitives Type if ISUP used if DSS1 used Setup Indication Request Response Confirm IAM
ANM Setup
Answer Release Request Indication REL/RLC Disconnect SubsequentAddress Request Indication SAM Information AddressEnd Request Indication SAM Information CallProgress Request Indication ACM, CPG Progress, Alerting ServiceFeature Request Indication ? Facility
NetworkSuspend Request Indication SUSPEND -- NetworkResume Request Indication RESUME --
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 13 5 ATS naming conventions This clause describes the conventions applied to define the ATS and gives the naming conventions chosen for the different elements of the ATS. The ATS conventions are intended to give a better understanding of the ATS but they describe also the conventions made for the development of the ATS, thus for any later maintenance purposes or further development of the ATS, the conventions described in this clause shall be considered. 5.1 Declarations part This clause describes the naming conventions chosen for the elements of the ATS declarations part. 5.1.1 Test suite type and structured type definitions by reference In order to avoid misalignment problems with the base IN CS-3 standard, all the ASN.1 types used in this ATS which are defined as types in the base standard have been imported by reference to the ASN.1 types in the base standard.
Where an imported type originally contained the dash ("-") character, it is replaced by an underscore ("_") in the type as imported. 5.1.2 Test suite operations definitions The test suite operation identifiers are composed of strings in uppercase letters starting with the uppercase string "TSO_". The different strings in the definition are separated with underscores. 5.1.3 Test suite parameter declarations The test suite parameter identifiers are composed of strings starting by the uppercase string "PX_" and separated by underscores. EXAMPLE: PX_CalledPartyNumber_1 Complete names as defined in the specifications are used. 5.1.4 Test case selection expression definitions The naming conventions for the test case selection expression definitions use free text starting with an uppercase letter. The name of the expression is intended to explain clearly the selection rule. The test case selection expressions are generally logical combinations of the test suite parameter definitions. 5.1.5 Test suite constant declarations by reference In order to avoid misalignment problems with the base IN CS-3 standard, all the ASN.1 constants used in this ATS which are defined as constants in the base standard have been imported by reference to the ASN.1 constants in the base standard.
Where an imported constant originally contained the dash ("-") character, it is replaced by an underscore ("_") in the type as imported. 5.1.6 Test suite variable declarations The test suite variable identifiers are composed of strings starting with the uppercase string "TSV_". EXAMPLE: TSV_DialogID1 If the test suite variable represents a system parameter or value, the name defined in the specifications is used. SIST EN 301 934-2 V1.1.1:2005
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 14 5.1.7 Test case variable declarations The test case variable identifiers are composed of strings starting with the uppercase string "TCV_". EXAMPLE: TCV_InvokeID1 5.1.8 Timer declarations Two kinds of timers are distinguished: 1) standardized:
Those defined in the standard, e.g. T_ssf, use the same name as in the standard, beginning with a capital "T". As there is a tolerance margin accepted for these timers, two values are needed: - the maximum value allowed, which uses the suffix "_Max"; - the minimum value allowed, which uses the suffix "_Min". EXAMPLE 1: T_ssf_Min, T_ssf_Max 2) non-standardized:
Those not defined in the standard, i.e. for execution use, e.g. a timer waiting for a response. These timers begin with the prefix "T_". EXAMPLE 2: T_Response
T_NoResponse 5.1.9 ASP type definitions ASP definitions follow the specification when a corresponding definition exists. If not, a free text name is used. EXAMPLE: TC_BeginInd 5.1.10 Alias definitions No alias definitions are used in the test suite. 5.2 Constraints part This clause describes the naming conventions chosen for the elements of the ATS constraints part. Constraint identifiers commence with uppercase "C_".
Table 5 Type Definition Constraint Definition Example TC_InvokeInd(IDP) C_InvI_InitialDP TC_InvokeReq(RRBE) C_InvR_RequestReportBCSMEvent TC_ErrorInd C_TC_ErrorInd TC_ErrorReq C_TC_ErrorReq TC_BeginInd(/Req) C_TC_BeginInd(/Req) TC_ContinueInd(/Req) C_TC_ContinueInd(/Req) TC_EndInd(/Req) C_TC _EndInd(/Req) TC-AbortInd C_TC_AbortInd
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 15 5.3 Dynamic part This clause describes the naming conventions chosen for the elements of the ATS dynamic part. 5.3.1 Test case identifier The identifier of a Test Case (TC) is identical to the corresponding Test Purpose, as described in table 6. Table 6: TC naming convention
Identifier: IN3_____
IN3
indicates IN Capability Set 3
= interface: A SSF-SCF interface
B SSF-SRF interface
C SCF-SCF interface
= common set BASIC Basic set for CS3
CPH Call Party Handling from Capability Set 3
SRF SRF-related functions from Capability Set 3
= procedure name such as
SF ServiceFiltering
= test category: BV Valid Behaviour tests
BI Invalid Behaviour tests
BO Inopportune Behaviour tests
= sequential number:
(01-99) Example of test case name: IN3_A_BASIC_SF_BV_02
5.3.2 Preambles and their naming conventions Preambles are used to bring the IUT from the initial state to the state where the test takes place. In the CS3 scheme, the set of the preambles forms a tree, which means that in order to reach the state created by preamble P3, it is necessary to execute preamble P1 followed by preambles P2 then P3. The naming convention used reflects the description of the connection view set by executing the preamble, in terms of nature of the legs per Call Segment (CS), starting from the stable legs then the ones on hold then the ones in transfer, with the indication of the number of legs, while the first letter indicates how this configuration was initiated. The general form is: a_[stableLegsParty or onHold (legs) or transfer(legs) for CallSegment 1]_[idem for CallSegment2]_[idem for CallSegment 3] where: a is letter: O for Originating (outgoing call for a user); T for Terminating (incoming call for a user); I for Initiate Call Attempt (initiated from the network). SIST EN 301 934-2 V1.1.1:2005
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 16 The state names and their abbreviations used are:
Null
1_Party 1P
Originating_Set-up OS
Terminating_Set-up TS
Originating_ 1_Party_Setup O1PS
Stable_1_Party S1P
Stable_2_Party S2P
Forward FW
Stable_Multi_Passive_Party (no. of passive legs n) SnPP
Stable_Multi_Party (no. of passive legs n) SnP The term "null" stands for "none" as in preamble O_NULL_S2P_OH3. There can be two set of CSs with the same nature of legs present at the same time, as in the preamble name O_S2P_S1P_S1P. 5.3.3 Postamble identifier Postambles are used to bring the IUT from the state where the test takes place back to the initial state. CPH is using a ReleaseAll postamble, applying to the number of legs/call references still being active in the call, from 1 up to 8. The SCF sends a ReleaseCall operation and the IUT sends ReleaseReq on the legs that are active. The names of the Release postambles indicate the numbers of the legs where the release of the associated signalling connection applies (in any stage of the connection). E.g. ReleaseAll_3 means that the signalling connections associated with legs 1, 2 and 3 (SigCon A, B and C) have to be released. Release_234 means that the signalling connections associated with legs 2, 3 and 4 (SigCon B, C and D) have to be released. 6 Implementation conventions Fully functional underlying TCAP protocol is assumed from the test system. Fully Functional underlying MTP-3/ISDN protocol is assumed from the test system. 6.1 TC and TP mapping There is a one-to-one mapping between the TC identifiers and the TP identifiers.
7 ATS generalities 7.1 ATS design This ATS has been produced according to methodology based on the use of formal languages (SDL, ASN.1, TTCN). Starting from the protocol description and using a powerful software environment, the TTCN test cases were generated automatically according to the test purpose description. 7.1.1 Methodology The methodology that has been used to produce the ATS tries to integrate the specification of a protocol and the definition of the conformance testing related to that protocol. Several stages integrating the whole process of testing and specification can be identified. In each stage a different formal language applies. Figure 6 shows the different steps followed to achieve the ATS generation. SIST EN 301 934-2 V1.1.1:2005
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 1nCS3
Description
SDL
ASN.1
SIMULATION
Validation&
Feedback
Test
Purposes
MSC
TTCN
ATS
TTCN
SDL Simulator
SDL Editor
VALIDATOR&
AUTOLINK
TRANSLATION
Figure 6: Steps in the generation of the ATS • SIMULATION The SDL formal description of INAP CS3 is taken as an input for this stage. The formal description of the protocol includes not only the SDL model but ASN.1 type definitions. Simulation of the model allows improvement of the SDL system description (Validation & Feedback). Once the model is validated, it is possible to simulate the test purposes against the model; for each simulated test purpose an MSC is obtained. These MSCs show the message exchange between the different interfaces involved in the description of the test purpose. • TRANSLATION The MSCs obtained from the model simulation are used in this stage to generate the TTCN test cases. Using the SDL INAP CS3 model and the MSCs (obtained from simulation) as inputs, the complete ATS is generated. As the SDL model does not include the whole protocol specification, some MSCs shall be defined manually to complement those obtained from the model simulation. The error handling and some operator specific procedures description are not included in the model. The MSCs designed by hand were translated to TTCN test cases using the same tool as for the MSCs obtained from simulation. SIST EN 301 934-2 V1.1.1:2005
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 18 7.2 Test Configuration When the IUT is considered to be an SSP the signalling protocol interaction should be taken into account. Some of the INAP CS3 operations have influence on the signalling scheme. The coordination of the message sequences on the different signalling interfaces is performed using a TTCN concurrent test configuration. Figure 7 shows the test configuration; test components, LTs, PCOs, etc. adopted for the CS3 test suites.
MTC: LT1 P T C P T C PCO:SCF PCO: SignallingA PCO: SignallingB SigconA SigconB P T C SigconC P T C SigconD CP CP CP CP LT3_1 LT3_2 LT3_3 LT3_4 SUT SSP
Figure 7 Each time a test case starts from the Master Test Component (MTC) some different behaviour trees are started at the corresponding PTCs (Parallel Test Component). The trees running at the PTC's control the signalling interfaces between the test device and the SUT (System Under Test). In order to co-ordinate the behaviour between the INAP interface and the signalling interfaces (SignallingA, SignallingB, etc.) the MTC uses some co-ordination messages through CPs (Co-ordination Point). SIST EN 301 934-2 V1.1.1:2005
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 19 7.2.1 Example The abstract signalling primitives used in the SDL model to reflect the Call Control Functionality of the SSP become co-ordination messages between the MTC and the several PTCs. A mapping between the abstract signalling primitives and the real signalling messages is done at the PTCs. As the real signalling procedures are protocol and network dependent, no parallel behaviour trees are included in the ATS. An example of how to introduce the parallel signalling behaviour trees is shown in figure 8. SigconA! SetupInd
SCF? TC_BeginInd
SCF? TC_InvokeInd(IDP)
SCF! TC_InvokeReq(RRB)
SCF! TC_InvokeReq(CON)
SCF! TC_ContinueReq
SigconB? SetupReq
SigconB! SetupConf
SigconA? SetupResp
SCF! TC_InvokeReq(RC)
SCF! TC_EndReqBasic
SigconA? RelReq
SigconB? RelReq
SigconA? SetupInd
SignallingA! SetUp
SignallingA? ANSWER
SigconA! SetupResp
SignallingA? RELEASE
SigconA! RelReqSignallingB? SetUp
SigconB! SetupReq
SigconB? SetupConf
SignallingB! ANSWER
SignallingB? RELEASE
SigconB! RelReqMTC:Test Body behaviour descriptionPTC: Parallel Signalling TreePTC: Parallel Signalling Tree Figure 8 Figure 8 shows a full co-ordination between the INAP interface and the signalling interfaces being done from the MTC test body. The test case takes into account not only the INAP procedures but the signalling procedures.
7.3 ATS restrictions 1) The Abstract Test Suite generated automatically introduces ASN.1 type definitions by reference. All the ASN.1 type definitions are included in several ASN.1 files associated to the ATS. If the ATS user wants to compile the TTCN test cases, either he should ask for a compiling facility to compile type definitions by reference or he should try to have a flat ATS with normal ASN.1 type definitions (cut and Paste between the ATS and the files containing the ASN.1 type definitions). 2) The test cases have been generated automatically from the MSCs, and by so doing, they check for all the possible sequence orders within the test body. 3) The constraint definitions have been generated automatically. 4) For those test cases which use a T_BCSM based preamble, the following DPs need to be armed as TDPs before the start of the test case: analysedInformation on leg 1 on an O_BCSM and termAttemptAuthorized on leg 1 for a T_BCSM. SIST EN 301 934-2 V1.1.1:2005
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 20 Annex A (normative): ATS for INAP CS3 Call Party Handling This ATS has been produced using the Tree and Tabular Combined Notation (TTCN) according to ISO/IEC 9646-3 [6]. The ATS was developed on a separate TTCN software tool and therefore the TTCN tables are not completely referenced in the table of contents. The ATS itself contains a test suite overview part which provides additional information and references. A.1 The TTCN Graphical form (TTCN.GR) The TTCN.GR representation of this ATS is contained in an Adobe Portable Document Format™ file (in3_cph_v013.pdf contained in archive en_30193402v010101p0.ZIP) which accompanies the present document. A.2 The TTCN Machine Processable form (TTCN.MP) The TTCN.MP representation corresponding to this ATS is contained in an ASCII file (in3_cph_v013.mp contained in archive en_30193402v010101p0.ZIP) which accompanies the present document. SIST EN 301 934-2 V1.1.1:2005
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 21 Annex B (normative): Partial PIXIT proforma for INAP CS3 CPH Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that users of the present document may freely reproduce the PIXIT proforma in this annex so that it can be used for its intended purposes and may further publish the completed PIXIT. B.1 Identification summary Table B.1 PIXIT number:
Test laboratory name:
Date of issue:
Issued to:
B.2 ATS summary Table B.2 Protocol specification: EN 301 931 Protocol to be tested:
ATS specification: EN 301 934-2 Abstract test method: Remote test method, embedded variant
B.3 Test laboratory Table B.3 Test laboratory identification:
Test laboratory manager:
Means of testing:
SAP address:
B.4 Client identification Table B.4 Client identification:
Client test manager:
Test facilities required:
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 22 B.5 SUT Table B.5 Name:
Version:
SCS number:
Machine configuration:
Operating system identification:
IUT identification:
PICS reference for IUT:
Limitations of the SUT:
Environmental conditions:
B.6 Protocol layer information B.6.1 Protocol identification Table B.6 Name: EN 301 931 Version:
PICS references:
B.6.2 IUT information B.6.2.1 Implicit send events Table B.7: Implicit send events Item PIXIT (See note) Related implicit send message (PDU) Invocation description 1
NOTE: The PIXIT names for the implicit send events in this table are the same as those of the test steps in which the implicit send events are used.
ETSI ETSI EN 301 934-2 V1.1.1 (2003-01) 23 B.6.2.2 PICS and PIXIT Values required by the ATS Table B.7: Implicit send events Parameter Type PICS/PIXIT Reference Description Value Supported PX_DialogID_1 DialogIDtype
Default: 51
PX_DialogID_2 DialogIDtype
Default: 1
PX_DialogID_4 DialogIDtype
Default: 5
PX_DialogID_5 DialogIDtype
Default: 52
PX_SCF_Address_1 TCoriginType
Default: oSCF
PX_SCF_Address_2 TCoriginType
Default: oSSF
PX_SSF_Address_1 TCoriginType
Default: oSSF
PX_SSF_Address_2 TCoriginType
Default: oSCF
PX_T_Global INTEGER
Global protection timer value in seconds
PX_T_NoAnswer INTEGER
No Answer Timer Value in seconds
PX_RC_Cause Cause
Release Cause sent in ReleaseCall in Postamble
PX_Send_Rel_Cause Cause
Release Cause sent in ReleaseInd in test cases
PX_RSF_Rel_Cause Cause
Release Cause sent to indicate RouteSelectFailure
PX_Busy_Rel_Cause Cause
Release Cause sent to indicate Busy
PX_CalledPartyNumber_1 CalledPartyNumber
1st Called Party Number used in a test case
PX_CalledPartyNumber_2 CalledPartyNumber
2nd Called Party Number used in a test case
PX_CalledPartyNumber_3 CalledPartyNumber
3rd Called Party Number used in a test case
PX_CalledPartyNumber_4 CalledPartyNumber
4th Called Party Number used in a test case
PX_CalledPartyNumber_5 CalledPartyNumber
5th Called Party Number used in a test case
PX_CalledPartyNumber_6 CalledPartyNumber
6th Called Party Number used in a test case
PX_CalledPartyNumber_7 CalledPartyNumber
7th Called Party Number used in a test case
PX_CallingPartyNumber_1 CallingPartyNumber
1st Calling Party Number used in a test case
PX_CSA2_CalledPartyNumber_1 CalledPartyNumber
1st Called Party Number used in a test case in 2nd CSA
PX_CSA2_CalledPartyNumber_2 C
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...