Content for TS 24.229 Word version: 18.4.0

1… 3… 4… 4.5… 5… 5.1.1.4… 5.1.2… 5.1.4… 5.2… 5.2.3… 5.2.6… 5.2.7… 5.3… 5.4… 5.4.1.2.2… 5.4.1.3… 5.4.2 5.4.3… 5.4.3.3… 5.4.4… 5.5… 5.7… 5.7.2… 5.8… 5.11… 6… 6.6… 7… 7.2A… 7.2A.6… 7.3… 7.9A… 8… A… A.2… A.2.1.4… A.2.1.4.7… A.2.1.4.8… A.2.1.4.10A… A.2.1.4.12… A.2.2… A.2.2.4… A.2.2.4.7… A.2.2.4.8… A.2.2.4.10A… A.2.2.4.12… A.3… A.3.3… B… C… E… F… H… I… K… L… L.2A… M… N… O… Q… R… S… U… U.2A… V… W…

L.1 Scope L.2 EPS aspects when connected to the IM CN subsystem via E-UTRAN
...

L (Normative) IP-Connectivity Access Network specific concepts when using EPS to access IM CN subsystem |R8| p. 881

L.1 Scope p. 881

The present annex defines IP-CAN specific requirements for a call control protocol for use in the IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP), and the associated Session Description Protocol (SDP), where the IP-CAN is Evolved Packet System (EPS). The EPS IP-CAN has an EPS core network which can be supported by an E-UTRAN radio access network.

L.2 EPS aspects when connected to the IM CN subsystem via E-UTRAN p. 881

L.2.1 Introduction p. 881

A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by EPS to provide packet-mode communication between the UE and the IM CN subsystem.

Requirements for the UE on the use of these packet-mode services are specified in this clause. Requirements for the P-GW in support of this communication are specified in TS 29.061, and TS 29.212.

When using the EPS, each IP-CAN bearer is provided by an EPS bearer.

L.2.2 Procedures at the UE p. 881

L.2.2.1 EPS bearer context activation and P-CSCF discovery p. 881

The policy on the PDN connection established during the EPS attach procedure identifies parameters for composing the ESM messages sent during the EPS attach procedure as specified in TS 24.301, when the UE performs the EPS attach procedure in order to communicate with IM CN subsystem.

The UE may support the policy on the PDN connection established during the EPS attach procedure.

If the UE supports the optional configuration parameter "Access_Point_Name_Parameter_Reading_Rule", as defined in TS 24.167 and has been configured with this parameter, then the UE shall use it to retrieve the access point name to use in the EPS bearer context activation procedure.

If the UE supports the policy on the PDN connection established during the EPS attach procedure, the UE may support being configured with the policy on the PDN connection established during the EPS attach procedure using one or more of the following methods:

the EPS_initial_attach_ConRefs node of EFIMSConfigData file described in TS 31.102;
the EPS_initial_attach_ConRefs node of EFIMSConfigData file described in TS 31.103; and
the EPS_initial_attach_ConRefs node of TS 24.167.

If the UE is configured with both the EPS_initial_attach_ConRefs node of TS 24.167 and the EPS_initial_attach_ConRefs node of the EFIMSConfigData file described in TS 31.102 or TS 31.103, then the EPS_initial_attach_ConRefs node of the EFIMSConfigData file shall take precedence.

Prior to communication with the IM CN subsystem, the UE shall:

if not attached for EPS services yet, perform a EPS attach procedure as specified in TS 24.301. If the UE requests establishment of a PDN connection during the EPS attach procedure, and the UE supports and is configured with the policy on the PDN connection established during the EPS attach procedure, the UE shall compose the ESM messages sent during the EPS attach procedure, according to the policy on the PDN connection established during the EPS attach procedure;

ensure that a EPS bearer context used for SIP signalling according to the APN and P-GW selection criteria described in TS 23.401, is available. This EPS bearer context shall remain active throughout the period the UE is connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration. As a result, the EPS bearer context provides the UE with information that makes the UE able to construct an IPv4 or an IPv6 address;

When the EPS bearer context establishment procedure for the SIP signalling is initiated by the UE:

if a default EPS bearer context is not available with the selected P-GW, the UE shall indicate to the network in the PDN CONNECTIVITY REQUEST that the request is for SIP signalling. If the request is authorized, the network establishes a bearer with the appropriate QCI as described in TS 24.301. The UE may also use this EPS bearer context for DNS and DHCP signalling;
if the default EPS bearer context is available with the selected P-GW, and is to be used for SIP signalling no additional steps are needed; and
if the default EPS bearer context is available with the selected P-GW and an EPS bearer for SIP signalling with the correct QCI and TFT is to be established, the UE shall indicate to the network, by setting the IM CN Subsystem Signalling Flag in the Protocol Configuration Options information element in the BEARER RESOURCE ALLOCATION REQUEST message, that the request is for SIP signalling. If the request is authorized, the network either establishes a new dedicated bearer or modifies an exisiting bearer with the appropriate QCI and TFT as described in TS 24.301. The general QoS negotiation mechanism is described in TS 24.301; and

acquire a P-CSCF address(es).

The methods for P-CSCF discovery are:

When using IPv4, employ the Dynamic Host Configuration Protocol (DHCP) RFC 2132, the DHCPv4 options for SIP servers RFC 3361, and RFC 3263 as described in subclause 9.2.1. When using IPv6, employ Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3315, the DHCPv6 options for SIP servers RFC 3319 and DHCPv6 options for Domain Name Servers (DNS) RFC 3646 as described in subclause 9.2.1.
Transfer P-CSCF address(es) within the EPS bearer context activation procedure.
The UE shall indicate the request for a P-CSCF address to the network within the Protocol Configuration Options information element of the PDN CONNECTIVITY REQUEST message or BEARER RESOURCE ALLOCATION REQUEST message.
If the network provides the UE with a list of P-CSCF IPv4 or IPv6 addresses in the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message or ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message, the UE shall assume that the list is ordered top-down with the first P-CSCF address within the Protocol Configuration Options information element as the P-CSCF address having the highest preference and the last P-CSCF address within the Protocol Configuration Options information element as the P-CSCF address having the lowest preference.
The UE selects a P-CSCF from the list (see TS 31.103) stored in the ISIM.
The UE selects a P-CSCF from the list in IMS management object.
The UE shall use method IV to select a P-CSCF, if
- a P-CSCF is to be discovered in the home network;
- the UE is roaming; and
- the IMS management object contains the P-CSCF list.
The UE shall use method III to select the P-CSCF, if:
- a P-CSCF is to be discovered in the home network;
- the UE is roaming;
- either the UE does not contain the IMS management object, or the UE contains the IMS management object but the IMS management object does not contain the P-CSCF list; and
- the ISIM residing in the UICC supports the P-CSCF list.

The UE can freely select method I or II for P-CSCF discovery, if:

the UE is in the home network; or
the UE is roaming and the P-CSCF is to be discovered in the visited network.

The UE can select method IV, if:

the UE is in the home network; and
the IMS management object contains the P-CSCF list.

In case method I is selected and several P-CSCF addresses or FQDNs are provided to the UE, the selection of P-CSCF address or FQDN shall be performed as indicated in RFC 3361 when using IPv4 or RFC 3319 when using IPv6. If sufficient information for P-CSCF address selection is not available, selection of the P-CSCF address by the UE is implementation specific.

If the UE is designed to use I above, but receives P-CSCF address(es) according to II, then the UE shall either ignore the received address(es), or use the address(es) in accordance with II, and not proceed with the DHCP request according to I.

If the UE is configured to use Option II above and detects that all P-CSCFs known by the UE have been used when the UE selects a different P-CSCF as a result of:

receiving 305 (Use Proxy) to the REGISTER request;
receiving 504 (Server Time-out); or
expiration of the timer F at the UE,

then if there are more than one PDN connection that UE is connected to and unless the IP-CAN bearer is in use by other applications, the UE shall:

release IP-CAN bearer that is used only for the transport of SIP signalling and that are not used for other non-IMS applications, but shall not release emergency IP-CAN bearers; and
unless the UE decides the service is no longer needed,
1. perform a new P-CSCF discovery procedure as described in subslause 9.2.1; and
2. perform the procedures for initial registration as described in subclause 5.1.1.2.

When using IPv4, the UE may request a DNS Server IPv4 address(es) via RFC 2132 or by the Protocol Configuration Options information element when activating a EPS bearer context according to TS 24.301.

When using IPv6, the UE may request a DNS Server IPv6 address(es) via RFC 3315 and RFC 3646 or by the Protocol Configuration Options information element when activating a EPS bearer context according to TS 24.301.

The encoding of the request and response for IPv4 or IPv6 address(es) for DNS server(s) and list of P-CSCF address(es) within the Protocol Configuration Options information element is described in TS 24.301.

