19.3 Non-UE detectable emergency call

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.3.1 Non-UE detectable emergency call / IM CN sends a 1xx response / UE geographical location information available or not

19.3.1.1 Definition

Test to verify that the UE acts correctly when it receives a 1xx response to an initial request for a dialog from the IM CN, the response containing a P-Asserted-Identity header field set to an emergency number that is recognisable by the UE and the UE sends an UPDATE request with:

Geolocation header and information if the UE is capable of obtaining location information; and
Contact header set appropriately

19.3.1.2 Conformance requirement

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

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

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

– if the UE has its geographical location information available and the geographical location information has not been included in the initial request for a dialog;

then the UE shall send an UPDATE request according to RFC 3311; and

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

2) if the UE has its geographical location information available, then the UE shall include it in the UPDATE request in the following way:

I) if the UE is aware of the URI that points to where the UE’s location is stored, include the URI in the Geolocation header field and set the "inserted-by" parameter to indicate its hostport, all in accordance with RFC 6442 and set the "inserted-by" parameter to indicate its hostport, all in accordance with draft-ietf-sipcore-loca; or

II) 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. The Geolocation header field is set to a Content ID and set the "inserted-by" parameter to indicate its hostport, all in accordance with RFC 6442;

3) if the UE has no geographical location information available, the UE shall not include any geographical location information as specified in RFC 6442; and

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

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

Reference(s)

3GPP TS 24.229 [10], clauses 5.1.6.10

19.3.1.3 Test purpose

To verify that if the UE is not able to detect that an emergency number has been dialled:

– in the event the UE receives a 1xx response to an INVITE request the response containing a P-Asserted-Identity header field set to an emergency number, the UE:

– If the UE is able to obtain its geolocation and the geographical location information has not been included in the initial request for a dialog; then the UE shall include its geolocation information in the UPDATE message

– If the UE is not able to obtain its geolocation the UE does not include it in the UPDATE message

– includes a Contact header in the UPDATE message with the correct contents

19.3.1.4 Method of test

Initial conditions

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

Test environment shall be set up to provide the needed input to the UE, in order for the UE to derive its location, if the UE is capable of obtaining location information. This shall be done by use of the test function Update UE Location Information defined in TS 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.

UE has discovered P-CSCF and registered to IMS services, by executing the generic test procedure in Annex C.2 up to the last step.

SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE. SS has performed AKAv1-MD5 authentication with the UE and accepted the registration.

Test procedure

A non-emergency MO call is initiated up following the generic procedure in Annex C.21.

Expected sequence

Step	Direction		Message	Comment
	UE	SS
1-13				Steps 1-13 of Annex C.21. The UE initiates a non-emergency call.

Specific Message Contents INVITE (Step 2)

Use the default message “INVITE” in annex A.2.1 without options A6, A7 and A8.

183 Session in Progress (Step 4)

Use the default message “183 Session in Progress” in annex A.2.3 with option A5.

UPDATE (Step 7)

Use the default message "UPDATE" in annex A.2.5 with the following exceptions:

Header/param	Cond	Value/remark	Rel	Reference
Geolocation	A1		Rel-9	RFC 6442 [98]
locationURI		cid-url indicating the Content-Id of the PIDF-LO within the multipart MIME body of INVITE request. (Note that location-by-reference URI is not allowed as the SS does not provide any external storage for location info for the UE to refer.)


Geolocation-Routing	A1	“yes”	Rel-9	RFC 6442
Contact				RFC 3261 [15] RFC 5627 [61]
addr-spec	A2	Public GRUU as obtained during registration as pub-gruu contact parameter of the 200 OK for REGISTER response
addr-spec	A3	SIP URI with IP address or FQDN and protected server port of UE
addr-spec	A4	SIP URI with IP address or FQDN and unprotected server port of UE
Content-Type
media-type	A1 not A1	multipart/mixed application/sdp		TS 24.229 [10] RFC 3261 [15]
Message-body		If condition A1 applies, the multipart-mime body shall also contain a PIDF-LO element mapped to the same Content-ID which can be found from the Geolocation header The PIDF-LO shall contain at least the following elements: – One or more ‘geopriv’ elements, each containing: – One ‘location-info’ element describing the location of the UE; and – One ‘usage-rules’ element describing the limitations of the usage of the location info.		RFC 6442 [98]

