Researching crowdsourcing to extend IoT testbed infrastructure for multidisciplinary experiments, with more end-user interactions, flexibility, scalability, cost efficiency and

societal added value

Grant agreement for: Collaborative project

Grant agreement no.: 610477

Start date of project: October 1st, 2013 (36 months duration)

D3.1 Open Interfaces

Contract Due Date 1st October 2016

Submission Date 1st July 2014 (M9)

Version 2 (10-06-2014)

Responsible Partner UNIGE

Author List Constantinos Marios Angelopoulos, Orestis Evangelatos, Ali Fakheri, José Rolim, Konstantinos Veroutis,

Dissemination level PU

Keywords APIs, interconnection, virtualisation

1. Table of Contents 1. Table of Contents ..................................................................................................... 2

2. Executive Summary ................................................................................................. 4

3. Introduction .............................................................................................................. 5

IoT Lab Objectives ....................................................................................................... 5

Work Package 3 Objectives ......................................................................................... 6

Task 3.1: “Open Interfaces” ......................................................................................... 6

4. IoT Lab Virtualisation Architecture ............................................................................ 7

5. Virtualisation of IoT Resources .............................................................................. 10

Interconnection at the Networking Layer ................................................................... 10

Interconnection at the Transport/Application Layers .................................................. 11

Representing Testbed Resources .............................................................................. 13

IoT Lab Cloud – Testbed Facilities Communication ................................................... 15

Experimental Data Exchange Between the IoT Lab Cloud and Testbeds .................. 16

6. Virtualisation of Crowdsourced Resources ............................................................ 21

Architectural Styles of Interfaces ............................................................................... 21

Custom API for Crowdsourced Resources ................................................................ 24

API for Privacy and Trust ........................................................................................... 26

7. Services of the IoT Lab Experimentation Platform ................................................. 30

Discovery, reservation, provisioning .......................................................................... 32

Experiment control ..................................................................................................... 33

Measuring and monitoring ......................................................................................... 34

Security ...................................................................................................................... 35

8. Conclusions ........................................................................................................... 36

APPENDIX A: Standards, RFCs, Specifications ........................................................... 37

APPENDIX B: Installation Guidelines for OML Client .................................................... 43

TABLE OF FIGURES FIGURE 1: THE FIRST PROPOSED IOT LAB VIRTUALISATION ARCHITECTURE. EACH INDIVIDUAL TESTBED IS SEMI-

AUTONOMOUSLY VIRTUALISED. THE IOT LAB CLOUD INFRASTRUCTURE MANAGES EACH DISTINCT FACILITY

INDEPENDENTLY. .......................................................................................................................... 7 FIGURE 2: THE SECOND PROPOSED IOT LAB VIRTUALISATION ARCHITECTURE. ALL INDIVIDUAL EXPERIMENTAL

FACILITIES ARE DEEPLY INTEGRATED INTO AN IOT LAB “META-TESTBED”. INFORMATION REGARDING THE VARIOUS

RESOURCES (E.G. A RESOURCE DIRECTORY) ARE CENTRALLY MAINTAINED IN THE IOT LAB CLOUD. ................. 8 FIGURE 3: GENERAL IOT LAB ARCHITECTURE SCHEME. ................................................................................. 9 FIGURE 4: THE OML FRAMEWORK ........................................................................................................ 19 FIGURE 5: OML CLIENT USING DYNAMIC LIBRARY .................................................................................... 20 FIGURE 6: OVERVIEW OF THE PRIVACY-ABC ARCHITECTURE ON THE USER SIDE ............................................. 26 FIGURE 7: A HIGH-LEVEL OVERVIEW OF THE FED4FIRE ARCHITECTURE. COLOURS ARE USED TO INDICATE THE

DIFFERENT LAYERS EACH COMPONENT BELONGS TO. ARROWS DEMONSTRATE INTERACTIONS ...................... 31 FIGURE 8: THE LIFE-CYCLE OF AN EXPERIMENT ACCORDING TO FED4FIRE ARCHITECTURE ................................. 32

4

2. Executive Summary

This report is part of the IoT Lab research project. First, the architecture of the IoT Lab Experimentation Platform is reviewed. The two proposed virtualisation architectures are presented and analysed. The virtualisation process and the corresponding open interfaces are presented following a three tier tessellation. First, the virtualisation process of IoT resources of individual testbed facilities and the corresponding interfaces are discussed. The process includes interconnection at a networking, transport and application layer, uniform representation and description of testbed resources as well as communication among the testbed facilities and the IoT Lab Cloud server. Then, we discuss the virtualisation process and the interfaces to be utilised by crowdsourced resources; i.e. devices such as smartphones and other smart gadgets provided by the general public in order to be used in experiments. Finally, we discuss the services that will be provided by the IoT Lab Experimentation Platform and the interfaces via which they will be exposed to the experimenters.

5

3. Introduction

IoT Lab Objectives

The IoT Lab is a research project exploring the potential of crowdsourcing to extend IoT testbed infrastructure for multidisciplinary experiments with more end-user interactions. It will research and develop:

1. Crowdsourcing mechanisms and tools enabling testbeds to use third parties resources (such as mobile phones), and to interact with distributed users (the crowd). The crowdsourcing enablers will be developed through end-user interactions and will address topics such as privacy by design, identity management, security, reputation mechanisms, and data ownership, addressing end-user and societal acceptance.

2. Virtualization of crowdsourcing and testbed components by using a meta-layer with an open interface, facilitating the integration and interaction with heterogeneous components, including physical, mobile and virtual ones. The architecture should ease the data integration and reduce the cost of deployment in real environment.

3. Ubiquitous Interconnection and Cloudification of the testbeds resources. It will research the potential of IPv6 and network virtualization to interconnect heterogeneous and distributed resources through a Virtual IoT Network and will integrate them into the Cloud to provide an on-line platform of Testbed as a Service (TBaaS) with user-driven functionalities and interfaces.

4. End-user and societal value creation by analysing the potential end-users and crowdsourcing participants, including: large industries, SMEs, public administrations, universities, students, NGOs and citizens. It will research their interests, drivers and barriers to adoption in order to propose an optimized model for end-user adoption and societal value creation.

5. “Crowdsourcing-driven research” as a new model in which the research can be initiated, guided and assessed by the crowd. It will compare it to other models.

6. Economic dimension of crowdsourcing testbed, by analysing the potential markets and business models able to monetize the provided resources with adequate incentives, in order to optimize the exploitation, costs, profitability and economic sustainability of such testbeds. It will also develop tools for future experiments.

7. Performing multidisciplinary experiments, including end-user driven experiments through crowdsourcing, to assess the added value of such approach.

IoT Lab will extend the capacities of the participating testbeds and will provide a Testbed as a Service platform available to the research community. It will promote its platform through the research community, social networks and forums such as the ITU. To achieve these ambitious goals, the consortium consists of 7 international academic and research partners and one SME bringing complementary expertises and several FIRE-related research infrastructures: CTI (WISBED, Hobnet), University of Geneva (WISEBED and Hobnet), Mandat International (Hobnet and EAR-IT) and the University of Surrey (Smart Santanders).

6

Work Package 3 Objectives

Work Package 3 “Virtualization and Mobility” WP3 addresses two key research topics: - The virtualization of the various testbed components (including crowdsourcing) to

be integrated into the IoT lab platform - The mobility and portability of those resources

The virtualization constitutes the cornerstone for the integration of heterogeneous components from different classes of IoT test-beds, including: existing FIRE testbeds, crowdsourced resources, portable testbeds, resource management, workflow scheduling and modelled resources.

WP3 will focus on delivering the specifications required to design systems that can be used with IoT systems in different areas. The different tasks will define guidelines that will enable the design and implementation of a coherent system by utilizing crowdsourcing, together with fixed, portable and modelled test-beds. It will enable the targeted components integration and cloudification to be performed by WP4. More generally, WP3 will work in close cooperation with WP2 and WP4.

Task 3.1: “Open Interfaces”

Task 3.1 investigates, analyses and proposes the common open interfaces to be used in the context of the IoT Lab for interconnecting testbed components and exchanging data. The open interfaces are provisioned to enable easy and seamless data transfer between virtualized resources and the central IoT Lab infrastructure via an abstraction layer. Several open interfaces are utilized for abstracting different physical testbed architectures while taking into account aspects like user and data privacy and security. Several other aspects are also considered, like differences in physical capabilities and characteristics of resource components. The open interfaces proposed in the context of this task are in the form of APIs, standards, specifications and RFCs. They constitute a provision and therefore may evolve as the research and development activities of the IoT Lab progress. For this reason, this task also reviews and provides a listing of already existing and emerging solutions provided by several standardization organisations.

7

4. IoT Lab Virtualisation Architecture IoT Lab virtualisation architecture refers to the ways the various resources that are scattered across several testbed facilities will be interconnected, organised and abstracted into a single, uniformly managed meta-testbed. The definition of this architecture is a pre-requisite for the definition of the open interfaces to be later used, as it will both identify and specify the ways the various components will communicate and exchange information with each other. The architecture will also specify the procedures via which an experimenter will interact with the IoT Lab platform (resource provisioning, experiment definition, authentication, etc), as well as the corresponding APIs.

Initially, two distinct virtualization architectures were investigated and proposed for the IoT Lab Experimentation Platform. Although their technical differences are subtle (meaning that in terms of implementation either one could be used with minimal adaptations), their semantics are quite different.

Figure 1: The first proposed IoT Lab virtualisation architecture. Each individual testbed is semi-autonomously virtualised. The IoT Lab Cloud infrastructure manages each distinct facility independently.

At a high, intuitive level, the first architecture for the virtualisation and integration process would result in a set of homogeneously virtualized, however distinct experimental facilities that would be able to be uniformly accessed and used over a common set of open interfaces. In the context of the IoT Lab the common point of reference for all these facilities would be the IoT Lab Cloud, which would provide the means to external experimenters to utilise their services while hiding the technical details of the testbed interconnection. This architecture had the advantage of enabling

