10 Emergency Calls

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

10.1 Emergency Call with emergency registration / Success / Location information available / 5GS

10.1.1 Test Purpose (TP)

(1)

with { UE being registered to IMS }

ensure that {

when { UE is being made to initiate an emergency call }

then { UE sends a correctly composed initial REGISTER request for IMS emergency registration }

(2)

with { UE having sent an 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 for the REGISTER sent for authentication }

then { UE sends a correctly composed INVITE request }

}

(4)

with { UE having sent INVITE }

ensure that {

when { UE receiving 100 Trying, followed by 180 Ringing, followed by 200 OK }

then { UE sends ACK }

}

(5)

with { Emergency call being established }

ensure that {

when { UE receives BYE }

then { UE sends a 200 OK response }

}

10.1.2 Conformance Requirements

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

[TS 24.229 clause 4.7.5]:

A number of mechanisms also exist for providing location in support of emergency calls, both for routeing to a PSAP, and for use by the PSAP itself, in the IM CN subsystem:

a) by the inclusion by the UE of the Geolocation header field containing a location by reference or by value (see RFC 6442 [89]);

b) by the inclusion by the UE of a P-Access-Network-Info header field, which contains a cell identifier or location identifier, which is subsequently mapped, potentially by the recipient, into a real location;

…

Which means of providing location is used depends on local regulatory and operator requirements. One or more mechanisms can be used. Location can be subject to privacy constraints.

[TS 24.229 clause 5.1.6.2]:

When the user initiates an emergency call, if emergency registration is needed (including cases described in subclause 5.1.6.2A), the UE shall perform an emergency registration prior to sending the SIP request related to the emergency call.

…

When a UE performs an initial emergency registration the UE shall perform the actions as specified in subclause 5.1.1.2 with the following additions and modifications:

a) the UE shall include a "sos" SIP URI parameter in the Contact header field as described in subclause 7.2A.13, indicating that this is an emergency registration and that the associated contact address is allowed only for emergency service; and

b) the UE shall populate the From and To header fields of the REGISTER request with:

– the first entry in the list of public user identities provisioned in the UE;

– the default public user identity obtained during the normal registration, if the UE is not provisioned with a list of public user identities, but the UE is currently registered to the IM CN subsystem; and

– the derived temporary public user identity, in all other cases.

[TS 24.229 clause 5.1.6.3]

Upon receiving the 200 (OK) to the REGISTER request that completes the emergency registration, the UE shall not subscribe to the reg event package of the public user identity specified in the REGISTER request.

[TS 24.229 clause 5.1.6.5]

When a UE performs authentication a UE shall perform the procedures as specified in subclause 5.1.1.5.

[TS 24.229 clause 5.1.6.8.3]

After a successful initial emergency registration, the UE shall apply the procedures as specified in subclause 5.1.2A and 5.1.3 with the following additions:

1) the UE shall insert in the INVITE request, a From header field that includes the public user identity registered via emergency registration or the tel URI associated with the public user identity registered via emergency registration, as described in subclause 4.2;

2) the UE shall include a service URN in the Request-URI of the INVITE request in accordance with subclause 5.1.6.8.1;

3) the UE shall insert in the INVITE request, a To header field with the same emergency service URN as in the Request-URI;

4) if available to the UE, and if defined for the access type as specified in subclause 7.2A.4, the P-Access-Network-Info header field shall contain a location identifier such as the cell id, line id or the identity of the WLAN access node, which is relevant for routeing the IMS emergency call;

NOTE 1: The IMS emergency specification in 3GPP TS 23.167 [4B] describes several methods how the UE can get its location information from the access network or from a server. Such methods are not in the scope of this specification.

5) the UE shall insert in the INVITE request, one or two P-Preferred-Identity header field(s) that include the public user identity registered via emergency registration or the tel URI associated with the public user identity registered via emergency registration as described in subclause 4.2;

NOTE 2: Providing two P-Preferred-Identity header fields is usually supported by UE acting as enterprise network.

6) void;

7) if the UE has its location information available, or a URI that points to the location information, then the UE shall include a Geolocation header field in the INVITE request in the following way:

– if the UE is aware of the URI that points to where the UE’s location is stored, include the URI as the Geolocation header field value, as described in RFC 6442 [89]; or

– if the UE is aware of its location information, include the location information in a PIDF location object, in accordance with RFC 4119 [90], include the location object in a message body with the content type application/pidf+xml, and include a Content ID URL, referring to the message body, as the Geolocation header field value, as described RFC 6442 [89], and include a Content-Disposition header field with a disposition type "render" value and a "handling" header field parameter with an "optional" value, as described in RFC 3261 [26];

8) if the UE includes a Geolocation header field, the UE shall also include a Geolocation-Routing header field with a "yes" header field value, which indicates that the location of the UE can be used by other entities to make routing decisions, as described in RFC 6442 [89];

NOTE 3: It is suggested that UE’s only use the option of providing a URI when the domain part belongs to the current P-CSCF or S-CSCF provider. This is an issue on which the network operator needs to provide guidance to the end user. A URI that is only resolvable to the UE which is making the emergency call is not desirable.

9) if the UE has neither geographical location information available, nor a URI that points to the location information, the UE shall not insert a Geolocation header field in the INVITE request; and

10) if support of the current location discovery during an emergency call is allowed in the IP-CAN specific annex and the UE supports the current location discovery during an emergency call, the UE shall include a Recv-Info header field as described in RFC 6086 [25], indicating the g.3gpp.current-location-discovery info package name and shall include an Accept header field indicating the "application/vnd.3gpp.current-location-discovery+xml" MIME type.

NOTE 4: RFC 3261 [26] provides for the use of the Priority header field with a suggested value of "emergency". It is not precluded that emergency sessions contain this value, but such usage will have no impact on the processing within the IM CN subsystem.

[TS 24.237 clause 7.2]:

When originating an emergency call as specified in 3GPP TS 24.229 [2] and if the SC UE has an IMEI, then the SC UE shall include the sip.instance media feature tag as specified in IETF RFC 5626 [22] with value based on the IMEI as defined in 3GPP TS 23.003 [12] in the Contact header field of the SIP INVITE request according to IETF RFC 3840 [53].

[TS 23.003 clause 13.8]:

An instance-id is a SIP Contact header parameter that uniquely identifies the SIP UA performing a registration.

When an IMEI is available, the instance-id shall take the form of a IMEI URN (see RFC 7254 [79]). The format of the instance-id shall take the form "urn:gsma:imei:<imeival>" where by the imeival shall contain the IMEI encoded as defined in RFC 7254 [79]. The optional <sw-version-param> and <imei-version-param> parameters shall not be included in the instance-id. RFC 7255 [104] specifies additional considerations for using the IMEI as an instance-id. An example of such an instance-id is as follows:

EXAMPLE: urn:gsma:imei:90420156-025763-0

If no IMEI is available, the instance-id shall take the form of a string representation of a UUID as a URN as defined in IETF RFC 4122 [80]. An example of such an instance-id is as follows:

EXAMPLE: urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

For more information on the instance-id and when it is used, see 3GPP TS 24.229 [81].

10.1.3 Test description

10.1.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

