Project Number: 723156 Project Acronym: Wise-IoT Project ...wise-iot.eu/wp-content/uploads/2018/09/D1.3-Wise-IoT-Updated... · Introduction 10 1 Introduction An increasing number

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


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


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


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


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.


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.


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.


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


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.


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.


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


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


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


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.


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/

https://www.gs1.org/


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/

http://gs1oliot.github.io/oliot/


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.


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.


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.


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


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


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.


34

Figure 14: OCF Architecture Concept (OCF Specification 1.3, Core Framework, 2018)


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


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.


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


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


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


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.


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.


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.


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.


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.


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.


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.


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


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


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.


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.


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.


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.


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.


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.


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.


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


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.


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-


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


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.


Figure 38 gives an overview of the SAR and its integration into Wise-IoT.


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

https://www.supersede.eu/downloads/deliverables/


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


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


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


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.


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


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.


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.


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.


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.


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.


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


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


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.


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.


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


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


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.

Documents

Project Number: 723156 Project Acronym: Wise-IoT Project ...wise-iot.eu/wp-content/uploads/2018/09/D1.3-Wise-IoT-Updated... · Introduction 10 1 Introduction An increasing number