Condition	Explanation
A1	UE is capable of obtaining location information
A2	obtaining and using GRUUs in the Session Initiation Protocol (SIP) (A.4/53 3GPP TS 34.229-2 [5])
A3	Not A2 and (IMS security, A.6a/2 3GPP TS 34.229-2 [5])
A4	Not A2 and (GIBA, A.6a/1 3GPP TS 34.229-2 [5])

180 Ringing (Step 9)

Use the default message “180 Ringing” in annex A.2.6 with options A4 and A8.

200 OK (Step 12)

Use the default message "200 OK" in annex A.3.1 with option A6.

19.3.1.5 Test requirements

SS must check that in:

Step 2 the UE sends a non-emergency INVITE with the correct contents
Step 7 the UE sends the UPDATE message with:
- the Geolocation header set appropriately, if the UE is capable of obtaining location information
- Contact header set appropriately

19.3.2 Non-UE detectable emergency call / IM CN sends 380 Alternative Service including emergency service URN and no emergency subservice type / Non-emergency IMS registration / UTRAN or GERAN

19.3.2.1 Definition

Test to verify that the UE correctly requests an emergency service on CS domain over UTRAN or GERAN if the UE has received a 380 (Alternative Service) response to an INVITE request with Contact header field in which an emergency service information is included with no emergency subservice type.

19.3.2.2 Conformance requirement

[TS 24.229 Rel-9, 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.

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 [8J]. 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 1: In this respect an equivalent HPLMN, as defined in 3GPP TS 23.122 [4C] will be considered as a visited network.

The type of emergency service for an emergency number is derived from the settings of the emergency service category value (bits 1 to 5 of the emergency service category value as specified in subclause 10.5.4.33 of 3GPP TS 24.008 [8]). Table L.2.2.6.1 below specifies mappings between a type of emergency service and an emergency service URN. The UE shall use the mapping to match an emergency service URN and a type of emergency service. If a dialled number is an emergency number but does not map to a type of emergency service the service URN shall be "urn:service:sos".

Table L.2.2.6.1: Mapping between type of emergency service and emergency service URN

Type of emergency service	Emergency service URN
Police	urn:service:sos.police
Ambulance	urn:service:sos.ambulance
Fire Brigade	urn:service:sos.fire
Marine Guard	urn:service:sos.marine
Mountain Rescue	urn:service:sos.mountain

If the IP-CAN did not provide a local emergency number that matches the dialled number (see subclause 5.1.6.1) and multiple types of emergency service can be derived for a dialled number from the information configured on the USIM then:

– if the UE is in the HPLMN, the UE shall map any one of these types of emergency service to an emergency service URN as specified in table L.2.2.6.1; and

– if the UE is in the VPLMN, the UE shall select "urn:service:sos".

If the IP-CAN provided a local emergency number that matches the dialled number (see subclause 5.1.6.1), and:

– if the UE can derive one or more types of emergency service from the information received from the IP-CAN for the dialled number and the UE cannot derive types of emergency service from the information configured on the USIM for the dialled number; or

– if the UE is able to derive identical types of emergency service from both the information received from the IP-CAN for the dialled number and from the information configured on the USIM for the dialled number,

then the UE shall map any one of these emergency service types to an emergency service URN as specified in table L.2.2.6.1.

NOTE 2: How the UE resolves clashes where an emergency number is associated with one or more different types of emergency service configured in the USIM and in information received from the access network, is implementation dependent.

Upon reception of a 380 (Alternative Service) response to an INVITE request as defined in subclause 5.1.3.1, if:

– the 380 (Alternate Service) response contains a Contact header field;

– the value of the Contact header field is a service URN; and

– the service URN has a top-level service type of "sos";

then the UE determines that "emergency service information is included" as described 3GPP TS 23.167 [4B], else the UE determines that "emergency service information" as described 3GPP TS 23.167 [4B] is not included.

If the "emergency service information is included" as described 3GPP TS 23.167 [4B]:

1) if the URN in the Contact header field matches an emergency service URN in table L.2.2.6.1, then the type of emergency service is the value corresponding to the matching entry in table L.2.2.6.1; and