– Test environment shall be set up to provide the needed input to the UE, in order for the UE to derive its location, if the UE uses Geolocation header for providing its geographical location. This shall be done by use of the test function Update UE Location Information defined in TS 38.509 [48], if supported by the UE according to pc_UpdateUE_LocationInformation. Otherwise, or in addition any other suitable method may also be used.

UE:

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

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

Preamble:

– The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS.

10.1.3.2 Test procedure sequence

Table 10.1.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE is made to make an emergency call	–	–	–	–
1A-1J	Steps 1-10 of test procedure specified in Table 4.9.11.2.2-1 of TS 38.508-1 [21] are performed.	–	–	–	–
2	Step 1 of annex A.3 (emergency registration) Check: Does the UE send a correctly composed initial REGISTER request for IMS emergency registration?	–>	REGISTER	1	P
3	Step 2 of annex A.3 (emergency registration)	<–	401 Unauthorized	–	–
4	Step 3 of annex A.3 (emergency registration) Check: Does the UE correctly authenticate itself by sending another REGISTER request with a correctly composed Authorization header using the AKAv1-MD5 algorithm?	–>	REGISTER	2	P
5	Step 4 of annex A.3 (emergency registration)	<–	200 OK	–	–
–	EXCEPTION: In parallel to steps 6-10 below, steps 11-13 of test procedure specified in Table 4.9.11.2.2-1 of TS 38.508-1 [21] takes place.	–	–	–	–
6	Step 1 of annex A.6 (emergency call) Check: Does the UE send a correctly composed INVITE request?	–>	INVITE	3	P
7	Step 2 of annex A.6 (emergency call)	<–	100 Trying	–	–
8	Step 3 of annex A.6 (emergency call)	<–	180 Ringing	–	–
9	Step 4 of annex A.6 (emergency call)	<–	200 OK	–	–
10	Step 5 of annex A.6 (emergency call) Check: Does the UE send ACK?	–>	ACK	4	P
11	Step 1 of annex A.8 (MT Release of Voice Call)	<–	BYE	–	–
12	Step 2 of annex A.8 (MT Release of Voice Call) Check: Does the UE send 200 OK for the BYE request and ends the call?	–>	200 OK	5	P

10.1.3.3 Specific message contents

Table 10.1.3.3-1: INVITE (step 6, table 10.1.3.2-1)

Derivation Path: Annex A.6, Step 1, with Conditions A7, A8, and A28 of TS 34.229-1 [2] cl A.2.1

10.2 Emergency Call with emergency registration / Success / Location information not available / 5GS

10.2.1 Test Purpose (TP)

(1)

with { UE being registered to IMS }

ensure that {

when { UE is being made to initiate an emergency call }

then { UE sends a correctly composed initial REGISTER request for IMS emergency registration }

(2)

with { UE having sent an 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 for the REGISTER sent for authentication }

then { UE sends a correctly composed INVITE request without location information }

}

(4)

with { UE having sent INVITE }

ensure that {

when { UE receiving 100 Trying, followed by 180 Ringing, followed by 200 OK }

then { UE sends ACK }

}

(5)

with { Emergency call being established }

ensure that {

when { UE receives BYE }

then { UE sends a 200 OK response }

}

10.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.6.1]:

If the IM CN subsystem is selected and the UE is currently attached to its home operator’s network (e.g. HPLMN) and the UE is currently registered and the IP-CAN defines emergency bearers and the core network has indicated that it supports emergency bearers, the UE shall:

1) perform an initial emergency registration, as described in subclause 5.1.6.2; and

2) attempt an emergency call as described in subclause 5.1.6.8.3.

[TS 24.229 clause 5.1.6.2]:

When a UE performs an initial emergency registration the UE shall perform the actions as specified in subclause 5.1.1.2 with the following additions and modifications:

b) the UE shall populate the From and To header fields of the REGISTER request with:

– the first entry in the list of public user identities provisioned in the UE;

– the derived temporary public user identity, in all other cases.

[TS 24.229 clause 5.1.6.8.1]:

When an initial request for a dialog or a standalone transaction, or an unknown method transmitted as part of UE detected emergency call procedures as defined in subclause 5.1.6 is initiated:

…

the Request-URI of the initial request for a dialog or the standalone transaction, or the unknown method transmitted as part of UE detected emergency call procedures as defined in subclause 5.1.6 shall include one of the following service URNs:

– "urn:service:sos", "urn:service:sos.ambulance", "urn:service:sos.police", "urn:service:sos.fire", "urn:service:sos.marine", "urn:service:sos.mountain", "urn:service:sos.ecall.manual", "urn:service:sos.ecall.automatic". If the UE can determine the type of emergency service the UE shall use an emergency service URN with a sub-service type corresponding to the type of emergency service.

[TS 24.229 clause 5.1.6.8.3]:

After a successful initial emergency registration, the UE shall apply the procedures as specified in subclause 5.1.2A and 5.1.3 with the following additions:

2) the UE shall include a service URN in the Request-URI of the INVITE request in accordance with subclause 5.1.6.8.1;

3) the UE shall insert in the INVITE request, a To header field with the same emergency service URN as in the Request-URI;

NOTE 2: Providing two P-Preferred-Identity header fields is usually supported by UE acting as enterprise network.

6) void;

7) if the UE has its location information available, or a URI that points to the location information, then the UE shall include a Geolocation header field in the INVITE request in the following way:

– if the UE is aware of the URI that points to where the UE’s location is stored, include the URI as the Geolocation header field value, as described in RFC 6442 [89]; or

9) if the UE has neither geographical location information available, nor a URI that points to the location information, the UE shall not insert a Geolocation header field in the INVITE request; and

[TS 24.229 annex U.2.2.6]:

For the purposes of this document, an emergency PDU session is the equivalent of emergency bearers; i.e. the 5GS defines emergency bearers for the support of emergency calls. Emergency PDU session is defined for use in emergency calls in 5GS and core network support of emergency PDU session is indicated to the UE in NAS signalling. Where the UE recognises that a call request is an emergency call and the core network supports emergency PDU session, the UE shall use emergency PDU session for both signalling and media for emergency calls made using the IM CN subsystem.

…

To perform emergency registration, the UE shall request to establish an emergency PDU session as described in 3GPP TS 24.501 [258]. The procedures for PDU session establishment and P-CSCF discovery, as described in subclause U.2.2.1 of this specification apply accordingly.

[TS 24.237 clause 7.2.1]:

[TS 23.003 clause 13.8]:

An instance-id is a SIP Contact header parameter that uniquely identifies the SIP UA performing a registration.

EXAMPLE: urn:gsma:imei:90420156-025763-0

If no IMEI is available, the instance-id shall take the form of a string representation of a UUID as a URN as defined in IETF RFC 4122 [80]. An example of such an instance-id is as follows:

EXAMPLE: urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

For more information on the instance-id and when it is used, see 3GPP TS 24.229 [81].

10.2.3 Test description

10.2.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

– Test environment shall ensure that UE cannot access any information (such as GPS signal) from which the UE would be able to derive its geographical location. The UE shall only be able to read the global cell ID as provided by the SS.

UE:

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

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

– UE is either not able to obtain location information or is configured to not obtain location information when setting up an emergency session.

Preamble:

– The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS.

10.2.3.2 Test procedure sequence

Same as test procedure sequence in clause 10.1.3.2

