Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Test Suite Structure and Test Purposes (TSS&TP) specification for Service Switching Function (SSF); Part 2: Call Party Handling (CPH)

Conformance Testing for CPH specification.

Inteligentno omrežje (IN) – Tretji nabor zmožnosti inteligentnega omrežja (CS3) – Aplikacijski protokol inteligentnega omrežja (INAP) – Zgradba preskušalnega niza in namen preskušanja (TSS&TP) – Specifikacija za funkcijo komutacije storitev (SSF) – 2. del: Ravnanje z udeležencem klica (CPH)

General Information

Status
Published
Publication Date
31-Dec-2004
Current Stage
6060 - National Implementation/Publication (Adopted Project)
Start Date
01-Jan-2005
Due Date
01-Jan-2005
Completion Date
01-Jan-2005
Standard
SIST EN 301 933-2 V1.1.1:2005
English language
478 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

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) – Aplikacijski protokol inteligentnega omrežja (INAP) – Zgradba preskušalnega niza in namen preskušanja (TSS&TP) – Specifikacija za funkcijo komutacije storitev (SSF) – 2. del: Ravnanje z udeležencem klica (CPH)Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Test Suite Structure and Test Purposes (TSS&TP) specification for Service Switching Function (SSF); Part 2: Call Party Handling (CPH)33.040.35Telefonska omrežjaTelephone networksICS:Ta slovenski standard je istoveten z:EN 301 933-2 Version 1.1.1SIST EN 301 933-2 V1.1.1:2005en01-januar-2005SIST EN 301 933-2 V1.1.1:2005SLOVENSKI
STANDARD
ETSI ETSI EN 301 933-2 V1.1.1 (2003-01) 2
Reference DEN/SPAN-120063-3-2 Keywords IN, CS3, INAP, TSS&TP, SSF, CTM 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 933-2 V1.1.1:2005

ETSI ETSI EN 301 933-2 V1.1.1 (2003-01) 3
Contents Intellectual Property Rights.6 Foreword.6 1 Scope.7 2 References.7 3 Definitions and abbreviations.8 3.1 Definitions.8 3.2 Abbreviations.8 4 Test Purpose generalities.9 4.1 Introduction.9 4.2 Grouping of Test Purposes per elementary procedures.9 4.3 Source of Test Purpose definitions.9 4.4 Method used for developing TPs.9 4.4.1 Use of MSCs generated by the SDL model of Core INAP CS3.9 4.4.2 TCAP adapter primitives.10 4.4.3 Generation of corresponding Test Cases.10 4.5 Method used for TP description.10 4.5.1 Text and MSCs.10 4.5.2 Test categories.10 4.5.3 Test purpose naming convention.11 4.5.4 Preambles and their naming conventions.11 4.5.5 How to interpret the parameters and their values as used in the MSCs.12 5 Test configuration.13 6 Overview of TSS and TP for CPH functions.14 6.1 Introduction.14 6.2 CPH procedures.14 6.2.1 List of procedures for CPH.14 6.2.2 Definitions of the CPH procedures.14 6.2.2.1 ContinueWithArgument procedure.14 6.2.2.2 ReleaseCall procedure.14 6.2.2.3 SplitLeg procedure.15 6.2.2.4 DisconnectLeg procedure.15 6.2.2.5 MoveLeg procedure.15 6.2.2.6 MergeCallSegments procedure.15 6.2.2.7 CreateCallSegmentAssociation.15 6.2.2.8 MoveCallSegments.15 6.3 Structure of the test suite (TSS) for CPH.15 6.4 Notations.16 6.4.1 Names of preambles and postambles.16 6.4.2 TTCN-like notation for preamble, test case and postamble description.17 6.4.3 Representation of preambles, postambles and Test Purposes using MSCs.17 6.4.4 How to interpret the parameters and their values as used in the MSCs.17 6.4.4.1 General.17 6.4.4.2 INAP operation parameters and their values.18 6.4.4.3 Cause values related to signalling connection release messages.18 6.4.4.4 TCAP operation parameters and their values.18 7 Preambles and postambles for CPH.19 7.1 Preamble descriptions.19 7.1.1 Originating preamble trees.19 7.1.1.1 Preamble O_OS_null_null.19 7.1.1.2 Preamble O_OSA_null_null.19 7.1.1.3 Preamble O_S2P_null_null.20 7.1.1.4 Preamble O_S1P_1P_null.20 SIST EN 301 933-2 V1.1.1:2005

