5.31 Support for Cellular IoT

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

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

5.31.1 General

This clause provides an overview about 5GS optimisations and functionality for support of Cellular Internet-of-Things (Cellular IoT, or CIoT) according to service requirements described in TS 22.261 [2]. Cellular IoT is in earlier 3GPP releases also referred to as Machine Type Communication (MTC) (see clause 4.3.17 of TS 23.401 [26]). The specific functionality is described in the affected procedures and features of this specification, in TS 23.502 [3], TS 23.503 [45] and other specifications.

In this Release Control Plane CIoT 5GS Optimisations (clause 5.31.4) and User Plane CIoT 5GS Optimisations (clause 5.31.18) are only supported over E-UTRA and these CIoT 5GS optimisations are not supported over Non-3GPP RAT type accesses.

CIoT functionality is provided by the visited and home networks when the networks are configured to support CIoT. It applies to both the non-roaming case and the roaming case and some functionality may be dependent upon the existence of appropriate roaming agreements between the operators.

Some of the CIoT functions are controlled by subscriber data. Other CIoT functions are based on indicators sent by the UE to the network. CIoT functionality is performed by UEs that are configured to support different options as described in clause 5.31.2

Though motivated by scenarios and use cases defined in TS 22.261 [2], the functions added to support CIoT have general applicability and are in no way constrained to any specific scenario, use case or UE types, except where explicitly stated.

In the context of CIoT the term AF denotes an SCS/AS as defined TS 23.682 [36].

5.31.2 Preferred and Supported Network Behaviour

At registration, a UE includes its 5G Preferred Network Behaviour indicating the network behaviour the UE can support and what it would prefer to use.

NOTE: If the UE supports S1-mode then the UE will indicate the supported EPS Network Behaviour Information in the S1 UE network capability IE.

The 5G Preferred Network Behaviour signalled by the UE includes the following information in the 5GMM Capability IE:

– Whether Control Plane CIoT 5GS Optimisation is supported.

– Whether User Plane CIoT 5GS Optimisation is supported.

– Whether N3 data transfer is supported.

– Whether header compression for Control Plane CIoT 5GS Optimisation is supported.

And the following 5G Preferred Network Behaviour in other IEs:

– Whether Control Plane CIoT 5GS Optimisation or User Plane CIoT 5GS Optimisation is preferred.

If N3 data transfer is supported is indicated by the UE, the UE supports data transfer that is not subject to CIoT 5GS Optimisations. If the UE indicates support of User Plane CIoT 5GS Optimisation then it shall also indicate support of N3 data transfer.

The AMF indicates the network behaviour the network accepts in the 5G Supported Network Behaviour information. This indication is per Registered Area. The AMF may indicate one or more of the following:

– Whether Control Plane CIoT 5GS Optimisation is supported.

– Whether User Plane CIoT 5GS Optimisation is supported.

– Whether N3 data transfer is supported.

– Whether header compression for Control Plane CIoT 5GS Optimisation is supported.

If the AMF indicates support of User Plane CIoT 5GS Optimisation then it shall also indicate support of N3 data transfer. If the UE and AMF indicate support for User Plane CIoT 5GS Optimisation, the AMF indicates support of User Plane CIoT 5GS Optimisation support for the UE to NG-RAN.

For NB-IoT UEs that only support Control Plane CIoT 5GS Optimisation, the AMF shall include support for Control Plane CIoT 5GS Optimisation in the Registration Accept message.

A UE that supports the NB-IoT shall always indicate support for Control Plane CIoT 5GS Optimisation.

A UE that supports WB-E-UTRA shall always indicate support for N3 data transfer.

The 5G Preferred Network Behaviour indication from the UE may be used to influence policy decisions that can cause rerouting of the Registration Request from an AMF to another AMF.

5.31.3 Selection, steering and redirection between EPS and 5GS

The UE selects the core network type (EPC or 5GC) based on the broadcast indications for both EPC and 5GC, and the UE’s EPC and 5GC Preferred Network Behaviour. Networks that support NB-IoT shall broadcast an indication whether N3 data transfer is supported or not in system information.

When the UE performs the registration procedure it includes its Preferred Network Behaviour (for 5G and EPC) in the Registration Request message and the AMF replies with the 5G Supported Network Behaviour in the Registration Accept message.

If the UE supports any of the CIoT 5GS Optimisations included in 5GC Preferred Network Behaviour, then when the UE performs an Attach or TAU procedure and the UE includes its EPC Preferred Network Behaviour then the UE shall also include its 5GC Preferred Network Behaviour.

In networks that support CIoT features in both EPC and 5GC, the operator may steer UEs from a specific CN type due to operator policy, e.g. due to roaming agreements, Preferred and Supported Network Behaviour, load redistribution, etc. Operator policies in EPC and 5GC are assumed to avoid steering UEs back and forth between EPC and 5GC.

To redirect a UE from 5GC to EPC, when the UE sends a Registration Request or Service Request, the AMF sends a Registration Reject or Service Reject with an EMM cause value indicating that the UE should not use 5GC. The UE disables N1 mode and re-enables S1 mode, if it was disabled. The UE then performs either an Attach or TAU in EPC as described in clause 5.17.2.

To redirect a UE from EPC to 5GC, when the UE requests an Attach or TAU procedure or Service Reject, the MME sends a reject message with an EMM cause indicating the UE should not use EPC. The UE disables S1 mode and re-enables N1 mode, if it was disabled. The UE then registers with 5GC as described in clause 5.17.2.

When determining whether to redirect the UE, the AMF/MME takes into account the UE support of S1/N1 mode, respectively, and the UE’s Preferred Network Behaviour and the Supported Network Behaviour of the network the UE is being redirected towards.

When determining to redirect the UE in 5GMM-CONNECTED mode to EPC, the AMF shall initiate the UE Configuration Update procedure to indicate registration requested and release of the N1 NAS signalling connection not requested, then the AMF redirects the UE to EPC by rejecting the subsequent Registration Request, see TS 24.501 [47].

If after redirection the UE cannot find a cell supporting connectivity, the UE may re-enable the disabled N1/S1 mode and then perform Registration, Attach or TAU.

5.31.4 Control Plane CIoT 5GS Optimisation

5.31.4.1 General

The Control Plane CIoT 5GS Optimisation is used to exchange user data between the UE and the SMF as payload of a NAS message in both uplink and downlink directions, avoiding the establishment of a user plane connection for the PDU Session. The UE and the AMF perform integrity protection and ciphering for the user data by using NAS PDU integrity protection and ciphering. For IP and Ethernet data, the UE and the SMF may negotiate and perform header compression.

NOTE: In the context of Control Plane CIoT 5GS Optimisation, established or activated user plane resources/connection refers to radio user plane resources/connection i.e Data Radio Bearer and N3 tunnel.

UE and AMF negotiate support and use of Control Plane CIoT 5GS Optimisation as defined in clause 5.31.2. When the Control Plane CIoT 5GS Optimisation feature is used and the PDU Session Type is unstructured, the SMF selects either NEF or UPF based on information in the UE’s subscription.

If UE and network have negotiated support and use of Control Plane CIoT 5GS Optimisation then the following paragraphs of this clause apply.

During the PDU Session Establishment procedure the AMF indicates to the SMF that Control Plane CIoT 5GS Optimisation is available for data transmission.

During the PDU Session Establishment procedure the AMF also determines based on Preferred and Supported Network Behaviour (see clause 5.31.2), subscription data, other already established PDU Sessions and local policy whether a new PDU Session shall only use the Control Plane CIoT 5GS Optimisation (i.e. that a user-plane connection shall never be established for the new PDU Session). If a PDU Session shall only use Control Plane CIoT 5GS Optimisation, the AMF provides a Control Plane Only Indicator to the SMF during the PDU Session Establishment. The SMF provides the Control Plane Only Indicator in the Session Management Request to the UE. A UE and SMF receiving the Control Plane Only Indicator for a PDU Session shall always use the Control Plane CIoT 5GS Optimisation for this PDU Session.

The following rules apply for the use of the Control Plane Only Indicator during PDU Session Establishment:

– If N3 data transfer was not successfully negotiated, all PDU Sessions shall include Control Plane Only Indicator.

– If N3 data transfer was successfully negotiated then:

– For a new PDU Session for a DNN/S-NSSAI for which the subscription data for SMF Selection includes an Invoke NEF indication (i.e. for a PDU Session which will be anchored in NEF), the AMF shall always include the Control Plane Only Indicator.

– For a new PDU Session for a DNN/S-NSSAI for which the subscription data for SMF Selection does not include an Invoke NEF indication (i.e. for a PDU Session which will be anchored in UPF) and that supports interworking with EPS based on the subscription data defined in TS 23.502 [3]:

– for the first PDU Session the AMF determines based on local policy whether to include the Control Plane Only Indicator or not;

– if the AMF previously included a Control Plane Only Indicator for PDU Sessions that support interworking with EPS based on the subscription data defined in TS 23.502 [3] and that are anchored in UPF, the AMF shall include it also for the new PDU Session;

– if the AMF previously did not include a Control Plane Only Indicator for any of the PDU Sessions that support interworking with EPS based on the subscription data defined in TS 23.502 [3] and that are anchored in UPF, the AMF shall not include it for the new PDU Session.

– For a new PDU Session for a DNN/S-NSSAI for which the subscription data for SMF Selection does not include an Invoke NEF indication (i.e. for a PDU Session which will be anchored in UPF) and that does not support interworking with EPS based on the subscription data defined in TS 23.502 [3], AMF determines individually per PDU Session whether to include the Control Plane Only Indicator or not.

As described in clause 5.31.4.2, if UE and AMF successfully negotiate N3 data transfer in addition to Control Plane CIoT 5GS Optimisation, the UE or SMF may request to establish N3 data transfer for one or more PDU Sessions for which Control Plane Only Indicator was not received. In CM-CONNECTED, the UE and the network use N3 delivery for PDU Sessions for which user plane resources are established, and uses NAS for data transmission for PDU Sessions for which user plane resources are not established.

If the AMF determines that Control Plane Only indication associated with PDU Session is not applicable any longer due to e.g. change of Preferred and Supported Network Behaviour, subscription data, and local policy, the AMF should request the SMF to release the PDU Session as specified in clause 4.3.4.2 or clause 4.3.4.3 of TS 23.502 [3].

Early Data Transmission may be initiated by the UE for mobile originated Control Plane CIoT 5GS Optimisation when the RAT Type is E-UTRA.

The QoS model as defined in clause 5.7 is not supported for PDU Sessions using Control Plane CIoT 5GS Optimisation as user plane resources are not established for those PDU Sessions.

5.31.4.2 Establishment of N3 data transfer during Data Transport in Control Plane CIoT 5GS Optimisation

If UE and AMF have successfully negotiated N3 data transfer in addition to Control Plane CIoT 5GS Optimisation based on the Preferred and Supported Network Behaviour as defined in clause 5.31.2, then the SMF may decide to establish N3 data transfer for any PDU session for which Control Plane Only Indicator was not included based on local SMF decision e.g. based on the amount of data transferred in UL or DL using Control Plane CIoT 5GS Optimisation. In that case, the SMF initiates the SMF-triggered N3 data transfer establishment procedure as described in clause 4.2.10.2 of TS 23.502 [3].

If UE and AMF successfully negotiate N3 data transfer in addition to Control Plane CIoT 5GS Optimisation based on the Preferred and Supported Network Behaviour as defined in clause 5.31.2, then the UE may decide to establish N3 data transfer for any PDU session for which Control Plane Only Indicator was not included based on local decision, e.g. based on the amount of data to be transferred. In that case, the UE performs the UE triggered N3 data transfer establishment procedure as described in clause 4.2.10.1 of TS 23.502 [3].

5.31.4.3 Control Plane Relocation Indication procedure

For intra-NB-IoT mobility when UE and AMF are using Control Plane CIoT 5GS Optimisation, the CP Relocation Indication procedures may be used. The purpose of the CP Relocation Indication procedure is to request the AMF to authenticate the UE’s re-establishment request (see TS 33.501 [29]), and initiate the establishment of the UE’s N2 connection after the UE has initiated an RRC Re-Establishment procedure in a new NG-RAN node (see TS 38.300 [27]).

The RRC Re-Establishment procedure uses the Truncated 5G-S-TMSI as the UE identifier. The NG-RAN is configured with the sizes of the components of the Truncated 5G-S-TMSI and it is configured with how to recreate the AMF Set ID, the AMF Pointer and 5G-TMSI from the equivalent truncated parameters (see TS 23.003 [19]).

The AMF configures the UE with the Truncated 5G-S-TMSI Configuration that provides the sizes of the components of the Truncated 5G-S-TMSI as described in TS 24.501 [47] during the Registration. The configuration of these parameters are specific to each PLMN.

NOTE: Network sharing default configuration of the sizes of the truncated components is described in TS 23.003 [19].

5.31.5 Non-IP Data Delivery (NIDD)

Functions for NIDD may be used to handle Mobile Originated (MO) and Mobile Terminated (MT) communication for unstructured data (also referred to as Non-IP). Such delivery to the AF is accomplished by one of the following two mechanisms:

– Delivery using the NIDD API;

– Delivery using UPF via a Point-to-Point (PtP) N6 tunnel.

NIDD is handled using an Unstructured PDU session to the NEF. The UE may obtain an Unstructured PDU session to the NEF during the PDU Session Establishment procedure. Whether or not the NIDD API shall be invoked for a PDU session is determined by the presence of a "NEF Identity for NIDD" for the DNN/S-NSSAI combination in the subscription. If the subscription includes a "NEF Identity for NIDD" corresponding with the DNN and S-NSSAI information, then the SMF selects that NEF and uses the NIDD API for that PDU session.

The NEF exposes the NIDD APIs described in TS 23.502 [3] on the N33/Nnef reference point.

The NEF uses the provisioned policies to map an AF Identifier and UE Identity to a DNN/S-NSSAI combination if the Reliable Data Service (RDS) is not enabled. If RDS is enabled, the NEF determines the association based on RDS port numbers and the provisioned policies that may be used to map AF Identifier and User identity to a DNN.

The NEF also supports distribution of Mobile Terminated messages to a group of UEs based on the NIDD API. If an External Group Identifier is included in the MT NIDD request, the NEF uses the UDM to resolve the External Group Identifier to a list of SUPIs and sends the message to each UE in the group with an established PDU Session.

The Protocol Configuration Options (PCO) may be used to transfer NIDD parameters to and from the UE (e.g. maximum packet size). The PCO is sent in the 5GSM signalling between UE and SMF. NIDD parameters are sent to and from the NEF via the N29 interface.

5.31.6 Reliable Data Service

The Reliable Data Service (RDS) may be used between the UE and NEF or UPF when using a PDU Session of PDU Type ‘Unstructured’. The service provides a mechanism for the NEF or UPF to determine if the data was successfully delivered to the UE and for the UE to determine if the data was successfully delivered to the NEF or UPF. When a requested acknowledgement is not received, the Reliable Data Service retransmits the packet. The service is enabled or disabled based on DNN and NSSAI Configuration per SLA.

When the service is enabled, a protocol is used between the end-points of the unstructured PDU Session. The protocol uses a packet header to identify if the packet requires no acknowledgement, requires an acknowledgement, or is an acknowledgment and to allow detection and elimination of duplicate PDUs at the receiving endpoint. RDS supports both single and multiple applications within the UE. Port Numbers in the header are used to identify the application on the originator and to identify the application on the receiver. The UE, NEF and the UPF may support reservation of the source and destination port numbers for their use and subsequent release of the reserved port numbers. Reliable Data Service protocol (as defined in TS 24.250 [80]) also enables applications to query their peer entities to determine which port numbers are reserved and which are available for use at any given time. The header is configured based on Reliable Data Service Configuration information which is obtained in the NIDD configuration, MT NIDD, and MO NIDD procedures with the AF as specified in TS 23.502 [3].

During NIDD Configuration, the AF may indicate which serialization formats it supports for mobile originated and mobile terminated traffic in the Reliable Data Server Configuration. When port numbers are reserved by the UE, the serialization format that will be used by the application may be indicated to the NEF. When port numbers are reserved by the NEF, the serialization format that will be used by the application may be indicated to the UE. If the receiver does not support the indicated serialization format, it rejects the port number reservation request and the sender may re-attempt to reserve the port number with a different serialization format. If, during NIDD Configuration, the AF indicated that it supports multiple serialization formats, the NEF determines the serialization format that it will indicate to the UE based on local policies and previous negotiations with the UE (e.g. the NEF may indicate the same serialization format that was indicated by the UE or avoid indicating a serialization format that was previously rejected by the UE). When serialization formats are configured for reserved port numbers, the NEF stores the serialization formats as part of the Reliable Data Service Configuration and provides the updated Reliable Data Service Configuration to the AF.

NOTE: Whether the UE Application or AF supports a given serialization format is outside the scope of 3GPP specifications.

