ETSI TS 103 289-2 V2.1.1 (2016-07)

TECHNICAL SPECIFICATION
Core Network and Interoperability Testing (INT);
Diameter Conformance testing for Cx and Dx interfaces;
(3GPP™ Release 10);
Part 2: Test Suite Structure (TSS) and Test Purposes (TP)

2 ETSI TS 103 289-2 V2.1.1 (2016-07)

Reference
RTS/INT-00128-2
Keywords
diameter, TSS&TP
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
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (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
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2016.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 289-2 V2.1.1 (2016-07)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 6
4 Test configurations . 6
4.1 Introduction . 6
4.2 Test configurations using Cx interface . 7
4.3 Test configurations using the Dx interface . 8
5 Test Suite Structure (TSS) and Test Purposes (TP) . 9
5.1 Test Suite Structure . 9
5.1.1 TP naming convention . 9
5.1.2 Test strategy . 9
5.1.3 TP structure . 9
5.2 Test Purposes . 10
5.2.0 PICS references . 10
5.2.1 Cx Interface . 11
5.2.1.1 HSS Role . 11
5.2.1.1.0 Test Selection . 11
5.2.1.1.1 Message Syntax . 11
5.2.1.1.2 User Authorization . 12
5.2.1.1.3 Server assignment . 29
5.2.1.1.4 Registration Termination . 38
5.2.1.1.5 Location Information . 42
5.2.1.1.6 Push Profile . 47
5.2.1.1.7 Multimedia authentication . 50
5.2.1.1.8 Error Handling . 56
5.2.1.2 CSCF Role . 57
5.2.1.2.0 Test Selection . 57
5.2.1.2.1 Message Syntax . 57
5.2.1.2.2 User Authorization . 58
5.2.1.2.3 Server assignment . 60
5.2.1.2.4 Registration Termination . 62
5.2.1.2.5 Location Information . 63
5.2.1.2.6 Push Profile . 64
5.2.1.2.7 Multimedia Authentication . 66
5.2.2 Dx Interface . 68
5.2.2.1 SLF Role . 68
5.2.2.1.0 Test Selection . 68
5.2.2.1.1 User Authorization . 69
5.2.2.1.2 Server assignment . 70
5.2.2.1.3 Location Information . 71
5.2.2.1.4 Multimedia authentication . 72
5.2.2.2 CSCF Role . 72
5.2.2.2.0 Test Selection . 72
5.2.2.2.1 User Authorization . 73
5.2.2.2.2 Server assignment . 73
5.2.2.2.3 Location Information . 73
5.2.2.2.4 Multimedia authentication . 74
History . 75
ETSI
4 ETSI TS 103 289-2 V2.1.1 (2016-07)
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 (https://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, essential 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 test specifications for the Diameter protocol on
the Cx and Dx interfaces, 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 (PIXIT)
pro forma specification".
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "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 the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
5 ETSI TS 103 289-2 V2.1.1 (2016-07)
1 Scope
The present document provides the Test Suite Structure (TSS) and Test Purposes (TP) for the test specifications for the
Diameter protocol on the Cx and Dx interfaces as specified in ETSI TS 129 228 [1] and ETSI TS 129 229 [2] in
compliance with the relevant requirements and in accordance with the relevant guidance given in ISO/IEC 9646-7 [5]
and ETSI ETS 300 406 [6].
2 References
2.1 Normative 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
referenced document (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 long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 129 228 (V10.8.0): "Digital cellular telecommunications system (Phase 2+); Universal
Mobile Telecommunications System (UMTS); LTE; IP Multimedia (IM) Subsystem Cx and Dx
Interfaces; Signalling flows and message contents (3GPP TS 29.228 version 10.8.0 Release 10)".
[2] ETSI TS 129 229 (V10.5.0): "Digital cellular telecommunications system (Phase 2+); Universal
Mobile Telecommunications System (UMTS); LTE; Cx and Dx interfaces based on the Diameter
protocol; Protocol details (3GPP TS 29.229 version 10.5.0 Release 10)".
[3] ETSI TS 103 289-1: "Core Network and Interoperability Testing (INT); Diameter Conformance
testing for Cx and Dx interfaces; (3GPP Release 10); Part 1: Protocol Implementation
Conformance Statement (PICS)".
[4] ISO/IEC 9646-1: "Information technology - Open Systems Interconnection - Conformance testing
methodology and framework - Part 1: General concepts".
[5] ISO/IEC 9646-7: "Information technology - Open Systems Interconnection - Conformance testing
methodology and framework - Part 7: Implementation Conformance Statements".
[6] ETSI ETS 300 406: "Methods for testing and Specification (MTS); Protocol and profile
conformance testing specifications; Standardization methodology".
[7] IETF RFC 3588: "Diameter Base Protocol".
2.2 Informative 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
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
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] IETF RFC 2617: "HTTP Authentication: Basic and Digest Access Authentication".
ETSI
6 ETSI TS 103 289-2 V2.1.1 (2016-07)
[i.2] ETSI TS 133 203: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); LTE; 3G security; Access security for IP-based services
(3GPP TS 33.203)".
[i.3] IETF RFC 4005: "Diameter Network Access Server Application".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI TS 129 228 [1], ETSI TS 129 229 [2]
and the following apply:
Abstract Test Method (ATM): Refer to ISO/IEC 9646-1 [4].
Abstract Test Suite (ATS): Refer to ISO/IEC 9646-1 [4].
Implementation Under Test (IUT): Refer to ISO/IEC 9646-1 [4].
Test Purpose (TP): Refer to ISO/IEC 9646-1 [4].
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI TS 129 228 [1], ETSI TS 129 229 [2] and
the following apply:
TP Test Purpose
TSS Test Suite Structure
4 Test configurations
4.1 Introduction
Test purposes of the present document address the IMS functional entities that are accessible via the following
standardized DIAMETER interfaces: Cx and Dx and SIP interfaces: Gm.
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 one or more CSCFs, HSS or SLF communicating
with the system under test (SUT).
NOTE: In a real operating network the different Diameter nodes would not connect directly to each other. The
connection is usually proxied through one or more Diameter Agents. In the following test architecture
figures the Diameter Agent is not explicitly depicted as it is seen as a transparent message handler for
conformance testing purposes.
ETSI
7 ETSI TS 103 289-2 V2.1.1 (2016-07)
4.2 Test configurations using Cx interface
The Cx interface is located between a CSCF and the HSS.
SUT
TS
Cx
CSCF
HSS
Figure 1: Test configuration CF_1Cx
SUT
TS
CSCF1
Cx1
HSS
Cx2
CSCF2
Figure 2: Test configuration CF_2Cx
SUT
TS
Cx1
CSCF1
Cx2
CSCF2 HSS
Cx3
CSCF3
Figure 3: Test configuration CF_3Cx
NOTE 1: Within figure 3 CSCF represents one I-CSCF and two S-CSCF components. Cx interface(DIAMETER
protocol) is located between an HSS and I-CSCF or between an HSS and S-CSCF.
ETSI
8 ETSI TS 103 289-2 V2.1.1 (2016-07)
SUT
TS
TS
Cx Gm
UE
HSS
CSCF
Figure 4: Test configuration CF_1Cx1Gm
NOTE 2: Within figure 4 CSCF represents P-CSCF, I-CSCF and S-CSCF components. Gm interface(SIP protocol)
is located between a UE and P-CSCF. Cx interface(DIAMETER protocol) is located between an HSS and
I-CSCF or between an HSS and S-CSCF.
4.3 Test configurations using the Dx interface
The Dx interface is located between a CSCF and the SLF.
SUT
TS
Dx
CSCF
SLF
Figure 5: Test configuration CF_1Dx
SUT
TS
TS
SLF
Dx
Gm
UE
CSCF
Cx
HSS
Figure 6: Test configuration CF_1Dx1Cx1Gm
ETSI
9 ETSI TS 103 289-2 V2.1.1 (2016-07)
NOTE: Within figure 5 CSCF represents P-CSCF, I-CSCF and S-CSCF components. Gm interface(SIP protocol)
is located between a UE and P-CSCF. Cx interface(DIAMETER protocol) is located between an HSS and
I-CSCF or between an HSS and S-CSCF. Dx interface(DIAMETER protocol) is located between an SLF
and I-CSCF or between an SLF and S-CSCF.
5 Test Suite Structure (TSS) and Test Purposes (TP)
5.1 Test Suite Structure
5.1.1 TP naming convention
TPs are numbered, starting at 001, within each group. Groups are organized according to the TSS.
Table 1: TP identifier naming convention scheme
Identifier: ____
= Test Purpose: fixed to "TP"
= Interface: CX or DX
= type of IUT: HSS, SLF or CSCF
= group MS Message syntax
UA User Authorization commands
SA Server Assignment commands
RT Registration Termination commands
LI Location Information commands
PP Push Profile commands
MA Multimedia authentication commands
ER Error Handling
= sequential number (01 to 99)

5.1.2 Test strategy
As the base standards ETSI TS 129 228 [1] and ETSI TS 129 229 [2] contain no explicit requirements for testing, the
TPs were generated as a result of an analysis of the base standard and the PICS specification ETSI TS 103 289-1 [3].
5.1.3 TP structure
Each TP has been written in a manner which is consistent with all other TPs. The intention of this is to make the TPs
more readable and checkable. A particular structure has been used which is illustrated in table 2. This table should be
read in conjunction with any TP, i.e. please use a TP as an example to facilitate the full comprehension of table 2.
ETSI
10 ETSI TS 103 289-2 V2.1.1 (2016-07)
Table 2: Structure of a single TP
TP part Text Example
Header see table 1
clause 5.2.1.1.2 (see note 4)
A.2/3
Summary Short free text description of the test objective Verify that the IUT processes all
mandatory AVPs in an UL-Request
received due to IP-CAN session
establishment.
Initial Free text description of the condition that the IUT has The IUT has received AF provisions
condition reached before the test purpose applies. information about the AF signalling
(optional) flows between UE and AF.
Configuration Short name of test configuration related to the clause 4 of the CF_1Cx1Gm
(optional) present document
Start point Ensure that the IUT in the

see IETF RFC 3588 [7], clause 5.6 Open state
and/or further actions before e stimulus having sent an AA-Request
if the action is sending/receiving
see below for message structure
Stimulus , see below for message structure on receipt of a
Capabilities-Exchange-Request
(see note 2)
or to require PCC supervision, etc.
Reaction . sends, saves, does, etc.
if the action is sending
see below for message structure
, etc.
Message CapabilitieS-Exchange-Answer, etc.
structure
a) containing a(n) AVP (see note 2)
b) indicating Vendor-Id, etc.
and back to a) or b) (see note 3)
NOTE 1: Text in italics will not appear in TPs and text between <> is filled in for each TP and may differ from one
TP to the next.
NOTE 2: All messages are considered as "valid and compatible" unless otherwise specified in the test purpose.
This includes the presence of all mandatory AVPs as specified in IETF RFC 3588 [7] and in ETSI
TS 129 229 [2].
NOTE 3: An AVP can be embedded into another AVP. This is expressed by indentations, e.g. if Message1 contains
AVP1 and AVP2 where AVP1 has AVP3 embedded this will be expressed like this:
sends/receives Message 1
containing AVP1
containing AVP3
indicating .
containing AVP2
indicating .
NOTE 4: In addition to the clause number there could be specified also following syntaxes:
a) Paragraph symbol ¶ can appear after clause number to make reference more precise. A paragraph
consists of one or more sentences and paragraph ends with newline.
b) Syntax like "item X-Y-Z-." could be also part of reference and it can stand beside clause where X
specifies item number and Y and Z are standing to represent number of dashed line. (ex. "item 3-4-1"
th st th
points to the item 3 and 4 dashed line and 1 dashed line present within previously mentioned 4
dashed line) above syntax can be present within parenthesis or separated with/symbol.

