19.1 Emergency session set-up within an emergency registration

34.229-13GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 1: Protocol conformance specificationRelease 16TSUser Equipment (UE) conformance specification

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

19.1.1 Emergency call with emergency registration / Success / Location information available

19.1.1.1 Definition

Test to verify that the UE can correctly register to IMS emergency services and initiate an IMS emergency call when UE is registered to IMS non-emergency services of the HPLMN either with ISIM or USIM. The process consists of setting up EPS emergency bearers, sending initial emergency registration to S-CSCF via the P-CSCF discovered, authenticating the user and finally initiating the emergency call.

19.1.1.2 Conformance requirement

[TS 24.229 clause 4.7]:

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 [98]);

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;

c) by the inclusion by the P-CSCF of a P-Access-Network-Info header field based on information supplied by either the PCRF or the NASS, and which contains a cell identifier or location identifier, which is subsequently mapped, potentially by the recipient, into a real location;

d) by the allocation of a location reference that relates to the call by the LRF. Location is then supplied to the recipient over the Le interface (see 3GPP TS 23.167 [4B] for a definition of the Le interface) along with other call information. The LRF can obtain the location from entities outside the IM CN subsystem, e.g. by the e2 interface from the NASS (see ETSI TS 283 035) or from the Gateway Mobile Location Centre (GMLC).

…

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.

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

d) by the allocation of a location reference that relates to the call by the LRF. Location is then supplied to the recipient over the Le interface (see 3GPP TS 23.167 [4B] for a definition of the Le interface) along with other call information. The LRF can obtain the location from entities outside the IM CN subsystem, e.g. by the e2 interface from the NASS (see ETSI TS 283 035 [98] or from the Gateway Mobile Location Centre (GMLC).

…

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

A CS and IM CN subsystem capable UE shall follow the conventions and rules specified in 3GPP TS 22.101 and 3GPP TS 23.167 to select the domain for the emergency call attempt. If the CS domain is selected, the UE shall attempt an emergency call setup using appropriate access technology specific procedures.

The UE shall determine, whether it is currently attached to its home operator’s network (e.g. HPLMN) or to a different network than its home operator’s network (e.g. VPLMN) by applying access technology specific procedures described in the access technology specific annexes.

A CS and IM CN subsystem capable UE shall follow the conventions and rules specified in 3GPP TS 22.101 [1A] and 3GPP TS 23.167 [4B] to select the domain for the emergency call attempt. If the CS domain is selected, the UE shall attempt an emergency call setup using appropriate access technology specific procedures.

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

…

IP-CAN procedures for emergency registration are defined in 3GPP TS 23.167 and in each access technology specific annex.

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 indicates 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.8.3]:

After a successful initial emergency registration, the UE shall apply the procedures as specified in subclause 5.1.2A, 5.1.3 and 5.1.4 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 Request-URI in the INVITE request that contains an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031. An additional sub-service type can be added if information on the type of emergency service is known;

3) the UE shall insert in the INVITE request, a To header field with:

– the same emergency service URN as in the Request-URI; or

– if the UE cannot perform local dialstring interpretation for the dialled digits, a dialstring URI representing the dialled digits in accordance with RFC 4967 or a tel URL representing the dialled digits;

NOTE 1: This version of this document does not provide any specified handling of a URI with the dialled digits in accordance with RFC 4967 at an entity within the IM CN subsystem. Behaviour when this is used is therefore not defined.

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 I-WLAN access node, which is relevant for routeing the IMS emergency call;

NOTE 2: The IMS emergency specification in 3GPP TS 23.167 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.

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

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;

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: 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 3: 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, then the UE shall include its location information 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 in the Geolocation header field, and set the Geolocation-Routing header field to "yes", all in accordance with RFC 6442 [98]; or

– if the geographical location information of the UE is available to the UE, include its geographical location information as PIDF location object in accordance with RFC 4119 and include the location object in a message body with the content type application/pidf+xml with RFC 6442 [98]. The Geolocation header field is set to a Content ID, set the Geolocation-Routing header field to "yes", all in accordance with RFC 6442 [98]; and

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

8) if the UE has no geographical location information available, the UE shall not include any geographical location information as specified in RFC 6442 [98] in the INVITE request.

NOTE 5: RFC 3261 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.

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

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

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.

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.229 annex L.2.2.6]:

Emergency bearers are defined for use in emergency calls in EPS and core network support of these bearers 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 bearers, the UE shall use these EPS bearer contexts for both signalling and media for emergency calls made using the IM CN subsystem.

…

When activating a EPS bearer context to perform emergency registration, the UE shall request a PDN connection for emergency bearer services as described in 3GPP TS 24.301. The procedures for EPS bearer context activation and P-CSCF discovery, as described in subclause L.2.2.1 of this specification apply accordingly.

In order to find out whether the UE is attached to the home PLMN or to the visited PLMN, the UE shall compare the MCC and MNC values derived from its IMSI with the MCC and MNC of the PLMN the UE is attached to. If the MCC and MNC of the PLMN the UE is attached to do not match with the MCC and MNC derived from the IMSI, then for the purpose of emergency calls in the IM CN subsystem the UE shall consider to be attached to a VPLMN.

NOTE: In this respect an equivalent HPLMN, as defined in 3GPP TS 23.122 will be considered as a visited network.

[TS 24.237 clause 7.2]:

When originating an emergency call as specified in 3GPP TS 24.229 and if the SC UE has an IMEI, then the SC UE shall include the instance-id media feature tag as specified in IETF RFC 5626 with value based on the IMEI as defined in 3GPP TS 23.003 in the Contact header field of the SIP INVITE request.

[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 [122]). The format of the instance-id shall take the form "urn:gsma:imei:<gsma-specifier-defined-substring>" where by the gsma-specifier-defined-substring shall be the IMEI encoded as defined in RFC 7254 [122]. The optional <gsma-specifier-defined-param> parameters shall not be included in the instance-id. An example of such an instance-id is as follows:

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

Reference(s)

3GPP TS 24.229 [10], clauses 5.1.6.1, 5.1.6.2, 5.1.6.8.3 and Annex L2.2.6, TS 24.237 [110] clause 7.2 and TS 23.003 [32] clause 13.8 (release 9)

19.1.1.3 Test purpose

1) To verify that the UE is able to request activation of EPS emergency bearer contexts, according to 3GPP TS 24.229 [10] annex L.2.2.6; and

2) To verify that the UE sends a correctly composed initial SIP REGISTER request for emergency services to S-CSCF via the discovered P-CSCF, according to 3GPP TS 24.229 [10] clause 5.1.6.1; and

