IoT - Lab D1.2

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)
Deliverable D1.2
Preliminary IoT Lab Architecture and Component Specification
Contract Due Date 30/09/2014
Submission Date 12/09/2014
Version v1.0
Responsible Partner Srdjan Krco (DNET)
Author List Michele Nati, Joao Fernandes, Stevan Jokic,

Aleksandra Rankov, Srdjan Krco, Sebastien Ziegler,
Marios Angelopoulos, Theofanis Raptis,
Dissemination level PU
Keywords Internet of Things, Crowdsourcing, Lab, Testbed, FIRE
Project Coordinator: Mandat International (MI)

Sbastien Ziegler <sziegler@mandint.org>
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
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
7.11 CitySDK ...................................................................................... 41

7.12 Xively .......................................................................................... 42
7.13 Crowdsourcing Platforms Summary ........................................ 43
8. Review of Existing Architectures of Individual Testbeds ............................. 50
8.1 WISEBED testbed @ University of Geneva ................................ 50
8.2 HOBNET testbed @ University of Geneva ................................. 51
8.3 HOBNET testbed @ CTI ............................................................. 52
8.4 Smart Campus testbed @ University of Surrey .......................... 54
8.5 HEPIA and Champ-Baron testbed @ MI .................................... 55
8.6 CS testbed @ Belgrade .............................................................. 57
8.7 mojNS testbed @ Novi Sad ........................................................ 59
9. Adaptation of Existing Platforms.................................................................... 61
9.1 Gaps in Existing Platforms wrt IoT Lab Platform requirements ... 61
9.2 Platform Selection....................................................................... 69
9.3 Selected Platform Adaptations.................................................... 70
10. Proposed IoT Lab Architecture ....................................................................... 72
10.1 IoT Lab Components: SW Architecture ...................................... 72
10.1.1 Account Manager..................................................................... 74
10.1.2 Resource management ........................................................... 74
10.1.3 Experiment Manager ............................................................... 75
10.1.4 Web user interfaces ................................................................. 76
10.2 Sequential View Use of Services ............................................. 77
10.2.1 User Registration Process ....................................................... 77
10.2.2 Experiment Submission ........................................................... 78
10.2.3 Contribution from Crowd/ Testbed Resources ......................... 79
10.3 IoT Lab Components: HW Architecture ...................................... 80
11. Conclusions and Future work ........................................................................ 81
12. References ........................................................................................................ 82
4
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
5
Figure 32: CS Testbed Architecture ....................................................................................................... 58

Figure 33: Web and Android based AR visualization ............................................................................ 59
Figure 34: mojNS functional diagram ................................................................................................. 60
Figure 35: IoT Lab enablers - generic .................................................................................................... 68
Figure 36 IoT Lab Architecture A deployment view of the proposed concrete architecture ............ 73
Figure 37: User Registration Process (Sequence Diagram) ................................................................... 77
Figure 38: Experiment Submission (Investigator side) .......................................................................... 78
Figure 39: Contribution from the Crowd/Testbed Resources ............................................................... 79
Figure 40: HW Architecture ................................................................................................................... 80
6
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
2. Terminology/Glossary
Term Definition
IoT-A Internet of Things Architecture
ARM Architecture Reference Model
FIRE Future Internet Research and Experimentation
Fed4Fire Federation for FIRE
Protocol API Application Programming Interface: Components that are used to

provide access to the IoT devices using specific protocols and
semantics.
CRUD Create, read, update and delete
WP Work package
SOTA State of the Art
REST Representational state transfer (REST): A way to create, read,

update or delete information on a server using simple HTTP calls.
SFA Slice-based Facility Architecture or SFA: Provides a minimal

interface that enables testbeds of different technologies and/or
from different administrative domains to federate without losing
control of their resources.
SFA WRAP Providing heterogeneous testbeds (e.g. coming from different EU

projects) with the way to plug their resources into a global SFA
federation and attract external users as well as provide internal
users with the access to other heterogenous resources.
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
DoW Description of Work
FG Functional Group
wrt With respect to
PaaS Platform as a Service
AAA Authentication, Authorisation and Accounting
P2P Peer-to-peer protocol
RSS Rich Site Summary
8
SMS Short Message Service
HTTP Hypertext Transfer Protocol
LGPL GNU Lesser General Public License
SCA Service Component Architecture
IaaS Infrastructure as a Service
OS Operating System
DB Database
RCT Remote Control Terminal
RS Remote Shells
RSE Remote Scripting Environment
RDT Remote Debug Tools
ADB Android Debug Bridge
SDK Software Development Kit
AIDL Android Interface Definition Language
IEEE Institute of Electrical and Electronics Engineers
6LoWPAN IPv6 over Low power Wireless Personal Area Networks
CoAP Constrained Application Protocol
GSM Global System for Mobile Communications
GPRS General Packet Radio Service
RFID Radio-frequency identification
NFC Near-field communication
IP Internet Protocol
TCP Transmission Control Protocol
UDP User Datagram Protocol
RD Resource Directory
RLI Resource Lookup Interface
RMI Resource Management Interface
GUI Graphical user interface
9
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.
3.2 Purpose and Scope of Task T1.2 on Architecture Design

In this task, we design and describe the IoT Lab architecture based on the technical
and end-user requirements defined in Task 1.1. The first approach will take different
emerging FIRE architectures to be analysed and considered as a basis for the
architecture design and specification. The architecture will also include specific IoT
Lab extensions in order to address the specific IoT Lab requirements. These
extensions will consider and support, for instance, an ad-hoc organised, dynamic
setup of experimental infrastructure to enable a simple mechanism while ensuring
issues like reliability and privacy are handled efficiently in a collective environment of
a small or large community. The architecture design will also take into consideration
built-in reputation and privacy mechanisms, as well as a dynamic selection of suitable
crowd resources and optimal experiments scheduling. The architectural model will
be iteratively addressed and taking into account the technical work carried out in the
technical work packages.
The architecture design will identify the main system components and their
functionalities, interaction patterns, interfaces as well as the underlying
communication links and mechanisms required for maintenance of such systems.
Finally, the fulfilment of the requirements defined in Task 1.1 and the other technical
work packages as well as their evaluation will be done in this task and taken into
consideration for the architecture design updates.
10
3.3 Purpose and Scope of the Document

It is the objective of this document to describe the scope of the Task 1.2 work carried
as described in the previous section. This description includes the overall
methodology to be followed for describing the architecture and its components,
followed by an overview of the envisioned use cases and their requirements, an
extensive crowdsourcing SOTA analysis of existing FIRE and non-FIRE platforms, as
well as existing architectures of individual testbeds. After this initial analysis, we
investigate possible adaptations to the existing platforms in order to cope with the IoT
Lab specific requirements and propose an initial IoT Lab architecture. The following
figure au-dessous shows the overall work sequence carried out and the interactions:
Figure 1: Task 1.2 Sequence and interactions

The overall IoT Lab architecture will be periodically revisited due to new possible
technical requirements or updates to already existing ones based on results of the
work carried out in the technical work packages and/or new experiments/ideas
coming from the crowd. D1.2 (Preliminary IOT Lab architecture and component
specification); D1.3 (Updated IoT architecture and components specification); and
D1.4 (Final IoT Lab architecture and components specification) will document the
architecture evolvement during the project.
3.4 Structure of the Document

The structure of the document is as follows: In Chapter 4, we provide a
comprehensive and detailed description of the methodology to be followed for
describing the IoT Lab architecture (IoT-A ARM). Chapter 5 provides a summary of
the selected use cases, including their main functionalities and requirements.
Chapter 6 discuss an initial picture of the high level architecture including a
presentation of the functional and information flow views. Chapter 7 provides an
extensive review of existing crowdsourcing solutions with respect to identified
important platform features. A review of the individual testbeds architectures is
provided in Chapter 8. Chapter 9 discusses the adaptations of existing platforms in
order to cope with the IoT Lab requirements. In Chapter 10 an initial deployment view
of the proposed IoT Lab architecture that includes a description of the main
components and their interactions is presented. Conclusions and future work
summarise the document in Chapter 11.
11
4. IoT Lab: Approach to Architecture Design

4.1 Introduction to IoT-A methodology
There are already a large number of IoT solutions developed; however, most of them
are for specific application silos each based on different architectural concepts
preventing communicate amongst themselves. The lack of a unified holistic approach
limits the potential of IoT, therefore, we can address only Intranet of Things.
In order to connect these silos and make them communicate regardless of the device
type and application domain, it is necessary to follow the concepts that facilitate
interoperability between these island applications.
The EU-funded project IoT-A [1] considers these problems and provides a good basis
for enabling the Internet of Things.
4.2 IoT-A ARM: Building Interoperable Concrete IoT Architectures

