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

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

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

L.2.1 Introduction

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 3GPP TS 29.061 [11], and 3GPP TS 29.212 [13B].

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

L.2.2 Procedures at the UE

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

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 3GPP TS 24.301 [8J], 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 3GPP TS 24.167 [8G] 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:

a) the EPS_initial_attach_ConRefs node of EF_IMSConfigData file described in 3GPP TS 31.102 [15C];

b) the EPS_initial_attach_ConRefs node of EF_{IMSConfigData} file described in 3GPP TS 31.103 [15B]; and

c) the EPS_initial_attach_ConRefs node of 3GPP TS 24.167 [8G].

If the UE is configured with both the EPS_initial_attach_ConRefs node of 3GPP TS 24.167 [8G] and the EPS_initial_attach_ConRefs node of the EF_{IMSConfigData} file described in 3GPP TS 31.102 [15C] or 3GPP TS 31.103 [15B], then the EPS_initial_attach_ConRefs node of the EF_{IMSConfigData} file shall take precedence.

NOTE 1: Precedence for files configured on both the USIM and ISIM is defined in 3GPP TS 31.103 [15B].

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

a) if not attached for EPS services yet, perform a EPS attach procedure as specified in 3GPP TS 24.301 [8J]. 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;

b) ensure that a EPS bearer context used for SIP signalling according to the APN and P-GW selection criteria described in 3GPP TS 23.401 [7B], 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;

NOTE 2: The default EPS bearer context can also be used for SIP signalling as well as any other EPS bearer context.

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

I. 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 3GPP TS 24.301 [8J]. The UE may also use this EPS bearer context for DNS and DHCP signalling;

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

III. 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 3GPP TS 24.301 [8J]. The general QoS negotiation mechanism is described in 3GPP TS 24.301 [8J]; and

NOTE 3: An EPS bearer with a QCI value other than the one for signalling can carry both IM CN subsystem signalling and media, in case the media does not need to be authorized by Policy and Charging control mechanisms as defined in 3GPP TS 29.212 [13B] and the media stream is not mandated by the P-CSCF to be carried in a separate EPS bearer.

c) acquire a P-CSCF address(es).

The methods for P-CSCF discovery are:

I. When using IPv4, employ the Dynamic Host Configuration Protocol (DHCP) RFC 2132 [20F], the DHCPv4 options for SIP servers RFC 3361 [35A], and RFC 3263 [27A] as described in subclause 9.2.1. When using IPv6, employ Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3315 [40], the DHCPv6 options for SIP servers RFC 3319 [41] and DHCPv6 options for Domain Name Servers (DNS) RFC 3646 [56C] as described in subclause 9.2.1.

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

III. The UE selects a P-CSCF from the list (see 3GPP TS 31.103 [15B]) stored in the ISIM.

IV. 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 [35A] when using IPv4 or RFC 3319 [41] 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.

NOTE 4: The UE decides whether the P-CSCF is to be discovered in the serving network or in the home network based on local configuration, e.g. whether the application on the UE is permitted to use local breakout.

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:

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

2) unless the UE decides the service is no longer needed,

a) perform a new P-CSCF discovery procedure as described in subslause 9.2.1; and

b) 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 [20F] or by the Protocol Configuration Options information element when activating a EPS bearer context according to 3GPP TS 24.301 [8J].

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

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 3GPP TS 24.301 [8J].

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:

a) the Allow_Handover_PDN_connection_WLAN_And_EPS node of EF_IMSConfigData file described in 3GPP TS 31.102 [15C];

b) the Allow_Handover_PDN_connection_WLAN_And_EPS node of EF_{IMSConfigData} file described in 3GPP TS 31.103 [15B]; and

c) the Allow_Handover_PDN_connection_WLAN_And_EPS node of 3GPP TS 24.167 [8G].

