Critical Machine Type Communication in 5G networks

Abstract

Machine-type multicast service (MtMS) is a good candidate to support mission-critical applications with a large number of low-cost devices. It allows a flexible customer-driven group formation and benefits from single cell point-to-multipoint (SC-PTM) capabilities. We analyze the performance of two approaches for delivering critical updates to a massive number of constrained devices. The first one is designed to multicast data to all devices in a cell requiring the update. Another approach allows initiation of multiple multicast sessions to small subgroups of devices for downloading the critical file. To inform devices in power saving mode about upcoming data in downlink, the base station has to send a paging message. We simulate the 3GPP legacy paging mechanism and its improved version, named enhanced group paging (eGP), designed to eficiently page a huge number of IoT/MTC devices. The conventional approach to serve all devices by one multicast session can be applied for delivering delay tolerant applications and when synchronized devices actions are needed. More strict delay requirements of critical applications can be fulfilled by a subgroup-based multicasting scheme.

Keywords

• and phrases
• group-oriented services
• massive MTC
• IoT
• machine-type multicast service
• critical data delivery
• paging
• random access

1. Introduction

The era of 5G mobile communication shall bring the support to the large variety of emerging use cases and fulfil the ever increasing demands of mobile broadband trafic.

After years of research activity on business requirements and technology evolution to the 5G systems, it has been agreed to categorize services into three broad service classes 1. Thus, according to the ITU-R nomenclature [ 1 ], 5G wireless systems will support: – enhanced Mobile Broadband (eMBB) supports the traditional human-centric broadband trafic with peak data rates of 20 Gbps and moderate rates for the cell-edge users. Expected capacity shall be 10000 times more as compared to LTE. The throughput up to 100 Mbps should be supported in densely populated areas and under high mobility. In particular – massive Machine Type Communication (mMTC) is characterized by a very large number of connected devices. The trafic of mMTC class is usually delay tolerant and has sporadic nature since devices transmit a relatively low data payload after a scheduled inactivity period. Depending on the application and use case, multiple combinations of service requirements and 3GPP device categories are possible. Battery life of low-cost and low-complexity devices is expected to be above 10 years. – Ultra Reliable Low Latency Communication (URLLC) supports a sporadic and extremely low-latency trafic from a limited set of terminals generating small payloads and requiring a very high reliability (99,999%).

"For ever ything" 10 years of batter y 106 devices / km2

Enhanced

Mobile Br oadband 5G "Ultim ate exper ience" 20 Gbps peak data rates 100 Mbps whenever needed "Instant action" < 1 ms radio latency 1 - 10-n reliability

Massive Machine Type Com munication

Ultr a r eliable

Low latency

Com munication

The 3GPP study in [ 2 ] identifies the use case families, trafic scenarios and potential requirements for mMTC. However, the problem of delivering data from the network to a large number of constrained devices is not addressed.

mMTC/mIoT could benefit from group-based, instead of unicast, services. In [ 3 ] a group-oriented Machine Type Multicast services (MtMS) architecture was introduced and the sporadic nature of MTC trafic with low payload was analyzed. A disruptive novelty of group-oriented MTC is that the owner of the devices (i.e., a customer paying for cellular connectivity of all their equipment/appliances) can decide which device or group of devices to involve in the communication. Group-oriented use cases are particularly relevant to the new vertical services, such as smart home/city, smart utilities, e-Health and smart wearables.

The 3GPP study in [ 4 ] discusses the following classes of use cases where a high number of MTC devices are interested in the receiving the same data: 1. Periodic and planned data delivery Sensors usually installed in deep indoor, for example, water or light metering devices wake up periodically to send a duty report to be transmitted in the uplink direction with a payload in the range of 10 to 100 bytes. However, the system configuration could change due to the increasing amount of communicated data or to the addition of new devices. Thus, some configuration updates should be shared among all devices in an efective way. The IoT devices manufacturer also provides non-critical software updates to fix bugs, improve the hardware performance or add new functionality. The frequency of planned updates could vary from weeks to years, e.g. 180 days is an estimated inter-arrival time for low-cost devices with 15 years of battery life [ 5 ]. 2. Initially unplanned data delivery As in the previous use case, devices wake up periodically to upload data. The wake-up period could be synchronized within a group of devices or set-up individually Alternatively, devices could wake up dynamically when the size of stored data exceeds the bufer threshold. If any software or firmware updates are available, the network will distribute files only to the group of active devices.

