Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal...

81
Universal Integration of the Internet of Things through an IPv6- based Service Oriented Architecture enabling heterogeneous components interoperability Grant agreement for: Collaborative project Grant agreement no.: 288445 Start date of project: October 1st, 2011 (36 months duration) Deliverable D1.4 Updated Version of IoT6 Architecture and SOA Specifications Contract Due Date 30/09/2014 Submission Date 30/09/2014 Version v1.0 Responsible Partner Ericsson Serbia (EYU) Author List Srdjan Krco, Boris Pokric, Dejan Drajić, Peter Kirstein Dissemination level PU Keywords IPv6, IoT6 Architecture Project Coordinator: Mandat International (MI) Sébastien Ziegler [email protected]

Transcript of Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal...

Page 1: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture enabling heterogeneous

components interoperability

Grant agreement for: Collaborative project Grant agreement no.: 288445 Start date of project: October 1st, 2011 (36 months duration)

Deliverable D1.4 Updated Version of IoT6 Architecture and SOA Specifications Contract Due Date 30/09/2014 Submission Date 30/09/2014 Version v1.0 Responsible Partner Ericsson Serbia (EYU) Author List Srdjan Krco, Boris Pokric, Dejan Drajić, Peter

Kirstein Dissemination level PU Keywords IPv6, IoT6 Architecture

Project Coordinator: Mandat International (MI) Sébastien Ziegler [email protected]

Page 2: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

2

Abstract

This document represents the third and final iterative step in the IoT6 architecture definition based on the initial architecture document presented in deliverable D1.2 “First version of IoT6 Architecture and SOA specifications” [47], and an updated IoT6 architecture was presented in D1.3 “Updated version of IoT6 Architecture and SOA specifications” [61] document. The architectural model is based on the requirements and scenarios outlined in deliverable D1.1 “IoT6 Use Case scenario and requirements definition report” of WP1.

Page 3: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

3

Table of Contents 1 Executive Summary ....................................................................................................... 7

2 Terminology/Glossary ................................................................................................... 8

3 Introduction ................................................................................................................... 11

3.1 Purpose and Scope of the document .................................................................. 11

3.2 Task T1.2 on Architecture design ......................................................................... 11

3.3 Structure of the document ..................................................................................... 12

4 Existing IoT Architectures ......................................................................................... 13

4.1 IoT-A Architecture Reference Model .................................................................... 13

4.2 ETSI M2M High-level Architecture view .............................................................. 16

4.3 FI-WARE Architecture view ................................................................................... 17

4.4 IoT Data Model Overview ...................................................................................... 21

4.5 IoT Data Semantics and Ontology ....................................................................... 23

5 IoT6 Architecture .......................................................................................................... 26

5.1 High-level IoT6 Architecture .................................................................................. 26

5.2 IoT6 Architecture – Functional view ..................................................................... 28

5.2.1 Communication Functionality Group ............................................................ 29

5.2.2 Resources and services ................................................................................. 31

5.2.3 Management ..................................................................................................... 32

5.2.4 IoT6 Process Automation ............................................................................... 32

5.2.5 IoT6 Security .................................................................................................... 33

6 Instantiation of IoT6 architecture for pilot purposes ......................................... 34

6.1 IoT6 Concrete Architecture .................................................................................... 34

6.2 IoT6 Interface Specification ................................................................................... 37

6.3 The Impact of the Handle Approach .................................................................... 39

7 IoT6 Scenario Mapping on IoT Architecture Reference Model ........................ 40

7.1 Use Cases (Test groups) ....................................................................................... 43

7.1.1 Meeting scheduling and Meeting room access control ............................. 43

7.1.2 User comfort and energy efficiency: ............................................................. 45

7.1.3 Safety-critical situation: Smart alarm initiation and clearance .................. 47

7.1.4 Building maintenance ...................................................................................... 49

7.2 Services .................................................................................................................... 51

7.2.1 Data access control ......................................................................................... 51

7.2.2 Notification Service .......................................................................................... 53

Page 4: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

4

7.2.3 Data update (handling) ................................................................................... 54

7.2.4 Alarm generation ............................................................................................. 56

7.2.5 Discovery .......................................................................................................... 58

7.2.6 Failure detection .............................................................................................. 60

7.3 Security Use Case .................................................................................................. 61

8 Addressing Recommendation 3 ............................................................................... 63

8.1 Scalability: Inputs from WP7 and Handle ............................................................ 63

8.2 Diversity integration: Inputs from WP4 and WP6 ............................................... 66

8.2.1 Diversity integration of Everything into a common IPv6-enabled layer. .. 67

8.2.2 Diversity integration of Services, Enablers and Third Party Systems. .... 68

8.3 Manageability: Inputs related to DigCovery and WP5 ...................................... 69

8.4 Global security: Inputs from WP2 and Handle ................................................... 70

8.5 Governance ............................................................................................................. 71

8.5.1 Governance of IP Space ................................................................................ 72

8.5.2 Governance of Name Space ......................................................................... 72

8.5.3 Governance of Multi-application Gateways ................................................. 74

8.5.4 Security Functions ........................................................................................... 74

8.5.5 Management of Security ................................................................................. 75

9 Conclusions ................................................................................................................... 77

10 References ..................................................................................................................... 78

Page 5: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

5

List of Figures Figure 1: Relationship between a Reference Architecture, architectures and actual systems (taken from IoT-A [2]) ......................................................................................................................... 14

Figure 2: Relation of an Architecture Reference Model, best practice, and concrete architectures ........................................................................................................................................ 14

Figure 3: IoT-A ARM Functional Model ........................................................................................... 15

Figure 4: ETSI M2M high-level architecture [16] ........................................................................... 17

Figure 5: FI-WARE IoT architecture ................................................................................................ 18

Figure 6: Summary of NGSI10 functionality ................................................................................... 20

Figure 7: Data element representation (FI-WARE definition) ...................................................... 21

Figure 8: Multiple measurements in JSON representation of SenML data ............................... 22

Figure 9: XML representation of SenML data ................................................................................ 22

Figure 10: EXI representation of SenML data ................................................................................ 22

Figure 11: Basic IoT model ............................................................................................................... 23

Figure 12: Resource Directory registration message from IoT resource (end point) ............... 24

Figure 13: Architecture design process ........................................................................................... 26

Figure 14: Initial high-level IoT6 architecture ................................................................................. 27

Figure 15: Functional IoT6 architecture divided into groups. ....................................................... 28

Figure 16: IoT6 Communication Channel Model ........................................................................... 30

Figure 17: IoT ARM Communication Channel Model ................................................................... 30

Figure 18: IoT6 architecture with indicated Gateway functionality .............................................. 31

Figure 19: IoT6 Concrete Architecture ............................................................................................ 35

Figure 20: Example of Legacy Protocol Integration (KNX and BACnet) into IoT6 ................... 36

Figure 21: IoT6 Architecture, Protocol stack mapping .................................................................. 37

Figure 22: Interface specification for the Building Maintenance Process scenario .................. 38

Figure 23: Overview of IoT6 Scenario and Use Cases ................................................................ 43

Figure 24: IoT Functional View ......................................................................................................... 47

Figure 25: Data access control service ........................................................................................... 52

Figure 26: Notification service .......................................................................................................... 53

Figure 27: Data update (handling) service...................................................................................... 55

Figure 28: Alarm generation service ................................................................................................ 57

Page 6: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

6

Figure 29: Discovery service ............................................................................................................. 59

Figure 30: Failure Detection service ................................................................................................ 60

Figure 31 Scalability of systems [62] ............................................................................................... 64

Figure 32: Classification of the presented solutions in function of the communication layer upgraded .............................................................................................................................................. 68

Page 7: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

7

1 Executive Summary Based on the initial architecture document presented in deliverable D1.2 “First version of IoT6 Architecture and SOA specifications” [47], an updated IoT6 architecture was presented in D1.3 “Updated version of IoT6 Architecture and SOA [61] document. The architectural model is based on the requirements and scenarios outlined in deliverable D1.1 “IoT6 Use Case scenario and requirements definition report” of WP1. This version of the document represents the third and final iterative step in the IoT6 architecture definition. The structure of the document is the same as in deliverable D1.3, the sections have been updated and expanded with two new sections, namely 7 and 8. Initially, an overview of the state-of-the-art in the IoT architecture area is provided. This is followed with an updated overview of the existing reference architecture models From the very beginning of the project, the approach to IoT6 architecture design was to reuse as much as possible the outcomes of other FP7 projects (most notably IoT-A [2]), as well as other projects and initiatives like ETSI M2M [6] and FI-WARE [7]. As the IoT-A Architecture Reference Model (ARM) has been significantly improved and elaborated, we aligned the IoT6 Year 1 architecture with the ARM and provided mapping between the two. The revised architecture model is described and presented, highlighting some of the special features related to the fact that the underlying protocol is IPv6. The aim is to utilise properties of this protocol and re-use them within the architecture model, possibly replacing some of the standard components. For example, parts of the service and resource discovery functionality are replaced with the DNS-SD [17] and mDNS [18] based approaches. Furthermore, the global addressing capability of IPv6 makes it possible to directly connect these devices to the backend IoT infrastructure. In Section 6 of the document, an instantiation of the architecture model (i.e. concrete architecture) is presented. The concrete architecture is obtained using the overall reference architecture model devised for the project, based on the requirements, envisaged use-cases and available or feasible engineering strategies. The concrete architecture integrates components developed across different activities within the project and focusing on specific areas of the IoT which are then mapped onto the reference architecture model. As a late development, an extension based on the use of identifiers is introduced. While it can be used much more widely, it carried through only for the security functionality. Nevertheless, the approach has impact also on the communications view. Two new sections have been added in this document. In Section 7, the definition of IoT scenario and its elements in IoT Architecture Reference Model will be given and IoT6 selected Use Cases will be presented according to IoT Architecture Reference Model. Section 8 addresses the reviewers’ comments regarding the IoT non-functional architecture properties: properties of diversity, scalability, manageability, global security, and governance.

Page 8: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

8

2 Terminology/Glossary

Term Definition Backend The backend is the term used for the component

that provides management functionalities for the devices and IoT domain-specific support for the applications. The backend can be connected southbound to IoT compliant devices (devices that implement the standardised interface i.e. ETSI M2M) or Gateways.

Complex event processing System providing functionality to process input data (raw events) in order to generate a smaller set of value-added, aggregated and filtered output data (derived events).

Constrained network A network of devices with restricted capabilities regarding storage, computing power and/or transfer rate.

Data handling This term is used for the component that provides functionality to address filtering, aggregating and merging data from different sources. Applications can then receive value-added data that are relevant to their need thanks to the complex event processing (CEP) component.

Data pooling Enables discovery operations requested both by the backend/platform and by the IoT resources

Device Technical physical component (hardware) with communication capabilities to other IT systems. A device can be either attached to or embedded inside a physical entity, or monitor a physical entity in its vicinity.

Device cluster A device cluster consists of a set of devices sharing common properties, for example protocol, location or type of sensor.

Device with private IP address Device with IP address not globally delegated placed behind appropriate network address translator (NAT) Gateway, or a proxy server.

