ETSI EN 301 933-2-2003 Intelligent Network (IN) Intellegent Network Capability Set 3 (CS3) Intelligent Network Application Protocol (INAP) Test Suite Structure and Test Purposes(TS_1.pdf

《ETSI EN 301 933-2-2003 Intelligent Network (IN) Intellegent Network Capability Set 3 (CS3) Intelligent Network Application Protocol (INAP) Test Suite Structure and Test Purposes(TS_1.pdf》由会员分享，可在线阅读，更多相关《ETSI EN 301 933-2-2003 Intelligent Network (IN) Intellegent Network Capability Set 3 (CS3) Intelligent Network Application Protocol (INAP) Test Suite Structure and Test Purposes(TS_1.pdf（478页珍藏版）》请在麦多课文档分享上搜索。

1、ETS I EN 30 1 933-2 VI .I .I (2003-01) European Sfandard (Telecommunicafions series) Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Test Suite Structure and Test Purposes (TSS Part 2: Call Party Handling (CPH) 2 ETSI EN 301 933-

2、2 VI .I .I (2003-01) Reference DENISPAN-I 20063-3-2 Keywords IN, CS3, INAP, TSS Essential, orpotentially Essential, IPRs notlJied to ETSI in respect ofETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (5). All published ETSI deliverabl

3、es 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 deli

4、verable covering the Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Test Suite Structure and Test Purposes (TSS “Call Party Handling (CPH)“; “Specialized Resource Function (SRF)“. National transposition dates Date of adoption of this EN: Date of latest a

5、nnouncement of this EN (doa): Date of latest publication of new National Standard or endorsement of this EN (dop/e): Date of withdrawal of any conflicting National Standard (dow): 10 January 2003 30 April 2003 3 1 October 2003 3 1 October 2003 ETSI 7 ETSI EN 301 933-2 VI .I .I (2003-01) 1 Scope The

6、present document contains the Test Suite Structure and Test Purposes (TSS Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Protocol specification; Part 1 : Common aspects“. ETSI EN 301 93 1-2: “Intelligent Network (IN); Intelligent Network Capability Set 3

7、 (CS3); Intelligent Network Application Protocol (INAP); Protocol specification; Part 2: SCF-SSF interface“. 21 31 ETSI EN 301 93 1-3: “Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Protocol specification; Part 3 : SCF-SRF inte

8、rface“. 41 ETSI EN 301 93 1-4: “Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Protocol specification; Part 4: SDLs for SCF-SSF interface“. 51 ETSI EN 301 933-1: “Intelligent Network (IN); Intelligent Network Capability Set 3 (C

9、S3); Intelligent Network Application Protocol (INAP); Test Suite Structure and Test Purposes (TSS Part 1: Basic capability set of CS3“. ETSI EN 301 933-3: “Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Test Suite Structure and

10、Test Purposes (TSS Part 3: Specialized Resource Function (SRF)“. Void. ISO/IEC 9646- 1 : “Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1 : General concepts“. ETSI 8 ETSI EN 301 933-2 VI .I .I (2003-01) 91 ISO/IEC 9646-2: “Information te

11、chnology - Open Systems Interconnection - Conformance testing methodology and framework - Part 2: Abstract Test Suite specification“. ITU-T Recommendation Q. 1224: “Distributed functional plane for intelligent network Capability Set 2“. lo1 3 3.1 Definitions and abbreviations De fi nit ions For the

12、purposes of the present document, the following terms and defiiitions apply: - termsdefinedinEN301 931-1 i; - terms defined in ISO/IEC 9646-1 SI and in ISO/IEC 9646-2 9. In particular, the following terms defiied in ISO/IEC 9646-1 SI apply: - Abstract Test Suite (ATS); - Implementation Under Test (I

13、UT); - System Under Test (SUT); - Protocol Implementation Conformance Statement (PICS). 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: ATS BI BO BV CA cs cs EDP-R FSM IN INAP IP is iSSP IUT MSC PDU PICS SCF SCP SDF SDL SRF SSF SSP SUT TCAP TP TSS Abstr

14、act Test Suite Invalid Behaviour tests Inopportune Behaviour tests Valid Behaviour tests Capability tests Call Segment Capability Set Event Detection Point - Request Finite State Machine Intelligent Network Intelligent Network Application Protocol Intelligent Peripheral initiating SSF initiating SSP

15、 Implementation Under Test Message Sequence Chart Protocol Data Unit Protocol Implementation Conformance Statement Service Control Function Service Control Point Service Data Function Specification and Description Language Specialized Resource Function Service Switching Function Service Switching Po

16、int System Under Test Transaction Capabilities Application Part Test Purpose Test Suite Structure ETSI 9 ETSI EN 301 933-2 VI .I .I (2003-01) 4 Test Purpose generalities 4.1 I n trod u ction A TP is defined for one or several conformance requirements to be tested. It is expected, that each TP will r

17、esult 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 de

18、fined: 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 defin

19、itions The Test Purposes are based on the requirement documented in EN 30 1 93 1 - 1 11 and EN 30 1 93 1-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 b

20、ehaviour 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 93 1-4 4. The SDL model specifies precisely and unambiguously the behaviour of and the intenvor

21、king 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 beh

22、aviour 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

23、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 posta

24、mble; a detailed MSC is developed by simulation: 1) b) system level MSC for Autolink (the tool used to automatically generate the TTCN test cases based on the MSCs and the SDL model); MSC for documentation of the TPs. 2) The reason for developing the detailed MSC by simulation is that it can be done

25、 step by step while the SDL model prompts the developer for the correct options and parameters. The MSCs identiSl 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 insta

26、nce) and the testers (representing the SCF and the SigCon A, B or C). ETSI 10 Work item no.: IN2 Ref(tmp) Purpose: Requirements refs ETSI EN 301 933-2 VI .I .I (2003-01) Temporary work item number; to be deleted when the TPs are stable Reference to INAP CS2 TP (optional) Textual phrasing of the TP t

27、o be achieved. Reference to clause(s of EN 301 931-2 121. 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 st

28、andard abbreviations the INAP operations which are embedded in the TCAP primitive, together with the operation arguments. Selection Cond. 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. I

29、t is also possible to ver manually developed test cases against the SDL model. For TPs related to theSRF 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). Reference to a formal selection expression, if the T

30、P is related to an optional INAP feature. If the field is empty, the TP is unconditional (mandatory requirement(s). 4.5 Method used for TP description Preamble : Test description Pass criteria Postamble: 4.5.1 Text and MSCs Reference to a preamble or “None“. Sequence of transmitted and received even

31、ts and timeouts (see clause “TTCN-like notation“). Textual description is also used, as appropriate. Indication of reception (or assured non-reception) of decisive message(s) related to the TP. Reference to a postamble or “None“. In general, a TP is described using text presented in a table followed

32、 by an MSC. The table describing each TP is as shown in table 1, Table 1: Test purpose description sample I ITP name, e.g. IN3-A-BASIC-FC-BV-O1 I 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 Te

33、st 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 behavi

34、our 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 ver that the IT is able to react properly having received an invalid Protocol Data Unit (PDU). An invalid PDU is defined as a syntactically i

35、ncorrect message. Inopportune Behaviour tests (BO) This test group is intended to veriSl 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

36、 in a wrong state (the IUT may respond by sending error UnexpectedComponentSequence). ETSI 11 ETSI EN 301 933-2 VI .I .I (2003-01) 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 IN3 = interfac

37、e: A SSF-SCF interface B SSF-SRF interface C SCF-SCF interface indicates IN Capability Set 3 I = commonset BASIC Basic set for CS3 CPH SRF Call Party Handling from Capability Set 3 SRF-related functions from Capability Set 3 = procedure name like SF ServiceFiltering = test category: BV Valid Behavio

38、ur 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 p

39、lace. 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 P 1 followed by preambles P2 then P3. The naming convention used reflects the description of the connection view set by executing t

40、he 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 fiist letter indicates how this configuration was initiated. The general form is: a-stablelegsparty o

41、r onHold (legs) or transfer(1egs) for Callsegment 11-idem for CallSegment2-idem for Callsegment 31 where: a is letter: O for Originating (outgoing call for a user); T I for Terminating (incoming call for a user); for Initiate Call Attempt (initiated from the network). ETSI 12 ETSI EN 301 933-2 VI .I

42、 .I (2003-01) The state names and their abbreviations used are: Null 1-Party 1P Originating-Set-up OS Terminating-Set-up TS Originating- 1-Party-Setup O 1 PS Stable-1-Party S1P Stable-2-Party S2P Forward FW StableMulti-Passive-Party (no. of passive legs n) SnPP StableMulti-Party (no. of passive legs

43、 n) SnP The term “null“ stands for “none“ as in preamble O_NLL_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-SlP-SlP. 4.5.5 How to interpret the parameters and their values as used in the MSCs The MSCs show the exchanges of

44、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, D

45、ialogueID, OperationCode, OperationArg, Timeout); TC-BeginReq ( DialogueID, OriginatingAddress); TC-ContinueReq ( DialogueID, OriginatingAddress); TC-EndReq ( DialogueID, Termination); TCAbortReq ( DialogueID). TCAP primitives from SSF to SCF: TC-InvokeInd (InvokeID, DialogueID, OperationCode, Opera

46、tionArg, Lastcomponent); TC-BeginInd ( DialogueID, OriginatingAddress, ComponentPresent); TC-ContinueInd ( DialogueID, OriginatingAddress, ComponentPresent); TC-EndInd ( DialogueID, Termination, ComponentPresent); TCAbortInd ( DialogueID); TC-ErrorInd (InvokeID, DialogueID, Errorcode, Lastcomponent)

47、; TC-ReturnResultInd (InvokeID, DialogueID, Lastcomponent, OperationCode, OperationArg); TC-Rej ectInd (InvokeID, DialogueID). ETSI 13 ETSI EN 301 933-2 VI .I .I (2003-01) The values of these parameters are either mandatory and imposed by the specifications, or they are informative only and chosen a

48、rbitrarily 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 s

49、hows the test configuration assumed for the CPH Test Purposes. Tester I UT 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