The UE indicates its capability of supporting RDS in the Protocol Configuration Options (PCO) and the SMF negotiates RDS support with the NEF or UPF. If the NEF or UPF supports and accepts RDS then the SMF indicates to the UE, in the PCO, that the RDS shall be used if enabled in the DNN and NSSAI configuration.

In order to prevent situations where an RDS instance needs to interface to both the user and control plane, RDS may only be used with PDU Sessions for which the "Control Plane CIoT 5GS Optimisation" indication is set or with PDU sessions using the Control Plane CIoT 5GS Optimisation when the AMF does not move the PDU session to the user plane.

Reliable Data Service protocol is defined in TS 24.250 [80].

5.31.7 Power Saving Enhancements

5.31.7.1 General

To enable UE power saving and to enhance MT reachability while using MICO mode, e.g. for CIoT, the following features are specified in the following clauses:

– Extended Discontinuous Reception (DRX) for CM-IDLE and CM-CONNECTED with RRC-INACTIVE;

– MICO mode with Extended Connected Time;

– MICO mode with Active Time;

– MICO mode and Periodic Registration Timer Control.

If a UE requests via NAS to enable both MICO mode with Active Time and extended idle mode DRX, e.g. based on local configuration, Expected UE Behaviour, if available, UE requested Active Time value, UE subscription information and network policies etc, the AMF may decide to enable MICO mode with or without Active Time, extended idle mode DRX or both.

5.31.7.2 Extended Discontinuous Reception (DRX) for CM-IDLE and CM-CONNECTED with RRC-INACTIVE

5.31.7.2.1 Overview

The UE and the network may negotiate over non-access stratum signalling the use of extended idle mode DRX for reducing its power consumption, while being available for mobile terminating data and/or network originated procedures within a certain delay dependent on the DRX cycle value. Extended DRX in CM-IDLE is supported for E-UTRA and NR connected to 5GC. Extended DRX in CM-CONNECTED with RRC-Inactive mode is supported for WB-E-UTRA, LTE-M and NR connected to 5GC. RRC-Inactive is not supported by NB-IoT connected to 5GC.

The negotiation of the eDRX parameters for NR, WB-E-UTRA and LTE-M is supported over any RAT.

Applications that want to use extended idle mode DRX need to consider specific handling of mobile terminating services or data transfers, and in particular they need to consider the delay tolerance of mobile terminated data. A network side application may send mobile terminated data, an SMS, or a device trigger, and needs to be aware that extended idle mode DRX may be in place. A UE should request for extended idle mode DRX only when all expected mobile terminating communication is tolerant to delay.

NOTE 1: The extended idle mode DRX cycle length requested by UE takes into account requirements of applications running on the UE. Subscription based determination of eDRX cycle length can be used in those rare scenarios when applications on UE cannot be modified to request appropriate extended idle mode DRX cycle length. The network accepting extended DRX while providing an extended idle mode DRX cycle length value longer than the one requested by the UE, can adversely impact reachability requirements of applications running on the UE.

UE and NW negotiate the use of extended idle mode DRX as follows:

If the UE decides to request for extended idle mode DRX, the UE includes an extended idle mode DRX parameters information element in the Registration Request message. The UE may also include the UE specific DRX parameters information element for regular idle mode DRX according to clause 5.4.5. The extended DRX parameters information element includes the extended idle mode DRX cycle length.

The AMF decides whether to accept or reject the UE request for enabling extended idle mode DRX. If the AMF accepts the extended idle mode DRX, the AMF based on operator policies and, if available, the extended idle mode DRX cycle length value in the subscription data from the UDM, may also provide different values of the extended idle mode DRX parameters than what was requested by the UE. The AMF taking into account the RAT specific Subscribed Paging Time Window, the UE’s current RAT and local policy also assigns a Paging Time Window length to be used, and provides this value to the UE during Registration Update procedures together with the extended idle mode DRX cycle length in the extended DRX parameter information element. If the AMF accepts the use of extended idle mode DRX, the UE shall apply extended idle mode DRX based on the received extended idle mode DRX length, the UE’s current RAT (NR, NB-IoT, WB-E-UTRA or LTE-M) and RAT specific Paging Time Window length. If the UE does not receive the extended DRX parameters information element in the relevant accept message because the AMF rejected its request or because the request was received by AMF not supporting extended idle mode DRX, the UE shall apply its regular discontinuous reception as defined in clause 5.4.5. For NR, Paging Time Window applies for extended DRX lengths greater than 10.24s as defined in TS 38.304 [50]. For WB-E-UTRA, Paging Time Window applies for extended DRX lengths of 10.24s and greater as defined in TS 36.304 [52].

When the UE is accessing NR, if the AMF provides an extended idle mode DRX cycle length value of 10.24s, and the registration area of the UE contains only NR cells, the AMF does not include a Paging Time Window. If the AMF provides an extended idle mode DRX cycle length value of 10.24s, and the registration area of the UE contains E-UTRA cells and NR cells if the UE supports both E-UTRA and NR, the AMF includes a Paging Time Window.

For WB-E-UTRA and LTE-M the eNB broadcasts an indicator for support of extended idle mode DRX in 5GC in addition to the existing indicator for support of extended idle mode DRX in EPC as defined in TS 36.331 [51]. For NR the gNB broadcasts an indicator for support of extended idle mode DRX as defined in TS 38.331 [28]. This indicator is used by the UE in CM-IDLE state.

NOTE 2: A broadcast indicator for support of extended idle mode DRX is not needed for NB-IoT as it is always supported in NB-IoT.

The specific negotiation procedure handling is described in TS 23.502 [3].

NOTE 3: If the Periodic Registration Update timer assigned to the UE is not longer than the extended idle mode DRX cycle the power savings are not maximised.

For RAT types that support extended DRX for CM-CONNECTED with RRC Inactive state, the AMF passes the UE’s accepted idle mode eDRX cycle length value to NG-RAN. If the UE supports eDRX in RRC inactive, based on its UE radio capabilities, NG-RAN configures the UE with an eDRX cycle in RRC-INACTIVE as specified in TS 38.300 [27] up to the value for the UE’s idle mode eDRX cycle as provided by the AMF in "RRC Inactive Assistance Information" as defined in clause 5.3.3.2.5.

If eDRX cycle is applied in RRC-INACTIVE, the RAN buffers DL packets up to the duration of the eDRX cycle chosen by NG-RAN if the eDRX cycle does not last more than 10.24 seconds. Otherwise if the eDRX cycle lasts more than 10.24s, the NG-RAN can send an indication to the CN and the CN can handle mobile terminated (MT) communication as specified in clause 5.31.7.2.4 and apply high latency communication as specified in clause 5.31.8..

NOTE 4: If the indication that the UE is transitioning to RRC-INACTIVE state is not sent (or sent after UE has entered RRC-INACTIVE state) by the NG-RAN then until CN receives it the CN cannot apply the high latency communication functionality, other NFs will not be aware of the UE reachability, certain high latency communication related services provided to the AF via NEF would not be available, and downlink data in RAN might be lost.

When the UE has PDU Session associated with emergency services, the UE and AMF follow regular discontinuous reception as defined in clause 5.4.5 and shall not use the extended idle mode DRX. Extended idle mode DRX parameters may be negotiated while the UE has PDU Session associated with emergency services. When the PDU Session associated with emergency services is released, the UE and AMF shall reuse the negotiated extended idle mode DRX parameters in the last Registration Update procedure.

The UE shall include the extended DRX parameters information element in each Registration Request message if it still wants to use extended idle mode DRX. At AMF to AMF, AMF to MME and MME to AMF mobility, the extended idle mode DRX parameters are not sent from the old CN node to the new CN node as part of the MM context information.

5.31.7.2.2 Paging for extended idle mode DRX in E-UTRA and NR connected to 5GC

5.31.7.2.2.0 General

For WB-E-UTRA and LTE-M connected to 5GC, the extended idle mode DRX value range will consist of values starting from 5.12s (i.e. 5.12s, 10.24s, 20.48s, etc.) up to a maximum of 2621.44s (almost 44 min). For NB-IoT, the extended idle mode DRX value range will start from 20.48s (i.e. 20.48s, 40.96s, 81.92, etc.) up to a maximum of 10485.76s (almost 3 hours) (see TS 36.304 [52]). For NR, the extended idle mode DRX value range will consist of values starting from 2.56s (i.e. 2.56s, 5.12s, 10.24s, 20.48s, etc.) up to a maximum of 10485.76s (almost 3 hours) (see TS 38.304 [50]). The extended idle mode DRX cycle length is negotiated via NAS signalling. The AMF includes the extended idle mode DRX cycle length for NR, WB-E-UTRA, LTE-M or NB-IoT in paging message to assist the NG-RAN node in paging the UE. For NR, Paging Time Window applies for extended DRX lengths greater than 10.24s as defined in TS 38.304 [50].

