4.3.17 Support for Machine Type Communications (MTC)

23.4013GPPGeneral Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) accessRelease 18TS

4.3.17.1 General

This clause provides an overview about functionality for Machine Type Communications according to service requirements described in TS 22.368 [66]. The specific functionality is described in the affected procedures and features of this and other specifications. For discrepancies between this overview clause and the detailed procedure and function descriptions, the latter take precedence.

MTC functionality is provided by the visited and home networks when the networks are configured to support machine type communication. 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 MTC functions are controlled by subscriber data. Other MTC functions are based on indicators sent by the UE to the network. MTC functionality is performed by UEs that are configured to support different options as described in clause 4.3.17.4.

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

Unless otherwise stated in this specification, MTC functionality also applies over satellite access.

4.3.17.2 Overview of protection from Potential MTC Related Overload

The number of MTC devices may be several orders of magnitude greater than "traditional" devices. Many (but not all) MTC devices will be relatively stationary and/or generate low volumes of traffic. However, these UEs have the capability to generate normal quantities of signalling. As normal signalling from large numbers of UEs may cause overload independently whether the UE is used for MTC or not, generic functionality for overload and congestion control is required.

The total signalling from large numbers of UEs is a concern in at least two situations:

– when an application (running in many UEs) requests many UEs to do "something" at the same time; and/or

– when many UEs are roamers and their serving network fails, then they can all move onto the local competing networks, and potentially overload the not (yet) failed network(s).

To counter these potential problems, the following standardised indications and mechanisms are provided in a generic manner. These permit node specific features to be developed to protect the networks.

a) Where applicable, UEs can be configured for enhancements as described in subsequent bullets Post-manufacturing configuration can be performed remotely as described in clause 4.3.17.4.

b) For mobile originated services, UEs configured for low access priority provide the E-UTRAN with information indicating that the RRC connection establishment request has low access priority (see clause 4.3.17.4). Clause 4.3.17.4 describes when low access priority is not applicable.

c) RRC signalling has the capability of providing ‘extended wait timers’ when rejecting messages from UEs. These ‘extended wait timers’ are only used by UEs that access the network with low access priority.

d) The MME can initiate rejection of RRC connection establishments in the E-UTRAN for UEs that access the network with low access priority as described in clause 4.3.7.4.1. In addition, MME signalling or O&M can trigger E-UTRAN to initiate Extended Access Barring. These mechanisms are further described in clause 4.3.7.4.1.

e) Overload messages from the MME to E-UTRAN are extended to aid the RAN in performing the functionality in bullets b, c and d above.

f) UEs configured with a long minimum periodic PLMN search time limit (see TS 24.368 [69]) have an increased minimum time in between their searches for more preferred PLMNs.

NOTE 1: Following the failure of a more preferred PLMN, UEs configured as above might change to other local competing networks. Expiry of this search timer will lead to the UE re-attempting to access the failed network, and then, if that network has not yet recovered, reaccessing one of the local competing networks. Use of a too short timer for the more preferred PLMN search can both prevent the failed network from recovering, and, impose more load on the local competing networks.

g) At PLMN change, UEs configured to perform Attach with IMSI at PLMN change (see TS 24.368 [69]) do this rather than a TA update with GUTI (thus avoiding the need to reject the TA update, and to request the IMSI following the subsequent Attach with GUTI).

NOTE 2: In the case of a network failure, this reduces the message processing load on a local competing network and hence makes that network more likely to survive the failure of the other network.

h) For mobile originated services, UEs configured for low access priority (see TS 24.368 [69]) provide a low access priority indication to the MME in NAS signalling that permit the MME to undertake protective measures (e.g. to permit the MME to immediately command the UE to move to a state where it does not need to generate further signalling messages and/or does not reselect PLMNs), as described in clause 4.3.7.4.1. Clause 4.3.17.4 describes when low access priority is not applicable.

i) Using Periodic TAU timer value sent by the HSS and/or UE provided low access priority indication (bullet h above), the MME can allocate a long periodic TAU timer value to the UE. A long periodic TAU timer is likely to slow down the rate at which a UE detects a network failure and thus it slows down the rate of movement of UEs from a failed network to other local competing networks (see clause 4.3.17.3).

