Module-2

IOT ARCHITECTURE-STATE OF THE ART & ARCHITECTURE REFERENCE MODEL

IOT ARCHITECTURE-STATE OF THE ART
Introduction
A reference model is a model that describes the main conceptual entities and how they are related to each
other, while the reference architecture aims at describing the main functional components of a system as well as how
the system works, how the system is deployed, what information the system processes, etc.
An Architecture Reference Model (ARM) is useful as a tool that establishes a common language across all the
possible stakeholders of an M2M or IoT system.
State of the art
Several Reference Architectures and Models exist both for M2M and IoT systems. We choose to present the
four most popular ones as follows.
European Telecommunications Standards Institute M2M/oneM2M:
The European Telecommunications Standards Institute (ETSI) in 2009 formed a Technical Committee (TC) on
M2M topics aimed at producing a set of standards for communication among machines from an end- to-end viewpoint.
ETSI M2M produced the first release of the M2M standards in early 2012, while in the middle of 2012 seven
of the leading Information and Communications Technology (ICT) standards organizations formed a global
organization called oneM2M Partnership Project (oneM2M) in order to develop M2M specifications, promote the
M2M business, and ensure the global functionality of M2M systems.
ETSI M2M high-level architecture
Figure shows the high-level ETSI M2M architecture. This high-level architecture is a combination of both a
functional and topological view showing some functional groups (FG) clearly associated with pieces of physical
infrastructure (e.g. M2M Devices, Gateways) while other functional groups lack specific topological placement. There
are two main domains, 1) a network domain 2) a device and gateway domain.
1) The Device and Gateway Domain contains the following functional/ topological entities:
M2M Device:
An M2M device connects to the Network Domain either directly or through an M2M Gateway
Direct connection:
The M2M Device is capable of performing registration, authentication, authorization, management, and provisioning
to the Network Domain. Direct connection also means that the M2M device contains the appropriate physical layer to
be able to communicate with the Access Network.
M2M Gateway:
The device that provides connectivity for M2M Devices in an M2M Area Network towards the Network Domain. The
M2M Gateway contains M2M Applications and M2M Service Capabilities.
Through one or more M2M Gateway:
This is the case when the M2M device does not have the appropriate physical layer, compatible with the
Access Network technology, and therefore it needs a network domain proxy. The M2M Gateway acts as a proxy for
the Network Domain and performs the procedures of authentication, authorization, management, and provisioning. An
M2M Device could connect through multiple M2M Gateways.
 The M2M Gateway contains M2M Applications and M2M Service Capabilities.
 The M2M Gateway may also provide services to other legacy devices that are not visible to the Network Domain.
 The device that provides connectivity for M2M Devices in an M2M Area Network towards the Network Domain.
M2M Area Network:
This is typically a local area network (LAN) or a Personal Area Network (PAN) and provides connectivity
between M2M Devices and M2M Gateways.

2) The Network Domain contains the following functional/topological entities:

Access Network:
This is the network that allows the devices in the Device and Gateway Domain to communicate with the Core network.
Core Network
It provides the following functions:
 IP connectivity.
 Service and Network control.
 Interconnection with other networks.
 Roaming.
M2M Service Capabilities:
These are functions exposed to different M2M Applications through a set of open interfaces. These functions
use underlying Core Network functions, and their objective is to abstract the network functions for the sake of simpler
applications.
M2M Applications:
These are the specific M2M applications (e.g. smart metering) that utilize the M2M Service Capabilities
through the open interfaces.
Network Management Functions:
These are all the necessary functions to manage the Access and Core Network.
M2M Management Functions:
These are the necessary functions required to manage the M2M Service Capabilities on the Network Domain
while the management of an M2M Device or Gateway is performed by specific M2M Service Capabilities.

There are two M2M Management functions,

1) M2M Service Bootstrap Function (MSBF):
The MSBF facilitates the bootstrapping of permanent M2M service layer security credentials in the M2M
Device or Gateway and the M2M Service Capabilities in the Network Domain.
2) M2M Authentication Server (MAS):
This is the safe execution environment where permanent security credentials such as the M2M Root Key are stored.
Any security credentials established on the M2M Device or Gateway are stored in a secure environment such
as a trusted platform module.
The most relevant entities in the ETSI M2M architecture are the M2M Nodes and M2M Applications. An
M2M Node can be a Device M2M, Gateway M2M, or Network M2M Node (Figure).

An M2M Application is the main application logic that uses the Service Capabilities to achieve the M2M system
requirements. The application logic can be deployed on a Device (Device Application, DA), Gateway (Gateway
Application, GA) or Network (Network Application, NA). The Service Capabilities Layer (SCL) is a collection of
functions that are exposed through the open interfaces or reference points mIa, dIa, and mId. Because the main
topological entities that SCL can deploy are the Device, Gateway, and Network Domain,
There are three types of SCL:
1. DSCL (Device Service Capabilities Layer)
2. GSCL (Gateway Service Capabilities Layer)
3. NSCL (Network Service Capabilities Layer).
The ETSI M2M Service Capabilities are recommendations of functional groups for building SCLs, but their
implementation is not mandatory, while the implementation of the interfaces mIa, dIa, and mId is mandatory for a
compliant system. It is worth repeating that from the point of view of the ETSI M2M architecture, an M2M device can
be either capable of supporting the mId interface (towards the NSCL) or the dIa interface (towards the GSCL).
ETSI M2M Service Capabilities
All the possible Service Capabilities (where “x” is N(etwork), G(ateway), and D(evice)) are shown in Figure:
Application Enablement (xAE)
The xAE service capability is an application facing functionality and typically provides the implementation of
the respective interface: NAE implements the mIa interface and the GAE and DAE implement the dIa interface. The
xAE includes registration of applications (xA) to the respective xSCL. In certain configurations xAE enables xAs to
exchange messages to each other. In certain configurations security operations such as authentication and authorization
of applications is also performed by xAE.
Generic Communication (xGC)
The NGC is the single point of contact for communication towards the GSCL and DSCL. It provides transport
session establishment and negotiation of security mechanisms, potentially secure transmission of messages, and
reporting of errors such as transmission errors. The GSC performs a few more functions such as relaying of messages
to/from NSCL from/to other SCs in the GSCL, and handles name resolution for the requests with the M2M Area
Network.

