Huge growth in the machine to machine (M2M) communications market is expected as we move towards a seamlessly connected world. This connectivity is provided via wired (Ethernet) and wireless (cellular, Wi-Fi, ZigBee, M-bus, etc.) accesses. The interworking between these different accesses is essential for the development of a seamlessly connected world.

M2M technologies enable automated remote monitoring and controlling of smart objects or smart devices (also called smart things). In addition, these technologies provide connectivity between smart objects, facilitating communications between them and resulting in the formation and foundation of the Internet of Things (IoT). IoT/M2M devices can exchange information, perform analysis, make decisions, and execute operations without human intervention.

In the domain of IoT/M2M, standardizations for key technologies (e.g., technologies for collecting and managing information, and discovering and managing devices) and horizontal service platforms are essential to achieve the IoT/M2M vision (i.e., interconnecting all smart things and allowing them to communicate with one another). Many leading standards development organizations (SDOs) are now collaboratively developing various standards to address the IoT/M2M technology spectrum.

The IoT/M2M ecosystem consists of many layers—application layer, common services layer, connectivity layer, and device management layer—as shown in Fig. 1. For each layer, different standards will apply and interwork. The third-generation partnership project (3GPP) system provides standards for the control layer and wireless connectivity layer, with special focus on energy and cost efficiency, and enhanced cellular coverage for machine type communications (MTC) devices. The Broadband Forum (BBF) standards apply for the fixed wireline connectivity, and device management (TR-069). The Open Mobile Alliance (OMA) standards apply to the management of wireless devices. The oneM2M standards apply to the application layer, control layer, and device management layer.

Therefore, in this paper, we will review the trends of these notable and active IoT/M2M-related standards organizations. Key features that are actively being discussed and considered will be highlighted. In particular, the work of the following standards organizations will be covered:

In addition to the SDOs listed above, there exist a large number of industry-sponsored consortiums and standards organizations in the world, developing other IoT/M2M-related specifications, such as IEEE Standards Association (IEEE-SA), Home Gateway Initiative, and AllSeen Alliance. The standards organizations considered in this paper are those that focus on IoT/M2M standards; these organizations have been chosen because they are considered major standards organizations in their respective areas (e.g., oneM2M for the common services layer) and are actively developing specifications in a timely manner according to our perspective.

This paper introduces the recent standards trends for 3GPP SA (Section II), 3GPP RAN (Section III), oneM2M (Section IV), and BBF (Section V). Each section presents an overview of IoT/M2M-related activities, main features, and future directions. Finally, the paper is concluded with a brief discussion and summary for future standardization work in the domain of IoT/M2M (Section VI).

3GPP is working on the standardization of mobile network technologies related to radio access and the mobile core network. Many technologies have been developed; the latest one in the market is long-term evolution–advanced (LTE-A), which is already in the early deployment stage in some mobile networks around the world. The 3GPP SA technical sub-working group started the work on MTC since Release 10 in the year 2010. MTC is just another name for M2M in 3GPP, concentrating only on the impact of using IoT devices on the 3GPP core network itself. While the MTC service provider may be outside of the 3GPP domain, the optimizations in the network are activated on the basis of the subscription or capabilities of the MTC device. 3GPP does not differentiate between normal 3GPP terminals, called user equipment (UE) and MTC devices, so all the enhancements for MTC could also be applied to normal UE. A detailed overview of the individual features of the different releases can be found in [1-3].

The first set of enhancements specified in Release 10 [4] includes MTC subscription handling and the overload and congestion control resulting from simultaneous transmission of data by a large amount of MTC UE.

The subscription control enables an MTC subscriber to activate/deactivate one or more MTC features in the subscription profile; this can be achieved by means of a web interface, but the process is outside the scope of 3GPP.

The overload and congestion control mechanism targets the prevention of scenarios when MTC UE is triggered or configured to send information to an MTC server simultaneously (synchronized application behavior). In order to prevent a ‘denial of service’ attack to the control nodes in the core network, the MTC UE includes in its service request a low priority indication. If an overload situation occurs, the MTC UE receives an ‘extended waiting timer’ and has to wait until its expiry before sending new requests.

In 3GPP Release 11, the following additional features were agreed to for MTC:

The MTC architecture enhancements [4] are shown in Fig. 2, highlighting the addition of new functional entities to the 3GPP architecture.

Communication takes place between the application server (AS), hosted by the third-party service provider and the MTC application in the UE. In order to provide value-added services like control plane triggering, a service capability server (SCS) is used, which can reside either in the 3GPP network operator domain or in the trusted third-party service provider domain. The MTC interworking function (MTC-IWF) is the major new node taking care of device triggering via the Tsp and T4 reference points as well as identifier mapping.