ETSI ETSI EN 301 933-2 V1.1.1 (2003-01) 4
7.1.1.5 Preamble O_S1P_OS_null.20 7.1.1.6 Preamble O_S1P_OSB_null.20 7.1.1.7 Preamble O_S1P_S2P_null.21 7.1.1.8 Preamble O_S1P_S1P_S2P.21 7.1.1.9 Preamble O_null_S2PP_S2P.21 7.1.1.10 Preamble O_null_null_S4P.21 7.1.1.11 Preamble O_null_S2P_S3PP.22 7.1.1.12 Preamble O_null_S1P_S3PP_S2P.22 7.1.1.13 Preamble O_null_S3P_S3PP.22 7.1.1.14 Preamble O_null_S2PP_S3PP_S2P.22 7.1.1.15 Preamble O_null_S4P_S3PP.23 7.1.1.16 Preamble O_null_S3PP_S3PP_S2P.23 7.1.1.17 Preamble O_null_S3P_null.23 7.1.2 Terminating preamble trees.23 7.1.2.1 Preamble T_TS_null_null.23 7.1.2.2 Preamble T_TSA_null_null.23 7.1.2.3 Preamble T_TSB_S1P_null.24 7.1.2.4 Preamble T_S2P_null_null.24 7.1.2.5 Preamble T_1P_FW_null.24 7.1.2.6 Preamble T_S2P_S1P_null.25 7.1.2.7 Preamble T_null_S3P_null.25 7.1.2.8 Preamble T_null_S2PP_S2P.25 7.1.2.9 Preamble T_null_null_S4P.25 7.1.3 InitiateCallAttempt preamble trees.26 7.1.3.1 Preamble I_OS1_null_null.26 7.1.3.2 Preamble I_S1P_null_null.26 7.1.3.3 Preamble I_S1P_S1P_null.26 7.1.3.4 Preamble I_S1P_S1P_S1P.26 7.1.3.5 Preamble I_null_S2PP_S1P.27 7.1.3.6 Preamble I_null_null_S3PP.27 7.1.3.7 Preamble I_null_S2PP_null.27 7.1.3.8 Preamble I_S1P_FW_null.27 7.1.4 Event Detecting/Report rules Preambles.28 7.1.4.1 Preamble O_S2P_null_null_controlling.28 7.1.4.2 Preamble O_S1P_S2P_null_controlling.28 7.1.4.3 Preamble O_null_S3P_null_controlling.28 7.1.4.4 Preamble O_null_S2PP_S2P_controlling.29 7.1.4.5 Preamble O_null_null_S4P_controlling.29 7.1.4.6 Preamble O_S2P_null_null_passive.29 7.1.4.7 Preamble O_S1P_OS_null_passive.29 7.1.4.8 Preamble O_S1P_S2P_null_passive.30 7.1.4.9 Preamble O_null_S3P_null_passive.30 7.1.4.10 Preamble O_null_S2PP_OS_passive.30 7.1.4.11 Preamble O_null_S2PP_S2P_passive.31 7.1.4.12 Preamble O_null_null_S4P_passive.31 7.1.4.13 Preamble I_S1P_S1P_null_passive.31 7.1.4.14 Preamble I_null_S2PP_null_passive.32 7.1.4.15 Preamble T_TS_null_null_controlling.32 7.1.4.16 Preamble T_S2P_null_null_controlling.32 7.1.4.17 Preamble T_S2P_S1P_null_controlling.33 7.1.4.18 Preamble T_null_S3P_null_controlling.33 7.1.4.19 Preamble T_null_S3P_S1P_controlling.33 7.1.4.20 Preamble T_null_null_S4P_controlling.33 7.1.4.21 Preamble T_S2P_null_null_passive.33 7.1.4.22 Preamble T_S2P_O1PS_null_passive.34 7.1.4.23 Preamble T_S2P_S1P_null_passive.34 7.1.4.24 Preamble T_null_S3P_null_passive.34 7.1.4.25 Preamble T_null_S3P_O1PS_passive.35 7.1.4.26 Preamble T_null_S3P_S1P_passive.35 7.1.4.27 Preamble T_null_null_S4P_passive.35 7.1.5 Preambles used together with the second CallSegmentAssociation.35 7.1.5.1 General.35 SIST EN 301 933-2 V1.1.1:2005

