11 Notification

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

11.1 Network-initiated deregistration

11.1.1 Definition

Test to verify that the UE can correctly process the network initiated deregistration request.

11.1.2 Conformance requirement

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package as described in subclause 5.1.1.3, including one or more <registration> element(s) which were registered by this UE with:

– the state attribute set to "terminated" and the event attribute within the <contact> element belonging to this UE set to "rejected" or "deactivated"; or

– the state attribute set to "active" and the state attribute within the <contact> element belonging to this UE set to "terminated", and associated event attribute element to "rejected" or "deactivated";

the UE shall remove all registration details relating to these public user identities. In case of a "deactivated" event attribute, the UE shall start the initial registration procedure as described in subclause 5.1.1.2. In case of a "rejected" event attribute, the UE shall release all dialogs related to those public user identities.

Upon receipt of a NOTIFY request, the UE shall delete the security associations towards the P-CSCF either:

– if all <registration> element(s) having their state attribute set to "terminated" (i.e. all public user identities are deregistered) and the Subscription-State header contains the value of "terminated"; or

– if each <registration> element that was registered by this UE has either the state attribute set to "terminated", or the state attribute set to "active" and the state attribute within the <contact> element belonging to this UE set to "terminated".

The UE shall delete these security associations towards the P-CSCF after the server transaction (as defined in RFC 3261 [26]) pertaining to the received NOTIFY request terminates.

NOTE 1: Deleting a security association is an internal procedure of the UE and does not involve any SIP procedures.

NOTE 2: If the security association towards the P-CSCF is removed, then the UE considers the subscription to the reg event package terminated (i.e. as if the UE had sent a SUBSCRIBE request with an Expires header containing a value of zero, or a NOTIFY request was received with Subscription-State header containing the value of "terminated").

Early IMS security:

NOTE 1: Early IMS security does not allow SIP requests to be protected using an IPsec security association because it does not perform a key agreement procedure

Reference(s)

3GPP TS 24.229 [10], clause 5.1.1.7, 3GPP TR 33.978 [59], clause 6.2.3.1.

11.1.3 Test purpose

To verify that UE will not try registration after getting a NOTIFY with all <registration> element(s) set to "terminated" and "rejected".

11.1.4 Method of test

Initial conditions

UE contains either SIM application (GIBA), ISIM and USIM applications or only USIM application on UICC. UE has activated a PDP context, discovered P-CSCF and registered to IMS services, by executing the generic test procedure in Annex C.2 or C.2a (GIBA only) up to the last step.

SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE. SS has performed AKAv1-MD5 authentication with the UE and accepted the registration (IMS security).

Test procedure

1) SS sends UE a NOTIFY request for the subscribed registration event package, indicating that registration for all the previously registered user identities has been terminated and that new registration shall not be performed. Request is sent over the existing security associations between SS and UE.

2) SS waits for the UE to respond the NOTIFY with 200 OK response.

Expected sequence

Step	Direction		Message	Comment
	UE	SS
1	🡨		NOTIFY	The SS sends a NOTIFY for registration event package, containing full registration state information, with all previously registered public user identities "terminated" and "rejected"
2	🡪		200 OK	The UE responds the NOTIFY with 200 OK

NOTE: The default messages contents in annex A are used with condition “IMS security” or “GIBA” when applicable.

Specific Message Contents

NOTIFY (Step 1)

Use the default message “NOTIFY for reg-event package” in annex A.1.6 with the following exceptions:

Header/param	Value/remark
CSeq
value	2
Subscription-State
substate-value	terminated
expires	0
Message-body	<?xml version=”1.0 encoding="UTF-8"?> <reginfo xmlns=”urn:ietf:params:xml:ns:reginfo” version=”1” state=”full”> <registration aor=”PublicUserIdentity1 (NOTE 1)” id=”a100” state=”terminated”> <contact id=”980” state=”terminated” event=”rejected”> <uri>same value as in Contact header of REGISTER request</uri> </contact> </registration> <registration aor=”AssociatedTelUri (NOTE 1)” id=”a101” state=”terminated”> <contact id=”981” state=”terminated” event=”rejected”> <uri>same value as in Contact header of REGISTER request</uri> </contact> </registration> <registration aor=”PublicUserIdentity2 (NOTE 1)” id=”a102” state=”terminated”> <contact id=”982” state=”terminated” event=”rejected”> <uri>same value as in Contact header of REGISTER request</uri> </contact> </registration> <registration aor=”PublicUserIdentity3 (NOTE 1)” id=”a103” state=”terminated”> <contact id=”983” state=”terminated” event=”rejected”> <uri>same value as in Contact header of REGISTER request</uri> </contact> </registration></reginfo>