Reachability, Addressing, and Repository (xRAR):

The NRAR hosts mappings of M2M Device and Gateway names to Reachability information, and scheduling
information relating to Reachability. It provides group management (creation/update/deletion) for groups of M2M
Devices and Gateways, stores application data. The GRAR provides similar functionality to the NRAR, such as
maintaining mappings of the names of M2M Devices. Similar to NRAR and GRAR, the DRAR stores DA, GA, NA,
DSCL, and NSCL data and manages subscriptions about these data, stores DA registration and NSCL information,
provides group management for groups of M2M Devices and event management.
Communication Selection (xCS):
This capability allows each xSCL to select the best possible communication network when there is more than
one choice or when the current choice becomes unavailable due to communication errors. The NCS provides such a
selection mechanism based on policies for reaching an M2M Device or Gateway, while the GCS/DCS provides a
similar selection mechanism for reaching the NSCL.
Remote Entity Management (xREM):
 The NREM provides management capabilities such as Configuration Management (CM) for M2M Devices
and Gateways (e.g. installs management objects in device and gateways), collects performance management (PM) and
Fault Management (FM) data and provides them to NAs. The GREM acts as a management client for performing
management operations to devices using the DREM and a remote proxy for NREM to perform management operations
to M2M Devices in the M2M Area Network. The DREM provides the CM, PM, and FM counterpart on the device
(e.g. start collecting radio link performance data) and provides the device side software and firmware update support.
Security (xSEC):
These capabilities provide security mechanisms such as M2M Service Bootstrap, key management, mutual
authentication, and key agreement and potential platform integrity mechanisms.
History and Data Retention (xHDR):
The xHDR capabilities are optional capabilities, in other words, they are deployed when required by operator policies.
Transaction Management (xTM):
This set of capabilities is optional and provides support for atomic transactions of operations.
An atomic transaction involves three steps:
a. Propagation of a request to a number of recipients
b. Collection of responses
c. Commitment or roll back whether all the transactions successfully completed or not
Compensation Broker (xCB):
This capability is optional and provides support for brokering M2M-related requests and compensation between a
Customer and a Service Provider. Telco Operator Exposure (NTOE).This is also an optional capability and provides
exposure of the Core Network service offered by a Telecom Network Operator.
Interworking Proxy (xIP):
This capability is an optional capability and provides mechanisms for connecting non- ETSI M2M Devices and
Gateways to ETSI SCLs.

ETSI M2M interfaces

The main interfaces mIa, dIa, and mId (ETSI M2M TC 2013b) can be briefly described as follows:
mIa:
This is the interface between a Network Application and the Network Service Capabilities Layer (NSCL). The
procedures supported by this interface are registration of a Network Application to the NSCL, request to read/write
information to NSCL, GSCL, or DSCL, request for device management actions , subscription and notification of
specific events.
dIa:
This is the interface between a Device Application and (D/G)SCL or a Gateway Application and the GSCL. The
procedures supported by this interface are registration of a Device/Gateway Application to the GSCL, registration of a
Device Application to the DSCL, request to read/write information to NSCL, GSCL, or DSCL, subscription and
notification of specific events.
mId:
This is the interface between the Network Service Capabilities Layer (NSCL) and the GSCL or the DSCL. The
procedures supported by this interface are (among others) registration of a Device/Gateway SCL to the NSCL, request
to read/write information to NSCL, GSCL, or DSCL, subscription and notification of specific events.
ETSI M2M resource management
The ETSI M2M architecture assumes that applications (DA, GA, NA) exchange information with SCLs by performing
CRUD (Create, Read, Update, Delete) operations on a number of Resources following the RESTful (Representational
State Transfer) architecture paradigm. In addition to the CRUD operations, ETSI M2M defines two more operations:
NOTIFY and EXECUTE.
 The NOTIFY operation is triggered upon a change in the representation of a resource, and results in a notification
sent to the entity that originally subscribed to monitor changes to the resource in question.
 The EXECUTE operation is not orthogonal as well, but can be implemented by an UPDATE operation with no
parameters from the requesting entity to a specific resource. When a requesting entity issues an EXECUTE
operation towards a specific resource, the specific resource executes a specific task.
The following examples in Figure demonstrates how an ETSI M2M entity communicates with another entity
using the CRUD and NOTIFY operations. Assume that a device application (DA) is programmed to send a sensor

measurement to a network application (NA). The DA using the DSCL updates the representation of a specific resource
(Ra) residing on the NSCL (steps 1 and 2 in Figure). The NA has configured the NSCL to be notified when the
specific resource is updated, in which case the NA reads the updated representation (steps 4 and 5, Figure).

The top-level structure of the, <sclBase> resource is shown in Figure. The different fonts used in this figure
denote different information semantics. A term between the symbols, ‘’ < ” and “ > ” denotes an arbitrary resource
name; for example, <sclBase> in Figure. A term within quotes (“”) denotes a placeholder for one or more fixed names.
In this specific case, “attribute” represents a member of a fixed list of attributes for the resource, <sclBase>.