When:

the UE obtains an EPS bearer context used for SIP signalling by performing handover of the connection from another IP-CAN;
IP address of the UE is not changed during the handover; and
the UE already communicates with the IM CN subsystem via the connection with the other IP-CAN, e.g. the UE determines that its contact with host portion set to the UE IP address (or FQDN of the UE) associated with the connection with the other IP-CAN has been bound to a public user identity;

the UE shall continue using the P-CSCF address(es) acquired in the other IP-CAN.

The UE may support the policy on when a UE roaming in a VPLMN is allowed to transfer the PDN connection providing access to IMS between EPC via WLAN and EPS. If the UE roams in the EPS IP-CAN, has a session and the policy indicates "roaming in a VPLMN and having an ongoing session, is not allowed to transfer the PDN connection providing access to IMS between EPC via WLAN and EPS", the UE shall not handover the PDN connection providing access to IMS from EPC via WLAN to EPS.

If the UE roams in the EPS IP-CAN, has a session and the policy indicates "roaming in a VPLMN and having an ongoing session, is allowed to transfer the PDN connection providing access to IMS between EPC via WLAN and EPS", the UE shall, if not prevented by other rules or policies, handover the PDN connection providing access to IMS from EPC via WLAN to EPS.

If the UE roams in the EPS IP-CAN and the policy indicates "roaming in a VPLMN is not allowed to transfer the PDN connection providing access to IMS between EPC via WLAN and EPS, irrespective of if the UE is in a session or not", the UE shall not handover the PDN connection providing access to IMS from EPC via WLAN to EPS. The UE can re-establish a new PDN connection to another IP-CAN type in idle mode, e.g. due to UE domain preference.

If the UE supports the policy on whether a roaming UE when in a session is allowed to transfer the PDN connection providing access to IMS between EPC via WLAN and EPS, the UE may support being configured with the policy on whether a roaming UE when in a session is allowed to transfer the PDN connection providing access to IMS between EPC via WLAN EPS using one or more of the following methods:

the Allow_Handover_PDN_connection_WLAN_And_EPS node of EFIMSConfigData file described in TS 31.102;
the Allow_Handover_PDN_connection_WLAN_And_EPS node of EFIMSConfigData file described in TS 31.103; and
the Allow_Handover_PDN_connection_WLAN_And_EPS node of TS 24.167.

If the UE is configured with both the Allow_Handover_PDN_connection_WLAN_And_EPS node of TS 24.167 and the Allow_Handover_PDN_connection_WLAN_And_EPS node of the EFIMSConfigData file described in TS 31.102 or TS 31.103, then the Allow_Handover_PDN_connection_WLAN_And_EPS node of the EFIMSConfigData file shall take precedence.

L.2.2.1A Modification of a EPS bearer context used for SIP signalling p. 884

The EPS bearer context shall not be modified from being used exclusively for SIP signalling to a general purpose EPS bearer. After the establishment of an EPS bearer context used for SIP signalling, the UE shall not set the IM CN Subsystem Signalling Flag in the Protocol Configuration Options information element of any subsequent BEARER RESOURCE MODIFICATION REQUEST message for that APN. The UE shall ignore the IM CN Subsystem Signalling Flag if received from the network in the Protocol Configuration Options information element.

After the establishment of a EPS bearer context used for SIP signalling, the UE shall not indicate the request for a P-CSCF address to the network within the Protocol Configuration Options information element of any subsequent BEARER RESOURCE MODIFICATION REQUEST message for that APN. The UE shall ignore P-CSCF address(es) if received from the network in the Protocol Configuration Options information element.

L.2.2.1B Re-establishment of the EPS bearer context for SIP signalling p. 885

If the UE registered a public user identity with an IP address allocated for the APN of the EPS bearer context used for SIP signalling, the EPS bearer context used for SIP signalling is deactivated as result of signalling from the network and:

if the UE is required to perform an initial registration according to subclause L.3.1.2;
if the signalling from the network results in requiring the UE to initiate activation of the PDN connection of the EPS bearer context used for SIP signalling; or
if the UE needs to continue having a public user identity registered with an IP address allocated for the APN;

the UE shall:

if the non-access stratum is performing the UE requested PDN connectivity procedure and the EPS bearer context activation procedure(s) for the APN triggered as result of the signalling from the network, wait until the UE requested PDN connectivity procedure and the EPS bearer context activation procedure(s) for the APN finish; and
perform the procedures in subclause L.2.2.1, bullets a), b) and c).

