Universal Integration of the Internet of Things through an IPv6- … - D4.4.pdf · 2021. 3. 2. ·...

1

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 D4.4 Report on Heterogeneous Device Interoperability and Multi-protocol Integration

Contract Due Date 31/07/2014

Submission Date 17/08/2014

Version v1.0

Responsible Partner HESSO

Author List Alex Olivieri

Dissemination level PU

Keywords Internet of Things, Business Process

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

This project has received funding from the European Union’s Seventh Framework Programme for research, technological development and demonstration under grant agreement no 288445.

mailto:[email protected]

Deliverable Abstract

This deliverable expounds on the work done on T4.3 Heterogeneous devices interoperability

and its two main requirements of researching various mechanisms for device interaction

(M2M ), and evaluating those mechanisms in order to understand which mechanism best fits

the goals of the IoT6 project.

IoT6 D4.4 Report on Heterogeneous Device Interoperability and Multi-protocol Integration

3

Table of Contents

1 Introduction ................................................................................................................. 6

1.1 Overview of IoT6 European Project ........................................................................... 6

1.2 Overview of Work Package 4: Multi-Protocol Interactions ........................................ 6

1.3 Overview of the Deliverable ....................................................................................... 8

2 The evolution of Machine-to-Machine: from the origins until the Internet of Things ............................................................................................................................... 9

2.1 Machine-to-Machine (M2M) ...................................................................................... 9

2.2 Influence of Internet of Things on Machine-to-Machine ......................................... 10

2.3 Evolution of Machine-to-Machine paradigm ........................................................... 10

2.4 Machine-to-Machine and the IoT6 project .............................................................. 11

3 Schemata definition ................................................................................................... 13

3.1 M2M Gateway Habitudinal Approach ...................................................................... 13

3.1.1 Heterogeneity Problem ...................................................................................... 14

3.1.2 Scalability Problem ............................................................................................. 14

3.2 Novel M2M Gateway Approaches ............................................................................ 14

3.2.1 Distributed Multi-Protocol ................................................................................. 15

3.2.2 Web-Service Multi-Protocol ............................................................................... 16

3.3 Multi-Protocol Gateway and Control and Monitoring System: Consequences for M2M interactions’ evaluations. ........................................................................................... 17

4 Models ....................................................................................................................... 18

4.1 IoT6 Stack ................................................................................................................. 18

4.2 Components ............................................................................................................. 19

4.2.1 Gateway .............................................................................................................. 19

4.2.2 Translation Mechanism ...................................................................................... 20

4.2.3 Control and Monitoring System ......................................................................... 20

4.3 Approaches’ Workflow ............................................................................................. 22

4.3.1 Multi-Protocol Gateway Workflow ..................................................................... 23

4.3.2 Distributed Multi-Protocol Gateway Workflow .................................................. 24

4.3.3 Web-Service Multi-Protocol Gateway Workflow ............................................... 26

5 Tests ........................................................................................................................... 29

5.1 Features to Analyze .................................................................................................. 29

5.1.1 Feasibility ............................................................................................................ 29

5.1.2 Scalability ............................................................................................................ 29

5.1.3 Potential for the IoT6 Architecture .................................................................... 30

5.2 Set Up ....................................................................................................................... 30

5.2.1 Set-Up Traditional M2M Interaction System ...................................................... 30

5.2.1.1 Workstation Details ...................................................................................... 30

5.2.1.2 Interactions Details ....................................................................................... 30

5.2.2 Set-Up Distributed M2M Interaction System ..................................................... 31



5.2.3 Set-Up Web-Service M2M Interaction System ................................................... 32


4


5.2.3.2 Web Service Platform Details ....................................................................... 33


5.3 Test Metrics .............................................................................................................. 34

5.3.1 Scalability ............................................................................................................ 34

5.3.2 Feasibility ............................................................................................................ 34

5.3.3 Potential Benefits ............................................................................................... 34

5.4 Results ...................................................................................................................... 35

5.4.1 Scalability ............................................................................................................ 35

5.4.1.1 Translation Test ............................................................................................. 35

5.4.1.2 Business Logic Exploration Test .................................................................... 38

5.4.2 Feasibility ............................................................................................................ 41

6 Evaluation .................................................................................................................. 42

6.1 Scalability .................................................................................................................. 42

6.2 Feasibility .................................................................................................................. 42

7 Conclusions ................................................................................................................ 43

8 Bibliography ............................................................................................................... 44


5

Table of Figures Figure 1: Traditional M2M System .......................................................................................................... 9

Figure 2: M2M concept in IoT ............................................................................................................... 12

Figure 3: Multi-Protocol Gateway ......................................................................................................... 13

Figure 4: Distributed Multi-Protocol ..................................................................................................... 15

Figure 5: Web-Service Multi-Protocol ................................................................................................... 16

Figure 6: IoT6 Ecosystem ....................................................................................................................... 18

Figure 7: Control and Monitoring System Algorithm ............................................................................ 21

Figure 8: Active Object Pattern - Structure ........................................................................................... 22

Figure 9: Workflow Traditional Approach ............................................................................................. 23

Figure 10: Workflow Distributed Approach .......................................................................................... 25

Figure 11: Workflow Web-Service Approach ........................................................................................ 27

Figure 12: Set-Up Traditional M2M Interaction System ....................................................................... 30

Figure 13: Set-Up Distributed M2M Interaction System ....................................................................... 31

Figure 14: Set-Up Web-Service M2M Interaction System .................................................................... 33

Figure 15: Latency when the translation is performed within the Gateway ........................................ 35

Figure 16: Latency when the translation is demanded to the Web Service ......................................... 36

Figure 17: Traditional and Web Service Approaches Latency curves superimposed ........................... 37

Figure 18: All Knowledge contained in one CMS placed in the same Workstation of the Gateway .... 39

Figure 19: Knowledge Distributed among CMS placed in different Workstations ............................... 40

Figure 20: Polynomial Interpolation of the Scalability Knowledge Base Scalability Results ................. 40

Table of Tables

Table 1: Questionnaire about Easiness ................................................................................................. 41


6

1 Introduction

This section describes the goals of Work Package 4 “Multi Protocol Interactions”, in the context of the IoT6 European project1, focusing on Task T4.3 “Heterogeneous Devices Interoperability”, and presents the work that has been done according to the Description of Work.

1.1 Overview of IoT6 European Project

IoT6 is a three-year FP7 European research project on the future Internet of Things. It aims at exploiting the potential of IPv6 and related standards (6LoWPAN, CoAP, etc.) to overcome current shortcomings and fragmentation of the Internet of Things. Its main challenges and objectives are to research, design and develop a highly scalable IPv6-based Service-Oriented Architecture to achieve interoperability, mobility, cloud computing integration and intelligence distribution among heterogeneous smart things components, applications and services. The potential of the proposed architecture is researched by exploring innovative forms of interactions such as:

Information and intelligence distribution.

Multi-protocol interoperability with and among heterogeneous devices.

Device mobility and mobile phone networks integration, to provide ubiquitous access

and seamless communication.

Cloud computing integration with Software as a Service (SaaS).

IPv6 - Smart Things Information Services (STIS) innovative interactions.

The main outcomes of IoT6 are recommendations on the exploitation of IPv6 features for the Internet of Things and an open and well-defined IPv6-based Service Oriented Architecture enabling interoperability, mobility, cloud computing and intelligence distribution among heterogeneous smart things components, applications and services, including building processes management tools.

1.2 Overview of Work Package 4: Multi-Protocol Interactions

Work Package 4 (WP4) is researching innovative forms of multi-protocol integration and interoperability through the developed IoT6 Service Oriented Architecture. Many Internet of Things components are using non-IP based communication protocols, in particular in building environments. This fragmentation appears at several levels: physical layer, networking layer and application layer. This WP will research and explore several schemes of multi-protocol integration, including shared ontology and multi-protocol translation, with a particular concern for the integration of non-IP based protocols and devices into the proposed architecture, and more generally into the Internet. It will among others explore the possibility to use solutions such as multi-protocol Gateways, distributed integration, and multi-protocol translation web services. WP4 is composed of three Tasks related to the integration of devices that have non-IP based communication protocols into the IoT6 paradigm and they can be summarized as follows:

1 http://www.iot6.eu/


7