j) Mechanisms for the MME and P-GW to detect congestion associated with a particular APN (see clauses 4.3.7.4.2 and 4.3.7.5).

k) The addition of ‘back off timers’ to EMM and ESM signalling messages (e.g. to rejection messages). These include some time randomisation to guard against a repeat of a load peak. The MME should be able to apply this behaviour on a per-APN basis. as described in clause 4.3.7.4.2

l) Signalling that permits the P-GW to request the MME to generate the above ESM signalling with ‘back off timers’ (see clause 4.3.7.5).

m) An MME overload control mechanism to selectively limit the number of Downlink Data Notification requests the S-GW sends to the MME for downlink low priority traffic received for UEs in idle mode (see clause 4.3.7.4.1a).

n) UE configured for specific handling of the invalid USIM state, the "forbidden PLMN list", the "forbidden PLMNs for attach in S1mode list" and the "forbidden PLMNs for GPRS service list" remembers that the USIM is invalid and keeps the PLMN forbidden lists even if the UE is switched off and then switched on.

o) When the UE has an activated PDN connection without low access priority or the UE is requested to establish such a PDN connection and the UE is configured with a permission for overriding low access priority the UE doesn’t provide a low access priority indication to the MME in NAS MM signalling and also not to the RAN in the RRC requests. In the NAS request for activating a PDN connection this UE always indicates what the upper layers requested, i.e. the UE indicates low access priority in that NAS request unless the upper layers request activation of a PDN connection without low access priority.

p) When the UE has an activated PDN connection that is without low access priority or the UE is requested to activate such a PDN connection and the UE is configured with a permission for overriding Extended Access Barring, then the UE ignores any Extended Access Barring (if it is activated in the network) as defined in TS 22.011 [67].

NOTE 3: It is assumed that the mechanisms described in this entire clause are designed by Stage 3 in a manner that allows extensibility and forward compatibility.

q) The eNodeB may use the low access priority indication provided by the UE to steer UEs configured for low access priority to specific MMEs.

4.3.17.3 Optimising periodic TAU Signalling

To reduce network load from periodic TAU signalling and to increase the time until the UE detects a potential need for changing the RAT or PLMN (e.g. due to network problems) the longer values of the periodic TAU timer and Mobile Reachable timer shall be supported.

A long periodic RAU/TAU timer value may be locally configured at MME or may be stored as part of the subscription data in HSS. During Attach and TAU procedures the MME allocates the periodic RAU/TAU timer value as periodic TAU timer to the UE based on VPLMN operator policy, low access priority indication from the UE, periodic RAU/TAU timer value requested by UE and subscription information received from the HSS.

If MME receives a subscribed periodic RAU/TAU timer value from the HSS it allocates the subscribed value to the UE as periodic TAU timer. A visited PLMN MME may use subscribed periodic RAU/TAU timer value, if available, as an indication to decide for allocating a locally configured periodic RAU/TAU timer value to the UE.

If no subscribed periodic RAU/TAU timer value is received from the HSS, the MME should:

– if the periodic RAU/TAU timer value requested by UE is within the boundaries of the VPLMN operator policy, allocate the value requested by the UE;

– if the periodic RAU/TAU timer value requested by UE is higher than allowed per the VPLMN operator policy, allocate the highest allowed value per the VPLMN operator policy;

– if the periodic RAU/TAU timer value requested by UE is lower than allowed per the VPLMN operator policy, allocate the lowest allowed value per the VPLMN operator policy.

4.3.17.4 UE configuration and usage of indicators

A subscriber can by agreement with its operator be required to use UEs that are configured (see TS 24.368 [69]) to support one or more of the following options:

– UE configured for low access priority; and/or

– UE configured with a permission for overriding low access priority, which is only applicable for a UE that is also configured for low access priority; and/or

– UE configured to perform Attach with IMSI at PLMN change; and/or

– UE configured with a long minimum periodic PLMN search time limit; and/or

– UE configured for specific handling of the invalid USIM state, the "forbidden PLMN list", the "forbidden PLMNs for attach in S1mode list" and the "forbidden PLMNs for GPRS service list"; and/or