If the UE is configured with both the Allow_Handover_PDN_connection_WLAN_And_EPS node of 3GPP TS 24.167 [8G] and the Allow_Handover_PDN_connection_WLAN_And_EPS node of the EF_{IMSConfigData} file described in 3GPP TS 31.102 [15C] or 3GPP TS 31.103 [15B], then the Allow_Handover_PDN_connection_WLAN_And_EPS node of the EF_{IMSConfigData} file shall take precedence.

NOTE 5: Precedence for files configured on both the USIM and ISIM is defined in 3GPP TS 31.103 [15B].

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

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

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:

i) if the UE is required to perform an initial registration according to subclause L.3.1.2;

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

iii) if the UE needs to continue having a public user identity registered with an IP address allocated for the APN;

the UE shall:

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

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

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

a) a BEARER RESOURCE MODIFICATION REQUEST message, if there are EPS bearer contexts to this PDN that are not related SIP sessions; or

b) a PDN DISCONNECT REQUEST message if all the EPS bearer contexts to this PDN are related to SIP sessions.

NOTE: If the SIP signalling was carried over the default EPS bearer context, all the resources established as a result of SIP signalling are released without any explicit NAS signalling.

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

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

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

B if the UE uses RFC 6223 [143] 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.

NOTE 1: For UEs using procedure A described above, the network ensures that P-CSCF address(es) in the Protocol Configuration Options information element of a Modify EPS Bearer Context Request message is sent only during P-CSCF restoration procedures as defined in subclause 5 of 3GPP TS 23.380 [7D].

NOTE 2: The P-CSCF can be completely unreachable, so it is up to UE implementation to detect the end of an ongoing session, e.g. using media plane inactivity detection. Services depending on signalling such as CW and MT calls will not work during this time.

L.2.2.2 Session management procedures

The existing procedures for session management as described in 3GPP TS 24.301 [8J] shall apply while the UE is connected to the IM CN subsystem.

L.2.2.3 Mobility management procedures

The existing procedures for mobility management as described in 3GPP TS 24.301 [8J] shall apply while the UE is connected to the IM CN subsystem.

L.2.2.4 Cell selection and lack of coverage

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

L.2.2.5 EPS bearer contexts for media

L.2.2.5.1 General requirements

NOTE 1: In EPS, the UE cannot control whether media streams belonging to different SIP sessions are established on the same EPS bearer context or not. During establishment of a session, the UE establishes data streams(s) for media related to the session. Such data stream(s) can result in activation of additional EPS bearer context(s). Either the UE or the network can request for resource allocations for media, but the establishment and modification of the EPS bearer is controlled by the network as described in 3GPP TS 24.301 [8J].

NOTE 2: When the UE wishes to allocate bandwidth for RTP and RTCP, the UE uses the rules as those outlined in 3GPP TS 29.213 [13C].

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 3GPP TS 24.301 [8J].

NOTE 3: If the resource reservation requests are initiated by the EPS IP CAN, then the bearer establishment is initiated by the network after the P-CSCF has authorised the respective IP flows and provided the QoS requirements over the Rx interface to the PCRF as described in 3GPP TS 29.214 [13D].

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

If the UE is configured not to initiate resource allocation for media according to 3GPP TS 24.167 [8G], 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

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:

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

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.

NOTE: The EPS bearer resource can be needed e.g. for other data streams of a session or for other applications in the UE.

L.2.2.5.1D Default EPS bearer context usage restriction policy

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.

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

1) the media is to be sent for a media stream negotiated in a session offered or established by SIP signalling;

2) the media stream is of a media type indicated in the media type condition of the EPS bearer context usage restriction policy part;

3) the following is true:

a) the default EPS bearer context usage restriction policy part does not have the ICSI condition; or

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

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

1) the UE shall not send media restricted according to the default EPS bearer context usage restriction policy; and

2) the UE may support being configured with the default EPS bearer context usage restriction policy using one or more of the following methods:

a) the Default_EPS_bearer_context_usage_restriction_policy node of the EF_{IMSConfigData} file described in 3GPP TS 31.102 [15C];