Task T4.1: Focuses on the multi-protocol architecture and on the system development. This task, in a first phase, analyzes the functional parameters of the WP1 in the light of the protocol suites that should be used. In a second phase, it will develop a multi-protocol and polyvalent control and monitoring system and to adapt it to the Universal Device Gateway2 (UDG) in order to support the Tasks T1.2 “First version of IoT6 architecture and SOA specifications” and T1.3 “Updated version of IoT6 architecture and SOA specifications”, and taking into account the use cases requirements identified in WP1. The Control and Monitoring System must provide the semantics to allow the interoperability with the other components and/or applications of the IoT6 architecture. This Task is also in charge of adapting and developing the graphical user interface (GUI) required to interact and monitor the heterogeneous devices integrated to the IoT6 architecture for the experiments. The GUI is intended to be portable on various interfaces such as PCs, mobile phones and touch screens. Task T4.2 “Multi-protocol integration” focuses on the integration of a selection of heterogeneous protocols into the IoT6 architecture. It analyses and researches the application layers of the selected protocols to integrate them and provide semantic interoperability. It uses as much as possible existing resources, including UDG existing modules and available OSGi bundles. This task researches a selection of heterogeneous mainstream communication protocols related to different sectors of the Internet of Things to analyze and compare their respective functions and ontology. This task also integrates the selected protocols into OSGi bundles to be used by the Multi-protocol control and monitoring system (T4.1). It tests and validates the multi-protocol integration by testing cross interactions among heterogeneous devices from every possible combination of selected standards. Task T4.3 ”Heterogeneous devices interoperability” focuses on research device to device interactions (M2M), by exploring, testing and validating different schemes of multi-protocol integration and interoperability, and by analyzing their feasibility, scalability, and potential benefit for the IoT6 architecture. It will address different schemes, such as:

a) Direct IoT6 interoperability, by exploring and testing the capacity of IoT6 SOA

architecture to provide direct interoperability among heterogeneous components

through IoT6 shared ontology.

b) Innovative Gateway interoperability, by exploring and validating 4 schemes of

heterogeneous integration through the UDG multiprotocol Gateway.

c) IPv6 web services and proxy for heterogeneous devices, by researching and designing

IPv6 web services and proxies for heterogeneous devices using non-IP compliant

protocols. It will explore and compare different schemes of integrating legacy devices

into IPV6, by providing an IPv6 proxy for non-IP smart things: Decentralized, Half-

centralized and Centralized IPv6 integration.

d) Multi-protocol translation web service, by exploring the possibility to provide such

services to other IoT6-connected systems and applications.

2 http://www.devicegateway.com/


8

1.3 Overview of the Deliverable

This deliverable expounds on the work done in Task T4.3 ”Heterogeneous devices interoperability” and its two main requirements of researching various mechanisms for device interaction (M2M3), and evaluating those mechanisms in order to understand which mechanism best fit the goals of the IoT6 project. This deliverable is organized as follows: Section 2 introduces the topic of Machine-to-Machine (M2M) interaction and what consequences the Internet of Things produces; Section 3 describes the usual schema for M2M gateways in M2M interactions, the limitations of this schema and proposes some new schemas to address these limitations; Section 4 models the three M2M Interaction Systems and the workflows of the communications that occurs in these systems; Section 5 involves testing and what features to test, the test metrics and the test results; Section 6 evaluates the test results; Section 7 summarizes the way in which the Description of Work requirements have been fulfilled; providing conclusions about the work done and proposes the guidelines for M2M Interactions Systems implementation.

3 Machine-to-Machine


9

2 The evolution of Machine-to-Machine: from the origins until the Internet of Things

In this section, the topic of Machine-to-Machine (M2M) interaction is introduced in detail in the context of the Internet of Things, pointing out the consequences that this new paradigm produces and how these consequences are faced.

2.1 Machine-to-Machine (M2M)

Machine-to-Machine4 refers to the information exchange among devices without human assistance. The interactions among those devices comprehend both wireless and wired systems [1]. In the beginning, M2M was used to create systems that were task- or device- specific, due to the absence of a standardized M2M platform that would allow the connection of heterogeneous technologies [2]. M2M has been used over time mainly to build decision-making systems (some kind of Control and Monitoring System), where the data sent by devices is interpreted, evaluated and the decisions as a result of those evaluations are used to pilot some device behavior. These M2M systems are pretty simple because they must address only one technology at a time between the devices and the decision maker. The systems need only a so-called Interpreter, which has the duty of translating the data workflow to and from the couples Devices/Decision Maker. Figure 1 shows the components present in the early M2M Systems and the interactions between them.

Figure 1: Traditional M2M System

4 http://en.wikipedia.org/wiki/Machine-to-Machine


10

2.2 Influence of Internet of Things on Machine-to-Machine

The invention of the Internet of Things (IoT) has brought new challenges to Machine-To-Machine communication. The Internet of Things by definition refers to the interconnection of uniquely identifiable embedded computing units, such as devices within the existing Internet infrastructure5. If we analyze this definition, we can determine that M2M can be seen as one of the integral parts of the Internet of Things, as it can be used to create some innovative scenarios using devices in an autonomous manner. Nevertheless, the name, and even more its definition, Internet of things, already suggests that the M2M paradigm may evolve its vision, passing from the usual mono-technology scenarios to scenarios that involve various heterogeneous joined technologies. By following one of the main ideas of the Internet of Things – Connecting the World [3]- leads to the fact that by using the Internet we exit from the small local boundaries and we move towards broader domains that incorporate heterogeneous technologies. Under these new conditions, the Interpreter, which was a main component in the former M2M systems, is no longer adequate as it was designed to work in a mono-technology environment.

2.3 Evolution of Machine-to-Machine paradigm

Machine-to-Machine has to evolve to face the new challenges brought by the Internet of Things and, more generally, by the Internet. Nowadays, M2M involves communications between machines from different vendors, typically using different technological communication protocols. In such situations the traditional concept of Interpreter is no longer satisfactory for these new scenarios. The systems must evolve, proposing a new solution to face the heterogeneity that will be present in those scenarios. The solution that has emerged is called Universal Gateway [4]. A Universal Gateway is a device that transacts data between two or more data sources using communication protocols specific to each one. Sometimes called a Universal Protocol Gateway, this class of product is designed as a computer appliance, and is used to connect data from one automation system to another. This Universal Gateway is a software component to support one or more Industrial Protocols for connecting data from one device to data in another, one being the source of data and one being the destination. Communication is typically polled or change based. Great care is typically taken to leverage communication protocols for the most efficient transaction of data (Optimized message sizes, communications speeds, and data update rates). Universal Gateways can perform such data translations through Protocol Converters [5], which is used to convert standard or proprietary protocol of one device to the protocol suitable for the other device, or tools, to achieve the interoperability. These Protocol Converters are implemented in the Universal Gateways, and they convert the data formats, data rate and protocols of one network into some semantics adopted within the Universal Gateway. The major protocol translation messages involve conversion of data messages, events, commands, and time synchronization.

5 http://en.wikipedia.org/wiki/Internet_of_Things


11

2.4 Machine-to-Machine and the IoT6 project

In the context of the IoT6 project, two different Gateway solutions have been developed: the middleware of the Universal Device Gateway (UDG)6 and the IoTSyS7. These two Gateways implement the logic of the Universal Gateway illustrated in Section 2.3 using two different semantics:

UDG Semantics: The UDG semantics is based on mapping devices (real or virtual) in

so called application modules, which allows conversion of data sent by devices in

events and converts actions internally defined in data, which are sent to the devices.

IoTSyS Semantics: IoTSyS semantics is based on the OASIS Open Building Information

Exchange8 standard and represents devices following a generic meta-model that

allows the usage of a data-point centric information model. The basic oBIX object

meta-model is generic and can be used to represent existing home and building

automation technologies, and similarly can also be used to model device objects that

directly reside on constrained devices such as sensors and actuators. So called oBIX

contracts provide a way of specifying certain device classes which allows provision of

more domain specific interface contracts for specific application domains such as

lighting, HVAC, alarming, security or safety.