ETSI ETSI EN 301 933-2 V1.1.1 (2003-01) 5
7.1.5.2 Preamble CSA2_null.36 7.1.5.3 Preamble CSA2_I_S1P_null_null.36 7.1.5.4 Preamble CSA2_O_S2P_null_null.36 7.1.5.5 Preamble CSA2_O_S1P_S2P_null.36 7.2 Postamble descriptions.37 8 Test Purpose (TP) descriptions for the test of CPH procedures.39 8.1 RequestReportBCSMEvent (RRB) procedure (CPH complement to basic procedure).39 8.2 ContinueWithArgument (CWA) procedure (CPH complement to basic procedure).43 8.3 SplitLeg (SL) procedure.53 8.4 MergeCallSegments (MECS) procedure.95 8.5 ReleaseCall (RC) procedure (CPH complement to basic procedure).159 8.6 DisconnectLeg (DL) procedure.171 8.7 MoveLeg (ML) procedure.203 8.8 CreateCallSegmentAssociation (CCSA) procedure.253 8.9 MoveCallSegments (MOCS) procedure.261 9 Test Purpose (TP) descriptions for the test of mixed call handling capabilities.341 9.1 Originating (O_BCSM) trigger (controlling legID = 1).341 9.2 Terminating (T_BCSM) trigger (controlling legID = 2).381 9.3 Network initiated.391 10 Test Purpose (TP) descriptions for testing arming/detecting rules.403 10.1 Originating (O) trigger.403 10.1.1 Events coming from the controlling leg (legID=1).403 10.1.1.1 All Passive legs are contained in a single Call Segment.403 10.1.1.1.1 Single event from the controlling leg.403 10.1.1.1.2 Multiple events from the controlling leg.407 10.1.1.2 Passive legs are contained in multiple Call Segments.409 10.1.1.2.1 Single event from the controlling leg.409 10.1.1.2.2 Multiple events from the controlling leg.413 10.1.2 Events coming from passive legs (legID= 2,3,4).415 10.1.2.1 Passive legs contained in multiple Call Segments.415 10.1.2.1.1 Single event from a single passive leg.415 10.1.2.1.2 Multiple events from a single passive leg.425 10.1.2.1.3 Multiple events from multiple passive legs in the same call segment.427 10.1.2.2 All Passive legs contained in a single Call Segment.431 10.1.2.2.1 Single event from a single passive leg.431 10.1.2.2.2 Multiple events from a single passive leg.435 10.1.2.2.3 Multiple events from multiple passive legs in the same call segment.437 10.2 Terminating (T) trigger.439 10.2.1 Events coming from the controlling leg (legID=2).439 10.2.1.1 Single event from the controlling leg.439 10.2.1.2 Multiple events from the controlling leg.451 10.2.2 Events coming from passive legs (legID= 1,3,4).459 10.2.2.1 Passive legs contained in multiple Call Segments.459 10.2.2.1.1 Single event from a single passive leg.459 10.2.2.1.2 Multiple events from multiple passive legs in the same call segment.467 10.2.2.2 All Passive legs contained in a single Call Segment.471 10.2.2.2.1 Single event from a single passive leg.471 10.2.2.2.2 Multiple events from a single passive leg.475 Annex A (informative): Bibliography.477 History.478
ETSI ETSI EN 301 933-2 V1.1.1 (2003-01) 6
Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http://webapp.etsi.org/IPR/home.asp). All published ETSI deliverables shall include information which directs the reader to the above source of information. Foreword This European Standard (Telecommunications series) has been produced by ETSI Technical Committee Services and Protocols for Advanced Networks (SPAN). The present document is part 2 of a multi-part deliverable covering the Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Test Suite Structure and Test Purposes (TSS&TP) specification for Service Switching Function (SSF), as identified below: Part 1: "Basic capability set of CS3"; Part 2: "Call Party Handling (CPH)"; Part 3: "Specialized Resource Function (SRF)".
National transposition dates Date of adoption of this EN: 10 January 2003 Date of latest announcement of this EN (doa): 30 April 2003 Date of latest publication of new National Standard or endorsement of this EN (dop/e):
31 October 2003 Date of withdrawal of any conflicting National Standard (dow): 31 October 2003
ETSI ETSI EN 301 933-2 V1.1.1 (2003-01) 7
1 Scope The present document contains the Test Suite Structure and Test Purposes (TSS&TP) for Call Party Handling (CPH), part of CoreINAP CS-3. The present document provides the Test Suite Structure and Test Purposes (TSS&TP) 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 EN 301 931-1 [1] and EN 301 931-2 [2]. The present document is completed by other parts constituting the testing of the CS3 Core INAP specifications: EN 301 931-1 [1] (Call party handling functions) and EN 301 933-3 [6] (Specialized resource functions). ISO/IEC 9646-1 [8] and ISO/IEC 9646-2 [9] 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 931-3: "Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Protocol specification; Part 3: SCF-SRF interface". [4] ETSI EN 301 931-4: "Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Protocol specification; Part 4: SDLs for
SCF-SSF interface". [5] ETSI EN 301 933-1: "Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Test Suite Structure and Test Purposes (TSS&TP) specification for Service Switching Function (SSF); Part 1: Basic capability set of CS3". [6] ETSI EN 301 933-3: "Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Test Suite Structure and Test Purposes (TSS&TP) specification for Service Switching Function (SSF); Part 3: Specialized Resource Function (SRF)". [7] Void. [8] ISO/IEC 9646-1: "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts". SIST EN 301 933-2 V1.1.1:2005

