B.2 GPRS 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

B.2.1 Introduction

A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by the core network 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 core network in support of this communication are specified in 3GPP TS 29.061 [11], 3GPP TS 29.207 [12] and 3GPP TS 29.212 [13B].

When using the GPRS IP-CAN, each IP-CAN bearer is provided by a PDP context.

B.2.2 Procedures at the UE

B.2.2.1 PDP context activation and P-CSCF discovery

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

a) if not attached for GPRS services yet, perform a GPRS attach procedure as specified in 3GPP TS 24.008 [8];

b) ensure that a PDP context used for SIP signalling according to the APN and GGSN or P-GW selection criteria described in 3GPP TS 23.060 [4] and 3GPP TS 27.060 [10A] is available. This PDP 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 PDP context provides the UE with information that makes the UE able to construct an IPv4 or an IPv6 address;

NOTE 1: During the PDP context activation procedure, the UE and the core network negotiate whether the UE or the GPRS IP-CAN is responsible for the resource reservation applicable to all PDP contexts within the activated PDP address/APN pair, as described in 3GPP TS 24.008 [8].

When the bearer establishment is controlled by the UE, the UE shall choose one of the following options when performing establishment of this PDP context:

I. A dedicated PDP context for SIP signalling:

The UE shall indicate to the core network that this is a PDP context intended to carry IM CN subsystem-related signalling only by setting the IM CN Subsystem Signalling Flag. The UE may also use this PDP context for DNS and DHCP signalling according to the static packet filters as described in 3GPP TS 29.061 [11]. The UE can also set the Signalling Indication attribute within the QoS information element;

II. A general-purpose PDP context:

The UE may decide to use a general-purpose PDP Context to carry IM CN subsystem-related signalling. The UE shall indicate to the core network that this is a general-purpose PDP context by not setting the IM CN Subsystem Signalling Flag. The UE may carry both signalling and media on the general-purpose PDP context. The UE can also set the Signalling Indication attribute within the QoS information element.

NOTE 2: When the bearer establishment is controlled by the GPRS IP-CAN, the core network follows the procedures described in 3GPP TS 29.061 [11] in order to establish a dedicated PDP context for SIP signalling.

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 PDP context activation procedure.

The UE indicates the IM CN Subsystem Signalling Flag within the Protocol Configuration Options information element of the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP CONTEXT REQUEST message. Upon successful signalling PDP context establishment the UE receives an indication in the form of IM CN Subsystem Signalling Flag within the Protocol Configuration Options information element. If the flag is not received, the UE shall consider the PDP context as a general-purpose PDP context.

The encoding of the IM CN Subsystem Signalling Flag within the Protocol Configuration Options information element is described in 3GPP TS 24.008 [8].

The UE can indicate a request for prioritised handling over the radio interface by setting the Signalling Indication attribute (see 3GPP TS 23.107 [4A]). The general QoS negotiation mechanism and the encoding of the Signalling Indication attribute within the QoS information element are described in 3GPP TS 24.008 [8]; and

NOTE 3: A general-purpose PDP Context 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 Service Based Local Policy mechanisms defined in 3GPP TS 29.207 [12] and the media stream is not mandated by the P-CSCF to be carried in a separate PDP Context.

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 PDP context activation procedure.

The UE shall indicate the request for a P-CSCF address within the Protocol Configuration Options information element of the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP CONTEXT REQUEST message.

If the UE is provided with a list of P-CSCF IPv4 or IPv6 addresses in the ACTIVATE PDP CONTEXT ACCEPT message or ACTIVATE SECONDARY PDP CONTEXT ACCEPT 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 the UE should:

– release IP-CAN bearer that is used only for the transport of SIP signalling and that are not used for other non-IMS applications, except emergency IP-CAN bearers;

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

– perform the procedures for initial registration as described in subclause 5.1.1.2.

NOTE 5: The UE may not be able to release the IP-CAN bearer if the IP-CAN bearer is in use by other applications.

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 PDP context according to 3GPP TS 27.060 [10A].

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 PDP context according to 3GPP TS 27.060 [10A].

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.008 [8].

When:

– the UE obtains a PDP context used for SIP signalling by performing handover of the connection from another IP-CAN;

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

B.2.2.1A Modification of a PDP context used for SIP signalling

The PDP context shall not be modified from a dedicated PDP context for SIP signalling to a general-purpose PDP context or vice versa. The IM CN Subsystem Signalling Flag shall not be set in the Protocol Configuration Options information element of the MODIFY PDP CONTEXT REQUEST message.

The UE shall not indicate the request for a P-CSCF address within the Protocol Configuration Options information element of the MODIFY PDP CONTEXT REQUEST message. The UE shall ignore P-CSCF address(es) if received in the Protocol Configuration Options information element of the MODIFY PDP CONTEXT RESPONSE message.

