5.16 Support for specific services

23.5013GPPRelease 18System architecture for the 5G System (5GS)TS

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

5.16.1 Public Warning System

The functional description for supporting Public Warning System for 5G System can be found in TS 23.041 [46].

5.16.2 SMS over NAS

5.16.2.1 General

This clause includes feature description for supporting SMS over NAS in 5G System. Support for SMS incurs the following functionality:

– Support for SMS over NAS transport between UE and AMF. This applies to both 3GPP and Non 3GPP accesses.

– Support for AMF determining the SMSF for a given UE.

– Support for subscription checking and actual transmission of MO/MT-SMS transfer by the SMSF.

– Support for MO/MT-SMS transmission for both roaming and non-roaming scenarios.

– Support for selecting proper domains for MT SMS message delivery including initial delivery and re-attempting in other domains.

5.16.2.2 SMS over NAS transport

5G System supports SMS over NAS via both 3GPP access and non-3GPP access.

During Registration procedure, a UE that wants to use SMS provides an "SMS supported" indication over NAS signalling indicating the UE’s capability for SMS over NAS transport. "SMS supported" indication indicates whether UE can support SMS delivery over NAS. If the core network supports SMS functionality, the AMF includes "SMS allowed" indication to the UE, and whether SMS delivery over NAS is accepted by the network.

SMS is transported via NAS transport message, which can carry SMS messages as payload.

5.16.3 IMS support

5.16.3.1 General

IP-Connectivity Access Network specific concepts when using 5GS to access IMS can be found in TS 23.228 [15].

5GS supports IMS with the following functionality:

– Indication toward the UE if IMS voice over PS session is supported.

– Capability to transport the P-CSCF address(es) to UE.

– Paging Policy Differentiation for IMS as defined in TS 23.228 [15].

– IMS emergency service as defined in TS 23.167 [18].

– Domain selection for UE originating sessions.

– Terminating domain selection for IMS voice.

– Support of P-CSCF restoration procedure (clause 5.16.3.9).

– NRF based P-CSCF discovery (clause 5.16.3.11).

NOTE: The NRF based P-CSCF discovery has no impact on the UE, i.e. the UE does not need to know how P-CSCF IP address(es) is discovered in the network.

– NRF based HSS discovery (clause 5.16.3.12).

5.16.3.2 IMS voice over PS Session Supported Indication over 3GPP access

The serving PLMN AMF shall send an indication toward the UE during the Registration procedure over 3GPP access to indicate if an IMS voice over PS session is supported or not supported in 3GPP access and non-3GPP access. A UE with "IMS voice over PS" voice capability over 3GPP access should take this indication into account when performing voice domain selection, as described in clause 5.16.3.5.

The serving PLMN AMF may only indicate IMS voice over PS session supported over 3GPP access in one of the following cases:

– If the network and the UE are able to support IMS voice over PS session in the current Registration Area with a 5G QoS Flow that supports voice as specified in clause 5.7.

– If the network or the UE are not able to support IMS voice over PS session over NR connected to 5GC, but is able for one of the following:

– If the network and the UE are able to support IMS voice over PS session over E-UTRA connected to 5GC, and the NG-RAN supports a handover or redirection to E-UTRA connected to 5GC for this UE at QoS Flow establishment for IMS voice;

– If the UE supports handover to EPS, the EPS supports IMS voice, and the NG-RAN supports a handover to EPS for this UE at QoS Flow establishment for IMS voice; or

– If the UE supports redirection to EPS, the EPS supports IMS voice, and the NG-RAN supports redirection to EPS for this UE at QoS Flow establishment for IMS voice.

– If the network is not able to provide a successful IMS voice over PS session over E-UTRA connected to 5GC, but is able for one of the following:

– If the UE supports handover to EPS, the EPS supports IMS voice, and the NG-RAN supports a handover to EPS for this UE at QoS Flow establishment for IMS voice; or

– If the UE supports redirection to EPS, the EPS supports IMS voice, and the NG-RAN supports redirection to EPS for this UE at QoS Flow establishment for IMS voice.

The serving PLMN provides this indication based e.g. on local policy, UE capabilities, HPLMN, whether IP address preservation is possible, whether NG-RAN to UTRAN SRVCC is supported and how extended NG-RAN coverage is, and the Voice Support Match Indicator from the NG-RAN (see clause 4.2.8a of TS 23.502 [3]).

NOTE 1: The terms "UE supports handover to EPS" or "UE supports redirection to EPS" used above also consider the case that the UE has signalled that S1 mode is enabled. In case the UE has signalled that S1 mode is disabled for a network that only supports IMS voice via EPS Fallback, the AMF will not indicate that IMS voice over PS session is supported over 3GPP access. A voice centric UE ensures its voice service as described in clauses 5.16.3.5 and 5.16.3.6.

The AMF in serving PLMN shall indicate that IMS voice over PS is supported only if the serving PLMN has a roaming agreement that covers support of IMS voice with the HPLMN. This indication is per Registration Area.

NOTE 2: If the network supports EPS fallback for voice the 5GC can be configured not to perform the Voice Support Match Indicator procedure in order to set the IMS voice over PS session Supported Indication.

The serving SNPN provides the IMS voice over PS indication based e.g. on local policy, UE capabilities, whether IP address preservation is possible, and how extended NR coverage is. This indication is per Registration Area.

NOTE 3: Since in SNPN access mode there is only support for NR and the "voice centric" UE cannot reselect to another RAT in the same registered SNPN if the first Registration Area that the UE tries to register from cannot support IMS voice, it is recommended that support for IMS voice is provided homogeneously in the whole SNPN if at all.

5.16.3.2a IMS voice over PS Session Supported Indication over non-3GPP access

The serving PLMN AMF shall send an indication toward the UE during the Registration procedure over non-3GPP access to indicate whether an IMS voice over PS session is supported or not supported via non-3GPP access. A UE with "IMS voice over PS" voice capability over non-3GPP access should take this indication (received in the Registration procedure performed over either 3GPP access or Non-3GPP access) into account when performing the selection between N3IWF/TNGF and ePDG described in clause 6.3.6.

