First impressions on the IEEE 802.11ah standard amendment

As highlighted in the previous blog post, there is a new emerging standard in the M2M arena based on the IEEE 802.11 standards family. This standard is being developed under the IEEE 802.11ah group, and aims to define the physical (PHY) and medium access control (MAC) layers that operate at radio frequencies below 1 GHz. One of the goals of this standard is to ensure that the transmission ranges up to 1 km and that the data rates per user are above 100 kbit/s.

The standard is currently being drafted, but some essential details about this new standard are already available, which we will highlight in this blog post. It is important to emphasize that although the IEEE 802.11ah standard will define operations below 1 GHz, it will not use the TV white space bands (54-698 MHz in the US), which are targeted instead by IEEE 802.11af.

The PHY transmission in IEEE 802.11ah is an OFDM based waveform consisting of a total of 64 tones/sub-carriers (including tones allocated as pilot, guard and DC), which are spaced by 31.25 kHz. The modulations supported include BPSK, QPSK and 16 to 256 QAM. It will support multi user MIMO and single user beam forming.

In [1] is stated that stations will support the reception of 1 MHz and 2 MHz PHY transmissions. The channelization (i.e. operating frequency) depends on the region. In Europe it will be within 863-868 MHz, allowing either five 1 MHz channels or two 2 MHz channels. While in the US the available band will be within 902-928 MHz, allowing either twenty-six 1MHz channels or thirteen 2MHz channels. In Japan, the available band is within 916.5-927.5 MHz, with eleven 1MHz channels. In China the available band will be within 755-787 MHz, with thirty-two 1 MHz channels. South Korea and Singapore also have specific channelizations that can be found in [1].

The MAC layer will include a power saving mechanism and an alternative approach to perform channel access, which will allow an access point to support thousands of stations, as required for M2M applications. The channel access also supports a mode of operation where only a restricted number of stations can transmit.

There are several use cases for this standard [2], which include:

  • Sensor Networks – where the IEEE 802.11ah is used as the communication medium for the transmission of short-burst data messages from sensors, which include smart metering;
  • Backhaul networks for sensors – where the IEEE 802.11ah can be used to create the backhaul of mesh networks created by IEEE 802.15.4 networks;
  • Extended Wi-Fi range for cellular traffic off-loading – where the IEEE 802.11ah can be used to off-load traffic from a cellular network. The caveat is that the performance should be at least comparable with the one from the cellular network;
  • M2M communications – Whereas current systems are optimized more for human-to-human (H2H) communications, IEEE 802.11ah standard will mainly consider sensing applications.
  • Rural communication – Wireless communication in rural areas has led to some effort that is also titled as bridging the digital divide. Large potential is given by sub 1 GHz due to the wider supported range.

In future blog posts, we will follow up with the standardization activities in IEEE 802.11ah.

Continue reading

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.

MASS M2M at 3rd ETSI Workshop

Two of our researchers (German and Nuno) are at the 3rd ETSI Workshop presenting a poster about our ongoing work in enhancing the capacity of GPRS and LTE in the Radio Access Network.


There are more than 220 participants attending the workshop.

German and Nuno will post a summary of the events in the workshop in the end of the day.

If you are around come and visit them in the poster section during the coffee breaks.

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.