Reliable Reporting for Massive M2M Communications

In many scenarios, M2M communications involve a massive number of low-rate connections. A showcase application is smart metering, consisting of a massive number of devices, up to 30000 [1], where meters periodically report energy consumption to a remote server for control and billing purposes. Massive communications present a new operating mode, not originally considered in the cellular radio access and that us why M2M-reengineering of the cellular systems has been so much into the research focus. In such a setting, conventional assessment of the system based on the average throughput is not sufficient.

We have instead asked a different question. Let us assume that each message that comes to the sensor needs to be reported within the deadline TRI with guaranteed reliability of, say 99.99%. There is a large number N of potentially reporting devices. How many cellular resources need to be used for such reporting and how to arrange those resources? There are two things that prevent us from assigning deterministic resources for reporting. One is that the arrival of a message at the device is a random process. Another is that the transmission from the device has a random outcome – the packet may end up in error and it will need to be retransmitted. In summary, the amount of resources required by each device is random.

We present a solution to this problem in our paper recently accepted at IEEE Wireless Communications Letters:

[1] Corrales Madueno, G.; Stefanovic, C.; Popovski, P., “Reliable Reporting for Massive M2M Communications With Periodic Resource Pooling,” Wireless Communications Letters, IEEE , vol.3, no.4, pp.429,432, Aug. 2014
doi: 10.1109/LWC.2014.2326674

The key idea to combat the individual randomness associated with each device is to take advantage of the statistical regularity that arises due to the fact that the number of devices N is massive. We show how to allocate resources using this statistical regularity and still guarantee 99.99% to each individual sensor.

A condensed version of the letter is given below.

How to achieve  reliability without sacrificing system efficiency?


Figure 1: Representation of the LTE uplink resource structure, where a set of RBs has been reserved for M2M purposes.

In [1], we consider a system with a periodically occurring pool of resources that are reserved M2M communications and shared for uplink transmission by all M2M devices (see previous figure). The re-occurring period is selected such that if a report is transmitted successfully within the upcoming resource pool, then the reporting deadline is met.


Figure 2: a) Periodically occurring M2M resource pool. b) Division of M2M resource pool in the pre-allocated and common pool.

The M2M resource pool is divided into two parts, denoted as the preallocated and  common pool, which reoccur with period TRI, as depicted in previous figure. We assume that there are N reporting devices, and each device is preallocated an amount of RBs from the preallocated pool dimensioned to accommodate a single report and an indication if there are more reports, termed excess reports, from the same device to be transmittedwithin the same interval. The common pool is used to allocate resources for the excess reports, as well as all the retransmissions of the reports/packets that were erroneously received.

The question that arises is:  How many periodically reporting devices can be supported with a desired reliability of report delivery (i.e., 99.99%), for a given number of resources reserved for M2M communications?

We note that, if each device has a deterministic number of packets to transmit in each resource pool and if there are no packet errors, then the problem is trivial, because a fixed number of resources can be preallocated periodically to each device. However, if the number of packets, accumulated between two reporting instances, is random and the probability of packet error is not zero, then the number of transmission resources required per device in each transmission period is random.

The derivation of the individual reporting reliability can be found in [1]. Promising results have been shown in the context of LTE, where even with the lowest-order modulation only 9% of the system resources are required to serve 30K M2M devices with a reliability of 99.99% for a report size of 100 bytes. The proposed method can be applied to other systems, such as 802.11ah.


Figure 3: Fraction of system capacity used for M2M services, when P[Φ] ≤ 10−3, RI of 1 minute, RS of 100 bytes, bandwidth of 5 MHz and pe = 10−1.


[1] Corrales Madueno, G.; Stefanovic, C.; Popovski, P., “Reliable Reporting for Massive M2M Communications With Periodic Resource Pooling,” Wireless Communications Letters, IEEE , vol.3, no.4, pp.429,432, Aug. 2014
doi: 10.1109/LWC.2014.2326674

