D1.1Universal Integration of the Internet of Things through an
IPv6-based
Service Oriented Architecture enabling heterogeneous components
interoperability
Grant agreement for: Collaborative project Grant agreement no.:
288445 Start date of project: October 1st, 2011 (36 months
duration)
Deliverable D1.3 Updated Version of IoT6 Architecture and SOA
Specifications
Contract Due Date 30/09/2013
Author List Srdjan Krco, Boris Pokric
Dissemination level PU
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
2
2 Terminology/Glossary
.......................................................................................................
5
3 Introduction
.......................................................................................................................
8 3.1 Purpose and scope of the document
...........................................................................
8
3.2 Task T1.2 on architecture design
................................................................................
8
3.3 Structure of the document
..........................................................................................
9
4 Existing IoT Architectures
.............................................................................................
10 4.1 IoT-A Architecture Reference Model
.......................................................................
10
4.2 ETSI M2M high-level architecture view
.................................................................
13
4.3 FI-WARE architecture view
.....................................................................................
14
4.4 IoT Data Model Overview
.......................................................................................
16
4.5 IoT Data Semantics and Ontology
...........................................................................
19
5 IoT6 Architecture
............................................................................................................
22 5.1 High-level IoT6 Architecture
...................................................................................
22
5.2 IoT6 architecture – functional view
.........................................................................
24
5.2.1 Communication functionality group
..................................................................
25
5.2.2 Resources and services
.......................................................................................
27
5.2.3 Management
.......................................................................................................
28
5.2.5 IoT6 security
......................................................................................................
28
6 Instantiation of IoT6 architecture for pilot purposes
.................................................. 30 6.1 IoT6
concrete architecture
........................................................................................
30
6.2 IoT6 Interface Specification
.....................................................................................
33
7 Conclusions and future work
.........................................................................................
36
8 References
........................................................................................................................
37
3
List of Figures Figure 1: Relationship between a reference
architecture, architectures and actual systems (taken from IoT-A
[2])
..............................................................................................................................................
11
Figure 2: Relation of an architectural reference model, best
practice, and concrete architectures ....... 11
Figure 3: IoT-A ARM functional model
...............................................................................................
12
Figure 4: ETSI M2M high-level architecture [16]
................................................................................
13
Figure 5: FI-WARE IoT architecture
....................................................................................................
15
Figure 6: Summary of NGSI10 functionality
........................................................................................
16
Figure 7: Data element representation (FI-WARE definition)
..............................................................
17
Figure 8: Multiple measurements in JSON representation of SenML
data ........................................... 18
Figure 9: XML representation of SenML data
......................................................................................
18
Figure 10: EXI representation of SenML data
......................................................................................
18
Figure 11: Basic IoT model
...................................................................................................................
19
Figure 12: Resource Directory registration message from IoT
resource (end point) ............................ 20
Figure 13: Architecture design process
.................................................................................................
22
Figure 14: Initial high-level IoT6 architecture
......................................................................................
23
Figure 15: Functional IoT6 architecture divided into groups.
...............................................................
24
Figure 16: IoT6 communication channel
model....................................................................................
26
Figure 18: IoT6 architecture with indicated Gateway functionality
...................................................... 27
Figure 19: IoT6 concrete architecture
...................................................................................................
32
Figure 20: Example of legacy protocol integration (KNX and BACnet)
into IoT6 .............................. 32
Figure 21: IoT6 architecture, protocol stack mapping
..........................................................................
33
Figure 22: Interface specification for the Building Maintenance
Process scenario .............................. 34
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
4
1 Executive Summary Based on the initial architecture document
presented in deliverable D1.2 [47], an updated IoT6 architecture is
presented in this document. The architectural model is based on the
requirements and scenarios outlined in deliverable D1.1 of WP1.
This version of the document represents the second iterative step
in the IoT6 architecture definition with the “snapshot” taken after
M24 as the work progresses.
The structure of the document is similar to the one in deliverable
D1.2, but expanded in a number of areas. Initially, an overview of
the state-of-the-art in the IoT architecture area is provided. This
is followed with an updated overview of the existing reference
architecture models. Furthermore, an overview section of data
models and ontology methodologies used in the reference
implementations are added in this document version.
From the very beginning of the project, the approach to IoT6
architecture design was to reuse as much as possible the outcomes
of other FP7 projects (most notably IoT-A [2]), as well as other
projects and initiatives like ETSI M2M [6] and FI-WARE [7]. As the
IoT-A architecture reference model (ARM) has been significantly
improved and elaborated, we aligned the IoT6 Year 1 architecture
with the ARM and provided mapping between the two. The revised
architecture model is described and presented, highlighting some of
the special features related to the fact that the underlying
protocol is IPv6. The aim is to utilise properties of this protocol
and re-use them within the architecture model, possibly replacing
some of the standard components. For example, parts of the service
and resource discovery functionality are replaced with the DNS-SD
[17] and mDNS [18] based approaches. Furthermore, the global
addressing capability of IPv6 makes it possible to directly connect
these devices to the backend IoT infrastructure.
In the last section of the document, which is an addition to the
last version, an instantiation of the architecture model (i.e.
concrete architecture) is presented. The concrete architecture is
obtained using the overall reference architecture model devised for
the project, based on the requirements, envisaged use-cases and
available or feasible engineering strategies. The concrete
architecture integrates components developed across different
activities within the project and focusing on specific areas of the
IoT which are then mapped onto the reference architecture
model.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
5
2 Terminology/Glossary
Term Definition Backend The backend is the term used for the
component that
provides management functionalities for the devices and IoT
domain-specific support for the applications. The backend can be
connected southbound to IoT compliant devices (devices that
implement the standardised interface i.e. ETSI M2M) or
Gateways.
Complex event processing System providing functionality to process
input data (raw events) in order to generate a smaller set of
value- added, aggregated and filtered output data (derived
events).
Constrained network A network of devices with restricted
capabilities regarding storage, computing power and/or transfer
rate.
Data handling This term is used for the component that provides
functionality to address filtering, aggregating and merging data
from different sources. Applications can then receive value-added
data that are relevant to their need thanks to the complex event
processing (CEP) component.
Data pooling Enables discovery operations requested both by the
backend/platform and by the IoT resources
Device Technical physical component (hardware) with communication
capabilities to other IT systems. A device can be either attached
to or embedded inside a physical entity, or monitor a physical
entity in its vicinity.
Device cluster A device cluster consists of a set of devices
sharing common properties, for example protocol, location or type
of sensor.
Device with private IP address Device with IP address not globally
delegated placed behind appropriate network address translator
(NAT) Gateway, or a proxy server.
Device with public IP address Device with public IP address
allowing it to be directly connected to the backend (i.e.
Internet)
Discovery service A discovery service allows to find unknown
resources/entities/services based on certain search properties. It
may be utilised by a human or another service.
Domain A domain model describes objects belonging to a particular
area of interest. The domain model also defines attributes of those
objects, such as name and identifier.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
6
ETSI M2M Resource-oriented M2M interface standard defined by
ETSI.
FI-WARE NGSI 9 Enhanced NGSI enabling applications to subscribe to
the dynamic registration of entities in the system (both IoT
resources and Things).
HGW Half Gateway is the element that bridge non-IPv6 enabled
technologies with an IPv6-powered environment.
IoT broker Maps events received from devices into events that can
be forwarded to the FI-WARE publish/subscribe broker using FI-WARE
NGSI compatible formats.
IoT6 Gateway IoT6 Gateway is providing inter-networking and
protocol conversion functionalities between devices and the IoT
backend. Furthermore, the IoT Gateway provides advanced
functionality such as resource discovery and management, device
handling mechanisms data access and handling etc.
IP device A device using IP as network layer communication
protocol.
Large IPv6 cluster Large device (sensor) network and where the
multicast traffic is considered to be inefficient, in which it is
better to employ the DNS-SD methodology, where additional DNS
server is placed within the network, serving as a local database
with resource records (RRs) structured as per DNS-SD
convention.
NGSI 9/10 Manages the simple concept of ‘entities and properties’.
It deals with metadata, i.e. the configuration, management aspects,
allowing queries and to trigger events when a new entity or
property appear, or the value of a property has changed, providing
in this way a very simple, clear and high performance API
[14].
Non-IP device A device which does not use IP as network layer
communication protocol.
Protocol adapter These components are part of Gateways used
primerily to convert from one to another communication
protocol.
Protocol API Components that are used to provide access to the IoT
devices using specific protocols and semantics.
Publish/subscribe broker Allows applications to interchange
heterogeneous events following a standard publish – subscribe
paradigm.
Resource Resource hosted inside a device and enabling access to the
device and thus to the related physical entity.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
7
Resource directory Common storage which hosts descriptions of
resources held on other servers, allowing look-ups to be performed
for those resources.
Restricted network Network that is accesible only for authorized
users.
SaaS Software as a service.
Service control (admission) Provides ability to monitor the
overload conditions of the IoT services enablement platform and in
case the platform is under stress conditions. Therefore it rejects
incoming messages without any further treatment but provides a log
of the received messages.
Small IPv6 cluster A cluster with small number of devices (sensors)
and with an efficient multicast infrastructure, where it is
possible to implement a direct service discovery using only mDNS
(or lmDNS).
Smart thing Generally speaking, a thing is any physical object. In
the term of IoT however, it denotes the same concept as a physical
entity. The term "smart" denotes the ability of the device to
perform more advanced operations such as network connection, data
exchange and data processing.
STIS Smart Things Information System.
Things and resources management
Provides functionality to register and discover things, IoT
resources and relationships between them.
Unconstrained network An unconstrained network is a network of
devices with no restriction on capabilities such as storage,
computing power, and / or transfer rate.
Unrestricted network Part of the network allowing unrestricted
access.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
8
3 Introduction
3.1 Purpose and scope of the document The IoT6 research project
aims at researching and exploiting the potential of IPv6 to develop
a service oriented architecture overcoming the current Internet of
Things fragmentation. The presented document is related to Task
T1.2 on Architecture design, which specifies the IoT6
architecture.
This document represents an update of deliverable D1.2 [47]. It
further specifies the initial IoT6 architecture based on the output
of other work packages as well as developments in the IoT
community. The architecture will be further updated during the last
year of the project.
NOTE: This document is not a delta document of deliverable D1.2
(Initial IoT6 architecture), but the full document which replaces
D1.2.
3.2 Task T1.2 on architecture design Based on the IoT6 requirements
definition (from Task T1.1), the objectives of this Task are to
design and describe the IoT6 IPv6-based Service Oriented
Architecture to be developed in order to integrate heterogeneous
subsystems of the Internet of Things. During the first year of the
project, different architectural options were evaluated against the
scenarios and requirements, discussed among the IoT6 participants
and the advisory board members. These activities resulted in the
initial IoT6 architecture presented in deliverable D1.2 [47],
designed to enable integration and interaction among various
components of the Internet of Things (including sensor networks,
mobile phones, STIS (RFID) and building automation systems), as
well as their integration with cloud computing applications
(Software as a Service) and business processes management tools.
The initial IoT6 architecture identifies the main system components
and their functionality, interaction patterns, interfaces and the
underlying communications links.
In this document, an updated version of the IoT6 architecture is
described, further specifying various IoT6 system components as
well as the ontology to be used in order to assure heterogeneous
integration and provide interoperability among them. The work done
in WP2-5 has been taken into account, in particular in the areas of
security and privacy aspects of the interactions (how the IPv6
features support security mechanism in the transport of information
and how the security and privacy could be integrated within the
interactions with the objects based on the service layer being
proposed and their implications on the architecture design). A
particular care is given to consider the privacy issues from an end
user perspective provided by MI and its supported UN
delegates.
In addition to the input from other work packages of the IoT6
project, the inputs were taken from interactions with the IoT
community, in particular with IoT-A project.
IoT6 participated in an IoT-A project workshop on IoT architecture
providing feedback to IoT-A and discussing their proposed
architecture reference model in particular in the communication
domain. Furthermore, the IoT6 project participated in meetings with
the FI- PPP project FI-WARE and has aimed to align these
initiatives as well as co-organized a workshop with IoT-A on IoT
architecture during the latest IoT week in Helsinki.
The final update of the IoT6 architecture will take place during
the last year of the project, integrating all project developments
and results.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
9
3.3 Structure of the document The document first addresses the
existing IoT architectures (Section 4). Instead of developing a new
architecture, we adopted an approach of building on top of the
existing IoT architectures and aligning it with the ongoing related
developments in several projects and standardization bodies.
Section 5 provides a description of the updated IoT6 architecture.
A description of a concrete system based on the IoT6 architecture
is provided in Section 6. Section 7 concludes the document with a
summary and indicates the future work planned.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
10
4 Existing IoT Architectures Over the years, a number of projects
have specified their own versions of IoT architectures, basing them
on the specific requirements the projects were addressing (IoT-A,
IoT-I, SENSEI, etc.). Due to a large heterogeneity of application
domains and consequently the requirements, the approaches to the
architecture specification differed between the projects thus
resulting in different, more or less, complex architectures
comprised of a number of components and protocols.
In the recent period, a significant effort was invested aiming to
harmonize different approaches and to specify a single IoT
reference architecture. The most prominent work is done in two FP7
projects, IoT-A and FI-WARE, and in the framework of the ETSI M2M
Technical Committee [6] initially and now oneM2M [46].
The approach we selected towards the definition of the IoT6
architecture is to leverage the on- going related activities and
base the initial IoT6 architecture on the available IoT
architecture specifications. Therefore, we first analyzed the work
done by IoT-A [2], ETSI M2M [16] and FI-WARE [7] regarding the IoT
architectures. Based on the results of the analysis, we focused on
those components and functions of these architectures that can be
enhanced with IPv6 features and IoT6 needs.
In the following sections, the ETSI M2M and FI-WARE architectures
are described. The activities in the IoT-A project are highly
relevant and have been taken into account in the requirements
analysis phase. The IoT-A project aims at specifying an IoT
reference model architecture and was used extensively as an input
to the FI-WARE architecture specification. As already mentioned in
the previous sections, in addition to using IoT-A deliverables, the
IoT6 project had several meetings with the IoT-A project to learn
about the details of the reference architecture model they proposed
as well as to provide feedback based on the IoT6 project
achievements up to that moment. The work done in the FP7 SENSEI
project has been taken into consideration by both ETSI M2M TC and
the FI-WARE project.
During the first year of the project, in the course of designing
the initial IoT6 architecture, we considered the ETSI M2M
(technical specifications issued) and FI-WARE (architecture based
on a number of inputs taking into consideration various recent
activities) as the most advanced in terms of the IoT/M2M
architecture specification. Hence, we decided to use these
activities as the basis for the initial IoT6 architecture. In the
meantime, IoT-A has done a considerable effort and produced a
number of relevant outputs providing a larger framework for
designing IoT architectures. Therefore, in this document, we
leveraged this effort and updated the initial IoT6 architecture
according to the provided best practices and guidelines.
4.1 IoT-A Architecture Reference Model The main aim of the IoT-A
project is to propose an IoT architecture reference model (ARM).
The intended usage of the ARM is the following:
• To serve as a cognitive aid – guiding discussions since it
provides a common language to everyone involved and helping in
identifying independent building blocks of an IoT system;
• Common grounding – definition of IoT entities and describing
their basic interactions and relationships with each other, i.e.
the ARM provides common concepts that should be used to build
compliant IoT systems;
• Generation of architecture – IoT ARM can be used for the
generation of compliant
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
11
• Benchmarking – standardized description, ordering and delineation
of components provide a high level of transparency and inherent
comparability to the benchmarking process.
The relationship between reference architecture, architectures and
the actual systems is outlined in Figure 1. Reference models and
reference architectures provide a description of greater
abstraction than what is inherent to actual systems and
applications. They are more abstract than system architectures that
have been designed for a particular application with particular
constraints and choices. Guidance in the form of best practices can
be associated to reference architecture in order to derive
use-case-specific architectures from the reference
architecture.
Figure 1: Relationship between a reference architecture,
architectures and actual systems
(taken from IoT-A [2])
Figure 2: Relation of an architectural reference model, best
practice, and concrete
architectures
Figure 3 shows a functional view of an IoT-A ARM containing seven
longitudinal functionality groups complemented by two transversal
functionality groups (Management and Security). These transversal
groups provide functionalities that are required by each of the
longitudinal groups.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
12
Figure 3: IoT-A ARM functional model
For IoT6, of particular interest are the following functionality
groups: IoT Business Process Management, Communication, Device and
Security.
The IoT Business Process Management Functionality Group (BPM FG)
relates to the integration of traditional business process
management systems. The overall aim of this FG is to provide the
functional concepts and interfaces necessary to augment traditional
business processes with the idiosyncrasies of the IoT world, so
that enterprises can effectively utilize IoT subsystems adhering to
common standards and best practices, thus avoiding the overhead and
costs of isolated and proprietary “intranet-of-things” island
solutions.
The Communication Functionality Group (CFG) aims to tackle all
communication needs of IoT-A compliant systems. Both data plane and
control plane are taken into account. The CFG enables addressing
and routes propagation in order to enable various communication
modes and bypassing the limitation of hop-to-hop communication. The
CFG ensures as well reliable communication and flow control, and
even expands it to multiple flows, enabling in this way QoS
enforcement. The CFG ensures also energy optimization exposing
functions dealing directly with the radio control but also
application level duty cycles. Finally, the CFG enables bridging
among different networks, allowing Devices to perform as a network
entry point implementing forwarding, filtering, connection tracking
and packets aggregation functions. All those functionalities are as
well supported by an error detection and correction infrastructure
implemented by this FG.
The proposed communication model aims at mimicking the ISO/OSI
stack, but it puts the focus on IoT systems requirements and
characteristics. Different channel models are envisaged, ranging
from constrained networks only to a mix of constrained networks,
Gateways and Internet. Of particular importance are the Gateways
which according to IoT-A is a forwarding element, enabling various
local networks to be connected.
The Security Functionality Group (Security FG) is responsible for
ensuring the security and privacy of the IoT-A compliant system. It
is in charge of handling the initial registration of a client to
the network in a secure manner. This ensures that only legitimate
clients may access services provided by the IoT infrastructure. The
Security FG is also in charge of protecting the user's private
parameters by featuring anonymity (ensuring that the user’s
identity remain confidential when he accesses a resource or a
service) and unlink-ability (ensuring that the user may make
multiple uses of resources or services without an attacker being
able to establish links between those uses). This privacy support
relies on fine-tuned identity management, able to assign various
pseudo-random identifiers to a single user. Finally, the Security
FG enables secure communications between peers by managing the
establishment of integrity and confidentiality features between two
entities lacking initial knowledge of each other.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
13
4.2 ETSI M2M high-level architecture view Figure 4 shows the
high-level M2M architecture as defined by ETSI technical
specification [8]. This architecture consists of two distinct
domains: the device and Gateway domain and the network
domain.
As the name implies, components of the device and Gateway domain
are IoT/M2M devices and Gateways. IoT/M2M Gateways enable
communication of M2M devices with other parts of the system via
access networks, i.e. wide area network. There can be one or more
M2M devices connected to a M2M Gateway. In principle, M2M devices
connected via Gateway do not implement the so called M2M
applications and M2M service capability functionality. However, if
a M2M device implements the M2M applications and M2M service
capability functionality, then this device can be connected
directly to the access network and interact with the rest of the
system.
The network domain consists of the wide area communication network
(access and core networks), M2M service capabilities and M2M
applications functions. M2M management and network management
functions are also components of the network domain.
Figure 4: ETSI M2M high-level architecture [16]
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
14
4.3 FI-WARE architecture view Figure 5 shows the IoT architecture
as defined by the FI-WARE project. This architecture has already
taken into account the ETSI M2M specification and has extended it
to incorporate OMA NGSI work [9]. The following large functional
blocks can be identified in this architecture: backend, Gateway,
IoT devices and legacy devices. The deployment of the architecture
of the IoT Service Enablement chapter is typically distributed
across a large number of devices, several Gateways and the backend.
The Generic Enablers shown in the figure below implement
functionalities distributed across these elements.
The backend functional block provides a number of functions and
acts as the main interfaces to access the IoT devices and the
information they produce. It provides both REST and NGSI interfaces
for interaction with the users as well as corresponding functions
like things and resources management; publish/subscribe
functionality and connectivity management. The backend can be
connected southbound to Gateways and/or IoT compliant devices
(devices that will implement the standardised interface i.e. ETSI
M2M). Backend consists of three main GEs, namely IoT Broker,
Configuration Management and Backend Device Management. The IoT
Broker GE is a component for retrieving and aggregating information
from the Internet of Things. The Configuration Manager GE (ConfMan
GE for short) is the part of the IoT Backend which is responsible
for context availability registration. The Backend Device
Management GE is the central component for the IoT backend. It
provides the resource-level management of remote assets (devices
with sensors and/or actuators) as well as core communication
capabilities such as basic IP connectivity and management of
disconnected devices.
The Gateway provides similar functionality, but on the local level,
i.e. it provides functions like things and resource management for
the IoT and legacy devices connected to the Gateway. It consists of
three GEs, namely Data Handling, Gateway Device Management and
Protocol Adapter. The Gateway Device Management GE contains much of
the "core" Gateway functionality. It is responsible for the
communication with the Backend and IoT and non-IoT devices. The
Gateway Device Management GE includes the functional components to
handle the registration/connection phases towards the
Backend/Platform, to translate the incoming data or messages in an
internal format and to send the outgoing data or messages in the
ETSI M2M format (marshal/unmarshal). The Data Handling GE addresses
the need of filtering, aggregating and merging real-time data from
different sources. The Protocol Adapter GE deals with the incoming
and outgoing traffic and messages between the Gateway and Devices
registered, to be served by the Gateway towards the Gateway Device
Management GE or the Data Handling GE. The Protocol Adapter GE
translates device specific protocols into a uniform internal
API.
IoT devices can be connected to a Gateway (e.g. IPv4-based devices
with private addresses) or directly to the backend (e.g. IPv6-based
devices with public addresses). Legacy devices are always connected
via a Gateway.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
15
Figure 5: FI-WARE IoT architecture
The FI-WARE IoT platform provides two fundamental entry points,
namely at the application and at the IoT resource level. The
application level interface is based on the Next Generation
Services Interface (NGSI) specified by Open Mobile Alliance (OMA)
[37]. They take the form of a RESTful binding specification of the
two interfaces defined in the OMA NGSI Context Management
specifications, namely NGSI-9 and NGSI-10. The central aspect of
the NGSI-9/10 information model is the concept of entities.
Entities are the virtual representation of all kinds of physical
objects in the real world. Examples for physical entities are
tables, rooms, or persons. Virtual entities have an identifier and
a type. For example, a virtual entity representing a person named
“John” could have the identifier “John” and the type “person” [38].
The entities have their attributes and attribute domains when more
attributes are grouped together. Exchange of entity information is
performed with context elements which contain information about
multiple attributes of one entity. The three main interaction types
are allowed and these are:
• One-time queries for context information
• Subscriptions for context information updates (and the
corresponding notifications)
• Unsolicited updates (invoked by context providers)
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
16
Figure 6: Summary of NGSI10 functionality
The mapping of NGSI-10 functionality to a resource tree is shown in
Figure 6 whereby POST only methods are coloured in green, whereas
the other operations follow the complete REST approach (GET, PUT,
POST and DELETE). Using these methods over HTTP, it is possible to
perform all the actions on the IoT resources relevant within the
defined architecture model.
The IoT resource level interface is generally split into two main
parts, namely sensor (and actuator data) and search and discovery
entry points. Interface dedicated to the sensor and actuator data
is defined with ETSI M2M [6] standard. However, other proprietary
protocols can be used which are then transcoded to the platform
protocol using associated Protocol Adapter GE functionality. The
search and discovery interface is implemented through CoAP [19] for
the Gateway Device Management GE as defined in the associated
FI-WARE specification [41].
4.4 IoT Data Model Overview A very important aspect of each
platform is the overall data model. The main purpose of data model
is to provide definition and format of data and the way the data is
structured taking into account various parts of the architecture,
system requirements and use-cases of the system, thus enabling the
interoperability of the system components. This aspect is
particularly important having in mind the fact that the overall
IoT6 architecture is complex, diverse and
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
17
that it contains heterogeneous data sources (IoT devices and
resources) and diverse data consumers (actuators, applications and
other platform components).
Data itself refers to information that is produced, generated,
collected or observed and that may be subject for further
processing in terms of analysis and knowledge extraction. It has an
associated data type and value. Subsequently, a data element is
usually defined by three attributes, commonly referred to as
triplet, namely name, value and type. A data element can have one
or more of these triplets and general representation is given in
Figure 7 as defined by the FI-WARE Data/Context Management GE
[21].
Figure 7: Data element representation (FI-WARE definition) As can
be seen, further to the base attributes, a data element can have
additional meta-data associated with it. Meta-data (also referred
to as semantic data) is optional and describes the data element(s)
in more details, providing further contextual description. Data
elements are used within the system in different ways, depending on
the component that is handling them.
For example, data elements are stored in an appropriate relational
(e.g. MySql [48]) or non- relational (e.g. Mongo [49]) database,
serialized in XML or JSON if being sent over the network or
converted in some other intermediate format in order to support a
legacy or proprietary components within the platform.
One of the most important aspects of the applied data model is to
define the format to be used between the sensors and the core
platform. A good candidate for this role is the Sensor Markup
Language (SenML) specification that defines new media types for
carrying simple sensor information in protocols such as HTTP or
CoAP [19]. The core design goal of this schema is to be able to
send simple sensor measurements in small packets on mesh networks
from large numbers of constrained devices, keeping the total
message size smaller than 80 bytes. The data itself is structured
as a single object with attributes and associated meta-data
resulting in an array of entries. The attributes and meta-data
describe the time the measurement was made, current value, base
units etc. Serializations for this data model are defined for JSON,
XML and Efficient XML Interchange (EXI) format [23]. The SenML
format can be extended with further custom attributes placed in the
base object, or in an entry. Extensions in the base object pertain
to all entries, whereas extensions in an entry object only pertain
to that particular entry.
In terms of the meta-data, this data model is designed so that it
carries minimal overhead of the static semantic information which
is transmitted or obtained separately. For example, web resources
using SenML representations, this meta-data can be made available
using the CoRE Link Format [24]. The CoRE Link Format provides a
simple way to describe Web Links, and in particular allows a web
server to describe resources it is hosting.
The following example shows how to query one device that can
provide multiple measurements. The example assumes that a client
has fetched information from a device at the following address:
2001:db8::2, by performing a GET operation on http://[2001:db8::2]
at Mon Oct 31 16:27:09 UTC 2011, and has gotten two separate values
as a result, a temperature and humidity measurement [22].
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
18
{"e":[ { "n": "temperature", "v": 27.2, "u": "degC" }, { "n":
"humidity", "v": 80, "u": "%RH" }], "bn": "http://[2001:db8::2]/",
"bt": 1320078429, "ver": 1 }
Figure 8: Multiple measurements in JSON representation of SenML
data In the JSON representation shown in Figure 8, different data
points are within the curved brackets with the name (“n”), value
(“v”) and type (“u”) attributes matching the proposed overall data
model above. Further dynamic meta-data (i.e. base name, base time
and version) are followed subsequently. There are other attributes
available and the details are given in the SenML specification
[22].
For the efficient transmission of SenML over e.g. a constrained
network, Efficient XML Interchange (EXI) can be used. This encodes
the XML Schema structure of SenML into binary tags and values
rather than ASCII text. An EXI representation of the SenML SHOULD
be made using the strict schema-mode of EXI. Figure 9 shows an
example of XML representation of SenML data, requiring 173
bytes.
<?xml version="1.0" encoding="UTF-8"?> <senml
xmlns="urn:ietf:params:xml:ns:senml"
bn="urn:dev:ow:10e2073a01080063" > <e n="temp" v="23.1"
u="degC" /> </senml>
Figure 9: XML representation of SenML data Figure 10 shows the byte
aligned EXI representation of XML data.
00000000 a00048806c200200 1d75726e3a646576 |..H.l ...urn:dev|
00000010 3a6f773a31306532 3037336130313038 |:ow:10e2073a0108|
00000020 3030363303010674 656d700306646567 |0063...temp..deg|
00000030 430100e701010001 02 |C........|
Figure 10: EXI representation of SenML data It can be seen that the
EXI representation is considerably smaller, resulting in 57 bytes
only, leading to more than 3-fold reduction in size. This is
especially important when putting this in the context of
constrained IoT devices and available network channels.
Furthermore, this fits well with the CoAP specification [19] that
is well-suited for the short message packets transmitted over UDP.
Messages larger than an IP packet result in undesirable packet
fragmentation. A CoAP message, appropriately encapsulated, should
fit within a single IP packet (i.e., avoid IP fragmentation) and
(by fitting into one UDP payload) needs to fit within a single IP
datagram. Furthermore, another important aspect of using CoAP is
that its choice of message size parameters works well with IPv6
which is very significant in the IoT6 context.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
19
4.5 IoT Data Semantics and Ontology IoT devices are very diverse,
providing heterogeneous data, legacy protocols, different data
formatting and therefore any low-level access to the devices and
data would prove to be very inefficient if not impossible task.
Therefore, it is necessary to provide an abstraction layer capable
to offer data (or resource) access using the semantic information
model.
The semantic and ontology can be applied to the well-defined and
structured IoT information model. This model should detail various
concepts and provide abstractions of the components and their
attributes. One of the main goals of IoT is to extend the Internet
into the physical world and from this perspective the information
model defines a physical entity within the ambient environment.
Different “things” (such as a human, an animal, a car, a store, a
logistic chain item, an electronic appliance or a closed or an open
environment) constitute entities which are the main focus of
interactions. These interactions are made possible by a hardware
component, a ‘device’, which either attaches to an entity or is a
part of the environment of an entity so it can monitor it. The
device allows the entity to be a part of the digital world by
mediating the interactions. The actual software component that
provides information on the entity or enables controlling of the
device, is a ‘resource’ [32]. This model is depicted in Figure
11.
Figure 11: Basic IoT model
Based on this model, suitable abstractions are created and defined
using interoperable representations. There are different
representational entity and resource models when dealing with
semantics and ontology such as Web Ontology Language (OWL) [33]. It
is designed for use by applications that need to process the
content of information instead of just presenting information to
humans. OWL provides three languages which are used depending on
the required flexibility, namely OWL Lite, OWL DL and OWL Full. For
example, the entity model applied in the IoT-A project [2] is built
upon the OWL DL language which is providing maximum expressiveness
while retaining computational completeness [33]. There are also
other representation models such as OntoSensor [34],
service-oriented ontology [35] and SensorData ontology [36] each
with their strengths and weaknesses such as not being able to
represent sensor data semantically.
One of the approaches that has received consensus from the
community is “sensing as a service” model which represents a
scalable way to access the sensor data through standard service
technologies. In other words, this approach represents resource and
service ontology model supporting search and discovery mechanisms
which are among the most important functionalities that are
required in IoT. These mechanisms allow locating resources or
services that provide data related to an entity of interest in the
physical world. In order to support these mechanisms it is
necessary to provide structured semantic annotations of the IoT
resources,
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
20
services and data that are being produced.
Resource discovery is one of the IoT6 functions. Two approaches are
envisaged: Resource Directory [28] and DNS-based service discovery
[17]. The reason for having two different approaches is to allow
simpler registration of legacy devices (requiring small firmware
footprint) using the Resource Directory while at the same time
supporting more advanced IoT IPv6-based resources using
digcovery.
Resource Directory (RD) is a component that belongs to the Resource
and Service functional group. The RD provides functionality for the
resource registration and discovery in compliance with the IETF
CoRE specifications [27]. It is also a part of the Gateway Device
Management GE within the FI-WARE architecture [26]. The resource
directory specification [28] defines the web interfaces required by
web servers to discover the RD and to register, maintain, look-up
and remove descriptions of resources. Furthermore, new link
attributes useful in conjunction with an RD are defined.
Essentially, a RD is used as a repository for the web links stored
on other servers.
From the ontology perspective, one important aspect of RD is that
it can be logically segmented by the use of Domains, creating the
hierarchical structure. From the semantics perspective, the
registration procedure defined within the specification enables
description of the resources, their physical location and type of
services offered. An example of a registration message is given in
Figure 12.
Req: POST coap://rd.example.org/rd?h=node1<=1024 Etag: 0x3f
Payload: </sensors/temp>;ct=41;rt="TemperatureC";if="sensor",
</sensors/light>;ct=41;rt="LightLux";if="sensor" Res: 2.01
Created Location: /rd/4521
Figure 12: Resource Directory registration message from IoT
resource (end point) In this case, i.e. CoAP RD, semantic
information about resources is provided with the “rt” parameter,
while the ontology component is supported through the domain and
directory paths. The discovery mechanism is subsequently followed
using the CoRE link format [29] where the process can be performed
either using unicast or multicast depending on whether a server's
IP address is already known (a priori or resolved via the DNS) or
client needs to locate a resource within a limited scope, and that
scope supports IP multicast. By using the supported filtering, it
is possible to search and discover resources globally, within
certain domain, name or capability, providing sufficient
flexibility in the context of IoT service search and
discovery.
Alternative search and discovery mechanism supported through IoT6
platform is based on the DNS protocol relying on the lightweight
multicast DNS (lmDNS) for IPv6-enabled Smart Objects in the local
domain. For the global discovery, digcovery [30] architectural
model is utilized, based on the DNS Service Discovery (DNS-SD). As
previously mentioned, DNS- based service discovery is utilized in
order to take advantage of already existing functionality within
the IPv6 stack and therefore supported within different platforms,
operating systems, routers, and networking devices.
Digcovery allows delegation of different domains to the end-users
and/or service providers through the so called digrectories. Each
digrectory is able to interact with the local devices and smart
things, protecting the accessible and publishable resources from
the local domain.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
21
The most significant aspect is that it allows for the publishing
and linking of the directories to digcovery, which is globally
accessible and allows global discoveries by considering the
resources from all the digrectories [31]. The architecture is
designed to support IPv6-based IoT resources as well as legacy
devices through the IPv6 Addressing Proxy.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
22
5 IoT6 Architecture Having in mind the potential usage of the IoT
ARM listed above and the fact that IoT-A project defined IoT ARM
with associated best practices and guidelines, the task of updating
the initial IoT6 architecture task is building on top of this work.
The methodology used for design of the IoT6 architecture is
presented in Figure 13.
Figure 13: Architecture design process
Using the requirements identified and documented in deliverable
D1.1 [1], IoT-A ARM and the state-of-the-art in terms of the IoT
architecture work, an initial IoT6 architecture has been designed
and presented in deliverable D1.2 [47] and updated in this
document. While the initial IoT6 architecture work was more relying
on ETSI M2M and FI-WARE IoT architectures, the updates of our
architecture are more based on the IoT ARM as it matured in the
meantime. Over the same period, interactions between our project,
IoT-A and FI-WARE regarding the IoT architecture took place as
well, which led to better understanding of the choices made by each
project and better alignment of the activities.
By doing it this way, not only was the creation of the IoT6
architecture sped up, but the outcome of our work will fit into the
overall effort (coordinated by the IERC) of creating a common
framework for the IoT systems.
5.1 High-level IoT6 Architecture In deliverable D1.2 [47], a high
level view of the initial IoT6 architecture is given (Figure 14).
As the focus of the IoT6 project is on utilizing IPv6 in IoT
systems and integration of heterogeneous application domains, the
architecture is mainly dealing with the communication part and
integration of business processes/applications. The main components
of the initial high level IoT6 architecture are IoT devices (IP and
non-IP based), local and wide area communication network and the
server side services and applications.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
23
Figure 14: Initial high-level IoT6 architecture
The top-level mapping of the initial IoT6 architecture shown in
Figure 14 to the IoT ARM functional model shown in Figure 3 is
described in Table 1.
IoT6 IoT ARM
IoT6 backend server IoT business process management
IoT6 wide and local area networks Communication
Devices Device
Table 1: Mapping IoT ARM to IoT6 architecture
IoT devices (sensors and actuators) can be found at the bottom of
the architecture stack outlined in Figure 14. From an IoT6
perspective, there are two distinct types of devices: IoT6
compliant and IoT6 non-compliant or legacy devices. The IoT6
compliant devices are IPv6 enabled or are using protocols such as
6LoWPAN, GLoWBAL IPv6 [13], CoAP [19] and CoRE [20]. The IoT6
non-compliant devices are based on other, non-IP
communication
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
24
protocols as well as IPv4-based devices. The IoT6 non-compliant
devices, require Gateways or proxies to be connected to the rest of
the IoT6 system in order to adapt the native protocols,
functionality and addressing to IPv6 through a transparent
mechanism.
The IoT6 Local Area Network (LAN) provides connectivity mechanisms
to IoT devices taking into account their specific protocols and
technology and making them available to the rest of the IPv6
powered environment in terms of discovery, access and
management.
The IoT6 wide area network (WAN) enables the interconnection of
multiple IoT6 LANs and IoT6 backend servers and provides by this
the overall IoT6 core infrastructure. This infrastructure offers
access to the IoT devices from the application-level layer
consisting of different services such as Software as a Service
(SaaS), Smart Things Information Service (STIS), Web and mobile
applications to mention just a few examples.
5.2 IoT6 architecture – functional view The functional view of the
initial IoT6 architecture is given in Figure 15. It is based on a
set of generic functionalities distributed between
resource-constrained and non-constrained devices.
Figure 15: Functional IoT6 architecture divided into groups.
The generic functionalities are divided into six groups according
to their specific domains. These domains and their functionalities
are described in the following sections.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
25
5.2.1 Communication functionality group The IoT6 communication
functionality group provides common access to resources and
devices, with the main assumption being that IPv6 is the main
underlying communication technology used. It is designed to enable
integration of various devices employing different communication
technologies and protocols, abstracting and adapting them to work
with IPv6.
To integrate different technologies, the IoT6 communication
proposes a networking abstraction layer between devices and
applications. This communication abstraction layer integrates smart
things, RFID tags, Zigbee devices and any embedded technologies
into an uniform networking solution based on IPv6. This abstraction
is developed by efficient mechanisms adapted to the limited
resources of IoT6 devices in terms of energy and computation. For
doing that, IoT6 communication requires several networking agents
enabling the interaction between edge devices of the network and
high-level applications. Networking agents like routers and
Gateways allow the interoperability of underlying communication
technologies into a homogeneous solution distributed onto various
levels with the following generic functionalities:
• Self-management: IoT6 routers, Gateways and proxies will
guarantee the automatic management of IoT6 devices in cases of
failures based on pre-established rules.
• Integrity: IoT6 communication will provide effective mechanisms
to detect errors produced during the communication process between
IoT6 routers, Gateways and devices to ensure succesful reception of
the generated traffic.
• Bootstrapping: IPv6-compliant devices will obtain their own
IP-addresses exploiting IPv6 features such as stateless
auto-configuration and the resource directory to register new
devices. For non-IPv6-compliant devices, IoT6 Gateways will provide
an IP-address and configuration in the time of joining to the
network.
• Addressing: For non-IPv6 based devices, IoT6 Gateways will map
their physical layer identifiers with IP addresses.
• Reliability: IoT6 routers and Gateways will provide
acknowledgement mechanisms to guarantee communication in IoT6
networks.
• Routing: IoT6 routers and Gateways will enable different
communication techniques like unicast, multicast, broadcast and
smart-routing.
• Mobility: IoT6 routers and Gateways will support the mobility of
IoT6 devices between local area networks and the mobility changes
are informed to the resource repository in order to update the
location of devices.
• Connectivity: IoT6 routers and Gateways will manage communication
with IoT6 devices which are sometimes in sleep mode. This
management will require to cache temporally the traffic for waiting
IoT6 devices to wake up.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
26
5.2.1.1 Communication channel model The IoT6 communication channel
model is presented in Figure 16 and outlines three distinct network
domains that are present within the architectural model.
Figure 16: IoT6 communication channel model
The first is the general Internet domain (Internet wide-area),
which contains the future Internet core network and its associated
components that access this network. This can be mobile networks,
monitoring applications, cloud computing (SaaS), user interfaces
and information systems. The second network domain covers the IoT
intranet (IPv6 local network) containing the IPv6 Services, routers
and Gateways used to provide access to sensor clusters. The third
domain is the sensor network domain that contains the things with
associated sensors connected using a variety of protocols (IPv6 or
non-IPv6 based).
Similar to the functional model, the communication channel model
can be mapped to the communication channel model of IoT ARM (Figure
17). IPv6 and non-IPv6 sensor networks in IoT6 represent
constrained networks, IPv6 local and future Internet core network
of IoT6 represent Internet in ARM, while mapping of the Gateways is
straightforward.
Figure 17: IoT ARM communication channel model
According to the IoT ARM, the use of Gateways is optional. While in
general we can agree with such statement, our view is that the
Gateways will be more often used than not. A more detailed view of
the role and functionality of Gateways are given in Figure
18.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
27
Figure 18: IoT6 architecture with indicated Gateway
functionality
Within the local network (Intranet), all the local Gateways are
IPv6-compliant and provide functionalities such as discovery of
services and resources, protocol adapters (e.g. HTTP to CoAP, IPv4
to IPv6), smart routing and security and privacy aspects. Half
Gateways provide more specific functionalities to the sensor
networks in terms of protocols and addressing, taking into account
IPv6 based as well as legacy devices (IPv4 and non-IP
devices).
5.2.2 Resources and services The IoT6 architecture must provide
generic mechanisms to enable IoT6 applications to discover and
manage heterogeneous resources. To achieve that, common schemes for
identifying and modeling IoT6 resources are needed as well as a
resolution infrastructure to associate them with things.
Concretely, IoT6 architecture needs a generic identification scheme
that permits to address and find heterogeneous IoT6 resources. To
solve this problem in the Internet the domain name system (DNS) has
been proposed to assign and resolve unique and universal
identifiers for network devices. However, DNS is not adapted to the
computation limitations of IoT6 devices and the need of discovering
specific properties of an IoT6 resource. Moreover, a common
resource modeling is essential to the discovery and look- up of
IoT6 resources. Although there are solutions to model sensor
networks, they were developed for specific devices and
applications. Below, we present the main functionalities
implementing IoT6 Resource and Services:
• Resolution: IoT6 resource repository maps an identifier for an
IoT6 device to its address or location to enable communication with
the IoT6 device.
• Look-up: The IoT6 resource repository maps the identification of
an IoT6 resource including the network address of the device to a
high-level resource identifier. The identifier of an IoT6 resource
and its recent information are stored in a directory where IoT6
applications and services can access. Unified information models
are required to improve the accessibility for IoT6 applications and
services.
• Discovery: The IoT6 resource repository enables finding unknown
resources by sending specific queries to IoT6 networks. These
queries are often distributed using broadcast or multicast
techniques within a local area network or within a predefined
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
28
range. IoT6 devices in the network answer with the resources
requested. In parallel, new IoT6 resources that are connected to
the network could be self-registered in the repository at the same
time.
5.2.3 Management IoT6 management will provide vertical mechanisms
for controlling and maintaining IoT6 networks to ensure efficient
and effective deployments. These mechanisms should enable the easy
deployment of new IoT6 devices and their later software changes.
They must support automatically the topology dynamism of IoT6
networks where devices can be in different states (sleep, awake)
and their health conditions can change. Moreover, the IoT6
management should support a traffic computing mechanism to redirect
the important data from sources to their respective destinations.
This automatic mechanism should be scalable and high performing,
distributed across IoT6 devices able to process local data
according to specific conditions and patterns. The main
functionalities for IoT6 management are described below:
• Status monitoring: IoT6 routers and Gateways should provide a
generic scheme for monitoring connection status of IoT6 resources
in local area networks and integrating alarm events in failure
situations.
• Configuration: IoT6 management should provide software
reprogramming mechanisms to enable initialization, activation,
update, de-activation, and re- activation of resources in IoT6
devices.
• QoS management: For urgent traffic flows, IoT6 devices should
prioritize incoming messages through faster routers and Gateways
without any human interaction.
5.2.4 IoT6 process automation IoT6 process automation will permit
configuration of the high-level services employing subscription and
rules templates for IoT resources. It requires to share the
processing overhead into IoT6 devices in order to achieve a
scalable and distributed solution. This distributed processing must
be developed using semantic mechanisms to establish interaction
between IoT6 devices, routers and Gateways. The main
functionalities of the IoT6 process automation are:
• Template: A distributed mechanism based on templates should
permit that services perform query operations for IoT6 resources. A
template management is required to create and keep templates in
order to define the subscription requests or event processing
rules.
• Semantic: A semantic technology should be applied to provide
related values of IoT6 resources in order to obtain hierarchical
dependencies between them. Moreover, an ontology scheme should
enable collection of knowledge from IoT resources in real-
time.
5.2.5 IoT6 security IoT6 security should provide privacy,
confidentiality, integrity and authentication operations from IoT6
devices to IoT6 applications and services. These mechanisms will be
configured based on security policy rules related to IoT6 resource
profile to improve the security management allowing human and
context changes. The main security functionalities proposed in IoT6
architecture are:
• Privacy: a secure mechanism must control the access of IoT6
resources based on pre- defined access policies for the
authorization of IoT6 applications and services.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
29
• Confidentiality: standard encryption operations will be proposed
according to shared keys in order to support confidential
communications in local area networks. IoT6 routers and Gateways
will use encryption algorithms with distributed keys to decrypt and
encrypt the incoming and outgoing traffic from IoT6 devices.
• Integrity: IoT6 routers and Gateways must provide effective
mechanisms to detect and recover from transmission errors produced
during the communication process.
• Authentication: IoT6 routers and Gateways should enable
cryptography mechanisms to authenticate IoT6 devices when they are
joining to IoT6 networks.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
30
6 Instantiation of IoT6 architecture for pilot purposes In the
previous sections, the IoT6 architecture was described on the
conceptual and functional levels. For the purpose of a concrete
implementation, i.e. for the implementation of the first IoT6
demonstration/pilot system, it is necessary to create an
instantiation of the described architecture, taking into account
the specific design and implementation requirements, constraints
and choices. In this section, the IoT6 architecture which will
serve as the basis for implementation of the IoT6 pilot system
described in detail in deliverables D7.1 [50], D5.1 [52] and D4.2
[51] is presented.
6.1 IoT6 concrete architecture This section outlines the
architectural view of the IoT6 platform based on the reference
architectural model as outlined in Section 5, following the
methodology described in Figure 13. In summary, the concrete
architecture is obtained using the overall reference architecture
model devised for the project, based on the requirements, envisaged
use-cases and available or feasible engineering strategies. The
concrete architecture integrates components developed across
different activities within the project and focusing on specific
areas of the IoT which are then and mapped onto the reference
architecture model as shown in Figure 19.
In the context of IPv6 devices to be used in the pilot, hardware
platform described in deliverable D5.1 deliverable [42] specifies
that they will be based on the 6LoWPAN protocol, backed by the
802.15.4 Gateway. Within the small IPv6 cluster, the resource and
service discovery is performed using the mDNS and RD functionality
combined together. The mDNS functionality is implemented with
Avahi, Free zeroconf implementation, including a system for
multicast DNS/DNS-SD service discovery [43]. Within the large IPv6
cluster, the resources are connected to the global discover engine
based on DNS-SD, called digcovery as discussed in deliverable D3.1
[31].
In terms of integration of mobile devices into the IoT6 platform,
two main features are implemented as presented in deliverable D6.2
[44]. Firstly, a mobile phone can be used as a Gateway, allowing
access to the rest of the IoT6 platform to the external sensors and
IoT devices (connected using WiFi or bluetooth). Mobile phone
itself is connected to the platform via IPv6 protocol, allowing the
global search and discovery via digcovery as well as via resource
directory functionality. Secondly, mobile phone is acting as an IoT
device itself, by registering its sensors (camera, accelerometer,
gyroscope, microphone etc.) as IoT services to the directory.
As it can be seen, there is RFID cluster, with EPC tags connected
together using EPCIS backbone. The search and discovery mechanism
is based on EPCIS-DNS digrectory connector locally and using
digrectory and resource directory on the global level [31]. In
terms of the legacy device, protocols and sensors, Universal Device
Gateway (UDG) components have been used to test the integration of
legacy devices as described in the IoT6 deliverable D4.2 [51]. UDG
represents an innovative solution developed in a previous project
that enables interoperability between heterogeneous devices,
protocols and standards such as ZigBee, KNX, Bluetooth, X10, RFID,
USB and WiFi. The components have been adapted and extended in
order to map the framework onto the overall IoT6 architecture and
to enable the test and experiments to be performed by the WP4 as
reported in deliverable D4.2.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
31
Protocol adatpter
Mobile applications
802.15.4 gateway
Resource Management
Discontinuous Connectivity
CoAP RD
Communication Core
Data Handling
32
Figure 19: IoT6 concrete architecture The main components of the
multi-protocol integration framework are shown in Figure 19
integrated within the IoT6 architecture model devised. The
appropriate components have been grouped together with other
components within the associated functional groups. The IPv6
mapping module is used to translate device identifier of specific
legacy protocol to an IPv6 address. Specific features of this
component enable, for example, that the same device obtains the
same IPv6 address every time it is connected to the same IPv6
Addressing Proxy, providing that the device configuration is not
changed. Furthermore, the IPv6 address is unique within the proxy
domain. The original feature scope of UDG has been extended through
the support of intelligence distribution based on dynamic target
and scope selection, dynamic source parameter determination and
advanced management of priorities as presented in D4.2 [51]. These
features are supported through the Dynamic Source and Parameters
and Priority components.
In order to integrate the existing systems and protocols into the
overall IoT6 architecture, a stack has been developed aligning the
functionalities on both sides and at the same time enabling the
legacy devices to run in the same environment. The stack extends
the IPv6, JSON and CoAP protocols with the oBIX data model. On top
of the protocol stack, oBIX is used as application layer protocol
as CoAP does not provide capability to map the identified
application features as identified in deliverable D4.1 [53]. Some
of these components are represented in the overall concrete IoT
architecture in Figure 19 as interfaces to the devices and through
the UDG Middleware component. Example of such integration is shown
in Figure 20 (as reported in D4.2 [51]).
Figure 20: Example of legacy protocol integration (KNX and BACnet)
into IoT6
Another view of the concrete IoT6 architecture is shown in Figure
21, indicating the protocol stack mapping to the IoT6 architecture
[54].
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
33
Figure 21: IoT6 architecture, protocol stack mapping
6.2 IoT6 Interface Specification The IoT6 platform provides two
fundamental entry points, namely at the application and at the IoT
resource level. Additional inter-component communication is defined
as per the available concrete technology and standards used within
the instantiated architecture as well as the defined use-cases as
described in D1.1 [1]. The test processes have been specified
within deliverable D7.1 [50] and this document provides extensive
detail regarding the specific interfaces for each of the use-cases
to be implemented and covered. The identified use-cases completely
cover the functional specification of the platform and ensure that
all of the features implemented provide sufficient flexibility for
the future platform usage. An example of the interface
specification is shown in Figure 22 indicating the components
involved and the interface and protocol used for the
inter-component communication.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
34
Figure 22: Interface specification for the Building Maintenance
Process scenario
As for the application level interface, there are number of
functional areas covered, such as search and discovery, resource
access and configuration. The search and discovery mechanism is
supported through two main interfaces. The first one is based on
the DNS protocol through digcovery which splits the architecture
into two main parts, namely digcovery and digrectory providing the
server-side and client-side interface respectively [40]. The
server-side interface is based on the ElasticSearch which is an
open source search engine for distributed RESTFul-based
architectures and integrated with digcovery [31], [39].
ElasticSearch provides a full Query DSL based on JSON to define
queries. The digcovery client API is split across five distinct
modules each having its own interface. These modules, namely
DigcoveryFormats, CoapLib, DigcoveryComm, MDNSDriver and
DNSBindManager and their respective interfaces are described in
detail in the API specification [40]. These interfaces are used
from the IoT resources side in order to register devices and send
the data to the digcovery server. The second interface is based on
FI-WARE specification using CoAP for performing search and
discovery process. This process is supported by the associated
Resource Directory component located within Gateway Device
Management module [41].
In terms of the resource access, the main interface implemented is
based on oBIX specification [45] published by Organization for the
Advancement of Structured Information Standards (OASIS) in December
2006. This standard defines M2M communication between embedded
software systems over existing networks using standard technologies
such as XML and HTTP. oBIX is based on service-oriented
client/server architecture and defines three request/response
services used to read and manipulate data or to invoke resource
operations. Each service response is an oBIX XML document that
contains the requested information or the result of the service.
The implementation of these three request/response services is
called
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
35
protocol binding. There are two different protocol bindings
specified by the oBiX standard. The first protocol is the HTTP
binding, which simply maps oBIX request to HTTP methods. The second
protocol binding is the SOAP binding that maps a SOAP operation to
each of the three oBIX requests.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
36
7 Conclusions and future work This deliverable has outlined the
IoT6 architecture together with the analysis of the future Internet
state-of-the-art IoT architectures. The approach adopted for the
architecture model definition was to combine and re-use already
existing initiatives in this area such as IoT-A and FI-WARE as
there is a significant functional overlap between the
architectures. However, the existing initiatives are focused on
providing only a generic reference implementation and therefore,
the proposed IoT6 architecture model aims at enhancing it and
applying IPv6 related requirements within the IoT6 project. In this
way, the reference architecture model was modified and new
components were added so that IPv6-specific functionalities are
leveraged not only at the protocol level, but also at the higher
levels within the architecture model. For example, components
responsible for providing functionality for discovery of resources
and services are enhanced with IPv6 mechanisms based on DNS-SD and
mDNS concepts. Furthermore, as IPv6-based devices are globally
accessible, there is no need for them to be connected to the system
via dedicated Gateways. Instead, they can be connected to the
backend server and associated global discovery mechanisms within
the core network.
The architecture described in this document represents an update of
the intial IoT6 architecture, based on the outputs of other project
work packages. It serves as the overall framework and guideline for
implementation of a pilot IoT6 instantiation. As the project
progresses and new results become available, the architecture will
be updated and the final version released at the end of the
project.
D1.3 Updated Version of IoT6 Architecture and SOA
specifications
37
8 References [1] IoT6 project, deliverable D1.1 - IoT6 use-case
scenario and requirements definition
report
[3] Internet-of-Things Architecture, IoT-A, Project, deliverable
D1.2 – Initial Architectural Reference Model for IoT
[4] Holistic Platform Design for Smart Buildings of the Future
Internet, HOBNET, STREP ICT-257466, FIRE,
http://www.hobnet-project.eu/
[5] SENSEI (Integrating the Physical with the Digital World of the
Network of the Future), Pervasive and Trusted Network and Service
Infrastructures: ICT-2007.1.1: The Network of the Future, Contract
no. 215923, http://www.sensei-project.eu/
[6] ETSI M2M Communications,
http://www.etsi.org/website/technologies/m2m.aspx
[7] FI-WARE Internet of Things (IoT) Services Enablement,
http://forge.fi-
ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-
WARE_Internet_of_Things_(IoT)_Services_Enablement
[8] ETSI TS 102 690, Machine-to-Machine communications (M2M),
Functional architecture,
http://www.etsi.org/deliver/etsi_ts/102600_102699/102690/01.01.01_60/
ts_102690v010101p.pdf
[9] OMA Next Generation Services Interface,
http://www.openmobilealliance.org/
Technical/release_program/ngsi_v1_0.aspx
[10] Jara, A.J.; Martinez-Julia, P.; Skarmeta A.F.: “Light-weight
multicast DNS and DNS- SD (lmDNS-SD): IPv6-based resource and
service discovery for the Web of Things”, International Workshop on
Extending Seamlessly to the Internet of Things, 2012.
[11] Shelby, Z.; Bormann, C.; “6LoWPAN: The Wireless Embedded
Internet”, Wiley, ISBN: 978-0-470-74799-5, 2009.
[12] Colitti, W.; Steenhaut, K.; De Caro, N.; Buta, B.; Dobrota,
V.; "REST Enabled Wireless Sensor Networks for Seamless Integration
with Web Applications," Mobile Adhoc and Sensor Systems (MASS),
IEEE 8th International Conference on, pp.867- 872, 17-22 Oct.
2011.
[13] Jara, A. J.; Zamora, M.A.; Skarmeta, A.F..; “GLoWBAL IP: an
adaptive and transparent IPv6 integration in the Internet of
Things”, Mobile Information Systems, “accepted and in press”,
2012.
[14] OMA Service API Standardisation,
http://www.ict-ccast.eu/workshops/2nd/13%20-
%20OMA%20-%20Kovacs%20-%20OMA_ServiceAPI_Standardisation.pdf
[15] ETSI M2M standard -
http://www.etsi.org/website/technologies/m2m.aspx
[16] ETSI M2M Functional Architecture –
http://www.etsi.org/deliver/
etsi_ts/102600_102699/102690/01.01.01_60/ts_102690v010101p.pdf
[17] DNS Service Discovery (DNS-SD), http://www.dns-sd.org/
38
[20] Constrained RESTful Environments,
http://tools.ietf.org/wg/core
[21] FI-WARE Data/Context Management, http://forge.fi-
ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-
WARE_Data/Context_Management
[22] Sensor Markup Language (SenML) Specification,
http://tools.ietf.org/html/draft- jennings-senml-08
[23] Efficient XML Interchange (EXI) Format 1.0, W3C Recommendation
10 March 201, http://www.w3.org/TR/exi/
[24] Constrained RESTful Environments (CoRE) Link Format,
http://www.ietf.org/rfc/rfc6690.txt
[25] Semantics for the Internet of Things: early progress and back
to the future, Payam Barnaghi and Wei Wang, Centre for
Communication Systems Research, University of Surrey, Guildford,
Cory Henson, Ohio Center of Excellence in Knowledge- enabled
Computing and Kerry Taylor, CSIRO ICT Centre, Canberra,
Australia
[26] Gateway Device Management GE - Ericsson IoT Gateway,
http://catalogue.fi-
ware.eu/enablers/gateway-device-management-ge-ericsson-iot-gateway
[27] Constrained RESTful Environments (core), IETF,
https://datatracker.ietf.org/wg/core/ [28] Resource Directory IETF
specification, http://tools.ietf.org/html/draft-shelby-core-
resource-directory-02 [29] CoRE Link Format, IETF Internet Draft,
Z. Shelby, June 15, 2011,
http://tools.ietf.org/html/draft-ietf-core-link-format-06 [30]
Digcovery, www.digcovery.com [31] IoT6 deliverable D3.1,
Look-up/discovery, context-awareness, and resource/services
directory [32] Service Modelling for the Internet of Things, IoT-A,
(http://www.iot-a.eu/public)
contract number: 257521 [33] OWL 2 Web Ontology Language Document
Overview (Second Edition), W3C
Recommendation 11 December 2012,
http://www.w3.org/TR/2012/REC-owl2- overview-20121211/
[34] D. J. Russomanno, C. Kothari, and O. Thomas, "Sensor
ontologies: from shallow to deep models," in Proceedings of the
Thirty-Seventh southeastern Symposium on System Theory, 2005.
[35] J. H. Kim, K. Kwon, K. D.-H, and S. J. Lee, "Building a
service-oriented ontology for wireless sensor networks," in
Proceedings of the Seventh IEEE/ACIS International Conference on
Computer and Information Science, 2008, pp. 649-654.
[36] P. M. Barnaghi, S. Meissner, M. Presser, and K. Moessner,
"Sense and sens'ability: Semantic data modelling for sensor
networks," in Proceedings of the ICT Mobile Summit, 2009.
[37] OMA Next Generation Services Interface V1.0,
http://technical.openmobilealliance.org/Technical/release_program/ngsi_v1_0.aspx
[38] NGSI-9/NGSI-10 information model, http://forge.fi-
ware.eu/plugins/mediawiki/wiki/fiware/index.php/NGSI-9/NGSI-
10_information_model
[39] ElasticSearch, http://www.elasticsearch.org/ [40] DigCovery
Framework Documentation, Pablo Lopez Martinez, David
Fernandez
Ros, Antonio J. Jara Valera, Clinical Technology Lab (CliTech),
Computer Science Faculty, University of Murcia, Murcia, Spain
39
[43] Avahi, http://avahi.org/
[49] Mongo DB, http://www.mongodb.org/
[50] IoT6, deliverable D7.1
[51] IoT6, deliverable 4.2
[52] IoT6, deliverable D5.1
[53] IoT6, deliverable D4.1
[54] WP2 and WP3 demo, IPv6 connectivity and Open Service
Architecture
3.2 Task T1.2 on architecture design
3.3 Structure of the document
4 Existing IoT Architectures
4.2 ETSI M2M high-level architecture view
4.3 FI-WARE architecture view
4.5 IoT Data Semantics and Ontology
5 IoT6 Architecture
5.2.1 Communication functionality group
5.2.1.1 Communication channel model
5.2.2 Resources and services
6.1 IoT6 concrete architecture
6.2 IoT6 Interface Specification
8 References