3. Initially unplanned data delivery for critical data The use case represents

the unplanned critical data delivery to a large number of devices. A software bug, vulnerability or emergency may require a critical data distribution to all devices within the coverage or to the dedicated group of devices. Unlike the previous case, devices should be informed about the upcoming data delivery session as soon as possible.

Group-based applications require a feedback report to inform the manufacturer or device owner about the data delivery success or failure. The system should support eficient mechanisms to page a huge number of IoT/MTC devices in order to inform them about the newly scheduled download session. A vast majority of IoT/MTC devices have limited capabilities of processing, battery life and storage. Some use cases require software or firmware updates to be completed within a short time applied either to all devices in a group or to none of them.

We design and investigate two approaches to deliver critical data file in a mMTC/IoT environment utilizing the MtMS architecture and addressing the discussed use cases requirements. The paper is organized as follows. We briefly overview the relates works on the topic and challenges of mMTC in section II. The system design and scenarios of device update are introduced in section III. We discuss simulation results in section IV and summarize them in the last section.

2.

Related Works

Authors in [ 6 ] note that diversity of existing and emerging MTC/IoT services may impose any combination of bandwidth and delay requirements. Design and benefits of a customer-driven group creation were discussed in [ 7 ]. However, there is no general low computation and low complexity algorithm for an optimal paging and data delivery group formation. Analysis of a legacy LTE-A core network connectivity model in [ 8 ] reveals its limitation to serve massive MTC with diferent classes of requirements.

Point-to-multipoint transmission typically becomes more eficient than point-to-point when there are more than five users per cell, as it supports feedback which can improve the radio link eficiency. At higher user densities, the point-to-multipoint transmission decreases the total amount of data transmitted in the downlink, and it may also reduce the control overhead in the uplink [ 9 ].

Speaking about the common benefits of multicasting such as improved system capacity and spectral eficiency, we note some challenges related to group-oriented mMTC/IoT applications. Low computation capacity of devices, limited battery life cycle and cell over-densification will always require the trade-of between service requirements and system capabilities. Improving end-to-end delay for group-oriented MTC services, one will face the shortage of random access resources and its fast overload considering simultaneous massive device access, overhead in a control plane [ 10 ].

In the MtMS architecture, a multicast MTC trafic is ofloaded to small-cells with eNB as an access point for MTC devices. Separating machine-oriented and human-oriented trafic the reliability and latency of MTC can be significantly improved.

3.

System model description

We consider a large number of IoT/MTC devices that are members of a target group located within the coverage of an evolved NodeB (eNB). Sensors or actuators, smart objects or smart devices represent the class of constrained small devices with limited CPU, memory, and power resources. Based on the device classification in [ 11 ], we assume that devices of categories 1 and 2 are involved in communication that is constrained in processing and power capabilities but supports a full protocol stack or a specifically designed Constrained Application Protocol (CoAP) over UDP.

The mechanism that allows IoT/MTC devices to save the battery during inactivity periods is called discontinuous reception (DRX). If no data arrives in UL or DL within a certain time interval, the device switches of its radio interface and enters the power saving mode. During the busy DRX cycle, the device is unreachable but it wakes up periodically to listen to the control data information over the physical downlink control channel (PDCCH).

Network defines the duration of the DRX cycle and broadcasts it to all devices. The cycle is usually configured following the desired frequency of paging. Thus, devices wake up to monitor the downlink at the specified paging occasions and come back to the idle mode. If PDCCH indicates the transmission of a paging message, the device will demodulate it and check whether it has to wake up. 3GPP introduces the enhanced DRX cycle (eDRX) for constrained devices. With longer eDRX cycle IoT/MTC devices could stay in power saving mode up to 10.24 seconds [ 12 ].