Device with public IP address Device with public IP address allowing it to be directly connected to the backend (i.e. Internet.

Discovery service A discovery service allows to find unknown resources/entities/services based on certain search properties. It may be utilised by a human or another service.

Domain A domain model describes objects belonging to a particular area of interest. The domain model also defines attributes of those objects, such as name

Page 9: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

9

and identifier.

ETSI M2M Resource-oriented M2M interface standard defined by ETSI.

FI-WARE NGSI 9 Enhanced NGSI enabling applications to subscribe to the dynamic registration of entities in the system (both IoT resources and Things).

Handle A specific system for working with digital object architecture.

HGW Half Gateway is the element that bridge non-IPv6 enabled technologies with an IPv6-powered environment.

IoT broker Maps events received from devices into events that can be forwarded to the FI-WARE publish/subscribe broker using FI-WARE NGSI compatible formats.

IoT6 Gateway IoT6 Gateway is providing inter-networking and protocol conversion functionalities between devices and the IoT backend. Furthermore, the IoT Gateway provides advanced functionality such as resource discovery and management, device handling mechanisms data access and handling etc.

IP device A device using IP as network layer communication protocol.

Large IPv6 cluster Large device (sensor) network and where the multicast traffic is considered to be inefficient, in which it is better to employ the DNS-SD methodology, where additional DNS server is placed within the network, serving as a local database with resource records (RRs) structured as per DNS-SD convention.

NGSI 9/10 Manages the simple concept of ‘entities and properties’. It deals with metadata, i.e. the configuration, management aspects, allowing queries and to trigger events when a new entity or property appear, or the value of a property has changed, providing in this way a very simple, clear and high performance API [14].

Non-IP device A device which does not use IP as network layer communication protocol.

Protocol adapter These components are part of Gateways used primerily to convert from one to another communication protocol.

Protocol API Components that are used to provide access to

Page 10: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

10

the IoT devices using specific protocols and semantics.

Public/private encryption A class of encryption that uses a private key encryption or decryption, and the corresponding public key for decryption or encryption

Publish/subscribe broker Allows applications to interchange heterogeneous events following a standard publish – subscribe paradigm.

Resource Resource hosted inside a device and enabling access to the device and thus to the related physical entity.

Resource directory Common storage which hosts descriptions of resources held on other servers, allowing look-ups to be performed for those resources.

Restricted network Network that is accesible only for authorized users.

SaaS Software as a service.

Service control (admission) Provides ability to monitor the overload conditions of the IoT services enablement platform and in case the platform is under stress conditions. Therefore it rejects incoming messages without any further treatment but provides a log of the received messages.

Small IPv6 cluster A cluster with small number of devices (sensors) and with an efficient multicast infrastructure, where it is possible to implement a direct service discovery using only mDNS (or lmDNS).

Smart thing Generally speaking, a thing is any physical object. In terms of IoT however, it denotes the same concept as a physical entity. The term "smart" denotes the ability of the device to perform more advanced operations such as network connection, data exchange and data processing.

STIS Smart Things Information System.

Things and resources management

Provides functionality to register and discover things, IoT resources and relationships between them.

Unconstrained network An unconstrained network is a network of devices with no restriction on capabilities such as storage, computing power, and / or transfer rate.

Unrestricted network Part of the network allowing unrestricted access.

Page 11: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

11

3 Introduction

3.1 Purpose and Scope of the document The IoT6 research project aims at researching and exploiting the potential of IPv6 to develop a service oriented architecture overcoming the current Internet of Things fragmentation. The presented document is related to Task T1.2 on Architecture design, which specifies the IoT6 architecture. This document represents an update of deliverables D1.2 “First version of IoT6 Architecture and SOA specifications” [47] and D1.3 “Updated version of IoT6 Architecture and SOA [61]. It further specifies the initial IoT6 architecture based on the output of other work packages as well as developments in the IoT community. NOTE: Deliverable D1.3 is not a delta update of deliverable D1.2 (Initial IoT6 architecture), but the full document which replaces D1.2, while this document D1.4 is delta document to deliverable D 1.3.

3.2 Task T1.2 on Architecture design Based on the IoT6 requirements definition (from Task T1.1), the objectives of this Task are to design and describe the IoT6 IPv6-based Service Oriented Architecture to be developed in order to integrate heterogeneous subsystems of the Internet of Things. During the first year of the project, different architectural options were evaluated against the scenarios and requirements, discussed among the IoT6 participants and the advisory board members. These activities resulted in the initial IoT6 architecture presented in deliverable D1.2 [47], designed to enable integration and interaction among various components of the Internet of Things (including sensor networks, mobile phones, STIS (RFID) and building automation systems), as well as their integration with cloud computing applications (Software as a Service) and business processes management tools. The initial IoT6 architecture identifies the main system components and their functionality, interaction patterns, interfaces and the underlying communications links. In this document, an updated version of the IoT6 architecture is described, further specifying various IoT6 system components as well as the ontology to be used in order to assure heterogeneous integration and provide interoperability among them. The work done in WP2 (IPv6 Connectivity) and WP5 (Smart Board and Intelligence distribution) has been taken into account, in particular in the areas of security and privacy aspects of the interactions (how the IPv6 features support security mechanisms in the transport of information and how security and privacy could be integrated within the interactions with the objects based on the service layer being proposed and their implications on the architecture design). Particular care was given to consider the privacy issues from an end user perspective provided by MI and its supported UN delegates. In addition to the input from other work packages of the IoT6 project, inputs were taken from interactions with the IoT community, in particular with the IoT-A project. IoT6 participated in an IoT-A project workshop on IoT architecture providing feedback to IoT-A and discussing their proposed Architecture Reference Model in particular in the communication domain. Furthermore, the IoT6 project participated in meetings with the FI-PPP project FI-WARE and has aimed to align these initiatives as well as

Page 12: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

12

co-organized a workshop with IoT-A on IoT architecture during the 2013 IoT week in Helsinki. The final update of the IoT6 architecture took place during the last year of the project, integrating all project developments and results.

3.3 Structure of the document The document first addresses the existing IoT architectures (Section 4). Instead of developing a new architecture, we adopted an approach of building on top of the existing IoT architectures and aligning it with the ongoing related developments in several projects and standardization bodies. Section 5 provides a description of the updated IoT6 architecture. A description of a concrete system based on the IoT6 architecture is provided in Section 6. In Section 7 the definition of the IoT scenario and its elements in the IoT Architecture Reference Model is given and IoT6 selected Use Cases are presented according to the IoT Architecture Reference Model. Section 8 addresses the reviewers’ comments regarding the IoT non-functional architecture properties. Section 9 concludes the document with a summary of our conclusions and some suggestions where further work is required.

Page 13: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

13

4 Existing IoT Architectures Over the years, a number of projects have specified their own versions of IoT architectures, basing them on the specific requirements the projects were addressing (IoT-A, IoT-I, and SENSEI, etc.). Due to a large heterogeneity of application domains and consequently the requirements, the approaches to the architecture specification differed between the projects thus resulting in different, more- or less- complex architectures comprised of a number of components and protocols. In the recent period, a significant effort was invested to harmonize the different approaches and to specify a single IoT reference architecture. The most prominent work was done in two FP7 projects, IoT-A and FI-WARE, and in the framework of the ETSI M2M Technical Committee [6] initially and now oneM2M [46]. The approach we selected towards the definition of the IoT6 architecture was to leverage the on-going related activities and base the initial IoT6 architecture on the available IoT architecture specifications. Therefore, we first analysed the work done by IoT-A [2], ETSI M2M [16] and FI-WARE [7]. Based on the results of the analysis, we focused on those components and functions of these architectures that can be enhanced with IPv6 features and IoT6 needs. In the following sections, the ETSI M2M and FI-WARE architectures are described. The activities in the IoT-A project are highly relevant and have been taken into account in the requirements analysis phase. The IoT-A project specifies an IoT reference model architecture and was used extensively as an input to the FI-WARE architecture specification. As already mentioned in the previous sections, in addition to using IoT-A deliverables, the IoT6 project had several meetings with the IoT-A project to learn about the details of the reference architecture model they proposed as well as to provide feedback based on the IoT6 project achievements up to that moment. The work done in the FP7 SENSEI project has been taken into consideration by both ETSI M2M TC and the FI-WARE project. During the first year of the project, in the course of designing the initial IoT6 architecture, we considered the ETSI M2M (technical specifications issued) and FI-WARE (architecture based on a number of inputs taking into consideration various recent activities) as the most advanced in terms of the IoT/M2M architecture specification. Hence, we decided to use these activities as the basis for the initial IoT6 architecture. In the meantime, IoT-A has done a considerable effort and produced a number of relevant outputs providing a larger framework for designing IoT architectures. Therefore, in this document, we leveraged this effort and updated the initial IoT6 architecture according to the provided best practices and guidelines.

4.1 IoT-A Architecture Reference Model The main aim of the IoT-A project was to propose an IoT Architecture Reference Model (ARM). The intended usage of the ARM is the following:

• To serve as a cognitive aid – guiding discussions since it provides a common language to everyone involved and helping in identifying independent building blocks of an IoT system;

• Common grounding – definition of IoT entities and describing their basic interactions and relationships with each other, i.e. the ARM provides common

Page 14: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

14

concepts that should be used to build compliant IoT systems;

• Generation of architecture – IoT ARM can be used for the generation of compliant architectures for specific systems using provided best practices, and facilitating creation of interoperable IoT systems;

• Benchmarking – standardized description, ordering and delineation of components provide a high level of transparency and inherent comparability to the benchmarking process.

The relationship between reference architecture, architectures and the actual systems is outlined in Figure 1. Reference Models and Reference Architectures provide a description of greater abstraction than what is inherent to actual systems and applications. They are more abstract than system architectures that have been designed for a particular application with particular constraints and choices. Guidance in the form of best practices can be associated to reference architecture in order to derive use-case-specific architectures.

Figure 1: Relationship between a Reference Architecture, architectures and actual

systems (taken from IoT-A [2])

Figure 2: Relation of an Architecture Reference Model, best practice, and concrete

architectures

Figure 3 shows a functional view of an IoT-A ARM containing seven longitudinal functionality groups complemented by two transversal functionality groups (Management and Security). These transversal groups provide functionalities that are required by each of the longitudinal groups.

Page 15: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

15

Figure 3: IoT-A ARM Functional Model

For IoT6, of particular interest are the following functionality groups: IoT Business Process Management, Communication, Device and Security. The IoT Business Process Management Functionality Group (BPM FG) relates to the integration of traditional business process management systems. The overall aim of this FG is to provide the functional concepts and interfaces necessary to augment traditional business processes with the idiosyncrasies of the IoT world, so that enterprises can effectively utilize IoT subsystems adhering to common standards and best practices, thus avoiding the overhead and costs of isolated and proprietary “intranet-of-things” island solutions. The Communication Functionality Group (CFG) aims to tackle all communication needs of IoT-A compliant systems. Both data plane and control plane are taken into account. The CFG enables addressing and routes propagation in order to enable various communication modes and bypassing the limitation of hop-to-hop communication. The CFG ensures as well reliable communication and flow control, and even expands it to multiple flows, enabling in this way QoS enforcement. The CFG ensures also energy optimization exposing functions dealing directly with the radio control but also application level duty cycles. Finally, the CFG enables bridging among different networks, allowing Devices to perform as a network entry point implementing forwarding, filtering, connection tracking and packets aggregation functions. All those functionalities are as well supported by an error detection and correction infrastructure implemented by this FG. The proposed communication model aims at mimicking the ISO/OSI stack, but it puts the focus on IoT systems requirements and characteristics. Different channel models are envisaged, ranging from constrained networks only to a mix of constrained networks, Gateways and Internet. Of particular importance are the Gateways which according to IoT-A is a forwarding element, enabling various local networks to be connected. The Security Functionality Group (Security FG) is responsible for ensuring the security and privacy of the IoT-A compliant system. It is in charge of handling the

Page 16: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

16

initial registration of a client to the network in a secure manner. This ensures that only legitimate clients may access services provided by the IoT infrastructure. The Security FG is also in charge of protecting the user's private parameters by featuring anonymity (ensuring that the user’s identity remain confidential when he accesses a resource or a service) and unlink-ability (ensuring that the user may make multiple uses of resources or services without an attacker being able to establish links between those uses). This privacy support relies on fine-tuned identity management, able to assign various pseudo-random identifiers to a single user. Finally, the Security FG enables secure communications between peers by managing the establishment of integrity and confidentiality features between two entities lacking initial knowledge of each other.

4.2 ETSI M2M High-level Architecture view Figure 4 shows the high-level M2M architecture as defined by ETSI technical specification [8]. This architecture consists of two distinct domains: the device and Gateway domain and the network domain. As the name implies, components of the device and Gateway domain are IoT/M2M devices and Gateways. IoT/M2M Gateways enable communication of M2M devices with other parts of the system via access networks, i.e. wide area network. There can be one or more M2M devices connected to a M2M Gateway. In principle, M2M devices connected via Gateway do not implement the so called M2M applications and M2M service capability functionality. However, if a M2M device implements the M2M applications and M2M service capability functionality, then this device can be connected directly to the access network and interact with the rest of the system. The network domain consists of the wide area communication network (access and core networks), M2M service capabilities and M2M applications functions. M2M management and network management functions are also components of the network domain.

Page 17: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

17

Figure 4: ETSI M2M high-level architecture [16]

4.3 FI-WARE Architecture view Figure 5 shows the IoT architecture as defined by the FI-WARE project. This architecture has already taken into account the ETSI M2M specification and has extended it to incorporate OMA NGSI work [9]. The following large functional blocks can be identified in this architecture: backend, Gateway, IoT devices and legacy devices. The deployment of the architecture of the IoT Service Enablement chapter is typically distributed across a large number of devices, several Gateways and the backend. The Generic Enablers shown in the figure below implement functionalities distributed across these elements. The backend functional block provides a number of functions and acts as the main interfaces to access the IoT devices and the information they produce. It provides both REST and NGSI interfaces for interaction with the users as well as corresponding functions like things and resources management; publish/subscribe functionality and connectivity management. The backend can be connected southbound to Gateways and/or IoT compliant devices (devices that will implement the standardised interface i.e. ETSI M2M). Backend consists of three main GEs, namely IoT Broker, Configuration Management and Backend Device Management. The IoT Broker GE is a component for retrieving and aggregating information from the Internet of Things. The Configuration Manager GE (ConfMan GE for short) is the part of the IoT Backend which is responsible for context availability registration. The Backend Device Management GE is the central component for the IoT backend. It

Page 18: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

18

provides the resource-level management of remote assets (devices with sensors and/or actuators) as well as core communication capabilities such as basic IP connectivity and management of disconnected devices. The Gateway provides similar functionality, but on the local level, i.e. it provides functions like things and resource management for the IoT and legacy devices connected to the Gateway. It consists of three GEs, namely Data Handling, Gateway Device Management and Protocol Adapter. The Gateway Device Management GE contains much of the "core" Gateway functionality. It is responsible for the communication with the Backend and IoT and non-IoT devices. The Gateway Device Management GE includes the functional components to handle the registration/connection phases towards the Backend/Platform, to translate the incoming data or messages in an internal format and to send the outgoing data or messages in the ETSI M2M format (marshal/unmarshal). The Data Handling GE addresses the need of filtering, aggregating and merging real-time data from different sources. The Protocol Adapter GE deals with the incoming and outgoing traffic and messages between the Gateway and Devices registered, to be served by the Gateway towards the Gateway Device Management GE or the Data Handling GE. The Protocol Adapter GE translates device specific protocols into a uniform internal API. IoT devices can be connected to a Gateway (e.g. IPv4-based devices with private addresses) or directly to the backend (e.g. IPv6-based devices with public addresses). Legacy devices are always connected via a Gateway.

Figure 5: FI-WARE IoT architecture

Page 19: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

19

The FI-WARE IoT platform provides two fundamental entry points, namely at the application and at the IoT resource level. The application level interface is based on the Next Generation Services Interface (NGSI) specified by Open Mobile Alliance (OMA) [37]. They take the form of a RESTful binding specification of the two interfaces defined in the OMA NGSI Context Management specifications, namely NGSI-9 and NGSI-10. The central aspect of the NGSI-9/10 information model is the concept of entities. Entities are the virtual representation of all kinds of physical objects in the real world. Examples for physical entities are tables, rooms, or persons. Virtual entities have an identifier and a type. For example, a virtual entity representing a person named “John” could have the identifier “John” and the type “person” [38]. The entities have their attributes and attribute domains when more attributes are grouped together. Exchange of entity information is performed with context elements which contain information about multiple attributes of one entity. The three main interaction types are allowed and these are:

• One-time queries for context information

• Subscriptions for context information updates (and the corresponding notifications)

• Unsolicited updates (invoked by context providers)

Page 20: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

20

Figure 6: Summary of NGSI10 functionality

The mapping of NGSI-10 functionality to a resource tree is shown in Figure 6 whereby POST only methods are colored in green, whereas the other operations follow the complete REST approach (GET, PUT, POST and DELETE). Using these methods over HTTP, it is possible to perform all the actions on the IoT resources relevant within the defined architecture model. The IoT resource level interface is generally split into two main parts, namely sensor (and actuator data) and search and discovery entry points. Interface dedicated to the sensor and actuator data is defined with ETSI M2M [6] standard. However, other proprietary protocols can be used which are then transcoded to the platform protocol using associated Protocol Adapter GE functionality. The search and discovery interface is implemented through CoAP [19] for the Gateway Device Management GE as defined in the associated FI-WARE specification [41].

Page 21: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

21

4.4 IoT Data Model Overview A very important aspect of each platform is the overall data model. The main purpose of data model is to provide definition and format of data and the way the data is structured taking into account various parts of the architecture, system requirements and use-cases of the system, thus enabling the interoperability of the system components. This aspect is particularly important having in mind the fact that the overall IoT6 architecture is complex, diverse and that it contains heterogeneous data sources (IoT devices and resources) and diverse data consumers (actuators, applications and other platform components). Data itself refers to information that is produced, generated, collected or observed and that may be subject for further processing in terms of analysis and knowledge extraction. It has an associated data type and value. Subsequently, a data element is usually defined by three attributes, commonly referred to as triplet, namely name, value and type. A data element can have one or more of these triplets and general representation is given in Figure 7 as defined by the FI-WARE Data/Context Management GE [21].

Figure 7: Data element representation (FI-WARE definition)

As can be seen, further to the base attributes, a data element can have additional meta-data associated with it. Meta-data (also referred to as semantic data) is optional and describes the data element(s) in more details, providing further contextual description. Data elements are used within the system in different ways, depending on the component that is handling them. For example, data elements are stored in an appropriate relational (e.g. MySql [48]) or non-relational (e.g. Mongo [49]) database, serialized in XML or JSON if being sent over the network or converted in some other intermediate format in order to support a legacy or proprietary components within the platform. One of the most important aspects of the applied data model is to define the format to be used between the sensors and the core platform. A good candidate for this role is the Sensor Markup Language (SenML) specification that defines new media types for carrying simple sensor information in protocols such as HTTP or CoAP [19]. The core design goal of this schema is to be able to send simple sensor measurements in small packets on mesh networks from large numbers of constrained devices, keeping the total message size smaller than 80 bytes. The data itself is structured as a single object with attributes and associated meta-data resulting in an array of entries. The attributes and meta-data describe the time the measurement was made, current value, and base units etc. Serializations for this data model are defined for JSON, XML and Efficient XML Interchange (EXI) format [23]. The SenML format can be extended with further custom attributes placed in the base object, or in an entry. Extensions in the base object pertain to all entries, whereas extensions in an entry object only pertain to that particular entry.

Page 22: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

22

In terms of the meta-data, this data model is designed so that it carries minimal overhead of the static semantic information which is transmitted or obtained separately. For example, Web resources using SenML representations, this meta-data can be made available using the CoRE Link Format [24]. The CoRE Link Format provides a simple way to describe Web Links, and in particular allows a Web server to describe resources it is hosting. The following example shows how to query one device that can provide multiple measurements. The example assumes that a client has fetched information from a device at the following address: 2001:db8::2, by performing a GET operation on http://[2001:db8::2] at Mon Oct 31 16:27:09 UTC 2011, and has gotten two separate values as a result, a temperature and humidity measurement [22].

{"e":[ { "n": "temperature", "v": 27.2, "u": "degC" }, { "n": "humidity", "v": 80, "u": "%RH" }], "bn": "http://[2001:db8::2]/", "bt": 1320078429, "ver": 1 }

Figure 8: Multiple measurements in JSON representation of SenML data

In the JSON representation shown in Figure 8, different data points are within the curved brackets with the name (“n”), value (“v”) and type (“u”) attributes matching the proposed overall data model above. Further dynamic meta-data (i.e. base name, base time and version) are followed subsequently. There are other attributes available and the details are given in the SenML specification [22]. For the efficient transmission of SenML over e.g. a constrained network, Efficient XML Interchange (EXI) can be used. This encodes the XML Schema structure of SenML into binary tags and values rather than ASCII text. An EXI representation of the SenML SHOULD be made using the strict schema-mode of EXI. Figure 9 shows an example of XML representation of SenML data, requiring 173 bytes. <?xml version="1.0" encoding="UTF-8"?> <senml xmlns="urn:ietf:params:xml:ns:senml" bn="urn:dev:ow:10e2073a01080063" > <e n="temp" v="23.1" u="degC" /> </senml>

Figure 9: XML representation of SenML data

Figure 10 shows the byte aligned EXI representation of XML data

00000000 a00048806c200200 1d75726e3a646576 |..H.l ...urn:dev| 00000010 3a6f773a31306532 3037336130313038 |:ow:10e2073a0108| 00000020 3030363303010674 656d700306646567 |0063...temp..deg| 00000030 430100e701010001 02 |C........|

Figure 10: EXI representation of SenML data Erreur ! Source du renvoi

Page 23: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

23

introuvable. It can be seen that the EXI representation is considerably smaller, resulting in 57 bytes only, leading to more than 3-fold reduction in size. This is especially important when putting this in the context of constrained IoT devices and available network channels. Furthermore, this fits well with the CoAP specification [19] that is well-suited for the short message packets transmitted over UDP. Messages larger than an IP packet result in undesirable packet fragmentation. A CoAP message, appropriately encapsulated, should fit within a single IP packet (i.e., avoid IP fragmentation) and (by fitting into one UDP payload) needs to fit within a single IP datagram. Furthermore, another important aspect of using CoAP is that its choice of message size parameters works well with IPv6 which is very significant in the IoT6 context.

4.5 IoT Data Semantics and Ontology IoT devices are very diverse, providing heterogeneous data, legacy protocols, different data formatting and therefore any low-level access to the devices and data would prove to be very inefficient if not impossible task. Therefore, it is necessary to provide an abstraction layer capable to offer data (or resource) access using the semantic information model. The semantic and ontology can be applied to the well-defined and structured IoT information model. This model should detail various concepts and provide abstractions of the components and their attributes. One of the main goals of IoT is to extend the Internet into the physical world and from this perspective the information model defines a physical entity within the ambient environment. Different “things” (such as a human, an animal, a car, a store, a logistic chain item, an electronic appliance or a closed or an open environment) constitute entities which are the main focus of interactions. These interactions are made possible by a hardware component, a ‘device’, which either attaches to an entity or is a part of the environment of an entity so it can monitor it. The device allows the entity to be a part of the digital world by mediating the interactions. The actual software component that provides information on the entity or enables controlling of the device, is a ‘resource’ [32]. This model is depicted in Figure 11.

Figure 11: Basic IoT model

Based on this model, suitable abstractions are created and defined using interoperable representations. There are different representational entity and

Page 24: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

24

resource models when dealing with semantics and ontology such as Web Ontology Language (OWL) [33]. It is designed for use by applications that need to process the content of information instead of just presenting information to humans. OWL provides three languages which are used depending on the required flexibility, namely OWL Lite, OWL DL and OWL Full. For example, the entity model applied in the IoT-A project [2] is built upon the OWL DL language which is providing maximum expressiveness while retaining computational completeness [33]. There are also other representation models such as OntoSensor [34], service-oriented ontology [35] and SensorData ontology [36] each with their strengths and weaknesses such as not being able to represent sensor data semantically. One of the approaches that has received consensus from the community is “Sensing as a Service” model which represents a scalable way to access the sensor data through standard service technologies. In other words, this approach represents resource and service ontology model supporting search and discovery mechanisms which are among the most important functionalities that are required in IoT. These mechanisms allow locating resources or services that provide data related to an entity of interest in the physical world. In order to support these mechanisms it is necessary to provide structured semantic annotations of the IoT resources, services and data that are being produced. Resource discovery is one of the IoT6 functions. Two approaches are envisaged: Resource Directory [28] and DNS-based Service Discovery [17]. The reason for having two different approaches is to allow simpler registration of legacy devices (requiring small firmware footprint) using the Resource Directory while at the same time supporting more advanced IoT IPv6-based resources using digcovery. Resource Directory (RD) is a component that belongs to the Resource and Service functional group. The RD provides functionality for the resource registration and discovery in compliance with the IETF CoRE specifications [27]. It is also a part of the Gateway Device Management GE within the FI-WARE architecture [26]. The resource directory specification [28] defines the Web interfaces required by Web servers to discover the RD and to register, maintain, look-up and remove descriptions of resources. Furthermore, new link attributes useful in conjunction with an RD are defined. Essentially, a RD is used as a repository for the Web links stored on other servers. From the ontology perspective, one important aspect of RD is that it can be logically segmented by the use of Domains, creating the hierarchical structure. From the semantics perspective, the registration procedure defined within the specification enables description of the resources, their physical location and type of services offered. An example of a registration message is given in Figure 12.

Req: POST coap://rd.example.org/rd?h=node1&lt=1024 Etag: 0x3f Payload: </sensors/temp>;ct=41;rt="TemperatureC";if="sensor", </sensors/light>;ct=41;rt="LightLux";if="sensor" Res: 2.01 Created Location: /rd/4521

Figure 12: Resource Directory registration message from IoT resource (end point)

Page 25: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

25

In this case, i.e. CoAP RD, semantic information about resources is provided with the “rt” parameter, while the ontology component is supported through the domain and directory paths. The discovery mechanism is subsequently followed using the CoRE link format [29] where the process can be performed either using unicast or multicast depending on whether a server's IP address is already known (a priori or resolved via the DNS) or client needs to locate a resource within a limited scope, and that scope supports IP multicast. By using the supported filtering, it is possible to search and discover resources globally, within certain domain, name or capability, providing sufficient flexibility in the context of IoT service search and discovery. Alternative search and discovery mechanism supported through IoT6 platform is based on the DNS protocol relying on the lightweight multicast DNS (lmDNS) for IPv6-enabled Smart Objects in the local domain. For the global discovery, digcovery [30] architectural model is utilized, based on the DNS Service Discovery (DNS-SD). As previously mentioned, DNS-based Service Discovery is utilized in order to take advantage of already existing functionality within the IPv6 stack and therefore supported within different platforms, operating systems, routers, and networking devices. Digcovery allows delegation of different domains to the end-users and/or service providers through the so called digrectories. Each digrectory is able to interact with the local devices and smart things, protecting the accessible and publishable resources from the local domain. The most significant aspect is that it allows for the publishing and linking of the directories to digcovery, which is globally accessible and allows global discoveries by considering the resources from all the digrectories [31]. The architecture is designed to support IPv6-based IoT resources as well as legacy devices through the IPv6 Addressing Proxy. Late in the project, an alternative approach has been developed. One aspect of the main IoT6 architecture has been to define IoT6 addresses algorithmically from properties of the devices using Glowbal. While convenient, this approach has the disadvantage that the addresses will normally be stored in the DNS, which has no confidentiality against inspection. This inspection may reveal more information about devices to unauthorized requestors and their location than is desirable. Hence an alternate approach is to use a repository of identifiers, and have attributes of these identifiers include the IP address of the device and other details. As a vehicle, we have used the Handle system [55], which allows arbitrary properties to be associated with an identifier of the form Type/Value. The advantage of this approach is that the system allows protection against unauthorized inspection of any of the attributes. Thus it is possible to store both security tokens and IP addresses in a manner that is protected against unauthorized inspection. The official releases presented only a programmatic interface to that system that is aimed at monolithic applications by a Java library. However, during the summer of 2014, we were granted a pre-Release version of the system that incorporate REST interfaces, making it more compliant with the IoT-A architecture.

Page 26: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

26

5 IoT6 Architecture Having in mind the potential usage of the IoT ARM listed above and the fact that IoT-A project defined IoT ARM with associated best practices and guidelines, the task of updating the initial IoT6 architecture task is building on top of this work. The methodology used for design of the IoT6 architecture is presented in Figure 13.

Figure 13: Architecture design process

Using the requirements identified and documented in deliverable D1.1 “IoT6 Use Case scenario and requirements definition report” [1], IoT-A ARM and the state-of-the-art in terms of the IoT architecture work, an initial IoT6 architecture has been designed and presented in deliverable D1.2 “First version of IoT6 Architecture and SOA specifications” [47] and updated in this document. While the initial IoT6 architecture work was more relying on ETSI M2M and FI-WARE IoT architectures, the updates of our architecture are more based on the IoT ARM as it matured in the meantime. Over the same period, interactions between our project, IoT-A and FI-WARE regarding the IoT architecture took place as well, which led to better understanding of the choices made by each project and better alignment of the activities. By doing it this way, not only was the creation of the IoT6 architecture sped up, but the outcome of our work will fit into the overall effort (coordinated by the IERC) of creating a common framework for the IoT systems.

5.1 High-level IoT6 Architecture In deliverable D1.2 “First version of IoT6 Architecture and SOA specifications” [47], a high level view of the initial IoT6 architecture is given (Figure 14). As the focus of the IoT6 project is on utilizing IPv6 in IoT systems and integration of heterogeneous application domains, the architecture is mainly dealing with the communication part and integration of business processes/applications. The main components of the initial high level IoT6 architecture are IoT devices (IP and non-IP based), local and

Page 27: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

27

wide area communication network and the server side services and applications.

IoT6 Local Area Network

IoT6 Wide Area Network

IP based devices

SaaS

Mobile applications

Web applications

IoT6 backend server

STISNo

n-IP

bas

ed le

gacy

dev

ices

IoT6

cor

e ar

chite

ctur

e

Figure 14: Initial high-level IoT6 architecture

The top-level mapping of the initial IoT6 architecture shown in Figure 14 to the IoT ARM functional model shown in Figure 3 is described in Table 1.

IoT6 IoT ARM Mobile applications, Web applications, etc.

Application

IoT6 backend server IoT business process management

IoT6 wide and local area networks Communication

Devices Device

Table 1: Mapping IoT ARM to IoT6 architecture

IoT devices (sensors and actuators) can be found at the bottom of the architecture

Page 28: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

28

stack outlined in Figure 14. From an IoT6 perspective, there are two distinct types of devices: IoT6 compliant and IoT6 non-compliant or legacy devices. The IoT6 compliant devices are IPv6 enabled or are using protocols such as 6LoWPAN, GLoWBAL IPv6 [13], CoAP [19] and CoRE [20]. The IoT6 non-compliant devices are based on other, non-IP communication protocols as well as IPv4-based devices. The IoT6 non-compliant devices, require Gateways or proxies to be connected to the rest of the IoT6 system in order to adapt the native protocols, functionality and addressing to IPv6 through a transparent mechanism. The IoT6 Local Area Network (LAN) provides connectivity mechanisms to IoT devices taking into account their specific protocols and technology and making them available to the rest of the IPv6 powered environment in terms of discovery, access and management. The IoT6 wide area network (WAN) enables the interconnection of multiple IoT6 LANs and IoT6 backend servers and provides by this, the overall IoT6 core infrastructure. This infrastructure offers access to the IoT devices from the application-level layer consisting of different services such as Software as a Service (SaaS), Smart Things Information Service (STIS), Web and mobile applications to mention just a few examples.

5.2 IoT6 Architecture – Functional view The functional view of the initial IoT6 architecture is given in Figure 15. It is based on a set of generic functionalities distributed between resource-constrained and non-constrained devices.

Figure 15: Functional IoT6 architecture divided into groups.

The generic functionalities are divided into six groups according to their specific

Page 29: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

29

domains. These domains and their functionalities are described in the following sections.

5.2.1 Communication Functionality Group The IoT6 Communication Functionality Group provides common access to resources and devices, with the main assumption being that IPv6 is the main underlying communication technology used. It is designed to enable integration of various devices employing different communication technologies and protocols, abstracting and adapting them to work with IPv6. To integrate different technologies, the IoT6 communication proposes a networking abstraction layer between devices and applications. This communication abstraction layer integrates smart things, RFID tags, Zigbee devices and any embedded technologies into an uniform networking solution based on IPv6. This abstraction is developed by efficient mechanisms adapted to the limited resources of IoT6 devices in terms of energy and computation. For doing that, IoT6 communication requires several networking agents enabling the interaction between edge devices of the network and high-level applications. Networking agents like routers and Gateways allow the interoperability of underlying communication technologies into a homogeneous solution distributed onto various levels with the following generic functionalities:

• Self-management: IoT6 routers, Gateways and proxies will guarantee the automatic management of IoT6 devices in cases of failures based on pre-established rules.

• Integrity: IoT6 communication will provide effective mechanisms to detect errors produced during the communication process between IoT6 routers, Gateways and devices to ensure succesful reception of the generated traffic.

• Bootstrapping: IPv6-compliant devices will obtain their own IP-addresses exploiting IPv6 features such as stateless auto-configuration and the resource directory to register new devices. For non-IPv6-compliant devices, IoT6 Gateways will provide an IP-address and configuration in the time of joining to the network.

• Addressing: For non-IPv6 based devices, IoT6 Gateways will map their physical layer identifiers with IP addresses.

• Reliability: IoT6 routers and Gateways will provide acknowledgement mechanisms to guarantee communication in IoT6 networks.

• Routing: IoT6 routers and Gateways will enable different communication techniques like unicast, multicast, broadcast and smart-routing. With the later approach using Handle, intermediate processes could be envisaged for carrying out intermediate, technology-dependent operations that would lead to simpler Gateways.

• Mobility: IoT6 routers and Gateways will support the mobility of IoT6 devices between local area networks and the mobility changes are informed to the resource repository in order to update the location of devices.

• Connectivity: IoT6 routers and Gateways will manage communication with IoT6 devices which are sometimes in sleep mode. This management will require to cache temporally the traffic for waiting IoT6 devices to wake up.

Page 30: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

30

• Multiple Identity: An intrinsic capability of IPv6 addressing is that an IPv6-enabled end-point can have multiple addresses. This permits different stakeholders to access the same devices through network paths native to their own application domain.

5.2.1.1 Communication Channel Model The IoT6 Communication Channel Model is presented in Figure 16 and outlines three distinct network domains that are present within the architectural model.

Figure 16: IoT6 Communication Channel Model

The first is the general Internet domain (Internet wide-area), which contains the future Internet core network and its associated components that access this network. This can be mobile networks, monitoring applications, cloud computing (SaaS), user interfaces and information systems. The second network domain covers the IoT intranet (IPv6 local network) containing the IPv6 Services, routers and Gateways used to provide access to sensor clusters. The third domain is the sensor network domain that contains the things with associated sensors connected using a variety of protocols (IPv6 or non-IPv6 based). Similar to the functional model, the communication channel model can be mapped to the communication channel model of IoT ARM (Figure 17). IPv6 and non-IPv6 sensor networks in IoT6 represent constrained networks, IPv6 local and future Internet core network of IoT6 represent Internet in ARM, while mapping of the Gateways is straightforward.

Figure 17: IoT ARM Communication Channel Model

According to the IoT ARM, the use of Gateways is optional. While in general we can agree with such statement, our view is that the Gateways will be more often used than not. A more detailed view of the role and functionality of Gateways are given in

Page 31: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

31

Figure 18.

Figure 18: IoT6 architecture with indicated Gateway functionality

Within the local network (Intranet), all the local Gateways are IPv6-compliant and provide functionalities such as discovery of services and resources, protocol adapters (e.g. HTTP to CoAP, IPv4 to IPv6), smart routing and security and privacy aspects. Half Gateways provide more specific functionalities to the sensor networks in terms of protocols and addressing, taking into account IPv6 based as well as legacy devices (IPv4 and non-IP devices).

5.2.2 Resources and services The IoT6 architecture must provide generic mechanisms to enable IoT6 applications to discover and manage heterogeneous resources. To achieve that, common schemes for identifying and modeling IoT6 resources are needed as well as a resolution infrastructure to associate them with things. Concretely, IoT6 architecture needs a generic identification scheme that permits to address and find heterogeneous IoT6 resources. To solve this problem in the Internet, the domain name system (DNS) has been proposed to assign and resolve unique and universal identifiers for network devices. However, DNS is not adapted to the computation limitations of IoT6 devices and the need of discovering specific properties of an IoT6 resource. Moreover, a common resource modeling is essential to the discovery and look-up of IoT6 resources. Although there are solutions to model sensor networks, they were developed for specific devices and applications. Below, we present the main functionalities implementing IoT6 Resource and Services:

• Resolution: IoT6 resource repository maps an identifier for an IoT6 device to its address or location to enable communication with the IoT6 device.

• Look-up: The IoT6 resource repository maps the identification of an IoT6 resource including the network address of the device to a high-level resource identifier. The identifier of an IoT6 resource and its recent information are stored in a directory where IoT6 applications and services can access.

Page 32: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

32

Unified information models are required to improve the accessibility for IoT6 applications and services.

• Discovery: The IoT6 resource repository enables finding unknown resources by sending specific queries to IoT6 networks. These queries are often distributed using broadcast or multicast techniques within a local area network or within a predefined range. IoT6 devices in the network answer with the resources requested. In parallel, new IoT6 resources that are connected to the network could be self-registered in the repository at the same time.

5.2.3 Management IoT6 management will provide vertical mechanisms for controlling and maintaining IoT6 networks to ensure efficient and effective deployments. These mechanisms should enable the easy deployment of new IoT6 devices and their later software changes. They must support automatically the topology dynamism of IoT6 networks where devices can be in different states (sleep, awake) and their health conditions can change. Moreover, the IoT6 management should support a traffic computing mechanism to redirect the important data from sources to their respective destinations. This automatic mechanism should be scalable and high performing, distributed across IoT6 devices able to process local data according to specific conditions and patterns. The main functionalities for IoT6 management are described below:

• Status monitoring: IoT6 routers and Gateways should provide a generic scheme for monitoring connection status of IoT6 resources in local area networks and integrating alarm events in failure situations.

• Configuration: IoT6 management should provide software reprogramming mechanisms to enable initialization, activation, update, de-activation, and re-activation of resources in IoT6 devices.

• QoS management: For urgent traffic flows, IoT6 devices should prioritize incoming messages through faster routers and Gateways without any human interaction.

5.2.4 IoT6 Process Automation IoT6 process automation will permit configuration of the high-level services employing subscription and rules templates for IoT resources. It requires to share the processing overhead into IoT6 devices in order to achieve a scalable and distributed solution. This distributed processing must be developed using semantic mechanisms to establish interaction between IoT6 devices, routers and Gateways. The main functionalities of the IoT6 process automation are:

• Template: A distributed mechanism based on templates should permit that services perform query operations for IoT6 resources. A template management is required to create and keep templates in order to define the subscription requests or event processing rules.

• Semantic: A semantic technology should be applied to provide related values of IoT6 resources in order to obtain hierarchical dependencies between them. Moreover, an ontology scheme should enable collection of knowledge from IoT resources in real-time.

Page 33: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

33

5.2.5 IoT6 Security IoT6 security should provide privacy, confidentiality, integrity and authentication operations from IoT6 devices to IoT6 applications and services. These mechanisms will be configured based on security policy rules related to IoT6 resource profile to improve the security management allowing human and context changes. The main security functionalities proposed in IoT6 architecture are:

• Privacy: A secure mechanism must control the access of IoT6 resources based on pre-defined access policies for the authorization of IoT6 applications and services.

• Confidentiality: Standard encryption operations will be proposed according to shared keys in order to support confidential communications in local area networks. IoT6 routers and Gateways will use encryption algorithms with distributed keys to decrypt and encrypt the incoming and outgoing traffic from IoT6 devices.

• Integrity: IoT6 routers and Gateways must provide effective mechanisms to detect and recover from transmission errors produced during the communication process.

• Authentication: IoT6 routers and Gateways should enable cryptographic mechanisms to authenticate IoT6 devices when they are joining to IoT6 networks.

Page 34: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

34

6 Instantiation of IoT6 architecture for pilot purposes In the previous sections, the IoT6 architecture was described on the conceptual and functional levels. For the purpose of a concrete implementation, i.e. for the implementation of the first IoT6 demonstration/pilot system, it is necessary to create an instantiation of the described architecture, taking into account the specific design and implementation requirements, constraints and choices. In this section, the IoT6 architecture which will serve as the basis for implementation of the IoT6 pilot system described in detail in deliverables D7.1 “Test process specified” [50], D7.2 “Components Instantiations and validation report” [60], D5.1 “Document on selection of circuits and functionalities” [52] and D4.2 “Multi-protocol architecture and system development report” [51] is presented.

6.1 IoT6 Concrete Architecture This section outlines the architectural view of the IoT6 platform based on the reference architectural model as outlined in Section 5, following the methodology described in Figure 13. In summary, the concrete architecture is obtained using the overall reference architecture model devised for the project, based on the requirements, envisaged use-cases and available or feasible engineering strategies. The concrete architecture integrates components developed across different activities within the project and focusing on specific areas of the IoT which are then mapped onto the reference architecture model as shown in Figure 19. In the context of IPv6 devices to be used in the pilot, hardware platform described in deliverable D5.1 “Document on selection of circuits and functionalities” [42] specifies that they will be based on the 6LoWPAN protocol, backed by the 802.15.4 Gateway. Within the small IPv6 cluster, the resource and service discovery is performed using the mDNS and RD functionality combined together. The mDNS functionality is implemented with Avahi, Free zeroconf implementation, including a system for multicast DNS/DNS-SD service discovery [43]. Within the large IPv6 cluster, the resources are connected to the global discovery engine based on DNS-SD, called digcovery as discussed in deliverable D3.1 “Look up and discovery, context-awareness and resource” [31]. In terms of integration of mobile devices into the IoT6 platform, two main features are implemented as presented in deliverable D6.2 “Ubiquitous access and mobile phone network interactions report” [44]. Firstly, a mobile phone can be used as a Gateway, allowing access to the rest of the IoT6 platform to the external sensors and IoT devices (connected using WiFi or bluetooth). The mobile phone itself is connected to the platform via IPv6 protocol, allowing the global search and discovery via digcovery as well as via resource directory functionality. Secondly, the mobile phone is acting as an IoT device itself, by registering its sensors (camera, accelerometer, gyroscope, microphone etc.) as IoT services to the directory. As it can be seen, there is a RFID cluster, with EPC tags connected together using EPCIS backbone. The search and discovery mechanism is based on EPCIS-DNS digrectory connector locally and using digrectory and resource directory on the global level [31]. In terms of the legacy device, protocols and sensors, Universal Device Gateway (UDG) components are utilized as described in the IoT6 deliverable D4.2 “Multi-protocol architecture and system development report” [51]. UDG represents an

Page 35: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

35

innovative solution that enables interoperability between heterogeneous devices, protocols and standards such as ZigBee, KNX, Bluetooth, X10, RFID, USB and WiFi. The components have been extended in order to map the framework onto the overall IoT6 architecture as reported in deliverable D4.2.

Figure 19: IoT6 Concrete Architecture

IoT6 Backend

IoT6 GatewayMobile or other embedded platform

Protocol adatpter

CoAP Portal HTMLDNS oBIX

oBIXCoAP

SecurityGateway Device Management

CoAP mDNSDNS

SaaS STISWeb applications(UDG UI)

Mobile applications

802.15.4 gateway

Resource Management

Discontinuous Connectivity

CoAP RD

Communication Core

Data Handling

Priority

IPv6 Addressing Proxy

Action Manager

Local StorageProtocol adapter

interface

Large IPv6 clusterRFID cluster

EPCIS

EPCIS-DNS

digrectory

EPC Tag

Small IPv6 cluster

6LoWPansensor

IPv6 Sensor

6LoWPANsensor

6loWPANsensor

DNS-SDdigrectory

mD

NS

mD

NS m

DN

Sav

ahi

Backend Device Management

Resource Management

Discontinuous Connectivity

Communication Core

IPv6 Addressing Proxy

Security

Advanced Connectivity

Things Management

Configuration Management

Discovery Enginedigcovery

Configuration Repository

EPC

IS A

PIR

FID

Discovery API

IPv6 Sensor on

mobile phone

mD

NS

avah

i

Directory API

Directory API

Digrectory

CoAP RD

Digrectory

CoAP oBIXDNS

CoAP oBIXDNS

CoAP oBIXDNS

Legacy cluster

KNX sensor

X10 sensor

ZigBee sensor

ZigBeeKNXX10

ZigBeeGateway

KNXGateway

ZigBeeGateway

UDG middleware

IPv6 mapping module

Dynamic source and parameters

Page 36: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

36

The main components of the UDG framework are shown in Figure 19 integrated within the IoT6 architecture model devised. The appropriate components have been grouped together with other components within the associated functional groups. The IPv6 mapping module is used to translate device identifier of specific legacy protocol to an IPv6 address. Specific features of this component enable, for example, that the same device obtains the same IPv6 address every time it is connected to the same IPv6 Addressing Proxy, providing that the device configuration is not changed. Furthermore, the IPv6 address is unique within the proxy domain. The original feature scope of UDG has been extended through the support of intelligence distribution based on dynamic target and scope selection, dynamic source parameter determination and advanced management of priorities as presented in D4.2 “Multi-protocol architecture and system development report” [51]. These features are supported through the Dynamic Source and Parameters and Priority components. In order to integrate the existing systems and protocols into the overall IoT6 architecture, a stack has been developed aligning the functionalities on both sides and at the same time enabling the legacy devices to run in the same environment. The stack extends the IPv6, JSON and CoAP protocols with the oBIX data model. On top of the protocol stack, oBIX is used as application layer protocol as CoAP does not provide capability to map the identified application features as identified in deliverable D4.1 “First report on the multi-protocol integration” [53]. Some of these components are represented in the overall concrete IoT architecture in Figure 19 as interfaces to the devices and through the UDG Middleware component. Example of such integration is shown in Figure 20 (as reported in D4.2 [51]).

Figure 20: Example of Legacy Protocol Integration (KNX and BACnet) into IoT6

Another view of the concrete IoT6 architecture is shown in Figure 21, indicating the protocol stack mapping to the IoT6 architecture [54].

Page 37: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

37

Figure 21: IoT6 Architecture, Protocol stack mapping

6.2 IoT6 Interface Specification The IoT6 platform provides two fundamental entry points, namely at the application and at the IoT resource level. Additional inter-component communication is defined as per the available concrete technology and standards used within the instantiated architecture as well as the defined use-cases as described in D1.1 “IoT6 Use Case scenario and requirements definition report” [1]. The test processes have been specified within deliverable D7.1 “Test process specified” [50] and this document provides extensive detail regarding the specific interfaces for each of the use-cases to be implemented and covered. The identified use-cases completely cover the functional specification of the platform and ensure that all of the features implemented provide sufficient flexibility for the future platform usage. An example of the interface specification is shown in Figure 22 indicating the components involved and the interface and protocol used for the inter-component communication.

Page 38: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

38

Figure 22: Interface specification for the Building Maintenance Process scenario

As for the application level interface, there are number of functional areas covered, such as search and discovery, resource access and configuration. The search and discovery mechanism is supported through two main interfaces. The first one is based on the DNS protocol through digcovery which splits the architecture into two main parts, namely digcovery and digrectory providing the server-side and client-side interface respectively [40]. The server-side interface is based on the ElasticSearch which is an open source search engine for distributed RESTFul-based architectures and integrated with digcovery [31], [39]. ElasticSearch provides a full Query DSL based on JSON to define queries. The digcovery client API is split across five distinct modules each having its own interface. These modules, namely DigcoveryFormats, CoapLib, DigcoveryComm, MDNSDriver and DNSBindManager and their respective interfaces are described in detail in the API specification [40]. These interfaces are used from the IoT resources side in order to register devices and send the data to the digcovery server. The second interface is based on FI-WARE specification using CoAP for performing search and discovery process. This process is supported by the associated Resource Directory component located within the Gateway Device Management module [41]. In terms of the resource access, the main interface implemented is based on oBIX specification [45] published by Organization for the Advancement of Structured Information Standards (OASIS) in December 2006. This standard defines M2M communication between embedded software systems over existing networks using standard technologies such as XML and HTTP. oBIX is based on service-oriented client/server architecture and defines three request/response services used to read

Page 39: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

39

and manipulate data or to invoke resource operations. Each service response is an oBIX XML document that contains the requested information or the result of the service. The implementation of these three request/response services is called protocol binding. There are two different protocol bindings specified by the oBiX standard. The first protocol is the HTTP binding, which simply maps oBIX request to HTTP methods. The second protocol binding is the SOAP binding that maps a SOAP operation to each of the three oBIX requests.

6.3 The Impact of the Handle Approach Instantiations of the IoT6 architecture using the Handle approach are much less mature than those of the main thread of the work. Indeed, they have been implemented only for a limited set of devices – gateways and IPv6-enabled sensors. This work is described in D5.4 “Intelligence distribution tests and evaluation report” [56]. Nevertheless, this approach was able to provide some features not demonstrated in the main approach. In particular, while the main thread included sophisticated use of IPv6, Digcovery and related communications protocols like CoAP and 6LoWPAN, they did not demonstrate much security. This was not that it could not be demonstrated, but that some of the components used were not powerful enough to allow both CoAP and DTLS. The platforms used had insufficient power, but there was insufficient effort and time to implement the facilities on a more powerful one compatible with the main components, developed near the end of the project. Moreover there was limited security infrastructure in the main IoT6 implementations. As described in Section 8, users could be authorized for certain functions by AAAS techniques, but the infrastructure did not extend to protection of attributes of individual devices. The Handle approach showed also how to perform the functions of the Authorization Server described in D5.4 “Intelligence distribution tests and evaluation report”, and could be used also to store the relevant Authentication and Authorization Tokens in a consistent manner. Further details are given in Section 8.

Page 40: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

40

7 IoT6 Scenario Mapping on IoT Architecture Reference Model

In this section, the definition of an IoT scenario and its elements in the IoT Architecture Reference Model are given. Selected Use Cases are presented according to the IoT Architecture Reference Model. An example of functional view for one IoT Use Case in accordance with IoT-A ARM functional model is given. Firstly, based on the IoT Architecture Reference Model, IoT-A D1.5 “Document on selection of circuits and functionalities” [59] that defines taxonomy of IoT concepts (e.g. Physical, Virtual and Augmented Entities, Devices, Resources and Services) and a set of relationships between those concepts, definitions of IoT model elements is provided. The most generic IoT scenario can be identified as that of a generic User needing to interact with a Physical Entity (PE) in the physical world. The User is a human person or some kind of a Digital Artefact (e.g., a Service, an application, or a software agent) that needs to interact with a Physical Entity. In the physical environment, interactions can happen directly, while in the IoT though, we want to be able to interact indirectly or mediated, i.e., by calling a Service that will either provide information about the Physical Entity or act on it. For example when a Human User is accessing a service, he does so through a service client, i.e., software with an accessible user interface. The Physical Entity is an identifiable part of the physical environment that is of interest to the User for the completion of his goal. Physical Entities can be almost any object or environment; from humans or animals to cars; from store or logistics chain items to computers, and electronic appliances etc. Physical Entities are represented in the digital world by a Virtual Entity. There are many kinds of digital representations of Physical Entities: 3D models, avatars, database entries, objects (or instances of a class in an object-oriented programming language), could be viewed as such a representation, because it digitally represents certain aspects of its human owner, such as a photograph or a list of his or hobbies. Augmented Entity is the composition of one Virtual Entity and the Physical Entity it is associated to, in order to highlight the fact that these two concepts belong together. The Augmented Entity is what actually enables everyday objects to become part of digital processes, thus, the Augmented Entity can be regarded as constituting the “Thing” in the Internet of Things. The relation between Virtual Entity and Physical Entity is usually achieved by embedding into, by attaching to, or by simply placing in close vicinity of the Physical Entity, one or more ICT Devices that provide the technological interface for interacting with, or gaining information about the Physical Entity. By so doing, the Device actually extends the Physical Entity and allows the latter to be part of the digital world. Devices are thus technical artifacts for bridging the real world of Physical Entities with the digital world of the Internet.

Page 41: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

41

Resources are software components that provide some functionality. When associated with a Physical Entity, they either provide some information about or allow changing some aspects in the digital or physical world pertaining to one or more Physical Entities. Resources can either run on a Device – hence called On-Device Resources – or they can run somewhere in the network (Network Resources). On-Device Resources are typically sensor Resources that provide sensing data or actuator Resources, e.g. a machine controller that effects some actuation in the physical world. As Network Resources run on a dedicated server in the network or in the “cloud”, they do not rely on special hardware that allows direct connection to the physical world. They rather provide enhanced Services that require more system resources than Devices typical for what the IoT can provide. Such Resources can process data, for instance, they can take sensor information as input and produce aggregated or more high-level information as output. Also, Network Resources can be storage Resources. IoT Services provide well-defined and standardized interfaces, hiding the complexity of accessing a variety of heterogeneous Resources. The interaction with a Physical Entity can be accomplished via one or more Services associated with the corresponding Virtual Entity. This association becomes important in the process of look-up and discovery. An IoT Service can thus be defined as a type of Service enabling interactions with the real world. On the Figure 23, the core services and the Use Cases are presented in the form of a user scenario taking place in a IoT6 enabled community, where:

• Use Case: Describes how a set of capabilities articulate a functionality offered to the final user and the interactions with the provider platform.

• Service: Defines every capability (or sort set of related capabilities) from a Use Case which can be shown as a core service; it tells a simple interaction between the final user and the service provider platform as elements of a complex service. The user identification and authentication or how the users share a file (photo of the incidence) are examples of core services. The services can be part of different Use Cases in the same or different scenario.

The IoT6 scenario defines in D7.1 “Test process specified” [50] Use Cases for test process that has to be capable of validating the IoT6 architecture that is defined in the IoT6 FP7 project. For the “Final Test Report” D7.2 [60], the original basic test scenarios have been adapted. The three originally introduced scenarios [50]: Maintenance process (Use Case Scenario 1), Safety alert with QoS through IoT6 (Use Case Scenario 2), and Smart Office (Use Case Scenario 3) have been merged into one single extended scenario incorporating all basic functionality of the three initially defined scenarios [60]. This allows a streamlined testing approach and reflects the capabilities of the IoT6 architecture for the future Internet of Things in one single Use Case. The new scenario can be seen as single Use Case or split into 4 well-defined test groups [60]. A formal approach has already been taken in Deliverable 7.1 “Test process specified” [50] and as the proposed scenario is mainly a combination of the three scenarios proposed there. For the introduced scenario, four test groups have

Page 42: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

42

been identified. These test groups reflect the main goals of the presented Use Case. Every test group can be seen as a separate Use Case. Tests groups are the following:

• Meeting scheduling and meeting room access control • User comfort and energy efficiency • Safety-critical situation • Building maintenance

Here, the aforementioned scenarios (Use Cases/test groups) are mapped according to the IoT Architecture model. The following services are included:

• Notification service • Alarm generation • Data update • Failure detection • Data access • Discovery

Figure 23 presents an overview of the IoT6 scenario, Use Cases and relations with services.

Page 43: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

43

Diagram

SCENARIO : IoT6

Meeting scheduling and Room access control

Failure detection

Building maintenance

Scenario Use Cases Services

User comfort and Energy efficiency

Alarm generation

Data update

Safety critical situation

Discovery

Data access control Notification service

Figure 23: Overview of IoT6 Scenario and Use Cases

7.1 Use Cases (Test groups) In this section overview, selected IoT6 Use Cases presented in the IoT Architecture model context is given.

7.1.1 Meeting scheduling and Meeting room access control This test group involves the scheduling of meetings for the meeting room and the conditioning of the room right before the start of the meeting, hence, the supply of comfortable environmental conditions. Further, the group performs tests concerning the meeting room access control. This involves the communication with legacy Building Automation Devices and a local Control and Monitoring System. Detailed explanation of this test group is given below. An employee plans a meeting using a Meeting Reservation Tool which uses a calendar for managing the room reservation. The Meeting Reservation Tool further configures access to the meeting room. For all attendees, the Meeting Reservation Tool therefore keeps a list of RFID tag values enabled for door access and belonging to a corresponding badge which is provided to meeting attendees at arrival time at the office entrance.

The Meeting Reservation Tool constantly checks the calendar and if a meeting is going to be started in the next 15 minutes, the local Control and Monitoring System

Page 44: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

44

(CMS) of the Smart meeting room is contacted to activate HVAC devices ensuring a conditioned environment at the start of the meeting (goal: user comfort). The Local CMS activates the HVAC (i.e. heating) in order to provide the desired room conditions (Communication between Local CMS and IoT6 Multi-protocol Gateway to start HVAC).

The employee (host of the meeting) uses his employee card to enter the meeting room. The Local CMS forwards the message to the Meeting Reservation Tool which checks the time and the identity and grants access to the meeting room. The visitor arrives and obtains a badge (with RFID tag) at the lobby and receives the information about the meeting room and how to get there. The visitor can walk there by him/herself and uses the badge to enter the meeting room. Again, the credentials have to be checked by the Meeting Reservation Tool before opening the door. The Meeting Reservation Tool can also keep track of the visitors attending the meeting.

Actors Involved (and Role played):

• Administrator: A system administrator with permission to register the profile and permissions for users. System management.

• User A: Physical person that interacts with a particular component in the IoT6 architecture. An employee who is scheduling a meeting.

• User B: Physical person that interacts with a particular component in the IoT6 architecture. Visitor, an unprivileged guest attending a scheduled meeting.

• Legacy Devices: RFID reader/door opener/light actuator/heating valve/sun blind actuator/brightness actuator/ legacy alarm device (legacy device): Devices of this class communicate via protocols that are different from the IPv6 protocol, so-called “legacy protocols”. Legacy devices are therefore usually integrated into the IoT6 through some form of the gateway.

• Physical Entities: Phenomena which are observed in the system, i.e. presence of the persons in office.

• Information: Virtual entity as a passive digital artefact, which is the digital representation of the physical entities, a report about a presence.

• Meeting Reservation Tool (SaaS): A resource, i.e. application that allows a human controller to schedule a meeting for a Smart meeting room. The human controller can thereby fix the date when the meeting will start and how long the meeting will last. Additionally, the Meeting Reservation Tool allows the specification of a list of RFID tags representing people who are allowed to enter the meeting room (i.e., meeting attendants).

• Local Control and Management System (CMS): A resource that handles the execution of scenes in the form of rules. These rules may be used to perceive the environment and its status and make the system act accordingly. Further, the component may also host legacy devices connected to the IoT6 through the Local CMS as gateway.

• IoT6 Multi-protocol gateway (IoT6 GW): A resource that provides an IoT6 stack interface for legacy devices which can be deployed on a smart board. The IoT6 GW thereby provides oBIX objects for the interaction with legacy devices and as such acts as a layer of abstraction between IoT6 and heterogeneous legacy devices and their associated networks.

Page 45: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

45

The following services are involved:

• Data access • Notification • Data update

7.1.2 User comfort and energy efficiency: This test group mainly focuses on the correct operation of Building Automation Devices through the IoT6 as well as the application of scenes and the general customization of the building environment. In order to control sensors through a mobile client, it is firstly necessary to discover sensors in the environment. The test group therefore, includes the operation of the environment through mobile clients. It has to be possible to start scenes to reflect different scenarios and customization preferences. Further, the system should act autonomously to some extent and assure a good balance of user comfort and energy efficiency according to the environmental situation and the predicted amount of locally available energy. Therefore, the incorporation of local sensors (e.g., brightness sensor) as well as the weather situation into control strategies is tested. A more detailed explanation of this test group is given below.

The employee uses a Building Automation Services App installed at a mobile device (e.g., a tablet or smart phone) to control the room environment (e.g., temperature, light). This app uses the Global Resource Discovery system to identify nearby sensors and actuators. The surrounding can thus be adjusted to the specific needs. Building Automation Service App (mobile client) communicate with multi-protocol IoT6 Gateway for environmental control. Multi-protocol IoT6 Gateway communicate with legacy devices to control the environment (actuators). Building Automation Service App (mobile client) invokes a scene at Local CMS.

The Meeting Reservation Tool communicates energy saving request to Local CMS. The Local CMS detects that the light intensity is too low by using the light intensity sensor values provided by the tablet/smart phone (Building Automation Services App) and it increases the brightness by turning on more lights. CMS communicate with legacy devices to control the environment (actuators). IoT6 Multi-protocol Gateway observes Internet weather service, and local CMS observes the weather situation at IoT6 Multi-protocol Gateway.

At the beginning of the meeting the weather station reports cloudy weather and thus the power production of the photovoltaic plant of the office building can be considered low. The room temperature set point is decreased to save energy (goal: energy efficiency). During the meeting, the weather station reports sunny weather, which means more renewable energy is available to partially cover the energy consumption of HVAC devices. In this case, the temperature set point is increased again to the comfort temperature level.

Actors Involved (and Role played): • Administrator: A system administrator with permission to register the profile

and permissions for users. System management.

Page 46: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

46

• User A: Physical person that interacts with a particular component in the IoT6 architecture. System engineer.

• Devices: Smartphone, tablet, light switch actuator, and temperature sensor. • Legacy Devices: RFID reader/door opener/light actuator/heating valve/sun

blind actuator/brightness actuator/ legacy alarm device (legacy device): Devices of this class communicate via protocols that are different from the IPv6 protocol, so-called “legacy protocols”. Legacy devices are therefore, usually integrated into the IoT6 through some form of a gateway.

• Physical Entities: Phenomena which are observed in the system, i.e. presence of the sensors and actuators in office.

• Information: Virtual entity as a passive digital artefact, which is the digital representation of the physical entities i.e. a report about a presence.

• Building Automation Services App: A resource, i.e. application that runs on a mobile device and can be used to wirelessly access devices. It may also be used to wirelessly activate or deactivate pre-configured setups. Apart from that, the app allows to receive and distribute messages from a brightness sensor installed at the hosting mobile device.

• Global Resource Directory (GRD): A resource at which IoT6 devices are registered and which can be used to search and discover devices based on certain criteria. It can be used to locate services available within a particular area.

• IoT6 Multi-protocol Gateway (IoT6 GW): A resource that provides an IoT6 stack interface for legacy devices which can be deployed on a smart board. The IoT6 GW thereby provides oBIX objects for the interaction with legacy devices and as such acts as a layer of abstraction between IoT6 and heterogeneous legacy devices and their associated networks.

• Local Control and Management System (CMS): A resource that handles the execution of scenes in the form of rules. These rules may be used to perceive the environment and its status and make the system act accordingly. Further, the component may also host legacy devices connected to the IoT6 through the Local CMS as gateway.

• Meeting Reservation Tool (SaaS): A resource, i.e. application that allows a human controller to schedule a meeting for a Smart meeting room. The human controller can thereby fix the date when the meeting will start and how long the meeting will last. Additionally, the Meeting Reservation Tool allows the specification of a list of RFID tags representing people who are allowed to enter the meeting room (i.e., meeting attendants).

The following services are involved:

• Discovery • Data access

7.1.2.1 IoT Functional View Figure 24 shows a functional view of this IoT Use Case in accordance with IoT-A ARM functional model.

Page 47: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

47

Figure 24: IoT Functional View

7.1.3 Safety-critical situation: Smart alarm initiation and clearance This group basically follows the “safety alert with QoS” scenario already introduced in Deliverable 7.1 “Test process specified”. As such, it involves the detection of a non-critical or critical sensor value and the tagging and forwarding of the message to a smart routing component which applies the smart routing introduced in Deliverable D5.3 “Smart Board intelligence development report, including validation tests” and forwards the message to Control and Monitoring Systems that are particularly concerned with temperature trending or building safety. In further consequence, for a critical message it needs to be tested that the Safety Server invokes a variety of different alarm devices as well as a cloud system, that itself contacts persons responsible for handling the alarm condition (i.e. system engineers). Additionally, it was implemented that the local Control and Monitoring System puts the devices in the room in a safe state as such already actively preventing the propagation of the situation to other parts of the building. As soon as the alarm situation has been handled by the responsible person, a test of the global updating function (i.e. the update that alarm has ceased) has to be performed that controls the correct IPv6 multicast switch-off of alarm devices started before. A more detailed explanation of this test group is given below. An Intelligent Temperature Sensor reads the temperature and performs a tagging of noncritical and critical temperatures according to a predefined threshold. When it detects the low temperature and generates a tagged “normal” message which is sent

Page 48: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

48

to a Smart Router. The Smart Router subsequently applies its routing tables and forwards the noncritical temperature to a Local CMS for temperature trending.

When Intelligent Temperature Sensor in the meeting room detects the high temperature which is out of safety bounds, generates a tagged “alert” message. This message is sent to a Smart Router which applies routing tables and forwards the alarm message to a Safety Server.

The Safety Server informs a Local CMS about the alarm situation. All the devices in the meeting room are grouped using an IPv6 multicast address for the according oBIX data points. The Safety Server therefore, performs a global switch off by sending CoAP PUT messages to this multicast address with simple payloads (e.g., <bool val=”false”/>). This way, all devices in the multicast group can be turned off.

The Safety Server activates IPv6-enabled as well as legacy alarms in the vicinity of the meeting room. It also raises an alert in a Safety and Management Tool (SaaS). The Safety and Management Tool contacts system operators through their mobile phones and the associated Safety and Maintenance App and informs them about the exact location and type of alarm.

Actors Involved (and Role played): • Administrator: A system administrator with permission to register the profile

and permissions for users. System management. • Registered User A: Physical person that interacts with a particular

component in the IoT6 architecture. System engineer, a person who is responsible for maintenance and handling of alarm situations.

• Physical Entities: Phenomena which are observed in the system, and temperature.

• Information: Virtual entity as a passive digital artefact, which is the digital representation of the physical entities, an alarm about abnormal temperature value.

• Smart Router: A resource installed on a smart board and implements the smart routing feature. Messages are forwarded to different components in the network according to the flow-label/traffic class tagging of an IPv6 message.

• Intelligent temperature sensor: Device (Sensor) which is directly integrated into the IoT6 using IPv6. This sensor autonomously detects a value which is “out of bounds” and in this case tags the temperature message as “critical” using flow label and traffic class of a standard IPv6 package.

• Devices: Mobile phone, tablet or smartphone. • Safety Server (CMS): A resource that represent a distinctive form of CMS

which is responsible for handling emergency situations. As such, this CMS includes rules that raise alarms in a particular part of the building in case a critical situation arises. It can interact with a number of components and devices integrated in the IoT6 architecture.

• Local Control and Management System (CMS): A resource that handles the execution of scenes in form of rules. These rules may be used to perceive the environment and its status and make the system act accordingly. Further, the component may also host legacy devices connected to the IoT6 through the Local CMS as gateway.

Page 49: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

49

• Safety and Maintenance App: A resource that runs on a mobile device which is used to receive alert messages and for building maintenance. It can receive alarm notifications to inform a system engineer about an alarm condition. Through this interface, the system engineer can also signal that an alarm situation has been treated and the invoked alarms may be turned off again. The second functionality of the app is building maintenance. In this case, it can communicate with a built-in mobile device RFID reader to scan a device and display information about a device to the user. It also allows to dispatch orders and control the state of an order as well as indicate the correct replacement of a device.

• Safety and Management Tool (SaaS): A resource responsible for distributing emergency messages. It therefore, accepts incoming alarm messages and sends SMS messages to mobile devices. The component keeps an internal list of responsible mobile devices to which an alarm notification is sent. As soon as the alarm has ceased, the service again informs associated mobile devices about the new situation. Another functionality of this component is the management of building maintenance. In this case, the service allows to receive and forward queries for devices based on an EPC code retrieved from an RFID tag. The service also facilitates the forwarding of device orders and querying of their status.

• Notification: Subscribed users (staff members) should receive notifications (alarms) about an abnormal temperature.

The following services are involved: • Data access • Notification • Alarm generation

7.1.4 Building maintenance This test group mainly follows the “building maintenance process” scenario that has already been proposed in Deliverable D7.1 “Test process specified”. In this case, the identification of a device and the involved communication between system parts is tested. Further, the whole order process needs to be covered in this test group which includes delivery tracking of the ordered device. When the new device has been installed, the communication between system operator and cloud system needs to be tested, so that the correct completion of the maintenance process is assured. Below is given more detailed explanation of this test group. After receiving information about the exact location and type of alarm, the system operator goes to the location and after arrival at the source of the alarm, the operator detects a false alarm was raised: the real problem is a malfunctioning temperature sensor. Through the Safety and Maintenance App, the operator acknowledges the alert to the Safety and Management Tool so that the invoked alarm devices are switched off again.

The operator opens the control enclosure and scans the EPC code attached on the temperature sensor device (e.g. KNX) using an RFID reader integrated in the mobile device. Mobile device sends RFID tag request to Safety and Management Tool (SaaS). The Safety and Management Tool (SaaS) uses the EPC code to find out

Page 50: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

50

the responsible Smart Things Information Service (STIS) and queries Global Resource Directory for the product data sheet.

The product data sheet is displayed (e.g. KNX product data sheet based on KNX product data base Web link). The system operator identifies that the device has failed and orders a new device at mobile client. Mobile device sends order request to Safety and Management Tool (SaaS). Safety and Management Tool sends order to Smart Things Information Service (STIS) in the cloud The EPC code of the new device is stored in the Safety and Management Tool. The Safety and Management Tool uses the Smart Things Information Service to keep track of the delivery state of the device. The device arrives and the system operator installs the device and closes the ticket in the Safety and Management Tool.

Actors Involved (and Role played): • Administrator: A system administrator with permission to register the profile

and permissions for users. System management. • Registered User A: Physical person that interacts with a particular

component in the IoT6 architecture. System engineer, a person who is responsible for maintenance and handling of alarm situations.

• Physical Entities: Phenomena which are observed in the system. • Information: Virtual entity as a passive digital artefact, which is the digital

representation of the physical entities, a report about a failure. • Global Resource Directory (GRD): A resource at which devices of the IoT6

are registered and which can be used to search and discover devices based on certain criteria. It can be used to locate services available within a particular area.

• Devices: Mobile phone (local terminal) and temperature sensor. • Notification: Subscribed users should receive notifications about a failure. • IoT6 Gateway: A resource that provides access to a legacy device. • Safety and Maintenance App: A resource that runs on a mobile device which

is used to receive alert messages and for building maintenance. It can receive alarm notifications to inform a system engineer about an alarm condition. Through this interface, the system engineer can also signal that an alarm situation has been treated and the invoked alarms may be turned off again. The second functionality of the app is building maintenance. In this case, it can communicate with a built-in mobile device RFID reader to scan a device and display information about a device to the user. It also allows to dispatch orders and control the state of an order as well as indicate the correct replacement of a device.

• Safety and Management Tool (SaaS): A resource responsible for distributing emergency messages. It therefore accepts incoming alarm messages and sends SMS messages to mobile devices. The component keeps an internal list of responsible mobile devices to which an alarm notification is sent. As soon as the alarm has ceased, the service again informs associated mobile devices about the new situation. Another functionality of this component is the management of building maintenance. In this case, the service allows to receive and forward queries for devices based on an EPC code retrieved from

Page 51: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

51

an RFID tag. The service also facilitates the forwarding of device orders and querying of their status.

• Smart Things Information Service (STIS): A resource that provides a database that keeps information about RFID tags and associated devices. As such it allows the querying of EPC codes and retrieval of information associated with a device corresponding to a particular code. Further, it allows to receive and process orders for devices. A query interface also makes querying for the current state of a device order possible.

The following services are involved:

• Data access • Notification • Failure detection • Data handling (update)

7.2 Services In this section, the IoT6 services are presented. Also, the actors involved in the Use Cases, service requirements and service features are given.

7.2.1 Data access control This service provides an access control to the system components through implementation of all authentication, authorization and accounting (AAA) mechanisms. Access to the virtual entities is provided for the registered users only. Data access is restricted to registered users allowing only those having a digital profile with sufficient privileges to retrieve certain information. Data access control handles several users’ roles. The user creation and management is one of the key components in the platform. The platform should manage several types of user accounts as well as the user authentication in the system. Data access control should be performed in such a way as to limit the access only inside the trusted group.

Page 52: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

52

IoTContext View

Figure 25: Data access control service

Actors Involved (and Role played): • User (A): User with permission to register a new virtual entity, i.e. a profile for

other users. • User (B): A person that accesses the entities directory. • Information: A virtual entity as a passive digital artefact, which is a digital

representation of physical entities. In this case, the main information includes the user identification as well as the other associated information such as roles, permissions etc.

• Entity directory: Resource that contains global information about physical entities, services and other resources.

Service Requirements: • Device ID registration/User registration • User data anonymization • Entities directory • Secure communication between the user and the platform (AAA) • Profile and virtual identity management must be supported • Context and influence on privacy policies must be properly formalized • Identification and authentication mechanisms for involved actors must be

provided • Entities directory (to implement Users Directory) • Depending on access control policies, access requests will be evaluated

Service Features:

• User management AAA

Page 53: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

53

• Secure communication between the user and the platform • Data access to virtual entity in the entity directory • User interface to show access result

7.2.2 Notification Service This service implements notifying capabilities - notifications. Notifications could represent different physical entities, like notifications about failure of the device (system operator receives information about the exact location and type of alarm), alarm about abnormal behaviour of observed phenomena (temperature), and notification about beginning of the meeting. When there is abnormal behaviour of observed phenomena (temperature), the Safety Server activates IPv6-enabled as well as legacy alarms (generates virtual entity) in the vicinity of the meeting room. It also raises an alert in a Safety and Management Tool. The Safety and Management Tool contacts system operators through their mobile phones and the associated Safety and Maintenance App and informs them about the exact location and type of alarm. The Meeting Reservation Tool generates a virtual entity such as the meeting is going to start in the next 15 minutes, and the local Control and Monitoring System (CMS) of the Smart meeting room is contacted in order to activate HVAC devices ensuring a conditioned environment at the start of the meeting.

IoT Context View

Figure 26: Notification service

Page 54: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

54

Actors Involved (and Role played): • User: User who receives notifications via a push mechanism and SMS. • Information: A virtual entity as a passive digital artefact, which is a digital

representation of the physical entities. • Virtual entity: A virtual representation of a real event. A passive digital artefact

which is a digital representation of the physical entities. This could be a notification about sensor failure or a farewell message.

• Data modelling processor: A resource in charge of managing the virtual entities’ subscriptions that are saved in Global Storage.

• Global Storage: A resource that contains global information about many physical entities.

Service Requirements: • Publish/subscribe mechanism • SMS gateway

Service Features:

• Notifying tool for sending notifications to users using different channels (push notification, SMS)

• Subscription tool that manages user subscriptions including different channel subscriptions (push notifications, SMS) and a logic for automatic notifications (for registered users that needs to be to notified by default).

• Profile creation and management tool supporting virtual identities. • Secured access (with different levels of security available) to all information:

general purpose, sensor collected or personal.

7.2.3 Data update (handling) This service allows users and the system to update data related to devices, sensors and users, and performs update of these data. The physical entities within this service are failure devices, alarm about abnormal behavior of observed phenomena and list of users that attend the meeting. This information is virtual entities saved in corresponding entities. This service encompasses a set of Use Cases that provides the users/system with capabilities to update and retrieve appropriate data. For example, after receiving information about the exact location and type of alarm, system operator goes to the location and after arrival at the source of the alarm detects a false alarm was raised: the real problem is a malfunctioning temperature sensor. Through the Safety and Maintenance App, the operator acknowledges the alert to the Safety and Management Tool so that the invoked alarm devices are switched off again (update of virtual entity in local CMS). The system operator identifies that the device has failed and orders a new device at mobile client. Mobile device sends the order request to Safety and Management Tool (SaaS). Safety and Management Tool sends order to Smart Things Information Service (STIS) in the cloud. The EPC code of the new device is stored in the Safety and Management Tool. The Safety and Management Tool uses the Smart Things Information Service to keep track of the delivery state of the device. The device

Page 55: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

55

arrives and the system operator installs the device and closes the ticket in the Safety and Management Tool (system operator manually updates the virtual entity in Safety Server). Finally, there is the case when an employee plans a meeting using a Meeting Reservation Tool. The Meeting Reservation Tool further configures access to the meeting room and makes the list of attendees (virtual entities). For all attendees, the Meeting Reservation Tool therefore, keeps a list of RFID tag values enabled for door access and belonging to a corresponding badge which is provided to meeting attendees at arrival time at the office entrance.

IoT Context View

CMS

GLOBAL STORAGE

Safety and Maintenance Appl.

Safet and management application

Data update

SafetyServer

Entities Directory

Meeting reservation tool

Figure 27: Data update (handling) service

Actors Involved (and Role played):

• User: User who performs update of sensors data or users whose presence has to be detected by the system. System operator.

• Information: A virtual entity as a passive digital artefact, which is a digital representation of the physical entities.

• Virtual entity: A virtual representation of a real event. A passive digital artefact which is a digital representation of the physical entities. Could be a data about sensor failure or information about the presence of the user.

• Devices: Sensors, and smartphone. • Local Control and Management System (CMS): A resource that handles the

execution of scenes in form of rules. These rules may be used to perceive the environment and its status and make the system act accordingly.

• Safety and Maintenance App: A resource that runs on a mobile device which is used to receive alert messages and for building maintenance. It can receive alarm notifications to inform a system engineer about an alarm condition.

• Safety and Management Tool (SaaS): A resource responsible for distributing emergency messages. It therefore accepts incoming alarm messages and sends SMS messages to mobile devices.

Page 56: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

56

• Smart Things Information Service (STIS): A resource that provides a database that keeps information about RFID tags and associated devices. As such it allows the querying of EPC codes and retrieval of information associated with a device corresponding to a particular code. Further, it allows to receive and process orders for devices. A query interface also makes querying for the current state of a device order possible.

• Local Control and Management System (CMS): A resource that handles the execution of scenes in the form of rules. These rules may be used to perceive the environment and its status and make the system act accordingly.

• Global Storage: A resource that contains global information about physical entities.

• Entity directory: Resource that contains global information about physical entities, services and other resources.

Service Requirements: • Entities directory • Reliable storage • Support for sharing data user/device policies definition • Secure communication between the user and the platform (AAA) • Identification and authentication mechanisms must be provided • Profile and virtual identity management must be supported. • Identification and authentication mechanisms for involved actors must be

provided • Depending on access control policies, access requests will be evaluated

Service Features:

• Data handling • Profile creation and management tool supporting virtual identities • Secured access (with different levels of security available) to all information • Safety management application and tool • Maintenance application and tool • Meeting reservation tool

7.2.4 Alarm generation This service allows alarm generation and handling in the IoT6 architecture. After the generation of alarm, propagation to different alarm systems is provided. The physical entities within this service are abnormal behavior of some parameter measured by sensors, like temperature. This information measured by sensor is recorded and transmitted as a virtual entity, i.e. alarm that report critical values. An Intelligent Temperature Sensor reads the temperature and performs a tagging of non-critical and critical temperatures according to a predefined threshold. The Intelligent Temperature Sensor reads a noncritical temperature then generates a tagged “normal” message which is sent to a Smart Router that forwards the noncritical temperature to a Local CMS for temperature trending.

Page 57: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

57

The Intelligent Temperature Sensor in the meeting room reads a critical temperature (overheating). It detects the high temperature which is out of safety bounds and generates a tagged “alert” message. This message is sent to a Smart Router which applies routing tables and forwards the alarm message to a Safety Server.

The Safety Server informs a Local CMS about the alarm situation. All the devices in the meeting room are grouped using an IPv6 multicast address for the according oBIX data points. The Safety Server therefore, performs a global switch off by sending CoAP PUT messages to this multicast address with simple payloads (e.g., <bool val=”false”/>). This way, all devices in the multicast group can be turned off. The Safety Server activates IPv6-enabled as well as legacy alarms in the vicinity of the meeting room. It also raises an alert in a Safety and Management Tool (SaaS).The Safety and Management Tool contacts system operators through their mobile phones and the associated Safety and Maintenance App and informs them about the exact location and type of alarm. IoT Context View

Safetyserver

Alarm alerts

CMS

Alarm Generation

Safety and mangement tool

……

..

……

..

Inteligent Temperature

sensor

Safety and mainetnance application

Regular measurements

Figure 28: Alarm generation service

Actors Involved (and Role played): • Administrator: a system administrator with permission to register the profile

and permissions for users. System management. • Registered Users: A physical person who is responsible for handling a

specific alarm. • Physical Entities: Phenomena which are observed in the system, and

temperature. • Information: Virtual entity as a passive digital artefact, which is the digital

representation of the physical entities, an alarm about abnormal temperature value.

• Safety Server (CMS): A resource that represent a distinctive form of CMS which is responsible for handling emergency situations. As such, this CMS includes rules that raise alarms in a particular part of the building in case a critical situation arises.

Page 58: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

58

• Local Control and Management System (CMS): A resource that handles the execution of scenes in the form of rules. These rules may be used to perceive the environment and its status and make the system act accordingly.

• Safety and Maintenance App: A resource that runs on a mobile device which is used to receive alert messages and for building maintenance. It can receive alarm notifications to inform a system engineer about an alarm condition.

• Safety and Management Tool (SaaS): A resource responsible for distributing emergency messages. It therefore accepts incoming alarm messages and sends SMS messages to mobile devices.

• Devices: Sensor and mobile phone. • Notification: Subscribed users (staff members) should receive notifications

(alarms) about an abnormal temperature. Service Requirements:

• Reliable storage • Support for sharing data user/device policies definition • Secure communication between the user and the platform (AAA) • Profile and virtual identity management must be supported • Identification and authentication mechanisms for involved actors must be

provided • Depending on access control policies, access requests will be evaluated

Service Features:

• Alarm generation • Safety management application and tool • Profile creation and management tool supporting virtual identities • Secured access (with different levels of security available) to all information

7.2.5 Discovery This service allows physical entities (nearby sensors and actuators) to be discovered using Building Automation Services App installed at a mobile device (e.g., a tablet or smart phone) and saved as virtual entity in the application. Building Automation Services App uses the Global Resource Directory system to identify nearby sensors and actuators. After that Building Automation Service App (mobile client) communicate with appropriate discovered devices (legacy HVAC devices and actuator) via multi-protocol IoT6 Gateway and performs environmental control.

Page 59: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

59

IoT Context View

GRD

Employee Building Automation Services App

IoT6 Gateway

Sensors&Actuators

Figure 29: Discovery service

Actors Involved (and Role played):

• Administrator: A system administrator with permission to register the profile and permissions for users. System management.

• Users: A physical person, employee • Physical Entities: Phenomena which are observed in the system, presence

of the nearby sensors or actuators • Information: Virtual entity as a passive digital artefact, which is the digital

representation of the physical entities, information about the presence of the person.

• Global Resource Directory (GRD): A resource at which devices of the IoT6 are registered and which can be used to search and discover devices based on certain criteria. It can be used to locate services available within a particular area.

• Devices: Sensors, actuators, smart phones, and tablets.

Service Requirements: • Global resource directory • Reliable storage • Profile and virtual identity management must be supported • Identification and authentication mechanisms for involved actors must be

provided

Service Features: • Discovering sensors and actuators • Profile creation and management tool supporting virtual identities

Page 60: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

60

• Secured access (with different levels of security available) to all information • Building Automation Services Application • Initiation of actions (sensors and actuators)

7.2.6 Failure detection This service presents detection of the failure within a Building Automation System, where spurious behaviour of an automation component is observed. Physical entity represents failure device (temperature sensor) which is transformed to virtual entity with the description about failure and ordering a new device (Safety and Management Tool).

After receiving information about the exact location and type of alarm, system operator goes to the location and after arrival at the source of the alarm he detects a false alarm was raised: the real problem is a malfunctioning temperature sensor. The operator opens the control enclosure and scans the EPC code attached on the temperature sensor device (e.g. KNX) using an RFID reader integrated in the mobile device. Mobile device sends RFID tag request to Safety and Management Tool. The Safety and Management Tool uses the EPC code to find out the responsible Smart Things Information Service (STIS) and queries Global Resource Directory for the product data sheet.

The product data sheet is displayed. The system operator identifies that the device has failed and orders a new device at mobile client. IoT Context View

STIS

Failed temperature sensor

RFID tag request

Safety and management tool

Scaning EtC code

GRD

Failure notification and ordering of new device

troduct datasheet query

System operator

Figure 30: Failure Detection service

Actors Involved (and Role played):

• Information: A virtual entity as a passive digital artefact, which is a digital representation of the physical entities.

Page 61: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

61

• Virtual entity: A virtual representation of a real event. A passive digital artefact which is a digital representation of the physical entities, data about sensor failure.

• Devices: Sensors. • Safety and Management Tool (SaaS): A resource responsible for distributing

emergency messages. It therefore accepts incoming alarm messages and sends SMS messages to mobile devices

• Smart Things Information Service (STIS): A resource that provides a database that keeps information about RFID tags and associated devices. As such it allows the querying of EPC codes and retrieval of information associated with a device corresponding to a particular code.

• Global Resource Directory (GRD): A resource at which devices of the IoT6 are registered and which can be used to search and discover devices based on certain criteria.

Service Requirements: • Reliable storage • Entities directory • Profile and virtual identity management must be supported. • Identification and authentication mechanisms for involved actors must be

provided

Service Features: • Failure detection • Maintenance tool notification • Secured access (with different levels of security available) to all information

7.3 Security Use Case A further extension of parts of the scenario of Section 7.2 has been analysed and is presented in the final report D8.6 “Final IoT6 Project Report”. In this Use Case, we extend the security aspects of some of the steps in Section 7.2 Security and Authentication tokens for devices like a door, temperature sensor, presence sensor and HVAC are stored securely in a Handle store. When a person with an RFID card wishes to enter a room, the credentials and authentication token of the door sensor are sent securely to an application. The application then accesses the Handle store securely, and ascertains the access rights of the owner of the card – and the network address of the door associated with that RFID reader. If the applicant is authorized, then the application sends a secured command to the door to allow it to be opened. When someone has entered the room, a presence sensor records the fact, and securely informs the application. The application instructs securely the lights to be switched on and the HVAC set to a particular temperature. The temperature is monitored by the application; if it deviates, the HVAC is adjusted securely. When the presence sensor detects no one is present, all systems are shut down. It is fairly clear how this Use Case is mapped onto the functional, network and security architecture. From the functional viewpoint, the application responds to requests, checks authentication, checks authorization, and actuates the relevant

Page 62: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

62

device. From the network viewpoint, the application will not store addresses a priori; When requests from the door sensor is received, then a match with the relevant identifier allows network addresses to be recovered from the repository. All communication uses REST, DTLS and CoAP – thus satisfying both the communications and security view. From the security view, the application accesses the Handle store with authorization and authentication. Authentication and authorization tokens are obtained from the Handle store by the application – after it has been so authorized. The application uses these various tokens to ensure that the authorization and authentication are done strongly. The devices are sensed and actuated with much simpler mechanisms because of their more constrained power. Of course the various authorisations, security tokens and authentication mechanisms must be set up in one or more set-up phases. Here all three views are again involved in different roles which permit the creation of entries into the different databases, the creation of metadata on their access, and the insertion of tokens into the constrained devices. Ideally we would have combined this Use Case with that of Section 7.2. Unfortunately, as explained earlier, the late arrival of the infrastructure from outside resources and the lack of available effort have made this impractical. The demonstration of this Use Case is therefore an independent one as described in D8.6 “Final IoT6 Project Report”.

Page 63: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

63

8 Addressing Recommendation 3 In this section, the reviewer comments from the 2nd year Review Report, regarding Recommendation 3 (Technical Review Report) are addressed. Here, deeper look and analysis of the IoT non-functional architecture properties are given. Properties of diversity, scalability, manageability, global security, and governance are analysed in more details.

8.1 Scalability: Inputs from WP7 and Handle The IoT6 project proposes technologies and applications addressing some problems which arise in the transition from the current Internet to the emerging “Internet of Things”. The tremendous growth of the Internet is owed not only to rapid advances in underlying hardware technology, but also - and crucially - to the fact that it turned out to be accepted and embraced by the general public to a much larger extent than could be expected. In particular, the latter aspect was not generally foreseen when the current architecture of the Internet was designed. This is the root cause for most of the scalability problems that are now being addressed in recent architectural changes and extensions. Among those problems, two key ones are an increase in size, i.e., node count, as well as an increase in diversity. Diversity in this case refers to the ability to connect devices with a wide range of hardware capabilities to the Internet, from powerful PC workstations down to individual binary sensors or actuators. The increase in network size is a critical issue due to the fact that it compounds the basic problems of addressing and routing. However, since IPv4 addressing has been stretched beyond its original limits for quite some time now, there already is an established solution to this problem, namely the IPv6 addressing scheme. While it remains to be seen whether the Internet of Things might possibly outgrow even the IPv6 address space in the foreseeable future, it was clear from the start that IoT6 would be based entirely on IPv6. It therefore, inherits an IPv6 networks scaling capacity, which can reasonably be deemed sufficient for IoT6 at this point; its potential bottlenecks are well beyond the scope of the IoT6 project. With respect to diversity, the trend has been for some years now to connect ever smaller and less powerful devices to the Internet, allowing access and configuration through the ubiquitous cloud interface. The technical challenge here is that a full IPv6-enabled stack requires a good amount of hardware resources, which many of these devices cannot reasonably provide – particularly if battery power and long life are additional constraints. In the IoT6 framework, this problem is addressed by the use of legacy device gateways, which provide the necessary translation mechanisms to make simple legacy devices appear fully IPv6 enabled. An advanced resource discovery mechanism, the Digcovery service, provides for highly efficient locating of services and/or devices based on complex queries. As the gateways and the Digcovery service as well as the STIS are IoT6-specific additions to an IPv6-based network, their scalability needed to be examined. This was handled in Deliverable D7.2 “Components Instantiations and Validation Report”. We shall now briefly review the results of this analysis.

Page 64: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

64

The Digcovery service was found to scale well due to its hierarchical design, which is very similar to the current DNS service; it can therefore, be expected to be equally robust and scalable. The gateways, on the other hand, have to deal with legacy protocols that were not designed for scalability. Due to some complex processing required in translating between the different protocols, gateways cannot handle too many concurrent requests. However, connectivity requirements for such device gateways will be limited by design, as they will generally have to be located near the devices they control in order to keep the wiring manageable. To implement local networks covering a wider area, UDG devices can be deployed as higher level “meta” gateways connecting multiple slave gateways. Scalability is thus a by-product of the hierarchical design of a control and monitoring network. In the following, we will provide a more detailed summary of the scalability issues that were investigated in Deliverable D7.2. One definition of scalability can be found in the relation between the increases of the response time according to the impact of increase load. A system is said to be scalable, if the observed response time is in linear relationship to the increased load. Figure 31 illustrates the scalability properties of two systems by an example. Whereas system A shows an exponential increase in the measured response time according to increased system load, the response time of system B increases in a linear way.

Figure 31 Scalability of systems [62]

In general, high performance of a (sub) system in small scale networks is not a sufficient requirement for scalability. However, for IoT6 gateways, which for the scalability analysis are quite naturally abstracted by using a queuing model, the performance in processing individual requests becomes a key factor. Through performance and fast processing of requests, the queuing of requests can be avoided. Further, through optimized message payloads congestion taking place in networks can be shifted to higher system loads. So optimizing and increasing the throughput of a system is an important factor. By doing so and by adding additional computational resources to a server, vertical scalability can be provided until the server cannot be upgraded any more due to system limits. When vertical scalability reaches its limits, it is required to provide horizontal scalability which relies on two main design principles which are a hierarchical system architecture and a decentralization of system components.

Page 65: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

65

Decentralization or distribution involves the use of several server instances providing a similar service, but comes with the problem synchronizing state between these servers and providing consistency throughout the whole system. Further, it is desirable to provide both availability, which means that every request can be successfully processed, and fault-tolerance in the case of failure of a system component or network communication link (partition-tolerance). As stated in the CAP theorem, it is not possible to provide all three properties for distributed Web services [63]. The components of the IoT6 service-oriented architecture are highly distributed and decentralized in order to provide scalability. The design paradigm of decentralization is applied on many different functionalities of the IoT6 architecture. The discovery services are following the hierarchical system architecture of the domain name system, which is due to its success in the Internet proven to be scalable. Discovery requests are passed to decentralized servers responsible for sub-areas of the name space. For centralized services such as a discovery mechanism based on a global index of provided services, distributed database technologies such as NoSQL databases can be used in order to provide scalability [64]. The principle of system decentralization is also applied for the control and monitoring system. The execution of control logic and rules is put on local gateway components or on devices. In this way, no central bottleneck in the system architecture exists. Further, the IoT6 gateway presented in deliverable D4.2 “Multi-protocol Architecture and System development report” and the IoT6 system stack can rely on decentralization of control logic using a group communication mechanism. Thus, it is possible to keep communication between devices local, relying on a peer-to-peer interaction mechanism. Since no central controller is involved, the scalability can be significantly increased [65]. Some services might require a centralized hosting of components. In this case, cloud-computing offers a technology stack that provides just-in time [66] and high scalability of central components [67]. The scalability of the IoT6 architecture is assessed in WP7. Deliverable D7.1 “Test process specified” will state the scalability testing methodology and within D7.2 “Components Instantiations and Validation Report” results on the scalability are presented. Beside the previous definition of scalability, there are many meanings to this concept. These include accommodating large numbers of the following:

• Identifiers, numbers of devices and processes • Types of processes, devices and gateways • Addressing all the above • Storing their properties

In addition, the network topology must allow large numbers of devices to be accessed, monitored and controlled. Finally, there should be a global reach – even if most of the application domains are more local. Some of these aims can be simulated or shown experimentally. Others can only be shown qualitatively. The mere fact that IoT actually embraces almost all aspects of human endeavor shows the impossibility of the experimental proof. Moreover, the numbers talked about in IoT are billions and trillions of devices; clearly any form of experimental demonstration of such scalability is probably impossible, and certainly cannot be attempted in a STREP. Nevertheless, we can start to answer some of the questions raised.

Page 66: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

66

If we take systems like Handle, there is literally no limit to the numbers of devices, etc., that can be accommodated. The structure of the identifiers, being a free format, has no limit. Since its attributes are an arbitrary set of type/value pairs, there is no theoretical limit to the number of types of processes, devices and gateways that can be covered – provided only that it is possible to describe them as digital objects. Because IoT6 is predicated on the use of IPv6, the number of objects that can be addressed is very large. Theoretically, one could route globally to a million, trillion addresses, with the same number of objects at each global address. We do not know, of course, where our current routing strategies would break down; however this is the subject of the Future Internet programme rather than this STREP. The architecture of systems like the Domain Name Service has shown already that they can be stretched to billions of globally routed entities. The architecture achieves this aim by breaking an address down into global and more local pieces. The Handle System is built on the same lines, and currently shows no sign of being limited with 65M identifiers. Its servers are so designed that if a particular server is becoming slow and having too many entries, the entries can be distributed over several servers instead. In practice, uses of systems like Handle will reflect a hierarchic distribution. With IPv4, this was mainly geographic. With the richness of the IPv6 and current Identifier spaces, there can be multiple hierarchies and almost arbitrary divisions. It is vital, however, for the architecture to allow multiple identifier routes to lead to the same physical object. This is certainly permissible in both IPv6 and Handle addressing. Both also adopt a philosophy where there is a global part of the identifier to allow global routing, and then delegation of all the management to a subsidiary. Eventually this technique will lead to intolerable delays, but there is no sign yet when this might occur.

8.2 Diversity integration: Inputs from WP4 and WP6 IoT6 project has been driven by IPv6 protocol and technologies around it. The first role of IPv6 itself as a network layer protocol is to provide a common communication environment where all the different communication medium technologies are abstracted, and consequently diversity integrated reached at the network layer (i.e., all the devices are able to speak a common protocol, IPv6). This diversity integration into a common network layer is not enough even in the current Internet of Things. The market is composed already not only of a wide range of communication technologies, but also a wide range of enablers to extend the Internet of Things beyond the Internet itself. For this purpose, IoT6 has provided and demonstrated the diversity integration in two different dimensions: On the one hand, diversity of communication technologies and devices integrated through protocols such as GLoWBAL IPv6, IPv6 Addressing Proxy / IPv6 Mapping to non-IP protocols, 6LoWPAN, and through middleware solutions and platforms such as UDG and IoTSyS. On the other hand, diversity of enablers and components that complement the Internet of Things architecture, in terms of Cloud Computing-enabled enablers, Management enablers, Publish / Subscribe Context Brokers, and third party systems,

Page 67: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

67

among others.

8.2.1 Diversity integration of Everything into a common IPv6-enabled layer.

The Internet of Things requires a common and transparent access through IPv6. IPv6 offers stable, scalable, extensive, and tested protocols for node and service discovery, mobility, security, and auto-configuration such as presented during the IoT6 project and in the rest of the sections of this Deliverable, In order to support the diversity presented by the Internet of Things devices into the Internet, IoT6 has adapted, extended, bridged, and mapped existing and legacy technologies from areas such as building and industrial automation to IPv6. Figure 32 presents the different available techniques (IPv6 and 6LoWPAN), which are being developed and supported by members of the IoT6 Consortium and the Advisory Board, and also the new proposed technologies by IoT6 such as GLoWBAL IPv6 and IPv6 addressing mapping for non-IP protocols (so-called IPv6 Addressing Proxy) and Handle. Thereby, IoT6 is providing mechanisms to enable IPv6 addressing to everything. Regarding the solutions proposed by IoT6, on the one hand, GLoWBAL IPv6 offers an optimized version of 6LoWPAN for constrained technologies that needs adaptation in the application layer. On the other hand, IPv6 addressing mapping offers a set of adaptation layers from non-IP towards the IPv6-based network layer in order to enable homogeneous access. This mapping is totally compatible with legacy devices and proprietary solutions that cannot offer a modification of their communication stack. Thereby, this proxy solution provides the mapping for legacy addressing spaces to IPv6. Remark that this solution is being standardized in the IETF 6Lo Working Group, and being considered as candidate for Working Group documents. We expect it will be finally accepted as standard during Q1 2015 [59].

Page 68: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

68

Figure 32: Classification of the presented solutions in function of the communication

layer upgraded

8.2.2 Diversity integration of Services, Enablers and Third Party Systems.

The Internet of Things ecosystem is not composed only of devices. It is a well-known trend of the Internet of Things to be interoperable with Cloud Computing-enabled services, with third party systems, and finally with any other enabler that complement and extend the potential of these emerging technologies to address the problems in a more efficient and suitable way. For this purpose, WP4 and WP6 demonstrated the interoperability of the proposed IoT6 with multiple systems from partners developed systems such as the Fujitsu RunMyProcess platform for Cloud Computing Services in the area of Business Process Management, the STIS system as an third party system integration for the management of RFID tags based on EPCIS standards, and also other third party integrations. Especially, regarding KAIST STIS, an innovative interaction between Smart Things Information System (STIS) using Smart Thing ID and IPv6 was shown and described. This interaction employed 6LoWPAN as a means to convey smart thing’s data like STID and sensory data. Smart things are connected to 6LoWPAN gateway, and their data is adapted to LLRP message by virtual LLRP reader. Then, it is integrated to STIS in the same way as usual RFID readers. In this way, smart things with STID can benefit from IPv6 and interact with STIS while maintaining advantages of 6LoWPAN

•Suitable when the Communication Stack is non programmable, but the application layer packets (data units) are editables.

•Application Layer solution to identify end-to-end Itv6 connections.

•Suitable when the Communication and application layers are non programmable/editable.

•troxy solution for mapping legacy addressing spaces to Itv6. This solution is independent of the communication stack, this does not require modify the stack in the end device.

•Suitable when the communication stack is programmable over constrained MAC layers

•Adaptation Layer solution to adapt constrained MAC layers to Itv6 layer.

•Suitable when the communication stack is programmable .ver non-constrained mediums (MAC layers).

•Default solution . •Lightweight implementations

of Itv6 (lwItv6 and uItv6). IPv6

lwIPv6 /uIPv6 (Network

Layer)

6LoWPAN (Adaptation

Layer)

GLoWBAL IPv6 (Application

Layer)

IPv6 Addressing Mapping

(Communication Stack

independent)

Page 69: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

69

such as low-power communication. Regarding the third party integrations, IoT6 has made echo of the biggest action in Europe in terms of enablers for developing the Future Internet, i.e., FIRE / FI-PPP and in particular some of the results from projects such as FI-WARE and its Generic Enablers. In details, IoT6 has integrated through FI-LAB (Cloud Computing-enabled Enablers) the Orion Context Broker Generic Enablers developed by Telefonica. Orion provides value for the Internet of Things through a Publish/ Subscribe broker. Remark that IoT6 Stack considers CoAP as one of the key protocols over IPv6 to enable the so-called Web of Things and provide interoperability among different components. Orion Context Broker also offers CoAP as a key technology, making it totally compatible with IoT6, such as demonstrated in the WP6. The Orion Context Broker was also designed considering the support for the diversity, through the exchange of information/data among heterogeneous entities scattered in a distributed environment, and it was also adapted recently to support CoAP, since the Internet of Things is one of the pillars for the Future Internet. Finally, in addition to the Orion Context Broker GE from FI-WARE, KAIST STIS system, and Fujitsu RunMyProcess Cloud Services for Business Process Management, IoT6 project has developed the integration with new emerging devices such as Google Glass and Philips Hub. Therefore, WP4 and WP6 have demonstrated that IoT6 stack and mechanisms are not only ready to integrate IoT6 partners’ solutions, but also Generic Enablers such as Orion from FI-WARE, and commercial solutions such as Google Glass and Philips Hub.

8.3 Manageability: Inputs related to DigCovery and WP5 The Digcovery system allows the scalable management of the IoT components and resources deployed in the IoT6 project. To manage the IoT resources, the digcovery system provides a scalable architecture based on a global digcovery core and many local digrectories. First, each digrectory is a resource repository deployed as a middleware distributed in routers or gateways in order to manage all services and resources in a local IoT network. Second, the digcovery is a central service system located in a cloud platform providing easily accessible and well-known access point to manage the look-up operations for any IoT resources registered in the system. So, the central digcovery platform offers a full vision of all available resources in the distributed local digrectories. The digcovery architecture provides resource management capabilities and resource directory at local and global levels. In particular, the digcovery system registers the types, domains, properties and locations of the IoT6 services and resources. Each digrectory saves information detailed about the services and resources of IoT devices in the local domain. The digcovery system stores information simplified about types of services available in the digrectories. The information changes of IoT components are automatically updated in the digcovery system at local and global levels. For instance, if a mobile device changes its location, this device indicates the new position to the local resources digrectory; this propagates the update to the global digcovery core. The global digcovery and local digrectories enable the easy management of dynamic services and resources provided by heterogeneous and ubiquitous IoT devices (for implementation details, see D3.1 “Look up and discovery, context-awareness and resource” [31]).

Page 70: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

70

8.4 Global security: Inputs from WP2 and Handle It is difficult to define a concept such as global security, though one can define aspects of security for devices that are globally accessible. In D2.2 “Distributed IPv6-based Security, Privacy, Authentication and QoS” [57] we defined the fundamental forms of security that could or should be invoked. The principal ones are the following:

• Confidentiality • Integrity • Authentication • Authorisation • Privacy • Non-repudiation • Audit Trails

This is not the place to repeat the definitions given earlier of these concepts. There are a few techniques that are fundamental to their implementation. These include symmetric and asymmetric cryptography, message digests, unique identifiers and key distribution. This project is not, fundamentally, a security project – though security services are vital to the acceptance of IoT. Thus we have used, wherever feasible, existing implementations of security procedures, implementations and libraries. One requires a complete infrastructure for achieving real security, and this was not universally available during the main part of the project. Only the strand represented in D2.4 [58] and parts of D5.4 could use such an infrastructure. To the extent that we are working with distributed processes, and using the Datagram communication between processes, DTLS is the protocol of choice for reliable and secure transmission of data packets. Both the Linux and Contiki operating systems had versions of that protocol implemented; we ensured that compatible versions of the protocol worked with the RESTful ‘transport’ protocol CoAP. This was described in D2.2 “Implementation and Testing Report on IPv6-based IoT6 features” and D5.4 “Intelligence Distribution Tests and Evaluation Report”. Though it is not used in the main Use Cases, a subsidiary one was is described in Section 7.3 and D5.4 Section 6. In the reduced functionality of constrained devices like sensors, it was practical only to use symmetric encryption in the DTLS; this would make non-repudiation more difficult to prove. We did use the real Handle system in parts of the project. This allows each attribute of an identifier to require authorization to be created, accessed or edited. By making extensive use of Handle, we showed how to achieve a measure of secured operation in all phases of a specific Use Case. Fundamental to the operations was the notion of an Authentication Token (AT) and a Security Token (ST). Any data provided by a device or process had to have a unique AT appended securely. Any operation on a device or process had to have an ST appended securely to ensure that the operation was authorized. There are many ways that the ATs and STs could be created, distributed and verified. In our approach, Handle was used heavily in this process. We used the Handle property that any attribute could be stored securely in Handle, and could only be

Page 71: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

71

retrieved by authorized processes. We used the public/private key pair infrastructure implemented by Handle to achieve the fine-grained security required in our Use Case; there would be similar needs in most IoT deployments. The principal of the use of asymmetric encryption for this is that a message processed with the private key of the entity desiring access is sent to Handle; this is processed with the entities’ public key. If they match, authentication is achieved. To ensure a secure operation, a message encrypted with the public key of the target is sent; only the target entity can decrypt this with his or her private key. Our Use Case was an application in Buildings Management. We defined the role of a Buildings Supervisor. The Supervisor was authorised to set up all the properties of a building – presumably from some model of the devices in the building. During a set-up phase he or she set up all the needed identifiers in Handle. The Supervisor was not authorized to set up any security attributes, or to set up the access conditions for each attribute. During another phase of the set-up, a Security Administrator set up all the security attributes (e.g. ATs and STs), the lists of people (and their ATs) authorized to perform various functions, and the authentication tokens required for each access to the attributes. In the operational phase, an application is programmed to perform both sensing and actuation activities. In a sensing activity, the sensing data includes the AT of the sensor; using the AT stored in Handle, the authenticity of the data can be established. In order to perform an actuation, the application must first retrieve the ST to the operational request; the target compares the ST to its stored value, and assumes authorization if they match. In practice, one also makes extensive use of the caching properties of the Handle protocol. If an AT or ST has been retrieved from Handle, it can be cached in the application for subsequent re-use. Of course, all the messages implied in the above transactions are sent with DTLS.

8.5 Governance The subject of governance in IoT is a major area of concern, and has been the object of a whole working group in IOTA and in the IERC. While we have considered it to some extent in the IoT6 project, the areas that we have discussed are very specific ones of direct concern to the work we have undertaken in the project. We have not really considered with the general problem. We treat here the problems of governance in the following particulars:

• Governance of IP-space • Governance of Name Space • Governance of Multi-application gateways • Governance of Security Functions • Management of Security

While we intend that our approach here would be more generally applicable, we do not advocate it as the only or even the best approach to the different problems raised. Indeed, the application domains of IoT are so diverse, that a single universal approach is very unlikely.

Page 72: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

72

8.5.1 Governance of IP Space There is huge international concern on all aspects of the Internet. Indeed, the Internet Governance Forum [75] meets frequently in large international gatherings just to consider this subject. One part of it is the management of IP-space. This used to be managed centrally from the US, but for the last twenty years this has become internationalised. There is a central Internet Registry IANA [73] that allocates large blocks of addresses to a number of regional registries e.g. RIPE [78] for Europe. This system has worked well for IPv4, and is now adopted for IPv6. We are not advocating any change to this system from the IoT6 project. However, some of our activities could threaten this system if carried further than our approach. With IoT, there are complex physical subsystems being managed. With the large address space of IPv6, 128 bits, it is tempting to reflect the structure of the parts of the IoT world in the use of IPv6 addresses. Because of the large number of devices, and the diversity of applications, it would be tempting to propose using a large part of the address space for application-specific purposes. It is immediately clear that any such usage should be limited to the lower 64 bits – as is used in WP2 and WP3 of IoT6. The reason for this is that the IETF [74], who mandate Internet protocols, has determined that the top 64 bits be used for Internet Routing, and be allocated under the IANA – Regional Registries framework, while the remaining 64 bits be reserved for local use. Thus any attempt to use any of the top 64 bits would immediately challenge the supremacy of that framework – for no useful purpose. The use of the lower 64 bits to represent structure is more defensible, but may still be considered problematic. It is tempting to define standards for the use of this part of the address space that are application-specific; indeed we have done this in IoT6 [68]. While convenient, it would raise the general question of having many more bodies concerned with the management of IP address space. We consider this a dangerous precedent which would cause endless squabbles in international fora, and may well interfere with the smooth running of the present system. We suggest that there would be nothing too problematic in application-specific organisations, e.g. the KNX forum [76] that a particular subset of the address space be used; indeed, this could not be prevented. However, even this modest proposal would be likely to raise conflicts between different such bodies. Moreover, IP addresses are often stored in the DNS system [69]. This system is open to outside inspection, thus the IP address might well reveal more information about the underlying physical system than is wise to make generally available. Moreover, there is an alternative mentioned below which would be superior and would avoid the above risks.

8.5.2 Governance of Name Space It is vital to achieve economic scaling to allow a systematic derivation of network addresses and subsystem properties from models of the physical system. Most systems we envisage, be they smart buildings, transportation systems, patient populations or smart cities, have such models – and therefore, a need to describe the properties of the physical objects. In the preceding section, we have mentioned the proposal to use IPv6 addresses in this context – and have deprecated it. An excellent alternative is to adopt a very flexible identifier system, and to associate attributes of the physical world algorithmically to such identifiers. Such a system can be much more flexible and open, if well-designed specifically for this purpose and can meet the IoT needs without the drawbacks of the use of IP space.

Page 73: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

73

Important aspects of such a system would be the following: • The system should be very extensible – conceptually able to extend to the

huge numbers of digital objects envisaged in IoT, with the variety of attributes being considered.

• Whereas all identified objects should be globally accessible if required, such access should be able to be completely cut off from the global system if that is desired.

• There should be the capability of providing access control to ensure that only authorised users can traverse the identifier space.

• There should be fine-grained access to the individual identifiers. • There should be subsets of the identifier space that could be completely

managed by arbitrary bodies. • It should be possible to manage the identifier system in a way that would be

acceptable to the potential stakeholders. • An identifier should be associated with an arbitrary number of attributes.

These can be used to specify its nature or how it can be treated. • It should be possible to embrace other identifier systems.

We do not pretend to have a unique solution to the needs of IoT in this regard. Indeed, it is a major subject of study in many august bodies including the ITU [79]. However, the approach adopted in D2.4 “Implementation and Testing Report on IPv6-based IoT6 features” [58] and parts of D5.4 “Intelligence Distribution Tests and Evaluation Report” [56] of using the Handle System [72] from CNRI seems to satisfy most of the above. We have discussed in detail in D5.4 how the system is organised, its characteristics, and why it would at least meet the above needs. A Handle consists of an arbitrary number of Type/Value attributes. Since the Type of the attributes can include authentication tokens, authorisation tokens and network addresses, it provides all the services that could be provided by the DNS – but in a more secure manner. There is even an international foundation [70] that governs the use of the system. Of course, any universal approach to this problem would scrutinize the properties of candidate systems much more rigorously, and put in much more elaborate safeguards, constraints, and governance of the system itself. Incidentally, a model of how this might work has been shown in Handle in its almost universal use in the media industry and ISBN system. Its practical use in IoT is being demonstrated in its Chinese use for the retail and food production chain. Here local governance, security and extensibility are key features. Handle has a provision for registering Types globally. This caters to two other types of governance. First, one can set up bodies to determine which types are of common enough usage that they should be registered globally. Second, it is possible to register types which embrace a whole other Identifier System. An example is to define the Type OID; this could allow the whole of the OID space [77] to be used to describe the nature of devices in Handle. In practice, this would not be straightforward or useful, because the OID system has a different security model and method of constructing its identifiers; this subject is currently being studied in the ITU. When we refer to Handle in the rest of this section it is to indicate only that a system such as Handle could be used, with the proviso that Handle already has the requisite features assumed. In D5.4 “Intelligence Distribution Tests and Evaluation Report”, and the final

Page 74: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

74

demonstration, we show how the system can be used in a generic fashion in a specific domain, The Buildings Management domain. We demonstrate a solution that implements a system which addresses the domain model, i.e. one could use it to implement other solutions for Buildings Management (as opposed to a system which addresses a specific Use Case of Management of X Buildings of Y organisation).

8.5.3 Governance of Multi-application Gateways At first sight, it would seem that the governance of gateways is a straight-forward task. Some entity owns a gateway, and can therefore be held completely responsible for its management. This is not quite the case. A major reason why IoT may become so prevalent is that the physical world will be increasingly populated with devices that can sense their environment and be made to actuate processes. Often the same devices may require access from different application domains, with their own ecosystem. For example, a smart building may contain a HVAC. The subsystem will need to be set, of course, by a Buildings Manager. However, it may also need to be accessed by a Maintenance Engineer with quite different access requirements – and incidentally normally different network address space. A door may need to have its capabilities managed by a Buildings Supervisor, its faults by a Maintenance Engineer, its access by a user with an RFID card, its local credentials by a Security manager and its opening in an emergency by the Municipal Fire Department. Some of these require quite different access to its properties, be authorised by different entities, and even different network addresses. In a smart city, a person sensor may be used by the traffic lights, police surveillance, bus traffic analysis and street lighting. The individual sensors, or a gateway controlling a collection of them, may require complex – and extensible – sensing and information authorisation facilities. Not only may these be beyond the capability of a smaller device, but also their management in multi-application environment could become very complex. For this reason, we envisage that use of a system like Handle could have a very important place. One property of IPv6 addresses is that it is possible, and natural, for an IPv6 device to have several such addresses. Thus each application domain could assign its own network address to the device – valid in the domain specific to its activity. By defining its own Handle, it could be assigned the network address and other attributes that matter to that application domain. If many application domains require similar attributes of the device, these could be put into another Handle – which is itself an attribute of each of the applications. Access to the gateway may require dual keys – ones specific to the owner of the gateway, and one specific to the owner of the application. There may well be further governance desired on specifying the attributes of certain classes of devices, certain classes of applications, and certain standards across applications. However, such agreements would only ease the implementation and deployment of the technologies, they are not prerequisites.

8.5.4 Security Functions We must distinguish between the management and the governance of security. In some cases the governance depends only on single domain, local, decisions. Many, or even most, of the current deployments have this property. However, there may well be Health and Safety or Public Interest considerations which modify this approach. For example, the sensors for car parking may be installed to police the billing of car owners; however their access for street lighting and police security may be statutory

Page 75: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

75

requirements. It could well be that for police security, a degree of camera movement is required, while for street lighting much less detail should be available. The Handle approach, with different Handles for the different domains, and several keys allowing access to different attributes, may be highly desirable. The governance may well require constraints on the attributes that are permitted in different application domains using the same sensors or gateways.

8.5.5 Management of Security Security management has many facets, most beyond the scope of IoT6 – let alone this Deliverable. When identification of sensors are required, it is desirable that each such sensor has an intrinsic token for identification. This might be the equivalent of a manufacturer-supplied MAC address or its unique address in some proprietary Building Automation Systems. The more difficult the token is to spoof, the more faith one can have in the system. For each operation possible on a digital device, there should be a security token that authorises the operation to be performed. It would be possible to have the device hold several security tokens with different privileges. This might require complex operations in remote devices. An alternative is to have the remote device have a single security token. However, each application may require its specific security, and would authenticate the validity of authorisation of an operation. If, and only if, the operation is indeed authorised would it be sent to the remote device with the specific security token required by the device. The use of a system like Handle would be very helpful in this process. Both the application-specific tokens and the device-specific ones can be stored as attributes in Handle, and used in the authorisation phase. Having different Handles associated with different applications on the same device, and with the same operations on different devices give powerful aids to security management. In some scenarios, the use of multicast IPv6 addresses even allow this approach to be used for secure group operations. Most mechanisms based on asymmetric encryption are more computer intensive than ones based on symmetric. Thus the authorisation and authentication mechanisms between an application and a remote device may use only symmetric techniques. To mitigate the damage caused by unauthorised penetration of Handle attribute store, the security attributes can be stored in an encrypted form, in which the Handle owner knows the symmetric key. The above are the sort of functionality demonstrated in the Use Case of Section 7.3. So far we have discussed management of applications and devices based on tokens. Another aspect of security is the management of the tokens themselves. In Handle, there are operations to create, delete, read and write Handles. These can require different authorisation. Normally each such operation requires strong authentication via a private/public key pair. There may be authorisations for dealing with Handles, and with each attribute of a Handle. Thus an application developer may or may not be authorised to put the security attributes into the Handle system; that may be reserved to a Security Administrator. An unauthorised person may not even be able to traverse the identifier space of Handle. Thus if the identifier space gives details of the architecture of a subsystem, these details could be hidden from unauthorised users. In the same way, the network manager may be authorised to put in the network address attributes from a model of the application. Here the purpose of the authorisation may be more to ensure that the translation is done correctly in view of the network characteristics. The fact that network attributes are associated with Handles may have nothing to do with who is authorised to access the Handle.

Page 76: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

76

Fundamental to all the above is that individuals are authorised by strong public/private key authorisation. This in its turn is predicated on a security infrastructure that is trusted to identify individuals and to furnish them with the appropriate public/private key pair, and to do the correct key renewal and revocation. These functions are fundamental to most of the current security environments. Their management and governance have not been considered in IoT6. Many IoT applications are carried out over radio networks which are notoriously insecure. For this reason in the D5.4 validation, all transactions between an application and a remote device are carried out using DTLS [71]. This is a datagram-based protocol standardised in the IETF for this class of transactions. Of course how strong the security of DTLS is depends on the encryption algorithms used – which may be not as strong as one would like if the devices are processing-challenged.

Page 77: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

77

9 Conclusions This deliverable has outlined the IoT6 architecture together with the analysis of the future Internet state-of-the-art IoT architectures. The approach adopted for the architecture model definition was to combine and re-use already existing initiatives in this area such as IoT-A and FI-WARE as there is a significant functional overlap between the architectures. However, the existing initiatives are focused on providing only a generic reference implementation and therefore, the proposed IoT6 architecture model aims at enhancing it and applying IPv6 related requirements within the IoT6 project. In this way, the reference architecture model was modified and new components were added so that IPv6-specific functionalities are leveraged not only at the protocol level, but also at the higher levels within the architecture model. For example, components responsible for providing functionality for discovery of resources and services are enhanced with IPv6 mechanisms based on DNS-SD and mDNS concepts. Furthermore, as IPv6-based devices are globally accessible, there is no need for them to be connected to the system via dedicated Gateways. Instead, they can be connected to the backend server and associated global discovery mechanisms within the core network.

Two new sections have been added and some earlier ones extended. In Section 7, the definition of the IoT scenario and its elements in the IoT Architecture Reference Model are given and the IoT6 selected Use Cases are presented according to the IoT Architecture Reference Model. Section 8 addresses the reviewers’ comments regarding the IoT non-functional architecture properties: properties of diversity, scalability, manageability, global security, and governance. The architecture described in this document represents an update of the initial IoT6 architecture, based on the outputs of other project work packages. It serves as the overall framework and guideline for implementation of a pilot IoT6 instantiation. As the project progresses and new results became available, the architecture was updated and this document represents final version released at the end of the project.

Page 78: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

78

10 References [1] IoT6 project, deliverable D1.1 - IoT6 use-case scenario and requirements

definition report [2] Internet of Things Architecture, IoT-A, http://www.iot-a.eu [3] Internet-of-Things Architecture, IoT-A, Project, deliverable D1.2 – Initial

Architectural Reference Model for IoT [4] Holistic Platform Design for Smart Buildings of the Future Internet, HOBNET,

STREP ICT-257466, FIRE, http://www.hobnet-project.eu/ [5] SENSEI (Integrating the Physical with the Digital World of the Network of the

Future), Pervasive and Trusted Network and Service Infrastructures: ICT-2007.1.1: The Network of the Future, Contract no. 215923, http://www.sensei-project.eu/

