9.2.1 Long Battery Life

Many IoT devices, e.g. smart meters, can be expected to have a very long life‐cycle. For many sensor applications, it can further be expected that the device has no other power supply than the original battery. Imagine a sensor embedded in a bridge to detect signs of wear and tear over the life of the bridge. This sensor must be able to work for many years in a situation where it is not connected to an external power supply and where it is not easily possible to replace the battery. Progress in battery development is one part solving the problem, more efficient use of radio and network resources can also extend the device's battery lifetime. There are trade‐offs between reachability, data rates, bandwidth, and power consumption, that can be managed through architectural and protocol enhancements in a Third Generation Partnership Project (3GPP) system that will extend device battery life for IoT devices while enabling their full functionality.

9.2.2 Mobility Patterns

Typical wireless networks are optimized for handling the mobility of devices that move quickly (e.g. on a car or train), frequently (e.g. on a delivery truck), or cover large distances (e.g. a global traveller). IoT includes the additional cases that connected devices are stationary (e.g. the embedded sensor), geographically limited (e.g. items in a warehouse), and nomadic (e.g. stationary while in use, but can change location when not in use). Providing the same kind of mobility for these different types of devices is not efficient and results in unnecessary power consumption both in the network and in the device. Adaptable mobility management requirements allow optimal support for each type of device.

One basic requirement is to identify the type of mobility an IoT device requires: stationary, geographically limited, nomadic, fully mobile. From there, different types of mobility can be applied to most efficiently support each device type. Depending on the type of mobility, handover, tracking area updates, and location updates may not need to be supported for this device, providing significant savings in resource usage and extending device battery life for low and no mobility devices.

9.2.3 Bursty Data

Wireless systems were originally designed for smart phones and PC dongles, therefore aimed at maximizing the bandwidth for the users within the capabilities provided by the radio network. This was done under the assumption of a continuous data flow for voice, downloading (e.g. web surfing), or streaming applications. IoT introduces the concept of bursty data, which places different requirements on the wireless system. Bursty data can consist of either a small payload or a large payload, the key criteria being the infrequent, yet regular, transmission of data. Consider a camera installed on a street corner which periodically sends a brief report, (e.g. text or snapshot) that ‘all is well’. In case of an accident, the camera is equipped to send streaming video for a certain period, after which it reverts to the brief report format. Traditional user plane setup overhead becomes much more impacting for these bursty data use cases than for voice or lengthy but episodic data transmissions. Session setup delay is also a restrictive factor for some bursty applications. For example, in the corner camera scenario, the video must be sent immediately to fully capture details of the accident. 3GPP has made several enhancements to improve the ratio of payload, session setup, and message overhead to better meet the needs of IoT devices with bursty data.

9.2.4 Bulk Device Management

In 2G, 3G, and 4G systems, it is expected that a user has only a few devices (e.g. one smartphone and one tablet) registering in the network. In an IoT marketplace, a user may range from a person with a dozen devices at home (e.g. smartphone, tablet, thermostat, printer, lights) to an enterprise with thousands of devices (e.g. smart parking meters). The ‘one at a time’ device management tools provided in 2G, 3G, and 4G for subscription management, activation/deactivation, billing, etc. are not efficient for managing hundreds and thousands of devices with common characteristics belonging to a single owner. 5G will specify bulk provisioning and management tools to more efficiently apply common treatment such as activation/deactivation and subscription updates to a huge number of devices.

9.2.5 Flexible Subscription Management

In 2G, 3G, and 4G systems, user equipments (UEs) are typically expected to belong to one subscriber with no need to change the subscription from the time a UE is activated until it is deactivated. IoT comes with a new business model, where a device, such as a UE embedded in rental equipment, may be passed from one ‘user’ to another. This model introduces the need to associate a UE in 5G with a new user and subscription in an easy and resource efficient manner.

As IoT continues to grow, it is expected that devices will be manufactured in a more generic manner than UEs today. This means, IoT devices will not be designed for use in a specific operator's network, rather they will be designed and built to be used anywhere in the world, with any mobile network. Consider a manufacturer of smart flower pots. The manufacturer does not want to build different pots for sale in different parts of the world that work with only one operator. From the flower pot manufacturer point of view, it would be better to build smart flower pots that can be sold anywhere and work with any network. It can also be expected that IoT devices will need the flexibility to update and change subscription data as the owner moves. For example, if the owner moves to another country, they will likely find it more desirable to set up a subscription with the new local operator rather than operate the flower pot in a roaming mode.

The 2G, 3G, and 4G paradigm still assumes a human user will insert a Universal Integrated Circuit Card (UICC) into a UE, something not feasible in many IoT cases and by far not cost effective when it comes to small IoT devices that regularly change ownership. To address this issue, the Global System For Mobile Communications Association (GSMA) has defined the E‐SIM (Embedded Subscriber Identity Module) specification that partly addresses this shortcoming. The E‐SIM is a reprogrammable chip on the device that comes in different shapes and sizes and can be updated over the air, allowing simplified change of the mobile operator by just updating the software. Additionally, 5G specifies more resource efficient mechanisms to administer devices, thus reducing overhead processing.

9.2.6 Security

While the E‐SIM solves some problems with device portability, still other solutions are needed to meet the needs of providing security for IoT devices. IoT devices come in a variety of sizes ranging from huge mining trucks to tiny sensors, have different physical characteristics such as a smart T‐shirt that will endure multiple washings, and have varying privacy requirements from the high privacy needed for medical device communications to low or no privacy for advertisements sent from a shop to passers‐by. 5G will fulfil requirements to support new security mechanisms. Additional work is needed in this area to ensure that the diversity of security requirements can be met in a manner maintaining the security of the mobile operator's network.

9.2.7 Others

Support for the IoT involves many diverse scenarios including:

• large numbers of devices requiring highly reliable instantaneous communication (e.g. V2X);
• smart wearables and other Personal Area Networks (e.g. home, office); and
• sensor networks (many devices, bursty data, static location, reusable, long battery life, low cost devices).

A key challenge is meeting these diverse, and often conflicting, requirements in a network. Fortunately, 5G also includes many new capabilities such as network slicing allowing mobile network operators (MNOs) operating different logical networks simultaneously, tailored to most efficiently meet the needs of a specific type of application.

Based on 2G, 3G, and 4G networks there are already many deployed IoT use cases, e.g. monitoring patients while they are at home or familiar use cases to support portable credit card readers at the point of sale. Another example is Amazon's E‐book allowing readers to connect to the bookstore via communication networks, without end user intervention. Common to all of these use cases is their ‘vertical’ M2M nature, i.e. the company providing such services builds the whole service – or has it built by a specialized company, provides the end user a telemetry device, arranges the connectivity with an operator, monitors the data received and so on, which on one side perfectly fits the needs of the company, but can have downsides when this ‘vertical silo’ M2M application needs to be extended to support new functionality, fulfil capacity, reliability, or latency requirements. While the silo nature of M2M communication is being addressed by industry for one such as oneM2M which specifies how data collected via IoT devices can be made available to other services when needed, the capacity growth and reliability aspects are being addressed by 3GPP and the new 5G standard.

While 2G, 3G, and 4G systems already support many IoT use cases there are several shortcomings of these systems that 5G needs to tackle. First, considering the expected huge number of IoT devices connected in future, ranging in the order of tens of billion devices in the next decade and growing into the trillions beyond, it becomes obvious that 3G and 4G technology cannot handle this growth rate as they were designed to support much smaller numbers of devices. One limiting factor is, e.g. the maximum number of one billion International Mobile Subscriber Identities (IMSIs) that can be supported in a single cellular public land mobile network (PLMN), another one the ability of a network to keep billions of devices connected at the same time.

9.4.1 MTC Architecture

In Rel‐11, 3GPP mainly introduced a new interworking function (MTC‐IWF) (Figure 9.2) for service providers to interconnect with the mobile operator network. The MTC‐IWF enables device triggering via control plane, identifier translation and other features that might be introduced in future. The end‐to‐end communication between the MTC application in the UE and the MTC application server (AS) may use services provided by the 3GPP system, and optionally services provided by a Services Capability Server (SCS). The MTC Application in the external network is typically hosted by an AS. The SCS can be in the service provider domain (as shown in Figure 9.2) but can also be hosted by the mobile operator as a kind of Service Delivery Platform. In the latter scenario, the SCS can implement charging and security functions.

While the MTC‐IWF serves as first contact point for requests coming from the SCS and provides security, charging and identifier translation (external to internal identifier) at the ingress of the PLMN, the newly introduced MTC‐AAA function translates the internal identifier (IMSI) at the network egress to the external identifier(s) before forwarding authentication, authorization, and accounting (AAA) requests to an AAA server in the service domain. This avoids exposure of the IMSI outside the operator domain. MTC‐AAA can work in server or proxy mode and has interfaces to the PDN Gateway (PGW)/Gateway GPRS Support Node (GGSN) (Gi/SGi) (where AAA requests originate from), Home Subscriber Server (HSS) (S6n) (to retrieve external identifier(s) for a given IMSI and vice versa) and external AAA servers. MTC‐IWF receives a device trigger request from the SCS over the Tsp interface and forwards it to the SMSC via T4. It receives subscription data including the IMSI from the HSS via S6m and provides charging data via the existing interfaces Rf/Ga to the charging gateway.

Different deployment models are possible for MTC allowing support for different service level agreements between MNO and service provider:

• Direct model. The AS connects directly to the operator network for direct user plane communication with the UE without the use of any SCS; this allows for simple implementation of OTT (over‐the‐top) applications; OTT deployments are transparent to the PLMN;
• Indirect model. The AS connects indirectly to the operator network through the services of a SCS to perform indirect user plane communication with the UE and to utilize additional value‐added services (e.g. control plane device triggering). The SCS is either:
  1. ∘ MTC Service Provider controlled: The SCS is an entity outside of the operator domain and Tsp is an external interface (i.e. to a third party MTC Service Provider) or
  2. ∘ 3GPP network operator controlled: The SCS is an entity inside the operator domain and Tsp is an internal interface to the PLMN;
• Hybrid model. The AS uses the direct and indirect models simultaneously to connect directly to the operator's network for direct user plane communication with the UE while also using SCS based services. From 3GPP network perspective, the direct user plane communication from the AS and any value‐added control plane related communication from the SCS are independent and have no correlation to each other even though they may be servicing the same MTC Application hosted by the AS.

Since different models are not mutually exclusive, but just complementary, it is possible for a network operator to combine them for different applications. This may include a combination of both MTC Service Provider and 3GPP network operator controlled SCSs communicating with the same PLMN.

9.4.2 Identifiers

As mentioned earlier, a shortage of E.164 numbers is an additional driver for optimizations and improvements in mobile networks. This urged the need to define Internet‐like identifiers such as Fully Qualified Domain Names (FQDN), Uniform Resource Names (URN) or Uniform Resource Identifiers (URI) for subscriptions without MSISDN. Such identifiers are referred to as external identifiers.

