6 Registration

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

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

6.1 Initial Registration / 5GS

6.1.1 Test Purpose (TP)

(1)

with { UE has an ISIM or USIM inserted, is registered for 5GS, and has acquired P-CSCF address(es) }

ensure that {

when { UE is made to register for IMS }

then { UE sends a correctly composed initial REGISTER request to the P-CSCF }

}

(2)

with { UE having sent unprotected REGISTER request }

ensure that {

when { UE receiving a valid 401 (Unauthorized) response for the initial REGISTER request sent }

then { UE correctly authenticates itself by sending another REGISTER request with a correctly composed Authorization header using the AKAv1-MD5 algorithm }

}

(3)

with { UE having sent unprotected and then protected REGISTER request }

ensure that {

when { UE receiving a valid 200 OK response from S-CSCF for the REGISTER sent for authentication }

then { UE subscribes to the reg event package for the public user identity registered, using the stored service route for routing the SUBSCRIBE request }

}

(4)

with { UE having subscribed to reg event }

ensure that {

when { UE receives NOTIFY request for reg event }

then { UE responds with a valid 200 OK response }

}

6.1.2 Conformance Requirements

The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.

[TS 24.229, clause C.2]:

In case the UE is loaded with a UICC that contains a USIM but does not contain an ISIM, the UE shall:

– generate a private user identity;

– generate a temporary public user identity; and

– generate a home network domain name to address the SIP REGISTER request to.

All these three parameters are derived from the IMSI parameter in the USIM, according to the procedures described in TS 23.003 [3]. Also in this case, the UE shall derive new values every time the UICC is changed, and shall discard existing values if the UICC is removed.

NOTE: If there is an ISIM and a USIM on a UICC, the ISIM is used for authentication to the IM CN subsystem, as described in TS 33.203 [19]. See also clause 5.1.1.1A.

[TS 24.229, clause 5.1.1.1A]:

The ISIM shall always be used for authentication to the IM CN subsystem, if it is present, as described in 3GPP TS 33.203 [19].

The ISIM is preconfigured with all the necessary parameters to initiate the registration to the IM CN subsystem. These parameters include:

– the private user identity;

– one or more public user identities; and

– the home network domain name used to address the SIP REGISTER request

The first public user identity in the list stored in the ISIM is used in emergency registration requests.

In case the UE does not contain an ISIM, the UE shall:

– generate a private user identity;

– generate a temporary public user identity; and

– generate a home network domain name to address the SIP REGISTER request to;

in accordance with the procedures in clause C.2.

The temporary public user identity is only used in REGISTER requests, i.e. initial registration, re-registration, UE-initiated deregistration.

The UE shall not reveal to the user the temporary public user identity if the temporary public user identity is barred. The temporary public user identity is not barred if received by the UE in the P-Associated-URI header field.

If the UE is unable to derive the parameters in this clause for any reason, then the UE shall not proceed with the request associated with the use of these parameters and will not be able to register to the IM CN subsystem.

[TS 24.229, clause 5.1.1.2.1]:

The initial registration procedure consists of the UE sending an unprotected REGISTER request and, if challenged depending on the security mechanism supported for this UE, sending the integrity-protected REGISTER request or other appropriate response to the challenge. The UE can register a public user identity with any of its contact addresses at any time after it has acquired an IP address, discovered a P-CSCF, and established an IP-CAN bearer that can be used for SIP signalling. However, the UE shall only initiate a new registration procedure when it has received a final response from the registrar for the ongoing registration, or the previous REGISTER request has timed out.

…

The UE shall send the unprotected REGISTER requests to the port advertised to the UE during the P-CSCF discovery procedure. If the UE does not receive any specific port information during the P-CSCF discovery procedure, or if the UE was pre-configured with the P-CSCF’s IP address or domain name and was unable to obtain specific port information, the UE shall send the unprotected REGISTER request to the SIP default port values as specified in RFC 3261 [26].

NOTE 1: The UE will only send further registration and subsequent SIP messages towards the same port of the P-CSCF for security mechanisms that do not require to use negotiated ports for exchanging protected messages.

The UE shall extract or derive a public user identity, the private user identity, and the domain name to be used in the Request-URI in the registration, according to the procedures described in subclause 5.1.1.1A or subclause 5.1.1.1B. A public user identity may be input by the end user.

On sending an unprotected REGISTER request, the UE shall populate the header fields as follows:

a) a From header field set to the SIP URI that contains:

…

2) the public user identity to be registered;

b) a To header field set to the SIP URI that contains:

…

2) the public user identity to be registered;

c) a Contact header field set to include SIP URI(s) containing the IP address or FQDN of the UE in the hostport parameter. If the UE:

1) supports GRUU (see table A.4, item A.4/53);

…

3) has an IMEI available; or

…

the UE shall include a "+sip.instance" header field parameter containing the instance ID. …

NOTE 2: The requirement placed on the UE to include an instance ID based on the IMEI or the MEID when the UE does not support GRUU and does not support multiple registrations does not imply any additional requirements on the network.

…

The UE shall include all supported ICSI values (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 and RFC 3840 [62] for the IMS communication services it intends to use, and IARI values (coded as specified in subclause 7.2A.9.2), for the IMS applications it intends to use in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3840 [62].

The UE shall include the media feature tags as defined in RFC 3840 [62] for all supported streaming media types.

…

If the UE has no specific reason not to include a user part in the URI of the contact address (e.g. some UE performing the functions of an external attached network), the UE should include a user part in the URI of the contact address such that the user part is globally unique and does not reveal any private information;

NOTE 3: A time-based UUID (Universal Unique Identifier) generated as per subclause 4.2 of RFC 4122 [154] is globally unique and does not reveal any private information.

d) a Via header field set to include the sent-by field containing the IP address or FQDN of the UE and the port number where the UE expects to receive the response to this request when UDP is used. For TCP, the response is received on the TCP connection on which the request was sent. For the UDP, the UE shall also include a "rport" header field parameter with no value in the Via header field. Unless the UE has been configured to not send keep-alives, and unless the UE is directly connected to an IP-CAN for which usage of NAT is not defined, it shall include a "keep" header field parameter with no value in the Via header field, in order to indicate support of sending keep-alives associated with the registration, as described in RFC 6223 [143];

NOTE 4: When sending the unprotected REGISTER request using UDP, the UE transmit the request from the same IP address and port on which it expects to receive the response to this request.

e) a registration expiration interval value of 600 000 seconds as the value desired for the duration of the registration;

NOTE 5: The registrar (S-CSCF) might decrease the duration of the registration in accordance with network policy. Registration attempts with a registration period of less than a predefined minimum value defined in the registrar will be rejected with a 423 (Interval Too Brief) response.

f) a Request-URI set to the SIP URI of the domain name of the home network used to address the REGISTER request;

g) the Supported header field containing the option-tag "path", and

1) if GRUU is supported, the option-tag "gruu"; and

2) if multiple registrations is supported, the option-tag "outbound".

h) if a security association or TLS session exists, and if available to the UE (as defined in the access technology specific annexes for each access technology), a P-Access-Network-Info header field set as specified for the access network technology (see subclause 7.2A.4);

…

On receiving the 200 (OK) response to the REGISTER request, the UE shall:

a) store the expiration time of the registration for the public user identities found in the To header field value and bind it either to the respective contact address of the UE or to the registration flow and the associated contact address (if the multiple registration mechanism is used);

…

b) store as the default public user identity the first URI on the list of URIs present in the P-Associated-URI header field and bind it to the respective contact address of the UE and the associated set of security associations or TLS session;

…

d) store the list of service route values contained in the Service-Route header field and bind the list either to the contact address or to the registration flow and the associated contact address (if the multiple registration mechanism is used), and the associated set of security associations or TLS session over which the REGISTER request was sent;

NOTE 10: When multiple registration mechanism is not used, there will be only one list of service route values bound to a contact address. However, when multiple registration mechanism is used, there will be different list of service route values bound to each registration flow and the associated contact address.

NOTE 11: The UE will use the stored list of service route values to build a proper preloaded Route header field for new dialogs and standalone transactions (other than REGISTER method) when using either the respective contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used), and the associated set of security associations or TLS session.

e) if the UE indicated support for GRUU in the Supported header field of the REGISTER request then:

– if the UE did not use the procedures specified in RFC 6140 [191] for registration, find the Contact header field within the response that matches the one included in the REGISTER request. If this contains a "pub-gruu" header field parameter or a "temp-gruu" header field parameter or both, then store the value of those parameters as the GRUUs for the UE in association with the public user identity and the contact address that was registered; and

…