[6] ETSI M2M Communications, http://www.etsi.org/Website/technologies/m2m.aspx

[7] FI-WARE Internet of Things (IoT) Services Enablement, http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_Internet_of_Things_(IoT)_Services_Enablement

[8] ETSI TS 102 690, Machine-to-Machine communications (M2M), Functional architecture, http://www.etsi.org/deliver/etsi_ts/102600_102699/102690/01.01.01_60/ ts_102690v010101p.pdf

[9] OMA Next Generation Services Interface, http://www.openmobilealliance.org/ Technical/release_program/ngsi_v1_0.aspx

[10] Jara, A.J.; Martinez-Julia, P.; Skarmeta A.F.: “Light-weight multicast DNS and DNS-SD (lmDNS-SD): IPv6-based resource and service discovery for the Web of Things”, International Workshop on Extending Seamlessly to the Internet of Things, 2012.

[11] Shelby, Z.; Bormann, C.; “6LoWPAN: The Wireless Embedded Internet”, Wiley, ISBN: 978-0-470-74799-5, 2009.

[12] Colitti, W.; Steenhaut, K.; De Caro, N.; Buta, B.; Dobrota, V.; "REST Enabled Wireless Sensor Networks for Seamless Integration with Web Applications," Mobile Adhoc and Sensor Systems (MASS), IEEE 8th International Conference on, pp.867-872, 17-22 Oct. 2011.

