Professional Documents
Culture Documents
Deliverable D1.2
Preliminary IoT Lab Architecture and Component Specification
Version v1.0
Dissemination level PU
Keywords Internet of Things, Crowdsourcing, Lab, Testbed, FIRE
This project has received funding from the European Unions Seventh Framework Programme for
research, technological development and demonstration under grant agreement no 610477.
D1.2 Preliminary IoT Lab Architecture and Components
Abstract
This document reports on a preliminary IoT Lab platform architecture and the main
platform components that have been derived from the specified use cases and
correspondingly identified requirements as provided in D1.1 Initial IoT Lab end-user
requirements report. Functionalities, interaction patterns, interfaces and
communication links between the specified components are described and the
proposed platform architecture is designed to ensure the compatibility with future
FIRE projects.
2
D1.2 Preliminary IoT Lab Architecture and Components
Table of Contents
1. Executive Summary ........................................................................................... 7
2. Terminology/Glossary ....................................................................................... 8
3. Introduction ...................................................................................................... 10
3.1 Purpose and Scope of the WP1.................................................. 10
3.2 Purpose and Scope of Task T1.2 on Architecture Design .......... 10
3.3 Purpose and Scope of the Document ......................................... 11
3.4 Structure of the Document .......................................................... 11
4. IoT Lab: Approach to Architecture Design .................................................... 12
4.1 Introduction to IoT-A methodology .............................................. 12
4.2 IoT-A ARM: Building Interoperable Concrete IoT Architectures .. 12
4.2.1 IoT-A Architecture Generation Process ..................................... 14
4.2.2 Functional View (IoT-A ARM Building Blocks) ........................... 15
4.2.3 Information (Flow) View ............................................................. 16
5. Use Cases Portfolio ......................................................................................... 18
5.1 Selected IoT Lab Scenarios and Use Cases .............................. 18
5.1.1 Smart City Scenario ................................................................... 18
5.1.2 Physical Testbed Scenario ........................................................ 20
5.2 Summary of Requirements ......................................................... 23
6. High Level IoT Lab Architecture ..................................................................... 24
6.1 IoT Lab Platform Functional View ............................................ 24
6.2 IoT Lab Platform Information Flow View .................................. 25
7. Review of Existing Crowdsourcing Solutions ............................................... 27
7.1 Smart Santander Pulse of the City........................................... 29
7.2 Ushahidi ...................................................................................... 30
7.3 APISENSE .................................................................................. 31
7.4 McSense (ParticipAct) ................................................................ 33
7.5 EpiCollect.................................................................................... 35
7.6 PhoneLab ................................................................................... 35
7.7 SmartLab .................................................................................... 36
7.8 Funf ............................................................................................ 37
7.9 AmbientDynamix......................................................................... 38
7.10 Compose .................................................................................... 40
3
D1.2 Preliminary IoT Lab Architecture and Components
4
D1.2 Preliminary IoT Lab Architecture and Components
List of Figures
Figure 1: Task 1.2 Sequence and interactions ....................................................................................... 11
Figure 2: Relationship between reference architecture, architectures and actual systems (taken from
IoT-A [1]) ................................................................................................................................................ 13
Figure 3: IoT architecture generation process [source: IoT-A [5]] ........................................................ 14
Figure 4: Functional view IoT System groups and components [1].................................................... 15
Figure 5: Game and Supermarket Marketing use case diagram ........................................................... 18
Figure 6: Supermarket marketing scenario diagram ............................................................................. 19
Figure 7: Energy Efficiency and user comfort hints use case diagram .................................................. 20
Figure 8: Physical testbed scenario diagram ......................................................................................... 21
Figure 9: IoT Lab General Use Case Diagram......................................................................................... 22
Figure 10: Functional View of IoT Lab Architecture .............................................................................. 24
Figure 11 IoT Lab: Information flow view.............................................................................................. 26
Figure 12: SmartSantander - Pace of the City logical architecture ....................................................... 29
Figure 13. Ushahidi architecture diagram ............................................................................................. 30
Figure 14. APISENSE approach ............................................................................................................. 31
Figure 15. APISENSE web architecture ................................................................................................. 31
Figure 16. APISENSE mob.app architecture ......................................................................................... 32
Figure 17: McSense ParticipAct big picture architecture ...................................................................... 33
Figure 18: McSense architecture........................................................................................................... 34
Figure 19: EpiCollect approach .............................................................................................................. 35
Figure 20: Funf approach ...................................................................................................................... 37
Figure 21: Funf phone-side architecture: high-level ............................................................................. 37
Figure 22: AmbientDynamixSystem architecture ................................................................................. 39
Figure 23: Compose Architectural high level components ................................................................... 40
Figure 24: CitySDK Ecosystem ............................................................................................................... 41
Figure 25 Xively Overview .................................................................................................................... 42
Figure 26: WISEBED testbed functional diagram ............................................................................... 50
Figure 27: Architecture .......................................................................................................................... 51
Figure 28: HOBNET architecture ........................................................................................................... 52
Figure 29: HOBNET Architecture ........................................................................................................... 53
Figure 30: Architecture .......................................................................................................................... 55
Figure 31: Architecture .......................................................................................................................... 56
5
D1.2 Preliminary IoT Lab Architecture and Components
6
D1.2 Preliminary IoT Lab Architecture and Components
1. Executive Summary
This document presents the preliminary IoT Lab Architecture and specification of its
components.
The IoT Lab platform is envisioned in the following:
Enable an ad-hoc organised dynamic setup of the experimental infrastructure
ensuring at the same time reliability and privacy in a non-centralised
environment.
Support a wide range of demanding research use cases which is due to the
crowdsourcing nature of acquired IoT data, their heterogeneity and volumes.
Use existing testbed infrastructure as a service in combination with crowd
participation in experiments.
The use cases will initially provide directions and guidance in the architecture design,
but the resultant platform should be general and able to support research
applications beyond the scope envisioned in the use cases.
This document describes the process of building such IoT Lab Architecture by
leveraging the existing body of work predominantly found in a domain of FIRE
architectures and adapting it by taking into account the requirements identified in
Task 1.1. A detailed analysis of the State of the Art of existing crowdsourcing
approaches is presented from the IoT Labs point of view regarding important
criteria/requirements and their limitations.
The main aim of the Iot Lab platform development focused on the following:
Enhancement of existing IoT FIRE testbeds which are traditionally built from
static sensor mote platforms by including the participants end user mobile
phones and thus achieving a crowd participation in sensing and actuation
operations.
Solutions with built-in reputation and privacy mechanisms as well as procedures
for dynamic selection of suitable crowd resources.
It has to be emphasised that by integrating smartphones with existing FIRE testbed
infrastructures or any general statically deployed IoT resources results in a novel
approach with respect to existing crowdsourcing solutions.
Main components of such a platform are identified and their functionalities of
interaction patterns, interfaces and communication links are described. Derivation
process followed an IoT-A methodology to support interoperability and scalability and
enable the use of a wide range of heterogeneous devices as well as the testbeds
from different application domains, therefore, satisfying a high number of
requirements.
The proposed IoT Lab architecture is in its preliminary form and it will be regularly
reviewed and updated in an iterative manner during the project duration taking into
account the outputs from other work packages and by monitoring and evaluating the
fulfilment of requirements. Relevant results from cooperation activities with other
research projects will also be fed back into the architecture platform.
This document will also serve as a reference document for all other work packages
as well as for the dissemination work.
7
D1.2 Preliminary IoT Lab Architecture and Components
2. Terminology/Glossary
Term Definition
WP Work package
OML format OML is a generic framework that can instrument the whole
software stack, and take input from any sensor with a software
interface.
EU European Union
FG Functional Group
8
D1.2 Preliminary IoT Lab Architecture and Components
OS Operating System
DB Database
RS Remote Shells
IP Internet Protocol
RD Resource Directory
9
D1.2 Preliminary IoT Lab Architecture and Components
3. Introduction
3.1 Purpose and Scope of the WP1
It is the purpose of WP1 to identify relevant crowdsourcing scenarios, the
requirements coming from the end-users and coherent platform architecture. This
architecture will consider inputs from other research projects (FIRE architectures)
and extend it by taking into account the IoT Lab requirements. All this work will be
aligned with the technical work carried out in all the technical work packages, where
use cases and technical requirements serve as inputs for the other WPs and at the
same time the outcomes of these WPs must be validated to the overall system
architecture designed in WP1.
This work package is divided in two tasks, as follows:
Task 1.1 Use cases and requirements analysis: In this task, a wide range of
relevant crowdsourcing use cases will be designed, as well as its derived
functional and non-functional requirements.
Task 1.2 Architecture design: This task will investigate emerging architectures
in European projects, novel extensions to those and design the overall IoT Lab
architecture that also considers the requirements coming from Task 1.1.
WP1 coordinates and aligns the overall strategy and facilitates activities for the
overall project.
10
D1.2 Preliminary IoT Lab Architecture and Components
11
D1.2 Preliminary IoT Lab Architecture and Components
12
D1.2 Preliminary IoT Lab Architecture and Components
Reference Architecture
Reference model and reference architecture provide an abstract description of
the system which can be mapped to a range of system architectures with each
architecture designed for a specific application with specific requirements,
constraints and choices.
Architecture
This refers to a mapped architecture for a specific application. Best practices are
used to guide derivation of use case specific (concrete) architectures from the
reference architecture ARM. This guidance can make new architectures and
systems compliant to each other.
Extraction of important bits of existing architectures (e.g. standards used) can
help define the reference architecture.
Actual Systems
Architectures are used then to help design, engineer, build and test the actual
systems. Understanding system constraints better can provide a feedback for
the architecture design and thus identify future opportunities.
A diagram showing the relationship between the Reference Architecture,
Architectures and the Actual Systems is illustrated in Figure 2.
Best practices are used as guidance for deriving the use case specific (concrete)
architectures from the reference architecture.
13
D1.2 Preliminary IoT Lab Architecture and Components
14
D1.2 Preliminary IoT Lab Architecture and Components
15
D1.2 Preliminary IoT Lab Architecture and Components
One way
Push (send) data
communication;
address of client
known to server;
client constantly
awaiting messages
e.g. Constrained
device to gateway
Synchronous
Request/response
communication; Client
sends request to server
and is waiting for its
response. More clients
can send requests, but
response sent on first
come first served
basis.
Asynchronous
communication without
client waiting for the
server response. Non-
blocking behavior
advantage with respect
to request/response
Subscribe/Notify
16
D1.2 Preliminary IoT Lab Architecture and Components
A loose coupling
between client and
service via broker.
Broker ensures the
information flow is
established between
Publish/subscribe
17
D1.2 Preliminary IoT Lab Architecture and Components
18
D1.2 Preliminary IoT Lab Architecture and Components
The following diagram illustrates the different levels of the scenario, use cases,
services and requirements:
19
D1.2 Preliminary IoT Lab Architecture and Components
Figure 7: Energy Efficiency and user comfort hints use case diagram
20
D1.2 Preliminary IoT Lab Architecture and Components
The following diagram illustrates the different levels of the scenario, use cases,
services and requirements:
For the two selected scenarios, the common functionalities or the non-experiment
specific functionalities the system must provide to the users are the following:
21
D1.2 Preliminary IoT Lab Architecture and Components
22
D1.2 Preliminary IoT Lab Architecture and Components
23
D1.2 Preliminary IoT Lab Architecture and Components
Mapping of the IoT Lab functional groups and components onto IoT ARM functional
model is illustrated in Table 2.
24
D1.2 Preliminary IoT Lab Architecture and Components
25
D1.2 Preliminary IoT Lab Architecture and Components
26
D1.2 Preliminary IoT Lab Architecture and Components
Platform Architecture
27
D1.2 Preliminary IoT Lab Architecture and Components
Since the IoT Lab project focuses on exploring the crowdsourcing mechanisms
and tools which will enable testbeds to use third party resources such as mobile
phones and tablets, it is important to have a platform that will support the
development of these device functions.
This refers to the capability of the platform to enable end users to design
experiments that will use virtualised resources of the platform even if they belong
to different physical testbeds.
Use of crowdsensing
This refers to leveraging the sensors in crowd mobile devices (smart phones) to
collect and share the data about the user or the physical world. This data is then
analysed and consumed. Compared to the conventional sensor-based
applications, the advantage of crowdsensing is in the capability to contribute
many diverse use cases.
28
D1.2 Preliminary IoT Lab Architecture and Components
The end users participation in crowdsensing can require different levels of their
participation. Data sharing can go from autonomous where no user participation is
needed (just turning the sensing on or off) to fully interactive where the user
should take specific places, routes, measures to improve the sample quality or
even his/her full engagement to provide an input/support for the survey, and
contribute to an ad hoc dash board or similar.
29
D1.2 Preliminary IoT Lab Architecture and Components
7.2 Ushahidi
The Ushahidi [http://www.ushahidi.com/] Platform, that was initially developed to map
reports of violence in Kenya after the post-election fallout at the beginning of 2008,
allows you to easily collect information via text messages, email, twitter and web-
forms. Ushahidi is a web and mobile platform, illustrated with an architecture diagram
below, that allows you to create, visualize and share stories on a map. Stories can be
shared between individuals on their own terms and using the tools they already have.
One of the most powerful ways to visualize information is to display it on a map.
30
D1.2 Preliminary IoT Lab Architecture and Components
7.3 APISENSE
APISENSE [http://www.apisense.fr, http://www.apisense.com/] makes it easy to
collect data with the crowd of mobile phone sensors. Their motto is to Innovate and
give sense on top of real world data feedback, in real time. The Apisense approach
is illustrated in Figure 14.
31
D1.2 Preliminary IoT Lab Architecture and Components
32
D1.2 Preliminary IoT Lab Architecture and Components
33
D1.2 Preliminary IoT Lab Architecture and Components
34
D1.2 Preliminary IoT Lab Architecture and Components
7.5 EpiCollect
EpiCollect [http://www.epicollect.net/] is a generic data collection tool that allows you
to collect and submit geo-tagged data forms (along with photos) to a central project
website (hosted using Googles AppEngine) from suitable mobile phones (Android or
iPhone). These include, for example, questionnaires, and surveys etc. All the data
synchronised (i.e. a copy sent from the phone) from multiple phones can then be
viewed / charted / filtered at the project website using Google Maps / Earth or
downloaded.
EpiCollect.net provides a Web and mobile app for the generation of forms
(questionnaires) and freely hosted project Websites for data collection.
Data are collected (including GPS and media) using multiple phones and all data can
be viewed centrally (using Google Maps, tables or charts).
Furthermore, the data can be requested and viewed/filtered from the project Website
directly on your phone using Google Maps.
EpiCollect approach for the project creation is illustrated with the following figure:
7.6 PhoneLab
PhoneLab [http://www.phone-lab.org] is a public programmable Android testbed
designed to simplify large-scale smartphone experiments. PhoneLab aims to address
some of the common barriers that make the experimentation at scale challenging
attracting participants and collecting data. The PhoneLab participants receive a
discounted service in exchange for their participation in your experiments.
The PhoneLab collects log messages from the experimenter application such as:
Log.v("MyGreatExperiment", "The user did something interesting.").
Preparing a PhoneLab experiment involves multiple steps:
Idea Submission
We begin with collecting some basic information to determine if your experiment is a
good fit for the PhoneLab testbed. We'd like to know what you aim to find out, how
you plan on doing so, and why your experiment can't be done on a smaller scale or
by using an app marketplace.
Once we've approved your idea, we'll need some additional information as well,
including a proof that your experiment has been deemed safe for the human subjects
35
D1.2 Preliminary IoT Lab Architecture and Components
7.7 SmartLab
SmartLab is a first-of-a-kind open cloud of smartphones that enables a new line of
systems-oriented mobile computing research.
Re-programming smartphones and instrumenting them for application testing and
data gathering is currently a tedious, time-consuming process that poses significant
logistical challenges. To this end, we have implemented and demonstrated
SmartLab, a first-of-a-kind open Infrastructure-as-a-Service (IaaS) Cloud that enables
fine-grained control over both real and virtual smartphones via an intuitive web-based
interface. Our current infrastructure is ideal for scenarios that require fine-grained and
low-level control over real smartphones, e.g., OS, Networking, DB and storage,
security, peer-to-peer protocols, but also for scenarios that require the engagement
of physical sensors and geo-location scenarios. Our preliminary edition has been
utilized extensively in-house for our research and teaching activities but it has also
been open to selected research groups around the globe. SmartLab provides a
diverse, high-availability platform that can be utilized by the mobile computing
research community to engage more effectively in systems-oriented research on
smartphones.
SmartLab [http://smartlab.cs.ucy.ac.cy/] supports four modes of user interaction with
the smartphones:
Remote Control Terminals (RCT), a Web-based remote screen terminal for
Android, developed in-house using Ajax that mimics touch screen clicks and
gestures among other functionalities.
Remote Shells (RS), a Web-based shell developed in-house with Ajax that
enables a wide variety of UNIX commands to be issued to the Android Linux
kernels.
Remote Scripting Environment (RSE), which allows users to author Android
MonkeyRunner automation scripts (written in Python) and upload them to the
devices to perform automated tasks.
Remote Debug Tools (RDT) which provide web-based debugging extensions to
the Android Debug Bridge (ADB). Through these tools, SmartLab facilitates
research in smartphone network programming environments, communication
protocols, system design and applications.
SmartLab is currently in testing phase and the source code and documentation are
not available on the web site.
36
D1.2 Preliminary IoT Lab Architecture and Components
7.8 Funf
The Funf Open Sensing Framework is an Android-based extensible framework,
originally developed at the MIT Media Lab for doing phone-based mobile sensing.
Funf provides a reusable set of functionalities enabling the collection, uploading, and
configuration for a broad range of data types.
37
D1.2 Preliminary IoT Lab Architecture and Components
Customize Collection - Build your own custom probes to collect the data you
want. You can extend existing probes or build a new type of probe. You can
even combine data from other probes.
Reliably Store - Let Funf ensure the data is reliably stored, encrypted, and
transparently moved to disks with available space.
Automatically Upload - Gather data from one or more phones automatically by
having the data routinely uploaded to your server.
Analyze - Easily decrypt and merge many data files into one convenient
database.
7.9 AmbientDynamix
AmbientDynamix (Dynamix) [http://ambientdynamix.org/] is a lightweight software
framework that enables mobile apps and websites to fluidly interact with the physical
world through advanced sensing and actuation plug-ins that can be installed on-
demand.
Dynamix comes with a growing collection of ready-made plug-ins and provides open
SDKs that enable 3rd party developers to create and share new plug-in types with
the community.
Dynamix runs as a background service on the users mobile device, leveraging the
device itself as a sensing, processing and communications platform. Applications
request context support from a local Dynamix instance using simple APIs. Dynamix
automatically discovers, downloads and installs the plug-ins needed for a given
sensing or actuation task. When the user changes environments, new or updated
plug-ins can be deployed to the device at runtime, without the need to restart the
application or framework. Dynamix is released under the Apache 2 open source
license.
Dynamix Service is situated between a devices local hardware and (potentially
many) Dynamix apps, which execute in their own runtime processes. Dynamix
supports two principal app types:
Native apps
Web apps
Native apps are defined as standard Android applications that communicate with a
local Dynamix service using its AIDL-based application programming interfaces
(APIs), which are included in the App SDK. These interfaces include an AIDL Facade
API, which enables apps to request and control context support; and an AIDL Event
API, which enables apps to receive framework notifications and context events.
Web apps are hosted by native Web browsers, such a Google Chrome and Firefox.
To support communication with browser-based Web apps, Dynamix exposes two
local REST-based APIs using a customized Web server that is embedded within the
Dynamix Service. Web apps communicate with Dynamix via Ajax, using two provided
JavaScript support files that simplify service binding, API interactions, data
serialization/deserialization, error handling and event processing.
38
D1.2 Preliminary IoT Lab Architecture and Components
39
D1.2 Preliminary IoT Lab Architecture and Components
7.10 Compose
The Compose project (FP7-ICT) [6] acronym for Collaborative Open Market to Place
Objects at your Service aims at building a marketplace that allows SMEs and
innovators in general to introduce new IoT-enabled services and/or applications
without the need of deep technical knowledge. In this approach, devices also called
smart objects are associated to services and can be combined, managed, and
integrated in a standardised way. Compose aims at converging IoS with the IoT and
the Internet of Content (IoC), through a simple to use UI (Node-Red) which users can
drag-and-drop and connect services and smart objects in order to build their services.
Compose provides an IoT Platform as a Service with components that provide
functionalities such as service discovery, device communication (different IoT
protocols), different service APIs and security. Figure 23 depicts the architectural
high level components.
40
D1.2 Preliminary IoT Lab Architecture and Components
7.11 CitySDK
The project CitySDK [7] (City Service Development Kit) aims at providing cities and
developers a set of programming APIs across cities. A range of tools and information
allow the users to easily and rapidly develop, scale and reuse new applications and
services. CitySDK has concentrated on participation, mobility and tourism as the
three main interactions that citizens have with their municipalities. The participation
service is similar to the one previously presented in the SmartSantander project
where the citizens can report problems in the city. Three main APIs: Open311 API,
Linked Data API and Tourism API are now available to developers, which can gain
access to city provided data by exploiting in a uniform way across different cities.
Furthermore, the network of cities is opened and new cities can be included in the
platform. Figure 24 shows the overall picture of the CitySDK Ecosystem and its
components.
41
D1.2 Preliminary IoT Lab Architecture and Components
7.12 Xively
Xively (xively.com) is a cloud platform that implements the concept of Platform as a
Service (PaaS). Figure 25 shows an overview of the Xively platform. Through a set of
REST APIs, Socket protocols and MQTT messages, a set of different Internet of
Things (IoT) objects, generating time series data, can be connect to the Data
Services, which provides storage functionalities for different time series. A set of
different enablers is already available in order to allow easy connectivity of the most
common platforms, such as Arduino and ARM mbed devices. Each connected device
and its associated time series can be seamlessly searched and shared in order to
build services, by creating different Xively applications which make use of the same
Xively APIs, specifically their READ counterpart. A set of iOS, Android and
JavaScript libraries are provided in order to visualize the data collected from different
time series.
While Xivelys main aim is to provide a platform that should allow easy connection of
IoT devices and the sharing of data. This will allow developers to focus on their
services development and their business logic. However, due to the well-defined
Xively APIs and the growing list of supported devices, Xively can also be seen as a
crowdsourcing platform where streams generated by different IoT devices can be
collected and virtualized, in order to be abstracted and treated in a homogeneous
way toward the production of IoT services. For non-commercial usage, the Xively
access is free.
42
D1.2 Preliminary IoT Lab Architecture and Components
43
D1.2 Preliminary IoT Lab Architecture and Components
5 EpiCollect Yes.
It is an open- Yes N/A N/A N/A
source project.
44
D1.2 Preliminary IoT Lab Architecture and Components
5 EpiCollect YES
Allows collection and
N/A N/A NO submission of geo-tagged
data forms such as
questionnaires and
surveys (along with
45
D1.2 Preliminary IoT Lab Architecture and Components
46
D1.2 Preliminary IoT Lab Architecture and Components
2 Ushahidi YES
Supports creation, Allows a user to quickly
visualization and sharing NO NO? create interactive maps
stories on a map. filled with multimedia
information.
3 APISENSE YES
Yes (use interactions)
Enables/supports easy
data collection with the Possible to push sensing
YES N/A and/or survey crop with
crowd of mobile phone
sensors. temporal and
geographical context.
4 McSense
YES N/A YES N/A
(ParticipAct)
47
D1.2 Preliminary IoT Lab Architecture and Components
6 PhoneLab YES
System provides a set of
Android phones for It can be implemented in the It can be implemented in
NO
experiment execution. application the application.
Collected data are from
logging.
48
D1.2 Preliminary IoT Lab Architecture and Components
49
D1.2 Preliminary IoT Lab Architecture and Components
50
D1.2 Preliminary IoT Lab Architecture and Components
the internet.
51
D1.2 Preliminary IoT Lab Architecture and Components
IPv4-to-IPv6
802.15.4-to-WiFi
The testbed resources are stored in a Resource Directory that contains all necessary
information regarding the wireless sensor network. It provides information on the
available resources of the network (resource discovery). The Resource Directory is
installed along with the gateway on a webserver.
The testbed provides some web tools in order to access the sensor data.
52
D1.2 Preliminary IoT Lab Architecture and Components
Architecture
The architecture of the testbed follows the architecture of HOBNET. The sensors are
forming a mesh network and can communicate with each other using hops. In order
for the sensors to be accessible from everywhere, a gateway is used. The gateway
(edge router) acts as a proxy between the IPv6 network and the application layer
protocols.
HTTP-to-CoAP
IPv4-to-IPv6
802.15.4-to-WiFi
The testbed resources are stored in a Resource Directory that contains all necessary
information regarding the wireless sensor network. It provides information on the
available resources of the network (resource discovery). The Resource Directory is
installed along with the gateway on a Web server.
53
D1.2 Preliminary IoT Lab Architecture and Components
54
D1.2 Preliminary IoT Lab Architecture and Components
the Internet from the testbed portal and the TMON 0 stand-alone application.
Additionally a data-provisioning server can be accessed and queried using REST
APIs in order to gain access to all the data generated by the testbed.
55
D1.2 Preliminary IoT Lab Architecture and Components
56
D1.2 Preliminary IoT Lab Architecture and Components
57
D1.2 Preliminary IoT Lab Architecture and Components
Web/mobile
Platform clients
Web/mobile
clients
Web/mobile
clients
EB700
device
EB700
device EB700
device
58
D1.2 Preliminary IoT Lab Architecture and Components
There are only 10 static sensors, deployment of personal sensor packs and mobile
applications are planned within the following year.
59
D1.2 Preliminary IoT Lab Architecture and Components
60
D1.2 Preliminary IoT Lab Architecture and Components
1
IoT Lab stakeholders are identified and discussed within WP6 in collaboration with WP5. For the scope of WP1
we will only consider the subset of stakeholders that at this stage have a more direct relation to the envisioned
platform and these are participants, investigators and testbed owners.
61
D1.2 Preliminary IoT Lab Architecture and Components
The platform must allow the participants The platform must allow the user to
to manage their personal profiles. By create and manage his or her personal
Personal default, the information needed to profile. By default, this profile requires
create an account is minimal (privacy minimal information.
by design).
62
D1.2 Preliminary IoT Lab Architecture and Components
The system must provide ways that The system must provide ways that
allow the participant to give his or her allow the investigator to score an
feedback on an experiment. This can experiment; this can be done through a
Score be a simple grading of stars or a form in simple 0 to 5 star rating.
case the user participated in the
experiment where it is asked his/her
opinion about it.
The system must allow the participants The system must allow the investigator
to see the results of an experiment to see the results of his or her
See results
taking into account data privacy. experiment. It also should allow
data access and
Moreover, the participants must be able exporting the results to external tools.
management
to visualise the data that they
generated for this specific experiment.
63
D1.2 Preliminary IoT Lab Architecture and Components
64
D1.2 Preliminary IoT Lab Architecture and Components
The system must provide ways that The system must provide ways that
allow the participant to get help from allow the investigator to get help from
Help the support team. This can be done the support team. This can be done in
through messaging. the forum or by writing a message to
the support.
The platform must allow the participant The platform must allow the investigator
to search for specific experiments. to search for specific experiments.
Experiment Filters such as experiment domain, Filters such as experiment domain,
status, type of needed resources can status, type of needed resources can
be applied. be applied.
Search
The system must provide ways that
allow the participant to search for other
Participant
participants; this can be for instance to
find nearby participants.
65
D1.2 Preliminary IoT Lab Architecture and Components
Table 7 Main platform features, resources and tools of interest for stakeholders
We may have to add the following features:
Experiment management
Data access and management
Data visualization: maps and graphs
Payment / financial retribution
Experiments reporting
66
D1.2 Preliminary IoT Lab Architecture and Components
In order to satisfy the above requirements, a unique platform, with respect to the
existing ones, will be designed and implemented as the IoT Lab platform.
Virtualization will be required in order to overcome the heterogeneous nature of the
different resources available in the IoT Lab enhanced testbeds and to provide
homogenous access to all the resources. By following the Fed4FIRE model, all the
IoT Lab testbeds will be interconnected and the different provided resources will be
virtualized and made accessible in a uniform way. Additionally, the existing resources
will be extended with crowdsourcing resources provided by mobile phones. In order
to support such integration, a common resource model will be required. Different from
existing platforms that mainly focus on a single type of resource, either mobile
smartphone or static sensor motes, the IoT Lab platform will have to accommodate
the characteristics of both these resource types.
Additionally, in order to perform integration of such resources, the IoT Lab platform
should provide tools for supporting and managing both types of resources that might
highly differ in terms of capability and interaction model. For this reason, the
designed IoT Lab architecture and the resulting platform will have to deal with the
complexity of this new interaction model, between resources of different nature, in
case of experiments requiring both static sensor motes available in existing IoT Lab
testbeds and crowdsourcing mobile phones. While testbed resources might be
available or not and this information can be gained by simply using lookup tables
provided by a well-defined Resource Manager, selected crowd resources might be
available only temporarily and with some constraints in a dedicated time frame. For
all these reasons, existing platforms should first of all expose a resource model able
to characterize both, existing static testbed resources and crowd resources, thus
including the combination of participants and their respective mobile phones, with
associated participation profile. A novel Resource Manager able to collect different
resource availability and select for adequate resource according to experiment
specification, represent IoT Lab related features that is not present in other existing
platforms. For instance, according to the participant participation profile, different
ways to select resources from the crowd could be envisioned and supported by
dedicated platform tools for the selection of such participants. This will require the
definition and the support of adequate Profile Management tools supported by the
IoT Lab or other existing platforms.
Additionally, due to the mixed nature of the envisioned IoT Lab experiments that
might require crowd participation in the sensing and actuation process (such as
surveys compilation, pictures and audio capturing and annotation, etc.) and
interaction with existing testbed resources, a new experimentation model able to
capture the heterogeneous nature of such experiments will be supported by the IoT
Lab platform. This will result in a novelty with respect to existing platforms that mainly
focus on experiments with only one kind of resource. For this reason, a unique IoT
Lab Experiment Management tool should be supported by the developed platform.
According to the IoT Lab envisioned experiment model, a set of new tools for
researchers and investigators to control resources and to design and control
experiments and surveys will be required, making the IoT Lab platform different from
existing ones. Tools for browsing and selecting existing and heterogeneous
resources matching specific experiments criteria should be made available to
experimenters (Search). In addition, tools for searching experiments and rating them,
along with tools for participants rating and reward are envisioned by IoT Lab in order
to support experiment resource selection according to participants reputation, other
67
D1.2 Preliminary IoT Lab Architecture and Components
68
D1.2 Preliminary IoT Lab Architecture and Components
69
D1.2 Preliminary IoT Lab Architecture and Components
application. McSense seems to have all the basic functionalities envisioned in the
IoT Lab mobile app (action and sensing), of which the IoT Lab platform should be
comprised, and includes also tools for resource selection, task (and experiments)
description and more useful functionalities. For all these reasons, the possibility to
integrate and extend it with other IoT Lab resources, such as integration with FIRE
testbeds Profile Management and Search and Communication tools should be
investigated further.
For all these reasons, the platforms that should be selected and further analysed to
understand their integration in the final IoT Lab platform are represented by
AmbientDynamix and McSense.
Compose project is particularly interesting for IoT Lab in respect to the Testbed as a
Service part of the architecture, we have initiated discussions with some members of
the consortium in order to further analyse possible synergies between the two
projects in these points and furthermore, consider possible exchange of knowledge
and/or components that best suit the objectives of both projects. The outcome of this
task will feed the architecture design in the second iteration of the project.
Regarding the CitySDK project, conversations with members of this project have
been initiated in order to further analyse the architecture and possible synergies., We
will take particular interest in the provided user tools for service development and
analyse the technical details of the participation use cases. Possible inputs to the
architecture will be presented in the second iteration report.
70
D1.2 Preliminary IoT Lab Architecture and Components
Cloud server. The data are stored in a database and can be later used to create
visualizations and extract useful conclusions. Moreover, OML can be used to collect
data from running experiments.
71
D1.2 Preliminary IoT Lab Architecture and Components
72
D1.2 Preliminary IoT Lab Architecture and Components
Figure 36 IoT Lab Architecture A deployment view of the proposed concrete architecture
73
D1.2 Preliminary IoT Lab Architecture and Components
This project has received funding from the European Unions Seventh Framework Programme for
research, technological development and demonstration under grant agreement no 610477.
D1.2 Preliminary IoT Lab Architecture and Components Specification
All individual testbeds should follow a common description scheme for announcing
their available resources to the IoT Lab platform. This would provide a common
understanding of the available resources and would enable the IoT Lab platform to
handle available resources in a uniform manner. Testbeds should also implement a
resource discovery mechanism that will announce their available resources following
the RSpecs format of the Slice-based Facility Architecture (SFA). The purpose of
SFA 0 or belonging to different administrative domains to federate without losing
control of their resources.
75
D1.2 Preliminary IoT Lab Architecture and Components Specification
76
D1.2 Preliminary IoT Lab Architecture and Components Specification
77
D1.2 Preliminary IoT Lab Architecture and Components Specification
78
D1.2 Preliminary IoT Lab Architecture and Components Specification
79
D1.2 Preliminary IoT Lab Architecture and Components Specification
80
D1.2 Preliminary IoT Lab Architecture and Components Specification
81
D1.2 Preliminary IoT Lab Architecture and Components Specification
12. References
[1] IoT-A: Internet of Things Architecture, www.iot-a.eu/
[2] OML http://www.fed4fire.eu/tools/oml.html
[3] SFA WRAP, http://sfawrap.info/
[4] D1.1 IoT Lab end-user requirements report
[5] IoT-A: Deliverable D1.5 Final architectural reference model for the IoT v3.0
[6] M. Nati and A. Gluhak and H. Abangar and W. Headley. SmartCampus: A user-
centric testbed for Internet of Things experimentation.
[7] Compose Project, http://www.compose-project.eu
[8] CitySDK project, http://www.citysdk.eu
82