5.2 Test Purposes
5.2.0 PICS references
All PICS items referred to in this clause are as specified in ETSI TS 103 289-1 [3] unless indicated otherwise by
another numbered reference. PICS items are only meant for test selection, therefore only PICS items with status
optional or conditional are explicitly mentioned.
ETSI
11 ETSI TS 103 289-2 V2.1.1 (2016-07)
5.2.1 Cx Interface
5.2.1.1 HSS Role
5.2.1.1.0 Test Selection
IUT takes the role of the HSS; PICS A.2/1 and applicable test configuration is CF_2Cx if not specified differently in the
TP.
HSS shall be properly provisioned for all specified tests.
5.2.1.1.1 Message Syntax
TP_CX_HSS_MS_01 Standards Reference: PICS item:
clause 6 ¶ 2
Summary: Verify that the IUT sends the appropriate Result-Code AVP when mandatory
Visited-Network-Identifier AVP is absent.
Configuration: CF_1Cx
Test purpose: Ensure that the IUT
on receipt of a UA-Request
containing a Session-ID AVP
containing a Public-Identity AVP
indicating the public user identity to be registered
not containing a Visited-Network-Identifier AVP
containing a User-Authorization-Type AVP
indicating REGISTRATION
containing a User-Name AVP
indicating the private user identity
containing a Destination-Host AVP
containing a Destination-Realm AVP
containing a UAR-Flags AVP
with IMS-Emergency-Registration bit not set
sends a UA-Answer
containing a Result-Code AVP
indicating DIAMETER_MISSING_AVP
containing a Failed AVP
indicating missing Visited-Network-Identifier AVP.
Comments:
ETSI
12 ETSI TS 103 289-2 V2.1.1 (2016-07)
TP_CX_HSS_MS_02 Standards Reference: PICS item:
clause 6 ¶ 2
Summary:
Verify that the IUT sends the appropriate Result-Code AVP when mandatory
Public-Identity AVP is absent.
Configuration: CF_1Cx
Test purpose: Ensure that the IUT
on receipt of a UA-Request
containing a Session-ID AVP
not containing a Public-Identity AVP
containing a Visited-Network-Identifier AVP
indicating the domain name of the visited network
containing a User-Authorization-Type AVP
indicating REGISTRATION
containing a User-Name AVP
indicating the private user identity
containing a Destination-Host AVP
containing a Destination-Realm AVP
containing a UAR-Flags AVP
with IMS-Emergency-Registration bit not set
sends a UA-Answer
containing a Result-Code AVP
indicating DIAMETER_MISSING_AVP
containing a Failed AVP
indicating missing Public-Identity AVP.
Comments:
5.2.1.1.2 User Authorization
In the test purposes below, an HSS properly provisioned means:
• Some users profile with barred Public User Identity are defined.
• Some users profile with barred Public User Identity and not allowed to roam are defined.
• Some users profile with barred Public User Identity and not allowed to register are defined.
• Some users profile with not barred Public User Identity are defined.
In addition, an Initial registration involves that there is no previously assigned S-CSCF for this user (first registration).
ETSI
13 ETSI TS 103 289-2 V2.1.1 (2016-07)
TP_CX_HSS_UA_01 Standards Reference: PICS item:
clause 6.1.1 and tables 6.1.1.1 and
6.1.1.2 and ETSI TS 129 229 [2],
clauses 6.1.1 and 6.1.2
Summary: Verify that the IUT successfully processes all mandatory AVPs in a UA-Request received
due to an UE initial registration.
Configuration: CF_1Cx
Test purpose: Ensure that the IUT
on receipt of a UA-Request
containing a Session-ID AVP
containing a Vendor-Specific-Application-Id AVP
containing an Auth-Session-State AVP
indicating NO_STATE_MAINTAINED
containing an Origin-Host AVP
containing an Origin-Realm AVP
containing a Public-Identity AVP
indicating the public user identity to be registered
containing a Visited-Network-Identifier AVP
indicating the domain name of the visited network
containing a User-Authorization-Type AVP
indicating REGISTRATION
containing a User-Name AVP
indicating the private user identity
containing a Destination-Host AVP
containing a Destination-Realm AVP
containing a UAR-Flags AVP
with IMS-Emergency-Registration bit not set
sends a UA-Answer
containing a Session-ID AVP
containing a Vendor-Specific-Application-Id AVP
containing an Auth-Session-State AVP
containing an Origin-Host AVP
containing an Origin-Realm AVP
not containing a Result-Code AVP
containing an Experimental-Result AVP
containing an Experimental-Result-Code AVP
indicating DIAMETER_FIRST_REGISTRATION.
Comments: IMS UE Action: Initial registration
The I-CSCF does not request for S-CSCF capabilities.