The aim is to build an IoT Lab architecture which supports and enables
interoperability and scalability and therefore, the use of a wide range of
heterogeneous devices and testbeds from different application domains meeting a
high number of requirements.
The architecture should not be too complex and the number of components and
protocols used should be optimal.
In order to achieve this, the IoT-reference architecture [1] can be used as a base for
designing the IoT Lab architecture together with the IoT-A Architecture Reference
Model. ARM goes one level beyond IoT-A and defines the reference model, which
provides the basis for a common understanding of the IoT domain by modeling its
concepts and relationships.
The use of IoT Architecture Reference Model (IoT-A ARM) as an input and
foundation of the IoT Lab architecture specification is recommended for the following
reasons:
Represents the Communication Aid: It provides a common language for
everyone involved on identifying and specifying the components of an IoT
system so that different architectural views can easily be compared.
Provides Common Concepts: Enables definition of IoT entities, interactions and
relationships with each other through the use of common concepts provided by
ARM for building compliant IoT systems.
Aids compliant architecture design and generation: Through use of best
practices and thus enables the generation of interoperable IoT systems.
Facilitates benchmarking: Through the use of standardized description providing
a high level transparency in components description and intrinsic comparability
to the benchmarking process.
Overall, following the structure and classic functionalities of IoT systems which are
defined and set by IoT-A, the IoT Lab architecture can be created by focusing only on
the main aspects of the project. In addition, the IoT-A methodology also provides a
range of functional and information flow views (decomposition diagrams, use cases,
interaction diagrams, interfaces, sequence charts) which can be reused easily.
The process used to build the Actual System is as follows:
12
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.
Figure 2: Relationship between reference architecture, architectures and actual

systems (taken from IoT-A [1])
Best practices are used as guidance for deriving the use case specific (concrete)
architectures from the reference architecture.
13
4.2.1 IoT-A Architecture Generation Process

IoT-A provides a methodology for the IoT-system architecture design. This
methodology enables generation of a set of views that completely define the target
architecture: physical view; context view; functional view; information view;
operational view and deployment view.
The generation process is illustrated in Figure 3. It includes:
Steps that align with the business goals.
This assumes specifying the purpose of the IoT system through a business model
definition which is described in detail in IoT Labs DoW document.
A process for deriving the requirements of the targeted IoT system.
A full process for deriving the requirements of the IoT system is specified in IoT-A.
IoT-A also provides a comprehensive list of functional and non-functional
requirements (UNI) that are applicable to any IoT system. These can be mapped to
different views of the proposed architecture.
Guidance for creation and derivation of above views needed for the complete
target architecture design.
Figure 3: IoT architecture generation process [source: IoT-A 0]
14
4.2.2 Functional View (IoT-A ARM Building Blocks)

The IoT-A Architecture Reference Model defines a set of functional groups and
components that can be found in any IoT system. These groups and components
result from mapping the unified requirements and they are presented in Figure 4. A
brief description of IoT system functional groups (FGs) is provided here 0.
Device can be either a sensor or tag which will measure something and/or
provide the information to the system, or an actuator which will modify the system
based on some input/measurement.
Communication FG Represents a concept that models a variety of interaction
schemes resulted from many technologies that belong to IoT systems and
providing a common interface to IoT Service FG.
IoT Service FG Contains services and functionalities for discovery, and look up
of IoT services.
Virtual Entity FG Contains functionalities that enable interaction with the IoT
System on the basis of VE and also the functionalities for discovery and lookup
services to get the information or to interact with the VEs as well as for managing
and dynamically finding new associations and monitoring their validity.
Service Organisation FG Composes and orchestrates services of different
levels of abstraction.
IoT Process Management FG Help in integrating a traditional business
process management with the IoT ARM through new functional concepts and
interfaces.
Management FG Responsible for the following functionalities: configuration of
devices, fault tracking, monitoring, reporting, maintenance and/or administration
of the whole IoT system.
Security FG Responsible for ensuring the security and privacy of IoT A
compliant systems.
Application FG Represents the application/end user interacting with the
application.
Figure 4: Functional view IoT System groups and components [1]

More detailed information with description of all the components can be found in 0.
15
4.2.3 Information (Flow) View

The flow of data between different functional groups and components is defined in an
information (flow) view. The information exchange between IoT functional
components depends on the observed use case and it follows four patterns as
described in in Table 1 0.
Table 1: Information flow patterns
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
method. Clients can

continue with other
tasks and process
notification when it
arrives. Server can
multiply notifications to
clients with the same
subscriptions.
More powerful server
required (records of
subscribers and
subscription types)
16
A loose coupling
between client and
service via broker.
Broker ensures the
information flow is
established between
Publish/subscribe
service and client upon

client interest in
specific information.
Regardless of the
number of interested
clients/subscriptions,
the service can publish
information to the
broker and the broker
will then multiply the
information and notify
each subscriber.
17
5. Use Cases Portfolio

In this chapter, we begin an architecture generation process through the analysis of
technical and end user related requirements derived from use cases selected in Task
1.1 0.
5.1 Selected IoT Lab Scenarios and Use Cases

A summary of selected IoT Lab scenarios, including a brief storyboard of the scenario
and its description following the IoT-A ARM specification is presented in this section.
5.1.1 Smart City Scenario

The first selected scenario is the Game and Supermarket Marketing use case
where the users can play a game and participate in experiments, for instance a
market survey from a supermarket. A detailed description of the scenario can be
found in D1.1 0. The following use case diagram depicts the main interaction
between the users and the system in this scenario.
Figure 5: Game and Supermarket Marketing use case diagram
18
IoT Context View
The following diagram illustrates the different levels of the scenario, use cases,
services and requirements:
Figure 6: Supermarket marketing scenario diagram
19
5.1.2 Physical Testbed Scenario

In the second scenario named Energy Efficiency and user comfort hints crowd
sensing is used to adapt energy efficiency to crowd presence and behaviour,
moreover the users can give feedback on the current devices setup and set their
user preferences. The detailed description of the scenario can be found in D1.1.0.
The following use case diagram shows the main user interactions with the system:
Figure 7: Energy Efficiency and user comfort hints use case diagram
20
IoT Context View
The following diagram illustrates the different levels of the scenario, use cases,
services and requirements:
Figure 8: Physical testbed scenario diagram
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
Figure 9: IoT Lab General Use Case Diagram
22
5.2 Summary of Requirements

In this section, a summary of the requirements for the IoT Lab platform is provided:
User profile management for both participants and investigators.
Experiment Configuration Investigators must specify a detailed description of
their experiments, including needed resources, ethics and privacy concerns,
timeline and overall objectives of the experiment.
Testbed Resources Management A simple and easy interface that allows
testbed managers to configure and make their resources available for
experimentation.
Crowdsourcing and Crowdsensing provisioning The platform must provide
ways that allow both crowd and testbed resources to provide data which can be
sensory data and/or crowd knowledge.
Experiments Management The system must provide ways that allow the users
to browse and evaluate existing experiments and in the case of the investigators
to manage their own experiments.
Privacy and Ethics Privacy by design concept is followed, users are requested
minimal information and for each of the experiments a clear description of the
required data (user and device) is presented. Experiments must be validated
before being run.
Support for incentives Incentive for crowd and investigators.
A detailed list of requirements can be found in D1.1 report 0.
23
6. High Level IoT Lab Architecture

Based on the requirements identified in D1.1 and summarized in the previous
section, this section presents the top level functional and information flow view of the
IoT Lab platform.
The main identified components of the targeted IoT Lab platform, which can be seen
as a Platform as a Service (PaaS) are:
IoT Lab accounts manager: The purpose of this component is to setup and
manage the participants accounts, including the researchers/experimenters
access and personal accounts.
IoT resources management interface: This interface is based on Fed4FIRE
enablers who enable interactions with IoT components from the testbeds and
the smart phones.
Crowd interaction management interface: This interface should handle the
interaction with the participants, including editors to set up survey and to design
ad hoc experimentation GUI, and to access the collected data, etc. This part will
be completely independent from Fed4FIRE.
6.1 IoT Lab Platform Functional View

Functional view of IoT Lab architecture is provided in Figure 10.
Figure 10: Functional View of IoT Lab Architecture
Mapping of the IoT Lab functional groups and components onto IoT ARM functional
model is illustrated in Table 2.
24
Table 2: Mapping IoT Lab FGs and FCs to IoT ARM
IoT Lab IoT ARM
Mobile (Android) application, Web Application

application
Configuration, Membership Management
Crowd: WLAN, Bluetooth Communication

Testbeds/Interface: Fed4FIRE, SFA
Protocols: http, https (RESTful), CoAP
Service organisation Service Organisation
Experiment Management: validation, IoT Process Management (Process

configuration, scheduling, storing, Modelling and Execution)
browsing, evaluation
Selection of participants/resources for the Virtual Entity

experiment
Resource Monitoring; Resource IoT Service

Discovery, Registration;
Participant/Resource Selection
Security (Privacy by Design): AAA, Security

