19.4 Emergency session set-up in case of no 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.4.1 Emergency call without emergency registration / EPS / UE does not contain an ISIM or USIM

19.4.1.1 Definition

Test to verify that the UE can initiate an IMS emergency call when the UE does not contain ISIM or USIM.

19.4.1.2 Conformance requirement

Reference(s)

3GPP TS 24.229 [10], clauses 5.1.6.1 and 5.1.6.8.2.

[TS 24.229 clause 5.1.6.1]

If the IM CN subsystem is selected and the UE has no credentials the UE can make an emergency call without being registered. 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]

Prior to establishing an emergency session for an unregistered user, the UE shall acquire a local IP address, discover a P-CSCF, and establish an IP-CAN bearer that can be used for SIP signalling. The UE shall send only the initial INVITE requests to the port advertised to the UE during the P-CSCF discovery procedure. If the UE does not receive any specific port information during the P-CSCF discovery procedure, the UE shall send the initial INVITE request to the SIP default port values as specified in RFC 3261.

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;

2) the UE shall include a Request-URI in the initial 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;

NOTE 1: Other specifications make provision for emergency service identifiers that 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 ACK requests and CANCEL requests) or response (except CANCEL responses) within a dialog or any request. 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 I-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. 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 draft-ietf-sipcore-keep;

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, the UE shall include the 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, 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 in accordance with RFC 6442 [98]. The Geolocation header field is set to a Content ID, in accordance with RFC 6442 [98]; and

9) 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 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 inapplicable in this area.

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

The UE shall build a proper preloaded Route header field value for all new dialogs. The UE shall build a Route header field value containing only the P-CSCF URI (containing the unprotected port number and the IP address or the FQDN learnt through the P-CSCF discovery procedures).

19.4.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] 5.1.6.1; and

2) To verify that the UE sends a correctly composed SIP INVITE request for the emergency call setup and will correctly complete the emergency session setup, according to 3GPP TS 24.229 [10] clauses 5.1.6.8.2 and 6.1.2.

19.4.1.4 Method of test

Initial conditions

The UE is Switched OFF and contains no ISIM or USIM.

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

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

Expected sequence:

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

Step	Direction		Message	Comment
	UE	SS
1-5			Steps defined in annex C.22	Generic test procedure for setting up emergency speech call. Referred from 36.508 [94] table 4.5A.5.3-1 for a UE with E-UTRA support.
6			Void
7			Void
8-12			Steps defined in annex C.32	UE releases the emergency call using generic test procedure for MO release of IMS call

Specific Message Contents

INVITE (Step 1)

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

– A6 “INVITE for creating an emergency session in case of no registration” shall apply; and

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

19.4.1.5 Test requirements

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

19.4.2 Emergency call without emergency registration / EPS / UE contains an ISIM or USIM / UE is in state EMM-REGISTERED.LIMITED-SERVICE

19.4.2.1 Definition

Test to verify that the UE with ISIM or USIM and in state EMM-REGISTERED.LIMITED-SERVICE, establishes an emergency call if emergency call is initiated. The process consists of setting the emergency call without IMS emergency registration.

19.4.2.2 Conformance requirement