8

each testbed provider to maintain a certain degree of autonomy. For instance, each individual testbed would be able to interconnect with other Fed4FIRE facilities (such as PlanetLab) independently of the IoT Lab Cloud. Figure 1 depicts this first architecture.

However, it has been the decision of the consortium to finally come up with a unique experimentation facility consisting of interconnected (even at a low, networking layer) experimental resources, rather than with a set of commonly managed yet still distinct testbeds. In this context, a second virtualization architecture was proposed that will result in having all the individual experimental facilities lying under an IoT Lab “umbrella” where information on the available resources are centrally maintained, thus forming a “meta-testbed”. This “umbrella” will expose a single Fed4FIRE-compliant point of access to the outside world. This architecture, although it might be a more centralised one, is more agile in the sense that it will enable us to come up with IoT Lab custom made solutions specifically designed to efficiently address particularities related to the IoT and crowdsourced nature of the IoT Lab Experimentation Platform. As an example, consider an IPv6 tunnelling broker service running at the IoT Lab cloud. Since all testbeds would lie under the same “umbrella”, a common addressing scheme could be utilized since the testbed integration will be taking place at a lower layer than that of Fed4FIRE. As a second example, one central Resource Directory could be maintained at the IoT Lab cloud (thus having global knowledge over all available resources) instead of having to probe the Resource Directory of each individual testbed every time resource provisioning is needed for an experiment. This second architecture is depicted in Figure 2.

Figure 2: The second proposed IoT Lab virtualisation architecture. All individual experimental facilities are deeply integrated into an IoT Lab “meta-testbed”. Information regarding the various resources (e.g. a Resource Directory)

are centrally maintained in the IoT Lab Cloud.

9

In the context of Work Package 1: “Requirements and Architecture design” other aspects of the IoT Lab architecture have been analysed and identified. Initial requirements for both functional and non-functional platform features imply four groups: account manager, experiment manager, resource manager and web user interfaces, with each group being responsible for different processes during the life-cycle of an experiment; user interaction and authentication, trust and privacy issues, maintaining a Resource Directory, setting up and running an experiment and so on. Figure 3 depicts the general IoT Lab architecture scheme that has been adopted.

Figure 3: General IoT Lab architecture scheme.

10

5. Virtualisation of IoT Resources In this section we address the open interfaces to be used for the interconnection of IoT resources among different testbed facilities, as well as with the IoT Lab Cloud. We note that it is not in the scope of this document how individual resources are connected to form a particular testbed facility (e.g. the routing algorithms used by a testbed to form a Wireless Sensor Network consisting of sensor motes), rather than how different testbeds can expose their available resources to each other and to the IoT Lab Cloud in a homogeneous and transparent way.

Interconnection at the Networking Layer

The adopted IoT Lab architecture provisions that a set of already existing testbed facilities will be integrated into a unique “meta-testbed” facility that will provide services to end-users in a way that will hide the underlying heterogeneity and each individual testbed in terms of spatial distribution, supported technologies, architectures and provided services. Such a “meta-testbed” will levitate the burden from an end-user to be both aware of and to tackle with the particularities of each testbed and the corresponding technical issues. Apart from important managerial gains, this way the IoT Lab platform will also be more easy to use and thus more attractive to a much broader set of experimenters.

In order to achieve the desired increased level of integration, the interconnection of the individual testbeds as well as their resources should begin from a lower, networking layer. For this layer, the following two facts should be taken into consideration a) the main focus of the IoT Lab platform will be on facilities used to evaluate protocols and use-cases for the Internet of Things and b) that the IoT Lab platform will also incorporate truly portable, mobile devices such as smartphones, tablets and other smart gadgets (e.g., smart watches and glasses). For these reasons, for the interconnection at the networking layer the IoT Lab is going to heavily utilise the next generation of the Internet Protocol; a.k.a. IPv6.

The use of IPv6 demonstrates several advantages both in terms of facility management and operational efficiency. It constitutes a simple, straight forward solution that provides and guarantees interoperability across diverse and heterogeneous systems via its support for multiple PHYs (Ethernet, Wi-Fi, Bluetooth, IEEE802.15.4, etc). Furthermore, IPv6 enables end-to-end connectivity with no need for further development of additional mechanisms such as Network Address Translation (NAT). The vast address space provided contributes towards system scalability since most IoT and portable devices natively support IPv6. Significant contribution is also made at the security level via inbuilt mechanisms, like IPsec, and more advanced techniques. As an example we mention the use of the huge IPv6 address space for completely new privacy mechanisms like changing dynamic IP addresses, which are public-private-key encrypted, between two peers.

Each testbed facility to be integrated with the IoT Lab platform has to be able to support an IPv6 interface as a means of communication with the IoT Lab Cloud and other

11

testbed facilities. For testbed facilities that do not have the ability to support global IPv6 networking (e.g., because their ISP lacks the necessary infrastructure), Mandat International has set-up an IPv6-over-IPv4 tunnelling service to be used (this has actually been the case for the testbed facilities of CTI and UNIS).

Although this is a requirement for the testbed communication with the outside world, testbed managers are also advised to support IPv6 connectivity internally in their facilities; i.e. at the level of individual testbed resources (e.g. IPv6-enabled sensor motes). As the corresponding details may be testbed-dependent (and are also outside of the scope of this document), a proposed and commonly used set-up would be each individual resource to operate on either TinyOS or Contiki OS that provide IPv6 support for Low power and Lossy networks by utilising the 6LoWPAN adaptation protocol (IETF RFC6282). An alternative set-up (e.g., in case the resources do not support IPv6 by design) could consist of a mapping mechanism that would map IPv6 addresses or IPv4 ports to testbed specific function calls, handling the interaction with the resources.

Interconnection at the Transport/Application Layers

At a higher layer, the various IoT resources located at each testbed facility should be able to communicate and interact with each other at an application layer regardless of the testbed they belong to. The two well established and most commonly used protocols designed particularly to address the nature of IoT resources, such as sensor motes, are the Constrained Application Protocol (CoAP)1 by IETF and the Message Queuing Telemetry Transport (MQTT)2 by OASIS. CoAP operates over UDP while MQTT assumes an underlying TCP connection. Following is a description of the two protocols and a comparison between the two.

The Constrained Application Protocol.

CoAP is a software protocol which has been designed for use between small and constrained electronic devices that allows them to communicate between themselves in the same constrained networks and between devices in other networks interactively over the Internet. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. Those requirements are very important and crucial in the design and operation of IoT enabled devices and networks due to constrains characterising them in energy, memory, power supply and processing performance of the embedded devices operating in such environments.

CoAP can run on most devices that support UDP, binding with optional reliability supporting unicast and multicast requests. However, it may also be used over Datagram Transport Layer Security (DTLS) and other transports such as SMS, TCP or SCTP. It

1 https://datatracker.ietf.org/doc/draft-ietf-core-coap/

2 http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html

12

provides as well, a stateless HTTP mapping, allowing proxies to be build providing access to CoAP resources via HTTP in a uniform way or for HTTP simple interfaces to be realized alternatively over CoAP. The interaction model of CoAP is similar to the client/server model of HTTP. However, Machine-to-Machine interactions typically result in a CoAP implementation acting in both client and server roles. CoAP makes use of GET, PUT, POST and DELETE methods in a similar manner to HTTP. Methods beyond the basic four can be added to CoAP in separate specifications.

Currently, the latest CoAP draft version is CoAP-18 that is in the final stages of processing for being included in the Internet Standards documents. The CORE (Constrained RESTful Environments) working group of IETF (Internet Engineering Task Force) is the standardization body behind the conception, design and leading of the CoAP.

The Message Queuing Telemetry Transport Protocol.

MQTT is a lightweight broker-based publish/subscribe protocol flowing over TCP/IP for remote sensors and control devices through low bandwidth, unreliable or intermittent communications. Its characteristics make the MQTT protocol suitable for networks that are expensive, have low bandwidth or are unreliable. The protocol provides a publish/subscribe message pattern to enable one-to-many message distribution and decoupling of applications. The messaging transport is agnostic to the content of the payload and it provides three qualities of service for message delivery; “At most once”, where messages are delivered according to the best efforts of the underlying TCP/IP network; “At least once”, where messages are assured to arrive but duplicates may occur and the “Exactly once”, where messages are assured to arrive exactly once.

MQTT has a client/server model, where every sensor in the network running the protocol is a client and can connect to a server which is known as a broker. The connection of the client with the server is being held over TCP. The MQTT is message oriented as described above and every message is a discreet chunk of data, opaque to the broker. Every message is published to an address, known as topic. Clients may subscribe to multiple topics and every client subscribed to a topic receives every message published to the topic.

Currently, the latest version is MQTT v3.1 and it has been submitted to the OASIS specification body and is in the standardization process.

CoAP-MQTT Comparison.

Both CoAP and MQTT are two of the most promising standard protocols for the IoT vision specifically designed for small and constrained devices. Common characteristics of both of them are:

Open standards

Better suited to constrained environments than HTTP

Providing mechanisms for asynchronous communication

Running on IP

Designed for a broad range of implementations

13

Flexible and scalable.

However, despite their similarities in the way they relay messages and data over constrained networks, they are characterised by fundamental differences. MQTT is a protocol designed for many-to-many communication which allows messages to be passed between multiple clients through a central broker. It decouples producer and consumer by letting clients publish and having the broker decide where to route and copy messages. While MQTT has some support for persistence, it does best as a communications bus for live data. On the other hand, CoAP is primarily a one-to-one protocol for transferring state information between client and server. While it has support for observing resources, CoAP is best suited to a state transfer model.

MQTT provides no support for labelling messages with types or other metadata to help clients understand it. MQTT messages can be used for any purpose, but all clients must know the message formats up-front to allow communication. CoAP, conversely, provides inbuilt support for content negotiation and discovery allowing devices to probe each other to find ways of exchanging data.

