07516570

482 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 19, NO.
1, FIRST QUARTER 2017
A Survey of Standards for Machine-to-Machine

and the Internet of Things
Vangelis Gazis
Abstract—Over the last decade, there has been a growing connectivity between arbitrary sensory artifacts of everyday
research interest in machine-to-machine communications and the life is ubiquitous. Thus, state information reflecting important
Internet of Things (IoT) as a milestone embodiment of the contin- aspects of human life can be conveyed from geographically
uous convergence between the physical facet of human activities
and its reflection on the information world. IoT is understood as distributed sensors to applications that make intelligent use
the (r)evolutionary transition into an era where physical assets of that information to optimize the effectiveness of human
and virtual assets will be treated uniformly and, for all intents activities, on the individual, group and social level.
and purposes, be largely indistinguishable to the processes involv- As part of its research agenda development, the European
ing them. The sheer scale of IoT suggests that harmonized global Commission (EC) has defined IoT as an integrated part of the
standards will be paramount in realizing a seamless treatment
across the physical facet and the virtual facet of things. In Future Internet (FI) where “things having identities and vir-
this paper, we survey the—admittedly babelian—standardization tual personalities operating in smart spaces using intelligent
landscape of IoT and present its major efforts. Our survey con- interfaces to connect and communicate within social, environ-
cludes with a comparative discussion that highlights the key mental, and user contexts” [6]. The use of standard technolo-
challenges of future standardization in IoT. gies in the World Wide Web (WWW) to instrument the IoT is
Index Terms—Standards, machine-to-machine, Internet of frequently referred to as the “Web of Things” (WoT) [7]. The
Things, communications, network, sensors, architectures, big Telecommunication Standardization Sector of the International
data. Telecommunication Union (i.e., ITU-T) defines IoT as a global
infrastructure for the information society, enabling advanced
services by interconnecting (physical and virtual) things based
I. I NTRODUCTION on, existing and evolving, interoperable information and com-
A. Vision munication technologies [8]. All these definitions acknowledge
Machine-to-Machine Communication (M2M) as a foundation
VER THE last decade, there has been a growing
O research interest in the “Internet of Things”—a disrup-
tive technology, according to the U.S. National Intelligence
capacity of IoT [6]–[8].
Council [1]. Despite its recent popularity, the term “Internet B. Challenges
of Things” was actually first heard of in the previous century. The vision of IoT is couched on wide scale interoperability
The original definition envisioned a world where computers across multiple domains. This brings on technical challenges
would relieve humans of the Sisyphean burden of data entry in the area of data representation formats, data dissemination
by automatically recording, storing and processing in a proper mechanisms, and, data management platforms. These must
manner all the relevant information about the things involved collectively support the integration of different types of data
in human activities [2]. Despite its recent popularity, differ- generated from disparate sources that possibly operate under
ent understandings and definitions of what the “Internet of different administrations. They must also support the curation,
Things” (henceforth abbreviated as IoT) is about have been provenance and exposure of data to third party applications
reported in [3]–[5]. through appropriate interfaces that abstract the technologi-
The Internet of Things (IoT) is understood as a major cal details of the supporting infrastructures. This will enable
embodiment of the convergence between device-oriented sen- flexible data mashups and thus foster rapid innovation in the
sor networks and data-oriented applications that is facilitated application and services ecosystems [9], [10].
through the Internet portfolio of technologies. As revealed Connecting administrative islands through appropriate chan-
through its name, it heralds a distributed infrastructure where nels and enabling processes (which have insofar operated in
isolation to each other) to publish and consume data and ser-
Manuscript received October 18, 2015; revised March 25, 2016 and vices is among—if not—the greatest challenge faced by IoT.
May 10, 2016; accepted June 21, 2016. Date of publication July 19, 2016; Doing so entails considerable security challenges while also
date of current version February 22, 2017.
The author was with the Communication Networks Laboratory, Department introduces additional, yet untackled challenges in information
of Informatics and Telecommunications, National and Kapodistrian quality (e.g., trustworthiness, privacy, reliability, provenance,
University of Athens, Athens 15784, Greece. He is now with Cognizant etc.). The huge volume of data sets in IoT introduces chal-
Technology Solutions, Torhaus Westhafen, Frankfurt 60327, Germany (e-mail:
gazis@di.uoa.gr). lenges in the algorithms processing those data sets where
Digital Object Identifier 10.1109/COMST.2016.2592948 large populations of observations favor an ensemble mode of
1553-877X c 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
GAZIS: SURVEY OF STANDARDS FOR M2M AND THE IoT 483
processing based on statistical computation paradigms. And networks (e.g., M2M networks based on the IEEE 802.15.4
though these may suffice when processing bulk data in batch standard [16]).
mode, applications with realtime or near-realtime require- On a global level, the oneM2M organization was
ments challenge our state-of -the-art in algorithmic approaches formed in July 2012 by seven Standard Development
targeted to data streams (e.g., complex event processing). Organizations to ensure global alignment of M2M standards.
From an infrastructure perspective, IoT brings significant The founding members include the Association of Radio
security challenges when it comes to supporting authentica- Industries and Businesses (ARIB), the Telecommunication
tion and authorization for an unanticipated, potentially huge Technology Committee (TTC) of Japan, the Alliance
number of devices seeking attachment to a network infras- for Telecommunications Industry Solutions (ATIS), the
tructure and/or to each other in a peer-to-peer mode. With a Telecommunications Industry Association (TIA), the China
significant percentage of IoT devices built on embedded com- Communications Standards Association (CCSA), the
puting solutions where resources (e.g., CPU, memory, etc.) are European Telecommunications Standards Institute (ETSI)
typically constrained, challenges are introduced in the area of and the Telecommunications Technology Association (TTA)
energy-efficient modes of operation, and resource-savvy com- of Korea [17]. These also participate in global standard-
munication protocols. From the network administration stand- ization activities of the International Telecommunication
point, introducing mechanisms that safeguard the integrity of Union (ITU). There is also close interaction with major
the network infrastructure and the reliability and availability industry alliances (e.g., Open Mobile Alliance, BroadBand
of communication services in a fair manner is paramount. Forum) and Internet standardization bodies (e.g., IETF). In
Robust and efficient device management on a large scale, along subsequent sections we elaborate on the standardization scope
with provisioning management (e.g., for trust establishment) and contribution of these efforts.1
and remote software management (e.g., IoT application lifecy- Some standardisation activities (e.g., oneM2M, ETSI M2M)
cle management), are understood as key pillars of successful address particulary the application layer and its requirements
deployment. These must be prudently balanced to economic on the M2M/IoT infrastructure. To this end, they define a ser-
concerns mandating the maximization of the utilization of the vice layer abstraction (e.g., the Common Services Entity in
network infrastructure by a large population of heterogenous oneM2M, the Common Services Layer in ETSI M2M) and
devices. the respective interfaces via which applications can consume
It becomes quickly apparent that most of the challenges services [12], [13], [18]. Rather than service layer interfaces,
brought on by IoT are interoperability challenges concerning the Open Geospatial Consortium (OGC) defines a distributed
multiple layers of the end-to-end protocol stack. It is, there- Web of Things (WoT) architecture to enable the creation
fore, no surprise that standardisation of key interoperability of observations and measurements about phenomena from
areas has been consistently recognized as the most significant sensory instruments in a controllable manner [19], [20]. To
factor for the success of the entire M2M/IoT ecosystem and this end, OGC defines the information model and represen-
its economy [11]. tation formats for observations and measurements [21], [22],
but also a set of Web Services to control and task sensory
C. Initiatives instruments according to each particular use case [21]–[24].
To foster the development of M2M ecosystems, multiple Communication and networking, particular in the field domain,
standardisation activities have been launched globally. The is addressed by different, sometimes antagonistic, technolo-
European Telecommunication Standards Institute (ETSI) gies providing solutions at a metropolitan (e.g., IEEE 802.16),
Technical Committee (TC) on Machine-to-Machine (M2M) local (e.g., IEEE 802.11a, IEEE 802.11h) and personal area
has developed specifications that are focusing on integration (e.g., IEEE 802.15.4) levels [16], [25], [26]. M2M and IoT
enablers and application support rendered through platform in a cellular wireless setting where integrity and efficiency
agnostic interfaces [9], [10], [12], [13]. The ETSI TC on requirements on the network infrastructure are paramount, are
M2M is collaborating closely with ETSI Next Generation addressed by 3GPP [14], [15], [27], [28] and 3GPP2 [29]–[31]
Network (NGN) activities and relevant activities in mobile in close collaboration. Finally, Open Mobile Alliance (OMA)
standardization progressed by 3GPP. The latter has included and Broadband Forum (BBF) provide a framework (e.g.,
support for Machine Type Communications (MTC) in its architecture, interfaces and protocols) to enable management
Release 10 specifications [14], [15], to ensure that 3GPP applications, most notably device management [32]–[38].
mobile networks can support M2M applications on a large scale. One quickly realizes that, in order to synthesize the com-
Within the Telecommunications Industry Association (TIA), the plete picture of M2M and IoT technologies, one needs first to
Engineering Committee TR-50 has developed access agnostic make sense out of the babel of relevant standards. In princi-
interface standards for systems in IoT. The Internet Engineering ple, this requires the establishment of a shared understanding
Task Force (IETF) Routing Over Low power and Lossy regarding which functions are available by the supporting tech-
networks (ROLL) working group is developing a routing archi- nologies without incurring the cost of dealing directly with
tectural framework for the IPv6 protocol tailored to resource- each particular technology. This challenge is at the center of
constrained devices (e.g., embedded devices). The IETF the oneM2M agenda to define an M2M service layer and its
Constrained RESTful Environments (CORE) working group
is developing a framework for resource-oriented applications 1 This is limited by practical constraints as not all SDOs make their scopes,
intended to run over the IP protocol on resource-constrained agendas and technical documentation publicly available in English.
484 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 19, NO. 1, FIRST QUARTER 2017
Fig. 1. The scope of M2M and IoT standardisation initiatives within the scope of the ITU-T reference framework for IoT [8].
basic buildings blocks. Of course one still needs to under- The contribution of IETF in regard to protocol standardis-
stand how each M2M/IoT standardisation activity fits in the ation for the IoT has been summarized in [39]. The authors
big picture (Fig. 1), as outlined in Table I. The reader may focus on the IEEE 802.15.4 standard and the details of the
refer to Table XI for a list of standards and acronyms found 6LowPAN work while also outlining the work done in the
in this paper. In the next section we present major M2M/IoT IETF ROLL working group. However, the consideration of
standards which we organize into a) service-related ones, deal- the IETF work on IoT standards is not comprehensive, in the
ing with defining common services for M2M applications, b) sense that significant work is not surveyed (e.g., the work of
communications-related ones, dealing with defining efficient the ACE and DICE working groups, which, is addressed here).
communication mechanisms for M2M applications, and, c) The essential features and the key capabilities of a wire-
data-related ones, dealing with defining generic mechanisms less protocol stack for IoT that is comprehensively addressing
for M2M applications to support versatile data usage and inter- important requirements in power efficiency, reliability, and,
operable data exchange. This classification scheme is derived connectivity to the Internet, is surveyed in [40]. Though
from the thematic clustering observed in the charter of the var- this work presents key technologies for IoT in the wireless
ious standardisation initiatives in M2M and IoT. For instance, domain, focusing on the IEEE 802.15.4 protocol stack and its
the ETSI and oneM2M activities are focusing on defining ser- particular features in support of power efficiency, reliability
vice interfaces to foster the development of M2M and IoT and Internet connectivity. However, other key technologies
applications by third parties (e.g., application developers). On for IoT (e.g., capabilities of the service layer, etc.) are not
the other hard, the work of OMA and BBF is primarily serving addressed, thus providing only a narrow perspective into IoT
the infrastructure management requirements for the benefit of standardisation (as opposed to the scope of this paper).
M2M service providers. Finally, [4] surveys the technological drivers, potential
applications, challenges and future research areas in the
domain of IoT. However, relevant activities in standardization
D. Prior and Related Work are neither identified nor surveyed.
Some of the most popular technologies in IoT (e.g., sensor Standard security protocols for the IoT are surveyed and
network technologies) have been the subject of other surveys. discussed in detail by [41]. However, the survey is concerned
TABLE I
R ELATIONSHIP A MONG M2M/I OT S TANDARDS
exclusively with security matters, thus not addressing in full work is tasked to the ITU Joint Coordination Activity on
the end-to-end perspective on IoT standardization. Internet of Things (JCA-IoT). The latter is also addressing
The technological pillars of IoT are addressed in [42], important networks matters, including approaches for the iden-
primarily from the research perspective of the a) technolo- tification of things and alignment to work on a Ubiquitous
gies employed in the (wireless) communication among a Sensor Network (USN).
group of IoT nodes, and, b) the interoperable data exchange According to the IoT model, a particular physical thing may
between IoT nodes and Internet nodes. Though the need for have a representation in the information space via multiple vir-
stronger horizontal integration at the application layer of IoT tual things, though a thing may exist solely in the information
is identified, the contributions of relevant standards are not world, without a physical counterpart. In [8] a device is defined
discussed. as a piece of equipment having at least communication capa-
bilities and optionally capabilities of sensing, actuation, data
capture, data storage, and data processing. Communication
II. S TANDARDS —S ERVICES
among devices may be realized in any of the following modes:
A. International Telecommunication Union (ITU-T) • Through a communication network via a gateway
The International Telecommunication Union (ITU) has estab- (case (a) in Fig. 3).
lished a Focus Group (FG) on Machine-to-Machine (M2M) • Through a communication network without a gateway
Service Layer [43]. Liaising with regional and national stan- (case (b) in Fig. 3).
dardisation bodies (Fig. 2), the ITU FG has identified a • Directly (case (c) in Fig. 3).
minimum common set of M2M service layer requirements In the ITU-T M2M model, an M2M Application uses
and capabilities. Furthermore, it investigated an Application capabilities provided by the M2M Service Layer (SL). An
Programming Interface (API) and associated protocol solutions M2M Application may be hosted on the Device, Gateway and
to support the communications between the M2M applications Network Application Server components and termed Device
and the telecommunication networks. To this end, it collaborated Application (DA), Gateway Application (GA) and Network
with Study Group 2 (Numbering, Naming and Addressing), Application (NA), respectively (Fig. 4). The ITU-T M2M
Study Group 13 (Next Generation Network Requirements service layer comprises the following reference points:
and Architecture for Applications and services using Tag- D-SL Reference point between DA and M2M SL.
Based Identification) and Study Group 16 (Requirements and G-SL Reference point between GA and M2M SL.
Architecture for Multimedia Information Access Triggered by N-SL Reference point between NA and M2M SL.
Tag-Based Identification) of the ITU-T. It also aligned to other SL-SL Reference point between instances of the M2M SL
ITU sectors (e.g., ITU-R, ITU-D), as well as with other rel- (not shown in Fig. 4).
evant stakeholders (e.g., agencies, SDOs, forums, consortia, In general, the ITU work recognizes that an M2M platform
regulators, policy makers, industry and academia). may serve any of the following purposes:
Within the ITU, the FG is aligned to the Internet of Things • Connectivity Support—Support the establishment and
Global Standards Initiative (IoT-GSI) which promotes a unified management of M2M connections between M2M entities
approach in ITU-T for the development of technical stan- (e.g., provisioning M2M connections, monitoring usage
dards enabling IoT on a global scale. Coordination of IoT and load of M2M connections, etc.).
Fig. 2. ITU-T standardisation activities on IoT.
gateways, etc.). The ETSI M2M standard provides applica-

