1、 ETSI TS 102 790-2 V3.1.1 (2014-07) Core Network and Interoperability Testing (INT); IMS specific use of Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Conformance Testing; (3GPP Release 10); Part 2: Test Suite Structure (TSS) and Test Purposes (TP) TECHNICAL SPECIFICATION
2、 ETSI ETSI TS 102 790-2 V3.1.1 (2014-07)2Reference RTS/INT-00093-2 Keywords IMS, network, SIP, testing, TSS 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 (htt
3、p:/ipr.etsi.org). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essent
4、ial to the present document. Foreword This Technical Specification (TS) has been produced by ETSI Technical Committee Core Network and Interoperability Testing (INT). The present document is part 2 of a multi-part deliverable covering the IMS specific use of Session Initiation Protocol (SIP) and Ses
5、sion Description Protocol (SDP); Conformance Testing, as identified below: Part 1: “Protocol Implementation Conformance Statement (PICS)“; Part 2: “Test Suite Structure (TSS) and Test Purposes (TP)“; Part 3: “Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing
6、 (PIXIT) proforma specification“. Modal verbs terminology In the present document “shall“, “shall not“, “should“, “should not“, “may“, “may not“, “need“, “need not“, “will“, “will not“, “can“ and “cannot“ are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for t
7、he expression of provisions). “must“ and “must not“ are NOT allowed in ETSI deliverables except when used in direct citation. ETSI ETSI TS 102 790-2 V3.1.1 (2014-07)61 Scope The present document provides the Test Suite Structure (TSS) and Test Purposes (TP) for the IP Multimedia core network Subsyst
8、em (IMS) equipment supporting the Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) as specified in TS 124 229 1 in compliance with the relevant requirements and in accordance with the relevant guidance given in
9、ISO/IEC 9646-7 4 and ETS 300 406 5. 2 References References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the reference docum
10、ent (including any amendments) applies. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox.etsi.org/Reference. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their
11、long term validity. 2.1 Normative references The following referenced documents are necessary for the application of the present document. 1 ETSI TS 124 229 (V10.14.0): “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; IP multimedia call
12、control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (3GPP TS 24.229 version 10.14.0 Release 10)“. 2 ISO/IEC 9646-1: “Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concept
13、s“. 3 Void. 4 ISO/IEC 9646-7: “Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 7: Implementation Conformance Statements“. 5 ETSI ETS 300 406: “Methods for testing and Specification (MTS); Protocol and profile conformance testing specificat
14、ions; Standardization methodology“. 6 ETSI TS 102 790-1: “Core Network and Interoperability Testing (INT); IMS specific use of Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Conformance Testing; (3GPP Release 10); Part 1: Protocol Implementation Conformance Statement (PICS
15、)“. 7 IETF RFC 4028: “Session Timers in the Session Initiation Protocol (SIP)“. 2.2 Informative references The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area. i.1 Void. ETSI ETSI TS 102 79
16、0-2 V3.1.1 (2014-07)73 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: abstract selection expression: Refer to ISO/IEC 9646-1 2. Abstract Test Method (ATM): Refer to ISO/IEC 9646-1 2. Abstract Test Suite (ATS): Refer
17、to ISO/IEC 9646-1 2. Implementation Under Test (IUT): Refer to ISO/IEC 9646-1 2. Lower Tester (LT): Refer to ISO/IEC 9646-1 2. Test Purpose (TP): Refer to ISO/IEC 9646-1 2. 3.2 Abbreviations For the purposes of the present document, the abbreviations given in TS 124 229 1 and the following apply: AS
18、 Application Server ATS Abstract Test Suite AUTS AUThentication Synchronization CS Circuit Switched CSCF Call Session Control Function E-CSCF Emergency CSCF FQDN Fully Qualified Domain Name IBCF Interconnection Border Control Function I-CSCF Interrogating CSCF IF InterFaceIMPU IMS Public Identity IM
19、S AKA IMS-Authentication and Key Agreement IMS IP Multimedia Subsystem IP Internet Protocol IUT Implementation Under Test P-CSCF Proxy CSCF PICS Protocol Implementation Conformance Statement PIXIT Protocol Implementation eXtra Information for Testing S-CSCF Serving CSCF SDP Session Description Proto
20、col SE Session-Expires SIP Session Initiation Protocol SUT System Under Test TP Test Purpose TS Test System TSS Test Suite Structure UDP Unreliable Datagram Protocol UE User Equipment ETSI ETSI TS 102 790-2 V3.1.1 (2014-07)84 Test configurations Test purposes of the present document address the IMS
21、functional entities that are accessible via the following standardized SIP interfaces: Gm, Mw, Ic, and ISC. This clause introduces the test configurations that have been used for the definition of test purposes. Depending on the specific configuration the test system (TS) simulates the behaviour of
22、one or more UEs or other IMS core networks communicating with the IMS core network under test. Test configurations try to cover various scenarios of IMS interworking and roaming conditions. Some test configurations show dashed boxes to visualize the implicit presence of a UE in the TS. These dashed
23、boxes have only been introduced to improve understanding but do not have to be reflected in a test suite implementation. 4.1 Test configurations using Gm interface only The Gm interface is located between a UE and the IMS core network. TS IMS UE Gm SUT Figure 1: Test configuration CF_1Gm TS IMS UE1
24、Gm1 SUT Gm2 UE2 Figure 2: Test configuration CF_2Gm 4.2 Test configurations using the Mw interface The Mw interface is used in case of interworking or roaming between two different IMS core networks. This interface is used only if no border control functions like topology hiding are required. TS IMS
25、 IMS UE Mw Gm SUT Figure 3: Test configuration CF_1Mw ETSI ETSI TS 102 790-2 V3.1.1 (2014-07)9TS TS IMS IMS UE2 Mw Gm UE1 Gm SUT Figure 4: Test configuration CF_1Mw1Gm TS TS IMS1 UE1 Mw1 Gm1 UE2 Mw2 IMS2 Gm2 IMS SUT Figure 5: Test configuration CF_2Mw 4.3 Test configurations using the Ic interface T
26、he Ic interface is used in case of interworking or roaming between two different IMS core networks. This interface is used only if border control functions like topology hiding are required. TS IMS IMS UE Ic Gm SUT Figure 6: Test configuration CF_1Ic TS IMS IMS UE2 Ic Gm SUT TS UE1 Gm Figure 7: Test
27、 configuration CF_1Ic1Gm TS IMS IMS UE2 Ic1 Gm SUT Ic2 TS UE1 Gm Figure 8: Test configuration CF_2Ic1Gm ETSI ETSI TS 102 790-2 V3.1.1 (2014-07)104.4 Test configurations using the ISC interface The ISC interface enables the IMS core network to communicate with an AS. TS IMS AS ISC SUT TS UE1 Gm Figur
28、e 9: Test configuration CF_1ISC1Gm TS IMS AS1 ISC SUT TS UE1 Gm1 UE2 Gm2 Figure 10: Test configuration CF_1ISC2Gm TS IMS AS1 ISC11 SUT TS UE1 ISC2 AS2 UE1 Gm1 UE2 Gm2 Figure 11: Test configuration CF_2ISC2Gm 5 Test Suite Structure (TSS) 5.1 TP structure Test Purposes have been written for IMS core n
29、etwork functionality that is accessible via SIP based interfaces, i.e. P-, I-, E-, S-CSCF and IBCF components, as defined by TS 124 229 1. All test purposes in this document assess mandatory functionality unless they have been marked with the keyword “OPTIONAL“ at the beginning of the TP summary. Th
30、e test purposes have been divided according to the interfaces into four major groups. Subgroups have been introduced to structure TPs further according to different procedures: 1) Test purposes for the Gm interface only: 1.1) General; 1.2) Registration procedures; 1.3) Initial dialogue request proce
31、dures; 1.4) Standalone requests procedures; 1.5) Subsequent requests on a dialogue procedures; ETSI ETSI TS 102 790-2 V3.1.1 (2014-07)111.6) Target refresh request procedures; 1.7) Emergency procedures; 1.8) Exceptional procedures; 1.9) SDP procedures; 1.10) NAT traversal procedures. 2) Test purpose
32、s for the Mw interface: 2.1) General; 2.2) Registration procedures; 2.3) Initial dialogue request procedures; 2.4) Standalone requests procedures; 2.5) Subsequent requests on a dialogue procedures; 2.6) Target refresh request procedures; 2.7) Emergency procedures; 2.8) SDP procedures. 3) Test purpos
33、es for the Ic interface: 3.1) General; 3.2) Registration procedures; 3.3) Initial dialogue request procedures; 3.4) Standalone requests procedures; 3.5) Subsequent requests on a dialogue procedures; 3.6) Target refresh request procedures. 4) Test purposes for the ISC interface: 4.1) Registration pro
34、cedures; 4.2) Initial dialogue request procedures; 4.3) Standalone requests procedures; 4.4) Subsequent requests on a dialogue procedures; 4.5) Target refresh request procedures. 5.2 TP naming convention TPs are numbered, starting at 01, within each group. Groups are organized according to the TSS.
35、Additional references are added to identify the actual test suite and whether it applies to the network or the user (see table 1). ETSI ETSI TS 102 790-2 V3.1.1 (2014-07)12Table 1: TP identifier naming convention scheme Identifier: TP_ = Test suite name: i.e. “IMS_T2“ = type of Interface: “MW“ Mw in
36、terface “GM“ Gm Interface“IC“ Ic interface “ISC“ ISC interface= subgroup 3 first letter of the subgroup according to TSS subdivision “GEN“ General “REG“ Registration procedures “INI“ Initial request procedures “STA“ Standalone request procedures “SUB“ Subsequent request on a dialogue procedures “TAR
37、“ Target refresh request procedures “EME“ Emergency procedures “SDP“ SDP procedures “EXC“ Exceptional procedures “NAT“ NAT traversal procedures = sequential number (01-99) EXAMPLE 1: TP_IMS_T2_GM_GEN_01 stands for 1sttest case in the Gm interface only group, and in the general subgroup. All PICS ite
38、ms referred to in this clause are as specified in TS 102 790-1 6 unless indicated otherwise by another numbered reference. For each PICS item there exists a unique reference defined as the table identifier, followed by a solidus character “/“, followed by the item number in the table within TS 102 7
39、90-1 6. EXAMPLE 2: A.5/4 is the reference to the answer of item 4 in table A.5 of TS 102 790-1 6. 5.3 The tabular symbolic TP presentation format Each table contains header fields and a description part. The header fields identify the TP, list the related clause reference the base specification that
40、 the TP was derived from, introduce the TP with a short summary, references the related test configuration and test case in the ATS. Identifiers starting with the string “RQ_003_“ indicate requirements within the internal requirement catalogue. The description part presents the TP using two sections
41、: (a) initial conditions that have to be fulfilled for the test purpose body to be valid and (b) the test purpose body which is illustrated with one or more stimulus/response pairs. Both sections are further substructured with columns for affected entities from the test configurations, i.e. IUT, UE,
42、 UE2, IMS (test system component), and AS. The condition section lists one or more conditions that have to be fulfilled in order for the test purpose body to apply. Each condition has a description and either “check“ or “xmark“ marks to indicate all the entities affected by this condition. “check“ m
43、arks indicates a positive condition, e.g. “A is registered in B“, whereas “xmark“marks indicate a negative condition, e.g. “B not configured for feature Z“. If there is no mark in a column then the condition does not apply for that entity, e.g. entity A is not involved in the condition “B not config
44、ured for feature Z“. It is assumed that all listed conditions have to be fulfilled in the order listed, i.e. the list reflects an “and“ relation. Table 2 shows an example condition section illustrating all of the above examples. Table 2: Example TP condition section Entities Condition A B check chec
45、k A registered in B xmark B configured for feature Z ETSI ETSI TS 102 790-2 V3.1.1 (2014-07)13The test purpose body section contains one or more steps identified with a number in the first column. Steps belonging to IUT stimuli are shown with a green background whereas steps related to IUT responses
46、 are shown with a beige background. All listed steps are assumed to be carried out in increasing step number, i.e. they reflect an “and“ relation. “or“ relations at the level of entire messages are shown with lowercase letters following the step number identifying the different alternatives, e.g. “2
47、a“ versus “2b“. Each step indicates the exchange of a message from a source entity (identified by the direction symbols “arrowdwnrt1“ or “arrowdwnleft1“), e.g. entity A sends the message, to a destination entity (identified by the direction symbols “arrowrtup1“ or “arrowleftup1“), e.g. entity B rece
48、ives the message. The use of the “|“ symbol in combination with the direction symbols, e.g. “|arrowdwnleft1“, indicates that a particular message shall either not be sent or received by an entity, e.g. entity B did not send the message. Additional information about valid as well as invalid message c
49、ontent is presented in the “Message“ column. First general information about message, e.g. its type, destination, attributes, etc., are shown in bold font. Below this information message headers or parameter content that shall be present in that message are listed using “checkbld“ symbols whereas headers or parameter content that shall not be present are listed using the “xmarkbld“ symbols. The “barb4right“ symbol indicates a valid message parameter value where as the “barb4right|“symbol indicates an invalid message parameter value. Any