– UE configured for Extended Access Barring; and/or

– UE configured with a permission for overriding Extended Access Barring, which is only applicable for a UE that is also configured for Extended Access Barring.

NOTE 1: When a UE is accessing the network with low access priority, then the UE may be subject for longer backoff timers at overload and consequently need to be designed to be tolerant to delays when accessing the network.

UEs can be configured for one or more of the above options with the following restrictions:

– in this Release of the specification, a UE that is configured for low access priority shall also be configured for Extended Access Barring; and

– in this Release of the specification, a UE that is configured for Extended Access Barring shall be configured for low access priority.

– in this Release of the specification, a UE that is configured for overriding low access priority shall also be configured for overriding Extended Access Barring; and

– in this Release of the specification, a UE that is configured for overriding Extended Access Barring shall also be configured for overriding low access priority.

UEs can be configured for one or more of the above options. Post-manufacturing configuration of these options in the UE can be performed only by OMA DM or (U)SIM OTA procedures. UEs capable of the above options should support configuration of these options by both OMA DM and (U)SIM OTA procedures.

A UE configured for low access priority shall transmit the low access priority indicator to the MME during the appropriate NAS signalling procedures and transmit the corresponding low access priority to the E-UTRAN during RRC connection establishment procedures.

NOTE 2: The low access priority indicator in NAS signalling and the corresponding low access priority for RRC connection establishment are used by the network to decide whether to accept the NAS request or the setup of the RRC connection respectively.

Low access priority shall not be applicable in the following situations:

– for all procedures related to an emergency PDN connection; used for IMS Emergency sessions that are to be prioritized as per the requirements for IMS Emergency session procedures (see clause 4.3.12). When an emergency PDN connection gets established, the MME may, based on MME configuration, initiate the deactivation of any non-emergency PDN connection using the MME requested PDN disconnection procedure described in clause 5.10.3;

– for all procedures when preferential access to the network is provided to the UE by the Access Class 11-15 mechanism according to TS 36.331 [37] and TS 22.011 [67] e.g. for Multimedia Priority Services as described in clause 4.3.18;

NOTE 3: The configuration of a UE for low access priority and Access Class 11-15 are configured independently of each other. However, the home operator can take care to prevent a subscription for Access Class 11-15 from being used in a UE configured for low access priority.

– for RRC connection establishment procedures when responding to paging;

– for a UE configured with a permission for overriding low access priority under conditions described by bullet o in clause 4.3.17.2; or

– other specific situations described in TS 24.301 [46].

If the NAS session management request message used to establish a new PDN connection contains a low access priority indication, the MME shall forward the low access priority indication in the Create Session Request message to the S-GW/P‑GW. The low priority indication gets associated with a PDN connection when it is established and it shall not change until the PDN connection is deactivated.

The low access priority indication may be included in charging records by the visited and home networks. In order to permit the S-GW to include the low access priority indicator in the charging records, the low access priority indicator should be stored in the MME EPS Bearer contexts and should be passed as part of these contexts to other SGSN/MME or S-GW nodes in mobility management procedures.

NOTE 4: In this release there is no other usage of storing the low access priority indicator in EPS Bearer contexts other than for the purpose to include it in charging records. Particularly, the low access priority indicator in EPS Bearer contexts is not used by the network to make overload control decisions.

A network node may invoke one or more of the following mechanisms based on the indicators received in signalling from UEs or forwarded by other network nodes:

– based on the low access priority indicator in NAS request messages, bullets e, h, i, k and l as defined in clause 4.3.17.2; and/or

– based on the low access priority for RRC connection establishment, bullets b, c and q as defined in clause 4.3.17.2.

A UE shall invoke one or more of the following mechanisms based on the configuration and capabilities of the UE:

– when UE is configured with a long minimum periodic PLMN search time limit, the UE invokes actions as described in bullet f in clause 4.3.17.2; and/or

– when UE is configured to perform Attach with IMSI at PLMN change, the UE invokes actions as described in bullet g in clause 4.3.17.2; and/or