MQTT clients make a long-lived outgoing TCP connection to a broker. This usually presents no problem for devices behind NAT. CoAP clients and servers both send and receive UDP packets. In NAT environments, tunnelling or port forwarding can be used to allow CoAP, or devices may first initiate a connection to the head-end as in LWM2M.

In a nutshell we would say that the fundamental difference between MQTT and CoAP is that the first one is a messaging-oriented protocol whereas the latter one is web-services oriented.

In the IoT Lab project the focus and the characteristics of the IoT testbeds are more complex than just a simple messaging transport scheme. Their functionality goes far beyond a mechanism which just reports data to a server. Several nodes either working as sensors or as actuators need to communicate with each other and servers for reporting their data, propagating the data from other nodes in their neighbourhood, reply to server demands, etc. The complexity of the applications that the IoT Lab is aiming at, can be easily supported by the CoAP protocol. The nature of the IoT Lab via its crowdsourcing mechanisms is focusing on a scheme in which the information from and to the users will be facilitated over internet connection. Concluding, the CoAP is perhaps the best candidate for our specification design, architecture and suits better to the IoT Lab applications. However, this does not exclude the use of MQTT by the IoT testbed facilities, if it is better suited to some of the applications to be developed.

Representing Testbed Resources

The IoT Lab infrastructure will interconnect heterogeneous resources by integrating several distinct testbed facilities, following different architectures focusing on different application areas. This means that the IoT Lab platform will have to be able to communicate and interact with a highly diverse set of experimental resources ranging from computationally strong server units to highly constrained sensor motes, from fixed experimental infrastructure (e.g. for smart home automations) to highly mobile

14

smartphones and from totally controlled experimental facilities to crowdsourced resources whose operation is heavily affected by third-party, unknown to the experimenter factors (e.g. level of commitment of a smartphone owner). Apart from these diversity aspects, we also have to take into consideration commonly raised issues such as interoperability and compatibility among different platforms. In order for the integration to be successful, the various experimental resources being available across the integrated testbeds need to be represented in a uniform manner, a common virtualization scheme that will allow interoperability among multiple control frameworks and aggregates via a common language for describing resources, resource requests and reservations. IoT Lab will adopt the Resource Specification (RSpec) schemas that are standardized on XML documents by GENI3. GENI RSpec schemas are now in the

geni.net namespace, currently using version 3 4.

RSpecs are just XML documents in a prescribed format defining three actions that take place among an experimenter, an individual testbed facility and the IoT Lab cloud. This mechanism has three distinct purposes and therefore RSpecs are divided into three different, closely-related languages in order to address each of these purposes in particular.

Advertisements are used to describe the resources available on a testbed facility. They contain information used by the IoT Lab Cloud in order to properly describe, classify and access the resources. Other kinds of information (MAC addresses, hostnames, etc.) which are not used to select resources should not be in the Advertisement.

Requests specify which resources are provisioned by the IoT Lab Cloud. They contain a (perhaps incomplete) mapping between physical components and abstract experimental resources (nodes, links, senor motes, etc.)

Manifests provide useful informations about the experimental resources that are actually allocated in a testbed by the IoT Lab Cloud for the purposes of an experiment. This involves information that may not be known until the actual resource reservation is performed (i.e. dynamically assigned IP addresses, hostnames) or additional configuration options.

Initially an experimenter requests for a particular set of resources with specific characteristics via an RSpec request. The platform will respond with an RSpec manifest that describes the available resources that are allocated to the experimenter. The manifest contains vital information on these resources that the experimenter needs to know in order to provision her experiment such as the names and IP addresses of compute resources (e.g. virtual machines), user accounts created on the resources, communication protocols supported by the resources (e.g. a smartphone may support HTTP while a sensor mote may require CoAP) and the permitted actions (e.g. some testbed facilities may support over-the-air programming while others may not). There is

3 Geni.net

4 http://www.geni.net/resources/rspec/3

15

a third type of RSpec called an advertisement RSpec. This is the RSpec returned by the testbed facility when the available resources on the testbed need to be listed and described.

The current version of RSpecs, utilised by other research projects such as GENI and Fed4FIRE, mainly focus on describing testbed facilities of computer networks typically consisting of few servers and some network level devices such as routers and switches. Therefore, RSpecs at their current form focus on describing the capabilities of servers (e.g. computational power and number of connections they can support) and the links connecting them (e.g. type of connection and bandwidth). This way RSpecs did not constitute an efficient way of describing IoT testbeds where the emphasis is on the diversity of resources and their interconnection with ambient conditions (e.g. temperature), human activity (e.g. human presence or motion) and actuators (e.g. light control and HVAC systems).

In order to adapt the RSpec functionality to the purposes of the IoT Lab we have greatly extended them to also include the description of IoT resources by incorporating into them the IPSO Application Framework5. The IPSO Application Framework makes use of IETF standards as building blocks for a simple and efficient RESTful design model for IP smart objects. The framework may be used over either HTTP or CoAP web transfer protocols and makes use of IETF standards as building blocks for a simple and efficient RESTful design model for IP smart objects. The new .XSD schemas can be found at http://tcs.unige.ch/lib/exe/fetch.php/user/ipsorspecs.tar along with sample .xml testbed descriptions and human readable visualisations. On Table 1 is a snipset of an extended RSpec advertisement listing the available resources of a smart building testbed; 4 indoor light arrays and one electric curtain.

IoT Lab Cloud – Testbed Facilities Communication

For the communication between the Testbeds facilities and the IoT Lab Cloud the following RESTful API will be implemented.

GET /testbed

Returns the participating test-beds and their id’s in XML format.

GET /resources

Returns the resources of the test-bed in XML format.

Parameters:

testbedId (optional) Returns the resources from the test-bed with the particular id. If omitted all the resources will be returned.

5 http://www.ipso-alliance.org/wp-content/media/draft-ipso-app-framework-04.pdf

16

PUT /resources

If it does not exist the server stores the XML file that contains the resources from the test-bed with the particular authentication token. Otherwise it updates the existing entry in the database.

authentication_token

(required) The authentication key that is used to validate the test-bed initiating the request.

resources The xml data describing the resources of the test-bed. The xml data must be validated.

POST /resources

The server stores the xml file that contains the resources from the test-bed with the particular authentication token.

authentication_token (required) The authentication key that is used to validate the test-bed initiating the request.

resources The xml data describing the resources of the test-bed. The xml data must be validated.

DELETE /resources

Deletes all the resources corresponding to the test-bed with the particular authentication_token.

authentication_token (required) The authentication key that is used to validate the test-bed initiating the request.

Experimental Data Exchange Between the IoT Lab Cloud and Testbeds

The next layer of integration refers to a uniform mechanism for transmitting

experimental data from individual testbeds to the IoT Lab Cloud. A well supported

mechanism that is commonly used for this purpose in spatially distributed experimental

facilities (such as in Fed4FIRE or GENI tesbeds) is the OML6.

The ORBIT Measurement Library (OML) is a distributed software framework which enables the collection of data in real-time in large distributed environments. OML provides a flexible and dynamic way in which data is collected and made available for real-time access to the experimenters of a testbed facility. One of the key factors for the success of a multiuser distributed testbed depends largely on the ease of use, remote access and the ease of collecting and sharing the measurements collected from the testbed. By using the OML, application programmers can use its simple interfaces provided to transfer measurements and other performance data to a central repository

6https:/mytestbed.net/projects/oml

17

(OML – Server).

OML enables experimenters to define customisable measurement points (MP) and parameters, collect and pre-process measurements, and organize the collected data into a single database with the experiment’s context, avoiding logging files in various formats. This Measurement Library tool overcomes the burdensome of the traditional testbeds where the data from measurements are locally written into log files and are collected at the end of the experiment, or are available only locally. Given that the testbeds are becoming bigger and more complex, the procedure of collecting and sharing data can become very challenging.

18

Table 1: Sample RSpec description of a smart building IoT testbed

<?xml version="1.0" encoding="UTF-8"?> <rspec type="advertisement" xsi:schemaLocation="http://www.iotlab.eu/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.iotlab.eu/"> <node component_manager_id="urn:publicid:iot-lab.eu+cm" component_name="telosb" exclusive="true" component_id="urn:publicid:IDN+emulab.geni.emulab.net+node+telosb" > <interface component_id="sdfa"> <ip address="150.140.193.153" netmask="255.255.255.0" protocol="http" type="" port="80"> </ip> </interface> <resource component_manager_id="urn:publicid:iot-lab.eu+cm" exclusive="true" component_id="urn:publicid:IDN+hobnet.sensorlab.upatras.gr+resource+ceilingLight1"> <lightcontrol> <on data_type="true" interface_def="a" resource_type="ipso.lt.on" path="/lt/0/on" name="Light Control"/> </lightcontrol> </resource> <resource component_manager_id="urn:publicid:iot-lab.eu+cm" exclusive="true" component_id="urn:publicid:IDN+hobnet.sensorlab.upatras.gr+resource+ceilingLight2"> <lightcontrol> <on data_type="true" interface_def="a" resource_type="ipso.lt.on" path="/lt/1/on" name="Light Control"/> </lightcontrol> </resource> <resource component_manager_id="urn:publicid:iot-lab.eu+cm" exclusive="true" component_id="urn:publicid:IDN+hobnet.sensorlab.upatras.gr+resource+ceilingLight3"> <lightcontrol> <on data_type="true" interface_def="a" resource_type="ipso.lt.on" path="/lt/2/on" name="Light Control"/> </lightcontrol> </resource> <resource component_manager_id="urn:publicid:iot-lab.eu+cm" exclusive="true" component_id="urn:publicid:IDN+hobnet.sensorlab.upatras.gr+resource+ceilingLight4"> <lightcontrol> <on data_type="true" interface_def="a" resource_type="ipso.lt.on" path="/lt/3/on" name="Light Control"/> </lightcontrol> </resource> </node> <node component_manager_id="urn:publicid:iot-lab.eu+cm" component_name="telosb" exclusive="true" component_id="urn:publicid:IDN+hobnet.sensorlab.upatras.gr+node+telosb" > <resource component_manager_id="urn:publicid:iot-lab.eu+cm" exclusive="true" component_id="urn:publicid:IDN+hobnet.sensorlab.upatras.gr+resource+curtains"> <gpio> <dout data_type="b" interface_def="a" resource_type="ipso.gpio.dout" path="/gpio/dout/0" name="Digital Output"/> </gpio> </resource> </node>