[TS 24.229 clause 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.

Some jurisdictions allow emergency calls to be made when the UE does not contain an ISIM or USIM, or where the credentials are not accepted. Additionally where the UE is in state EMM-REGISTERED.LIMITED-SERVICE and EMM-REGISTERED.PLMN-SEARCH, a normal ATTACH has been attempted and it can also be assumed that a registration in the IM CN subsystem will also fail. In such cases, the procedures for emergency calls without registration apply, as defined in subclause 5.1.6.8.2.

[TS 24.229 clause 5.1.6.8.2]:

When establishing an emergency session for an unregistered user, the UE is allowed to receive responses to emergency requests and requests inside an established emergency session on the unprotected ports. The UE shall reject or silently discard all other messages not arriving on a protected port. Additionally, the UE shall transmit signalling packets pertaining to the emergency session from the same IP address and unprotected port on which it expects to receive signalling packets containing the responses to emergency requests and the requests inside the established emergency session.

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 Request-URI in the initial 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 [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;

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;

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, the UE shall include the 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, 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, in accordance with RFC 6442 [98]; and

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

When a SIP transaction times out, i.e. timer B, timer F or timer H expires at the UE, the UE may behave as if timer F expired, as described in subclause 5.1.1.4.

NOTE 5: It is an implementation option whether these actions are also triggered by other means.

NOTE 6: A number of header fields can reveal information about the identity of the user. Where privacy is required, implementers should also give consideration to other header fields that can reveal identity information. RFC 3323 [33] subclause 4.1 gives considerations relating to a number of header fields.

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

If the response for the initial INVITE request indicates that the UE is behind NAT, and the INVITE request was sent over TCP connection, the UE shall keep the TCP connection during the entire duration of the emergency session. In this case the UE will receive all responses to the emergency requests and the requests inside the established emergency session over this TCP connection.

If the Via header field of any provisional response, or of the final 200 (OK) response, for the initial INVITE request contains a "keep" header field parameter with a value, unless the UE detects that it is not behind a NAT, the UE shall start to send keep-alives associated with the session towards the P-CSCF, as described in draft-ietf-sipcore-keep [143].

Reference(s)

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

19.4.2.3 Test purpose

1) To verify that the UE in state EMM-REGISTERED.LIMITED-SERVICE, on initiation of an emergency call, performs EMM emergency registration to acquire a local IP address, discover a P-CSCF, and establishes an IP-CAN bearer that can be used for SIP signalling and then composes an INVITE request for the emergency call setup and will correctly complete the emergency session setup.

19.4.2.4 Method of test

Initial conditions

The UE contains either ISIM and USIM applications or only USIM application on UICC. The UE is initially IMS registered in cell A and made to select cell B. The Tracking area update procedure is rejected with cause #15, No suitable cells in tracking area in cell B, thus ensuring that the UE is in state EMM-REGISTERED.LIMITED-SERVICE.

The SS is configured with the IMSI within the USIM application, the home domain name, the SS is listening to SIP default port 5060 for both UDP and TCP protocols. The SS supports EMM emergency attach procedure and emergency bearers.

The SS configures two cells as below:

EUTRA cell A and Cell B as in TS 36.508

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

– the IMS emergency call is initiated on the UE.

– UE executes the procedures described in TS 36.508 [94] table 4.5A.5.3-1 steps 1 to 19 for EMM Emergency registration, EPS emergency bearer context activation, IMS emergency speech call establishment with PSAP.

Expected sequence

Step	Direction		Message	Comment
	UE	SS
1			User initiates an emergency call
2-6			Steps defined in annex C.22	Generic test procedure for setting up emergency speech call. Referred from 36.508 [94] table 4.5A.5.3-1 for a UE with E-UTRA support.
6A-C			Steps 1-3 of Annex C.32	The UE releases the emergency call using steps 1-3 of Annex C.32
7			void
8			void
			EXCEPTION: Either step 9 or steps 10-11 are performed, depending on UE behaviour: if UE detaches, step 9 is performed. Otherwise, steps 10-11 are performed.
9			Detach procedure initiated by the UE	Generic test procedure for UE initiated detach according to TS 36.508 [94] table 6.4.3.14-1 may happen within 5 seconds.
10-11			Steps 4-5 of Annex C.32	If step 9 was not performed steps 4-5 of Annex C.32 are performed

Specific Message Contents

INVITE (step 1 of procedure in annex C.22)

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

– A6 “INVITE for creating an emergency session in case of no registration” shall apply;

19.4.2.5 Test requirements

In steps 2-6, UE establishes an emergency call.

19.4.3 Void

19.4.4 Void

19.4.5 Emergency call without emergency registration / UE credentials are not accepted

19.4.5.1 Definition

Test to verify that when UE is unable to emergency register due to UE credentials not accepted, initiates an emergency call on non protected ports when an emergency call is attempted. The process consists of setting up IMS emergency call after emergency registration failure.

19.4.5.2 Conformance requirement

[TS 24.229 clause 4.2B]:

In case of an emergency session if the UE does not have sufficient credentials to authenticate with the IM CN subsystem and regulations allow, the UE and P-CSCF shall send request and responses other than initial REGISTER requests on non protected ports.

[TS 24.229 clause 4.7]:

The need for support of emergency calls in the IM CN subsystem is determined by national regulatory requirements.

If the UE cannot detect the emergency call attempt, the UE initiates the request as per normal procedures as described in subclause 5.1.2A. Depending on network policies, for a non-roaming UE an emergency call attempt can succeed even if the UE did not detect that an emergency session is being requested, otherwise the network rejects the request indicating to the UE that the attempt was for an emergency service.

The UE procedures for UE detectable emergency calls are defined in subclause 5.1.6.

The P CSCF, S-CSCF, and E-CSCF procedures for emergency service are described in subclause 5.2.10, 5.4.8 and 5.11, respectively.

Access dependent aspects of emergency service (e.g. emergency registration support and location provision) are defined in the access technology specific annexes for each access technology.

There are a number of variants within these procedures and which variant gets used depends on a number of issues. These conditions are defined more specifically in 3GPP TS 23.167 [4B] and, where appropriate, in the access technology specific annex, but are summarised as follows:

a) if the UE knows that it is in its own home network, then an existing registration is permitted to be used for signalling the emergency call, except where item c) applies. The access technology specific annexes define the mechanism by which home network determination is made;

b) if emergency calls are permitted without security credentials (or additionally where the authentication is not possible or has failed), then the emergency call is made directly without use of any security association created by a registration, and therefore without the registration; and

c) where the access technology defines emergency bearers for the support of emergency calls, a new emergency registration is required so that these emergency bearers can be used for both signalling and media, unless an existing emergency registration exists on those emergency bearers.

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

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.

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 does not define emergency bearers, or the IP-CAN does define emergency bearers but the core network has not indicated that it supports emergency bearers, the UE shall attempt an emergency call as described in subclause 5.1.6.8.4.

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