Both Gateways can map data provided by heterogeneous devices belonging to various technologies and both have the ability to translate the data into their own internal semantics with the purpose of using them for various aims. The IoT6 project has recognized two other fundamental concepts: the Control and Monitoring System (CMS) and the IoT6 stack. The CMS can be likened to the decision maker introduced in Section 2.1. The IoT6 Stack is the common communication interface amongst all components present within the IoT6 project. The core elements of the IoT6 Stack are: IPv6 as Internet Protocol, Web services based on CoAP 9 as service layer, the OASIS Open Building Information Exchange standard (oBIX) [6] as object model and JSON10 as message encoding. UDG and IoTSyS are IoT6 Stack compliant and therefore, can communicate with the Control and Monitoring System using a standard interface that could eventually be used as semantic for a standardized M2M/Internet of Things platform. Figure 2 shows how the M2M paradigm is seen within the IoT6 project for what concerns the devices’ interoperability, and the Multi-Protocol integration. The Gateway (can be UDG or IoTSyS) has a type of connector for each technology that allows interpretation of the data sent by devices and translates them into an internal representation (the internal semantics). These semantics can be transformed using the standard interface into IoT6 Stack information

6 http://www.devicegateway.com/ 7 https://code.google.com/p/iotsys/ 8 https://www.oasis-open.org/committees/obix/ 9 http://tools.ietf.org/html/draft-ietf-core-coap-09 10 http://www.json.org/


12

that can be exchanged with any components that are part of the IoT6 project. The figure shows that in the context of this deliverable, the exchange of information will take place within the Control and Monitoring System.

Figure 2: M2M concept in IoT


13

3 Schemata definition

In this section, what is described is the usual schema that M2M Gateways use as an approach for M2M interactions, and why we believe this approach may not be adequate in the context of novel scenarios brought by the Internet of Things. Then, we propose new schematas that can be used to address the challenges the new scenarios related to the Internet of Things brings to M2M interactions. Subsequently, wetest the different schematas to define some guidelines for M2M Gateway developers in order to help them create easier and higher performance solutions.

3.1 M2M Gateway Habitudinal Approach

The history of M2M interactions showed over time the utilization of a local scenario M2M Gateway, where only a few solutions contemplated the integration of heterogeneous protocol and only a limited number of devices were used in order to perform a bounded task or group of tasks [7]. This solution was efficient and successful until the Building Automation System did not advance to the current situation, and the Internet of Things did not create such scenarios where huge number of devices may be employed. Figure 3 shows the approach Multi-Protocol Gateways usually use. The Gateway can hypothetically manage, if equipped by developers of the necessary structures, all protocols for building automation technologies.

Figure 3: Multi-Protocol Gateway

A Gateway is implemented to fully support all devices belonging to different technologies, which are employed in the scenario of interest, and only one Gateway is needed to manage that scenario.

The IoT6 project has seen two Gateways (IoTSyS and UDG) developed and built following this idea. Both Gateways have very good features and are being used in other European projects.


14

These Gateways have even won some awards11, 12.

From our point of view, as the M2M interactions domain is changing, this way of developing Gateways can encounter two developing issues:

Difficulty in creating solutions that can face the high and mutable number of

heterogeneous technologies of the devices employed in current scenarios.

Difficulty in creating solutions which scale well with the increasing number of

devices.

3.1.1 Heterogeneity Problem

Nowadays, Internet of Things scenarios expect the usage of devices belonging to various heterogeneous technologies, they also expect that those devices can be replaced over time with devices belonging to other technologies. It means that developers of a Gateway should have technical knowledge of, hypothetically, all possible technologies for devices within the Internet of Things context. To have such knowledge of a large number of technological protocols can be really challenging. Each technology possesses features that are different and all of them use different protocol stacks. To create and maintain such an idea of a gateway can create a huge effort for the gateway’s owners. The team that implements it, having first identified the interesting technologies, must foresee how many different developers it needs and must anticipate specialization courses in order to give them the necessary knowledge.

3.1.2 Scalability Problem

The Internet of Things brought Gateways to the next level, where it is difficult to estimate the number of devices that will be employed on a scenario from the beginning. It means that the Gateway can start working perfectly with a certain number of already tested devices, and they can deal with the simultaneous incoming/outgoing communications from and to devices properly. The problems arise when the number of devices increases with likely consequent augmentation of the number of simultaneous communications. If a gateway was modeled without load balancing features, it is likely that it would collapse under the new workloads the Internet of Things scenarios can produce.

3.2 Novel M2M Gateway Approaches

In this subsection, two approaches are proposed that can enrich the current M2M Multi-Protocol Gateway solutions by addressing the problems described in subsections 3.1.1 and 3.1.2. Both approaches aim to distribute the devices’ management in order to ease the development and to provide scalability to current scenarios.

11 http://www.ipso-alliance.org/challenge/ipso-challenge-2014-interviews/iotsys 12 http://www.ipso-alliance.org/ipso-challenge-2013-interviews/iotsys-internet-of-things-integration-middleware


15

3.2.1 Distributed Multi-Protocol

Figure 4 shows the first proposed innovative approach. In this approach, we propose to treat the protocols singularly or as a subset of the selected protocols in each gateway. The devices managed by each gateway belong to a unique technology (or in some case to a small subset of them). Each gateway is capable of interpreting the information contained in the raw data exchanged with the devices attached to it. Afterwards, gateways provided by different working groups skilled in dedicated technologies can be combined to create multi-protocol scenarios.

Figure 4: Distributed Multi-Protocol

At first sight, this approach of having every Gateway managing only one protocol may seem like the multi-protocol Gateway is regressing back some years ago. However, we believe that a proficient engineering of the systems will bring advantages which will eliminate the drawbacks if this approach is used. By using this approach, it is possible to envisage a solution for the two challenges previously illustrated in the following ways:

Heterogeneity Problem: Developers of a Gateway must have knowledge about only one

technology to be able to map the data coming from devices to the internal semantics of

the gateway and vice versa (from the semantic to the data for the devices). This allows

developers to enrich their competences for a smaller domain of technologies that will

lead to an improvement of the quality of their work. Obviously Gateways that manage

different technology can be employed to create heterogeneous scenarios, but each of

those gateways will be developed by different vendors.

Scalability Problem: This approach faces the scalability issues deriving by the growth of

the devices used in novel scenarios distributing the managing of devices among more

distributed Gateways. By doing so, we can alleviate the scalability constraints arising

from the underlying framework present inside the gateways. In fact, developers can try

to make a framework as scalable as they can, but eventually the scalability depends upon

the hardware and the number of processes13 and threads14 the underlying platforms can

13 http://en.wikipedia.org/wiki/Process_(computing)


16

support. So, the only way to improve the scalability is to distribute the amount of work

among more Gateways.

Nevertheless, this approach also brings some new challenges which the developers must face. Now, every Gateway must be able to interact with other Gateways to implement scenarios. We are not specifying which kinds of communications will be used, because it depends on the design of the Distributed Multi-Protocol System. But to interact, the Gateways need to talk the same language, which leads to the creation of a common language spoken by all Gateways.

3.2.2 Web-Service Multi-Protocol

Figure 5 shows the second proposed innovative approach. This approach deals with the heterogeneity of the protocols with a methodology similar to the ones we proposed for the Distributed approach, where only one protocol or a subset of the selected protocol is managed within a single Gateway. As before, Gateways managing dedicated technologies must be combined to create multi-protocol scenarios.

This main difference is that in this approach, a solution where the Gateways are fully unaware of the format of the data they will exchange with the connected devices is proposed. It receives raw data from devices and sends raw data to devices without being able to interpret the information contained in the raw data. To have interpretable data, the gateways need to contact a Web Service that can perform the translation between raw data and shared format that they will use for internal purpose and to interact with other Gateways (and to translate the information from the shared format to the raw data).

The Web Service performs the task of interpreting the raw data belonging to different protocols and translates them into a shared format. This task can be accomplished thanks to so called Translation Modules that developers, experts in some technologies, implement and install on the Web Service.

Figure 5: Web-Service Multi-Protocol

We believe that this approach brings solutions for the two challenges previously mentioned

14 http://en.wikipedia.org/wiki/Thread_(computing)


17

in the following ways:

Heterogeneity Problem: Developers who build a gateway do not need any knowledge of

the raw data exchanged with the devices, because the interpretation work will be

performed in the Web Service, through the Translation Mechanisms. This allows

developers to focus on the logic of the Gateway and how it manages the

incoming/outgoing communications with the devices.

Scalability Problem: The translation needs computations regardless of the

methodologies used to perform it. Those computations could lead to some performance