tions with standardized interfaces for accessing and consuming
the data and services rendered through such (typically last
mile) devices. It also defines the system architecture (i.e.,
functional elements, logical interfaces and communication pro-
tocols) that expose these interfaces to technology-agnostic
M2M applications. The latter may use data sets rendered
through M2M devices (e.g., sensors) and may also interact
with M2M devices (e.g., actuators) on the basis of issu-
ing commands and responding to events raised by M2M
devices. A Release 2 update was recently published by
Fig. 3. ITU-T model of IoT [8].
ETSI [10], [13], [47].
As illustrated in Fig. 5, the M2M logical architecture under
•Service Enablement—Realize a software environment
development in ETSI comprises two high level domains:
and a set of interfaces (e.g., API calls) to support
1) The Network and M2M Application (NA) domain (right
the development, deployment and execution of M2M
part of Fig. 5), composed of the following elements:
applications.
a) Access Network (AN) providing for communica-
• Device Management—Realize functions to support man-
tion between the Device Domain and the Core
agement processes dealing with M2M devices (e.g.,
Network (CN).
firmware update, provisioning of security credentials,
b) M2M Core Network (CN) providing for IP
bootstrapping, etc.).
connectivity and the associated control func-
• Application Support—Includes functions specific to the
tions to accommodate roaming and network
support of multiple M2M device types, multiple inter-
interconnection.
connection technologies and involving multiple network
c) M2M Service Capabilities (SC) providing func-
providers.
tions shared by M2M applications by expos-
The ITU-T M2M system scope within the overall ITU-T
ing selected infrastructure functionalities through
model for IoT is depicted in Fig. 4 [44], [45].
network interfaces whilst hiding technology
details.
B. European Telecommunication Standards Institute (ETSI) d) M2M Applications running the actual application
The ETSI Technical Committee (TC) on Machine to logic.
Machine (M2M) communications has published its Release 1 2) The Device and Gateway (DG) domain (left part of
of M2M specifications [9], [12], [46]. These define an end-to- Fig. 5), composed of the following elements:
end system architecture that supports the integration of M2M a) M2M Gateway using M2M SC for interconnect-
devices with different characteristics (e.g., sensors, actuators, ing to the NA domain and interworking M2M
Fig. 4. Reference points of an ITU-T M2M system within the scope of the ITU-T IoT model.
field-specific networking technology (e.g., Power

Line Communications (PLC), KNX, M-BUS, etc.).
d) M2M Applications running the actual application
logic.
Management plane functions include network management
functions (i.e., functions for managing fault, configuration,
accounting, performance and security aspects) for the AN
and CN domains, as well as management functions specific
to M2M.
An M2M application may use any combination of the
Fig. 5. The ETSI M2M architecture. Service Capabilities available in the DG and NA domains.
These Service Capabilities are accessed through the following
reference points (Fig. 5):
Devices to it. The M2M Gateway may also run mIa Resides in the NA domain and supports access and
M2M applications. use of Service Capabilities therein by NA instances.
b) M2M Device that runs M2M applications that are It thus supports the following features:
using M2M SC functions and are connecting to the 1) Registration management (i.e., registering) of
NA domain through any of the following modes: NA to the NSCL.
Direct The AN provides connectivity to the M2M 2) Accessing (e.g., reading, writing) information in
applications. an SCL.
Proxy The AN provides connectivity to the M2M 3) Device management.
applications through the M2M Gateway 4) Notification management (i.e., subscribe/notify)
acting as a proxy. for specific events.
c) M2M Network (MN) interconnecting M2M 5) Group management (e.g., creating, listing,
Devices and M2M Gateways through a updating and deleting groups).
TABLE II
R EFERENCE P OINTS IN THE ETSI S TANDARD
TABLE III
dIa Resides in the DG domain and supports an M2M I DENTITIES D EFINED BY THE ETSI M2M S TANDARD [12], [13]
application residing in an M2M host (i.e., Device
or Gateway) to access and use different Service
Capabilities in the DG domain. When the M2M host
is an M2M Device, access and use of different Service
Capabilities in an M2M Gateway is supported also.
Supported features include:
1) Registration management (i.e., registering) of
DA to an SCL and of GA to a GSCL.
2) Accessing (e.g., reading, writing) information in
an SCL.
3) Notification management (i.e., subscribe/notify)
for specific events.
4) Group management (e.g., creating, listing,
updating and deleting groups).
mId Supports the communication between M2M Service
Capabilities residing in different M2M domains. To
this end, it defines mechanism for generic SCL
interactions:
1) Registration management (i.e., registering) of
DSCL/GSCL to an NSCL.
2) Accessing (e.g., reading, writing) information in
an SCL.
3) Device management.
4) Notification management (i.e., subscribe/notify)
for specific events.
5) Group management (e.g., creating, listing,
updating and deleting groups). Reference points mIa, dIa and mId were part of
6) Security. Release 1 [12] while reference point mIm was introduced in
mIm Supports the communication between M2M Service Release 2 [13]. Table II depicts the features supported over
Capabilities residing in different M2M domains. It each reference point across releases.
leverages core network connectivity functions (e.g., Table III lists the identity information defined by the ETSI
DNS, etc.) to support the following cases: M2M standard across its releases.
1) Interaction without registration, where a subset 1) Modes of Interaction: In providing access to M2M
of the capabilities offered over the mId reference resources, references points mIa, dIa and mId adopt a RESTful
point is supported (i.e., accessing of information model where each M2M resource is addressable via a URI
in an SCL in a different M2M domain, subscrip- and can have its state manipulated only via a defined set of
tion to and notification of particular events, and, primitives (e.g., Create, Retrieve, Update, Delete, Subscribe,
group management functions). Notify). The interaction between an M2M Application and an
2) Interaction with registration, where the capa- SCL, as well as between SCL pairs, is expressed exclusively
bilities offered over the mId reference point is through these primitives. Primitive execution will guaran-
supported in full. tee atomicity (e.g., through mutual exclusion) to ensure the
consistency of resource state. Different protocol bindings (Fig. 6a). The DSCL/GSCL will check if a SAF policy spe-
map the abstract definition of the mIa, dIa and mId ref- cific to the requesting entity applies. If no provisioned policy
erence points to concrete transport solutions (i.e., protocol matches, the DSCL/GSCL will apply the default provisioned
stacks). Protocol bindings to HTTP and CoAP [48] are SAF policy. If no default SAF policy has been provisioned,
defined by ETSI [46], [47] while additional bindings the DSCL/GSCL will send a STATUS_FORBIDDEN (i.e.,
(e.g., product-specific library calls to an internal API) can be rejection) response to the requesting entity and end the
supported. operation. Once the applicable SAF policy has been selected,
Primitive execution can be synchronous, asynchronous, the DSCL/GSCL will select the receiving SCL and, based
or, semi-asynchronous. In synchronous mode, the SCL on the RCAT attribute, build an ordered list of candidate
that receives a RequestIndication performs the appropri- access network that are already in use by the DSCL/GSCL
ate actions and (after checking that neither asynchronous and may provide a communication channel to the target
nor semi-asynchronous mode is required) sends a single SCL. The DSCL/GSCL will check each access network
ResponseConfirm (indicating either success or error). In asyn- in the list, according to the latter’s order) whether it is an
chronous and semi-asynchronous mode, the SCL that receives appropriate choice for the indicated (via the RCAT attribute)
a RequestIndication determines that an asynchronous mode category and (time-wise) communication schedule. If an
should be applied. It thus sends a single ResponseConfirm with appropriate access network is found, the SCL will select it
a STATUS_ACCEPTED code indicating that the final response and reuse the selected communication channel to send the
is pending. When the final response is eventually available, RequestIndication primitive to the receiving SCL.
the receiving SCL sends it via a single ResponseConfirm. The Otherwise, the DSCL/GSCL will check the TRPDT attribute
resulting differences between the synchronous, asynchronous of the RequestIndication primitive. If that indicates that
and semi-asynchronous modes will be handled in the transport deferred forwarding is acceptable (i.e., there is sufficient
layer (i.e., via HTTP, CoAP, or other bindings) [46], [47]. delay budget available at the time the DSCL/GSCL checks
2) Handling of Primitives: An M2M Application may issue the TRPDT attribute), the DSCL/GSCL may buffer the
(and route) a RequestIndication primitive to the local SCL RequestIndication primitive, according to its SAF policies. The
(e.g., a GSCL in the case of an M2M Application hosted on DSCL/GSCL may opt not to buffer (e.g., due to a SAF policy
an M2M Gateway) in various ways (e.g., via an internal library limit on the number of buffered RequestIndication primitives).
call for an application collocated to the SCL, a DNS lookup If the DSCL/GSCL buffers the RequestIndication primitive, it
to the Fully Qualified Domain Name (FQDN) of the sclBase will start a timer to monitor the additional delay and ensure
resource of an NSCL for an application remote to the NSCL, it does not exceed the maximum allowable delay indicated
etc.). A RequestIndication primitive may be subject to delayed by the value of the TRPDT attribute. Once buffering is done,
forwarding by the local SCL (i.e., the SCL receiving the the DSCL/GSCL will send a STATUS_ACCEPTED response
RequestIndication primitive from the M2M Application) if it to the requesting entity (i.e., typically the M2M Application)
includes a Tolerable Request Processing Delay Time (TRPDT) and wait for either availability of a appropriate communica-
attribute. The latter indicates the maximum acceptable delay, tion channel, or, expiration of the timer. In the former case,
either as an absolute value or as a delay period. When the the DSCL/GSCL will forward the RequestIndication primitive.
associated M2M resource is part of a resource group, delayed In the latter case, the DSCL/GSCL will attempt to establish
forwarding allows the local SCL to aggregate information a communication channel based on the value of the RCAT
related to other members of that group, if available. attribute. The DSCL/GSCL will first build an ordered list of
Before forwarding a RequestIndication primitive to access candidate access network that may provide a communication
remote M2M resources, the local SCL will check if the channel to the target SCL, checking also their time availability
primitive includes a Request Category (RCAT) attribute and schedule. If no suitable access network is found (i.e., the list is
assert that, for the particular M2M Application, connectiv- empty) and the RequestIndication primitive was buffered, the
ity to the remote M2M resource can be established via an DSCL/GSCL will send a semi-asynchronous or asynchronous
appropriate access network. If that is not possible, the local response with a STATUS_GATEWAY_TIMEOUT response
SCL will block forwarding of the RequestIndication primi- and remove the RequestIndication primitive from the buffer;
tive [46], [47]. The issuer of a RequestIndication primitive will otherwise, the RequestIndication primitive will be immediately
wait for reception of a respective ResponseConfirm primitive. rejected with a STATUS_GATEWAY_TIMEOUT response. If
We note that the correlation of ResponseConfirm primitives at suitable access network was found, the DSCL/GSCL will
to RequestIndication primitives is delegated to the transport iterate through the built list’s entries and attempt to establish a
layer [46], [47]. If a ResponseConfirm primitive is not received communication channel to the selected access network accord-
within the time window set for such acknowledgements, the ing to its policies, until either it is successful, or, the list entries
issuing SCL will act as if it had received a ResponseConfirm are exhausted.
primitive with a STATUS_REQUEST_TIMEOUT. 4) Selection of Communication Channel (Issuer is NSCL):
3) Selection of Communication Channel (Issuer The NSCL will check its SAF policy for a matching entry
is DSCL/GSCL): When a DSCL/GSCL issues a for the combination of the requesting entity (e.g., M2M
RequestIndication primitive, the SCL will apply Store-And- Application) ID and the target DSCL/GSCL ID. If a match
Forward (SAF) policy control in selecting the appropriate is not found, the NSCL will apply the SAF policy spe-
combination of access network and communication channel cific to the target SCL, if any (Fig. 6b). If no SAF policy
Fig. 6. Request handling in the ETSI M2M.
specific to the target SCL can be found, the NSCL will buffering the RequestIndication primitive is an acceptable
apply its default SAF policy, if one exists. Otherwise, it will option. So if no suitable communication channel is available,
send a STATUS_FORBIDDEN (i.e., rejection) response to the the NSCL will check the TRPDT attribute associated with
requesting entity and end the operation. After an applicable the RequestIndication primitive. If the TRPDT has a non-zero
SAF policy has been selected, the NSCL will proceed to net- value, The NSCL may buffer the RequestIndication primi-
work selection based on the RCAT attribute associated with tive according to the delay budget indicated by its TRPDT
the RequestIndication primitive. In doing so, the NSCL will attribute. In doing so, the buffer selected will be specific
build the list of available communication channels through to the RCAT attribute associated with the RequestIndication
which the target DSCL/GSCL can be contacted. The NSCL primitive. However, the NSCL may opt out of buffering
will map the RCAT value to specific access networks and (e.g., due to a SAF policy limit on the number of buffered
assemble the m2mPoC (Point-of-Contact) M2M resources in RequestIndication primitives) and immediately attempt to
an ordered list. Each m2mPoC resource is associated to a com- establish a communication channel for the target SCL (as
munication channel that can be employed to communicate to described subsequently), just as it would do if the TRPDT
the respective DSCL/GSCL. The setup of the communication value is zero. If buffering is applied, the NSCL will start a
channel between a DSCL/GSCL and a NSCL is typically orig- timer to ensure that the delay budget indicated by its TRPDT
inated by the DSCL/GSCL. The communication channel will attribute is not exceeded and send a STATUS_ACCEPTED
typically be bidirectional, though the unidirectional case may response to the requesting entity. The NSCL will then wait
also apply (e.g., due to NAT restrictions, etc.). for either availability of a appropriate communication chan-
The NSCL will thus iterate over the m2mPoC entries nel, or, expiration of the timer. If the timer expires, the NSCL
in the list and attempt to successfully map one to an IP will attempt to establish a communication channel for the tar-
address and port pair (e.g., via a DNS lookup, etc.). If it get SCL. It will do so based on the RCAT attribute associated
succeeds, it will address the RequestIndication primitive to with the RequestIndication primitive.
the resolved IP and port details. If resolution fails for all In establishing a communication channel, the NSCL may
m2MPoC entries in the list, the NSCL will consider whether reiterate over access network selection, enlarge its scope to
TABLE IV
ATTRIBUTES OF M2M R ESOURCES IN THE ETSI S TANDARD
all potential access networks (e.g., including access networks

that are have become available and excluding ones that are
currently blocked due to a wake-up procedure). If no suit-
able access network can be found, and the RequestIndication
primitive was buffered, the NSCL will reject it by removing it
from the buffer and sending a semi-asynchronous or asyn-
chronous response with a STATUS_GATEWAY_TIMEOUT
response. Otherwise, the RequestIndication primitive will be
rejected with a STATUS_GATEWAY_TIMEOUT response. If
suitable access networks are found, the NSCL will go through
them and may engage a wake-up procedure to the M2M
device associated to the target SCL, including the parameters
for establishing the preferred communication channel, until
a receiving SCL establishes a communication channel (thus
concluding also the wake-up procedure).
Once a communication channel to the target SCL has Fig. 7. The oneM2M Functional Architecture [18].
been established, the NSCL will build the list of buffered
RequestIndication primitives for the target SCL and send each
one to the target SCL, stopping also its associated TRPDT
OneM2M defines a so-called Service Layer that is agnostic
timer.
to the Underlying Network (UN) and supports the transport of
5) Resources: To fit the needs of multiple M2M application
data and between M2M entities, as well as a set of associated
domains, the ETSI specifications provide generic mechanisms
M2M services. The oneM2M model is thus closely aligned to
to define resources of arbitrary complexity. Resources exposed
the ETSI model based on service capabilities.
by an SCL through the ETSI M2M RESTful API are com-
The oneM2M high-level architecture is organized into three
prised of a basic common set of attributes, including those
layers. Reference points defined by oneM2M provide a clear
(non-exhaustive set) in Table IV.
demarcation between these layers and enable interoperability
between oneM2M provider infrastructures.
C. OneM2M • The Application Layer (AL) containing M2M applica-
Established in 2012, oneM2M [17] is a partnership among tions termed Application Entities (AE),
the major ICT standards development organizations around the • The Common Services Layer (CSL) containing com-
world (i.e., ATIS, ARIB, CCSA, ETSI, TTC, TIA, TTA and mon functions of the oneM2M architecture termed
TSDSI) [17]. Chartered to the development of global M2M Common Service Function (CSF). Sets of related CSF
standards, it currently numbers approximately 200 members. instances are organised into so-called Common Service
Their common objective (and charter of the partnership) is the Elements (CSE).
development of joint specifications and technical reports for • The Network Services Layer (NSL) subsuming the
M2M, with a priority on the M2M service layer. The current underlying network infrastructure(s) and exposing
state of the actual specification of the end-to-end oneM2M their capabilities through so-called Network Services
functional architecture is given in [49]. Entities (NSE).
Fig. 8. The possible configurations of the oneM2M system [18].
1) Reference Points: Entities in the AL, CSL and the NSL resource whose state is managed by invoking operations
interact through the following reference points (Fig. 7): on it).
Mca Supports the interaction between AE and CSE so as Hence, from a technological implementation standpoint,
to enable the AE to use CSE services and the CSE oneM2M may be provided by a CSE with access to the lat-
to communicate with the AE. ter’s functionality either by invoking service operations over a
Mcc Supports the interaction between two CSE instances Service-Oriented Architecture (SOA) interface or by invoking
in the same oneM2M provider domain. The Mcc operations over a Representational Service Transfer (REST)
reference point enables a CSE to use the services interface.
supported by another CSE (i.e., through proxying). 2) Node Types: These reference points involve two types
The Mcc’ reference point is used for the interaction of nodes comprised in a oneM2M system:
between CSE pairs in different oneM2M provider • CSE-Capable Node, containing one CSE and zero or
domains. more AE instances. An Application Service Node (ASN)
Mcn Supports the interaction between CSE and NSE to and a Mobile Node (MN) are examples of a CSE-Capable
enable the CSE to use the (transport and connectivity) Node.
services supported by the NSE. • Non-CSE-Capable Node, containing no CSE and one
To achieve openness and to promote interoperability among or more AE instances. An Application Dedicated Node
infrastructure investments, oneM2M does not enforce a par- (ADN) is an example of a non-CSE-Capable Node.
ticular application style for M2M applications. Instead, it The functional entities specified in the oneM2M system
specifies all interactions taking place over the oneM2M interact through the Mca, Mcn and Mcc reference points while
reference points on the basis of a request-response pat- residing in nodes, which may be arranged as follows:
tern [18]. The latter is flexible enough to accommo- • Application Service Node (ASN), containing one CSE
date both the Service-Oriented Architecture (SOA) and the and at least one AE and communicatíng via Mcc with
Representational Service Transfer (REST) architecture styles. a Middle Node (MN) or an Infrastructure Node (IN). For
Technical proposals for the integration of multiple archi- instance, a (oneM2M-compliant) M2M device could host
tecture styles through the request-response pattern have an ASN.
been studied in oneM2M [50]. In alignment to these • Application Dedicated Node (ADN), containing no CSE
studies, the oneM2M architecture represents all informa- and at least one AE and communicates via Mca with an
tion as a resource (i.e., every piece of information within MN or an IN. For instance, a resource-constrained M2M
the scope of the oneM2M standard is represented as a device could act as an ADN.
Fig. 10. The oneM2M CSE structure [18].
Fig. 9 provides an illustrative example for a oneM2M

system deployment, comprised of a) an M2M Service
Provider (SP) domain with support for multiple execution
environments (e.g., HGI/OSGi, OMG DDS), along with the
respective protocol layers, b) field domain comprised of
IEEE 802.15.4 gateway and device nodes acting as MN,
ASN and AN.
3) Layers and Entities: The oneM2M functional architec-
ture includes a field domain (i.e., M2M devices in deployment)
and an infrastructure domain (Fig. 7), comprised of the
following layers:
• The Application Layer (AL) (connected to the Common
Services Layer over the Mca interface) contains
Application Entity (AE) instances implementing the
M2M business logic. Each AE is identified through a
unique identifier (AE-ID).
• The Common Services Layer (CSL) contains Common
Services Entity (CSE) instances providing common ser-
vice functions (e.g., data management, etc.) to AL enti-
ties. Each CSE (identified through a unique CSE-ID) is
Fig. 9. An illustrative example of applying the oneM2M architecture from defined by oneM2M as the basic unit of service offered
a protocol stack perspective [18]. This deployment scenario involves an by a CSL and used by another CSL or AL. Each so-
extended field domain based on the IEEE 802.15.4 standard. The oneM2M called Common Service Function (CSF) can be hosted in
Field Domain is further decomposed in a Field Domain (involving M2M
gateways and M2M devices) and an Edge Domain (involving M2M devices a CSE, as illustrated in Fig. 10. Thus a CSE can contain
that cover also the case of device-to-device communication, e.g., according instances of any of the following CSF types:
to 3GPP). – Addressing & Identification (AID). Provides for the
addressing and identification of entities (i.e., AE,
ASN, ADN, CSE, IN, MN, etc.) and their resources,
• Middle Node (MN), containing one CSE and zero throughout their lifetime. The identities defined by
or more AE instances and communicating via Mcc oneM2M are included in Table V.
or Mca with IN, MN, ASN, and ADN nodes. For – Application & Service Layer Management (ASM).
instance, a (oneM2M-compliant) M2M gateway could act The ASM CSF provides software management for the
as a MN. CSE and AE layers and configuration management for
• Infrastructure Node (IN), containing one CSE and zero the CSL (i.e., configuration management of entities in
or more AE instances and communicating via Mcc or the AE layer are beyond the oneM2M scope). To this
Mca with MN or ASN nodes. For instance, a node in the end, it leverages the Device Management (DM) CSF
service infrastructure of the M2M Service Provider (SP) for interacting with the Management Server (MS).
could be an IN. The Software Management Function (SMF) provides
Fig. 8 depicts the supported configurations of the oneM2M functions to manage software components for AE
system, in terms of the way oneM2M-compliant and non- and CSE instances. These involve lifecycle manage-
oneM2M-compliant nodes can interface to each other and ment of software packages (e.g., installing, updating,
realize a oneM2M-compliant deployment. uninstalling, querying of status, etc.) and of software
TABLE V
I DENTITIES D EFINED BY THE ONE M2M S TANDARD [18]
components executing within the supporting execu- instances, as well as for M2M AN devices. AE
tion environment (i.e., starting, stopping, querying of instances can use DMG CSF functions to man-
status, etc.). age capabilities in the aforementioned nodes while
– Communication Management & Delivery Handling being independent of the technologies used for their
(CMDH). The CMDH CSF coordinates data delivery implementation. An AE can thus utilize device
in space (e.g., by selecting the appropriate trans- capability information for administrative purposes
port connections, etc.) and time (e.g., by buffering (e.g., diagnostics procedures, etc.). Different device
communication requests, scheduling data transmis- management technologies (e.g., BBF TR-069 [34],
sions in time according to the acceptable maximum OMA-DM [32], etc.) are made available through the
delay of delivery, etc.) for communication requests DMG by means of Management Adapter elements that
(e.g., for CSE-to-CSE interactions). To this end, it perform translation and adaptation functions between
employs the supporting data transfer mechanisms the DMG and Management Server instances.
(e.g., expedited delivery mechanisms, etc.), if any, of – Discovery (DIS). Supports the search and discovery
the underlying NSL. Thus end-to-end data delivery is of information regarding AE instances and associated
realized by coordinating the store-and-forward pro- services (i.e., resources, in general) across one or
cessing of data requests through the use of CMDH more CSE.
policies. Furthermore, CMDH functions support the – Group Management (GMG). Supports the man-
awareness of the availability of underlying network agement of groups and their members through
infrastructures. Multiple bindings to transport pro- resource-oriented operations (e.g., creating and delet-
tocols are defined, with HTTP/HTTPS, MQTT [51] ing groups, adding and removing members from a
and CoAP [48] being included in oneM2M Release 1 group, updating a group, querying for a group and
and WebSockets [52] being added in oneM2M its properties, subscribing and notifying to and from
Release 2. groups, etc.). To maintain consistency, these opera-
– Data Management & Repository (DMR). It pro- tions ensure that only AE and CSE instances with
vides storage and mediation functions for data, valid roles with regard to access control policies are
thus enabling the loosely-coupled exchange of data included in a particular group. Likewise, subscrip-
among AE instances. Furthermore, it provides data tion to a group means that the subscriber has an
collection and aggregation capacities to enable interest in all its members; hence the GMG CSF
large-scale data processing and subsequent seman- aggregates the notifications from the group members
tic analysis. Data is annotated with key contextual and notifies the subscriber of their aggregate result.
information (e.g., type, location, time stamp, etc.) In carrying out its function, the GMG CSF may lever-
to enable search and retrieval over a wide set of age the NSL capacities for broadcast and multicast
parameters. The DMR SCF enforces data access con- communication, if any.
trol policies and can trigger the designated type of – Location (LOC). Enables an AE to obtain geographi-
processing based on data access. cal location information regarding a particular Node.
– Device Management (DMG). Provides management To this end, it requests selected Nodes to share and
of device capabilities for MN, ASN, and, ADN report information about their geographical location
with the requesting AE while providing a mechanism • The Network Services Layer (NSL) interacts with the
to ensure the confidentiality of exposed information. CSL over the Mcn interface and contains Network
– Network Service Exposure, Execution, Triggering Services Entity (NSE) instances that provide common
(NSSE). Makes selected functions of the underlying network services (e.g., device triggering, etc.) to CSL
network infrastructure (e.g., device triggering, small entities. We note that pure networking services (e.g., data
data transmission, location notification, etc.) acces- transport) are not part of the NSL.
sible to AE instances without exposing the latter to The particular arrangement of a oneM2M system will
the technological details of their instrumentation. The vary, depending on the technology solutions deployed by
NSSE provides translation and adaptation for the net- each oneM2M provider. The oneM2M system defines a flex-
work service of different UN instances. It maintains ible architecture which, through the appropriate arrangement
the necessary sessions over the Mcn reference point of its aforementioned elements, can accommodate different
between the CSE and the UN on behalf of local CSF deployment settings and infrastructure migration requirements.
instances in need of a network service. In addition, it Interworking to non-oneM2M M2M area network technolo-
supports the CMDH CSF by providing information gies is achieved through an Interworking Proxy Application
about the UN instances it interfaces to. Entity (IPE). An IPE may undertake interworking to multiple
– Registration (REG). Processes requests from an M2M area networks of different types (e.g., ZigBee, BACnet,
AE (or another CSE) to register with a so-called etc.). To this end, the IPE will represent the structure of each
Registrar CSE. Registration is required before the M2M area network (i.e., its devices, applications, interfaces,
requesting AE (or CSE) can use the services offered etc.) as an M2M resource which it will update accordingly
by the Registrar CSE. Registration also applies so that a consistent representation is available to oneM2M
locally to an ASN, MN or IN, before a co-located AE entities.
can use the services offered by the respective ASN, Table VI lists the parameters included in the requests created
MN or IN. Successful registration of an AE to a CSE and handled by a oneM2M system. For the detailed mapping
means that the AE can access, subject to policy con- of parameters to request types the reader is referred to [18].
trol, the resources of all CSE instances accessible by Table VII lists the parameters included in the responses
the CSE. created and handled by a oneM2M system. For the detailed
– Security (SEC). The SEC CSF provides for the han- mapping of parameters to request types the reader is referred
dling of sensitive data (e.g., encryption/decryption, to [18].
anonymization, etc.), the establishment of security By handling requests and issuing responses, the CSE
associations, the application of access control (i.e., supports the manipulation of M2M resources by the AE.
identification, authentication, authorization), and, the Resources provide a representation for the entities comprising
management of identities and security policies. a oneM2M system (e.g., nodes, applications, sensors, actua-
Security administration involves also the creation tors, data, etc.). Each resource is uniquely addressable and can
and management of dedicated security environments, serve as a container for attributes and other child resources.
along with the required (pre- and/or post-) provision- Conveying the representation of a resource between M2M
ing of their root security credentials. entities and resource manipulation, in general, is based on
– Service Charging & Accounting (SCA). The SCA RESTful operations (e.g., Create, Retrieve, Update, and Delete
CSF provides to the SL charging functions applica- as per the CRUD pattern). Different types of M2M resources
ble to different charging models (e.g., subscription- are defined by the oneM2M standard [18]:
based charging, event-bases charging, etc.). The latter • Normal—These include a complete representation of the
include online real time credit control. The SCA CSF data included in the resource.
manages the charging policies applicable for the SL • Virtual—These lack a permanent representation of the
to support the capture of chargeable events and the data and serve to trigger a particular processing and/or
generation of charging records. To this end, the SCA the retrieve of particular results. For instance, a group
CSF may also interact with the UN, while the SCA resource contains a child fanOutPoint virtual resource to
CSF in the IN-CSE handles the charging information. enable the application of operations to the group mem-
– Subscription Notification (SUB). Provides notifica- bers in bulk. Responses from the individual members are
tions reflecting a change in the state of a particular subsequently assembled and aggregated at the fanOut-
resource (e.g., an update of a resource). The CSE Point resource so that the response matching the original
hosting a resource realizes the subscription by an AE request can be formulated. The CSE hosting the group
or CSE and undertakes the dissemination of appro- resource is responsible for these tasks.
priate notifications when changes to that particular • Announced—These are linked to some other original
resource occur. The scope of a resource subscrip- resource and bear some of its characteristics (e.g., a sub-
tion includes, subject to filtering criteria, tracking set of its attributes). When a resource is announced to a
change of the resource’s attributes as well as of set of CSE nodes, the latter are effectively informed of
its child resources (but not of changes to the lat- it. The announced resource at each CSE node includes a
ter’s attributes). Notifications are addressed to the link to the original resource and when the latter is deleted,
address(es) designated by the requesting AE or CSE. all announced resources for it will be deleted also. In the
TABLE VI
PARAMETERS OF R EQUESTS IN THE ONE M2M S TANDARD (M: M ANDATORY, O: O PTIONAL ) [18]
TABLE VII
PARAMETERS OF R ESPONSES IN THE ONE M2M S TANDARD (M: M ANDATORY, O: O PTIONAL ) [18]
face of updates, the CSE hosting the original resource is These enable the monitoring of events occurring at M2M
responsible for keeping all the resources announced for systems and the bidirectional exchange of events informa-
the original resource in sync to the latter. So an announced tion. The M2M SDC framework developed by TR-50 abstracts
resource can be regarded as a proxy of the original the underlying transport networks (wireless, wireline, etc.) so
resource that can have child resources added, even if that applications are not bound to their technology details.
those are not defined or announced as part of the orig- Furthermore, it provides a convergence layer for adapting to
inal resource. This enables the creation of a distributed different transport network technologies [53]. There are three
tree of resources that spans multiple CSE instances. Thus types of hosting entities (i.e., containers) in the TIA SDC
resource announcement supports the incremental discov- framework: the Server container, the Node container, and the
ery of resources across multiple CSE instances through Point of Attachment (PoA) container, as depicted in Fig. 11.
hop-by-hop inquires. The Server container hosts the Home Application (HA), a
Addressing a particular M2M resource can be logical entity that subsumes business logic and may interact
achieved through multiple identification methods, as listed with peer application entities hosted at the Point of Attachment
in Table VIII. (PoA) and/or Device (D) nodes. A Node Application (NA) acts
as an intermediary between:
• The Home Application (HA) and the PoA
D. Telecommunications Industry Association (TIA) Application (PoAA).
TIA tasked the Engineering Committee TR-50 M2M on • The Home Application (HA) and the PoA Device (PoAD)
Smart Device Communications (SDC) with the develop- node. A PoA Application (PoAA) exposes resources to
ment of access-independent interface standards for M2M. other application entities (e.g., HA, NA, PoAA).
TABLE VIII
M ETHODS OF A DDRESSING R ESOURCES IN THE O NE M2M S TANDARD [18]
III. S TANDARDS —C OMMUNICATIONS