– when a UE is configured for low access priority, the UE invokes actions as described in bullets b and h in clause 4.3.17.2; and/or

– when UE is configured for specific handling of the invalid USIM state, the "forbidden PLMN list", the "forbidden PLMNs for attach in S1mode list" and the "forbidden PLMNs for GPRS service list", the UE invokes actions as defined in bullet n in clause 4.3.17.2; and/or

– when UE is configured for Extended Access Barring, the UE invokes actions as defined in bullet d in clause 4.3.17.2; and/or

– when a UE is configured with a permission for overriding low access priority and configured with a permission for overriding Extended Access Barring, the UE invokes actions as described in bullets o) and p) in clause 4.3.17.2.

4.3.17.5 Void

4.3.17.6 Support of UEs configured for low access priority, Extended Access Barring and permission for override

The feature is specified in TS 23.060 [7] clause 5.3.13.6.

4.3.17.7 High latency communication

Functions for High latency communication may (depending on operator configuration) be used to handle mobile terminated (MT) communication with UEs being unreachable while using power saving functions (e.g. UE Power Saving Mode (see clause 4.3.22) or extended idle mode DRX (see clause 5.13a)) or UEs that are using a satellite access with discontinuous coverage. "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 the initial downlink packet(s). The feature is described in TS 23.682 [74].

The High latency communication includes invoking extended buffering of MT data at the Serving GW when the UE is in a power saving state and not reachable. The handling is specified in the Network Triggered Service Request procedure, clause 5.3.4.3. Establishing the user plane for delivering the buffered data when the UE contacts the MME or SGSN by signalling shall be done in the Tracking Area Update and Routing Area Update procedures. The MME/SGSN uses its parameter DL Data Buffer Expiration Time in the MM context information to remember if there is buffered DL data to be delivered when the UE becomes reachable. When set, the DL Data Buffer Expiration Time shall be cleared at any user plane setup to the RAN, i.e. buffered DL data can been delivered. At TAU/RAU procedures with MME/SGSN change, the old MME/SGSN shall indicate in the context response to the new MME/SGSN that buffered DL data is waiting and hence the new MME/SGSN shall establish the user plane for delivery of the buffered DL data. When the DL Data Buffer Expiration Time has expired, the MME/SGSN considers no DL data to be buffered and no indications of Buffered DL Data Waiting are sent during context transfers at TAU procedures. At TAU/RAU procedures with Serving GW change, the buffered DL data is forwarded to the new Serving GW or Gn/Gp-SGSN.

For Control Plane CIoT EPS Optimisation, the High latency communication includes invoking the buffering of MT data at the Serving GW or the MME as specified in Mobile Terminated Data Transport in Control Plane CIoT EPS Optimisation with P-GW connectivity, clause 5.3.4B.3. When the UE contacts MME, MME delivers the buffered data using NAS PDUs. If MT data is buffered in MME, at TAU procedures with MME change the buffered data in the old MME is discarded.

The High latency communication also includes sending event notifications to application servers that have requested "UE Reachability" or "Availability after DDN failure" monitoring events. Event notifications are sent when a UE becomes reachable, for example as part of the Attach Procedure, TAU/RAU procedures and the UE triggered Service Request procedure.

When "UE Reachability" monitoring is requested for UE’s that are using extended idle mode DRX, an event notification is sent to the application server when the UE is about to become reachable for paging.

If the MME 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 or PSM enabled, the MME may include a Pending Data indication in the next S1-AP message towards an eNodeB. If the eNodeB receives this indication, the eNodeB may take this information into account when determining user inactivity. At inter-RAN node handovers, if some signalling or data are still pending, the target MME may send a Pending Data indication to the target RAN node.

4.3.17.8 Support for Non-IP Data Delivery (NIDD)

4.3.17.8.1 General

The support of Non-IP data is part of the CIoT EPS Optimisations. A PDN Type "Non-IP" is used for Non-IP data. The Non-IP data delivery to SCS/AS is accomplished by one of two mechanisms:

– Delivery using SCEF as defined in clause 4.3.17.8.3.2.

– Delivery using a Point-to-Point (PtP) SGi tunnel as defined in clause 4.3.17.8.3.3.