Identity Management, Trust & Reputation.
Incentives Schemes, Anonymisation
Sensors, crowd knowledge (crowd) Device

Sensors, Actuators, (testbeds)
6.2 IoT Lab Platform Information Flow View

Information view as proposed by IoT-A describes the flow of data and
interaction/dependency of components involved in this flow as described in Section
4.2.3. The view presented here corresponds to the general IoT Lab use case
illustrating the flow of information/data starting with the users secure
registration/login via experiment submission, validation and allocation of resources to
data collection/storing and evaluation.
25
Figure 11 IoT Lab: Information flow view
Table 3 IoT Lab: Information flow description
1. Auth.req/resp. User performs registration/login to the platform.
2. Post exp.msg - Posting the formatted experiment to the

>validation&conf.. validation and configuration component.
If successful, this component prompts Selection
of Resources and initiates subscription of
Scheduling component to Resources.
3. Schedul.subscribe to Retrieves matched resources.
Selection
4. Sel.requests resources Request for resource reservation.
5. Discovery subscribe to This enables retrieval of new available resources

Registration that match the experiments requirements.
6. Devices through AAA & Data collection and storage.

anonymisation post data The storage of the crowd sourced/sensed data is
to Storing preceded by anonymisation in order to separate
the data from data owners.
7. Publish data mng.->user Once stored data is available to the user, it can
be further analysed/evaluated.
26
7. Review of Existing Crowdsourcing Solutions

Crowdsourcing is recognised as a practice of obtaining needed services, ideas, or a
content by soliciting contributions from a large group of people and especially from an
online community, rather than from traditional employees or suppliers.
The crowdsourcing approach can apply to a wide range of activities including
crowdsourcing of data, measurements, opinions, solutions and funding. The main
focus here is on IoT attractive types of crowdsourcing such as collection of
data/measurements and user rates/opinions. The crowdsourcing platforms presented
here are summarised at the end of this section from the point of view of IoT Lab
important criteria/requirements which include:
Platform openness and extensibility
In order to extend the functionalities of existing platforms to fully match IoTLab

requirements, it is important that the platform is open and the source code
available. This will enable and facilitate modification for IoT Lab purposes.
Therefore, the important features include:
Plugin support and code base extensibility: Through addition of plug-ins or new
functional blocks.
Platform dependency: This refers to the ability of the platform to be installed on
any server.
Free to use.
Code license Free, open source or commercial
Documentation Documentation describing the selected platform

availability architecture and its functionalities is necessary for the
further platform development and extension required
for building the IoT testbed infrastructure as specified
in IoT Lab project.
Plug-in support and Usually enabled through addition of plug-ins or new

code base functional blocks.
extensibility
Platform dependency This refers to the ability of the platform to be installed

on any server. (The deployment phase can be
simplified if the solution uses the cloud installation of a
platform but that limits the control of the platform).
Platform Architecture
Control plane: Centralised or distributed

Data plane: Hierarchical/client-server or flat/p2p
27
Support for privacy, security and trust

Subject to European personal data protection norms
The important aspect of this criterion is the capability of the platform to carry out
the user account management, authentication, authorization and accounting
(AAA) setting the access control to the platform as well as the underlying security
characteristics. Based on this, the important sub-criteria for assessing the
platforms are derived and they include:
Identity management (single, multiple, anonymisation).
Data sharing mechanisms.
Access control mechanisms - privacy aware and secure data sharing
depending on context.
Encryption support.
Reputation schemes.
Remote experimentation capability
Experimenters user interface to enable building ad hoc experiments
Mobile device (smart phones) experimentation support
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.
Use of physical testbeds
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.
Use of interactions with end-users
28
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.
7.1 Smart Santander Pulse of the City

As part of the EU FP7 project SmartSantander (http://smartsantander.eu), a mobile
crowdsourcing application was developed (Android and iOS platforms are
supported). Through use of this application, the citizens of Santander can share and
receive events of what is happening in the city. This includes, for instance, traffic
jams, cultural events, or even problems such as a hole in the pavement so that the
municipality can be informed and react.
Figure 12: SmartSantander - Pace of the City logical architecture

The application covers both crowdsourcing and crowdsensing capabilities, where
sensory information from the mobile phones is periodically sampled and sent to the
platform (the user can select the sensors and the sampling periodicity). For the
crowdsourcing part, the application only considers events as knowledge coming from
the crowd. When the application starts, it registers to the SmartSantander platform,
where a device identifier is generated at server side. This way no unique information
is sent from the device, keeping the user and the device anonymous.
The general ideas of the crowdsensing and crowdsourcing capabilities can be reused
by the IoT Lab application. In the IoT Lab perspective, the crowdsourcing part will be
extended with the possibility that the experimenters can write their specific solutions
(in this case event reporting) to the experiment (survey, specific user input or data
annotations, etc.).
29
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.
Figure 13. Ushahidi architecture diagram

Available platform services and features include:
Crowdmap is a service for mapping anything on the Web focusing more on a social
mapping experience with a better support for multimedia, sharing, and mobile
support. Crowdmap is for anyone wanting to tell a story with a map not only
through location but also by sharing photos, videos, and stories tied to a specific
locations or entire regions.
SwiftRiver is a free and open source platform for helping people to make sense of
large amounts of information in a short amount of time. The mission is to democratize
access to the tools that are used to make sense of data and discover information that
is authentic, accurate and above all relevant - by providing the following capabilities:
Gathering and filtering information from a variety of channels e.g. RSS, Email,
SMS, and Twitter etc.
Drawing insights from the collected information.
Allowing people to create buckets of information using their own expectations of
authority and accuracy as opposed to popularity.
From the IoT Lab perspective, the Ushahidi platform can provide both map
visualization and a data collection. Data can be provided via SMS, e-mail messages
and custom HTTP messages. Community supports security aspects of the platform
and provides updates and patches for reported security issues. The Ushahidi
platform has evolved through several versions and the latest version (v3) supports
the REST API. The platform is free for download and use. It is released under the
GNU Lesser General Public License (LGPL).
30
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.
Figure 14. APISENSE approach
The main objective of APISENSE is to provide a platform for scientists, which is

open, easily extensible and congurable in order to be reused in various contexts. To
achieve this goal, the server-side infrastructure of APISENSE has been designed as
a Distributed Service Component Architecture (SCA) system.
Figure 15. APISENSE web architecture
31
Figure 16. APISENSE mob.app architecture

The official launch of this platform has not happened yet and the project is still in the
beta phase. The announced expected features will include:
Easy crop scripting.
Detection of activity on your crop data.
Cloud supported efficient data transfer and hosting/storage.
Easy crop scripting

This platform allows you to use a high level API and a user friendly documentation to
write your crop script. It is also possible to push sensing and/or survey crop with
temporal and geographical context.
The following illustrates a location example very similar to an Android approach:
Privacy and energy

Each mobile phone owner, with the APISENSE mobile app, has the ability to filter
crops, according to sensors, times or places. Also included transparently are the
smart crop strategies to reduce the energy effort.
Start in no time
It is possible to get the crop up and running in seconds with their cloud. If the user
wants to host their cropped data, an APISENSE version can be provided to enable a
quick operation on a users servers with all functional features.
The platform is open with user friendly documentation available. Platform allows you
to use a high level API.
A platform is good for scientists because it is open, easily extensible and congurable
in order to be reused in various contexts. In terms of use of interactions with end-
users, it is possible to push sensing and/or survey crop with temporal and
geographical context.
32
7.4 McSense (ParticipAct)

McSense ParticipAct is a research project that aims at exploring how and to what
extent the power of collective though imprecise intelligence can be employed in smart
cities. Link to the website is [http://www-
lia.deis.unibo.it/Research/McSense/index.html].
The main visionary goal is to automate the organization of spontaneous and
impromptu collaborations of large groups of people participating in collective actions,
i.e., participAct, such as in the notable case of urban crowdsensing.
In a crowdsensing environment, the people or their mobile devices act as both
sensors that collect urban data and actuators that take actions in the city, possibly
under solicitation/request. Managing the crowdsensing process is a hard task
addressing several socio-technical issues: from the characterization of the regions
under control to the quantification of the sensing density needed to obtain the certain
accuracy.
McSense is a crowdsensing platform that tackles these problems with three main
original technical aspects:
An innovative geo-social model to profile users and regions along different
variables, such as time, location, social interaction, service usage, and
human activities.
A matching algorithm to autonomously choose people to be involved in
participActions and to quantify the performance of their sensing.
A new Android-based platform to collect sensing data from smartphones,
either automatically or with users help and to deliver to them the
sensing/actuation tasks.
The McSense Data Collection Lifecycle consists of three main functions:
Mobile sensing
User/region profiling
Task assignment
Figure 17: McSense ParticipAct big picture architecture

Mobile Sensing
The Smart City Management system strictly interacts with McSense to provide a full-
fledged framework for data sensing including functions to create and describe new
sensing tasks and to analyze the sensed data.
33
By focusing firstly on the McSense subsystem, the mobile sensing is a

comprehensive term used to describe all kinds of sensing activities carried out by
users via their mobile devices, such as recording the noise pollution and taking the
pictures.
Data processing analyses the output of mobile sensing to extract the relevant data for
the active sensing task.
User Profiling
User profiling processes the collected data and aims to profile the user participation
by drawing accurate estimations about their potential involvement in future mobile
sensing tasks.
Region Profiling
Moreover, to avoid long processing operations and to improve the user experience,
McSense includes region profiling to cache already evaluated user profiles, stored by
geo-localized regions, thus exploiting also the physical locality principle (higher
probabilities of similar profiles in the same region).
Task Assignment
Task assignment includes all tools and support components to ease and assist the
design of new sensing tasks, first of all the automatic task assignment.
Figure 18: McSense architecture

As to the Smart City Management subsystem, it includes a Web-based user interface
that offers two main functions:
Data processing and visualization that provides active mapping features and
exploits over-imposed informative visualization layers to show statistics about
completed sensing tasks and collected data.
Task design console, enables the creation and publication of new crowdsensing
tasks.
Distributed architecture of the McSense system is presented in Figure 18.
34
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:
Figure 19: EpiCollect approach

This platform is an attractive solution for a large scale text/form based questioner
collection. Data are stored on the Google App. The platform provides all the data
access, downloading as well as the visualization. The source code is not available for
downloading.
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
and a link to your app on the Google Play Store.

Testing
During the next phase the PhoneLab developers will install and use your app. This is
a chance to ensure that your app is not bug ridden, does not drain the battery, and is
providing the data you are expecting.
Deployment
Once you're app is tested, it's ready for deployment! We'll release your experiment to
our participants and begin tracking their participation and logging data.
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
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.
Figure 20: Funf approach
Figure 21: Funf phone-side architecture: high-level

Funf in a Box helps you create mobile sensing Android app in which no programming
is required. Simply connect your Dropbox account, check off the data you want to
collect, and the app (and later, your data) will appear in your Dropbox. Take the
application, distribute it manually or through the Android Market for a study. Then
forget about managing a server for data collection. It's all in your Dropbox wherever
you are.
Funf platform provides:
Gather Rich Data - Over 30 existing probes to gather a wide array of in depth
data on users' social behavior.
Easily Configure - Setup data collection across multiple devices by loading a
configuration file on the phone, or using the automatic server synchronization.
37
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
Figure 22: AmbientDynamixSystem architecture
39
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.
Figure 23: Compose Architectural high level components
40
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.
Figure 24: CitySDK Ecosystem
41
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.
Figure 25 Xively Overview
42
7.13 Crowdsourcing Platforms Summary

Reviewed crowdsourcing solutions are summarized below with respect to identified criteria (Table 4-Table 6).
Table 4: Review of Existing Platforms - Summary (part 1)
Documentation Code base Platform

Code license Plug-in support
availability extensibility dependency
Platform name
1 Smart Santander Not open N/A N/A N/A N/A
2 Ushahidi Open source

Free to
Yes Supports the REST Supports the REST
download N/A
(released (forums also exist) API (v3) API (v3)
under GNU
LGPL)
3 APISENSE Platform allows Easily extensible and

User friendly you to use a high congurable in order to
Open platform documentation level API N/A
be reused in various
available
contexts
4 McSense Not, currently

(ParticipAct) Documentation
The McSense
available but some N/A N/A N/A
client, server,
and data links do not work
processing
43

source code is
currently not
available for
download.
5 EpiCollect Yes.
It is an open- Yes N/A N/A N/A
source project.
6 PhoneLab Not open N/A N/A N/A N/A
7 SmartLab Not open N/A N/A N/A N/A
8 Funf Open source N/A N/A N/A N/A

under the
LGPL license.
9 AmbientDynamix Open-source N/A N/A N/A N/A

(Apache 2)
10 Compose Open source Yes (tutorials on N/A Can be extended and No

(Apache github) configured
license)
11 CitySDK Not open Yes N/A N/A N/A
12 Xively Not open Yes Yes N/A N/A
44
Table 5: Review of Existing Platforms Summary (part 2)

Support for privacy, Remote
security and trust experimentation
capability
Control plane: Experimenters user
Data plane: Subject to European
interface to enable
Centralised vs Hierarchical/client- personal data protection
building ad hoc
Platform name server vs flat/p2p norms
distributed experiments
1 Smart Santander Participatory Sensing

Device Registration is
Server and Pace of Hierarchical NO
anonymous.
the City Server.
2 Ushahidi Security aspects supported by

community (provides updates YES visualise and create
N/A N/A
and patches for reported stories.
security issues).
3 APISENSE Control plane:

Distributed SCA N/A YES Yes (sensor based)
System.
4 McSense N/A N/A N/A N/A

(ParticipAct)
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
Support for privacy, Remote

security and trust experimentation
capability
photos) from smart phones
(Android and iPhone) .
6 PhoneLab N/A N/A NO
7 SmartLab N/A N/A YES
8 Funf Modular, depends on