The serving PLMN AMF may only indicate IMS voice over PS session supported over non-3GPP access if the network is able to provide a successful IMS voice over PS session over N3IWF/TNGF connected to 5GC with a 5G QoS Flow that supports voice as specified in clause 5.7.

5.16.3.3 Homogeneous support for IMS voice over PS Session supported indication

5GC shall support the usage of "Homogeneous Support of IMS Voice over PS Sessions" indication between AMF and UDM.

When the AMF initiates Nudm_UECM_Registration operation to the UDM, it shall:

– if "IMS Voice over PS Sessions" is supported homogeneously in all TAs in the serving AMF for the UE, include the "Homogeneous Support of IMS Voice over PS Sessions" indication set to "Supported";

– if none of the TAs of the serving AMF supports "IMS Voice over PS Sessions" for the UE, include the "Homogeneous Support of IMS Voice over PS Sessions" indication set to "Not supported";

– if "IMS Voice over PS Sessions" support is either non-homogeneous or unknown, not include the "Homogeneous Support of IMS Voice over PS Sessions" indication.

The AMF shall be able to provide the "Homogeneous Support of IMS Voice over PS Sessions" indication as described above to the UDM using Nudm_UECM_Update operation as specified in clause 4.2.2.2.2 of TS 23.502 [3].

The UDM shall take this indication into account when doing Terminating Access Domain Selection (T-ADS) procedure for IMS voice.

NOTE: A TA supports "IMS Voice over PS Sessions" if the serving AMF indicates IMS voice over PS Session Supported Indication over 3GPP access to the UE, as described in clause 5.16.3.2. In order to support routing of incoming IMS voice calls to the correct domain, the network-based T-ADS (see TS 23.292 [63] and TS 23.221 [23]) requires that the "Homogeneous Support of IMS Voice over PS Sessions" indication is set to "Supported" for all registered TAs of the UE or "Not supported" for all registered TAs of the UE.

5.16.3.4 P-CSCF address delivery

At PDU Session Establishment procedure related to IMS, SMF shall support the capability to send the P-CSCF address(es) to UE. The SMF is located in VPLMN if LBO is used. This is sent by visited SMF if LBO is used. For Home routed, this information is sent by the SMF in HPLMN. P-CSCF address(es) shall be sent transparently through AMF, and in the case of Home Routed also through the SMF in VPLMN. The P-CSCF IP address(es) may be locally configured in the SMF, or discovered using NRF as described in clause 5.16.3.11.

NOTE 1: Other options to provide P-CSCF to the UE as defined in TS 23.228 [15] is not excluded.

NOTE 2: PDU Session for IMS is identified by "APN" or "DNN".

In the case of SNPN access the SMF is always located in the serving SNPN (no support for Home Routed traffic); therefore, the serving SMF sends the P-CSCF address(es) to the UE.

5.16.3.5 Domain selection for UE originating sessions / calls

For UE originating calls, the 5GC capable UE performs access domain selection. The UE shall be able to take following factors into account for access domain selection decision:

– The state of the UE in the IMS. The state information shall include: Registered, Unregistered.

– The "IMS voice over PS session supported indication" as defined in clause 5.16.3.2.

– Whether the UE is expected to behave in a "voice centric" or "data centric" way for 5GS.

– UE capability of supporting IMS PS voice.

– UE capability for operating in dual-registration mode with selective PDU Session transfer as defined in clause 5.17.2.3.3.

– Whether 3GPP PS Data Off is active or not and whether IMS voice is included in 3GPP PS Data Off Exempt Services or not as defined in clause 5.24.

NOTE 1: In this release of the specification, the exact logic of which PDU sessions are kept in which system for Dual Registration UE with selective transfer of certain PDU Sessions as defined in clause 5.17.2.3.3, is left up to UE implementation. The voice centric UE will keep the PDU Session used for IMS services to a system that supports voice over IMS. The voice centric UE can re-register with the IMS (if needed) when the IMS PDU session is transferred between 5GS and EPS.

To allow for appropriate domain selection for originating voice calls, the UE shall attempt Initial Registration in 5GC. If the UE fails to use IMS for voice, e.g. due to "IMS voice over PS session supported indication" indicates voice is not supported in 5G System, the UE behaves as described below for "voice centric" for 5GS or "data centric" for 5GS:

– A UE set to "voice centric" for 5GS shall always try to ensure that Voice service is possible. A voice centric 5GC capable and EPC capable UE unable to obtain voice service in 5GS shall not select a cell connected only to 5GC. By disabling capabilities to access 5GS, the UE re-selects to E‑UTRAN connected to EPC first (if available). When the UE selects E-UTRAN connected to EPC, the UE performs Voice Domain Selection procedures as defined in TS 23.221 [23].

– A UE set to "data centric" for 5GS does not need to perform any reselection if voice services cannot be obtained.

NOTE 2: The related radio capabilities in order for the voice centric UE to not reselect to NR or E-UTRA cell connected to 5GC (i.e. avoid ping pong) will be defined by RAN WGs.

5.16.3.6 Terminating domain selection for IMS voice

When requested by IMS, the UDM/HSS shall be able to query the serving AMF for T-ADS related information. T-ADS is a functionality located in the IMS and is performed as specified in TS 23.221 [23].

The AMF shall respond to the query with the following information unless the UE is detached:

– whether or not IMS voice over PS Session is supported in the registration area (s) where the UE is currently registered;

– whether or not IMS voice over PS Session Supported Indication over non-3GPP access is supported in the WLAN where the UE is currently registered;

– the time of the last radio contact with the UE; and

– the current Access Type and RAT type.

5.16.3.7 UE’s usage setting

If the UE is configured to support IMS voice, the UE shall include the information element "UE’s usage setting" in Registration Request messages. The UE’s usage setting indicates whether the UE behaves in a "voice centric" or "data centric" way (as defined in clause 5.16.3.5).

A UE supporting IMS voice over 3GPP access connected to 5GC and that is EPS capable shall also support IMS voice over E-UTRA connected to EPC.

NOTE: Depending on operator’s configuration, the UE’s usage setting can be used by the network to choose the RFSP Index in use (see clause 5.3.4.3). As an example, this enables the enforcement of selective idle mode camping over E-UTRA for voice centric UEs.

5.16.3.8 Domain and Access Selection for UE originating SMS