2) if the URN in the Contact header field does not match any emergency service URN in table L.2.2.6.1, then the type of emergency service is not identified.

NOTE 3: In bullet 2), the URN in the Contact header field either contains "no emergency subservice type" as described in 3GPP TS 23.167 [4B] triggering an emergency call, or contains an "emergency subservice type that does not map into an emergency service category for the CS domain" as described in 3GPP TS 23.167 [4B] triggering a normal call when the dialled number is available or triggering an emergency call when the dialled number is not available.

Reference(s)

3GPP TS 24.229 [10], clause L.2.2.6

19.3.2.3 Test purpose

To verify that on reception of 380 Alternative Service with a Contact header field with value "urn:service:sos" for an INVITE where the UE did not detect that an emergency number had been dialled, the UE initiates a CS emergency call in supported CS domain over UTRAN or GERAN.

19.3.2.4 Method of test

Initial conditions

UE contains ISIM and USIM applications or only USIM application on UICC. UE has activated EPS bearers, discovered P-CSCF and 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

1-2) MO call is initiated on the UE by dialling a non emergency number. UE sends INVITE REQUEST.

3) SS responds to the INVITE request with a 380 Alternative Service.

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

5) 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 a normal call	MO call is initiated on the UE by dialling a “non emergency” number.
2	->		INVITE	UE sends INVITE. Request-URI of the INVITE request matches with the “non emergency” number dialled.
3	<-		380 Alternative Service	The SS responds with a 380 Alternative Service
4	->		ACK	The UE acknowledges the receipt of 380 Alternative Service for INVITE NOTE 1: Step 4 can happen in parallel to step 4Aa1.
–	–		EXCEPTION: The UE performs a domain selection for the emergency call and within 2 seconds of step 3 the UE may transmit EXTENDED SERVICE REQUEST	NOTE 2: Value of 2 seconds is based on estimation.
4Aa1	->		EXTENDED SERVICE REQUEST	If CS Fallback is performed, the UE sends service request with Service type set to mobile originating CS fallback emergency call as defined in 24.301 clause 9.9.3.27
4Aa2	<-		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)
5a1	–		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	NOTE 3: RAU procedure can take place in parallel to emergency CS call.
–	–		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.
5a2	–		SS configures cell A as a “non-suitable cell”
5a3	–		Emergency CS call is released
5b1	–		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
5b2	–		SS configures cell A as a “non-suitable cell”
5b3	–		Emergency CS call is released
5b4	–		UE performs MM/GMM registration

NOTE: The default messages contents in annex A are used with condition “IMS security “ or “GIBA” when applicable.

Specific Message Contents

ATTACH ACCEPT (preamble)

Use the default message as in TS 36.508 [94] sub-clause Table 4.7.2-1 except the following change:

Information Element

Value/remark

Comment

EPS network feature support

‘0000 0001’B

IMS voice over PS session in S1 mode supported

emergency bearer services in S1 mode not supported

INVITE (Step 2)

Use the default message “INVITE” in annex A.2.1 for MO Call” in annex A.2.1 with the following exceptions:

Header/param

Value/remark

Message-body

The following SDP types and values.

Session description:

v=0
o=(username) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE)
s=(session name)
c=IN (addrtype) (connection-address for UE) [Note 1]

Time description:

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

Media description:

m=audio (transport port) [Note 2]
c=IN (addrtype) (connection-address for UE) [Note 1]
b=AS: (bandwidth-value)

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

Note 2: AMR codec shall be present

380 Alternative Service (Step 3)

Use the default message “380 Alternative Service” in annex A.4.1 with the following exceptions:

Header/param	Value/Remark
Contact
Name-addr	urn:service:sos

ACK (Step 4)

Use the default message "ACK" in annex A.2.7

RRCConnectionRelease (step 4Aa2)

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 5b4)

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.3.2.5 Test requirements

In step 5a1 or 5b1, UE initiates a CS emergency call in UTRAN or GERAN cell (respectively).

Check that the UE sends all the requests over the security associations set up during registration, in accordance to 3GPP TS 24.229 [10], clause 5.1.1.5.1.

Step 2: the UE sends an INVITE message with correct content.

Step 5a1, 5b1: Check that the emergency call on the CS domain UTRAN or GERAN is successfully established according to the procedures described in 3GPP TS 24.008 [12].

19.3.2a Non-UE detectable emergency call / IM CN sends 380 Alternative Service / Non-emergency IMS registration / CDMA 2000 1xRTT

19.3.2a.1 Definition

Same as in 19.3.2.1, except: UE correctly requests an emergency service on CS domain over CDMA 2000 1xRTT.

19.3.2a.2 Conformance requirement

Same Conformance requirement as in clause 19.3.2.2

19.3.2a.3 Test purpose

To verify that if the UE is not able to detect that an emergency number has been dialled:

– in the event the UE receives a 380 (Alternative Service) response to an INVITE request the response containing a XML body that includes an <alternative-service> child element with the <type> child element set to "emergency" and the <action> element is not set to "emergency-registration", the UE:

– send an ACK request to the P-CSCF as per normal SIP procedures;

– attempt an emergency call setup via CS domain CDMA 2000 1xRTT according to the procedures described in 3GPP2 TS C.S0005-E[112], only if the P-Asserted-Identity header field with a value equal to the value of the SIP URI of the P-CSCF received in the Path header field during registration.

19.3.2a.4 Method of test

Initial conditions

Same as in 19.3.2.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” cell 19 power level is set as “suitable cell”

Test procedure

Same as in 19.3.2.4 except step 5:

5) SS waits for an emergency call setup according to the procedures described in 3GPP2 TS C.S0005-E[112].

Expected sequence

Step	Direction		Message	Comment
	UE	SS
1				MO call is initiated on the UE by dialling a “non emergency” number.
2	🡪		INVITE	UE sends INVITE. Request-URI of the INVITE request matches with the “non emergency” number dialled.
3	🡨		380 Alternative Service	The SS responds with a 380 Alternative Service
4	🡪		ACK	The UE acknowledges the receipt of 380 response for INVITE and starts the emergency call in CS domain
5				SS waits for an emergency call setup. according to the procedures described in 3GPP2 TS C.S0005-E[112].
6				Having reached the active state, the call is cleared by the SS

NOTE: The default messages contents in annex A are used with condition “IMS security “ or “GIBA ” when applicable.

Specific Message Contents

Same as in 19.3.2.4

19.3.2a.5 Test requirements

Same as 19.3.2.5.

Except Steps 5, 6: SS must check that the emergency call on the CS domain CDMA 2000 1xRTT is successfully established according to the procedures described in 3GPP TS 24.008 [12].

19.3.2b Non-UE detectable emergency call / IM CN sends a 380 with unavailable emergency service URN / UE performs normal call via CS domain / UTRAN or GERAN

19.3.2b.1 Definition

Test to verify that the UE correctly requests normal voice service on CS domain over UTRAN or GERAN if the UE has received a 380 (Alternative Service) response to an INVITE request with Contact header field which does not match any emergency service URN.

