R.2 IP-CAN aspects when connected to the IM CN subsystem

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

R.2.1 Introduction

A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by the EPC and the WLAN 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.

R.2.2 Procedures at the UE

R.2.2.1 Establishment of IP-CAN bearer and P-CSCF discovery

Prior to communication with the IM CN subsystem:

NOTE 1: The UE performs access network discovery and selection procedures as specified in 3GPP TS 24.302 [8U] and executes access authentication signalling for access to the EPC between the UE and 3GPP AAA server, if applicable, as described in 3GPP TS 24.302 [8U] prior to perform the procedure to obtain a local IP address;

a) the UE establishes an IP-CAN bearer for SIP signalling as follows:

1) if the UE attaches to the EPC via S2b using untrusted WLAN IP access:

A) the UE shall obtain a local IP address using the WLAN IP access;

B) if the UE does not support procedures for access to the EPC via restrictive non-3GPP access network or unless the UE determines that the WLAN used is a restrictive non-3GPP access network, then the UE shall establish an IKEv2 security association and an IPsec ESP security association with ePDG as described in 3GPP TS 24.302 [8U]. If the UE supports the Fixed Access Broadband interworking, the UE shall apply the establishment of tunnel specified in 3GPP TS 24.139 [8X];

NOTE 2: UE can determine that the WLAN used is a restrictive non-3GPP access network if no IKEv2 response is received for the IKEv2 IKE_SA_INIT request, or using means out of scope of this specification.

C) if the UE supports procedures for access to the EPC via restrictive non-3GPP access network, and if the UE determines that the WLAN used is a restrictive non-3GPP access network, then the UE may perform procedures for access to the EPC via restrictive non-3GPP access network as described in 3GPP TS 24.302 [8U], and may establish an IKEv2 security association and an IPsec ESP security association with ePDG via the firewall traversal tunnel;

D) the IKEv2 security association and the IPsec ESP security association (tunnel) 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; and

E) the UE may carry both signalling and media on an IPsec ESP security association;

2) if the UE attaches to the EPC via S2c using the WLAN IP access:

A) the UE shall obtain a local IP address;

B) the UE shall establish an IKEv2 security association and an IPsec ESP security association as described in 3GPP TS 24.302 [8U] and 3GPP TS 24.303 [8V]. If the UE supports the Fixed Access Broadband interworking, the UE shall apply the establishment of tunnel specified in 3GPP TS 24.139 [8X];

C) the IKEv2 security association and the IPsec ESP security association (tunnel) 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; and

D) the UE may carry both signalling and media on an IPsec ESP security association.

3) if the UE attaches to the EPC via S2a using a trusted WLAN IP access:

A) the IPv4 address and/or IPv6 prefix is allocated as specified in 3GPP TS 24.302 [8U]; and

B) the UE IP address shall remain valid throughout the period the UE is connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration;

The UE can determine trust relationship of a non-3GPP IP access network as specified in 3GPP TS 24.302 [8U]; and

b) the UE shall aquire a P-CSCF address(es).

The methods for P-CSCF discovery are:

I. Use DHCP mechanism

II. Use DNS

When using IPv4, the UE may request a DNS Server IPv4 address(es) via RFC 2132 [20F]. When using IPv6, the UE may request a DNS Server IPv6 address(es) via RFC 3315 [40] and RFC 3646 [56C].

III. Obtain the list of P-CSCF address(es) from the IMS management object

IV. Obtain P-CSCF address(es) using signalling for access to the EPC via WLAN.

If the UE attaches to the EPC via S2b using untrusted WLAN IP access, the UE shall request P-CSCF IPv4 address(es), P-CSCF IPv6 address(es) or both using the P_CSCF_IP4_ADDRESS attribute, the P_CSCF_IP6_ADDRESS attribute or both in the CFG_REQUEST configuration payload as described in 3GPP TS 24.302 [8U]. The network can provide the UE with the P-CSCF IPv4 address(es), P-CSCF IPv6 address(es) or both using the P_CSCF_IP4_ADDRESS attribute, the P_CSCF_IP6_ADDRESS attribute or both in the CFG_REPLY configuration payload as described in 3GPP TS 24.302 [8U]. If the UE receives multiple P-CSCF IPv4 or IPv6 addresses, the UE shall assume that the list is ordered top-down with the first P-CSCF address within the CFG_REPLY configuration payload as the P-CSCF address having the highest preference and the last P-CSCF address within the CFG_REPLY configuration payload as the P-CSCF address having the lowest preference.