5.16.3.8.1 UE originating SMS for IMS Capable UEs supporting SMS over IP

To allow for appropriate domain selection for SMS delivery, it should be possible to provision UEs with the following HPLMN operator preferences on how an IMS enabled UE is supposed to handle SMS services:

– SMS is not to be invoked over IP networks: the UE does not attempt to deliver SMS over IP networks. The UE attempts to deliver SMS over NAS signalling.

– SMS is preferred to be invoked over IP networks: the UE attempts to deliver SMS over IP networks. If delivery of SMS over IP networks is not available, the UE attempts to deliver SMS over NAS signalling.

5.16.3.8.2 Access Selection for SMS over NAS

It should be possible to provision UEs with the HPLMN SMS over NAS operator preferences on access selection for delivering SMS over NAS signalling.

Based on the SMS over NAS preference:

– SMS is preferred to be invoked over 3GPP access for NAS transport: the UE attempts to deliver MO SMS over NAS via 3GPP access if the UE is both registered in 3GPP access and non-3GPP access.

– SMS is preferred to be invoked over non-3GPP access for NAS transport: the UE attempts to deliver MO SMS over NAS via non-3GPP access if the UE is both registered in 3GPP access and non-3GPP access. If delivery of SMS over NAS via non-3GPP access is not available, the UE attempts to deliver SMS over NAS via 3GPP access.

5.16.3.9 SMF support for P-CSCF restoration procedure

For the support of P-CSCF restoration the SMF behaves as described in TS 23.380 [61].

5.16.3.10 IMS Voice Service via EPS Fallback or RAT fallback in 5GS

In order to support various deployment scenarios for obtaining IMS voice service, the UE and NG-RAN may support the mechanism to direct or redirect the UE from NG-RAN either towards E-UTRA connected to 5GC (RAT fallback) or towards EPS (E-UTRAN connected to EPC System fallback).

Following principles apply for IMS Voice Service:

– The serving AMF indicates toward the UE during the Registration procedure that IMS voice over PS session is supported.

– If a request for establishing the QoS Flow for IMS voice reaches the NG-RAN, the NG-RAN responds indicating rejection of the establishment request and the NG-RAN may trigger one of the following procedures depending on UE capabilities, N26 availability, network configuration and radio conditions:

– Redirection to EPS;

– Handover procedure to EPS;

– Redirection to E-UTRA connected to 5GC; or

– Handover to E-UTRA connected to 5GC.

– If needed, Network Provided Location Information is provided as described in clauses 4.13.6.1 and 4.13.6.2 of TS 23.502 [3].

– The ongoing IMS voice session is not impacted by a change of the IMS voice over PS session indicator from supported to unsupported (e.g. the UE receives during RAT Fallback or EPS Fallback the IMS voice over PS session indicator indicating that IMS voice over PS sessions are not supported).

NOTE: Any change in IMS voice over PS session indicator applies to new IMS sessions initiated only after the ongoing IMS voice session is terminated.

During any release of RRC connection including after EPS/RAT fallback is performed, the eNB or NG-RAN node may provide to the UE dedicated idle mode priorities for NR as defined in TS 36.331 [51] taking into account RFSP, PLMNs contained in Handover Restriction List and local operator policy. If the UE remains ECM/CM connected after the voice call has ended, the eNB or NG-RAN node may trigger handover to NR connected to 5GC, if configured to do so, taking into account local operator policy and Handover Restriction List.

5.16.3.11 P-CSCF discovery and selection

P-CSCF selection functionality may be used by the SMF to select the P-CSCF for an IMS PDU Session of the UE.

The SMF can utilize the Network Repository Function to discover the P-CSCF instance(s). The NRF provides the IP address or the FQDN of P-CSCF instance(s) to the SMF. The P-CSCF selection function in the SMF selects the P-CSCF instance(s) based on the available P-CSCF instances obtained from NRF or based on the configured P-CSCF information in the SMF. If the SMF receives FQDN(s) from the NRF or is configured with FQDN(s) the SMF shall resolve these to IP addresses for sending to the UE in the PDU session response.

The following factors may be considered during the P-CSCF discovery and selection:

– S-NSSAI of the PDU Session.

– UE location information.

– Local operator policies.

– Availability of candidate P-CSCFs.

– UE IP address.

– Access Type.

– Proximity to location of selected UPF.

– Selected Data Network Name (DNN).

5.16.3.12 HSS discovery and selection

HSS discovery and selection functionality is used by the I-CSCF/S-CSCF/IMS-AS to select an HSS that manages the user’s IMS subscriptions and has the ability to serve the IMS services for the UE, see clause AA.3.3 of TS 23.228 [15] and clause 6.3.1 for details.

5.16.4 Emergency Services

5.16.4.1 Introduction

Emergency Services are provided to support IMS emergency sessions. "Emergency Services" refers to functionalities provided by the serving network when the network is configured to support Emergency Services. Emergency Services are provided to normally registered UEs and to Emergency Registered UEs, that can be either normally registered or in limited service state. Depending on local regulation, receiving Emergency Services in limited service state does not require a valid subscription. Depending on local regulation and on operator’s policy, the network may allow or reject a registration request for Emergency Services (i.e. Emergency Registration) from UEs that have been identified to be in limited service state. Four different behaviours of Emergency Services as defined in clause 4.3.12.1 of TS 23.401 [26] are supported.

Emergency Services shall not be provided to a UE over 3GPP access and non-3GPP access concurrently, except for the following case:

– a UE may be Emergency Registered and have an emergency PDU session over non-3GPP access or may be attached for emergency session to ePDG over untrusted WLAN (as defined in TS 23.402 [43]) when 3GPP access becomes available. In which case the UE may have to register over 3GPP access and check first the support for Emergency Services over the 3GPP RAT it has selected (e.g. based on Emergency Services Support indication, Emergency Services Fallback, AS broadcast indicator). If there is native support for Emergency Services in the selected 3GPP RAT the UE will attempt to transfer the emergency PDU session from non-3GPP access to 3GPP access (see clause 4.9.2 or clause 4.9.3 of TS 23.502 [3]). If there is no native support for Emergency Services in the selected RAT, but Emergency Services Fallback to another RAT in 5GS or to another System where Emergency Services may be supported (based on the conditions defined in clause 5.16.4.11), the UE may trigger first Emergency Services Fallback (see clause 4.13.4.2 of TS 23.502 [3]) and then attempt to transfer the emergency PDU session from non-3GPP access to 3GPP access (see clause 4.9.2 of TS 23.502 [3]). In these cases the UE may thus briefly be emergency registered and receive emergency services over both 3GPP access and non-3GPP access concurrently.

