project number: 723156 project acronym: wise-iot project...
TRANSCRIPT
D1.3
WISE IoT updated high level architecture
and reference technologies and standards
Editor: Martin Bauer (NECLE, EU) / SeungMyeong Jeong (KETI, KR)
Submission date: 04/07/18
Version 1.0
Contact: [email protected] / [email protected]
This deliverable will provide the final architecture of Wise-IoT concept and specific pilots. A
detailed technology plan will help forthcoming initiatives to choose optimum infrastructures
and technologies.
Project Number: 723156
Project Acronym: Wise-IoT
Project title: Worldwide Interoperability for SEmantics IoT
Editor: Martin Bauer, NEC Europe Ltd., [email protected]
SeungMyeong Jeong, KETI, [email protected]
Deliverable nature: R
Dissemination level: PU
Contractual/actual delivery date: M24 M25
Disclaimer
This document contains material, which is the copyright of certain Wise-IoT consortium parties, and may
not be reproduced or copied without permission.
All Wise-IoT consortium parties have agreed to full publication of this document.
The commercial use of any information contained in this document may require a license from the
proprietor of that information.
Neither the Wise-IoT consortium as a whole, nor a certain part of the WISE-IOT consortium, warrant
that the information contained in this document is capable of use, nor that use of the information is free
from risk, accepting no liability for loss or damage suffered by any person using this information.
This project has received funding from the European Union’s H2020 Programme for research,
technological development and demonstration under grant agreement No 723156, the Swiss State
Secretariat for Education, Research and Innovation (SERI) and the South-Korean Institute for Information
& Communications Technology Promotion (IITP).
Copyright notice
2018 Participants in project Wise-IoT
Table of contents
Executive summary _________________________________________ 5
Authors ______________________________________________________ 6
Glossary _____________________________________________________ 8
1 Introduction _____________________________________________ 10
2 High-Level Architecture _________________________________ 12
2.1 High-level Architecture Requirements ________________________ 12
2.2 Layered Architecture View ____________________________________ 15
2.2.1 Data Collection and Device Actuation Layer ____________________ 15
2.2.2 Integration and Management Layer ______________________________ 16
2.2.3 Information Access Layer ________________________________________ 16
2.2.4 Knowledge Processing Layer ____________________________________ 16
2.2.5 Application Layer _________________________________________________ 16
2.3 Deployment View and Federated Architecture ________________ 17
2.4 Semantics Perspective ________________________________________ 18
2.5 Trust Perspective ______________________________________________ 19
2.6 Security Perspective ___________________________________________ 20
2.7 Self-Adaptation and Evolution Perspective ___________________ 20
2.8 Wise-IoT System Definition ____________________________________ 23
3 Technology Plan: Protocols, Standards and Technologies
25
3.1 Mapping Layers to Technologies ______________________________ 25
3.2 Data Collection and Device Actuation Layer __________________ 27
3.2.1 GS1 ________________________________________________________________ 27
3.2.2 Eclipse sensiNact ________________________________________________ 31
3.2.3 Open Connectivity Foundation (OCF) ____________________________ 33
3.2.4 LoRa ______________________________________________________________ 35
3.2.5 Z-Wave ____________________________________________________________ 35
3.3 Integration and Management Layer ___________________________ 37
3.3.1 oneM2M Platform _________________________________________________ 37
3.3.2 Wise-IoT Morphing Mediation Gateway __________________________ 40
3.4 Information Access Layer _____________________________________ 43
3.4.1 FIWARE Generic Enablers ________________________________________ 43
3.4.2 OAuth-based Framework for Wise-IoT ___________________________ 52
3.5 Knowledge Processing Layer __________________________________ 54
3.5.1 Wise-IoT Self-Adaptive Recommender ___________________________ 54
3.5.2 Wise-IoT Trust Monitor ___________________________________________ 58
4 Pilot Site Deployments __________________________________ 61
4.1 Smart City Use Cases __________________________________________ 61
4.1.1 Santander Smart City Use Cases Architecture __________________ 62
4.1.2 Busan Smart Parking Use Case Architecture ___________________ 64
4.1.3 Busan Bus Information Use Case Architecture __________________ 65
4.2 Smart Skiing Use Cases _______________________________________ 66
4.2.1 Chamrousse Smart Skiing Use Case Architecture ______________ 66
4.2.2 PyeongChang Smart Skiing Use Case Architecture _____________ 68
4.3 Lifestyle Use Cases ____________________________________________ 68
4.3.1 Daegu Lifestyle Use Case Architecture _________________________ 69
4.4 Service Roaming and Cross-Domain Data Reuse Use Case __ 72
4.4.1 Federation Technical Use Case Architecture ___________________ 72
5 Conclusions _____________________________________________ 75
6 References ______________________________________________ 76
Executive summary
This deliverable provides an update of the Wise-IoT Architecture. It is structured in three main parts: the
high-level architecture; the technology plan covering protocols, standards, technology & Wise-IoT
components; and finally the concrete instantiation of the architecture in the Wise-IoT pilot site
deployments supporting the Wise-IoT use cases in the areas of smart city, smart skiing and lifestyle.
As a first step the high-level Wise-IoT architecture requirements are identified in the context of the main
overall Wise-IoT project objectives. The high-level architecture in general is based on the approach
specified in the ISO/IEC/IEEE 42010 standard for describing architectures that proposes different
architectural views and models. The most important view of the high-level Wise-IoT architecture is the
Layered Architecture View. It is motivated by the observation that typically different enablers have been
designed to support the respective functionalities on the respective abstraction layers. In Wise-IoT, the
aim is to choose standardized enablers that are best suited for the particular task and connecting them
in a suitable way to combine the particular stengths while mitigating possible weaknesses. The
Deployment View and Federated Architecture looks at the typical deployment options for IoT system
components, i.e. on devices, on the edge or in the infrastructure/cloud. The Semantics Perspective
discusses the use of semantic information across the whole IoT system. The Trust Perspective describes
the role of trust across the IoT system. The Security Perspective looks at how security requirements can
be fullfiled throughout the IoT system. Finally, the Self-Adaptation and Evolution Perspective discusses
how, as the result of monitoring the usage of the system, it can self-adapt and support engineers in the
evolution of the system. The Wise-IoT system is defined as a system that instantiates the Wise-IoT
architecture and it is discussed how such a system fullfils the previously defined Wise-IoT architecture
requirements.
The technology plan describes which protocols, standards, technologies and components are used in
Wise-IoT and how and where they fit into the high-level architecture, in particular in what layer(s) they
can be used. The technologies discussed range from general IoT platforms like oneM2M and FIWARE to
more specialized or domain-specifc platformslike GS1, sensiNact and OCF. These are followed by
concrete communication technologies like LoRa and Z-Wave. Finally, the architectural aspects of some
important components like the Self-Adaptive Recommender and the Trust Monitor are presented.
The Pilot Site Deployments show how the high-level architecture is instantiated in the different pilot
sites and which technologies, protocols, standards and components from the technology plan are used
in each deployment. The deployment architectures discussed are the smart city architectures in
Santander and Busan including the parking and bus use cases, the smart skiing architectures in
Chamrousse and Alpensia, the lifestyle use case architecture and finally the service roaming and cross-
domain use case that has been validated as Federation Technical Use Case.
Authors
Section Author (Organisation)
Executive Summary Martin Bauer (NECLE)
1 – Introduction Franck Le Gall (EGM)
2 – High-level Architecture Martin Bauer (NECLE)
2.1 High-level Architecture Requirements Martin Bauer (NECLE)
2.2 Layered Architecture View Martin Bauer (NECLE)
2.3 Deployment View and Federated Architecture Martin Bauer (NECLE)
2.4 Semantic Perspective Martin Bauer (NECLE)
2.5 Trust Perspective Abayomi Otebolaku (LJMU)
2.6 Security Perspective Se-Ra Oh (SJU)
2.7 Self-Adaptation and Evolution Perspective Dustin Wüest (FHNW)
2.8 Wise-IoT System Definition Martin Bauer (NECLE)
3 Technology Plan: Protocols, Standards and Technologies Martin Bauer (NECLE)
3.1 Mapping Layers to Technologies Martin Bauer (NECLE)
3.2 Data Collection and Device Actuation Layer Haris Aftab (SJU)
3.2.1 GS1 Yalew Kidane (KAIST)
3.2.2 sensiNact Rémi Druilhe (CEA)
3.2.3 Open Connectivity Foundation (OCF) SeungMyeong Jeong (KETI)
3.2.4 LoRa SeungMyeong Jeong (KETI)
3.2.5 Z-Wave Haris Aftab (SJU)
3.3. Integration and Management Layer SeungMyeong Jeong (KETI)
3.3.1 oneM2M Platform SeungMyeong Jeong (KETI)
3.3.1.1 oneM2M Security Component Se-Ra Oh(SJU)
3.3.2 Wise-IoT Morphing Mediation Gateway Martin Bauer (NECLE)
3.4 Information Access Layer Martin Bauer (NECLE)
3.4.1 FIWARE Generic Enablers Martin Bauer (NECLE)
3.4.2 OAuth-based Framework for Wise-IoT Hamza Baqa (EGM)
3.4.2.1 FIWARE Security Se-Ra Oh(SJU)
3.5 Knowledge Processing Layer Dustin Wüest (FHNW)
3.5.1 Wise-IoT Self-Adaptive Recommender Dustin Wüest (FHNW)
3.5.2 Wise-IoT Trust Monitor Abayomi Otebolaku (LJMU)
4 Pilot Site Deployments Martin Bauer (NECLE)
4.1 Smart City Use Cases Carmen López (UC)
4.1.1 Santander Smart City Use Cases Architecture Carmen López (UC)
4.1.2 Busan Smart Parking Use Case Architecture SeungMyeong Jeong (KETI)
4.1.3 Busan Bus Information Use Case Architecture Minh Hoang Nguyen (KAIST)
4.2 Smart Skiing Use Cases Martin Bauer (NECLE)
4.2.1 Chamrousse Smart Skiing Use Case Architecture Rémi Druilhe (CEA)
4.2.2 Alpensia Smart Skiing Use Case Architecture Hyokeun Choi (SDS)
4.3 Lifestyle Use Cases Cheolwoo Jung (KNU)
4.3.1 Daegu Lifestyle Use Case Architecture Cheolwoo Jung (KNU)
4.4 Service Roaming and Cross-Domain Data Reuse Use Case Martin Bauer (NECLE)
5 Conclusions Martin Bauer (NECLE)
Glossary
Term or Abbreviation Definition (Source)
AIOTI Alliance for Internet of Things Innovation
ALE Application Level Events
API Application programming interface
ASM Adaptive Semantic Module
CAG Context-Aware Auxiliary Gateway
CMC Context Management Component
DS Discovery Service
EPC Electronic Product Code
EPCIS Electronic Product Code Information Services
GE Generic Enabler (FIWARE)
GIoTS Global IoT Services
GPC Global Product Classification (GS1)
GW Gateway
HLA AIOTI High-Level Architecture
IAL Information Access Layer
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
IoT Internet of Things
ISO International Organization for Standardization
ISO/IEC JTC1 ISO/IEC Joint Technical Committee 1
ITU International Telecommunication Union
LLRP Low Level Reader Protocol (GS1)
LoRa(WAN) Long Range Wide Area Network
M2M machine-to-machine
MMG Morphing Mediation Gateway
NGSI NGSI Next Generation Service Interfaces (OMA), in the context
of this project referring to the NGSI Context Interfaces,
numbered NGSI-9 and NGSI-10.
OCF Open Connectivity Foundation
OMA Open Mobile Alliance
ONS Object Naming System
PAN Personal Area Network
QoI Quality of Information
REST REpresentational State Transfer
SAR Self-Adaptive Recommender
WAN Wide Area Network
Introduction
10
1 Introduction
An increasing number of devices is getting deployed in the cities, whatever their size is. These
deployments are today often driven by regulation obligations or security concerns. A simple example is
the monitoring of indoor air quality, being an obligation in many countries (e.g. France (Décret n° 2015-
1926 du 30 décembre 2015 modifiant le décret n° 2012-14 du 5 janvier 2012 relatif à l'évaluation des
moyens d'aération et à la mesure des polluants effectuées au titre de la surveillance de la qualité de l'air
intérieur de certains établiss)). To comply with this obligation, public procurement is being launched by
the cities which get in return attractive offers from companies proposing solutions such as LoRaWAN
sensors connected to a proprietary web-based dashboard. Such a simple offer appears at first glance
cost efficient and easy to deploy. However, it appears from direct contact with cities managers during
the Wise-IoT trials that they start questioning the long-term sustainability of such an approach which
multiply deployment of vertical siloes and break the IoT paradigm. On the other side, researchers and
technologists in the IoT field have been working over the past years to solve the interoperability issue
of the IoT paradigm and as a consequence, many standards and IoT platforms, either open or
proprietary, have emerged. Unfortunately, this multiplication still does not help the city managers which
are getting lost in the market offer while perceiving the underlying issues. This holds particularly true in
small and medium size cities which do not have the large IT teams able to devote the necessary time to
understand the market offering. In addition, cities are often grouped over a certain area, building
territories, having to share some services (i.e. public, transportation).
The Wise-IoT project made in its first period an analysis of high level architectures proposed by several
standard organisations and Alliances (Wise-IoT D1.2 - Wise-IoT high level architecture and reference
technologies and standards, 2017). It resulted in a simplified 5 layers approach over which the analysed
high-level architectures can be mapped. This approach, despite having been kept simple to ease
understanding by non-experts, considers also connectivity between IoT and data enrichment (big data,
AI) domains, through a context information layer as well as multi-domain federation.
During the second period of the project, the proposed high-level architecture has been tested within
field trials. Lessons learnt are described in this D1.3 document intended to be a guideline for
administration willing to deploy an IoT infrastructure.
The document is structured as follows:
Section 2 reminds about the Wise-IoT high-level architecture. This section includes updates made over
the first version, justified by findings obtained within the field trials.
Section 3 describes several potential technologies and standards which can be used for actual
implementation of the Wise-IoT architecture.
Section 4 illustrates the use of these technologies within different use cases to help the reader to
understand the Wise-IoT architecture.
This document is an evolution of the content of D1.2 (Wise-IoT D1.2 - Wise-IoT high level architecture
and reference technologies and standards, 2017). To be self-contained and complete, some material
from D1.2 has been kept with limited changes. In some sections, where there have been significant
updates, a short description in italics at the beginning of the section explains what has changed
compared to D1.2.
Introduction
11
High-Level Architecture
12
2 High-Level Architecture
In this chapter, the Wise-IoT high-level architecture is described. The Wise-IoT high-level architecture
describes the important functional and non-functional aspects that need to be fulfilled to achieve the
main project objectives. It represents a reference architecture that then needs to be instantiated with
concrete components developed based on specific technologies to result in a system architecture. The
technologies and components that have been selected in Wise-IoT – either explicitly or they happened
to be already deployed on a certain site – are presented in Section 3. A specical focus in Wise-IoT was to
select solutions based on international standards and use semantic information to achieve semantic
interoperability. Section 4 then shows what platforms and components have been selected to
instantiate the high-level architecture in the respective pilot sites.
As a first step, key high-level architecture requirements are identified in the context of the main Wise-
IoT project objectives. Then different views and perspectives of the high-level architecture are
described, following the approach specified in the ISO/IEC/IEEE 42010 (ISO/IEC/IEEE 42010: Systems and
software engineering — Architecture description, the latest edition of the original IEEE Std 1471:2000,
Recommended Practice for Architectural Description of Software-intensive Systems., 2011). Each view
and perspective covers a different aspect and these aspects are largely orthogonal. It is not possible to
put all aspects into a single architecture diagram, e.g. information abstraction level, functional aspects
and deployment aspects should not be mixed as the same functional aspect may be covered on multiple
abstraction levels or multiple abstraction levels may be deployed in different parts of the system.
2.1 High-level Architecture Requirements
The Wise-IoT project proposed four main objectives (Wise-IoT D1.1 - Wise-IoT Pilot Use Case Technical
Description, Business Requirement, and Draft High-Level Architecture, 2016). From an architectural
perspective in particular the first two are relevant:
1. Provide a world-wide interoperable Internet-of-Things that utilizes a large variety of different IoT systems and combine them with contextualized information from various data sources.
2. Prove that this system can securely deliver dependable dynamic, real-time, and remote IoT
services with automatic adaptation to available resources and data lakes at any place in the
world.
3. Help users to trust the GIoTS and effectively exploit it for international events like the Winter
Olympics in Korea 2018.
4. Strengthen the on-going international IoT standardization based on outcomes from field pilots
Based on these, a number of high level architecture requirements are presented in this section, whose
fulfillement is at the core of the Wise-IoT architecture.
After giving an overview of the most relevant architecture views and perspectives from section 2.2 to
section 2.7, the fulfilment of the high-level architecture requirements is checked in the context of the
Wise-IoT System definition in section 2.8.
Access to information
REQ1. Integrate heterogeneous IoT technologies and platforms
Often, IoT devices like sensors and other IoT technologies have already been deployed at a certain
site. This may already include a local IoT platform that is used by local applications. Redeploying
High-Level Architecture
13
sensors or reengineering complete installations is often not feasible and thus the existing IoT
technologies and platforms have to be integrated into an encompassing IoT platform architecture.
This requirement primarily targets project objective 1 as it supports integrating a large variety of
different IoT systems.
REQ2. Enable that higher-level applications and components on only need to support one API
To ease the development of applications, it should be possible to only use a single API and still be
able to utilize core system functionality, in particular to access all relevant IoT information. This
requirement primarily targets project objective 2 as it enables uniform access to available resources
at any place in the world.
REQ3. Provide support to the data / information / knowledge pyramid
An important source of IoT data are sensors providing raw data. Only if this data is transformed and
annotated, it becomes information that can be found and used by applications that are not tightly
coupled to the sensors in the first place. Further processing and analytics can create knowledge and
eventually wisdom. This hierarchy created by annotation, processing and analytics is also known as
the knowledge or wisdom pyramid (Rowley, 2007). IoT applications require access, but also can
contribute to the layers of the knowledge pyramid, thus the IoT platform architecture needs to
support it. This requirement targets project objectives 1 and 2 as it enables contextualized and thus
higher-level information and it enables the uniform access to available resources at any place in the
world.
Semantics
REQ4. Support semantic modelling / semantic annotation
In order to understand information, its semantics needs to be clear. Semantics is the study of
meaning. If producers and consumers of information are tightly coupled, the semantics can be
implicitly encoded in the producers and consumers themselves, but if consumers need to find and
utilize information from previously unknown producers, the semantic information needs to be
explicitly provided. Raw information providers may not directly provide explicit semantics and thus
there is a need for semantic annotation to reach a higher layer in the knowledge pyramid (REQ3).
The semantic information provides the basis for achieving semantic interoperability. Semantic
interoperability is of key importance for providing a world-wide interoperable Internet-of-Things
and thus this requirement targets project objective 1.
Local and remote information
REQ5. Support transparent access to local & remote information
Applications need to be able to access local information, i.e. concerning IoT information related to
the current location of the user as well as IoT information from other locations. Beyond specifying
the geographic location of interest, the underlying access, e.g. across boundaries of underlying
systems, should be transparent to the user and the consuming application. This requirement
primarily targets project objective 2 as it enables delivering remote IoT services with uniform access
to available resources at any place in the world.
REQ6. Enable access to local & remote information for roaming users
If the user is not in his/her home location, e.g. home city or home country, the user is considered to
be “roaming”. The IoT system should still provide access to IoT information relevant at the user’s
High-Level Architecture
14
current location, but also at a remote location, e.g. the home location. This is needed to provide the
user with the same level of support in the remote location as in the home location, but also enable
the user to keep up with the situation at home or in another location. This requirement primarily
targets project objective 2 as it enables delivering remote IoT services with uniform access to
available resources at any place in the world.
Dynamic discovery
REQ7. Support discovery of information
As applications cannot be tightly coupled to sources of IoT information, e.g. in the case of a roaming
user (REQ6), they do not a priory know what information is available in the system and who can
provide it. Thus applications have to discover this, specifying the information they need. The
architecture must support the applications in either directly receiving the information or at least
getting a list of sources back that can provide the information. In order to deliver IoT services at any
place in the world, it is essential to be able to discover information. Thus this requirement targets
project objective 2.
REQ8. Support discovery and management of devices
The Wise-IoT architecture needs to support large scale IoT systems. The available devices in such
systems will change dynamically, e.g. as new devices become available, devices are replaced and
others become unavailable. Thus the system must support the discovery and management of
devices, ideally without having to do system adaptations beyond the local environment.
When working with a large variety of different IoT systems, it is important to be able to automatically
discover devices as the available devices will be changing continuously. Thus this project
requirement targets project objective 1.
Security
REQ9. Adherence to common security standards
To deliver IoT services securely in real-time and dependable dynamic manner, the Wise-IoT project
requires standard security definitions applicable in all parts. Authentication and authorization
policies should answer the different requirements of IoT systems in the interoperating network. Due
to the federated nature of Wise-IoT, any updating of the security standards (e.g., threat definition,
users’ authentication, and black list updating) should be automatically delivered to the different
parties. Furthermore, the new updates should be practical at the shortest time.
Due to the diversity of IoT applications, services, and platforms, the security protection system
requires more usability, scalability, and applicability in an interoperable model. Since Wise-IoT
provides an interworking possibility between IoT systems, the security requirements of IoT systems
should be reported regularly to provide the required updates and patches. Detecting any attack in
an IoT platform should be reported to other systems to prevent the same threat.This requirement
primarily targets project objective 2 as it enables secure and dependable IoT services.
Trust
REQ10. Support for trust building between IoT systems and their users
In the Wise-IoT architecture, components are connected for data sharing and data analysis. The data
is accessed by services or by humans in order to generate value from knowledge that is aggregated
from the IoT data. The Wise-IoT architecture shall enable close interactions between users and
systems involving access to user data or information. Thus, support for trust building between the
High-Level Architecture
15
users and the IoT systems becomes an important requirement. This requirement primarily targets
project objective 3 as it helps users to trust global IoT services.
2.2 Layered Architecture View
From a high-level perspective, the Wise-IoT architecture follows a layered approach similar to the AIOTI
HLA architecture (WG03, 2017). In addition to the basic layering of the HLA, it differentiates layers and
respective functionalities according to their level of abstraction (see Figure 1). Raw data is collected and
real-world actuation executed by a large number of heterogeneous devices. To be able to handle this,
there is an integration layer for making the raw data accessible and semantically annotate it. At the same
time, the heterogeneous devices and the connectivity between the devices is managed in this layer. The
information access layer makes information derived from the raw data accessible to applications, as well
as analytics and recommendation components. The latter makes up the Knowledge Processing Layer.
The layering follows the knowledge pyramid as specified in requirement REQ3.
Figure 1: Wise-IoT Layered Architecture View
Components making up the higher layers can talk to components in the lower layers, not just in the layer
directly below, even though this is typically the preferred way of interaction. Figure 1 shows the
interactions between the components in the layers with different line weights. The stronger the line
weight the more interactions can be expected between these layers.
The motivation behind the Layered Architecture View is the observation that typically different enablers
have been designed to support the respective functionalities on the respective abstraction layers. In
Wise-IoT, the aim is to choose standardized enablers that are best suited for the particular task and
connecting them in a suitable way to combine the particular stengths while mitigating possible
weaknesses.
2.2.1 Data Collection and Device Actuation Layer
The Data Collection and Device Actuation Layer provides the connection to the physical world. It can
utilize a large number of different device and communication technologies and is inherently
High-Level Architecture
16
heterogeneous. Key technologies are sensors and actuators for sensing and controlling relevant aspects
of the physical world. These sensors may be part of specific, often resource-constraint sensor nodes or
be attached to sensor platforms running on more powerful devices, e.g. mobile phones, gateways or
dedicated servers. The important aspect for the Wise-IoT Architecture View is that interfaces are
provided for accessing data, controlling physical world aspects and managing the devices.
2.2.2 Integration and Management Layer
The Integration and Management Layer integrates and homogenizes the access to the data and services
provided by the Data Collection Layer. The requirement REQ1 on integrating heterogeneous IoT
technologies and platforms is primarily addressed here. As a result, the components in higher layers do
not have to deal with the heterogeneous access and communication technologies. However, the data
may still be in its raw form, i.e. there may not be any common abstraction with respect to the data
provided by different devices and technologies.
In addition to providing access to the data, the Integration and Management Layer may also enable the
management of devices in the Data Collection and Device Actuation Layer and configuring and
controlling the connectivity and communication. This addresses REQ8 on management of devices.
Finally, to enable the abstraction needed by the Information Access Layer, annotation capabilities are
required through which additional (meta-) information can be added. This partially addresses
requirement REQ4 on (semantic) annotation.
2.2.3 Information Access Layer
The Information Access Layer provides access to information on a higher, common abstraction level.
Applications and components of the Knowledge Processing Layer can request information, specifying
what information they need, and they get back exactly the requested information. This addresses REQ7
on discovery of information. For this purpose, expressive filters may be supported. The Information
Access Layer may provide different interaction styles, e.g. request-response or subscribe-notify. It
integrates information from different sources in the Integration and Management Layer. The
Information Access Layer provides a suitable interface for fulfilling REQ2.
2.2.4 Knowledge Processing Layer
The components of the Knowledge Processing Layer process information and data, primarily information
provided by the Information Access Layer, to elicit higher level knowledge, implicitly contained in the
information. Different kinds of analytics, e.g. from the artificial intelligence domain, including reasoning
and learning, can be used for this purpose. Furthermore, smart applications may be supported through
recommendations derived from the information, while taking into account the application goals.
2.2.5 Application Layer
The Application Layer is the place for end-user applications. The applications primarily access Knowledge
Processing Layer and Information Access Layer components to have a good basis for optimally
supporting the users in their respective tasks. Applications directly interact with the users to find out
about their goals, which are then the basis for interacting with the Information Access Layer and the
Knowledge Processing Layer to retrieve the required information and knowledge.
High-Level Architecture
17
2.3 Deployment View and Federated Architecture
Figure 2 shows a high-level view of an IoT deployment. It consists of three logical levels on which
computing nodes can be found – device, edge and infrastructure, which may be a cloud. In practice,
there may be sublevels involving multiple nodes, but nodes can generally be characterized according to
these levels.
Figure 2: Deplployment View
Devices are nodes with a direct connection to the physical world, i.e. they can provide information about
or actuate on the physical world. So these nodes are connected to sensors and/or actuators – through
a wired or wireless connection.
Edge nodes are typically part of the wired network infrastructure, but are geographically located close
to the devices to which may be connected to edge nodes via a wireless connection. Gateway nodes are
typical examples edge nodes. They may have significant computational resources and possibly a good
network connection. If short delays are required or communication with the infrastructure represents a
bottleneck, they are a good place for deploying computation tasks.
The infrastructure/cloud is rich in computational power, but there may be bottlenecks in the connection
to devices and there may be significant delays.
High-Level Architecture
18
Figure 3: Federation of domains
A set of nodes on the device, edge and infrastructure level can be combined to form a domain, which is
typically managed by one administrative entity. In Wise-IoT, each local deployment for smart cities or
smart skiing can be seen as such a domain. To enable cross-domain operation, a federation level as
shown in Figure 3 can be added, which enables applications connecting to the federation level to access
all federated domains without having to know different access points. In order to enable efficient access
on the federation level, suitable index structures are needed. In particular, indexing according to
location is suitable for IoT. If the domains are registered with the area and type, e.g. parking spots in the
area of one city like Santander or Busan, a request scoped for one location can be forwarded to the right
domain(s) and not all domains need to be considered. It is also possible to have multiple levels of
federations, i.e. to have a federation of federated domains etc.
2.4 Semantics Perspective
Semantics is the study of meaning. In our context, this refers to the meaning of data, information or
knowledge represented in an IoT system. If systems can a-priori agree on the semantics of information,
the semantics can be implicit, i.e. encoded in the system itself. For example, due to such an agreement,
an information consuming system knows that the value 56.0 provided by an information producing
system is a temperature value in Celsius that represents the internal working temperature of a particular
machine. Such exchange of information is efficient, but requires a very tight coupling and each change
requires explicit steps to change the configuration or even to re-compile the system. For large-scale,
dynamically changing systems as in the Internet of Things, the involved systems need to be able to self-
adapt to any such changes. To be able to find the currently relevant information or the set of currently
relevant sources of information, their semantics has to be explicit, i.e. provided as meta information
with the data or information itself.
High-Level Architecture
19
For two systems to interwork in a meaningful way, they have to agree on the semantics of the
information they exchange. This is referred to as semantic interoperability, which in (W3C) is defined in
the following way: semantic interoperability “means enabling different agents, services, and applications
to exchange information, data and knowledge in a meaningful way, on and off the Web”, and in
(Murdock, et al., 2016): “Semantic interoperability is achieved when interacting systems attribute the
same meaning to an exchanged piece of data, ensuring consistency of the data across systems regardless
of individual data format.”
As shown in Figure 4 (oneM2M TR-0007 Study of Abstraction and Semantics Enablement., 2014), there
are different levels of meaningfulness regarding the semantic (meta) information that is provided, both
concerning the data itself and the device.
Figure 4: Increasing levels of meaningfulness
Semantic interoperability is a core feature of the Wise-IoT architecture as it enables the integration of
heterogeneous systems. In general, semantic information can be explicitly made available on all layers
of the Layered Architecture View described in Section 2.2. However, not all devices on the Data
Collection and Device Actuation Layer may support the explicit representation of semantic (meta)
information. Thus adding such information on higher layers, in particular the Integration and
Management Layer is required, which is also referred to as semantic annotation. Following from the
discussion above, the less semantic information is explicitly provided between systems in two layers,
the tighter the coupling has to be due to the implicit agreements necessary. In general, the higher the
layer, the higher the level of abstraction and the more important the explicit representation of semantic
(meta) information. In particular this is relevant when federating systems from different domains, which
will typically be less tightly coupled than systems in the same domain.
2.5 Trust Perspective
In addition to enabling global interoperability, the Wise-IoT project aims at building mechanisms for
ensuring trust in the global IoT systems. Such trust enablement is important because systems and
devices become increasingly connected, the need for personalization, the number of points-of-failure,
and the exposure to attacks increases.
Trust can be generally defined as an ‘assurance’ or ‘confidence’ of a trustor in a trustee to perform a
task in a way that satisfies the trustor’s expectation. In this sense, the trustor partly recognizes the
High-Level Architecture
20
vulnerabilities and potential risks when the trustee accomplishes the task. Thus, it represents the
trustor’s willingness to be vulnerable under the conditions of risks and interdependence. Generally, trust
is defined as a belief of a trustor in a trustee that the trustee will provide or accomplish a trust goal as
trustor’s expectation within a specific context for a specific period of time. As illustrated in Erreur !
Source du renvoi introuvable., in the IoT environment, trustors and trustees can be humans, devices,
systems, applications and services. Measurement of trust as the belief (called trust value) can be
absolute (e.g., probability) or relative (e.g., level of trust). It could be an action that the trustee is going
to perform (trust for action); it could also be information that the trustee provides (trust for
information). Trustor’s expectations are deliberately considered to include specific requirements for
well perform (in some degree) the trust goal.
Figure 5: Conceptual Model of Trust in the IoT
2.6 Security Perspective
In addition to enabling global interoperability, the Wise-IoT project aims also at building a standarized
mechanisms for ensuring end-to-end security in the global IoT systems. As identified by REQ9, security
is an important part of the Wise-IoT project since authentication and authorization are required in order
to identify users, things, services and applications in different domains and enabling the ability to give
them proper access rights to use enforced resources in connected IoT platforms. As the project
interconnects several IoT platforms, proper security interworking mechanisms are a key to success in
delivering reliable IoT services to users. To perform secure interworking, there is a need to integrate
security mechanisms of IoT platforms such as FIWARE or oneM2M because IoT platforms use different
security standards and security mechanisms including authentication and authorization, security
policies, etc. In addition, it is required to analyze the security requirements of each IoT platform
(oneM2M and FIWARE) to provide a federated security approach that encompass all the security
requirements of these platforms .
2.7 Self-Adaptation and Evolution Perspective
The Self-Adaptation and Evolution Perspective has been successfully incorporated into the Knowledge
Processing Layer as part of the Self-Adaptive Recommender. It has been used and validated in the
Santander Smart City field trials. As a result, we found that no change had to be made to our high-level
view on self-adaptation systems in IoT. Therefore, our theory presented in deliverable D1.2 on the Self-
Adaptation and Evolution Perspective is still valid. For the convenience of the reader, we repeat the
theory in the remainder of this section.
High-Level Architecture
21
The Knowledge Processing Layer offers the IoT system the capabilities to self-adapt and engineers to
understand the needs for IoT system evolution. It allows collecting information, analyzing that
information by answering questions, deciding how to act by interpreting these insights, and acting
according to these decisions. These abilities are the elements of a loop that controls the dynamic
behavior of the system (Cheng, et al., 2009) as illustrated in Figure 6. They allow the system to examine,
introspect, and modify its structure and behavior at runtime. They also allow engineers to understand
the achievements, problems, and needs for evolving the system over versions and releases.
Figure 6: Control loop enabling self-adaptation based on (Cheng, et al., 2009).
The Knowledge Processing Layer aggregates information needed for answering adaptation-related
questions and makes the insights that are generated by answering these questions available to
subscribers. The information may concern user intentions and requirements, context information, and
use context of the IoT system and applications. The insights may concern the validity of context
information and models of the world, the fulfillment of user requirements and preferences, and
trustworthiness of entities comprised by the system.
The Knowledge Processing Layer may initiate self-adaptation or recommend adaptations to entities
listening to the layer. Self-adaptation actions may include alterations to the system configuration,
modification of problem-solving and recommendation mechanisms, online learning, and the
manipulation of effectors. Recommendations may be targeted at humans and applications that use the
IoT system and at engineers that monitor, maintain, and evolve the IoT system.
In the Wise-IoT architecture self-adaptation and evolution are seen as a means to build end user trust
over time as the global IoT system is being used. A system that does not fulfill user needs or may not be
dependent upon will be abandoned. For that reason, mechanisms are needed to discover insights such
as unsatisfied needs and encountered problems. Wise-IoT aims at discovering these problems and needs
during runtime and acts on them by self-adapting and offering decision-support for engineers that are
concerned of evolving parts of the system.
Figure 7 offers an overview of the components and data flows needed for enabling self-adaptation and
supporting evolution.
High-Level Architecture
22
Figure 7: Self-adaptation capabilities and support for evolution.
The components and data flows are orchestrated according to the control shown in Figure 6. Data are
collected to understand the application’s requirements, the use context, the real-world context as
sensed by the IoT system, and the users’ opinions. These data are being analyzed by an inference
mechanism to offer insights, recommendations, and initiate self-adaptation. Insights might relate to the
proper functioning of the IoT system, the fulfillment of user needs, the validation of assumptions, and
other observations that are of interest to applications or humans that depend on the IoT system. The
IoT system finally offers mechanisms for subscribing to recommendations that are implied by the
insights and adapting such recommendations.
Table 1 shows the component types needed for self-adaptation and evolution of the Wise-IoT system.
Table 1: Component types of the self-adaptation and evolution perspective.
Component Types
Description
Information Sources
IoT Sensors, end-user applications, and humans involved in the use of the IoT system
Information Collectors
Subscriptions to context data (IoT sensors) and mechanisms that collect information about user needs (user inputs), use context (session managers), and user opinions (feedback probes).
Knowledge Database
Databases that allow storage of information used for inference and knowledge produced with inference.
Inference Mechanisms
Mechanisms that transform the sensed inputs into knowledge. The inference mechanisms include help for users to exploit the IoT system (recommenders), analysis of information quality (QoI analyzers), assessment of trustworthiness (trust analyzers and aggregators), and decision support for system change (fault detectors and requirements probes).
Knowledge Brokers
Mechanisms that offer subscriptions or other forms of access to knowledge such as recommendations for exploiting the IoT system, insights about system quality and fulfillment of user needs, and parameters and data needed for self-adaptation.
Knowledge Subscribers
Applications used by end-users, analysis and backlog management tools used by engineers, and components offering configuration and adaptation capabilities.
The information collectors, knowledge database, inference mechanisms, and knowledge brokers
represent the core of the self-adaptation and evolution perspective and represent mandatory elements
of an IoT system that is self-adapting or offers support for evolution. The information sources and
knowledge subscribers are considered to be the elements external of the self-adaptation and evolution
Users
IoT System
Engineers
Recommendations
Insights
Evolve
Inference
Adaptation
Requirements,Use Context, Opinions
KnowledgeInformation
CollectorKnowledge
Broker
IoT Context
Self-Adaptation
High-Level Architecture
23
view. An inference mechanism is considered internal if it consumes produced knowledge as input
information.
2.8 Wise-IoT System Definition
A Wise-IoT System is a system that instantiates the high-level architecture described in this chapter and
thereby fulfills the high-level architecture requirements specified in Section 2.1.
A Wise-IoT System implements the layered architecture. It supports local IoT platforms and
heterogeneous IoT devices with sensing an actuating capabilities in the Data Collection and Device
Actuation Layer. It integrates these IoT devices and local IoT platforms in the Integration and
Management Layer, thereby fulfilling REQ1. It supports the data / information / knowledge pyramid by
implementing corresponding layers, i.e. the Integration and Management Layer, the Information Access
Layer and the Knowledge Processing Layer respectively. Thus REQ3 is fulfilled.
The purpose of the Information Access Layer is to provide a uniform API for accessing information.
Application developers that require general high level information can use this API and do not need to
know about any others, thus fullfiling REQ2. More device-specific information and functionality can be
accessed through the common interface provided by the Integration and Management Layer. As this
interface also provides common abstractions, albeit possibly not to the level of a general, technology-
independent information model, it is an alternative option for applications that require this more device-
specific level of interaction.
The Wise-IoT architecture enables the federation of Wise-IoT System instantiation, i.e. in this way
applications can access information across these instantiation. Ideally, this is done completely
transparently, e.g. by always explicitly providing a geographic scope. In this case the federating
component can identify the relevant instantiations. This fulfils REQ5, the support of transparent access
to local & remote information. As this is independent of where the user is currently located – as long as
the access to its federation component is available – it also fulfils REQ6, the transparent access to local
and remote information for roaming users.
The semantic perspective plays an important role for Wise-IoT as it enables the interoperability between
the different layers. For the higher layers, the explicit representation of semantic information is required
to support semantic interoperability. As many technologies in the Data Collection and Device Actuation
Layer do not directly support explicitly representing semantic information, the Integration and
Management Layer has to support semantic annotation functionality and the semantic information must
be at the core of the Information Access Layer. Thus REQ4 is supported. The Knowledge Processing and
Application Layers then make use of the semantic information.
The Information Access Layer allows applications to specify what information they are interested in, thus
REQ7 is fulfilled. The Integration and Management layer has to support the integration and management
of devices in the Data Collection and Device Actuation Layer, hence REQ8 is also fulfilled.
Wise-IoT is building on security standards in particular with respect to authentication and authorization
in order to identify users, things, services and applications in different domains and enabling the ability
to give them proper access rights (enforcement policies, security proxy) to use protected resources in
connected IoT platforms and thus REQ9 is fulfilled.
The interactions between the Wise-IoT entities especially between the system and users call for ensuring
that exchange of data or information between the users and the system can be trusted so that users are
guaranteed trustworthiness of data especially context data. The monitoring and evaluation of such
High-Level Architecture
24
interactions using feedback data and the quality of information supports the decision making process of
users, and especially those of the functionalities of the Wise-IoT System such as the self-adaptation
and recommendation to treat cautiously any data that is considered untrustworthy. Thus, support for
trust building (REQ10) has been fulfilled.
Technology Plan: Protocols, Standards and Technologies
25
3 Technology Plan: Protocols, Standards and
Technologies
After introducing the Wise-IoT high-level architecture in Section 2, Section 3 introduces the protocols,
standards, technologies and the components build from these that are used to instantiate the Wise-IoT
architecture. An instantiation of the Wise-IoT architecture may cover a single use case site or be
extended to federate a multitude of use case sites. These specific instantiations will be described in
Chapter 4.
3.1 Mapping Layers to Technologies
Figure 8 depicts how the components based on protocols, standards and technologies that have been
selected for the Wise-IoT platform and use cases can be used to instantiate the Layered Architecture
View introduced in Section 2.2. As we are going to show in Section 4, a subset of these components is
used in each of the pilot site deployments. The Wise-IoT applications that instantiate the Application
Layer are specific to each use case and thus are not shown in this general architecture overview.
Figure 8: Mapping Technoloigies to Layered Architecture View
In the Data Collection and Device Actuation Layer (Section 3.2) devices and edge-side platforms can be
found. In this project, there is a focus on integrating devices based on LoRa and Z-Wave, which are
introduced in Sections 3.2.4 and 3.2.5 respectively. Further devices can be connected through the GS1,
sensiNact and OCF platforms, which are introduced in Sections 3.2.1, 3.2.2 and 3.2.3. On the one hand
they integrate different other technologies and thus could be assigned to the Integration and
Management Layer, on the other hand they provide only limited management functionalities and are
primarily used for data collection. Thus they are shown with a gradient colour, but are assigned to the
Data Collection and Device Actuation Layer due to their actual use in Wise-IoT. In another instantiation
of the proposed high-level architecture a different assignment could be considered.
The Integration and Management Layer (Section 3.3) is instantiated by the oneM2M platform. oneM2M
is a worldwide standard produced by the oneM2M partnership project. On the one hand oneM2M
supports the interworking with a wide range of technologies and platforms (REQ1), providing a
Technology Plan: Protocols, Standards and Technologies
26
homogeneous interface (REQ2) to higher layers, on the other hand it supports different ways of
managing devices and connectivity. In the project, three different implementations – Mobius, Brightics
and ThingPlug – provided by different partners are going to be used. All these implementations in
principle provide the same standardized interfaces, but may differ slightly in the concrete set of features
that have been implemented.
The Information Access Layer (Section 3.4) is instantiated by FIWARE Generic Enablers (GEs) using the
NGSI Context Interfaces. The FIWARE platform has been developed as part of the European Future
Internet Public-Private-Partnership. In addition to the open specification for each GE, FIWARE has
provided an open source reference implementation. The FIWARE GEs used in Wise-IoT are the Context
Broker GE (Orion open-source implementation), the IoT Broker GE (Aeron open-source implementation)
and the IoT Discovery GE (NEConfMan open-source implementation), which are introduced in Sections
3.4.1.2 and 3.4.1.3 respectively. Whereas the Context Broker GE primarily supports a centralized
architecture, the IoT Broker GE and the IoT Discovery GE support a distributed approach and can be used
to implement a federation. All GEs are based on the NGSI Context Interfaces that have been specified as
abstract interfaces by OMA and for which FIWARE has defined an HTTP binding with a JSON-based
representation. The NGSI interface allows components of the higher layers to specify and retrieve
exactly the information required (REQ2).
The Knowledge Processing Layer is instantiated by the Self-Adaptive Recommender (SAR). The SAR can
be used by applications from the Application Layer to generate recommendations for users. The SAR
retrieves IoT data from the lower layers, and can consider the user’s preferences and feedback when
calculating recommendations. User feedback is used to compute trust values that influence future
recommendation and make the SAR self-adaptive. To fulfil its tasks, the SAR consists of a number of
loosely-coupled, distributed sub-components that have been developed in Wise-IoT Work Package 2
(with the exception of the Supersede framework that is developed in the Supersede project) and are
described in Section 3.5.1. Five components are implemented as web services: the QoI Monitor observes
the quality of IoT data, the IoT Recommender calculates recommendations, the Adherence Monitor
monitors the (non)adherence of users to recommendations, the Trust Monitor calculates trust values
between users and IoT entities, and the SAR façade hides the SAR’s complexity and partitioning from
application developers. In addition, a front end library takes care of all communication with the SAR and
includes the Supersede framework that gathers feedback from users.Due to the heterogeneity of
protocols and data representations on the one hand and the differences of core platform concepts on
the other hand, it is not possible to simply plug the different components and layers together directly.
To bridge these gaps, Wise-IoT introduces the Morphing Mediation Gateway (MMG) component, which
has been developed in Wise-IoT Work Package 2. The idea of the MMG is to have a flexible modular
component that enables translating between different protocols and data representations. For example,
from a Z-Wave sensor to the oneM2M platform or from the oneM2M platform to an NGSI-based FIWARE
enabler. While the former case may be simple and straight-forward as it connects a sensor to a platform,
the latter case is more diverse and complex as two platforms are being connected. The idea here is to
enable the continuous discovery of information in the source platform. In the case of oneM2M, semantic
annotations (REQ4) are used to provide the meta information necessary to enable the translation of
possibly raw sensor data to the NGSI entity-attribute model, for which an entity type, entity id, attribute
and possibly further attribute information needs to be derived. The “morphing” aspect of the MMG is
that it can change itself at runtime. It can download and dynamically initiates transformations. If a new
source is provided or even if information annotated using a different ontology, the MMG can check for
suitable components in its repository, dynamically instantiates them and create a translation process
for this new kind of information, without having to recompile or manually reconfigure the component.
Technology Plan: Protocols, Standards and Technologies
27
A detailed description of the Morphing Mediation Gateway can be found in the Wise-IoT Deliverable
D2.7 (Wise-IoT D2.7 – Final System, 2018).
3.2 Data Collection and Device Actuation Layer
The Data Collection and Device Actuation Layer connects to physical devices deployed in real world. IoT
devices consists mainly of sensors and actuators that gathers real time data about various aspects of our
environment. These devices can use various different wireless protocols and technologies that include
Z-Wave, Lora, RFID, etc. Wise-IoT uses oneM2M as service layer for data storage and access. This layer
contains various components that perform data translation to oneM2M after gathering it from physical
world. This section discusses working and integration of such components in Wise-IoT architecture in
detail.
3.2.1 GS1
GS11 is a international not-for-profit organization that develops and maintains global standardized
identification systems for products, assets, services, places, and organizations. GS1 standards may be
divided into three groups (9): Identify (GS1 standards for Identification), Capture (GS1 standards for
barcodes & EPC/RFID), and Share (GS1 standards for data exchange).
- Identify: provide the means to identify real-world entities so that they may be the subject of
electronic information that is stored and/or communicated by end users.
- Capture: provide the means to automatically capture data that is carried directly on physical
objects, bridging the world of physical things and the world of electronic information.
- Share: provide the means to share information, both between trading partners and internally,
providing the foundation for electronic business transactions, electronic visibility of the physical
and digital world, and other information applications.
1 GS1, The Global Language of Business, https://www.gs1.org/
Technology Plan: Protocols, Standards and Technologies
28
Figure 9 GS1 standards overview
3.2.1.1 GS1 Oliot Architecture
Oliot2 is an open source IoT platform, which extends the GS1 code system. By supporting various IoT
connectivity protocols, it aims to implement the GS1/EPCglobal standards. The platform captures
resource and services, which are uniquely identified by GS1 ID system, through a standard interface. It
share the data through standard query interface where the repositories are independently distributed.
Its uses the internet DNS principle to hierarchically manage the repositories.
Figure 10 shows the overall Oliot architecture which can be divided into 8 major components, including
ID System, Global Product Classification (GPC) Extension, Metadata Service, Low Level Reader Protocol
(LLRP), Application Level Events (ALE), Electronic Product Code Information Services (EPCIS), Object
Naming Service (ONS), and Discovery Service (DS).
• ID System: aims to provide an interoperable endpoint URN scheme to support various types of
protocols that connects into the Oliot architecture.
• Global Product Code (GPC) Extension: represents IoT services and provides a linked way of
describing components.
• Metadata Service: provides static information about things and contains GS1 source and GTIN+
on the web styles.
• Low Level Reader Protocol (LLRP): provides device connectivity with heterogeneous devices
and necessary connection to ALE adaptation layer.
• Application Level Events (ALE): integrates various connectivity protocols and processes data
from smart devices.
2 Open Language for Internet of Things (Oliot), Auto-ID Lab, KAIST, Korea, http://gs1oliot.github.io/oliot/
Technology Plan: Protocols, Standards and Technologies
29
• Electronic Product Code Information Services (EPCIS): is currently EPCIS v1.2 compliance and
embeds extended Core Business Vocabulary. It is an independent distributed repository, which
explicitly deals with historical data in addition to the current data. It is composed of standardized
capturing interface, persistence layer and standardized query interface. Each events stored in
EPCIS provides contextual information (what, when, where, why).
• Object Naming Service (ONS): provides service records registration and search for services
provided by things. It is designed similarly as Domain Name Service (DNS). By providing an initial
point of contact, Root ONS delegates Local ONSs to provide a means to look up a reference to
an EPCIS services using non-serialized identifiers.
• Discovery Service (DS): provides lookup service of dynamic information about a given GS1 key
and search for the list of EPCIS related with things.
Technology Plan: Protocols, Standards and Technologies
30
Figure 10 Oliot Architecture
3.2.1.2 Mapping to Wise-IoT Architecture
In this project, Oliot is used to collect data and is integrated to Wise-IoT through the Morphing Mediation
Gateway. Data collected through Oliot are fed upward to oneM2M service layer through GS1-oneM2M
Morphing Mediation Gateway, which consists of oneM2M Capturing and Accessing Applications.
Technology Plan: Protocols, Standards and Technologies
31
In the integration, the data coming from IoT devices and existing systems are kept in the Oliot federated
repository system, EPCIS. As shown in Figure 11, in the case where oneM2M Accessing Application does
not know which EPCIS contain the data to be translated to oneM2M, it can discovers through Oliot ONS
and Oliot DS and subscribe EPCIS to get new IoT event data. Then it makes the data available to Wise-
IoT platform by creating an oneM2M container and publish the data from Oliot EPCIS to oneM2M service
layer. Data collected as part of Wise-IoT through other platforms is also collected back to Oliot through
oneM2M Capturing Application, which discovers, subscribes, and gets data from the integration layer.
Figure 11 GS1 Mapping to Wise-IoT Architecture
3.2.2 Eclipse sensiNact
Eclipse sensiNact (Eclipse sensiNact, 2017) is a generic and open source IoT platform that can be
deployed in various environments. The platform provides several bridges to various protocols, e.g.,
HTTP, LoRa, EnOcean, from various environment, e.g., smart home, smart city. The element provided in
this project is the sensiNact Gateway.
The gateway acts as an "edge gateway", i.e., it is the first element of the architecture after the physical
device. Thus, it retrieves the data directly from the devices and stores it in a basic data model detailed
below. This technology is located into the “Data collection and device actuation” layerof the architecture
proposed in this project.
To enable the connection to various protocols, the gateway provides functionalities to ease the
development of southbound bridges. Moreover, to access to the data, several northbound bridges are
available using various protocols which allow the integration of the gateway into wider and
heterogeneous systems.
Technology Plan: Protocols, Standards and Technologies
32
3.2.2.1 Eclipse sensiNact architecture
Figure 12: Eclipse sensiNact architecture
The interactions between the gateway and other entities are performed through an extensible set of
northbound and southbound (cf. Figure 12).
Southbound bridges are specialized into the interaction with devices, which can be sensors or actuators.
Each bridge is in charge of communicating with a specific kind of device, using a given protocol. The
Generic module provides a set of intermediate data structures at different complexity levels to ease and
accelerate the integration of new southbound bridges. Thanks to an OSGi based architecture, it’s
possible to add bridges on the fly, while the gateway is running, to allow the communication with new
kind of devices.
Symmetrically to the southbound bridges, northbound bridges are in charge of publishing information
to remote systems. It can be using common protocols, e.g., HTTP, MQTT, XMPP, NGSi 9/10. The set of
northbound bridges is also extensible, for tailoring special needs or singular systems.
All the communications managed by sensiNact Gateway are converging to a central piece: the Core
module. This element is in charge of the overall coordination of information, involving two managers:
the device manager and the application manager. The device manager, with its associated database
stores all the information regarding devices. This include devices availability, devices properties,
location, etc.
Finally, the application manager, the AppManager, provides execution environment to run simple and
small applications closed to the devices. It allows, for example, to listen for a device and, depending on
the conditions, to perform simple actions locally.
3.2.2.2 Eclipse sensiNact data model
Eclipse sensiNact supports Devices and Resource Discovery and Resource Management capabilities, to
keep track of IoT resource descriptions that reflect the resources that are reachable via the gateway.
These can be both IoT Resources, or resources hosted by legacy devices that are exposed as abstracted
Technology Plan: Protocols, Standards and Technologies
33
IoT resources. Moreover, resources can be hosted on the gateway itself. The Resource Management
functionality enables to publish resources in sensiNact, and also for the client to discover what resources
are actually available from the gateway; sensiNact data model allows exposing the resources provided
by an individual service. The latter, characterized by a service identifier, represents a concrete physical
device or a logical entity not directly bound to any device. Each service exposes resources and could use
resources provided by other services. Figure 13 depicts the data model such as an example for a device.
Figure 13: sensiNact data model
3.2.2.3 Mapping to Wise-IoT Architecture
In the Wise-IoT project, sensiNact is deployed in the smart skiing environment, especially in Chamrousse.
Figure 45, in Section 4.2.1, shows the integration of the sensiNact platform with the Wise-IoT
architecture. The platform is connected to it using the oneM2M Mca interface. Data collected on the
field are sent to a oneM2M MQTT queue.
3.2.3 Open Connectivity Foundation (OCF)
OCF standards provide the framework for communications among IoT devices in proximity networks.
Each OCF devices has server and/or client roles to communicate with others and its architecture is
designed in RESTful. As RESTful architecture, it provides REST APIs with standard resource types. Mainly
different resource types represent IoT devices and their behaviour/properties. The OCF protocol is bound
to CoAP protocol utilizing several features of CoAP (e.g. Observe/Notify) and implemented by its official
open source project, IoTvity.
Currently the main IoT domain for OCF is smart home driven by manufacturers. It is expected to broaden
the scope of its standard to cover cloud associated architecture.
Technology Plan: Protocols, Standards and Technologies
34
Figure 14: OCF Architecture Concept (OCF Specification 1.3, Core Framework, 2018)
3.2.3.1 Mapping to Wise-IoT Architecture
As one of the Data Collection and Device Actuation Layer technology, OCF interworks with oneM2M and
this interworking has been specified in oneM2M (oneM2M TS-0024 oneM2M-OCF Interworking, 2018).
This specification provides means to oneM2M applications to use OCF devices and its services.
Since both system is designed in RESTful, the interworking can be done as resource mapping in principle.
When the OCF-oneM2M interworking proxy is initiated, it discover and exposes OCF devices in oneM2M
platform as oneM2M resource. Then those OCF resources in oneM2M platfrom can be used by oneM2M
applications (e.g. controlling OCF devices).
For example, in Figure 15, when a oneM2M application wants to turn on OCF light bulb what is exposed
to oneM2M system, it creates an instance under the container that represents the OCF light switch
resource of a OCF light bulb. That new instance creation gets notified to the proxy and then the proxy
translates that notification into OCF request message to send it to the targeted light bulb.
Figure 15: OCF-oneM2M Interworking Architecture
Technology Plan: Protocols, Standards and Technologies
35
3.2.4 LoRa
LoRa (short for Long Range) low powered wide area wireless communication technology covering
several killometers as its coverage. As a trade-off its bit rate is quiet low (0.25 ~ 22kbps) so it is suitable
for IoT services with small payloads and low time sensitivity (e.g. metering). LoRa is deployed by
operators and especially in South Korea, it has been deployed nation widely.
The communication between LoRa devices and gateways are non-IP. When a LoRa message was sent
from the gateway toward the IoT platfrom, it is sent to the gateway then the gateway forward it to the
platfrom over IP.
3.2.4.1 Mapping to Wise-IoT Architecture
To support bi-directional communication in Wise-IoT between LoRa devices and oneM2M system, LoRa-
oneM2M proxy has been designed. The proxy bridges non-IP and IP communication in between while
translating LoRa message parameters into oneM2M resource path for core APIs (e.g. <contentInstance>
creation). As a setup, the proxy exposes LoRa devices per its Application EUI (Extended Unique Identifier).
For example, LoRa parking sensors are represented in oneM2M platform as children resources of a
specific AppEUI container. Each device container then has uplink and downlink sub-containers to enable
bi-directional communication in end-to-end manner.
Figure 16: LoRa-oneM2M Interworking Architecture
3.2.5 Z-Wave
Z-Wave is a low powered wireless communication protocol that is primarily used in home automation.
Due to its ability to deal with small messages efficienty, it is widely used in the IoT environment. The Z-
Wave automation system is controlled via the Internet with a Z-Wave gateway that serves as Z-Wave
controller. Multiple Z-Wave devices can be connected to a single controller. The Z-Wave controller helps
in getting data from registered devices (e.g. sensors).
The Z-Wave-oneM2M compoenent translates Z-Wave data to oneM2M standard format and send to
oneM2M service layer. Data from the Z-Wave devices are gathered by the Z-Wave Driver (an application
for specific Z-Wave device) residing on gateway with the assistance of Z-Wave controller. The Z-Wave-
oneM2M component collects data from Z-Wave Driver and then performs data translation. Data from
multiple Z-Wave Drivers can be managed by a single Z-Wave-oneM2M component. Z-Wave Driver is
Technology Plan: Protocols, Standards and Technologies
36
needed for a specific Z-Wave device in order to collect its data. Fig. 10 shows working of Z-Wave-
oneM2M component.
Figure 17: Z-Wave-oneM2M Component
3.2.5.1 Mapping to Wise-IoT Architecture
In the Wise-IoT architecture, data from the Z-Wave devices is gathered in Device Collection and
Actuation Layer. Z-Wave-oneM2M integrates in Integration and Management Layer through MMG
Manager. The MMG manager maintains the docker repository for different oneM2M components. The
Z-Wave-oneM2M docker component resides in MMG repository. The MMG manager instantiates the
component on-demand to store translated data in oneM2M service layer. Fig. 11 shows integration of
Z-Wave-oneM2M with MMG Manager and oneM2M service layer in Wise-IoT architecture.
Figure 18: Integration of Z-Wave-oneM2M in Wise-IoT Architecture
Technology Plan: Protocols, Standards and Technologies
37
3.3 Integration and Management Layer
Integration and Management Layer is defined on top of Data Collection and Device Actuation Layer.
There are a lot of different protocols and platforms for IoT devices on the market and this is the main
reason to have Wise-IoT project demonstrating global IoT services with interoperability technologies.
oneM2M is the choice that provides interoperability framework to other technologies (e.g. GS1, Z-Wave)
in this layer. one of the benefits to adopting oneM2M standard is to integrate other systems than
oneM2M due to its resource oriented architecture design and published interworking specifications (e.g.
OCF-oneM2M interworking). Therefore oneM2M provides abstraction to heterogeneous underlying
technologies in Data Collection and Device Actuation Layer. All the thing needed in the upper layer
components is complying oneM2M standard APIs not the individual protocols and APIs.
3.3.1 oneM2M Platform
oneM2M is the global partnership project among regional standard development organizations (i.e. ETSI,
TTA, ATIS, TIA, TTC, ARIB, CCSA, TSDSI) and also stands for its technical standard name. Since 2012, to
reduce IoT technology fragmentation, oneM2M started its standardization to deliver the same standards
to those partner countries. Instead of silo platform and APIs, oneM2M provides common and horizontal
platform for different IoT domains (e.g. home, energy). Then with that horizontal platform ready not
just to guarantee interoperability via its standard APIs, but it enables time-to-market and lower cost for
further service deployments. There are open source implmentations (e.g. Mobius of KETI) and
commercial products including oneM2M certified ones.
oneM2M specification has been transposed into ITU-T Recommendations since 2017 in Y.4500 series. It
was industry standards but now it became the international standards.
3.3.1.1 oneM2M Platform as an IoT Middleware
It is easier to understand oneM2M standard with IoT Reference Model of ITU-T compared to traditional
OSI 7 layer model. oneM2M defines 3 layered model and its platform resides in Common Services Layer.
The reason why it is called Common Services is oneM2M as IoT middleware provide common functions
(e.g. device management, group access) to different IoT services. Then the application developers can
focus on service logic implementations while using oneM2M APIs for common service functions. One
key idea to understand is oneM2M applications talk to oneM2M platform. So to exchange data, for
example, between different applications, they share it via the platform using the standard APIs.
Technology Plan: Protocols, Standards and Technologies
38
Figure 19. oneM2M as Service Layer Middleware
From deployment perspectives, a oneM2M platform (e.g. one in gateway or server) provides more than
data exchange for applications. As adopted in Wise-IoT, oneM2M platform offers interworking features
and it now provides generic interworking framework for different technologies. Backend systems or
external IoT systems can interwork too over oneM2M standard and this south to north interworking
scenarios illustrates the concept of heterogeneous system integration using oneM2M.
Figure 20. Example of oneM2M integration deployment
3.3.1.2 oneM2M Common Services Functions
As explained in section 3.3.1.1, oneM2M platform as IoT middleware provides common functions in
terms of its APIs. The Figure 21 show the list of common services functions of oneM2M release 2
specifications. In Rel-3 which is going to be published in 3Q 2018 offers more functions.
Technology Plan: Protocols, Standards and Technologies
39
Figure 21. oneM2M Common Services Functions (Rel-2)
Providing common services by the platform to its applications means that platform work as applications
asked to do so. For instance, when application stores sensing data into platform so that can be consumed
by other applications, not just retrieve APIs give back the data to consumer, but also the platform
manages the data storage (e.g. maximum storage size and number of instances of a data container). In
the other example, when an application wants to fetch latest measurement of thousands metering
sensors in field, what application does is not sending out thousands of requests but querying one single
request to the platform once it configured those sensors into one group resource.
3.3.1.3 oneM2M Security Component
Access to oneM2M can be managed by validating REST API request that is supported to control a
resource and IoT device. In Wise-IoT project, oneM2M security component is developed for managing
access to oneM2M based on OAuth 2.0. Figure 22 is overview of oneM2M security component.
Figure 22. Overview of oneM2M Security Component
As described in Figure 22, oneM2M security component is built on Mobius which is one of
implementations of oneM2M, and validates REST APIs in front of Mobius. The detailed operation is
depicted in Figure 23.
Technology Plan: Protocols, Standards and Technologies
40
Figure 23. Operation of oneM2M Security Component
To use oneM2M resource, all clients (applications) must have an access token issued by oneM2M
security component based on client credentials (i.e., username and password). After the token is issued,
client can access a resource with the token.
3.3.1.4 Mapping to Wise-IoT Architecture
In terms of heterogeneous systems (e.g. device, platform) integration, oneM2M plays a pivotal role in
Integration and Management Layer. To the lower layer, Data Collection and Device Actuation Layer,
different protocols and APIs can be abstracted and exposed to the oneM2M platform. Several specific
systems (e.g. OCF, OMA LwM2M) interworking technologies have been standardized in oneM2M.
Others (e.g. Z-Wave) can be interworked following the interworking framework using oneM2M resource
driven architecture, too.
Devices and actuators in oneM2M or different systems then can be accessed via oneM2M APIs by
oneM2M applications in Application Layer or other components like Fiwware Context Broker in
Information Access Layer. Semantic features of oneM2M standards is also used to provide interworking
with the Context Broker.
oneM2M system has more value propositions however the focus in Wise-IoT is to use as interoperability
framework to the lower layer and upper layers.
3.3.2 Wise-IoT Morphing Mediation Gateway
Figure 24 a) shows the underlying concept of a Morphing Mediation Gateway (MMG). An MMG can be
used to connect one platform to another or a specific technology to a platform. The assumption is that
the interfaces are conceptually so different that one platform cannot simply access the other platform.
The core idea is that the MMG is the driver of the communication, i.e. it reads (possibly after a discovery
step) information from the source platform, transforms it to fit the information model of the target
platform and finally writes the transformed information to the target platform. With this approach,
there is no direct coupling between the platforms / platform and device.
Technology Plan: Protocols, Standards and Technologies
41
Figure 24: a) Morphing Mediation Gateway Concept b) Example Instantiation
Figure 24 b) shows an example instantiation, which is also of special importance for Wise-IoT. The source
platform is the oneM2M platform, the MMG discovers relevant sources via the Mca interface and sets
up a process for continously retrieving information. The MMG then translates the information using
either some configuration information or the semantic annotation provided in the oneM2M platform to
the NGSI data model required by the FIWARE GE, e.g. a Context Broker. It then uses the NGSI-10 update
operation to provide the translated information as entity information to the FIWARE GE.
Figure 25 shows the architecture of the MMG. At the core, there is an MMG manager that allows the
loading and configuration of different translation modules implemented as docker containers.
Depending on the source and target system, a fitting translation module can be configured and
instantiated. A repository provides the docker modules. The morphing concept is based on the idea that
the MMG can be dynamically adapted or even adapt itself during runtime: the MMG changes itself, it
morphes.
Depending on the platforms or technologies between which the translation is supposed to happen, the
modules can be relatively simple or highly complex and may even have more fine-grained adaptation
capabilities. One module that uses semantic information and fucntionalities enabling fine-grained
adaptation is the Adaptive Semantic Module, whose structure is shown in Figure 26.
Technology Plan: Protocols, Standards and Technologies
42
Figure 25: Morphing Mediation Gateway Manager
The Adaptive Semantic Module (ASM) works as follows. It has a discovery process that allows the
discovery of semantically annotated information in the source system, e.g. a oneM2M system. A
oneM2M system consists of a hierarchically structured set of REST resources. To semantically annotate
a resource, a semantic descriptor child resource is created that contains the semantic annotation in RDF.
According to the semantic annotation, the ASM checks whether a suitable translation process exists. If
this is the case, the translation process is instantiated. The translation process subscribes or if necessary
polls the information. The information in combination with the semantic annotation (meta information)
is used as a basis to derive the information necessary for the translation, e.g. to NGSI for FIWARE as the
target system. In the case of NGSI, the entity type, entity id, attribute name, attribute type and possibly
further meta information are required. For this purpose further knowledge and semantic reasoning may
be required. The ASM then creates the target information, possibly transforming the original
information into the required representation and finally it updates the information in the target system,
in this case using the NGSI-10 update operation. The process is continuously repeated for each new
information instance as long as the information is provided by the source system. If this is no longer the
case, the translation process is terminated.
Technology Plan: Protocols, Standards and Technologies
43
Figure 26: Adaptive Semantic Module
3.4 Information Access Layer
The Information Access Layer provides access to information on a higher, common abstraction level. In
Wise-IoT it was decided to instantiate this layer with FIWARE Generic Enablers implementing the
FIWARE NGSI interface. FIWARE NGSI allows applications and components of the Knowledge Processing
Layer to request information, specifying the information they need, and then get back exactly the
requested information. This fulfils REQ2. FIWARE NGSI provides the concept of Entity as an abstraction.
An Entity has an entity type and a number of attributes that provide information about the entity.
Applications can request information about a specific entity or discover entities specifying the entity
type and possibly a scope. This addresses REQ7 on discovery of information. Applications can also filter
on attribute layers. FIWARE NGSI provides both request-response or subscribe-notify interaction styles.
The FIWARE Generic Enabler can integrate information from different sources in the Integration and
Management Layer.
3.4.1 FIWARE Generic Enablers
FIWARE has been developed as the core of the EU Future Internet PPP launched by the European
Commission in 2010. The FIWARE platform has a modularized architecture based on existing standards.
The elements of the platform architecture are Generic Enablers (GEs) for which open source reference
implementations have been made available. In the following subsections we focus on some core GEs
relevant for the Internet of Things, in particular, the Context Broker GE, the IoT Broker GE and the IoT
Discovery GE. All of these GEs are based on the NGSI Context Interfaces that have originally been
developed by OMA. As OMA only developed an abstract interface, the FIWARE project developed a REST
Technology Plan: Protocols, Standards and Technologies
44
binding and proposed changes and enhancements to the original interfaces. The ETSI ISG on Context
Information Management is developing an evolution of the NGSI Context Interface. The intention is that
future versions of the FIWARE GEs will implement these evolved interfaces.
The remainder of this section is structured as follows. First, the OMA NGSI context interfaces, the
FIWARE NGSI bindings and the evolution of the interfaces are presented, which form the basis of the
FIWARE GEs relevant for IoT and their open source reference implementations which are presented in
subsequent subsections: the Context Broker GE, the IoT Broker GE and the IoT Disocvery GE.
3.4.1.1 NGSI Context Interfaces and Evolution
3.4.1.1.1 OMA NGSI Specification
In 2009/2010 the Open Mobile Alliance developed specifications for a set of interfaces, called Next
Generation Service Interfaces (NGSI) as shown in Figure 27. Among these were the interfaces numbered
NGSI-9 and NGSI-10, which deal with Context Management. In the following, only these two interfaces
will be considered.
Figure 27: OMA NGSI Interface Specifications
The NGSI Context Interfaces NGSI-9 and NGSI-10 are based on the Context Information Model depicted
in Figure 28.
Figure 28: NGSI Context Information Model
class Context Information Model
Context Entity
- EntityId: xsd:string
- EntityType: xsd:anyURI
Person Group Place Ev ent Thing
Context Attributes
- Name: xsd:string
- Type: xsd:anyURI
- Value: xsd:any
Meta-Data
- Name: xsd:string
- Type: xsd:anyURI
- Value: xsd:any
*1 *1
Technology Plan: Protocols, Standards and Technologies
45
All information is related to an entity which has an entity identifier and an entity type. Figure 28 gives
some examples of entities, e.g. a concrete real-world entity like a person, place or thing, but can also
represent more abstract concepts like groups or events.
Entities are characterized by attributes, which have a name, a type and a value. In addition there can be
any number of meta information – again represented by a name, type and value.
For example, an entity could be GroupMeetingRoom#1 (unique identifier), which is of type
MeetingRoom and which may have attributes like IndoorTemperature, Occupancy or Size. For the
IndoorTemperature (of attribute type Temperature) relevant meta information may be the Unit (Celsius
or Fahrenheit), the Timestamp of the measurement, the Provenance (sensor that measured it) and the
Accuracy of the measurement.
Figure 29 shows the operations supported by the NGSI-10 interface that is used for accessing and
providing context information itself.
Figure 29: NGSI-10 Operations
In OMA NGSI only interfaces are defined, not complete architectures. Only some very high-level
architectural assumptions are made concerning the role of components. Context producers produce
context information, context consumers consume context information and the Context Management
Component (CMC) is an intermediary that manages the context information. The CMC is a functional
component; it says nothing about the implementation and deployment of this functional component,
i.e. the functions can be implemented by multiple components and in a distributed fashion.
The update operation allows a context producer to update a context value in the CMC. The query
operation enables the context consumer to do a synchronous one-time request. An actor 1 can subscribe
for an actor 2 to be asynchronously and continuously notified whenever a certain notification conditions
is reached. Actor 1 and actor 2 can but do not have to be the same.
Technology Plan: Protocols, Standards and Technologies
46
Figure 30: NGSI-9 Operations
The NGSI-9 interface, whose operations are depicted in Figure 30, supports a distributed operation with
decentralized storage of context information. Actors can register themselves or others with the CMC,
identifying what context information they can provide on request. This means they would identify what
entities and attributes they can provide information for, but not the actual information – the attribute
values – themselves. The CMC can use this registration information to find the relevant producers of
context information when a request is received and only then retrieve and aggregate the information,
before returning it to the requester.
For this purpose, there is again a synchronous one-time discovery operation that returns the currently
registered producers potentially fitting a request and an asynchronous, continuous subscription
operation to be notified about changes regarding the availability of context producers, which can be
relevant for supporting NGSI-10 subscription under changing context producers.
3.4.1.1.2 FIWARE NGSI Binding(s)
As OMA only defined the abstract interfaces for NGSI, FIWARE had to define a binding to be able to
utilize the interfaces. The choice was a REST(-like) HTTP binding, initially using an XML serialization,
which was later replaced by JSON. Figure 31 shows the structure of the REST resources for the NGSI-10
binding in version 1.
Technology Plan: Protocols, Standards and Technologies
47
Figure 31: FIWARE NGSI-10 Binding v1
The interface was separated in two parts. One set of resources provides a one-to-one mapping to the
abstract NGSI-10 operations specified by OMA, and another set of resources is for convenience
operations that implement the REST idea, but only provide a subset of the functionalities provided by
the complete NGSI-10 operations.
Technology Plan: Protocols, Standards and Technologies
48
Figure 32: FIWARE NGSI-9 binding
As shown in Figure 32, the same approach was taken for the NGSI-9 interface.
In the course of the FIWARE project, an evolution of FIWARE NGSI was developed that corresponds to
an evolved functionality of NGSI-10 with the goal of simplifying its use for developers. NGSIv2 is currently
only supported by the Orion Context Broker implementation (see Section 3.4.1.2), which simultaneously
still supports NGSIv1. For NGSI-9 no second version has been defined.
3.4.1.1.3 ETSI ISG CIM - NGSI-LD
Recently the ETSI Industry Specification Group on Context Information Management (ETSI ISG CIM) has
published the NGSI-LD specification (ETSI, 2018). NGSI-LD represents an evolution of the previous NGSI
versions, including previous NGSI-10 and NGSI-9 functionalities. It has been developed with significant
input from Wise-IoT partners (NEC, EGM, KETI) taking into account requirements and experiences from
Wise-IoT, in particular the semantic grounding, enabling semantic interoperability, and the need for
supporting the federation of NGSI systems (see Section 4.4.1), enabling the support of remote
information access as well as roaming users.
Technology Plan: Protocols, Standards and Technologies
49
NGSI-LD uses JSON-LD for the information representation, providing a semantic grounding and to create
a seamless connection to the world of linked data and the semantic web. It is the intention that future
versions of the FIWARE GEs will support NGSI-LD.
3.4.1.2 Context Broker GE
The Context Broker GE has a centralized architecture as shown in Figure 33. The primary assumption is
that context producers update the information in the Context Broker database using the NGSI update
operation. Context consumers can query information using the NGSI query operation or subscribe using
the NGSI subscribe operation. In the latter case, they are asynchronously notified whenever the
notification condition specified in the subscription is fulfilled.
Figure 33: Context Broker Architecture
The reference implementation of the Context Broker GE is called Orion, which is available as an open
source implementation. It supports the NGSIv2 and NGSIv1 JSON bindings.
3.4.1.3 IoT Broker GE and IoT Discovery GE
The IoT Broker GE – whose architecture is shown in Figure 34 – in combination with an IoT Discovery GE
supports a distributed operation, where the actual information is stored in distributed IoT sources, e.g.
IoT Agents, and is only accessed in case the IoT Broker gets a request for which the IoT source may have
relevant information. To enable this, the IoT sources register themselves with the IoT Discovery GE,
specifying what information they can provide, e.g. that they can provide the occupancy of meeting room
A or that they can provide the speed of cars in a given area. On a query, the IoT Broker asks the IoT
Discovery for IoT sources that are possibly relevant, requests the information from each of the sources,
aggregates the information and returns the aggregated information. On a subscription, the IoT Broker
first subscribes for suitable resources, sets up subscriptions with potential IoT sources and notifies the
component to be notified whenever the notification condition is fulfilled. The typical interactions when
requesting information from an IoT Broker are shown in Figure 35.
Technology Plan: Protocols, Standards and Technologies
50
Figure 34: IoT Broker Architecture
As can be seen from the registration examples, different granularities of registrations are possible. This
represents a trade-off, i.e. the more fine-grained the registration, the more registration updates may be
needed, but the fewer IoT sources have to be asked on each request; the more coarse-grained the
registration, the more IoT sources may have to be asked on each query, but the fewer registration
updates are needed.
Technology Plan: Protocols, Standards and Technologies
51
Figure 35: Interactions required when requesting information from an IoT Broker
In order to efficiently support type-based queries, e.g. give me the speed of cars, scopes are important.
Typically not all cars are of interest, but possibly the cars within a certain geographic area. In this case,
a geographic scope can be used. IoT sources register themselves with the geographic area for which they
can provide information about entities of certain type(s). When receiving a request, the IoT Discovery
GE matches the requested scope against the registered geographic area of all registered IoT sources
returning only those for which there is a spatial overlap. This may reduce the number of IoT sources
from a large number that have information about entities of the given type, to a small number which
have information about entities of the given type within the specified geographic scope.
An IoT Broker GE with an associated IoT Discovery GE can also be used as a Federation Broker. In this
case, the IoT sources are not simple information providers, but the brokers (Context Brokers or IoT
Brokers) responsible for whole domains. These brokers would be registered with the IoT Discovery GE
on the federation level on a course grained level with their respective scopes, e.g. can provide
information about parking spots or crowd density in a certain geographic area. For example, the brokers
providing parking information for Santander and Busan could each be registered with their geographic
coverage area and applications requesting parking information from the federation broker with the
respective location scope being either in Santander or Busan would get the information from the broker
with the relevant information.
The reference implementation of the IoT Broker GE is the Aeron IoT Broker and the preferred
implementation of the IoT Discovery GE to work together with the Aeron IoT Broker, supporting
geographic scopes, is the NEConfMan implementation.
3.4.1.4 Mapping to Wise-IoT Architecture
The NGSI-based Context Broker GE and IoT Broker GE are suitable to implement the Information Access
Layer as the NGSI interface provides the right abstraction level, allowing applications to specify the
information they are interested in, so they receive exactly the information fitting the specification as a
result. As discussed in Section 3.4.1.3, the IoT Broker GE in combination with the Discovery GE can be
Technology Plan: Protocols, Standards and Technologies
52
used to implement a federation with Context Brokers or IoT Brokers as IoT sources, representing
complete domains.
3.4.2 OAuth-based Framework for Wise-IoT
3.4.2.1 OpenAM and OpenIG
OpenAM and OpenIG provide flexibility in terms of customizing user Identity and Access Management
(IAM) experience. The solution requirements include design and implementation of a highly performant,
highly available, and scalable digital identity provider service that allows system users to register their
accounts, update their profiles and credentials, use their accounts as a point of reference for identity
federation, and register/reach to other services in the federation.
Figure 36: Intercations (User-Protected reource)
The solution architecture for such an approach is depicted in Figure 36. A session is initiated by a user
browsing to a protected web resource. A Java EE OpenAM Policy Agent sitting in front of the url
intercepts the request from the client (user’s browser) and redirects the request to OpenAM
component, OpenAM will send then to the OpenAM Login Page back to the user, the user needs to
supply the credential, which the OpenAM verifies. If authentication is successful, OpenAM adds the
username of the user and his/her encrypted password to the session and sends it to Java EE Policy Agent.
A Java EE Policy agent validates the user’s session, gives control to OpenIG. Because the URL that the
client requested for the protected resource, matches a specific route (say 04-route.json). configured in
OpenIG, it applies the filters in the route configuration file. The first filter will use a shared key (also
known to the OpenAM) to decrypt the encrypted password sent by OpenAM. The second filter will
retrieve the username and password from the exchange and replaces your browser’s original HTTP GET
request with an HTTP POST login request that contains the credentials to authenticate and the third
filter will remove the username and password headers before continuing to process the exchange. The
server validates the credentials and respond back to OpenIG with user’s profile page. If the server
doesn’t have other security implementation. OpenIG will send that response directly to the End user.
Technology Plan: Protocols, Standards and Technologies
53
3.4.2.2 FIWARE Security
The security architecture of FIWARE is built around the topical areas :
Identity and Access Management
Access Control Decision and Enforcement The security architecture consists of three GEs (Generic Enabler) that together provide a comprehensive
set of services for applications to comply with major security requirements such as authentication and
authorization. Access management in FIWARE is performed as described in Figure 37.
Figure 37. FIWARE Security Architecture
The Identity Management GE in Figure 6 provides user, organization and application identity (and
credentials) management, and authentication. It complies with IETF System for Cross-domain Identity
Management (SCIM) 2.0 Specification, providing a REST API for managing user identities in multi-tenant
cloud-based applications and services. It also provides flexible management of organization-specific
and/or application-specific roles and associated permissions (on specific URLs and actions), as well as
user-role assignments. As shown on the diagram, developers (application owners) interact with the IdM
to register their applications, and manage the security of their application (credentials, roles,
authorization policy); end-users interact with the IdM to self-register, manage their profile and their
organizations. Finally, all users and client applications (e.g. service consumers) interact with the IdM for
authentication and possibly delegate access to a third-party client application (using the OAuth2 flow).
The Authorization PDP GE (PDP) in Figure 37 manages authorization policies in XACML format and
enforces decisions based on them when requested by PEPs to authorize or deny access requests to
services. Besides the interaction with PEPs, the IdM uses the PDP GE (REST API) to manage policies
defined by developers for their application and have them enforced via the PDP API when requested by
PEPs. The Authorization PDP GEri currently available in the catalogue is AuthZForce.
The PEP Proxy GE in Figure 37 plays the role of Policy Enforcement Point in the form of a HTTP reverse-
proxy in front of the protected REST services. The PEP intercepts requests to the service, then
authenticates the access request by requesting the IdM to validate the attached access token; then it
authorizes the request by requesting the PDP with the client access request information and token-
Technology Plan: Protocols, Standards and Technologies
54
related information (such as user attributes retrieved in previous step from the IdM), for the PDP to
decide whether to permit or deny based on the current authorization policy enforced by the PDP for the
requested resource. The PEP applies the PDP's decision to permit or deny the access request. If
permitted, the PEP forwards the request to the service, then forwards the service’s response back to
the client, like a reverse proxy (FIWARE., 2017).
3.5 Knowledge Processing Layer
The Knowledge Processing Layer analyses data from the Information Access Layer to provide higher level
knowledge. In Wise-IoT, the purpose of the Knowledge Processing Layer is to offer mechanisms for
ensuring trust of users and developers in the global IoT systems. Such trust enablement is important
because systems and devices become increasingly connected, and the need for personalization, the
number of points-of-failure, and the exposure to attacks increases.
The data provided by the Knowledge Processing Layer can be categorized into three types of knowledge:
i) knowledge in the form of recommendations for end-users, ii) knowledge provided to developers and
engineers in the form of insights how the systems and the user experience can be improved, and iii)
trust information. Combining these three knowledge types enables developers and engineers to manage
trust and offer users trusted experiences.
This section describes how the Knowledge Processing Layer is implemented with a Self-Adaptive
Recommender (SAR) component (Section 3.5.1) and a Trust Monitor compontent (Section 3.5.2).
Knowledge of the first two types ('i' and 'ii') is provided by the SAR: its IoT Recommender subcomponent
analyzes available IoT and context data to create recommendations for users, and the Adherence
Monitor subcomponent creates insights for developers according to the results of user monitoring and
user feedback. Knowledge of the third type ('iii') is provided by the Trust Monitor: it takes various factors
into account to calculate trust values between entities.
The output from the Trust Monitor is very valuable for the generation of recommendations and thus
also influences the generated insights. This leads to a big dependency between the Trust Monitor and
the SAR, which is the reason why the integration of the Trust Monitor into the SAR is explained in Section
3.5.1 although the Trust Monitor is described in more detail in Section 3.5.2. The combination of the
SAR and the Trust Monitor has been validated successfully in the Santander Smart City use case.
3.5.1 Wise-IoT Self-Adaptive Recommender
This section extends the corresponding section in deliverable D1.2. The first two subsections 3.5.1.1 and
3.5.1.2 are revised versions that contain some changes compared to D1.2: changes include the addition
of a frontend library that simplifies the use of the Self-Adaptive Recommender and encapsulates the
Supersede frontend library, as well as the replacement of the Supersede backend with a context broker
that provides the insights stream to developers or/and engineering tools. The second two Subsections
3.5.1.3 and 3.5.1.4 are new. They explain how the components of the Self-Adaptive Recommender map
to the theory of the Self-Adaptation and Evolution Perspective, and present implementations of the
control loop (Collect-Analyze-Decide-Act pattern (Cheng, et al., 2009)).
3.5.1.1 Approach
The Self-Adaptive Recommender (SAR) component offers mechanisms for managing trust. SAR allows
monitoring of IoT system use and offers cues about potential problems. Developers and engineers may
use these cues to adapt the IoT system and user applications by maintaining and evolving them. SAR is
Technology Plan: Protocols, Standards and Technologies
55
also using these cues for self-adaptation of recommendations that depend on the IoT system to account
for the problems that are discovered. With the help of these mechanisms trust in global IoT systems
becomes observable and, thus, manageable. Thus, the mechanisms contribute towards requirement
REQ10.
The SAR backend consists of four sub-components that carry out the monitoring and adaptation
mechanisms:
- The QoI Monitor checks quality of information (QoI) of the context data data and thereby
contributes to requirement REQ4. It enables system engineers to understand problems in data
syntax and semantics, who may adapt the data sources to comply with formatting constraints
and ontologies. Also, data that is not plausible is reported for checking by systems engineers,
possibly entailing the replacement of defective sensors.
- The IoT Recommender utilizes context information to answer user questions about the real
world that is being sensed by the IoT system. According to the Wise-IoT use cases, such
questions concern the recommendation of point-of-interest locations and the pathways for
reaching these locations. When computing a recommendation for a user, the IoT
Recommender can take the preferences of the user into account. User preferences are stored
in the user application and can be explicit selections/restrictions chosen by the user, or trust
values that originate from previous feedback of the user (see Trust Monitor).
- The Adherence Monitor monitors the use of the recommendations and collects feedback from
users if recommendations are not adhered to. Deviations to recommendations are cues
indicating that information about the real world or assumptions about the user are wrong. It
could be that a parking space is occupied even though the sensor indicates the parking to be
free, that a street is blocked even though the pathway network available to the recommender
indicates that the street is available, or that a user’s preferences have not been considered.
The component shares the gathered insights with other Wise-IoT components for self-
adaptation as well as application developers and systems engineers for informing evolution
and maintenance decisions.
- The Trust Monitor aggregates QoI information and feedback obtained from users to derive an
indicator for the trustworthiness of context data. Such knowledge about trustworthiness
supports decision-making of users. Also, the trustworthiness indicator is considered by the IoT
recommender for self-adaptation purposes, thus treating context data cautiously if that data is
untrustworthy. This process supports trust building between the IoT system and its users
(REQ10). For details, see Section 3.5.2.
The SAR backend component offers a façade that abstracts from the individual components and offers
a single point of access for components that use the SAR. As an implementation decision, Wise-IoT chose
to utilize the Supersede feedback framework to elicit feedback from end-users. Furthermore, Android
applications can benefit from a SAR Frontend Library that takes care of all communication with the SAR
backend and the Supersede framework, and performs some steps automatically. Information about
users is managed by the use case application to account for privacy requirements.
3.5.1.2 Mapping to Wise-IoT Architecture
Figure 38 gives an overview of the SAR and its integration into Wise-IoT.
Technology Plan: Protocols, Standards and Technologies
56
Figure 38: Knowledge Processing Layer featuring the Self-Adaptive Recommender (SAR). Components belonging to the SAR are colored in green, other parts of the Wise-IoT system are colored in blue.
The SAR backend offers the following interfaces for integration into the global IoT system:
- Southbound, the SAR backend interacts with the Information Access Layer (IAL) through the
NGSI interface. The Wise-IoT Morphing Mediation Gateway (MMG) offers connectivity from
FIWARE to the oneM2M Service Layer.
- Northbound, the SAR backend (or alternatively the SAR Frontend Library) interacts with the use
case application to answer requests for recommendations and offer trust-related insights. SAR
utilizes the use case application for eliciting user feedback and for managing user information.
As indicated in the figure, a use case application may bypass the Knowledge Layer and directly
interact with the IAL.
- Eastbound, the SAR backend interacts with engineering tools through a publish/subscribe
interface that offers trust-related insights. An engineering tool may be as simple as a logger that
collects the insights in a format that may be inspected by a developer or engineer. On the
contrary, it can be as complex as a big data analytics tool that feeds packages of issues to
development backlog management tools like Atlassian Jira.
To enable easy deployment and interoperability, the SAR backend component is offered in the form of
Docker containers. SAR is a RESTful component that offers REST APIs for the use case application and
engineering tools. To ease integration into a use case application, an Android SAR Frontend Library is
provided, as well as customized versions of the Supersede front-end libraries for Android and Web
applications3. Southbound, SAR expects a FIWARE ORION Context Broker. Eastbound, SAR can either use
the same Context Broker instance to publish insights, or it can use a separate instance. The SAR only
3 Supersede Deliverable D1.2, https://www.supersede.eu/downloads/deliverables/
Fiware
SARBackend
UseCaseApplication
SARComponent
Facade
SARFrontendLibrarySupersede
FrontendLibrary
IoTRecommender
AdherenceMonitor
EngineeringTools
ContextBrokerwithIoTdata
InsightStream(Context
Broker)
Self-AdaptationandEvolutionPerspectiveApplicationLayer
Know
ledgeProcessingLayer
Inform
ation
AccessLayer
QoIMonitor
TrustMonitor
Technology Plan: Protocols, Standards and Technologies
57
needs to use the FIWARE ORION Context Broker API, which means that in this case, requirement REQ2
is fulfilled. The SAR adopted this philosophy and provides single API to end-user applications.
3.5.1.3 Self-adaptation and evolution components in the SAR
The following table shows the mapping between the components of the self-adaptation and evolution
perspective presented in Section 2.7, and the implemented SAR components.
Table 2: Mapping between component types and SAR functionality.
Component Type
Implementation in the SAR for WiseIoT
Information Sources
<External to the SAR>
Information Collectors
The QoI Monitor is subscribed for updates in the IoT context data. The Adherence Monitor collects session data such as the gps signals from the users and user feedback.
Knowledge Database
SAR backend: The Trust Monitor stores accumulated trust scores, derived from anonymous user feedback. The QoI Monitor stores its analysis results of the context data. The Adherence Monitor manages and temporarily stores the user sessions, and publishes information related to the sessions in the insights stream, such as deviation notifications and user feedback. Frontend: The trust scores of each individual user, as well as the user’s preferences, are stored in the user application for data privacy reasons.
Inference Mechanisms
The IoT Recommender takes IoT context data, user preferences, and trust scores as input and makes recommendations. The QoI Monitor takes IoT context data as input and calculates the data’s quality. The Trust Monitor takes user feedback and data quality values as input and calculates trust values. The Adherence Monitor observes users’ adherence to recommendations and calculates deviations, concluding whether a user followed a recommendation or not.
Knowledge Brokers
The Adherence Monitor publishes user feedback and deviation information in an insight stream. For this purpose, a FIWARE Orion Context Broker is used. Knowledge Subscribers can subscribe for listening to the stream and can then decide based on the received information whether they want to update the system or the user application. The Adherence Monitor forwards user feedback to the Trust Monitor. The derived trust values lead to system self-adaptation.
Knowledge Subscribers
<External to the SAR>
3.5.1.4 Control Loops in the SAR
The SAR contains three control loops following the Collect-Analyze-Decide-Act pattern (Cheng, et al.,
2009) as shown in Section 2.7. The first two loops enable self-adaptation of the SAR system. Collecting
user feedback, trust scores, user preferences and IoT data over time leads to different system decisions.
The third loop enables the evolution of the SAR system and includes the developer in the loop.
Loops for system self-adaptation
• Loop for user recommendations: this loop enables the system to adapt its recommendations to
the users’ context and preferences. [Collect] The system collects information from various
sources. The Adherence Monitor and Trust Monitor components gather user feedback, and the
Technology Plan: Protocols, Standards and Technologies
58
IoT Recommender collects user preferences and IoT data (point of interest information, the user
position, available routes, crowdedness of route segments). [Analyze] The user feedback gets
analyzed for user ratings of IoT entities and context information. The ratings become part of the
user preferences. The IoT Recommender then analyzes the collected information to find good
recommendations for the user. [Decide] Given the available data, the IoT Recommender decides
what the best recommendation for the user could be. [Act] The system presents the
recommendation to the user. The user can follow or deviate from the recommendation, and
give feedback about his/her experience. This information can then again be collected and
analyzed in the next iteration of the loop.
• Loop for mitigating quality problems: the quality of information coming from users and IoT
devices can vary. This loop especially considers the trustworthiness of the data. [Collect] The
QoI monitor collects IoT data through its subscription to updates in the Information Access
Layer, and the Trust Monitor collects user feedback. [Analyze] The QoI monitor checks the
syntax and semantics of the IoT data to analyze the trustworthiness of IoT devices. The Trust
Monitor analyzes the user feedback to obtain further information about the trustworthiness of
individual IoT devices. [Decide] The results of the analysis enable the IoT Recommender to
decide what data can be taken into account for generating user recommendations, and what
data should be ignored because either there is a quality problem with the data or the user does
not trust a particular entity. [Act] The system filters out untrustworthy data and makes sure that
the consideration of corresponding IoT devices is less likely when making a recommendation.
Loop for system evolution
Development loop: the system generates insights about user behavior that help developers in improving
the system. The Adherence Monitor observes the users (non-)adherence to recommendations, and
publishes the observations together with anonymous user feedback in an insights stream. [Collect]
Engineers and developers can subscribe to the insights stream to collect the insights. [Analyze] An
analysis of the insights helps the developers to identify potential problems. [Decide] Depending on the
analysis results, developers can come up with specific hypotheses: wrong information about a route
segment could lead to bad recommendations, the users might particularly like or dislike a specific point
of interest, there could be a usability problem in the user application, a specific IoT sensor could be
broken, etc. [Act] According to the hypotheses, developers can improve the user application, the SAR
system, or replace defect IoT sensors. Their actions will have an influence on the data that they will
receive in the next iteration of the loop.
3.5.2 Wise-IoT Trust Monitor
As the aim of many IoT services, such as those deployed on the Wise-IoT platform, is to autonomously
make decisions without human intervention, trust has been highlighted as a vital feature for establishing
seamless connectivity, secure interactions between components (as illustrated in Figure 39) and reliable
services. A trust platform thus is expected to minimize the unexpected risks and to maximize the
predictability, which helps both IoT infrastructures and services to operate in a controlled manner and
to avoid unpredicted conditions and service failures.
Accordingly, trust related components are supposed to associate all vertical layers of the IoT platform
architecture from the data collection/device actuation layer to application layer. That is, the final value
of trust of specific entity is determined not only by one single parameter but by trust matrices distributed
among users, applications, connections and devices. Moreover, this aggregated data is essential for the
Technology Plan: Protocols, Standards and Technologies
59
decision making process. In the Wise-IoT layered architecture, the trust framework allows collection of
interaction data such as feedback to provide trustwothiness of the interactiing entities. Thus, in the
architecture the trust maps vertically between the data collection and device actuation layer to the
application layer.
Figure 39: Interaction between context-aware applications and context providers via IoT context broker
To simplify its implementation and instantiation, the approach for the design of the Trust Framework
for the Wise-IoT platform, is based on the development and implementation of trust evaluation
processes comprising of some key components addressing related technical issues, as illustrated in the
implementation architecture in Figure 40. Additionally, the trust framework has been instantiated as
trust monitor and integrated into the SAR compoonent architecture in Figure 38, where it has been
deployed to provide trustworthiness knowledge of interacting entities such as users and services..
Accordingly, the following processes have been implemented as integral parts of the trust framework to
support trust monitoring in the Wise-IoT platform.
Figure 40: Trust Management Implementation Architecture
In order to deploy the trust management in the Wise-IoT platform to fulfil its important requirements,
its key functionality such as Trust Data Collection, Trust Feature Extraction, Trust Indicator computation
and Trust Index Evaluator have been designed, implemented and instantriated as as a component(Trust
Monitor). Trust Data Collection and Pre-processing: The data collection implements the ‘Trust Agent’
using the available interfaces or APIs provided by the IoT platform/s data access layer, such as the
Technology Plan: Protocols, Standards and Technologies
60
FIWARE context broker or other REST interfaces, to collect or gather trust-related data. The data could
be Trust Attributes (TAs) data, interaction data between entities of the platform or even opinions of
entities as recommendations or feedbacks as, illustrated in Figure 40, to other entities, applications or
services, etc.
• Trust Feature Computation: The feature computation is responsible for computing/extracting
features from the collected trust related data, such as feedback data as illustrated in Figure 41.
It also pre-processes the collected data to eliminate erroneous or repetitive and other irrelevant
data for trust indicators’ evaluation.
Figure 41: Example of feedback mechanism after each interaction for trust establishment and evaluation
• Trust Data Store: This module is responsible for storing trust related data and the history of
interactions between entities of the IoT platform. Additionally, this historical data store is also
used to store values of trust indicators as well as the trust scores for both trustors and trustees
of the platform. Any trust score consumers, e.g. the Self Adaptive Recommender, can interact
with the trust score store via a Web Service interface, or via the Wise-IoT data access component
such as the FIWARE broker to request such data.
• Trust Indicator Computation: Trust indicator computation implements the one of the
functionality of the Trust Evaluation and Management component, realized based on the REK
model. It is responsible for computing the trust indicators such as experience, reputation and
knowledge. These indicators are computed from trust attributes.
Trust Score Evaluator: This module implements the REK model, the main module responsible for
producing trust scores for trustees, and it evaluates and generates trust scores for IoT entities. The trust
evaluator computes the trust score or index from the combination of trust indicators, e.g. experience,
reputation and knowledge, which are computed by the previous module.
Pilot Site Deployments
61
4 Pilot Site Deployments
Chpater 4 describes the concrete instantiations of the Wise-IoT architecture that are deployed in the
different use case sites. Each architecture instantiation makes use of a subset of the components,
protocols, standards and technologies that have been described in Section 3 and follows the high-level
Wise-IoT architecture specified in Section 2.
4.1 Smart City Use Cases
Some of the WISE-IoT use cases are focused on the smart city paradigm. The objectives of these Smart
City use cases, as all the use cases proposed in WISE-IoT project, are twofold: to assess the
developments carried out in the project, and to provide citizens with services which can be of added
value for them. The Smart City use cases have been focused on two services related to private and public
transport: car parking and bus information provision. Regarding the car parking service, the idea is to
provide a route recommendation to an available parking spot to citizens through two applications which
can be used (both) in Santander and Busan cities. The reason of providing two parking applications is
related to the already mentioned objective of testing the different developments provided by the
project. One of the applications is based on FIWARE technologies, while the other one is based on
oneM2M. By using the interoperability components developed in the project, both applications can be
used in both cities even if the source information is provided through different technologies.
The bus information use case aims to provide a bus information service to citizens in both Busan and
Santander. Hence, it demonstrates, thanks to the interoperability enablers developed in the project,
that it is possible to provide through a single application information gathered from heterogeneous
sources.
Pilot Site Deployments
62
4.1.1 Santander Smart City Use Cases Architecture
Figure 42: Santander Smart City Architecture.
Figure 42 shows the Santander Smart City instantiation of the Wise-IoT architecture. In the picture the
different layers which compose the architecture and which have been described in Section 2.2, are
presented.
At the bottom of the figure it can be found the Data Collection and Device Actuation layer. At this level
it can be found the IoT edge where the data collection takes places. It is formed by different IoT devices
such as parking sensors, traffic sensors, locations devices, WiFi and Bluetooth sniffers, sensors in
vehicles, etc. These IoT devices pour the information to the Santander or NEC Backbone through the
different technologies available in the city: from the legacy deployments relying on Digimesh Wireless
Sensor Networks, to the new deployments taking place within the WISE-IoT project based on LoRa
technology or the NEC Crowd system based on cellular networks.
At the second level, the Integration and Management layer, the aforementioned Santander Backbone is
in charge of collecting all the information from the layer below and adapting it in order to make it
understandable by the upper Information Access layer (IAL) layer. In the case of legacy deployments, or
Pilot Site Deployments
63
others that directly send to the IAL layer, the information is adapted to follow NGSI format and Wise-
IoT data model through the semantic adaptor. However, in the case of the new LoRa deployments in
Santander, which first destination is the oneM2M platform, two different options are available
depending on where the oneM2M GW component is placed. In the case of the LoRa parking deployment,
the information coming from the LoRa sensors arrives to the LoRa gateway (GW) and it is injected to the
Mobious instance through the LoRa-oneM2M adaptor (oneM2M GW) directly installed in the LoRa GW.
In the case of the rest of LoRa devices (e.g. LoRa trackers) the info arrives first to the LoRa GW and later
it is injected to the LoRa backbone (which is an instace of The Things Network (The Things Network, kein
Datum) environment). Once in the LoRa backbone, the information can be injected to oneM2M Mobius
platform through the mentioned LoRa-oneM2M adaptor. In this Integration and Management layer it is
also included the Adaptive Semantic Module (ASM) component, which is in charge of the translation of
the info from oneM2M to NGSI and also the Context-Aware Auxiliary Gateway (CAG) which translates
from the IAL layer to oneM2M. This way, both NGSI and oneM2M applications will be able to get all the
information available through SmartSantander facility.
One level up, the Information Access layer is in charge of providing the interfaces for the access to the
information to the upper layers. In the Santander instantiation of the WISE-IoT architecture, the
information is offered through the NGSI interface provided by the Orion Context Broker, which, as
already mentioned, is fed by the Integration and Management layer.
Finally, at the top layer, in addition to the apps that can be interested in accessing the info provided
through the IAL layer, the Knowledge Processing layer can be found. At this level there can be found the
services offered by the SAR components which aims to analyze the information in the IAL in order to
provide new context information that can be useful for other components or applications. In the case
of the Santander instantiation of the architecture, and in order to support the Rich Parking use case, this
layer embraces the SAR components that provides context information related to the QoI and Trust of
the info and also tools to enhance the functionalities of the application such as routes recommendations
or feedback provision.
Pilot Site Deployments
64
4.1.2 Busan Smart Parking Use Case Architecture
Figure 43: Busan Smart Parking Architecture
The parking service architecture in Busan deployed before this project consists of parking sensors,
gateways, oneM2M platform and parking application. In Wise-IoT, the parking service architecture has
been extended to show interoperability between the oneM2M platform and the FIWARE Context Broker,
which are components of the Integration and Management Layer and Information Access Layer,
respectively.
Using the oneM2M standard interface, the sensor data has been gathered and provided to the oneM2M
platforms and the Context Broker for two different applications for Korean and European service users.
With this interworking architecture, an European user, for example, can still use his/her parking
appliation when they visit Busan or the other Korean cities since data gathered to oneM2M platform
will be accessible by the Context Broker.
Due to governance and semantics implementation issues, the Busan platform data has been mirrored
to KETI’s platform. For this, mirroring application data has been developed using the oneM2M’s
subscribe/notify API over Mca interface. Then the parking data gets semantically annotated by the
annotator application and stored with the raw data. This semantic annotation data is consumed by
Adaptive Semantic Module (ASM) to interprete data and store into the Context Broker.
Like the Santander case, LoRa parking sensors deployed in Korea (e.g. KETI headquarter premise) and
parking data is being stored into KETI’s oneM2M platform. LoRa-oneM2M interworking is deployed for
this use case.
Pilot Site Deployments
65
4.1.3 Busan Bus Information Use Case Architecture
Figure 44. Busan Bus Information Use Case Architecture
The architecture of the Busan Bus Information Use Case is shown in Figure 44; this architecture overview
has been layered according to the Wise-IoT project’s Layered Architecture View in Section 2.2.
This use case architecture heavily uses components from Oliot (Open Language for Internet of Things),
which is an open-source RFID software platform extending the GS1 code system and their standard
architecture to support various IoT connectivity and protocols such as bar code, RFID, ZigBee, and
6LoWPAN. More detailed explanations about GS1 can be found in Section 3.2.1. The GS1 Oliot part of
the use case architecture consists of two main groups of components, which are GS1 Repository &
Discovery Services, and oneM2M Capturing & Accessing Applications.
The GS1 Repository & Discovery Services group of components is composed of EPCIS (Electronic Product
Code Information Services), ONS (Object Naming Service), and DS (Discovery Service). These three
components are grouped for better visualization of Figure 44. This GS1 Repository & Discovery Services
collects bus data coming from various sources, including Santander Bus Data, Busan Proprietary Bus
Data, and any other bus devices that support oneM2M interface. The data is then handled by the
oneM2M Capturing & Accessing Applications; more specifically, the Capturing Application (CA), a GS1-
based Context Creator, collects the data, generates a business context, and forwards it to EPCIS.
Applications can easily subscribe to or use REST/SoAP interface to access the resulting data stored in
EPCIS and context (bus) information. Other systems can also access real-time information from CA using
the oneM2M Mca or the REST interface. ONS and DS are used to resolve the federated EPCIS service.
ONS is a look-up service built on top of DNS (Directory Naming Service), while DS (Discovery Service) is
used to track individual devices when the EPCIS containing devices information is unknown.
Pilot Site Deployments
66
The data processed by GS1 Oliot components is forwarded to oneM2M through a GS1-oneM2M
Morphing Mediation Gateway. In the Integration and Management Layer, the ASM (Adaptive Semantic
Module) of the MMG (Morphing Mediation Gateway) takes care of the translation of data from oneM2M
to NGSI and CAG (Context-aware Auxiliary Gateway) translates data from the Information Access Layer
to oneM2M.
The Information Access Layer takes care of providing NGSI interfaces for information access from upper
layers. The Knowledge Processing Layer provides data analysis for new context information creation,
and the Bus Information System application is at the Application Layer in the Wise-IoT architecture. This
application serves as a demonstration of the explained Busan Bus Information use case architecture.
4.2 Smart Skiing Use Cases
Another focus area of Wise-IoT are use cases in skiing resorts both in the European Alps and in the
Korean Pyeongchang area. Whereas the focus of the Korean use case is purely on the asset tracking
feature, the European use case also supports the conquer the slope feature with the intention of
augmenting the skiing experience. With the asset tracking use case, it is possible to directly show
roaming between Europe and Korea.
4.2.1 Chamrousse Smart Skiing Use Case Architecture
The Smart Skiing use case is deployed in the Chamrousse skiing resort, closed to Grenoble in France. It
uses three kinds of devices that are connected to the Wise-IoT infrastructure through LoRa and HTTP: a
LoRa band offering LoRa based geolocalisation and long distance communication, PIQ robot – a wearable
device providing real time analysis of skiers performance and a crowd detector for estimation of crowd
density and movement patterns within a given area.
Pilot Site Deployments
67
Figure 45: Architecture of the Smart Skiing use cases in Europe.
The Figure 45 presents the target architecture of the Smart Skiing use case that is deployed in Europe.
This use case uses the various layers described in this document to fit the Wise-IoT architecture.
The sensiNact gateway is the main interface between the devices and the Wise-IoT infrastructure. This
platform is deployed closed to the devices, i.e., in the skiing resort. The data are retrieved using either
LoRa or HTTP protocol. Then, the sensiNact Gateway transmits the data to the remote oneM2M Mobius
to process it in the upper layers. A dedicated Morphing Mediation Gateway component, i.e., sensiNact-
oneM2M, performs the translation between the two data models for interoperability.
Data are then sent from oneM2M to FIWARE Orion Context Broker using the dedicated component of
the Morphing Mediation Gateway, i.e., the CAG (Contaxt-Aware Auxiliary Gateway) component.
Depending on the requirements of the Smart Skiing use cases, some of the feature of the application
may require to get processed data from the SAR System or directly from the Eclipse sensiNact Gateway.
Refer to the D1.1 (Wise-IoT D1.1 - Wise-IoT Pilot Use Case Technical Description, Business Requirement,
and Draft High-Level Architecture, 2016) for the details of the use cases.
Pilot Site Deployments
68
4.2.2 PyeongChang Smart Skiing Use Case Architecture
Figure 46: PyeongChang Smart Skiing Use Case Architecture
Figure 46 presents the PyeongChang Smart Skiing Use Case instantiation of the Wise-IoT architecture.
The data from IoT Tracker are retrieved using LoRA protocol on private LoRa infrastructure that is
deployed in Alpensia. LoRa-oneM2M MMG transmits the data to the remote oneM2M Insator instance
(oneM2M Common Service Entity (CSE)) with the oneM2M resource model. Insator can integrate and
manage the received data with not only the oneM2M resource form, but also with Insator’s own
standard form. So, applications connected with Insator can choose communication protocol they want
to use. In Alpensia Smart Skiing use case, we develop Resort Management Application(Web) and Resort
Mobile Application(Mobile) based on insator own standard. Alpensia resort managers lend a tracker to
visitor and track the devices through the resort management application. And vistors can track the their
belongings through the resort mobile Application. oneM2M resources from SensiNact-oneM2M MMG
also can be integrated and managed by Insator, and can be tracked in resort applications.
4.3 Lifestyle Use Cases
The brief description of the lifestyle use case is described below. Smart fitness use case has been chosen
for Lisfestyle use case. Specifically, tennis was selected for the smart fitness use case. The smart fitness
use case is accomplished using the PIQ device for the tennis. . The objective of the smart fitness use case
is to assess the feasibility of the smart fitness using PIQ device and IoT-based healthcare platform. The
Tennis show room use case is created at the Daegu global healthcare center living lab (Daegu GHC living
lab). The PIQ device is installed at Daegu GHC living lab, and communicates with the MAPHIS (Most
Advanced Personalized Healthcare Intelligent Service) platform. In order to support smart fitness use
case, tennis activity data is sent to the PIQ server and the data is then stored at MAPHIS healthcare
platform. The smart fitness pilot can be defined as the deployment of the PIQ device for the tennis for
the purpose of monitoring and enhancing the tennis activity of the tennis player
Pilot Site Deployments
69
4.3.1 Daegu Lifestyle Use Case Architecture
The configuration of Daegu Lifestyle Use Case which has been installed in Daegu global healthcare center
living lab, South Korea is shown in Figure 35. The installed PIQ device communicates with the MAPHIS
(Most Advanced Personalized Healthcare Intelligent Service) platform which is based on oneM2M
standard. MAPHIS also complies with ISO/IEEE 11073 DIM (Domain Information Model) and HL7 (Health-
Level 7) specifications for interoperability of various healthcare devices for connectivity. In order to
support smart fitness center use case, tennis activity data is sent to the PIQ server and the data then is
stored at MAPHIS healthcare platform (cf. Figure 47).
Figure 47: Integration of the IoT platforms for the fitness testbed
In order to use the PIQ device, the users first create their own accounts. The tennis activity data of using
the PIQ devices are then sent directly to the PIQ server via the Wi-Fi. User data is then delivered to the
MAPHIS platform via the web. Intelligent data analysis such as chat-bot can be performed either by
directly accessing the data stored in PIQ server or indirectly accessing the data stored in MAPHIS
platform.
In the following, there will be more detailed descriptions on the pilot which includes the tools provided
to the user, and procedures of the monitoring and displaying the fitness activities using PIQ device and
applications, and evaluation metrics. Figure 48 shows the PIQ application installed in Daegu GHC living
lab. As mentioned before, the smart fitness use case is accomplished using the PIQ device for the
tennis, which is created at Daegu GHC living lab.
Figure 48: PIQ application installed in Daegu GHC living lab
Pilot Site Deployments
70
The procedure for using the PIQ device and tools for monitoring the user activities are as follows:
- The user first provides his/her credentials (name, e-mail, left or right hand) and then places PIQ
Robot on his wrist using a specific accessory. Figure 49 shows the interface for adding a new
participant.
Figure 49: Adding a new participant with user information (right/left hand, name, e-mail)
- PIQ Robot recognizes the motions, computes the metrics related to speed, movement (style),
rotation from which a global score is computed (PIQ score). Then data is sent to a tablet using a
BLE connectivity. Figure 50 shows the PIQ device for recognizing motion and displaying data.
Figure 50: Recognize motion and display data
- The tablet runs a dedicated application. Figure 51 shows the applications’ launching on tablet.
Pilot Site Deployments
71
Figure 51: App launch on tablet
- The tablet is also used to create a short video of the user during his motion. Figure 52 shows the
video of recording user’s motion.
Figure 52: User’s motion recording video
- The motions and video can then be sent to the user. The overall data of the users can be used
for other analysis. Figure 53 shows the measured data.
Pilot Site Deployments
72
Figure 53: Check measured data.
Since the smart fitness use case is created at Daegu GHC living lab, the number and type of users are
variable. For the user, there was questionare sheet for the user’s feedback of using the PIQ device for
tennis. The questionare includes both quantative and qualilative questions regarding to the usage of PIQ
device for tennis. These feedback from the users was collected and analyzed statiscally for the
evaluation of the smart fitenss use case.
4.4 Service Roaming and Cross-Domain Data Reuse Use
Case
As described in Wise-IoT D1.1 (Wise-IoT D1.1 - Wise-IoT Pilot Use Case Technical Description, Business
Requirement, and Draft High-Level Architecture, 2016), the Wise-IoT system shall offer global
interoperability and roaming to anybody who uses IoT systems. Global interoperability implies that an
IoT end-user may access IoT data with his application at the geographical location of the IoT user, as well
as IoT data from remote IoT systems. Mobility implies that an IoT user may use his application originally
developed for the IoT user’s home location also when being physically located at the remote location.
Cross-domain data reuse means that instead of providing separate vertical systems for each use case,
there is the possibility to leverage the same information using one common horizontal system. The
federation technical use case architecture shows how these IoT system properties can be achieved
utilizing the NGSI-based FIWARE architecture.
4.4.1 Federation Technical Use Case Architecture
Figure 54 shows the architecture that enables service roaming and cross-domain data reuse. The
architecture follows the layered architecture view described in Section 2.2 and uses FIWARE / NGSI to
implement the federated architecture as described in Section 2.3.
The idea is that for each domain there is a local installation that provides access to the local information.
Each local installation provides access to its information through a NGSI-based interface that is typically
implemented by a Context Broker or an IoT Broker. To provide seamless access to applications, a
federation layer is put on top, consisting of federated IoT Brokers. Applications request the information
they need from a federated IoT Broker and depending on the scope of the request; the request will be
forwarded to the correct local broker(s).
Pilot Site Deployments
73
Figure 54: Architecture of Service Roaming and Cross-Domain Data Reuse Use Case.
In more detail, to enable NGSI-based applications, as shown in Figure 54, to seamlessly work across
different locations, in Europe and South Korea, information needs to be made available as NGSI-
information using an NGSI interface. Figure 54 shows different cases how WiFi sniffers and Bluetooth
sniffers used for crowd and queue detection can be connected through the respective local platform
installations and exposed through local IoT Brokers or Context Brokers as described in Section 3.4.1.3
and Section 3.4.1.2 respectively. The local platforms and gateways are part of the Integration and
Management Layer, whereas the IoT Brokers and Context Brokers are part of the Information Access
Layer.
In the leftmost case shown in Figure 54, a proprietary source or platform is assumed, and a Morphing
Mediation Gateway is responsible for transforming the proprietary data into NGSI information, which is
pushed to a local broker. This situation is found in Santander, where information is directly provided
through NGSI. In the middle case shown in Figure 54, the sniffers are locally connected to a oneM2M
platform. Semantic annotations within the oneM2M platform enable a Morphing Mediation Gateway
to translate the information to NGSI, which then is also pushed to a broker, which has to be deployed to
complement the local platform enabling the support of NGSI-based applications. Such a scenario is
typical for South Korea, which has local oneM2M deployments. Finally, there may be cases where sensor
devices can directly provide NGSI information, which would then directly be pushed to a broker without
the need for a Morphing Mediation Gateway.
In all three cases described above, there is a local NGSI broker through which applications could access
NGSI-based information, but applications do not know about all these local deployments. However, the
use of NGSI enables adding a federation layer consisting of a federation of IoT Brokers and a registry
based on the FIWARE IoT Discovery Generic Enabler (GE). In NGSI, location scopes can be used for
Pilot Site Deployments
74
requesting information and NGSI sources can be registered using different levels of granularity. Thus,
the local IoT Brokers can be registered on the federation level on a coarse-grained granularity, e.g. the
local Santander broker could be registered stating that it can provide crowd, parking and bus information
for the geographic area of Santander and the local Busan broker could be registered that it can provide
bus and parking information for Busan. The registration can be done by the operator of the local broker
or even by a third party – assuming respective authorization, etc.
An application, e.g. a parking application, can then request parking information via an NGSI request
using a location scope depending on the current user location. If the user is in Santander, this will match
the Santander geographic area, so the federated IoT Broker would get the fitting source from the registry
and would forward the NGSI request to the local Santander broker. If the user is in Busan, it will get back
the fitting Busan broker and the request would be forwarded accordingly – completely seamless for the
application, except for possibly incurring a higher delay due to the additional step.
As described in Section 3.4.1.1, the NGSI interfaces have evolved and currently the Orion Context Broker
GE supports both NGSI v1 and NGSIv2, whereas the IoT Broker GE only supports NGSIv1. As it turned
out in the project, NGSIv2 supports extended JSON data models which are not accessible through the
NGSIv1 API. However, key information models, e.g. the parking information model, make use of these
extended JSON models and thus could not be federated using the IoT Broker. Apart from the problem
that the IoT Broker does not implement NGSIv2, key features of NGSI, in particular what was defined in
the OMA NGSI-9, have not become part of NGSIv2 as they were not needed for the centralized
architecture supported by the Orion Context Broker GE.
As a result, the federation feature could not be as widely used in Wise-IoT as originally intended.
However, a technical validation as shown in Figure 55, using only the NGSIv1-based crowd information,
has been performed and reported in Wise-IoT D3.3 (Wise-IoT D3.3 - Tests and Validation Results, 2018).
Figure 55: Architecture of the Federation Validation Deployment
The problem will disappear in the future – unfortunately not in the project lifetime of Wise-IoT. With
the evolution of the interface to NGSI-LD, which will be supported by upcoming versions of the FIWARE
GEs, both extended JSON models and all functionality needed for federation will be available again.
Wise-IoT project participants, taking requirements and experience from the project, were instrumental
in making contributions in ETSI ISG CIM to ensure that all required features are included in NGSI-LD (ETSI,
2018).
Conclusions
75
5 Conclusions
This deliverable has introduced the Wise-IoT architecture and the Wise-IoT system as a system that
instantiates the Wise-IoT architecture while fullfilling the high-level architecture requirements that have
been identified in Wise-IoT. The architecture has been described following the structure of architectural
views and perspectives. A core contribution of Wise-IoT is the differentiated Layered Architecture View,
which provides different levels of abstraction. Federating IoT systems from different domains is of key
importance for a globally interoperable IoT infrastructure. The explicit modelling of semantics provides
the basis for integrating heterogeneous systems across the different layers and the federated
infrastructure.
In order to support users in the best possible way, the system has to provide recommendations. It then
needs to self-adapt according to the actual behavior of the user and support developers with respect to
the evolution of the system. In this context security and trust are extremely important and thus have to
be incorporated in the design of the Wise-IoT architecture.
The deliverable has discussed the architectural aspects of key standard-based technologies, platforms
protocols & components and to which layers of the Layered Architecture these can be applied. In
particular the oneM2M platform is a suitable fit for the Integration and Management Layer, whereas
the NGSI-based FIWARE brokers can implement the Information Access Layer, enabling the federation
across different domains. With the heterogeneity of the platforms and technologies, the Morphing
Mediation Gateway developed in Wise-IoT WP2 provides the necessary basis for bridging the gaps
between platforms and technologies utilizing the underlying semantic modelling where possible.
The instantiations of the Wise-IoT architecture in the different project sites have been described. It has
been shown which aspects of the architecture are relevant in each site and how the identified
technologies are applied in each case. It has to be noted that in most cases already existing and utilized
deployments have been evolved to conform to the Wise-IoT architecture. The feasibility of this shows
the flexibility of this approach.
With the deployment of Wise-IoT on the project sites in Europe and South Korea to implement the smart
city, smart skiing and lifestyle use cases, plus the service roaming & cross-domain data reuse, which has
been validated as a technical use case, it has been shown that the Wise-IoT architecture:
• provides a suitable basis for a variety of IoT use cases, leveraging information across use cases
• has the ability to integrate heterogeneous IoT technologies and provide uniform access
• provides information access on different abstraction levels (information pyramid)
• enables uniform access to local as well as remote information
• supports roaming users with the same information services at home and abroad
• has self-adaptation features (Self-adaptive Recommender, Morphing Mediation Gateway)
• prescribes the adherence to common security standards to achieve security across platforms
• provides the user with feedback and trust-related information that enables trust building
References
76
6 References
Cheng, B. H., Lemos, R. d., Giese, H., Inverardi, P., Magee, J., & et al. (2009). Software Engineering for
Self-Adaptive Systems: A Research Roadmap. In LNCS 5525 - Software Engineering for Self-
Adaptive Systems (pp. 1-26). Berlin, Heidelberg: Springer.
(n.d.). Décret n° 2015-1926 du 30 décembre 2015 modifiant le décret n° 2012-14 du 5 janvier 2012 relatif
à l'évaluation des moyens d'aération et à la mesure des polluants effectuées au titre de la
surveillance de la qualité de l'air intérieur de certains établiss.
Eclipse sensiNact. (2017, June). Retrieved April 17, 2018, from
https://projects.eclipse.org/projects/technology.sensinact
ETSI. (2018, April). Retrieved from ETSI GS CIM 004 - Context Information Management (CIM) Application
Programming Interface (API) [NGSI-LD]:
http://www.etsi.org/deliver/etsi_gs/CIM/001_099/004/01.01.01_60/gs_CIM004v010101p.pdf
FIWARE. (2017, September). Retrieved from Security Architecture:
https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Security_Architecture
ISO/IEC/IEEE 42010: Systems and software engineering — Architecture description, the latest edition of
the original IEEE Std 1471:2000, Recommended Practice for Architectural Description of
Software-intensive Systems. (2011). Retrieved from http://www.iso-architecture.org/ieee-
1471/
Murdock, P., Bassbouss, L., Kraft, A., Bauer, M., Logvinov, O., Alaya, M. B., . . . Wang, C. (2016). Retrieved
from Semantic Interoperability for the Web of Things, White Paper:
https://www.researchgate.net/publication/307122744_Semantic_Interoperability_for_the_W
eb_of_Things
OCF Specification 1.3, Core Framework. (2018). Retrieved from
https://openconnectivity.org/developer/specifications
oneM2M TR-0007 Study of Abstraction and Semantics Enablement. (2014). Retrieved from
http://www.onem2m.org/images/files/deliverables/TR-0007-
Study_on_Abstraction_and_Semantics_Enablement-V1_0_0.pdf
(2018, December 21). oneM2M TS-0024 oneM2M-OCF Interworking. Retrieved March 15, 2018, from
http://www.onem2m.org/component/rsfiles/download-
file/files?path=Release_3_Draft_TS%255CTS-0024-OIC_Interworking-
V3_0_0.docx&Itemid=238
Rowley, J. (2007, April). The wisdom hierarchy: representations of the DIKW hierarchy. Journal of
Information and Communication Science, 33(2), 163–180.
The Things Network. (n.d.). Retrieved April 18, 2018, from https://www.thethingsnetwork.org/
W3C. (n.d.). Retrieved from Semantic Integration & Interoperability Using RDF and OWL:
https://www.w3.org/2001/sw/BestPractices/OEP/SemInt/
WG03, A. (2017, June). Retrieved from AIOTI High Level Architecture (HLA) Release 3.0:
https://aioti.eu/wp-content/uploads/2017/06/AIOTI-HLA-R3-June-2017.pdf
Wise-IoT. (2017). Retrieved from D2.3 - End-to-End Security and Trust Framework.
References
77
(2016). Wise-IoT D1.1 - Wise-IoT Pilot Use Case Technical Description, Business Requirement, and Draft
High-Level Architecture.
Wise-IoT D1.2 - Wise-IoT high level architecture and reference technologies and standards. (2017).
Retrieved from http://wise-iot.eu/wp-content/uploads/2017/06/D1.2-Wise-IoT-Architecture-
PU-V1.0.pdf
(2018). Wise-IoT D2.7 – Final System.
(2018). Wise-IoT D3.3 - Tests and Validation Results.