For extended idle mode DRX cycle length of 5.12s, the network follows the regular paging strategy as defined in clause 5.4.5.

For extended idle mode DRX cycle length of 10.24s or longer, clauses 5.31.7.2.2.1, 5.31.7.2.2.2 and 5.31.7.2.2.3 apply.

5.31.7.2.2.1 Hyper SFN, Paging Hyperframe and Paging Time Window length

A Hyper-SFN (H-SFN) frame structure is defined on top of the SFN used for regular idle mode DRX. Each H-SFN value corresponds to a cycle of the legacy SFN of 1024 radio frames, i.e. 10.24s. When extended idle mode DRX is enabled for a UE, the UE is reachable for paging in specific Paging Hyperframes (PH), which is a specific set of H-SFN values. The PH computation is a formula that is function of the extended idle mode DRX cycle, and a UE specific identifier, as described in TS 36.304 [52] and TS 38.304 [50]. This value can be computed at all UEs and AMFs without need for signalling. The AMF includes the extended idle mode DRX cycle length and the PTW length in paging message to assist the NG-RAN nodes in paging the UE.

The AMF also assigns a Paging Time Window length, and provides this value to the UE during Registration Update procedures together with the extended idle mode DRX cycle length. The UE first paging occasion is within the Paging Hyperframe as described in TS 36.304 [52] and TS 38.304 [50]. The UE is assumed reachable for paging within the Paging Time Window. The start and end of the Paging Time Window is described in TS 36.304 [52] and TS 38.304 [50]. After the Paging Time Window length, the AMF considers the UE unreachable for paging until the next Paging Hyperfame.

5.31.7.2.2.2 Loose Hyper SFN synchronization

NOTE: This clause applies for extended DRX cycle lengths of 10.24s or longer.

In order for the UE to be paged at roughly similar time, the H-SFN of all NG-RAN nodes and AMFs should be loosely synchronized.

Each NG-RAN node and AMF synchronizes internally the H-SFN counter so that the start of H-SFN=0 coincides with the same a preconfigured time epoch. If NG-RAN nodes and AMFs use different epochs, e.g. due to the use of different time references, the GPS time should be set as the baseline, and the NG-RAN nodes and AMFs synchronize the H-SFN counter based on the GPS epoch considering the time offset between GPS epoch and other time-reference epoch a preconfigured time. It is assumed that NG-RAN nodes and AMFs are able to use the same H-SFN value with accuracy in the order of legacy DRX cycle lengths, e.g. 1 to 2 seconds. There is no need for synchronization at SFN level.

There is no signalling between network nodes required to achieve this level of loose H-SFN synchronization.

5.31.7.2.2.3 AMF paging and paging retransmission strategy

NOTE: This clause applies for extended DRX cycle lengths of 10.24s or longer.

When the AMF receives trigger for paging and the UE is reachable for paging, the AMF sends the paging request. If the UE is not reachable for paging, then the AMF pages the UE just before the next paging occasion.

The AMF determines the Paging Time Window length and a paging retransmission strategy, and executes the retransmission scheme.

For extended DRX length of 10.24s, in the paging request message the AMF sends the Paging Time Window to the ng-eNB but does not send the Paging Time Window to the gNB.

5.31.7.2.3 Paging for a UE registered in a tracking area with heterogeneous support of extended idle mode DRX

When the UE is registered in a registration area with heterogeneous support of extended idle mode DRX (e.g. comprising WB-E-UTRA and NR cells) and has negotiated eDRX, the AMF shall, for any paging procedure, perform at least one paging attempt during a PTW.

NOTE: Heterogeneous support of extended idle mode DRX in tracking areas assigned by AMF in a TAI list can result in significant battery life reduction in the UE as compared to homogeneous support by NG-RAN nodes of extended idle mode DRX.

5.31.7.2.4 Paging for extended DRX for RRC-INACTIVE in NR connected to 5GC

For NR, the NG-RAN may request the CN to handle mobile terminated (MT) communication for the UE configured with eDRX for RRC-INACTIVE state by means of the Connection Inactive procedure with CN based MT communication handling Procedure (see clause 4.8.1.1a of TS 23.502 [3]). This allows the CN to apply high latency communication functions as specified in clause 5.31.8. The NG-RAN provides the eDRX cycle value for RRC-INACTIVE to AMF (i.e. >10.24s). Based on the request from NG-RAN, the AMF responds to NG-RAN and informs other NFs (e.g. SMF and UPF) involved in downlink data handling and trigger the data buffering as specified in clause 4.8.1.1a of TS 23.502 [3].

When MT data or signalling arrives for a UE in RRC-INACTIVE state, the other NFs communicate with the AMF for delivery of MT data or signalling. The AMF calculates the UE reachability based on the eDRX cycle value for RRC-INACTIVE state provided by NG-RAN and triggers NG-RAN paging via an N2 message if the UE is considered reachable as specified in clause 4.8.2.2b of TS 23.502 [3], otherwise the AMF informs other NFs applying high latency communication functions as specified in clause 5.31.8 based on eDRX cycle for RRC-INACTIVE (e.g. an Estimated Maximum Wait Time is calculated based on eDRX cycle value for RRC-INACTIVE).

When the UE enters RRC-CONNECTED state if the NG-RAN had indicated to the CN about the RRC-INACTIVE state, NG-RAN informs the AMF that the UE is now in RRC-CONNECTED state as specified in clause 4.8.2.2 of TS 23.502 [3]. The AMF then informs other NFs that the UE is now reachable using the high latency communication functions as specified in clause 5.31.8 and MT data and signalling can be delivered to the UE.

5.31.7.3 MICO mode with Extended Connected Time

When a UE, using MICO mode, initiates MO signalling or MO data and the AMF is aware of pending or expected MT traffic, the AMF may keep the UE in CM-CONNECTED state and the RAN may keep the UE in RRC-CONNECTED state for an Extended Connected Time period in order to ensure the downlink data and/or signalling is delivered to the UE. The Extended Connected Time is determined by the AMF and is based on local configuration and/or the Maximum Response Time, if provided by the UDM.

The AMF maintains the N2 connection for at least the Extended Connected Time and provides the Extended Connected Time value to the RAN. The Extended Connected Time value indicates the minimum time the RAN should keep the UE in RRC-CONNECTED state regardless of inactivity. The Extended Connected Time value is provided to the RAN together with the

– NAS Registration Accept message; or

– NAS Service Accept message.

At inter-RAN node handovers, if some signalling or data are still pending, the target AMF may send the Extended Connected Time value to the target RAN node.

5.31.7.4 MICO mode with Active Time

During a Registration procedure the UE may optionally request an Active Time value from the AMF as part of MICO Mode negotiation. In response, if the AMF receives an Active Time value from the UE and determines that the MICO mode is allowed for the UE, the AMF may assign an Active Time value for the UE, e.g. based on local configuration, Expected UE Behaviour if available, UE requested Active Time value, UE subscription information and network policies, and indicates it to the UE during Registration procedure. When an Active Time value is assigned to the UE the AMF shall consider the UE reachable for paging after the transition from CM-CONNECTED to CM-IDLE for the duration of the Active Time. Together with the Active Time value, the UE may request a periodic registration time value as specified in clause 5.31.7.45.

When the AMF indicates MICO mode with an Active Time to a UE, the registration area may be constrained by paging area size. To avoid paging in the entire PLMN, when the AMF allocates the Active Time the AMF should not allocate "all PLMN" registration area to the UE.

The UE and AMF shall set a timer corresponding to the Active Time value negotiated during the most recent Registration procedure. The UE and AMF shall start the timer upon entering CM-IDLE state from CM-CONNECTED. When the timer expires (i.e. reaches the Active Time) the UE enters MICO mode and the AMF can deduce that the UE has entered MICO mode and is not available for paging. If the UE enters CM-CONNECTED state before the timer expires, the UE and AMF shall stop and reset the timer.

If no Active Time value was negotiated during the most recent Registration procedure the UE shall not start the timer and it shall instead enter MICO mode directly upon entering CM-IDLE state.

Active Time is not transferred between AMF and MME.

5.31.7.5 MICO mode and Periodic Registration Timer Control

If the Expected UE Behaviour indicates the absence of DL communication, the AMF may allow MICO mode for the UE and allocate a large periodic registration timer value based on e.g. Network Configuration parameters to the UE so that the UE can maximise power saving between Periodic Registration Updates.