A UE may only attempt to use Emergency Services over non-3GPP access if it is unable to use Emergency Services over 3GPP access as specified in TS 23.167 [18].

The UE is only allowed to have one PDU session for Emergency services at a time. A PDU Session cannot be changed between a PDU Session for Non-Emergency services and a PDU Session for Emergency services. PDU session for emergency services can be transferred from one Access Type to another as specified in clause 5.16.4.9.

To provide Emergency Services, the AMF is configured with Emergency Configuration Data that are applied to Emergency Services that are established by an AMF based on request from the UE. The AMF Emergency Configuration Data contains the S-NSSAI and Emergency DNN which is used to derive an SMF. In addition, the AMF Emergency Configuration Data may contain the statically configured SMF for the Emergency DNN. The SMF may also store Emergency Configuration Data that contains statically configured UPF information for the Emergency DNN.

NOTE 1: The Network slices associated with emergency services are assumed to be configured consistently in the AMF (i.e. emergency configuration data) and NG-RAN nodes within the corresponding Registration Area where emergency services are to be supported.

When the UE is camped normally in the cell, i.e. not in limited service state, during Registration procedure described in clause 4.2.2.2 of TS 23.502 [3], the serving AMF includes an indication for Emergency Services Support within the Registration Accept to the UE. For 3GPP access, the Emergency Services Support indication is valid within the current Registration Area per RAT (i.e. this is to cover cases when the same registration area supports multiple RATs and they have different capability).

The Emergency Services Support is configured in the AMF according to local regulations and network capabilities. AMF includes Emergency Services Support indicator in the Registration Accept message to indicate that the UE can setup emergency PDU Session to obtain emergency services. The AMF may include additional local emergency numbers associated with the serving network for the UE, further defined in TS 24.501 [47].

During Registration procedures over 3GPP access in a PLMN, the 5GC includes the Emergency Services Support indicator, valid for the current Registration Area and indicating per RAT that Emergency Services are supported if any of the following conditions is true within the current Registration Area:

– the Network is able to support Emergency Services natively over 5GS;

– E-UTRA connected to 5GC supports IMS Emergency Services (e.g. voice), and the NG-RAN is able to trigger handover or redirection from NR to E-UTRA connected to 5GC at QoS Flow establishment for IMS Emergency Services (e.g. voice);

– NG-RAN is able to trigger handover to EPS at QoS Flow establishment for IMS Emergency Services (e.g. voice);

– NG-RAN is able to trigger redirection to EPS at QoS Flow establishment for IMS Emergency Services (e.g. voice); or

– NG-RAN is able to trigger 5G SRVCC handover to UTRAN for IMS Emergency Services (i.e. voice).

During Registration procedures over non-3GPP access, the 5GC indicates that Emergency Services are supported if the Network is able to support Emergency Services natively over 5GS.

In the case of SNPN, during Registration procedures over 3GPP access, the 5GC includes the Emergency Services Support indicator, valid for the current Registration Area indicating that Emergency Services are supported if the following condition is true within the current Registration Area:

– the Network is able to support Emergency Services natively over 5GS.

The 5GC includes an indication per RAT whether it supports Emergency Services Fallback (as defined in clause 5.16.4.11) to another RAT in 5GS or to another System where Emergency Services are supported natively. The Emergency Services Fallback support indicator is valid within the current Registration Area per RAT.

If a certain RAT is restricted for Emergency Services, AMF signals that the corresponding RAT is restricted for Emergency Services Support to the Master RAN Node. This helps assist the Master RAN node determine whether to set up Dual Connectivity for Emergency Services.

UEs that are in limited service state, as specified in TS 23.122 [17], or that camp normally on a cell but failed to register successfully to the network under conditions specified in TS 24.501 [47], initiate the Registration procedure by indicating that the registration is to receive Emergency Services, referred to as Emergency Registration, and a Follow-on request is included in the Registration Request to initiate PDU Session Establishment procedure with a Request Type indicating "Emergency Request". UEs that had registered for normal services and do not have emergency PDU Session established and that are subject to Mobility Restriction in the present area or RAT (e.g. because of restricted tracking area) shall initiate the UE Requested PDU Session Establishment procedure to receive Emergency Services, i.e. with a Request Type indicating "Emergency Request". Based on local regulation, the network supporting Emergency Services for UEs in limited service state provides Emergency Services to these UE, regardless whether the UE can be authenticated, has roaming or Mobility Restrictions or a valid subscription.

For Emergency Services over 3GPP access via PLMN, other than eCall over IMS, the UEs in limited service state that do not operate in SNPN access mode determine that the cell supports Emergency Services over NG-RAN from a broadcast indicator in AS. The cell connected to EPC and 5GC broadcasts separate broadcast indicator for EPC and 5GC to indicate support of emergency services by the EPC and 5GC. If the UE supports SNPN access mode, is in limited service state, is not operating in SNPN access mode, needs to make an emergency call and cannot find an acceptable cell in any PLMN, the UE may activate SNPN access mode and attempt to camp on an acceptable cell of any available SNPN supporting emergency calls (irrespective of SNPN ID or GIN) as defined in TS 23.122 [17]. For Emergency Services over untrusted non-3GPP access, other than eCall over IMS, the UE in limited service state selects any N3IWF as specified in clause 6.3.6. Emergency calls for eCall Over IMS may only be performed if the UE has a USIM.

For Emergency Services over NR via SNPN, other than eCall over IMS, the UEs in limited service state that operate in SNPN access mode determine that the cell supports Emergency Services over NR from a broadcast indicator in AS and indication that the SNPN supports Emergency Services. If the UE operates in SNPN access mode and is in limited service state, the UE shall attempt to camp on an acceptable cell of any available SNPN supporting emergency calls (irrespective of SNPN ID or GIN). If the UE cannot find acceptable cell on any available SNPN, the UE shall deactivate SNPN access mode and camp on any available PLMN cell supporting emergency calls (irrespective of PLMN ID) as defined in TS 23.122 [17].