[13] Jara, A. J.; Zamora, M.A.; Skarmeta, A.F..; “GLoWBAL IP: an adaptive and transparent IPv6 integration in the Internet of Things”, Mobile Information Systems, “accepted and in press”, 2012.

[14] OMA Service API Standardisation, http://www.ict-ccast.eu/workshops/2nd/13%20-%20OMA%20-%20Kovacs%20-%20OMA_ServiceAPI_Standardisation.pdf

[15] ETSI M2M standard - http://www.etsi.org/Website/technologies/m2m.aspx [16] ETSI M2M Functional Architecture – http://www.etsi.org/deliver/

etsi_ts/102600_102699/102690/01.01.01_60/ts_102690v010101p.pdf

Page 79: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

79

[17] DNS Service Discovery (DNS-SD), http://www.dns-sd.org/ [18] Multicast DNS, http://www.multicastdns.org/ [19] Constrained Application Protocol (CoAP), draft-ietf-core-coap-11,

https://datatracker.ietf.org/doc/draft-ietf-core-coap/, 2012-07-16 [20] Constrained RESTful Environments, http://tools.ietf.org/wg/core [21] FI-WARE Data/Context Management, http://forge.fi-

ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_Data/Context_Management

[22] Sensor Markup Language (SenML) Specification, http://tools.ietf.org/html/draft-jennings-senml-08