If the UE attaches to the EPC via S2a using trusted WLAN IP access using single-connection mode, the UE shall indicate request for P-CSCF IPv4 address(es), P-CSCF IPv6 address(es) or both within the PROTOCOL_CONFIGURATION_OPTIONS item of the message with SCM_REQUEST message type as described in 3GPP TS 24.302 [8U]. The network can provide the UE with the P-CSCF IPv4 address(es), P-CSCF IPv6 address(es) or both within the PROTOCOL_CONFIGURATION_OPTIONS item of the message with SCM_RESPONSE message type as described in 3GPP TS 24.302 [8U]. If the UE receives multiple P-CSCF IPv4 or IPv6 addresses, the UE shall assume that the list is ordered top-down with the first P-CSCF address within the PROTOCOL_CONFIGURATION_OPTIONS item as the P-CSCF address having the highest preference and the last P-CSCF address within the PROTOCOL_CONFIGURATION_OPTIONS item as the P-CSCF address having the lowest preference.

If the UE attaches to the EPC via S2a using trusted WLAN IP access using multi-connection mode, the UE shall indicate request for P-CSCF IPv4 address(es), P-CSCF IPv6 address(es) or both within the Protocol Configuration Options information element of the PDN CONNECTIVITY REQUEST message as described in 3GPP TS 24.244 [8ZB]. The network can provide the UE with the P-CSCF IPv4 address(es), P-CSCF IPv6 address(es) or both within the Protocol Configuration Options information element of the PDN CONNECTIVITY ACCEPT message as described in 3GPP TS 24.244 [8ZB]. If the UE receives multiple P-CSCF IPv4 or IPv6 addresses, 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 shall use method III to select a P-CSCF, if a P-CSCF is to be discovered in the home network and the WLAN, to which the UE is attached, is connected to a visited network.

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

– the UE is in the home network; or

– the WLAN, to which the UE is attached, is connected to a visited network and the P-CSCF is to be discovered in the visited network.

If DHCP is used, the following procedures apply:

Upon establishing an IP-CAN, the UE may use the Dynamic Host Configuration Protocol (DHCP) specified in RFC 2131 [40A] or Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specified in RFC 3315 [40] to discover the P-CSCF.

Prior to accessing the DHCP server, the UE will have obtained an IP address via means other than DHCP and DHCPv6.

If the UE uses DHCP for P-CSCF discovery and the UE is unaware of the address of the DHCP server, the UE sends the DHCPINFORM using the limited broadcast IP address (i.e., 255.255.255.255) and UDP port 67. If the UE knows the IP address of the DHCP server, the UE shall send the DHCPINFORM to the DHCP server’s unicast IP address and UDP port 67. The DHCP server sends the DHCPACK on the IP address specified in the Client IP Address field of the DHCPINFORM. The DHCP server can include, in the DHCPACK, the SIP Server DHCP Option specified in RFC 3361 [35A], which carries either a list of IPv4 address(es) of the P-CSCF(s) or a list of DNS fully qualified domain name(s) that can be mapped to one or more P-CSCF(s). If the UE uses DHCPv6 for P-CSCF discovery and the UE is unaware of the address of the DHCP Server, the UE shall send an Information Request using the IPv6 multicast address FF02::1:2 and the UDP port 547. If the UE knows the IP address of the DHCPv6 server, the UE shall send the Information Request message to the DHCPv6 server’s IP address and UDP port 547. In the Information Request, the UE can request either one or both the SIP Servers Domain Name List option and the SIP Servers IPv6 Address List option specified in RFC 3319 [41]. The DHCP server sends the Reply to the IP address specified in the Information Request. The DHCP server can include in the Reply either one or both the SIP Servers Domain Name List option and the SIP Servers IPv6 Address List option, as requested by the UE.

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 establishment of IP-CAN bearer.

