19.5 Emergency registration

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

19.5.1 New initial emergency registration / UE obtains from the serving IP-CAN an IP address different than the IP address used for the emergency registration

19.5.1.1 Definition

Test to verify that the UE having performed emergency registration which has not yet expired, triggers a new initial emergency registration, when the UE obtains a different IP address than the one used for current emergency registration. The process consists of sending an unprotected REGISTER request for new initial emergency registration over the EPS emergency bearers, receiving 401 response, sending another REGISTER request to complete the re-authentication and receiving the 200 OK for renewed registration.

19.5.1.2 Conformance requirement

[TS 24.229 clause 5.1.6.2A]:

The UE shall perform a new initial emergency registration, as specified in subclause 5.1.6.2, if the UE determines that:

– it has previously performed an emergency registration which has not yet expired; and

– it has obtained an IP address from the serving IP-CAN, as specified in subclause 9.2.1, different than the IP address used for the emergency registration.

[TS 24.229 clause 5.1.1.2.1]:

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 the public user identity to be registered;

b) a To header field set to the SIP URI that contains 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 supports GRUU (see table A.4, item A.4/53) or multiple registrations, the UE shall include a "+sip.instance" header field parameter containing the instance ID. If the UE supports multiple registrations it shall include "reg-id" header field parameter as described in RFC 5626 [92]. 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];

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 UDPis used. For TCP, the response is received on the TCP connection on which the request was sent. The UE shall also include an "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 2: 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 3: 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); and

i) a Security-Client header field to announce the media plane security mechanisms the UE supports, if any, labelled with the "mediasec" header field parameter specified in subclause 7.2A.7.

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

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

a) 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, the UE may initiate that mechanism on a media level when it initiates new media in an existing session.

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

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;

NOTE 6: When using the respective contact address and associated set of security associations or TLS session, the UE can utilize additional URIs contained in the P-Associated-URI header field and bound it to the respective contact address of the UE and the associated set of security associations or TLS session, e.g. for application purposes.

c) treat the identity under registration as a barred public user identity, if it is not included in the P-Associated-URI header field;

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 7: 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 8: 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 when using either the respective 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.

e) 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, and the UE supports GRUU (see table A.4, item A.4/53), 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;

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 9: 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; and

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

h) if the Via header field contains a "keep" header field parameter with a value, unless the UE detects that it is not behind a NAT, start to send keep-alives associated with the registration towards the P-CSCF, as described in RFC 6223 [143].

[TS 24.229 clause 5.1.1.4.1]:

The UE can perform the reregistration of a previously registered public user identity via an initial registration as specified in subclause 5.1.1.2, when binding the previously registered public user identity to new contact address or to the registration flow and the associated contact address (if the multiple registration mechanism is used).

… [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].

On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.2.1, the UE shall additionally:

1) If the UE supports multiple registrations and the REGISTER request contained the "+sip.instance" header field parameter and the "reg-id" header field parameter in the Contact header field, and the "outbound" option-tag in the Supported header field, the UE shall check whether the option-tag "outbound" is present in the Require header field. If the option-tag "outbound" is present, then the UE shall use the bidirectional flow as defined in RFC 5626 [92] as follows:

a) for UDP, the bidirectional flow consists of two unidirectional flows, i.e. the first unidirectional flow is identified with the UE’s protected client port, the P-CSCF’s protected server port, and the respective IP addresses. The UE uses this flow to send the requests and responses to the P-CSCF. The second unidirectional flow is identified with the P-CSCF’s protected client port, the UE’s protected server port and the IP addresses. The second unidirectional flow is used by the UE to receive the requests and responses from the P-CSCF; or

b) for TCP, the bidirectional flow is the TCP connection between the UE and the P-CSCF. This TCP connection was established by the UE, i.e. from the UE’s protected client port and the UE’s IP address to the P-CSCF’s protected server port and the P-CSCF’s IP address. This TCP connection is used to exchange SIP messages between the UE and the P-CSCF; and