With respect to addressing, 3GPP agreed to use IPv6 as a primary addressing mechanism. Furthermore, for solving the identification issue due to the constrained number of available mobile subscriber integrated services digital network numbers (MSISDNs), external identifiers were agreed for usage outside of the 3GPP network operator domain by the third-party service provider, which are mapped to the unique international mobile subscriber identity (IMSI) for all related procedures inside the 3GPP network.

Device triggering was one of the most important topics in the discussions. Since the MTC UE may not be attached to the packet-switched domain of the 3GPP network all the time for battery-saving reasons or other constraints, it needs to be triggered by the third-party application server in order to trigger a specific action, e.g., submitting measurement results. This is achieved by the T4 triggering procedure, which is basically a trigger message from the third-party service provider to the MTC-IWF over Tsp, where the external identifier is mapped to the IMSI and the trigger is sent in form of an SMS to the UE via T4. Once the UE receives the trigger SMS, it can identify it as a special trigger message and route it to the corresponding MTC application based on the used port number.

The enhancement that was specified in Release 11 was the PS-only service provision; i.e., an MTC UE may not have an MSISDN, since these devices can use only packet-switched services. The specified enhancement consists of the SMS delivery and interworking for such MSISDN-less devices.

In Release 12, only two other features were specified [5]: one is the small data enhancements feature, which optimizes the network for the low data application needs of the MTC devices. This is done by adjusting the base station (eNodeB) parameters with the assistance of the core network. The other enhancement targets the power consumption and battery saving in the UE by introducing a new power-saving state for the MTC UE.

In Release 13, all the features that were not standardized in Release 12, i.e., monitoring enhancements of MTC UE [6] and group-based handling of MTC devices [7], are standardized. A new study item is carried out for exposing services from 3GPP [8] to the third-party service provider with application programming interfaces (APIs), e.g., from OMA or GSM Association (GSMA); a good overview can be found in [9]. Another new study item targets improvements of constraint devices that can handle high latency in their communication with the third-party application server [10].

Currently, the 3GPP RAN working groups have identified MTC as one of the most important topics for further enhancements, due to the diverse set of use cases and consumer demands for such communication, as compared to end-user communication for which such systems were traditionally designed [11]. The main motivation to develop new mechanisms for MTC is the large and diverse set of requirements and deployment use cases as well as scenarios currently envisioned for such modes of communication, which require cost- and energy-efficient solutions, in order to make such network deployments a viable option for network operators.

The focus of the RAN work done as part of Release 12 standardization was to first study whether LTE would be an ideal medium for providing MTC in an efficient manner [12]. Due to the perceived dense deployment of MTC devices or UE, reducing the cost of such devices was important and thus, had to be investigated. Since such devices were expected to be deployed in locations where there could be poor LTE coverage, possible coverage enhancement mechanisms also needed to be studied in detail. Various mechanisms for accomplishing these objectives were studied and compared with enhanced general packet radio service (EGPRS) multi-slot class 2 [12]. Various solutions were analyzed for reductions in the UE cost and power consumption, as well as for improving the coverage of such deployments.

In Release 13 of 3GPP LTE standards, a new work item has been defined, with the aim of specifying the solutions identified as part of the Release 12 work [13]. The key aim is to specify a new, low-complexity UE category for MTC devices, which operates in all the duplex modes supported by LTE. The device would have additional capabilities, such as a reduced UE bandwidth of 1.4 MHz in downlink and uplink, lower maximum transmission power, reduced support of downlink transmission modes, and some further optimizations, such as reduced transport block size, optimized support for reception of multiple transmissions, reduced channel quality, and state information reporting modes.

Some of the key requirements defined for LTE MTC UE include minimum data rate requirements similar to those of the EGPRS multi-class slot 2 devices, improved spectral efficiency as compared to the reference benchmark, similar or better service coverage area as compared to the reference case with 20-dB target coverage enhancement for LTE MTC UE as compared to regular LTE UE, co-existence with legacy LTE UE, use of the same carrier, no impacts on core network architecture, compatibility with frequency and time division duplexing (FDD/TDD), avoidance of LTE base station hardware changes, and limited mobility support [12]. The performance analysis of the proposed solutions was carried out mainly from a UE power consumption and cost perspective, as well as from the perspective of network coverage improvements.

The concepts that were studied to provide cost improvements [12] were as follows: reduced maximum bandwidth, single receiver radio frequency (RF) chain, reduced peak rate, reduced UE transmission power, half-duplex operation, and reduced support of downlink transmission modes. The main idea behind reduced maximum bandwidth was to have MTC UE supporting only lower bandwidth, e.g., 1.4, 3, or 5 MHz, instead of the 20-MHz LTE bandwidth. This could lead to optimizations in RF and baseband units, as well as optimizations in data and control channel bandwidths, in both downlink and uplink. The evaluations conducted for this mechanism revealed that reducing the maximum bandwidth could provide significant cost reductions, mainly due to optimizations in baseband processing. Uplink bandwidth reductions were shown not to impact the UE costs significantly, and minimal savings were observed for the RF components as well.