decreases when the number of devices connected grows too much. This decrease in

performance does not happen in Web Service, because they can be implemented in a

way that can afford higher workloads. With this approach, it is possible to let the Web

Service work for the Gateway, while the latter will focus on different tasks thank to the

possibility to have asynchronous communications [8] between the Gateways and the

Web Service.

This approach brings the same challenges given by the approach mentioned in Section 3.2.1., but they must be faced and solved in different ways.

3.3 Multi-Protocol Gateway and Control and Monitoring System: Consequences for M2M interactions’ evaluations.

In this section, the concept of Multi-Protocol Gateway on the M2M interactions is introduced; the limits which they manifest when the switch to the new domain of the “Internet of Things” is made and two new approaches that could solve these limits are proposed.

In the next sections, as the main task of the Task T4.3, all schematas (the traditional M2M interaction approach and the two new ones) will be tested in order to suggest to Gateway developers the approach they should follow.

However, in the IoT6 project context, we cannot stop at the Multi-Protocol Gateway concept, since it is meant to be used in more complex scenarios whose logics must be defined and managed by a component called Control and Monitoring System. This means that a full M2M interaction system includes devices, one or more Multi-Protocol Gateways and one or more Control and Monitoring Systems. Therefore, the entire M2M interaction system must be evaluated.

Each schema will integrate the Control and Monitoring System within the Gateway in a different way, as shown in the following section.


18

4 Models

In this Section, three M2M interaction systems are modeled and include the following main components: the Multi-Protocol Gateway, the Control and Monitoring System and the Translation Mechanism. The idea is to have each component implemented in the same modality in order to reproduce homogeneous conditions when the tests are performed. What will change in the implementations is the communications schema adopted for each system, as shown in Figures 3, 4, and 5.

4.1 IoT6 Stack

In Section 3, a new challenge brought about by the two new approaches proposed; namely, the need for a common language was discussed. This common language in Figure 4, and 5 is named “Shared Format” and represents the standard communication methodology that must be adopted as interaction format to allow every component to understand each other.

In the IoT6 project, a common interface has been designed that allows the interconnection of all components under a common communication environment. This interface, named the IoT6 Stack, defines the standards to which all entities must comply if they want to exchange information inside the IoT6 ecosystem. The IoT6 Stack aims to provide a common communication interface amongst all technologies present in the Internet of Things environment. The core elements of the IoT6 stack are: IPv6 as Internet Protocol, Web services based on CoAP 15 as service layer, the OASIS Open Building Information Exchange standard (oBIX) [6] as object model and JSON16 as message encoding.

Currently, through the IoT6 Stack, the IoT6 project has made all IoT6 components interoperable. Figure 6 shows the six main IoT6 components present within the IoT6 ecosystem and all the communications are supported by the IoT6 Stack.

Figure 6: IoT6 Ecosystem

15 http://tools.ietf.org/html/draft-ietf-core-coap-09 16 http://www.json.org/


19

The deliverable D6.6 “Multi-systems integration for smart building environment report” demonstrated that this “IoT6 Stack” can also be used easily outside the IoT6 Ecosystem, thanks to the previously mentioned standards of which it is composed. Mainstream technologies also used within the Internet of Things domain, such as Philips Lighting HUE, Microsoft Kinect, Android Smartphone and Google Glass have been integrated through that stack, requiring little effort. In the context of the work being performed, we will consider the IoT6 Stack as the methodology to enable the interactions among the components present. Indeed, we will use only a sub set of this stack specification – IPv6 and JSON – without considering CoAP and oBIX.

4.2 Components

We stated that when M2M interactions are applied in the context of the Internet of Things, the former Multi-Protocol Gateways are no longer satisfactory. This is due to the heterogeneity of the devices involved and the complexity of the scenarios. In the IoT6 project, M2M Interaction Systems are essentially composed of 3 main components: the Multi-Protocol Gateway, the Translation Mechanism and the Control and Monitoring System. The Gateway acts as a bridge between the connected devices and the framework that manages the logic of the scenarios. It manages the incoming and outgoing flows of raw data, paying attention to the features of the technologies it is managing. The Translation Mechanism acts as an interpreter and it performs the translations from raw data sent by devices to the IoT6 Stack and vice versa. The Control and Monitoring System has the logic of the scenarios and it decides the system behavior based on something that the involved devices communicated.

Within the IoT6 project, as mentioned previously, there are already two gateway solutions that have been deployed, each with its own logic. However, we want to create a solution as independent as possible, in order to draw guidelines that developers can depend upon in generic conditions. Another observation is that, for testing, the scalability required is a high number of components and devices and this is out of the project scope, since it is not focused on the IPv6 IoT architecture or on the high number of test devices. Therefore, we will not use any hardware, for the three components nor for the devices. The framework will be fully software-based and the devices will be software modules that will simulate virtual devices.

4.2.1 Gateway

The Gateway within the context of this work is considered as the component to which all devices are attached and acts as a communication bridge between the devices and the framework. It receives measurements from devices that act as sensors, forwarding them to the framework and sending commands provided by the framework to devices that act as actuators. Hence, it is the manager of the information workflows in the form of raw data. When a device is attached to the Multi-Protocol Gateway, it assigns a global unique identifier to that device based on the IPv6 Mapping Module researched and implemented in the Deliverable D4.2 “Multi-protocol architecture and system development report”. This


20

mechanism allows every Gateway to identify the technology to which a device belongs, and is a very important aspect for the data interpretation phase.

Within this global unique identifier, we can find other information useful for applying the distributed idea proposed in the Distributed and Web Service approaches. The three important fields of that identifier are:

Gateway Identifier

Protocol Identifier

Device Identifier

With this identification mechanism, we can aggregate more Gateways in distributed scenarios while still having the capability to understand which devices are being referred to.

4.2.2 Translation Mechanism

The Translation Mechanism is the component that can interpret information contained within raw data sent by devices and can translate it to a defined format (in our case the JSON piece of information of the IoT6 Stack) understandable by other components. Vice-versa, it has the ability to translate information formatted using JSON into raw data. To perform these operations, the Translation Mechanism must know the technology to which the device that is sending the data belongs, and this piece of information is passed along by the Gateway using the identifier, along with the raw data (this is the reason why the Protocol Identifier parameter is needed). Once the information formatted as JSON is sent back from the Translation Mechanism to the Gateway, the Gateway extracts the information contained inside the JSON representation and incorporates it in an object called Fact. This Fact can be sent via messages to other IoT6 components, and it contains three pieces of information: the device identifier of the device that sent the measurement, the description of what this measurement refers to and the value of that measurement.

4.2.3 Control and Monitoring System

The Control and Monitoring System is a framework17 that decides the behavior to be performed when something happens. In short, it manages the business logic of the scenario where the M2M interaction System is used. When complex scenarios need to be performed, we need to react to these events, which in the M2M context are the sensors’ measurements that will lead to some action that must be performed by some actuators. In the context of the IoT6 project, the component Control and Monitoring System speaks the IoT6 Stack language, and can interact with the other components through JSON based communications. For the M2M interaction system, the Control and Monitoring System communicates with the Gateway. It receives pieces of information contained within Fact formatted in JSON representation from the Gateway and it sends back pieces of information contained within Action, always formatted in JSON. An Action is a piece of information that contains a Recipient and an Operation. The Recipient identifies the actuator on which the

17 http://en.wikipedia.org/wiki/Software_framework


21

Operation must be performed. The Operation represents the real task that the actuator must perform (e.g. turn on a light alarm). Figure 7 shows a picture of the algorithm that the Control and Monitoring System framework uses to decide the behavior to be performed. When a Fact arrives into the Control and Monitoring System, it extracts the information contained in the Fact and compares it with the Triggers defined by the Rules. Each Trigger is associated to one or more Actions that are dispatched back to the Gateway in case the Trigger matches with the Fact.

Figure 7: Control and Monitoring System Algorithm

The CMS component implements the Active Object Pattern [10] and its structure follows the Figure 8 as explained below.


22

Figure 8: Active Object Pattern - Structure