If the Expected UE Behaviour indicates scheduled DL communication the AMF should allow MICO mode for the UE and allocate a periodic registration timer value such that the UE performs Periodic Registration Update to renegotiate MICO mode before or at the scheduled DL communication time, if the AMF decides to allow MICO mode for the UE. When UE requests the MICO mode with active time, the UE may also request a periodic registration timer value suitable for the latency/responsiveness of the DL communication service known to UE. If the UE wants to change the periodic registration timer value, e.g. when the conditions are changed in the UE, the UE consequently requests the value it wants in the registration procedure. The AMF takes the UE requested periodic registration time value into consideration when providing the periodic registration timer to UE during Registration procedure as specified in clause 4.2.2.2.2 of TS 23.502 [3].

If the UE supports ‘Strictly Periodic Registration Timer Indication’, the UE indicates its capability of supporting ‘Strictly Periodic Registration Timer Indication’ in the Registration Request message. If the UE indicates its support of ‘Strictly Periodic Registration Timer Indication’ in the Registration Request message, the AMF may provide a Strictly Periodic Registration Timer Indication to the UE together with the periodic registration timer value, e.g. based on Expected UE Behaviour. If the indication is provided by the AMF, the UE and the AMF shall start the periodic registration timer after completion of the Registration procedure. The UE and the AMF shall neither stop nor restart the periodic registration timer when the UE enters CM-CONNECTED, and shall keep it running while in CM-CONNECTED state and after returning to CM-IDLE state. If and only when the timer expires and the UE is in CM-IDLE, the UE shall perform a Periodic Registration Update. If the timer expires and the UE is in CM-CONNECTED state, the AMF and the UE restart the periodic registration timer while still applying ‘Strictly Periodic Registration Timer Indication’. The AMF may use the UE Configuration Update procedure to trigger the UE to perform Registration procedure, in which the periodic registration timer value and ‘Strictly Periodic Registration Timer Indication’ can be renegotiated.

When the UE and the AMF locally disable MICO mode (e.g. when an emergency service is initiated), the UE and the AMF shall not apply ‘Strictly Periodic Registration Timer Indication’.

If the periodic registration timer is renegotiated during a Registration procedure, e.g. triggered by UE Configuration Update, and if the periodic registration timer is running, then the periodic registration timer is stopped and restarted using the renegotiated value even when the Strictly Periodic Registration Timer Indication was provided to the UE.

5.31.8 High latency communication

Functions for High latency communication may be used to handle mobile terminated (MT) communication with UEs being unreachable while using power saving functions as specified in clause 5.31.7. "High latency" refers to the initial response time before normal exchange of packets is established. That is, the time it takes before a UE has woken up from its power saving state and responded to an initial downlink packet or signal.

When a NR RedCap UE requests to use the power saving functions as specified in clause 5.31.7, then the AMF may, based on local policy, reroute the Registration Request to another AMF that supports High latency communication as specified in clause 6.3.5.

High latency communication is supported by extended buffering of downlink data in the UPF, SMF or NEF when a UE is using power saving functions in CM-IDLE state or in RRC-INACTIVE state and the UE is not reachable. For UPF anchored PDU sessions the SMF configures during AN release or when NG-RAN indicates via the AMF the UE is in extended DRX for RRC-INACTIVE, the UPF with user data Forwarding Action Rule and user data Buffering Action Rule according to TS 29.244 [65]. The rules include instructions whether UPF buffering applies or the user data shall be forwarded to the SMF for buffering in the SMF. For NEF anchored PDU sessions only extended buffering in the NEF is supported in this release of the specification. During the Network Triggered Service Request procedure or Mobile Terminated Data Transport procedures when using Control Plane CIoT 5GS Optimisation, the AMF provides an Estimated Maximum Wait Time to the SMF if the SMF indicates the support of extended buffering. The SMF determines the Extended Buffering Time based on the received Estimated Maximum Wait Time or local configuration. The handling is e.g. specified in the Network Triggered Service Request procedure, clauses 4.2.3.3, 4.2.6, 4.24.2 and 4.25.5 of TS 23.502 [3].

High latency communication is also supported through notification procedures. The following procedures are available based on different monitoring events:

– UE Reachability;

– Availability after DDN failure;

– Downlink Data Delivery Status.

An AF may request a one-time "UE Reachability" notification when it wants to send data to a UE which is using a power saving function (see event subscription procedure in clause 4.15.3.2 of TS 23.502 [3]). The SCS/AS/AF then waits with sending the data until it gets a notification that the UE is reachable (see notification procedures in TS 23.502 [3]).

An AF may request repeated "Availability after DDN failure" notifications where each UE reachability notification is triggered by a preceding DDN failure, i.e. the AF sends a downlink packet to request a UE reachability notification when the UE becomes reachable. That downlink packet is discarded by the UPF or SMF or NEF (see notification procedures in TS 23.502 [3]).

An AF may request repeated "Downlink Data Delivery Status" notifications when it wants indications that DL data has been buffered or when buffered DL data has been delivered to the UE.

If MICO mode or extended idle mode DRX is enabled, Idle Status Indication allows the AF to determine when the UE transitions into idle mode. When requesting to be informed of either "UE Reachability" or "Availability after DDN failure" notification, the AF may also request Idle Status Indication. If the UDM and the AMF support Idle Status Indication, then when the UE for which MICO mode or extended idle mode DRX is enabled transitions into idle mode, the AMF includes in the notification towards the NEF the time at which the UE transitioned into idle mode, the active time and the periodic registration update timer granted to the UE by the AMF, the eDRX cycle length and the Suggested number of downlink packets if a value was provided to the SMF.

An AF may provide parameters related to High latency communication for different methods to UDM, via NEF, as part of provisioning capability as specified in clause 5.20. The UDM can further deliver the parameters to other NFs (e.g. AMF or SMF) as specified in clause 4.15.6 of TS 23.502 [3].

If the AMF is aware that some signalling or data is pending in the network for an UE that is known as being unreachable for a long duration, e.g. for UE’s having extended idle mode DRX, extended DRX for RRC-INACTIVE or MICO enabled, the AMF maintains the N2 connection for at least the Extended Connected Time and provides the Extended Connected Time value in a NG-AP message to the RAN. The Extended Connected Time value indicates the minimum time the RAN should keep the UE in RRC-CONNECTED state regardless of inactivity. At inter-RAN node handovers, if some signalling or data are still pending, the target AMF may send the Extended Connected Time value to the target RAN node.

5.31.9 Support for Monitoring Events

The Monitoring Events feature is intended for monitoring of specific events in the 3GPP system and reporting such Monitoring Events via the NEF. The feature allows NFs in 5GS to be configured to detect specific events and report the events to the requested party. Clause 5.20 further discusses the Monitoring capabilities of the NEF.

For CIoT, the list of supported monitoring events is specified in Table 4.15.3.1-1 of TS 23.502 [3].

Support for Monitoring Events can be offered via AMF, UDM, NSACF and SMF, and can be reported via the NEF, as specified in clause 4.15.3 of TS 23.502 [3].

5.31.10 NB-IoT UE Radio Capability Handling

NB-IoT Radio Capabilities are handled in the network independently from other RATs’ Radio Capabilities, see clause 5.4.4.1.

5.31.11 Inter-RAT idle mode mobility to and from NB-IoT

Tracking Areas are configured so that they do not contain both NB-IoT and other RATs’ cells, so when the UE is changing RAT type to or from NB-IoT while remaining registered with 5GC, the UE will perform the Mobility Registration Update procedure, see clause 5.3.2.3. When the UE is changing RAT type to or from NB-IoT and moving between 5GC and EPC, during the Registration, Attach or TAU procedure the RAT type change is determined.

The specification in this clause does not apply to RAT type corresponding to Non-3GPP Access type.

PDU session handling is controlled by "PDU Session continuity at inter RAT mobility" in the UE’s subscription data, which indicates per DNN/S-NSSAI whether to;

– maintain the PDU session,

– disconnect the PDU session with a reactivation request,

– disconnect the PDU session without reactivation request, or

– leave it up to local VPLMN policy

when the UE moves between a "broadband" RAT (e.g. NR or WB-E-UTRA) and a "narrowband" RAT (NB-IoT).

During PDU session establishment the SMF retrieves the "PDU Session continuity at inter RAT mobility" subscription information (if available) from the UDM. Local SMF configuration is used if "PDU Session continuity at inter RAT mobility" is not available for a PDU Session.

The AMF informs the SMF at an inter-RAT idle mobility event, e.g. to or from NB-IoT connected to 5GC about the RAT type change in the Nsmf_PDUSession_UpdateSMContext message during the Registration procedure. Based on this (H-)SMF handles the PDU session according to "PDU session continuity at inter RAT mobility information" subscription data or based on local policy.