For NR satellite access, if a UE in limited service state is aware of its location, the UE selects a PLMN that is allowed to operate in the UE location as specified in TS 23.122 [17]. The network may be configured to verify the location of a UE that is registering for emergency services as specified in clause 5.4.11.4.

There is no support for eCall over IMS for SNPNs in this Release.

A serving network shall provide an Access Stratum broadcast indication from NG-RAN (NR or E-UTRA connected to 5GC) to UEs indicating whether eCall Over IMS is supported:

– When an E-UTRA cell is connected to EPC and 5GC, the cell broadcasts separate Access stratum broadcast indication for 5GC and EPC to indicate support of eCall over IMS by 5GC and EPC.

– A UE that is not in limited service state determines that the NG-RAN cell supports eCall Over IMS via 5GC using the broadcast indicator for eCall over IMS. Emergency calls for eCall over IMS are not supported over non-3GPP access.

NOTE 2: The Access Stratum broadcast indicator is determined according to operator policies and minimally indicates that the PLMN, or all of the PLMNs in the case of network sharing, and at least one emergency centre or PSAP to which an eCall Over IMS can be routed, support eCall Over IMS.

– A UE in limited service state determines that the cell supports eCall Over IMS using both the broadcast indicator for support of Emergency Services over NG-RAN and the broadcast indicator of NG-RAN for eCall over IMS. Emergency calls for eCall Over IMS are not supported over Non-3GPP access and NR via SNPN.

NOTE 3: The broadcast indicator for eCall Over IMS does not indicate whether UEs in limited service state are supported. So, the broadcast indicator for support of Emergency Services over NG-RAN that indicates limited service state support needs to be applied in addition.

For a UE that is Emergency Registered, if it is unauthenticated the security context is not set up on UE.

In order to receive Emergency Services, UEs that camp on a suitable cell in RM-DEREGISTERED state (i.e. without any conditions that result in limited service state), or that decide to access 5GC via non-3GPP access (and not in limited service state over non-3GPP access), initiate the Initial Registration procedure for normal service instead of Emergency Registration. Upon successful registration, such UEs shall initiate the UE Requested PDU Session Establishment procedure with a Request Type indicating "Emergency Request" to receive Emergency Services if the AMF indicated support for Emergency Services in 5GC (for the RAT the UE is currently camped on when UE is camping on 3GPP access). The UEs that camp normally on a cell or that are connected via Non-3GPP access are informed that the PLMN supports Emergency Services over 5G-AN from the Emergency Services Support indicator in the Registration procedure. This applies to both 3GPP and non-3GPP Access Types. There is no support for Emergency Services for SNPN that is accessed via NWu from a PLMN.

NOTE 4: The Emergency Services Support indicator in the Registration procedures does not indicate support for eCall Over IMS.

For a UE that is Emergency Registered, normal PLMN or SNPN selection principles apply after the end of the IMS emergency session.

NOTE 5: For Emergency Services, there is no support for inter PLMN mobility thus there is a risk of service disruption due to failed inter PLMN mobility attempts when there is no session continuity (e.g. change of anchor SMF/UPF due to mobility) for the PDU Session and/or based on operator policies.

NOTE 6 Based on operator policies, Inter PLMN mobility with session continuity can be supported for Emergency Services if the anchor SMF/UPF for PDU Session supporting Emergency Services does not change.

The UE shall set the RRC establishment cause to emergency as defined in TS 38.331 [28] when it requests an RRC Connection in relation to an emergency session.

In the case of Limited Service state, UE shall not include any Network Slice related parameters when communicating with the network.

When a PLMN or SNPN supports IMS and Emergency Services:

– all AMFs in that PLMN or SNPN shall have the capability to support Emergency Services.

– at least one SMF shall have this capability.

For other emergency scenarios (e.g. UE autonomous selection for initiating Emergency Services), refer to TS 23.167 [18] for domain selection principles.

For emergency service support in Public network integrated NPNs, refer to clause 5.30.3.5.

5.16.4.2 Architecture Reference Model for Emergency Services

According to clause 4.2, the non-roaming architectures (Figure 4.2.3-1 and Figure 4.2.3-2) and roaming architecture with the visited operator’s application function (Figure 4.2.4-1 and Figure 4.2.4-4) apply for Emergency Services. The other non-roaming and roaming architectures with services provided by the home network do not apply for Emergency Services.

5.16.4.3 Mobility Restrictions and Access Restrictions for Emergency Services

When Emergency Services are supported and local regulation requires IMS Emergency Sessions to be provided regardless of Mobility Restrictions or Access Restrictions, the Mobility Restrictions or Access Restrictions (see clause 5.3.4.1) should not be applied to UEs receiving Emergency Services. Additionally, due to Mobility Restrictions or Access Restrictions (e.g. CAG restrictions) for normally registered UEs, that have established both non-emergency PDU Sessions and emergency PDU Session, the AMF indicates to the SMF to perform a local release of all non-emergency PDU Sessions via PDU Session Release procedure as specified in clause 4.3.4 of TS 23.502 [3]. The UE locally releases non-emergency PDU Sessions. The AMF and the UE behave as if the UE is emergency registered as described in TS 24.501 [47].

When the (R)AN resources for Emergency Services are established, the ARP value for Emergency Services indicates the usage for Emergency Services to the 5G-AN.

During handover, the source NG-RAN and source AMF ignore any UE related restrictions during handover evaluation when there is an active PDU Session associated with emergency service.

During Mobility Registration Update procedures, including a Mobility Registration Update as part of a handover, the target AMF ignores any Mobility Restrictions or access restrictions for UE with emergency services where required by local regulation. Any non-emergency services are not allowed, by the target network when not allowed by the subscription for the target location. To allow the UE in limited service state (either Emergency Registered or registered for normal service) over a given Access Type to get access to normal services over this Access Type after the Emergency Session has ended and when it has moved to a new area that is not stored by the UE as a forbidden area, after allowing a period of time for subsequent Emergency Services, the UE may explicitly deregister and register for normal services over this Access Type without waiting for the emergency PDU Session Release by the SMF.