One IMSI may have one or more external identifier(s) stored in the HSS assigned to it. Rationale behind one to many mapping is twofold. A single device may have several applications running on the device and each application may use its own external identifier. Alternatively, a single device may have subscriptions with several service providers for different applications and each service provider may assign its own external identifier. Although this approach provides more flexibility for deployments, it comes with some drawbacks. At the border between PLMN and service domain external identifiers are used and the PLMN translates them to one internal identifier like the IMSI for usage within the network. Reverse mapping (e.g. for MO‐SMS, at Gi/SGi interface) from internal to external identifier may then cause issues in terms of uniqueness of the reverse translation. Choosing the correct external identifier in such scenarios was not resolved in Release 11.

The External Identifier is required to be globally unique and has the following components:

• Domain identifier. Identifies a domain that is under the control of the MNO; SCS/AS use the domain identifier to determine the correct MTC‐IWF.
• Local identifier. Used to derive and obtain the IMSI. It shall be unique within the applicable domain and is managed by the MNO.

The external identifier will use the format of a network access identifier (NAI), i.e. username@realm, as specified in clause 2.1 of Internet Engineering Task Force (IETF) RFC 4282 [62]. The username part of the External Identifier contains a Local Identifier. The realm part contains a Domain Identifier. As a result, an external identifier will have the form ‘<Local Identifier>@<Domain Identifier>’. This identifier will mainly be used at Tsp, S6m, S6n, T4, Rf/Ga interfaces.

9.4.3 Addressing

To cope with the potentially very huge number of machines connecting to the network, IPv6 is recommended by 3GPP as the preferred addressing format for devices subscribed for MTC. Addressing is a deployment topic, thus use of a certain IP version is an operator decision.

9.4.4 Device Triggering

Device Triggering is needed for delivering a message towards a UE and a specific application on that UE, if the IP address of the UE is not known by the SCS/AS. MTC devices can be triggered when they are attached to the network, with and without an existing packet data protocol (PDP)/packet data network (PDN) connection. In current deployments SMS is used to trigger attached devices but in the early releases before the introduction of the external identifier concept, this required an MSISDN allocated to each MTC subscription. As MSISDNs are limited in some regions (e.g. in the US and China) solutions need to be found that do not need a require MSISDN per MTC user. In addition, solutions using Internet‐like identifiers like NAI are more flexible as such identifiers can be allocated more freely on a per need basis. It must be noted that devices with an established PDP/PDN connection can register their IP address OTT at the AS by application layer means. Thus, the server can trigger the device by sending an application layer trigger without the need to use 3GPP network capabilities. However, when the SCS requests the 3GPP network to trigger a MTC device it can provide the appropriate identifier in the request and the network translates this external identifier into an internal one (e.g. the IMSI) used to trigger the device. The device could be triggered by different means such as SMS, Cell Broadcast messages, session initiation protocol (SIP) messages (Instant Messaging or SMS over IP), or via some new path traversing the MME/SGSN (Serving GPRS Support Node) and/or HSS/HLR (home location register) (e.g. using hypertext transfer protocol (HTTP), DIAMETER/MAP, and non‐access stratum (NAS, see [15]) as transport means). However, in Release 11 SMS is the only standardized mechanism that was adopted for device triggering. Cell broadcast messages are used by some operators for triggering groups of devices, but this is a proprietary solution. The external identifier must be stored in the HSS/HLR to allow the network to translate the external request coming from the SCS into an internal trigger request using the proper internal identifier. One device may be assigned multiple external identifiers, thus the HSS/HLR needs to store one IMSI with many external identifiers. Figure 9.2 shows the MTC architecture for device triggering with the Tsp (sp = service provider) interface between SCS and 3GPP network. Tsp is used by the SCS to send a trigger request to the PLMN using the External Identifier for identifying the target device. Tsp is based on DIAMETER and terminates at the MTC‐IWF within the PLMN. The MTC‐IWF sends the trigger request to the SMSC using the T4 interface, which is also based on DIAMETER and described in TS 29.337 [32]. Device triggering over Tsp/T4 is the only standardized method for triggering in Release 11 (besides application layer triggering). Optionally, the SCS/AS can send a device trigger SMS via the Tsms interface directly to the SMSC. Tsms is the existing legacy interface between a Short Message Entity (SME), e.g. the SCS/AS and the SMSC to send and receive short messages.

9.4.5 PS‐only Service Provision

PS‐only service provision is providing a UE with all subscribed services via the packet (PS) domain of a mobile network. PS‐only service provision implies a subscription that allows only for services exclusively provided by the PS domain, i.e. data bearer services and SMS. Support of SMS via PS domain NAS is a network deployment option and may also depend on roaming agreements. Therefore, a subscription intended for PS‐only service provision may also allow for SMS services via CS domain to provide a UE with SMS services in situations when serving node or network doesn't support SMS via the PS domain. The functionality that enables PS‐only service provision is described in TS 23.060 [6] and TS 23.272 [13].

9.4.6 Dual Priority Devices

As mentioned above, low priority (or delay tolerant) access configuration was introduced in Release 10 to aid with congestion and overload control when millions or billions of M2M devices are trying to connect to the network. There may however be circumstances when such devices need to access the network for higher priority services. Following are some example scenarios:

• Electricity meters sending a daily report (of the per hour usage) using ‘low priority’ indication, but, may want to send an alarm without ‘low priority’, if the meter is being tampered with or is being vandalized.
• A road temperature sensor could send daily ‘I'm still working’ reports using ‘low priority’, but, when the temperature falls to sub‐zero, immediately send a warning to the control centre without ‘low priority’.
• A M2M module which hosts multiple hybrid applications; the room temperature application always requires data transmission using ‘low priority’ and video streaming application requires data transmission without using ‘low priority’.

As a result, it is possible that an application overrides the default low priority setting on rare occasions for establishing normal connections. To accomplish this, a new configuration parameter called ‘override low priority access’ was introduced. Devices with both low priority access and override low priority access configurations are dual priority devices. Override low priority access indicates to the UE that an application can connect to the network without setting the low priority indicator (e.g. in PDN connection request messages). PDN connections marked as low priority and not marked as low priority may co‐exist. When the UE has PDN connections established with low priority and without low priority, it can establish mobility management procedure and RRC connections without low priority ([9]).

9.4.7 Extended Access Barring

EAB is a mechanism to restrict network access for low priority devices. It is activated by the RAN. A network operator can restrict network access for UEs configured for EAB in addition to the common access control and domain specific access control. The UE can be configured for EAB in the Universal Subscriber Identity Module (USIM) or in the mobile equipment (ME). When EAB is activated in the radio base station (e.g. via OA&M) and the UE is configured for EAB, it is not allowed to access the network. When the UE is accessing the network with access classes AC 11–15, and that access class is not barred, the UE can ignore EAB. Also, if it is initiating an emergency call and emergency calls are allowed in the cell, it can ignore EAB. The UE can also respond to paging when barring is active, this is under the assumption that the network will initiate paging only when there is no congestion situation. Dual priority devices may also be configured with override EAB configuration.

9.4.8 Short Message Service in MME

SMS in MME was introduced mainly to address requirements from operators who do not deploy a 3GPP mobile switching centre (MSC) (thus no SGs interface is available) and do not want to support MAP in their network. SMS over IP (i.e. SMS over Internet Protocol Multimedia Subsystem [IMS]) could be one solution, however the concern with this solution was the need for an IMS/SIP client in the devices and not all devices (e.g. machine type devices, dongles) will have such a client implemented. Furthermore, inbound roamers whose home operators do not support IMS cannot be offered SMS over IMS and thus they will need support for SMS over NAS. These factors resulted in the need to introduce a new architecture for supporting SMS services in evolved packet core (EPC) defined in TS 23.272 [13] (Figure 9.3). This feature can be enabled or disabled in the MME via configuration.

From UE perspective it is transparent whether SMS in MME or SMS over SGs is offered by the network. The UE will perform combined EPS/IMSI attach (or combined tracking area updating [TAU]) to obtain SMS services. The network can decide to offer SMS over SGs or SMS in MME depending on several factors such as user's subscription (PS only, PS, and CS), user requested service (SMS only or SMS and voice), support for the feature in general and local policies. If the UE is performing ‘combined attach’ to request for SMS services only and the network supports SMS in MME, the network need not establish a SGs association between MME and MSC. The network will then indicate ‘SMS only’ in the accept message to inform the UE that it has been attached only for SMS services. To keep it transparent to the UE, MME will include a non‐broadcast location area identity (LAI) (‘dummy LAI’) and a reserved temporary mobile subscriber identity (TMSI) in the combined attach accept or combined TAU accept. This ensures backward compatibility so that legacy UEs consider the attach procedure to be successful. Between UE and MME, SMS messages as defined in 3GPP TS 23.040 [31] are encapsulated and transferred within NAS messages.

A third release of improvements was developed for MTC devices and mobile data applications running in smart phones. This work was covered by the Rel‐12 feature ‘Machine‐Type and other mobile data applications Communications Enhancements (MTCe)’. Two main features are part of Rel‐12:

• Device triggering enhancements and Small Data Transmission (infrequent and frequent)
• UE power consumption optimizations.

Power consumption is important for UEs using a battery and for UEs using an external power supply. Its importance increases with the continued need for energy savings.

Following are the solution options that were considered in 3GPP to achieve power savings:

• Introducing Extended discontinuous reception (DRX) cycle in idle mode
• Introducing Power saving mode for devices
• Introducing long DRX cycles in connected mode
• Keeping UEs in detached state when not communicating.

Finally, 3GPP agreed to introduce Power Saving Mode (PSM) feature for devices in Release 12.

9.5.1 General

IoT applications are in general assumed to be access agnostic. The application layer needs connectivity (e.g. IP connectivity) to transport application specific payload between IoT device and AS. However, especially the connectivity and mobility pattern of typical telemetry type use cases differs substantially from that of mobile smart phones which are usually always online. The EPS design focussed mainly on highly mobile always‐on use cases. The IoT use case was not supported in an optimal way, until the MTC related work items improved the efficiency of infrequent and small data usage patterns. The main stage 2 architecture specifications for CIoT are TS 23.401 [14] and TS 23.682 [27].

Up to Rel‐12, the 3GPP M2M work introduced compatible and evolutionary improvements to serve MTC devices more efficiently within the existing GPRS and EPS architectures. CIoT in Rel‐13 took a revolutionary approach by introducing a new architecture supporting small data transfer with the ‘CIoT EPS Optimization’ feature set that is not fully backwards compatible with the Rel‐12 EPS architecture.

The Service Capability Exposure Function, SCEF was introduced in the earlier 3GPP releases for monitoring the UE mobility and registration status. It is re‐used in CIoT for user data transport. The Rel‐14 work item ‘Non‐IP_GPRS’ imported some selected Rel‐13 CIoT EPS Optimizations to GPRS, allowing the support of Non‐IP Small Data and the user plane Small Data via SGSN and SCEF. The PS domain and the triggering part of the architecture is shown in Figure 9.4.

