A.21 Activation and deactivation of Supplementary Services / 5GS
34.229-53GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 5: Protocol conformance specification using 5G System (5GS)Release 16TSUser Equipment (UE) conformance specification
Generic test procedure for signalling between UE and XCAP server to activate or deactivate a supplementary service.
Test procedure:
0a) Pre-configurations:
– The UE is in state 3N-A, registered to IMS on an IMS PDU session and at least one PDU session for Internet active according to TS 38.508-1 [21], clause 4.5.3.
NOTE: All XCAP signalling shall occur on the Internet PDU session according to NG.114 [31], Annex C.3.
0b) At the SS an HTTP server is established at port 80 to simulate the XCAP server.
NOTE: TLS is not a test requirement i.e. the UE uses port 80 to access XCAP and BSF servers and SS does not redirect the UE to use HTTPS (port 443).
1) Activation of the specific Supplementary Service is triggered at the UE with appropriate MMI command.
2) The UE sends an initial HTTP request to the SS.
3) In case of HTTP Digest XCAP authentication when the UE does not provide correct authorization credentials within its initial request:
3a) the SS shall challenge the UE by sending a “401 Unauthorized” response to it.
When the UE supports GBA for XCAP authentication and GBA shall be used according to test requirements or test configuration, the SS shall indicate bootstrapped security association is required as specified in TS 24.109 [43] clause 5.2.4 and the generic procedure A.22 shall be applied.
3b) the UE repeats the HTTP request including a valid digest response in the authorization header.
The SS shall check the digest response taking into account the user’s prearranged password for (pure) HTTP digest authentication, or, for GBA, being derived from the key material (Ks) using key derivation function as specified in 3GPP TS 33.220 [44].
4) The SS sends a 200 (OK) response
5) Optionally UE and SS exchange a sequence of additional HTTP requests and responses. In this sequence the UE may query the contents of the simservs document or selected parts of it.
In general the HTTP requests are responded with a 200 “Ok” response but in case of a GET request to a non-existing node the SS shall respond with a 404 “File Not Found”.
6) The simservs document is checked according to specific test requirements.
7) Deactivation of supplementary service is triggered at the UE with appropriate MMI command.
8) UE and SS exchange a sequence of HTTP requests and responses. In this sequence the UE may query the contents of the simservs document or selected parts of it.
In general the HTTP requests are responded with a 200 “Ok” response but in case of a GET request to a non-existing node the SS shall respond with a 404 “File Not Found”.
9) The simservs document is checked according to specific test requirements.
Expected sequence:
Step |
Direction |
Message/Procedure |
Comment |
|
UE |
SS |
|||
1 |
Make the UE attempt activation of supplementary service |
|||
2 |
🡪 |
Initial HTTP Request |
NOTE 1 |
|
3 |
EXCEPTION: steps 3a and 3b describe behaviour in case of HTTP Digest XCAP authentication when the UE does not provide correct authorization credentials within its initial request |
|||
3a |
🡨 |
HTTP Response: “401 Unauthorized” |
||
EXCEPTION: By default, when the UE supports GBA for XCAP authentication, GBA shall be used according to the generic test procedure A.22. NOTE: See TS 34.229-2 [3] for cases where the default does not apply. |
(optional) GBA authentication at BSF server |
|||
3b |
🡪 |
HTTP Request with valid authorization credentials |
The SS checks the digest response |
|
4 |
🡨 |
HTTP Response: “200 OK” |
||
5 |
EXCEPTION: steps 5a and 5b describe further optional message exchange between the UE and the SS; steps 5a and steps 5b can be repeated several times this exchange of information is considered to be finished when there is no further HTTP request sent by the UE within 20 seconds after the previous request |
|||
5a |
🡪 |
HTTP Request |
NOTE 1 |
|
5b |
🡨 |
HTTP Response: “200 OK” or “404 File Not Found” |
NOTE 3 |
|
6 |
Check: Does the simservs document stored in the SS contain the information supplied by the UE as required by the test requirements of the specific test case? |
This is done by fetching the whole simservs document from the XCAP server and checking its content against the respective XML file (according to the XSD definitions for the respective supplementary service) |
||
7 |
Make the UE attempt deactivation of supplementary service |
|||
8 |
EXCEPTION: steps 8a and 8b describe the mandatory message exchange between the UE and the SS which can be repeated several times; this exchange of information is considered to be finished when there is no further HTTP request sent by the UE within 20 seconds after the previous request |
|||
8a |
🡪 |
HTTP Request |
NOTE 1 |
|
8b |
🡨 |
HTTP Response: “200 OK” or “404 File Not Found” |
NOTE 3 |
|
9 |
Check: Does the simservs document stored in the SS contain the information supplied by the UE as required by the test requirements of the specific test case? |
This is done by fetching the whole simservs document from the XCAP server and checking its content against the respective XML file (according to the XSD definitions for the respective supplementary service) |
||
NOTE 1: The HTTP requests sent by the UE are processed by an XCAP server implementation at the SS to modify or query the contents of the simservs document. NOTE 2: Void. NOTE 3: “404 File Not Found” is sent as response for a GET request to a non-existing node |
Specific Message Contents
HTTP Requests sent by the UE (step 2, 3b, 5a, 8a)
Header/param |
Cond |
Value/remark |
Rel |
Reference |
---|---|---|---|---|
Request-Line |
RFC 2616 [46] |
|||
Method |
GET, PUT, DELETE |
|||
Request-URI |
XCAP URI referring to the simservs document as specified in RFC 4825 [45]; the document selector of such XCAP URI consists of – Configured XCAP root URI – simservs.ngn.etsi.org – users – same public user id as the default public user identity received in P-Associated-URI header in 200 OK for REGISTER (NOTE 4). – simservs.xml (in this order, separated by a slash); According to RFC 4825 [45] the node selector of the XCAP URI shall identify a valid part of a simservs document or whole document itself (NOTE 2). |
|||
Version |
HTTP 1.1 |
|||
User-Agent |
A1 |
RFC 2616 [46] |
||
Product token |
3gpp-gba |
TS 24.109 [43] |
||
Authorization |
present in case of HTTP Digest XCAP authentication in the initial request or in the request following the “401 Unauthorized” response Digest |
RFC 2617 [16] RFC 3310 [17] |
||
username |
NOT A2 |
As configured in the UE (NOTE 5). Same public user id as the default public user identity received in P-Associated-URI header in 200 OK for REGISTER (NOTE 6). |
||
username |
A2 |
B-TID as obtained from GBA authentication |
||
realm |
same value as received in the realm directive in the WWW Authenticate header sent by SS |
|||
nonce |
same value as in WWW-Authenticate header sent by SS |
|||
opaque |
same value as sent by the SS in “401 Unauthorized” |
|||
digest-uri |
same URI as used in Request-URI |
|||
qop-value |
auth |
|||
cnonce-value |
value assigned by UE affecting the response calculation |
|||
nonce-count |
1 |
|||
response |
NOT A2 |
response calculated by UE using prearranged password |
||
response |
A2 |
response calculated by UE using password derived from the key material of the GBA authentication according to Generic key derivation as specified in Annex B.3 of TS 33.220 [44] using static string “gba-me” as parameter P0 in Annex B.3. |
||
algorithm |
MD5 |
|||
Content-Type |
present for HTTP PUT method |
RFC 2616 [46] |
||
media-type |
application/vnd.etsi.simservs+xml or application/xcap-el+xml or application/xcap-att+xml (NOTE 3) |
|||
Message-body |
present for HTTP PUT method: XML fragment of given node |
RFC 2616 [46] RFC 4825 [45] |
||
NOTE 1: Any other headers are ignored. NOTE 2: The SS shall check and make sure that the syntax of the node selector expressions is in compliance to clause 6.2 of RFC 4825 [45]. NOTE 3: the media-type depends on the kind of node being accessed by the Request-URI: document, element or attribute (see RFC 4825 [45]). NOTE 4: According A.12/38 3GPP TS 34.229-2 [3]. NOTE 5: Shall be present if A.12/37 3GPP TS 34.229-2 [3] is yes. NOTE 6: Shall be present if A.12/37 3GPP TS 34.229-2 [3] is no. |
Condition |
Explanation |
A1 |
UE supports GBA authentication |
A2 |
GBA authentication shall be applied (according to test requirements or test configuration) |
HTTP Responses (step 4, 5b, 8b2) – normal case
Header/param |
Cond |
Value/remark |
Rel |
Reference |
---|---|---|---|---|
Status-Line |
RFC 2616 [46] |
|||
Version |
HTTP 1.1 |
|||
Code |
200 |
|||
Reason |
OK |
|||
Server |
RFC 2616 [46] |
|||
product |
XCAP-Server |
|||
Date |
RFC 2616 [46] |
|||
HTTP-date |
valid date according to RFC 2616 [46] section 3.3.1 |
|||
ETag |
RFC 2616 [46] |
|||
entity-tag |
hextring: value starting with "478fb2358f700" and incremented after each PUT operation |
|||
Content-Type |
present for HTTP GET method |
RFC 2616 [46] |
||
media-type |
application/vnd.etsi.simservs+xml or application/xcap-el+xml or application/xcap-att+xml (NOTE 1) |
|||
Content-Length |
RFC 2616 [46] |
|||
value |
length of the message body |
|||
Message-body |
present for GET method: XML fragment of given node |
RFC 2616 [46] RFC 4825 [45] |
||
NOTE 1: the media-type depends on the kind of node being accessed with the HTTP GET method: document, element or attribute (see RFC 4825 [45]). |
HTTP Responses (step 5b, 8b) – Response for GET request to a non-existing node
Header/param |
Cond |
Value/remark |
Rel |
Reference |
---|---|---|---|---|
Status-Line |
RFC 2616 [46] |
|||
Version |
HTTP 1.1 |
|||
Code |
404 |
|||
Reason |
File Not Found |
|||
Server |
RFC 2616 [46] |
|||
product |
XCAP-Server |
|||
Date |
RFC 2616 [46] |
|||
HTTP-date |
valid date according to RFC 2616 [46] section 3.3.1 |
HTTP Response (step 3a) for HTTP Digest XCAP authentication
Header/param |
Cond |
Value/remark |
Rel |
Reference |
---|---|---|---|---|
Status-Line |
RFC 2616 [46] |
|||
Version |
HTTP 1.1 |
|||
Code |
401 |
|||
Reason |
Unauthorized |
|||
Server |
RFC 2616 [46] |
|||
product |
XCAP-Server |
|||
Date |
RFC 2616 [46] |
|||
HTTP-date |
valid date according to RFC 2616 [46] section 3.3.1 |
|||
WWW-Authenticate |
RFC 2616 [46] |
|||
realm |
NOT A1 |
home domain name as stored in EFDOMAIN or home domain name derived from the IMSI |
||
realm |
A1 |
containing two parts delimited by "@" (see TS 24.109 [43] clause 5):
|
||
algorithm |
MD5 |
|||
qop-value |
auth |
|||
nonce |
Base 64 encoding of RAND and AUTN |
|||
opaque |
arbitrary value (to be returned by the UE in subsequent request) |
Condition |
Explanation |
A1 |
UE supports GBA authentication and GBA authentication shall be applied (according to test requirements or test configuration) |