This functionality applies to all mobility procedures.

5.16.4.4 Reachability Management

Over 3GPP access, an Emergency Registered UE when its Periodic Registration Update timer expires shall not initiate a Periodic Registration Update procedure but shall enter the RM-DEREGISTERED state. For such UEs, the AMF runs a mobile reachable timer with a similar value to the UE’s Periodic Registration Update timer. After expiry of this timer the AMF may change the UE RM state for 3GPP Access in the AMF to RM-DEREGISTERED. The AMF assigns the Periodic Registration Update timer value to Emergency Registered UEs. This timer keeps the Emergency Registered UE registered for Emergency Services after change to CM-IDLE state to allow for a subsequent Emergency Service without a need for a new Emergency Registration.

Over non-3GPP access, an Emergency Registered UE is only reachable in CM-CONNECTED state: since the UE may only use Emergency Services over Non-3GPP access when it is not possible over 3GPP access, 3GPP access is assumed to be unavailable for paging the UE.

5.16.4.5 SMF and UPF selection function for Emergency Services

When a SMF is selected for Emergency Services, the SMF selection function described in clause 6.3.2 for normal services is applied to the Emergency DNN or the AMF selects the SMF directly from the AMF Emergency Configuration Data. If the SMF selection function described in clause 6.3.2 is used it shall always derive a SMF in the Serving PLMN or SNPN, which guarantees that the IP address is also allocated by the Serving PLMN or SNPN. When a UPF is selected for Emergency Services, the UPF selection function described in clause 6.3.3 for normal services is applied to the Emergency DNN or the SMF selects the UPF directly from the SMF Emergency Configuration Data. The information in the AMF Emergency Configuration Data and the SMF Emergency Configuration Data is specified in clause 5.16.4.1.

5.16.4.6 QoS for Emergency Services

Local regulation may require supporting emergency calls from an unauthorised UE. In such a case, the SMF may not have subscription data. Additionally, the local network may want to provide Emergency Services support differently than what is allowed by a UE subscription. Therefore, the initial QoS parameters used for establishing Emergency Services are configured in the V-SMF (local network) in the SMF Emergency Configuration Data.

This functionality is used by the UE Requested PDU Session Establishment procedure when establishing Emergency Services.

5.16.4.7 PCC for Emergency Services

Dynamic PCC is used for UEs establishing emergency service and shall be used to manage IMS emergency sessions when an operator allows IMS emergency sessions. When establishing Emergency Services with a SMF, the PCF provides the SMF with the QoS parameters, including an ARP value reserved for the Emergency Services to prioritize the QoS Flows when performing admission control, as defined in TS 23.503 [45].

The PCF rejects an IMS session established via the emergency PDU Session if the AF (i.e. P-CSCF) does not provide an emergency indication to the PCF.

5.16.4.8 IP Address Allocation

Emergency service is provided by the serving PLMN or SNPN. The UE and serving PLMN or SNPN must have compatible IP address versions in order for the UE to obtain a local emergency PDU Session.

5.16.4.9 Handling of PDU Sessions for Emergency Services

The QoS Flows of a PDU Session associated with the emergency DNN shall be dedicated for IMS emergency sessions and shall not allow any other type of traffic. The emergency contexts shall not be changed to non-emergency contexts and vice versa. The UPF shall block any traffic that is not from or to addresses of network functions (e.g. P-CSCF) providing Emergency Services.

If there is already an emergency PDU Session over a given Access Type (3GPP access or non-3GPP access), the UE shall not request another emergency PDU Session over any Access Type except for handing over the existing emergency PDU Session to the other Access Type.

If the SMF receives a new emergency PDU session establishment request and an emergency PDU Session exists for the same UE over any Access Type, the SMF shall remove the existing SM context locally and clear the associated resources in the network and proceed with the new request.

NOTE: If the UE releases emergency PDU session locally and requests for establishment of a new one before the SMF has released the emergency PDU session due to PDU session inactivity as specified in clause 4.3.4.2 of TS 23.502 [3], the above duplicate emergency PDU session handling in the network removes the old emergency PDU session as part of establishing a new one. This releases all emergency call back resources related with the old emergency PDU Session.

The ARP reserved for emergency service shall only be assigned to QoS Flows associated with an emergency PDU Session. If the UE is Emergency Registered over a given access, it shall not request a PDU Session to any other DNN over this access.

5.16.4.9a Handling of PDU Sessions for normal services for Emergency Registered UEs

For an Emergency Registered UE over a given Access Type:

– the UE shall not initiate the UE Requested PDU Session Establishment procedure for normal service over this Access Type; and

– the network shall reject any PDU Session Establishment request for normal service from the UE on this Access Type;

– the UE may attempt to receive normal service over another Access Type if not otherwise prevented by the present document.

5.16.4.10 Support of eCall Only Mode

For service requirements for eCall only mode, refer to TS 22.101 [33].

A UE configured for eCall Only Mode shall remain in RM-DEREGISTERED state, shall camp on a network cell when available but shall refrain from any Registration Management, Connection Management or other signalling with the network. The UE may instigate Registration Management and Connection Management procedures in order to establish, maintain and release an eCall Over IMS session or a session to any non-emergency MSISDN(s) or URI(s) configured in the USIM for test and/or terminal reconfiguration services. Following the release of either session and after the UE has left RRC Connected state, the UE starts a timer whose value depends on the type of session (i.e. whether eCall or a session to a non-emergency MSISDN or URI for test/reconfiguration). While the timer is running, the UE shall perform normal RM/CM procedures and is permitted to respond to paging to accept and establish an incoming session (e.g. from an emergency centre, PSAP or HPLMN operator). When the timer expires, once the UE is not in RRC Connected state, the UE shall perform a UE-initiated Deregistration procedure if still registered and enter RM-DEREGISTERED state.

NOTE 1: An HPLMN operator can change the eCall Only Mode configuration state of a UE in the USIM. An HPLMN operator can also instead add, modify or remove a non-emergency MSISDN or URI in the USIM for test and/or terminal reconfiguration services. This can occur following a UE call to a non-emergency MSISDN or URI configured for reconfiguration. When the eCall Only Mode configuration is removed, the UE operates as a normal UE that can support eCall over IMS.