ETSI
14 ETSI TS 103 289-2 V2.1.1 (2016-07)
TP_CX_HSS_UA_02 Standards Reference: PICS item:
st
clause 6.1.1.1 items 1, 2, 4 (1 dash),
nd st
5 (2 dash), 6 (1 dash) and
tables 6.1.1.1 and 6.1.1.2
Summary: Verify that the IUT when the User-Authorization-Type is absent within UA-Request then the
IUT returns the stored S-CSCF name, no S-CSCF capabilities and the appropriate
experimental result in the UA-Answer.
Initial condition: - Private and Public User Identity exist in IUT
- Public User Identity matches a distinct Public User Identity in IUT
- Public User Identity received in Request is associated to Private User Identity in
IUT
- Public User Identity received in Request is not barred
- User-Authorization-Type is absent and Public User Identity is allowed to roam in
the visited network and authorized to register
- Public User Identity is registered
Test purpose: Ensure that the IUT
on receipt of a UA-Request
containing a Public-Identity AVP
indicating the public user identity which is already registered
containing a User-Name AVP
indicating a known private user identity
not containing a User-Authorization-Type AVP
sends a UA-Answer
not containing a Result-Code AVP
containing an Experimental-Result AVP
containing an Experimental-Result-Code AVP
indicating DIAMETER_SUBSEQUENT_REGISTRATION
containing a Server-Name AVP
indicating the name of the assigned S-CSCF
not containing a Server-Capabilities AVP.
Comments: IMS UE Action: Registration (Already Registered - see ETSI TS 129 228 [1], clause A.4.1).
The I-CSCF does not request for S-CSCF capabilities.

