Content uploaded by Pietro Tedeschi
Author content
All content in this area was uploaded by Pietro Tedeschi on Sep 07, 2018
Content may be subject to copyright.
Interoperation of IoT platforms in confined Smart Spaces
The symbIoTe Smart Space Architecture
G. Carrozzo, M. Pardi
Nextworks srl, Pisa, Italy
{g.carrozzo, m.pardi}@nextworks.it
P. Tedeschi, G. Piro
CNIT, Bari, Italy
{pietro.tedeschi, g.piro}@poliba.it
M. Dobski, K. Leszczyski
PSNC, Pozna´
n, Poland
{mikolaj.dobski,
konrad.leszczynski}@man.poznan.pl
A. Carminati, M. Di Fraia
UNIDATA, Rome, Italy
{a.carminati, m.difraia}@unidata.it
Abstract— The Internet of Things (IoT) today is a large
set of technologies and platforms for sensor and actuation
applications in smart-health, transportation, metering, city and
building management, etc. Most of these IoT platforms are
designed as isolated systems and are distributed across the
composite space of devices, interconnected with complex control
layers, often distributed as cloud services. The H2020 symbIoTe
R&D project originated from the need to design new solutions
and approaches to achieve symbiosis of smart objects across
different IoT environments. In symbIoTe we have developed
novel methodologies to enable federations of vertical IoT silos
and allow various levels of interoperation among IoT platforms,
devices and applications.
This paper describes the architecture of the symbIoTe Smart
Space (SSP), a concept which has been developed by the authors
to cover functions, interfaces, and resources that allow one or
more IoT platforms to provide coordinated services to their
users. The SSP architecture supports discovery for various types
of sensors and actuators, coordinates access to the resources (i.e.
the symbIoTe Devices) and implements security services estab-
lishing trust relationship for the actions on IoT resources. The
SSP solution developed in symbIoTe is being evaluated in some
reference use cases of the project, two of which of particular
interest for the authors: namely, a Smart Residence use case
designed to validate the interoperability across different smart
home IoT solutions, and a Smart Yachting use case designed
to implement the interoperation between the IoT platforms on
yachts and the ones available in marinas.
Index Terms— Internet of Things, Smart Space, Security,
Interoperability, Open-Source
I. INTRODUCTION
The state of the art in Internet of Things (IoT) platforms is
fragmented in a large series of silo solutions. These, on one
hand, integrate connected objects within local environments
(e.g. home, office, etc.) while, on the other hand, connect
smart spaces with their back-end cloud hosting components
[1]. The H2020 symbIoTe project1is working to harmonize
this fragmented environment in order to converge towards an
interoperation framework and architecture for different IoT
platforms. In symbIoTe, various IoT platform federations can
securely interoperate, collaborate and share resources among
SSPs. A Smart Space is an environment where one or more
1H2020 symbIoTe project, symbiosis of smart objects across IoT envi-
ronments - https://www.symbiote-h2020.eu/
IoT platforms coexist, each of them providing some kind
of service. Such environments are typically identifiable by
their physical locations, ranging in size from local to wide
areas. Any device that can directly interact with an SSP is
referenced as a Smart Device (SDEV). It is to be defined
as local device if it establishes a permanent connection with
its origin IoT platform, or as a roaming device if it has the
ability to move across heterogeneous platforms, keeping its
identity.
An SSP acts as a gateway for local resources to the rest of
the symbIoTe environment, i.e. it mediates between the local
composition of IoT platform in a space and the centralized
Core services allowing for registration, search and actuation
on generalized IoT sensors, as well as the IoT applications
which make use of this information. The design of the
SSP and SDEV domains includes functions and mechanisms
handling local resources registration and access. The design
of the symbiote Smart Space Middleware (S3M) has been
influenced by the analysis of the relationships with the Core
and the Cloud components and the complex interactions
of software modules both inside and outside the SSP. The
main technical features of the SSP and SDEV domains
are the dynamic discovery and configuration of resources,
the IoT platform interoperability at the SSP level (platform
transparency), and a set of baseline operations in order to
provide the support for nomadic devices. It is important for
the SSP to be able to provide its functionality even when the
cloud components are not reachable, in order to allow the
user to interact with the SSP in every kind of connectivity
conditions. For example, in the Smart Residence Use Case it
is essential that devices keep working (i.e. they can be read
and they can perform operations) even if it is temporarily
(or even permanently) not possible to communicate with the
Core.
The rest of the paper is organized as follows: Section
II describes the architectural aspects and the features of
SSPs and SDEVs; Section III is devoted to the analysis of
related security aspects and their implications. In Section
IV, we provide some information on the initial SSP code
made publicly available at symbIoTe’s GitHub and initial
tests executed with SSP and SDEV instances in preparation
of large trials. In Section V, we discuss how our symbIoTe
solution is positioned with respect to state of the art of IoT
platforms. Finally, Section VI summarizes the results of this
work and draws conclusions.
II. IOT SMART SPACES AND SMART DEVICES
SymbIoTe SSPs are defined as environments where one
or more IoT platforms provide coordinated services. Such
environments are typically related to a physical space (e.g.
a smart residence), but in the more general case, it’s useful
extend the concept of the SSP to a broader physical space
(e.g. a smart campus or even city).
The main features of the symbIoTe SSP can be sum-
marised in:
•Dynamic discovery and automatic resource configura-
tion;
•IoT platform interoperability at the SSP level;
•Baseline operation even when the cloud components are
not reachable;
•Support for device roaming.
A. The SymbIoTe Smart Space
As depicted in Figure 1, an SSP comprises both of virtual
and physical objects, such as gateways and smart objects. In
order to turn these environments into an SSPs and integrate
them in symbIoTe, we need to deploy proper software
adapters that we refer to as S3M.
The SSP as a whole exposes (i.e. registers) the resources
it contains, regardless of which local IoT platform they
belong to. Therefore, an SDEV associated to the SSP is
exposed directly, that is without being mediated by any
of the local platforms. The symbIoTe-compliant local IoT
platforms within an SSP are able to access the resources
associated with that SSP, provided that the authentication
and authorization policies placed on them are satisfied.
This includes both resources provided by any co/located
IoT platforms and those provided by the locally associated
SDEVs. This way, the interoperability role of symbIoTe
is fully functional also at the SSP level. When more than
one IoT platform is active in an SSP, the S3M thus acts
as a local resource interchange. Since each IoT Platform
manages its own devices according to its internal protocols
(which remains opaque to symbIoTe), discovery and auto-
configuration of those devices is delegated to the Platform
itself. It is the Platform’s duty to register/deregister its
devices with the S3M whenever a change happens. The S3M
then publishes information about the Platform’s devices in
the same way it does for symbIoTe’s SDEVs. Hence, SDEVs
is not distinguishable from the devices of a native platform.
B. IoT platform interoperability at the Smart Space level
One of symbIoTe’s value offerings consists in providing
a common information model, which makes the access and
usage of the registered resources possible in an ecosystem
composed by different IoT platforms. This modelling ap-
proach is pursued to ease the integration and portability
of IoT applications, which do not need to be adapted to
Fig. 1. SymbIoTe Smart Space Architecture.
different information formats whenever some new device
or platform is introduced into the ecosystem. Services and
applications within a given Smart Space are able to access
its resources and platforms transparently, meaning that when
an application searches, accesses and uses certain symbIoTe-
compliant resources within the Smart Space, these are avail-
able and usable under the same information model, regardless
of their origin. Certainly, the service must be authorized
to access these resources. The Core Cloud Domain in the
symbIoTe architecture provides unified and secure access to
platform resources which have been registered within the
symbIoTe core services. Although these functionalities are
very relevant when dealing with cross-domain applications,
there are certain situations where it is beneficial or even
required to work without access to the cloud. While, for
example, applications in the Smart Cities domain are very
dependent on the cloud, other situations, such as Smart Res-
idence applications, operating locally (within a residence),
can run without being controlled by a middleware in the
cloud. Access to the brightness sensors installed in a house
and the ability to handle lamps in a room should not be
dependent on Internet access. In fact, sometimes the Internet
connectivity can be unreliable and security in non-globally
reachable systems is far superior, since breaches such as
man-in-the-middle attacks can be avoided.
C. Architectural mapping to existing IoT platforms
In some specific SSP contexts (e.g. a house or a yacht in
a marina) resource access must be guaranteed and control
must be feasible with a very low latency (e.g. for switching
on a light or opening a door lock). In other contexts (e.g. a
stadium or a campus) this requirement could be less stringent
due to the different types of sensing and control loop to be
applied (e.g control of lightning in large spaces, counting
of crowds, etc.). This turns into a different requirement to
connect to a cloud-based core middleware across the Internet.
In principle, as shown in Figure 2, IoT platforms can be
split in three different categories:
Type A) Fully local platforms;
Type B) Hybrid local/cloud-based platforms;
Type C) Fully cloud-based platforms.
In this categorization, with the ”local” term we identify a
network space which is reachable by a smartphone or PC-
based desktop application in the same Local Area Network
(LAN), or routing domain where the platform components
and resources are located.
Fully local platforms (type-A) are completely isolated
environments, where devices and resources are managed by
local hardware and software components. Users located in
the same environment can access the resources by interacting
directly with those components, with minimum latency and
very limited risk of unavailability. Remote users do not
necessarily have the possibility to access the resources within
the environment: in order for this to be possible, either the
platform must be publicly addressable from the Internet, or
a minimum platform counterpart must be deployed in the
cloud to provide such an access point. This adapter contains
no platform specific functions, and is barely a sort of tunnel
end-point to allow entering the smart space.
Hybrid platforms (type-B), instead, have a more substantial
cloud counterpart, where part of the platform’s functions
is deployed. Functions that are provided by local modules
and functions that are delegated to cloud-based ones are
different, according to the specific IoT platform architecture.
For example, management of the platform’s resources might
be provided by cloud modules, whereas control might be
done by local ones; data storage might be done locally
and synchronized to the cloud, whereas aggregated analytics
might be done in the cloud and so on. Local users connect
either to on-premise or to cloud-based modules, depending
on where the functions they need to use are located; remote
users always connect to cloud-based modules.
Finally, type-C platforms have all of their functions pro-
vided by cloud-based software modules. Physical resources
are controlled directly (in case they are IP-reachable) or
by means of an on-premise gateway. The role of the on-
premise gateway, in this case, is dual with respect to the
lightweight adapter for type-A platforms: this component
can be reduced down to a simple tunnel end-point to allow
for the remote modules to communicate with the local
devices. The three types of platforms can be mapped to the
symbIoTe architecture by properly positioning the symbIoTe
interworking interface:
A. for type-A platforms, all the information related to the
platform is known only by modules located in the same
smart space where the IoT platform resides. So, that’s
where the interworking interface needs to be placed.
Examples of platform of this category include: Samsung
SmartThings 2, AllSeen / Open Connectivity Foundation
2Samsung SmartThings - https://www.smartthings.com/
3, Symphony 4by Nextworks (when in stand-alone
mode)
B. for type-B platforms, where information is split across
local and cloud modules, the interworking interface
needs to be split as well. This depends completely on
the architecture of the IoT platform. Examples of plat-
form of this category include: Symphony by Nextworks
(when deployed with cloud services)
C. for type-C platforms, of course, the interworking inter-
face are located in the cloud. Examples in this category
include: products built with Microsoft Azure IoT Suite,
most vehicular fleet tracking systems.
D. The symbIoTe Smart Devices
In symbIoTe an SDEV is any type of device (small sen-
sor/actuators or group of them) using the symbIoTe SDEV
interface. This interface is designed to be lightweight, which
is the key to let resources-constrained devices to operate in
a complex environment such as symbIoTe’s. The reference
symbIoTe SDEV interface has to implement the following
features: i) authentication and authorization; ii) joining the
SSP; iii) read/write sensor, iv) keep-alive.
It is worth noticing that an SDEV does not necessarily map
to a small constrained device; in fact, the aforementioned
SDEV interface can be exported by a medium/large IoT
gateway used to exchange resources and information with
the symbIoTe ecosystem from, e.g. a LoRa network [2].
On the architecture side, SDEVs do not a standard. Sym-
bIoTe’s flexibility allows any kind of device implementing
its interface to join and become part of the ecosystem. Any
symbIoTe SDEV architecture may be summarized in the fol-
lowing components: a core module which allows the device
to function and a symbIoTe SDEV interface which introduces
the devices in the symbIoTe ecosystem. The key part of the
interoperability is the latter component: the agent. This piece
of software realises a series of interfaces to talk with the INK
for the registration inside the SSP and between the RAP
for the exchange of the information coming from sensor
and the eventually needs of actuation of some resources;
the agent, thus, maps the internal buses that take/actuate
these resources and expose them as understandable by the
symbIoTe ecosystem. It is worth noting that an SDEV is not
necessarily a small constrained device, and that the interface
defined in symbIoTe allows also to let medium/large IoT
gateways exchange services with the symbIoTe ecosystem.
The price a gateway implementing the SDEV interface must
pay is the fact that they cannot have a fine granularity in
access permission.
E. Devices roaming and symbIoTe Level 3 and Level 4
compliance
An interesting feature supported by SDEVs is the possi-
bility to roam from a smart space to another. In fact, once
object identities are registered in the symbIoTe system, these
objects can roam from a smart space to another and, by
3AllSeen / Open Connectivity Foundation - https://allseenalliance.org/
4Symphony - https://www.nextworks.it/en/products/brands/symphony
Fig. 2. Different categories of IoT platforms.
Fig. 3. SymbIoTe compliance levels.
maintaining their identities, be uniquely recognized inside
the ecosystem. An example of roaming IoT object could be
a personal health monitoring device, usually registered in
the home smart space, that can continue to communicate
its health data also when brought outside the origin IoT
platform, e.g. in a gym.
symbIoTe’s has designed four levels of compliance to its
services for IoT platforms. Of these levels, the two lowers are
reserved to the smart space operating devices. Compliance
Level 3 (L3) defines a standard which the smart devices
and smart platforms must meet to be attached to a SSP
and be dynamically configured (i.e. registered to a symbIoTe
SSP middleware and thus become searchable and accessible).
Level 4 (L4) compliance includes all the L3 statements,
and permits the SDEV to roam across different SSPs being
recognized as the same object it was before.
Device identity is the main characterizing aspect of an
L4 SDEV: if the device can be uniquely recognized in-
dependently of the SSP it is connected to, it can actually
roam across SSPs. Otherwise, there is no way to distinguish
the aforementioned device from another ’identical’ device.
Maintaining identity only makes sense if there is a service
or an application which needs to track the device, either
because it is associated with a specific service or user, or
because the history of the device is meaningful for the
purpose it is used for. The only strict requirement for an
SDEV to be L4-compliant, thus, is having a unique identifier
(e.g. Media Access Control (MAC) address or symbIoTe-
generated Universally Unique Identifier (UUID)). The choice
of using the SDEV as an L3 or L4 device, though, is up to the
specific service and may even change over time, as the SDEV
is being used for different purposes. Hence, an L4-compliant
SDEV does not necessarily always roam. An example of
roaming IoT object could be a personal health monitoring
device, usually registered in the home smart space, that can
continue to communicate its health data also when brought
outside the origin IoT area, e.g. in a gym.
III. SECURITY IMPLICATIONS
According to the standard security services defined in
X.800 [3], the targeted security services for the SSP, imple-
mented between SDEV, IoT Platforms, User/Application(s)
and Gateway/Innkeeper, include:
•Algorithm Negotiation;
•Peer Authentication and Authorization;
•Key Agreement;
•Protection from attacks, including replay;
•Data Confidentiality/Authentication/Integrity.
SDEV
Agent
IoT
Platform
Agent
INK
RAP
(with access
policies)
SAAM
(with users’
details)
SSP Midd leware
User/App
Core Services
IoT
Platform
Agent
Own
AuthZ
Module
Fig. 4. SSP High Level Security Architecture.
The SSP security architecture depicted in Figure 4, is
under the control by the SSP owner. SSP middleware in-
tegrates the functionalities of Innkeeper (INK), Resource
Access Proxy (RAP) and SSP Authentication and Autho-
rization Manager (SAAM). From one side Core Services
and User/Application(s) are defined, while from the other
side, SDEVs and IoT Platforms are exposed. SSP middleware
exposes resources of:
•SDEVs, directly connected to the middleware;
•IoT platforms governed by the SSP owner;
•IoT platforms governed by third-party entities.
SDEV and IoT Platforms can interact with the SSP
middleware through an agent. The SSP owner is able to
configure the SSP itself, including resource access policies
in the RAP and the users database in the SAAM. Since the
SSP also integrates IoT platform controlled by third-party
entities, the middleware introduces proxy functionalities for
handling access control mechanisms. Furthermore, the SSP
and its resources management procedures is coherent with
the rest of the symbIoTe ecosystem. This introduces addi-
tional challenges due to limited computational resources on
SDEVs and their ability to roam between SSPs. Finally, the
resources need to be accessible by existing symbIoTe clients,
which implies no or limited changes to the existing resource
access Application Programming Interfaces (APIs).
To manage the security aspects within the SSP various
aspects needs to be considered, as detailed in the following
subsections.
A. System Configuration
The SSP owners can create users (e.g. by defining user-
name and password, or by exposing the securuser registration
form) and assigns their permission properties according to
the Attribute Based Access Control (ABAC) paradigm [4]
in the SAAM. For resources under the SSP control, the
SSP owner defines access policies in the RAP in order to
permit or deny access to particular resources. Such resources
are available only to users registered in the particular SSP.
For resources governed by the IoT platforms themselves,
symbIoTe offers a challenge-response procedure inspired
approach where the clients need to deliver a hashed secret
as described in III-B.
B. Clients Authentication and Authorization
Security services provided for the users and applications,
are defined by reusing the conventional symbIoTe Level
1 (L1) and Level 2 (L2) [5] security functionalities. For
resources with access governed by the SSP owner:
•The user gets its Home Token from the SAAM he has
registered and possess an account in;
•Delivers a Security Request containing the aforemen-
tioned token along with its ownership proof (described
in L1 and L2 as challenge-response payloads) to the
RAP in the SSP middleware;
•RAP verifies locally that the token is authentic (also
offline) and that the client is authorized to possess it
(authentication challenge);
•RAP verifies in the SAAM if any of the security
credentials presented by the client (the token or its
certificate) were not revoked;
•Resource access is granted if the set of attributes
matches the access policy stored for it.
For resources governed by the IoT platform itself:
•The client requests a guest token from the SAAM;
•delivers to the SSP’s RAP a L3 specific extended
security request which apart from the guest token must
contain a hashed secret. The hash consists of a times-
tamp and the secret concatenated together;
•The secret must be known by the client and the IoT
platform. SymbIoTe must not know about the secret as
it only offers reference hashing method;
•After SSP’s RAP verifies the guest token, it forwards the
aforementioned hash to the Platform Agent where the
final authorization check is done by the Platform Agent
(PA) recreating the hash and verifying if it matches with
the received value.
Should the IoT platform offer different secrets to its
clients, symbIoTe security request also support a placeholder
for the IoT platform client identifier.
C. Security services between SSP middleware and SDEV
The HyperText Transfer Protocol (HTTP) protocol [6] is
used at the application layer. But Transport Layer Security
(TLS)-based solutions [7] cannot be used in this context. In
fact, constrained devices belonging to the smart space present
limited processing power, storage space, and transmission
capabilities. Lightweight solutions natively conceived for
Constrained Application Protocol (CoAP) [8] cannot be
directly applied in this case. For this reason, a new approach
is designed for symbIoTe in order to provide data confiden-
tiality, integrity and authenticity.
A lightweight protocol depicted in Figure 5 to support the
aforementioned security requirements has been proposed. It
includes the following main phases: i) Peer configuration
provided by the Network Administrator; ii) Negotiation of
cryptographic techniques; iii) Key agreement and iv) Mutual
Peer Authentication.
SDEV
PEER
CONFIGURATION
PEER
CONFIGURATION
SDEV HELLO
(Crypto Proposal with Key Material)
KEY DERIVATION
FUNCTION
KEY DERIVATION
FUNCTION
GW_INK HELLO
(Crypto Choi ce with Key Materia l)
UPDATE OF
SECUR ITY
CONTEXT
UPDATE OF
SECUR ITY
CONTEXT
SDEV AuthN
(encrypted Hash of p revious messages)
GW_INK AuthN
(encrypted Hash of previous messages)
INNKEEP ER / GW
Fig. 5. Lightweight Security Protocol for SSPs.
The protocol ensures a secure interaction: negotiated se-
crets is unavailable to eavesdroppers, even by an attacker who
can place himself in the middle of the connection. Moreover,
in the case the protocol ends successfully, communicating
peers can protect their communication through symmetric
cryptography (e.g., AES, ChaCha20) [9][5], and reliable
mechanisms (i.e., messages include an authentication tag
which protects them against tampering). Indeed, the protocol
provides in output all the details needed to support data
confidentiality, data authentication and data integrity.
In order to protect the data communication between mid-
dleware and IoT Platforms, TLS protocol results the best
choice to achieve and guarantee data confidentiality, integrity,
and authenticity requirements.
D. L3 and L4 resources in the symbIoTe ecosystem
At the roots of symbIoTe’s resources governance lies the
requirement that each of them belongs to a trusted party
exposing its data and/or actuation. The trust comes hence
from the services that are registered in Core - platforms,
enablers and smart spaces - and the verification of their
owners. As such SSP resources - denoted as L3 resources
participate in the environment on behalf of the SSP they
reside in. It is the responsibility of the SSP owner to first
verify his resources and yet after accept their registration
in the SSP Registry (and should they need to be resolvable
and accessible from the Internet also in the Core). Roaming
resources - denoted as L4 resource are however a novelty to
the evolving symbIoTe environment. They are self-governed
and belong to no particular service permanently. Further-
more, they have limited computational power and their added
values come from true Machine 2 Machine (M2M) roaming
protocols [10]. In order to satisfy the existing principles
of trust in symbIoTe an L4 SDEVs needs to support two
scenarios:
Initial Registration. In this procedure, it is the SSP
owner’s, who first comes into contact with an L4 SDEV,
responsibility to verify the device, prepare its description
and register it in the Core Registry. From that moment
the SDEV is given an identifier unique within the whole
symbIoTe ecosystem. Moreover, the Core is notified of the
device’s communication key which allows it to interact with
the aforementioned SSP. Last but not least, the INK notifies
the Core if an L4 device is still present within that SSP
(by utilizing a heartbeat protocol) or needs to be marked as
absent/unreachable by the SSP middleware.
Roaming. When an already registered and configured
L4 SDEV roams from one SSP to another, it provides
to the new SSP its identifier and a hash of it with the
communication key it used in its former SSP. With that
information, the new SSP is able to query the core for the
device’s description and communication key. This challenge
also allows the SSP to confirm that the device is genuine as
only the communications key is known only by the device,
the Core and the previous SSP which was harboring it. Upon
a successful challenge verification in the Core, the INK is
given the device’s communication key and can confirm the
roaming procedure to the SDEV. It is also important that
in this procedure the INK updates the SDEV’s description
in the Core with the new key the device is using within the
current SSP and the address under which the device will now
be available. Changing the device’s key upon each roaming
is crucial so that SSPs the device has roamed into formerly
will lose authority to govern that SDEV.
Last but not least designating the SDEV as L4 only allows
it to request roaming but the ultimate decision to accept or
decline a roaming request lies with the SSP owner.
IV. SYMBIOTESMA RT SPACE IMPLEMENTATION
The realization of the software for the SSP described in
the previous sections, allows to integrate locally available
devices or IoT platforms. Its implementation provides the
following functions:
•interface with the symbIoTe Core components, to ex-
pose local devices resources for queries and actuation;
•interact with local smart devices and platforms to pro-
vide means to connect and share new resources;
•maintain certain degree of autonomy allowing the local
IoT middleware to function also in case of no Internet
connection.
As already mentioned, Smart Space is designed to be im-
plemented by three main components: the Innkeeper (INK),
the Resource Access Proxy (RAP) and Smart Space AAM
(SAAM) each one performing specific tasks as detailed
below. Other components related to the SSP are: the RAP
gateway (allowing access to local resources for clients that
are outside the SSP) and the Platform and symbIoTe agents
(the internal interface towards the SSP).
A. Innkeeper
The INK is the component in charge to receive registration
from devices/platforms agents. It keeps the consistency of
the Smart Space resources and communicates to the RAP
for their reachability. It is in charge of communicating with
L3/L4-compliant applications and devices in order to enable
their registration and interaction with the SSP. It mainly
fills the role of a local registry in the SSP, providing a list
of applications and devices currently registered in the SSP.
Furthermore, it provides information about the SSP devices
such as the current status and location. Innkeeper is also
required for interaction with upper layers. Specifically, it is
in charge to communicate with the core level components to
let the Smart Space integrate with the rest of the symbIoTe
ecosystem and it updates information (e.g. location) of
L4 roaming devices in upper layers. Moreover, Innkeeper
exposes an interface for application to get a list of the public
resources of the SSP itself.
B. Resource Access Proxy
The RAP receives and forwards request from and to the
Smart Space. It is in charge for directing request to the
intended resources and to reply to the applications with data
coming from these resources. RAP exposes Data interfaces
for direct resources access and an additional interface is
used for push mechanism, where notifications are sent via
WebSocket to the client application.
C. Smart Space AAM
SAAM is the guarantor of the symbIoTe security within
the Smart Space. It enables the core-centric security function
while Internet connection is established, but it becomes
Smart Space-centric when no Internet connection is avail-
able. The SAAM logic will allow to satisfy L1 compliance
requirements - common ecosystem security scheme - trust
chaining for mutual authentication in the whole ecosystem
as well as SSP actors attributes / resources management
features.
D. RAP Gateway
As the name might suggest, this component acts as a
gateway, allowing access to local resources for clients and
applications that are outside the SSP. Basically, it establishes
a tunnel connection to the Smart Space local network,
providing an access point for resources to be addressable
from outside the SSP.
E. symbIoTe Agent
The symbIoTe agent is the adaptation layer that handles
communications between the SSP and the SDEV or the
Platform. It acts as a translator between the custom language
talked by the specific resource and the symbIoTe ecosystem.
Every platform or Smart Device that wants to be symbIoTe
compliant at SSP level needs to implement this module on
their platform side. To reach this scope, the agent uses a well-
defined communication protocol to talk with the Innkeeper
(for resource registration) and RAP (for resource access).
The Smart Space Middleware and all its features has been
validated in a laboratory trial made of an Intel NUC Mini
PC, which was hosting the deployment of the S3M, and
an Arduino ESP8266 device, with temperature and pressure
sensors and a RGB led on board. An iOS application, running
on an iPhone 6x, has been used to control of the IoT device
via Wi-Fi.
A well-known SSID is created by the S3M gateway in
order to enable the automatic connection of the SDEV to the
Smart Space: at power on, the device will search a specific
Wi-Fi network (sym-[SSP-WiFi-ID]). After connecting, the
lightweight security protocol enables a secured communi-
cation channel between the SDEV and the S3M, thus the
registration procedure can start.
Fig. 6. iOS App Sensor View.
At this point, the iOS application retrieves the list of
the public resources from the INK and allows the user to
navigate into different graphical interfaces for reading the
sensors (see Figure 6) and control the actuators (see Figure
7).
The SSP software is delivered as open source on GitHub5.
V. POSITIONING OF SSP IN IOTSTATE OF THE ART
The symbIoTe approach and architecture presented in
this paper is in line with some relevant reference architec-
tures for IoT systems like those developed by AIOTI [11]
and IoT-A [12]. In fact, interfaces defined in AIOTI HLA
can be mapped into the symbIoTe functional components,
and the IoT-A functional groups have their counterparts in
symbIoTe components. The key innovation we produce via
symbIoTe is in offering of device discovery, look-up, and
name resolution across different IoT platforms without the
need to embrace/implement these reference architectures, but
rather decide to expose IoT resources from various platforms
through REST-based interfaces. The symbIoTe architecture
also extends the oneM2M functional architecture [13], with
aspects that related to platform federations, bartering and
5Smart Space Middleware Software - https://github.com/symbiote-
h2020/SymbioteSmartSpace
Fig. 7. iOS App Actuator View.
trading, further made available beyond the Cloud Domain to
cover also SSPs to share resources with third-party applica-
tions. When comparing symbIoTe to other research projects
in the same IoT scope, another specific element of innovation
and peculiarity emerges in the approach to interoperability.
Projects such as CRYSTAL[14], iCore [15] and FIESTA-IOT
[16] have worked on syntactic and semantic interoperability
of IoT platforms, but not supporting IoT Federations for
secure interoperation, collaboration and sharing of resources
between two platforms, as well as IoT Device Roaming.
Other relevant differences are in data to be stored for
interoperability: e.g while iCore stores the data provided by
platform devices, symbIoTe in all its layers, including SSPs
stores only their metadata required for effective search.
VI. CONCLUSIONS
This paper has presented the key design principles of
the SymbIoTe Smart Space architecture defined in the
context of the H2020 symbIoTe project. The SSP pro-
vides generalized device discovery and coordinated ac-
cess (read/write) to resources belonging to different fed-
erated IoT platforms. The SSP and SDEV concepts we
described have been implemented as open source software
publicly accessible at GitHub at https://github.com/symbiote-
h2020/SmartSpaceMiddleware. The SSP and SDEV software
are also used to validate the proposed architecture in a Smart
Residence scenario designed to verify the interoperability of
different IoT platforms in the smart Home (i.e. based on
Symphony by Nextworks and KIT by AIT6), and in a Smart
6Keep In Touch (KIT) Telehealth Solutions -
https://kit.ait.ac.at/technology/plattform/
Yachting use case designed to implement the interoperation
of the IoT platforms of the Yachts (based on Symphony by
Nextworks) and the platform at the Port (based on NAVIGO
DIGITALE by Navigo7). Results of our trials are expected
by Q4/2018.
ACKNOWLEDGMENT
This work is supported by the H2020 symbIoTe project,
funded within the EU Horizon 2020 framework programme
under grant agreement No 688156. Authors thank specifi-
cally G. Insolvibile, G. Boggia, J. Toczek and P. Pisani for
their contributions to this work, and the entire symbIoTe
consortium for the useful discussions on SSP design.
REFERENCES
[1] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and
M. Ayyash, “Internet of things: A survey on enabling technologies,
protocols, and applications,” IEEE Communications Surveys Tutorials,
vol. 17, no. 4, pp. 2347–2376, Fourthquarter 2015.
[2] A. Lavric and V. Popa, “Internet of Things and LoRa; Low-Power
Wide-Area Networks: A survey,” in 2017 International Symposium
on Signals, Circuits and Systems (ISSCS), July 2017, pp. 1–5.
[3] I. Rec, “X. 800 security architecture for open systems interconnection
for ccitt applications,” ITU-T (CCITT) Recommendation, 1991.
[4] V. C. Hu, D. Ferraiolo, R. Kuhn, A. R. Friedman, A. J. Lang, M. M.
Cogdell, A. Schnitzer, K. Sandlin, R. Miller, K. Scarfone et al., “Guide
to attribute based access control (ABAC) definition and considerations
(draft),” NIST special publication, vol. 800, no. 162, 2013.
[5] Joaquin Iranzo Yuste, J. A. Sanchez, Joao Garcia, P. Tedeschi,
G. Piro, G. Boggia, G. Bianchi, Micha Pilc, Mikoaj Dobski,
V. Glykantzis, C. Ruggenthaler, and P. Skocir, “D3.2 - resource
trading, security and federation mechanisms,” 2018. [Online].
Available: https://zenodo.org/record/1135955
[6] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach,
and T. Berners-Lee, “Hypertext transfer protocol–http/1.1,” 1999.
[7] T. Dierks, “The transport layer security (tls) protocol version 1.2,”
2008.
[8] Z. Shelby, K. Hartke, and C. Bormann, “The constrained application
protocol (CoAP),” 2014.
[9] S. William, Cryptography and network security: principles and prac-
tices. Pearson Education India, 2006.
[10] G. Wu, S. Talwar, K. Johnsson, N. Himayat, and K. D. Johnson,
“M2M: From mobile to embedded internet,” IEEE Communications
Magazine, vol. 49, no. 4, 2011.
[11] P. Murdock and O. Elloumi, “AIOTI high level architecture, release
2.1,” 2016.
[12] “IoT-A deliverable d1.5 final architectural reference model for the iot
v3.0,” 2013.
[13] ETSI, “onem2m. m2m functional architecture. technical specifica-
tion, url: http://www.onem2m.org/images/files/deliverables/TS-0001-
FunctionalArchitecture −V16 1.pdf,00 2015.
[14] “CRYSTAL critical system engineering acceleration, url:
http://www.crystal-artemis.eu/, access: September 2018.”
[15] “iCore project. deliverable d2.3 architecture reference model. technical
specification,” 2013.
[16] “FIESTA-IOT project. federated interoperable semantic iot testbeds
and applications, url:http://fiesta-iot.eu/, access: September 2018.”
7NaVIGO Digitale, management of digital assets and services for boat-
ing and yachting - http://www.navigotoscana.it/port-net-sistema-digitale-del-
porto-viareggio/