19

The OML framework is based on a client-server architecture and uses IPv6 multicast communications for the client to report the collected data from the local testbed to the server in real-time. At the time of writing this document, the latest version that has been deployed in testbeds of U. of Geneva, Computer Technology Institute, U. of Surrey and Mandat International is the OML 2.11 released on 6 May 2014. OML defines the data structures and functions for sending/receiving, encoding/decoding and storing experimental data. It provides user-friendly generic APIs, which can be easily integrated into testbed applications. The OML consists of two main components:

The OML client library which provides a C API for applications to collect

measurements that they produce. The library includes a dynamically configurable

filtering mechanism that can perform some processing on each measurement

stream before it is forwarded to the OML Server.

The OML Server which is responsible for collecting and storing the measurements into a database.

The following figure depicts the framework of OML.

Figure 4: The OML framework

On the experimenter's side, the Node Handler starts an instance of the OML Collection Server, which will listen and collect experimental results from the various nodes involved in the experiment. On each experimental node, the OML Collection Client interfaces with each experimental applications. It collects any required measurements or outputs from these applications, optionally apply some filter/processing to these measurements/outputs, and then sends them to the OML Server. The communication from the multiple OML Clients on all the experimental nodes towards the OML Server on the experimenter side is currently done over one multicast channel per experiment (for logical segregation of data and for scalability).

20

The user defines on XML format the measurement points and measurement frequencies at which data collection will take place. Optionally, the user can also define some filtering rules to apply on these measurements. Using this XML definition, an OML web service will then automatically generate the source and compiled code for a specific OML Measurement API. This specific API provides application-specific methods that handle type-safe data collection. The user can call these methods within its C/C++ application code, whenever he/she wants to pass on measurement data to the OML collection service. These methods within the OML Measurement API relie on a set of Dynamic OML Libraries to format these measurement data and forward them to the OML Collection Server. This set of dynamic OML libraries are part of the standard system libraries. In the context of the IoT Lab, the OML Server will be installed in the IoT Lab Cloud and the OML Client on each individual testbed.

Figure 5: OML client using Dynamic Library

21

6. Virtualisation of Crowdsourced Resources One of the main additive values of IoT Lab is to explore the potential of crowdsourcing to extend IoT testbed infrastructure for multidisciplinary experiments with more end-user interactions. That said, the IoT Lab project seeks to provide a comprehensive framework for the support of experimentation with crowdsourced IoT experimentation resources. The term “crowdsourced IoT experimentation resources” mainly refers to devices that can be used and therefore contribute in the experimentation process and that are provided in an ad-hoc manner by third party users, not related to the integrated IoT testbed facilities of the IoT Lab platform. Although such devices could refer to any IoT device (from NFC tags to IPv6-enabled sensor motes), it is highly anticipated that their grand majority will consist of truly portable, handheld devices like smartphones and tablets. Due to the nature of such devices and in order to deal with their underlying dynamicity and unreliable nature, while preserving the privacy demands and preferences of their owners, in this section we describe the corresponding open interfaces to be used in order to address these aspects with a main focus on smartphones, tablets and other similar devices.

Architectural Styles of Interfaces

When making the decision on the open interfaces to be used, two are the main architectural options; SOAP and REST. By taking into consideration the particular nature of crowdsourced resources and in particular the fact that in their grand majority will be smartphones or similar devices, we below discuss the advantages and the disadvantages of each option. At this point we would like to note that the following discussion is performed in the light of the development procedure and therefore its role is to highlight the main aspects and not to define strict guidelines that have to be adopted.

SOAP.

SOAP stands for Simple Object Access Protocol. It’s a protocol specification that describes the process of exchanging structured information in the context of web-services in computer networks. Therefore, it lies in the core of the protocol stack of web-services, defining the communication between applications running on different systems in terms of operating systems, technologies and programming languages being used. It significantly improves XML-RPC, a protocol that uses XML over HTTP to describe the calls to be invoked by a remote system. The disadvantage of RPC web services has been that the abstraction level is quite low due to its simplicity and therefore, the complexity increases with an increasing number of different requests.

On the other hand, while SOAP inherits the use of XML as a means of exchanging data, it offers a higher degree of flexibility by supporting additional communication protocols apart from HTTP (e.g. SMTP) as well as higher levels of abstraction and extension capabilities. For several years it has been the de-facto architectural style used in practice and as a result SOAP is very well documented and supported, thus offering an increased level of interoperability. On the down side, in terms of complexity, in SOAP it

22

is time-consuming to serialize and de-serialize native languages into SOAP messages. Furthermore, the WS-* protocol stack (the security SOAP extension) is highly complex, so that only programmers can understand how to deploy a service [8][9]. Also, since in SOAP a specific service interface is defined for each service, a client must be bound to a specific WSDL7. Once the WSDL has changed, the client has to follow these changes thus inferring significant maintenance costs and hurdles. Finally, SOAP is characterised by high verbosity. In terms of performance and efficiency this translates in increased network communication volume and server-side payload and it is difficult to support the proxy and cache servers because clients cannot identify the useful information straightforwardly from the URI and HTTP.

REST.

REST stands for Representational State Transfer. In this architectural style each web service operation is described as a resource and can be accessed by a resource identifier. This identifier can be seen as an address which specifies where to find the resource. There are a number of terms referring to resource identifiers like URI or Uniform Resource Locator (URL). When transferring information between components (e.g. client/server) – this means accessing a resource by a resource identifier – the state of the information received by the resource at a specific time is called representation. RESTful Web services are perceived to be simple because REST leverages the existing well-known W3C/IETF standards (HTTP, XML, URI and MIME type) as well as the necessary infrastructure that has already become pervasive.

On the advantages of REST first lies addressability; resources are marked with global URIs and therefore are accessible once they are exposed on the Web rather than require a separate resource discovery and location mechanism. Second, Resources are linked with each other by using hyperlinks which point to valid future states in representations. What most important is that, state transfer can be implemented by following the links. Then, each request includes all the necessary information for the servers to understand, so each transaction is independent and unrelated to previous ones; servers do not need to keep states between requests. Finally, resources in REST are manipulated using a uniform, HTTP interface (functions GET, PUT, POST and DELETE). On the other hand, REST is not so efficient in encoding large amounts of input data in the resource URI as the server may either refuse long URIs or crash. It may also be challenging to encode complex data structures into URI as there is no commonly accepted marshalling mechanism. Inherently, the POST method (that SOAP heavily utilises) does not suffer from such limitations.

Which one for Crowdsourced Resources?

As mentioned before, although not restricted to a particular type of device, it is highly expected that the grand majority of the crowdsourced resources that will be contributed by third parties will mainly consist of truly portable, handheld devices such as smartphones and other, recently introduced, wearable gadgets (smart watches, glasses, etc). Such devices share several common attributes with other IoT devices, like sensor motes.

7 Web Services Description Language (WSDL): an XML-based interface description language that is

used for describing the functionality offered by a web service.

23

In particular, they are characterised by significant constraints in terms of either computational power or energy autonomy or both. Furthermore, as these devices are intrinsically mobile, their motion is highly dynamic, diverse and unpredictable. Therefore, their communication heavily relies on wireless communication modules and they tend to form ephemeral connections at an opportunistic manner. Apart from these, technical reasons, the availability of such devices is also governed by external factors that are very hard to model and thus, difficult for a system to predict. Such factors include the willingness of their owner to provide access to a system such as IoT Lab, their reaction to incentives offered, etc. Finally, another important factor are the additional charges that a mobile user may have when providing access to her device. For instance, when backbone cellular networks are used for connectivity (e.g. 3G or LTE), the increased communication overhead inferred by SOAP could have an important impact. The following table, summarises the differences between SOAP and REST regarding these central aspects of crowdsourced resources.

Table 2: Comparison of SOAP and REST based Web Services

SOAP REST

In SOAP, Client-Server interaction is Tightly coupled.

In REST, Client-Server interaction is loosely coupled.

Changing services in SOAP web provisioning often means a complicated code change on the client side.

Changing services in REST web provisioning not requires any change in client side code.

SOAP has heavy payload as compared to REST. REST is definitely lightweight as it is meant for lightweight data transfer over a most commonly known interface, - the URI

It requires binary attachment parsing. It supports all data types directly.

SOAP is not a wireless infrastructure friendly. REST is a wireless infrastructure friendly.

It consumes more bandwidth because a SOAP response could require more than 10 times as many bytes as compared to REST.

It consumes less bandwidth because it’s response is lightweight.

SOAP request uses POST and require a complex XML request to be created which makes response-caching difficult.

Restful APIs can be consumed using simple GET requests, intermediate proxy servers / reverse-proxies can cache their response very easily.

SOAP uses HTTP based APIs refer to APIs that are exposed as one or more HTTP URIs and typical responses are in XML / JSON. Response schemas are custom per object.

REST on the other hand adds an element of using standardized URIs, and also giving importance to the HTTP verb used (i.e. GET / POST / PUT etc).

False assumption: SOAP is more secure. SOAP use WS-Security. WS-Security was created because the SOAP specification was transport-independent and no assumptions could be made about the security available on the transport layer.

REST assumes that the transport will be HTTP (or HTTPS) and the security mechanisms that are built-in to the protocol will be available.

From the points listed on the table, we note the following two aspects related to security, why SOAP would be less adequate to be adopted as the basis for the API of the crowd sourced resources. The first one is the false assumption usually made that SOAP is

24