10.2.3.3 Specific message contents

Table 10.2.3.3-1: INVITE (step 6, table 10.2.3.2-1)

Derivation Path: Annex A.6 Step 1, with Conditions A7, A28 and NOT A8 of 34.229-1 [2] A.2.1

10.3 Emergency call with emergency registration / Emergency SIP signalling and media in parallel with another ongoing IM CN subsystem signalling and media / 5GS

10.3.1 Test Purpose (TP)

(1)

with { UE being registered to IMS, having set up a voice call, and having it put on hold }

ensure that {

when { UE is being made to initiate an emergency call }

then { UE initiates and completes IMS emergency registration }

}

(2)

with { UE being made to initiate an emergency call }

ensure that {

when { UE having completed IMS emergency registration }

then { UE sends correctly composed INVITE request for emergency call }

}

(3)

with { UE having sent INVITE }

ensure that {

when { UE receiving 100 Trying, followed by 180 Ringing, followed by 200 OK }

then { UE sends ACK }

}

(4)

with { Emergency call being established }

ensure that {

when { UE receives BYE }

then { UE sends a 200 OK response }

}

(5)

with { Emergency call being terminated }

ensure that {

when { UE having sent 200 OK for BYE }

then { UE sends re-INVITE and completes resumption of the original voice call }

}

10.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.6.1]:

1) perform an initial emergency registration, as described in subclause 5.1.6.2; and

2) attempt an emergency call as described in subclause 5.1.6.8.3.[TS 24.229 clause 5.1.6.2]:

When a UE performs an initial emergency registration the UE shall perform the actions as specified in subclause 5.1.1.2 with the following additions and modifications:

b) the UE shall populate the From and To header fields of the REGISTER request with:

– the first entry in the list of public user identities provisioned in the UE;

– the derived temporary public user identity, in all other cases.

[TS 24.229 clause 5.1.6.8.1]:

When an initial request for a dialog or a standalone transaction, or an unknown method transmitted as part of UE detected emergency call procedures as defined in subclause 5.1.6 is initiated:

…

[TS 24.229 clause 5.1.6.8.3]:

After a successful initial emergency registration, the UE shall apply the procedures as specified in subclause 5.1.2A and 5.1.3 with the following additions:

2) the UE shall include a service URN in the Request-URI of the INVITE request in accordance with subclause 5.1.6.8.1;

3) the UE shall insert in the INVITE request, a To header field with the same emergency service URN as in the Request-URI;

NOTE 2: Providing two P-Preferred-Identity header fields is usually supported by UE acting as enterprise network.

6) void;

7) if the UE has its location information available, or a URI that points to the location information, then the UE shall include a Geolocation header field in the INVITE request in the following way:

– if the UE is aware of the URI that points to where the UE’s location is stored, include the URI as the Geolocation header field value, as described in RFC 6442 [89]; or

9) if the UE has neither geographical location information available, nor a URI that points to the location information, the UE shall not insert a Geolocation header field in the INVITE request; and

[TS 24.229 annex U.2.2.6]:

…

[TS 24.237 clause 7.2.1]:

[TS 23.003 clause 13.8]:

An instance-id is a SIP Contact header parameter that uniquely identifies the SIP UA performing a registration.

EXAMPLE: urn:gsma:imei:90420156-025763-0

If no IMEI is available, the instance-id shall take the form of a string representation of a UUID as a URN as defined in IETF RFC 4122 [80]. An example of such an instance-id is as follows:

EXAMPLE: urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

For more information on the instance-id and when it is used, see 3GPP TS 24.229 [81].

10.3.3 Test description

10.3.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

UE:

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

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

Preamble:

– The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS and thereafter executing the generic test procedure in Annex A.4.1 up to and including its last step for a non-emergency voice call defined in Table 4.9.15.2.2-1 of TS 38.508-1 [21].

10.3.3.2 Test procedure sequence

Table 10.3.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE is made to hold the ongoing call	–	–	–	–
2-5	Ongoing call is put on hold by UE (Steps 1-4 of Annex A.17)	–	–	–	–
6	UE is made to initiate an emergency call	–	–	–	–
6A	Steps 1-8 of generic procedure specified in Table 4.9.11.2.2-1 of TS 38.508-1 [21] are performed.
–	EXCEPTION: In parallel with steps 7-10, steps 9-10 of generic procedure specified in Table 4.9.11.2.2-1 of TS 38.508-1 [21] take palce.	–	–	–	–
7-10	Check: Does the UE initiate and complete the IMS emergency registration? (Steps 1-4 of Annex A.3)	–	–	1	P
–	EXCEPTION: In parallel to steps 11-15 below, steps 11-13 of generic procedure specified in Table 4.9.11.2.2-1 of TS 38.508-1 [21] takes place.	–	–	–	–
11	Check: Does the UE send correctly composed INVITE request for emergency call? (Step 1 of Annex A.6)	–>	INVITE	2	P
12-14	SS sends 100 Trying, followed by 180 Ringing, followed by 200 OK. (Steps 2-4 of Annex A.6)	–	–	–	–
15	Check: Does the UE acknowledge? (Step 5 of Annex A.6)	–>	ACK	3	P
16	SS sends BYE to release the emergency call. (Step 1 of Annex A.8)	<–	BYE	–	–
17	Check: Does the UE send 200 OK response? (Step 2 of Annex A.8)	–>	200 OK	4	P
17A-17C	Steps 3b1-3b3 of generic procedure specified in Table 4.9.12B.2.2-1 of TS 38.508-1 [21] are performed.	–	–	–	–
18	UE is made to resume the original voice call	–	–	–	–
19-22	Check: Does the UE send re-INVITE and completes resumption of the original voice call? (Steps 1-4 of Annex A.17)	–	–	5	P
23	UE is made to release the original voice call	–	–	–	–
24	The UE sends BYE for the original voice call (Step 1 of Annex A.7)	–>	BYE	–	–
25	SS sends 200 OK for BYE (Step 2 of Annex A.7)	<–	200 OK	–	–

10.3.3.3 Specific message contents

None as fully specified in Annex A.17, A.3, A.6, A.8, and A.7, except for the following:

Table 10.3.3.3-1: INVITE (Step 11, table 10.3.3.2-1)

Derivation Path: A.6, step 1, conditions A7 and A28 of TS 34.229-1 [2] cl A.2.1

10.4 Non-UE detectable emergency call / IM CN sends a 1xx response / UE geographical location information available or not / 5GS

10.4.1 Test Purpose (TP)

(1)

with { UE being registered to IMS}

ensure that {

when { UE is being made to initiate a voice call it does not recognize as an emergency call }

then { UE sends a correctly composed INVITE request }

}

(2)

with { UE having sent INVITE for a non-UE detectable emergency call }

ensure that {

when { UE receives 183 Session Progress containing a P-Asserted-Identity header }

then { UE sends (after PRACK/200 OK) a correctly composed UPDATE request and completes the call setup }

}

10.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.1.6.10]

If the UE receives a 1xx or 200 (OK) response to an initial request for a dialog, the response containing a P-Asserted-Identity header field set to an emergency number as specified in 3GPP TS 22.101 [1A], and:

– if a public GRUU value (pub-gruu) has been saved associated with the public user identity, the public GRUU value has not been included in the Contact header field of the initial request for a dialog as specified in RFC 5627 [93];