2) set the security association lifetime to the longest of either the previously existing security association lifetime (if available), or the lifetime of the just completed registration plus 30 seconds.

NOTE 3: If the UE receives Authentication-Info, it will proceed as described in RFC 3310 [49].

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

[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;

2) check the validity of a received authentication challenge, as described in 3GPP TS 33.203 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. 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), 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;

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;

3) store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports received in the Security-Server header field, if any, according to the procedures described in draft-dawes-dispatch-mediasec-parameter.

NOTE 1: Security mechanisms that apply to the media plane are distinguished by the "mediasec" header field parameter.

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;

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

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.

[TS 33.203 clause 7.5]:

When a UE changes its IP address, e.g. by using the method described in RFC 3041 [18], then the UE shall delete the existing SA’s and initiate an unprotected registration procedure using the new IP address as the source IP address in the packets carrying the REGISTER messages.

Reference(s)

3GPP TS 24.229 [10], clauses 5.1.6.2A, 5.1.1.2.2, 5.1.1.2.1, 5.1.1.5.1 and 5.1.6.4, 33.203 clause 7.5 (release 9).

19.5.1.3 Test purpose

1) To verify that when UE obtains an IP address different than the IP address used for current emergency registration, which is not yet expired, the UE shall perform new initial emergency registration, as defined within 3GPP TS 24.229 [10] clause 5.1.6.2A.

19.5.1.4 Method of test

Initial conditions

SS is configured with the IMSI within the USIM application, the home domain name, public and private user identities (including the public emergency user identity allocated for the user) 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 AKAv1-MD5 authentication algorithm for that IMPI, according to 3GPP TS 33.203 [14] clause 6.1 and RFC 3310 [17].

UE contains either ISIM and USIM applications or only USIM application on UICC. In the E-UTRA attach SS has indicated to the UE that the cell supports E-UTRA emergency bearers. UE is registered to IMS services, by having executed the generic test procedure in Annex C.2 up to the last step. UE has registered to IMS emergency services, by having executed the generic test procedure in Annex C.20 up to the last step. Thereafter the UE has initiated an emergency call by having executed the generic test procedure in Annex C.22 up to the last step. The emergency call is released.

An IP address re-allocation is triggered by executing a network initiated detach procedure with detach type indication "re-attach required". The UE then triggers an Attach procedure. The SS indicates support of emergency bearers and allocates an IP address different from the one used in the attach procedure in the preamble.

Test procedure

applicable for a UE with E-UTRA support (TS 34.229-2 [5] A.18/1)

1-15) UE executes the procedures described in TS 36.508 [94] table 4.5A.4.3-1 steps 1 to 15 for EPS emergency bearer context activation, IMS emergency registration and subsequent IMS emergency speech call establishment with PSAP

16) Call is released on the UE. SS waits for the UE to send a BYE request.

17) SS responds to the BYE request with valid 200 OK response.

Expected sequence

Step	Direction		Message	Comment
	UE	SS
1			User initiates an emergency call
2-10			Steps defined in annex C.20 followed by the steps defined in annex C.22	IMS emergency registration by the UE followed by IMS emergency call setup with PSAP. Referred from 36.508 [94] table 4.5A.4.3-1 for a UE with E-UTRA support.
11			void
12			void
13-17			Steps defined in annex C.32	Make the UE release the call including EPS Bearer Deactivation procedure according to TS 36.508 [94] subclause 4.5A.15.

Specific Message Contents

INVITE (step 1 of Annex C.22)

Use the default message “INVITE for MO call setup” in annex A.2.1. with the following conditions:

– A7 “INVITE for creating an emergency session within an emergency registration” shall apply; and

– A8 “UE is capable of obtaining location information, has obtained its location and is setting up an emergency session” shall apply if the UE is capable of obtaining location information.

19.5.1.5 Test requirements

In steps 2-10 UE performs emergency EPS bearer context establishment and establishes an emergency call.