3) To verify that the UE is able to use the IMS security procedures for the IMS emergency registration, as defined for IMS AKA and IPSec within 3GPP TS 24.229 [10] clause 5.1.1; and

4) To verify the support of the UE for providing its location within the IMS emergency call signalling messages, as defined within 3GPP TS 24.229 [10] clause 5.1.6.8.3; and

5) To verify that the UI sends a correctly composed SIP INVITE request for the emergency call setup and will correctly complete the emergency session setup using SDP preconditions, according to 3GPP TS 24.229 [10] clauses 5.1.6.8.3 and 6.1.2.

19.1.1.4 Method of test

Initial conditions

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

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

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 34.109 [117] or in TS 36.509 [118] depending on the RAT being used in the test case, if supported by the UE according to pc_UpdateUE_LocationInformation. Otherwise, or in addition any other suitable method may also be used.

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

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

16) Call is released on the UE using C.32 procedure.

17) Void

18) Emergency Bearer context is deactivated

Expected sequence:

NOTE: Only the IMS procedure relevant to the test purpose is described below.

Step	Direction		Message	Comment
	UE	SS
1-15			Steps defined in annex C.20 followed by the steps defined in annex C.22	IMS emergency registration by the UE followed by IMS emergency call setup with PSAP. Referred from 36.508 [94] table 4.5A.4.3-1 for a UE with E-UTRA support.
16-16A4	🡪		Steps defined in annex C.32	The UE releases the call
17			Void
18			EPS emergency bearer context deactivation by the SS.	EPS Bearer Deactivation procedure according TS 36.508 [94] subclause 4.5A.15, applied to the identity of the Default EPS Bearer of the emergency PDN.

Specific Message Contents

INVITE (step 1 of Annex C.22)

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

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

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

180 Ringing for INVITE (step 3 of Annex C.22)

Use the default message “180 Ringing for INVITE” in annex A.2.6 The condition A4 “180 sent by the SS when setting up an emergency call” shall apply.

200 OK for INVITE (step 4 of Annex C.22)

Use the default message “200 OK for other requests than REGISTER or SUBSCRIBE” in annex A.3.1. The condition A6 “Response sent by SS for INVITE for emergency call” shall apply

BYE (Step 16)

Use the default message “BYE” in annex A.2.8.

200 OK for BYE (Step 17)

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

19.1.1.5 Test requirements

If the UE is capable of obtaining location information the INVITE request sent for initiating the emergency call shall contain a Geolocation header. The body of an INVITE request containing the Geolocation header must contain a PIDF location object. The PIDF-LO shall be syntactically correct (as specified within RFC 4119 [99]) and it shall be mapped to the same Content-ID which can be found from the Geolocation header.

19.1.2 Emergency call with emergency registration / Success / Location information not available

19.1.2.1 Definition

19.1.2.2 Conformance requirement

[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, 5.1.3 and 5.1.4 with the following additions:

…

8) if the UE has no geographical location information available, the UE shall not include any geographical location information as specified in RFC 6442 [98] in the INVITE request.

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

…

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.

Reference(s)

3GPP TS 24.229 [10], clause 5.1.6.8.3 (release 9)

19.1.2.3 Test purpose

1) To verify that if the location information is not available UE will not add Geolocation header or PIDF-LO to the INVITE request for emergency call, as defined within 3GPP TS 24.229 [10] clause 5.1.6.8.3.

19.1.2.4 Method of test

Initial conditions

Test environment shall ensure that UE can not 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.

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

16) Call is released on the UE using Annex C.32 procedure

17) Void

18) Emergency Bearer context is deactivated

Expected sequence

NOTE: Only the IMS procedure relevant to the test purpose is described below.

Step	Direction		Message	Comment
	UE	SS
16-16A4	🡪		Steps defined in Annex C.32	The UE releases the call
17			Void
18			EPS emergency bearer context deactivation by the SS.	EPS Bearer Deactivation procedure according TS 36.508 [94] subclause 4.5A.15, applied to the identity of the Default EPS Bearer of the emergency PDN.

Specific Message Contents

INVITE (Step 1 of Annex C.22)

Use the default message “INVITE for MO call setup” in annex A.2.1. The condition A7 “INVITE for creating an emergency session within an emergency registration” shall apply. In this test case condition NOT A8 shall apply as the UE is not able to obtain its geographical location.

180 Ringing for INVITE (Step 3 of Annex C.22)

Use the default message “180 Ringing for INVITE” in annex A.2.6 The condition A4 “180 sent by the SS when setting up an emergency call” shall apply.

200 OK for INVITE (Step 4 of Annex C.22)

Use the default message “200 OK for other requests than REGISTER or SUBSCRIBE” in annex A.3.1. The condition A6 “Response sent by SS for INVITE for emergency call” shall apply

BYE (Step 16)

Use the default message “BYE” in annex A.2.8.

200 OK for BYE (Step 17)

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

19.1.2.5 Test requirements

The INVITE request sent for initiating the emergency call shall not contain a Geolocation header and the body of the request shallnot contain a PIDF location object.

19.1.3 Emergency call with emergency registration / Abnormal case / IM CN sends a 380 / UE performs emergency call via CS domain / UTRAN or GERAN

19.1.3.1 Definition

Test to verify that the UE performs a emergency call via CS domain, when attempt to initiate an IMS emergency call is rejected by 380 for a UE registered to IMS emergency services and IMS non-emergency services of the HPLMN either with ISIM or USIM. The process consists of setting up EPS emergency bearers, sending initial emergency registration to S-CSCF via the P-CSCF discovered, authenticating the user , initiating the emergency call. The emergency call is rejected with 380 and UE performs emergency call via supported CS domain over UTRAN or GERAN.

19.1.3.2 Conformance requirement

[TS 24.229 clause 5.1.6.1]:

[TS 24.229 clause 5.1.6.2]:

…

IP-CAN procedures for emergency registration are defined in 3GPP TS 23.167 and in each access technology specific annex.

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

The UE shall translate any user indicated emergency number as specified in 3GPP TS 22.101 to an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031.

…

In the event the UE receives a 380 (Alternative Service) response to an INVITE request the response including a 3GPP IM CN subsystem XML body as described in subclause 7.6 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.7AA), the UE shall automatically send an ACK request to the P-CSCF as per normal SIP procedures and terminate the session. In addition, if the 380 (Alternative Service) response includes a P-Asserted-Identity header field with a value equal to the value of the last entry on the Path header field value received during registration:

– the UE may also provide an indication to the user based on the text string contained in the <reason> child element of the <alternative-service> child element of the <ims-3gpp> element; and

– one of subclause 5.1.6.8.3 or subclause 5.1.6.8.4 applies.

NOTE 2: Emergency numbers which the UE does not detect, will be treated as a normal call.

NOTE 3: The last entry on the Path header field value received during registration is the value of the SIP URI of the P-CSCF.

[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, 5.1.3 and 5.1.4 with the following additions:

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;

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

– if the UE is aware of its location information, include the location information in a PIDF location object, in accordance with RFC 4119, 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;

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.

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

In the event the UE receives a 380 (Alternative Service) response with a P-Asserted-Identity header field with a value equal to the value of the last entry on the Path header field value received during registration, and the Content-Type header field set according to subclause 7.6 (i.e. "application/3gpp-ims+xml"), independent of the value or presence of the Content-Disposition header field, independent of the value or presence of Content-Disposition parameters, then the following treatment is applied:

1) if the 380 (Alternative Service) response includes a 3GPP IM CN subsystem XML body as described in subclause 7.6 the <ims-3gpp> element, including a version attribute, with the <alternative-service> child element with the <type> child element set to "emergency" (see table 7.7AA), then the UE shall:

a) if the CS domain is available to the UE, and no prior attempt using the CS domain for the current emergency call attempt has been made, attempt emergency call via CS domain using appropriate access technology specific procedures; and

b) if the CS domain is not available to the UE or the emergency call has already been attempted using the CS domain, then perform one of the following actions:

– if the <action> child element of the <alternative-service> child element of the <ims-3gpp> element in the IM CN subsystem XML body as described in subclause 7.6 is set to "emergency-registration" (see table 7.7AB), perform an initial emergency registration using a different VPLMN if available, as described in subclause 5.1.6.2 and if the new emergency registration succeeded, attempt an emergency call as described in this subclause; or

– perform implementation specific actions to establish the emergency call; and

2) if the 380 (Alternative Service) response includes a 3GPP IM CN subsystem XML body as described in subclause 7.6 with the <ims-3gpp> element, including a version attribute, with the <alternative-service> child element with the <type> child element set to "emergency" (see table 7.7AA) then the UE may also provide an indication to the user based on the text string contained in the <reason> child element of the <alternative-service> child element of the <ims-3gpp> element.

NOTE 5: The last entry on the Path header field value received during registration is the value of the SIP URI of the P-CSCF.

[TS 24.229 annex L.2.2.6]:

…

NOTE: In this respect an equivalent HPLMN, as defined in 3GPP TS 23.122 will be considered as a visited network.

Reference(s)

3GPP TS 24.229 [10], clauses 5.1.6.1, 5.1.6.2, 5.1.6.8.1, 5.1.6.8.3, and Annex L2.2.6 (release 9)

19.1.3.3 Test purpose

1) To verify that the on reception of 380 Alternate Service for an INVITE sent for emergency call establishment, UE initiates the emergency call in supported CS domain over UTRAN or GERAN.

19.1.3.4 Method of test

Initial conditions

UE contains either ISIM and USIM applications or only USIM application on UICC. UE is registered to IMS services, by executing the generic test procedure in Annex C.2 up to the last step.

The SS is configured:

– with 2 cells: as in TS 36.508

– E-UTRAN cell A

– if px_RATComb_Tested = EUTRA_UTRA, cell 5

– if px_RATComb_Tested = EUTRA_GERAN , GERAN cell 24

– Cell A power level is set as “serving cell” and cell 24/cell 5 power level is set as “suitable cell”

Note: Setting px_RATComb_Tested = EUTRA_Only is not allowed.

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

1) IMS emergency call is initiated on the UE.

2)-5) UE executes the procedures described in TS 36.508 [94] table 4.5A.4.3-1 steps 2 to 15 and parallel behaviour steps 1-4 for EPS emergency bearer context activation, and subsequent IMS emergency registration,

6) UE sends INVITE for emergency call.

7) SS responds with 380 Alternative services.

8) UE ACKS the 380 Alternative service message. UE performs CS fallback or cell reselection to a cell supporting CS domain (UTRAN/GERAN) based on capability supported and initiates CS domain emergency call with MM/GMM registration if necessary.

9) CS emergency call is established and released. For GERAN cell, UE performs MM/GMM registration after CS call is released.

Expected sequence

Step	Direction		Message	Comment
	UE	SS