The Control and Monitoring System provides clients with an entry point (the Proxy) to invoke tasks that it will perform for them. As the communications among clients and the Control and Monitoring System will be totally asynchronous18, they will be performed using the message passing paradigm19. For every request, the proxy will create a container for the response (the Future) that will be sent back to the specific client. Internally, the CMS has a pool of Threads 20 (the Servants) that are waiting to concretely perform the tasks to satisfy the clients’ requests. The requests coming from clients are inserted by a Thread (The Scheduler) in a queue (the Activation List). The Scheduled, following some policies, assigns the requests to Servants. Once a Servant has performed its task, the results of its computation are placed into the Future, which will be sent back to the client.

4.3 Approaches’ Workflow

We have just described how the components collaborate to provide a system that supports the M2M interactions for the IoT6’s scenarios. In this subsection, all the approaches will be described, how these components are connected and show and explain the different sequence diagrams that describe the workflows that happen in these interactions. In describing the operational workflow of the three different approaches, we assume that the business logic of the scenarios concerns only the devices attached to Gateways. Nevertheless, communications could clearly come from outside and go to other components of the IoT6 project (e.g. DigCovery, STIS etc.) or outer entities that conform to the IoT6 Stack. In order to allow this communication, a Gateway should always cooperate with other components and provide interfaces. However, these external kinds of communications are out of the scope of this work.

18 http://en.wikipedia.org/wiki/Asynchronous_communication 19 http://en.wikipedia.org/wiki/Message_passing 20 http://en.wikipedia.org/wiki/Thread_pool_pattern


23

4.3.1 Multi-Protocol Gateway Workflow

We stated that the traditional approach to Gateways in M2M interactions is to group all protocols under a unique Gateway that internally has an Interpreter capable of understanding all data sent by devices and using the data for defined purposes. This is how the two Multi-Protocol Gateways presented within the IoT6 project have been developed.

In the context of the IoT6 project, a Gateway is part of a larger task – managing the logic of scenarios where devices are involved. This task, as previously explained in this section, involves the other main component, the Control and Monitoring System.

We previously introduced the IoT6 Stack as format to exchange information among the components belonging to the IoT6 project, but now we present how those interactions are designed for the traditional approach. Figure 9 shows the workflow of the communications that are involved in the traditional approach, starting from a device sending raw data about a measurement, passing through the Gateway and the Control and Monitoring System to the device that will receive the raw data.

Figure 9: Workflow Traditional Approach

The steps that form this workflow are as follows:

1) A device senses that something related to the scenario happened and sends the raw data

containing information about the measurement to the Gateway;


24

2) The Gateway has a listening Agent 21 that is continuously listening for information

coming from devices. When a communication arrives it starts a new thread telling it that

the identifier (Gateway Id, Protocol Id, and Device Id) of the device is that has sent the

data. This thread is part of the Translation Mechanism, and it has the duty of

understanding the raw data based on the identifier of the device and transforming it into

IoT6 Stack information.

3) The Gateway creates a Fact containing the device’s identifier, the kind and value of the

measurement and it sends a message containing the Fact which conforms with the IoT6

Stack to the Control and Monitoring System.

4) The Control and Monitoring System internally possesses a data structure containing all

Rules defined to manage this interesting scenario. When the CMS is initialized, all Rules

are stored in memory and they are ready to be inspected in order to find the possible

association between Facts and Triggers. When a request from the Gateway arrives, the

CMS assigns it to a working Thread, which elaborates the request, checking if there are

any matches in the Rules.

5) If one or more matches are found, the CMS creates an object Action, conforms with the

IoT6 Stack, containing the information for every match found and then sends a message

back to the Gateway.

6) The Gateway receives the Action, reads the data, understands which device is interested

by the command contained in the Action, then passes the command to a worker Thread

that will transform it into raw data.

7) As a final step, the Gateway sends the raw data representing the command to the

interested device.

Using this approach there is a 1-to-1 correlation between the Gateway and the Control and Monitoring System, since only one Gateway and one CMS are present within a scenario.

4.3.2 Distributed Multi-Protocol Gateway Workflow

The first innovative approach we proposed involves communications among Gateways that each manage a specific protocol or a small set of them. Each Gateway contains an interpreter specific to the protocol it is developed for, and can understand all data sent by devices it manages and can use those data for defined purposes.

As we said previously, in the IoT6 project – and, more generally, in the Internet of Things domain - scenarios are created where a Control and Monitoring System manages business logics that involve more technologies, and as a consequence, those scenarios contemplate more protocols managed by more Gateways. Using this approach, we can employ Gateways built by different developer experts in a dedicated technology and exploit the IoT6 Stack to allow the interactions among the Gateways and the CMS.

21 http://en.wikipedia.org/wiki/Software_agent


25

Figure 10: Workflow Distributed Approach

Figure 10 shows a possible workflow of the communications that are involved in the distributed approach. The workflow is similar to what is shown in Figure 9, but the difference here is that more Gateways are involved. What can happen is that a device that sends some raw data about a measurement is behind a Gateway (let us call it Gateway A). Then the Gateway A will translate this data into an IoT6 Stack format (Fact) and will forward it to the Control and Monitoring System. The CMS will evaluate the behavior and, following the logic defined in the Rules it contains, will send the information as IoT6 Stack format (Action) to a Gateway i.e. this receiving Gateway could be the Gateway A that sent the first message or one of the other Gateways involved in the scenario. Subsequently the receiving Gateway will translate from IoT6 Stack format to raw data and will pass it to the device addressed within the Action, in order to have the command contained in the Action performed. The steps that form this workflow are as follows:


containing information about the measurement to the Gateway;

2) The Gateway has a listening Agent 22 that is continuously listening for information

coming from devices. When a communication arrives it starts a new thread telling the

identifier (Gateway Id, Protocol Id, and Device Id) of the device that has sent the data.

This thread is part of the Translation Mechanism, and it has the duty of understanding

the raw data based on the identifier of the device and transforming it into IoT6 Stack

information.

22 http://en.wikipedia.org/wiki/Software_agent


26

3) The Gateway creates a Fact containing the device’s identifier, the kind and value of the

measurement and it sends a message containing that Fact which conforms with the IoT6

Stack to the Control and Monitoring System.


Rules defined to manage the interesting scenario. When the CMS is initialized, all Rules


association between Facts and Triggers. When a request from the gateway arrives, the

CMS assigns it to a working Thread, which elaborates the request checking if there are

any matches in the Rules.

5) If one or more matches are found, the CMS creates an object Action, which conforms to

the IoT6 Stack, containing the information for every match found and then sends

messages containing the Actions to the addressed Gateways.

6) The Gateway receives the Action, reads the data, understanding which device is

interested by the command contained in the Action, then passes the command to a

worker Thread that will transform it into raw data.

7) As a final step the Gateway sends the raw data representing the command to the

addressed device in order to have the command performed.

Using this approach, there is an association n-to-1 between the Gateways and the Control and Monitoring System, because more Gateways are associated with one CMS. But theoretically, more CMS can be used to also distribute the intelligence, and this will be the real implementation used to perform the tests.

4.3.3 Web-Service Multi-Protocol Gateway Workflow

The second innovative approach proposed involves a new component, a Web Service that performs the translation task. This approach is an extension of the distributed approach, but here the Gateways act more as a network proxy23 than as Gateway for M2M. Each Gateway receives raw data from devices connected to it (usually only belonging to one protocol), but it does not contain any Interpreter, so it is not able to understand the information the raw data is conveying.

The Gateways need the support of a Web Service that contains modules implemented and deployed by developers to interpret the information contained within the raw data and transform it to an IoT6 Stack (Fact) message. As in the distributed approach, the Gateways will communicate with the Control and Monitoring System passing information in IoT6 Stack format (Fact), so that it can decided if the behavior defined is logical for the scenario.

Once the CMS figures out the behavior to accomplish, it sends information as an IoT6 Stack (Action) message to a Gateway. The Gateway must contact the Web Service again, which will translate the IoT6 Stack format information into raw data that will be used directly on the devices by the Gateway afterwards. By using this approach, the Gateways developers can directly implement an Interpreter versus trying to understand the problems of the raw data. The creation and deployment of Web Service modules will be done by experts in their respective technologies, or by their

23 http://en.wikipedia.org/wiki/Proxy_server


27

manufacturers.

Figure 11: Workflow Web-Service Approach