NOTE 12: When allocating public GRUUs to registering UAs the functionality within the UE that performs the role of registrar will add an "sg" SIP URI parameter that uniquely identifies that UA to the public GRUU it received in the "pub-gruu" header field parameter. The procedures for generating a temporary GRUU using the "temp-gruu-cookie" header field parameter are specified in subclause 7.1.2.2 of RFC 6140 [191].

f) if the REGISTER request contained the "reg-id" and "+sip.instance" Contact header field parameter and the "outbound" option tag in a Supported header field, the UE shall check whether the option-tag "outbound" is present in the Require header field:

– if no option-tag "outbound" is present, the UE shall conclude that the S-CSCF does not support the registration procedure as described in RFC 5626 [92], and the S-CSCF has followed the registration procedure as described in RFC 5627 [93] or RFC 3261 [26], i.e., if there is a previously registered contact address, the S-CSCF replaced the old contact address and associated information with the new contact address and associated information (see bullet e) above). Upon detecting that the S-CSCF does not support the registration procedure as defined in RFC 5626 [92], the UE shall refrain from registering any additional IMS flows for the same private identity as described in RFC 5626 [92]; or

NOTE 13: Upon replaces the old contact address with the new contact address, the S-CSCF performs the network initiated deregistration procedure for the previously registered public user identities and the associated old contact address as described in subclause 5.4.1.5. Hence, the UE will receive a NOTIFY request informing the UE about the deregistration of the old contact address.

– if an option-tag "outbound" is present, the UE may establish additional IMS flows for the same private identity, as defined in RFC 5626 [92];

g) if available, store the announcement of media plane security mechanisms the P-CSCF (IMS-ALG) supports labelled with the "mediasec" header field parameter specified in subclause 7.2A.7 and received in the Security-Server header field, if any. Once the UE chooses a media security mechanism from the list received in the Security-Server header field from the server, it may initiate that mechanism on a media level when it initiates new media in an existing session;

NOTE 14: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

[TS 24.229, clause 5.1.1.2.2]:

On sending a REGISTER request, as defined in subclause 5.1.1.2.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field, with:

– the "username" header field parameter, set to the value of the private user identity;

– the "realm" header field parameter, set to the domain name of the home network;

– the "uri" header field parameter, set to the SIP URI of the domain name of the home network;

– the "nonce" header field parameter, set to an empty value; and

– the "response" header field parameter, set to an empty value;

NOTE 1: If the UE specifies its FQDN in the hostport parameter in the Contact header field and in the sent-by field in the Via header field, then it has to ensure that the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP address that is bound to the security association.

NOTE 2: The UE associates two ports, a protected client port and a protected server port, with each pair of security association. For details on the selection of the port values see 3GPP TS 33.203 [19].

b) additionally for the Contact header field, if the REGISTER request is protected by a security association, include the protected server port value in the hostport parameter;

c) additionally for the Via header field, for UDP, if the REGISTER request is protected by a security association, include the protected server port value in the sent-by field; and

d) a Security-Client header field set to specify the signalling plane security mechanism the UE supports, the IPsec layer algorithms the UE supports and the parameters needed for the security association setup. The UE shall support the setup of two pairs of security associations as defined in 3GPP TS 33.203 [19]. The syntax of the parameters needed for the security association setup is specified in annex H of 3GPP TS 33.203 [19]. The UE shall support the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The UE shall support the IPsec layer algorithms for integrity and confidentiality protection as defined in 3GPP TS 33.203 [19], and shall announce support for them according to the procedures defined in RFC 3329 [48].

[TS 24.229, clause 5.1.1.5.1]:

Authentication is performed during initial registration. A UE can be re-authenticated during subsequent reregistrations, deregistrations or registrations of additional public user identities. When the network requires authentication or re-authentication of the UE, the UE will receive a 401 (Unauthorized) response to the REGISTER request.

On receiving a 401 (Unauthorized) response to the REGISTER request, the UE shall:

1) extract the RAND and AUTN parameters;

2) check the validity of a received authentication challenge, as described in 3GPP TS 33.203 [19] i.e. the locally calculated XMAC must match the MAC parameter derived from the AUTN part of the challenge; and the SQN parameter derived from the AUTN part of the challenge must be within the correct range; and

3) check the existence of the Security-Server header field as described in RFC 3329 [48]. If the Security-Server header field is not present or it does not contain the parameters required for the setup of the set of security associations (see annex H of 3GPP TS 33.203 [19]), the UE shall abandon the authentication procedure and send a new REGISTER request with a new Call-ID.

In the case that the 401 (Unauthorized) response to the REGISTER request is deemed to be valid the UE shall:

1) calculate the RES parameter and derive the keys CK and IK from RAND as described in 3GPP TS 33.203 [19];

2) set up a temporary set of security associations for this registration based on the static list and parameters the UE received in the 401 (Unauthorized) response and its capabilities sent in the Security-Client header field in the REGISTER request. The UE sets up the temporary set of security associations using the most preferred mechanism and algorithm returned by the P-CSCF and supported by the UE and using IK and CK (only if encryption enabled) as the shared key. The UE shall use the parameters received in the Security-Server header field to setup the temporary set of security associations. The UE shall set a temporary SIP level lifetime for the temporary set of security associations to the value of reg-await-auth timer;

…

4) send another REGISTER request towards the protected server port indicated in the response using the temporary set of security associations to protect the message. The header fields are populated as defined for the initial REGISTER request that was challenged with the received 401 (Unauthorized) response, with the addition that the UE shall include an Authorization header field containing:

– the "realm" header field parameter set to the value as received in the "realm" WWW-Authenticate header field parameter;

– the "username" header field parameter, set to the value of the private user identity;

– the "response" header field parameter that contains the RES parameter, as described in RFC 3310 [49];

– the "uri" header field parameter, set to the SIP URI of the domain name of the home network;

– the "algorithm" header field parameter, set to the value received in the 401 (Unauthorized) response; and

– the "nonce" header field parameter, set to the value received in the 401 (Unauthorized) response.

The UE shall also insert the Security-Client header field that is identical to the Security-Client header field that was included in the previous REGISTER request (i.e. the REGISTER request that was challenged with the received 401 (Unauthorized) response). The UE shall also insert the Security-Verify header field into the request, by mirroring in it the content of the Security-Server header field received in the 401 (Unauthorized) response. The UE shall set the Call-ID of the security association protected REGISTER request which carries the authentication challenge response to the same value as the Call-ID of the 401 (Unauthorized) response which carried the challenge.

NOTE 2: The Security-Client header field contains signalling plane security mechanism and if the UE supports media plane security, then media plane security mechanisms are contained, too.

[TS 24.229, clause 5.1.1.5.1]:

On receiving the 200 (OK) response for the security association protected REGISTER request registering a public user identity with the associated contact address, the UE shall:

– change the temporary set of security associations to a newly established set of security associations, i.e. set its SIP level lifetime to the longest of either the previously existing set of security associations SIP level lifetime, or the lifetime of the just completed registration plus 30 seconds; and

– if this is the only set of security associations available toward the P-CSCF, use the newly established set of security associations for further messages sent towards the P-CSCF. If there are additional sets of security associations (e.g. due to registration of multiple contact addresses), the UE can either use them or use the newly established set of security associations for further messages sent towards the P-CSCF as appropriate.

NOTE 3: If the UE has registered multiple contact addresses, the UE can either send requests towards the P-CSCF over the newly established set of security associations, or use different UE’s contact address and associated set of security associations when sending the requests towards the P-CSCF. Responses towards the P-CSCF that are sent via UDP will be sent over the same set of security associations that the related request was received on. Responses towards the P-CSCF that are sent via TCP will be sent over the same set of security associations that the related request was received on.

When the first request or response protected with the newly established set of security associations is received from the P-CSCF or when the lifetime of the old set of security associations expires, the UE shall delete the old set of security associations and related keys it may have with the P-CSCF after all SIP transactions that use the old set of security associations are completed.

[TS 24.229, clause 5.1.1.3]:

Upon receipt of a 2xx response to the initial registration, the UE shall subscribe to the reg event package for the public user identity registered at the user’s registrar (S-CSCF) as described in RFC 3680 [43] and RFC 6665 [28].

…

The UE shall subscribe to the reg event package upon registering a new contact address via an initial registration procedure. If the UE receives a NOTIFY request via the newly established subscription dialog and via the previously established subscription dialogs (there will be at least one), the UE may terminate the previously established subscription dialogs and keep only the newly established subscription dialog.

The UE shall use the default public user identity for subscription to the registration-state event package.

NOTE 2: The subscription information stored in the HSS ensures that the default public user identity is a SIP URI.

On sending a SUBSCRIBE request, the UE shall populate the header fields as follows:

a) a Request-URI set to the resource to which the UE wants to be subscribed to, i.e. to the SIP URI that is the default public user identity used for subscription;

b) a From header field set to the SIP URI that is the default public user identity used for subscription;

c) a To header field set to the SIP URI that is the default public user identity used for subscription;

d) an Event header field set to the "reg" event package;

e) an Expires header field set to 600 000 seconds as the value desired for the duration of the subscription;

f) void; and

g) void.

[TS 24.229, clause 5.1.2.1]:

Upon receipt of a NOTIFY request for the dialog associated with the subscription to the reg event package the UE shall perform the following actions:

– store the information for the established dialog;

– store the expiration time as indicated in the "expires" header field parameter of the Subscription-State header field, if present, of the NOTIFY request. Otherwise the expiration time is retrieved from the Expires header field of the 2xx response to SUBSCRIBE request;

– if a <registration> element with state attribute "active", i.e. registered, is received for one or more public user identities, the UE shall store the indicated public user identities as registered;

– if a <registration> element with state attribute "active" is received, and the UE supports GRUU (see table A.4, item A.4/53), then for each public user identity indicated in the notification that contains a <pub-gruu> element or a <temp-gruu> element or both (as defined in RFC 5628 [94]), the UE shall store the value of those elements in association with the public user identity;

[TS 24.229, clause 5.1.2A.1.1]:

When the UE sends any request, the UE shall use either a given contact address that has been previously registered or a registration flow and the associated contact address (if the multiple registration mechanism is used) and shall:

– if IMS AKA is in use as a security mechanism:

a) if the UE has not obtained a GRUU, populate the Contact header field of the request with the protected server port and the respective contact address; and

b) include the protected server port and the respective contact address in the Via header field entry relating to the UE;

…

The UE shall determine the public user identity to be used for this request as follows:

1) if a P-Preferred-Identity was included, then use that as the public user identity for this request; or

2) if no P-Preferred-Identity was included, then use the default public user identity for the security association or TLS session and the associated contact address as the public user identity for this request;

…

If this is a request for a new dialog, the Contact header field is populated as follows:

1) a contact header value which is one of:

– if a public GRUU value ("pub-gruu" header field parameter) has been saved associated with the public user identity to be used for this request, and the UE does not indicate privacy of the P-Asserted-Identity, then the UE should insert the public GRUU ("pub-gruu" header field parameter) value as specified in RFC 5627 [93]; or

– if a temporary GRUU value ("temp-gruu" header field parameter) has been saved associated with the public user identity to be used for this request, and the UE does indicate privacy of the P-Asserted-Identity, then the UE should insert the temporary GRUU ("temp-gruu" header field parameter) value as specified in RFC 5627 [93];

– otherwise, a SIP URI containing the contact address of the UE that has been previously registered without any contact parameters dedicated to registration procedure;

NOTE 7: The above items are mutually exclusive.

…

If available to the UE (as defined in the access technology specific annexes for each access technology), the UE shall insert a P-Access-Network-Info header field into any request for a dialog, any subsequent request (except CANCEL requests) or response (except CANCEL responses) within a dialog or any request for a standalone method (see subclause 7.2A.4). Insertion of the P-Access-Network-Info header field into the ACK request is optional.

NOTE 13: During the dialog, the points of attachment to the IP-CAN of the UE can change (e.g. UE connects to different cells). The UE will populate the P-Access-Network-Info header field in any request or response within a dialog with the current point of attachment to the IP-CAN (e.g. the current cell information).

NOTE 14: The value of the P-Access-Network-Info header field could be stale if the point of attachment of the UE with the network changes before the message is received by the network.

The UE shall build a proper preloaded Route header field value for all new dialogs and standalone transactions. The UE shall build a list of Route header field values made out of the following, in this order:

a) the P-CSCF URI containing the IP address acquired at the time of the P-CSCF discovery procedures which was used in registration of the contact address (or registration flow); and

NOTE 15: If the UE is provisioned with or receives a FQDN at the time of the P-CSCF discovery procedures, the FQDN is resolved to an IP address at the time of the P-CSCF discovery procedures.

b) the P-CSCF port based on the security mechanism in use:

– if IMS AKA or SIP digest with TLS is in use as a security mechanism, the protected server port learnt during the registration procedure;

…

c) and the values received in the Service-Route header field saved from the 200 (OK) response to the last registration or re-registration of the public user identity with associated contact address.

NOTE 16: When the UE registers multiple contact addresses, there will be a list of Service-Route headers for each contact address. When sending a request using a given contact address and the associated security associations or TLS session, the UE will use the corresponding list of Service-Route headers to construct a list of Route headers.

[TS 24.341, clause 5.3.2.2]

On sending a REGISTER request, the SM-over-IP receiver shall indicate its capability to receive traditional short messages over IMS network by including a "+g.3gpp.smsip" parameter into the Contact header according to RFC 3840 [16].

6.1.3 Test description

6.1.3.1 Pre-test conditions

System Simulator:

– 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 listening to SIP default port 5060 for both UDP and TCP protocols.

– SS is able to perform IMS AKA authentication for the IMPI, according to 3GPP TS 33.203 [16] clause 6.1.

– 1 NR Cell

UE:

– The UE contains either ISIM and USIM applications or only USIM application on UICC.

– The UE is configured to register for IMS after switch on.

– The UE is switched off.

Preamble:

– None

6.1.3.2 Test procedure sequence

Table 6.1.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	The UE is switched on.
2	Check: does the UE send an initial registration request?	–>	REGISTER	1	P
3	SS sends 401 Unauthorized.	<–	401 Unauthorized
4	Check: does the UE send a subsequent registration request?	–>	REGISTER	2	P
5	SS sends 200 OK for REGISTER.	<–	200 OK
	EXCEPTION: In parallel to the events described in steps 6 to 9, the steps specified in Table 6.1.3.2-2 may take place.
6	Check: does the UE subscribe to reg-event?	–>	SUBSCRIBE	3	P
7	SS sends 200 OK for SUBSCRIBE.	<–	200 OK
8	SS sends NOTIFY for reg-event package, containing full registration state information for the registered public user identity in the XML body.	<–	NOTIFY
9	Check: does the UE acknowledge reception of NOTIFY?	–>	200 OK	4	P
NOTE: The associated NR/5GC signalling is specified in TS 38.508-1 [21] generic procedure 4.5.2.

Table 6.1.3.2-2: Parallel Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE sends a PUBLISH request.	–>	PUBLISH
2	SS sends a 503 Service Unavailable response	<–	503 Service Unavailable

6.1.3.3 Specific message contents