YES YES
implementation
9 AmbientDynamics More oriented to the

mobile application NO
development
10 Compose Modular, depends on

Client/Server YES YES
implementation
11 CitySDK City Clusters Client/Server N/A YES
12 Xively Centralized Client/Server N/A NO
46
Table 6: Review of Existing Platforms - Summary (part 3)

Use of Use of crowd sensing Use of
Mobile device
physical interactions with
experimentation
testbeds end-users
support
Support for survey, ad
(Smart phones) Sensors in the smart phones hoc dash board, etc.
Platform name
1 Smart Santander Specific to events

NO NO YES
sharing.
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

Mobile device
experimentation
testbeds end-users
support
5 EpiCollect YES YES
Data synchronisation from Allows collection and
multiple phones and submission of geo-tagged
presentation/filtering at the data forms such as
NO NO? questionnaires and
project website (central
viewing using Google surveys (along with
maps/tables/charts). photos) from smart
phones (Android and
iPhone).
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.
7 SmartLab YES, system provides set

YES, but smart phones are
of Android phones for NO NO
fixed
experiment execution.
8 Funf YES, experiments for YES YES

execution on smart NO
phones can be created
9 AmbientDynamix Yes, capable of

NO YES, collection of readymade YES
leveraging the device as a
plug-ins + SDK for creating and
sensing, processing and
48

Mobile device
experimentation
testbeds end-users
support
communication platform. sharing new plug-in types.
10 Compose Yes, the user can add

YES, links also to social
mobile phones to the Yes. YES, possible.
networks.
platform
11 CitySDK Yes, participation and

YES, participation
mobility scenarios are Yes. YES, participation scenario.
scenario.
supported.
11 Xively Yes, mobile devices can

be connected as any other
NO YES, somehow possible. YES, somehow possible.
devices but for service
production
49
8. Review of Existing Architectures of Individual Testbeds

The existing testbeds developed by project partners which are planned to be used
within the IoT Lab platform through SFA WRAP interface are described. They are
divided into initially implemented testbeds and complementary testbeds.
Initially implemented testbeds:
WISEBED testbed @ University of Geneva
HOBNET testbed @ University of Geneva
HOBNET testbed @ CTI
Smart Campus testbed @ University of Surrey
HEPIA and Champ-Baron testbed @ MI
Complementary testbeds:
CS testbed @ Belgrade (DNET)
mons testbed @ Novi Sad (DNET)
All testbeds are described below in terms of (I) Hardware and network; (ii)
Architecture and (iii) Available services.
8.1 WISEBED testbed @ University of Geneva

Hardware and Network
The testbed consists of I Sense sensor motes. The sensor motes form a wireless ad-
hoc network and communicate with the IEEE 802.15.4 protocol. I Sense motes can
be equipped with various modules such as environmental measurements (light,
temperature etc.) and security. The motes support both the IPv4 and IPv6 network
stack. Within the sensor network, the 6LoWPAN protocol suite (including
implementations of neighbours discovery, header compression and fragmentation) is
used to transmit IPv6 datagrams over the IEEE 802.15.4 link layer radio.
Figure 26: WISEBED testbed functional diagram

Architecture
Each sensor mote is connected via USB to a mini Atom D550 PC. The mini PCs are
connected through a local Ethernet network to the main server. The main server acts
as a gateway and connects the ad-hoc mesh network to the WISEBED platform and
50
the internet.
Figure 27: Architecture

Services and Objectives
The testbed allows external users to develop and evaluate new algorithms and
topologies on real life wireless sensor networks. It offers the following services.
Flashing new firmware on sensor motes
Remote connection tools to debug sensors and protocols
Reservation System API
WSN API
Controller API
8.2 HOBNET testbed @ University of Geneva

