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, http://www.analysysmason.com/About-Us/News/Press-releases1/M2M-forecast-2012-PR-Jun2012/

[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

M2M communications in microgrids

As traditional energy resources are becoming increasingly scarce and thus more expensive (not to mention their adverse effects on the environment), the efforts towards energy generation from alternative, environmentally friendly resources and smart energy consumption are rapidly becoming concern of governments, industry and academia all over the world. The recent buzz-term smart grid symbolizes this important concept of the efficient generation, distribution and exploitation in case of electrical energy. In brief, smart grid comprises all elements of the electrical grid, but it is much more than just a collection of its parts – it is a dynamic system that interconnects them in a meaningful manner for the benefit of the end users. As such, smart grid heavily relies on communications between consumers, suppliers, smart devices and applications.

Smart grids of the future are envisioned as networks of integrated microgrids – (geographically) localized collections of generators, storage capacities and users (loads) that operate as singly entity with the goal of smart energy exploitation. With respect to this, the centralized approach for the regulation (i.e., control) of microgrid operation imposes itself naturally. However, the decentralized, distributed approach for microgrid control (known as the paradigm of multiagent systems) is a more favorable one, as it is inherently more robust and scalable. Naturally, distributed control should leverage on adequate distributed communication techniques.

A recent issue of IEEE Wireless Communications (Jun 2012), under the topic “Recent advances in wireless technologies for smart grid”, presents a couple of research articles devoted to the wireless communications within microgrid. Particularly, a generalized approach for the multiagent coordination is assessed in [1], investigating the usage of consensus algorithms for distributed dissemination of information among the agents. The idea behind consensus algorithms is a simple one – series of local exchanges among the agents should result with each agent having the same insight into the global network parameters (in other words, communicating only locally spreads information globally – a well-known phenomenon in the social networks). In turn, this allows agents to separately apply the control algorithms using the same data, harmonizing their operation to achieve the optimal performance of microgrid. As the actual communication technology, the authors suggest use of WiFi (IEEE 802.11) or ZigBee (IEEE 802.15.4). The above generalized approach can be applied to a number of issues in smart grid operation, such are:

  • Economic dispatch problem,
  • Decentralized invertor problem,
  • Fault detection and recovery,
  • Agent clock synchronization (when GPS is not used),…

Economic dispatch

A related article [2] gives a nice analysis of the economic dispatch problem when the impact of communications is included. Economic dispatch [3] is a short-term determination of the optimal output of a number of electricity generation facilities to meet the system load at the lowest possible cost, while serving power to the public in a robust and reliable manner. The authors of [2] develop a plausible cost model which, besides generation costs, cost of purchasing power and cost of generating extra power, includes both the communication costs and the impact of communication errors on the possible deviation of system operation from the optimum. It is shown that the use of distributed consensus algorithms can in general steer the system operation towards the optimum. Further, it is shown that use of communication links that interconnect distant agents (which are not directly connected by WiFi/Zigbee links) can speed up the convergence to the desired state of optimal operation, lowering the total cost. On the other hand, these “global” links are provided using cellular communications, which increases communications costs and thus increases the total costs; the overall result being that the amount of cellular link usage should be carefully selected.

Although these initial research efforts are promising, a lot remains to be done. The impact of wireless communications impairments on microgrid operation is still not adequately addressed nor experimentally verified. With respect to the latter, it remains to be seen how effectively will WiFi/ZigBee networks (which are almost exclusively operating in a star/tree topology) support the execution of the distributed consensus algorithms.

[1] H. Liang et al, “Multiagent Coordination in Microgrids via Wireless Networks”, IEEE Wireless Communications, Jun 2012

[2] H. Liang et al, “Decentralized Economic Dispatch in Microgrids via Heterogeneous Wireless Networks”, IEEE Journal on Selected Areas In Communications, July 2012

[3] http://en.wikipedia.org/wiki/Economic_dispatch

ČS

Dealing with Short Data Packets

Many M2M applications use short data packets, going down to even several bytes. If a system is designed or analyzed under the assumption that the packets are short, then at least two issues should be taken into account:

  1. The size of the overhead or metadata becomes comparable to the data size.
  2. Near-optimal coding methods rely on large block lengths, and cannot be used in this setting.

Large percentage of overhead

The issue of metadata is often overlooked when putting forward conceptual (academic?) study of protocols and transmission methods. This is often because it is assumed that the packet is sufficiently long, such that a few bytes of metadata will be just an insignificant fraction of the whole packet. But, in the light of this, let us look at an ALOHA protocol run by, say 4000 devices. Assume that each device has only one byte of information to send. The meatadata of the packet sent by a node needs to be at least

log2(4000)≈12 [bits]

i. e. at least 50% more metadata than data in order to be able to address all the devices. This example could be extreme, but the main point is that the ALOHA protocol will spend at least 60% of the time, used for successful transmission, to send overhead. If we add the inherent loss in efficiency due to random access (idles and collisions), then the overall efficiency becomes quite low.

Coding rate for short packets

Information theory has been very good in teaching us how to send a large amount of data. But the elegant asymptotic results are not applicable, or even not indicative, when the packet has a short length. Let us take an example. If the Signal-to-Noise Ratio (SNR) at which the signal is received is S and the signal bandwidth is W, then we often, almost automatically, state that the data rate of the transmission is:

R_S=W log2(1+S)   [bps]

which is questionable since this is the data rate achieved over a channel with additive Gaussian noise, then codebooks that have their samples also distributed with the Gaussian distribution and, finally, the length of the codeword is N that goes to infinity. In that case, R_S (sometimes called Shannon formula) tells what is the maximal rate at which the probability for packet error will be approximately 0. In order to have a proper theoretical framework for short packets, perhaps one should resort to the recent advances in the area of non-asymptotic information theory.

But, another thing that should be kept in mind is that the coding/modulation that will be used by a simple M2M device will be also simple, far from the optimal Gaussian codebooks. In that sense, it seems viable to work with finite modulation (BPSK, QPSK) which is arguably not generic, but may provide more usable results for the scenario at hand.