In case several P-CSCF’s IP addresses or domain names are provided to the UE, the UE shall perform P-CSCF selection according to RFC 3361 [35A] or RFC 3319 [41]. The UE shall perform the procedure for the resolution of domain name according to RFC 3263 [27A]. If sufficient information for P-CSCF address selection is not available, selection of the P-CSCF address by the UE is implementation specific.

When:

– the UE obtains an IP-CAN bearer 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 as specified in subclause L.2.1.1. 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 EPS to EPC via WLAN.

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 EPS to EPC via WLAN.

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 EPS to EPC via WLAN. The UE can re-establish a new PDN connection to another IP-CAN type in idle mode, e.g. due to UE domain preference.

The UE may support the policy on when a UE is allowed to transfer a PDN connection providing access to IMS between EPC via WLAN and 5GS as specified in subclause U.2.1.1. If the UE is in a session and the policy indicates "is not allowed to transfer the PDN connection providing access to IMS between EPC via non-3GPP access and 5GCN via NG-RAN" or if the UE is roaming when in a session and the policy indicates "a UE roaming in a VPLMN and having an ongoing IMS session, is not allowed to transfer the PDN connection providing access to IMS between EPC via non-3GPP access and 5GCN via NG-RAN" the UE shall not handover the PDN connection providing access to IMS from 5GS to EPC via WLAN.

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

If the UE is in a 5GS IP-CAN and the policy indicates "a UE is not allowed to transfer a PDN connection providing access to IMS, if any, between EPC via non-3GPP access and 5GCN via NG-RAN, irrespective of if the UE has an ongoing IMS session or not" or the UE is roaming in a 5GS IP-CAN and the policy indicates "a UE roaming in a VPLMN is not allowed to transfer a PDN connection providing access to IMS, if any, between EPC via non-3GPP access and 5GCN via NG-RAN, irrespective of if the UE has an ongoing IMS session or not" the UE shall not handover the PDU session providing access to IMS from 5GS to EPC via WLAN.

R.2.2.1A Modification of an IP-CAN used for SIP signalling

Not applicable.

R.2.2.1B Re-establishment of the IP-CAN used for SIP signalling

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

i) the signalling from the network results in requiring the UE to initiate activation of the IP-CAN bearer for SIP signalling; or

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

and the UE is allowed to activate the IP-CAN bearer for SIP signalling, the UE shall:

A) if the non-access stratum is performing activation of the IP-CAN bearer for SIP signalling for the APN triggered as result of the signalling from the network, wait until the activation of the IP-CAN bearer for SIP signalling for the APN finishes;

B) if the non-access stratum is not performing activation of the IP-CAN bearer for SIP signalling for the APN, perform the procedures in subclause R.2.2.1, bullet a); and

C) if the IP-CAN bearer for SIP signalling is available:

– perform the procedures in subclause R.2.2.1, bullet b); and

– if a P-CSCF address was acquired, perform a new initial registration according to subclause 5.1.1.2.

R.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 IV for P-CSCF discovery, the UE has previously sent the "P-CSCF Re-selection support" PCO indicator (in trusted non-3GPP access network) or the P-CSCF_RESELECTION_SUPPORT IKEv2 attribute (in untrusted non-3GPP access network) during the PDN connection establishment, and the UE receives one or more P-CSCF address(es) during the TWAG initiated PDN connectivity modification procedure (in trusted non-3GPP access network) or the ePDG initiated modification (in untrusted non-3GPP access network), then the UE shall acquire a P-CSCF address from the one or more P-CSCF addresse(s). If more than one P-CSCF addresses of the same IP address type are included, then the UE shall assume that the more than one P-CSCF addresses of the same IP address type are prioritised with the first P-CSCF address within the Protocol Configuration Options information element or within the IKEv2 configuration payload as the P-CSCF address having the highest priority; and

B) if the UE uses RFC 6223 [143] as part of P-CSCF restoration procedures, and the P-CSCF fails to respond to keep-alive requests, then the UE shall acquire a different P-CSCF address using any of the methods described in the subclause R.2.2.1.

When the UE has acquired the P-CSCF address, the UE shall perform an initial registration as specified in subclause 5.1.