– if a public GRUU value (pub-gruu) has not been saved and a protected server port was not included in the address in the Contact header field of the initial request for a dialog; or

– if the UE has its geographical location information available, or a URI that points to the location information, and the geographical location information or URI has not been included in the initial request for a dialog;

then the UE shall send an UPDATE request according to RFC 3311 [29]; and:

1) if available to the UE, and if defined for the access type as specified in subclause 7.2A.4, the UE shall include in the UPDATE request a P-Access-Network-Info header field and it shall contain a location identifier such as the cell id or the identity of the WLAN access node;

2) if the UE has its geographical location information available, or a URI that points to the location information, then the UE shall include it in the UPDATE request in the following way:

I) if the UE is aware of the URI that points to where the UE’s location is stored, include the URI as the Geolocation header field value, as described in RFC 6442 [89]; or

II) if the UE is aware of its location information, include the location information in a PIDF location object, in accordance with RFC 4119 [90], include the location object in a message body with the content type application/pidf+xml, and include a Content ID URL, referring to the message body, as the Geolocation header field value, as described RFC 6442 [89], and include a Content-Disposition header field with a disposition type "render" value and a "handling" header field parameter with an "optional" value, as described in RFC 3261 [26];

3) if the UE includes a Geolocation header field, the UE shall also include a Geolocation-Routing header field with a "yes" header field value, which indicates that the location of the UE can be used by other entities to make routing decisions, as described in RFC 6442 [89];

4) if the UE has neither geographical location information available, nor a URI that points to the location information, the UE shall not insert a Geolocation header field in the UPDATE request; and

5) if a public GRUU value ("pub-gruu" header field parameter) has been saved associated with the public user identity, then the UE shall insert the public GRUU ("pub-gruu" header field parameter) value in the Contact header field of the UPDATE request as specified in RFC 5627 [93]; otherwise the UE shall include the address in the Contact header field set in accordance with subclause 5.1.6.8.4, item 8.

NOTE 2: It is suggested that UEs only use the option of providing a URI when the domain part belongs to the current P-CSCF or S-CSCF provider. This is an issue on which the network operator needs to provide guidance to the end user. A URI that is only resolvable to the UE which is making the emergency call is not desirable.

NOTE 3: 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 (except CANCEL requests) or response (except CANCEL responses) within a dialog with the current point of attachment to the IP-CAN (e.g. the current cell information).

NOTE 4: In this version of the specification, only requests creating a dialog can request emergency services.

10.4.3 Test description

10.4.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

UE:

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

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

– UE is configured to use preconditions.

– The test environment shall be set up to provide the needed input to the UE, in order for the UE to derive its location, if the UE is capable of obtaining location information. This shall be done by use of the test function Update UE Location Information defined in TS 38.509 [48], if supported by the UE according to pc_UpdateUE_LocationInformation (Item 3 in Table A.4.3-2 in TS 36.523-2 [XX]). Otherwise, or in addition any other suitable method may also be used.

Preamble:

– UE is in state 1N-A (TS 38.508-1 [21]) and registered to IMS.

10.4.3.2 Test procedure sequence

Table 10.4.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Make the UE attempt an IMS voice call.			–	–
2-7	Steps 2-7 of test procedure specified in Table 4.9.15.2.2-1 of TS 38.508-1 [21] are performed.	–	–	–	–
–	EXCEPTION: In parallel to step 8 below, step 8 of test procedure specified in Table 4.9.15.2.2-1 of TS 38.508-1 [21] takes place.	–	–	–	–
8	Check: Does the UE send an INVITE (Step 1 of Annex A.4.1)?	–>	INVITE	1	P
9	SS sends a 100 Trying provisional response (Step 2 of Annex A.4.1)	<–	100 Trying	–	–
10-12	Steps 10 -12 of test procedure specified in Table 4.9.15.2.2-1 of TS 38.508-1 [21] are performed.	–	–	–	–
13	SS sends an SDP answer (Step 3 of Annex A.4.1)	<–	183 Session Progress	–	–
14	UE acks 183 Session Progress (Step 4 of Annex A.4.1)	–>	PRACK	–	–
15	SS responds to PRACK (Step 5 of Annex A.4.1)	<–	200 OK	–	–
16	Check: Does the UE send an UPDATE?	–>	UPDATE	2	P
17	SS responds to UPDATE (Step 7 of Annex A.4.1)	<–	200 OK	–	–
17A	SS sends 180 Ringing reliably. (Step 8 of Annex A.4.1)	<–	180 Ringing	–	–
17B	UE acknowledges reception of 180 Ringing. (Step 9 of Annex A.4.1)	–>	PRACK	–	–
17C	SS responds to PRACK. (Step10 of Annex A.4.1)	<–	200 OK	–	–
17D	SS responds to INVITE. (Step 11 of Annex A.4.1)	<–	200 OK	–	–
18	UE acks 200 OK for INVITE (Step 12 of Annex A.4.1)	–>	ACK	–	–
19-20	Steps 1-2 of the procedure A.8 are executed for MT release of speech call	–	–	–	–
21-23	Steps 3-5 of test procedure specified in Table 4.9.18.2.2-1 of TS 38.508-1 [21] are performed.	–	–	–	–

10.4.3.3 Specific message contents