A. 3rd Generation Partnership Project (3GPP)
Starting with Release 10, 3GPP has introduced support
for (device terminated and device originated) Machine Type
Communications (MTC) [14]. To this end, 3GPP has identi-
fied main use classes (e.g., traffic management, e-health, etc.)
and respective essential features of M2M communications rel-
evant to those (e.g., time budget for data delivery in unreliable
M2M communications, etc.).
MTC capabilities provided by a 3GPP network (Fig. 12) are
exposed to MTC applications via a MTC Service Capability
Server (SCS). The MTC SCS is a service platform as defined
by the ETSI M2M set of standards, or as contributed by the
Fig. 11. The TIA SDC M2M architecture.
proprietary solution of a market stakeholder. Administered by
the Home Public Land Mobile Network (HPLMN) operator
or by a MTC service provider, the MTC SCS interfaces to
The PoA container hosts PoAA entities that provide the MTC Interworking Function (MTC-IWF) in the 3GPP
resources to NA entities and HA entities. In addition, they HPLMN over the Tsp interface. The latter supports the request
also host PoA Device (PoAD) resources representing the actual of a device trigger by the MTC SCS and its subsequent
physical devices (e.g., sensory devices, IEEE 802.15.4 network notification of a device trigger occurring [27]. The inter-
nodes, USB peripherals, etc.). The management plane of SDC faces between the 3GPP system architecture elements and
provides functions for configuration, provisioning, deploy- the (newly introduced) MTC Server element [15], [27], [28]
ment, installation and maintenance procedures in the following are defined to support the following communication
layers: models:
• Application Management, dealing with applications.
• Direct, where an MTC Application communicates to the
• Device Management, dealing with devices.
MTC Server transparently to the 3GPP network (i.e., by
The SDC framework adopts a RESTful application model leveraging 3GPP bearer services in transparent mode).
and technology stack, thus addressing entities (i.e., resources • Indirect, where an MTC Application communicates to
and applications) by means of a URI/URL scheme. It is the MTC Server (e.g., to realize a value-added service),
thus classified as a “Web of Things” architecture model. which may be administered by:
Security concerns (i.e., authentication, authorization and – 3GPP Operator, where the MTC Server interfaces
accounting) are provided by an Authentication Authorization to 3GPP network elements using interfaces internal
and Accounting (AAA) entity acting as a container for secu- to the 3GPP network.
rity services (Fig. 11). As of 2011 the work in TR-50 has been – Third Party, where the MTC Server interfaces
harmonized to the work advanced in the ETSI M2M Technical to 3GPP network elements using the border
Committee (TC). interfaces of the 3GPP network (e.g., the Gi
interface [55], [56]).
E. ATIS
The ATIS M2M Focus Group (FG) has positioned its
M2M work as an horizontal capability (i.e., a platform) B. 3rd Generation Partnership Project 2 (3GPP2)
spanning across multiple vertical domains (e.g., Smart Grid, 3GPP2 has studied the communication aspects of M2M
Connected Vehicle). The scope of ATIS M2M work is being applications that impact the cdma2000 network infrastructure
pursued as an integrated activity to the 3GPP Machine Type (i.e., huge population of communicating devices, low traf-
Communications (MTC) work program [54]. Topics rele- fic volume per device, etc.) [31]. The M2M segment of the
vant for standardization by ATIS include carrier portability 3GPP2 reference architecture is aligned to the M2M architec-
issues (e.g., relieving the need for SIM card swapping, remote ture work done in 3GPP and ETSI in supporting the direct
reconfiguration, etc.), management procedures (e.g., provi- and indirect models described in Section III-A as part of an
sioning, billing, etc.), transport (e.g., peering), and security access-agnostic architecture [29]–[31]. Table IX summarizes
issues. the features of M2M applications considered by the 3GPP and
Fig. 12. The 3GPP M2M architecture.

