Content for  TS 23.501  Word version:  18.5.0

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. Cellular IoT is in earlier 3GPP releases also referred to as Machine Type Communication (MTC) (see clause 4.3.17 of TS 23.401). The specific functionality is described in the affected procedures and features of this specification, in TS 23.502, TS 23.503 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, 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.

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

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

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

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

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 or due to discontinuous coverage as described in clause 5.4.13. "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, or when the UE is using a satellite access with discontinuous coverage 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. 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. 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). 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). 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). 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. 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.

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

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

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. 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 to remove any non-default QoS rule, and maintain only the default QoS rule.

Support of UEs in E-UTRA Enhanced Coverage is specified in TS 36.300. 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. 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 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, 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 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. 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.

Support of UEs in E-UTRA Enhanced Coverage is specified in TS 36.300. 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. 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.

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.

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. 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). 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. 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. 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. 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:
  1. Re-registration to the registered PLMN: The remaining Service Gap timer value survives.
  2. Registration to a different PLMN: The remaining Service Gap timer value survives.
  3. 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;
• UE Triggered Service Request, see clause 4.2.3.2 of TS 23.502;

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.

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,
• 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). 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). 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 and TS 38.423. For MT data or signalling when the UE is in CM-IDLE with Suspend, Network Triggered Service Request procedure (clause 4.2.3.3 of TS 23.502) applies. 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. 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.

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

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. 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 and TS 38.413). 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), and take into account the "LTE-M Indication" received from NG-RAN, as specified above.