B.2.2.1B Re-establishment of the PDP context for SIP signalling

If the UE registered a public user identity with an IP address allocated for the APN of the PDP context used for SIP signalling, the PDP context used for SIP signalling is deactivated as result of signalling from the core network (e.g. no longer available as a result of a successful GPRS routeing area update procedure) and:

i) if the signalling from the core network results in requiring the UE to initiate activation of the PDP context used for SIP signalling; or

ii) if 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 send:

– ACTIVATE PDP CONTEXT REQUEST message; or

– ACTIVATE SECONDARY PDP CONTEXT REQUEST message,

to activate the PDP context for SIP signalling, the UE shall:

A) if the non-access stratum is performing the PDP context activation procedure for the APN triggered as result of the signalling from the core network, wait until the PDP context activation procedure for the APN finishes; and

B) perform the procedures in subclause B.2.2.1, bullets a), b) and c).

If:

– none of the bullets i) and ii) of this subclause evaluate to true;

– the UE is not allowed to send the ACTIVATE (SECONDARY) PDP CONTEXT REQUEST message;

– the procedures in bullet B) of this subclause were unable to ensure that the PDP context used for SIP signalling is available; or

– the procedures in bullet B) of this subclause were unable to acquire any P-CSCF address(es);

and if the PDP context used for SIP signalling was a dedicated PDP context for SIP signalling as described in subclause B.2.2.1, the UE shall deactivate all PDP contexts established as a result of SIP signalling according to the 3GPP TS 24.008 [8].

NOTE: 3GPP TS 24.008 [8] specifies conditions that prevent the UE from sending an ACTIVATE (SECONDARY) PDP CONTEXT REQUEST message.

If all PDP contexts for the APN were deactivated at the start of this subclause and the procedures in bullet B) of this subclause ensured that the PDP 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.

B.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 PDP CONTEXT REQUEST message and 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 PDP 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 PDP Context Activation and if the UE receives one or more P-CSCF address(es) in the Protocol Configuration Options information element of a MODIFY PDP CONTEXT REQUEST message, then the UE shall acquire a P-CSCF address from the one or more P-CSCF addresse(s) in the MODIFY PDP 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 B.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 PDP CONTEXT REQUEST 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.

B.2.2.2 Session management procedures

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

B.2.2.3 Mobility management procedures

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

B.2.2.4 Cell selection and lack of coverage

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

B.2.2.5 PDP contexts for media

B.2.2.5.1 General requirements

The UE can establish media streams that belong to different SIP sessions on the same PDP context.

During establishment of a session, the UE establishes data streams(s) for media related to the session. Such data stream(s) may result in activation of additional PDP context(s). Such additional PDP context(s) shall be established as secondary PDP contexts associated to the PDP context used for signalling. Such secondary PDP contexts for media can be established either by the UE or the core network.

If the bearer establishment is controlled by the UE, the UE starts reserving its local resources whenever it has sufficient information about the media streams, media authorization and used codecs available as specified in 3GPP TS 24.008 [8].

NOTE 1: If the bearer establishment is controlled by the GPRS IP-CAN, the resource reservation requests are initiated by the core 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].

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

B.2.2.5.1A Activation or modification of PDP 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] and both UE and the core network are allowed to establish the secondary PDP contents, then the UE shall refrain from establishing the secondary PDP context(s) for media and from modifying existing PDP contexts for media until the UE considers that the network did not initiate resource allocation for the media.

If the UE receives indication within the SDP according to RFC 3524 [54] that media stream(s) belong to group(s), the media stream(s) shall be set up on separate PDP contexts according to the indication of grouping of media streams. The UE may freely group media streams to PDP context(s) in case no indication of grouping of media streams is received from the P-CSCF.

If the capabilities of the originating UE prevents it from establishment of additional PDP contexts 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 prevents it from establishment of additional PDP contexts 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 the 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:

– either use existing PDP context(s) where another media authorization token is already in use and no indication of grouping of media streams is required; or

– establish separate PDP context(s) for the media; or

– use an existing PDP context where media authorization token is not in use and no indication of grouping of media streams is required.

When a UE modifies a PDP context to indicate a new media authorization token:

– either as a result of establishment of an additional SIP session; or

– modification of media streams for an ongoing SIP session;

the UE shall include all media authorization tokens and all flow identifiers for all ongoing SIP sessions that use this particular PDP context.

If a media authorization token is received in subsequent messages for the same SIP session, the UE shall:

– use the existing PDP context(s) for media;

– modify the existing PDP context(s) for media; or

– establish additional PDP context(s) for media.

If either background or interactive QoS class is needed for the media, then the UE does not need to use the authorization token even if it receives one. In this case the UE may reuse an existing PDP context and it does not need to request PDP context modification unless it needs to modify the QoS.