[23] Efficient XML Interchange (EXI) Format 1.0, W3C Recommendation 10 March 201, http://www.w3.org/TR/exi/

[24] Constrained RESTful Environments (CoRE) Link Format, http://www.ietf.org/rfc/rfc6690.txt

[25] Semantics for the Internet of Things: early progress and back to the future, Payam Barnaghi and Wei Wang, Centre for Communication Systems Research, University of Surrey, Guildford, Cory Henson, Ohio Center of Excellence in Knowledge-enabled Computing and Kerry Taylor, CSIRO ICT Centre, Canberra, Australia

[26] Gateway Device Management GE - Ericsson IoT Gateway, http://catalogue.fi-ware.eu/enablers/gateway-device-management-ge-ericsson-iot-gateway

[27] Constrained RESTful Environments (core), IETF, https://datatracker.ietf.org/wg/core/

[28] Resource Directory IETF specification, http://tools.ietf.org/html/draft-shelby-core-resource-directory-02

[29] CoRE Link Format, IETF Internet Draft, Z. Shelby, June 15, 2011, http://tools.ietf.org/html/draft-ietf-core-link-format-06

[30] Digcovery, www.digcovery.com [31] IoT6 deliverable D3.1, Look-up/discovery, context-awareness, and

resource/services directory [32] Service Modelling for the Internet of Things, IoT-A, (http://www.iot-

a.eu/public) contract number: 257521 [33] OWL 2 Web Ontology Language Document Overview (Second Edition), W3C