19.5.2 to 19.5.5 Void

19.5.6 User-initiated emergency reregistration / UE has emergency related ongoing dialog

19.5.6.1 Definition

Test to verify that the UE can correctly renew its emergency registration while an emergency call is going on and half of the registration time has expired. The process consists of sending a new REGISTER request over the existing security associations and EPS emergency bearers, receiving 401 response, sending another REGISTER request to complete the reauthentication and receiving the 200 OK for renewed registration.

19.5.6.2 Conformance requirement

[TS 24.229 clause 5.1.6.4]:

The UE shall perform user-initiated emergency reregistration as specified in subclause 5.1.1.4 if half of the time for the emergency registration has expired and:

– the UE has emergency related ongoing dialog; or

– standalone transactions exist; or

– the user initiates an emergency call.

[TS 24.229 clause 5.1.1.4.1]:

When sending a protected REGISTER request, the UE shall use a security association or TLS session associated with the contact address used to send the request, see 3GPP TS 33.203 [19], established as a result of an earlier initial registration.

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.

On sending a REGISTER request that does not contain a challenge response, the UE shall populate the header fields as follows:

a) a From header field set to the SIP URI that contains the public user identity to be registered;

b) a To header field set to the SIP URI that contains the public user identity to be registered;

c) a Contact header field set to include SIP URI(s) that contain(s) in the hostport parameter the IP address or FQDN of the UE, and containing the instance ID of the UE in the "+sip.instance" header field parameter, if the UE supports GRUU (see table A.4, item A.4/53) or multiple registrations. If the UE support multiple registrations, it shall include "reg-id" header field as described in RFC 5626 [92]. 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 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];

d) a Via header field set to include the IP address or FQDN of the UE in the sent-by field. For the TCP, the response is received on the TCP connection on which the request was sent. If the UE previously has previously negotiated sending of keep-alives associated with the registration, it shall include a "keep" header field parameter with no value in the Via header field, in order to indicate continuous support to send keep-alives, as described in draft-ietf-sipcore-keep [143];

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

NOTE 1: 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 if GRUU is supported, the option-tag "gruu";

h) 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); and

i) a Security-Client header field to announce the media plane security mechanisms the UE supports, if any, according to the procedures described in draft-dawes-dispatch-mediasec-parameter [174].

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

a) bind the new expiration time of the registration for this public user identity found in the To header field value to the contact address used in this registration;

b) store the list of service route values contained in the Service-Route header field and bind the list to the contact address used in registration, in order to build a proper preloaded Route header field value for new dialogs and standalone transactions when using the respective contact address;

NOTE 3: If the list of Service-Route headers saved from a previous registration and bound to this contact address and the associated set of security associations or TLS session already exist, then the received list of Service-Route headers replaces the old list.

NOTE 4: The UE can utilize additional URIs contained in the P-Associated-URI header field, e.g. for application purposes.

c) 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, and the UE supports GRUU (see table A.4, item A.4/53), 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;

d) store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports received in the Security-Server header field, if any, according to the procedures described in draft-dawes-dispatch-mediasec-parameter [174]; and

NOTE 5: Security mechanisms that apply to the media plane are distinguished by the "mediasec" header field parameter.

e) if the Via header field contains a "keep" header field parameter with a value, continue to send keep-alives as described in draft-ietf-sipcore-keep [143], towards the P-CSCF.

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

[TS 24.229 clause 5.1.1.4.2]:

On sending a REGISTER request, as defined in subclause 5.1.1.4.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 directive, 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" header field parameter, set to the last calculated response value;

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

NOTE 3: If the UE is setting up an additional registration using procedures specified in RFC 5626 [92] and the UE accesses the network through 3GPP or 3GPP2 systems without any NAT, the flow is considered to be "logical flow".

b) additionally for the Contact header field, 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;

d) a Security-Client header field, set to specify the signalling plane security mechanism it supports, the IPsec layer algorithms for security 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.

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