To inform devices in idle mode about upcoming critical data in the downlink, the eNB will wake up them through the paging procedure. We may assume that, at the beginning of paging, all devices are in idle mode. The legacy 3GPP paging (SP) allows to page only 16 devices in a paging occasion. To improve the performance of the paging procedure, group paging (GP) and enhanced (eGP) were introduced in [ 13 ] and [ 14 ], respectively. Both approaches are based on assigning to a set of devices a group identifier (GID) carried in a paging message. Diferent from GP, eGP allows splitting devices into paging subgroups in order to experiment a lower collision rate during the random access stage.

The members of the group interested in receiving the same critical file (bug fix or specific configuration in case of emergency) are subscribed for MtMS. For the sake of system robustness, any feedback of successful or failed data delivery should be provided. Sending reports from numerous nodes to the eNB could negatively afect device battery life or throughput in case of the low system bandwidth. Thus, we assume that critical data communication should be completed within a short period. If any device is still not ready or waiting for the data delivery session after the end of the specified period, it is considered failed or unreachable.

To reduce battery consumption, the software update for low-end IoT/MTC devices might be carried in diferent MtMS sessions.

We consider two diferent approaches to deliver critical data: with a single MtMS session, referred to as M1 scenario, and with multiple MtMS sessions, referred to as an M2 scenario.

According to the first scenario, all devices that entered RRC_connected state are members of the same MtMS session. Only when the last device joins the data delivery group the session will be initiated. The time a device could keep RRC connection, i.e. being synchronized in UL and DL with eNB, is limited and defined by a timer. When the timer expires, RRC connection is released and a device can get back network synchronization again through the random access procedure. To reduce the control overhead generated by devices that lost synchronization, inactivity timer extension might be a promising solution. However, the impact on device energy consumption should be investigated.

The M2 scenario is aimed to improve the device energy consumption during the software/firmware updates. Any set of RRC_connected devices might be grouped into a subgroup to receive the same MtMS session. Data delivery subgroups could be formed dynamically, e.g. each 1 ms, 10 ms etc., or be of a fixed size. We consider initiating a MtMS session for critical file delivery each frame when at least one device switches to RRC_connected mode. Thus the number of devices in data delivery subgroups could be diferent.

4.

Simulation Results

We model the discussed scenarios for critical data delivery in our MATLAB simulator calibrated according to the 3GPP recommendations [ 15 ]. The system bandwidth of 1,4 Mhz is configured to support constrained low-cost class of devices. The time window for critical data delivery to mIoT/MTC devices is limited to 1 s. With symmetric radio frame configuration and 2 random access slots within a frame, we obtain 24 and 12 available resource blocks (RBs) in DL and UL channels respectively, while random access capacity is estimated as 10800 random access opportunities (RAOs) utilizing 54 preambles available for contention-based radio access scheme. Primary simulation parameters are summarized in Table 1. Radio channel and system level parameters are set-up according to [ 16 ] and [ 17 ].

At the beginning of the simulation, a critical file is available, no RRC connection is established, and all devices in the cell are configured and subscribed for MtMS. The eNB waits for the paging opportunity to send the first paging message. We investigate the performance of M1 and M2 with diferent paging mechanisms. In [ 3 ] authors compared the performance of legacy 3GPP paging mechanism (SP), group paging (GP) and its modification, named enhanced group paging (eGP) when the paging message arrives every 30 ms to address a paging subgroup of 36 devices. We implemented both SP and eGP in our study but we do not consider group paging since it shown the worst performance in our set-up.

First, we investigate the access success probability and data success probability to understand whether M1 and M2 suit critical communications. The portion of devices that successfully established RRC connection is shown on fig. 2. Not less than 95% of IoT/MTC devices successfully complete random access procedure within the allowed number of preamble retransmission and all of those devices receive critical data.

Access delay is the time that the devices need to complete the random access procedure. Access delay shows similar performance in M1 and M2 scenarios. To understand this behaviour we note that PDSCH resource allocation to random access procedure messages (RAR) is in priority to the data flow. Thus, the next metric of our interest is the total average delay that comprises access delay, join delay (i.e., the time that a device waits for MtMS session initiation in RRC_connected mode) and multicast session delay. From Fig. 3 and Fig. 4 the drawback of a single MtMS session is clear. High access delay of a single device in a data delivery group leads to the significant latency degradation. The same behaviour can be observed in the average device energy consumption analysis. In fact, keeping devices in RRC_connected state until the last device of a data delivery group completes the random access procedure results in additional energy consumption, Fig. 5. In scenario M2, devices don’t need to wait for the MtMS session.