When the Reliable Data Service is not used, Non-IP data in-sequence delivery cannot be guaranteed and data PDUs may be lost requiring higher protocol layers to ensure guaranteed delivery when needed. The Reliable Data Service is defined in TS 23.682 [74].

NOTE: If UEs use protocols that require broadcast/multicast mechanisms (e.g. use "IP stacks" on top of PDN connections of type "Non-IP"), this may cause increased traffic and power consumption to the UE and the network.

The SMS service may also be used to deliver data without use of the IP protocol. The SMS service is always supported for CIoT EPS Optimisations, i.e. can be used simultaneously with Non-IP and IP data. When only the SMS service is needed, an attach without PDN connection establishment can be used, see clause 5.3.2.

Dedicated bearers are not supported for the Non-IP data.

4.3.17.8.2 ESM Procedures

The UE indicates in the ESM connection request, e.g. in Attach or PDN Connectivity Request, that a Non-IP PDN type shall be used. The subscription information has a default APN for PDN Type Non-IP, which the MME uses for the first received Non-IP connectivity request unless the UE has included an APN in the request.

4.3.17.8.3 Delivery mechanism

4.3.17.8.3.1 General

At each PDN connectivity request, the MME decides which delivery mechanism (SCEF based delivery or SGi based delivery) is used for delivering the Non-IP data between RAN and AS. An indication associated with the used APN determines if SCEF based delivery or SGi based delivery shall be used.

4.3.17.8.3.2 SCEF based delivery

When the MME decides to use SCEF based delivery mechanism for Non-IP data, a PDN connection is established towards the selected SCEF. Such a PDN Connection is also known as an "SCEF Connection". The APN used for SCEF based delivery is an FQDN, which either resolves to an SCEF hostname or to an SCEF IP address.

The SCEF based delivery is applicable only to the Control Plane CIoT EPS Optimisation (see clause 4.10).

The support of Non-IP data via the SCEF is further defined in TS 23.682 [74].

4.3.17.8.3.3 SGi based delivery

4.3.17.8.3.3.1 General

When support of Non-IP data is provided at the SGi interface, different point-to-point tunnelling techniques may be used. Point-to-point tunnelling by UDP/IP encapsulation can be used as described in clause 4.3.17.8.3.3.2 below. Other techniques as described in clause 4.3.17.8.3.3 below may be used.

Support for the SGi based delivery of Non-IP data can be used by any UE. That is, it is independent of support for the User Plane CIoT EPS Optimisation and the Control Plane CIoT EPS Optimisation (see clause 4.10).

The P-GW decides at PDN connection establishment based on pre-configuration which point-to-point tunnelling technique is used for the SGi based delivery between the P-GW and the AS.

NOTE: The pre-configuration can be done in the P-GW per APN or based on other criterion such as SLA between operator and 3rd party application service provider, etc.

4.3.17.8.3.3.2 SGi PtP tunnelling based on UDP/IP

SGi PtP tunnelling based on UDP/IP may be used to deliver Non-IP data to AS via SGi.

A point-to-point tunnel is used by the P-GW towards the AS. The tunnel parameters (i.e. destination IP address and UDP port) for SGi PtP tunnelling based on UDP/IP are pre-configured on the P-GW. IP address allocation procedures for PDN connections are performed locally (e.g. without involving the UE) by the P-GW based on APN configuration and according to clause 5.3.1. Only single IP address is used (i.e. both IPv4 and IPv6 addresses are not allocated).

The P-GW acts as a transparent forwarding node for the payload between the UE and the AS.

For uplink Non-IP data, the P-GW forwards the received data to the AS over the SGi PtP tunnel using UDP/IP encapsulation. When the Reliable Data Service is enabled, the P-GW processes the Reliable Data Service Header. The Reliable Data Service Configuration is pre-configured on the P-GW. The Reliable Data Service Configuration is defined in TS 23.682 [74].