TP_CX_HSS_UA_03 Standards Reference: PICS item:
st
clause 6.1.1.1 items 4 (1 dash),
nd st
5 (2 dash), 6 (1 dash), and
tables 6.1.1.1 and 6.1.1.2
Summary: Verify that the IUT when the User-Authorization-Type is equal to REGISTRATION within
UA-Request then the IUT returns the stored S-CSCF name, no S-CSCF capabilities and the
appropriate experimental result in the UA-Answer.
Initial condition: - Private and Public User Identity exist in IUT
- Public User Identity matches a distinct Public User Identity in IUT
- Public User Identity received in Request is associated to Private User Identity in IUT
- Public User Identity received in Request is not barred
- User-Authorization-Type is set to REGISTRATION and Public User Identity is allowed
to roam in the visited network and authorized to register
- Public User Identity is registered
Test purpose: Ensure that the IUT
on receipt of a UA-Request
containing a Public-Identity AVP
indicating the public user identity which is already registered
containing a User-Name AVP
indicating a known private user identity
containing a User-Authentication-Type AVP
indicating REGISTRATION,
sends a UA-Answer
not containing a Result-Code AVP
containing an Experimental-Result AVP
containing an Experimental-Result-Code AVP
indicating DIAMETER_SUBSEQUENT_REGISTRATION
containing a Server-Name AVP
indicating the name of the assigned S-CSCF
not containing a Server-Capabilities AVP.
Comments: IMS UE Action: Registration (Already Registered - see ETSI TS 129 228 [1], clause A.4.1).
The I-CSCF does not request for S-CSCF capabilities.