NOTE: The "PDU Session continuity at inter RAT mobility" and "PDN continuity at inter-RAT mobility" subscription should be the same so that the PDU sessions/PDN connections are handled the same by both CN types.

During inter-RAT idle mode mobility to NB-IoT, if a PDU session has more than one QoS rule, the SMF shall initiate a PDU session modification procedure as described in TS 23.502 [3] to remove any non-default QoS rule, and maintain only the default QoS rule.

5.31.12 Restriction of use of Enhanced Coverage

Support of UEs in Enhanced Coverage is specified in TS 36.300 [30].

The usage of Enhanced Coverage requires use of extensive resources (e.g. radio and signalling resources). Specific subscribers can be restricted to use the Enhanced Coverage feature through Enhanced Coverage Restricted information that is stored in the UDM as part of subscription data and specifies per PLMN whether the Enhanced Coverage functionality is restricted or not for the UE. For eMTC, the Enhanced Coverage Restricted information indicates whether CE mode B is restricted for the UE, or both CE mode A and CE mode B are restricted for the UE, or both CE mode A and CE mode B are not restricted for the UE. For NB-IoT, the NB-IoT Enhanced Coverage Restricted information indicates whether the Enhanced Coverage is restricted or not for the UE.

The AMF receives Enhanced Coverage Restricted information from the UDM during the Registration procedure. If the UE includes the support for restriction of use of Enhanced Coverage in the Registration Request message, the AMF based on local configuration, UE Usage setting, UE subscription information and network policies, or any combination of them, determines whether Enhanced Coverage is restricted for the UE and stores updated Enhanced Coverage Restriction information in the UE context in the AMF. If the UE usage setting indicated that UE is "voice centric", then the AMF shall set CE mode B restricted for the UE in Enhanced Coverage Restriction information.

The AMF sends Enhanced Coverage Restricted information to the UE in the Registration Accept message. The UE shall use the value of Enhanced Coverage Restricted information to determine if enhanced coverage feature is restricted or not. The AMF provides an Enhanced Coverage Restricted information to the RAN via N2 signalling whenever the UE context is established in the RAN, e.g. during N2 Paging procedure, Service Request procedure, Initial Registration and Periodic Registration procedure.

For roaming UEs, if the UDM doesn’t provide any Enhanced Coverage Restricted information or the provided Enhanced Coverage Restricted information is in conflict with the roaming agreement, the AMF uses default Enhanced Coverage Restricted information locally configured in the VPLMN based on the roaming agreement with the subscriber’s HPLMN.

The UE indicates its capability of support for restriction of use of Enhanced Coverage to the AMF in the Registration procedure for the RAT it is camping on. A UE that supports Enhanced Coverage shall also support restriction of the Enhanced Coverage.

The UE shall assume that restriction for use of Enhanced Coverage indicated by Enhanced Coverage Restricted information is the same in the equivalent PLMNs. NB-IoT cells also broadcast the support of restriction of use of Enhanced Coverage as defined in TS 36.331 [51].

If the UE supports CE mode B and use of CE mode B is not restricted according to the Enhanced Coverage Restriction information in the UE context in the AMF, then the AMF shall use the extended NAS-MM timer setting for the UE as specified in TS 24.501 [47] and shall send the extended NAS-SM timer indication during PDU session establishment to the SMF.

If the UE supports CE mode B and use of CE mode B changes from restricted to unrestricted or vice versa in the Enhanced Coverage Restriction information in the UE context in the AMF (e.g. due to a subscription change) then:

– The AMF determines when to enforce the change of restriction of use of Enhanced Coverage.

– When the UE is in CM-CONNECTED mode, the AMF can use the UE Configuration Update procedure, as specified in step 3a of clause 4.2.4.2 of TS 23.502 [3], to trigger a mobility registration update procedure in CM-CONNECTED mode for the AMF to inform the change of restriction of Enhanced Coverage towards the UE.

– If the UE has already established PDU sessions, then the AMF shall trigger a PDU session modification to the SMFs serving the UE’s PDU sessions to update the use of the extended NAS-SM timer setting as described in step 1f of clause 4.3.3.2 of TS 23.502 [3] when the AMF determines that NAS-SM timer shall be updated due to the change of Enhanced Coverage Restriction.

– The UE and network applies the new Enhanced Coverage Restriction information after mobility registration procedure is completed.

Based on the extended NAS-SM timer indication, the SMF shall use the extended NAS-SM timer setting for the UE as specified in TS 24.501 [47].

The support for Enhanced Coverage Restriction Control via NEF enables AF to query status of Enhanced Coverage Restriction or enable/disable Enhanced Coverage Restriction per individual UEs. The procedure for Enhanced Coverage Restriction Control via NEF is described in clause 4.27 of TS 23.502 [3].

5.31.13 Paging for Enhanced Coverage

Support of UEs in Enhanced Coverage is specified in TS 36.300 [30].

Whenever N2 is released and Paging Assistance Data for CE capable UE is available for the UE, the NG-RAN sends it to the AMF as described in clause 4.2.6 of TS 23.502 [3].

The AMF stores the received Paging Assistance Data for CE capable UE and then the AMF includes it in every subsequent Paging message for all NG-RAN nodes selected by the AMF for paging.

If Enhanced Coverage is restricted for the UE as described in clause 5.31.12, the AMF sends the Enhanced Coverage Restriction parameter as defined in TS 38.413 [34].

NOTE: Only the NG-RAN node which cell ID is included in the Paging Assistance Data considers the assistance data.

5.31.14 Support of rate control of user data

5.31.14.1 General

The rate of user data sent to and from a UE (e.g. a UE using CIoT 5GS Optimisations) can be controlled in two different ways:

– Serving PLMN Rate Control;

– Small Data Rate Control.

Serving PLMN Rate Control is intended to allow the Serving PLMN to protect its AMF and the Signalling Radio Bearers in the NG-RAN from the load generated by NAS Data PDUs.

Small Data Rate Control is intended to allow HPLMN operators to offer customer services such as "maximum of Y messages per day".

NOTE: Existing Session-AMBR mechanisms are not suitable for such a service since, for radio efficiency and UE battery life reasons, an AMBR of e.g. > 100kbit/s is desirable and such an AMBR translates to a potentially large daily data volume.

The SMF in the Serving PLMN may send the Small Data rate control parameter for an emergency PDU session.

5.31.14.2 Serving PLMN Rate Control

The Serving PLMN Rate Control value is configured in the (V-)SMF.

NOTE 1: Homogeneous support of Serving PLMN Rate Control in a network is assumed.

At PDU Session establishment and PDU Session modification, the (V-)SMF may inform the UE and UPF/NEF of any per PDU Session local Serving PLMN Rate Control that the Serving PLMN intends to enforce for NAS Data PDUs. The (V-)SMF shall only indicate a Serving PLMN Rate Control command to the UPF if the PDU Session is using N4 and is set to Control Plane only. The (V-)SMF shall only indicate a Serving PLMN Rate Control command to the NEF if that PDN connection is using NEF.

Serving PLMN rate control is operator configurable and expressed as "X NAS Data PDUs per deci hour" where X is an integer that shall not be less than 10. There are separate limits for uplink and downlink NAS Data PDUs:

– The UE shall limit the rate at which it generates uplink NAS Data PDUs to comply with the Serving PLMN policy. In the UE the indicated rate control applies only on the PDU Session where it was received, and therefore the UE shall limit the rate of its uplink NAS Data PDUs to comply with the rate that is indicated for the PDU Session. The indicated rate is valid until the PDU Session is released.

– The UPF/NEF shall limit the rate at which it generates downlink Data PDUs. In the UPF/NEF the indicated rate control applies only on the PDU Session where it was received, and therefore the UPF/NEF shall limit the rate of its downlink Data PDUs to comply with the rate that is indicated for the PDU Session.

– The (V-)SMF may enforce these limits per PDU Session by discarding or delaying packets that exceed these limits. The Serving PLMN Rate does not include SMS using NAS Transport PDUs. The (V-)SMF starts the Serving PLMN Rate Control when the first NAS Data PDU is received.

NOTE 2: If the UE/UPF/NEF start the Serving PLMN rate control at a different time than the (V-)SMF, PDUs sent within the limit enforced at the UE/UPF/NEF can still exceed the limit enforced by the (V-)SMF.

NOTE 3 It is assumed that the Serving PLMN Rate is sufficiently high to not interfere with the Small Data Rate Control as the Small Data Rate Control, if used, is assumed to allow fewer messages. NAS PDUs related to exception reports are not subject to the Serving PLMN Rate Control.

