Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.501  Word version:   16.4.0

Top   Up   Prev   Next
1…   3…   4…   4.2.4   4.2.5…   4.2.8…   4.2.8.2.2   4.2.8.2.3…   4.2.8.4…   4.2.9…   4.3…   4.3.3   4.3.4   4.3.5   4.4…   4.4.6…   4.4.8   5…   5.3…   5.3.3…   5.4…   5.5…   5.6…   5.6.7…   5.7…   5.7.2…   5.7.3…   5.7.4   5.7.5…   5.8…   5.8.2.11…   5.9…   5.10…   5.11…   5.15…   5.16…   5.17…   5.18…   5.19…   5.21…   5.22…   5.27…   5.28…   5.29…   5.30…   5.31…   5.32…   5.33…   5.34…   5.35…   6…   6.3…   7…   7.2…   8…   8.2.4   8.2.5…   8.3…   A…   D…   E…   F   G…   G.3   G.4…   J…

 

5.16  Support for specific servicesWord-p. 209
5.16.1  Public Warning System
The functional description for supporting Public Warning System for 5G System can be found in TS 23.041.
5.16.2  SMS over NASWord-p. 210
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.
Up
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.
Up
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.
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.
  • IMS emergency service as defined in TS 23.167.
  • 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 or SCP based HSS discovery (clause 5.16.3.12).
Up
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 TS 23.502, clause 4.2.8a). 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:
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.
Up
5.16.3.2a  IMS voice over PS Session Supported Indication over non-3GPP accessWord-p. 211
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.
Up
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.
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 and TS 23.221) 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.
Up
5.16.3.4  P-CSCF address deliveryWord-p. 212
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 is not excluded.
NOTE 2:
PDU Session for IMS is identified by "APN" or "DNN".
Up
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.
  • 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.
Up
5.16.3.6  Terminating domain selection for IMS voiceWord-p. 213
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.
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.
Up
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.
Up
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.
Up
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.
Up
5.16.3.9  SMF support for P-CSCF restoration procedureWord-p. 214
For the support of P-CSCF restoration the SMF behaves as described in TS 23.380.
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.
  • 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 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.
Up
5.16.3.11  P-CSCF discovery and selection [R16]
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).
Up
5.16.3.12  HSS discovery and selection [R16]Word-p. 215
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 Y.11 in TS 23.228 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 TS 23.401, clause 4.3.12.1 are supported.
Emergency Services shall not be provided to a UE over 3GPP access and untrusted 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) 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 TS 23.502, clause 4.9.2). 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 TS 23.502, clause 4.13.4.2) and then attempt to transfer the emergency PDU session from non-3GPP access to 3GPP access (see TS 23.502, clause 4.9.2). 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 untrusted non-3GPP access if it is unable to use Emergency Services over 3GPP access as specified in TS 23.167.
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.
When the UE is camped normally in the cell, i.e. not in limited service state, during Registration procedure described in TS 23.502, clause 4.2.2.2, 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.
During Registration procedures over 3GPP access, 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.
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, or that camp normally on a cell but failed to register successfully to the network under conditions specified in TS 24.501, 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 Sessions 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, other than eCall over IMS, the UEs in limited service state 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. 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.
A serving network shall provide an Access Stratum broadcast indication from E-UTRA connected to 5GC to UEs indicating whether eCall Over IMS is supported:
  • When a 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 E-UTRA cell supports eCall Over IMS via 5GC using the broadcast indicator for eCall over IMS. UE shall originate emergency calls for eCall Over IMS only over E-UTRA connected to 5GC and shall not originate emergency calls for eCall Over IMS over NR. Emergency calls for eCall over IMS are not supported over non-3GPP access.
  • NOTE 1:
    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 center or PSAP to which an eCall Over IMS can be routed, support eCall Over IMS.
    NOTE 2:
    There is no restriction on handoff of an emergency call for eCall Over IMS to NR or on use of NR for call back by a PSAP.
  • 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 E-UTRA connected to 5GC and the broadcast indicator of E-UTRA for eCall over IMS. Emergency calls for eCall Over IMS are not supported over NR and Non-3GPP access.
  • 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 E-UTRA connected to 5GC 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 untrusted non-3GPP access (and not in limited service state over untrusted 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 untrusted 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.
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 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.
The UE shall set the RRC establishment cause to emergency as defined in TS 38.331 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 supports IMS and Emergency Services:
  • all AMFs in that PLMN 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 for domain selection principles.
For emergency service support in Public network integrated NPNs, refer to clause 5.30.3.5.
Up
5.16.4.2  Architecture Reference Model for Emergency ServicesWord-p. 217
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.
Up
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 the Mobility Restrictions (see clause 5.3.4.1), or access should not be applied to UEs receiving Emergency Services. 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.
Up
5.16.4.4  Reachability ManagementWord-p. 218
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 untrusted non-3GPP access, an Emergency Registered UE is only reachable in CM-CONNECTED state: since the UE may only use Emergency Services over untrusted Non-3GPP access when it is not possible over 3GPP access, 3GPP access is assumed to be unavailable for paging the UE.
Up
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, which guarantees that the IP address is also allocated by the Serving PLMN. 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.
Up
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.
Up
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.
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.
Up
5.16.4.8  IP Address Allocation
Emergency service is provided by the serving PLMN. The UE and serving PLMN 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 ServicesWord-p. 219
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 untrusted non-3GPP access), the UE shall not request another emergency PDU Session over the other Access Type except for handing over the emergency PDU Session to this other Access Type. The network shall reject any emergency PDU Session requests over a given Access Type (3GPP access or untrusted non-3GPP access) if it knows the UE already has an emergency PDU Session over the other Access Type. 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.
Up
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.
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, 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, 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.
Up
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 TS 23.502, clause 4.13.4.1.
  • 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).
NOTE:
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.
Up
5.16.5  Multimedia Priority ServicesWord-p. 220
TS 22.153 specifies the service requirements for Multimedia Priority Service (MPS). MPS allows Service Users (as per TS 22.153) 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. 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, 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 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, TS 23.503 and TS 23.228.
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.
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.
NOTE 3:
According to regional/national regulatory requirements and operator policy, On-Demand MPS Service Users can be assigned the highest priority.
Priority treatment is applicable to IMS based multimedia services and priority PDU connectivity 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 4:
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 level 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. Methods applied to existing QoS Flows focus on handover and congestion control and are described in clause 5.22.4.
Up
5.16.6  Mission Critical ServicesWord-p. 221
According to TS 22.280, 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, Mission Critical Video (MCVideo) as defined in TS 23.281, or Mission Critical Data (MCData) as defined in TS 23.282 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 sub 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 TS 22.261, clause 6.8, 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. 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, 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 level 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.
Up

Up   Top   ToC