Table 10.4.3.3-1: 183 Session Progress (step 11, table 10.4.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in annex A.2.3, Conditions A1, A5

Header/param

Cond

Value/remark

Rel

Reference

Message-body

The following SDP types and values.

Session description:

v=0

o=- 1111111111 1111111111 IN (addrtype) (unicast-address for SS)

s=-

c=IN (addrtype) (connection-address for SS)

b=AS:65

Time description:

t=0 0

Media description:

m=audio (transport port) RTP/AVP (fmt) [Note 1, 2]

b=AS:65

b=RS: (bandwidth-value) [Note 3]

b=RR: (bandwidth-value) [Note 3]

Attributes for media:

a=rtpmap: (payload type) EVS/16000/1 [Note 1, 8]

a=fmtp: (format) br=13.2; bw=swb; mode-set=0,1,2; max-red=220 [Note 8]

a=rtpmap: (payload type) EVS/16000/1 [Note 1, 9]

a=fmtp: (format) br=5.9-13.2; bw=nb-swb; mode-set=0,1,2; max-red=220 [Note 9]

a=ecn-capable-rtp: leap ect=0 [Note 6]

a=rtcp-fb:* nack ecn [Note 6]

a=rtcp-xr:ecn-sum [Note 6]

a=ptime:20

a=maxptime:240

Attributes for media security mechanism:

a=3ge2ae: requested [Note 7]

a=crypto:1 AES_CM_128_HMAC_SHA1_80inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4 [Note 7]

Note 1: The values for fmt, payload type and format are copied from step 1.

Note 2: Transport port is the port number of the SS (see RFC 3264 clause 6).

Note 3: The bandwidth-value is copied from step 1.

Note 4: Void

Note 5: Void

Note 6: Attributes for ECN Capability are present if the UE supports Explicit Congestion Notification.

Note 7: Attributes for media plane security are present if the use of end-to-access-edge security is supported by UE.

Note 8: This EVS configuration is sent if UE sent it as the first of its EVS configurations in INVITE.

Note 9: This EVS configuration is sent if UE did not send "br=13.2; bw=swb" as the first of its EVS configurations in INVITE.

Table 10.4.3.3-2: UPDATE (step 16, table 10.4.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in annex A.2.5, Conditions A1, A6
Header/param	Cond	Value/Remark
Geolocation locationURI	B1	cid-url indicating the Content-Id of the PIDF-LO within the multipart MIME body of INVITE request. (Note that location-by-reference URI is not allowed as the SS does not provide any external storage for location info for the UE to refer.)
Geolocation-Routing	B1	“yes”
Contact addr-spec		SIP URI with IP address or FQDN and protected server port of UE
Content-Type media-type		If condition A1 applies: multipart/mixed If condition A1 application/sdp
Message-body		If condition A1 applies, the multipart-mime body shall also contain a PIDF-LO element mapped to the same Content-ID which can be found from the Geolocation header The PIDF-LO shall contain at least the following elements: – One or more ‘geopriv’ elements, each containing: – One ‘location-info’ element describing the location of the UE; and – One ‘usage-rules’ element describing the limitations of the usage of the location info.

Condition	Explanation
B1	UE is capable of obtaining location information

Table 10.4.3.3-3: Void

Table 10.4.3.3-4: 200 OK (step 17, table 10.4.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.3.1, Condition A6.

10.5 Void

10.6 Non-UE detectable emergency call / IM CN sends 380 with an Alternative Service / Previous emergency IMS registration not expired / 5GS

10.6.1 Test Purpose (TP)

(1)

with { UE being registered to IMS }

ensure that {

when { UE is made to start an emergency call }

then { UE performs IMS registration and sets up emergency call }

}

(2)

with { Emergency call ongoing }

ensure that {

when { Network sends BYE }

then { UE sends 200 OK for BYE }

}

(3)

with { Emergency call being terminated }

ensure that {

when { UE is made to initiate a non UE detectable emergency call }

then { UE sends correctly composed INVITE request for normal voice call }

}

(4)

with { UE having sent INVITE for normal voice call }

ensure that {

when { UE receives 380 Alternative Service response }

then { UE acknowledges and initiates an emergency call }

}

(5)

with { Emergency call ongoing }

ensure that {

when { Network sends BYE }

then { UE sends 200 OK for BYE }

}

10.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.3.1]:

In the event the UE receives a 380 (Alternative Service) response to an initial INVITE request the response containing a P-Asserted-Identity header field with a value equal to the value of the last entry of the Path header field value received during registration and the response containing a 3GPP IM CN subsystem XML body that includes an <ims-3gpp> element, including a version attribute, with an <alternative-service> child element with the <type> child element set to "emergency" (see table 7.6.2), the UE shall select a domain in accordance with the conventions and rules specified in 3GPP TS 22.101 [1A] and 3GPP TS 23.167 [4B], and:

– if the CS domain is selected, the UE behaviour is defined in subclause 7.1.2 of 3GPP TS 23.167 [4B] and, where appropriate, in the access technology specific annex; and

– if the IM CN subsystem is selected, the UE shall apply the procedures in subclause 5.1.6 with the exception of selecting a domain for the emergency call attempt.

NOTE 10: The last entry on the Path header field value received during registration is the value of the SIP URI of the P-CSCF. If there are multiple registration flows associated with the registration, then the UE has received from the P-CSCF during registration multiple sets of Path header field values. The last entry of the Path header field value corresponding to the flow on which the 380 (Alternative Service) response was received is checked.

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

10.6.3 Test description

10.6.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

UE:

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

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

Preamble:

– UE is in state 1N-A (TS 38.508-1 [21]) and registered to IMS.

10.6.3.2 Test procedure sequence

Table 10.6.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE is made to make an emergency call	–	–	–	–
2-11	Steps 1-10 of generic procedure specified in Table 4.9.11.2.2-1 of TS 38.508-1 [21] are performed.	–	–	–	–
–	EXCEPTION: In parallel to the events described in steps 12-16 below the events specified in 11-13 of Table 4.9.11.2.2-1 of TS 38.508-1 [21] are performed.	–	–	–	–
12-15	Steps 1-4 of Annex A.6 happens	–	–	–	–
16	Step 5 of Annex A.6 happens Check: Does the UE send an ACK?	–>	ACK	1	P
17	Step 1 of Annex A.8 happens	<–	BYE	–	–
18	Step 2 of Annex A.8 happens Check: Does the UE send 200 OK for the BYE request and ends the call?	–>	200 OK	2	P
18A-18C	Steps 3b1-3b34 of generic procedure specified in Table 4.9.12B.2.2-1 of TS 38.508-1 [21] are performed to release emergency speech bearer and Keep emergency PDU session.	–	–	–	–
19	UE is made to attempt an IMS voice call	–	–	–	–
20	UE sends INVITE with the first SDP offer Check: Does the UE send correctly composed INVITE request for normal voice call?	–>	INVITE	3	P
21	SS responds with 380 Alternative Service	<–	380 Alternative Service	–	–
22	UE acknowledges the receipt of 380 Alternative Service response	–>	ACK	–	–
–	EXCEPTION: In parallel to the events described in steps 23-27 below the events specified in 11-13 of Table 4.9.11.2.2-1 of TS 38.508-1 [21] are performed.	–	–	–	–
23	Step 1 of Annex A.6 happens Check: Does UE send INVITE message for emergency call?	–>	INVITE	4	P
24-27	Steps 2-5 of Annex A.6 happens	–	–	–	–
28	Step 1 of Annex A.8 happens	<–	BYE	–	–
29	Step 2 of Annex A.8 happens Check: Does the UE send 200 OK for the BYE request and ends the call?	–>	200 OK	5	P

10.6.3.3 Specific message contents

Table 10.6.3.3-1: INVITE for non UE detectable emergency call (step 20, table 10.6.3.2-1)

Derivation path: TS 34.229-1 [2], Annex A.2.1, Conditions A1, A3, A4, A28, A29, and A30

Header/param

Cond

Value/remark

Rel

Reference

Message-body

The following SDP types and values.

Session description:

v=0

o=(username) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE)

s=(session name)

c=IN (addrtype) (connection-address for UE) [Note 1]

Time description:

t= (start-time) (stop-time)

Media description:

m=audio (transport port) [Note 2]

c=IN (addrtype) (connection-address for UE) [Note 1]

b=AS: (bandwidth-value)

Note 1: At least one "c=" field shall be present.

Note 2: EVS codec shall be present in the media attributes, optionally including channel number "/1".

TS 24.229 [7]

Table 10.6.3.3-2: 380 Alternative Service (step 21, table 10.6.3.2-1)

Derivation path: TS 34.229-1 [2], Annex A.4.1

Header/param

Cond

Value/remark

Rel

Reference

Message-body

<?xml version="1.0" encoding="UTF-8"?>

<ims-3gpp version="1">

<alternative-service>

<type>emergency</type>

<reason/>

<action>emergency-registration</action>

</alternative-service>

</ims-3gpp>

TS 24.229 [7]

Table 10.6.3.3-3: ACK (step 22, table 10.6.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.7, Conditions A1 and A4

10.7 Void

10.8 Void

10.9 Emergency call without emergency registration / UE credentials are not accepted / 5GS

10.9.1 Test Purpose (TP)

(1)

with { UE being registered to IMS and being made to initiate an emergency call }

ensure that {

when { UE attempts IMS emergency registration and network declines by sending 403 Forbidden }

then { UE initiates and completes IMS emergency calls on non-protected ports }

}

10.9.2 Conformance Requirements

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

[TS 33.203 clause 7.1]

The P‑CSCF is allowed to receive only REGISTER messages, messages relating to emergency services in accordance with TS 23.167 [31] and TS 24.229 [8], and error messages related to unprotected messages on unprotected ports. All other messages not arriving on a protected port shall be either discarded or rejected by the P‑CSCF.

4. The UE is allowed to receive only the following messages on an unprotected port:

– responses to unprotected REGISTER messages;

– messages relating to emergency services in accordance with TS 23.167 [31] and TS 24.229 [8];

– error messages related to unprotected messages.

All other messages not arriving on a protected port shall be rejected or silently discarded by the UE.

[TS 24.229 clause 5.1.6.1]

1) perform an initial emergency registration, as described in subclause 5.1.6.2; and

2) attempt an emergency call as described in subclause 5.1.6.8.3.