5.31.14.3 Small Data Rate Control

The (H-)SMF may consider, e.g. based on operator policy, subscription, DNN, S-NSSAI, RAT type etc. to determine whether to apply Small Data Rate Control or not. The (H-)SMF can send a Small Data Uplink Rate Control command to the UE using the PCO information element. The (H-)SMF informs the UPF or NEF of any Small Data Rate Control that shall be enforced.

The Small Data Rate Control applies to data PDUs sent on that PDU Session by either Data Radio Bearers or Signalling Radio Bearers (NAS Data PDUs).

The rate control information is separate for uplink and downlink and in the form of:

– an integer ‘number of packets per time unit’, and

– an integer ‘number of additional allowed exception report packets per time unit’ once the rate control limit has been reached.

The UE shall comply with this uplink rate control instruction. If the UE exceeds the uplink ‘number of packets per time unit’, the UE may still send uplink exception reports if allowed and the ‘number of additional allowed exception reports per time unit’ has not been exceeded. The UE shall consider this rate control instruction as valid until it receives a new one from (H-)SMF.

When a PDU Session is first established, the (H-)SMF may provide the configured Small Data Rate Control parameters to the UE and UPF or NEF.

When the PDU Session is released, the Small Data Rate Control Status (including the number of packets still allowed in the given time unit, the number of additional exception reports still allowed in the given time unit and the termination time of the current Small Data Rate Control validity period) may be stored in the AMF so that it can be retrieved for a subsequent re-establishment of a new PDU Session.

At subsequent establishment of a new PDU Session, the (H-)SMF may receive the previously stored Small Data Rate Control Status and if the validity period has not expired, it provides the parameters to the UE in the PCO and to the UPF/NEF as the initially applied parameters, in addition to the configured Small Data Rate Control parameters. If the initially applied parameters are provided, the UE and UPF or NEF shall apply them and shall use the SMF provided configured Small Data Rate Control parameters once the initially applied Small Data Rate Control validity period expires.

NOTE 1: Storage of Small Data Rate Control Status information for very long time intervals can be implementation specific.

For the UPF and NEF, Small Data Rate Control is based on a ‘maximum allowed rate’ per direction. If (H-)SMF provided the ‘number of additional allowed exception report packets per time unit’, then the ‘maximum allowed rate’ is equal to the ‘number of packets per time unit’ plus the ‘number of additional allowed exception report packets per time unit’, otherwise the ‘maximum allowed rate’ is equal to the ‘number of packets per time unit’.

The UPF or NEF may enforce the uplink rate by discarding or delaying packets that exceed the ‘maximum allowed rate’. The UPF or NEF shall enforce the downlink rate by discarding or delaying packets that exceed the downlink part of the ‘maximum allowed rate’.

NOTE 2: It is assumed that the Serving PLMN Rate is sufficiently high to not interfere with the Small Data Rate Control as the Small Data Rate Control, if used, is assumed to allow fewer messages. NAS PDUs related to exception reports are not subject to the Serving PLMN Rate Control.

For NB-IoT the AMF maintains an "MO Exception Data Counter" which is incremented when the RRC establishment cause "MO exception data" is received from NG-RAN. The AMF reports whether the UE accessed using "MO exception data" RRC establishment cause, to all (H-)SMFs which have PDU Sessions that are subject to Small Data Rate Control and if the UE is accessing using "MO exception data" then the "MO Exception Data Counter" is also provided by the AMF. The SMF indicates each use of the RRC establishment cause "MO Exception Data" by including the related counter on the charging information.

NOTE 3: Since Exception Data PDUs and normal priority PDUs cannot be distinguished within an RRC connection, the AMF is only counting the number of RRC Connection establishments with "MO Exception data" priority.

If the UE moves to EPC then the UE and the PGW-U+UPF store the current Small Data Rate Control Status for all PDU Sessions that are not released. If the UE moves back to 5GC the stored Small Data Rate Control Status is restored and continues to apply to PDU Session(s) that are moved from EPC to 5GC, taking into account remaining validity period of the stored Small Data Rate Control Status. When the UE moves to EPC the Small Data Rate Control Status for all PDU Session(s) may also be stored in the AMF if the PDU Session is released while the UE is connected to EPC and re-established when the UE moves to 5GC. The time to store the Small Data Rate Control Status information is implementation specific.

5.31.15 Control Plane Data Transfer Congestion Control

NAS level congestion control may be applied in general for all NAS messages. To enable congestion control for control plane data transfer, a Control Plane data back-off timer is used, see clause 5.19.7.6.

5.31.16 Service Gap Control

Service Gap Control is an optional feature intended for CIoT UEs to control the frequency at which these UEs can access the network. That is, to ensure a minimum time gap between consecutive Mobile Originated data communications initiated by the UE. This helps reducing peak load situations when there are a large number of these UEs in an operator network. Service Gap Control is intended to be used for "small data allowance plans" for MTC/CIoT UEs where the applications are tolerant to service latency.

NOTE 1: Time critical applications, such as regulatory prioritized services like Emergency services can suffer from the latency caused by the Service Gap Control feature. Therefore Service Gap Control feature is not recommended for subscriptions with such applications and services.

Service Gap Time is a subscription parameter used to set the Service Gap timer and is enforced in the UE and in the AMF on a per UE level (i.e. the same Service Gap Timer applies for all PDU Sessions that the UE has). The UE indicates its capability of support for Service Gap Control in the Registration Request message to the AMF. The AMF passes the Service Gap Time to the UE in the Registration Accept message for a UE that has indicated its support of the Service Gap Control. The Service Gap Control shall be applied in a UE when a Service Gap Time is stored in the UE context and applied in the AMF when the Service Gap Time is stored in the UE Context in the AMF.

Service Gap Control requires the UE to stay in CM-IDLE mode for at least the whole duration of the Service Gap timer before triggering Mobile Originated user data transmission, except for procedures that are exempted (see TS 24.501 [47]). The Service Gap timer shall be started each time a UE moves from CM-CONNECTED to CM-IDLE, unless the connection request was initiated by the paging of a Mobile Terminated event, or after a Mobility or Periodic Registration procedure without Follow-on Request indication and without Uplink data status, which shall not trigger a new or extended Service Gap interval. When a Service Gap timer expires, the UE is allowed to send a connection request again. If the UE does so, the Service Gap timer will be restarted at the next CM-CONNECTED to CM-IDLE transition.

The Service Gap control is applied in CM-IDLE state only and does not impact UE Mobile Originated user data transmission or Mobile Originated signalling in CM-CONNECTED state. The Service Gap timer is not stopped upon CM-IDLE state to CM-CONNECTED state transition. The UE shall not initiate connection requests for MO user plane data, MO control plane data, or MO SMS when a Service Gap timer is running. The UE shall not initiate PDU Session Establishment Requests when a Service Gap timer is running, unless it is for Emergency services which are allowed. CM-CONNECTED with RRC_INACTIVE is not used for UEs that have a Service Gap Time configured.

NOTE 2: As a consequence of allowing Initial Registration Request procedure, the UE with a running Service Gap timer does not initiate further MO signalling, except for Mobility Registration procedure, until the UE receives MT signalling or after the UE has moved to CM-IDLE state and the Service Gap Timer is not running.

NOTE 3: Implementations need to make sure that latest and up-to-date data are always sent when a Service Gap timer expires.

The AMF may enforce the Service Gap timer by rejecting connection requests for MO user plane data, MO control plane data, or MO SMS when a Service Gap timer is running. The AMF may enforce the Service Gap timer by not allowing MO signalling after Initial Registration requests when a Service Gap timer is running except for Mobility Registration procedure, Periodic Registration procedure or access to the network for regulatory prioritized services like Emergency services, which are allowed. When rejecting the connection requests and the SM signalling after Initial Registration Requests while the Service Gap timer is running, the AMF may include a Mobility Management back-off timer corresponding to the time left of the current Service Gap timer. For UEs that do not support Service Gap Control (e.g. pre-release-16 UEs), Service Gap Control may be enforced using "General NAS level congestion control" as defined in clause 5.19.7.2.

NOTE 4: After MT signalling in CM-CONNECTED state the AMF does not further restrict MO signalling when a Service Gap timer is running as this case is considered equal to a connectivity request in response to paging.

When the AMF starts the Service Gap timer, the AMF should invoke the Service Gap timer with a value that is slightly shorter than the Service Gap Time value provided to the UE based on the subscription information received from the UDM.

