C.30 Generic test procedure for Mobile Initiated Deregistration – 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

The generic test procedure:

IMS deregistration is initiated on the UE. SS waits for the UE sending a REGISTER request, in accordance with 3GPP TS 24.229 [10], clause 5.1.1.6.

Expected sequence:

Step	Direction		Message/Procedure	Comment
	UE	SS
0A	🡪		SUBSCRIBE	Optional: The UE unsubscribes from one of its subscribed to event packages
0B	🡨		200 OK	If the UE sent SUBSCRIBE, the SS responds to SUBSCRIBE with 200 OK
0C	🡨		NOTIFY	If the UE sent SUBSCRIBE, the SS sends a final NOTIFY
0D	🡪		200 OK	Optional: If the UE sent SUBSCRIBE, the UE responds to NOTIFY with 200 OK
1	🡪		REGISTER	The UE sends deregistration for IMS services
2	🡨		200 OK	The SS responds to REGISTER with 200 OK
Note 1: Steps 0A-0D may be repeated for any or all event packages subscribed to by the UE. It is the UE’s decision which unsubscriptions to perform. Note 2: The UE can send the 200 OK for NOTIFY after the REGISTER request or even not send it at all.

Specific message contents

SUBSCRIBE (step 0A)

Use the default message “SUBSCRIBE for reg-event package” in annex A.1.4 or “SUBSCRIBE for conference event package” in annex A.5.1 or “SUBSCRIBE for message-summary event package” in annex A.6.1 with the following exceptions:

Header/param	Value/remark
From addr-spec tag	Same as in original SUBSCRIBE that set up the corresponding subscription Same as in original SUBSCRIBE that set up the corresponding subscription
To addr-spec tag	As specified in A.1.4/A.5.1/A.6.1 Same as in 200 OK for original SUBSCRIBE that set up the corresponding subscription
CSeq value method	value of the previous SUBSCRIBE sent by the UE for this dialog incremented by one SUBSCRIBE
Session-ID sess-id	Same as in original SUBSCRIBE that set up the corresponding subscription (if present in original SUBSCRIBE)
Expires
delta-seconds	0

200 OK for SUBSCRIBE (step 0B)

Use the default message “200 OK for SUBSCRIBE” in annex A.1.5, A.5.2 or A.6.3 whatever appropriate, with the following exceptions:

Header/param	Value/remark
Expires
delta-seconds	0

Header/param

Value/remark

addr-spec

tag

As specified in A.1.4/A5.1/A.6.1

Same as in step 0A

Expires

delta-seconds

NOTIFY (step 0C)

Header/param	Cond	Value/remark	Reference
Request-Line			RFC 3261 [15]
Method		NOTIFY
Request-URI		UE’s contact address in SIP URI form, as provided in the Contact header within the SUBSCRIBE creating the dialog

SIP-Version		SIP/2.0
Via		order of the parameters in this header must be like in this table	RFC 3261 [15]
via-parm1:
Sent-protocol		SIP/2.0/UDP when using UDP or SIP/2.0/TCP when using TCP
sent-by	A1	IP address and protected server port of SS
sent-by	A2, A6	IP address and unprotected server port of SS (optional)
via-branch		value starting with ‘z9hG4bK’ (NOTE 1)
via-parm2:
sent-protocol		SIP/2.0/UDP when using UDP or SIP/2.0/TCP when using TCP
sent-by		scscf.3gpp.org
via-branch		value starting with ‘z9hG4bK’ (NOTE 1)
From			RFC 3261 [15]
addr-spec		same URI as received in the To header of the corresponding SUBSCRIBE message
tag		same as to-tag in step 0A
To			RFC 3261 [15]
addr-spec		same URI as received in the From header of the corresponding SUBSCRIBE message
tag		same as from-tag in step 0A
Call-ID			RFC 3261 [15]
callid		same as value received in SUBSCRIBE message	RFC 3261 [15]
CSeq	A1,A2		RFC 3261 [15]
value		1
method		NOTIFY
Contact			RFC 3261 [15]
addr-spec	A3	<sip:scscf.3gpp.org>	RFC 3261 [15]
addr-spec	A4	sip:final@conf-factory. appended with px_IMS_HomeDomainName
addr-spec	A5	<scscf.3gpp.org>
Event			RFC 6665 [140] RFC 3680 [22]
event-type	A3	reg	RFC 6665 [140] RFC 3680 [22]
event-type	A4	conference
event-type	A5	message-summary
Max-Forwards			RFC 3261 [15]
value		69	RFC 3261 [15]
Subscription-State			RFC 6665 [140]
substate-value		terminated	RFC 6665 [140]
Content-Length
value		0

Condition	Explanation
A1	IMS security (A.6a/2 3GPP TS 34.229-2 [5])
A2	GIBA (A.6a/1 3GPP TS 34.229-2 [5]
A3	Final NOTIFY sent for reg-event
A4	Final NOTIFY sent for conf-event
A5	Final NOTIFY sent for message-summary
A6	SIP Digest without TLS for Fixed Broadband Access (SIP Digest without TLS, A.6a/5 3GPP TS 34.229-2 [5])

NOTE 1: Branch parameter values sent by SS are different within a test case execution.

200 OK (step 0D)

Use the default message "200 OK for other requests than REGISTER or SUBSCRIBE"

Use the default message “REGISTER” in annex A.1.1 with conditions A2 (IMS Security) or A3 (GIBA), as applicable, in accordance to 3GPP TS 24.229 [10] clause 5.1.1.6, and A17 "UE initiated IMS re-registration or de-registration" with the following exceptions:

Header/param	Value/remark
Contact
addr-spec	SIP URI with IP address or FQDN and protected server port of the UE in case of IMS security (A2 of A.1.1) or unprotected port of the UE (optional) in case of GIBA (A3 of A.1.1) and, if the UE supports GRUU, the following parameter: +sip.instance="<urn:gsma:imei: (gsma-specifier-defined-substring)>” or *
expires	0 (if present)
Expires	(must be present if addr-spec is *)
delta-seconds	0 (if present)
Supported	header may be missing or it may contain any value
Authorization	value not checked

NOTE: In contrast to A.1.1, the Contact header does not have any further mandatory feature parameters.

200 OK (step 2)

Use the default message “200 OK for REGISTER” in annex A.1.3 with the following exceptions:

Header/param	Value/remark
Contact
addr-spec	same value as in REGISTER request if "" is not included in the Contact header field of the REGISTER request in step 1 same value as in the Contact header field of the "200 OK" response to the initial registration if "" is included in the Contact header field of the REGISTER request in step 1 (NOTE)
expires	0
NOTE: According to 3GPP TS 24.229 [10] clause 5.4.1.4.1 when the S-CSCF gets a wild-carded contact address for de-registration it shall include all de-registered contact addresses in the contact header of the 200 OK response ⇒ there is no “*” in DL.