10.9.3 Test description

10.9.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

UE:

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

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

Preamble:

– The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS.

10.9.3.2 Test procedure sequence

Table 10.9.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Make the UE to initiate an emergency call.	–	–	–	–
2-9	Steps 1-8 of Table 4.9.11.2.2-1 of TS 38.508-1[21] are performed.	–	–	–	–
	EXCEPTION: In parallel to the events described in steps 10-11 below the events specified in steps 1a1 of Table 4.9.11.2.2-2 of TS 38.508-1 [21] take place.	–	–	–	–
10-11	Steps 9-10 of Table 4.9.11.2.2-1 of TS 38.508-1 [21] are performed.	–	–	–	–
12	UE sends REGISTER (Step 1 of Annex A.3)	–>	REGISTER	–	–
13	SS sends 401 Unauthorized (Step 2 of Annex A.3)	<–	401 Unauthorized	–	–
14	UE sends REGISTER (Step 3 of Annex A.3)	–>	REGISTER	–	–
15	SS sends 403 Forbidden The following messages are exchanged on non protected port.	<–	403 Forbidden
–	EXCEPTION: In parallel to steps 16-20 below, steps 16-18 of generic procedure specified in Table 4.9.12.2.2-1 of TS 38.508-1 [21] takes place.	–	–	–	–
16	Check: Does the UE send a correctly composed INVITE request? (Step 1 of annex A.6)	–>	INVITE	1	P
17	SS sends 100 Trying. (Step 2 of annex A.6)	<–	100 Trying	–	–
18	SS sends 180 Ringing. (Step 3 of annex A.6)	<–	180 Ringing	–	–
19	SS sends 200 OK. (Step 4 of annex A.6)	<–	200 OK	–	–
20	Check: Does the UE send ACK? (Step 5 of annex A.6)	–>	ACK	1	P
21	SS sends BYE. (Step 1 of annex A.8)	<–	BYE	–	–
22	UE sends 200 OK. (Step 1 of annex A.8)	–>	200 OK	–	–

10.9.3.3 Specific message contents

Table 10.9.3.3-1: 403 Forbidden (step 15, table 10.9.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.3.2, Conditions A1.

Table 10.9.3.3-2: INVITE (step 16, table 10.9.3.2-1)

Derivation Path: Annex A.6, Step 1, Conditions A6, A28 of TS 34.229-1 [2] cl A.2.1

Table 10.9.3.3-3: 180 Ringing (step 18, table 10.9.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.6, Conditions A4, A7, A14.

Table 10.9.3.3-4: 200 OK (step 19, table 10.9.3.2-1)

Derivation Path: Annex A.6, Step 4, Conditions A7, A10, A22 of TS 34.229-1 [2] cl A.3.1.

Table 10.9.3.3-5: BYE (step 21, table 10.9.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.8, Conditions A3, A6.

10.10 Emergency call without emergency registration / Failure of registration / Rejected by 403(Forbidden)

10.10.1 Test Purpose (TP)

(1)

with { UE being registered to IMS in V-PLMN and being made to initiate an emergency call }

ensure that {

when { UE attempts IMS emergency registration and visited network declines by sending 403 Forbidden }

then { UE initiates and completes anonymous IMS emergency calls on non-protected ports }

}

10.10.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]

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:

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

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

2) supports multiple registrations;

3) has an IMEI available; or

4) has an MEID available;

the UE shall include a "+sip.instance" header field parameter containing the instance ID. 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.

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.

If the UE supports multiple registrations it shall include a "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].

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

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.

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

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 6: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

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 Require header field containing the option-tag "gin"; and

k) 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".

[TS 24.229, clause 5.1.6.2]

If:

1) the UE receives a 403 (Forbidden) response to the REGISTER request for initial emergency registration containing an "sos" SIP URI parameter in the Contact header field; and

2) the response contains a 3GPP IM CN subsystem XML body that includes an <ims-3gpp> element, including a version attribute, with an <alternative-service> child element with the <type> child element set to "emergency" (see table 7.6.2) and <action> child element set to "anonymous-emergencycall" (see table 7.6.3);

the UE shall attempt an emergency call as described in subclause 5.1.6.8.2.

[TS 24.229, clause 5.1.6.8.2]

The UE shall apply the procedures as specified in subclause 5.1.2A.1 and subclause 5.1.3 with the following additions:

1) the UE shall set the From header field of the INVITE request to "Anonymous" as specified in RFC 3261 [26];

2) the UE shall include a service URN in the Request-URI of the initial INVITE request in accordance with subclause 5.1.6.8.1;

NOTE 1: Other specifications make provision for emergency service identifiers, which are not specifically the emergency service URN, to be recognised in the UE. Emergency service identifiers which the UE does not detect will be treated as a normal call by the UE.

3) the UE shall insert in the INVITE request, a To header field with the same emergency service URN as in the Request-URI;

4) if available to the UE (as defined in the access technology specific annexes for each access technology), the UE shall include in the P-Access-Network-Info header field in any request for a dialog, any subsequent request (except CANCEL requests) or response (except CANCEL responses) within a dialog or any request. Insertion of the P-Access-Network-Info header field into the ACK request is optional. The UE shall populate the P-Access-Network-Info header field with the current point of attachment to the IP-CAN as specified for the access network technology (see subclause 7.2A.4). The P-Access-Network-Info header field contains the location identifier such as the cell id, the line id or the identity of the WLAN access node, which is relevant for routeing the emergency call;

5) if defined by the access technology specific annex, the UE shall populate the P-Preferred-Identity header field in the INVITE request with an equipment identifier as a SIP URI. The special details of the equipment identifier to use depend on the IP-CAN;

6) a Contact header field set to include SIP URI that contains in the hostport parameter the IP address of the UE and an unprotected port where the UE will receive incoming requests belonging to this dialog. The UE shall also include a "sip.instance" media feature tag containing Instance ID as described in RFC 5626 [92]. The UE shall not include either the public or temporary GRUU in the Contact header field;