Table 6.1.3.3-1: REGISTER (step 2, table 6.1.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.1, Condition A1

Table 6.1.3.3-2: 401 Unauthorized for REGISTER (step 3, table 6.1.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.2, Condition A1

Table 6.1.3.3-3: REGISTER (step 4, table 6.1.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.1, Conditions A2 and A32

Table 6.1.3.3-4: 200 OK for REGISTER (step 5, table 6.1.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.3, Condition A2

Table 6.1.3.3-5: SUBSCRIBE for reg-event package (step 6, table 6.1.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.4, Conditions A1 and A7

Table 6.1.3.3-6: 200 OK for SUBSCRIBE (step 7, table 6.1.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.5, Condition A1

Table 6.1.3.3-7: NOTIFY for reg-event package (step 8, table 6.1.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.6, Condition A1

Table 6.1.3.3-8: 200 OK for requests other than REGISTER or SUBSCRIBE (step 9, table 6.1.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.3.1, Conditions A8 and A22

Table 6.1.3.3-9: PUBLISH (step 1, table 6.1.3.2-2)

Derivation Path: TS 34.229-1 [2], Table in subclause A.4.3, Conditions A1 and A5

Table 6.1.3.3-10: 503 Service Unavailable (step 2, table 6.1.3.2-2)

Derivation Path: TS 34.229-1 [2], Table in subclause A.4.2

6.2 Initial Registration Failures / 5GS

6.2.1 Test Purpose (TP)

(1)

with { UE having sent unprotected REGISTER request }

ensure that {

when { UE receiving a 503 (Service Unavailable) response without Retry-After header for the unprotected REGISTER request sent }

then { UE waits at most 5 minutes and then sends another unprotected REGISTER request }

}

(2)

with { UE having sent an unprotected REGISTER request }

ensure that {

when { UE receiving a 503 (Service Unavailable) response with Retry-After header for the initial REGISTER request sent }

then { UE waits until interval given is up and then sends another unprotected REGISTER request }

}

(3)

with { UE having sent unprotected REGISTER request }

ensure that {

when { UE receiving a 423 (Interval Too Brief) response }

then { UE sends another unprotect REGISTER request with new expiration interval }

}

6.2.2 Conformance Requirements

The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.

[TS 24.229, clause 5.1.1.2.1, Release 17]:

For each 4xx, 5xx or 6xx response received without a Retry-After header field to the REGISTER request, the UE shall:

a) use the mechanism defined in subclause 4.5 of RFC 5626 [92] for determination of the retry delay time before each new registration attempt;

b) mark the currently used P-CSCF address as unavailable for the last duration of the retry delay time computed by the algorithm defined in subclause 4.5 of RFC 5626 [92] plus 5 minutes; and

c) initiate an initial registration as specified in subclause 5.1.1.2 after the amount of time of the last retry delay time computed by the algorithm defined in subclause 4.5 of RFC 5626 [92]; and

– if there is a locally stored P-CSCF address as specified in subclause 5.1.9 which is different from the currently used P-CSCF address and which is not marked as unavailable, may initiate the initial registration using that P-CSCF; and

– if there is no locally stored P-CSCF address as specified in subclause 5.1.9 which is different from the currently used P-CSCF address and which is not marked as unavailable, may get a new set of P-CSCF addresses as described in subclause 9.2.1 unless otherwise specified in the access specific annexes (as described in annex B, annex L or annex U) and initiate the initial registration as specified in subclause 5.1.1.2.

The values of max-time and base-time (if all failed) may be provided by the network to the UE with the management objects specified in 3GPP TS 24.167 [8G]. If no values of the parameters max-time and base-time (if all failed) have been provided to the UE by the network, the default values defined in subclause 4.5 of RFC 5626 [92] shall be used. Other mechanisms may be used as well and are outside the scope of the present document.

[TS 24.229, clause 5.1.1.2.1]:

On receiving a 503 response with a Retry-After header field to the REGISTER request and the Retry-After header field indicates time bigger than the value for timer F as specified in table 7.7.1, the UE:

a) shall mark the currently used P-CSCF address as unavailable for the time indicated by the Retry-After header field;

b) if there is a locally stored P-CSCF address as specified in subclause 5.1.9 which is different than the currently used P-CSCF address and which is not marked as unavailable, may initiate an initial registration as specified in subclause 5.1.1.2 using that P-CSCF; and

c) if there is no locally stored P-CSCF address as specified in subclause 5.1.9 which is different than the currently used P-CSCF address and which is not marked as unavailable, may get a new set of P-CSCF addresses as described in subclause 9.2.1 unless otherwise specified in the access specific annexes (as described in annex B, annex L or annex U) and initiate an initial registration as specified in subclause 5.1.1.2.

NOTE 19: if the Retry-After header field indicates time smaller than the value for timer F as specified in table 7.7.1, the UE continues using the currently used P-CSCF address.

[TS 24.229, clause 5.1.1.2.1]:

On receiving a 423 (Interval Too Brief) response to the REGISTER request, the UE shall:

– send another REGISTER request populating the registration expiration interval value with an expiration timer of at least the value received in the Min-Expires header field of the 423 (Interval Too Brief) response.

6.2.3 Test description

6.2.3.1 Pre-test conditions

System Simulator:

– SS is listening to SIP default port 5060 for both UDP and TCP protocols.

– SS is able to perform IMS AKA authentication for the IMPI, according to 3GPP TS 33.203 [16] clause 6.1.

– 1 NR Cell

– UE provided with a second P-CSCF in the PDU SESSION ESTABLISHMENT ACCEPT according to Table 4.7.2-2 (conditions Additional_P-CSCF_IPv6 and Additional_P-CSCF_IPv4) of TS 38.508-1 [21].

UE:

– The UE contains either ISIM and USIM applications or only USIM application on UICC.

– The UE is configured to register for IMS after switch on.

– The UE is switched off.

Preamble:

– None

6.2.3.2 Test procedure sequence

Table 6.2.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	The UE is switched on			–	–
2	UE sends an initial registration request.	–>	REGISTER	–	–
3	SS sends 503 Service Unavailable without Retry-After header.	<–	503 Service Unavailable	–	–
–	The subsequent messages are sent to second P-CSCF	–	–	–	–
4	Check: does the UE send an initial registration request ?	–>	REGISTER	1	P
5	SS sends 503 Service Unavailable with Retry-After header set to 10 seconds.	<–	503 Service Unavailable	–	–
6	Check: does the UE send an initial registration request, but no earlier than 10 seconds after step 5?	–>	REGISTER	2	P
7	SS sends 423 Interval Too Brief.	<–	423 Interval Too Brief	–	–
8	Check: does the UE send an initial registration request with an expiration value set to the value provided in Step 7?	–>	REGISTER	3	P
9	SS sends 401 Unauthorized.	<–	401 Unauthorized	–	–
10	UE sends a subsequent registration request.	–>	REGISTER	–	–
11	SS sends 200 OK for REGISTER	<–	200 OK	–	–
	EXCEPTION: In parallel to the events described in steps 12 to 15, the steps specified in Table 6.1.3.2-2 may take place.	–	–	–	–
12-15	Steps 5-8 from clause A.2.	–	–	–	–
NOTE: The associated NR/5GC signalling is specified in TS 38.508-1 [21] generic procedure 4.5.2.

Table 6.2.3.2-2: Parallel Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE sends a PUBLISH request.	–>	PUBLISH	–	–
2	SS sends a 503 Service Unavailable response	<–	503 Service Unavailable	–	–

6.2.3.3 Specific message contents

Table 6.2.3.3-1: REGISTER (step 2, table 6.2.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.1, Condition A1

Table 6.2.3.3-2: 503 Service Unavailable (step 3, table 6.2.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.4.2
Header/param	Cond	Value/remark	Rel	Reference
Retry-After		not present

Table 6.2.3.3-3: REGISTER (step 4, table 6.2.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.1, Condition A1

Table 6.2.3.3-4: 503 Service Unavailable (step 5, table 6.2.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.4.2
Header/param	Cond	Value/remark	Rel	Reference
Retry-After
delta-seconds		10

Table 6.2.3.3-5: REGISTER (step 6, table 6.2.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.1, Condition A1

Table 6.2.3.3-6: 423 Interval Too Brief (step 7, table 6.2.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.7
Header/param	Cond	Value/remark	Rel	Reference
Min-Expires
delta-seconds		800000

Table 6.2.3.3-7: REGISTER (step 8, table 6.2.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.1, Condition A1
Header/param	Cond	Value/remark	Rel	Reference
Contact
expires		800000
Expires
delta-seconds		800000 Note: value 800000 is given in at least one of Contact or Expires header.
CSeq
value		incremented from previous REGISTER

Table 6.2.3.3-8: 401 Unauthorized (step 9, table 6.2.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.2, Condition A1

Table 6.2.3.3-9: REGISTER (step 10, table 6.2.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.1, Conditions A2 and A32
Header/param	Cond	Value/remark	Rel	Reference
Contact
expires		800000
Expires
delta-seconds		800000 Note: value 800000 is given in at least one of Contact or Expires header.

Table 6.2.3.3-10: 200 OK (step 11, table 6.2.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.3, Condition A2
Header/param	Cond	Value/remark	Rel	Reference
Contact
expires		800000

6.3 Re-Registration Scenarios / 5GS

6.3.1 Test Purpose (TP)

(1)

with { UE being registered to IMS with expiration interval at 120 seconds }

ensure that {

when { 60 seconds passed }

then {UE re-registers }

}

(2)

with { UE starting re-registration procedure by sending REGISTER }

ensure that {

when { UE receives 500 Server Internal Error response }

then {UE starts initial registration }

}

(3)

with { UE being registered to IMS with expiration interval at 360 seconds }

ensure that {

when { 180 seconds passed }

then {UE re-registers }

}

(4)

with { UE being registered to IMS with expiration interval at 1600 seconds }

ensure that {

when { 1000 seconds passed }

then {UE re-registers }

}

(5)

with { UE attempting re-registration }

ensure that {

when { UE receives 423 Interval Too Brief response }

then {UE sends another re-registration request with given expiration interval }

}

(6)

with { UE being registered }

ensure that {

when { UE receives notification about shortened expiration interval for one of its registered public user identities }

then {UE re-registers after half of the shorted expiration interval elapses }

}

6.3.2 Conformance Requirements

The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.

[TS 24.229, clause 5.1.1.4.1]:

The UE can perform the reregistration of a previously registered public user identity bound to any one of its contact addresses and the associated set of security associations or TLS sessions at any time after the initial registration has been completed.

…

On receiving a 423 (Interval Too Brief) response to the REGISTER request, the UE shall:

On receiving a 408 (Request Timeout) response or 500 (Server Internal Error) response or 504 (Server Time-Out) response or 403 (Forbidden) response for a reregistration, the UE shall perform the procedures for initial registration as described in subclause 5.1.1.2.

[TS 24.229, clause 5.1.1.4.1]:

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.

6.3.3 Test description

6.3.3.1 Pre-test conditions

System Simulator:

– SS is listening to SIP default port 5060 for both UDP and TCP protocols.

– SS is able to perform IMS AKA authentication for the IMPI, according to 3GPP TS 33.203 [16] clause 6.1.

– 1 NR Cell

UE:

– The UE contains either ISIM and USIM applications or only USIM application on UICC.

– The UE is configured to register for IMS after switch on.

– The UE is switched off.

Preamble:

– None

6.3.3.2 Test procedure sequence

Table 6.3.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE is switched on.
2-9	Steps 1-8 from clause A.2: initial IMS registration happens, with SS giving 120 seconds expiration interval.
10	UE re-registers 60 seconds later.	–>	REGISTER	1	P
11	SS declines re-registration attempt.	<–	500 Server Internal Error
12	Step 1 from clause A.2: UE sends initial IMS registration request	–>	REGISTER	2	P
13-19	Steps 2-8 from clause A.2, with SS giving 360 seconds expiration interval.
20	UE re-registers 180 seconds later.	–>	REGISTER	3	P
21	SS responds with 1600 seconds expiration interval	<–	200 OK
22	UE re-registers 1000 seconds later	–>	REGISTER	4	P
23	SS responds with 423 Interval Too Brief with Min-Expires value of 800000 seconds	<–	423 Interval Too Brief
24	UE sends a new another re-registration request using at least 800000 seconds expiration.	–>	REGISTER	5	P
25	SS responds with 200 OK.	<–	200 OK
26	SS notifies UE about shortened expiration time of 60 seconds for one of the registered public user identities.	<–	NOTIFY
27	UE responds with 200 OK	–>	200 OK
28	30 seconds before new expiry time, UE re-registers	–>	REGISTER	6	P
29	SS responds with authentication challenge and security mechanism supported by the network	<–	401 Unauthorized
30	UE completes security procedures	–>	REGISTER
31	SS responds with 200 OK	<–	200 OK
NOTE: The associated NR/5GC signalling is specified in TS 38.508-1 [21] generic procedure 4.5.2.

6.3.3.3 Specific message contents

Table 6.3.3.3-1: 200 OK for REGISTER (step 5, Table 6.3.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.3
Header/param	Cond	Value/remark	Rel	Reference
Contact
expires		120

Table 6.3.3.3-2: REGISTER (step 10, Table 6.3.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.1, Conditions A2, A17, A32
Header/param	Cond	Value/remark	Rel	Reference
Security-Client
spi-c		new SPI number of the inbound SA at the protected client port, shall be different from previously used number
spi-s		new SPI number of the inbound SA at the protected server port, shall be different from previously used number
port-c		new protected client port, shall be different from previously used number
port-s		same value as in the previous REGISTER
Authorization				RFC 2617 [23]
nonce-count		2		TS 24.229 [7]

Table 6.3.3.3-3: 500 Server Internal Error (step 11, Table 6.3.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.4.7

Table 6.3.3.3-4: 200 OK for REGISTER (step 15, Table 6.3.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.3
Header/param	Cond	Value/remark	Rel	Reference
Contact
expires		360

Table 6.3.3.3-5: REGISTER (step 20, Table 6.3.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.1, Conditions A2, A17, A32
Header/param	Cond	Value/remark	Rel	Reference
Security-Client
spi-c		new SPI number of the inbound SA at the protected client port, shall be different from previously used numbers
spi-s		new SPI number of the inbound SA at the protected server port, shall be different from previously used numbers
port-c		new protected client port, shall be different from previously used numbers
port-s		same value as in the previous REGISTER
Authorization				RFC 2617 [23]
nonce-count		2		TS 24.229 [7]

Table 6.3.3.3-6: 200 OK for REGISTER (step 21, Table 6.3.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.3
Header/param	Cond	Value/remark	Rel	Reference
Contact
expires		1600

Table 6.3.3.3-7: REGISTER (step 22, Table 6.3.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.1, Conditions A2, A17, A32
Header/param	Cond	Value/remark	Rel	Reference
Security-Client
spi-c		new SPI number of the inbound SA at the protected client port, shall be different from previously used numbers
spi-s		new SPI number of the inbound SA at the protected server port, shall be different from previously used numbers
port-c		new protected client port, shall be different from previously used numbers
port-s		same value as in the previous REGISTER
Authorization				RFC 2617 [23]
nonce-count		3		TS 24.229 [7]

Table 6.3.3.3-8: 423 Interval Too Brief (step 23, Table 6.3.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.7
Header/param	Cond	Value/remark	Rel	Reference
Min-Expires
delta-seconds		800000

Table 6.3.3.3-9: REGISTER (step 24, Table 6.3.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.1, Conditions A2, A17, A32
Header/param	Cond	Value/remark	Rel	Reference
Contact
expires		800000 or more (Remark: either the Contact header contains such expires parameter or below Expires header is present. If both are present, Expires header is to be ignored)
Expires
delta-seconds		800000 or more (Remark: either the Contact header contains above expires parameter or Expires header is present. If both are present, Expires header is to be ignored)
Authorization				RFC 2617 [23]
nonce-count		4		TS 24.229 [7]

Table 6.3.3.3-9A: 200 OK for REGISTER (step 25, Table 6.3.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.3
Header/param	Cond	Value/remark	Rel	Reference
Contact
expires		800000

Table 6.3.3.3-10: NOTIFY (step 26, Table 6.3.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.6, Conditions A1, and A3 OR A4
Header/param	Cond	Value/remark	Rel	Reference
Message-body
	A3	<?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>
	A4	<?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>

Table 6.3.3.3-11: 200 OK for other requests than REGISTER or SUBSCRIBE (step 27, Table 6.3.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.3.1, Conditions A5, A11, A22

Table 6.3.3.3-12: REGISTER (step 28, Table 6.3.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.1, Conditions A2, A17, A32
Header/param	Cond	Value/remark	Rel	Reference
Contact
expires		800000 (if present)
Expires		present if no expires parameter in Contact header
delta-seconds		800000
Authorization
nonce-count		5

Table 6.3.3.3-13: 401 Unauthorized (step 29, Table 6.3.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.2, Condition A1
Header/param	Cond	Value/remark	Rel	Reference
WWW-Authenticate				RFC 2617 [23]
nonce		Base 64 encoding of new RAND and new AUTN (different from the values used in step 3)		TS 24.229 [7]

Table 6.3.3.3-14: REGISTER (step 30, Table 6.3.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.1, Conditions A2, A17, A32
Header/param	Cond	Value/remark	Rel	Reference
Contact
expires		800000 (if present)
Expires		present if no expires parameter in Contact header
delta-seconds		800000
Authorization
nonce-count		1

Table 6.3.3.3-15: 200 OK for REGISTER (step 31, Table 6.3.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.3, Condition A2

6.4 De-Registration Scenarios / 5GS

6.4.1 Test Purpose (TP)

(1)

Void

(2)

with { UE being registered to IMS }

ensure that {

when { UE receiving a NOTIFY request containing de-registration information with contact elements being "deactivated" }

then { UE acknowledges de-registration }

}

(3)

with { UE being de-registered from IMS by the network with contact elements being "deactivated" }

ensure that {

when { UE acknowledging de-registration }

then { UE performs initial registration to IMS }

}

(4)

with { UE being registered to IMS }

ensure that {

when { UE is made to de-register its contact address }

then { UE performs de-registration from IMS }

}

6.4.2 Conformance Requirements

The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.

[TS 24.229, clause 5.4.1.5]:

For any registered public user identity, the S-CSCF can deregister:

– all contact addresses bound to the indicated public user identity (i.e. deregister the respective public user identity);

– some contact addresses bound to the indicated public user identity;

– a particular contact address bound to the indicated public user identity; or

– one or more registration flows and the associated contact address bound to the indicated public user identity, when the UE supports multiple registration procedure;

by sending a single NOTIFY request.

…

When a network-initiated deregistration event occurs for one or more public user identities that are bound either to one or more contact addresses or registration flows and the associated contact addresses (if the multiple registration mechanism is used), the S-CSCF shall send a NOTIFY request to all subscribers that have subscribed to the respective reg event package. For each NOTIFY request, the S-CSCF shall:

1) set the Request-URI and Route header field to the saved route information during subscription;

2) set the Event header field to the "reg" value;

3) in the body of the NOTIFY request, include as many <registration> elements as many public user identities the S-CSCF is aware of the user owns;

4) set the aor attribute within each <registration> element to one public user identity:

a) set the <uri> sub-element inside each <contact> sub-element of each <registration> element to the respective contact address provided by the UE;

b) if the public user identity:

i) has been deregistered (i.e. all contact addresses and all registration flows and associated contact addresses bound to the indicated public user identity are removed) then:

– set the state attribute within the <registration> element to "terminated";

– set the state attribute within each <contact> element belonging to this UE to "terminated"; and

– set the event attribute within each <contact> element belonging to this UE to either "unregistered", or "deactivated" if the S-CSCF expects the UE to reregister or "rejected" if the S-CSCF does not expect the UE to reregister; or

…

When sending a final NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" (i.e. all public user identities have been deregistered or expired), the S-CSCF shall also terminate the subscription to the registration event package by setting the Subscription-State header field to the value of "terminated".

[TS 24.229, clause 5.1.1.7]:

Upon receipt of a NOTIFY request, on any dialog which was generated during the 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:

1) the state attribute within the <registration> element set to "terminated", and within each <contact> element belonging to this UE, the state attribute set to "terminated" and the event attribute set either to "unregistered", or "rejected", or "deactivated", the UE shall remove all registration details relating to the respective public user identity (i.e. consider the public user identity indicated in the aor attribute of the <registration> element as deregistered); or

…

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 all security associations or TLS sessions towards the P-CSCF either:

– if all <registration> element(s) have their state attribute set to "terminated" (i.e. all public user identities are deregistered) and the Subscription-State header field 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".

When all UE’s public user identities are registered via a single P-CSCF and the subscription dialog to the reg event package of the UE is set via the respective P-CSCF, the UE shall delete these security associations or TLS sessions towards the respective P-CSCF when all public user identities have been deregistered and after the server transaction (as defined in RFC 3261 [26]) pertaining to the received NOTIFY request terminates.

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

NOTE 4: If all the public user identities (i.e. <contact> elements) registered by this UE are deregistered and the security associations or TLS sessions have been removed, the UE considers the subscription to the reg event package terminated since the NOTIFY request was received with Subscription-State header field containing the value of "terminated".

[TS 24.229, clause 5.1.1.6.1]:

For any public user identity that the UE has previously registered, the UE can deregister via a single registration procedure:

– all contact addresses bound to the indicated public user identity;

– some contact addresses bound to the indicated public user identity;

– a particular contact address bound to the indicated public user identity; or

– when the UE supports multiple registrations (i.e. the "outbound" option tag is included in the Supported header field) one or more flows bound to the indicated public user identity.

The UE can deregister a public user identity that it has previously registered with its contact address at any time. The UE shall protect the REGISTER request using a security association or TLS session that is associated with contact address, see 3GPP TS 33.203 [19], established as a result of an earlier registration, if one is available.

Prior to sending a REGISTER request for deregistration, the UE shall release all dialogs that were using the contact addresses or the flow that is going to be deregistered and related to the public user identity that is going to be deregistered or to one of the implicitly registered public user identities. However:

– if the dialog that was established by the UE subscribing to the reg event package used the public user identity that is going to be deregistered; and

– this dialog is the only remaining dialog used for subscription to reg event package of the user, i.e. there are no other contact addresses registered with associated subscription to the reg event package of the user;

then the UE shall not release this dialog.

On sending a REGISTER request that will remove the binding between the public user identity and one of its contact addresses or one of its flows, the UE shall populate the header fields as follows:

a) a From header field set to the SIP URI that contains:

1) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, the main URI of the UE; else

2) the public user identity to be deregistered;

b) a To header field set to the SIP URI that contains:

1) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, the main URI of the UE; else

2) the public user identity to be deregistered;

c) a Contact header field set to the SIP URI(s) that contain(s) in the hostport parameter the IP address of the UE or FQDN, and:

1) if the UE is removing the binding between the public user identity indicated in the To header field, (together with the associated implicitly registered public user identities), and the contact address indicated in the Contact header field; and

– if the UE supports GRUU, or multiple registrations (i.e. the "outbound" option tag is included in the Supported header field), or has an IMEI available, or has an MEID available, the Contact header field also contains the "+sip.instance" header field parameter. Only the IMEI shall be used for generating an instance ID for a multi-mode UE that supports both 3GPP and 3GPP2 defined radio access networks;

– if the UE supports multiple registrations (i.e. the "outbound" option tag is included in the Supported header field), the Contact header field does not contain the "reg-id" header field parameter;

– if the UE does not supports GRUU and does not support multiple registrations (i.e. the "outbound" option tag is not included in the Supported header field), and does not have an IMEI available, and does not have an MEID available, the Contact header field does not contain either the "+sip.instance" header field parameter or the "reg-id" header field parameter;

NOTE 1: Since the contact address is deregistered, if there are any flows that were previously registered with the respective contact address, all flows terminating at the respective contact address are removed.

2) if the UE is removing the binding between the public user identity indicated in the To header field, (together with the associated implicitly registered public user identities) and one of its flows, the Contact header field contains the "+sip.instance" header field parameter and the "reg-id" header field parameter that identifies the flow; and

NOTE 2: The requirement placed on the UE to include an instance ID based on the IMEI when the UE does not support GRUU and does not support multiple registrations does not imply any additional requirements on the network.

3) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Contact URI without a user portion and containing the "bnc" URI parameter;

d) a Via header field set to include the IP address or FQDN of the UE in the sent-by field;

e) a registration expiration interval value set to the value of zero, appropriate to the deregistration requirements of the user;

f) a Request-URI set to the SIP URI of the domain name of the home network used to address the REGISTER request;

g) if available to the UE (as defined in the access technology specific annexes for each access technology), a P-Access-Network-Info header field set as specified for the access network technology (see subclause 7.2A.4);

h) a Security-Client header field to announce the media plane security mechanisms the UE supports, if any;

NOTE 3: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

i) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Require header field containing the option-tag "gin"; and

j) if the UE supports RFC 6140 [191] and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Proxy-Require header field containing the option-tag "gin".

For a public user identity that the UE has registered with multiple contact addresses or multiple flows (e.g. via different P-CSCFs), the UE shall also be able to deregister multiple contact addresses or multiple flows, bound to its public user identity, via single deregistration procedure as specified in RFC 3261 [26]. The UE shall send a single REGISTER request, using one of its contact addresses and the associated set of security associations or TLS session, containing a list of Contact headers. Each Contact header field is populated as specified above in bullets a) through i).

The UE can deregister all contact addresses bound to its public user identity and associated with its private user identity. The UE shall send a single REGISTER request, using one of its contact addresses and the associated set of security associations or TLS session, containing a public user identity that is being deregistered in the To header field, and a single Contact header field with value of "*" and the Expires header field with a value of "0". The UE shall not include the "instance-id" feature tag and the "reg-id" header field parameter in the Contact header field in the REGISTER request.

NOTE 4: All entities subscribed to the reg event package of the user will be informed via NOTIFY request which contact addresses bound to the public user identity have been deregistered.

When a 401 (Unauthorized) response to a REGISTER request is received the UE shall behave as described in subclause 5.1.1.5.1.

On receiving the 200 (OK) response to the REGISTER request, the UE shall:

– remove all registration details relating to this public user identity and the associated contact address.

– store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports labelled with the "mediasec" header field parameter specified in subclause 7.2A.7 and received in the Security-Server header field, if any.

NOTE 5: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

If there are no more public user identities registered with this contact address, the UE shall delete any stored media plane security mechanisms and related keys and any security associations or TLS sessions and related keys it may have towards the IM CN subsystem.

If all public user identities are deregistered and all security association or TLS session is removed, then the UE shall consider subscription to the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an Expires header field containing a value of zero).