Simulation parameters

Group-oriented services are an essential part of the 5G portfolio. The MtMS architecture enables flexible and scalable clustering of IoT/MTC to improve data delivery. We analyze the performance of diferent scenarios for critical file distribution. Access delay could be significantly improved if devices are paged in small paging subgroups with increased interval between paging messages. Since the payload generated by mMTC devices is usually small, we show that initiating multiple multicast sessions to small data delivery subgroups of devices leads to better latency and energy consumption and could be exploited in critical applications.

Acknowledgments

The publication was prepared with the support of the “RUDN University Program 5-100” and funded by RFBR according to the research project No. 19-07-00933.

References

1. ITU-R , “ ITU-R M. Minimum Requirements Related to Technical Performance for IMT2020 Radio Interface(s),” Report ITU-R M. 2410-0 , Nov. 2017 .

2. 3GPP 22.861 v14.1.0 Feasibility Study on New Services and Markets Technology Enablers for Massive Internet of Things. Stage 1 . 2016 .

3. M. Condoluci , G. Araniti, T. Mahmoodi , and M. Dohler , “ Enabling the IoT Machine Age With 5G: Machine-Type Multicast Services for Innovative Real-Time Applications ,” IEEE Access, vol. 4 , pp. 5555 - 5569 , 2016 .

4. 3GPP 26.850 V15.1 .2 Technical Specification Group Services and System Aspects MBMS for IoT . 2018 .

5. 3GPP 45.820 V13 . 1.0 Cellular system support for ultra-low complexity and low throughput Internet of Things (CIoT ). 2015 .

6. A. Al-Fuqaha , M. Guizani , M. Mohammadi , M. Aledhari , M. Ayyash . Internet of Things: A Survey on Enabling Technologies, Protocols, and Applications. IEEE Communication Surveys & Tutorials, v. 17 , pp. 2347 - 2376 , 2015 .

7. G. Araniti , M. Condoluci , P. Scopelliti , A. Molinaro , and A. Iera , “ Multicasting over Emerging 5G Networks: Challenges and Perspectives,” IEEE Network , vol. 31 , no. 2 , pp. 80 - 89 , Mar. 2017 .

8. R. Trivisonno , M. Condoluci , X. An , and T. Mahmoodi, “ mIoT Slice for 5G Systems: Design and Performance Evaluation,” Sensors , vol. 18 , no. 2 , p. 635 , Feb . 2018 .

9. A. Daher , M. Coupechoux , P. Godlewski , P. Ngouat , and P. Minot , “ SC-PTM or MBSFN for Mission Critical Communications? ”, 2017 , pp. 1 - 6 .

10. E. Kurniawan, P. H. Tan , K. Adachi , and S. Sun , “ Hybrid Group Paging for Massive Machine-Type Communications in LTE Networks ,” 2017 , pp. 1 - 6 .

11. IETF RFC 7228 (May 2014 ): "Terminology for Constrained-Node Networks" , C. Bormann , M. Ersue , A. Keranen .

12. 3GPP 37 . 869 v12 Study on Enhancements to Machine-Type Communications (MTC) and other Mobile Data Applications . 2013 .

13. C.-H. Wei , R.-G. Cheng, and S.-L. Tsao, “ Performance Analysis of Group Paging for Machine-Type Communications in LTE Networks,” IEEE Transactions on Vehicular Technology , vol. 62 , no. 7 , pp. 3371 - 3382 , Sep. 2013 .

14. H. -Y. Wei , C.-C. Hsu , G.- Y. Lin , and C.-C. Chou , “ Enhanced paging mechanism for machine type communication , ” EP 2 609 762 B1 , 07 -Mar- 2013 .

15. 3GPP 37.868 v11.0.0 Study on RAN Improvements for Machine-type Communications . 2011 .

16. 3GPP 36.213 V14 . 2.0 Physical layer procedures . 2017 .

17. 3GPP 36.321 v14.2 .1 Medium Access Control (MAC) protocol specification . 2017 .