If existing PDP context(s) where another media authorization token is already in use is re-used for the media, or separate PDP context(s) is established for the media, the UE shall proceed as follows:

– when a SIP session is terminated, the media authorization token is no longer valid and the UE shall not include it in future GPRS session management messages. The UE shall send a MODIFY PDP CONTEXT REQUEST message updating the binding information by deleting the media authorization token and the corresponding flow identifiers that are no longer valid. If a SIP session is terminated and no other SIP sessions are using the PDP context, the UE shall either update the binding information as described above or deactivate the PDP context;

– the UE shall transparently pass the media authorization token received from the P-CSCF in a response to an INVITE request at originating setup or in the INVITE request at terminating setup to the core network. The UE shall signal it by inserting it within the Traffic Flow Template information element in the ACTIVATE SECONDARY PDP CONTEXT REQUEST message or the MODIFY PDP CONTEXT REQUEST message;

– to identify to the core network which flow(s) (identified by m-lines within the SDP) that are transferred within a particular PDP context, the UE shall set the flow identifier(s) within the Traffic Flow Template information element in the ACTIVATE SECONDARY PDP CONTEXT REQUEST message or the MODIFY PDP CONTEXT REQUEST message. Detailed description of how the flow identifiers are constructed is provided in 3GPP TS 29.207 [12];

– if the UE receives several media authorization tokens from the P-CSCF within the same SIP request or response, the first instance of the media authorization token shall be sent to the core network, and subsequent instances are discarded by the UE; and

– the UE shall not include the IM CN Subsystem Signalling Flag when a PDP context for media is established or modified.

The encoding of the media authorization token and the flow identifiers within the Traffic Flow Template information element is described in 3GPP TS 24.008 [8].

B.2.2.5.1B Activation or modification of PDP contexts for media by the core network

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

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

1) modify the related PDP context in accordance with the received modification request.

B.2.2.5.1C Deactivation of PDP context for media

When a data stream for media related to a session is released, if the PDP context transporting the data stream is no longer needed and if the PDP context has been activated by the UE, then the UE deactivates the PDP context.

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

B.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 core 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 sets up the PDP context(s) 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 PDP context(s). The UE performs no activation or modification of PDP contexts.

2) the subsequent SDP introduces different QoS requirements or additional IP flows. The UE modifies the existing PDP context(s), if necessary, according to subclause B.2.2.5.1A.

3) the subsequent SDP introduces one or more additional IP flows. The UE establishes additional PDP context(s) according to subclause B.2.2.5.1A.

NOTE 2: When several forked responses are received, the resources requested by the UE is 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.

NOTE 3: When service-based local policy is applied, the UE receives the same authorization token for all forked requests/responses related to the same SIP session.

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 radio/bearer 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 PDP context(s) 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, delete the PDP context(s) or modify the delete the PDP context(s) back to their original state.

B.2.2.5.3 Unsuccessful situations

One of the Go, Gq, Rx and Gx interface related error codes can be received by the UE in the ACTIVATE SECONDARY PDP CONTEXT REJECT message or the MODIFY PDP CONTEXT REJECT message. If the UE receives a Go, Gq, 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 Go, Gq, Rx and Gx interface related error codes are further specified in 3GPP TS 29.207 [12], 3GPP TS 29.209 [13A], 3GPP TS 29.214 [13D] and 3GPP TS 29.212 [13B].

B.2.2.6 Emergency service

B.2.2.6.1 General

Emergency bearers are defined for use in emergency calls in GPRS IP-CAN 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 bearers for both signalling and media on 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 GMM-REGISTERED.LIMITED-SERVICE and GMM-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 25.331 [9A]), the procedures for emergency calls without registration can be applied, as defined in subclause 5.1.6.8.2. If the GPRS 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 GPRS authentication procedure has succeeded during the emergency ATTACH procedure when an integrity protection algorithm is received in the RRC signalling SECURITY MODE COMMAND message (see 3GPP TS 25.331 [9A]).

When activating a PDP context to perform emergency registration, the UE shall request a PDP context for emergency bearer services as defined in 3GPP TS 24.008 [8]. The procedures for PDP context activation and P-CSCF discovery, as described in subclause B.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 donot 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.

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 a number as for an emergency call and performs the procedures in subclause B.2.2.6.1A.

NOTE 3: The Extended Local Emergency Numbers List (see 3GPP TS 24.301 [8J]) does not apply in this IP-CAN.

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 B.2.2.6.1, then the type of emergency service is the value corresponding to the matching entry in table B.2.2.6.1; and

2) if the URN in the Contact header field does not match any emergency service URN in table B.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 PDP context for emergency bearer services as defined in 3GPP TS 24.008 [8].

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.

B.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 B.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 B.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 B.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 B.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 core network, is implementation dependent.

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

Void

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

B.2.2.6.3 Current location discovery during an emergency call

Void.