TABLE IX
F EATURES OF M2M A PPLICATIONS IN 3GPP AND 3GPP2 – Providing load control information to M2M server
as part of the response to device trigger requests.
• M2Msms, used to interface to the Short Message Service
Service Centre (SMS-SC).
C. Internet Engineering Task Force (IETF)

The Internet Engineering Task Force (IETF) has chartered
several working groups to address technical requirements
related to M2M and IoT. The Routing Over Low power and
Lossy networks (ROLL) WG is developing a routing archi-
tectural framework for the IPv6 protocol that is tailored to
resource-constrained devices (e.g., embedded devices). The
Constrained RESTful Environments (CORE) WG is develop-
ing a framework for resource-oriented applications intended
to run over the IP protocol on resource-constrained net-
works (e.g., such as a wireless sensor network based on
the IEEE 802.15.4 standard [16]). The Authentication and
Authorization for Constrained Environments (ACE) WG will
develop use cases and requirement specifications for authenti-
3GPP2 standardization bodies. The M2M Server in 3GPP2 cation and authorization concerns in constrained environments
supports the following interface types: while also identifying authentication and authorization mech-
• IP, used to interface to the Home Agent (HA), Local anisms suitable for resource access. The Datagram Transport
Mobility Anchor (LMA) and Packet Data Service Node Layer Security (DTLS) in Constrained Environments (DICE)
(PDSN) network elements. WG is defining a DTLS profile suitable for IoT that can be
• M2Msp, used to interface to the M2M Interworking implemented on a wide spectrum of constrained environments
Function (M2M-IWF), which follows the protocols and (e.g., in terms of memory space, algorithm choices, packet
procedures of the Tsp interface defined 3GPP [28], and sizes, loss rates, error rates, etc.). In addition, the DICE WG
for the following purposes: will define mechanisms to enable use of the DTLS record layer
– Reception of a device trigger request from M2M for secure multicast communication.
Server. 1) ACE: The IETF ACE WG evaluates existing authenti-
– Reporting to the M2M server the acceptance or non- cation and authorization protocols for network environments
acceptance of a device trigger request. comprising constrained devices (e.g., in terms of process-
– Reporting to the M2M server the success or failure ing power, memory capacity, power supply, communication
of a device trigger delivery (if known). range, etc.). For these it considers a RESTful model of
interaction where CoAP with DTLS protection is employed 3) 6Lo: The IETF 6lo WG is addressing the IPv6 connec-
by clients to access resources addressable through a URI. tivity requirements of constrained devices (i.e., devices with
The ACE WG has proposed (and evaluated) multiple solutions hard upper bounds on transient and persistent state, code foot-
to confront the authentication and authorization challenges in print, processing cycles, power limitations, minimal set of link
LLN settings [57]. layer services like broadcast and multicast, etc.). It develops
Leveraging the Extensible Authentication Protocol (EAP), information models and data models to enable management of
the EAP-Based Authentication Service for CoAP employs adaptation layers (e.g., 6LoWPAN) in a generic manner. It has
CoAP messages for EAP transport to a) bootstrap the cre- also addressed header compression matters by building on the
dentials used to protect the exchange of CoAP messages, and, solution applicable to IPv6 over 6LoWPAN [64] and defin-
b) authenticate CoAP peers [58]. One solution is to introduce ing a Generic Header Compression (GHC) scheme based on
an AUTH option that leverages the cryptographic material LZ77 [65] compression and applicable to any header-like pay-
resulting from a successful EAP authentication. The AUTH load. Thus typical header-like payloads (e.g., DHCPv6, DTLS)
option can thus protect the integrity of CoAP messages con- are carried in UDP.
veying it. Another solution is to use the cryptographic material 4) DICE: To enable IoT constrained devices to make data
resulting from a successful EAP authentication to establish a available in a secure manner, the DICE WG has defined a
TLS security association. TLS/DTLS 1.2 [66], [67] Profile for IoT that safeguards data
The Two-Way Authentication for IoT (TWAI) uses DTLS exchange from eavesdropping, tampering and forgery attempts.
to support two-way authentication for resource-rich devices Though primarily intended for a CoAP setting, the TLS/DTLS
utilizing the RSA cryptographic algorithm [59]. It targets profile for IoT can also be applied to other environments, as
a 6LowPAN environment employing IPv6 and UDP. Due it is basically an optimized selection of configuration options
to the resource overhead associated with RSA, an Elliptic supported by TLS/DTLS, not an extension of the protocol.
Curve Cryptography (ECC) is proposed for more resource- The TLS protocol comprises two layers:
constrained devices. • Record—Uses reliable transport (e.g., TCP) services to
OAuth 2.0 is an established method of controlling access provide a secure connection based on symmetric cryp-
to resources hosted on a server [60]. An authorization token tography. It thus provides confidentiality, authentication
is issued by an authorization server to a client requesting of data origin, and, integrity protection for higher layers.
access to a particular resource. The server hosting a resource • Handshake—Uses Record layer services to enable the
checks the token provided by the client requesting access to the mutual authentication between a TLS client and a TLS
resource and grants the designated level of access to the latter server and the negotiation of the encryption algorithm
only if the token is found valid. OAuth 2.0 Introspection over and cryptographic keys to be used by higher layers for
the Constrained Application Protocol (CoAP) [61] defines a the exchange of data.
mechanism that enables the holder of an authorization token to In terms of security credentials, the following types are
get metadata associated to the token (e.g., validity, scope, etc.). supported by the DICE WG TLS/DTLS 1.2 Profile for IoT:
This leverages the OAuth Token Introspection mechanism in • PSK—Paired PSK identities and secret key per DTLS
defining a protocol mapping to CoAP for resource-constrained server.
devices. • Public Key—Either the public key of the DTLS server,
2) ROLL: The IETF ROLL WG has published a Routing or, its hash.
Protocol for Low-Power and Lossy Networks (RPL) based • Certificate—A properly populated trust anchor that
on a generic distance vector protocol. Over a particular (con- allows the DTLS server to validate the certificate provided
strained) network infrastructure, multiple RPL instances may by the DTLS client during their handshake.
run in parallel, each serving its given performance objec- Given the constrained resources of typical IoT devices and
tives (e.g., energy minimization, latency minimization, etc.). considering that not all IoT use cases will require the full suite
In RPL, the optimization of the routing objective is indepen- of security services offered by the TLS/DTLS 1.2 Profile for
dent of the processing and forwarding of packets. Thus the IoT, the DICE WG has defined the mechanism to apply data
RPL can be tailored to particular combinations of network integrity and confidentiality selectively for CoAP [68]. This
types and application classes through its so-called Objective is realized by establishing DTLS security channels using the
Functions [62]. RPL assumes a verification of link proper- AES_CCM cipher suite and selectively encrypting data at the
ties and a node’s reachability, e.g., using mechanisms like DTLS record layer. Thus the memory footprint and processing
Neighbor Unreachability Detection (NUD) and Bidirectional load attributed to security functions can be tailored to each
Forwarding Detection (BFD). Furthermore, RPL relies on an particular IoT application and, ideally, minimized.
external transport mechanism for particular control informa- In a low-power lossy network (LLN) network setting,
tion termed the RPL Packet Information. devices may join and leave the LNN dynamically. This intro-
Networks of IoT devices (e.g., sensors, actuators, etc.) may duces the scenario where a device has joined the network but
exhibit highly dynamic topologies (e.g., due to volatile wire- is not yet routable from an IP perspective. As a result, it can-
less conditions, etc.). Since each RPL node has a basic con- not engage in DTLS interactions. To address this issue, the
figuration, it operates mostly autonomously in disseminating DICE WG has proposed use of a DTLS Relay to support the
information. Trickle [63] is used to optimize the dissemination non-routable device and enable it to establish a secure DTLS
of information in RPL. session with a DTLS server [69]. The DTLS Relay goes into
The DTLS stateful mode preserves the end-to-end DTLS

protocol and its semantics at the cost of additional overhead,
which is placed exclusively at the DTLS Relay. DTLS stateful
mode is couched on the same architectural principles as NAT
and other middle boxes [70]. The DTLS stateless approach
impacts the end-to-end DTLS protocol as it introduces an
additional DTLS message (i.e., the DRY message) which both
DTLS Relay and DTLS Server must be able to process prop-
erly. The additional overhead is distributed among the DTLS
Relay and the DTLS Server and is associated to the encapsula-
tion/decapsulation of DTLS Client messages into/from DTLS
Relay messages, respectively. Since there is no need to main-
tain tuple state, the resource requirements on the DTLS Relay
are practically identical to those of a typical DTLS Client.
Transport efficiency is lower in the DTLS stateless mode, due
to the encapsulation overhead.
Fig. 13. Operation modes of DTLS Relay.

