C.29 Generic test procedures for Supplementary Services – EPS

34.229-13GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 1: Protocol conformance specificationRelease 16TSUser Equipment (UE) conformance specification

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

C.29.1 Procedures for activation and deactivation of Supplementary Services – EPS

Generic test procedure for signalling between UE and XCAP server to activate or deactivate a supplementary service.

Test procedure:

0a) Pre-configurations:

In case of EUTRA

– The UE is IMS registered before any activation or deactivation of Supplementary Services is triggered. This will ensure more deterministic UE behaviours.

– The UE has established a 2^nd PDN connectivity for IMS XCAP signalling. In case of EUTRA the UE may either be configured to re-use the Internet APN for XCAP signalling or the UE uses a specific XCAP-only APN:

– in case of Internet APN the PDN connectivity is established during the initial registration procedure according to TS 36.508 clause 4.5.2 [94] applying XCAP_SIGNALLING.

– in case of a specific XCAP-only APN the generic procedure according to TS 36.508 clause 4.5A.14 [94] shall be applied.

– During these procedures the UE may request a DNS server address via NAS signalling and as parallel behaviour the UE may resolve the IP address of the XCAP server via DNS.

In case of WLAN the UE is configured to use XCAP requests with PDN according TS 36.508 clause 4.5A.25 or without any PDN connection according A.12/49 3GPP TS 34.229-2 [5].

In case of fixed broadband access, the UE is configured to use XCAP requests according A.12/50 TS 34.229‑2 [5].

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 [119] clause 5.2.4 and the generic procedure according to C.29.2 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 [120].

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 C.29.2. NOTE: See TS 34.229-2 [5] 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 2 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	Reference
Request-Line			RFC 2616 [69]
Method		GET, PUT, DELETE
Request-URI		XCAP URI referring to the simservs document as specified in RFC 4825 [70]; 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 [70] 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 [69]
Product token		3gpp-gba	TS 24.109 [119]
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 [120] using static string “gba-me” as parameter P0 in Annex B.3.
algorithm		MD5
Content-Type		present for HTTP PUT method	RFC 2616 [69]
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 [69] RFC 4825 [70]
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 [70]. NOTE 3: the media-type depends on the kind of node being accessed by the Request-URI: document, element or attribute (see RFC 4825 [70]). NOTE 4: According A.12/38 3GPP TS 34.229-2 [5]. NOTE 5: Shall be present if A.12/37 3GPP TS 34.229-2 [5] is yes. NOTE 6: Shall be present if A.12/37 3GPP TS 34.229-2 [5] 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	Value/remark	Reference
Status-Line		RFC 2616 [69]
Version	HTTP 1.1
Code	200
Reason	OK
Server		RFC 2616 [69]
product	XCAP-Server
Date		RFC 2616 [69]
HTTP-date	valid date according to RFC 2616 [69] section 3.3.1
ETag		RFC 2616 [69]
entity-tag	hextring: value starting with "478fb2358f700" and incremented after each PUT operation
Content-Type	present for HTTP GET method	RFC 2616 [69]
media-type	application/vnd.etsi.simservs+xml or application/xcap-el+xml or application/xcap-att+xml (NOTE 1)
Content-Length		RFC 2616 [69]
value	length of the message body
Message-body	present for GET method: XML fragment of given node	RFC 2616 [69] RFC 4825 [70]
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 [70]).

HTTP Responses (step 5b, 8b) – Response for GET request to a non-existing node

Header/param	Value/remark	Reference
Status-Line		RFC 2616 [69]
Version	HTTP 1.1
Code	404
Reason	File Not Found
Server		RFC 2616 [69]
product	XCAP-Server
Date		RFC 2616 [69]
HTTP-date	valid date according to RFC 2616 [69] section 3.3.1

HTTP Response (step 3a) for HTTP Digest XCAP authentication

Header/param	Cond	Value/remark	Reference
Status-Line			RFC 2616 [69]
Version		HTTP 1.1
Code		401
Reason		Unauthorized
Server			RFC 2616 [69]
product		XCAP-Server
Date			RFC 2616 [69]
HTTP-date		valid date according to RFC 2616 [69] section 3.3.1
WWW-Authenticate			RFC 2616 [69]
realm	NOT A1	home domain name as stored in EF_DOMAIN or home domain name derived from the IMSI
realm	A1	containing two parts delimited by "@" (see TS 24.109 [119] clause 5): 3GPP-bootstrapping home domain name as stored in EF_DOMAIN 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)

C.29.2 Procedure for GAA XCAP authentication

The generic test procedure for GBA authentication between UE and BSF.

The generic test procedure for GAA XCAP authentication is referred to the bootstrapping procedure in TS 33.220 [120], clause 4.5.2 and TS 24.109 [119] clause 4.2.

Test procedure:

0a) Pre-configurations:
The UE may resolve the IP address for the BSF server via DNS.