7) a Via header field set to include the IP address of the UE in the sent-by field and for the UDP the unprotected server port value where the UE will receive response to the emergency request, while for the TCP, the response is received on the TCP connection on which the emergency request was sent. For the UDP, the UE shall also include "rport" header field parameter with no value in the top 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, and during the lifetime of, the emergency session, as described in RFC 6223 [143];

NOTE 2: The UE inserts the same IP address and port number into the Contact header field and the Via header field, and sends all IP packets to the P-CSCF from this IP address and port number.

8) if the UE has its location information available, or a URI that points to the location information, the UE shall include a Geolocation header field in the INVITE request in the following way:

– if the UE is aware of the URI that points to where the UE’s location is stored, include the URI as the Geolocation header field value, as described in RFC 6442 [89]; or

9) if the UE includes a Geolocation header field, the UE shall also include a Geolocation-Routing header field with a "yes" header field value, which indicates that the location of the UE can be used by other entities to make routing decisions, as described in RFC 6442 [89];

10) if the UE has neither geographical location information available, nor a URI that points to the location information, the UE shall not insert a Geolocation header field in the INVITE request; and

11) if support of the current location discovery during an emergency call is allowed in the IP-CAN specific annex and the UE supports the current location discovery during an emergency call, the UE shall include a Recv-Info header field as described in RFC 6086 [25], indicating the g.3gpp.current-location-discovery info package name and shall include an Accept header field indicating the "application/vnd.3gpp.current-location-discovery+xml" MIME type.

NOTE 4: 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).

Reference(s)

TS 24.229 [10] clauses 5.1.1.2.1, 5.1.6.2 and 5.1.6.8.2.

10.10.3 Test description

10.10.3.1 Pre-test conditions

System Simulator:

– NR Cell 12 as specified in TS 38.508-1 [4] table 4.4.2-3 is configured and connected to 5GC, default parameters.

UE:

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

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

Preamble:

– The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS.

10.10.3.2 Test procedure sequence

Table 10.10.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
0	UE is made to initiate an emergency call.	–	–	–	–
1-8	Steps 1-8of Table 4.9.11.2.2-1 of TS 38.508-1 [21] are performed.	–	–	–	–
	EXCEPTION: In parallel to the events described in steps 9-10 below the events specified in steps 1a1 of Table 4.9.11.2.2-2 of TS 38.508-1 [21] take place.	–	—	–	–
9-10	Steps 9-10 of Table 4.9.11.2.2-1 of TS 38.508-1 [21] are performed.	–	–	–	–
11	UE sends REGISTER (Step 1 of Annex A.3)	–>	REGISTER	–	–
12	SS sends 403 Forbidden The following messages are exchanged on non protected port.	<–	403 Forbidden	–	–
–	EXCEPTION: In parallel to steps 13-17 below, steps 16-18 of generic procedure specified in Table 4.9.12.2.2-1 of TS 38.508-1 [21] takes place.	–	–	–	–
13	Check: Does the UE send a correctly composed INVITE request?	–>	INVITE	1	P
14	SS sends 100 Trying. (Step 2 of annex A.6)	<–	100 Trying	–	–
15	SS sends 180 Ringing	<–	180 Ringing	–	–
16	SS sends 200 OK. (Step 4 of annex A.6)	<–	200 OK	–	–
17	UE sends ACK. (Step 5 of annex A.6)	–>	ACK	–	–
18	SS sends BYE. (Step 1 of annex A.8)	<–	BYE	–	–
19	UE sends 200 OK. (Step 1 of annex A.8)	–>	200 OK	–	–

10.10.3.3 Specific message contents

Table 10.10.3.3-1: 403 Forbidden (step 12, table 10.10.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.3.2, Conditions A1.

Table 10.10.3.3-2: INVITE (step 13, table 10.10.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.1, Conditions A6, A28.

Header/param

Cond

Value/remark

Rel

Reference

Message-body

The following SDP types and values.

Session description:

v=0

o=(username) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE)

s=(session name)

c=IN (addrtype) (connection-address for UE) [Note 1]

Time description:

t= (start-time) (stop-time)

Media description:

m=audio (transport port) [Note 2]

c=IN (addrtype) (connection-address for UE) [Note 1]

b=AS: (bandwidth-value)

Note 1: At least one "c=" field shall be present.

Note 2: EVS codec shall be present in the media attributes, optionally including channel number "/1".

TS 24.229 [7]

Table 10.10.3.3-3: 180 Ringing (step 15, table 10.10.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.6, Conditions A4, A7, A14.

Table 10.10.3.3-4: 200 OK (step 16, table 10.9.3.2-1)

Derivation Path: Annex A.6, Step 4, Conditions A7, A10, A22 of TS 34.229-1 [2] cl A.3.1.

Table 10.10.3.3-5: BYE (step 18, table 10.9.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.8, Conditions A3, A6.

10.11 New initial emergency registration after obtaining new IP address different than the IP address / 5GS

10.11.1 Test Purpose (TP)

(1)

with { UE being registered to IMS }

ensure that {

when { UE is made to start an emergency call }

then { UE performs IMS emergency registration and sets up an emergency call }

}

(2)

with { Emergency call ongoing }

ensure that {

when { Network sends BYE }

then { UE sends 200 OK for BYE }

}

(3)

with { Emergency call having ended and emergency registration not having expired }

ensure that {

when { IP address re-allocation is triggered by the network }

then { UE performs a new initial IMS emergency registration }

}

10.11.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.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:

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

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

2) supports multiple registrations;

3) has an IMEI available; or

4) has an MEID available;

If the UE supports multiple registrations it shall include a "reg-id" header field parameter as described in RFC 5626 [92].

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

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.

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;

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

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 6: 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 7: 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);

NOTE 8: If the UE supports RFC 6140 [191] and performs the functions of an external attached network, the To header field will contain the main URI of the UE.

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

– if the UE used the procedures specified in RFC 6140 [191] for registration then 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 then store the value of the "pub-gruu" header field parameter for use for generating public GRUUs for registering UAs as specified in RFC 6140 [191]. If this contains a "temp-gruu-cookie" header field parameter then store the value of the "temp-gruu-cookie" header field parameter for use for generating temporary GRUUs for registering UAs as specified in RFC 6140 [191];

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.

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

i) if a Feature-Caps header field, as specified in RFC 6809 [190], is received, a UE supporting the Feature-Caps header field shall consider the ICSI values received in the Feature-Caps header field of 200 (OK) response as supported by the IM subsystem for the established registration or registration flow (if the multiple registration mechanism is used);

NOTE 15: The UE and related applications can use the ICSI values received in the Feature-Caps header field of 200 (OK) response to improve the user experience.

j) void; and

k) if the 200 (OK) response includes a Feature-Caps header field, as specified in RFC 6809 [190], with a "+g.3gpp.verstat" header field parameter and if the UE supports calling number verification status determination, determine that the home network supports calling number verification using signature verification and attestation information, as defined in subclause 3.1.

[TS 24.229 clause 5.1.6.8.3]:

After a successful initial emergency registration, the UE shall apply the procedures as specified in subclause 5.1.2A and 5.1.3 with the following additions:

2) the UE shall include a service URN in the Request-URI of the INVITE request in accordance with subclause 5.1.6.8.1;

3) the UE shall insert in the INVITE request, a To header field with the same emergency service URN as in the Request-URI;

