IoT Architecture -State of the Art

Reference model:
Model that describes the main conceptual entities and how
they are related to each other
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 ARM is useful as a tool that establishes a common language of an M2M or

IoT system.

State of the art: Several Reference Architectures and Models exist both for
M2M and IoT systems.
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
ETSI M2M high-level architecture

High-level ETSI M2M

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,
a network domain and a
device and gateway
domain.
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.
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.
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
M2M Gateway:
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.

Access Network:
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:

Functions use underlying Core Network functions, and their objective is to abstract the
network functions for simpler applications.
M2M Applications:
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:

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:
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.
M2M Authentication Server (MAS):
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.
M2M Service Capabilities, M2M Nodes and Open Interfaces

The application logic can be deployed on a Device (Device Application, DA), Gateway
(Gateway Application, GA) or Network (Network Application, NA).
The SCL is a collection of functions that are exposed through the open interfaces. 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.

ETSI M2M Service Capabilities

All the possible Service Capabilities (where “x” is N(etwork), G(ateway), and
D(evice))

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.
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), 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 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)

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.

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 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.
Example:

Communication Between DA and NA Using the SCLs.

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).
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).
International Telecommunication Union _ Telecommunication sector view
The ITU-T IoT domain model includes a set of physical devices that connect
directly or through gateway devices to a communication network that allows
them to exchange information with other devices, services, and applications.
The devices in this model include mandatory communication capabilities and
optional sensing, actuation, and processing capabilities in order to capture
and transport information about the things.

ITU-T IoT reference Model

 The Application Layer the ITU-T IoT model considers this layer as the
host of specific IoT applications

 The Service & Application Support Layer consists of generic service

capabilities used by all IoT applications, such as data processing and data
storage, and specific service capabilities tailored to specific application
domains, such as e-health or telematics.

 The Network Layer provides networking capabilities such as Mobility

Management, Authentication, Authorization, and Accounting (AAA), and
Transport Capabilities such as connectivity for IoT service data.

 The Device Layer includes Device Capabilities and Gateway Capabilities.

 The Device Capabilities include, among others, the direct device interaction
with the communication network and therefore the Network Layer
Capabilities, the indirect interaction with the Network Layer Capabilities
through Gateway Devices, any ad hoc networking capabilities, as well as
low-power operation capabilities that affect communications.
 The Gateway Device Capabilities include multiple protocol support and
protocol conversion in order to bridge the Network Layer capabilities and
the device communication capabilities.

 In terms of Management Capabilities, these include the typical FCAPS

(Fault, Configuration, Accounting, Performance, Security) model of
capabilities as well as device management, network topology management
and traffic management. Specific management functionality related to a
specific application domain is also included among the Management
Capabilities.

 With respect to the Security Capabilities, this layer represents a grouping

of different Security Capabilities required by other layers. The capabilities
are grouped generically, such as AAA and message
integrity/confidentiality support, and specifically, such as ones that are
tailored to the specific application, e.g. mobile payment.
Reference model and architecture
An ARM consists of two main parts: a Reference model and a Reference
Architecture.
We have chosen to use the IoT ARM as a guide because it is currently the most
complete model and reference.
IoT Reference Model.
The foundation of an IoT
Reference Architecture
description is an IoT reference
model.
A reference model describes
the domain using a number of
sub-models.
The domain model of an
architecture model captures the
main concepts or entities in the
domain in question, in this case
M2M and IoT.
IoT Domain Model:
The foundation of the IoT Reference Model.
which introduces the main concepts of the Internet of Things like Devices, IoT
Services and Virtual Entities (VE), and it also introduces relations between
these concepts.
The abstraction level of the IoT Domain Model has been chosen in such a way
that its concepts are independent of specific technologies and use-cases.

The domain model captures the basic attributes of the main concepts and the
relationship between these concepts.
A domain model also serves as a tool for human communication between
people working in the domain in question and between people who work
across different domains.
IoT Information Model:
It defines the structure (e.g. relations, attributes) of
IoT related information in an IoT system on a conceptual level without
discussing how it would be represented.
The information pertaining to those concepts of the IoT Domain Model is
modelled,
which is explicitly gathered, stored and processed in an IoT system, e.g.
information about Devices, IoT Services and Virtual Entities.