D. Institute of Electrical and Electronics Engineers (IEEE)
IEEE is addressing IoT work at the systems level through
its P2413 and 802.24 working groups.
operation when it receives a DTLS message from a newly 1) IEEE Project 2413 (P2413): IEEE is addressing IoT
joined device (i.e., a device capable of link addressing only) through the P2413 Working Group (WG) that will define an
supports the following modes: architectural framework for IoT [71]. The P2413 work will
Stateful—In this mode the DTLS Relay will change the include descriptions of different IoT domains, definitions for
source IP address and source port of the received DTLS mes- essential abstractions of IoT domains, and, identification of
sage to the source IP address and a randomly chosen source architecture elements that are common across different IoT
port, respectively, of the DTLS Relay. The latter will record domains. The P2413 work product will provide a reference
the (DTLS Client source link-local IP address, DTLS Client architecture for IoT comprised of basic building blocks that
source port, DTLS Server IP address, DTLS Relay source port) can be appropriately integrated into multi-tier systems. Being
tuple of the received DTLS message. The updated DTLS mes- still at an early stage, the P2413 WG leverages the standard-
sage is then sent to the DTLS Server which further interacts isation work done in Special WG 5 (Internet of Things) and
with the DTLS Relay as a regular DTLS protocol peer. When WG 7 (Sensor Networks) of ISO/IEC JTC 1, as well as the
the DTLS Relay receives a DTLS message from the DTLS work of oneM2M, IETF, ITU-T and W3C.
Server, it looks up its tuple state for a DTLS Client source link- 2) IEEE 802.24 Vertical Applications Technical Advisory
local IP address and source port matching the DTLS Server IP Group (TAG): The IEEE 802.24 Vertical Applications TAG
address and DTLS Relay source port conveyed in the DTLS addresses application classes that use IEEE 802 standards and
message. If a match is found, the DTLS Relay replaces the des- to which multiple working groups of IEEE 802 have an inter-
tination IP address and destination port of the DTLS message est in [72]. The IEEE 802.24 thus acts as a liaison and point
with the matching DTLS Client source link-local IP address of contact to other relevant standardisation bodies, industry
and source port and forwards the DTLS message accordingly. organizations, government agencies, and, IEEE societies for
Otherwise, the DTLS message is discarded, as depicted in matters of vertical (i.e., domain) applications in the context of
Part a) in Fig. 13. the IEEE 802 suite of standards. In this capacity it also pro-
Stateless—In this mode the DTLS Relay will encapsulate vides resources to regulatory agencies in order to promote and
a DTLS message received from a DTLS Client with only foster their understanding of the IEEE 802 suite of standards.
a link-local IP address into a new type of DTLS message
called DTLS Relay (DRY) message which it further sends
IV. S TANDARDS —DATA
to the DTLS Server. The DRY message header contains the
DTLS Client source link-local IP address and source port A. Open Geospatial Consortium (OGC)
while its payload contains the original DTLS message. The Given the infrastructure for disseminating IoT data, over-
DTLS Server, upon receiving the DRY message, decapsulates coming the challenge of semantic interoperability will
the original DTLS message from its payload and processes it largely depend on the existence of common information
according to the DTLS protocol. In responding to the DTLS models and the level of support for metadata manage-
Relay, the DTLS Server also encapsulates its DTLS message ment and semantic annotation. These concerns have been
in a DRY message. The DTLS Relay, when receiving a DRY addressed by the W3C Incubator Group on Semantic Sensor
message, decapsulates the original DTLS message from its Networks (SSN) whose recommendations include methods
payload and addresses it to the appropriate DTLS Client as to semantically enable applications developed according to
indicated in the DRY message header, as depicted in Part b) existing standards. These include the W3C SSN ontology for
in Fig. 13. describing sensors and networks thereof [73] and the Open
Geospatial Consortium’s (OGC) standards for Sensor Web SWE framework elements. These models allow applications
Enablement (SWE) described subsequently. to structure, encode and transmit data sets resulting from
1) Open Geospatial Consortium (OGC): The OGC adopts or relevant to sensor observations in a self-describing and
the Web of Things paradigm whereby sensors and the data semantically enabled way.
they produce are accessible over the Web using elements The SensorML Model and XML Encoding provides a
(interaction protocols, addressing schemes, etc.) of the Web semantically-rich instrument to support the definition of ele-
architecture (e.g., HTTP/HTTPS, URL/URI, etc.). OGC has ments (e.g., sensory devices, actuator devices, computational
established a Sensor Web Enablement (SWE) framework to processes) associated with the measurement of observations
facilitate the seamless integration of sensor network infrastruc- and their subsequent (i.e., after the measurement phase) trans-
tures and the observations these produce to the commonplace formation. Through semantic annotation interoperability at the
Web. OGC SWE defines a service-oriented architecture based syntactic (i.e., representation) level as well as at the semantic
on Web Services that enables applications to discover avail- level is facilitated. Thus descriptions of sensors and processes
able sensors and to consume data acquired through them in an become interpretable by computational agents and can be
interoperable manner [19]. In particular, OGC SWE realizes organised in units of automation within complex workflows
the following capabilities: at a Web scale.
• The definition of data models for the exchange of sensor The Observations and Measurements defines an XML
related data between elements of the SWE framework, implementation for the Observations and Measurements
through the SWE Common Data Model (CDM). (O&M) conceptual model of OGC and ISO, including XML
• The modeling of arbitrary complex sensor systems and schemas for observations acquired through sensors and for the
the associated processing of their observations, through features relevant in sampling observations.
the Sensor Model Language (SensorML) [22]. The Sensor Observation Service defines WS interfaces to
• The discovery of sensors and their associated obser- enable querying sensors about their metadata, their obser-
vations, through the Observations and Measurements vations, and, the representations of observed features. In
(O&M) standard [20], [21]. addition, it enables the registration/deregistration of sensors
• The exchange of observation data acquired through and sensor observations. Transport bindings include key-value
sensors, through the Sensor Observation Service (SOS) pairs conveyed through HTTP/HTTPS and SOAP.
standard [23]. The Sensor Alert Service (SAS) defines interfaces to enable
• The processing of sensor observations, through the Sensor sensors to register alert types to a SAS instance so they can
Observation Service (SOS) standard taking into account subsequently deliver the matching alert instance to the latter.
geometric, dynamic, and observational properties of indi- It also defines interfaces to enable applications to register their
vidual sensors. alert interests with a SAS instance so that the SAS can deliver
• The discovery of feasible (in space and time) observations matching alerts when the designated conditions occur. These
and the tasking of sensors and sensor systems, through interfaces are instrumented via the IEEE Extensible Messaging
the Sensor Planning Service (SPS) standard [24]. and Presence Protocol (XMPP).
The Sensor Web Enablement (SWE) Service Model defines The Sensor Planning Service (SPS) defines WS interfaces
data types that are commonly used across the OGC SWE to enable queries about the capabilities of a particular sensor
and its associated Web Services. These include the data types and about the feasible options of tasking it. SPS supports the
for request/response interactions among OGC WS servers and following queries:
clients. • Determining the feasibility of a sensor planning request.
• Common—Elementary and commonly used data types. • Submitting and (depending on the feasibility criteria)
• CommonCodes—Commonly used codes (e.g., request reserving and/or committing to a sensor planning request.
codes, response codes, etc.) with specific semantics. • Inquiring about the status of such a sensor planning
• Contents—Data types to support access to sensors. request.
• Notification—Data types to support the description of • Updating and canceling a sensor planning request.
a service’s notification capabilities and the definition of • Requesting information about other OGC Web Services
events relevant within the scope of the SWE framework. that provide access to the data collected by the requested
• DescribeSensor—Defines the request/response operations sensor planning request.
to request (and provide) metadata for a particular sensor.
• UpdateSensorDescription—Defines the request/response
operations to update the description for a particular B. OASIS
sensor. The OASIS Extensible Resource Identifier (XRI) Technical
• InsertSensor—Defines the request/response operations to Committee (TC) has published the Extensible Resource
insert a new sensor (to the OGC service in question). Identifier (XRI) and Extensible Resource Descriptor (XRD)
• DeleteSensor—Defines the request/response operations standards [74], [75]. The XRI syntax leverages the URI
to delete a particular sensor (from the OGC service in (Uniform Resource Identifier) specification [76] and the
question). IRI (Internationalized Resource Identifier) specification [77].
The Sensor Web Enablement (SWE) Common Data Model XRI defines a generic syntax for structuring abstract identi-
defines data models for exchanging sensor related between fiers so that they can be shared across different application
data anonymously and asynchronously, decoupled in space

and time. Each data instance is associated to a particu-
lar topic, thus decoupling application identity and achieving
anonymity. Decoupling in space and time is achieved through
asynchronous interaction over topics conveyed through a
publish/subscribe mechanism. A Quality of Service (QoS)
profile associated to each data instance regulates the non-
functional properties (e.g., reliability, availability, timeliness,
etc.) of information in the global data space. Thus DDS
addresses the prominent concerns associated to the develop-
ment of IoT applications (e.g., decoupling the production of
data to the consumption of data, providing notifications of
data updates, supporting one-to-any patterns in data distribu-
tion, etc.), while delegating the enforcement of QoS policies
to the DDS middleware layer.
V. S TANDARDS —S UPPORT
Fig. 14. The OMG DDS architecture. A. IP for Smart Objects (IPSO) Alliance
The IP for Smart Objects (IPSO) Alliance is a global col-
domains and embedded transparently within different URI laboration between industry stakeholders chartered to establish
schemes. Thus XRI provides a standard mechanism for iden- the Internet Protocol as the network for the connection of
tifying a resource in an abstract manner and independently of Smart Objects. In IPSO parlance, a Smart Object is a tiny
its concrete representation, if any at all. The XRD standard and low cost computer that may contain:
defines a generic XML format for describing and discov- • A sensor that can measure physical data (e.g., tempera-
ering distributed resources. The XRI Resolution standard ture, vibration, pollution).
defines a generic secure protocol for resolving XRI informa- • An actuator capable of performing a task (e.g., change
tion by means of resource descriptions and HTTP/HTTPS URI traffic lights, rotate a mirror).
information [78]. • A communication device to receive instructions, send data
or possibly route information.
C. Object Management Group (OMG) IPSO is chartered to enable applications comprised of Smart
The Object Management Group (OMG) has defined the Objects across several domains, including home automation,
Data Distribution Service (DDS) standard, a middleware archi- building automation, factory monitoring, smart cities, struc-
tecture and the respective publish/subscribe services to enable tural health management systems, energy management, and
scalable, real-time, dependable, high performance, and inter- transportation (i.e., all recognized parts of an IoT landscape).
operable exchange of data between publishers and subscribers. It complements other standardization initiatives by focusing
As illustrated in Fig. 14, the DDS specification includes: on the protocol aspects of interworking between the standard
• A Data-Local Reconstruction Layer (DLRL) layer that
IPv4/IPv6 protocol stack of the Internet and the resource-
enables integration to the application layer by means of constrained protocol stack of sensor networks based on the
an API for creating information objects out of a collection IETF Constrained Application Protocol (CoAP). IPSO is sup-
of topics. porting the creation of awareness on IoT technologies by
• A Data-Centric Publish/Subscribe (DCPS) layer provid-
complementing SDO work (e.g., by IEEE, IETF, oneM2M,
ing the real-time topic-based publish/subscribe API to etc.). Thus, its technical contribution is limited in scope and
applications. The DCPS API features provide a coherent heavily reusing the work of liaised standardization bodies.
set of standardized profiles and is available in multiple IPSO is active through a supporting role by documenting
programming languages (e.g., Ada, C, C++, C#, Java, the use of new technologies (i.e., IEEE 802.15.4, etc.) and
Scala, Lua, and Ruby). organising interoperability events.
• A Real-time Publish Subscribe (RTPS) protocol for
encoding/decoding data and conveying data between B. Other Standards
publishers and subscribers. It comprises a DDS 1) GS1: GS1 defines supply chain standards to address
Interoperability Wire Protocol Specification (DDSI) that the need for product identification and tracking in the retail,
facilitates interoperability between different DDS imple- food services, health care, transport, logistics, and, finan-
mentations. cial sectors of the global economy. Its standards support the
• An Interoperability Wire Protocol, referred to as DDSI, unique identification, accurate capture and automatic sharing
which realises the mechanism for point-to-point data of key information about products, locations and assets. In
transmission. GS1, products (and, in general, items) are identified through
In the DDS standard [79], all data instances exist in a their Global Trade Item Number (GTIN) information, also
typed global data space where applications read and write commonly referred to as their barcode.
The GS1 Global Data Synchronisation Network (GDSN)