Figure 11 shows a possible workflow of the communications that are involved in the Web-Service approach. The workflow in this approach changes significantly due to a new component (the Translator Web-Service) is present. What can happen is that a device that sends raw data about a measurement is behind a Gateway (let us call it Gateway A). Then the Gateway A will send the raw data to a Web Service to obtain an IoT6 Stack message (Fact) containing a translation of those data. As Figure 11 shows, the communications from the Gateways towards the Web Service are totally asynchronous. The Web Service waits for new requests but it does not care who sends them. Once the Gateway A receives the raw data translated as IoT6 message, it will forward that message to the Control and Monitoring System. The CMS will evaluate the behavior and following the logic defined in the Rules it contains, it will send an IoT6 Stack message (Action) to a Gateway – this receiving Gateway could be the Gateway A that sent the first message or one of the other Gateways involved in the scenario (the functioning is the same as in the Distributed Approach). Subsequently, the receiving Gateway asks again for support from the Web Service in translating the IoT6 message to raw data and it will use the received raw data to command the device addressed within the Action to perform the necessary action.


28

The steps that form this workflow are as follows:


containing information about the measurement to the Gateway.

2) The Gateway has a listening Agent that is continuously listening for information coming

from devices. When a communication arrives, a new thread starts and informs the

Agent the device Identifier that sent the data. This thread will forward the raw data

together with the device identifier to the Web Service in a synchronous way.

3) The Web Service possesses methods that are dedicated to perform tasks for clients

(Gateway). When it receives a Raw Data -> IoT6 Stack format translation request from a

gateway, it activates one of the threads that are part of the Raw Data to IoT6 Stack pool

of threads. The activated thread extracts the device identifier in order to understand the

raw data and transforms it into IoT6 Stack information (Fact).

4) The Web Service then sends a reply message containing the Fact to the Gateway.

5) The Gateway will then forward that Fact to the CMS with an asynchronous message.


Rules defined to manage the interesting scenario. When the CMS is initialized, all Rules


association between Facts and Triggers. When a message arrives, the CMS assigns it to a

working Thread, which elaborates the request, checking if there are any matches in the

Rules.

7) If one or more matches are found, the CMS creates an object Action which conforms

with the IoT6 Stack, containing the information for every match found and then sends

messages containing the Actions to the addressed Gateway.

8) A Gateway that receives an Action starts a new thread that forwards that Action to the

Web Service in a synchronous way.

9) When the Web Service receives an IoT6 Stack format -> Raw Data translation request

from a Gateway, it activates one of the threads that are part of the IoT6 Stack to Raw

Data pool of threads. The activated thread extracts interpretations of the Action, and

translates the command contained in it into raw data.

10) The Web Service then sends a reply message containing the raw data to the Gateway.

11) As a final step the Gateway sends the raw data representing the command to the

addressed device in order to have the command performed.

As in the Distributed approach, an n-to-1 or an n-to-n association between the Gateways and the Control and Monitoring System is seen. However, in this case, we will also have a Web Service to contact in order to receive the translations. In the next section we explain the conditions under which the tests were performed.


29

5 Tests

This deliverable is required to “research, compare and evaluate Machine-to-Machine interactions” (or, more-specifically, Device-to-Device interactions). The Description of Work suggests some features that the deliverable should examine: the feasibility, the scalability and the potential benefit for the IoT6 architecture. In this section, the features of what the Description of Work suggests will be analyzed, then the set-up of each schema will be illustrated and the interaction modalities for each one will be clarified. Once the objective of the tests and where the test environment will be performed are explicit, the metrics used for the tests will be presented, and finally the test results will be shown.

5.1 Features to Analyze

As stated in the introduction of this Section, the focus will be on three features namely, feasibility, scalability and the potential benefit for the IoT6 architecture. The following defines these three features in the context of this deliverable.

5.1.1 Feasibility

The feasibility by definition is: the possibility that something can be made, done, or achieved, or is reasonable [Cambridge Dictionary]. In information technology almost everything can be included in that definition, so, we will define it in the context of the Machine-to-Machine interactions, which is the topic of this work, resulting in a slightly different definition: Feasibility is the possibility that something can be made, done, or achieved easily.

5.1.2 Scalability

For scalability, one of the definitions commonly used in information technology, which also incorporates the more generic definition found in dictionaries can be used. Scalability is the ability of a system, network, or process to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth [11]. The M2M Interaction Systems we designed and presented in this deliverable have three different phases where the scalability can play a fundamental role. These three phases are: the management of the measurements sent by devices; the interpretation and the translation of information from raw data to IoT6 Stack format; and the analysis of the rules to decide the behavior of the System. When we test the scalability, measurement combinations produced by the tests will be shown.


30

5.1.3 Potential for the IoT6 Architecture

This is an abstract feature, which is not easy to define, but we gave it the following definition: added value brought to the project without changing its underlying architecture.

5.2 Set Up

In this subsection, the deployment of the components that are part of each M2M Interaction System is shown, as well as the features of the workstations where they are installed and the communications used to interoperate.

5.2.1 Set-Up Traditional M2M Interaction System

Figure 12 shows how the components that belong to the traditional approach for M2M Interaction System were deployed. The deployment reflects the centric-approach used by usual Multi-Protocol Gateway, where all components are placed into a single Workstation.

Figure 12: Set-Up Traditional M2M Interaction System

5.2.1.1 Workstation Details

Processor: Intel Xeon CPU E31245 – 3.30 GHz

RAM: 16GB

System Type: Operating System 64-bit

5.2.1.2 Interactions Details

Devices - Gateway: Devices are implemented as software modules that simulate

measurements. They send raw data to the Gateway calling a method it provides as entry

point.

o The interaction is a method call.

Gateway - Translation Mechanism: When the Gateway wants to translate information

from raw data to IoT6 Stack (and vice versa), a thread is started and it passes the

information to that thread. Gateway and Translator are in the same memory space.

o The interaction is a synchronous request to a local thread.


31

Gateway – Control and Monitoring System: When the Gateway wants to discover if

there are some Actions to be performed in response to the measurement sent by the

device, it sends a message containing information to the Control and Monitoring System.

In the same way, if the Control and Monitoring System finds any Actions to be done, it

sends a message containing information to the Gateway. Gateway and Translator are not

in the same memory space.

o The interaction is an asynchronous exchange of messages between the Gateway and

the Control and Monitoring System.

5.2.2 Set-Up Distributed M2M Interaction System

Figure 13 shows how the components that belong to the Distributed approach for M2M Interaction System are deployed. More Workstations are used for this System, due to the fact that we want to distribute both the workload and the management of the technologies. Each Gateway will manage a different technology (Workstation 1 ZigBee devices, Workstation 2 KNX devices) and the business logic defined in the scenario is distributed among three Control and Monitoring Systems deployed in Workstation 3, 4 and 5.

Figure 13: Set-Up Distributed M2M Interaction System


32



RAM: 16GB





point.


Gateway - Translation Mechanism: When the Gateway wants to translate information

from raw data to IoT6 Stack (and vice versa), a thread is started and information is

passed to the thread. Gateway and Translator are in the same memory space.

o The interaction is a synchronous request to a local thread.





sends a message containing information to the Gateway. The difference with the

previous system is that here Gateway and Translator are not only in different memory

space, but also in different machines.


the Control and Monitoring System that is performed through Message Passing

among software placed in different machines.

5.2.3 Set-Up Web-Service M2M Interaction System

Figure 13 shows how the components that belong to the Web Service approach for M2M Interaction System were deployed. Here, in addition to the Workstations a Web Service to the System is added, in order to translate the information from raw data to IoT6 Stack format (and vice versa). As before, Workstation 1 will manage ZigBee devices whilst Workstation 2 will manage KNX devices and the business logic defined in the scenario is distributed among three Control and Monitoring Systems deployed in Workstation 3, 4 and 5.


33

Figure 14: Set-Up Web-Service M2M Interaction System



RAM: 16GB


5.2.3.2 Web Service Platform Details

Service: Amazon Cloud

Enviroment Tier: Web Server

Platoform: Tomcat

Environment Type: Load balancing, auto scaling

Instance Type: Micro instance with

Working Zone: EU (Ireland)




point.


Gateway – Web Service: When the Gateway wants to translate information from raw

data to IoT6 Stack (and vice versa) it calls an HTTP method request in the Web Service

and passes the information as request parameter. Gateway and Translator are in

different locations

o The interaction is a standard HTTP request.


34





sends a message containing information to the Gateway. Gateway and Translator are not

in the same memory space.


