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):

  • 3GPP-bootstrapping
  • home domain name as stored in EFDOMAIN or home domain name derived from the IMSI

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)