Having a single RF chain, instead of two antennas and RF chains is proposed to reduce the MTC UE cost, with the added cost of reduced UE receiver performance and corresponding loss of downlink coverage and spectral efficiency. The peak rate is envisioned to be reduced using reductions in maximum transmit block sizes and number of physical resource blocks in an assignment or grant, as well as optimizing the maximum modulation order used. A reduction in the transmit power could be achieved by removing the power amplifier stage of the MTC UE, which is proposed to reduce the UE cost. Such optimizations are expected to lower the uplink coverage and spectral efficiency performance. A half-duplex UE operation is proposed to reduce the costs related to the duplexer, and replacing the duplexer with a switch, thereby reducing the complexity of the RF implementation. Reduction of the transmission mode support of MTC UE is also proposed as a means to reduce cost. Coverage enhancement studies were also conducted with techniques proposed for achieving the 20-dB improvements for various physical channels. A new UE category for MTC devices is also proposed to avoid any impact on legacy devices.

The main objectives and justifications for the MTC-related specification work, proposed for Release 13 can be found in [13]. The key aim of the work is to specify solutions considered in [12], which could prove advantageous in enabling cost- and power-efficient MTC UE, which could operate in an environment with possible coverage enhancements. The objective of reducing the bandwidth to 1.4 MHz is to enable UE to operate in networks having any system bandwidth, while reducing the cost requirements. Transmit power reductions would be considered with an additional constraint of support for integrated power amplifier implementation. Further relaxations of UE processing requirements will also be investigated as part of this release.

For coverage improvements, some of the mechanisms that would be considered include sub-frame bundling techniques with hybrid automatic repeat request (HARQ) for physical data channels, removing or repetition of certain control channels, new channel formats, and flexible coverage enhancement techniques with new reporting formats. These mechanisms need to be evaluated with minimal impact on the standards and divergence from the currently defined procedures. Further, mechanisms for enabling an ultra-long battery life for such UE are being studied along with optimizations in transmit/receive times, modifications of signals/channels, and reductions in measurements/feedbacks that need to be achieved by the UE.

The IoT/M2M marketplace consists of many market segments, such as smart homes, smart buildings, smart grids, and healthcare that are being deployed using targeted solutions from solution providers. These IoT/M2M solutions are referred to as verticals, because they are proprietary solutions for specific market segments and are not designed to interplay with other verticals. In the future, in a seamlessly connected world, there will be a strong need to allow all IoT/M2M market segments to interplay in a standardized manner to allow application developers to build sophisticated, enriched horizontal M2M services. Therefore, in the last two years, oneM2M-related research has been focused upon the standardization of a distributed/modular horizontal M2M services layer platform that will enable vertical market segments to interplay using standardized interfaces. This would allow off-the-shelf products from different manufactures to easily interwork, thereby providing cost efficiencies for the customers.

The need for the development of a globally applicable access independent M2M services layer platform was recognized by the same seven leading national SDOs (ARIB, ATIS, CCSA, ETSI, TIA, TTA, and TTC) as in the case of 3GPP. Therefore, in July 2012, seven of the world’s leading information and communications technology (ICT) organizations agreed to collaborate in the launch of a oneM2M global partnership to undertake the development of M2M services layer platform specifications. The first set of oneM2M specifications (called Release 1) would be completed by the end of 2014. The formal launch of oneM2M Release 1 took place on December 9, 2014, at the ETSI Headquarters in Sophia Antipolis, France. Further, several leading organizations have been engaged in demonstrating the use of oneM2M specifications via working prototypes [14].

In the development of the oneM2M services layer platform, the three-stage standards methodology (stages 1, 2, and 3) was used as employed by other standards organizations. Stage 1 identified the service requirements for a horizontal M2M services platform by studying various vertical M2M use case scenarios [15]. This led to the development of the oneM2M services platform architecture [16] that addressed the service requirements (called Stage 2). The protocol work (called Stage 3) was done last to define the detailed message flows carried over the three reference points (Mcc, Mcn, and Mca), as shown in the high-level oneM2M functional architecture (Fig. 3). There are two other working groups in oneM2M for security (SEC), and management, abstraction, and semantics (MAS). The SEC working group defines the security and privacy requirements for secure communication between all the oneM2M system entities and the application layer. The MAS working deals with the technical aspects related to the management of M2M entities and/or functions. It also deals with support for application-specific abstraction and semantics.

The following list provides the oneM2M technical specifications for Release 1:

The key functionalities of the oneM2M services platform architecture are as follows:

The oneM2M functional architecture consists of the following three entities:

A combination of AE and CSE can reside in M2M devices or M2M gateways or inside the NSE. This makes the oneM2M architecture distributed and modular, thereby making it possible for different types of M2M configurations to be easily supported via standardized interfaces. The placement of these entities in different physical entities allows them to communicate over standardized interfaces and facilitate the handling of resources. A oneM2M certification process would be needed in the future to allow manufacturers to build products that are oneM2M compliant. The oneM2M certification process is under discussion.

As the work on oneM2M Release 1 specifications gets closer to being completed, work has already started in the Requirements working group (Stage 1) to identify new service requirements for Release 2. The working group is studying new M2M use cases that will help in identifying new service requirements that are not currently supported in Release 1. Further, work has started on a new technical report on home domain enablement with a focus on the management of home devices/appliances. For example, the oneM2M system shall support a semantic relation between two M2M home devices and take appropriate actions. This area has attracted a lot of attention lately, and has come under the umbrella of smart homes.

In addition, a new work item has been created to start studying the interworking aspects between the oneM2M services platform and the AllJoyn open-source system. AllJoyn is a collaborative open-source project of the AllSeen Alliance, providing manufacturers and developers the tools that they need to invent new ways for smart things to work together. The goal of this work item is to study the interworking scenarios between oneM2M and AllJoyn systems, resulting in the identification of gaps in the oneM2M system.

The Broadband Home Working Group (BBHome WG) of the BBF is developing and maintaining a CPE WAN management protocol (CWMP; also widely known as TR-069). CWMP is used for the remote management and configuration of customer devices (mainly Internet gateways and the devices connected to them) from the operator premises. This protocol is used by approximately 250 million devices worldwide [17].

Provided that CWMP is appropriate for the management of IoT/M2M devices, the BBHome WG continues enhancing this aspect of CWMP by working on various M2M-related aspects of the protocol. Fig. 4 illustrates the traditional scope of CWMP (re-drawn based on [18]), and Fig. 5 highlights the CWMP enhancements and extensions that have either been completed recently or are officially in progress. Each of the five aspects listed in the figure are explained in the following paragraphs.

Elaborate descriptions of using CWMP in M2M applications: BBHome is working on detailed descriptions of how to manage M2M solutions using CWMP. This is mainly performed in the context of work item SD-278 (cf. [19]) and can promote IoT/M2M scenarios by providing analyses of, implicit guidelines on, and discussions on the technologies involved in concrete CWMP-supported M2M applications.

Inter-SDO collaboration to support the use of CWMP as management protocol in M2M platforms: Through cooperation between BBHome and oneM2M, CWMP has already been included as one of the two main M2M management protocols in Release 1 (‘aubergine’) of oneM2M. More details about CWMP usage inside oneM2M platforms can be found in the mentioned release, but BBHome is also continuously working on ensuring the compatibility of the two protocols and the involved entities (e.g., the ACS with the oneM2M service platform).

Integration of features for M2M support in CWMPv2: A new version of CWMP, called CWMPv2, has been announced [17], with the intention to re-build various aspects of CWMP from scratch, in order to evolve towards “incorporating virtualization in broadband services, the M2M environment, and the Internet of Things.” The relevant foundations are being laid in the context of SD-069 [19].

Extension of the CPE proxy framework: The latest amendments of TR-069 [18] and TR-181, which is the data model for TR-069, include a large number of features for the CWMP proxy mechanism and framework. Proxying is for obvious reasons extremely important for IoT/M2M scenarios, e.g., for enabling the CWMP-based management of UPnP- or ZigBee-based M2M devices.

New data models for the support of M2M protocols: BBHome is constantly adding data models for the support of an increasing number of technologies at the customer premises. Many of the recently added data models are extremely important for M2M applications, e.g., the ZigBee-, UPnP-, and ETSI-M2M data models, and for the cellular interface, proxy-related objects, and various other parts.

In this article, we reviewed the recent trends in some of the most actively engaged standardization bodies in the areas of the IoT and M2M communications: 3GPP for architecture and radio access aspects, oneM2M for service layer platforms, and BBF for IoT/M2M device management in wired line networks. Further, an overview of the major features and issues that have been developed or are under development in these standards bodies was presented.

Looking at the recent activities in these standards organizations, we identified some key common trends: 1) given the request from various stakeholders from the IoT/M2M verticals, standards for a common service layer are actively being developed in order to provide a costefficient platform that can be easily deployed in a multivendor environment, 2) as an explosive growth of network traffic is expected from IoT/M2M, wireless network architectures and technologies are focusing on the optimization of their networks and mitigation of the potential impact, and 3) in managing millions of IoT/M2M smart devices, a concerted effort is underway in SDOs to develop various technologies for managing such devices using standardized methods.