(Also available in


How Many Smart Meters can be Deployed in a GSM cell?

The need to deploy large number of wireless devices, such as electricity or water meters, is becoming a key challenge for any utility. Furthermore, such a deployment should be functional for more than a decade. Many cellular operators consider LTE to be the single long-term solution for wide area connectivity serving all types of wireless traffic. GSM/GPRS is a well-adopted technology and represents a valuable asset to build M2M infrastructure due to the good coverage, device maturity, and low cost. We recently submitted a paper in which we assess the potential of GSM to operate as a dedicated network for M2M communications. In order to enable M2M-dedicated operation in the near future, we reengineer the GSM/GPRS/EDGE protocol in a way that requires only minor software updates of the protocol stack. We propose different schemes to boost the number of M2M devices in the system without affecting the network stability. We show that GSM a single cell can support simultaneous low-data rate connections (e. g. to smart meters) in the order of 10^4 devices.

Ideal system in which the bandwidth is shared among the multiplexed devices. The protocol operation is limiting the number of devices, despite the application requirements.
Ideal system in which the bandwidth is shared among the multiplexed devices. The protocol operation is limiting the number of devices, despite the application requirements.

Ideally, a TDMA system should be able to allocate as many as possible devices as long as the quality of service is guaranteed. However, in practice, systems are typically not able to operate in this manner. GSM and GPRS are an example of a TDMA system limited by the protocol rather than the application requirements of the smart meters. Specifically, for smart metering, a payload below 1000 bytes is expected. Moreover, the traffic patters corresponds to device originated with periodical reporting in the range of 5 mins, 15 mins, 1 hour and 6 hours. These devices tolerate a delay up to the next scheduled transmission opportunity if the message was not successfully delivered.

The main idea is that resources are pre-allocated according the application needs. In this manner, thousands of simultaneous connections can take place in a single cell (a single frequency is considered). In addition, we analyze the probability of reports exceed the deadline.  This probability is presented in the following figure, where it is noticeable that for the most demanding case when RI=1min, a single cell could provide service for up to 5 · 10^3 simultaneous connections with a reliability of 99.99%. This number rises to outstanding value of 5 · 10^4 simultaneous connections that are served with 99.99%, if the reporting interval is set to 15 min.

Probabilty report arriving after deadline as a function of report interval RI, report size 100 bytes.
Probability report arriving after deadline as a function of report interval RI, report size 100 bytes.

The paper has been submitted to ICC’13 (Second IEEE Workshop on Telecommunication Standards). Download

1st day at the ETSI M2M 2012 workshop impressions

The talks on the first day of the 3rd ETSI M2M workshop were interesting. Along the day there were four thematic speaker sessions. The program is available here.

The first thematic session was dedicated to the ETSI current standardization efforts, where the main highlights was the recently started initiative OneM2M partnership project (, which the mission statement is:

“The purpose and goal of oneM2M is to develop technical specifications which address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M application servers worldwide.”

The speaker and ETSI board member Joachim Koss emphasized that the current M2M ETSI standard will be an important part in the upcoming oneM2M standard. The first release of the oneM2M standard is expected to come within one year time.

The second thematic session was dedicated to the ETSI M2M standard and included talks from industry. The focus was put on the current ETSI M2M architecture, what are the contributions of ETSI for M2M security standards, how should the device abstraction and semantics be performed. From these talks, it was interesting to see how the classification of security threats is currently being done (Check the slides when they become available).

The third thematic session was dedicated to the experience that several companies had when implementing the ETSI M2M standard in their products. From this talk it was highlighted that when in M2M the term constrained device is mentioned, it means different things to different people and therefore a holistic characterization should be considered. There was also some discussion about if the gateways are still required when IP become native in all devices, where the conclusion that it is still required but not for protocol translation.

The fourth and last thematic session was dedicated to the M2M in the industry. The talks included the efforts to align the smart metering industry approach with standards requirements and national security demands. The talk about smart grid was focused on how to leverage security and privacy. Finally the last talk was about road traffic assistance and the challenges that need to be addressed in 3GPP networks to be able to meet the requirements. One interesting example of the road assistance is to inform the driver what should be their average speed so that they are able to get in the green wave (i.e., catch green semaphores in a long stretch of the road).

The organizers will release the slides to the public at the end of the event.

M2M Standard Status & Traffic Patterns for MTC Devices

Note: Most of the information contained in this post can be found in our IEEE Article:

Reengineering GSM/GPRS Towards a Dedicated Network for Massive Smart Metering. / Madueño, Germán Corrales; Stefanovic, Cedomir; Popovski, Petar.

Proceedings of IEEE Internation Conference on Smart Grid Communications (SmartGridComm 2014). IEEE, 2014.. IEEE Communications Society, 2014.

Today we present the major M2M standard groups that have been investigating M2M communications requirements and issues, namely European Telecommunications Standardization Institute (ETSI), 3rd Generation Partnership Project (3GPP) and 802.16 Machine-to-Machine (M2M) Task Group.

Standard Specification Description Specification Reference
3GPP sA1- M2M study Report 3GPP TR 22.868
sA1- MTC service Requirements 3GPP TS 22.368
sA2 – system Improvements for MTC 3GPP TR 22.888
sA3 – M2M security Aspect for Remote Provisioning and subscription Change 3GPP TR 33.812
sA3 – security Aspect of MTC 3GPP TR 33.868
3GPP study on RAN Improvements for MTC 3GPP TR 37.868
3GPP study on GERAN Improvements for MTC 3GPP TR 43.868
IEEE 802.16 M2M Group Technical Report on usage scenarios, requirements, and standards changes needed for supporting Machine to Machine (M2M) Communication IEEE 802.16p-10/0005
M2M Evaluation Methodology Document IEEE 802.16p-10/0014
ETSI M2M service Requirements ETSI TS 102 689
ETSI Smart Metering Use Cases ETSI TR 102 692

23.888 – System Improvements for MTC

The scope of this Technical Report (TR) by 3GPP is the architectural enhancements to support a large number of Machine-Type-Communication (MTC) devices in the network and the enhancements to fulfill the MTC service requirements.

Key Issue Solutions
Group Based Optimization 0 Solutions
MTC Devices communicating with one or more MTC Servers 3 Solutions
IP Addressing 10 Solutions
Small Data Transmission 3 Solutions
Low Mobility 4 Solutions
MTC Subscriptions 1 Solution
MTC Device Trigger 19 Solutions
Time Controlled 6 Solutions
MTC Monitoring 11 Solutions
Decoupling MTC Server from 3GPP Architecture 4 Solutions
Signaling Congestion Control     11 Solutions
MTC Identifiers 7 Solutions
Potential overload issues caused by Roaming MTC devices 6 Solutions
Low Power Consumption 0 Solutions

The main issues identified in this document are Signaling Congestion Control, MTC Device Trigger and MTC Monitoring. While many solutions are proposed to IP Addressing, which is related to the lack of IP address in IPv4 and therefore it is considered as deprecated.

Signaling Congestion Control an overload is an urgent problem that Network Operators (NO) are currently facing. Though this issue can be partially solved in the application side to operate in a network friendly manner, it is difficult for network operators to influence the application developers.

MTC Device Trigger: many applications requires to remotely request reports from the MTC devices.

MTC Monitoring: For many MTC devices it is desired that the network detects and report events causes by those devices that may result from vandalism or theft of the communications module.

We also like to mention Group Based Optimization issue, which can help to alleviate the redundant signaling to avoid congestion. MTC devices can be grouped together for the control, management or charging facilities etc. to meet the need of the operators.

43.868 – GERAN Improvements for Machine-type Communications

The scope of the document compromises: GERAN enhancements for Smart Metering, improve efficient use of Radio Access Network (RAN) resources and overload and congestion control.

The current status of this TR is the definition of common assumptions for simulation tests, where M2M traffic models are provided for synchronous and asynchronous users. More precisely three traffic models are presented:

Traffic model Description
T1 MTC devices accessing the network in an uncoordinated/non-synchronized manner
T2 MTC devices accessing the network in a coordinated/synchronized manner with a certain distribution
T3 Legacy devices accessing the network in an uncoordinated/non-synchronized manner

37.868 Study on RAN Improvements for MTC

The study aims to study the traffic characteristics of different M2M applications and define new traffic models based on these findings. RAN enhancements to improve the support of MTC. These improvements are:

  • Access class barring scheme
  • Separate RACH resources for MTC
  • Dynamic allocation of RACH resources
  • MTC specific back off scheme
  • Slotted access
  • Pull based scheme.

Furthermore examples of RACH load for smart electric metering, fleet management and Earthquake monitoring are provided.

22.368 Service Requirements for MTC Communications

This document identifies the general requirements for MTC and where network improvements are needed to handle the specific nature of MTC communications.

M2M becomes massive also in terms of diversity across applications. Wireless M2M networks are instrumental to manage the complexity of tracking, fleet, and asset management. The industrial sector can widely apply M2M in monitoring and control of processes and equipment… Therefore the applications do not all have the same characteristics. The following MTC Features have been defined:

  • Low Mobility
  • Time Controlled
  • Time Tolerant
  • Small Data Transmissions
  • Mobile Originated Only
  • Infrequent Mobile Terminated
  • MTC Monitoring
  • Priority Alarm
  • Secure Connection
  • Location Specific Trigger
  • Infrequent Transmission
  • Group Based MTC Features
  • Group Based Policing
  • Group Based Addressing

IEEE 802.16’s Machine-to-Machine (M2M) Task Group is a relevant resource in terms of traffic characteristics and traffic models for Smart Grids and M2M applications.

Application Access Interval of Interest Access Attempt/second

(12K devices/sector)

Access Attempt/second

(35K devices/sector)

Meter Reporting 5 minute 40 116.7
Meter Reporting 1 minute 200 583.3
Unsynchronized Alarm Reporting or Network Access 10 second 1200 3500
Last Gasp Event Reporting 500 millisecond 24000 70000

To finish this post, the following two tables provides an excelent view of M2M Traffic patterns, where the average message size and the attempts per seconds is specified.

M2M traffic in cellular networks

Current cellular mobile networks are designed for human communication, and therefore are optimized for the traffic characteristics of human-based communication applications, i.e. communication with a certain session length, data volume, interaction frequency and patterns.

As the number of Machine-to-Machine (M2M) type devices increases so does the motivation to optimize existing cellular networks. While the features of the traffic generated by M2M devices are varied and application specific, the connected devices will be a mix of sensors and actuators. It is expected that a large majority will be sensors; therefore a bulk of the generated traffic will be in the uplink direction, i.e. from the M2M devices towards the network.

According to a recent market research study, in the next 10 years it is expected that the amount of M2M devices connections will reach 2.1 billion and that from these 61% will be due to the utilities market [1].

There are two interesting points about the characteristics of the traffic generated by this kind of application: The first is that the amount of data reported is generated sporadically and in small amounts, i.e. only a few bytes at a time; The second is that due to the expected density of the devices and the observed correlation between the reporting times [2], then the network will often observe a traffic pattern similar to a botnet, i.e. the traffic will arrive in batches. These two points will have an adverse effect on current cellular networks.

Currently, if one of these M2M devices wants to send a report to the network it will most likely use as carrier a SMS message. For this to happen, first the device needs to be connected to the network, which entails significant signaling overhead [3], then there is also the overhead associated to the transmission of a SMS message. Therefore, in the case of batch arrivals this will easily lead to the network to become overloaded due to signaling, while only transmitting a limited amount of data.

The network overload can occur at the radio access network, i.e. from a multitude of devices towards a base station, where in this case the base station gets overloaded, or globally where several base stations convey the traffic to a core network node. The ultimate consequence is the induction of signaling congestion and high computational load in the network.

In future blog posts we will describe what are the ongoing efforts to optimize the cellular networks to handle the characteristics of this particular type of M2M traffic.

[1] 2.1 billion M2M devices in 2021,

[2] M. Zubair Shafiq et al, “A First Look at Cellular Machine-to-Machine Traffic – Large Scale Measurement and Characterization” in Proceedings of the International Conference on Measurement and Modeling of Computer Systems (SIGMETRICS), London, United Kingdom, June 2012.

[3] Annex B.4 3GPP TR 37.868 V11.0.0