1			User initiates an emergency call
2-5			Steps defined in annex C.20	EPS emergency bearer context activation and subsequent IMS emergency registration by the UE. Referred from 36.508 [94] table 4.5A.4.3-1 for a UE with E-UTRA support.
6	🡪		INVITE	UE sends INVITE with the first SDP offer indicating all desired medias and codecs the UE supports
7	<-		380 Alternative Service	The SS responds with a 380 Alternative Service response
8	🡪		ACK	The UE acknowledges the receipt of 380 Alternative Service for INVITE NOTE 1: Step 8 can happen in parallel to step 8Aa1.
–	–		EXCEPTION: Within 2 seconds of step 7 the UE may transmit EXTENDED SERVICE REQUEST OR PDN_DISCONNECT_REQUEST (or both). DEACTIVATE EPS BEARER CONTEXT REQUEST is sent if EXTENDED SERVICE REQUEST is not received within one second after PDN DISCONNECT REQUEST. Steps 8AAa1 to Step 8AAa4 OR 8AAb1 to 8AAb3 OR 8AAc1 to 8AAc2 OR 8AAd1 can happen	NOTE 2: Value of 2 seconds is based on estimation.
8AAa1	->		PDN DISCONNECT REQUEST	UE sends PDN disconnect request during CS fallback procedure triggered
8AAa2	<-		DEACTIVATE EPS BEARER CONTEXT REQUEST	SS responds with DEACTIVATE EPS BEARER CONTEXT REQUEST after 1s
8AAa3	->		DEACTIVATE EPS BEARER CONTEXT ACCEPT	UE sends DEACTIVATE EPS BEARER CONTEXT ACCEPT
8AAa4	->		EXTENDED SERVICE REQUEST	If CS Fallback is performed, the UE sends service request with Service type set to mobile originating CS fallback as defined in 24.301 clause 9.9.3.27
8AAb1	->		PDN DISCONNECT REQUEST	UE sends PDN disconnect request during CS fallback procedure triggered
8AAb2	<-		DEACTIVATE EPS BEARER CONTEXT REQUEST	SS responds with DEACTIVATE EPS BEARER CONTEXT REQUEST after 1s
8AAb3	->		EXTENDED SERVICE REQUEST	If CS Fallback is performed, the UE sends service request with Service type set to mobile originating CS fallback as defined in 24.301 clause 9.9.3.27
8AAc1	->		PDN DISCONNECT REQUEST	UE sends PDN disconnect request during CS fallback procedure triggered
8AAc2	->		EXTENDED SERVICE REQUEST	If CS Fallback is performed, the UE sends service request with Service type set to mobile originating CS fallback as defined in 24.301 clause 9.9.3.27 within 1s of step 8AAc1
8AAd1	->		EXTENDED SERVICE REQUEST	If CS Fallback is performed, the UE sends service request with Service type set to mobile originating CS fallback as defined in 24.301 clause 9.9.3.27
8Aa0a1 – 8Aa0a3			Void
8Aa1	->		EXTENDED SERVICE REQUEST	If CS Fallback is performed, the UE sends Extended service request with Service type set to mobile originating CS fallback emergency call as defined in 24.301 clause 9.9.3.27
8Aa2	<-		SS releases the RRC connection	SS waits for two seconds before sending RRC connection release. UE state is changed from RRC_CONNECTED to RRC_IDLE, and UE is redirected to UTRAN/GERAN (if supported)
–	–		EXCEPTION: Either step 9a1 or 9b1 is performed, depending on the value of px_RATComb_Tested
9a1	–		IF px_RATComb_Tested = EUTRA_UTRA UE performs CS fallback or cell reselection to a cell supporting CS domain (UTRAN) and performs emergency call in CS domain together with MM/GMM registration	NOTE3: RAU procedure can take place in parallel to emergency CS call. If the Service category IE is included, then SS verifies that the Emergency Service Category IE bit 6 and bit 7 are set to 0
–	–		EXCEPTION: Depending on the UE implementation, the generic test procedure for mobile initiated IMS SIP re-registration defined in Annex C.46 of TS 34.229-1 can take place	–
–	–		EXCEPTION: Depending on the UE implementation, the generic test procedure for mobile initiated IMS SIP de-registration defined in Annex C.30 of TS 34.229-1 can take place	The optional de-registration happens in parallel with the CS call release procedures.
9a2	–		SS configures cell A as a “non-suitable cell”	–
9a3	–		Emergency CS call is released	–
9b1	–		IF px_RATComb_Tested = EUTRA_GERAN UE performs CS fallback or cell reselection to a cell supporting CS domain (GERAN cell) and performs emergency call in CS domain	If the Service category IE is included, then SS verifies that the Emergency Service Category IE bit 6 and bit 7 are set to 0
9b2	–		SS configures cell A as a “non-suitable cell”	–
9b3	–		Emergency CS call is released	–
9b4	–		UE performs MM/GMM registration	–

Specific Message Contents

INVITE (Step 6)

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

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

ACK (Step 8)

Use the default message “ACK” in Annex A.2.7.

380 Alternative Service (Step 7)

Use the default message “380 Alternative Service” in annex A.4.1.

RRCConnectionRelease (step 8Aa2)

Use the default message with the following specific contents