b) the Default_EPS_bearer_context_usage_restriction_policy node of the EF_{IMSConfigData} file described in 3GPP TS 31.103 [15B]; and

c) Default_EPS_bearer_context_usage_restriction_policy node of 3GPP TS 24.167 [8G].

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 3GPP TS 24.167 [8G] and the Ethe Default_EPS_bearer_context_usage_restriction_policy node of F_{IMSConfigData} file described in 3GPP TS 31.102 [15C] or 3GPP TS 31.103 [15B], then the EF_{IMSConfigData} file shall take precedence.

NOTE: Precedence for files configured on both the USIM and ISIM is defined in 3GPP TS 31.103 [15B].

L.2.2.5.2 Special requirements applying to forked responses

NOTE 1: The procedures in this subclause only apply when the UE requests activation and modification of media bearers. In the case where the network activates and modifies the media bearers the network takes care of the handling of media bearers in the case of forking.

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:

1) the bearer requirements of the subsequent SDP can be accommodated by the existing resources requested. The UE performs no further resource requests.

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

3) the subsequent SDP introduces one or more additional IP flows. The UE requests further resource allocation according to subclause L.2.2.5.1.

NOTE 2: When several forked responses are received, the resources requested by the UE are the "logical OR" of the resources indicated in the multiple responses to avoid allocation of unnecessary resources. The UE does not request more resources than proposed in the original INVITE request.

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 RFC 3261 [26] subclause 13.2.2.4), the UE shall:

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

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 3GPP TS 29.214 [13D] and 3GPP TS 29.212 [13B].

L.2.2.6 Emergency service

L.2.2.6.1 General

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 3GPP TS 36.331 [19F]), 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.

NOTE 1: The UE can determine that EPS authentication procedure has succeeded during the emergency ATTACH procedure when a non-null integrity protection algorithm (i.e. other than EIA0 algorithm) is received in the NAS signalling SECURITY MODE COMMAND message.

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

NOTE 3: The UE verifies if a detected emergency number is still present in the Extended Local Emergency Number List after attach to a different PLMN. It is possible for the number to no longer be present in the Extended Local Emergency Number List if:

– the PLMN attached to relies on the Local Emergency Number List for deriving a URN; or

– the previously received Extended Emergency Number List Validity field indicated "Extended Local Emergency Numbers List is valid only in the PLMN from which this IE is received".

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 3GPP TS 24.301 [8J]), 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 3GPP TS 24.301 [8J]) 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 3GPP TS 24.008 [8]), 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 3GPP TS 23.167 [4B].

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 3GPP TS 23.167 [4B].

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 4: 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. The country specific URN is an example of a "emergency subservice type that does not map into an emergency service category for the CS domain".

When the emergency registration expires, the UE should disconnect the PDN connection for emergency bearer services as described in 3GPP TS 24.301 [8J].

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

L.2.2.6.1A Type of emergency service derived from emergency service category value

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

NOTE 1: It is not possible for a UE to indicate more than one type of emergency service in an emergency service URN.

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

NOTE 2: If the Non-3GPP emergency number indicator within the Non-3GPP NW provided policies IE (see 3GPP TS 24.008 [8]) provided through registration procedures over 3GPP access is set to "use of non-3GPP emergency numbers permitted", the UE also considers WLAN provided local emergency numbers (see 3GPP TS 24.302 [8U], subclause 4.7). If the Non-3GPP NW provided policies IE provided through registration procedures over 3GPP access is set to "use of non-3GPP emergency numbers not permitted", the UE does not consider WLAN provided local emergency numbers. If the Non-3GPP NW provided policies IE is not provided through registration procedures over 3GPP access, the UE does not consider WLAN provided local emergency numbers.

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.

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

L.2.2.6.1B Type of emergency service derived from extended local emergency number list

The Extended Local Emergency Number List (defined in 3GPP TS 24.301 [8J]) 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

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

Void.