The SCEF handles Non‐IP PDN connections over the control plane. The PGW handles all types of PDN connections over control and user plane.

Also, other energy saving methods, such as UE PSM and extended idle mode DRX (eDRX) can be used in conjunction with CIoT EPS Optimizations. A UE that needs extremely long battery life benefits from eDRX or PSM. Both methods lead to extended but predictable UE unreachability periods, and consequently the need for the network to buffer downlink (DL) data towards UEs that may be unreachable due to their power saving cycle for up to some hours. The maximum eDRX cycle length depends on the hyper frame structure of the used radio. For example, the LTE maximum DRX cycle of 2.56 seconds can be extended via eDRX to more than 42 minutes, and in NB‐IoT up to almost three hours.

9.5.2 CIoT EPS Optimizations

One of the main goals of CIoT EPS optimizations is to allow reduction of the power budget and cost of a CIoT UE. While the legacy 3GPP 2G, 3G, and 4G technologies were optimized for continuous big data, downloading and streaming use cases of smart phones and PC dongles, CIoT is optimized for infrequent one‐shot small data transfer. Whether the CIoT EPS Optimizations lead to more compact or more elaborate network design, depends on the deployment. An all‐new standalone CIoT network need not support all the legacy network capabilities. Such a standalone CIoT network can be deployed as a Dedicated Core Network using the 3GPP DECOR feature or as an extra PLMN making use of Network Sharing (see [12]). But to support both the traditional EPS UEs and CIoT UEs in the same network elements, an integrated EPS and CIoT network needs to support both sets of capabilities. In integrated deployments, the selected network elements need to be updated to support CIoT EPS Optimization features.

The individual features in CIoT EPS Optimization feature set specified in TS 23.401 [14] can be supported selectively on both UE and network side, and they are not mutually exclusive, even though some conditions exist for the sake of achieving compatibility.

Although a new NB‐IoT radio access technology (RAT) was specified by 3GPP, CIoT EPS Optimizations features can use multiple radios, including WB‐E‐UTRAN (LTE) and GERAN. WB‐E‐UTRAN stands for wideband E‐UTRAN, contrary to NB‐IoT which is a narrowband technology based on E‐UTRAN.

The CIoT related improvements address the following areas:

1. Simplified UE implementation and power saving;
2. Network attach without PDN connectivity (possibly followed by PDN connectivity on demand);
3. Infrequent and short bursts of data;
4. Infrequent and long bursts of data;
5. SMS transfer for PS only UE without CS domain attach.

In addition to these four main optimization areas, a fallback to traditional EPS user plane connectivity is available.

9.5.3 Attach Without PDN Connection

Until Rel‐13, an EPS UE always requested PDN connection when attaching to the network. Rel‐13 CIoT allows a UE to request attach without PDN connection. Since this feature is not backwards compatible, and it would be rejected by an MME that has not been upgraded to support CIoT, the network capability to support attach without PDN connection is broadcast to the UE via the radio (in System Information Blocks). If support of this feature is broadcast, the UE can request for attach without PDN connectivity.

The EPS attach procedure including security runs normally, but session management and bearer establishment procedures are omitted. The logic to support attach without PDN connection is to allow a minimalistic UE implementation. Such a UE can still support location procedures and act as a transponder to indicate the present location of the cargo it is included in, and without having any PDN connection, it can communicate with an AS using SMS.

It is rather exceptional for 3GPP to specify a feature that is not backwards compatible with previous releases. The indication of no support for attach without PDN connection in the selected PLMN saves signalling for attach attempts that are doomed to fail. There is no way to obtain compatibility between networks that do not support attach without PDN connection and UEs that cannot support PDN connections. The fallback method for such case is designed in the UE, which needs to select another PLMN in attempt to obtain connectivity.

9.5.4 UE Requested and Network Supported CIoT Capabilities

Since many of the new CIoT EPS Optimizations are not backwards compatible, the network support cannot be taken for granted by the UE. To obtain compatibility between the CIoT EPS Optimizations that are supported on UE and network side, the main capabilities are indicated in System Information Blocks broadcast by the serving cell, and the supported capabilities are negotiated on NAS level between UE and MME ([15]).

The UE indicates in the ATTACH REQUEST the CIoT EPS Optimizations that it would prefer to use. The MME responds in ATTACH ACCEPT with the CIoT EPS Optimizations that it has chosen for this UE.

Network supported CIoT EPS Optimization features are the result of MME and other network elements capabilities, UE subscription and PLMN operator local policy in the MME. Broadcast network CIoT capabilities are:

1. – NB‐IoT and WB‐E‐UTRAN: Support of attach without PDN connection
2. – NB‐IoT and WB‐E‐UTRAN: Support of U‐plane EPS Optimization
3. – WB‐E‐UTRAN only: Support of C‐plane EPS optimization is only broadcast by WB‐E‐UTRAN cells, as in NB‐IoT both sides shall support it. Hence there is no need to indicate this capability over NB‐IoT.

The following CIoT UE requested and network supported capabilities are negotiated:

1. – Whether C‐Plane is supported or not;
2. – Whether U‐plane is supported or not;
3. – Whether S1‐U data transfer is supported or not;
4. – Whether SMS transfer without combined attach is supported;
5. – Whether attach without PDN connection is supported;
6. – Whether robust header compression (RoHC) is supported for C‐plane or not;
7. – If UE indicates support of both C‐plane and U‐plane, it also indicates which one it prefers.

9.5.5 Selection of Control or User Plane

One of the difficulties in designing CIoT was the lack of a single reference application using this kind of connectivity. The IoT traffic patterns vary substantially depending on the application. These span from very infrequent small data of tens or hundreds of octets once a day or week, to video streaming capability. It is also foreseen that some CIoT devices may need to change behaviour between pure telemetry‐type one‐shot messaging to large amount of data streaming, e.g. for updating SW or providing additional information in case of alarms. Thus, both small data and big data optimizations were specified.

Control Plane CIoT EPS Optimization works most efficiently with applications whose data transfer needs area infrequent and small. User Plane CIoT EPS Optimization is an efficient method of sending either a large amount of data or frequent small data. It is not possible to give a single answer which one is more efficient, as the breakeven point in terms of message round trips depends on the traffic pattern of the CIoT application.

The properties of the PDN connection are determined when the connection is established. The UE may request an IPv4, IPv6, dual stack IPv4/IPv6, or Non‐IP PDN type. The Non‐IP type was added for CIoT EPS Optimizations.

It is possible for the MME to ‘pin’ a PDN connection to control plane by including the ‘Control Plane Only Indicator’ in the PDN connection establishment signalling. A pinned PDN connection is permanently locked to the control plane, and it cannot be changed to user plane transport during its life time.

If a PDN connection is not pinned to the control plane, it is possible for either the UE or MME to switch a PDN connection between control and user plane transport.

9.5.6 Control Plane CIoT EPS Optimization

Figure 9.5 shows the possible control plane data paths via SCEF and P‐GW.

The network can provide Control Plane CIoT EPS Optimization via two paths, either via the P‐GW and its SGi interface, or via the SCEF that was initially introduced to exposure data like UE registration status and reachability to the Application Server (AS) via T8/API. These paths are differentiated by different access point names (APNs) hosted by P‐GW or SCEF. The MME determines between use of T6 interface towards SCEF and S11/S5 interfaces towards S‐GW/P‐GW based on the APN, either requested by the UE or one that is selected by the MME. The APN selected by the MME can be the default APN stored in the HSS as part of the subscription data. In case of P‐GW, EPS interfaces S5 and S8 are re‐used, in case of SCEF, the T6 interface between MME and SCEF, and the T7 roaming interface towards the Interworking Service Capability Exposure Function ( IWK‐SCEF) needs to be supported. P‐GW and S‐GW can support IPv4, IPv6, IPv4v6 dual stack, and Non‐IP PDN connection types, but the SCEF supports only Non‐IP PDN connections.

User data are encapsulated in NAS signalling messages (NAS Packet Data Unit). Establishment of a Data Radio Bearer (DRB) is omitted, as the Signalling Radio Bearer (SRB) carries also the user data payload. The encapsulated user data messages may be chained to allow application level dialogues by indicating in the NAS signalling that there are more data to send. However, the Control Plane CIoT EPS Optimization yields the highest efficiency on one‐shot messages, and if the network sees that the UE is sending an excessive amount of small data using control plane procedures, and if both Control Plane and User Plane CIoT EPS Optimization have been negotiated during UE attach, then the network can assign a DRB and move the transport of user data from control plane to user plane.

A CIoT UE with infrequent and small data traffic pattern may use power saving optimizations such as extended idle mode DRX (eDRX) or PSM to optimize the UE power budget. Both eDRX and PSM allow the UE to negotiate with the MME sleep cycles during which it need not listen to paging. During this sleep cycle, the UE is considered by the network as not reachable, and consequently the network needs to buffer all incoming data for later delivery. The S‐GW and the SCEF, based on the MME awareness of the UE sleep cycle, may buffer data until the UE becomes available again. If the UE sleep cycle is excessively long, the AS may be notified about UE unreachability and the estimated reachability time. MME is aware of the negotiated eDRX and PSM cycles, and thus able to predict when the UE might respond to paging again. If MME receives downlink C‐plane data ‘just before’ the next UE Paging Time Window (PTW), then subject to MME local policy and buffering capacity, the MME may buffer the data while waiting for the next paging opportunity. If the MME considers the amount of data or time for buffering excessive, it can request S‐GW or SCEF to buffer the message by indicating that the UE is not reachable and giving an estimate of the next paging opportunity.

User identification in Control Plane EPS Optimization follows the same principles irrespective of IP type or P‐GW versus SCEF path. Inside the 3GPP system the user is identified by IMSI. IMSI is not disclosed outside of the operator's trust domain, but publicly usable identities are External Identifier or MSISDN. Since the MSISDN has been made optional in earlier releases, a CIoT UE can be addressed without having MSISDN assigned to it.

P‐GW and SCEF establish a mapping between IMSI and External ID or MSISDN at connection setup, and they do the mapping of internal (IMSI) and external (External ID or MSISDN) identities of the UE as well as the mapping of the PDN connection related EPS Bearer Identities to the services provided by the ASs.

Volume based rate control would not be practical with infrequent small data, so the Control Plane rate control is based on counting of messages that are sent over a period of time. There are different rate control parameters for uplink (UL) and DL traffic.

In roaming situations (Figure 9.6), both home PLMN (HPLMN) and visited PLMN (VPLMN) may apply rate control on C‐plane messages. Serving VPLMN operator cannot dimension the data volumes for the services that are running on roaming CIoT UEs. The Serving PLMN rate control is for safeguarding the serving MME from overload excessive C‐plane user data message exchange might cause. APN rate control is set up by the HPLMN operator to dimension the service in terms of how many messages in the agreed time unit a CIoT UE can send or receive.

9.5.7 User Plane CIoT EPS Optimization

User plane connectivity in EPS is always provided via S‐GW and P‐GW. Normal S1 user plane connection procedures are also supported for a CIoT UEs, i.e. connection establishment and release after data transmission, without the option to suspend and resume connections.