Derivation Path: 36.508 Table 4.6.1-15
Information Element	Value/remark	Comment	Condition
RRCConnectionRelease ::= SEQUENCE {
criticalExtensions CHOICE {
c1 CHOICE {
rrcConnectionRelease-r8 SEQUENCE {
redirectedCarrierInfo ::= CHOICE {
utra-FDD	Downlink UARFCN of cell 5		UTRA-FDD
_utra-TDD	Downlink UARFCN of cell 5		UTRA-TDD
Geran	ARFCN of cell 24		GERAN
}
}

ROUTING AREA UPDATE ACCEPT (step 9b4)

Use the default message with the following specific contents

Derivation path: 36.508, Table 4.7B.2-2
Information Element	Value/Remark	Comment	Condition
PDP context status	0	NSAPI(0) – NSAPI(15) is set to 0, which means that the SM state of all PDP contexts is PDP-INACTIVE

19.1.3.5 Test requirements

In step 9a1 or 9b1, UE initiates a CS emergency call in UTRAN or GERAN cell (respectively). When the service category IE is included, UE shall send the Emergency Service Category IE bit 6 and bit 7 set to 0.

19.1.3a Emergency call with emergency registration / Abnormal case / IM CN sends a 380 / UE performs emergency call via CS domain / CDMA 2000 1xRTT

19.1.3a.1 Definition

Same as in 19.1.3.1, except: UE performs emergency call via supported CS domain over CDMA 2000 1xRTT.

19.1.3a.2 Conformance requirement

Same Conformance requirement as in clause 19.1.3.2

19.1.3a.3 Test purpose

1) To verify that the on reception of 380 Alternate Service for an INVITE sent for emergency call establishment, UE initiates the emergency call in supported CS domain CDMA 2000 1xRTT

19.1.3a.4 Method of test

Initial conditions

Same as in 19.1.3.4, except: UE contains ISIM and USIM and CSIM or USIM and CSIM applications on UICC.

The SS is configured:

with 2 cells: as in TS 36.508
E-UTRAN cell A
1xRTT cell 19
Cell A power level is set as “serving cell” and cell 19 power level is set as “suitable cell”

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

Same as in 19.1.3.4

Expected sequence

Step	Direction		Message	Comment
	UE	SS
1			User initiates an emergency call
2-5			Steps defined in annex C.20	EPS emergency bearer context activation and subsequent IMS emergency registration by the UE. Referred from 36.508 [94] table 4.5A.4.3-1 for a UE with E-UTRA support.
6	🡪		INVITE	UE sends INVITE with the first SDP offer indicating all desired medias and codecs the UE supports
7	<-		380 Alternative Service	The SS responds with a 380 Alternative Service response
8	🡪		ACK	The UE acknowledges the receipt of 380 Alternative Service for INVITE
9			UE performs cell reselection to a cell supporting CS domain (CDMA2000 1XRTT cell) and performs emergency call in CS domain after CDMA registration (if needed)
10			CS call is released

Specific Message Contents

Same as in 19.1.3.4

19.1.3a.5 Test requirements

In step 9, UE initiates a CS emergency call in 1xRTT cell.

19.1.3b Void

19.1.3c Emergency call with emergency registration / Abnormal case / IM CN sends 503 Service Unavailable / UE performs emergency call via CS domain / UTRAN or GERAN

19.1.3c.1 Definition

Test to verify that the UE performs an emergency call via CS domain, when attempt to initiate an IMS emergency call is rejected by 503 for a UE registered to IMS emergency services and IMS non-emergency services either with ISIM or USIM.

19.1.3c.2 Conformance requirement

[TS 24.229 clause 5.1.6.1]:

[TS 24.229 annex L.2.2.6]:

Upon receiving a 3xx other than 380 (Alternative service), 4xx, 5xx or 6xx response to an INVITE request for a UE detectable emergency call, the UE shall perform domain selection as specified in 3GPP TS 23.167 [4B] annex H, to re-attempt the emergency call.

[TS 23.167 annex H.5]:

This clause details the domain priority and selection (see clause 7.3) for UE that attempts to make an emergency session for UTRAN, E-UTRAN or NG-RAN radio access networks based on the UE attach status to CS or PS domains and the network support for IMS emergency and IMS voice over PS.

The following table (Table H.1) defines these rules based on the UE (last 2 columns) for different initial conditions (first 4 columns) when an emergency session is initiated and when the UE is not in limited service state.

For NG-eCall (eCall over IMS) domain selection in clause H.6 applies. This clause is not applicable for NG-eCall.

Table H.1: Domain Selection Rules for emergency session attempts for UTRAN, E-UTRAN or NG-RAN radio access networks

	CS Attached	PS Attached	VoIMS	EMS	First EMC Attempt	Second EMC Attempt
A	N	Y	Y	Y	PS	CS if available and supported – NOTE 7)
B	N	Y	N	Y	PS or CS if the emergency session includes at least voice. PS if the emergency session contains only media other than voice.	PS if first attempt in CS CS if first attempt in PS – NOTE 7)
C	N	Y	Y or N	N	PS if ESFB is "Y" (NOTE 5). Else CS or PS for another 3GPP RAT with EMS or ESFB set to "Y" if available and supported and if the emergency session includes at least voice. Else PS for another 3GPP RAT with EMS or ESFB set to "Y" if available and supported if the emergency session contains only media other than voice.	PS if first attempt in CS CS if first attempt in PS – NOTE 7)
D	Y	N	Y or N	Y or N	CS if the emergency session includes at least voice. PS if available and EMS or ESFB is "Y" and emergency session contains only media other than voice.	PS if available and EMS or ESFB is "Y"
E	Y	Y	Y	Y	If the emergency session includes at least voice, follow rules in TS 22.101 [8] which say to use the same domain as for a non-EMC (NOTE 2) PS if the emergency session contains only media other than voice.	PS if first attempt in CS CS if first attempt in PS
F	Y	Y	Y or N	N	PS if ESFB is "Y" (NOTE 5). Else PS for another 3GPP RAT with EMS if available and supported or CS, if the emergency session includes at least voice.	CS if first attempt in PS PS for another 3GPP RAT if available and supported and EMS or ESFB is "Y" if first attempt in CS.
G	Y	Y	N	Y	CS if the emergency session includes at least voice. PS if the emergency session contains only media other than voice.	PS
EMC = Emergency Session. EMC includes also normal calls initiated in the CS domain that are treated by the CS CN as emergency calls. VoIMS = Voice over IMS over PS sessions support as indicated by IMS Voice over PS session supported indication as defined in TS 23.401 [28], TS 23.060 [2] and TS 23.502 [49]. EMS = IMS Emergency Services supported as indicated by Emergency Service Support indicator as defined in TS 23.401 [28], TS 23.060 [2], TS 23.501 [48] and TS 23.502 [49]. ESFB = Emergency Services Fallback for 5GS as defined in TS 23.501 [48] and TS 23.502 [49]. NOTE 1: If the UE selects the CS domain and initiates a normal call using the dialled local emergency number (see clause 7.1.2), and the UE enters limited service state (e.g. due to a Location Registration failing), then the UE camps on an acceptable cell (see TS 23.122 [41]) and may proceed with the EMC by initiating an emergency call in limited service state. NOTE 2: Use of the same domain as for a non-EMC is restricted to UTRAN, E-UTRAN and NG-RAN access (e.g. excludes WLAN). NOTE 3: This NOTE applies to a UE in dual registration mode as defined in TS 23.501 [48]. A dual registration mode UE that is registered to both EPC and 5GC assumes attachment, for the purpose of the "PS Attached" column, to whichever of EPC or 5GC indicates EMS as "Y". When both EPC and 5GC indicate EMS as "Y", the UE shall assume attachment to either EPC or 5GC based on implementation. A UE that is registered to both EPC and 5GC does not use emergency services fallback and ignores the ESFB condition when performing domain selection. NOTE 4: The other 3GPP RAT for row C and row F can be any of UTRA, E-UTRAN connected to EPC, E-UTRA connected to 5GC or NR connected to 5GC that is supported by the UE and differs from the RAT to which the UE is currently attached in the PS domain (or is assumed to be attached based on NOTE 3). NOTE 5: The condition ‘ESFB is "Y"’ only applies for a UE that is camped on or connected to 5GS via NR or via E-UTRA and that supports Emergency Services Fallback. In that case the emergency call will be provided over E-UTRAN or E-UTRA connected to 5GC as defined in procedures in TS 23.502 [49]. The condition ‘ESFB is "Y"’ is taken into consideration by the UE only when the network has indicated EMS = "N" for the RAT on which the UE is camping or connected. NOTE 6: For 5GS, the value of the column "EMS" is for the RAT that UE is camped on or is connected to. NOTE 7: As an implementation option, when the first attempt uses PS and fails for reasons other than related to IMS, the second attempt may use PS with a different 3GPP RAT. In this case the UE, can make a third attempt using CS.

Reference(s)

3GPP TS 24.229 [10], clauses 5.1.6.1 and Annex L.2.2.6, and TS 23.167 [141], annex H.5.

19.1.3c.3 Test purpose

1) To verify that on reception of 503 Service Unavailable for an INVITE sent for emergency call establishment, UE initiates the emergency call in supported CS domain over UTRAN or GERAN.

19.1.3c.4 Method of test

Initial conditions

UE contains either ISIM and USIM applications or only USIM application on UICC. UE is registered to IMS services, by executing the generic test procedure in Annex C.2 up to the last step.

The SS is configured:

– with 2 cells: as in TS 36.508

– E-UTRAN cell A

– if px_RATComb_Tested = EUTRA_UTRA, cell 5

– if px_RATComb_Tested = EUTRA_GERAN , GERAN cell 24

– Cell A power level is set as “serving cell” and cell 24/cell 5 power level is set as “suitable cell”

Note: Setting px_RATComb_Tested = EUTRA_Only is not allowed.

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

1) IMS emergency call is initiated on the UE.