[TS 24.229, clause 5.1.1.6.2]:

On sending a REGISTER request, as defined in subclause 5.1.1.6.1, the UE shall additionally populate the header fields as follows:

a) an Authorization header field, with:

– the "username" header field parameter, set to the value of the private user identity;

– the "realm" header field parameter, set to the value as received in the "realm" WWW-Authenticate header field parameter;

– the "uri" header field parameter, set to the SIP URI of the domain name of the home network;

– the "nonce" header field parameter, set to last received nonce value; and

– the response directive, set to the last calculated response value;

b) additionally for each Contact header field and associated contact address, include the associated protected server port value in the hostport parameter;

c) additionally for the Via header field, include the protected server port value bound to the security association in the sent-by field;

d) a Security-Client header field, set to specify the signalling plane security mechanisms it supports, the IPsec layer algorithms for integrity and confidentiality protection it supports and the new parameter values needed for the setup of two new pairs of security associations. For further details see 3GPP TS 33.203 [19] and RFC 3329 [48]; and

e) a Security-Verify header field that contains the content of the Security-Server header field received in the 401 (Unauthorized) response of the last successful authentication.

NOTE 2: When the UE has received the 200 (OK) response for the REGISTER request of the only public user identity currently registered with this contact address and its associated set of implicitly registered public user identities (i.e. no other public user identity is registered), the UE removes the security association (between the P-CSCF and the UE) that were using this contact address. Therefore further SIP signalling using this security association (e.g. the NOTIFY request containing the deregistration event) will not reach the UE.

