ETSI EN 301 933-1 V1.1.1 (2003-01)
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
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
DEN/SPAN-120063-3-1
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) – 1. del: Osnovni nabor zmožnosti CS3
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) – Aplikacijski protokol inteligentnega omrežja (INAP) – Zgradba preskušalnega niza in namen preskušanja (TSS&TP) – Specifikacija za funkcijo komutacije storitev (SSF) – 1. del: Osnovni nabor zmožnosti CS3Intelligent 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 CS333.040.35Telefonska omrežjaTelephone networksICS:Ta slovenski standard je istoveten z:EN 301 933-1 Version 1.1.1SIST EN 301 933-1 V1.1.1:2005en01-januar-2005SIST EN 301 933-1 V1.1.1:2005SLOVENSKI
STANDARD
ETSI ETSI EN 301 933-1 V1.1.1 (2003-01) 2
Reference DEN/SPAN-120063-3-1 Keywords CS3, CTM, IN, INAP, SSF, TSS&TP, UPT 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-1 V1.1.1:2005
ETSI ETSI EN 301 933-1 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 4.6 Test purpose parametrization and selection.13 5 Test configuration.18 6 TSS and TPs for CS3 basic capabilities.19 6.1 Introduction.19 6.2 Basic procedures.19 6.2.1 List of procedures.19 6.2.2 Definitions of the procedures.20 6.3 Structure of the test suite (TSS) for the basic capabilities.23 6.4 Notations.24 6.4.1 Names of preambles and postambles.24 6.4.2 TTCN-like notation for preamble, test case and postamble description.25 6.4.3 Representation of preambles, postambles and Test Purposes using MSCs.25 6.4.4 How to interpret the parameters and their values as used in the MSCs.25 6.4.4.1 General.25 6.4.4.2 INAP operation parameters and their values.25 6.4.4.3 Cause values related to signalling connection release messages.26 6.4.4.4 TCAP operation parameters and their values.26 6.5 Preambles and postambles used.27 6.5.1 Preamble descriptions.27 6.5.1.1 O_OS preamble.27 6.5.1.2 O_OS_ColIn preamble.27 6.5.1.3 O_S2P preamble.27 6.5.1.4 I_S1P preamble.27 6.5.1.5 I_S1P_S1P_S1P preamble.28 6.5.1.6 T_TS preamble.28 6.5.1.7 T_S2P preamble.28 6.5.1.8 STAT_S2P.29 6.5.1.9 STAT_1P.29 6.5.1.10 STAT_S1P_1P.29 6.5.1.11 PRE_TRIG.29 6.5.1.12 PRE_ACTIVATE_TRIG1.30 6.5.1.13 PRE_DEACTIVATE_TRIG1.30 SIST EN 301 933-1 V1.1.1:2005
ETSI ETSI EN 301 933-1 V1.1.1 (2003-01) 4
6.5.1.14 PRE_ACTIVATE_TRIG_PROF_2.30 6.5.1.15 PRE_DEACTIVATE_TRIG_PROF_2.31 6.5.1.16 PRE_ACTIVATE_TRIG_DP_2.32 6.5.1.17 PRE_DEACTIVATE_TRIG_DP_2.32 6.5.1.18 PRE_ACTIVATE_TRIG_DP_3.33 6.5.1.19 O_OSA_AC_CURR.33 6.5.1.20 O_OSA_AC_PULSE.34 6.5.1.21 O_OSA_AC.34 6.5.1.22 O_OSA_FCI.35 6.5.1.23 O_OSA_RNC.35 6.5.1.24 Preamble PRE_SCI_1.36 6.5.1.25 Preamble PRE_SCI_2.36 6.5.2 Postamble descriptions.36 6.5.2.1 SigConA_Release postamble.36 6.5.2.2 SigConA_Release_thenB postamble.37 6.5.2.3 ReleaseCallA postamble.37 6.5.2.4 ReleaseICA postamble.37 6.5.2.5 ReleaseCallAB_cause_00 postamble.37 6.5.2.6 ReleaseCallAB_cause_0F postamble.37 6.5.2.7 SigConB_Release postamble.37 6.5.2.8 SigConB_Release_cause_0D postamble.37 6.5.2.9 SigConA_Release_thenB_cause10 postamble.37 6.5.2.10 ReleaseCallB postamble.38 6.5.2.11 ReleaseCallA2 postamble.38 6.5.2.12 ReleaseCallA3 postamble.38 6.5.2.13 ReleaseToAB postamble.38 6.5.2.14 ReleaseAandIgnoreStat.38 6.5.2.15 ReleaseABandIgnoreStat.39 6.5.2.16 TrigReleaseA postamble.39 6.5.2.17 TrigReleaseB postamble.39 6.5.2.18 TrigReleaseAB postamble.39 6.5.2.19 TrigReleaseA2 postamble.40 6.5.2.20 StopGapCld(cldDigits,scf,ctrl,clear) postamble.40 6.5.2.21 StopGapCld2(cldDigits,scf,ctrl,clear) postamble.41 6.5.2.22 StopGapCld3(cldDigits,scf,ctrl,clear) postamble.41 6.5.2.23 StopGapCldService(skey,cldDigits,scf,ctrl,clear) postamble.42 6.5.2.24 StopGapCldService2(skey, cldDigits, scf, ctrl, clear) postamble.42 6.5.2.25 StopGapClgService(skey, clgDigits, locNum, scf, ctrl, clear) postamble.43 6.5.2.26 StopGapClgService2(skey, clgDigits, locNum, scf, ctrl, clear) postamble.44 6.5.2.27 StopGapGos(sKey, scf, ctrl, clear) postamble.44 6.5.2.28 StopGapGos2(sKey, scf, ctrl, clear) postamble.45 6.5.2.29 StopGapGos3(sKey,scf,ctrl,clear) postamble.46 6.5.2.30 StopGapGosOS(sKey,scf,ctrl,clear) postamble.47 6.5.2.31 StopGapAllIn(scf, ctrl, clear) postamble.47 6.5.2.32 StopGapAllIn2(scf, ctrl, clear) postamble.48 6.5.2.33 Postamble POST_SCI_RELEASE_B.48 6.5.2.34 Postamble POST_SCI_RELEASE_BC.49 6.5.2.35 Postamble POST_SCI_EXCEPT_RELEASE_B.49 6.5.2.36 Postamble POST_SCI_EXCEPT_RELEASE_BC.49 6.6 Test Purposes (TP) description.50 6.6.1 ActivityTest (AT) procedure.50 6.6.2 ApplyCharging (AC) procedure.54 6.6.3 CallGap (CG) procedure.83 6.6.4 CallInformation (CF) procedure.126 6.6.5 Cancel (CA) procedure.142 6.6.6 CollectInformation (CI) procedure.143 6.6.7 Connect (CO) procedure.149 6.6.8 EntityReleased (ER) procedure.171 6.6.9 CreateOrRemoveTriggerData (CT) procedure.172 6.6.10 Continue (CU) procedure.258 6.6.11 ContinueWithArgument (CWA) procedure.260 6.6.12 FurnishChargingInformation (FC) procedure.260 SIST EN 301 933-1 V1.1.1:2005
ETSI ETSI EN 301 933-1 V1.1.1 (2003-01) 5
6.6.13 InitialDP (DP) procedure.282 6.6.14 InitiateCallAttempt (IC) procedure.296 6.6.15 ManageTriggerData (MT) procedure.304 6.6.16 ReleaseCall (RC) procedure.354 6.6.17 ReportUTSI (RP) procedure.362 6.6.18 RequestCurrentStatusReport (RT) procedure.362 6.6.19 RequestEveryStatusChangeReport (RE) procedure.365 6.6.20 RequestFirstStatusMatchReport (RF) procedure.387 6.6.21 RequestNotificationChargingEvent (RN) procedure.397 6.6.22 RequestReportBCSMEvent (RR) procedure.407 6.6.23 ResetTimer (RS) procedure.468 6.6.24 SendChargingInformation (SCI) procedure.471 6.6.24.1 General information on testing SCI.471 6.6.24.2 Send Charging InformationTest Purposes.474 6.6.25 Service Filtering (SF) procedure.518 6.6.26 SetServiceProfile (SP) procedure.528 Annex A (informative): Description of various functional configurations.538 Annex B (informative): Bibliography.539 History.540
ETSI ETSI EN 301 933-1 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 1 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-1 V1.1.1 (2003-01) 7
1 Scope The present document provides the Test Suite Structure and Test Purposes (TSS&TP) for the testing of the "Basic" 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 933-2 [5] (Call party handling functions) and EN 301 933-3 [6] (Specialized Resource Function). 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-2: "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)". [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] ETSI ES 201 296 (V1.2.2): "Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP); Signalling aspects of charging". [8] ISO/IEC 9646-1: "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts". [9] ISO/IEC 9646-2: "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 2: Abstract Test Suite specification". SIST EN 301 933-1 V1.1.1:2005
ETSI ETSI EN 301 933-1 V1.1.1 (2003-01) 8
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 CPH Call Party Handling CS Call Segment CS Capability Set EDP-R Event Detection Point - Request FSM Finite State Machine IN Intelligent Network INAP Intelligent Network Application Protocol IUT Implementation Under Test MSC Message Sequence Chart PDU Protocol Data Unit PICS Protocol Implementation Conformance Statement PIXIT Protocol Implementation eXtra Information for Testing SCF Service Control Function SCP Service Control Point 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-1 V1.1.1:2005
ETSI ETSI EN 301 933-1 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 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-1 V1.1.1:2005
ETSI ETSI EN 301 933-1 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-1 V1.1.1:2005
ETSI ETSI EN 301 933-1 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). The state names and their abbreviations used are: Null 1_Party 1P SIST EN 301 933-1 V1.1.1:2005
ETSI ETSI EN 301 933-1 V1.1.1 (2003-01) 12 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). 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. SIST EN 301 933-1 V1.1.1:2005
ETSI ETSI EN 301 933-1 V1.1.1 (2003-01) 13 4.6 Test purpose parametrization and selection In order to define an appropriate set of TPs for all functions and operations, but to enable deselection of TPs not applicable to particular IUTs, the following Test Parameters are defined in table 3. NOTE: It is assumed, that these Test Parameters are mapped to corresponding PIXIT/Test Suite Parameters. Table 3: Test Parameters applicable to TP selection Test Parameter name Type Explanation RCSR_INTERRUPTABLE BOOLEAN TRUE if the RequestCurrentStatusReport operation is interruptable, i.e. when after receiving the operation the SSF remains for some time in a state, where other operations can be received before the returnResult component is sent. Otherwise FALSE. SINGLE_POINT_OF_CONTROL BOOLEAN TRUE if only Single Point of Control is implemented in the SSF. BASIC_TARIFF_METHOD IA5String The possible values are "Currency" and "Pulse", depending on which method is implemented in the SSF for charging supervision. TSPX_SCI_DESTB_ROUTE_CH BOOLEAN True if there is a destination routing address (given by TSPX_SCI_DESTB1_ADDR_CH) which forces the SSF to determine a charging tariff (act as CDP). TSPX_SCI_DESTC_ROUTE_CH BOOLEAN True if there is a destination routing address (given by TSPX_SCI_DESTC1_ADDR_CH) which forces the SSF to determine a charging tariff (act as CDP). TSPX_SCI_CLD_IN_CH BOOLEAN True if there is a called IN address (given by TSPX_SCI_IN_ADDR_CH) which forces the SSF to determine a charging tariff (act as CDP).
The following Test Parameters used to parameterize the TP descriptions, when necessary, are defined in table 4. NOTE: It is assumed, that these Test Parameters are mapped to corresponding PIXIT/Test Suite Parameters. Table 4: Test Parameters applicable to TP parametrization Test Parameter name Type Explanation STAT_RESOURCE_1 ResourceID When describing TPs for StatusReport operations (RequestCurrentStatusReport, RequestEveryStatusChangeReport and RequestFirstStatusMatchReport), calls with 2 legs are made. STAT_RESOURCE_1 identifies the resources associated with leg 1 (controlling; user A). The association is independent of whether the StatusReport operations are performed inside this call context or not. In each case call-related operations are performed to bring the associated resources in a specified status ("busy" or "idle"). STAT_RESOURCE_2 ResourceID Like STAT_RESOURCE_1, but for leg 2 (passive; user B). STAT_RESOURCE_U ResourceID Syntactically valid Resource ID not identifying any resource known to the SSF. STAT_MON_DUR_ANY Duration Duration value to be sent in the RequestEveryStatusChangeReport or RequestFirstStatusMatchReport invoke component. Any positive duration in the range specified by Duration or OMIT is allowed. SIST EN 301 933-1 V1.1.1:2005
ETSI ETSI EN 301 933-1 V1.1.1 (2003-01) 14 Test Parameter name Type Explanation STAT_MON_DUR Duration Positive duration value to be sent in the RequestEveryStatusChangeReport or RequestFirstStatusMatchReport invoke component. OMIT is not allowed. PROFILE_ID_1 ProfileIdentifier Profile Identifier value compatible with the call-related data sent by the SCF/tester in a SetupInd message where CALL-DATA-1 is indicated as parameter for the SetupInd message. The parameter is used in TPs for Trigger Management operations. The parameter must be seen in connection with parameters TRIGGER_DATA_1 and CALL-DATA-1. It is assumed that a call with CALL-DATA-1 can be made to go through all DPs except originationAttemptDenied, routeSelectFailure, authorizeRouteFailure and terminationAttemptDenied by appropriate call operations like release or suspend etc.
It is also assumed that a trigger can be set on all DPs except the mentioned ones, if the trigger uses PROFILE_ID_1 and TRIGGER_DATA_1 and that the trigger criteria will be fulfilled for a call with call-related data CALL-DATA-1. TRIGGER_DATA_1 TriggerData Trigger Data value (trigger criteria etc.) compatible with the call-related data sent by the SCF/tester in a "standard" SetupInd message, or where CALL-DATA-1 is indicated as parameter for the SetupInd message. See also PROFILE_ID_1. CALL-DATA-1 Informal This parameter denotes call-related data sent in a SetupInd message/ASP in an informal way. These data cover the called address, and depending on the kind of call and the signalling protocol, data like calling address, calling party's category, facilities etc. The important point is, that a call with these call-related data can be made to match trigger conditions and trigger criteria defined by parameters PROFILE_ID_1 and TRIGGER_DATA_1 at all DPs mentioned under PROFILE_ID_1. SERVICE_KEY1 ServiceKey Service key set for triggers defined by PROFILE_ID_1 and TRIGGER_DATA_1. PROFILE_ID_2 ProfileIdentifier Similar as PROFILE_ID_1, but a matching trigger condition can be set at DP originationAttemptDenied, if also TRIGGER_DATA_2 and CALL-DATA-2 are set appropriately. TRIGGER_DATA_2 TriggerData Similar as TRIGGER_DATA_1, but a matching trigger condition can be set at DP originationAttemptDenied, if also PROFILE_ID_2 and CALL-DATA-2 are set appropriately. CALL-DATA-2 Informal Similar as CALL-DATA-1, but a matching trigger condition can be set at DP originationAttemptDenied, if also TRIGGER_DATA_2 and PROFILE_ID_2 are set appropriately. SERVICE_KEY2 ServiceKey Service key set for triggers defined by PROFILE_ID_2 and TRIGGER_DATA_2. SIST EN 301 933-1 V1.1.1:2005
ETSI ETSI EN 301 933-1 V1.1.1 (2003-01) 15 Test Parameter name Type Explanation PROFILE_ID_3 ProfileIdentifier Similar as PROFILE_ID_1, but a matching trigger condition can be set at DP routeSelectFailure, if also TRIGGER_DATA_3 and CALL-DATA-3 are set appropriately. TRIGGER_DATA_3 TriggerData Similar as TRIGGER_DATA_1, but a matching trigger condition can be set at DP routeSelect
...








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