more secure than REST. While it is true that SOAP has a particular extension for security –namely WS-Security specification – this only happens due to the fact that SOAP makes no assumptions regarding the transport layer lying below. On the other hand REST explicitly runs over HTTP (or other similar protocols like CoAP) and therefore is able to utilise their built in security mechanisms (e.g. HTTPS). A solid example of successfully using REST on critical applications has been the sector of on-line payments. A second point in favour of REST is the fact that in SOAP the two communicating parties are considered to be safe. This is due to the fact that SOAP has been developed mainly having in mind that the communicating entities would be web servers, generally considered safe. Such an assumption would be rather invalid for devices like smartphones.

Based on the presented analysis and having taken into consideration the nature of the crowdsourced resources, it is our recommendation to utilise the REST architectural style for their virtualisation.

Custom API for Crowdsourced Resources

The IoT Lab Cloud will need a standardised way of accessing and interacting with the Crowdsourced resources that will address their particular nature. The corresponding API should be able to provide access to the embedded sensors of modern smartphones as well as to take care of (i.e. establish and maintain) the communication between the IoT Lab Cloud and the crowdsourced resources.

The communication between a smartphone and the IoT Lab Cloud will be based on web sockets utilized by the Socket.IO framework and will focused the exchange of data. The API calls are categorised into Smartphone Calls and Server Calls.

Smartphone Calls.

In the context of the IoT Lab the main focus for the crowdsourced resources will be on devices running the Android OS. The open source mentality characterizing it, its great market share and the variety of the supported devices are the main features that make it attractive. Following is the list of the sensors that are currently supported by the Android API as well as the IoT Lab API for the crowdsourced resources.

Table 3: Sensors supported by the Android API

TYPE_ACCELEROMETER TYPE_PROXIMITY

TYPE_AMBIENT_TEMPERATURE TYPE_RELATIVE_HUMIDITY

TYPE_GRAVITY TYPE_ROTATION_VECTOR

TYPE_GYROSCOPE TYPE_TEMPERATURE

TYPE_LIGHT TYPE_ORIENTATION

TYPE_LINEAR_ACCELERATION TYPE_PRESSURE

TYPE_MAGNETIC_FIELD

25

SensorManager.registerListener(Sensor sensor) -> void

This method registers a listener corresponding to the sensor that is passed as argument. Any new events captured from this sensor will be automatically propagated.

SensorManager.unregisterListener(Sensor sensor) -> void

This method removes the listener corresponding to the sensor that is passed as argument.

onSensorChanged(SensorEvent event) -> void

This method is called when sensor new events are captured by registered sensors. The

SensorEvent instance holds information such as the sensor’s type, the timestamp,

accuracy and the data from the sensor.

onAccuracyChanges(Sensor sensor, int accuracy) -> void

This method is called when the accuracy of a sensor has changed (i.e. tha sample rate

of the sensor). The argument accuracy contains the new accuracy value of the

particular sensor.

monitorSensors(JSONObject sensors) -> JSONObject

This method is called when the server needs to enable some particular sensors. The JSONObject contains the type of the sensors that the server needs and the polling period for each one of them. Returns a new JSONObject containing the sensors that

are enabled through the function monitorOk() on the Server.

availableResources() -> JSONObject

This method is called by the server in order to list all available resources on the smartphone.

Server Calls.

join(String MACAddress)

This method is called by a smartphone in order to establish a connection with the Server.

availableResources(JSONObject sensors)

This method is called in response to the availableResources()method on the

smartphones. The argument sensors contains the list of the available sensors.

sensorValue(String type, Double value)

This method is called when the smartphone sends the sensor value from a particular sensor. The first argument refers to the type of sensor while the second argument refers to the actual value from the sensor.

26

monitorOk(JSONObject object)

This method is called in response to the monitorSensors(JSONObject sensors)

method on the smartphones. It lists the sensors that are enabled on the smartphone.

API for Privacy and Trust

IoT Lab seeks to develop an experimentation platform that will integrate existing IoT testbed facilities and will augment them with crowdsourced experimental resources provided by third parties and the general public. Crowdsourced resources mainly refer to handheld devices, such as smartphones. Devices belonging to this class store and carry sensitive personal information and therefore their owners and users require an increased level of trustworthiness and privacy guarantees in order to provide access. The IoT Lab project, taking these aspects in deep consideration, addresses them directly in Work Package 2 and particularly in T2.1: “Privacy and data ownership by design”. In the corresponding privacy document a generic privacy architecture and reference implementation of privacy preserving services provided by another EU project, called ABC4Trust8 is considered. This technology, called Privacy-ABCs (ABC stands for Attribute Based Credentials), implements privacy preserving authentication (either of machines of people) based on the general principle of revealing only a subset of necessary attributes (e.g. the age of a person) instead of the entire set (e.g. full identity details).

While the ABC4Trust project provides the ABC-Engine (ABCE), a set of specifications covering several entities across the engine (such as the Verifier, the Issuer, etc), IoT Lab will treat the ABC-Engine as a service and therefore will make use of its functionalities as a User. Following is the API of the ABCE that is exposed to the upper application layers and that will be used by the IoT Lab.

Figure 6: Overview of the Privacy-ABC Architecture on the User Side

8 www.abc4trust.eu

27

boolean canBeSatisfied(PresentationPolicyAlternatives p)

On input of presentation policy alternatives, this method determines whether the user has the necessary credentials and established pseudonyms to create a presentation token that satisfies the policy. If so, this method returns true, otherwise, it returns false.

Path /user/canBeSatisfied/

HTTP Method POST

Input Type application/xml or text/xml

Input Format PresentationPolicyAlternatives

Output Type text/xml

Output Format ABCEBoolean

UiPresentationArguments createPresentationToken (

PresentationPolicyAlternatives p)

On input of presentation policy alternatives, this method determines whether the user has the necessary credentials and established pseudonyms to create a presentation token that satisfies the policy. If there is at least one way in which the policy can be satisfied with the user's credentials and pseudonyms, this method returns an object that encodes the different alternatives. The caller then lets the user choose her preferred way of satisfying the policy or let her cancel the transaction, for example by displaying the relevant information in a (graphical) user interface. If the presentation policy alternatives cannot be satisfied, this method returns an error.

Path /user/createPresentationToken/

HTTP Method POST

Input Type application/xml or text/xml

Input Format PresentationPolicyAlternatives

Output Type text/xml

Output Format UiPresentationArguments

PresentationToken createPresentationToken(UiPresentationReturn upr)

After the user has chosen her preferred way of satisfying the presentation policy in the identity selector, she calls this method on input of the object encoding her choice. This method generates a presentation token that reflects this choice, and which satisfies the respective presentation policy alternatives. The generated presentation token consists of two parts: (1) a description of the token's content, which largely repeats the information of the corresponding alternative in the presentation policy; and (2) cryptographic evidence, which mainly consists of a non-interactive zero-knowledge proof (using the Fiat-Shamir heuristic) that the user owns all the credentials and pseudonyms referenced in the token, that all revocable credentials are not revoked, that all inspectable attributes were encrypted correctly, and that all predicates hold. Furthermore, the presentation token contains a reference to the policy alternative that the user chose to fulfil. This method returns the generated presentation token.

Path /user/createPresentationTokenUi/

HTTP Method POST

28

Input Type application/xml or text/xml

Input Format UiPresentationReturn

Output Type text/xml

Output Format PresentationToken

IssuanceReturn issuanceProtocolStep(IssuanceMessage im)

This method performs one step in an interactive issuance protocol. It takes as input an issuance message received from an issuer. The method has exactly one of the following three return values: (1) an issuance message, which has to be sent to the issuer; (2) a description of the newly issued credential—this return value indicates that the protocol was completed successfully and that the newly issued credential was stored in the user's credential manager; (3) an object of type UiIssuanceArguments which encodes the user's choices to satisfy the issuance policy (and which, for example, is forwarded to an identity selection user interface). In the latter case, the user must then call the other issuanceProtocolStep() method with an object that reflects the selected choice. During simple issuance, this method never returns an object of type of type UiIssuanceArguments.

Path /user/issuanceProtocolStep/

HTTP Method POST

Input Type application/xml or text/xml

Input Format IssuanceMessage

Output Type text/xml

Output Format IssuanceReturn

IssuanceMessage issuanceProtocolStep(UiIssuanceReturn uir)

This method is called during the issuance protocol after the other issuanceProtocolStep() method returned an object of type UiIssuanceArguments, and after the user has made her choice (in the identity selector) on how to satisfy the issuance policy. The input to this method is an object which encodes the user's choice on how to satisfy the issuance policy. The method returns an issuance message, which has to be sent to the issuer.

Path /user/issuanceProtocolStepUi/

HTTP Method POST

Input Type application/xml or text/xml

Input Format UiIssuanceReturn

Output Type text/xml

Output Format IssuanceMessage

void updateNonRevocationEvidence()

This method updates the non-revocation evidence associated to all credentials in the credential store. Calling this method at regular time intervals reduces the likelihood of having to update non-revocation evidence at the time of presentation, thereby not only speeding up the presentation process, but also offering improved privacy as the Revocation Authority is no longer “pinged” at the moment of presentation.

Path /user/updateNonRevocationEvidence/

29

HTTP Method POST

Input Type Application/xml or text/xml

Input Format None

Output Type Text/xml

Output Format none

URI[] listCredentials()

This method returns an array of all unique credential identifiers (UIDs) available in the Credential Manager.

Path /user/listCredentials/

HTTP Method GET

Output Type text/xml

Output Format URISet

CredentialDescription getCredentialDescription(URI credUid)

This method returns the description of the credential with the given unique identifier. The unique credential identifier credUid is the identifier which was included in the credential description that was returned at successful completion of the issuance protocol.

Path /user/getCredentialDescription/{credentialUid}

HTTP Method GET

Output Type text/xml

Output Format CredentialDescription

Path Parameter Parameter Type

credentialUid URI

boolean deleteCredential(URI credUid)

This method deletes the credential with the given identifier from the credential store. If deleting is not possible (e.g. if the referred credential does not exist) the method returns false, and true otherwise.

Path /user/deleteCredential/

HTTP Method DELETE

Output Type text/xml

