Packet Core for Cellular IoT Use Cases Support of Massive IoT Connections

IoT is the next revolution in the mobile ecosystem with an estimated 75 billion connected IoT devices projected to be deployed by 2025. Cellular IoT including 2G, 3G and 4G technologies which can be used for IoT but not specifically optimized for IoT and LPWA modules are forecast to account for a significant percentage of those devices. Given such sanguine forecasts, IoT services are likely to be a key driver for future growth in cellular infrastructure.

Packet Core for Cellular IoT Use Cases Support of Massive IoT Connections
Packet Core for Cellular IoT Use Cases Support of Massive IoT Connections

The Aricent NB-IoT core is based on the evolved packet system (EPS) and provides cellular IoT (C-IoT) by performing control plane and user-plane optimizations. The Aricent NB-IoT solution fulfills all the key requirements of tomorrow’s low-power, wide-area networks, including long battery life, low-cost devices, low deployment costs and support of massive IoT connections. The Aricent NB-IoT core is based on the evolved packet system and provides cellular IoT by performing control-plane and user-plane optimizations.

Content Summary

Introduction
The Aricent NB-IoT Solution
IoT Core Architectures
The Aricent C-SGN Solution
Control Plane C-IoT Optimization
User Plane C-IoT optimization
Summary

Introduction

In recent years, low-power wide-area (LPWA) technologies have received a lot of attention and gained popularity in large part because of their potential to connect billions of Internet-of-Things (IoT) devices and attain machine-type communication (MTC) by using wireless communications networks more cost-effectively.

The advantage of LPWA technologies over other options is that they can be deployed in both licensed and unlicensed spectrum. Within the unlicensed spectrum, proprietary technologies such as SigFox and LoRa provide non-cellular IoT whereas in licensed spectrum 3GPP has standardized technologies like LTE-M—also known as enhanced machine-type communication (eMTC)—and narrow-band IoT (NB-IoT) that have evolved over existing LTE frameworks to provide cellular IoT. In addition, 3GPP has standardized extended-coverage GSM for IoT (EC-GSM-IoT), which has evolved to provide cellular IoT using the GSM 2G framework.

IoT is the next revolution in the mobile ecosystem with an estimated 75 billion connected IoT devices projected to be deployed by 2025. Cellular IoT—including 2G, 3G and 4G technologies which can be used for IoT but not specifically optimized for IoT—and LPWA modules are forecast to account for a significant percentage of those devices. Given such sanguine forecasts, IoT services are likely to be a key driver for future growth in cellular infrastructure.

Indeed, cellular IoT is expected to provide services for large IoT networks in applications ranging from smart meters and vending machines to autonomous vehicles, medical alert systems and wearables. Already, devices such as baby monitors, e-book readers, GPS navigation aids, parking meters and digital cameras are connected to the internet.

The Aricent NB-IoT Solution

Aricent implements cellular IoT with our NB-IoT offering to provide wide-area coverage, long battery life, low-cost devices, low deployment costs and support of massive IoT connections. NB-IoT fulfills all the key requirements of the LPWA network, enabling communications service operators (CSPs) to manage smart-metering, smart-building and a variety of other applications. The Aricent NB-IoT core is based on the evolved packet system (EPS) and provides cellular IoT (C-IoT) by performing controlplane and user-plane optimizations.

NB-IoT is the most recent technology introduced by 3GPP to address the requirements of C-IoT devices. It is an improvement over LTE-M because it can attain an extended area of coverage with lower data rates by operating in the 200 kHz band, which enhances battery life even further through lower power consumption.

Some of the specific advantages NB-IoT offers include:

Extended battery life
NB-IoT provides longer battery life by allowing a device to remain in idle mode for a longer period of time. Extended battery life is achieved using the power saving mode (PSM) and extended discontinuous reception (eDRX).

3GPP introduced PSM in Release 12. Devices that support PSM can request the network for an extended timer value (T3412 extended value), which is used to send periodic tracking area update (TAU) requests towards the network. On entering PSM, the device stops listening to the paging channel. Therefore, during this period the network does not send any data in the downlink (DL) direction as there are no mobile terminated calls in this mode. On expiration of the timer, the device wakes up from its deep sleep and initiates a TAU request towards the network. To move into connected mode, the device initiates a mobile-originated call by sending a periodic TAU request or any other uplink message, such as a service request or uplink data.

In release 13, 3GPP introduced eDRX that allows a device to sleep for an extended period of time before listening to the paging channel. The eDRX allows a device to sleep for as long as three hours, which is a significant improvement over the sleep duration provided by the existing DRX value.