NOTE 2: A test call and a reconfiguration call can be seen as normal (non-emergency) call by a serving PLMN and normal charging rules can apply depending on operator policy.

NOTE 3: An MSISDN configured in the USIM for test and/or terminal reconfiguration services for eCall Over IMS can differ from an MSISDN configured in the USIM for test services for eCall over the CS domain.

5.16.4.11 Emergency Services Fallback

In order to support various deployment scenarios for obtaining Emergency Services, the UE and 5GC may support the mechanism to direct or redirect the UE either towards E-UTRA connected to 5GC (RAT fallback) when only NR does not support Emergency Services or towards EPS (E-UTRAN connected to EPC System fallback) when the 5GC does not support Emergency Services. Emergency Services fallback may be used when the 5GS does not indicate support for Emergency Services (see clause 5.16.4.1) and indicates support for Emergency Services fallback.

Following principles apply for Emergency Services Fallback:

– If the AMF indicates support for Emergency Services fallback in the Registration Accept message, then in order to initiate Emergency Service, normally registered UE supporting Emergency Services fallback shall initiate a Service Request with Service Type set to Emergency Services fallback as defined in clause 4.13.4.1 of TS 23.502 [3].

– AMF uses the Service Type Indication within the Service Request to redirect the UE towards the appropriate RAT/System. The 5GS may, for Emergency Services, trigger one of the following procedures:

– Handover or redirection to EPS.

– Handover or redirection to E-UTRA connected to 5GC.

– After receiving the Service Request for Emergency Fallback, the AMF triggers N2 procedure resulting in either CONNECTED state mobility (Handover procedure) or IDLE state mobility (redirection) to either E-UTRA/5GC or to E-UTRAN/EPC depending on factors such as N26 availability, network configuration and radio conditions. In the N2 procedure, the AMF based on support for Emergency Services in 5GC or EPC may indicate the target CN for the RAN node to know whether inter-RAT fallback or inter-system fallback is to be performed. The target CN indicated in the N2 procedure is also conveyed to the UE in order to be able to perform the appropriate NAS procedures (S1 or N1 Mode).

– When the AS re-keying procedure and the Emergency Fallback procedure collides, the AMF gives up the AS re-keying procedure and only initiates the Emergency Fallback procedure.

NOTE 1: Emergency Services Fallback to EPS can be followed by an onward movement to GERAN or UTRAN via CSFB procedures if the PLMN does not support IMS emergency services.

NOTE 2: If the UE has signalled that S1 mode is disabled for a network that only supports IMS voice via EPS Fallback, the AMF will not indicate that Emergency Services Fallback is supported over 3GPP access.

Emergency Services fallback is supported only in case of PLMN. Emergency Services Fallback is not supported for SNPN.

5.16.5 Multimedia Priority Services

TS 22.153 [24] specifies the service requirements for Multimedia Priority Service (MPS). MPS allows Service Users (as per TS 22.153 [24]) priority access to system resources in situations such as during congestion, creating the ability to deliver or complete sessions of a high priority nature. Service Users are government-authorized personnel, emergency management officials and/or other authorized users. MPS supports priority sessions on an "end-to-end" priority basis.

MPS is based on the ability to invoke, modify, maintain and release sessions with priority, and deliver the priority media packets under network congestion conditions. MPS is supported in a roaming environment when roaming agreements are in place and where regulatory requirements apply.

NOTE 1: If a session terminates on a server in the Internet (e.g. web-based service), then the remote end and the Internet transport are out of scope for this specification.

A Service User may use an MPS-subscribed UE or any other UE to obtain MPS. An MPS-subscribed UE obtains priority access to the Radio Access Network by using the Unified Access Control mechanism according to TS 22.261 [2]. This mechanism provides preferential access to UEs based on its assigned Access Identity. If an MPS-subscribed UE belongs to the special Access Identity as defined in TS 22.261 [2], the UE has preferential access to the network compared to ordinary UEs in periods of congestion.

MPS subscription allows users to receive priority services, if the network supports MPS. MPS subscription entitles a USIM with special Access Identity. MPS subscription includes indication for support of priority PDU connectivity service including MPS for Data Transport Service and IMS priority service support for the end user. Priority Level regarding QoS Flows and IMS are also part of the MPS subscription information. The usage of Priority Level is defined in TS 22.153 [24], TS 23.503 [45] and TS 23.228 [15].

NOTE 2: The term "Priority PDU connectivity services" is used to refer to 5G System functionality that corresponds to the functionality as provided by LTE/EPC Priority EPS bearer services in clause 4.3.18.3 of TS 23.401 [26].

MPS includes signalling priority and media priority. All MPS-subscribed UEs get priority for QoS Flows (e.g. used for IMS signalling) when established to the DN that is configured to have priority for a given Service User by setting MPS-appropriate values in the QoS profile in the UDM.

Service Users are treated as On Demand MPS subscribers or not, based on regional/national regulatory requirements. On Demand service is based on Service User invocation/revocation explicitly and applied to the media QoS Flows being established. When not On Demand MPS service does not require invocation, and provides priority treatment for all QoS Flows only to the DN that is configured to have priority for a given Service User after attachment to the 5G network.

MPS for Data Transport Service is an on-demand service that may be invoked/revoked by an authorized Service User using a UE with a subscription for MPS (i.e. according to its MPS profile), or using a UE that does not have a subscription for MPS (using methods not in scope of this specification).

MPS for Data Transport Service requires explicit invocation. The Service User invokes the service by communicating with an AF. The authorization of an MPS for Data Transport Service request is done by the AF or the PCF according to clause 6.1.3.11 of TS 23.503 [45]. Upon successful authorization, the PCF performs the necessary actions to achieve appropriate ARP and 5QI settings for the QoS Flows (see clause 6.1.3.11 of TS 23.503 [45]).

MPS for Data Transport Service enables the prioritization of all traffic on the QoS Flow associated with the default QoS rule and other QoS Flows upon AF request. The QoS modification to the QoS Flow associated with the default QoS rule and other QoS Flows is done based on operator policy and regulatory rules by means of local PCF configuration.