NOTE 2: Providing two P-Preferred-Identity header fields is usually supported by UE acting as enterprise network.

6) void;

7) if the UE has its location information available, or a URI that points to the location information, then the UE shall include a Geolocation header field in the INVITE request in the following way:

– if the UE is aware of the URI that points to where the UE’s location is stored, include the URI as the Geolocation header field value, as described in RFC 6442 [89]; or

9) if the UE has neither geographical location information available, nor a URI that points to the location information, the UE shall not insert a Geolocation header field in the INVITE request; and

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

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

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

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.

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.

10.11.3 Test description

10.11.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

UE:

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

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

Preamble:

– The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS.

10.11.3.2 Test procedure sequence

Table 10.11.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE is made to initiate an emergency call	–	–	–	–
1A-H	The events specified in steps 1-8 of Table 4.9.11.2.2-1 of TS 38.508-1 [21] take place	–	–	–	–
	EXCEPTION: In parallel to the events described in steps 1I-5 below the events specified in steps 9-10 of Table 4.9.11.2.2-1 of TS 38.508-1 [21] take place.	–	–	–	–
1I-J	The generic procedure for IP address allocation in the user plane specified in subclause 4.5A.3 of TS 38.508-1 [21] takes place	–	–	–	–
2-5	Check: Does the UE correctly initiate and complete emergency registration? (Steps 1-4 of Annex A.3)	–	–	1	P
–	EXCEPTION: In parallel to the events described in steps 6-9A below the events specified in steps 11-13 of Table 4.9.11.2.2-1 of TS 38.508-1 [21] take place.	–	–	–	–
6-9A	Check: Does the UE correctly initiate and complete the establishment of an emergency voice call? (Steps 1-5 of Annex A.6)	–	–	1	P
10	SS waits 3 seconds and then sends BYE to release the emergency call. (Step 1 of annex A.8)	<–	BYE	–	–
11	Check: Does the UE send 200 OK for the BYE request and ends the call? (Step 2 of annex A.8)	–>	200 OK	2	P
–	EXCEPTION: The steps specified in table 10.11.3.2-2 take place.	–	–	–	–
11A	Steps 2-20 of generic procedure specified in Table 4.5.2.2-2 of TS 38.508-1 [21] are performed. NOTE: The UE performs initial registration and the RRC connection is released.
12	Void.	–	–	–	–
12A	UE is made to initiate an emergency call	–	–	–	–
12B	The events specified in steps 1-8 of Table 4.9.11.2.2-1 of TS 38.508-1 [21] take place.	–	–	–	–
–	EXCEPTION: In parallel to the events described in steps 12C-19 below the events specified in steps 9-10 of Table 4.9.11.2.2-1 of TS 38.508-1 [21] take place.	–	–	–	–
12C	The generic procedure for IP address allocation in the user plane specified in subclause 4.5A.3 of TS 38.508-1 [21] takes place Note: A different IP address than the one used for last emergency registration is allocated.	–	–	–	–
13-16	Check: Does the UE correctly initiate and complete emergency registration? (Steps 1-4 of Annex A.3)	–	–	3	P
–	EXCEPTION: In parallel to the events described in steps 17-19 below the events specified in steps 11-13 of Table 4.9.11.2.2-1 of TS 38.508-1 [21] take place.	–	–	–	–
17	The UE correctly initiate and complete the establishment of an emergency voice call. (Steps 1-5 of Annex A.6)	–	–	–	–
18	SS waits 3 seconds and then sends BYE to release the emergency call. (Step 1 of annex A.8)	<–	BYE	–	–
19	The UE send 200 OK for the BYE request and ends the call. (Step 2 of annex A.8)	–>	200 OK	–	–

Table 10.11.3.2-2: Network-initiated de-registration procedure

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	The SS transmits a DEREGISTRATION REQUEST with indicates "re-registration required".	<–	DEREGISTRATION REQUEST	–	–
2	The UE transmits a DEREGISTRATION ACCEPT message	–>	DEREGISTRATION ACCEPT	1	P
3	The SS releases RRC connection.	–	–	–	–

10.11.3.3 Specific message contents

None as fully specified in Annex A.3, A.6 and A.8.

10.12 User-initiated emergency reregistration / UE has emergency related ongoing dialog / 5GS

10.12.1 Test Purpose (TP)

(1)

with { UE being registered to IMS }

ensure that {

when { UE is made to start an emergency call }

then { UE performs IMS emergency registration and sets up an emergency call }

}

(2)

with { Emergency call ongoing }

ensure that {

when { IMS emergency registration passes half of the expiring time }

then { UE performs IMS emergency re-registration }

}

10.12.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.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;

– standalone transactions exist; or

– the user initiates an emergency call.

The UE shall not perform user-initiated emergency reregistration in any other cases.

[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 either with the contact address or with the registration flow and the associated 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:

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

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 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:

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

2) supports multiple registrations;

3) has an IMEI available; or

4) has an MEID available.

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.

NOTE 1: 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.

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

If a user part has previously been included in an initial REGISTER request, the UE shall use the user part which was previously used to create the binding being refreshed or removed;

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 RFC 6223 [143];

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

NOTE 2: 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 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);

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 3: 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) bind the new expiration time of the registration for this public user identity found in the To header field value either to the contact address or to the registration flow and the associated contact address used in this registration;

NOTE 4: If the UE supports RFC 6140 [191] and performs the functions of an external attached network, the To header field will contain the main URI of the UE.

b) 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);

NOTE 5: The stored list of service route values will be used 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).

NOTE 6: If the list of Service-Route headers saved from a previous registration and bound either to this 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 already exist, then the received list of Service-Route headers replaces the old list.

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

c) 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

– if the UE used the procedures specified in RFC 6140 [191]for registration then 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 then store the value of the "pub-gruu" header field parameter for use for generating public GRUUs for registering UAs as specified in RFC 6140 [191]. If this contains a "temp-gruu-cookie" header field parameter then store the value of the "temp-gruu-cookie" header field parameter for use for generating temporary GRUUs for registering UAs as specified in RFC 6140 [191];

NOTE 8: 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].

d) store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports received in the Security-Server header field and labelled with the "mediasec" header field parameter specified in subclause 7.2A.7, 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 9: The "mediasec" header field parameter indicates that security mechanisms are specific to the media plane.

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

f) if the 200 (OK) response contains the Authentication-Info header field including a nextnonce field, store the contained nonce as a nonce for authentication associated to the same registration or registration flow (if the multiple registration mechanism is used) and shall delete any other previously stored nonce value for authentication for this registration or registration flow (if the multiple registration mechanism is used);

NOTE 10: The related registration flow or registration is identified by the couple instance-id and reg-id if the multiple registration mechanism is used or by contact address if not.

g) if a Feature-Caps header field is received, a UE supporting the Feature-Caps header field shall consider the ICSI values received in the Feature-Caps header field of 200 (OK) response as supported for the established registration or registration flow (if the multiple registration mechanism is used) according to RFC 6809 [190]; and

NOTE 11: The UE and related applications can use the ICSI values received in the Feature-Caps header field to improve the user experience.

h) void.

[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 either this 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 to the longest of either the previously existing security association lifetime, or the lifetime of the just completed registration plus 30 seconds.

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