Output Format ABCEBoolean

Query Parameter Parameter Type

credUid URI

30

7. Services of the IoT Lab Experimentation Platform The aim of the IoT Lab project is to research and create a crowdsourcing infrastructure together with the supporting mechanisms that will enable multidisciplinary experimentation in the general domain of Internet of Things (IoT) and social and economic aspects of the society. Towards this vision, the services provided by several already existing FIRE testbed facilities need to be unified and extended with crowdsourced resources such as smartphones and tablets. The envisioned IoT Lab platform needs to follow a scalable and agile architecture in order to constitute a successful crowdsourced experimental facility. Therefore, the architecture needs to be scalable in order to be able to support an increasing number of testbed facilities as well as ad-hoc crowdsourced resources such as smartphones, tablets and third party IoT facilities. Further, the IoT Lab architecture needs to be agile in order to be able to incorporate experimental infrastructure of different orientation and technologies; from fixed testbed facilities for smart buildings to innately mobile crowdsourced smartphones; from facilities focusing to high level end-user applications (e.g. smart-home profiling, end-user comfort vs low power consumption, etc.) to facilities being used for evaluating low-level networking protocols.

Towards this end, it has been the consensus of the consortium to benefit from already existent knowledge and tools rather than “re-inventing the wheel”. In this context, in terms of efficiently managing and providing access to this diverse set of experimental resources and facilities, the IoT Lab experimentation platform will be strongly based but will also build on top of the efforts of the on-going EU funded Fed4FIRE9 Integrating Project. The objective of Fed4FIRE is to develop a federated FIRE facility that offers benefits to both experimenters and facility providers. From the Experimenter point of view, the federation will provide a better view on the availability and offered functionalities of different Future Internet experimentation facilities in Europe. From the Facility Provider point of view, Fed4FIRE improves the capabilities of the facility by providing more functionalities in terms of experiment lifecycle management and trustworthiness.

Figure 7 depicts a high level tessellation of the Fed4FIRE architecture in four main layers.

Following a bottom-up description, these four layers are organised as follows:

• At the bottom lie the test-bed platforms (experimental facilities) and their resources such as servers, gateways, sensor motes, sensors and actuators.

• On top of each test-bed lies the testbed management software that manages these resources, the users and the experiments of a testbed. For instance, for a given testbed, it may organize all available resources in a Resource Directory, provide a user interface or allocate time-slots to experimenters.

9 http://www.fed4fire.eu

31

• At the third layer lie the broker services; these services are handled by 3rd parties or Fed4FIRE and act as a liaison between the experimentation platforms and the experimenters.

• At the fourth and higher layer lie the experimenter tools and user interfaces which are used by the experimenters to communicate with the testbed management frameworks, the testbed resources and the brokers if needed. In the context of the IoT Labs project, at this layer the test-bed cloudification will be implemented.

Communication among the different layers is established by the use of common open interfaces. Following the heterogeneous testbed federation architecture, each testbed keeps its own management software while the interfaces on top of the testbed software are specified, standardized and made interoperable into a federation.

Fed4FIRE architecture breaks the life-cycle of an experiment down to three distinct phases:

Resource discovery, reservation and provisioning

Figure 7: A high-level overview of the Fed4FIRE architecture. Colours are used to indicate the different layers each component belongs to. Arrows demonstrate interactions

32

Experiment control

Measuring and monitoring.

For each one of these phases different software components are used, each one implementing a different functionality. In the following sub-sections a detailed review is provided on the software to be utilised in the context of IoT Lab mainly for test-bed virtualisation and interconnection purposes. Figure 8 depicts a graphical representation of the phases an experiment would consist of for a hypothetical experiment scenario.

Figure 8: The life-cycle of an experiment according to Fed4FIRE architecture

Discovery, reservation, provisioning

The open interface to be used for discovery, reservation and provisioning of the resources of the IoT Lab is the one defined by the Slice Federation Architecture, commonly referred to as SFA. Slice-based Federation Architecture (SFA) provides a minimal interface to enable the federation of test-beds with different technologies and belonging to different administrators, while granting the control of the resources to their owners. This allows researchers to combine resources available in different test-beds, increasing the scale and diversity of their experiments. SFA is based on a set of high-level concepts that define the actors and the resources that interact on the testbed, as well as defining an architecture with its interfaces and main data types to facilitate the federation of test-beds.

SFA is more of a specification of a standard rather than a specific implementation, and as a result there exist several different implementations (PlanetLab, ProtoGENI, OpenFlow). In the context of IoT Lab we will investigate the two most mature and widely used SFA software implementations for virtualization of the resources and the eventual

33

test-bed integration.