ETSI
15 ETSI TS 103 289-2 V2.1.1 (2016-07)
TP_CX_HSS_UA_04 Standards Reference: PICS item:
st
clauses 6.1.1.1 items 4 (1 dash),
th st
5 (4 dash), 6 (1 dash) and
tables 6.1.1.1 and 6.1.1.2
Summary: Verify that the IUT when the User-Authorization-Type is equal to DE-REGISTRATION
within UA-Request then the IUT returns the stored S-CSCF name, no S-CSCF capabilities
and the appropriate experimental result in the UA-Answer.
Initial condition: - Private and Public User Identity exist in IUT
- Public User Identity matches a distinct Public User Identity in IUT
- Public User Identity received in Request is associated to Private User Identity in
IUT
- Public User Identity received in Request is not barred
- User-Authorization-Type set to DE-REGISTRATION
- Public User Identity is registered
Test purpose: Ensure that the IUT
on receipt of a UA-Request
containing a Public-Identity AVP
indicating the public user identity which is already registered
containing a User-Name AVP
indicating a known private user identity
containing a User-Authentication-Type AVP
indicating DE-REGISTRATION,
sends a UA-Answer
containing a Result-Code AVP
indicating DIAMETER_SUCCESS
containing a Server-Name AVP
indicating the name of the assigned S-CSCF
not containing a Server-Capabilities AVP.
Comments: IMS UE Action: Registration (Already Registered - see ETSI TS 129 228 [1], clause A.4.1).
The I-CSCF does not request for S-CSCF capabilities.