For downlink Non-IP data, the AS sends the data using UDP/IP encapsulation with the IP address of the UE and the 3GPP defined UDP port for "Non-IP" data. The P-GW decapsulates the received data (i.e. removes the UDP/IP headers) and forwards the data to S-GW on the GTP-U tunnel identified by the IP address of the UE (i.e. PDN connection) for delivery to the UE. When the Reliable Data Service is enabled, the P-GW adds the Reliable Data Service Header.

The P-GW performs the IP related operations (e.g. allocates IP address for the PDN connection), but the IP address or IP prefix is not provided to the UE (i.e. SLAAC / Router Advertisements are not performed. DHCP or DHCPv6 are not used). In the case of IPv6 the P-GW assigns an Interface Identifier for the PDN connection. The allocated IP address or IPv6 prefix identifies the PDN connection of the UE. The P-GW shall inform the MME of the assigned IPv4 address or IPv6 prefix and Interface Identifier for a PDN Connection of a given UE. However, the UE is not informed about the assigned IPv6 prefix and Interface Identifier.

NOTE: It is recommended to use IPv6 for CIoT. IPv4 based addressing is deprecated for machine type communication used over 3GPP accesses, see TS 23.221 [27].

4.3.17.8.3.3.3 Other SGi PtP tunnelling mechanisms

SGi PtP tunnelling mechanisms such as PMIPv6/GRE, L2TP, GTP-C/U, etc, may be used to deliver Non-IP data to AS via SGi. The general handling of such delivery mechanisms is as described below.

A point-to-point tunnel is established by the P-GW towards the AS. Depending on the type of protocol employed on the SGi PtP tunnel, the SGi PtP tunnel setup may be done at the time of Attach or at the time of first MO datagram being sent by the CIoT UE. The P-GW selects the AS based on the P-GW configuration (e.g. per APN, or per PtP tunnel type etc.). However, IP address allocation procedures for the UE (according to clause 5.3.1) are not performed by the P-GW.

NOTE: An AS can be dedicated for handling a specific Non-IP data protocol.

The P-GW acts as a transparent forwarding node between the UE and the AS.

For uplink Non-IP data, the P-GW forwards the received data to the AS over the established SGi PtP tunnel.

For downlink Non-IP data, the AS locates the right SGi PtP tunnel for the UE (using information such as UE identifiers in the Non-IP protocol itself, etc) to forward the data. The AS sends the data to P-GW over the established SGi PtP tunnel. The P-GW in turn sends the data to S-GW on the GTP-U tunnel identified by the associated SGi PtP tunnel for delivery to the UE.

4.3.17.8a Support of PDN type Ethernet

The support of Ethernet PDN type relies upon the selection of a P-GW that supports combined PGW+SMF functionality specified in TS 23.501 [83], TS 23.502 [84] and TS 23.503 [88]. This functionality may be supported by a PLMN even if it has no NG-RAN coverage, however, it does require that the subscriber has a subscription record in the 5GS UDM.

This feature is described in clause 5.6.10.2 of TS 23.501 [83].

For PDN connection with Ethernet PDN type, IP address allocation is not needed.

In contrast to the Non-IP PDN type, EPS Dedicated Bearers are supported for the Ethernet PDN type (including the TFT as described in clause 4.7.2.1). The details about the TFT packet filter(s) are described in clause 5.7.6.3 of TS 23.501 [83].

For PDN connection of Ethernet type, dynamic PCC is applied as described in clause 4.7.5 with the following differences:

– Dynamic PCC specified in TS 23.503 [88] is applied, i.e. the PCEF interacts with the PCF using N7 interface as described in TS 23.501 [83], and the PCEF does not interact with the PCRF using Gx interface as specified in TS 23.203 [6].

– The SDF template included in the PCC rule(s) uses Ethernet packet filter as specified in TS 23.501 [83].

– The description related to IP address configuration is not applicable.

Dedicated Core Network functionality (see clause 4.3.25) can be used to avoid the need for all MMEs in the PLMN to be upgraded to support Ethernet PDN Type.

If the UE’s attempt to use the Ethernet PDN Type is rejected by the network, the UE may attempt to gain service by requesting the Non-IP PDN type.

Ethernet PDN Type is not supported in GERAN/UTRAN. If the UE only has an Ethernet PDN connection established, mobility to GERAN/UTRAN should be prevented. To do this, the MME shall indicate to the eNodeB in Handover Restriction List that GERAN/UTRAN is restricted.