6) UE sends INVITE for emergency call.

7) SS responds with 503 Service Unavailable.

8) UE ACKS the Service Unavailable message. UE performs CS fallback or cell reselection to a cell supporting CS domain (UTRAN/GERAN) based on capability supported and initiates CS domain emergency call with MM/GMM registration if necessary.

9) CS emergency call is established and released. For GERAN cell, UE performs MM/GMM registration after CS call is released.

Expected sequence

Step	Direction		Message	Comment
	UE	SS
1			User initiates an emergency call
2-5	–		Steps defined in annex C.20	EPS emergency bearer context activation and subsequent IMS emergency registration by the UE. Referred from 36.508 [94] table 4.5A.4.3-1 for a UE with E-UTRA support.
6	->		INVITE	UE sends INVITE with the first SDP offer indicating all desired medias and codecs the UE supports
7	<-		503 Service Unavailable	The SS responds with 503 Service Unavailable response
8	->		ACK	The UE acknowledges the receipt of 503 Service Unavailable for INVITE NOTE 1: Step 8 can happen in parallel to step 8Aa1.
–	–		EXCEPTION: Within 2 seconds of step 7 the UE may transmit EXTENDED SERVICE REQUEST OR PDN_DISCONNECT_REQUEST (or both). DEACTIVATE EPS BEARER CONTEXT REQUEST is sent if EXTENDED SERVICE REQUEST is not received within one second after PDN DISCONNECT REQUEST. Steps 8AAa1 to Step 8AAa4 OR 8AAb1 to 8AAb3 OR 8AAc1 to 8AAc2 OR 8AAd1 can happen	NOTE 2: Value of 2 seconds is based on estimation.
8AAa1	->		PDN DISCONNECT REQUEST	UE sends PDN disconnect request during CS fallback procedure triggered
8AAa2	<-		DEACTIVATE EPS BEARER CONTEXT REQUEST	SS responds with DEACTIVATE EPS BEARER CONTEXT REQUEST after 1s
8AAa3	->		DEACTIVATE EPS BEARER CONTEXT ACCEPT	UE sends DEACTIVATE EPS BEARER CONTEXT ACCEPT
8AAa4	->		EXTENDED SERVICE REQUEST	If CS Fallback is performed, the UE sends service request with Service type set to mobile originating CS fallback as defined in 24.301 clause 9.9.3.27
8AAb1	->		PDN DISCONNECT REQUEST	UE sends PDN disconnect request during CS fallback procedure triggered
8AAb2	<-		DEACTIVATE EPS BEARER CONTEXT REQUEST	SS responds with DEACTIVATE EPS BEARER CONTEXT REQUEST after 1s
8AAb3	->		EXTENDED SERVICE REQUEST	If CS Fallback is performed, the UE sends service request with Service type set to mobile originating CS fallback as defined in 24.301 clause 9.9.3.27
8AAc1	->		PDN DISCONNECT REQUEST	UE sends PDN disconnect request during CS fallback procedure triggered
8AAc2	->		EXTENDED SERVICE REQUEST	If CS Fallback is performed, the UE sends service request with Service type set to mobile originating CS fallback as defined in 24.301 clause 9.9.3.27 within 1s of step 8AAc1
8AAd1	->		EXTENDED SERVICE REQUEST	If CS Fallback is performed, the UE sends service request with Service type set to mobile originating CS fallback as defined in 24.301 clause 9.9.3.27
8Aa1	->		EXTENDED SERVICE REQUEST	If CS Fallback is performed, the UE sends Extended service request with Service type set to mobile originating CS fallback emergency call as defined in 24.301 clause 9.9.3.27
8Aa2	<-		SS releases the RRC connection	SS waits for two seconds before sending RRC connection release. UE state is changed from RRC_CONNECTED to RRC_IDLE, and UE is redirected to UTRAN/GERAN (if supported)
–	–		EXCEPTION: Either step 9a1-9a3 or 9b1-9b3 are performed, depending on the value of px_RATComb_Tested
9a1	–		IF px_RATComb_Tested = EUTRA_UTRA UE performs CS fallback or cell reselection to a cell supporting CS domain (UTRAN) and performs emergency call in CS domain together with MM/GMM registration	NOTE3: RAU procedure can take place in parallel to emergency CS call. If the Service category IE is included, then SS verifies that the Emergency Service Category IE bit 6 and bit 7 are set to 0
–	–		EXCEPTION: Depending on the UE implementation, the generic test procedure for mobile initiated IMS SIP re-registration defined in Annex C.46 of TS 34.229-1 can take place	–
–	–		EXCEPTION: Depending on the UE implementation, the generic test procedure for mobile initiated IMS SIP de-registration defined in Annex C.30 of TS 34.229-1 can take place	The optional de-registration happens in parallel with the CS call release procedures.
9a2	–		SS configures cell A as a “non-suitable cell”	–
9a3	–		Emergency CS call is released	–
9b1	–		IF px_RATComb_Tested = EUTRA_GERAN UE performs CS fallback or cell reselection to a cell supporting CS domain (GERAN cell) and performs emergency call in CS domain	If the Service category IE is included, then SS verifies that the Emergency Service Category IE bit 6 and bit 7 are set to 0
9b2	–		SS configures cell A as a “non-suitable cell”	–
9b3	–		Emergency CS call is released	–
9b4	–		UE performs MM/GMM registration	–

Specific Message Contents

INVITE (Step 6)

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

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

ACK (Step 8)

Use the default message “ACK” in Annex A.2.7.

503 Service Unavailable (Step 7)

Use the default message “503 Service Unavailable” in annex A.4.2.

RRCConnectionRelease (step 8Aa2)

Use the default message with the following specific contents