NOTE 1: The public user ids and the associated TEL URI are as returned to the UE in the P-Associated-URI header of the 200 (OK) response to the REGISTER request;
PublicUserId1 is the default public user id i.e. the first one contained in P-Associated-URI;
AssociatedTelUri is the same as used in P-Associated-URI
PublicUserId2 and PublicUserId3 are the remaining IMPUs of the P-Associated-URI header

200 OK for NOTIFY (Step 2)

Use the default message “200 OK for other requests than REGISTER or SUBSCRIBE” in annex A.3.1

11.1.5 Test requirements

Step 2: SS shall check that the UE sends the 200 OK response over the existing set of security associations.

SS shall check that terminal does not try to send a REGISTER message after sending 200 OK. Waiting period of one minute is sufficient.

11.2 Network initiated re-authentication

11.2.1 Definition

Test to verify that the UE can correctly process a network initiated re-authentication request and re-authenticate the user before the registration expires, in accordance to 3GPP TS 24.229 [10], clause 5.1.1.5A.

11.2.2 Conformance requirement

At any time, the UE can receive a NOTIFY request carrying information related to the reg event package (as described in subclause 5.1.1.3). If:

– the state attribute in any of the <registration> elements is set to "active";

– the value of the <uri> sub-element inside the <contact> sub-element is set to the Contact address that the UE registered; and

– the event attribute of that <contact> sub-element(s) is set to "shortened";

the UE shall:

1) use the expires attribute of the <contact> sub-element that the UE registered to adjust the expiration time for that public user identity; and

2) start the re-authentication procedures at the appropriate time (as a result of the S-CSCF procedure described in subclause 5.4.1.6) by initiating a reregistration as described in subclause 5.1.1.4, if required.

NOTE: When authenticating a given private user identity, the S-CSCF will only shorten the expiry time within the <contact> sub-element that the UE registered using its private user identity. The <contact> elements for the same public user identity, if registered by another UE using different private user identities remain unchanged. The UE will not initiate a reregistration procedure, if none of its <contact> sub-elements was modified.

Reference(s)

3GPP TS 24.229 [10], clause 5.1.1.5A.

11.2.3 Test purpose

1) To verify that UE adjusts the expiration time for a public user identity as indicated within the received NOTIFY related to reg event package; and

2) To verify that the UE will start the re-authentication procedures at the appropriate time before the registration expires.

11.2.4 Method of test

Initial conditions

UE contains either ISIM and USIM applications or only USIM application on UICC. UE has activated a PDP context, discovered P-CSCF and registered to IMS services by executing the generic test procedure in Annex C.2 up to the last step.. The expiration time for the registration must be at least 600 seconds. Security associations have been set up between UE and the SS.

SS is configured with the IMSI within the USIM application, the home domain name, public and private user identities together with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) that is configured on the UICC card equipped into the UE. SS is able to perform AKAv1-MD5 authentication algorithm for that IMPI, according to 3GPP TS 33.203 [14] clause 6.1 and RFC 3310 [17].

Test procedure

1) SS sends UE a NOTIFY request for the subscribed registration event package, indicating the shortened expiration time as 60 seconds. Request is sent over the existing security associations between SS and UE.

2) SS waits for the UE to respond the NOTIFY with 200 OK response.

3) SS waits for the UE send a REGISTER request 30 seconds before the expected new expiration time.

4) SS responds to the REGISTER request with a valid 401 Unauthorized response, headers populated according to the 401 response common message definition.