The HOBNET testbed of University of Geneva implements the HOBNET architecture
in the context of smart/green buildings. It uses Telosb sensor motes that act as
sensors and actuators. The sensor motes form a wireless ad-hoc network and
communicate with the IEEE 802.15.4 protocol. The motes support the IPv6 network
stack and are accessible directly over the internet by using CoAP v12 (application
layer protocol). The IPv6 connectivity on the motes is provided by 6LowPAN; a
protocol stack that defines encapsulation and header compression mechanisms that
allow IPv6 packets to be sent to and received from low-power and lossy networks.
Architecture
The architecture of the testbed follows the architecture of HOBNET. The sensors are
forming a mesh network and 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
51
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.
Figure 28: HOBNET architecture

The main objective of the testbed is to use the wireless sensor network to create
smart scenarios and services such as:
Local adaptation to presence;
Energy management;
Electric device monitoring;
Maintenance control;
User centric environment customization.
The testbed also provides a web interface to interact with the devices inside the
testbed as well as to visualize data of the sensors values and the status of the
actuators.
8.3 HOBNET testbed @ CTI

The HOBNET testbed uses Telosb sensor motes that act as sensors and actuators.
The sensor motes form a wireless ad-hoc network and communicate with the IEEE
802.15.4 protocol. The motes support the IPv6 network stack and can be accessible
directly over the internet by using CoAP (application layer protocol). The IPv6
connectivity is provided by 6LowPAN, a series of protocols that run on every mote.
52
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.
Figure 29: HOBNET Architecture

The main objective of the testbed is to use the wireless sensor network to create
smart scenarios and such as:
Local adaptation to presence;
Energy management;
User comfort (air and temperature);
Electric device monitoring;
Maintenance control;
User centric environment customization.
The testbed provides the following services:
Web interface to control the devices inside the testbed;
Web interface for composing smart dynamic scenarios;
53
Data visualization of the sensors values and the energy meters;

HTTP RESTFul API to retrieve and control the testbed resources.
8.4 Smart Campus testbed @ University of Surrey

The Smart Campus testbed infrastructure consists of a number of sensors connected
to TelosB mote platforms and positioned in different campus buildings. A total of over
1000 sensors are connected through a wired backbone infrastructure to a cloud
computing environment and high-speed core network that allows physical and remote
access to users via the Internet. The motes can be reprogrammed to form individual
ad-hoc wireless sensor networks where information can be transmitted wirelessly to a
selected sink. Motes wirelessly communicate using IEEE 802.15.4 and different
network protocols, such as CoAP and 6LoWPAN.
Architecture
The TelosB based sensor devices are deployed at each working desk in the
instrumented buildings and consist of different sensing and actuation capabilities,
such as:
Energy features of the connected devices;
Presence at work desk;
Light of the room;
Noise level of the room;
Temperature of the room;
On/Off actuation capabilities on the connected devices.
Additionally to these mote-based devices, a number of other IoT devices are
connected to the testbed and made available for experimentations. Available devices
are the following:
Smartphones (in the number of 20 available for experimentation and to be
provided to volunteer participants);.
Mobile TelosB motes (in the number of 100 available for experimentation and to
be provided to volunteer participants);
Wall-mounted Smart Displays;.
Gateways with Ethernet/WiFi and Bluetooth capabilities.
Although they could be used as experimentation resources, the 80 gateways are
mainly responsible to forward the data from dedicated motes selected as data sink to
the Core Network platform for information storage. To improve reliability in case of
management operations, the gateways communicate with the individual networks
and are connected using Ethernet to the main platform. Additionally, in order to
support reliable mote reprogramming and collection of out-of-band debug
information, the 80 Gateways are connected to the 200 TelosB motes through USB.
End users can communicate with the Core Network platform and gain information
from all the IoT devices. Also, end users can communicate with the testbed through
54
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.

The Smart Campus testbed offers many services to end users focusing on
experimentation purposes:
Resource discovery, exploration and reservation through the reservation system;
Topology exploration showing the position and the link connecting the mote-
based IoT devices;
Visual environment for the representation of the experiments;
Node reprogramming and debug information collection;
Data access to the generated application data using REST APIs.
Besides the experimental services, Smart Campus testbed offers the following
applications to end-users:
Energy efficiency feedback application in order to capture the energy footprint of
some buildings;
Indoor visitor guidance system that uses the smart displays to show information.
8.5 HEPIA and Champ-Baron testbed @ MI

The testbed consists of heterogeneous components that form ad-hoc wireless sensor
networks. The components support both the IPv4 and IPv6 network stack. Within the
sensor network multiple network protocols are used such as 6LoWPAN/CoAP-12,
ZigBee, Z-Wave, WiFi, Bluetooth, GSM/GPRS, KNX, X10.
The heterogeneous components include:
55
Wireless sensor motes measuring temperature, presence, humidity, and CO2 ;

Energy meter;
Audio monitoring sensors;
Building automation actuators: blinds, radiator valves;
Magnetic sensors to detect doors and windows opened;
RFID and NFC readers;
Remotely controllable smart lighting systems and buses;
IP cameras and phones;
ICT controlled equipment;
Media servers and renderers;
Remote switches.
Architecture
The components of the Smart Office testbed at Champ-Baron and the Smart HEPIA
testbed are interconnected with each other and they are forming individual ad-hoc
networks. Each site is encompassing various communication protocols. In order for
all the heterogeneous components to be easily accessible, a virtualization layer with
a CoAP-based interface is provided and can be used as a common gateway to the
various components. All the necessary information from the underlying infrastructure
is stored in a Resource Directory. The server that holds the Resource Directory
contains also a Web-service proxy.

In order for the end user to access the infrastructure another server is used. The
server uses the Resource Directory and the Web service proxy in order to
communicate with the devices. The provided services of the server are:
3D visualization of the components;
Control and monitoring system;
Energy analysis;
56
High-level directory of the available resources.

The objectives of Champ-Baron and HEPIA deployments are to perform IoT-related
experiments with a focus on cross systems integration and IPv6 and CoAP
deployments. It enables among others to test IoT interoperability and multiprotocol
integration by enabling and testing different sorts of cross-domain interactions
between different kinds of devices (sensors and actuators) using different protocols.
Energy efficiency and user comfort applications are provided in these deployments,
as well as explore the potential of IPv6 for smart buildings and test and improvement
of deployment methodologies. 7
The provided services are:
Energy efficiency and electricity consumption monitoring;
Building and lighting monitoring;
Safety and security;
Interoperability;
Context user awareness.
8.6 CS testbed @ Belgrade

The CS testbed is equipped with static and personal sensors that are used to
measure the air pollution (quality) and environmental conditions. Testbeds also
include smart phones running the application that can take the users input/feedback
on subjective feeling/perception about the current air pollution.
All sensors are deployed in the city of Belgrade and the current testbed deployment
includes:
Sensors;
EB700 devices equipped with sensors for temperature, humidity, air pressure,
CO, CO2, NO2 and SO2;
Personal sensor packs based on ARM Cortex-M3 core including NO, NO2, CO,
CO2, O3, SO2, VOC;
Android mobile applications;
o For taking subjective feeling of the air quality
Backend server.
Architecture
The overall architecture is illustrated in Figure 32:
All EB700 devices are connected to the back-end server using GPRS channel.
They also support TCP or UDP over IP;
All personal devices use the Bluetooth and associated smart phone application
to connect to the backend server via GPRS.
57
Web/mobile
Platform clients
Web/mobile
clients
Web/mobile
clients
EB700
device
EB700
device EB700
device
Figure 32: CS Testbed Architecture

Backend server combines all the data from measurements as well as the user
data to determine the air quality;
All the nodes (both static and personal) are registered with their capabilities,
URLs and available services within the CoAP Resource Directory inside the
back-end server;
Data visualisation is performed with available web and mobile applications;
Available web services enable alternative access to the testbed.
The objective of the CS testbed is to monitor the air pollution levels with static and
personal sensors together with subjective feeling of the air provided by the perception
of the end users.
Available services of the testbed are:
Data visualization of collected sensors values through a Web or a mobile
application (Figure 33);
Web service that enables end users to gain the sensor data differently and use
them in their own applications;
Air quality map across a wide city area and the effect of this on the subjective
feeling of air pollution;
More precise air quality monitoring using personal sensor packs and tracking of
locations where measurements have been taken;
Correlation of subjective feeling of air quality with location;
It is planned to have 10 users, but potentially an unlimited number of users for the
subjective feeling data can be planned as well. The sensors are limited to 40 static
and 10 personal.
The current testbed constraint is that there are only 10 static sensors. Deployment of
personal sensor packs and mobile applications are planned within the following year.
58
There are only 10 static sensors, deployment of personal sensor packs and mobile
applications are planned within the following year.
Figure 33: Web and Android based AR visualization
8.7 mojNS testbed @ Novi Sad