Recommendation 11 December 2012, http://www.w3.org/TR/2012/REC-owl2-overview-20121211/

[34] D. J. Russomanno, C. Kothari, and O. Thomas, "Sensor ontologies: from shallow to deep models," in Proceedings of the Thirty-Seventh southeastern Symposium on System Theory, 2005.

[35] J. H. Kim, K. Kwon, K. D.-H, and S. J. Lee, "Building a service-oriented ontology for wireless sensor networks," in Proceedings of the Seventh IEEE/ACIS International Conference on Computer and Information Science, 2008, pp. 649-654.

[36] P. M. Barnaghi, S. Meissner, M. Presser, and K. Moessner, "Sense and sens'ability: Semantic data modelling for sensor networks," in Proceedings of the ICT Mobile Summit, 2009.

[37] OMA Next Generation Services Interface V1.0, http://technical.openmobilealliance.org/Technical/release_program/ngsi_v1_0.aspx

Page 80: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

80

[38] NGSI-9/NGSI-10 information model, http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/NGSI-9/NGSI-10_information_model

[39] ElasticSearch, http://www.elasticsearch.org/ [40] DigCovery Framework Documentation, Pablo Lopez Martinez, David

Fernandez Ros, Antonio J. Jara Valera, Clinical Technology Lab (CliTech), Computer Science Faculty, University of Murcia, Murcia, Spain