NOTE: For UEs using procedure A described above, the network ensures that P-CSCF address(es) received in the Protocol Configuration Options information element during TWAG initiated PDN connectivity modification procedure (in trusted non-3GPP access network), and P-CSCF address(es) received in the P-CSCF_IP6_ADDRESS attribute, the P-CSCF_IP4_ADDRESS attribute or both during ePDG initiated modification (in untrusted non-3GPP access network) are sent only during P-CSCF restoration procedures as defined in subclause 5 of 3GPP TS 23.380 [7D].

R.2.2.2 Void

R.2.2.3 IP-CAN support of DHCP based P-CSCF discovery

When using WLAN IP access via S2c to access the EPC, the Home Agent (HA) in case of Mobile IP with reverse tunneling, can forward the packet to one or more local DHCP servers, or relay the packet to a specific DHCP server. The HA in case of Mobile IP with reverse tunnelling, does not forward the DHCPINFORM (or Information-Request) to any UE.

NOTE 1: For forwarding the DHCPINFORM or Information-Request, the HA in case of Mobile IP with reverse tunnelling, does not change the destination IP address of the packet.

NOTE 2: For relaying the DHCPINFORM or Information-Request, the HA in case of Mobile IP with reverse tunnelling inserts a DHCP server’s IP address in the destination IP address field of the packet.

R.2.2.4 Void

R.2.2.5 Tunnel procedures for media

R.2.2.5.1 General requirements

The UE can establish media streams that belong to different SIP sessions on the same tunnel when accessing the EPC via untrusted WLAN.

During establishment of a session, the UE establishes data streams(s) for media related to the session. When using untrusted WLAN IP access via S2c to access the EPC, such data stream(s) may result in activation of additional IPsec ESP security associations (tunnels).

If the capabilities of the originating UE, or operator policy at the ePDG prevents the originating UE from establishment of additional IPsec ESP security associations (tunnels) according to the media grouping attributes given by the P-CSCF in accordance with RFC 3524 [54], the UE will not establish such grouping of media streams. Instead, the originating UE shall negotiate media parameters for the session according to RFC 3264 [27B].

If the capabilities of the terminating UE or operator policy at the ePDG prevents the originating UE from establishment of additional IPsec ESP security associations (tunnels) according to the media grouping attributes given by the P-CSCF in accordance with RFC 3524 [54], the UE will not establish such grouping of media streams. Instead, the terminating UE shall handle such SDP offers in accordance with RFC 3388 [53].

The UE can receive a media authorization token in the P-Media-Authorization header field from the P-CSCF according to RFC 3313 [31]. If a media authorization token is received in the P-Media-Authorization header field when a SIP session is initiated, the UE shall reuse the existing tunnel and ignore the media authorization token.

R.2.2.5.1A Modification of tunnel for media by the UE

The tunnel modification procedure for the UE shall follow the procedures specified in 3GPP TS 24.302 [8U]. If the UE supports the Fixed Access Broadband interworking, the modification of tunnel specified in 3GPP TS 24.139 [8X] shall be applied.

R.2.2.5.1B Modification of tunnel for media by the network

The UE shall follow the procedure specified in 3GPP TS 24.302 [8U] for the modification of tunnel. If the UE supports the Fixed Access Broadband interworking, the modification of tunnel specified in 3GPP TS 24.139 [8X] shall be applied.

If the UE attaches to the EPC via S2b using untrusted WLAN IP access, and IKEv2 multiple bearer PDN connectivity is used in the PDN connection according to 3GPP TS 24.302 [8U], then:

1) if:

A) an additional IPSec ESP tunnel is established according to 3GPP TS 24.302 [8U]; or

B) an IPSec ESP tunnel is modified according to 3GPP TS 24.302 [8U];

the UE shall, based on the information contained in the TFT Notify payload, correlate the media IPSec ESP tunnel with SDP media descriptions of a currently ongoing SIP session establishment or SIP session modification.

R.2.2.5.1C Deactivation of tunnel for media

Not applicable.

R.2.2.5.2 Special requirements applying to forked responses

Since the UE is unable to perform bearer modification, forked responses place no special requirements on the UE.

R.2.2.5.3 Unsuccessful situations

Not applicable.

R.2.2.6 Emergency service

R.2.2.6.1 General