5) SS waits for the UE to set up a new set of security associations and send another REGISTER request, over those security associations.

6) The SS responds with 200 OK over the new security association

Expected sequence

Step	Direction		Message	Comment
	UE	SS
1	🡨		NOTIFY	The SS sends a NOTIFY for registration event package, containing partial registration state information, indicating shortened expiration time (60 seconds) for the registered public user identity in the XML body.
2	🡪		200 OK	The UE responds the NOTIFY with 200 OK.
3	🡪		REGISTER	UE re-registers the user 30 seconds before the expected expiration.
4	🡨		401 Unauthorized	The SS responds with a valid AKAv1-MD5 authentication challenge and security mechanisms supported by the network.
5	🡪		REGISTER	UE completes the security negotiation procedures, sets up a new temporary set of SAs and uses those for sending another REGISTER with AKAv1-MD5 credentials.
6	<-		200 OK	The UE responds with 200 OK.

Specific Message Contents

NOTIFY (Step 1)

Use the default message “NOTIFY for reg-event package” in annex A.1.6 with the following exceptions:

Header/param	Cond	Value/remark
CSeq
value		2
Message-body
	NOT A1	<?xml version=”1.0” encoding="UTF-8"?> <reginfo xmlns=”urn:ietf:params:xml:ns:reginfo” version=”1” state=”partial”> <registration aor=” PublicUserIdentity1 (NOTE 1)” id=”a100” state=”active”> <contact id=”980” state=”active” event=”shortened” expires="60"> <uri>same value as in Contact header of REGISTER request</uri> </contact> </registration> </reginfo>
	A1	<?xml version=”1.0” encoding="UTF-8"?> <reginfo xmlns=”urn:ietf:params:xml:ns:reginfo” xmlns:gr="urn:ietf:params:xml:ns:gruuinfo" version=”1” state=”partial”> <registration aor=” PublicUserIdentity1 (NOTE 1)” id=”a100” state=”active”> <contact id=”980” state=”active” event=”shortened” expires="60"> callid="Call-Id of most recent REGISTER" cseq="CSeq value of most recent REGISTER"> <uri>same value as in Contact header of REGISTER request</uri> <unknown-param name="+sip.instance"> "Instance ID of the UE;" </unknown-param> <gr:pub-gruu uri="public GRUU associated to this aor"/> <gr:temp-gruu uri="temporary GRUU associated to this aor" first-cseq="CSeq of the REGISTER request that caused the temporary GRUU to assigned for the UE"/> </contact> </registration> </reginfo>

Condition	Explanation
A1	obtaining and using GRUUs in the Session Initiation Protocol (SIP) (A.4/53 3GPP TS 34.229-2 [5])

200 OK for NOTIFY (Step 2)

Use the default message “200 OK for other requests than REGISTER or SUBSCRIBE” in annex A.3.1

Use the default message “REGISTER” in annex A.1.1 condition A2 with the following exceptions:

Header/param	Value/remark
Security-Client
spi-c	new SPI number of the inbound SA at the protected client port
spi-s	new SPI number of the inbound SA at the protected server port
port-c	new protected client port needed for the setup of new pairs of security associations
port-s	Same value as in the previous REGISTER

401 Unauthorized for REGISTER (Step 4)

Use the default message “401 Unauthorized for REGISTER” in annex A.1.2 with the following exceptions:

Header/param	Value/remark
Security-Server
spi-c	new SPI number of the inbound SA at the protected client port
spi-s	new SPI number of the inbound SA at the protected server port
port-c	new protected client port needed for the setup of new pairs of security associations
port-s	Same value as in the previous Security-Server headers
WWW-Authenticate
nonce	Base 64 encoding of a new RAND and AUTN

Use the default message “REGISTER” in annex A.1.1 with condition A2.

11.2.5 Test requirements

Step 2: SS shall check that the UE sends the 200 OK response over the existing set of security associations.

Step 3: SS shall check that in accordance to the 3GPP TS 24.229 [10] clause 5.1.1.4 the UE sends a REGISTER request over the existing set of security associations.