[41] FI-WARE, Gateway Device Management GE - User and Programmers Guide, https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Gateway_Device_Management_-_User_and_Programmers_Guide

[42] IoT6, deliverable 5.1, Selection of circuits and functionalities [43] Avahi, http://avahi.org/ [44] IoT6 project, deliverable D6.2 [45] oBIX specification,

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=obix [46] OneM2M, http://www.onem2m.org/ [47] IoT6, deliverable D1.2 [48] MySql, http://www.mysql.com/ [49] Mongo DB, http://www.mongodb.org/ [50] IoT6 project, deliverable D7.1 [51] IoT6 project, deliverable D4.2 [52] IoT6 project, deliverable D5.1 [53] IoT6 project, deliverable D4.1 [54] WP2 and WP3 demo, IPv6 connectivity and Open Service Architecture [55] Handle System. http://www.handle.net/index.html [56] IoT6 project, deliverable D5.4 (2014) Intelligence distribution tests and

evaluation [57] IoT6 project, deliverable D2.2 [58] IoT6 project, deliverable D2.4 (2014) IPv6 based advanced features [59] IoT A project, deliverbale D 1.5 http://www.iot-a.eu/public/public-

documents/d1.5/view [60] IoT6 project, deliverable D7.2 [61] IoT6 project, deliverable D1.3 [62] D. Menascé, V. Almeida, L. Dowdy, Performance by design: computer