If none of the bullets i), ii) and iii) of this subclause evaluate to true, or the procedures in bullet B) of this subclause were unable to ensure that the EPS bearer context used for SIP signalling is available or were unable to acquire any P-CSCF address(es):

if the SIP signalling was carried over a dedicated EPS bearer context, the UE shall release all resources established as a result of SIP signalling by sending to the network either:
1. a BEARER RESOURCE MODIFICATION REQUEST message, if there are EPS bearer contexts to this PDN that are not related SIP sessions; or
2. a PDN DISCONNECT REQUEST message if all the EPS bearer contexts to this PDN are related to SIP sessions.

If the default EPS bearer context of the PDN connection of the EPS bearer context used for SIP signalling was deactivated at the start of this subclause, and the procedures in bullet B) of this subclause ensured that the EPS bearer context used for SIP signalling is available and acquired the P-CSCF address(es), the UE shall perform a new initial registration according to subclause 5.1.1.2.

L.2.2.1C P-CSCF restoration procedure |R9| p. 885

A UE supporting the P-CSCF restoration procedure performs one of the following procedures:

if the UE used method II for P-CSCF discovery and if the UE receives one or more P-CSCF address(es) in the Protocol Configuration Options information element of a Modify EPS Bearer Context Request message the one or more P-CSCF addresse(s) do not include the address of the currently used P-CSCF, then the UE shall acquire a different P-CSCF address from the one or more P-CSCF addresse(s) in the Modify EPS Bearer Context Request message. If more than one P-CSCF address with the same container identifier (i.e. "P-CSCF IPv6 Address" or "P-CSCF IPv4 Address") are included, then the UE shall assume that the more than one P-CSCF addresses with the same container identifier are prioritised with the first P-CSCF address with the same container identifier within the Protocol Configuration Options information element as the P-CSCF address with the highest priority.

If the UE used method II for P-CSCF discovery and if the UE has previously sent the "P-CSCF Re-selection support" PCO indicator at PDN creation and if the UE receives one or more P-CSCF address(es) in the Protocol Configuration Options information element of a Modify EPS Bearer Context Request message, then the UE shall acquire a P-CSCF address from the one or more P-CSCF addresse(s) in the Modify EPS Bearer Context Request message. If more than one P-CSCF address with the same container identifier (i.e. "P-CSCF IPv6 Address" or "P-CSCF IPv4 Address") are included, then the UE shall assume that the more than one P-CSCF addresses with the same container identifier are prioritised with the first P-CSCF address with the same container identifier within the Protocol Configuration Options information element as the P-CSCF address with the highest priority;

if the UE uses RFC 6223 as part of P-CSCF restoration procedures, and if the P-CSCF fails to respond to a keep-alive request, then the UE shall acquire a different P-CSCF address using one of the methods I, III and IV for P-CSCF discovery described in the subclause L.2.2.1.

If the UE has an ongoing session and acquired the new P-CSCF address by using procedure A described above, the UE may wait until the UE has detected that the ongoing session has ended before performing an initial registration as specified in subclause 5.1.

In all other cases, when the UE has acquired the P-CSCF address, the UE not having an ongoing session shall perform an initial registration as specified in subclause 5.1.

L.2.2.2 Session management procedures p. 886

The existing procedures for session management as described in TS 24.301 shall apply while the UE is connected to the IM CN subsystem.

L.2.2.3 Mobility management procedures p. 886

The existing procedures for mobility management as described in TS 24.301 shall apply while the UE is connected to the IM CN subsystem.

L.2.2.4 Cell selection and lack of coverage p. 886

The existing mechanisms and criteria for cell selection as described in TS 36.304 shall apply while the UE is connected to the IM CN subsystem.

L.2.2.5 EPS bearer contexts for media p. 886

L.2.2.5.1 General requirements p. 886

If the resource allocation is initiated by the UE, the UE starts reserving resources whenever it has sufficient information about the media streams, and used codecs available as specified in TS 24.301.

L.2.2.5.1A Activation or modification of EPS bearer contexts for media by the UE p. 887

If the UE is configured not to initiate resource allocation for media according to TS 24.167, then the UE shall refrain from requesting additional EPS bearer context(s) for media until the UE considers that the network did not initiate resource allocation for the media.

L.2.2.5.1B Activation or modification of EPS bearer contexts for media by the network p. 887