a) set the security association lifetime associated with this contact address and the associated set of security associations to the longest of either the previously existing security association lifetime, or the lifetime of the just completed registration plus 30 seconds.

[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;

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];

NOTE 1: Security mechanisms that apply to the media plane are distinguished by the "mediasec" header field parameter.

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

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:

Reference(s)

3GPP TS 24.229 [10], clauses 5.1.1.4.1, 5.1.1.4.2, 5.1.1.5.1 and 5.1.6.4 (release 9)

19.5.6.3 Test purpose

1) To verify that when half of the time for the emergency registration has expired and the UE has emergency related ongoing dialog, the UE shall perform user-initiated emergency reregistration, as defined within 3GPP TS 24.229 [10] clauses 5.1.6.4, 5.1.1.4.1, 5.1.1.4.2 and 5.1.1.5.1.

19.5.6.4 Method of test

Initial conditions

UE contains either ISIM and USIM applications or only USIM application on UICC. In the E-UTRA attach SS has indicated to the UE that the cell supports E-UTRA emergency bearers. UE is registered to IMS services, by executing the generic test procedure in Annex C.2 up to the last step. The UE has performed EPS emergency bearer context activation, IMS emergency registration and the subsequent IMS emergency call, s described in TS 36.508 [94] table 4.5A.4.3-1 steps 1 to 15. When performing the steps of Annex C.20 the SS sets the expiration time to 120 seconds in Step 4. Thereafter the UE has initiated an emergency call by executing the generic test procedure in Annex C.22 up to the last step.

Test procedure

1) When half of the initial emergency registration time has expired and while emergency call is still going on SS receives REGISTER request from the UE.

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

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

4) The SS responds with 200 OK over the new security association, setting the new expiration time as 1200 seconds

Expected sequence

Step	Direction		Message	Comment
	UE	SS
1	🡪		REGISTER	UE re-registers to the emergency services 60 seconds before the expected expiration.
2	🡨		401 Unauthorized	The SS responds with a valid AKAv1-MD5 authentication challenge and security mechanisms supported by the network.
3	🡪		REGISTER	UE completes the security negotiation procedures, sets up a new temporary set of SAs and uses those for sending another REGISTER with AKAv1-MD5 credentials.
4	🡨		200 OK	The SS responds with 200 OK.

Specific Message Contents

Use the default message “REGISTER” in annex A.1.1. with condition A2 "Subsequent REGISTER sent over security associations” and the following exceptions applying:

Header/param	Value/remark
Contact
addr-spec	SIP URI with IP address or FQDN and protected server port of UE. The SIP URI shall contain the sos URI parameter.
Security-Client
spi-c	new SPI number of the inbound SA at the protected client port
spi-s	new SPI number of the inbound SA at the protected server port
port-c	new protected client port needed for the setup of new pairs of security associations
port-s	Same value as in the previous REGISTER

401 Unauthorized for REGISTER (Step 2)

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

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

Use the default message “REGISTER” in annex A.1.1 like in step 1 above. The only difference is that the response value within Authorization header shall have been recalculated based on the nonce received from SS within 401 response.

200 OK for REGISTER (Step 4)

Use the default message “200 OK for REGISTER” in annex A.1.3 with condition A3 “Response for an emergency registration” and the expires parameter of Contact header set to 1200.

19.5.6.5 Test requirements

All the messages specified for this test case shall be sent over the EPS emergency bearers allocated for the initial emergency registration.

19.5.7 User-initiated emergency reregistration / The user initiates an emergency call

19.5.7.1 Definition

Test to verify that the UE can correctly renew its emergency registration while an emergency call is being initiated and half of the registration time has expired. The re-registration process consists of sending a new REGISTER request over the existing security associations and EPS emergency bearers, receiving 401 response, sending another REGISTER request to complete the reauthentication and receiving the 200 OK for renewed registration. The test case is applicable for IMS security.

19.5.7.2 Conformance requirement