The mojNS provides an event reporting system in the city of Novi Sad. Currently, the
mobile application for Android based devices provides an interface for citizens to
report different types of events. Reported events are forwarded to the appropriate
institution. Municipality police dispatcher receives events, processes them with
additional information and forwards them to the appropriate authority institution. The
key system mission is to enable an easy, fast and trustful access to the city utility
institutions for citizens using their mobile devices.
The mojNS testbed consists of Android smartphones. The smartphones are used to
collect different types of events such as temperature, acceleration, noise and battery
levels.
Architecture & Deployment
The public utility company in the city of Novi Sad JKP Informatika has deployed the
communication with the municipality police dispatcher. The central component of the
system is IEWS (Informatika Events Web Service). IEWS provides REST based web
service for reported events that can be accmessed by JKP Informatika. They
perform periodical checks for new events and forward them to the Municipality police
dispatcher. PS Server accepts events and measurements (temperature, acceleration,
noise, battery levels, etc.) observed by the users.
59
Figure 34: mojNS functional diagram

The mojNS testbed provides an event reporting system in the city of Novi Sad in
Serbia. Users are equipped with an Android mobile application which they can use to
report on different types of events. These events are forwarded to the appropriate
institution. The Municipality police dispatcher receives events, processes them with
additional information and forwards them to the appropriate authority institution. The
goal is to enable an easy, fast and trustful access for citizens to the city utility
institutions using their mobile phones.
Data collected from the users may be used for different experiments and
applications. For example city noise map may be obtained from their observations.
Reported events may be a good indicator related to different city conditions, such as
streets with snow, etc. All this information can be derived from the observed data.
Data collected from the end users may be used for different experiments and
applications. For example, city noise map may be obtained from the end user noise
observations. Reported events may be a good indicator about different city
conditions, such as crowded traffic parts, and streets with snow etc. All this
information, derived from the observed data, may be useful for a different citizen
planning.
Several improvements are planned in the mojNS architecture. For example, if past
information about reported events from the appropriate authority institution doesnt
exist, users do not know if their event was taken into account for processing.
Workshops with different end users may be useful when finding new features which
will be more attractive. Personalization of the service by introducing user accounts
with improved event rating and evaluation mechanism may increase reliance in
reported events and be more attractive to end users.
60
9. Adaptation of Existing Platforms

9.1 Gaps in Existing Platforms wrt IoT Lab Platform requirements
This section focuses on novel features of the IoT Lab approach and thus identifies
the limitations of existing crowdsourcing approaches. Classification of required
features and resources is also provided and discussed/assessed regarding required
adaptations of existing approaches.
The aim of the IoT Lab project is to enhance the existing Internet of Things and FIRE
testbeds which traditionally comprise of static sensor mote platforms, by leveraging
participants end user mobile phones in order to achieve crowd participation in the
sensing and actuation operations. In order to achieve this, the kind of support that an
IoT Lab platform should provide is the following:
Virtualization of existing testbeds through Fed4FIRE and integration with
crowdsourcing IoT resources;
Integration of end users mobile phones;
Researchers and investigators empowerment to control resources and to design
and control experiments and surveys;
End users participation and interaction with experiments and investigators.
In order to support such envisioned functionalities, the IoT Lab platform should
provide a set of features and resources to be used by its stakeholders, specifically
participants, investigators and testbed owners1. Such resources consist of: Profile
Management, Experiment Management, Search and Communication tools and
Resource Management. Table 7 provides a summary of the envisioned features,
resources and tools, classified according to the different IoT Lab platform
stakeholders. This will serve as input for the initial architectural design of the IoT Lab
platform.
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
Stakeholder/Functionality Participants Investigators Testbed Owners
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).
The platform must allow the participants

to manage and define policies on their
Profile devices data. This includes a sensor
Data
Management (physical and social) selection; data
offload method, sampling periodicity, as
well as notification methods.
As an extension to the default profile As an extension to the default profile

the platform should allow the user to information, the investigator can specify
specify more information about himself, more information about himself/herself
Social
this includes birth date, gender, that include: affiliation, country,
employment status and sector, country description and a profile picture.
of residence, etc.
The system must provide ways that

allow the investigator to specify and
submit an experiment. This description
includes contact information, detailed
Experiment
Submit experiment description, resources
Management
needed, as well as implementation
details. After submitting the experiment
to the platform, the experiment needs to
be validated.
62

allow the participant to join
experiments. This can be done also
through notifications. A clear
Join description of the experiment and its
implementation must be provided to the
participant so that he or she can make
a choice to join or not join the specific
experiment.

allow the participant to leave an
experiment at any time. In that case a
Leave
new participant that fits the criteria of
that experiment must be found as
replacement.
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

allow sampling the sensor data from the
participants phones, possibly storing it
locally and sending it to the platform
where it is stored persistently.
The system must provide ways to push

actions to the participants. This can be
by taking a picture, answering a
questionnaire or other types of actions.
The data is then transferred to the
platform and stored persistently.
After participating in an experiment, the After finishing an experiment, the

system must provide ways to provide system must provide ways for the
Experiment
rewards to the participants; this investigator to classify the participants
reward
incentive can be a reputation update or participation in the experiment (quality
any other incentive. and amount of data provided).
The platform must provide ways that

allow the investigators to communicate
with other users (other investigators or
Experiment
Sensor Data Provisioning participants). Investigators can also
Participation
follow other users. Communication can
be done through messaging or forum
posts.
Communicate
allow the investigator to share
information in social media, this can be
Knowledge Data Provision for instance to share his experiments
link in order to get more participants or
to share the results of a finished
experiment.
64
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
allow the participant to search for other
Participant
participants; this can be for instance to
find nearby participants.
The system must provide ways that The system must

allow the participant to temporarily add provide ways that
his/her mobile phone to the pool of allow the testbed
available crowdsourcing resources. owner to add new
Default policy might be quite broad resources. The
Add resource though. owner must provide
a unified description
of the resource and
Resource
this information must
Management
be added to the
system.

allow the investigator to reserve a
Reserve
specific resource to run an experiment.
Resource
While the resource is reserved no other
user can use this specific resource.
65

allow the participant to temporarily provide ways that
remove his/her mobile phone to the allow the testbed
Remove pool of available crowdsourcing owner to remove or
Resource resources. temporarily make
unavailable a
specific testbed
resource.

allow the investigator to have an provide ways that
Resources overview of the resources available allow the testbed
Overview (crowd and testbed). owner to have an
overview of his
resources.
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
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
than provide rewards to participants according to their experiment participation

behavior (Experiment Management). Additionally, Communication tools for
communicating with participants and creating surveys and pushing them to selected
experimentation resources and corresponding end user participants are also required
for the investigators in order to control the complete experimentation flow. The
platform should also integrate and provide features enabling the investigators to
access, manage and eventually retrieve data from their experiments, as well as
visualization tools such as graphs and interactive maps. Such elements will be
aligned with mainstream open source standards such as OGC SWE.
From the participants and end users perspective a set of additional new tools, mainly
provided by a crowdsourcing mobile app, are required according the novel IoT Lab
experiment and participation model. The possibility for participants to browse existing
experiments and select those to join will be provided (Search). Additionally, in order
to foster end user participation and full understanding of each participated
experiment, the IoT Lab platform envisions also new user tools for interacting with
other participants (i.e. to promote participation) and to get support from experiment
investigators (Communication). Finally the IoT Lab platform, with respect to existing
ones, envisions tools for defining end user profile and participation to experiments
(Profile Management), by giving him/her control on every aspect of the shared
information and possibility to withdraw from an experiment at any time, along with the
possibility to receive an award and be evaluated for his/her participation (Experiment
Management).
Figure 35: IoT Lab enablers - generic
68
9.2 Platform Selection

Following the wave currently driving the Internet of Things (IoT) development in
which every human being is seen as a source of data that are generated and shared
through his/her mobile smartphone; all the crowdsourcing platforms reviewed in
Section 7 actually focus on different ways to empower user participation to the IoT
through mobile phones. For this reason, none of the platforms actually foresee the
possibility to integrate smartphones with existing FIRE testbed or in general statically
deployed IoT resources, such as energy meter, home automation control system and
so on. Nonetheless, no effort has been addressed in order to provide virtualization
tools in order to homogenize heterogeneous IoT resources, in order to make them
available and interoperable. To this purpose, the approach proposed by IoT Lab
results are new and advanced with respect to existing crowdsourcing platforms.
While this integration is missing in current crowdsourcing platforms, most of the
reviewed ones provide an interesting approach for IoT experimentations including
participating user mobile phones.
While some of the reviewed platforms might be too specific and only support pre-
defined tasks without the possibility to extend them due to the lack of open source
code, others might be too general, like Ushahidi, do not support the involvement of
participants and the complete IoT Lab participation model, but only leverage on geo-
localized data collection and visualization through maps.
Others, like Phonelab provide a platform and a model for crowd engagement in the
IoT co-creation effort, but no actual application is provided to support this, while
instead custom applications are developed and distributed according to selected use
case.
However, other platforms properly support user participations in IoT experimentation
through mobile phones, but still lack the ability to fully support the IoT Lab envisioned
models for participation and interaction between participants and investigators.
APISENSE supports script and crowdsourcing on mobile phones but will need
integration with other IoT Lab provided tools, such as Resource Management and
Experiment Management. However, an official version of the platform has not been
released yet.
Similarly, a set of other existing platforms, fulfilling the different needs envisioned by
the IoT Lab mobile app, will be investigated further in order to understand how and to
which extent they could be extended with other IoT Lab tools, so as to achieve a
complete IoT Lab platform.
EpiCollect can be useful for creating a survey and questionnaire, but the lack of open
source code, limits the possibility of extension and integration.
mCrowd seems to be better fit for participatory sensing applications and the lack of
APIs and the only provided iPhone version might limit the possibility of integration
and extension.
Funf and AmbientDynamix represent good frameworks for crowdsensing and
crowdsourcing. In particular, the capability of AmbientDynamix to adapt its behaviour
to context could allow the supporting of different experiment participation models
suitable for the end user perspective. The possibility to integrate it with other
envisioned IoT Lab resources should be further investigated.
Together with AmbientDynamix, the scope of results are limited to the IoT Lab mobile
69
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.
9.3 Selected Platform Adaptations