6.4.3 Test description

6.4.3.1 Pre-test conditions

System Simulator:

– SS is listening to SIP default port 5060 for both UDP and TCP protocols.

– SS is able to perform IMS AKA authentication for the IMPI, according to 3GPP TS 33.203 [16] clause 6.1.

– 1 NR Cell

UE:

– The UE contains either ISIM and USIM applications or only USIM application on UICC.

– The UE is configured to register for IMS after switch on.

– The UE is switched off.

Preamble:

– None

6.4.3.2 Test procedure sequence

Table 6.4.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE is switched on.	–	–	–	–
2-9	Steps 1-8 from Annex A.2: initial IMS registration happens.	–	–	–	–
10-12	Void	–		–	–
13	SS de-registers the UE’s contact address.	<–	NOTIFY	–	–
14	UE acknowledges.	–>	200 OK	2	P
15-22	Steps 1-8 from Annex A.2: initial IMS registration happens.	–	–	3	P
–	EXCEPTION: Steps 23a1-23a8 describe behaviour that depends on UE configuration; the "lower case letter" identifies a step sequence that takes place if data centric mode is configured	–	–	–	–
23a1	IF [52] pc_data_centric THEN UE is made to de-register its contact address.	–	–	–	–
23a2-23a8	Steps 0A-2 defined in Annex A.11	–	–	4	P
24-29	Void	–	–	–	–
–	EXCEPTION: Steps 30a1 to 30a2 may be performed depending on UE implementation; the "lower case letter" identifies a step sequence that take place if the UE performs a specific action.	–	–	–	–
30a1	The UE transmits a PDU SESSION RELEASE REQUEST message to release ‘ims’ PDU session.	–>	PDU SESSION RELEASE REQUEST	–	–
30a2	PDU session release procedure defined in clause 4.9.21 of TS 38.508-1 [4] is performed.	–	–	–	–
–	EXCEPTION: Step 31a1 may be performed depending on UE implementation; the "lower case letter" identifies a step sequence that take place if the UE performs a specific action.	–	–	–	–
31a1	The UE transmits a DEREGISTRATION REQUEST message.	–>	DEREGISTRATION REQUEST	–	–
NOTE: The associated NR/5GC signalling is specified in TS 38.508-1 [21] generic procedure 4.5.2.