NOTE 3: According to regional/national regulatory requirements and operator policy, On-Demand MPS (including MPS for Data Transport Service) Service Users can be assigned the highest priority.

NOTE 4: If no configuration is provided, MPS for Data Transport Service applies only to the QoS Flow associated with the default QoS rule.

NOTE 5: MPS for DTS controls the priority of traffic on QoS Flows independent of the application(s) being used. Other mechanisms (e.g. Priority PDU connectivity service) can be used to control the priority of traffic on other QoS Flows under the control of specific data application(s), based on operator policy.

NOTE 6: MPS for Data Transport Service can be applied to any DNN other than the well-known DNN for IMS.

For MPS for Data Transport Service, the AF may also create an SDF for priority signalling between the UE and the AF (see clause 6.1.3.11 of TS 23.503 [45]).

Priority treatment is applicable to IMS based multimedia services and Priority PDU connectivity service including MPS for Data Transport Service.

Priority treatment for MPS includes priority message handling, including priority treatment during authentication, security, and Mobility Management procedures.

Priority treatment for MPS session requires appropriate ARP and 5QI (plus 5G QoS characteristics) setting for QoS Flows according to the operator’s policy.

NOTE 7: Use of QoS Flows for MPS with QoS characteristics signalled as part of QoS profile enables the flexible assignment of 5G QoS characteristics (e.g. Priority Level) for MPS.

When an MPS session is requested by a Service User, the following principles apply in the network:

– QoS Flows employed in an MPS session shall be assigned ARP value settings appropriate for the priority of the Service User.

– Setting ARP pre-emption capability and vulnerability for MPS QoS Flows, subject to operator policies and depending on national/regional regulatory requirements.

– Pre-emption of non-Service Users over Service Users during network congestion situation, subject to operator policy and national/regional regulations.

The terminating network identifies the priority of the MPS session and applies priority treatment, including paging with priority, to ensure that the MPS session can be established with priority to the terminating user (either a Service User or normal user).

MPS priority mechanisms can be classified as subscription-related, invocation-related, and those applied to existing QoS Flows. Subscription related mechanisms, as described in clause 5.22.2, are further divided into two groups: those which are always applied and those which are conditionally applied. Invocation-related mechanisms, as described in clause 5.22.3, are further divided into three groups: those that apply for mobile originated SIP call/sessions, those that apply for mobile terminated SIP call/sessions, and those that apply for the Priority PDU connectivity services including MPS for Data Transport Service. Methods applied to existing QoS Flows focus on handover and congestion control and are described in clause 5.22.4.

NOTE 8: The network can hide its topology from the AF supporting MPS for Data Transport Service. At the same time, the UE needs to provide its locally known IP address to the AF supporting MPS for Data Transport Service to support interactions with the applicable PCF. Thus, there can be no NAT of the UE IP address between the UPF and the AF supporting MPS for Data Transport Service.

5.16.6 Mission Critical Services

According to TS 22.280 [37], a Mission Critical Service (MCX Service) is a communication service reflecting enabling capabilities Mission Critical Applications and provided to end users from Mission Critical Organizations and mission critical applications for other businesses and organizations (e.g. utilities, railways). An MCX Service is either Mission Critical Push To Talk (MCPTT) as defined in TS 23.379 [38], Mission Critical Video (MCVideo) as defined in TS 23.281 [39], or Mission Critical Data (MCData) as defined in TS 23.282 [40] and represents a shared underlying set of requirements between two or more MCX Service types. MCX Services are not restricted only to the ones defined in this clause and such services can also have priority treatment, if defined via operator’s policy and/or local regulation.

MCX Services are based on the ability to invoke, modify, maintain and release sessions with priority, and deliver the priority media packets under network congestion conditions. As specified in clause 6.8 of TS 22.261 [2], MCX Users require 5GS functionality that allows for real-time, dynamic, secure and limited interaction with the QoS and policy framework for modification of the QoS and policy framework by authorized users. The limited interaction is based on operator policy, and provides specific limitations on what aspects of the QoS and policy framework an authorized MCX User can modify. MCX Services are supported in a roaming environment when roaming agreements are in place and where regulatory requirements apply.

An MCX-subscribed UE obtains priority access to the Radio Access Network by using the Unified Access Control mechanism according to TS 22.261 [2]. This mechanism provides preferential access to UEs based on its assigned Access Identity. If an MCX-subscribed UE belongs to the special Access Identity as defined in TS 22.261 [2], the UE has preferential access to the network compared to ordinary UEs in periods of congestion. MCX subscription allows users to receive priority services, if the network supports MCX. MCX subscription entitles a USIM with special Access Identity.

MCX Services leverage the foundation of the 5G QoS Model as defined in clause 5.7, and 5G Policy Control as defined in clause 5.14. It requires that the necessary subscriptions are in place for both the 5G QoS Profile and the necessary Policies. In addition, MCX Services leverage priority mechanism as defined in clause 5.22.

The terminating network identifies the priority of the MCX Service session and applies priority treatment, including paging with priority, to ensure that the MCX Service session can be established with priority to the terminating user (either an MCX User or normal user).

Priority treatment for MCX Service includes priority message handling, including priority treatment during authentication, security, and Mobility Management procedures.

Priority treatment for MCX Service sessions require appropriate ARP and 5QI (plus 5G QoS characteristics) setting for QoS Flows according to the operator’s policy.

NOTE: Use of QoS Flows for MCX Service sessions with non-standardized 5QI values enables the flexible assignment of 5G QoS characteristics (e.g. Priority Level).

When a MCX Service session is requested by an MCX User, the following principles apply in the network:

– QoS Flows employed in a MCX Service session shall be assigned ARP value settings appropriate for the priority of the MCX User.

– Setting ARP pre-emption capability and vulnerability of QoS Flows related to a MCX Service session, subject to operator policies and depending on national/regional regulatory requirements.

– Pre-emption of non-MCX Users over MCX Users during network congestion situations, subject to operator policy and national/regional regulations.

Priority treatment is applicable to IMS based multimedia services and priority PDU connectivity services.

Relative PDU priority decisions for MCX Service sessions are based on real-time data of the state of the network and/or based on modification of the QoS and policy framework by authorized users as described in clause 6.8 of TS 22.261 [2].