User Plane CIoT EPS Optimization (see Figure 9.7) uses S1‐U between eNB and S‐GW and DRB on the radio interface between UE and eNB for user data transport (see e.g. [8]). This suits well application level dialogues and occasional big data, e.g. for device configuration or SW updates.

Transport of data via user plane (DRB and S1‐U) is by default supported in EPS, but it fails to address the infrequent data transport pattern of IoT device as it incurs signalling overhead to setup and tear down the RRC and User plane connection. User Plane CIoT EPS Optimization adds the capability to suspend the existing RRC connection between UE and eNB when no data are transferred, and to resume it later, to minimize the signalling overhead introduced by RRC connection and UE context setup (see Figure 9.8). In addition, a CIoT UE can fall back to normal S1‐U EPS user plane procedures.

The eNB, based on detected UE inactivity, requests the MME to suspend the connection. The MME will trigger bearer release on the user plane but keeps the UE context for later use. The suspend is indicated to the UE in an RRC message, including the Resume ID that the UE stores for later use when it needs to resume the connection (Figure 9.9).

The UE identifies the connection to be resumed with the Resume ID, and if the UE context is available in eNB, it is resumed. If the previously suspended connection cannot be resumed, e.g. due to UE mobility, then normal RRC connection establishment is performed.

9.5.8 Non‐IP PDN Connection

The 3GPP system already supports IP types IPv4, IPv6, and IPv4v6 dual stack. The fourth IP type ‘Non‐IP’ was added for CIoT to minimize the IP header overhead. The support of header compression is one of the optional features that are negotiated in UE requested and network supported CIoT EPS Optimizations during the attach procedure. IP header compression is obviously not useful for Non‐IP data as IP header is not included.

Non‐IP data refers to data without IP header sent over Non‐IP PDN connection. Since there is no IP header, header compression (e.g. RoHC) techniques are unnecessary for such data.

The P‐GW can support Non‐IP data as one of its four IP types, but the SCEF is restricted to Non‐IP control plane data only.

Non‐IP PDP type and T6b interface between SGSN and SCEF was added in Rel‐14 to allow the GPRS system to support Non‐IP Data Delivery (NIDD) via SCEF.

9.5.9 SMS Transport

A UE that has attached without PDN connection cannot send or receive any Control Plane data or User Plane data. This leaves SMS as the only means of data transport available for a CIoT UE that has attached without PDN connection. Such a UE need not support CS domain procedures, PS only registration is possible and indicated in the attach procedure. SMS is transported using the same NAS message encapsulation principle as in NIDD but using a different NAS protocol data unit (PDU). The data path is shown in Figure 9.10.

SMS for CIoT only requires PS SMS support for a UE. As the CIoT UE is likely to use long eDRX or PSM cycles, thus the same challenges with long UE unreachability periods like in MT NIDD will arise.

The SMS architecture differs from the one used for NIDD, but the principle for handling extended UE sleep cycles is the same: the network elements need to buffer a MT SMS towards the UE that has just started its extended power saving cycle. The maximum eDRX time is (depending on RAT) in the order of hours, and the maximum predictable PSM cycle is more than a year. This is not necessarily a practical value applicable in a network, but it shows why network elements do have the option to reject downlink messages with an indication that the UE is not reachable instead of buffering it.

9.5.10 Rel‐14 CIoT Extensions

CIoT functionality was further enhanced under two 3GPP work items in Rel‐14, ‘Non‐IP GPRS’ and ‘CIoT Extensions’.

9.5.10.2 Coverage Enhancement

Coverage Enhancement (CE) allows a UE in a weak coverage area to access the network even with low signal strength. CE techniques (e.g. using higher transmit power at the base station) allow for compensating coverage loss due to reduced number of antennas in low‐cost devices and for LTE coverage extensions to static devices in locations prone to weak coverage such as the basement. CE was already a 3GPP Rel‐13 feature, but since CE consumes more network resources than non‐CE operation, Rel‐14 added the network capability to control use of CE based on subscription information. The HSS subscriber data indicate per PLMN whether CE is allowed for the user or not. For backwards compatibility reasons, the UE assumes that CE is allowed, unless it is explicitly restricted by the serving PLMN.

The CE setting is negotiated during attach procedure (Figure 9.11), where the MME informs the eNB of CE authorization. The eNB can then determine the CE level based on the UE capabilities and the subscriber data it receives from the MME. When paging the UE, MME includes the CE information in S1 paging message. It is also possible for the AS to request CE, if the subscription allows it.

9.5.10.3 Reliable Communication Service Between UE and SCEF

Use of reliable transport protocols on the path between UE and SCEF provides reliable delivery at each hop, but it cannot guarantee successful processing on the application layer. A message that is successfully transported may still contain syntactical or semantical issues causing it to be ignored or rejected by the receiver.

Reliable communication service between UE and SCEF (Figure 9.12) overcomes this problem for the chargeable NIDD information in two alternative ways. The full end‐to‐end solution exists of an overlay protocol between UE and SCEF managing the acknowledgements each way to ensure error handling and successful delivery. An alternative solution is based on hop‐by‐hop security, where each interface is secured by acknowledgements.

9.5.10.5 MBMS Service for CIoT

CIoT EPS Optimizations do not prevent multimedia broadcast/multicast service (MBMS) operation, but the foreseen extremely long eDRX or PSM UE power saving cycles pose the usual problem of UE reachability also for data delivery via MBMS (see [11]). In the case of multicast and broadcast services, the problem is slightly different from the standalone UE reachability for NIDD, as the service would need to be offered to multiple UEs whose non‐synchronous PTW reachability periods between sleep cycles are scattered randomly over the maximum sleep cycle range that is used.

The basis of the solution builds on synchronizing the receiving UEs to wake up for receiving broadcast data at the same time. Depending on the application, the solution can be AS or UE centric.

The AS may issue a trigger to the UEs to wake up for MBMS service announcement (see [11]) well ahead of the data delivery so that all affected UEs can receive the service announcement timely before data delivery, as shown in the Figure 9.13 (reference 3GPP TR 23.730 [28]). The figure shows UE1 using a shorter eDRX cycle than UE2.

The UEs may also be configured to wake up at a certain pre‐configured time to check a potential MBMS service announcement. Once the service announcement is issued, both methods are aligned, but with this UE synchronization the lead time needed before the data transfer is shorter, as all UEs are synchronously reachable at the same time of the day.

9.5.10.7 QoS Differentiation Between UEs Using Control Plane CIoT EPS Optimization

CIoT applications are expected to span a wide range of services, ranging from toys and hobbies to critical application involving safety, security and money. Prioritization mechanisms are needed to ensure that critical IoT services do not suffer when a large number of low priority applications are connected in the same place at the same time.

Serving PLMN Rate Control protecting the serving MME from NIDD overload should ideally never need to be enforced, as that throttles the traffic that otherwise would fit in the APN Rate Control quota that dimensions the service in terms of number of messages in time unit. Priority mechanism is designed for the case when a dense population of CIoT devices operating within their rate control limits would risk congesting the control plane.

Figure 9.14 shows an RRC connection establishment, where the eNB retrieves the UE context using the temporary UE identity from the MME, and may apply prioritization between UEs when establishing the RRC connection.

9.5.10.8 CN Overload Protection in Control Plane

General overload protection mechanisms already exist, but in case of control plane overload (see Figure 9.15), it would be an overkill to deny other services unnecessarily. Part of the deal is that a UE blocked for control plane access is encouraged to use user plane services instead.

Already before CIoT, an MME may request eNB to reject connection requests on its behalf to avoid congestion. If the MME load is mainly due to processing control plane NIDD traffic, then the MME may send S1 OVERLOAD START indicating control plane overload. This instructs the eNB to reject control plane data transmission requests from the UE with a control plane back‐off timer.

Following the traditional back‐off timer principle, the UE processing of control plane back‐off timer prevents new control plane requests, but as the control plane back‐off does not affect the user plane data transfer, the UE is allowed using user plane connection, if this was negotiated during attach.

9.5.11 Northbound API for SCEF (NAPS)

The T8/API interface between SCEF and SCS/AS was out of scope of 3GPP specifications until Rel‐14. In Rel‐15, 3GPP specified the T8 interface in detail. As the main goal of this work was to satisfy the need providing a single application programming interface (API) to manage MTC UEs, also the option for co‐located MTC‐IWF – SCEF deployments was added so that triggering services available via MTC‐IWF can be provided over T8 using a common API.

Some modifications and improvements of the existing 3GPP services were also made under the Northbound API for SCEF – SCS/AS Interworking (NAPS) work item. Depending on network authorization and local policy, the AS may request certain UE reachability and buffering parameters. In earlier 3GPP releases, the AS could set network parameters for monitoring and buffering only in a monitoring request, but a standalone ‘Network parameter configuration’ procedure was added under NAPS work item.

The parameters the AS may request from the serving 3GPP network are Maximum Latency that guides the setting of periodic update timer by indicating how frequently the AS wants to communicate with the UE, the Maximum Response Time controlling the period of time that the UE remains reachable when it has woken up from power saving, and the Suggested Number of Downlink Packets that gives a hint of the foreseen buffer size.

The other enhancements include the capability for the AS to request CE to be used (subject to authorization), and the addition of source and destination port numbers to identify applications.

9.6.1 Introduction

The continued growth of MTC and IoT provide new business scenarios for MNOs. To serve this demand, different technologies were standardized in 3GPP Release 13, Release 14, and Release 15, such as LTE based enhanced machine type communication (eMTC) and NB‐IoT as well as GSM based Extended Coverage‐GSM‐IoT (EC‐GSM‐IoT), the latter being dealt with in this section. It is shown how key radio aspects of a Cellular IoT system – such as enhanced coverage (EC), efficient small data transmission, high system capacity, low device complexity, energy efficient device operation and flexible usage in existing network deployments – are realized in the EC‐GSM‐IoT system. For this purpose, the objectives defined as part of the Cellular IoT study item for 3GPP Rel‐13 are depicted, followed by an overview of the design aspects of the selected EC‐GSM‐IoT solution. Then logical channel design and basic concepts of EC‐GSM‐IoT such as Coverage Class design, Overlaid Code Division Multiple Access (CDMA) and the description of idle and connected mode operation are presented. Finally, improvements to operation in tight frequency reuse networks and enhancements standardized in 3GPP Rel‐14 and Rel‐15 are briefly summarized.

9.6.2 Objectives

Objectives for EC‐GSM‐IoT were set during the Feasibility Study on Cellular Support for IoT, carried out in 3GPP TSG GERAN in 2014 and 2015, which investigated both backward compatible and clean slate solutions and generated the Technical Report 3GPP TR 45.820 [16]. These relate to:

• Enhanced coverage. CE versus GPRS by 20 dB to cover devices in extended coverage (e.g. indoor, basements, shielded in moving vehicles) with support of both stationary devices and moving devices (speed up to 50 km h⁻¹).
• Efficient small data transmission. Allowed latency of 10 s for high priority reports such as alarms; minimum supported data rate on downlink and uplink of 160 bps on the SubNetwork Dependent Convergence Protocol (SNDCP) layer.
• High system capacity. Capacity enhancement versus GPRS; support of massive number of devices (∼52 500 per cell) based on the assumptions of 40 devices per household (metropolitan area).
• Low device complexity. Low device cost with considerable complexity reduction versus GPRS legacy mobiles.
• Energy efficient device operation. Long battery life time of targeted 10 years with 5 Wh battery to minimize operational efforts for most battery‐operated devices.
• Flexible usage in existing network deployments. No HW impact to GSM/EDGE legacy networks due to introduction of this technology and support of combined operation with GSM/EDGE legacy networks in the same spectrum as well as of standalone operation in separate spectrum.
• Non‐radio related aspects. Improved security compared to GSM/EDGE achieved by the introduction of integrity protection and improved ciphering algorithms as output of the feasibility study undertaken in 3GPP TSG SA3 [17].

9.6.3 Feature Design Overview

Among the investigated candidates, EC‐GSM‐IoT has been selected as the backward compatible GSM based solution for CIoT and been standardized in 3GPP Rel‐13. To satisfy the feasibility study objectives, the following design aspects are aligned to the key radio aspects of a CIoT network.

Enhanced Coverage

• Introduction of four coverage classes to support devices on different coverage levels up to Maximum Coupling Loss (MCL) of 164 dB, supporting physical layer repetitions both in normal and extended coverage, more robust channel encoding for some logical channels and Hybrid Automatic Repeat Request (ARQ) for retransmitted traffic data.

Efficient Small Data Transmission

• Handling of device exception reports (indicating, e.g. alarms) with higher priority.
• Handling of small data payloads of few bytes in few 20 ms radio blocks (normal coverage). High System Capacity
• Usage of Coverage Class specific training sequence for random access to lower failure due to collisions.
• Coherent repetition of bursts in same Time Division Multiple Access (TDMA) frame, thus improving co‐channel and adjacent channel interference performance in connected mode.
• Introduction of Overlaid CDMA allowing to multiplex up to four devices in extended coverage for data transfer on the same uplink resources. Low Device Complexity
• Simplified half duplex operation with relaxed switching times: either transmit or receive operation per each TDMA frame to lower device complexity.
• Reduction of puncturing patterns compared to enhanced general packet radio service (EGPRS) to lower device complexity.
• Use of Fixed Uplink Allocation (FUA) to achieve resource efficiency for delay tolerant services and to omit Uplink State Flag (USF) monitoring yielding energy efficient operation in connected mode. Energy Efficient Device Operation
• Support of extended DRX (eDRX) and/or PSM in idle mode reducing paging availability of the device to ensure long battery lifetime.
• Support of Power Efficient Operation (PEO), indicated per cell, to support relaxation for measurement requirements for the device.
• Energy efficient downlink common control channel (CCCH) operation to reduce paging and access grant monitoring time.
• Removal of continuous timing advance procedure in connected mode to adapt to the range of device speeds and to lower device complexity. Flexible Usage in Existing Network Deployment
• Support of existing infrastructure: Radio frequency (RF) and baseband processing performance requirements are defined in a way to support legacy base stations in the field.
• Support of both combined/standalone system operation through CCCHs for EC‐GSM‐IoT operated on different timeslots of the Broadcast Control Channel (BCCH) carrier (i.e. TN 1, TN 3, TN 5, and TN 7) than used for legacy GSM/EDGE CCCHs (i.e. TN 0, TN 2, TN 4, and TN 6) and support of tighter frequency reuse by extended base station identity code (BSIC).
• Scalable resources for EC‐GSM‐IoT, such that at minimum one additional timeslot is needed for EC‐GSM‐IoT CCCHs in a combined deployment with legacy GSM/EDGE.

9.6.4 Logical Channel Design

Out of the logical channels for GSM/(E)GPRS, only the frequency correction channel (FCCH) is reused due to its suitable power spectral density (PSD) characteristics, while all other logical channels for EC‐GSM‐IoT have a new design compared to (E)GPRS. The set of logical channels for EC‐GSM‐IoT is depicted in the Table 9.2.

9.6.5 Coverage Class Concept

To enable operation of devices in normal and in extended coverage, the concept of Coverage Classes (CC), applicable to the operation on the radio interface only, was introduced in 3GPP. For EC‐GSM‐IoT, each of the defined four Coverage Classes serves for operating a device according to its coverage condition, up to the CE target of 20 dB versus GPRS. The coverage gain is obtained through:

• The use of blind physical layer repetitions, i.e. consecutive repetitions of radio blocks over a larger number of TDMA frames thus increasing the effective transmission time interval (TTI) of the basic radio block. At the receiver the repetitions across TDMA frames are soft combined.
• The coherent transmission of four consecutive bursts within a TDMA frame by applying the same initial modulator phase and amplitude for the start of each burst (or in case of Overlaid CDMA a sequence of predefined burst phase shifts, see Section 9.6.6). At the receiver, the IQ samples of the four bursts are accumulated providing ideally a signal power gain of 12 dB and an signal‐to‐noise ratio (SNR) gain of 6 dB.
• The use of Hybrid ARQ after the receiver has sent feedback information on the received blocks. At the receiver side, the initial transmission and retransmissions are soft combined.
• The use of more robust encoding for CCCHs in downlink and for the packet associated control channel in downlink and uplink conveying smaller payload sizes compared to (E)GPRS.

Figure 9.16 illustrates the assignment of the defined four Coverage Classes to devices located outdoor or indoor with increasing building penetration loss requiring an increase of the applied Coverage Class.

The details of the coverage classes are summarized in the following Tables 9.3–9.5 for the packet traffic channel and for the CCCHs. The MCL figures are taken from 3GPP TS 43.064 [18] and confirm a maximum gain of 20 dB versus GPRS with a reference MCL of 144 dB [16].

Depending on the traffic load, the network may request the MS using Coverage Class 1 to perform the channel access either on TN 0 using legacy channels or on TN 1 using EC channels, which is signalled in the synchronization channel (EC‐SCH). In addition, as an option the random access channel (EC‐RACH) can be operated on dual timeslots (TN 0 and TN 1). For this deployment option, indicated in the broadcasted EC System Information, the device transmits the same number of repeated access bursts for Coverage Classes CC2 to CC4, as given above, both on TN 0 and TN 1 and uses coherent transmission between TN 0 and TN 1 to enable IQ combining at the base station, which yields further improved sensitivity and interference performance compared to the single timeslot EC‐RACH configuration. Each Coverage Class on EC‐RACH is assigned a distinct new synchronization sequence to enable the Base Transceiver Station (BTS) distinguishing these channel requests from those originated by legacy GSM/(E)GPRS users.

The design of logical channels for network synchronization to EC‐GSM‐IoT cells, depicted in Table 9.6, was made sufficiently robust to allow operation in the entire targeted range for extended coverage.

9.6.6 Overlaid CDMA

To improve system capacity for mobile originated data transfer, Overlaid CDMA may be applied on the uplink packet data traffic channel (EC‐PDTCH/U) for users in a higher coverage class (CC2 to CC4) using four consecutive timeslots per TDMA frame. This allows the network to multiplex up to four mobile stations on the same uplink physical resources for simultaneous transmission of packet data.

Orthogonality between mobile stations is achieved through orthogonal codes, corresponding to a set of phase shifts to be applied on a per transmitted burst basis. The phase shifts shall, in sequence, be applied to the transmitted bursts per TDMA frame. For this purpose, an individual Hadamard sequence is used by each device multiplying the modulation symbols with the predefined phase shifts, being multiples of π, for the four consecutive bursts in the TDMA frame. By knowing the Hadamard sequence of each multiplexed device, the base station can distinguish the transmissions of the multiplexed devices, since based on orthogonal codes and provided the amplitude and phase coherency requirements between consecutive bursts are satisfied by each device.

Overlaid CDMA is used on the packet data channel and its packet associated control channel (EC‐PDTCH and EC‐PACCH) and the code to be used is included in the channel assignment command. Figure 9.17 depicts the principle of Overlaid CDMA for achieving orthogonality between uplink transmissions (for details see [19]).

Either two, three, or four users may be multiplexed in 3GPP Rel‐13 on 4 consecutive time slots; additionally in 3GPP Rel‐14 two users on two consecutive timeslots can be multiplexed. Support of Overlaid CDMA is mandatory for the mobile station and optional for the base station.

9.6.7 MS Support Level for EC‐GSM‐IoT

Different support levels are specified for the device. Aside non‐support, the device may support only EC‐GSM‐IoT, in which case it cannot camp on a legacy GPRS/EGPRS cell, or it may support EC‐GSM‐IoT in combination with GPRS/EGPRS, in which case this restriction does not apply, i.e. the device may (re‐)select to a legacy GPRS/EGPRS cell or a EC‐GSM‐IoT cell depending on the received signal level.

9.6.8 Operation in Idle Mode

9.6.9 Operation in Connected Mode

The EC‐GSM‐IoT device leaves packet idle mode and enters connected mode (packet transfer mode) when it has received a matching page or when there is a trigger due to data on higher layers to be sent from the device to the network.

9.6.10 Location Services

EC‐GSM‐IoT in 3GPP Rel‐13 supports cell ID TA procedure. Both the timing advance to the serving cell, the cell ID and optionally received quality parameters are sent to the Serving Mobile Location Centre (SMLC) determining the location estimate, which is fed back to the SGSN in the Core Network (CN). An enhanced location method is specified in 3GPP Rel‐14 (see Section 9.6.14).

9.6.11 Core Network Support

To achieve energy efficient operation in idle and connected mode, the device attaches to the network indicating EC operation and negotiates its eDRX cycle or its PSM active timer with the Serving GPRS Support Node (SGSN) in the CN. The CN takes the restricted paging availability of the device into account and eventually postpones the paging request based on feedback from the Base Station Subsystem (BSS), which has knowledge of the paging group occurrence for the device under interest. The BSS also forwards DL and UL coverage class as well as cell ID information in connected mode to the SGSN which is used for subsequent paging requests in idle mode. In case the device selects a higher DL coverage class in idle mode due to degraded radio conditions, a cell update is sent to the SGSN including the new DL CC to be used for subsequent paging requests. These messages are exchanged on the Gb interface between BSS and SGSN. Due to longer radio transmissions, the CN uses increased NAS timer values for EC‐GSM‐IoT devices compared to legacy GPRS/EGPRS devices to avoid NAS layer timeouts when the device is in extended coverage.

9.6.12 Security Enhancements

Several enhancements are introduced for EC‐GSM‐IoT to protect the user data from undesired interception or mitigate operation of faked base stations or EC‐GSM‐IoT devices. Weak ciphering algorithms on the user plane such as GEA1 to GEA3 were removed for EC‐GSM‐IoT and only the usage of GEA4 [21] and the newly introduced GEA5 [23] are allowed, while there is no ciphering on the control plane. In addition, integrity protection has been introduced with the definition of GIA4 and GIA5 algorithms for NAS layer messages [22,23].