TP_CX_HSS_UA_05 Standards Reference: PICS item:
st
clause 6.1.1.1 items4 (1 dash),
rd th
5 (3 dash), 6 (9 dash) and
tables 6.1.1.1 and 6.1.1.2
Summary: Verify that the IUT when IMS-Emergency Registration is set and
User-Authorization-Type is absent within UA-Request then the IUT does not return any
S-CSCF name but does return an experimental result code in the UA-Answer.
Initial condition: - Private and Public User Identity exist in IUT
- Public User Identity matches a distinct Public User Identity in IUT
- Public User Identity received in Request is associated to Private User Identity in
IUT
- Public User Identity received in Request is barred and it is an IMS Emergency
Registration
- User-Authorization-Type is absent
- Public User Identity is not registered yet
Configuration:
CF_1Cx
Test purpose: Ensure that the IUT
on receipt of a UA-Request
containing a Public-Identity AVP
indicating the public user identity to be registered
containing a User-Name AVP
indicating the associated private user identity
containing a UAR-Flags AVP
with IMS-Emergency-Registration bit set
not containing a User-Authorization-Type AVP
sends a UA-Answer
not containing a Result-Code AVP
containing an Experimental-Result AVP
containing an Experimental-Result-Code AVP
indicating DIAMETER_FIRST_REGISTRATION
not containing a Server-Name AVP.
Comments: IMS UE Action: Initial Registration.
The I-CSCF does not request for S-CSCF capabilities.

ETSI
16 ETSI TS 103 289-2 V2.1.1 (2016-07)
TP_CX_HSS_UA_06 Standards Reference: PICS item:
st
clause 6.1.1.1 items 4 (1 dash),
nd st
5 (2 dash), 6 (1 dash) and
tables 6.1.1.1 and 6.1.1.2
Summary: Verify that the IUT when IMS-Emergency Registration is set and User-Authorization-Type is
equal to REGISTRATION within UA-Request then the IUT does not return any S-CSCF name
but does return an experimental result code in the UA-Answer.
Initial condition: - Private and Public User Identity exist in IUT
- Public User Identity matches a distinct Public User Identity in IUT
- Public User Identity received in Request is associated to Private User Identity in IUT
- Public User Identity received in Request is not barred
- User-Authorization-Type is set to REGISTRATION and Public User Identity is
allowed to roam in the visited network and authorized to register
- Public User Identity is registered
Test purpose: Ensure that the IUT
on receipt of a UA-Request
containing a Public-Identity AVP
indicating a non barred public user identity
containing a User-Name AVP
indicating the associated private user identity
containing a User-Authentication-Type AVP
indicating REGISTRATION
containing a UAR-Flags AVP
with IMS-Emergency-Registration bit not set
sends a UA-Answer
not containing a Result-Code AVP
containing an Experimental-Result AVP
containing an Experimental-Result-Code AVP
indicating DIAMETER_SUBSEQUENT_REGISTRATION
containing a Server-Name AVP
indicating the name of the assigned S-CSCF
not containing a Server-Capabilities AVP.
Comments: IMS UE Action: Registration (Already registered - see ETSI TS 129 228 [1], clause A.4.1).
The I-CSCF does not request for S-CSCF capabilities.

