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

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

1、ETSI EN 301 933-1 1.1.1 (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 1: Basic capability set of CS3 2 ETSI EN 301 933-1 V

2、1.l.l (2003-01) Reference DENISPAN-I 20063-3-1 Keywords CS3, CTM, IN, INAP, SSF, 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 deliv

3、erables 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

4、 deliverable 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 lat

5、est announcement 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-1 V1.l.l (2003-01) 1 Scope T

6、he present document provides 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 Se

7、t 3 (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 i

8、nterface“. 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-2: “Intelligent Network (IN); Intelligent Network capability Set 3

9、 (CS3); Intelligent Network Application protocol (INAP); Test Suite Structure and Test Purposes (TSS Part 2: Call Party Handling (CPH) “ . ETSI EN 301 933-3: “Intelligent Network (IN); Intelligent Network Capability Set 3 (CS3); Intelligent Network Application Protocol (INAP); Test Suite Structure a

10、nd Test Purposes (TSS Part 3: Specialized Resource Function (SRF)“. ETSI ES 201 296 (Vi .2.2): “Integrated Services Digital Network (ISDN); Signalling System N0.7; ISDN User Part (ISUP); Signalling aspects of charging“. ISO/IEC 9646- 1 : “Information technology - Open Systems Interconnection - Confo

11、rmance testing methodology and framework - Part 1 : General concepts“. ISO/IEC 9646-2: “Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 2: Abstract Test Suite specification“. ETSI 8 ETSI EN 301 933-1 V1.l.l (2003-01) 3 3.1 Definitions and

12、abbreviations De fi nit ions For the purposes of the present document, the following terms and defmitions apply: - - terms defined in EN 301 931-1 i; terms defined in ISO/IEC 9646-1 SI and in ISO/IEC 9646-2 9. In particular, the following terms defied in ISO/IEC 9646-1 SI apply: - Abstract Test Suit

13、e (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 BI BO BV CA CPH cs cs EDP-R FSM IN INAP IUT MSC PDU PICS PIXIT SCF SCP SDL

14、 SRF SSF SSP SUT TCAP TP TSS Abstract Test Suite Invalid Behaviour tests Inopportune Behaviour tests Valid Behaviour tests Capability tests Call Party Handling Call Segment Capability Set Event Detection Point - Request Finite State Machine Intelligent Network Intelligent Network Application Protoco

15、l Implementation Under Test Message Sequence Chart Protocol Data Unit Protocol Implementation Coiiformance Statement Protocol Implementation extra Information for Testing Service Control Function Service Control Point Specification and Description Language Specialized Resource Function Service Switc

16、hing Function Service Switching Point System Under Test Transaction Capabilities Application Part Test Purpose Test Suite Structure ETSI 9 ETSI EN 301 933-1 V1.l.l (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

17、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 e

18、ach 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.

19、4.3 Source of test purpose definitions 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 S

20、DL (SDL92) and specifies the behaviour of the SSF. 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 intenvorking between the different functional entities of th

21、e 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 c

22、an 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 create

23、d 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; a detailed MSC is developed by simulation: 1)

24、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 step by step while the SDL model prompts the develo

25、per 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 instance) and the testers (representing the SCF and the S

26、igCon A, B or C). ETSI 10 Work item no.: IN2 Ref(tmp) Purpose: Requirements ETSI EN 301 933-1 V1.l.l (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 to be achieved. Reference to clause(s of EN 301 931-2 121. 4

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

28、 in the TCAP primitive, together with the operation arguments. ref; 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. It is also possible to ver manually developed test case

29、s 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 TP is related to an optional INAP feature. If the field

30、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 events and timeouts (see clause “TTCN-like notation“). Text

31、ual 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 by an MSC. The table describing each TP is as shown in

32、 table 1, Table 1: Test purpose description sample TP name, e.g. INS-A-BASIC-FC-BV-O1 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 tr

33、ansitions 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 messag

34、e 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 incorrect message. Inopportune Behaviour tests (BO) This test

35、 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 in a wrong state (the IUT may respond by sending error Unex

36、pectedComponentSequence). ETSI 11 ETSI EN 301 933-1 V1.l.l (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 Identifier: IN3- rN3 indicates IN Capability Set 3 = interface: A SSF-SCF in

37、terface 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: BVValid Behaviour tests BI Invalid Behaviour tests BOInopportu

38、ne Behaviour tests = sequential number: (O 1-99) Example of test purpose and test case name: IN3-A-BASIC-SF-BY02 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 preamble

39、s 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 the preamble, in terms of nature of the legs per

40、Call Segment (CS), starting fiom 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(1egs) for Callsegmen

41、t 11-idem for CallSegment2-idern for Callsegment 31 where: a is letter: O T I for Originating (outgoing call for a user); for Terminating (incoming call for a user); for Initiate Call Attempt (initiated from the network). The state names and their abbreviations used are: Null 1-Party 1P ETSI 12 ETSI

42、 EN 301 933-1 V1.l.l (2003-01) Originating-Set-up OS Terminating-Set-up TS Originating- 1-Party-Setup 01PS 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 n) SnP The term “null“ stands for “none“ as in pre

43、amble 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 PDUs of the TCAP protocol, as well as the Core INAP

44、 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); T

45、C-BeginReq (DialogueID, OriginatingAddress); TC-ContinueReq (DialogueID, OriginatingAddress); TC-EndReq (DialogueID, Termination); TCAbortReq (DialogueID). TCAP primitives from SSF to SCF: TC-InvokeInd (InvokeID, DialogueID, OperationCode, OperationArg, Lastcomponent); TC-BeginInd (DialogueID, Origi

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

47、OperationCode, OperationArg); TC-Rej ectInd (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

48、-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. ETSI 13 ETSI EN 301 933-1 V1.l.l (2003-01) Test Parameter name KSR-INTERRUPTABLE 4.6 Test purpose parametrization and selection Type Ex

49、planation BOOLEAN TRUE if the RequestCurrentStatusReport operation is interruptable, .e. when after receiving the operation the SSF remains for some time in a state, where other 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. SINGLE-POINT-OF-CONTROL BOOLEAN 3ASIC-TARIFF-METHOD IA5String TSPX-SCI-DESTB-ROU