9.6.13 Operation in Reduced Spectrum Allocation

For reduced spectrum allocation due to tight frequency reuse networks, the system operation has been optimized by introducing following measures:

1. Usage of a longer 9‐bit BSIC, consisting of the Network Colour Code (NCC, 3 bit), the Base Station Colour Code (BCC, 3 bit), and the Radio Frequency Colour Code (RCC, 3 bit). The new RCC part is used to distinguish cells operating on the same BCCH carrier frequency. For instance, in a 1/3 tighter reuse network, the same BCCH carrier frequency is used in one cell of each three‐sectored cell site and hence the device synchronizing to the network and selecting the best available cell needs to have means to distinguish between these sector cells. The 9‐bit BSIC is contained in the EC‐SCH. The 9‐bit BSIC is also supported by PEO devices, not supporting EC‐GSM‐IoT but eDRX and/or PSM on NAS level, composed by the 6‐bit long BSIC being signalled in the SCH and the 3‐bit RCC broadcast in the BCCH as well as in PCH/AGCH rest octets.
2. Signal power measurement mandated for the device: The mandated usage of measurements on FCCH and EC‐SCH channels, further the removal of interference and noise contributions to determine the signal power of the cell, and the definition of new cell reselection criteria yield improved performance in particular in tighter reuse networks with larger interference power levels compared to the legacy measurement method, requiring the mobile to measure the total power including noise and interference for cell selection purposes, and hence degrading the estimation of the received quality of a cell in this scenario.
3. Signal to interference plus noise ratio (SINR) based Coverage Class Selection: In addition to signal level based DL and UL coverage class selection, an SINR based DL coverage class selection is specified. The network signalling SINR based DL CC thresholds requires the device to estimate the appropriate DL CC based on the experienced SINR yielding improved performance in tighter frequency reuse networks, typically being interference limited.

Operation of EC‐GSM‐IoT in tighter frequency reuse networks is described in more detail in 3GPP TR 45.050 [24].

9.6.14 Rel‐14 Enhancements

In 3GPP Rel‐14 following enhancements for EC‐GSM‐IoT were standardized:

• Positioning enhancements. Position accuracy of EC‐GSM‐IoT devices is improved with a target of 100 m by using Multilateration Timing Advance (MTA). The device being paged in idle or connected mode, reselects to the strongest cell and performs channel access to this cell as well as to other suitable, non‐co‐sited cells to enable the BSS to acquire the timing advance to multiple cell sites and to report these measurements to its assigned SMLC which performs a Timing Advance multilateration for determining the position of the device. SMLC forwards this information via the CN to the requesting application. In addition, Multilateration Observed Time Difference (MOTD) is introduced, where the SMLC after the mobile station's reselection to the strongest cell, provides it with assistance data for selecting appropriate neighbour cells for measuring observed time differences of arrival between the strongest cell and any of these neighbour cells at its location and reporting them via the BSS to the SMLC. MOTD provides better device energy efficiency since minimizing transmissions, but exhibits lower position accuracy compared to MTA. It may be used in synchronized networks in standalone mode and in non‐synchronized networks in combination with MTA. The functional description for MTA and MOTD is contained in 3GPP TS 43.059 [25].
• Support of Dedicated Core Networks (DCN). The support of a DCN for EC‐GSM‐IoT requires to (re‐)route data and control information from the BSS to the correct CN node. This (re‐)route capability is controlled by new information elements: UE Usage Type (fetched by the SGSN from HSS), SGSN Group Identity and additional P‐TMSI.
• Radio Interface Enhancements. Alternative mappings for higher Coverage Classes (CC2 to CC4) based on two consecutive PDCHs (i.e. time slots), rather than four consecutive PDCHs as used in 3GPP Rel‐13, are introduced in 3GPP Rel‐14 both for downlink and uplink packet traffic channels and associated signalling channels to allow for EC‐GSM‐IoT data transfer in conditions with constraint radio resources, i.e. few carriers in the cell, or temporary high traffic load due to other services. In this case Overlaid CDMA is supported on two consecutive time slots, see Figure 9.17. In addition, a more robust Coverage Class (CC5) for uplink is designed to achieve a target MCL at least 3 dB higher compared to 3GPP Rel‐13, this enabling an uplink MCL beyond 164 dB for devices with 33 dBm and equally improving uplink MCL for devices with low output power (i.e. 23 dBm) towards 157 dB, thus getting closer to downlink MCL. The functional description is contained in 3GPP TS 43.064 [18].

9.6.15 Rel‐15 Enhancements

In 3GPP Rel‐15 following enhancements for EC‐GSM‐IoT were standardized:

• Further enhancements. With the increase of CIoT deployments, new use cases requiring reduced latency for network commands are becoming more relevant. Use cases, such as the unlocking of smart‐bikes based on payment reception at server or network command based tracking of devices for fleet management purposes, require low latency for the network command which in turn requires the MS to operate a lower eDRX cycle, such as a few minutes rather than tens of minutes, while the frequency of network commands to the MS in these use cases is still expected to be rather low. However, the lower eDRX cycle will yield a substantial decrease of the battery life time; a reduction from beyond 10 years to 2.5 years is observed calling for further MS energy savings [26]. Two enhancements are specified in 3GPP Rel‐15 which are expected to yield significant MS energy savings for these scenarios:
  1. ∘ Introduction of a paging indication channel (EC‐PICH): using up to two bursts, informing the EC‐GSM‐IoT device in a higher coverage class (CC3 or CC4) on the presence of a paging request in upcoming paging blocks and thus allowing for an early ‘go‐back‐to‐sleep’ mode, in case no paging is indicated. This enhancement particularly reduces energy consumption of the device in extreme coverage; a reduction of up to around 25% for a stationary device in CC4 was evaluated [26].
  2. ∘ Introduction of deferred System Information acquisition: mitigating the need to read system information messages on EC‐BCCH, for cell reselection as well as after cell reselection to a specific neighbour cell prior to receiving a matching page in that cell. This is achieved through the definition of common cell parameters for idle mode mobility, such as broadcast carrier allocation, PCH organization, cell reselection parameters and Coverage Class threshold parameters, for a group of geographically contiguous cells, which is known to the MS in the serving cell prior to performing cell reselection to another cell. The MS will thus defer the reading of EC System Information for these cells after receiving a matching paging request. This enhancement is observed to yield an energy consumption benefit of up to around 35% [26] and will particularly serve well for devices with low or moderate velocity. At the time of writing, the specification of this feature is being finalized, the functional description being contained in 3GPP TS 43.064 [18].

9.8.1 Introduction

NB‐IoT was standardized in Rel‐13 to provide low‐power, wide‐area cellular access for IoT devices. It is a new radio access system built from existing LTE functionalities with essential simplifications and optimizations. The design objectives for NB‐IoT include (see [16]):

• Support of ultra‐low complexity and low‐cost devices.
• Improved coverage of 20 dB compared to legacy GPRS, corresponding to a MCL of 164 dB. At this coverage level, a data rate of at least 160 Bps should be supported at the application layer.
• Support of massive number of low‐throughput devices, at least 52 547 devices within a cell‐site sector.
• Improved power efficiency, battery life of 10 years with battery capacity of 5 Watt/hour.
• Exception report latency of 10 seconds or less for 99% of the devices.

These design objectives can be met with the following techniques:

• Reducing device complexity by supporting only narrow channel bandwidth of 200 kHz, having only one receiver antenna at the device, half‐duplex operation only, reduced peak data rates, and supporting relaxed processing time.
• Improving coverage via narrowband transmission, using repetition, power boosting, and using single‐tone transmission with low power backoff requirement in the uplink.
• Supporting a large number of devices by using single‐tone/multi‐tone transmission, signalling reduction for small data transmission, and using multiple carriers.
• Improving power efficiency by minimizing downlink and uplink transmissions using extended discontinuous transmission/reception (eDRX), PSM, signalling reduction for small data transmission, and low peak to average power ratio modulation schemes in the uplink.
• Reducing delay for exception report by signalling reduction for small data transmission and adding an establishment cause for exception reporting.

NB‐IoT occupies 180 kHz of spectrum, which is equivalent to the bandwidth of one PRB in LTE. It can be deployed in three operation modes, in‐band within an LTE carrier, in the guard‐band of an LTE carrier, and as a stand‐alone carrier. In in‐band operation mode, each NB‐IoT carrier uses one LTE PRB. This allows LTE and NB‐IoT to seamlessly share valuable spectrum between the two systems. In addition, broadband traffic served by LTE is downlink centric, while IoT traffic served by NB‐IoT is uplink centric. Thus, the two systems can share spectrum efficiently.

In guard‐band operation mode, NB‐IoT will be deployed in the guard‐band of an LTE system. This allows IoT services to be supported without eating up LTE spectrum. This operation mode is most suitable for wideband LTE with bandwidth greater than or equal 5 MHz. This is because there is sufficiently large amount of guard‐band available allowing NB‐IoT to be deployed without co‐existence issues.

In stand‐alone operation mode, each NB‐IoT carrier can be deployed as a replacement for one GSM carrier. This provides the ability to efficiently refarm spectrum from older GSM technology to support IoT services.

NB‐IoT design is based on LTE and supports most LTE functionalities with many simplifications and some optimizations to support low‐power, wide‐area, and low data‐rate IoT services. Reusing LTE design where possible has been vital in achieving rapid specification of NB‐IoT in Rel‐13.

Table 9.9 lists downlink (DL) and uplink (UL) NB‐IoT channels and signals and their functions. A summary of each channel and signal is provided in this section (see also [35], [36], [37], [38], [39]).

9.8.2 Coverage

Coverage evaluation is provided via link budget analysis. Table 9.11 illustrates NB‐IoT link budget for in‐band deployment. In this operation mode, eNB transmission power must be shared between NB‐IoT and LTE. In this analysis, the total eNB transmit power is 46 dBm, resulting in PSD per PRB of 29 dB. To improve coverage, 6 dB PSD boosting is used for NB‐IoT, bringing the total transmission power for NB‐IoT to 35 dBm. At the UE side, 23 dBm of power is available. Table 9.11 shows that the target MCL of 164 dB can be achieved.

9.8.3 Capacity

Capacity evaluation is determined using system simulations. A traditional macro‐cell system simulation scenario is used with NB‐IoT deployed within an LTE system. The cell layout is of a traditional 19‐site, 57‐cell system setup with wrap‐around. The inter‐site distance between cells is 1732 m, which represents a suburban macro‐cell deployment scenario. LTE system bandwidth is 10 MHz and NB‐IoT occupies one LTE PRB. NB‐IoT transmit power is 35 dBm and thermal noise level of −174 dBm/Hz is assumed. The carrier frequency is 900 MHz.

