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

W.2.1 Introduction

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

W.2.2 Procedures at the UE

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

NOTE: The UE performs access network discovery and selection procedures as specified in 3GPP TS 24.502 [263] and executes access authentication signalling as described in 3GPP TS 24.502 [263] prior to perform the procedure to obtain a local IP address;

The UE handles an IP-CAN bearer for SIP signalling as follows:

1) the UE shall obtain a local IP address;

2) the UE shall establish an IKEv2 security association and an IPsec ESP security association as described in 3GPP TS 24.502 [263]; and

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

In addition the procedures specified in Annex U.2.2.1 apply

The UE may support the policy on when a UE is allowed to transfer a PDU session providing access to IMS between 5GC via non-3GPP access and 5GS as specified in subclause U.2.1.1. If the UE is in a session and the policy indicates "a UE having an ongoing IMS session, is not allowed to transfer the PDU session providing access to IMS between 5GCN 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 PDU session providing access to IMS between 5GCN via non-3GPP access and 5GCN via NG-RAN" the UE shall not handover the PDU session providing access to IMS from 5GC via non-3GPP access to 5GS.

If the UE is in a seesion in the EPS IP-CAN and the policy indicates "a UE is not allowed to transfer a PDU session providing access to IMS, if any, between 5GCN 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 PDU session providing access to IMS between 5GCN via non-3GPP access and 5GCN via NG-RAN" the UE shall, if not prevented by other rules or policies, handover the PDU session providing access to IMS from 5GC via non-3GPP access to 5GS.

If the UE is in a 5GS IP-CAN and the policy indicates "a UE is not allowed to transfer a PDU session providing access to IMS, if any, between 5GCN 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 PDU session providing access to IMS, if any, between 5GCN 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 5GC via non-3GPP access to 5GS.

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

The procedures specified in Annex U.2.2.1A apply.

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

The procedures specified in Annex U.2.2.1B apply.

W.2.2.1C P-CSCF restoration procedure

The procedures specified in Annex U.2.2.1C apply.

W.2.2.2 Session management procedures

The procedures specified in Annex U.2.2.2 apply.

W.2.2.3 Mobility management procedures

The procedures specified in Annex U.2.2.3 apply.

W.2.2.4 Cell selection and lack of coverage

Not applicable.

W.2.2.5 5GS QoS flow for media

W.2.2.5.1 General requirements

NOTE 1: During establishment of a session, the UE establishes data streams(s) for media related to the session. Either the UE or the network can request for resource allocations for media, but the establishment and modification of the 5GS QoS flow is controlled by the network as described in 3GPP TS 24.501 [258].

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.501 [258] and 3GPP TS 24.502 [263].

NOTE 2: If the resource reservation requests are initiated by the network, then the establishment of 5GS QoS flow for media is initiated by the network after the P-CSCF has authorised the respective 5GS QoS flows and provided the QoS requirements to the PCF.

W.2.2.5.1A Activation or modification of QoS flows 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 5GS QoS flow(s) for media until the UE considers that the network did not initiate resource allocation for the media.

W.2.2.5.1B Activation or modification of QoS flows for media by the network

If the UE receives an activation request from the network for a 5GS QoS flow for media which is associated with the 5GS QoS flow used for signalling, the UE shall correlate the media 5GS QoS flow with a currently ongoing SIP session establishment or SIP session modification.

If the UE receives a modification request from the network for a 5GS QoS flow that is used for one or more media streams in an ongoing SIP session, the UE shall:

1) modify the related PDU session context in accordance with the request received from the network.

W.2.2.5.1C Deactivation of a QoS flow for media

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

NOTE: The 5GS QoS flow can be needed e.g. for other data streams of a session or for other applications in the UE.

W.2.2.5.2 Special requirements applying to forked responses

The procedures specified in Annex U.2.2.5.2 apply.

W.2.2.5.3 Unsuccessful situations

Not applicable.

W.2.2.6 Emergency service

W.2.2.6.1 General

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

The UE determines that the 5GCN supports emergency services via WLAN when the Emergency service support for non-3GPP (EMCN3) access indicator in the REGISTRATION ACCEPT message indicates emergency services are supported over non-3GPP access as defined in subclause 9.11.3.5 of 3GPP TS 24.501 [258].

When the UE is registered over a WLAN access and detects an emergency call attempt, if the UE supports the emerg-non3gpp timer defined in table 7.8.1 and has determined that 5GCN supports emergency services via WLAN 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].

When the IM CN subsystem is selected as the domain for the emergency call attempt, 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 5GCN supports emergency services via WLAN.

To perform emergency registration, the UE shall request to establish an emergency PDU session as described in 3GPP TS 24.501 [258]. The procedures for PDU session establishment and P-CSCF discovery, as described in subclause W.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: 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, the dialled number is not stored in the ME, in the USIM and in the Local Emergency Number List, and:

– the REGISTRATION 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 W.2.2.6.1B; and

– the REGISTRATION 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 W.2.2.6.1B or the procedures in subclause W.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 W.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 W.2.2.6.1A.

Once IPsec tunnel setup is completed, the UE shall follow the procedures described in subclause W.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 L, 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; 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 L.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 registration expires, the UE should disconnect the emergency PDU session.

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

Annex U.2.2.6.1A applies.

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

Annex U.2.2.6.1B applies.

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

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