ETSI ETSI EN 301 933-2 V1.1.1 (2003-01) 8
[9] ISO/IEC 9646-2: "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 2: Abstract Test Suite specification". [10] ITU-T Recommendation Q.1224: "Distributed functional plane for intelligent network Capability Set 2". 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: - terms defined in EN 301 931-1 [1]; - terms defined in ISO/IEC 9646-1 [8] and in ISO/IEC 9646-2 [9]. In particular, the following terms defined in ISO/IEC 9646-1 [8] apply: - Abstract Test Suite (ATS); - Implementation Under Test (IUT); - System Under Test (SUT); - Protocol Implementation Conformance Statement (PICS). 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: ATS Abstract Test Suite BI Invalid Behaviour tests BO Inopportune Behaviour tests BV Valid Behaviour tests CA Capability tests CS Call Segment CS Capability Set EDP-R Event Detection Point - Request FSM Finite State Machine IN Intelligent Network INAP Intelligent Network Application Protocol IP Intelligent Peripheral iS initiating SSF iSSP initiating SSP IUT Implementation Under Test MSC Message Sequence Chart PDU Protocol Data Unit PICS Protocol Implementation Conformance Statement 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 TCAP Transaction Capabilities Application Part TP Test Purpose TSS Test Suite Structure SIST EN 301 933-2 V1.1.1:2005