NOTE 5: This ensures that the AMF does not reject any UE requests just before the Service Gap timer expires e.g. because of slightly unsynchronized timers between UE and AMF.

A UE which transitions from a MICO mode or eDRX power saving state shall apply Service Gap Control when it wakes up if the Service Gap timer is still running.

Additional aspects of Service Gap Control:

– Service Gap Control applies in all PLMNs.

– When the Service Gap timer is running and the UE receives paging, the UE shall respond as normal.

– Service Gap Control does not apply to exception reporting for NB-IoT.

– Access to the network for regulatory prioritized services like Emergency services are allowed when a Service Gap timer is running.

– Service Gap Control shall be effective also for UEs performing de-registration and re-registration unless access to the network for regulatory prioritized services like Emergency services is required.

– If the Service Gap timer is running, the Service Gap is applied at PLMN selection as follows:

a) Re-registration to the registered PLMN: The remaining Service Gap timer value survives.

b) Registration to a different PLMN: The remaining Service Gap timer value survives.

c) USIM swap: The Service Gap timer is no longer running and the Service Gap feature does not apply, unless re-instantiated by the serving PLMN.

– Multiple uplink packets and downlink packets are allowed during one RRC connection for UE operating within its Rate Control limits.

The following procedures are impacted by Service Gap Control:

– Registration Procedure, see clause 4.2.2.2 of TS 23.502 [3];

– UE Triggered Service Request, see clause 4.2.3.2 of TS 23.502 [3];

NOTE 6: Since UE triggered Service Request is prevented by Service Gap timer, this implicitly prevents the UE from initiating UPF anchored Mobile Originated Data Transport in Control Plane CIoT 5GS Optimisation (see clause 4.24.1 of TS 23.502 [3]), NEF Anchored Mobile Originated Data Transport (see clause 4.25.4 of TS 23.502 [3]) and MO SMS over NAS in CM-IDLE (see clause 4.13.3.3 of TS 23.502 [3]).

5.31.17 Inter-UE QoS for NB-IoT

To allow NG-RAN to prioritise resource allocation between different UEs accessing via NB-IoT when some of the UEs are using Control Plane CIoT 5GS Optimisation, NG-RAN may, based on configuration, retrieve from the AMF the subscribed NB-IoT UE Priority for any UE accessing via NB-IoT by using the UE’s 5G-S-TMSI as the identifier.

In order to reduce signalling load on the AMF, NG-RAN may be configured to request the NB-IoT UE Priority from the AMF e.g. only when the NG-RAN’s NB-IoT load exceeds certain threshold(s) or when the NG-RAN needs to cache the QoS profile.

5.31.18 User Plane CIoT 5GS Optimisation

User Plane CIoT 5GS Optimisation enables transfer of user plane data from CM-IDLE without the need for using the Service Request procedure to establish Access Stratum (AS) context in NG-RAN and UE.

If the following preconditions are met:

– UE and AMF negotiated support User Plane CIoT 5GS Optimisation (see clause 5.31.2) over NAS,

– the UE has indicated support of User Plane CIoT 5GS Optimisation in the UE radio capabilities as defined in TS 36.331 [51],

– AMF has indicated User Plane CIoT 5GS Optimisation support for the UE to NG-RAN,

– the UE has established at least one PDU session with active UP connection, i.e. AS context is established in NG-RAN and the UE,

then the RRC connection can be suspended by means of the Connection Suspend Procedure (see clause 4.8.1.2 of TS 23.502 [3]).

Based on a trigger from the NAS layer when a UE is in CM-IDLE with Suspend, the UE should attempt the Connection Resume in CM-IDLE with Suspend procedure (clause 4.8.2.3 of TS 23.502 [3]). If the Connection Resume in CM-IDLE with Suspend procedure fails, the UE initiates the pending NAS procedure. To maintain support for User Plane CIoT 5GS Optimisation for UE mobility across different NG-RAN nodes, the AS Context should be transferred between the NG-RAN nodes, see TS 38.300 [27] and TS 38.423 [99].

By using the Connection Suspend Procedure:

– the UE at transition into CM-IDLE stores the AS information;

– NG-RAN stores the AS information, the NGAP UE association and the PDU session context for that UE;

– AMF stores the NGAP UE association and other information necessary to later resume the UE, interacts with the SMF(s) to deactivate the user plane resources for the UE’s PDU Sessions and enters CM-IDLE.

NG-RAN may decide based on implementation to delete the stored UE context and NGAP association. In that case, the RAN shall initiate the AN Release procedure as described in clause 4.2.6 of TS 23.502 [3]. NG-RAN does not initiate any RRC procedure to notify the UE of the UE context release.

By using the Connection Resume in CM-IDLE with Suspend procedure:

– the UE resumes the connection from CM-IDLE with the network using the AS information stored during the Connection Suspend procedure;

– NG-RAN notifies the AMF that the connection with the UE has been resumed;

– AMF enters CM-CONNECTED and interacts with the SMF to activate the user plane resources for the UE’s PDU Sessions.

Early Data Transmission may be initiated by the UE for mobile originated User Plane CIoT 5GS Optimisation during Connection Resume.

If the AMF establishes an NGAP UE association with a new NG-RAN node different from the stored NGAP UE association, e.g. the UE initiates service request or registration procedure from a different NG-RAN node, the AMF initiates UE N2 release command towards the old NG-RAN node.

NG-RAN maintains the N3 tunnel endpoint information while a UE is in CM-IDLE with Suspend. UPF is instructed to remove DL N3 Tunnel Info of AN during Connection Suspend procedure, while UPF keeps UL N3 Tunnel Info (i.e. UPF accepts and forwards UL data). If a UE sends MO data with resume procedure, the NG-RAN can send the MO data to the UPF which is addressed by the N3 tunnel endpoint information. In the case of change of serving NG-RAN node due to UE mobility, if NG-RAN determines that it is not able to connect to the UPF which is addressed by the N3 tunnel endpoint information, NG-RAN performs Path Switch procedure before sending the MO data received from the UE.

Early Data Transmission may be initiated by the UE for mobile originated User Plane CIoT 5GS Optimisation when the RAT Type is E-UTRA.

5.31.19 QoS model for NB-IoT

5GC QoS model described in clause 5.7 applies to NB-IoT with the following requirements:

– The default QoS rule shall be the only QoS rule of a PDU Session for a UE connected to 5GC via NB-IoT. There is only one QoS Flow (corresponding to the default QoS rule) per PDU session.

– Reflective QoS is not supported over NB-IoT.

– For NB-IoT, there is a 1:1 mapping between the QoS Flow corresponding to the default QoS of a PDU session and a Data Radio Bearer when user plane resources are active for that PDU session.

– A maximum of two Data Radio Bearers are supported over NB-IoT. Therefore, at most two PDU sessions can have active user plane resources at the same time.

– The capability of multiple UP resource support for NB-IoT UEs is indicated in the UE 5GMM Core Network Capability (see TS 24.501 [47]). During PDU Session Establishment or UP resource activation, the AMF checks if the UE can support the establishment of user plane resources (See clause 4.2.3.2 and clause 4.3.2.2.1 of TS 23.502 [3]).

5.31.20 Category M UEs differentiation

This functionality is used by the network to identify traffic to/from Category M UEs, e.g. for charging differentiation.

A Category M UE using E-UTRA shall provide a Category M indication to the NG-RAN during RRC Connection Establishment procedure as defined in TS 36.331 [51].

When the UE has provided a Category M indication to the NG-RAN during RRC Connection Establishment, the NG-RAN shall provide an LTE-M Indication to the AMF in the Initial UE Message (see clause 4.2.2.2.1 of TS 23.502 [3] and TS 38.413 [34]).

When the AMF receives an LTE-M Indication from NG-RAN in an Initial UE Message or from an MME during EPS to 5GS handover, the AMF shall store the LTE-M Indication in the UE context, consider that the RAT type is LTE-M and signal it accordingly to the SMSF during registration procedure for SMS over NAS, to the SMF during PDU Session Establishment or PDU Session Modification procedure. The PCF will also receive the RAT Type as LTE-M, when applicable, from the SMF during SM Policy Association Establishment or SM Policy Association Modification procedure.

The NFs generating CDRs shall include the LTE-M RAT type in their CDRs.

Upon AMF change or inter-system mobility from 5GS to EPS, the source AMF shall provide the "LTE-M Indication" to the target AMF or MME as part of the UE context.

During EPS to 5GS Mobility Registration Procedure, the AMF shall disregard any "LTE-M Indication" received from the MME in the UE context (see TS 23.401 [26]), and take into account the "LTE-M Indication" received from NG-RAN, as specified above.