Extended network coverage
NB-IoT provides an improvement of over 20 dB in the link budget, which results in extended geographical coverage. This is achieved because NB-IoT supports only low data rates, works in the 200 kHz band and provides a link budget of approximately 169 dB.

Low device cost
There are four reasons why NB-IoT enables device manufacturers to produce low-cost devices:

  • It requires only half FDD mode
  • It does not require multi-input multi-output (MIMO)
  • It supports only low data rates
  • It requires bandwidth of only 200 kHz

Combined, these factors result in a significant reduction in both the complexity and cost of the device.

Low deployment cost
NB-IoT has evolved beyond the existing LTE network architecture and uses existing deployed hardware and the spectrum in an optimal way as it requires only 200 kHz. NB-IoT has three deployment modes, all of which result in lower deployment costs

  • In-Band Mode: This mode makes use of the single resource block (RB) in the existing LTE network.
  • Guard-Band Mode: In this mode, the NB-IoT solution is deployed in the bandwidth that has been reserved for guarding between two consecutive bands in the legacy LTE network.
  • Standalone Mode: In this mode, one or more GSM carriers are reserved to deploy the NB-IoT solution. Unlike the in-band and guard-band modes, the standalone mode does not coexist with legacy LTE network.

IoT Core Architectures

The 3GPP has modified the network architecture for smallpacket services, such as meter reading and environmental monitoring using sensors. The standard EPC could be used for these services; however, the nature of the data traffic means the classic core network dimensioning is not well suited for these services.

3GPP has proposed two different architectures for transporting small data packets over the NAS control plane. The first one is the S11-U, which uses the interface from the MME to the packet gateway for delivery via the SGi. The second is the T6a option with the interface from the MME.

Case 1: S11-U Interface
In this option, the device connects to the MME over an S1 interface. The MME is modified to support the payload traffic and is upgraded with a new S11-U interface that can send payload traffic to the serving gateway. (See Figure 1.)

This is a relatively straightforward extension to the existing EPC core network. Here, the S1 interface is modified in MME to handle the UE traffic, which is then forwarded to the S11-U interface towards the SGW. There are no changes in the rest of the nodes.

Figure 1: The S11-U option
Figure 1: The S11-U option

Case 2: T6a with C-SGN
Here, a new dedicated core network node called the cellular IoT service gateway node (C-SGN) is introduced into the network. The C-SGN has an S1 interface towards the eNB and instead of an S11-U interface, it has a T6a interface towards the service capability exposure function (SCEF). No user-plane bearer is set up and only the NAS interface is used to transport the payload. (See Figure 2.)

The C-SGN receives the payload in the NAS interface and forwards it to the SCEF on the T6a interface and then onward to the service platform. This solution is cloud-friendly as the SCEF connects to the service platform over a REST API.

Both architectures can be used for deploying NB-IoT devices. Based on the requirements, the network operator will choose the best architecture for the network.

Figure 2: C-IoT architecture for small data transmission via SCEF
Figure 2: C-IoT architecture for small data transmission via SCEF

The Aricent C-SGN Solution

The Aricent IoT C-SGN is a combined-node EPC implementation option that minimizes the number of physical entities by collocating EPS entities in the control plane and user-plane paths. C-SGN combines the MME, PGW and SGW functions to provide a highly optimized C-IoT solution. The Aricent C-SGN runs on virtualized environments to support C-IoT traffic. The C-IoT EPS optimizations in this release provide improved support for small-data transfer. (See Figure 3.)

Aricent C-SGN supports C-IoT optimizations, which provide improved support for small-data transfer. It supports both control-plane C-IoT EPS optimization as well as user-plane C-IoT EPS optimization.

Figure 3: C-IoT Network Architecture with Aricent C-SGN
Figure 3: C-IoT Network Architecture with Aricent C-SGN

Control Plane C-IoT Optimization

The Aricent C-SGN solution supports control-plane C-IoT. In this method, the user data is encapsulated in the control plane signaling messages in the form of a non-access stratum protocol data unit (NAS-PDU). C-SGN provides support for both IP and non-IP type data (small packet size) transmission in both the uplink and downlink direction.

IP type data over SGi.
In the uplink, C-SGN receives an encapsulated user data container in an ESM data transport message. C-SGN then decodes the uplink NAS packet and extracts the user data container. The user data is sent towards the PGW node which further relays it over the SGi interface towards the C-IoT application server. (See Figure 3.)