capacity planning by example, Prentice Hall, 2004 [63] S. Gilbert, N. Lynch, “Brewer’s Conjecture and the Feasibility of Consistent,

Available, Partition-Tolerant Web Services”, ACM SIGACT News 33.2 (2002): 51-59.

[64] J. Jaroslav, “NoSQL database: a step to database scalability in Web

Page 81: Universal Integration of the Internet of Things through an ... - D1.4_0.pdf · Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture

D1.4 Updated Version of IoT6 Architecture and SOA specifications

81

environment”, International Journal of Web Information Systems 9.1, (2013), 69-82.

[65] Markus Jung, Philipp Raich, Wolfgang Kastner. The relevance and impact of IPv6 multicasting for Wireless Sensor and Actuator Networks based on 6LoWPAN and Constrained RESTful Environments. In Proceedings of the 4th International Conference on the Internet of Things (IoT 2014), Cambridge, MA, USA, October 2014.

[66] Jie, Yang, Jie Qiu, and Ying Li. "A profile-based approach to just-in-time scalability for cloud applications." Cloud Computing, 2009. CLOUD'09. IEEE International Conference on. IEEE, 2009.

[67] Lee, Jae Yoo, and Soo Dong Kim. "Software approaches to assuring high scalability in cloud computing." e-Business Engineering (ICEBE), 2010 IEEE 7th International Conference on. IEEE, 2010.

[68] IoT6 project, D2.3 Deliverable (2013), Implementation and testing report on IPv6-based features for the Service.

[69] Domain Name System, Wikipedia.org/wiki/Domain Name System [70] Digital object Numbering Authority,

http://itu4u.wordpress.com/2014/01/06/lost-something-on-the-internet-never-again-with-new-digital-object-do-architecture/

[71] Datagram Transport Level Security, Wikipedia.org/wiki/Data Transport Level Security

[72] The Handle System, Handle.net [73] Internet Assigned Number Authority, www.iana.org [74] Internet Engineering Task Force, www.ietf.org [75] Internet Governance Forum, http://www.intgovforum.org/ [76] KNX Standard, http://en.wikipedia.org/ [77] www.oid-info.com [78] Registry for IP Europe, www.ripe.net [79] Recommendation ITU-X 1255 (2013), Series X Data Networks, Open System

Communications and Security, Framework for discovery of identity management information.