automates data sharing and synchronization across global trad-
ing partners. GDSN relies on the GS1 Global Registry (GR), a
central directory service. The latter keeps track of the so-called
data pools of market stakeholders and to maintain a consistent
view of data items (e.g., product prices, etc.) for all trading
partners. For each particular data item (e.g., price of a prod-
uct), the GS1 GR identifies the source (i.e., authoritative) data
pool. In addition, it includes subscription information for (sub-
ordinate) data items (of other market stakeholders) that depend
on this particular data item. Thus when an update occurs at a
particular data item, the GR can trigger the update of informa-
tion of (subordinate) data items and thus maintain information
consistency.
As GS1 deals with things (e.g., product items) lacking
a communication capacity, it cannot be considered an IoT
technology under any of the common definitions of IoT [2].
However, the continuous embedding of communication capac-
ities into everyday life items and the increasing pervasiveness
of computing instruments makes GS1 a potentially strong
Fig. 15. Features of the ITU-T ORS standard [88].
candidate for specific technology challenges entailed by IoT.
2) The Handle System: Developed by the Corporation for
National Research Initiatives (CNRI) as a component of its
Digital Object Architecture (DOA), the Handle system is an • Canonical Encoding Rules (CER) [85].
extensible framework to support the efficient and secure resolu- • Distinguished Encoding Rules (DER) [85].
tion of unique persistent identifiers of digital objects [80], [81]. • Packet Encoding Rules (PER) [86].
A digital object has a platform independent structure that • XML Encoding Rules (XER) [87].
enables its identification and access in a controlled manner The ITU-T Object Resolution System (ORS) provides for-
(e.g., according to security policies). Besides its particular dig- ward and reverse resolution for OID information by mapping
ital content, it may also include metadata information about OID-IRI values to the DNS naming scheme [88]. Applications
it (e.g., access restrictions, ownership notices, licensing terms, use ORS services through an ORS client interface which,
etc.). The Handle system comprises the following parts: in turn, leverages a DNS client interface in accessing the
• A namespace to support multiple independent application respective information from DNS. It thus imposes particular
verticals. requirements on the management of DNS settings. Fig. 15
• A set of protocols to enable a distributed comput- illustrates the ITU-T ORS framework and process.
ing infrastructure to support use of a set of (globally)
distributed resources by requesting entities (e.g., appli-
VI. E VALUATION AND D ISCUSSION
cations). A so-called handle identifies each resource and
can be resolved into the information necessary to locate, A. Evaluation
access, contact, authenticate, and otherwise make use of 1) Offerings: The architecture definitions published by
a given resource. Updates to the latter information (i.e., ETSI and oneM2M offer a basic capacity for the solicited (i.e.,
changes of location, access details, etc.) of a resource pull) and unsolicited (i.e., push) exchange of data among IoT
do not affect its handle, thereby allowing persistence of entities (e.g., sensors, actuators, applications). From an archi-
resource identifiers across updates of resource metadata. tecture standpoint, the ETSI and oneM2M architectures are
The Digital Object Identifier (DOI) system is an interna- aligned to a resource-oriented (i.e., RESTful) model, with the
tional standard [82] that leverages the Handle system for latter being able to also support a service-oriented (i.e., SOA)
name resolution [83]. model. The primary difference between RESTful and SOA lies
• A reference implementation of the set of protocols. not so much in their technological instrumentation, as in the
3) ITU-T X.660: The ITU-T X.660 standard defines a degree of transparency imposed on the IoT application model.
hierarchical tree structure to accommodate the needs of inter- SOA renders the internal arrangement of applications opaque
national object registration authorities [84]. The so-called to external observers, save for the interface used in interacting
Object Identifier (OID) tree is accompanied with proce- with the applications. RESTful, on the other hand, stipulates
dure definitions and guideline recommendations to ensure that the application model is founded on the basis of opera-
its consistency in the face of its simultaneous use by tions (e.g., create, read, update, delete, subscribe, notify, etc.)
multiple independent object registration authorities. Multiple enacted upon resources that are accessible over the Web tech-
representations (i.e., encoding/decoding formats) are defined nology stack. Thus, through transparency, a RESTful approach
for OID information: enforces a degree of compliance to the—admittedly—simple
• Basic Encoding Rules (BER) [85]. model of the Web and its field-proven scalability.
Despite the apparent similarities to the ETSI M2M standard, One possible approach in addressing this shortcoming
the oneM2M standard introduces in addition the option of would be to extend IoT standardization to include architec-
MN-to-MN interfacing, thus being accommodating to a wider tural definitions for QoS, by leveraging existing standards for
range of possible field deployments (e.g., industrial instal- QoS (e.g., IntServ, DiffServ, DiffServ-aware MPLS Traffic
lations spanning a wide geographical area). On the service Engineering, etc.). This would enable M2M/IoT applications
level, the oneM2M architecture can accommodate a mix of to convey their QoS requirements as part of their requests to
paradigms, beyond SOA and RESTful, as it allows for multiple the M2M/IoT platform. However, with the majority of IoT
protocol bindings for each specified interface. entities expected to reside on the edge segment of the end-to-
The TIA SDC architecture offers limited support for flex- end infrastructure (e.g., residential home networks, customer
ible hierarchies in its application and device parts. And premises networks, wireless mobile networks, capillary util-
although a Device Manager element is included in the Smart ity networks, etc.) and the deepest adoption of QoS standards
Device (SD) architecture, traversal of device hierarchies (i.e., being in the core segment of the of the end-to-end infras-
navigating the relationship path between the Device Manager tructure (i.e., aggregation networks, backhaul networks, core
element and individual Device elements) is not within the networks, etc.), the applicability and the suitability of this
scope of TR-50. The same limitation holds respectively for approach are not straightforward.
the Application Server (AS) architecture within the SDC
framework [89]. B. Discussion
2) Adaptation: Most of the IoT and M2M standards (e.g.,
In this section we discuss M2M/IoT standards and highlight
oneM2M, ETSI) acknowledge the importance of adaptation
relevant concerns, from a technical as well as a business and
and convergence to the technological diversification that is
ecosystem perspective. To this end, we classify the M2M/IoT
characteristic of the edge of the infrastructure (i.e., what is cus-
standards (and the relevant architectures) according to their
tomarily known as the last mile). A gateway element subsumes
key features. Table X compares the different features of
these functions and offers interfaces for device management
the M2M standards and architectures along the following
procedures and, optionally, service management operations. It
dimensions:
is commonly understood that gateways will provide hosting
• Maturity refers to the progress/release state of the respec-
capacities for third-party applications and value-added ser-
tive effort.
vices. For instance, the ETSI standard prescribes a 3-tier model
• Layers refers to the (groups of) layers of the Internet
where components of the end-to-end application may reside
protocol stack that are addressed.
at any of the M2M device, the M2M gateway and the M2M
• Segments indicates which parts of the end-to-end infras-
application server.
tructure and its associated functional elements are
The oneM2M model goes even further by defining an N-tier
addressed by the respective effort.
model with an arbitrary number of intermediate nodes capable
• Arrangement refers to the deployment perspective and the
of hosting application components. From the tier perspec-
coordination model supported.
tive, one can clearly identify commonalities among the ETSI,
• Domain lists the supported domains (e.g., Home domain
3GPP and 3GPP2 standards whose primary objective is to
only).
support the efficient communication between M2M entities
• Definitions lists the definitive elements contributed.
and M2M applications. Coupled with peering agreements to
• Style refers to the architecture style supported.
support roaming among (home and foreign) providers, this
• PIM/PSM classifies the platform (in)dependency of the
paradigm has underpinned global cellular communications for
artifacts.
nearly two decades. In contrast, the oneM2M model is strongly
• API indicates whether an API is specified.
aligned to the Web Services model where any number of
• Audience lists the intended audiences of the respective
intermediate Web Services may comprise part of an end-to-end
effort.
interaction, possibly in an completely transparent manner to
• Prototype indicates whether a prototype or a reference
the interaction peers.
framework implementation is provided.
3) Shortcomings: To the exception of OMG DDS, the ser-
vice offered by existing M2M standards provides only coarse
support for Quality of Service (QoS) (i.e., treatment of reli- C. Challenges
ability, reordering, etc.). ETSI and OneM2M prescribes that 1) Object Identification: With size estimates ranging up to
the forwarding of a request may be subject to delay during 50 billion things [90], [91], it is no surprise that IoT introduces
its processing by a CSE, if so indicated by the delay bound significant challenges in object identification. In comparison,
information that is part of the request. An enforceable delay the size of the Internet, after 30 years of development, is esti-
mechanism can support multiple classes of delay; however, it mated to approximately 900 million hosts [92]. Being able to
requires that the design and development of M2M/IoT appli- properly identify an object in IoT, regardless of whether of
cations takes into account delay budget requirements. In the not it resides behind network security mechanisms (e.g., fire-
ETSI M2M standards, support for QoS is subsumed in the walls) and infrastructure hiding instruments (e.g., proxies), is
SAF policy. However, the ETSI standard does not establish by itself a significant challenge. The frequent overloading of
QoS classes at the SAF policy level, thus leaving room for IP addresses with location semantics (i.e., beyond their stan-
incompatible approaches across different M2M domains. dard semantic of a device’s addressable point of attachment
TABLE X
F EATURES OF M2M/I OT S TANDARDS
to a network) further aggravates the challenge. To raise the quality of available data into consideration will become more
bar even higher, in IoT, an object is not restricted to being a and more pressing. However, a capacity for flexible data selec-
network-attached host and may be virtually anything, from a tion (e.g., through an appropriate query language) is not yet
computational process hosted on an M2M gateway to a single included in the standardization agenda of any SDO.
sensor installed on a remote geographical location. 3) Data Transparency: Transparency of the usage of IoT
Object identification on a large scale requires an extensi- Data (ToD) is commonly understood as a major concern
ble identifier format whose administration can be delegated and, for lack thereof, a significant inhibitor of the IoT mar-
to multiple organizations. In turn, this requires establishment ket. With IoT data being solicited from multiple stakeholders
of an international schema for object identifier information with dissimilar privacy requirements, the need for reliable
and standard procedures for the operation of object iden- privacy-supporting mechanisms is clearly identified. What is
tifier registration authorities. Furthermore, mechanisms are particularly needed is a set of global mechanisms to specify
required to enable M2M/IoT applications to query object reg- and enforce the permissible uses and acceptable disclosures
istration authorities with descriptions of objects and retrieve of a particular piece of data across multiple domains. For
identification information for the matching objects. Most instance, patient monitoring data collected by an IoT e-health
importantly, however, the IoT will require a set of simple yet application should not be exposed to other (i.e., unrelated to
efficient mechanisms to map object identifiers across differ- health) domain applications without explicit patient consent,
ent object identification schemes (e.g., ITU-T ASN.1 to/from or, in a format that facilitates the identification of the patient
IETF URI/IRI, etc.). by third parties. From the perspective of the M2M/IoT appli-
2) Data Quality: Quality of Data (QoD) is another signif- cation, prevalence of IoT data is also an important concern
icant concern not yet addressed by M2M or IoT standardiza- that is not yet addressed sufficiently.
tion. In an IoT setting, data can be expected to exhibit signifi- 4) Information Semantics: Though not yet included in the
cant variation in its properties (e.g., volume, velocity, accuracy, M2M and IoT scope of standardization work, the important
etc.). Furthermore, the same piece of data may be available in role of semantic annotation has been identified and discussed
different parts of the quality space (e.g., sensor measurements within ETSI and oneM2M. ETSI has published a technical
may be rendered with varying degrees of accuracy). It is, there- report on semantic support for M2M data [93]. This addresses
fore, reasonable to project that, as the set of available data the importance of providing a common set of enablers to M2M
grows, the need for a data selection process that takes the applications for the discovery, interpretation and use of M2M
data from different sources. In particular, it refers to the short- these reside. For instance, for M2M data relevant to a Smart
comings of the ETSI M2M Release 1 which standardises only Home use case, an abstract model of the environment that
the data container capabilities (i.e., the creation of containers includes M2M devices (e.g., temperature sensors, humidity
and the update of data therein in a standard manner). As a sensors, etc.) and M2M processes (e.g., air quality control,
result, M2M applications are exposed to the intricate techno- etc.) would be necessary.
logical details of their M2M peers (e.g., data formats used Considering that M2M standardisation addresses multiple
by sensors, actions supported by actuators, etc.). This intro- market domains, there will be a need for an open integration
duces additional complexity in designing and developing M2M framework that enables the incorporation of multiple inde-
applications, thus hindering the potential for a global market pendently developed information models (and their associated
for M2M. semantics) in a coherent manner with the least complexity.
The importance of an abstraction layer that factors out the In this direction, the Home Gateway Initiative (HGI) has
details of instrumentation technologies and enables conver- recently published standards for a smart home architecture [99]
gence on the model level has also been proposed and discussed that define a Device Abstraction Layer (DAL). The DAL pro-
during the 4th M2M Workshop organized by ETSI [94]. On vides the means for exposing devices in the home environment
top of the abstraction layer, multiple ontologies (i.e., seman- to M2M applications in a manner that is independent of their
tic descriptions) of M2M entities (e.g., resources, services, and instrumentation technologies (e.g., interaction primitives, pay-
applications) can be then defined based on Semantic Web tech- load formats, etc.). Thus home environment devices (that may
nologies. Introducing such a capacity of semantic annotation be disparate in terms of technologies) can be accessed by M2M
would significantly align the IoT model to the Semantic Web applications without the additional complexity associated to
model and extend the applicability of technology solutions device technologies. Through abstraction the DAL enables
for Linked Open Data (LOD) into the IoT realm. In plain harmonisation in the lifecycle management (i.e., developing,
terms, this would upgrade the vision for what is currently com- deploying, upgrading, retiring, etc.) of M2M applications, thus
monly understood as an “Internet of Things” to the realm of significantly promoting the emergence of a global M2M mar-
the “Internet of Reasonable Things”. The latter signifies the ket. The HGI DAL is also aligned to the device abstraction
capacity for reason (e.g., First Order Logic, Description Logic, support in the OSGi Alliance Release 6 specifications [100].
etc.) as a quintessential property of all things in IoT. Similar efforts, though with yet little or less support
5) Stakeholder Ecosystem: From a market development for semantics, are being advanced by market stakeholders
perspective, fostering innovation in application development (e.g., Apple [101]) and industry consortia (e.g., the Smart
and widespread engagement of key stakeholders are the main Home Device Specification [102] from the Open Interconnect
challenges faced by M2M and IoT standardization. The for- Consortium). These contributions, along with other from par-
mer has been traditionally achieved by means of open API allel industry initiatives, are being currently converged and
specifications combined with a sufficient level of support in harmonised in the oneM2M work for an abstract information
development instruments (e.g., software development kit, inte- model for the home domain [103]. As part of its broader work
grated development environment, tools for validation, testing on abstraction and semantics within the end-to-end system
and integration, end-to-end interoperability testing between architecture, OneM2M is setting the direction for conver-
multiple manufacturers, etc.). In this respect, the approach of gence to multiple solution technologies through a semantics
the Eclipse Foundation and its M2M/IoT ecosystem of devel- adaptation layer [104].
oper enablers is clearly a step in the right direction [95]. 2) Edge Computing and Near-Data Processing:
Initiated by the Laboratory of Analysis and Architecture of Considering that 90% of the world data has been gener-
Systems (LAAS) at the Centre National de la Recherche ated over the last 2 years [105], the introduction of IoT
Scientifique (CNRS), the Eclipse OM2M project is aiming at data sources at a global scale will strengthen challenges
an open source implementation of the oneM2M standard [96]. already faced in the Big Data space. Particularly in regard
Also highly supportive are the ETSI coordination activities in to the typical deployment model, where all the data pro-
the area of interoperability testing of M2M standards that are vided by sensors (i.e., at the edge of the infrastructure) are
regularly hosted as part of the ETSI M2M Workshops [97]. transported to the data center (i.e., at the core of the infras-
tructure) for processing. In a Big Data scenario, conveying the
entire data set across the end-to-end infrastructure becomes
D. Future Directions an unrealistic proposition. Instead, approaches that strive to
1) Information and Semantics: Future versions of M2M colocate data and computations (e.g., Edge Computing [106],
standards include a closer alignment to the WWW architec- Near-Data Processing [107], etc.), present a more viable
ture by addressing the lack of support for semantic information alternative.
under an open world model [98]. This will require the intro- The premise of Edge Computing (EC) is pushing the pro-
duction of capacities for the dynamic discovery and use of cessing of data away from the core of the infrastructure and
semantic information for M2M data, without any prior knowl- towards the latter’s edge, as close to the source of the data
edge of the context (or other relevant details) of the M2M data. as possible, possibly even on the M2M/IoT device itself.
These capacities will have to be complemented by abstract Placing processing close to the data sources is particularly
models of the actual entities referred to by the M2M data beneficial in the case of video, whose transport across the
(e.g., sensors, actuators, etc.) and the environment in which infrastructure can claim considerable network resources, not
TABLE XI
ACRONYMS F OUND IN T HIS PAPER
forgetting the resources required for its storage. It is more In a Big Data setting, the cost of moving data to the
resource-effective to process video information at its source computing facilities is a major concern. Reducing data
and extract all relevant features (e.g., objects, faces, etc.) movement by moving the computation closer to the data is
immediately. an approach known as Near-Data Processing (NDP) [107].
NDP employs specialised hardware collocated to data stor- the area of generic mechanisms for data definition and data
age and supporting specific computational capabilities. As exchanges across different M2M/IoT applications, as well as
increases in CPU performance continue to outpace increases in middleware architectures to enable data-centric M2M/IoT
in memory performance, the resulting shortcomings in the applications. Leveraging the early standardization work on
capacity to scale become significant. In a mature M2M M2M, IoT standardization is now being globally coordinated
and IoT market where billions of devices, applications and at the ITU-T level with rapid progress. As the IoT market
services are engaged in data-driven use cases, being able to develops, interoperability will be a significant factor to the
scale efficiently will be crucial. In this respect, NDP, as a commercial success of IoT products, services and applications.
data-centric paradigm can be expected to impact on future Hence knowledge and understanding of the IoT standardiza-
standardisation in M2M and IoT. tion landscape and the established architectures for IoT will
3) Security and Privacy: IoT data will be inadvertently be essential. To this end, we have presented the state-of-
associated with strong security and privacy concerns. This the-art on M2M and IoT standards in the areas of services,
will hold for multiple domains, e.g., residential, industrial, communication, data and support for M2M/IoT applications.
automotive, health, insurance, etc. There is clearly a need for
a standard end-to-end framework that caters for the secure
execution of M2M functions and IoT applications while also R EFERENCES
enforcing the security and privacy requirements of information [1] SRI Consulting Business Intelligence, “Disruptive civil technolo-
stakeholders. gies: Six technologies with potential impacts on US interests out
to 2025,” Nat. Intell. Council, Washington, DC, USA, Tech. Rep.,
In addition to security considerations from the systems per- Apr. 2008. [Online]. Available: http://www.dni.gov/nic/confreports_
spective, security and privacy concerns relevant to the informa- disruptive_disruptive_tech.html
tion itself (e.g., lineage, provenance, etc.) become significant. [2] “The Internet of Things,” Int. Telecommun. Union,
Geneva, Switzerland, Tech. Rep., 2005. [Online]. Available:
With an increasing number of real world processes being https://www.itu.int/net/wsis/tunis/newsroom/stats/The-Internet-of-
driven from IoT data, supporting root cause investigations over Things-2005.pdf
large data sets will be an everyday requirement. Enforcing [3] L. Atzori, A. Iera, and G. Morabito, “The Internet of Things:
A survey,” Comput. Netw., vol. 54, no. 15, pp. 2787–2805, 2010.
security and ensuring privacy in the interactions among groups [Online]. Available: http://www.sciencedirect.com/science/article/
of IoT entities (e.g., devices, gateways, processes, etc.) is pii/S1389128610001568
another challenge ahead. [4] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami,
“Internet of Things (IoT): A vision, architectural ele-
4) Human Society and Machine Intelligence: From the ments, and future directions,” Future Gener. Comput. Syst.,
societal perspective, IoT can be understood as the doorstep to a vol. 29, no. 7, pp. 1645–1660, 2013. [Online]. Available:
fully digital economy and society. In this context, fully digital http://www.sciencedirect.com/science/article/pii/S0167739X13000241
[5] D. Miorandi, S. Sicari, F. D. Pellegrini, and I. Chlamtac, “Internet
refers to one that is quantified in terms of operational models of Things: Vision, applications and research challenges,” Ad Hoc
that capture the state of things across multiple verticals (e.g., Netw., vol. 10, no. 7, pp. 1497–1516, 2012. [Online]. Available:
global transportation of goods, energy production, distribution http://www.sciencedirect.com/science/article/pii/S1570870512000674
and consumption, health and insurance, etc.) [108]. [6] DG INFSO, “Internet of Things in 2020: A roadmap for the future,
INFSO D.4 networked enterprise & RFID and INFSO G.2 micro
It is commonly understood that human intelligence falls short & nanosystems in co-operation with RFID working group of the
of the computational capacity required to make sense of data- European technology platform on smart systems integration (EPOSS),”
intensive world brought on by the IoT vision and the fully digital Eur. Commission, Brussels, Belgium, Tech. Rep. (ver. 3), 2008.
[Online]. Available: http://www.smart-systems-integration.org/public/
economy and society. Inevitably, the human civilisation will documents/publications/Internet-of-Things_in_2020_EC-EPoSS_
rely increasingly on machine intelligence, initially in typical Workshop_Report_2008_v3.pdf
daily tasks (e.g., autonomous vehicles, etc.) and, eventually, [7] D. Guinard, V. Trifa, F. Mattern, and E. Wilde, “From the
Internet of Things to the Web of Things: Resource-oriented
for its further development. Social concerns suggest that robust architecture and best practices,” in Architecting the Internet of
policy safeguards are embedded as fundamental pillars of the Things, D. Uckelmann, M. Harrison, and F. Michahelles, Eds.
end-to-end technological infrastructure, which will be leveraged Heidelberg, Germany: Springer, 2011, pp. 97–129. [Online]. Available:
http://dx.doi.org/10.1007/978-3-642-19157-2_5
by machine intelligence in the future. This proposition is not [8] ITU-T, Recommendation ITU-T Y.2060, Overview of the Internet of
the product of an irrational bias towards the more pessimistic Things, ITU-T Standard Y.2060, Jun. 2012.
visions of a machine-predominant world, but rather the rational [9] ETSI, TS 102 689; Machine-to-Machine Communications (M2M);
M2M Service Requirements Release 1, ETSI Standard TS 102 689
conclusion of informed work in existential risk [109]. V1.2.1 (2013-06), 2013. [Online]. Available: http://webapp.etsi.org/
workprogram/Report_WorkItem.asp?WKI_ID=37695
[10] ETSI, TS 102 689; Machine-to-Machine Communications (M2M);
VII. C ONCLUSION M2M Service Requirements Release 2, ETSI Standard TS 102 689
V1.1.1 (2010-08), 2013. [Online]. Available: http://webapp.etsi.org/
After several years of experimental research from academia workprogram/Report_WorkItem.asp?WKI_ID=38384
and industry, M2M and IoT are now priorities in standard- [11] “Industry trends for M2M/IoT survey results from the ETSI
ization agendas globally. Coordination among standardisation M2M Workshop 2014,” ETSI, Sophia Antipolis, France, Tech.
Rep., 2014. [Online]. Available: http://docbox.etsi.org/workshop/
organizations is ongoing with little or no overlap observed in 2014/201412_M2MWORKSHOP/INDUSTRY_TRENDSforM2M_
their technical scopes. 3GPP and 3GPP2 are defining support IoT_SURVEY_RESULTS.pdf
for M2M applications accessed over cellular mobile networks [12] TS 102 690; Machine-to-Machine Communications (M2M);
Functional Architecture Release 1, ETSI Standard TS 102 690
while IETF is developing technology solutions at the protocol V1.1.1 (2013-06), 2013. [Online]. Available: http://webapp.etsi.org/
level. OGC, OASIS and OMG have contributed standards in workprogram/Report_WorkItem.asp?WKI_ID=38270
[13] TS 102 690; Machine-to-Machine Communications (M2M); [34] “TR-069; CPE WAN management protocol,” BroadBand Forum (BBF),
Functional Architecture Release 2, ETSI Standard TS 102 690 Fremont, CA, USA, Tech. Rep. TR 069, 2013.
V1.1.1 (2011-10), 2013. [Online]. Available: http://webapp.etsi.org/ [35] “TR-106; data model template for TR-069-enabled devices,”
workprogram/Report_WorkItem.asp?WKI_ID=38271 BroadBand Forum (BBF), Fremont, CA, USA, Tech. Rep. TR 106,
[14] TS 23.887; Study on Machine-Type Communications (MTC) and 2013.
Other Mobile Data Applications Communications Enhancements, 3rd [36] “TR-157; component objects for CWMP,” BroadBand Forum (BBF),
Generation Partnership Project (3GPP) TR 23.887, 2013. Fremont, CA, USA, Tech. Rep. TR 157, 2011.
[15] TS 23.888; System Improvements for Machine-Type [37] “TR-181; device data model for TR-069,” BroadBand Forum (BBF),
Communications (MTC), 3rd Generation Partnership Project (3GPP) Fremont, CA, USA, Tech. Rep. TR 181, 2011.
TR 23.888, 2012. [38] “TR-098; Internet gateway device data model for TR-069,” BroadBand
[16] IEEE Standards Association, IEEE Standard for Local and Forum (BBF), Fremont, CA, USA, Tech. Rep. TR 098, 2008.
Metropolitan Area Networks Part 15.4: Low-Rate Wireless Personal [39] Z. Sheng et al., “A survey on the IETF protocol suite for the Internet
Area Networks (LR-WPANs), IEEE Standard 802.15.4-2011, Sep. 2011. of Things: Standards, challenges, and opportunities,” IEEE Wireless
[17] oneM2M Partners. (Jul. 2012). oneM2M Partnership Commun., vol. 20, no. 6, pp. 91–98, Dec. 2013.
Agreement. Accessed on Feb. 10, 2014. [Online]. Available: [40] M. R. Palattella et al., “Standardized protocol stack for the Internet
http://www.onem2m.org/ docs/oneM2M_Partnership_Agreement.pdf of (important) Things,” IEEE Commun. Surveys Tuts., vol. 15, no. 3,
[18] oneM2M. (Aug. 2014). oneM2M Functional Architecture Baseline pp. 1389–1406, 3rd Quart. 2013.
Draft. [Online]. Available: http://www.onem2m.org/images/files/ [41] S. L. Keoh, S. S. Kumar, and H. Tschofenig, “Securing the Internet of
deliverables/TS-0001-oneM2M-Functional-Architecture-V-2014-08.pdf Things: A standardization perspective,” IEEE Internet Things J., vol. 1,
[19] (2011). Sensor Web Enablement Architecture. Open Geospatial no. 3, pp. 265–275, Jun. 2014.
Consortium, Wayland, MA, USA. [Online]. Available: [42] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and
https://portal.opengeospatial.org/files/?artifact_id=48492 M. Ayyash, “Internet of Things: A survey on enabling technologies,
[20] (2011). Observations and Measurements. Open Geospatial protocols, and applications,” IEEE Commun. Surveys Tuts., vol. 17,
Consortium, Wayland, MA, USA. [Online]. Available: no. 4, pp. 2347–2376, 4th Quart. 2015.
http://www.opengeospatial.org/standards [43] ITU-T, Focus Group on M2M Service Layer, ITU-T Standard.
[21] (2011). Observations and Measurements—XML Implementation. Open [Online]. Available: http://www.itu.int/en/ITU-T/focusgroups/m2m/
Geospatial Consortium, Wayland, MA, USA. [Online]. Available: Pages/default.aspx
http://www.opengeospatial.org/standards
[44] ITU-T, Deliverable 2.1: M2M Service Layer: Requirements and
[22] (2011). Sensor Model Language (SensorML). Open Geospatial Architectural Framework, ITU-T Standard, 2014. [Online]. Available:
Consortium, Wayland, MA, USA. [Online]. Available: http://www.itu.int/pub/T-FG-M2M-2014-D2.1/en
[45] ITU-T, Deliverable 3.1: M2M Service Layer: APIs and
[23] (2011). Sensor Observation Service. Open Geospatial
Protocols Overview, ITU-T Standard, 2014. [Online]. Available:
Consortium, Wayland, MA, USA. [Online]. Available:
http://www.itu.int/pub/T-FG-M2M-2014-D3.1
[24] (2011). Sensor Planning Service. Open Geospatial
mIa, dIa and mId Interfaces Release 1, ETSI Standard TS 102 921
Consortium, Wayland, MA, USA. [Online]. Available:
[25] IEEE Standards Association, IEEE Standard for Information
Technology Telecommunications and Information Exchange Between
mIa, dIa and mId Interfaces Release 2, ETSI Standard TS 102 921
Systems-Local and Metropolitan Area Networks Specific Requirements
Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications Amendment 1: Radio Resource
Measurement of Wireless LANs, IEEE Standard 802.11-2007, [48] Z. Shelby, K. Hartke, and C. Bormann, “The constrained
Jun. 2008. application protocol (CoAP),” Internet Eng. Task Force,
[26] IEEE Standards Association, IEEE Standard for Information Fremont, CA, USA, RFC 7252, Jun. 2014. [Online]. Available:
Technology Telecommunications and Information Exchange Between http://www.ietf.org/rfc/rfc7252.txt
Systems Local and Metropolitan Area Networks Specific Requirements [49] oneM2M Partners. (Jan. 2014). oneM2M Homepage. Accessed on
Part 11: Wireless Lan Medium Access Control (MAC) and Physical Feb. 10, 2014. [Online]. Available: http://www.onem2m.org/index.cfm
Layer (PHY) Specifications, IEEE Standard 802.11-2012, 2007. [50] oneM2M Partners. (Oct. 2013). Services and/or Resources for the
[Online]. Available: http://standards.ieee.org/getieee802/download/ oneM2M Architecture. Accessed on Feb. 5, 2014. [Online]. Available:
802.11-2007.pdf ftp://ftp.onem2m.org/Meetings/ARC/2013%20meetings/20131014_
[27] TS 22.368; Service Requirements for Machine-Type Communications ARC7.0_Sophia%20Antipolis/oneM2M-ARC-2013-0477R01-
(MTC); Stage 1, 3rd Generation Partnership Project (3GPP) TS 22.368, Services_and_or_Resources_for_the_Architecture.PPT
2011. [51] MQTT Version 3.1.1 Plus Errata 01, OASIS Stand.,
[28] TS 29.368; TSP Interface Protocol Between the MTC Interworking Burlington, MA, USA, 2015. [Online]. Available:
Function (MTC-IWF) and Service Capability Server (SCS), 3rd http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
Generation Partnership Project (3GPP) TS 29.368, 2011. [52] I. Fette and A. Melnikov, “The WebSocket protocol,” Internet Eng. Task
[29] X.P0067-0; Machine to Machine (M2M) Architecture and Force, Fremont, CA, USA, RFC 6455, Dec. 2011. [Online]. Available:
Enhancements Study for CDMA2000 Networks, 3rd Generation http://www.ietf.org/rfc/rfc6455.txt
Partnership Project 2 (3GPP2) TR X.P0067-0, 2012. [53] TIA, TIA-4940.005: Smart Device Communications Reference
[30] X.S0068-X; cdma2000 Network Enhancements for M2M, 3rd Architecture, TIA Standard Tia-4940.005, 2012. [Online]. Available:
Generation Partnership Project 2 (3GPP2) TR X.S0068-X, 2012. http://global.ihs.com/search_res.cfm?RID=TIA&INPUT_DOC_
[Online]. Available: ftp://ftp.3gpp2.org/TSGSX/Working/2013/ NUMBER=TIA-4940
2013-12-Kauai/TSG-SX-2013-12-Kauai/WG3/ [54] Assessments and Recommendations, ATIS Stand., Washington, DC,
[31] S.R0141-0; Study for Machine-to-Machine (M2M) Communication for USA, 2013. [Online]. Available: http://atis.org/M2M/index.asp
CDMA2000 Networks, 3rd Generation Partnership Project 2 (3GPP2) [55] TS 22.060; General Packet Radio Service (GPRS); Service
TR S.R0141-0, 2010. Description; Stage 1, 3rd Gener. Partnership Project (3GPP)
[32] OMA Device Management V1.2, Open Mobile Alliance TS 22.060, 2008. [Online]. Available: http://www.3gpp.org/ftp/
Stand., San Diego, CA, USA, 2013. [Online]. Available: Specs/html-info/22060.htm
http://technical.openmobilealliance.org/Technical/technical- [56] TS 23.060; General Packet Radio Service (GPRS); Service
information/release-program/current-releases/dm-v1-2 Description; Stage 2, 3rd Gener. Partnership Project (3GPP)
[33] OMA Gateway Management Object (GwMO) Architecture, Open TS 23.060, 2008. [Online]. Available: http://www.3gpp.org/
Mobile Alliance Stand., San Diego, CA, USA, 2013. [Online]. ftp/Specs/html-info/23060.htm
Available: http://technical.openmobilealliance.org/Technical/release_ [57] R. Sun, B. Greevenbosch, and D. He, Comparison of Different
program/docs/CopyrightClick.aspx?pck=GwMO&file=V1_1- Proposals for ACE, Working Draft, IETF Secretariat Internet-Draft,
20130625-C/OMA-AD-GwMO-V1_1-20130625-C.pdf draft-greevenbosch-ace-comparison-01.txt, Sep. 2014.
[58] R. Sanchez and R. Marin, EAP-Based Authentication Service for CoAP, [81] S. Sun, S. Reilly, and L. Lannom, “Handle system namespace
Working Draft, IETF Secretariat Internet-Draft, draft-marin-ace-wg- and service definition,” Internet Eng. Task Force, Fremont,
coap-eap-01.txt, Oct. 2014. CA, USA, RFC 3651, Nov. 2003. [Online]. Available:
[59] B. Stiller, C. Schmitt, T. Kothmayr, and H. Wu, Two-Way http://www.ietf.org/rfc/rfc3651.txt
Authentication for IoT, Working Draft, IETF Secretariat Internet-Draft, [82] ISO 26324:2012 Information and Documentation—Digital Object
draft-schmitt-ace-twowayauth-for-iot-01.txt, Dec. 2014. Identifier System, Int. Organization Standardization Stand. ISO
[60] D. Hardt, “The OAuth 2.0 authorization framework,” Internet Eng. Task 26324:2012, Geneva, Switzerland, 2012. [Online]. Available:
Force, Fremont, CA, USA, RFC 6749, Oct. 2012. [Online]. Available: http://www.iso.org/iso/catalogue_detail?csnumber=43506
http://www.ietf.org/rfc/rfc6749.txt [83] DOI Handbook, Int. DOI Found., Wilmington, DE, USA, 2012.
[61] E. Wahlstroem, OAuth 2.0 Introspection over the Constrained [84] ITU-T, OSI Networking and System Aspects—Naming, Addressing
Application Protocol (CoAP), Working Draft, IETF Secretariat and Registration; Information Technology—Procedures for
Internet-Draft, draft-wahlstroem-ace-oauth-introspection-00.txt, the Operation of Object Identifier Registration Authorities:
Oct. 2014. General Procedures and Top Arcs of the International Object
[62] P. Thubert, “Objective function zero for the routing protocol for Identifier Tree, ITU-T Standard X.660, 2011. [Online]. Available:
low-power and lossy networks (RPL),” Internet Eng. Task Force, http://www.itu.int/rec/T-REC-X.660-201107-I
Fremont, CA, USA, RFC 6552, Mar. 2012. [Online]. Available: [85] ITU-T, OSI Networking and System Aspects—OSI Networking and
http://www.ietf.org/rfc/rfc6552.txt System Aspects—Abstract Syntax Notation One (ASN.1)—Information
Technology—ASN.1 Encoding Rules: Specification of Basic Encoding
[63] P. Levis, T. Clausen, J. Hui, O. Gnawali, and J. Ko, “The trickle
Rules (BER), Canonical Encoding Rules (CER) and Distinguished
algorithm,” Internet Eng. Task Force, Fremont, CA, USA, RFC 6206,
Encoding Rules (DER), ITU-T Standard X.690, 2015. [Online].
Mar. 2011.
Available: http://www.itu.int/rec/T-REC-X.690-200811-I
[64] J. Hui and P. Thubert, “Compression format for IPv6 datagrams
[86] ITU-T, OSI Networking and System Aspects—OSI Networking and
over IEEE 802.15.4-based networks,” Internet Eng. Task Force,
System Aspects—Abstract Syntax Notation One (ASN.1)—Information
Fremont, CA, USA, RFC 6282, Sep. 2011. [Online]. Available:
Technology—ASN.1 Encoding Rules: Specification of Packed Encoding
http://www.ietf.org/rfc/rfc6282.txt
Rules (PER), ITU-T Standard X.691, 2015. [Online]. Available:
[65] J. Ziv and A. Lempel, “A universal algorithm for sequential data http://www.itu.int/rec/T-REC-X.691-200811-I
compression,” IEEE Trans. Inf. Theory, vol. 23, no. 3, pp. 337–343, [87] ITU-T, OSI Networking and System Aspects—OSI Networking
May 1977. and System Aspects—Abstract Syntax Notation One (ASN.1)—
[66] T. Dierks and E. Rescorla, “The transport layer security (TLS) protocol Information Technology—ASN.1 Encoding Rules: XML Encoding
version 1.2,” Internet Eng. Task Force, Fremont, CA, USA, RFC 5246, Rules (XER), ITU-T Standard X.693, 2015. [Online]. Available:
Aug. 2008. [Online]. Available: http://www.ietf.org/rfc/rfc5246.txt http://www.itu.int/rec/T-REC-X.693-200811-I
[67] E. Rescorla and N. Modadugu, “Datagram transport layer security ver- [88] ITU-T, OSI Networking and System Aspects—Naming,
sion 1.2,” Internet Eng. Task Force, Fremont, CA, USA, RFC 6347, Addressing and Registration; Information Technology—
Jan. 2012. [Online]. Available: http://www.ietf.org/rfc/rfc6347.txt Open Systems Interconnection—Object Identifier Resolution
[68] N. Kang, S. Jung, S. Jung, J. Choi, and G. Lee, Fine-Grained Support System, ITU-T Standard X.672. 2010. [Online]. Available:
of Security Services for Constrained Devices Using DTLS, Working http://www.itu.int/rec/T-REC-X.672-201008-I
Draft, IETF Secretariat Internet-Draft, draft-choi-dice-finegrained-dtls- [89] “Presentation of TIA TR-50 smart device com-
security-00.txt, Oct. 2014. munications (SDC) at oneM2M,” TIA, Arlington,
[69] O. Garcia-Morchon, S. Kumar, and S. Keoh, DTLS Relay for VA, USA, Tech. Rep., 2013. [Online]. Available:
Constrained Environments, Working Draft, IETF Secretariat Internet- http://ftp.tiaonline.org/tr-50/public/Joint_TR-50_ETSI_TC_M2M/
Draft, draft-kumar-dice-dtls-relay-02.txt, Oct. 2014. 20110321_Joint_TR-50_ETSI_TC_M2M/TR50_ETSI-20110321-006_
[70] B. Carpenter and S. Brim, “Middleboxes: Taxonomy and issues,” TR501_Presentation.pdf
Internet Eng. Task Force, RFC 3234, Fremont, CA, USA, Feb. 2002. [90] “The Internet of Things,” Cisco, San Jose, CA, USA, Tech.
[Online]. Available: http://www.ietf.org/rfc/rfc3234.txt Rep., 2013. [Online]. Available: http://www.cisco.com/c/
[71] Standard for an Architectural Framework for the Internet of dam/en_us/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf
Things (IoT), IEEE Standard P2413, 2014. [Online]. Available: [91] “More than 50 billion connected devices,” Ericsson, Stockholm,
http://grouper.ieee.org/groups/2413/Intro-to-IEEE-P2413.pdf Sweden, Tech. Rep., 2013. [Online]. Available: https://
[72] I. TAG, IEEE 802.24 Vertical Applications TAG, IEEE Standard 802.24, www.ericsson.com/openarticle/mwc-connected-devices_1686565587_c
2014. [Online]. Available: http://www.ieee802.org/24/ [92] Internet Census 2012. Accessed on Jul. 25, 2016. [Online]. Available:
[73] M. Compton et al., “The SSN ontology of the W3C semantic sen- http://internetcensus2012.bitbucket.org/tld_overview.html
sor network incubator group,” Web Semant. Sci. Services Agents [93] ETSI, TR 101 584; Machine-to-Machine Communications (M2M);
World Wide Web, vol. 17, pp. 25–32, Dec. 2012. [Online]. Available: Study on Semantic Support for M2M Data, ETSI Standard TR 101
http://www.sciencedirect.com/science/article/pii/S1570826812000571 584 V2.1.1 (2013-12), 2013.
[94] M2M Workshop 2013, ETSI, Sophia Antipolis, France.
[74] Extensible Resource Identifier (XRI) Version 2.0, OASIS
[Online]. Available: http://www.etsi.org/news-events/events/
Stand., Burlington, MA, USA, 2005. [Online]. Available:
666-2013-m2mworkshop
http://docs.oasis-open.org/xri/xri/V2.0/xri-syntax-V2.0-cd-01.pdf
[95] The Eclipse Portal for IoT. Accessed on Jul. 25, 2016. [Online].
[75] Extensible Resource Descriptor (XRD) Version 1.0, OASIS
Available: http://iot.eclipse.org/
Stand., Burlington, MA, USA, 2010. [Online]. Available:
[96] The Eclipse OM2M Project. Accessed on Jul. 25, 2016. [Online].
http://docs.oasis-open.org/xri/xrd/v1.0/cd02/xrd-1.0-cd02.html
Available: http://www.eclipse.org/om2m/
[76] T. Berners-Lee, R. Fielding, and L. Masinter, “Uniform resource [97] The ETSI Plugfests Event Series. Accessed on
identifier (URI): Generic syntax,” Internet Eng. Task Force, Jul. 25, 2016. [Online]. Available: http://www.etsi.org/about/
Fremont, CA, USA, RFC 3986, Jan. 2005. [Online]. Available: what-we-do/plugtests/calendar-of-events
http://www.ietf.org/rfc/rfc3986.txt [98] Architecture of the World Wide Web, Volume One, World Wide Web
[77] M. Duerst and M. Suignard, “Internationalized resource identi- Consortium (W3C) Stand., Cambridge, MA, USA, 2004. [Online].
fiers (IRIs),” Internet Eng. Task Force, Fremont, CA, USA, RFC 3987, Available: https://www.w3.org/TR/webarch/
Jan. 2005. [Online]. Available: http://www.ietf.org/rfc/rfc3987.txt [99] Smart Home Architecture and Requirements, Home
[78] Extensible Resource Identifier (XRI) Resolution Version 2.0, Gateway Initiative (HGI) Stand., 2015. [Online]. Available:
OASIS Stand., Burlington, MA, USA, 2008. [Online]. Available: http://www.homegatewayinitiative.org/downloads.aspx
http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cd03/xri- [100] OSGi Release 6 Specifications, OSGi Alliance Stand., San
resolution-V2.0-cd-03.pdf Ramon, CA, USA, 2014. [Online]. Available: https://www.osgi.org/
[79] Data Distribution Service (DDS), Object Management developer/specifications/
Group TS, Needham, MA, USA, 2005. [Online]. Available: [101] “HomeKit developer reference,” Apple, Cupertino, CA, USA, Tech.
http://www.omg.org/spec/DDS/ Rep., 2014. [Online]. Available: https://developer.apple.com/homekit/
[80] S. Sun, L. Lannom, and B. Boesch, “Handle system overview,” Internet [102] Smart Home Device Specification, Open Interconnect
Eng. Task Force, Fremont, CA, USA, RFC 3650, Nov. 2003. [Online]. Consortium (OIC) Stand., 2015. [Online]. Available:
Available: http://www.ietf.org/rfc/rfc3650.txt https://openconnectivity.org/resources/specifications
[103] Home Domain Abstract Information Model, Vangelis Gazis received the B.Sc., M.Sc., and Ph.D. degrees from the
oneM2M Partners, Nov. 2015. [Online]. Available: Department of Informatics and Telecommunications, University of Athens,
http://ftp.onem2m.org/Work%20Programme/WI-0017/TR-0017-Home_ and the M.B.A. degree from the Athens University of Economics and
Domain_Abstract_Information_Model-V1_0_1.ZIP Business. He currently leads the Big Data practice for Cognizant, Germany.
[104] Study on Abstraction and Semantics Enablers. OneM2M Previously he was the Lead IoT Scientist with AGT International, Darmstadt,
Global Partnership Stand., Jan. 2016. [Online]. Available: Germany, where he acted as a Standardisation Liaison and an Executive
http://ftp.onem2m.org/Work%20Programme/WI-0005/WI-0005- Advisor in the Machine-to-Machine and Internet of Things areas. He served
Abstraction_&_Semantics_Capab as an Adjunct Associate Professor with the School of Electronic and
[105] Big Data, for Better or Worse: 90% of World’s Data Computer Engineering, Technical University of Crete, and as a Lecturer
Generated Over Last Two Years. (2013). [Online]. Available: with the Department of Information & Communication Systems Engineering,
https://www.sciencedaily.com/releases/2013/05/130522085217.htm University of the Aegean. He was with the Communication Networks
[106] R. LaMothe. (2013). Edge Computing. [Online]. Available: Laboratory Group, Department of Informatics and Telecommunications, where
http://vis.pnnl.gov/pdf/fliers/EdgeComputing.pdf he participated in National (OTE-DECT, GRNET, GUNet) and European IST
[107] R. Balasubramonian et al., “Near-data processing: Insights from Projects (MOBIVAS, ANWIRE, GEANT-2, E2R, SELFNET). His profes-
a MICRO-46 workshop,” IEEE Micro, vol. 34, no. 4, pp. 36–42, sional interest lies at the intersection of Big Data, Machine-to-Machine com-
Jul./Aug. 2014. munications, and the Internet of Things. His technical interest and expertise
[108] The Digital Single Market, Eur. Commission, Brussels, Belgium. include mobile service platforms, reconfigurable mobile networks, cross-layer
[Online]. Available: https://ec.europa.eu/digital-single-market/ design, adaptable protocol stacks, ontology languages for autonomic systems,
[109] N. Bostrom, Superintelligence: Paths, Dangers, Strategies, 1st ed. and self-managing cognitive systems. He has over 60 publications in the
Oxford, U.K.: Oxford Univ. Press, 2014. above areas.

07516570

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

07516570

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

07516570

Uploaded by

Copyright:

Available Formats

482 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 19, NO.

1, FIRST QUARTER 2017

A Survey of Standards for Machine-to-Machine

Fig. 2. ITU-T standardisation activities on IoT.

gateways, etc.). The ETSI M2M standard provides applica-

field-specific networking technology (e.g., Power

Fig. 6. Request handling in the ETSI M2M.

all potential access networks (e.g., including access networks

Fig. 8. The possible configurations of the oneM2M system [18].

Fig. 10. The oneM2M CSE structure [18].

Fig. 9 provides an illustrative example for a oneM2M

III. S TANDARDS —C OMMUNICATIONS

Fig. 12. The 3GPP M2M architecture.

C. Internet Engineering Task Force (IETF)

The DTLS stateful mode preserves the end-to-end DTLS

Fig. 13. Operation modes of DTLS Relay.

data anonymously and asynchronously, decoupled in space

The GS1 Global Data Synchronisation Network (GDSN)

You might also like