ETSI
17 ETSI TS 103 289-2 V2.1.1 (2016-07)
TP_CX_HSS_UA_07 Standards Reference: PICS item:
rd
clause 6.1.1.1 items 4 (3 dash),
nd st
5 (2 dash), 6 (1 dash) and
tables 6.1.1.1 and 6.1.1.2
Summary: Verify that the IUT checks whether the Public User Identity received in a subsequent
UA-Request is barred from the establishment of multimedia sessions. - On receipt of
UA-Request with other non barred Public User Identity and IMS-Emergency Registration is not
set and User-Authorization-Type is equal to REGISTRATION or is absent then the IUT returns
the S-CSCF name, no S-CSCF capabilities and an appropriate experimental result code in the
UA-Answer.
Initial condition: - Private and Public User Identity exist in IUT
- Public User Identity matches a distinct Public User Identity in IUT
- Public User Identity received in Request is associated to Private User Identity in IUT
- Public User Identity received in Request is not barred and within IUT there are other
non-barred Public User Identities to be implicitly registered
- User-Authorization-Type is absent and Public User Identity is allowed to roam in the
visited network and authorized to register
- Public User Identity is registered
Test purpose: Ensure that the IUT
on receipt of a UA-Request
containing a Public-Identity AVP
indicating a non barred public user identity
containing a User-Name AVP
indicating the associated private user identity
containing a UAR-Flags AVP
with IMS-Emergency-Registration bit not set
sends a UA-Answer
not containing a Result-Code AVP
containing an Experimental-Result AVP
containing an Experimental-Result-Code AVP
indicating DIAMETER_SUBSEQUENT_REGISTRATION
containing a Server-Name AVP
indicating the name of the assigned S-CSCF
not containing a Server-Capabilities AVP.
Comments: IMS UE Action: Registration (Already registered - see ETSI TS 129 228 [1], clause A.4.1).
The I-CSCF does not request for S-CSCF capabilities.

ETSI
18 ETSI TS 103 289-2 V2.1.1 (2016-07)
TP_CX_HSS_UA_08 Standards Reference: PICS item:
st
clause 6.1.1.1 items 4 (1 dash),
th
5 (7 dash) and tables 6.1.1.1 and
6.1.1.2
Summary: Verify that the IUT when IMS-Emergency Registration is set and if User-Authorization-Type
is equal to REGISTRATION_AND_CAPABILITIES within UA-Request then the IUT does
not return any S-CSCF name and does return the appropriate result code in the UA-
Answer.
Initial condition:
- Private and Public User Identity exist in IUT
- Public User Identity matches a distinct Public User Identity in IUT
- Public User Identity received in Request is associated to Private User Identity in
IUT
- Public User Identity received in Request is barred and it is an IMS Emergency
Registration
- User-Authorization-Type is REGISTRATION_AND_CAPABILITIES
- Public User Identity is registered
Test purpose: Ensure that the IUT
on receipt of a UA-Request
containing a Public-Identity AVP
indicating a public user identity
containing a User-Name AVP
indicating the associated private user identity
containing a User-Authentication-Type AVP
indicating REGISTRATION_AND_CAPABILITIES
containing a UAR-Flags AVP
with IMS-Emergency-Registration bit set
sends a UA-Answer
containing a Result-Code AVP
indicating DIAMETER_SUCCESS
not containing a Server-Name AVP.
Comments: IMS UE Action: Registration (Already registered - see ETSI TS 129 228 [1], clause A.4.1).
The I-CSCF requests for S-CSCF capabilities.