19.3.2b.2 Conformance requirement

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

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

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 not currently registered, the UE shall:

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

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

If the IM CN subsystem is selected and the UE is attached to a different network than its home operator’s network (e.g. VPLMN), the UE shall:

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

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

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.

The IP-CAN can, dependent on the IP-CAN capabilities, provide local emergency numbers (including information about emergency service categories) to the UE which has that capability, in order for the UE to recognize these numbers as emergency call.

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

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

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

– in event other than reception of a 380 (Alternative Service) response to an initial request for a dialog, or a standalone transaction, or an unknown method as defined in procedures in subclause 5.1.2A.1.1, subclause 5.1.3.1, subclause 5.1.6.8.1, subclause 5.1.6.8.3 and subclause 5.1.6.8.4; or

– upon reception of a 380 (Alternative Service) response to an initial request for a dialog, or a standalone transaction, or an unknown method as defined in procedures in subclause 5.1.2A.1.1, subclause 5.1.3.1, subclause 5.1.6.8.1, subclause 5.1.6.8.3 and subclause 5.1.6.8.4, and the 380 (Alternative Service) response does not contain a Contact header field containing a service URN with a top-level service type of "sos",

the Request-URI of the initial request for a dialog or the standalone transaction, or the unknown method transmitted as part of UE detected emergency call procedures as defined in subclause 5.1.6 shall include one of the following service URNs; "urn:service:sos", "urn:service:sos.ambulance", "urn:service:sos.police", "urn:service:sos.fire", "urn:service:sos.marine", "urn:service:sos.mountain". If the UE can determine the type of emergency service the UE shall use an emergency service URN with a sub-service type corresponding to the type of emergency service.

NOTE 1: A service URN with a top-level service type of "sos" is used only when the user intends to establish an emergency call.

When an initial request for a dialog or a standalone transaction, or an unknown method transmitted as part of UE detected emergency call procedures as defined in subclause 5.1.6 is initiated upon reception of 380 (Alternative Service) response to an initial request for a dialog, or a standalone transaction, or an unknown method as defined in procedures in subclause 5.1.2A.1.1, subclause 5.1.3.1, subclause 5.1.6.8.1, subclause 5.1.6.8.3 and subclause 5.1.6.8.4, and if the 380 (Alternative Service) response contains a Contact header field containing a service URN with a top-level service type of "sos", the UE shall set the Request-URI of the initial request for a dialog or the standalone transaction, or the unknown method transmitted as part of UE detected emergency call procedures as defined in subclause 5.1.6 to the service URN of the Contact header field of the 380 (Alternative Service) response.

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.6.2), 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. If there are multiple registration flows associated with the registration, then the UE has received from the P-CSCF during registration multiple sets of Path header field values. The last entry of the Path header field value corresponding to the flow on which the 380 (Alternative Service) response was received is checked.

[TS 24.229 clause 5.1.6.8.3]:

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

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

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

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

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

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

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

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

6) void;

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

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

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

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.

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.6.2), 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;

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.6.3), 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.6.2) 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 4: The last entry on the Path header field value received during registration is the value of the SIP URI of the P-CSCF. If there are multiple registration flows associated with the registration, then the UE has received from the P-CSCF during registration multiple sets of Path header field values. The last entry of the Path header field value corresponding to the flow on which the 380 (Alternative Service) response was received is checked.

[TS 24.229 annex L.2.2.6]:

…

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

Table L.2.2.6.1: Mapping between type of emergency service and emergency service URN

Type of emergency service	Emergency service URN
Police	urn:service:sos.police
Ambulance	urn:service:sos.ambulance
Fire Brigade	urn:service:sos.fire
Marine Guard	urn:service:sos.marine
Mountain Rescue	urn:service:sos.mountain