6.4.3.3 Specific message contents

Table 6.4.3.3-0: Void

Table 6.4.3.3-1: NOTIFY (step 13, Table 6.4.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.6, Conditions A1 AND ((A3 AND A6) OR (A4 AND A6))

Table 6.4.3.3-2: 200 OK for other requests than REGISTER or SUBSCRIBE (step 14, Table 6.4.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.3.1, Conditions A5, A11, A22

6.5 Void

6.6 Re-Registration after capability update / 5GS

6.6.1 Test Purpose (TP)

(1)

with { UE being registered to IMS }

ensure that {

when { UE is made to update its capabilities }

then { UE re-registers }

}

6.6.2 Conformance Requirements

The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.

[TS 24.229, clause 5.1.1.4.1]:

Unless either the user or the application within the UE has determined that a continued registration is not required the UE shall reregister an already registered public user identity either 600 seconds before the expiration time if the previous registration was for greater than 1200 seconds, or when half of the time has expired if the previous registration was for 1200 seconds or less, or when the UE intends to update its capabilities according to RFC 3840 [62] or when the UE needs to modify the ICSI values that the UE intends to use in a g.3gpp.icsi-ref media feature tag or IARI values that the UE intends to use in the g.3gpp.iari-ref media feature tag.

6.6.3 Test description

6.6.3.1 Pre-test conditions

System Simulator:

– SS is configured 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 [16] clause 6.1 and RFC 3310 [15].

– SS is listening to SIP default port 5060 for both UDP and TCP protocols.

– 1 NR Cell

UE:

– UE contains either ISIM and USIM applications or only USIM application on UICC.

– UE is registered to IMS services, by executing the generic test procedure in Annex A.2 up to the last step.

– UE is able to be made change its capabilities, manifested through a specific instance which is setting the AT Command +CASIMS (Availability for SMS using IMS, defined in 3GPP TS 27.007 [22] 8.72) to 0.

Preamble:

– UE complete the registration procedure and IMS PDU session establishment procedure according to Steps 2-19a1 of TS 38.508-1 table 4.5.2.2-2.

6.6.3.2 Test procedure sequence

Table 6.6.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE is made to turn off its SMS over IMS capability.
2	Check: does the UE initiate a re-registration procedure, and indicating the changed capabilities in the REGISTER message?	–>	REGISTER	1	P
3	Void
4	Void
5	SS responds with 200 OK for REGISTER	<–	200 OK

6.6.3.3 Specific message contents

Table 6.6.3.3-1: REGISTER (step 2, table 6.6.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.1, Condition A2, A17 and A32
Header/param	Cond	Value/remark	Rel	Reference
Contact
feature-param		does not contain "+g.3gpp.smsip"
Authorization
nonce-count		2

Table 6.6.3.3-2: Void

Table 6.6.3.3-3: Void

Table 6.6.3.3-4: 200 OK for REGISTER (step 5, table 6.6.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.3, Condition A2

6.7 Authentication / MAC Parameter Invalid / Only two consecutive invalid challenges / 5GS

6.7.1 Test Purpose (TP)

(1)

with { UE starting registration procedure }

ensure that {

when { UE receiving invalid MAC parameter }

then { UE sends another REGISTER request without challenge response AUTS and populates a new Security-Client header }

}

(2)

with { UE having responded to invalid MAC parameter }

ensure that {

when { UE receives another invalid MAC parameter }

then { UE sends another REGISTER request without challenge response AUTS and populates a new Security-Client header }

}

(3)

Void

6.7.2 Conformance Requirements

The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.

[TS 24.229 clause 5.1.1.5.3]:

If, in a 401 (Unauthorized) response, either the MAC or SQN is incorrect the UE shall respond with a further REGISTER indicating to the S-CSCF that the challenge has been deemed invalid as follows:

– in the case where the UE deems the MAC parameter to be invalid the subsequent REGISTER request shall contain no "auts" Authorization header field parameter and an empty "response" Authorization header field parameter, i.e. no authentication challenge response;

…

Whenever the UE detects any of the above cases, the UE shall:

– send the REGISTER request using an existing set of security associations, if available (see 3GPP TS 33.203 [16]);

– populate a new Security-Client header field within the REGISTER request and associated contact address, set to specify the security mechanisms it supports, the IPsec layer algorithms for integrity and confidentiality protection it supports and the parameters needed for the new security association setup. These parameters shall contain new values for spi_uc, spi_us and port_uc; and

– not create a temporary set of security associations.

[TS 24.229 clause 5.1.1.5.12]:

A UE shall only respond to two consecutive invalid challenges and shall not automatically attempt authentication after receiving two consecutive invalid challenges. The UE may attempt to register with the network again after an implementation specific time.

6.7.3 Test description

6.7.3.1 Pre-test conditions

System Simulator:

– 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 is able to perform AKAv1-MD5 authentication algorithm for that IMPI, according to 3GPP TS 33.203 [16] clause 6.1 and RFC 3310 [15].

– SS is listening to SIP default port 5060 for both UDP and TCP protocols.

– 1 NR Cell

UE:

– UE contains either ISIM and USIM applications or only USIM application on UICC.

– The UE is configured to register for IMS after switch on.

– The UE is switched off.

Preamble:

– None.

6.7.3.2 Test procedure sequence

Table 6.7.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	The UE is switched on.
2	UE sends initial registration for IMS services.	–>	REGISTER
3	SS responds with an invalid AKAv1-MD5 authentication challenge with an invalid MAC value.	<–	401 Unauthorized
4	Check: does the UE send a REGISTER request: – contains no AUTS directive and an empty response directive, i.e. no authentication challenge response – UE populates a new Security-Client header set to specify the security mechanism it supports, the IPsec layer algorithms it supports and the parameters needed for the new security association setup	–>	REGISTER	1	P
5	SS responds with an invalid AKAv1-MD5 authentication challenge with an invalid MAC value.	<–	401 Unauthorized
6	Check: does the UE send another REGISTER request: – contains no AUTS directive and an empty response directive, i.e. no authentication challenge response – UE populates a new Security-Client header set to specify the security mechanism it supports, the IPsec layer algorithms it supports and the parameters needed for the new security association setup	–>	REGISTER	2	P
7	Void
8	Void
9-15	Steps 2-8 from Clause A.2 are performed.
NOTE: The associated NR/5GC signalling is specified in TS 38.508-1 [21] generic procedure 4.5.2.

6.7.3.3 Specific message contents

Table 6.7.3.3-1: REGISTER (step 2, table 6.7.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.1, Condition A1

Table 6.7.3.3-2: 401 Unauthorized for REGISTER (step 3/5, table 6.7.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.2, Condition A1
Header/param	Cond	Value/remark	Rel	Reference
WWW-Authenticate
nonce		Base 64 encoding of RAND and AUTN, generated using invalid MAC value

Table 6.7.3.3-3: REGISTER (step 4/6, table 6.7.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.1, Condition A1
Header/param	Cond	Value/remark	Rel	Reference
CSeq
value		must be incremented from previous REGISTER
Call-ID
callid		same value as in REGISTER at Step 2
Authorization
response		present, but empty
auts		not present
Security-Client
spi-c		new SPI number of the inbound SA at the protected client port, shall be different from previously used number(s)
spi-s		new SPI number of the inbound SA at the protected server port, shall be different from previously used number(s)
port-c		new protected client port, shall be different from previously used number(s)

6.8 Authentication / Security-Server missing / SQN out of range / 5GS

6.8.1 Test Purpose (TP)

(1)

with { UE starting registration procedure }

ensure that {

when { UE receiving a challenge response without Security-Server header }

then { UE abandons the authentication procedure and sends a new REGISTER request with new Call-ID }

}

(2)

with { UE having sent a new initial REGISTER request }

ensure that {

when { UE receiving a challenge response with SQN out of range }

then { UE sends another REGISTER request with challenge response AUTS and populates a new Security-Client header }

}

6.8.2 Conformance Requirements

The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.

[TS 24.229 clause 5.1.1.5.1]:

On receiving a 401 (Unauthorized) response to the REGISTER request, the UE shall:

1) extract the RAND and AUTN parameters;

…

In the case that the 401 (Unauthorized) response is deemed to be invalid then the UE shall behave as defined in subclause 5.1.1.5.3.

[TS 24.229, clause 5.1.1.5.3]

If, in a 401 (Unauthorized) response, either the MAC or SQN is incorrect the UE shall respond with a further REGISTER indicating to the S-CSCF that the challenge has been deemed invalid as follows:

– in the case where the UE deems the SQN to be out of range, the subsequent REGISTER request shall contain the "auts" Authorization header field parameter (see 3GPP TS 33.102 [18]).

NOTE: In the case of the SQN being out of range, a "response" Authorization header field parameter can be included by the UE, based on the procedures described in RFC 3310 [49].

Whenever the UE detects any of the above cases, the UE shall:

– send the REGISTER request using an existing set of security associations, if available (see 3GPP TS 33.203 [19]);

– not create a temporary set of security associations.

6.8.3 Test description

6.8.3.1 Pre-test conditions

System Simulator:

– 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 is able to perform AKAv1-MD5 authentication algorithm for that IMPI, according to 3GPP TS 33.203 [16] clause 6.1 and RFC 3310 [15].

– SS is listening to SIP default port 5060 for both UDP and TCP protocols.

– 1 NR Cell

UE:

– UE contains either ISIM and USIM applications or only USIM application on UICC.

– The UE is configured to register for IMS after switch on.

– The UE is switched off.

Preamble:

– None.

6.8.3.2 Test procedure sequence

Table 6.8.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	The UE is switched on.
2	UE sends initial registration for IMS services.	–>	REGISTER
3	SS responds challenge response without Security-Server header.	<–	401 Unauthorized
4	Check: does the UE sends a new REGISTER request with new Call-ID	–>	REGISTER	1	P
5	SS responds with an invalid AKAv1-MD5 authentication challenge with SQN out of range.	<–	401 Unauthorized
6	Check: does the UE send another REGISTER request: – contains AUTS directive – UE populates a new Security-Client header set to specify the security mechanism it supports, the IPsec layer algorithms it supports and the parameters needed for the new security association setup.	–>	REGISTER	2	P
7-13	Continue with Annex A.2 step 2-8 in order to get the UE in a stable registered state.	–
NOTE: The associated NR/5GC signalling is specified in TS 38.508-1 [21] generic procedure 4.5.2.

6.8.3.3 Specific message contents

Table 6.8.3.3-1: REGISTER (step 2, table 6.8.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.1, Condition A1

Table 6.8.3.3-2: 401 Unauthorized for REGISTER (step 3, table 6.8.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.2, Condition A1
Header/param	Cond	Value/remark	Rel	Reference
Security-Server		not present.

Table 6.8.3.3-3: REGISTER (step 4, table 6.8.3.2-1)

Derivation path: TS 34.229-1 [2], Table in subclause A.1.1, Condition A1 and A32
Header/param	Cond	Value/remark	Rel	Reference
Call-ID
callid		Value differs from the one sent in in Step 2 of table 6.8.3.2-1.

Table 6.8.3.3-4: 401 Unauthorized for REGISTER (step 5, table 6.8.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.2, Condition A1
Header/param	Cond	Value/remark	Rel	Reference
WWW-Authenticate
nonce		Base 64 encoding of RAND and AUTN, generated with SQN out of range with the AMF information field set to AMF_RESYNCH value to trigger SQN re-synchronisation procedure in test ISIM/USIM, see TS 34.108 clause 8.1.2.2.

Table 6.8.3.3-5: REGISTER (step 6, table 6.8.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.1, Conditions A1
Header/param	Cond	Value/remark	Rel	Reference
CSeq
value		must be incremented from previous REGISTER
Call-ID
callid		same value as in REGISTER at Step 4
Authorization
nonce		same as in previous 401 UNAUTHORIZED message
opaque		same as in previous 401 UNAUTHORIZED message
auts		any value
Security-Client
spi-c		new SPI number of the inbound SA at the protected client port, shall be different from previously used number
spi-s		new SPI number of the inbound SA at the protected server port, shall be different from previously used number
port-c		new protected client port, shall be different from previously used number

6.9 Subscription / 503 Service Unavailable / 5GS

6.9.1 Test Purpose (TP)

(1)

with { UE subscribing to reg event }

ensure that {

when { UE receives 503 Service unavailable containing a Retry-After header field }

then { UE does not reattempt the request for the indicated time period }

}

6.9.2 Conformance Requirements

The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.

[TS 24.229 clause 5.1.2.2]:

If the UE receives a 503 (Service Unavailable) response to an initial SUBSCRIBE request containing a Retry-After header field, then the UE shall not automatically reattempt the request until after the period indicated by the Retry-After header field contents.

6.9.3 Test description

6.9.3.1 Pre-test conditions

System Simulator:

– 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).

– SS is listening to SIP default port 5060 for both UDP and TCP protocols.

– 1 NR Cell

UE:

– UE contains either ISIM and USIM applications or only USIM application on UICC.

– The UE is configured to register for IMS after switch on.

– The UE is switched off.

Preamble:

– None.

6.9.3.2 Test procedure sequence

Table 6.9.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	The UE is switched on.
2-5	Steps 1-4 of Annex A.2 happen.
6	UE subscribes to its registration event package.	–>	SUBSCRIBE
7	SS responds with 503 response containing a Retry-After header with period set to T=128s.	<–	503 Service Unavailable
8	Check: does the SS receive the UE’s re-attempt of SUBSCRIBE within the Time T=128s?			1	F
9	UE reattempts to subscribe to its registration event package.	–>	SUBSCRIBE
10-12	Continue with Annex A.2 step 6-8 in order to get the UE in a stable registered state.	–
NOTE: The associated NR/5GC signalling is specified in TS 38.508-1 [21] generic procedure 4.5.2.

6.9.3.3 Specific message contents

Table 6.9.3.3-1: SUBSCRIBE for reg-event package (step 6, table 6.9.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.4, Conditions A1 and A7

Table 6.9.3.3-2: 503 Service Unavailable (step 7, table 6.9.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.4.2
Header/param	Cond	Value/remark	Rel	Reference
Retry-After				RFC 3261 [6]
period		128

Table 6.9.3.3-3: SUBSCRIBE for reg-event package (step 9, table 6.9.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in subclause A.1.4, Conditions A1 and A7
Header/param	Cond	Value/remark	Rel	Reference
Call-ID				RFC 3261 [6]
callid		value different from the previous SUBSCRIBE request