Derivation Path: 36.508 Table 4.6.1-15
Information Element	Value/remark	Comment	Condition
RRCConnectionRelease ::= SEQUENCE {
criticalExtensions CHOICE {
c1 CHOICE {
rrcConnectionRelease-r8 SEQUENCE {
redirectedCarrierInfo ::= CHOICE {
utra-FDD	Downlink UARFCN of cell 5		UTRA-FDD
_utra-TDD	Downlink UARFCN of cell 5		UTRA-TDD
Geran	ARFCN of cell 24		GERAN
}
}

ROUTING AREA UPDATE ACCEPT (step 9b4)

Use the default message with the following specific contents

Derivation path: 36.508, Table 4.7B.2-2
Information Element	Value/Remark	Comment	Condition
PDP context status	0	NSAPI(0) – NSAPI(15) is set to 0, which means that the SM state of all PDP contexts is PDP-INACTIVE

19.1.4 Void

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

19.1.5.1 Definition

Test to verify that the UE [IMS registered for non-emergency services and ongoing multimedia call] can correctly register to IMS emergency services and initiate an IMS emergency call when UE is registered to IMS non-emergency services of the HPLMN either with ISIM or USIM. The process consists of setting up EPS emergency bearers, sending initial emergency registration to E-CSCF via the P-CSCF discovered, authenticating the user and finally initiating the emergency call.

19.1.5.2 Conformance requirement

[TS 24.229 clause 5.1.6.1]:

[TS 24.229 clause 5.1.6.2]:

…

IP-CAN procedures for emergency registration are defined in 3GPP TS 23.167 [4B] and in each access technology specific annex.

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 "sop" SIP URI parameter in the Contact header field as described in subclause 7.2A.13, indicating that indicates 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 derived temporary public user identity, in all other cases.

When the UE performs an initial emergency registration and whilst this emergency registration is active, the UE shall:

– handle the emergency registration independently from any other ongoing registration to the IM CN subsystem;

– handle any signalling or media related IP-CAN for the purpose of emergency calls independently from any other established IP-CAN for IM CN subsystem related signalling or media; and

– handle all SIP signalling and all media related to the emergency call independently from any other ongoing IM CN subsystem signalling and media.

[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, 5.1.3 and 5.1.4 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 tell URI associated with the public user identity registered via emergency registration, as described in subclause 4.2;

2) the UE shall include a Request-URI in the INVITE request that contains an emergency service URN, i.e. a service URN with a top-level service type of "sops" as specified in RFC 5031 [69]. An additional sub-service type can be added if information on the type of emergency service is known;

3) the UE shall insert in the INVITE request, a To header field with:

– the same emergency service URN as in the Request-URI; or

– if the UE cannot perform local dial string interpretation for the dialled digits, a dial string URI representing the dialled digits in accordance with RFC 4967 [103] or a tell URL representing the dialled digits;

NOTE 1: This version of this document does not provide any specified handling of a URI with the dialled digits in accordance with RFC 4967 [103] at an entity within the IM CN subsystem. Behaviour when this is used is therefore not defined.

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 tell URI associated with the public user identity registered via emergency registration as described in subclause 4.2;

NOTE 3: 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, then the UE shall include its location information 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 in the Relocation header field, set the Relocation-Routing header field to "yes", all in accordance with RFC 6442 [98]; or

– if the geographical location information of the UE is available to the UE, include its geographical location information as PIDF location object in accordance with RFC 4119 [90] and include the location object in a message body with the content type application/pidf+xml in accordance with RFC 6442 [98]. The Geolocation header field is set to a Content ID, and set the Geolocation-Routing header field to "yes", all in accordance with RFC 6442 [98]; and

8) if the UE has no geographical location information available, the UE shall not include any geographical location information as specified in RFC 6442 [98] in the INVITE request.

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

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

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;

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.

[TS 24.229 annex L.2.2.6]:

…

NOTE: In this respect an equivalent HPLMN, as defined in 3GPP TS 23.122 will be considered as a visited network.

Reference(s)

3GPP TS 24.229 [10], clauses 5.1.6.1, 5.1.6.2, 5.1.6.8.3 and Annex L2.2.6 (release 9)

19.1.5.3 Test purpose

1) To verify that the UE registered for non-emergency services and ongoing multimedia call, on initiation of an emergency call, holds the ongoing multimedia call and sends a correctly composed INVITE request for the emergency call setup and will correctly complete the emergency session setup using SDP preconditions, according to 3GPP TS 24.229 [10] clauses 5.1.6.8.3 and 6.1.2.

19.1.5.4 Method of test

Initial conditions

UE contains either ISIM and USIM applications or only USIM application on UICC. UE is registered to IMS services, by executing the generic test procedure in Annex C.2 up to the last step and thereafter executing the generic test procedure in Annex C.21 up to its last step for a multimedia non-emergency call.

Test procedure

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

1) Ongoing multimedia call is put on hold.

2) IMS emergency call is initiated on the UE.

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

15A User initiates resumption of Multimedia call.

16-17) UE releases the emergency call.

18) Void.

19-24) Multimedia call is resumed and released.

Expected sequence

Step	Direction		Message	Comment
	UE	SS
1			User initiates hold of ongoing call
2-5	🡪		Steps defined in annex C.8	Ongoing call is put on hold by UE
6			User initiates an emergency call
7-15			Steps defined in annex C.20 followed by the steps defined in annex C.22	IMS emergency registration by the UE followed by IMS emergency call setup with PSAP. Referred from 36.508 [94] table 4.5A.4.3-1 for a UE with E-UTRA support.
15A			User resumes the ongoing call which is on hold	Triggers release of the emergency call.
16-17			The UE releases the emergency call using steps 2-5 of Annex C.32
18			Void
19-22			Steps defined in Annex C.8	Ongoing call is resumed.
23	🡪		BYE	The UE releases the multimedia call
24	🡨		200 OK	The SS sends 200 OK for BYE

Specific Message Contents

INVITE (step 1 in procedure in Annex C.22)

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

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

19.1.5.5 Test requirements

In steps 7-15, UE performs emergency registration and establishes an emergency call

19.1.6 Emergency call with emergency registration / Success / GIBA against a network with GIBA support only

19.1.6.1 Definition

Test to verify that the UE can correctly register to IMS emergency services in a visited network with support for GIBA only, while the home network used for IMS registration supports IMS security, when equipped with UICC that contains either both ISIM and USIM applications or only USIM application but not ISIM. The process consists of sending initial emergency registration to S-CSCF via the P-CSCF discovered, authenticating the user and finally sending an emergency session initiation.

19.1.6.2 Conformance requirement

[TS 24.229 Rel-8, clause 5.1.1.2.1]

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

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

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

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

d) a Via header field set to include the sent-by field containing the IP address or FQDN of the UE and the port number where the UE expects to receive the response to this request when UDPis used. For TCP, the response is received on the TCP connection on which the request was sent. The UE shall also include 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;

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

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

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

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

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

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

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

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

[TS 24.229 Rel-9, clause 5.1.1.2.1]

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

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

[TS 24.229 Rel-9, clause 5.1.1.2.6]

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 as defined in RFC 2617 shall not be included, in order to indicate support for GPRS-IMS-Bundled authentication.

b) the Security-Client header field as defined in RFC 3329 shall not be included;

c) a From header field set to a temporary public user identity derived from the IMSI, as defined in 3GPP TS 23.003, as the public user identity to be registered;