In this release of the specification, a WLAN, conforming to the requirements in this annex, defines emergency bearers. Emergency session is supported over the WLAN access if the UE has failed or has not been able to use 3GPP access to set up an emergency session as described in 3GPP TS 23.167 [4B] annex J.

IMS emergency session is also supported for UEs with unavailable IMSI (i.e. a UE without USIM) or unauthenticated IMSI. 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.

When the UE is attached over a WLAN access and detects an emergency call attempt, if the UE supports the emerg-non3gpp timer defined in table 7.8.1, the UE shall start the emerg-non3gpp timer when starting a domain selection searching for a 3GPP access usable to establish an emergency call. The UE shall stop the timer when a 3GPP access supporting emergency call is found. When the emerg-non3gpp timer expires, the UE shall consider that it has failed to use 3GPP access to setup the emergency call and shall attempt to setup the emergency call over the available WLAN access.

The UE may support being configured for the emerg-non3gpp timer using one or more of the following methods:

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

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

c) the Timer_Emerg_non3gpp leaf of 3GPP TS 24.167 [8G].

EPC procedures for emergency session using WLAN are defined for both trusted WLAN access via S2a, depending on the TWAN usage mode, and untrusted WLAN access via S2b to access EPC.

When the IM CN subsystem is selected as the domain for the emergency call attempt, and the UE uses:

– untrusted WLAN access via S2b, the UE determines that the EPC supports emergency bearer services by selecting or using an ePDG that has indicated its capability of support for emergency services, as specified in subclause 7.2.1A of 3GPP TS 24.302 [8U]; or

– trusted WLAN access via S2a, the UE determines that the EPC, accessed in usage modes multi-connection mode or single-connection mode, supports emergency bearer services if the CONNECTION_MODE_CAPABILITY item in the EAP-Request/AKA’-Challenge message indicates support of emergency services, as specified in 3GPP TS 24.302 [8U].

When the IM CN subsystem is selected as the domain for the emergency call attempt, and the UE uses untrusted WLAN access via S2b, the UE determines whether it is currently attached to its home operator’s network (e.g. HPLMN) or not (e.g. VPLMN) after it has determined that the core network supports emergency bearer services.

When establishing an IMS emergency session using trusted WLAN access via S2a, the UE shall establish an IMS emergency session over trusted WLAN access depending on the usage mode used to access EPC. When using the usage mode single-connection mode, subclause 6.4.2.6.2A of 3GPP TS 24.302 [8U] applies. When using the usage mode multi-connection mode, subclause 6.4.2.6.3A of 3GPP TS 24.302 [8U] applies. The procedures for attaching to the EPC via S2a using a trusted WLAN IP access, as described in subclause R.2.2.1 of this specification apply accordingly.

When establishing an IMS emergency session using untrusted WLAN access via S2b, the UE shall establish an IMS emergency session over untrusted non-3GPP access as specified in 3GPP TS 24.302 [8U]. The procedures for attaching to the EPC via S2b using untrusted WLAN IP access, as described in subclause R.2.2.1 of this specification apply accordingly.

If the ME is equipped with a UICC, 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 purposes of emergency calls in the IM CN subsystem the UE shall consider to be attached to a VPLMN. If the ME is not equipped with a UICC, the procedure to find d out whether the UE is attached to the home PLMN or to the visited PLMN for the purpose of emergency calls in the IM CN subsystem, is implementation specific.

NOTE 1: The UE verifies if a detected emergency number is still present in the Extended Local Emergency Number List applicable to the PLMN it is currently using. 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 uses a different PLMN than the PLMN from which the UE received the last Extended Local Emergency Number List:

NOTE 2: The UE has either attached to or authenticated (e.g. due to EAP-3GPP-LimitedService based access authentication, see 3GPP TS 24.302 [8U]) with a PLMN via WLAN prior to detecting the emergency number or because of detecting the emergency number.

– the dialled number is not stored in the ME, in the USIM and in the Local Emergency Number List;

then:

a) if the UE supports provision and handling of local emergency numbers as defined in 3GPP TS 24.302 [8U], the UE has received the local emergency numbers using any of the methods defined in subclause 4.7 in 3GPP TS 24.302 [8U], the dialled number matches a received local emergency number, then the UE derives a URN as defined in 3GPP TS 24.302 [8U] or using the procedures in subclause R.2.2.6.1A, depending on the method used to provision the local emergency number;

b) otherwise, 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 R.2.2.6.1B or the procedures in subclause R.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 R.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 R.2.2.6.1A.

Once IPsec tunnel setup is completed, the UE shall follow the procedures described in subclause R.2.2.1 of this specification for establishment of IP-CAN bearer and P-CSCF discovery accordingly.

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

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, the UE shall proceed as follows:

1) if a 3GPP access network is available and the UE has not already attempted to use a 3GPP access network to set up an emergency session as described in 3GPP TS 23.167 [4B] annex J, when the UE selects a domain in accordance with the conventions and rules specified in 3GPP TS 22.101 [1A] and 3GPP TS 23.167 [4B], the UE shall attempt to select a domain of the 3GPP access network, and:

– if the CS domain is selected, the UE behaviour is defined in subclause 7.1.2 of 3GPP TS 23.167 [4B] and in annex B, annex L or annex U; and

– if the IM CN subsystem is selected, the UE shall apply the procedures in subclause 5.1.6 with the exception of selecting a domain for the emergency call attempt;

In addition, when the UE determines that "it has not been able to use 3GPP access to set up an emergency session" in accordance with subclause J.1 of 3GPP TS 23.167 [4B], the UE shall apply the procedures in subclause 5.1.6 using WLAN, with the exception of selecting a domain for the emergency call attempt; and

2) if a 3GPP access network is not available, then the UE shall apply the procedures in subclause 5.1.6 using WLAN, with the exception of selecting a domain for the emergency call attempt.

When the emergency session ends, the UE:

1) shall release the tunnel as described in 3GPP TS 24.302 [8U]; and

2) if EPC via WLAN is the preferred IP-CAN to access IM CN subsystem or if no 3GPP access is available:

a) if the UE did not select the currently selected ePDG using procedures for selection of ePDG for non-emergency services, shall select an ePDG for non-emergency services as described in 3GPP TS 24.302 [8U];

b) if the UE does not have an IP-CAN bearer for non-emergency SIP signalling, shall follow the procedures described in subclause R.2.2.1 for establishment of an IP-CAN bearer for SIP signalling and P-CSCF discovery; and

c) if the UE determines that its contact associated with the IP-CAN bearer for non-emergency SIP signalling is not bound to a public user identity, shall perform an initial registration as specified in subclause 5.1.1.2 using the IP-CAN bearer for SIP signalling.

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

– the UE considers itself in the country of the HPLMN;

NOTE 2: It is out of scope of the present annex to define how the UE determines whether it considered itself in the country of the HPLMN. When the UE is in coverage of a 3GPP RAT, it can, for example, use the information derived from the available PLMN(s). In this case, the UE can match the MCC broadcasted on the BCCH of the 3GPP access against the UE’s IMSI to determine if they belong to the same country, as defined in 3GPP TS 23.122 [4C]. If the UE is not in coverage of a 3GPP RAT, the UE can use other techniques, including user-provided location, for determining whether it is located in its home country or not.

– multiple types of emergency services can be derived for a dialled number from the information configured on the USIM; and

– no IP-CAN provided a local emergency number that matches the dialled number (see subclause 5.1.6.1);

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

NOTE 4: A UE, only connected to a PLMN through non-3GPP access, considers the WLAN provided local emergency numbers if the applicable conditions in subclause 4.7 of 3GPP TS 24.302 [8U], are met.

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

If the UE considers itself in the country of the HPLMN and an 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

– derives 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 R.2.2.6.1.

NOTE 5: 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 an IP-CAN, is implementation dependent.

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

R.2.2.6.2 eCall type of emergency service

The UE shall not send an INVITE request with Request-URI set to "urn:service:sos.ecall.manual" or "urn:service:sos.ecall.automatic".

R.2.2.6.3 Current location discovery during an emergency call

The UE may support the current location discovery during an emergency call specified in subclause 5.1.6.8.2, subclause 5.1.6.8.3, subclause 5.1.6.8.4, and subclause 5.1.6.12.