Upon reception of a 380 (Alternative Service) response to an INVITE request as defined in subclause 5.1.2A.1.1 and subclause 5.1.3.1, if:

– the 380 (Alternate Service) response contains a Contact header field;

– the value of the Contact header field is a service URN; and

– the service URN has a top-level service type of "sos";

If the "emergency service information is included" as described 3GPP TS 23.167 [4B]:

2) if the URN in the Contact header field does not match any emergency service URN in table L.2.2.6.1, then the type of emergency service is not identified.

Reference(s)

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

19.3.2b.3 Test purpose

1) To verify that the on reception of 380 Alternate Service with Contact header field which does not match any emergency service URN specified in TS 24.229 [10] for an INVITE sent for emergency call establishment, UE initiates the normal call in supported CS domain over UTRAN or GERAN.

19.3.2b.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.

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

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-2) MO call is initiated on the UE by dialling a non emergency number.

3) SS responds with 380 Alternative services.

4) UE ACKS the 380 Alternative service message.

5) UE performs CS fallback or cell reselection to a cell supporting CS domain (UTRAN/GERAN) based on capability supported and initiates CS domain normal call with MM/GMM registration if necessary.

6) CS call is established.

7) CS call is 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 a normal call	MO call is initiated on the UE by dialling a “non emergency” number.
2	->		INVITE	UE sends INVITE with the first SDP offer indicating all desired medias and codecs the UE supports
3	<-		380 Alternative Service	The SS responds with a 380 Alternative Service response
4	->		ACK	The UE acknowledges the receipt of 380 Alternative Service for INVITE NOTE 1: Step 4 can happen in parallel to step 4Aa1.
–	–		EXCEPTION: The UE performs a domain selection for the emergency call and within 2 seconds of step 3 the UE may transmit EXTENDED SERVICE REQUEST	NOTE 2: Value of 2 seconds is based on estimation.
4Aa1	->		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
4Aa2	<-		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 5a1 or 5b1 is performed, depending on the value of px_RATComb_Tested
5a1	–		IF px_RATComb_Tested = EUTRA_UTRA UE performs CS fallback or cell reselection to a cell supporting CS domain (UTRAN) and performs normal call in CS domain together with MM/GMM registration	NOTE 3: RAU procedure can take place in parallel to normal CS call.
–	–		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.
5a2	–		SS configures cell A as a “non-suitable cell”
5a3	–		Normal CS call is released
5b1	–		IF px_RATComb_Tested = EUTRA_GERAN UE performs CS fallback or cell reselection to a cell supporting CS domain (GERAN cell) and performs normal call in CS domain
5b2	–		SS configures cell A as a “non-suitable cell”
5b3	–		Normal CS call is released
5b4	–		UE performs MM/GMM registration

Specific Message Contents

ATTACH ACCEPT (preamble)

Use the default message as in TS 36.508 [94] sub-clause Table 4.7.2-1 except the following change:

Information Element

Value/remark

Comment

EPS network feature support

‘0000 0001’B

IMS voice over PS session in S1 mode supported

emergency bearer services in S1 mode not supported

380 Alternative Service (Step 3)

Use the default message "380" in annex A.4.1 with the following exceptions:

Header/param	Value/Remark
Contact
Name-addr	urn:service:sos.country-specific

RRCConnectionRelease (step 4Aa2)

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 5b4)

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.3.2b.5 Test requirements

In step 5a1 or 5b1, UE initiates a CS normal call in UTRAN or GERAN cell (respectively).

19.3.2c Non-UE detectable emergency call / IM CN sends a 380 with available emergency service URN / UE performs CS Emergency call via CS domain / UTRAN or GERAN

19.3.2c.1 Definition

Test to verify that the UE correctly requests CS emergency voice service on CS domain over UTRAN or GERAN if the UE has received a 380 (Alternative Service) response to an INVITE request with Contact header field which matches an emergency service URN.

19.3.2c.2 Conformance requirement