deliverable d1.3 updated version of iot6 architecture and

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

deliverable d1.3 updated version of iot6 architecture and

Documents