the Control and Monitoring System.

5.3 Test Metrics

In this subsection, the metrics used for the tests is defined. Three features are to be measured: feasibility of the System’s construction, scalability of the Systems and the positive impact that the solutions bring to the IoT6 architecture (potential benefits). Two of these features are quite abstract and difficult to measure objectively – feasibility and potential benefits – conversely, we can define an objective metric for the scalability of the System.

5.3.1 Scalability

For scalability, the time to perform two tasks in different conditions will be measured, as well as changing the number of entities that will be managed. The two tasks are as follows:

a) When the raw data is sent by a device and arrives at the Gateway and the moment when

the Gateway possess the IoT6 Stack format of information.

b) When the Gateway sends the message containing the Fact and the moment of time it

receives a message containing the Action (if found) or an empty message (if no Action is

found).

5.3.2 Feasibility

As stated previously, the definition of feasibility is that the M2M Interaction System must be created in a way that makes it as easy as possible, a questionnaire will be provided for the developers that will implement the three systems in order to obtain feedback regarding the difficulties they faced and which approach is easier to implement and why.

5.3.3 Potential Benefits

For the potential benefits, valuable metrics were not able to be found, therefore, it will not be part of the Results subsection. Consequently, only our point of view on the pros and cons of each approach regarding the IoT6 project will be made in the Evaluation Conclusions.


35

5.4 Results

In this section, the sample and the parameters used for the tests are introduced. For the Scalability, we used an analytical approach, testing the performance of the three different M2M interaction Systems under different conditions. For the Feasibility, a subjective approach providing a questionnaire for the developers in order to understand which approach had been easier to implement is used.

5.4.1 Scalability

For the Scalability, two phases were analyzed: a) The time needed to translate information from Raw Data to IoT6 Stack format.

b) The time needed to know what Action (if any) corresponds to a Fact.

Each test was performed 30 times and the reported values represent the average of the measurements.

5.4.1.1 Translation Test

In the case of information translation, there were three approaches but only two cases to test (translation within the Gateway or translation demanded to the Web Service). The reason is that in the traditional and in the Distributed M2M Interaction Systems, the translation happens within the Gateway, so the conditions and the results are the same. For the Translation test, the number of devices attached to the Gateway that send measurements at the same time are considered and the results represent the time needed to provide the translation for all measurements. The samples taken for the tests go from 10 devices sending measurements to 10,000 devices, all sending measurements at the same time.

Figure 15: Latency when the translation is performed within the Gateway

0.00

20.00

40.00

60.00

80.00

100.00

120.00

140.00

160.00

180.00

0 2000 4000 6000 8000 10000 12000

Tim

e (

ms)

Number of Devices

Max Values

Min Values


36

Figure 15 is related to the translation performed within the Gateway (Traditional approach and Distributed approach). It shows the curve that represents the relation between the number of devices that send information at the same time and the interval of time the Translator included within the Gateway needs to provide all information translated. It can be seen that the latency is almost zero when only a few devices send information and it increases when the number of devices grows, following a slightly logarithmic increasing trajectory. Another observation is that the variance in the measurements in each sample is very limited.

Figure 16: Latency when the translation is demanded to the Web Service

Figure 16 shows the curve that represents the relation between the number of devices that send information at the same time and the period of time Gateway needs to obtain all information translated when the translation is demanded from a Web Service. Unlike what Figure 15 shows, this curve also presents latency in the situation when there are just a few devices that send information. In this test, the increment when the number of devices grows has a linear trajectory. We also notice that there is a strong variance in the measurements in each sample, which we believe is provided by variance in the transferring of data via the Internet. Figure 17 embodies the two curves together and it shows us that the latency produced by the translation performed within a Gateway is more inferior than the latency produced when a Web Service is used to perform the translation. A conclusion that can be drawn is that the approach using a Web Service as translator produces latency also when the number of measurements simultaneously sent is very limited (10 at time). Moreover, if the Web Service should theoretically scale better, given its architecture (Environment Type: Load balancing, auto scaling), it performs the task following a linear trajectory rather than following the algorithmic trajectory produced by the other method of translating. It confirms our belief that the transferring time present in the Web Service dominates the translation latency time,

0.00

500.00

1000.00

1500.00

2000.00

2500.00

3000.00

3500.00

4000.00

4500.00

0 2000 4000 6000 8000 10000 12000

Tim

e (

ms)

Number of Devices

Max Values

Min Values


37

nullifying the eventual benefits introduced by the Web Service features.

Figure 17: Traditional and Web Service Approaches Latency curves superimposed

0.00

500.00

1000.00

1500.00

2000.00

2500.00

3000.00

3500.00

4000.00

4500.00

0 2000 4000 6000 8000 10000 12000

Tim

e (

ms)

Number of Devices

Web ServiceLatency

Gateway Latency


38

5.4.1.2 Business Logic Exploration Test

The second scalability test performed concerns how the M2M Interaction System scales when the number of rules that defines the business logic grows. To have a larger performance system, a data structure loaded in memory is used rather than a data base approach. This approach will have a slower initialization phase to store all rules in memory, but when all the logic is in memory, it will be faster and it will not depend on the performance of the underlying data container. Since we have only two cases to test as mentioned previously: the traditional model of having all logic managed by a single Control and Monitoring System; and the distributed model proposed for the Distributed and Web Service approach, where the logic is distributed among various Control and Monitoring Systems (in our case we have tested with three CMS), there is a structural difference beyond the distribution of the logic. In the traditional model, the Control and Monitoring System is placed in the same machine as the Multi-Protocol Gateway. They are fully independent from one another and this implies they are in different memory spaces with the consequences of using message passing as a communication paradigm. But, they are still in the same workstation, so no network communications are needed. Instead, in the distributed model, the Multi-Protocol Gateway is placed in a workstation, and the Control and Monitoring Systems are placed in three different workstations. This implies that the communications have to cross not only the memory boundaries, but also the workstation boundaries. As a consequence, the communications will also be performed via message passing, but this time the messages will flow through the network. An important clarification is that we assume the logic is managed in a local area, such as a LAN24, so the communication will not pass through the Internet. The two models have been tested under the following conditions:

5 test series were performed where the knowledge base that defined the logic of the

scenario contained 10, 100, 1000, 10000, 100000 of Rules;

For every test series, eleven samples (from 10 until 10000) were defined, which

represented the number of Facts a Multi-Protocol Gateway sends at the same time;

30 measurements for every sample were taken and the curve reports their average

value.

The test measures the interval of time from when a Gateway sends all Facts together until it receives all the answers from the Control and Monitoring System(s). The answer can be an Action if the Fact matched the Trigger of a Rule, or an empty answer if no match was found. We recall that in the case when more Control and Monitoring Systems manage the distributed logic, a Fact will always be sent to all Control and Monitoring Systems. Figure 18 shows the five curves representing the 5 test series when a single Control and Monitoring System (traditional model) is used. It When 4 out of the 5 curves where the knowledge base is composed from 10 until 10000 Rules, behave likewise. They grow linearly until the gateway sends less than 7500 Facts at time, but after that threshold, there is an

24 http://en.wikipedia.org/wiki/Local_area_network


39

exponential growth. It means that when the number of working threads used for the exploration of Rules matching the Facts reaches the physical limits, the performances begins to deteriorate. The other curve behaves differently, it seems to miss the change of the trajectory from linear to exponential and we have no explanation what makes this behavioral difference.

Figure 18: All Knowledge contained in one CMS placed in the same Workstation of the Gateway

Figure 19 shows the 5 curves representing the 5 test series when three Control and Monitoring Systems (Distributed model) are used. The measurements seem random (with curves that overlap) in the beginning - until the numbers of Facts sent at the same time -reaches 1500 entity at time. Afterwards, the curves begin to have more regular trajectories, but they still remain difficult to interpret.

0

20

40

60

80

100

120

0 2000 4000 6000 8000 10000 12000

Tim

e (

ms)

Number of Facts

10 Rules

100 Rules

1000 Rules

10000 Rules

100000 Rules


40

Figure 19: Knowledge Distributed among CMS placed in different Workstations

To help us better understand the trajectories, Figure 20 shows the polynomial interpolation of the curves illustrated by Figures 18 and 19. The interpolations demonstrate that the trend of the curves is the same for the two tests. There is always an increment that tends to become exponential when the physical limits imposed by the workstation architecture are reached. However, the distribution of the knowledge brings a reduction in the performance decay with a factory similar to 1 divided n° of CMS.