d) a To header field set to a temporary public user identity derived from the IMSI, as defined in 3GPP TS 23.003, as the public user identity to be registered;

e) the Contact header field with the port value of an unprotected port where the UE expects to receive subsequent mid-dialog requests; and

f) the Via header field with the port value of an unprotected port where the UE expects to receive responses to the request.

NOTE 1: Since the private user identity is not included in the REGISTER requests when GPRS-IMS-Bundled authentication is used for registration, re-registration and de-registration procedures, all REGISTER requests from the UE use the IMSI-derived IMPU as the public user identity even when the implicitly registered IMPUs are available at the UE. The UE does not use the temporary public user identity (IMSI-derived IMPU) in any non-registration SIP requests.

On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.2.1, there are no additional requirements for the UE.

NOTE 2: When GPRS-IMS-Bundled authentication is in use, a 401 (Unauthorized) response to the REGISTER request is not expected to be received.

[TS 24.229 Rel-9, clause 5.1.1.5.3]

On receiving a 420 (Bad Extension) in which the Unsupported header field contains the value "sec-agree" and if the UE supports GPRS-IMS-Bundled authentication, the UE shall initiate a new authentication attempt with the GPRS-IMS-Bundled authentication procedures as specified in subclause 5.1.1.2.6.

[TS 24.229 Rel-9, clause 5.1.2A.1.1]

The procedures of this subclause are general to all requests and responses, except those for the REGISTER method.

When the UE sends any request using either a given contact address or to the registration flow and the associated contact address, the UE shall:

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

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

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

…

– if GPRS-IMS-Bundled authentication is in use as a security mechanism, and therefore no port is provided for subsequent SIP messages by the P-CSCF during registration, the UE shall send any request to the same port used for the initial registration as described in subclause 5.1.1.2.

…

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

1) a contact header value which is one of:

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

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

– otherwise, a SIP URI containing the contact address of the UE;

NOTE 7: The above items are mutually exclusive.

2) include an "ob" SIP URI parameter, if the UE supports multiple registrations, and the UE wants all subsequent requests in the dialog to arrive over the same flow identified by the flow token as described in RFC 5626;

3) if the request is related to an IMS communication service that requires the use of an ICSI then the UE shall include in a g.3gpp.icsi-ref media feature tag, as defined in subclause 7.9.2 and RFC 3841, the ICSI value (coded as specified in subclause 7.2A.8.2) for the IMS communication service. The UE may also include other ICSI values that the UE is prepared to use for all dialogs with the terminating UE(s); and

4) if the request is related to an IMS application that is supported by the UE, then the UE may include in a g.3gpp.iari-ref media feature tag, as defined in subclause 7.9.3 and RFC 3841, the IARI value (coded as specified in subclause 7.2A.9.2) that is related to the IMS application and that applies for the dialog.

…

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

Reference(s)

TS 24.229 [10] clauses 5.1.1.2.1, 5.1.1.2.6, 5.1.1.5.3 and 5.1.2A.1.1.

19.1.6.3 Test purpose

1) To verify that after receiving a 420 (Bad Extension) response the UE sends a correctly composed initial REGISTER request for IMS emergency services.

2) To verify that after receiving a 200 OK response for the REGISTER without security-client header, the UE successfully initiates an IMS emergency call.

19.1.6.4 Method of test

Initial conditions

UE contains either ISIM and USIM applications or only USIM application on UICC. In the E-UTRA attach SS has indicated to the UE that the NW is VPLMN and the cell supports E-UTRA emergency bearers. UE is registered to IMS services, by executing the generic test procedure in Annex C.2 up to the last step.

Test procedure

1)-12) UE executes the procedures described in TS 36.508 [94] table 4.5A.4.3-1 steps 1 to 12 and parallel behaviour steps 1 for EPS emergency bearer context activation,

13) SS waits for the UE to send an initial REGISTER request containing “sos” SIP URI parameter in the Contact header field.

14) The SS responds to the REGISTER request with a 420 Bad Extension response,

15) The UE initiates IMS registration indicating support of GIBA. SS waits for the UE to send an initial REGISTER request.

16) The SS responds to the REGISTER request with valid 200 OK response,

17) The SS waits for the UE to send an INVITE request.

18)-20A) UE executes the procedures described in TS 36.508 [94] table 4.5A.4.3-1 steps 13 to 15 and parallel behaviour Steps 2-5 defined in annex C.22 of TS 34.229-1 for IMS Emergency call for EPS is established,

21)-24A) The UE releases the call.

25)-26) The SS deactivates EPS emergency bearer context.

Expected sequence

Step	Direction		Message	Comment
	UE	SS
1-12			Steps defined in TS 36.508 [94] table 4.5A.4.3-1	EPS Bearer Activation procedure and IP address allocation according TS 36.508 [94] table 4.5A.4.3-1 for a UE with E-UTRA support.
13	🡪		REGISTER	UE sends initial registration for IMS services.
14	🡨		420 Bad Extension	The SS responds with a failure.
15	🡪		REGISTER	The UE sends initial registration for IMS services indicating support for GIBA procedure by not including an Authorization header field.
16	🡨		200 OK	The SS responds with 200 OK.
17	🡪		INVITE	UE sends INVITE request.
18-20A			Steps 2 to 5 defined in annex C.22	IMS emergency call setup with PSAP
21-24A	🡪		Steps defined in annex C.32	The UE releases the call
25-26			EPS emergency bearer context deactivation by the SS.	EPS Bearer Deactivation procedure according TS 36.508 [94] subclause 4.5A.15, applied to the identity of the Default EPS Bearer of the emergency PDN.

Specific Message Contents

Use the default message “REGISTER” in annex A.1.1 with condition A1 "Initial unprotected REGISTER" and A7 “Initial unprotected or subsequent REGISTER for emergency registration”

420 Bad Extension for REGISTER (Step 14)

Use the default message “420 Bad Extension for REGISTER” in annex A.1.8 with condition A1 “IMS emergency registration failure for an anonymous emergency call”.

Use the default message “REGISTER” in annex A.1.1 with condition A7 “Initial unprotected or subsequent REGISTER for emergency registration”.

200 OK for REGISTER (Step 16)

Use the default message “200 OK for REGISTER” in annex A.1.3 with condition A2 “GIBA”

INVITE (Step 17)

Use the default message “INVITE” in annex A.2.1 with condition A19 “INVITE for creating an emergency session within an emergency registration using GIBA”.

19.1.6.5 Test requirements

The UE shall send requests and responses as described in clause 19.1.6.4.