If the UE receives an activation request from the network for a EPS bearer context which is associated with the EPS bearer context used for signalling, the UE shall, based on the information contained in the Traffic Flow Template information element, correlate the media EPS bearer context with a currently ongoing SIP session establishment or SIP session modification.

If the UE receives a modification request from the network for a EPS bearer context that is used for one or more media streams in an ongoing SIP session, the UE shall:

modify the related EPS bearer context in accordance with the request received from the network.

L.2.2.5.1C Deactivation of EPS bearer context for media |R11| p. 887

When a data stream for media related to a session is released, if the EPS bearer resource transporting the data stream is no longer needed and allocation of the EPS bearer resource was requested by the UE, then the UE releases the EPS bearer resource.

L.2.2.5.1D Default EPS bearer context usage restriction policy |R14| p. 887

The default EPS bearer context usage restriction policy consists of zero or more default EPS bearer context usage restriction policy parts.

The default EPS bearer context usage restriction policy part consists of a mandatory media type condition and an optional ICSI condition.

The default EPS bearer context usage restriction policy does not apply to UE detected emergency calls.

Sending media is restricted according to the default EPS bearer context usage restriction policy, if sending media is restricted according to at least one default EPS bearer context usage restriction policy part of the default EPS bearer context usage restriction policy or if the UE is roaming.

Sending media is restricted according to the default EPS bearer context usage restriction policy part if:

the media is to be sent for a media stream negotiated in a session offered or established by SIP signalling;
the media stream is of a media type indicated in the media type condition of the EPS bearer context usage restriction policy part;
the following is true:
1. the default EPS bearer context usage restriction policy part does not have the ICSI condition; or
2. the session is offered or established by SIP signalling related to an IMS communication service identified in the ICSI condition of the default EPS bearer context usage restriction policy part; and
the media is to be sent via the default EPS bearer context of the PDN connection for SIP signalling.

The UE may support the default EPS bearer context usage restriction policy.

If the UE supports the default EPS bearer context usage restriction policy:

the UE shall not send media restricted according to the default EPS bearer context usage restriction policy; and
the UE may support being configured with the default EPS bearer context usage restriction policy using one or more of the following methods:
1. the Default_EPS_bearer_context_usage_restriction_policy node of the EFIMSConfigData file described in TS 31.102;
2. the Default_EPS_bearer_context_usage_restriction_policy node of the EFIMSConfigData file described in TS 31.103; and
3. Default_EPS_bearer_context_usage_restriction_policy node of TS 24.167.
If the UE is configured with both the the Default_EPS_bearer_context_usage_restriction_policy node of Default_EPS_bearer_context_usage_restriction_policy node of TS 24.167 and the Ethe Default_EPS_bearer_context_usage_restriction_policy node of FIMSConfigData file described in TS 31.102 or TS 31.103, then the EFIMSConfigData file shall take precedence.

L.2.2.5.2 Special requirements applying to forked responses p. 888

Since the UE does not know that forking has occurred until a second, provisional response arrives, the UE requests resource allocation as required by the initial response received. If a subsequent provisional response is received, different alternative actions may be performed depending on the requirements in the SDP answer:

the bearer requirements of the subsequent SDP can be accommodated by the existing resources requested. The UE performs no further resource requests.
the subsequent SDP introduces different QoS requirements or additional IP flows. The UE requests further resource allocation according to subclause L.2.2.5.1.
the subsequent SDP introduces one or more additional IP flows. The UE requests further resource allocation according to subclause L.2.2.5.1.

When a final answer is received for one of the early dialogs, the UE proceeds to set up the SIP session. The UE shall release all the unneeded IP-CAN resources. Therefore, upon the reception of the first final 200 (OK) response for the INVITE request (in addition to the procedures defined in Section 13.2.2.4 of RFC 3261), the UE shall:

in case resources were established or modified as a consequence of the INVITE request and forked provisional responses that are not related to the accepted 200 (OK) response, send release request to release the unneeded resources.

L.2.2.5.3 Unsuccessful situations p. 888

One of the Rx and Gx interface related error codes can be received by the UE in either the PDN CONNECTIVITY REJECT message, the BEARER RESOURCE MODIFICATION REJECT message, or the BEARER RESOURCE ALLOCATION REJECT message. If the UE receives a Rx and Gx interface related error code, the UE shall either handle the resource reservation failure as described in subclause 6.1.1 or retransmit the message up to three times. The Rx and Gx interface related error codes are further specified in TS 29.214 and TS 29.212.