The traffic model is based on MAR [16]. In this model, devices wake up periodically to transmit a report, then go back to sleep. The inter‐arrival time for the reports are as follows: 40% of the devices transmit a report once a day, 40% of the devices transmit a report once every two hours, 15% of the devices transmit a report once every hour and remaining 5% of the devices transmit a report once every thirty minutes. The size of each report is random and follows a Pareto distribution with a minimum packet size of 20 bytes and a maximum packet size of 200 bytes. The mean packet size is 32.6 bytes. In addition, to each packet a total protocol overhead of either 65 bytes (without IP header compression) or 29 bytes (with IP header compression) is added.

NB‐IoT objective is to support at least 52 547 devices within a cell‐site sector. System‐level simulation results show that at least 250 000 devices can be supported within a cell site sector per NB‐IoT carrier (in this case, one NB‐IoT carrier equals one LTE PRB). Additional capacity, if needed, can be acquired through using multiple carriers.

9.8.4 Extended Battery Life

Battery life analysis is based on MAR traffic model described previously and battery capacity of 5 Wh. The target is to achieve battery life of more than ten years at extreme coverage (164 dB maximum coupling loss). In the analysis four power states are used: transmit, receive, idle and power saving. The current consumptions corresponding to the four states are 543, 90, 2.4, and 0.015 mW, respectively.

Based on these assumptions, the estimated battery lifetime at maximum coverage level are 10.5 years to send a daily report of 200 bytes and 16.8 years to send a daily report of 50 bytes. This shows that the NB‐IoT 10‐year battery life target can be met or exceeded for daily reporting.

9.8.5 Rel‐14 NB‐IoT Enhancements

In Rel‐14, the following enhancements were introduced to NB‐IoT:

• Positioning based on Enhanced Cell‐ID (E‐CID) and OTDOA. Narrowband Positioning Reference Signal (NPRS) was defined allowing the UE to measure the time of arrival (ToA) of reference signals received from multiple transmission points and report the Reference Signal Time Difference (RSTD) to the location server. In addition, performance requirements were defined for E‐CID.
• Multicast support based on single‐cell point‐to‐multipoint (SC‐PTM) transmission.
• Support for higher data rates. A new UE category (Cat‐NB2) was introduced. This new UE category can achieve peak data rates of approximately 127 kbps in the downlink and 159 kbps in the uplink.
• Support of paging and random access on non‐anchor carriers. This increases paging and random access capacity and allows the network to perform load balancing for paging and random access among carriers.
• A new UE power class with a maximum output power of 14 dBm has been introduced with relevant RF requirements defined. This new power class is suitable for small form‐factor batteries supporting use cases such as wearables.

Release 15 enhancements for NB‐IoT are ongoing and enhancements are being considered to improve latency and battery life. Rel‐15 will also introduce TDD support for NB‐IoT and enhance the range and reliability of the random access channel.

9.9.1 Requirements

Although M2M support in 5G will be specified by 3GPP only in Rel‐16, some high‐level assumptions and key targets for the 5G radio to fulfil M2M/IoT device requirements are known today:

• 5G wide area coverage is a necessity for many applications.
• Local area support for low cost IoT devices is also envisioned.
• Use cases for local area, low cost IoT devices may include connected homes (light, heating, ventilation, etc.).
• Having 5G IoT devices supporting both local area and wide area networks requires a solution to enable multiband support in 5G IoT devices.
• Native support for low cost and low power IoT, both local area and wide area.
• Lower energy consumption compared to LTE‐M.
• Optimized architecture for massive IoT support.

Like for other radio technologies, M2M/IoT devices using 5G radio are supposed to support all or a subset of following features:

• Power savings and paging optimizations.
• Efficient infrequent and frequent small data transmission.
• Optimizing signalling and latency for idle to active mode transition.
• Support of Embedded SIM/Soft SIM and SIM‐less authentication.
• Automated subscription and provisioning.
• Group based features, e.g. group‐based messaging.
• Mobility and session on demand.

9.9.2 Challenges

The 5G New Radio (NR) as specified in Rel‐15 provides a unified, flexible radio interface capable of supporting various verticals such as automotive, healthcare, industry, smart city, utility, smart home, etc. The 5G radio interface can be tailored to meet requirements coming from different services, including enhanced Mobile Broadband (eMBB), massive Machine‐Type‐Communication (mMTC) and Ultra Reliable and Low Latency Communication (URLLC):

• Scalable orthogonal frequency‐division multiplexing (OFDM) numerology to support different bandwidth, subcarrier spacing, and frequency bands including mmWave.
• Flexible slot structure supporting low latency services and dynamic TDD.
• Massive multiple input multiple output (mMIMO) support to utilize large number of antennas for capacity and Coverage Enhancements (CE).
• Beamforming based operation for capacity and CEs.
• Advanced coding schemes for both control and data packets.

With respect to M2M, the 5G radio must support two use cases:

• mMTC with the following performance objectives: ultra‐low complexity and low‐cost IoT devices and networks, MCL of 164 dB for a data rate of 160 Bps at the application layer, connection density of one million devices per square km in an urban environment, battery life in extreme coverage beyond 10 years (15 years is desirable), and latency of 10 seconds or less on the uplink to deliver a 20‐byte application layer packet measured at 164 dB MCL.
• URLLC with the following performance objectives: user plane latency of 1 ms (0.5 ms for downlink and 0.5 ms for uplink), and packet transmission reliability of 10e−5 with a user plane latency of 1 ms (for a packet size of 32 bytes).

For mMTC, it has been agreed in 3GPP that no 5G radio solution will be specified for low‐power, wide‐area use cases. Instead, these use cases will continue to be addressed by evolving LTE‐M and NB‐IoT as those two radio technologies can satisfy the 5G requirements for mMTC. Note that peak data rates up to 27 Mbps in DL and 7 Mbps in UL are possible with LTE‐M. Further analysis of LTE‐M/NB‐IoT deployment within 5G carriers might be required to ensure optimal co‐existence between these technologies.

For URLLC, key radio techniques have been specified for 5G in Rel‐15 including short slot length, mini‐slot allocation, data pre‐emption, advanced coding, massive MIMO and beamforming. Further 5G radio enhancements are being studied including grant‐free transmission, compact scheduling grant, control channel repetition and defining new modulation and coding table.

In addition, 3GPP is studying M2M use cases that fall in between mMTC and URLLC. Examples include CCTV cameras, mass transit train control and building automation. These use cases require higher data rates, e.g. peak data rates of 100 Mbps, than can be delivered by mMTC, but do not require URLLC level of latency and reliability. A low‐complexity 5G UE category may be defined to support these use cases.

9.9.3 Architecture Enablers

9.10.1 Goals of MTC and IoT Optimizations

Main drivers for the architectural design to support MTC and IoT use cases were the following:

• UE simplicity and power saving capability;
• Registration without PDN connection (and possible connectivity on demand);
• Infrequent and frequent small data support.

Efficient use of radio frequencies and MTC optimized radios is by no means less important than these architectural requirements, but it is covered in other sections of the book. In the following sections we will compare EPS (see [14]) and 5GS (see [33], [34]) concepts to cope with the above‐mentioned goals and drivers.

9.10.2 UE Simplicity and Power Saving

CIoT EPS Optimizations aim at UE complexity reduction via omitting capabilities that are not required for MTC use cases. One major advantage is removal of CS domain support. With 5G, a UE gains the same advantage, as native interworking between 4G and 5G is specified, and the 5G system does not contain a CS part. Thus, CIoT and 5G UE need not support combined attach/registration to use SMS service.

The UE needs to communicate with the network due to periodic updates and the need to monitor possible paging causes heavy impact on the UE power budget.

The protocol details for Periodic Registration Update have not been specified at the time of writing this book. If the extended timer values in GPRS are also used for the extended 5G timer values, it would bring 5G on par in terms of periodic updates that can be set to maximum value of 31 times 320 hours, which is more than one year's update period. Such values should be long enough for any application.

The longest possible eDRX period in EPS is determined by the radio hyperframe structure, which means the maximum eDRX cycle depends on the layer 1 frame structure of each radio technology. The longest possible eDRX cycle in NB‐IoT (close to three hours) and in WB‐E‐UTRAN (almost 44 minutes) are far longer than the maximum DRX cycle of 5G. Extended Idle mode DRX and HLcom are not supported for 5G in Rel‐15.

The EPS concept of UE PSM was not copied over to 5G as it stands, but MICO mode serves the same purpose. Considering the very long periodic update timers, both MICO and PSM allow the UE to switch off the modem until the next uplink data transfer or the next periodic update. MICO allows to assign an ‘All PLMN’ Registration Area to the UE, reducing the number of Registration Updates from UE side.

In terms of simplicity, supported procedures, and power saving features, a 5G UE with uplink only application is comparable with CIoT EPS Optimizations. If the UE needs to be paged, then the 5G UE suffers from lack of extended idle mode DRX feature support in 5G.

9.10.3 Connectionless Registration

Attach without PDN connectivity is supported for SMS‐only CIoT UEs. With 5G, the registration procedure in AMF is independent from session management function (SMF) controlled PDU session establishment. Connectionless registration is supported natively from the first release of 5G onwards.

Connectivity on demand is supported for UEs initially attached/registered to the network without PDN connection. The UE may remain registered without PDU/PDN connections, but it may request for PDN connection establishment or PDU session establishment later, if this is required by the application.

Connectionless network attachment is supported in 5G with less restrictions than in CIoT EPS Optimizations.

9.10.4 Small and Infrequent Data

For frequent and infrequent data with bursty nature, CIoT offers the User Plane CIoT EPS Optimizations with the capability to suspend the RRC connection to resume it later with an expedited signalling procedure. Introduction of RRC Inactive state offers the same option for a 5G UE. Thus, efficiency of the user plane communication depends mainly on the implementation of radio layers.

CIoT supports also control plane user data using the Control Plane CIoT EPS Optimizations. Control plane data was left out of 5G in 3GPP Rel‐15, but it is one of the Rel‐16 topics to be studied. Even without dedicated method for control plane data, 5G can compete with Control Plane CIoT EPS Optimizations offering very low latency and minimal overhead with RRC Inactive state applicable to one‐shot messages.

9.11.1 General Rel‐16 IoT Aspects

The first 5G Rel‐15 specification version follows the 3GPP tradition of establishing the first full 5G release which builds the baseline for further work and enhancements in future releases. At the time of writing this book, several Rel‐16 studies are ongoing. One of the agreed study items is ‘Study on Cellular IoT support and evolution for the 5G system’. This work considers alignment with the CIoT EPS Optimizations, but it is not restricted to the already specified EPS procedures, even though the goals are mostly common.

The Rel‐16 aims for CIoT and 5G evolution in the MTC area and will focus on the following main topics:

• Enable CIoT/MTC functionalities in 5G CN;
• Co‐existence and migration from EPS based eMTC/NB‐IoT to 5G CN;
• Enhancements to address 5G service requirements.

TR 23.724 [10] documents the goals of the study and candidate solutions. The following key issues were already identified. The study will consider possible solutions for these topics:

1. Support of frequent and infrequent small data transmission;
2. High Latency communication;
3. Power Saving functions;
4. UE TX power saving functions;
5. Management of EC;
6. Overload control for small data;
7. Support of Reliable Data Service;
8. Support of common North‐bound APIs for EPC‐5GC interworking;
9. Network parameter configuration API provided by network exposure function (NEF);
10. Monitoring support;
11. Inter‐RAT mobility support to and from NB‐IoT;
12. Support for expected UE behaviour;
13. Quality of Service (QoS) support for NB‐IoT,
14. CN selection for Cellular IoT.

As can be seen in the above list, the 5G CIoT study has a wider scope than CIoT EPS Optimizations. In addition to the Rel‐13 CIoT work scope, 5G CIoT comprises also the Rel‐14 CIoT enhancements, the Rel‐15 Northbound API for SCEF and network and UE parameter provisioning and monitoring capabilities. Even though the goals are mostly common, the 5GC architecture shown in Chapter 4 requires some re‐design. It is expected that the agreed candidate solutions will be specified as part of 3GPP Rel‐16, but the final conclusions on the candidate solutions that will move forward have not been made at the time of writing this book.

9.11.2 Small Data

Both infrequent and frequent small data will be supported in 5G, but the architectural differences between 5GC and EPC do not guarantee that all CIoT EPS Optimizations can be re‐used without change in 5GC. The main differences possibly requiring a re‐design are the functional split between AMF and SMF and the control plane – user plane split between SMF and user plane function (UPF) in 5GC. Both could make the transfer of user data over the control plane more complicated in 5G.

The candidate solutions for small data include enhanced versions of both control plane and user plane solutions. Among control plane solutions, the main candidate solutions include routing of mobile originating (MO) small data on the path

• UE‐RAN‐AMF‐SMF‐UPF‐DN or
• UE‐RAN‐AMF‐UPF‐DN or
• UE‐RAN‐AMF‐NEF‐DN.

The user plane solutions can lead to possible optimizations in suspend and resume procedures. The new candidate solutions for user plane small data include Connectionless and Fast Path solutions, allowing transfer of single packets even without establishment of an RRC connection. This requires the existence of a pre‐configured path between RAN and UPF. RAN may either maintain the UE state to know where to route packets, but can also be stateless and retrieve path information from the control plane node when needed. In this case, UPF needs the UE related security parameters for ciphering and integrity protection.

9.11.3 UE Power Saving and High Latency Communication

The initial version of the 5G radio does not support extended idle mode DRX, but various interworking scenarios also allow wide‐band LTE and NB‐IoT to interwork with the 5G Core over N2 and N3 interfaces, which enables eDRX at least in LTE RAT. UE PSM is not copied to 5GC as such, but MICO mode also requires the network to either drop DL packets targeted for a UE during its sleep cycle, or to buffer them. This requires the addition of High Latency Communication to 5GC. When this is specified in 3GPP, it needs to be determined which node (NEF, UPF, SMF) buffers DL packets during the UE sleep cycle.

Also, MICO mode enhancements are considered in 3GPP, i.e. the addition of an Active Timer to keep the UE pageable for a known period after moving to idle state and a timer to keep the UE connected until the pending DL data can be delivered.

9.11.4 Management of Enhanced Coverage

Management of EC copies the EPC principles where the UE may request for EC, which the serving CN may grant after checking subscription information.

An additional aspect for EPS‐5GC interworking and mobility is the capability of MME and AMF to exchange the EC restriction information as part of the UE context transfer during inter‐system mobility.

9.11.5 Overload Control for Small Data

User plane overload controls are mostly already in place, but if user data transfer on control plane is supported, then it also requires additional CP‐related overload control mechanisms.

Small Data Rate control corresponds to the APN Rate Control in CIoT EPS Optimizations. This is the operator's tool to dimension CIoT subscription in terms of number of messages that are allowed in time unit (hour, day, week). The operator may delay or drop the packets that exceed the rate control quota, or may pass them on and possibly over‐charge.

Service Gap control was added in Rel‐15 EPS to discourage the CIoT UEs from excessive frequent detach and re‐attach cycles. A UE that detaches after every data packet generates very high signalling overhead, so typically it is more efficient to keep such a UE registered all the time between transmit intervals. CIoT optimizations provided in EPS and in 5GS ensure UE power budget optimizations by means of signalling efficiency.

AMF Overload control corresponds to the Serving PLMN Overload control, which protects the serving CN node (AMF or MME) against signalling overload that could be caused by excessive control plane small data signalling. It is expected that the AMF in the serving PLMN allows at least a reasonable Small Data Rate control quota to pass, without having to intercept small data that is within the subscribed Small Data Rate control quota.

Control Plane Back‐Off timer protects the serving CN nodes against overload caused by control plane small data signalling by means of allowing the AMF to assign a back‐off timer to some or all UEs, if it is running very high load. If the UE supports both user plane and control plane signalling, it can bypass the Control Plane Back‐Off by transfer data via user plane.

9.11.6 Reliable Data Service

Reliable Data Service (RDS) was initially introduced between UE and SCEF, but the capability to support RDS overlay protocol has been broadened to apply also between UE and P‐GW on the user plane.

To support the same service in 5GC, both NEF and UPF need to terminate the RDS protocol.

9.11.7 Northbound API

In the 5GC architecture, NEF takes the role of the network exposure function. An AS, whether it is modelled as an EPS SCS/AS or 5GC AF, should not need to worry about the UE camping on a 4G or 5G cell, thus the NEF needs to expose the Northound API like the SCEF in EPS. For privacy reasons, it is also important to hide the 3GPP identities of the user, so the 3GPP network edge should look the same from the outside irrespective of what lies southbound of the NEF or SCEF.

Using just a single exposure function towards the applications is ideal for application designers, but it fits the substantially different southbound architectures inside the 3GPP network very badly and forcing an update of all related EPC legacy interfaces is not an attractive option to build the interworking between EPC and 5GC.

The 3GPP architecture is a logical model that does not bind the mapping of the logical entities to physical deployments. Merging multiple logical nodes into a single box implementation is always a viable option. In this case the combined SCEF and NEF seems an attractive alternative that solves most of the interworking challenges. Such combined nodes must support the sum of SCEF and NEF interfaces. The SCS/AS or AF can use the common T8 API without the need to distinguish between SCEF and NEF, but inside the 3GPP system, a UE roaming in a 4G or 5G system is addressed via the procedures that are specified for each system. More importantly, AMF and SMF need not support T6 interface towards SCEF and the MME need not support the 5GC interfaces, but the combined SCEF and NEF node exposes both EPC and 5GC interfaces towards all affected (EPS and 5GS) nodes. However, the combined SCEF and NEF node exposes only one API interface towards the AS.

This admittedly leaves two main points open for the implementation. These are the interaction between SCEF and NEF roles inside the combined node and handling of the subscriber data. The user specific subscriber data are considered as a single set of data managed jointly by the HSS and unified data management (UDM)/unified data repository (UDR). The beauty of this design is that duplication of updates is avoided, as either HSS or UDM/UDR can update the same subscription data record, depending on whether the update was received from EPC or 5GC. For example, a UE monitoring request received from the application is inserted by HSS/UDM into the subscription data, and then updated to the affected MMEs and AMFs. Whichever detects a monitoring event will send the notification towards the exposure node they interface with (either SCEF or NEF).

The API offered to the AS is expected to be the same in all cases when a service is provided via EPC and 5GC. However, this does not mandate all EPC and 5GC services to be the same, e.g. if for some reason a service can be provided only in one system.

If small data is supported over user plane, then the user plane nodes must offer the API services corresponding to EPS NIDD. Candidate solutions allowing the SMF or UPF to play the role of the NEF are documented in TR 23.724 [10]

9.11.8 Network Parameter Configuration

The 3GPP network may open an interface for authorized third party applications to update certain parts of the user subscription based on predicted UE behaviour. A generic subscription data provisioning framework is specified for an external party to provision UE communication pattern parameters that are called Expected UE behaviour. These parameters give an educated guess on the UE's behaviour, such as:

• Expected UE moving trajectory. The foreseen or planned UE movement in terms of geo‐location;
• Stationary indication. Indicates whether the UE is static or mobile;
• Communication duration time. The time that the UE usually stays in CM‐CONNECTED state;
• Periodic Time. Time interval for periodic communication;
• Scheduled communication time. Weekday and time of the day when the UE is expected to be available for communication;
• Scheduled communication type. Downlink only, Uplink only, or bi‐directional communication.

If the AS can predict the above Expected UE behaviour accurately, then the 3GPP network can benefit from the provisioned values and provide a better service to the application by configuring the UE mobility parameters and UE power saving cycles accordingly.

9.11.9 Monitoring

The monitoring framework is already supported in Rel‐15 5GC, but UE mobility between EPS and 5GS is still an open topic. As already mentioned in section 9.11.7, ideally the external AS should not need to worry about whether the UE is camping on LTE or 5G, it only needs to request monitoring of a certain UE identified by an External Identifier or External Group Identifier. It is the network responsibility notifying the AS on the reachability of the UE irrespective of whether the UE becomes available for communication over LTE or 5G.

In EPS, the HSS updates the monitoring request in the MMEs that can notify on the UE availability for communication. In a multi‐system network environment this requires a monitoring request entered in the subscription data by HSS or UDM is forked to all affected MMEs, AMFs, and SMFs that can process the monitoring notification part. The common subscription data stored in UDR is key for a combined monitoring solution.

9.11.10 NB‐IoT Inter‐RAT Mobility

The goal is to provide UE mobility without having to re‐attach to the network at RAT change. This requires inter‐RAT TAU and Mobility Registration each way, however the various 5G deployment scenarios (see Chapter 1) are adding complexity to potential solutions. The main point is whether NB‐IoT radio network is connected to EPC over S1 or to 5GC over N2/N3.

Inter‐RAT mobility requires the maintenance of the UE Radio Capabilities for 5G and NB‐IoT, which implies handling of those capabilities on each RAT separately. This is the result of the large size of the multi‐RAT, multi‐band UE Radio Capability information data in relation with the limited data rate of NB‐IoT. Signalling over 3GPP protocols must be optimized to avoid excessive signalling overhead over narrow‐band radio.

An aspect related with the different capabilities supported in each system is the way how the active 5G PDU Sessions and 4G PDN Connections can follow in the UE's inter‐RAT mobility. The capabilities of the serving network elements are of course considered, but additionally a subscription‐based indication of which connections can be maintained during mobility may be introduced. The CN transfers only those PDN Connections or PDU Sessions that can be supported after mobility, considering the network capabilities, the subscription data and the network local policy.

9.11.11 QoS Support for NB‐IoT

The goal is to enable QoS differentiation between NB‐IoT UEs mainly for control plane small data.

As a possible solution the AMF can assign the subscribed QoS index received from the UDM during registration to the UE. The UE includes this QoS index in subsequent control plane data messages. This allows the RAN to evaluate the UE's priority compared to other UEs. The QoS Index can be policed by the AMF by comparing the QoS index value provided by the UE against the one from UDM. While this service is considered Quality of Service, the technical implementation has got similarities with overload control.