The IoT Lab platform architecture includes, among others, testbeds, smartphones
and a cloud server that is responsible for integrating all the components into a
virtualised IoT Lab testbed providing the Testbed as a Service functionality. The
cloud server provides several tools in order to communicate with the underlying
testbeds and also provides interfaces to the experimenter in order to run
experiments.
The IoT Lab platform allows experimenters to run their own experiments using
resources from several testbeds. In the IoT Lab architecture, each testbed preserves
its functionality, architecture and interfaces. The interfaces, mechanisms and
technologies among testbeds are different. Fed4FIRE tools are used to provide a
common interface to all the testbeds and provide the ability for experimenters and
end-users to access testbeds in a unified way.
Fed4FIRE is used in the cloudification and federation of the testbeds and in particular
assists the unification of the resource discovery and reservation process. In order for
the stakeholders to be able to use the available resources across each testbed, there
is a mechanism to inform them about the availability of the resources. The tool that is
used to expose the management software of each testbed is SFA Wrap and is
required by many Fed4FIRE tools that are responsible for resource discovery,
reservation and provisioning. SFA Wrap provides an SFA interface to the testbeds
by translating the SFA commands into testbed specific calls. The Cloud server
communicates with each testbed using the SFA interface.
Also, the IoT Lab platform provides the ability for measurement and monitoring of the
available resources and infrastructures. For this particular functionality, another
Fed4FIRE tool is being used - OML. OML is responsible for collecting data from the
endpoints of each testbeds and transmitting them to the OML server hosted on the
70
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.
Functionality Fed4FIRE Tools
Resource virtualization SFA Wrap
Federation and integration of testbeds
Data collection from testbeds OML
Data collection from crowdsourcing devices
71
10. Proposed IoT Lab Architecture

This section describes a possible deployment view of the IoT Lab architecture.
The software components of the platform are firstly presented and then described
with their respective functionalities, their interactions and interfaces. Description of
the usage of available platform services is also provided for each of the platform
deployment stages.
Hardware architecture within a potentially deployed IoT Lab architecture is also
described illustrating a high level communication scheme among diverse range of
possible hardware components.
10.1 IoT Lab Components: SW Architecture

The IoT Lab architecture design aims to provide a polyvalent and flexible platform
able to support a large set of IoT-related experiments. In order to ease its future
evolution, its design is guided by several considerations:
Adopting a modular architecture, that will enable the evolution of individual
components without impacting the whole architecture;
Favoring generic enablers that can be easily used by different experiments;
Aligned with main stream standards and solutions to ease the integration with
third parties resources;
Satisfying the requirements derived from the best voted use case scenarios
proposed by the consortium.
Selected use cases identified several important experimental approaches including
crowd sensing; data collection and processing from different IoT testbeds; the code
execution on the participant side and completion of different questionnaires by
participants.
Main architectural components of the proposed IoT Lab system are organised in four
groups as follows: Account manager, Experiment manager, Resource manager and
Web user interfaces which is illustrated in Figure 36.
72
Figure 36 IoT Lab Architecture A deployment view of the proposed concrete architecture
73
10.1.1 Account Manager

The Account Manager group collects components related to different user accounts,
as well as to different assigned users roles. Two main user categories are
Investigators and Participants. Investigators use the IoT Lab platform and tools to
set-up their investigations or experiments, recruit participants and collect and analyse
results. Participants are all actors involved in an experiment, for example, the people
who use the IoT Lab product (application) and allow the experiment execution on
their phones. Other users of the platform include: platform owners,
researchers/students, testbed owners, customers, testbed service managers, and
administrators, etc.
The IoT lab platform will collect different types of data and it will be designed to
ensure the privacy and trust of the users. All users will have to be authenticated and
appropriately authorised to be able to use the system functionalities. The platform will
provide the option for data anonymisation as well as for generating identifiers for
such accounts. Access to the platform functionality will be controlled by AAA
(Authentication Authorization and Accounting) component. The Security component
will control AAA mechanisms in the system. All accounts and roles, as well as their
associations will be persistently stored in a database.
The function of the Reputation and Incentives framework component is to monitor the
user activity and then estimate the user rating in a semi-automatic way. Different
mechanisms will be implemented in this component to be able to reliably rate the
users. Rates will be estimated and assigned to both participants and investigators.
One of the inputs to this component is a collection of positive and negative rates
collected from the system users. This component also includes the Incentives
schemes for participating in the experiments coming from the perspectives of
different end users and crowdsourcing participants.
10.1.2 Resource management

In order to properly setup and execute the experiment, it is necessary to monitor and
collect information on available resources in the system which is the role of the
Resource Manager Group. Resource Directory (RD) component provides a
persistent storage of resources. RD implements interfaces for the resource
management by providing the CRUD (Create, Read, Update and Delete) functionality
as well as the lookup Resource Managing Interface (RMI) and Resource Lookup
Interface (RLI). RMI and RLI interfaces are implemented as REST based web
services. All resources available in the IoT system should be uniformly described.
Resource Monitor Component manages resources in the RD by keeping the real time
picture of resources in the system. The changes in resources can happen for
different reasons:
Users can lose their Internet connection;
Users can decide to stop experiment execution on their phone;
A new user can agree to provide resources for experimenting.
Resource Monitor will send notifications to appropriate system components about
any detected change in available resources.
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.
10.1.3 Experiment Manager

Experiment Manager Group aggregates components related to both the experiment
management and the experiment data management. API provides the standardised
Web service based access (i.e. REST) interface for component interaction. Several
components take part in creating the experiment:
Experiment Validator Component receives a standardised abstract experiment
representation and validates the experiment definition. Standardised experiment
representation should result from consolidated analysis of use cases and additional
user requirements. It can contain code segments that should be performed on the
participants devices involved in the experiment, or a definition of questionnaire forms
that should be completed by participant. All segments of an experiment should be
verified and any detected irregularities should be reported before the further
processing.
Experiment Configurator Component interprets the received validated experiment
definition and stores the standardized experiment representation in an Experiment
Database.
Participant/Resource Selection Component detects and selects available resources
that match the experiment requirements. This component performs the appropriate
query on the RLI interface and receives notifications on availability (and location) of
Resources from the Resource Monitor component.
Experiment Scheduler runs the experiment on resources using the Reservation and
Provisioning Components for appropriate testbeds.
Experiment Querying, through the Experiment Manager API, provides an access to
stored experiments.
All data provided by the experiment are collected by the Experiment Data Manager
component. Testbeds provide streams of experimental data in the OML format 0
Experiments are performed on top of different testbeds. The process of an
experimenter discovering, reserving and provisioning the available resources across
all testbeds for his/her experiment will be conducted in a standardised way via the
SFA Wrap tools and architecture (e.g. an SFA client will be running at the Web GUI).
Then, the IoT Lab Experimenting Platform will take care of the particularities of each
testbed and will interact with the resources according to the experiment scenario.
Crowd based experimenting is focused on running the experiments on users mobile
devices. Again, these resources will be exposed by the IoT Lab Experimenting
Platform in a standardised way via SFA Wrap.
User Interaction component aggregates components for experiments on top of
crowdsourcing smart mobile devices. Several components for survey, crowdsensing,
code script execution are involved in experiment execution.
75
IoT interaction tools control the experiment execution on federated testbeds.

All components in the Experiment Manager are accessible through the REST based
Experiment manager API Web service interface.
10.1.4 Web user interfaces