Virtual Entity in the IoT Domain Model is the “Thing” in the Internet of
Things, the IoT information model captures the details of a Virtual Entity-
centric model.
Similar to the IoT Domain Model, the IoT Information Model is presented
using Unified Modelling Language
IoT Functional Model:
Identifies groups of functionalities, of which most
are grounded in key concepts of the IoT Domain Model.
A number of these Functionality Groups (FG) build on each other, following
the relations identified in the IoT Domain Model.
The Functionality Groups provide the functionalities for interacting with the
instances of these concepts or managing the information related to the
concepts, e.g. information about Virtual Entities or descriptions of IoT
Services.
The functionalities of the FGs that manage information use the IoT
Information Model as the basis for structuring their information.
The IoT Functional Model aims at describing mainly the Functional Groups
(FG) and their interaction with the ARM, while the Functional View of a
Reference Architecture describes the functional components of an FG,
interfaces, and interactions between the components.  
The Functional View is typically derived from the Functional Model in
conjunction with high-level requirements.
Device functional group
The Device FG contains all the possible functionality hosted by the physical Devices that
are used for increment the Physical Entities.
This Device functionality includes sensing, actuation, processing, storage, and
identification components, the sophistication of which depends on the Device capabilities

Communication functional group

The Communication FG abstracts all the possible communication mechanisms used by
the relevant Devices in an actual system in order to transfer information to the digital
world components or other Devices.
IoT Service functional group
The IoT Service FG corresponds mainly to the Service class from the IoT Domain
Model, and contains single IoT Services exposed by Resources hosted on Devices
or in the Network (e.g. processing or storage Resources).

Virtual Entity functional group

The Virtual Entity FG corresponds to the Virtual Entity class in the IoT Domain
Model, and contains the necessary functionality to manage associations between
Virtual Entities with themselves as well as associations between Virtual Entities
and related IoT Services, i.e. the Association objects for the IoT Information
Model. Associations between Virtual Entities can be static or dynamic depending
on the mobility of the Physical Entities related to the corresponding Virtual
Entities.

IoT Service Organization functional group

The purpose of the IoT Service Organisation FG is to host all functional components
that support the composition and orchestration of IoT and Virtual Entity services.
Moreover, this FG acts as a service hub between several other functional groups
such as the IoT Process Management FG when, for example, service requests from
Applications or the IoT Process Management are directed to the Resources
implementing the necessary Services.
IoT Process Management functional group
The IoT Process Management FG is a collection of functionalities that allows smooth
integration of IoT-related services (IoT Services, Virtual Entity Services,
Composed Services) with the Enterprise (Business) Processes.

Management functional group

The Management FG includes the necessary functions for enabling fault and
performance monitoring of the system, configuration for enabling the system to be
flexible to changing User demands, and accounting for enabling subsequent billing
for the usage of the system.   Support functions such as management of ownership,
administrative domain, rules and rights of functional components, and information
stores are also included in the Management FG.

Security functional group

The Security FG contains the functional components that ensure the secure operation
of the system as well as the management of privacy. The Security FG contains
components for Authentication of Users (Applications, Humans), Authorisation of
access to Services by Users, secure communication (ensuring integrity and
confidentiality of messages) between entities of the system such as Devices,
Services, Applications, and last but not least, assurance of privacy of sensitive
information relating to Human Users.
Application functional group
The Application FG is just a placeholder that represents all the needed logic
for creating an IoT application. The applications typically contain custom
logic tailored to a specific domain such as a Smart Grid

IoT Communication Model :

Introduces concepts for handling the
complexity of communication in heterogeneous IoT environments.
Communication also constitutes one FG in the IoT Functional Model.
Trust, Security and Privacy (TSP) are important in typical IoT use-case
scenarios.

Safety
the IoT Reference Model can only provide IoT-related guidelines for ensuring
a safe system to the extent possible and controllable by a sys- tem designer.

Eg: smart grid.

Privacy
Because interactions with the physical world may often include humans,
protecting the User privacy is of utmost importance for an IoT system.
 The IoT-A Privacy Model depends on the following functional components:
Identity Management, Authentication, Authorisation, and Trust &
Reputation

Trust
Generally, an entity is said to ‘trust’ a second entity when the first entity
makes the assumption that the second entity will behave exactly as the first
entity expects.”

Security
The Security Model for IoT consists of communication security that focuses
mostly on the confidentiality and integrity protection of interacting entities
and functional components such as Identity Management, Authentication,
Authorisation, and Trust & Reputation.