ETSI ETSI EN 301 933-2 V1.1.1 (2003-01) 9
4 Test Purpose generalities 4.1 Introduction A TP is defined for one or several conformance requirements to be tested. It is expected, that each TP will result in a test case keeping the same name, specified in the ATS. 4.2 Grouping of Test Purposes per elementary procedures The Test Purposes are grouped by elementary procedures. A procedure groups elementary INAP operations which it is possible to test together. For each elementary procedure, are defined: how to invoke it; and what are the possible return results and return error(s) at the INAP interface. NOTE: Some have no results at all at this INAP interface. In these cases, and to have a "visible" result, the PCO will be at the signalling control interface. 4.3 Source of Test Purpose definitions The Test Purposes are based on the requirement documented in EN 301 931-1 [1] and EN 301 931-2 [2]. 4.4 Method used for developing TPs 4.4.1 Use of MSCs generated by the SDL model of Core INAP CS3 The SDL model of INAP CS3 is specified with object oriented SDL (SDL"92") and specifies the behaviour of the SSF. The CS3 specification inherits the CS-1 and specifies the whole of CS-1 and CS-2. The SDL specification is the normative specification of the INAP behaviour and is contained in EN 301 931-4 [4]. The SDL model specifies precisely and unambiguously the behaviour of and the interworking between the different functional entities of the SSF. The external interfaces of the SDL model are two signalling control interfaces (SigConA and SigConB) carrying abstract primitives, and the INAP interfaces to the SCF. Mappings are provided from SigConA and SigConB to DSS.1 and ISUP. The behaviour of the SDL model thus resembles an SSP, and can be used for service emulation and the development of Test Purposes and test cases. MSCs delivered by this SDL model are used in the TP definition and are provided in addition to the descriptive text. The development of the Test Purposes (TP) is done in two steps: a) the descriptive text is created together with a rough MSC defined by hand. It illustrates the basic behaviour in MSC-like form which is expected from the IUT. The rough MSC does not contain all the constraints in detail. The description makes reference to a preamble and a postamble; b) a detailed MSC is developed by simulation: 1) system level MSC for Autolink (the tool used to automatically generate the TTCN test cases based on the MSCs and the SDL model); 2) MSC for documentation of the TPs. The reason for developing the detailed MSC by simulation is that it can be done step by step while the SDL model prompts the developer for the correct options and parameters. The MSCs identify the different entities (SSF, SCF, SigCon A and B) involved in a given configuration and shows the different components used for a test, in term of the IUT (representing the SSF for instance) and the testers (representing the SCF and the SigCon A, B or C). SIST EN 301 933-2 V1.1.1:2005

ETSI ETSI EN 301 933-2 V1.1.1 (2003-01) 10 4.4.2 TCAP adapter primitives In addition to showing the INAP protocol, and in order to ease the implementation of the test suite, the MSCs show the TCAP adapter primitives such as TC begin, TC continue, TC invoke and TC end and show using standard abbreviations the INAP operations which are embedded in the TCAP primitive, together with the operation arguments. 4.4.3 Generation of corresponding Test Cases Using Computer Aided Test Generation techniques, TTCN test cases can be automatically generated from the SDL model. It is also possible to verify manually developed test cases against the SDL model. 4.5 Method used for TP description 4.5.1 Text and MSCs In general, a TP is described using text presented in a table followed by an MSC. The table describing each TP is as shown in table 1. Table 1: Test purpose description sample
TP name, e.g. IN3_A_BASIC_FC_BV_01 Work item no.: Temporary work item number; to be deleted when the TPs are stable IN2 Ref(tmp) Reference to INAP CS2 TP (optional) Purpose: Textual phrasing of the TP to be achieved. Requirements refs Reference to clause(s) of EN 301 931-2 [2]. For TPs related to the SRF function: also reference to clause(s) of EN 301 931-3 [3].
In the latter case the part numbers are explicitly indicated (part 2 and/or part 3). Selection Cond. Reference to a formal selection expression, if the TP is related to an optional INAP feature. If the field is empty, the TP is unconditional (mandatory requirement(s)). Preamble: Reference to a preamble or "None". Test description Sequence of transmitted and received events and timeouts (see clause "TTCN-like notation"). Textual description is also used, as appropriate. Pass criteria Indication of reception (or assured non-reception) of decisive message(s) related to the TP. Postamble: Reference to a postamble or "None".
The MSC which follows the TP description describes the test body, as the preambles and postambles are mostly defined by a single line in the MSC. 4.5.2 Test categories Valid Behaviour tests (BV) Predefined state transitions are considered as valid. The Test Purposes in the valid behaviour test sub group cover as far as reasonable the verification of the normal and exceptional procedures of the various Finite State Machines (FSMs), i.e. a valid behaviour test is a test where the message sequence and the message contents is considered as valid. Invalid Behaviour tests (BI) This test sub group is intended to verify that the IUT is able to react properly having received an invalid Protocol Data Unit (PDU). An invalid PDU is defined as a syntactically incorrect message. Inopportune Behaviour tests (BO) This test group is intended to verify that the IUT is able to react properly in the case an inopportune protocol event occurring. Such an event is syntactically correct but occurs when it is not expected, e.g. a correctly coded operation is received in a wrong state (the IUT may respond by sending error UnexpectedComponentSequence). SIST EN 301 933-2 V1.1.1:2005