For PDN connection with Ethernet PDN type, mobility to Non 3GPP access to EPC is not supported.

4.3.17.9 Service Gap Control

Service Gap Control is an optional feature intended for MTC/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 emergency services and regulatory prioritised 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 MME on a per UE level (i.e. the same Service Gap Timer applies for all PDN connections that the UE has). The UE indicates its capability of support for Service Gap Control in the Attach Request message and TAU Request message to the MME. The MME passes the Service Gap Time to the UE in the Attach Accept message and/or Tracking Area Update Accept message for UE that has indicated its supports 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 MME when the Service Gap Time is stored in the MM context.

Service Gap Control requires the UE to stay in ECM-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.301 [46]). The Service Gap timer shall be started each time a UE moves from ECM-CONNECTED to ECM-IDLE, unless the connection request was initiated by the paging of a Mobile Terminated event, or after a TAU procedure without active flag or signalling active flag, 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 ECM-CONNECTED to ECM-IDLE transition.

The Service Gap control is applied in ECM-IDLE state only and does not impact UE Mobile Originated user data transmission or Mobile Originated signalling in ECM-CONNECTED state. The Service Gap timer is not stopped upon ECM-IDLE state to ECM-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 also not initiate Attach Requests when a Service Gap timer is running, unless it is Attach Request without PDN connectivity or Emergency Attach which are allowed.

NOTE 2: As a consequence of allowing Attach without PDN connectivity procedure, the UE with a running Service Gap timer does not initiate further MO signalling, except for tracking area updating procedure, until the UE receives MT signalling or after the UE has moved to ECM-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 MME may enforce the Service Gap timer by rejecting connection request for MO user plane data, MO control plane data, or MO SMS when a Service Gap timer is running. The MME may enforce the Service Gap timer by not allowing Attach Requests when a Service Gap timer is running, unless it is Attach Request without PDN connectivity or Emergency Attach which are allowed. When rejecting the connection requests and the Attach Requests while the Service Gap timer is running, the MME may include a Mobility Management back-off timer corresponding to the time left of the current Service Gap timer. For the UEs that does not support Service Gap Control (e.g. pre-release-15 UEs), Service Gap Control may be enforced using "General NAS level Mobility Management control" as defined in clause 4.3.7.4.2.1.

When the MME starts the Service Gap timer, the MME should invoke the Service Gap timer with a value that is slightly shorter than the Service Gap Time value provided to the UE in the subscription information received from the HSS.

NOTE 4: This ensures that the MME doesn’t reject any UE requests just before the Service Gap timer expires e.g. because of slightly unsynchronized timers between UE and MME.

A UE which transitions from a PSM 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 applies to low priority (delayTolerant) and normal traffic.

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

– Emergency Attach and Attach without PDN Connectivity are allowed when a Service Gap timer is running.

– Service Gap Control shall be effective also for UEs performing detach and reattach unless it is Attach Request without PDN connectivity or Emergency Attach.

– Tracking Area Update with active flag or signalling active flag is not allowed when a Service Gap timer is running except for emergency bearer services or if the UE is accessing with high priority access class in the range AC 11-15.

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

a) Re-attach to the registered PLMN: The remaining Service Gap timer value survives and controls the re-attach.

b) Attach or Tracking Area Update to a different PLMN: The remaining Service Gap timer value survives and controls the Attach/Tracking Area Update to the new PLMN.

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

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

The following procedures are impacted by Service Gap Control:

– E-UTRAN Initial Attach, see clause 5.3.2.1;

– Tracking Area Update procedures, see clause 5.3.3;

– UE Triggered Service Request, see clause 5.3.4.1;

– Connection Resume Request, see clause 5.3.5A.

NOTE 5: Since UE triggered Service Request and Connection Resume Request are prevented by Service Gap timer, this implicitly prevents the UE from initiating MO data in Control Plane EPS Optimisations (see clause 5.3.4B.2), MO NIDD procedure (see TS 23.682 [74]) and MO SMS (see TS 23.272 [58]).