In the downlink, PGW receives user data over the SGi interface and relays it towards C-SGN. C-SGN then encapsulates the received user data in an ESM data transport message and sends it towards the device, but only if the device is in connected mode; otherwise, C-SGN buffers the received data. Upon the reception of a mobile-originated message, the buffered data is encapsulated in an ESM data transport message and sent towards the device

Non-IP type data over SGi.
In uplink, the C-SGN receives an encapsulated user data container in an ESM data transport message. C-SGN then decodes the uplink NAS packet to extract the user data container and forms an IP header using its local IP and configuration provided by the user. It also forms and applies a UDP header and then appends user data to this IP and UDP header. This IP packet is sent towards the PGW node, which further relays it over the SGi interface towards the C-IoT application server. (See Figure 3.)

In downlink, PGW receives user data over the SGi interface and relays it towards C-SGN. C-SGN removes the IP and UDP header from the packet received from the PGW, encapsulates the user data in ESM data transport message and sends it towards the device, but only if the device is in connected mode; otherwise, it buffers the received data without the IP and UDP header. Upon the reception of a mobile-originated message, the buffered data is encapsulated in an ESM data transport message and sent towards the device

Non-IP type data over SCEF.
In uplink, C-SGN receives an encapsulated user data container in an ESM data transport message. C-SGN then decodes the uplink NAS packet to extract the user data container. If the data delivery mechanism for this device is set as SCEF, based on the subscriber configuration, then C-SGN sends the user-data container towards the SCEF node over the T6a interface, which then relays it to the C-IoT application server. (See Figure 3.)

In downlink, SCEF receives user data from the C-IoT application server and relays it towards C-SGN. C-SGN encapsulates the user data in an ESM data transport message and sends it towards the device, but only if the device is in connected mode; otherwise, it buffers the received data. Upon the reception of a mobile-originated message, the buffered data is encapsulated in an ESM data transport message and send towards the device.

eDRX and PSM support.
Aricent C-SGN supports the extended discontinuous reception (eDRX) feature which allows an IoT device to remain inactive for a longer period. The device can remain in sleep mode for minutes, hours or even days, thus extending its battery life. Upon receiving eDRX from the UE in an attach request, Aricent C-SGN sends it back to the UE by sending an attach accept, thus enabling the device to use the eDRX capability.

C-SGN supports PSM by handling the two timer values in the attach or TAU request. One of the timer values is T3324, which defines the time the UE stays in active mode after the idle mode following the attach or TAU procedure. The other timer value is extended T3412, which allows the UE to extend the time before sending the periodic TAU. These two timers are supported by Aricent C-SGN for C-IoT services.

User Plane C-IoT optimization

In user plane C-IoT optimization, the user data is transferred over the user plane. The data is forwarded over the conventional user plane through the network.

Both IP and non-IP data in the uplink direction is transmitted from eNodeB to SGW over an S1-U interface, which forwards the data to PGW over an S5 interface, PGW further relays data to the C-IoT application server. In the downlink, PGW receives data from the C-IoT application server and sends it towards SGW, which transmits it towards eNodeB over an S1-U interface.

Aricent C-SGN can support both control-plane optimizations and user-plane optimizations. Control plane optimizations are usually used for NB-IoT devices where the data packets are small and can be sent in the NAS PDU itself. For bigger packet sizes, user plane optimization is used.

Aricent C-SGN supports high-latency communication (HLCOM) by buffering the downlink packets of the UE in idle mode. Here, whenever the IoT device goes in the idle state—and if there is a DL packet sent for it—then instead of paging the UE, C-SGN buffers the packets and does not page the UE. This means there are fewer signaling messages while the UE is in idle mode. Whenever the UE comes into a connected state, all the buffered packets are transferred to the UE. HLCOM limits packet storing to 50 packets per UE, after which the packets are discarded.

Summary

The IoT era is upon us and promises to expand rapidly in the coming years. The competitive advantage for implementing and managing massive IoT networks will go to the network operators and communications service providers that can provide the most robust applications and seamless support.

The Aricent NB-IoT solution fulfills all the key requirements of tomorrow’s low-power, wide-area networks, including long battery life, low-cost devices, low deployment costs and support of massive IoT connections. The Aricent NB-IoT core is based on the evolved packet system and provides cellular IoT by performing control-plane and user-plane optimizations. With over 25 years of experience providing engineering and technology solutions for network operators, Aricent is well positioned to lead into the IoT era.

Source: Altran