The first one is SFA Wrap (http://sfawrap.info/) provided by INRIA in the context of the Fed4FIRE research project. SFA Wrap is a generic tool that enables the adoption of the SFA architecture with limited efforts and in a relatively short amount of time. What the wrapper basically does is to provide a complete implementation of the SFA API with some empty stubs at the test-bed side; this is what is called the test-bed driver. Test-bed providers have to fill in these stubs with appropriate calls to their existing test-bed management software in order to implement SFA support for their testbed and probably extend the parser of SFA Wrap to encode and decode specifications of resources that are not captured by the existing resource description formats; referred to as RSpecs. SFA Wrap installation guides can be found at http://sfawrap.info/installation.

SFA Wrap seems to be mature enough and well supported, while at the same time seems to be compatible with the RESTful architecture of several of the already existing IoT Lab facilities (e.g. CTI and UNIGE HOBNET test-beds). Therefore, this implementation is the main candidate to be adopted by IoT Lab facilities providers. However, for robustness purposes, we list here another one, different implementation of the SFA architecture developed in the context of the Planetlab (http://www.planet-lab.org/). Planetlab provides a brief tutorial on installing, configuring and using the Slice Federation Architecture service and user tools that can be deployed over Fedora or Debian operating systems. The tutorial can be found here http://svn.planet-lab.org/wiki/SFATutorial and walks through the installation, configuration and federation processes.

Once the adoption of the SFA architecture by a test-bed provider has been concluded, the resources of this test-bed will be accessible by experimenters by using the available SFA client applications listed below:

The Fed4FIRE portal MySlice (http://myslice.info/): Technical details about MySlice on http://trac.myslice.info

The visual SFA client Flack (http://www.protogeni.net/wiki/Flack)

The command line SFA client Omni (http://trac.gpolab.bbn.com/gcf/wiki/Omni)

The command line SFA client SFI (http://www.fed4fire.eu/tools/sfi.html)

Experiment control

The main software to be used for the experiment control is the cOntrol and Management Framework (OMF). OMF (http://omf.mytestbed.net) is a generic framework which allows the definition and orchestration of experiments using shared (already provisioned) resources from different federated test-beds. It provides a domain-specific language based on an event-based execution model to fully describe even complex experiments (OEDL), defines a generic resource model and concise interaction protocol (FRCP) and, finally, provides a distributed communication infrastructure based on XMPP supporting the scalable orchestration of multiple distributed and potentially disconnected resources. Currently OMF is at its 6th version and the corresponding wiki (found at: http://mytestbed.net/projects/omf6/wiki/Wiki) provides documentation for

34

users, experimenters and developers (in case it is needed to be extended in the context of IoT Lab). Also an OMF glossary is available10 that is very useful in comprehending the main terms as well as the OMF architecture itself.

A life-cycle management tool for network experiments to be investigated in the context of IoT Lab alongside OMF is the Network Experimentation Programming Interface (http://nepi.inria.fr) provided by INRIA. NEPI is a Python-based language to design and easily run network experiments on network evaluation platforms (e.g. PlanetLab, OMF wireless test-beds, network simulators, etc) that allows to specify resources, to define an experiment workflow and to automate deployment, resource control and result collection. NEPI is currently at version 3.0 and comes along with a detailed installation guide, a manual and a reference document. The main disadvantage seems to be the fact that it is not yet compatible with the latest version of OMF (supports OMF 5.4).

Measuring and monitoring

During the execution of an experiment at the IoT Lab experimental facilities a mechanism for data collection and resource monitoring is required. Due to the fact that the IoT Lab infrastructure will consist of several federated testbed facilities plus ad-hoc crowdsourced resources, this mechanism should a) provide a uniform process of data collection and monitoring and b) should be flexible and agile enough in order to be applied on a heterogeneous set of infrastructure. Towards this end the OML library will be used. OML11 is an instrumentation tool that allows application writers to define customisable measurement points (MP) inside new or pre-existing applications. Experimenters running the applications can then direct the measurement streams (MS) from these MPs to remote collection points, for storage in measurement databases. The main advantage of OML is the fact that it is a generic framework that can instrument the whole software stack, and take input from any sensor with a software interface. It has no preconception on the type of software to be instrumented, nor does it force a specific data schema. Rather, it defines and implements a reporting protocol and a collection server. On the client side, any application can be instrumented using libraries abstracting the complexity of the network communication. Additionally, some of the libraries provide in-band filtering, allowing to adapt the measurement streams obtained from an instrumented application to the requirements of the current observation (e.g., time average rather than raw metrics).

The current version of OML is OML 2.11.0rc12, released on 2013-11-01 and it consists of two main components:

OML client library: the OML client library provides a C API for applications to collect measurements that they produce. The library includes a dynamically configurable filtering mechanism that can perform some processing on each measurement stream before it is forwarded to the OML Server. The OML client library comes in C (here), Python (OML4Py) and Ruby (OML4R).

10

http://omf.mytestbed. net /projects/ omf/wiki/Glossary 11

http://oml.mytestbed.net/projects/oml/wiki 12

http://oml.mytestbed.net/projects/ oml/wiki /OML2_v2110_Release_Notes

35

OML Server: the OML server component is responsible for collecting and storing measurements inside a database. Currently, SQLite3 and PostgreSQL are supported as database back-ends.

There also exists an implementation in Java (OML4J) provided by the NITLab of University of Thessaly, Greece that can also be ported in Android platforms. Therefore, it could be used in the context of the IoT Lab smartphone app.

Security

For authentication/authorization between users and test-beds Fed4FIRE utilizes a X.509 certificate. It uses a trust model, where identity providers trust each other and specific experimenter properties are included in the experimenter’s X.509 certificate,

which is signed by the identity provider. So test-beds can do rule‐based authorization. A testbed can query/trust the central certificate directory to see which root certificates it should trust.

The following table summarises the Fed4FIRE related software components that are provisioned to be used in the context of IoT Lab.

Software Component

Resources Functionality

SFA Wrap

(Fed4FIRE)

General info: http://sfawrap.info/

Installation Guide: http://sfawrap.info/installation

A testbed SFA wrapper provided by Fed4FIRE for user authentication and

resource provisioning

SFA implementati

on

(PlanetLab)

Introduction and installation guide:

http://svn.planet-lab.org/wiki/SFATutorial

Implementation of the SFA architecture

provided by PlanetLab (back-up solution)

MySlice General info: http://myslice.info/

Technical details: http://trac.myslice.info

Resource management tool maintained by Fed4FIRE

Flack General info: http://www.protogeni.net/wiki/Flack

SFA flash based, visual client provided by Geni

Omni General info: http://trac.gpolab.bbn.com/gcf/wiki/Omni

SFA command line client provided by Geni

SFI General info: http://www.fed4fire.eu/tools/sfi.html

SFA command line client provided by Fed4FIRE

OMF v6.0 General info: http://omf.mytestbed.net

Technical details: http://mytestbed.net/projects/omf6/wiki/

Wiki

OMF glossary: http://omf.mytestbed.net/projects/omf/wi

ki/Glossary

Generic framework for experiment orchestration

36

NEPI v3.0 General info: http://nepi.inria.fr Scripting framework for experiment set-up (supports OMF v5.6)

OML 2.11.0rc General info: http://oml.mytestbed.net/projects/oml/wi

ki OML2_v2110_Release_Notes

Implementation in C: http://mytestbed.net/doc/oml/latest/doxy

gen/

Implementation in Python: http://pypi.python.org/pypi/oml4py/

Implementation in Ruby: http://rubygems.org/gems/oml4r

Implementation in Java (can be ported in Android):

https://github.com/NitLab/oml4j

Instrumentation tool for measurements, data collection and resource monitoring during the

execution of an experiment.

X.509 certificate

General info:

http://en.wikipedia.org/wiki/X.509

Security standard for a public key infrastructure (PKI) and Privilege

Management Infrastructure (PMI). Used for authentication, access control and trust

purposes.

8. Conclusions In this document we addressed the Open Interfaces to be used in the context of the IoT Lab Experimental Platform. The described interfaces enable the uniform virtualisation and interconnection of experimental resources at several layers spanning from individual testbed resources, crowdsourced resources and interconnection between testbed facilities, to the services provided by the IoT Lab Cloud server in order to form a unified meta-testbed facility.

The proposed technologies and interfaces have been chosen under the light of an extended review of the state of the art of already established and emerging standards, RFCs and specification guidelines provided by major standardisation bodies. Further, the break-down of the virtualisation process into layers is conducted in such a way so that if during the development/operation of the IoT Lab platform new solutions emerge or other than the chosen ones are proven more suitable, corresponding adaptations will me made easily while causing minimal disturbance to the overall system.

37

APPENDIX A: Standards, RFCs, Specifications We below provide a list of standards, including emerging ones, to be potentially used by IoT Lab in particular for virtualization, cloudification and security.

Standards for resource networking

Constrained Application Protocol CoAP is an internet draft, soon to become a standard, provided by the Internet Engineering Task Force (IETF) – Constrained RESTful Environments (CoRE) working group. CoAP is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments.

http://datatracker.ietf.org/doc/draft-ietf-core-coap/

Constrained RESTful Environments Link Format Link Format is RFC6690 provided by the Internet Engineering Task Force (IETF) – Constrained RESTful Environments (CoRE) working group. This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server.

http://datatracker.ietf.org/doc/rfc6690

Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks This specification is RFC6282 provided by the Internet Engineering Task Force (IETF) – 6LoWPAN working group that defines an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. It also specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework.

http://tools.ietf.org/html/rfc6282/

RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks RPL is published as RFC6550 by the Internet Engineering Task Force (IETF) Routing Over Low power and Lossy networks (roll) working group. RPL provides a mechanism

38

whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available.

http://datatracker.ietf.org/doc/rfc6550

Distributed Mobility Management: Current practices and gap analysis This internet draft is provided by the Internet Engineering Task Force (IETF) - Distributed Mobility Management (dmm) working group. This internet draft analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment. It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution.

http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis/

Message Queuing Telemetry Transport This protocol specification is provided is provided by OASIS Message Queuing Telemetry Transport (MQTT) TC. As an M2M/Internet of Things (IoT) connectivity protocol, MQTT is designed to support messaging transport from remote locations/devices involving small code footprints (e.g., 8-bit, 256KB ram controllers), low power, low bandwidth, high-cost connections, high latency, variable availability, and negotiated delivery guarantees. For example, MQTT is being used in sensors communicating to a broker via satellite links, SCADA, over occasional dial-up connections with healthcare providers (medical devices), and in a range of home automation and small device scenarios. MQTT is also ideal for mobile applications because of its small size, minimized data packets, and efficient distribution of information to one or many receivers (subscribers).

http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html

Extensible Messaging and Presence Protocol This protocol is published as RDC3923, RFC6122 and RFC6120 by the XMPP Standards Foundation. The Extensible Messaging and Presence Protocol (XMPP) is an open technology for real-time communication, which powers a wide range of applications including instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML data. The technology pages provide more information about the various XMPP “building blocks”. Several books about Jabber/XMPP technologies are available, as well.

http://xmpp.org/xmpp-protocols/rfcs/

Standards for authentication/privacy

Cloud Authorization This standard is under development by the OASIS Cloud Authorization (CloudAuthZ) TC. The CloudAuthZ TC develops enhanced models for managing authorizations and entitlements in SaaS, PaaS, and IaaS contexts. CloudAuthZ enables contextual attributes and contextual entitlements sets to be delivered to Policy Enforcement Points

39

in real time. With CloudAuthZ, authorization decisions can be informed by data such as where users are, what they are doing, which device they are using, etc.

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cloudauthz

Privacy Management Reference Model and Methodology This is a committee specification draft provided by the OASIS Privacy Management Reference Model (PMRM) TC. The OASIS PMRM TC works to provide a standards-based framework that will help business process engineers, IT analysts, architects, and developers implement privacy and security policies in their operations. PMRM picks up where broad privacy policies leave off. Most policies describe fair information practices and principles but offer little insight into actual implementation. PMRM provides a guideline or template for developing operational solutions to privacy issues. It also serves as an analytical tool for assessing the completeness of proposed solutions and as the basis for establishing categories and groupings of privacy management controls.

http://docs.oasis-open.org/pmrm/PMRM/v1.0/csd01/PMRM-v1.0-csd01.pdf

Identity In The Cloud Use Cases This is a committee specification provided by the OASIS Identity in the Cloud TC. This document address the serious security challenges posed by identity management in cloud computing. The TC identifies gaps in existing identity management standards and investigates the need for profiles to achieve interoperability within current standards. It performs risk and threat analyses on collected use cases and produces guidelines for mitigating vulnerabilities.

http://docs.oasis-open.org/id-cloud/IDCloud-usecases/v1.0/cn01/IDCloud-usecases-v1.0-cn01.html

XML Signature Syntax and Processing Version 2.0 This is a recommendation provided by the W3C Working Group Note. This recommendation specifies XML digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere.

http://www.w3.org/TR/xmldsig-core2/

OASIS Reference Model for Service Oriented Architecture This is a standard provided by the OASIS SOA Reference Model TC. The OASIS Service Oriented Architecture Reference Model TC develops a reference model to encourage the continued growth of different and specialized SOA implementations whilst preserving a common layer of understanding about what SOA is.

http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf

http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/cs01/soa-ra-v1.0-cs01.pdf

40

Standards for Virtualization

IPSO Application Framework The IPSO Application Framework is provided by the IPSO Alliance and defines a RESTful design for use in IP smart object systems such as Home Automation, Building Automation and other M2M applications. This design defines sets of REST interfaces that may be used by a smart object to represent its available resources, interact with other smart objects and backend services. This framework is designed to be complementary to existing Web profiles including SEP2 and oBIX.

http://www.ipso-alliance.org/wp-content/media/draft-ipso-app-framework-04.pdf

Virtualisation MO 1.0 This is a candidate version provided by the Open Mobile Alliance. This specification enables the management of any Virtual Machine on a device. Basic management operations include creating/deleting, resuming/suspending and powering on/off of a Virtual Machine. In addition, advanced management features supported by this enabler include resource allocation to a Virtual Machine. This specification also supports to reuse Management Objects to provide the device managements for the Virtual Machine. The Virtualization MO leverages hardware virtualization technologies on mobile devices, which virtualizes hardware resources such as CPU, RAM and storage so as to provide the abstract hardware layer.

http://technical.openmobilealliance.org/Technical/release_program/docs/VirMO/V1_0-20130726-C/OMA-ER-VirMO-V1_0-20130625-C.pdf

LightweightM2M v1.0 This is an enabler package provided by the Open Mobile Alliance. The motivation of LightweightM2M is to develop a fast deployable client-server specification to provide machine to machine service. LightweightM2M is principly a device management protocol, but it should be designed to be able to extend to meet the requirements of applications. LightweightM2M is not restricted to device management, it should be able transfer service / application data. LightweightM2M implements the interface between M2M device and M2M Server. It provides a choice for the M2M Service Provider to deploy a M2M system to provide service to the M2M user.

http://technical.openmobilealliance.org/Technical/release_program/docs/copyrightclick.aspx?pck=LightweightM2M&file=V1_0-20131210-C/OMA-ERP-LightweightM2M-V1_0-20131210-C.zip

OMA Device Management v2.0 This is a candidate version provided by the Open Mobile Alliance. Device management is the generic term used for technology that allows third parties to carry out the difficult procedures of configuring mobile devices on behalf of the end user (customer). Third parties would typically be wireless operators, service providers or corporate information management departments. Through device management, an external party can remotely set parameters, conduct troubleshooting servicing of terminals, install or upgrade software

41

http://technical.openmobilealliance.org/Technical/release_program/docs/CopyrightClick.aspx?pck=DM&file=V2_0-20131210-C/OMA-ERP-DM-V2_0-20131210-C.zip

vCloud API This is an API provided by VMware. The vCloud API is an interface for building new management solutions and integrating existing ones with VMware cloud infrastructure. The vCloud API enables the upload/download of vApps along with their instantiation, customization, and deployment.

https://developercenter.vmware.com/web/sdk/5.5.0/vcloud-api

Open Virtualization Format Specification This is a DMTF standard provided by the Distributed Management Task Force. The Open Virtualization Format (OVF) Specification describes an open, secure, portable, efficient and extensible format for the packaging and distribution of software to be run in virtual machines. The OVF standard is not tied to any particular hypervisor or processor architecture. The unit of packaging and distribution is a so-called OVF Package which may contain one or more virtual systems each of which can be deployed to a virtual machine.

http://dmtf.org/sites/default/files/standards/documents/DSP0243_1.1.0.pdf

Standards for Cloudification

XAM (eXtensible Access Method) Interface This is a SNIA technical position provided by the Storage Networking Industry Association. The XAM (eXtensible Access Method) Interface specification defines a standard access method (API) between "Consumers" (application and management software) and "Providers" (storage systems) to manage fixed content reference information storage services. XAM includes metadata definitions to accompany data to achieve application interoperability, storage transparency, and automation for ILM-based practices, long term records retention, and information security. XAM will be expanded over time to include other data types as well as support additional implementations based on the XAM API to XAM conformant storage systems.

http://www.snia.org/tech_activities/standards/curr_standards/xam

Cloud Data Management Interface (CDMI) This is a SNIA technical position provided by the Storage Networking Industry Association. The Cloud Data Management Interface defines the functional interface that applications will use to create, retrieve, update and delete data elements from the Cloud. As part of this interface the client will be able to discover the capabilities of the cloud storage offering and use this interface to manage containers and the data that is placed in them. In addition, metadata can be set on containers and their contained data elements through this interface.

http://snia.org/sites/default/files/CDMI%20v1.0.2.pdf

42

Open Cloud Computing Interface Core This is a specification provided by the Open Grid Forum (OGF) - Open Cloud Computing Interface (OCCI) Working Group. The OCCI Core Model defines a representation of instance types which can be manipulated through an OCCI rendering implementation. It is an abstraction of real-world resources, including the means to identify, classify, associate and extend those resources. Through these core and model features, the Open Cloud Computing Interface provides a boundary protocol and API that acts as a service front-end to a provider’s internal management framework. Service consumers can be both end-users and other system instances. OCCI is suitable for both cases. The key feature is that OCCI can be used as a management API for all kinds of resources while at the same time maintaining a high level of interoperability.

http://ogf.org/documents/GFD.183.pdf

43

APPENDIX B: Installation Guidelines for OML Client OML is an instrumentation tool that allows application writers to define customisable measurement points inside new or pre-existing applications. OML provides a way to collect all the measurement data being recorded by devices to a central location, via the network.

This guide will assist you to install and test the OML Client in your computer-gateway of your testbed.

The guide is focused on Debian/Ubuntu distributions and the OML client library is based

on the following libraries: liboml2-dev and libocomm-dev.

Step 1. : Add Software Sources

First you need to install the oml2 and the oml2-apps.

To do so, depending on your Ubuntu distribution run the following command in the terminal:

sudo sh -c "echo 'deb

http://download.opensuse.org/repositories/home:/cdwertmann:/oml/xUbuntu_13.

10/ /' >> /etc/apt/sources.list.d/oml2.list"

sudo apt-get update

sudo apt-get install oml2

where: xUbuntu_13.10 should correspond to your distribution.

To find out which Ubuntu distribution you are running, run the following command: lsb_release –a

If your distribution release is for example 12.04, in the command above replace with: XUbuntu_12.04

You can add the repository key to apt. Keep in mind that the owner of the key may distribute updates, packages and repositories that your system will trust. To add the key, run:

wget

http://download.opensuse.org/repositories/home:cdwertmann:oml/xUbuntu_13.10

/Release.key

sudo apt-key add - < Release.key

44

Step 2. : Installing OML Components

On Debian/ Ubuntu, the client library is package as liboml2, and also depends

on libocomm, which will be pulled at the same time. It is also a good idea to install the

dummy oml2-example package, as it allows to test the installation. This is done by running the following command.

sudo apt-get install liboml2 oml2-example

If the measurement nodes are expected to run in disconnected mode, the Proxy Server will also be needed.

sudo apt-get install oml2-proxy-server

For the Collection Point – Server side you will need the oml2-server package. You can install it by running the following:

sudo apt-get install oml2-server

On Debian/Ubuntu, development headers are suffixed -dev. The liboml2-dev will pull

the relevant libocomm-dev dependency. This can be done much in the same way as the library itself.

sudo apt-get install liboml2-dev

Step 3. : Testing the Library Installation locally.

The oml2-example package will have installed a dummy sine generator reporting its data through OML, oml2-generator. It can be used to test that the library has been properly installed, simply by running it with the appropriate parameters to report data to the standard output (so a server is not needed at this stage).

oml2-generator --amplitude 1 --frequency 1000 --samples 10 --sample-

interval .1 \ --oml-id librarytest --oml-domain installtest --oml-

collect file:-

If the library has been properly installed, dummy measurements will be generated and sent to the localhost. Something similar to the following will be output:

orestis-u@Orestis-Server:~$ oml2-generator --amplitude 1 --frequency

1000 --samples 10 --sample-interval .1 --oml-id librarytest --oml-domain

installtest --oml-collect file:-

May 12 16:46:09 INFO OML Client V2.11.0rc [Protocol V5] Copyright

2007-2013, NICTA

45

INFO File_stream: opening local storage file '-'

3.141593, 628.318531, 100000

sample-1 1 | 0.000000 0.000000

protocol: 5

domain: installtest

start-time: 1399905969

sender-id: librarytest

app-name: generator

schema: 0 _experiment_metadata subject:string key:string value:string

schema: 1 _client_instrumentation measurements_injected:uint32

measurements_dropped:uint32 bytes_allocated:uint64 bytes_freed:uint64

bytes_in_use:uint64 bytes_max:uint64

schema: 2 generator_d_lin label:string seq_no:uint32

schema: 3 generator_d_sin label:string phase:double value:double

content: text

0.956224 2 1 sample-1 1

0.956253 1 1 1 0 9884 3913 5971 6798

0.956263 3 1 sample-1 0.000000 0.000000

INFO -: Connected

sample-2 2 | 6.283180 -0.000006

1.062835 2 2 sample-2 2

1.062866 3 2 sample-2 6.283180 -0.000006

sample-3 3 | 6.283136 -0.000049

1.163002 2 3 sample-3 3

1.163026 3 3 sample-3 6.283136 -0.000049

sample-4 4 | 6.283136 -0.000049

1.263162 2 4 sample-4 4

1.263184 3 4 sample-4 6.283136 -0.000049

sample-5 5 | 6.283136 -0.000049

1.363319 2 5 sample-5 5

1.363342 3 5 sample-5 6.283136 -0.000049

sample-6 6 | 6.283136 -0.000049

1.463463 2 6 sample-6 6

1.463488 3 6 sample-6 6.283136 -0.000049

sample-7 7 | 6.283136 -0.000049

1.563610 2 7 sample-7 7

1.563634 3 7 sample-7 6.283136 -0.000049

sample-8 8 | 6.283136 -0.000049

1.663791 2 8 sample-8 8

1.663820 3 8 sample-8 6.283136 -0.000049

sample-9 9 | 6.283136 -0.000049

1.763949 2 9 sample-9 9

1.763972 3 9 sample-9 6.283136 -0.000049

sample-10 10 | 6.283136 -0.000049

1.864152 2 10 sample-10 10

1.864197 3 10 sample-10 6.283136 -0.000049

INFO -: Waiting for buffered queue thread to drain...

Step 4. : Testing the Library Installation by accessing the CTI- OML Server.

To test whether the connectivity between your OML – Client and the OML Server at CTI is established, run the following command. The IP of the server is in IPv6, so if you see an output like the one below it means that you have succeed to transmit in OML your dummy measurements to the OML server. In case of errors the possible problems are

46

that either the server is down, or your IPv6 outgoing connectivity is blocked.

oml2-generator --amplitude 1 --frequency 1000 --samples 10 --sample-

interval .1 --oml-id localservertest --oml-domain installtest --oml-

collect [2001:620:607:5f00::2]

Output:

orestis-u@Orestis-Server:~$ oml2-generator --amplitude 1 --frequency

1000 --samples 10 --sample-interval .1 --oml-id localservertest --oml-

domain installtest --oml-collect [2001:620:607:5f00::2]

May 12 17:23:00 INFO OML Client V2.11.0rc [Protocol V5] Copyright

2007-2013, NICTA

3.141593, 628.318531, 100000

sample-1 1 | 0.000000 0.000000

INFO tcp:2001:620:607:5f00::2:3003: Connected

sample-2 2 | 6.283180 -0.000006

sample-3 3 | 6.283136 -0.000049

sample-4 4 | 6.283136 -0.000049

sample-5 5 | 6.283136 -0.000049

sample-6 6 | 6.283136 -0.000049

sample-7 7 | 6.283136 -0.000049

sample-8 8 | 6.283136 -0.000049

sample-9 9 | 6.283136 -0.000049

sample-10 10 | 6.283136 -0.000049

INFO tcp:2001:620:607:5f00::2:3003: Waiting for buffered queue thread to

drain...