Figure 20: Polynomial Interpolation of the Scalability Knowledge Base Scalability Results

0

10

20

30

40

50

60

0 2000 4000 6000 8000 10000 12000

Tim

e (

ms)

Number of Facts

10 Rules

100 Rules

1000 Rules

10000 Rules

100000 Rules

0

20

40

60

80

100

120

140

0 5000 10000 15000

All Knowledge contained within one CMS

0

20

40

60

80

100

120

140

0 5000 10000 15000

Knowledge distributed among CMS


41

5.4.2 Feasibility

To evaluate the Feasibility, or as we defined before the Easiness of creating the different M2M Interactions Systems, a test was submitted to all of the developers that worked on the Systems prototypes. The Developers had to answer with a number between 0 and 5, as defined below:

0 = No effort

1 = Very Easy

2 = Easy

3 = Slightly Difficult

4 = Difficult

5 = Very Difficult

The test contained four questions that we believe are fundamental to evaluate the difficulties developers can find when they decide to implement M2M Interaction Systems. After the developers answered the questions, an oral session was held in order to understand the reasons for their answers and what obstacles were more challenging to surmount. In the project design and implementation, we included Bachelor students who in the beginning of the work, had existing knowledge of language programming, but did not have knowledge of Building Automation Systems, Distributed Programming nor Web Service. This was to ensure the coherence of the tests.

Developer 1 Developer 2 Developer 3 Developer 4

How difficult was learning a Building Automation Technology?

4 5 3 5

Once a technology is assimilated, how difficult is to manage new devices belonging to it?

2 3 2 2

How difficult was learning how to implement in Distributed Environment?

3 3 3 3

How difficult was learning how to implement using Web Services?

2 3 2 3

Table 1: Questionnaire about Easiness

Table 1 shows the answers provided by the developers and shows that to learn new Building Automation Technology was the most challenging task they dealt with. However, when a technology is assimilated, it becomes easier to learn how to manage new devices belonging to that technology. The Distributed Programming had some difficult issues in the beginning, but considering the amount of online documentations, tutorials and books about the topic, they said that they could understand quite quickly how it works and how to implement it.


42

6 Evaluation

In this section, the results of the tests performed in Section 5 are evaluated and a choice of approach is suggested for implementing the M2M Interaction Model, with the corresponding motivation.

6.1 Scalability

In Section 5, two different scalability situations were tested: the translation of raw data into the IoT6 Stack format (and vice versa), and the exploration of the knowledge base containing the rules to check the matches between Facts and Rules which decide the behavior of the system.

The first set of tests, related to the translation, suggest that since this task seems quite straightforward and is performed quickly, a Gateway can greatly satisfy the scalability issue for what concerns the translation task. So there is no need to use a Web Service for the translation which would bring a considerable delay caused by the networking.

For the exploration of the knowledge base, this task does involve examining a data structure completely before sending a complete answer – a Fact can trigger more Rules – resulting in a difficult and time consuming task. This leads to the deduction that performing more of these tasks in parallel can bring the consumption of all resources in a workstation. The limits of the tasks that can be performed at the same time depend on the features of the workstations. For our workstation, it seems that the threshold, when the performance starts to really have degradation, is 7000 Facts sent to be elaborated. The same situation happens no matter how many Rules the knowledge base contains, and it is noted by the trajectories of the different curves illustrated in Figures 18, 19, and 20.

The conclusion is that if the knowledge is distributed among more Control and Monitoring Systems, the M2M Interaction Systems is allowed to keep the latency curves lower.

6.2 Feasibility

The evaluation of the feasibility depends upon the answers the developers provided during the questionnaire and the subsequent interview regarding their feedback.

The developers expressed difficulty in learning how Building Automations Systems functions, due to each having different features and that it was based on different stacks that make it even more difficult to master properly. The main reason for their concerns is due to a lack of how to do tutorials, which allows developers to fully study the protocols in order to understand how they can be managed.

During the implementation, the developers tried to use third party software libraries that already managed the protocols and making it easier to integrate various technologies together.

Regarding the Distributed Programming, the developers found difficulties at the beginning of the work, but once they understood the paradigms and patterns on which it is based, the work became much easier.


43

7 Conclusions

The following conclusions have been drawn after analyzing the test results based on the defined parameters for the evaluations: To group all Building Automation Technologies, or a big subset of them, under a unique Multi-Protocol Gateway can be very challenging and requires developers to invest a lot of time and effort to master them properly. So, the best solution is to combine solutions provided from experts in the domain, such as the XBee API 25 and integrate it within the M2M Interaction Systems. The M2M Interaction Systems we have tested demonstrate that the translation from raw data into a shared Semantics (in the context of the IoT6 project – the IoT6 Stack format) does not imply scalability issues. The reason is that the task is so fast that the amount of measurements that could arrive at the same time can be well managed. The scalability problem can arise in the exploration of the knowledge base that the M2M Interaction System needs to control the logic for the scenario. This depends on the fact that the knowledge base is a more time-consuming task and if a high parallel computation is required, it could lead to a depletion of the available resources. For this reason we suggest distributing the logic of the scenario among multiple Control and Monitoring Systems in the same local network so as not to incur a big delay introduced by the external networking. For the project IoT6, the best solution is the Distributed Approach integrating different Gateway solutions for building easier and more scalable M2M interaction systems. This can bring large benefits to focus more on the aim of making the Internet of Things globally accessible using the IPv6 and by allowing it to perform more and more sophisticated scenarios. We believe that following these guidelines in this deliverable, the management of more sophisticated scenarios can be allowed, such as complex real-time scenarios, which currently are considered very challenging in the Internet of Things domain.

25 https://code.google.com/p/xbee-api/


44

8 Bibliography

[1] D. S. Watson, M. A. Piette, O. Sezgen and M. Naoya, "Machine to Machine (M2M) Technology in Demand Responsive Commercial Buildings," ACEEE Summer Study on Energy Efficiency in Buildings, 2004.

[2] G. Wu, S. Talwar, K. Johnsson, N. Himayat and K. Johnson, "M2M: From mobile to embedded internet," Communications Magazine, vol. 49, no. 4, pp. 36 - 43, April 2011.

[3] J. Carretero and D. J. Garcia, "The Internet of Things: connecting the world," Personal and Ubiquitous Computing, vol. 18, no. 2, pp. 445-447, 2014.

[4] J. Latvakoski, H. Ganem, B. Juben, A. Iivari, J. Leguay, J. M. Bosch and N. Granqvist, "Towards Horizontal Architecture for Autonomic M2M Service Network," Future Internet, vol. 6, no. 2, pp. 261 - 301, 2014.

[5] "Protocol Converter," [Online]. Available: http://en.wikipedia.org/wiki/Protocol_converter.

[6] "oBIX Version 1.1 Working Draft 06," 08 06 2010. [Online]. Available: https://www.oasis-open.org/committees/download.php/38212/oBIX-1-1-spec-wd06.pdf.

[7] U. o. Kentucky, "Monitoring and Control," in Scenarios Interactions, Kentucky (Unbricoled Spirit).

[8] E. B. Johnsen and O. Owe, "An Asynchronous Communication Model for Distributed Concurrent Objects," Software & Systems Modeling, vol. 6, no. 1, pp. 39 - 58, 01 03 2007.

[9] G. Rizzo, A. C. Olivieri, Y. Bocchi and F. Morard, "Multi-Protocol Architecture and System Development Report," 2013.

[10] G. R. Lavender and D. C. Schmidt, "Active Object: An Object Behavioral Pattern for Concurrent Programming," in Pattern Languages of Program Design 2, J. M. a. C. J. O. a. K. N. L. Vlissides, Ed., Boston, MA: Addison-Wesley Longman Publishing Co., Inc., 1996, pp. 483--499.

[11] A. B. Bondi, "Characteristics of scalability and their impact on performance.," in 2nd international workshop on Software and performance (WOSP '00), New York, 2000.

Universal Integration of the Internet of Things through an IPv6- … - D4.4.pdf · 2021. 3. 2. ·...

Documents

Transcript of Universal Integration of the Internet of Things through an IPv6- … - D4.4.pdf · 2021. 3. 2. ·...