TP_CX_HSS_UA_09 Standards Reference: PICS item:
th
clause 6.1.1.1 item 5 (6 dash) and
tables 6.1.1.1 and 6.1.1.2
Summary:
Verify that the IUT checks the User-Authorization-Type received in the UA-Request if
IMS-Emergency Registration is not set and User-Authorization-Type is equal to
REGISTRATION_AND_CAPABILITIES then the IUT does not return S-CSCF name and
does return the appropriate result code in the UA-Answer.
Initial condition: - Private and Public User Identity exist in IUT
- Public User Identity matches a distinct Public User Identity in IUT
- Public User Identity received in Request is associated to Private User Identity in
IUT
- Public User Identity received in Request is barred and it is an IMS Emergency
Registration
- User-Authorization-Type is REGISTRATION_AND_CAPABILITIES and Public
User Identity is allowed to roam in the visited network and authorized to register
- Public User Identity is registered
Test purpose: Ensure that the IUT
on receipt of a UA-Request
containing a Public-Identity AVP
indicating public user identity
containing a User-Name AVP
indicating the associated private user identity
containing a User-Authentication-Type AVP
indicating REGISTRATION_AND_CAPABILITIES
containing a UAR-Flags AVP
with IMS-Emergency-Registration bit not set
sends a UA-Answer
containing a Result-Code AVP
indicating DIAMETER_SUCCESS
not containing a Server-Name AVP.
Comments: IMS UE Action: Registration (Already registered - see ETSI TS 129 228 [1], clause A.4.1).
The I-CSCF requests for S-CSCF capabilities.

ETSI
19 ETSI TS 103 289-2 V2.1.1 (2016-07)
TP_CX_HSS_UA_10 Standards Reference: PICS item:
st
clause 6.1.1.1 items 1, 2, 4 (1 dash),
th st
5 (4 dash), 6 (1 dash) and
tables 6.1.1.1 and 6.1.1.2
Summary: Verify that the IUT when the User-Authorization-Type is equal to DE-REGISTRATION
within UA-Request then the IUT returns the stored S-CSCF name, no S-CSCF capabilities
and the appropriate result code in the UA-Answer.
Initial condition: - Private and Public User Identity exist in IUT
- Public User Identity matches a distinct Public User Identity in IUT
- Public User Identity received in Request is associated to Private User Identity in
IUT
- Public User Identity received in Request is barred and it is an IMS Emergency
Registration
- User-Authorization-Type set to DE-REGISTRATION
- Public User Identity is registered
Test purpose: Ensure that the IUT
on receipt of a UA-Request
containing a Public-Identity AVP
indicating non-barred public user identity
allow to roam
indicating the public user identity which is already registered
containing a User-Name AVP
indicating a known private user identity
containing a User-Authentication-Type AVP
indicating DE-REGISTRATION
containing a UAR-Flags AVP
with IMS-Emergency-Registration bit set,
sends a UA-Answer
containing a Result-Code AVP
indicating DIAMETER_SUCCESS
containing a Server-Name AVP
indicating the name of the assigned S-CSCF
not containing a Server-Capabilities AVP.
Comments: IMS UE Action: De-Registration (Already Registered Public User- see ETSI TS 129 228 [1],
clauses A.4.1 and A.4.3).
The I-CSCF does not request for S-CSCF capabilities.

ETSI
20 ETSI TS 103 289-2 V2.1.1 (2016-07)
TP_CX_HSS_UA_11 Standards Reference: PICS item:
st
clause 6.1.1.1 items 1, 2, 4 (1 dash),
th nd
5 (4 dash), 6 (2 dash) and
tables 6.1.1.1 and 6.1.1.2
Summary: Verify that the IUT when receives UA-Request where the Public User Identity is
unregistered and the User-Authorization-Type is equal to DE-REGISTRATION then the
IUT returns the stored S-CSCF name, no S-CSCF capabilities and the appropriate result
code in the UA-Answer.
Initial condition:
- Private and Public User Identity exist in IUT
- Public User Identity matches a d
...