L.2.2.6 Emergency service p. 888

L.2.2.6.1 General |R14| p. 888

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 but it can also be assumed that a registration in the IM CN subsystem will also fail. In such cases, subject to the lower layers indicating that the network does support emergency bearer services in limited service state (see TS 36.331), the procedures for emergency calls without registration can be applied, as defined in subclause 5.1.6.8.2. If the EPS authentication procedure has already succeeded during the latest normal or emergency ATTACH procedure, the UE shall perform an initial emergency registration, as described in subclause 5.1.6.2 before attempting an emergency call as described in subclause 5.1.6.8.3.

When activating an EPS bearer context to perform emergency registration, the UE shall request a PDN connection for emergency bearer services as described in 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.

If the UE detected an emergency number, the UE subsequently performs an attach procedure or an emergency attach procedure with a different PLMN than the PLMN from which the UE received the last Extended Local Emergency Number List, the dialled number is not stored in the ME, in the USIM and in the Local Emergency Number List; and

the ATTACH ACCEPT message received from the different PLMN contains the Extended Local Emergency Number List and the emergency number is present in the updated Extended Local Emergency Number List then the UE uses the updated Extended Local Emergency Number List when it performs the procedures in subclause L.2.2.6.1B; and
the ATTACH ACCEPT message received from the different PLMN contains no Extended Local Emergency Number List or the emergency number is no longer present in the updated Extended Local Emergency Number List then the UE shall attempt UE procedures for SIP that relate to emergency using emergency service URN "urn:service:sos".

If the dialled number is equal to a local emergency number stored in the Extended Local Emergency Number List (as defined in TS 24.301), then the UE shall recognize such a number as for an emergency call and:

if the dialled number is equal to an emergency number stored in the ME, or in the USIM, then the UE shall perform either procedures in the subclause L.2.2.6.1B or the procedures in subclause L.2.2.6.1A; and
if the dialled number in not equal to an emergency number stored in the ME, or in the USIM, then the UE shall perform procedures in the subclause L.2.2.6.1B.

If the dialled number is not equal to a local emergency number stored in the Extended Local Emergency Number List (as defined in TS 24.301) and:

if the dialled number is equal to an emergency number stored in the ME, in the USIM or in the Local Emergency Number List (as defined in TS 24.008), then the UE shall recognize such a number as for an emergency call and performs the procedures in subclause L.2.2.6.1A.

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

then the UE determines that "emergency service information is included" as described TS 23.167.

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 does not contain a Contact header field with service URN that has a top-level service type of "sos", then the UE determines that "no emergency service information is included" as described TS 23.167.

If the "emergency service information is included" as described TS 23.167:

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

When the emergency registration expires, the UE should disconnect the PDN connection for emergency bearer services as described in TS 24.301.

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 TS 23.167 Annex H, to re-attempt the emergency call.

L.2.2.6.1A Type of emergency service derived from emergency service category value |R15| p. 890

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 TS 24.008). 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 an IP-CAN, capable of providing local emergency numbers, 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 an IP-CAN, capable of providing local emergency numbers, 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.

L.2.2.6.1B Type of emergency service derived from extended local emergency number list |R15| p. 891

The Extended Local Emergency Number List (defined in TS 24.301) can contain sub-services of the associated emergency service URN for the detected emergency number.

If:

the length of sub-services field is greater than "0", the UE shall construct the emergency service URN using "urn:service:sos" followed by adding a dot followed by the content of the sub-services field; and
the length of sub-services field is "0", the UE shall use the emergency service URN "urn:service:sos".

EXAMPLE 1:

For a detected number, if the sub-service is "gas", then the UE constructs "urn:service:sos.gas" as the associated emergency service URN.

EXAMPLE 2:

For a detected number, if no sub-service is provided, then the UE uses "urn:service:sos" as the associated emergency service URN.

L.2.2.6.2 eCall type of emergency service |R14| p. 891

If the IP-CAN indicates the eCall support indication or the CS domain is not available to the UE, the UE can send an INVITE request with Request-URI set to "urn:service:sos.ecall.manual" or "urn:service:sos.ecall.automatic".

If the IP-CAN does not indicates the eCall support indication and the CS domain is available to the UE, the UE shall not send an INVITE request with Request-URI set to "urn:service:sos.ecall.manual" or "urn:service:sos.ecall.automatic".

L.2.2.6.3 Current location discovery during an emergency call |R14| p. 892

Void.