0b) At the SS an HTTP server is established at port 80 to simulate the BSF server.

UE sends initial GET to the BSF server.
BSF server responds with “401 Unauthorized”.
UE sends GET with Authorization header to the BSF server.
BSF server responds with "200 OK" when the UE has provided a valid Authorization header.

Expected sequence:

Step	Direction		Message	Comment
	UE	SS
1	🡪		HTTP Request
2	🡨		HTTP Response: “401 Unauthorized”
3	🡪		HTTP Request with valid authorization credentials
4	🡨		HTTP Response: “200 OK”

Specific Message Contents

HTTP Request (step 1)

Header/param	Value/remark	Reference
Request-Line		RFC 2616 [69]
Method	GET
Request-URI	Request-URI
Version	HTTP/ DIGIT.DIGIT
Host		RFC 2616 [69]
host	bsf.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org (when no ISIM available on the UICC) , optionally followed by port 80 or bsf.domain name (when using ISIM) , optionally followed by port 80	RFC 2616 [69]
User-Agent		RFC 2616 [69]
Product token	3gpp-gba-tmpi	TS 24.109 [119]
Authorization	Digest	RFC 2616 [69] RFC 2617 [16] RFC 3310 [17]

username	private user identity as stored in EF_IMPI(when using ISIM) or private user identity derived from IMSI (when no ISIM available on the UICC) or the value of the TMPI if one has been associated with the private user identity as described in 3GPP TS 33.220 [120]

realm	bsf.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org (when no ISIM available on the UICC) or bsf.domain name (when using ISIM)
nonce	empty value
digest-uri	absoluteURL http://<BSF address>/ or abs_path "/"
response	empty value

NOTE 1: All choices for applicable conditions are described for each header.

HTTP Response (step 2)

Header/param	Value/remark	Reference
Status-Line		RFC 2616 [69]
Version	HTTP/1.1
Code	401
Reason	Unauthorized
Server		RFC 2616 [69]
product	BSF-Server
Date		RFC 2616 [69]
HTTP-date	valid date according to RFC 2616 [69] section 3.3.1
WWW-Authenticate		RFC 2616 [69] RFC 2617 [16]
challenge	Digest
realm	same value as received in step 1
algorithm	AKAv1-MD5
qop-value	auth-int
nonce	Base 64 encoding of RAND and AUTN
opaque	5ccc069c403ebaf9f0171e9517f30e41

HTTP Request (step 3)

Header/param	Value/remark	Reference
Request-Line		RFC 2616 [69]
Method	GET
Request-URI	Request-URI
Version	HTTP/ DIGIT.DIGIT
Host		RFC 2616 [69]
host	bsf.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org (when no ISIM available on the UICC), optionally followed by port 80 or bsf.domain name (when using ISIM), optionally followed by port 80	RFC 2616 [69]
Authorization	Digest	RFC 2616 [69] RFC 2617 [16] RFC 3310 [17]

username	private user identity as stored in EF_IMPI(when using ISIM) or private user identity derived from IMSI (when no ISIM available on the UICC) or the value of the TMPI if one has been associated with the private user identity as described in 3GPP TS 33.220 [120]

realm	same value as received in the realm directive in the WWW Authenticate header sent by SS
opaque	5ccc069c403ebaf9f0171e9517f30e41
digest-uri	absoluteURL http://<BSF address>/ or abs_path "/"
cnonce-value	value assigned by UE affecting the response calculation
nonce-count	00000001
response	response calculated by UE
algorithm	AKAv1-MD5

NOTE 1: All choices for applicable conditions are described for each header.

HTTP Response (step 4)

Header/param	Value/remark	Reference
Status-Line		RFC 2616 [69]
Version	HTTP/1.1
Code	200
Reason	OK
Server		RFC 2616 [69]
Product token	3gpp-gba-tmpi
Date		RFC 2616 [69]
HTTP-date	valid date according to RFC 2616 [69] section 3.3.1
Authentication-Info		RFC 2616 [69] RFC 2617 [16]
message-qop	qop=auth-int
rspauth	see Note 1
cnonce	same value as received in step 3
nc	1

Content-Type		RFC 2616 [69]
media-type	application/vnd.3gpp.bsf+xml
Content-Length		RFC 2616 [69]
value	length of the message body
Message-body	<?xml version="1.0" encoding="UTF-8"?> <BootstrappingInfo xmlns="uri:3gpp-gba"> <btid>B-TID</btid> <lifetime>key lifetime</lifetime> </BootstrappingInfo> with B-TID Bootstrapping – Transaction Identifier according to TS 33.220 [120] clause 4.5.2: base64encode(RAND)@BSF_servers_domain_name – key lifetime lifetime of the key material formatted according to XSD dateTime data type	RFC 2616 [69] TS 24.109 Annex C [119]

NOTE 1: Rspauth is computed according to RFC 3310 and RFC 2617.