ETSI ETSI EN 301 933-2 V1.1.1 (2003-01) 11 4.5.3 Test purpose naming convention The identifier of the TP is built according to the scheme in table 2. Table 2: TP identifier naming convention scheme
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 like
SF ServiceFiltering
= test category:
BV Valid Behaviour tests
BI Invalid Behaviour tests
BO Inopportune Behaviour tests
= sequential number: (01-99)
Example of Test Purpose and test case name: IN3_A_BASIC_SF_BV_02
4.5.4 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 933-2 V1.1.1:2005

ETSI ETSI EN 301 933-2 V1.1.1 (2003-01) 12 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. 4.5.5 How to interpret the parameters and their values as used in the MSCs The MSCs show the exchanges of PDUs of the TCAP protocol, as well as the Core INAP protocol. PDUs of both protocols use parameters. The list of parameters for the TCAP protocol is recalled here for each TCAP primitives. Note that only mandatory parameters are used. TCAP primitives from SCF to SSF: TC_InvokeReq (InvokeID, Class, DialogueID, OperationCode, OperationArg, Timeout); TC_BeginReq ( DialogueID, OriginatingAddress); TC_ContinueReq ( DialogueID, OriginatingAddress); TC_EndReq ( DialogueID, Termination); TC_AbortReq ( DialogueID). TCAP primitives from SSF to SCF: TC_InvokeInd (InvokeID, DialogueID, OperationCode, OperationArg, LastComponent); TC_BeginInd ( DialogueID, OriginatingAddress, ComponentPresent); TC_ContinueInd ( DialogueID, OriginatingAddress, ComponentPresent); TC_EndInd ( DialogueID, Termination, ComponentPresent); TC_AbortInd ( DialogueID); TC_ErrorInd (InvokeID, DialogueID, ErrorCode, LastComponent); TC_ReturnResultInd (InvokeID, DialogueID, LastComponent, OperationCode, OperationArg); TC_RejectInd (InvokeID, DialogueID). SIST EN 301 933-2 V1.1.1:2005

ETSI ETSI EN 301 933-2 V1.1.1 (2003-01) 13 The values of these parameters are either mandatory and imposed by the specifications, or they are informative only and chosen arbitrarily in ranges compatible with the specifications. Some preambles contain references to an ASP Mgt_SetTriggerTable. This does not exist in the protocol, but in the SDL model it allows which Trigger Detection points need to be set before commencing the test case. 5 Test configuration Figure 1 shows the test configuration assumed for the CPH Test Purposes.
Tester IUT
INAP
Operations
SSF/ SCF L1
SSP
L2
SigCon
A SigCon
B SigCon
C SigCon
D
Signalling messages Tester Figure 1: Test configuration for the CPH Test Purposes This test configuration covers a single SCP and a single SSP, where the SCP is simulated by the tester and the SSF is the implementation under test (IUT). INAP PDUs (operations) are exchanged between the tester and the IUT across the interface named L1 (or L2 etc.), which corresponds to a PCO in the TTCN-like notation used for the description of the test behaviour (see clause 6.4.2). INAP PDUs are embedded in TCAP messages as described in clause 10 of EN 301 931-1 [1] and clause 15 of EN 301 931-2 [2]. When call-related operations are tested, signalling messages are exchanged between the tester and the IUT, where the signalling terminations in the IUT are named SigCon A to SigCon D. Depending on the implementation, the signalling messages can be messages of the DSS1 protocol, ISUP protocol or another protocol (see e.g. clause 6.2.2.1 of EN 301 931-2 [2]). To be independent of any particular signalling protocol, Abstract Signalling Primitives are used in the test descriptions instead of signalling messages. For the definition of the Abstract Signalling Primitives see clause 6.2.2.2 of EN 301 931-2 [2]. NOTE: Test configurations including SRF entities ar
...

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...