GUI access to the system is implemented through components grouped in the Web
user interfaces.
The Experiment Configuration GUI provides the Web access for designing and
initiating the experiment and it should be intuitive. The GUI communicates with the
Experiment Manager through the API to provide the experiment description to the
Experiment Validator. This also includes the access to the Survey and GUI editor so
the experimenter can set up a specific survey and/or a specific user interface for his
or experiment on the smart phone application.
The Experiment Search Component provides an interface for the experiment
querying. This component can query the resources in order to make the access
easier for resources in different testbeds.
Results Visualisation Component provides the appropriate graphical interpretation of
collected experiment data. It will include a maps and graphs generator based on
main stream open source solutions, such as OGC SWE and Google maps. It will
enable the platform to provide graphical representation as well as dynamic maps of
the results as well as of the live data.
Social media share components of the Web interface and enables different types of
users to publish their experiments and related opinions on popular social networks.
The system management is provided through the Platform Administration Component
which enables many functionalities including:
The User Account Administration for the users to log in and manage their
personal account and profile.
The Data Access and Management for the experimenter to manage the
collected data; delete unnecessary data sets; and/or retrieve filtered data
sets.
Filtering users personal data in order to ensure full compliance with the
personal data protection policy and obligations.
76
10.2 Sequential View Use of Services

An overview of the usage of available services within the proposed IoT Lab platform
described in the previous section is illustrated using the Sequence Diagrams, which
illustrate three stages in the platform deployment:
User registration Process (Figure 37)
Experiment submission Investigator side (Figure 38)
Contribution from Crowd (Figure 39)
10.2.1 User Registration Process

Testbed Resources: All available individual testbed resources need to be stored in
the Resource Manager following their announcement to the IoT Lab platform using a
common description scheme. In this way, the IoT Lab platform will be able to
leverage the available resources in a uniform manner.
Users of the platform (participants and investigator researchers) should be stored in a
Resource Manager component following their registration in Account Manager,
authentication through AAA and the role assignment again in Account Manager.
Figure 37: User Registration Process (Sequence Diagram)
77
10.2.2 Experiment Submission

Investigator/Researcher uses the Web UI to setup the experiment via Experiment
Manager REST API.
The experiment is then validated based on standardized experiment representation,
interpreted by Experiment Configurator and then stored in an Experiment Database.
The Experiment Manager is then able to recruit the relevant participants and
resources (testbeds) by communicating the Resource Manager through Resource
Lookup Interface (RLI). Experiment is then scheduled by Experiment Manager
through reservation and provisioning of resources which includes:
Testbeds - reserved through SFA WRAP;
Crowd/mobile phones.
Figure 38: Experiment Submission (Investigator side)
78
10.2.3 Contribution from Crowd/ Testbed Resources

The obtained experimental data from Testbeds and Participants is sent to Experiment
Data Storage within Experiment Manager in an OML format.
Investigator researcher can send the query for experiments through Web UI via
Experiment Manager REST API.
It is important to say that Monitoring the Resources and information about their
availability and location should take place either periodically or based on the query
from Experiment Manager between the Account Manager and Resource Manager.
Resource Manager should notify the Experiment Manager on Resources periodically
as well as based on the query through RLI interface.
Figure 39: Contribution from the Crowd/Testbed Resources
79
10.3 IoT Lab Components: HW Architecture

The following Figure 40 depicts at a high level the communication scheme among the
various hardware components. The IoT Lab infrastructure will consist of a highly
diverse set of devices ranging from highly constrained sensor motes to Cloud
Servers. This grand variety of devices needs to be organized in an efficient and
scalable way in order for the IoT Lab Experimental Facility to be viable. Towards this
end, a detailed virtualization strategy has been studied (see deliverable D3.1 Open
Interfaces) which, as a side effect, also indicates how the communication among
different classes of devices will be orchestrated.
At a local testbed level, the various devices are organised in communication islands
dictated by the physical constraints of the communication medium. For instance,
several sensor motes communicating over IEEE802.15.4 will be organised in a
Wireless Sensor Network, while smartphones may communicate with the local
testbed server or gateway (this depends on the local architecture of each individual
testbed) over Bluetooth or Wi-Fi. Then, at an aggregating level, the server/gateway of
each individual testbed facility will communicate with the IoT Lab Cloud Server. This
communication will be bidirectional; first enabling each individual testbed to
communicate information regarding the virtualisation of its resources and second
providing the experimenters with access to its own resources. Furthermore, ad-hoc,
crowdsourced resources, such as smartphones, will also be able to communicate in a
bidirectional way with the IoT Lab Cloud Server acting both as an experimental
platform and as an entry point to the IoT Lab Experimental Facility.
Finally, at an IoT Lab Experimental Facility layer, a Resource Directory will be
maintained listing all available resources across all individual testbeds along with
meta-data regarding their access and usage (e.g. which communication protocols
they support, which function sets, etc). Furthermore, all necessary mechanisms will
be implemented at this layer in order to enable the exerimenters to access the
resources (e.g. trust and privacy mechanisms, experiment orchestration, storage and
visualisation of experimental results, etc).
Figure 40: HW Architecture
80
11. Conclusions and Future work

This document presents an initial IoT Lab architecture that addresses the
requirements from Task 1.1, as well as other technical and non-technical work
packages. Moreover, a detailed analysis of the SOTA regarding IoT and
crowdsourcing platforms is presented. This analysis serves also as a very important
input to the architecture design where IoT Lab adaptations are considered in order to
fulfil the requirements.
The first iteration of the IoT Lab architecture presented in this document will serve as
a reference model for the implementations to be carried out in the technical work
packages. Moreover, lessons learned and general feedback from the implementation
work, as well as new use case scenarios will be considered as input for architectural
updates in further iterations
This deliverable also focused more on the testbeds integration with a particular
attempt to make the platform compatible with future FIRE projects and platforms. The
next iteration of the architecture design will focus more on potential interactions with
external services and resources. We have already begun to consider complementary
solutions and platforms (such as Compose, CitySDK, OpenLab, and others) which
will be further analyzed and considered in our architecture design in the first quarter
of Year 2 in the development of the IoT Lab platform.
For Year 2, we will also consider the addition of new components to the IoT Lab
architecture, such as for instance component(s) that provide participant or
investigator reward mechanisms. This will be the subject of a detailed study in both
WP5 and WP6 and will serve as input to the design of the updated architecture.
81
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

IoT - Lab D1.2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IoT - Lab D1.2

Uploaded by

Copyright:

Available Formats

Researching crowdsourcing to extend IoT testbed infrastructure for

multidisciplinary experiments, with more end-user interactions, flexibility,

Grant agreement for: Collaborative project

Contract Due Date 30/09/2014

Submission Date 12/09/2014

Responsible Partner Srdjan Krco (DNET)

Author List Michele Nati, Joao Fernandes, Stevan Jokic,

Project Coordinator: Mandat International (MI)

7.11 CitySDK ...................................................................................... 41

Figure 32: CS Testbed Architecture ....................................................................................................... 58

IoT-A Internet of Things Architecture

ARM Architecture Reference Model

FIRE Future Internet Research and Experimentation

Fed4Fire Federation for FIRE

Protocol API Application Programming Interface: Components that are used to

CRUD Create, read, update and delete

SOTA State of the Art

REST Representational state transfer (REST): A way to create, read,

SFA Slice-based Facility Architecture or SFA: Provides a minimal

SFA WRAP Providing heterogeneous testbeds (e.g. coming from different EU

DoW Description of Work

wrt With respect to

PaaS Platform as a Service

AAA Authentication, Authorisation and Accounting

P2P Peer-to-peer protocol

RSS Rich Site Summary

SMS Short Message Service

HTTP Hypertext Transfer Protocol

LGPL GNU Lesser General Public License

SCA Service Component Architecture

IaaS Infrastructure as a Service

RCT Remote Control Terminal

RSE Remote Scripting Environment

RDT Remote Debug Tools

ADB Android Debug Bridge

SDK Software Development Kit

AIDL Android Interface Definition Language

IEEE Institute of Electrical and Electronics Engineers

6LoWPAN IPv6 over Low power Wireless Personal Area Networks

CoAP Constrained Application Protocol

GSM Global System for Mobile Communications

GPRS General Packet Radio Service

RFID Radio-frequency identification

NFC Near-field communication

TCP Transmission Control Protocol

UDP User Datagram Protocol

RLI Resource Lookup Interface

RMI Resource Management Interface

GUI Graphical user interface

3.2 Purpose and Scope of Task T1.2 on Architecture Design

3.3 Purpose and Scope of the Document

Figure 1: Task 1.2 Sequence and interactions

3.4 Structure of the Document

4. IoT Lab: Approach to Architecture Design

4.2 IoT-A ARM: Building Interoperable Concrete IoT Architectures

Figure 2: Relationship between reference architecture, architectures and actual

4.2.1 IoT-A Architecture Generation Process

Figure 3: IoT architecture generation process [source: IoT-A 0]

4.2.2 Functional View (IoT-A ARM Building Blocks)

Figure 4: Functional view IoT System groups and components [1]

4.2.3 Information (Flow) View

Table 1: Information flow patterns

method. Clients can

service and client upon