deliverable d1.1 iot lab end-user requirements report · integrate them into the cloud to provide...

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.1 IoT Lab end-user requirements report

Contract Due Date 31/03/2014

Submission Date 31/03/2014

Version 1.0

Responsible Partner AI

Author List João Fernandes (AI), Srdjan Krco (DNET), Stevan Jokic

(DNET), Nenad Gligoric (DNET), Michele Nati (UniS),

Sebastién Ziegler (MI), Cedric Crettaz (MI), Sotiris

Nikoletseas (CTI), Theofanis Raptis (CTI), Constantinos

Marios Angelopoulos (UniGe), José Rolim (UniGe),

Valerio Veglio (SOTON), Franck McGroarty (SOTON),

IoT Lab WP1 Requirements and Architecture design

2

Annika Sällström (LTU), Anna Ståhlbröst (LTU)

Dissemination level PU

Keywords Internet of Things, Crowd sourcing, Lab,Requirements,

Use Cases, Crowdsourcing platforms, Testbeds,

Privacy, Data Protection

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

Abstract

This document reports on a list of envisioned crowdsourcing scenarios for the IoT Lab project. A comprehensive list of end-user requirements and system requirements (both functional and non-functional) derived from the use cases are also enlisted. Privacy and personal data protections requirements have been gathered in a complementary and specific deliverable D7.1.


3

Table of Contents

1 Executive Summary ........................................................................................... 7

2 Introduction ........................................................................................................ 8

2.1 The IoT Lab project in brief ............................................................................ 8

2.2 Purpose and scope of the WP 1 .................................................................... 9

2.3 Purpose and scope of the Task1.1 ................................................................ 9

2.4 Purpose and scope of the current document ................................................. 9

3 Use Cases Portfolio ..........................................................................................10

3.1 Methodology for Scenario Collection ........................................................... 10

3.1.1 Scenario brainstorms ............................................................................. 11

3.1.2 Other projects and platforms .................................................................. 11

3.1.3 Crowdsourcing ....................................................................................... 11

3.2 Scenarios portfolio ........................................................................................ 11

3.3 Use Cases selection metrics ....................................................................... 32

3.4 Scenario selection ....................................................................................... 33

3.4.1 Smart City Scenario ...............................................................................35

3.4.2 Physical Testbed Scenario .....................................................................39

3.4.3 Derived services ....................................................................................41

4 Detailed requirements ......................................................................................48

4.1 Terminology and Notation ............................................................................ 49

4.2 Objectives and Basic Conditions ................................................................. 50

4.3 Privacy and data protection ......................................................................... 50

4.4 Functional requirements .............................................................................. 50

4.4.1 Authentication, Authorization and Accounting ........................................50

4.4.2 Experiment Management .......................................................................56

4.4.3 Resource Management ..........................................................................76

4.4.4 Federation ..............................................................................................78

4.4.5 Community/Forum .................................................................................80

4.4.6 Trustworthiness ......................................................................................82

4.4.7 IoT Lab application .................................................................................83

4.5 Non-functional requirements ....................................................................... 85

4.5.1 Experiment Validator ..............................................................................85

4.5.2 User Interface ........................................................................................86

4.5.3 Community/Forum .................................................................................89

4.5.4 Security and Privacy ..............................................................................91

4.5.5 Authentication, Authorization and Accounting ........................................97

4.5.6 Resource Management ..........................................................................98


4

4.5.7 Experiment Configurator ........................................................................99

5 Conclusions ....................................................................................................100

References .............................................................................................................101

6 Appendixes ......................................................................................................102

6.1 Appendix 1: Existing crowdsourcing platforms .......................................... 102

6.2 Appendix 2: Other project scenarios.......................................................... 105

6.3 Appendix 3: Needfinding interviews – questions to be used by each partner 113

6.4 Appendix 4: Use cases ranking scores ....................................................... 115


5

List of Figures

Figure 1: Scenario collection and selection methodology .................................................................... 10

Figure 2: Supermarket marketing scenario diagram ............................................................................. 38

Figure 3: Physical testbed scenario diagram ......................................................................................... 41

Figure 4: Formal structure of a requirement ........................................................................................ 49


6

List of Tables Table 1: eCrowd scenario ...................................................................................................................... 12

Table 2: Public Reporting and participatory sensing scenario .............................................................. 14

Table 3: Citi-Sense air quality estimation scenario ............................................................................... 14

Table 4: Lecture monitoring scenario ................................................................................................... 15

Table 5: Business and market studies scenario ..................................................................................... 16

Table 6: Participant contest scenario .................................................................................................... 17

Table 7:Gamification scenario ............................................................................................................... 18

Table 8: Meeting record and mood monitoring scenario ..................................................................... 19

Table 9: IoT Lab as a tool to support Living Lab operations scenario ................................................... 21

Table 10: Managing Building assets with security provisioning scenario ............................................. 22

Table 11: Energy Efficiency contest scenario ........................................................................................ 23

Table 12: Energy Efficiency and user comfort in HOBNET enabled environments, using mobile crowdsensing hints scenario ................................................................................................................. 25

Table 13: HEPIA sustainable week - crowdsourcing driven energy efficiency buildings scenario ........ 25

Table 14: IoT Lab online trading game scenario.................................................................................... 26

Table 15: Demographic migration tracker scenario .............................................................................. 27

Table 16: Colours and customer purchases scenario ............................................................................ 28

Table 17: Selling policies and customers behaviour scenario ............................................................... 29

Table 18: Shops temperature and selling percentage scenario ............................................................ 30

Table 19: Shops light effects and maximization of business performance scenario ............................ 30

Table 20: Effects of light colours and maximization of business performance scenario ...................... 31

Table 21: IoT Lab online focus group scenario ...................................................................................... 32

Table 22: Scenario Categories and Weights .......................................................................................... 33

Table 23: Best ranked scenarios ............................................................................................................ 34

Table 24: Market focussed use case ..................................................................................................... 35

Table 25: Threadless crowdsourcing platform .................................................................................... 102

Table 26: InnoCentive crowdsourcing platform .................................................................................. 103

Table 27: Amazon Mechanical Turk crowdsourcing platform ............................................................ 103

Table 28: iStockPhoto crowdsourcing platform .................................................................................. 104

Table 29: Smart energy management in smart cities scenario ........................................................... 106

Table 30: Smart city public bus transport scenario ............................................................................. 106

Table 31: Enabling Santander/Novi Sad scenario ............................................................................... 108

Table 32: Subjective feeling of air pollution in correlation with observed measurements scenario . 109

Table 33: ODAA (Open Data Aarhus) and city dashboard scenario .................................................... 110

Table 34: SmartSantander experimentation on top of smartphones scenario .................................. 111

Table 35: Noise mapping by participatory sensing ............................................................................. 112

Table 36: Use Cases ranking results .................................................................................................... 116


7

1 Executive Summary

This document reports on the work carried out in WP1 for task 1.1 on the use cases and requirements analysis. It contains a detailed description of various relevant crowdsourcing use case scenarios for the IoT Lab project. These use cases are abstract descriptions or story narratives that describe the interaction between the user and the IoT Lab envisioned platform, emphasising the added value/usefulness of the IoT Lab tools.

The general concept of crowdsourcing defines a mix of bottom-up open and creative process with top-down organisational goals[1], this balance is indeed very important and for that reason we involve the crowd/potential users of the IoT Lab platform already in this early ideation phase where we together have worked on the elaboration of use case scenarios that are of our research interest or challenge. The use cases include not only a technological research perspective, but also a business and societal research angle that fulfils the needs and challenges of the researchers in all the three areas.

It is also important to mention that the use cases will grow and possibly change during the lifetime of the project due to new ideas or requirements coming from the research community, the feedback from the advisory board group and during the implementation, deployment and evaluation cycles of the project. In order to capture new use cases coming from the research community we have included in our website the possibility of submission of relevant use cases, these new ideas will be evaluated and considered during the lifecycle of the project.

Based on the use cases portfolio, a detailed set of functional and non-functional requirements for the architecture and its components have been identified. These requirements also include heterogeneous network requirements, privacy, authentication and data ownership requirements, and will serve as foundation for the work to be carried out in task 1.2 for the architecture specification work, as well as the work to be carried out in the technical work packages (WP2, WP3 and WP4). The specified requirements will be revisited in the light of new use cases that may emerge from consultations with the research community, advisory board and lessons learned from implementation and experiments. Finally it is important to mention that the IoT Lab project requirements also address the ethical issues, including data protection and privacy processes as described in the Grant Agreement obligations and following the European directives on personal data protection. IoT Lab project has adopted complementary measures and specifications to specifically address privacy, personal data protection and ethics. It includes among others: - a detailed set of IoT Lab Privacy Rules and Guidelines adopted by the consortium; - a detailed set of technical measures to improve security and trust in the platform and to mitigate the risk of privacy breach; - as well as the Grant agreement commitments related to privacy and ethics; Those documents and their related requirements have been gathered into a specific deliverable D7.1 Ethical Approvals; IoT Lab project and privacy protection, and will be used as complementary requirements for the whole project development. They should be considered as an extension of D1.1.


8

2 Introduction

This chapter introduces this report; we describe the project briefly, as well as the work package 1 and the task 1.1 use cases and requirements analysis. Finally we discuss the purpose and scope of this document.

As mentioned in the executive summary, a set of complementary requirements have been adopted to address the privacy and personal data protection, and are gathered in a specific deliverable D7.1 and should be considered as a complementary set of formal requirements for the project.

2.1 The IoT Lab project in brief

IoT Lab is a European research project exploring the potential of crowdsourcing to extend European IoTtestbed infrastructure for multidisciplinary experiments with more end-user interactions. It researches and develops:

1. Crowdsourcing mechanisms and tools enabling testbeds to use third parties resources (such as mobile phones), and to interact with distributed users (the crowd). The crowdsourcing enablers will address issues such as privacy by design, identity management, security, reputation mechanisms, and data ownership.

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

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

4. End-user and societal value creation by analyzing the potential end-users and crowdsourcing participants to propose an optimized model for end-user adoption and societal value creation.

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

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

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

The project will adopt a multidisciplinary approach and address issues such as privacy and personal data protection. To achieve these ambitious goals, the consortium consists of seven international academic or research partners and a SME that bring in expertise from complementary research areas, including Information and Communication Technologies, End-user interaction, and Economics.


9

2.2 Purpose and scope of the WP 1

It is the purpose of WP1 to identify relevant crowdsourcing scenarios, the requirements coming from the end-users and coherent platform architecture. These requirements include the potential crowdsourcing contributors, heterogeneous network, privacy, authentication and data ownership.All this work will be aligned with the technical work to be carried out in all the technical work packages, where use cases and technical requirements serve as input 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 the task 1.1.

WP1 coordinates and aligns the overall strategy and facilitates activities in the overall project.

2.3 Purpose and scope of the Task1.1

In this task we identify a set of relevant use case scenarios and define the IoT Lab requirements from a multi stakeholder perspective. The ideation and design of the use cases will be done in close cooperation with the research community. These use cases will demonstrate the intended added value and usefulness of the IoT Lab tool and will address the challenges of heterogeneous networks, privacy, data ownership, scalability and sustainability. The portfolio will include use cases addressing technological research needs and challenges, as well as business and societal research perspectives. A set of functional and non-functional requirements will be derived from the use cases. These requirements will include research labs requirements (network, security and interconnection); crowdsourcing contributors/participant requirements with focus on privacy and participation incentives and end-user requirements. Moreover we analyse and address the interoperability gaps with particular focus on crowdsourcing resources and the associated FIRE infrastructures. The requirements will guide the development of task 1.2 as well as the subsequent technical work packages.

2.4 Purpose and scope of the current document

It is the objective of this document to describe the work carried out in the scope of task 1.1described above. This description includes the methodology followed for scenarios collection, metrics and categories for scenario selection for implementation, the use cases portfolio list and finally a list of requirements to be fulfilled by the work to be carried out in the other technical work packages.


10

3 Use Cases Portfolio

3.1 Methodology for Scenario Collection

As discussed in previous sections the ideation and design of relevant use case scenarios for the IoT Lab project is to be done together with the end-users. We need also to take into account the research challenges and needs from the project partners. We have therefore considered three input angles for the use case scenarios contribution, as follows:

1. Scenario brainstorms – scenarios coming from each of the project partners

reflecting their specific research/experimentation challenges.

2. Literature– these are scenarios collected from project partners’ internal reference

materials, general literature such as previous projects and existing crowdsourcing

platforms.

3. Stakeholder need based scenarios – scenarios emerging from a dialogue with

a group of selected end users or key stakeholders.

Figure 1: Scenario collection and selection methodology

In the following sections we will describe in more details each of the three input types. For each of the scenario ideas a use case template is to be filled out with information that includes the scenario description, stakeholders identification,IoT Lab relevance and respective impacts (business, research and societal).

After collecting the list of use cases, the templates will be used as reference for the ranking and selection of the most promising scenarios to be implemented in the scope of IoT Lab.


11

3.1.1 Scenario brainstorms

The consortium partners as “initial” users of the IoT Lab platform are a very important stakeholder group of the project. For this reason each of the partners has contributed with at least one use case scenario that addresses their current research challenges and needs. These challenges include technological, societal and business research questions that are envisioned to be solved/addressed by the specific use cases.

3.1.2 Other projects and platforms

Other very important input to the scenario portfolio is literature scenarios, coming from other projects or existing crowdsourcing platforms. We have therefore performed an extensive study of existing crowdsourcing platforms (together with WP2) and literature projects and extracted relevant crowdsourcing scenarios to this list.Platforms including Threadless, InnoCentive, Amazon Mechanical Turk and iStockPhoto were addressed (6.1). Projects such as SmartSantander, HOBNET, IoT6, TEFIS, Citi-Sense, SMARTIE and OutSmartprovide valuable inputs to theuse cases list both as references (6.2), as well as the basis for new crowdsourcing scenarios included in the scenarios portfolio.

3.1.3 Crowdsourcing

Finally and in order to involve the crowd in the ideation of use cases we have been in contact with the potential stakeholders of the IoT Lab. Through interviews and the organisation of workshops with the end-users we have gathered also relevant use cases. Together with WP5 we have defined guidelines on how to perform such kind of workshops/interviews as we can see in 6.3.

Another important point for the contribution from the crowd on the scenarios is that we have added in the IoT Lab website the possibility to the crowd to contribute with ideas for the project. We will through the duration of the project evaluate and consider new scenarios coming from the community.

3.2 Scenarios portfolio

ID: IOT-LAB-UC-1 Title: eCROWD

Narrative/Descriptive: Peter is an interaction designer working at Google in Aarhus. He has recently downloaded the IoT Lab application for his smartphone called Crowdee. When running the application for the first time Peter sets up his preferences, including which sensors the application can use

List of data sources:

• End-users’ smartphones

• End-users data (annotations, etc)


12

(accelerometer, GPS, battery level, noise level, temperature, humidity, etc), as well as his willingness to share his identity (users can choose to keep their anonymity). The sensory information is sampled periodically (time interval can also be set by Peter) and sent to the eCROWD system. This heterogeneous data is indeed very important for Jacob a researcher working at the Alexandra Institute. He is currently experimenting on the different transportation modes the citizens use in order to get to work, moreover he would like to know if the public transports are running on schedule (trains and buses).

The Crowdee application has the capability of inferring what kind of transportation mode the user is currently on through the combination of acceleration and GPS coordinates values, this includes also learning mechanisms so it is asked the user if he/she was really using that kind of transportation mode in a specific timeframe (user annotation of data).

For creating and setting up his experiment Jacob uses the eCROWD system experimenter user interfaces, where he specifies in detail the experiment’s characteristics, this includes a selection of users to run the experiment, constraints to the experiment, what kind of data is needed from the crowd, as well as specific questions that can be made to the user when running it, etc.

Since it is raining Peter decides today that he will take the bus to work, after getting on the bus Peter receives a notification from the Crowdee application asking him if he is using the bus and if it was on time, he answers positively and says that he is on bus 6A towards the Incuba Science Park. This information is stored in the eCROWD system for Jacob’s experiment and can also be actively used to notify other users that are waiting for this specific bus on its current location.

After the peek time Jacob can further process the collected data for this specific experiment calculating the distribution of transportation modes used by the citizens this morning, as well as the percentage of public transports running on time.

List of stakeholders:

• Citizens • City municipalities • Experimenters

Research Impact Potential:

Medium

Economic Impact Potential:

Medium

Societal Impact Potential:

High

Privacy Concern:

High

Table 1: eCrowd scenario


13

ID: IOT-LAB-UC-2 Title: Public reporting and participatory sensing

Narrative/Descriptive: Marko lives in Novi Sad. He has recently installed Android application for Public reporting and participatory sensing in the city of Novi Sad. He sets his personal data and identity in the preferences and his application is ready for participating. Marko is now able to report different events noticed in the city directly to municipalities.

These reports are available to other citizens that can rate published events. The rating mechanism is a part of trust and privacy and reputation mechanism that will be later developed within this scenario. Reports which municipalities should resolve are directly forwarded to communal department.

Users may subscribe for specific types of events or city parts. Reported events should be forwarded to the appropriate utility department.

Mobile application will collect measurements observed by sensors deployed with phone. Application user can choose sensors which can be used for participatory sensing. Now day smart phones are equipped with a various set of sensors. Mobile application may implements different measurements derived from the sensor’s observations like step detection or heart rate estimation. Step detection may be derived from the acceleration sensor’s data. Heart rate may be observed from the user finger using camera with close flash or using additional cheep ECG/HR device. From the detected heart beats additional processing may estimate stress level. User management will store user information like age, gender, profession. Estimated measurements may be used in the geo/social-specific research.

This scenario may be interesting to District Heating Plant (DHP) as well. User may report weak heating, as well as temperature sensor observations from their mobile devices. If several users report weak heating and observations confirms this claims, DHP have a good information about conditions in this building or apartments.

Experimenter can define rate of sensor reading as well as additional processing algorithms that should be applied to the raw observations. For example, Stevan as a heart rate variability analysis researcher is interested in collecting data from different users. Participant annotation is very useful, but researcher may be able to use and correlate another observations from participant ‘s smartphone regarding to



• End-users data (reporting, annotations, etc)




High


Medium


High

Privacy Concern:

High


14

detect user activity, in/out door measurements etc.

It’s very important to promote and made application attractive for a big set of users. Event reporting is implemented in the city of Novi Sad. Service name is mojNS and application is promoted by city government in several workshops.

Table 2: Public Reporting and participatory sensing scenario

ID: IOT-LAB-UC-3 Title: Citi-Sense air quality estimation

Narrative/Descriptive: In this scenario, Citi-Sense platform provides a facility to correlate air quality sensor’s observations with user reports. The concept of CITI-SENSE rests on three pillars: technological platforms for distributed monitoring; information and communication technologies; and societal involvement. Measurements collection is based on distributed data collection using innovative static, portable and personal devices (low-cost reliable micro-sensor packs) that communicate with data repositories through mobile phones or other devices.

Mobile application for this scenario has interface for reporting user’s air quality evaluation. Mobile application stores in the system user’s evaluation and location. If user location is near sensor device deployment, application may raise air quality evaluation interface and asks user to fill data. Collected data, user evaluations and sensor measurements may be used for further air quality research. Rough calibration may be performed by correlating collected user’s evaluations and sensor measurements.

Accessing to user’s air quality evaluation may be useful for peoples with sensitive respiratory tract.



• End-users data (reporting etc)




Medium


Low


Medium

Privacy Concern:

Low

Table 3: Citi-Sense air quality estimation scenario


15

ID: IOT-LAB-UC-4 Title: Lecture monitoring

Narrative/Descriptive: In this scenario, IoT Lab platforms provides interface for class monitoring. Participants in this scenario are equipped with mobile phones with installed appropriate application. Mobile application analyses sound in the classroom regarding to detect lecture voice, as well as characteristics of speech, level of noise etc. Using this observations mobile application estimates level of attention and overall quality of the lecture. Mobile application provides lecture rate interface as well.

Report from the mobile application contains estimated features of the analyzed sound, as well as user’s rates like annotation. Collected data may be useful for experimenter and his research of applied algorithms in the process of automatize lecture rating.



• End-users data (observations, annotations, etc)


• Citizens • Experimenters


High


Low


Medium

Privacy Concern:

Low

Table 4: Lecture monitoring scenario

ID: IOT-LAB-UC5 Title: Business and market studies


16

Narrative/Descriptive: John is a business analyst working at Bang&Olufsen in Copenhagen. He is currently in charge of analysing the market potential of B&O’s upcoming product BeoVision 11, a new line of televisions that will reach the market in the next couple of months. For conducting this analysis he is planning on a survey questionnaire where he would like to target people in age range between 30 and 50 years old. He uses the IoT Lab platform to specify the study and the target respondents´characteristics. He also elaborates the questionnaire where questions such as “Do you already have a B&O product?” and “What do you think of the upcoming BeoVision 11?”, “Would you buy the new BeoVisio 11?”, etc. He also targets the questionnaire to be sent to the participants when they are in the surroundings of a B&O shop, so they can see in the storefront a prototype model of the television. After answering the questionnaire the participants receive a 5% discount coupon on B&O products. With this valuable information John is able in two weeks to have a detailed study on the market potential and product flavor for this new coming product, he extracts the information from the IoT Lab platform and uses his own tools to have some graphical representation of the results so he can better present to his boss.



• End-users data (questionnaires)


• Citizens • Private

companies


High


High


Medium

Privacy Concern:

Low

Table 5: Business and market studies scenario

ID: IOT-LAB-UC6 Title: Participant Contest

Narrative/Descriptive: Michael is a participant of the IoT Lab platform. He has been in March rewarded with the distinction of “Participant of the Month” due to the number of experiments that he participated in, as well as the quality of the data provided by himself. The platform ranks the participants according to their



• End-users data


17

contributions where levels like: Beginner, Average Participant, Professional and Master of Data are attributed to the users. As “Participants of the Month” the participants can earn a prize of 15€ credit on their mobiles, 2Gb free data or free tickets for the cinema. This action helps to make the participants proactive on participating in experiments and at the same time making it fun and rewarding to participate in IoT Lab.


• Citizens • IoT Lab

owners


Medium


Medium


High

Privacy Concern:

Low

Table 6: Participant contest scenario

ID: IOT-LAB-UC7 Title: Gamification scenario (Ogame like en.ogame.gameforge.com/‎)

Narrative/Descriptive: CrowdWars is a strategy game set in space where the participants across the world can compete at the same time. A player starts with his one underdeveloped world and by developing it in terms of resources he is able to build facilities such as, a research lab, shipyard and his military force. By developing these infrastructures the player starts to have access to research technologies such as laser technology, plasma, combustion engine, propulsion engines, etc and researching on these technologies gives the possibility of building new ships and new defenses to your planet. For improving one level of these facilities or research technologies the player can use either resources produced in the game or by participating in a real experiment of the IoT Lab platform. By building an


• End-users’ smartphones • End-users data


• Citizens • Game company


Medium


18

armada players enforce their throughout the universe! Economic Impact Potential:

Medium


High

Privacy Concern:

Low

Table 7:Gamification scenario

ID: IOT-LAB-UC8 Title: Meeting record and mood monitoring

Narrative/Descriptive: Michele is an IoT researcher at CCSR and as such he hosts many meetings. To make meetings more productive he wants to crowdsource data using the participants’ mobile smartphone in order to record the meeting and to monitor the mood of the participants. He can do so by using the IoT Lab platform and deploying a script to enable audio recording from participants smartphones.

Alex is a meeting participants. When arriving at CCSR building, he touches the “I‎follow‎IoT‎Lab”‎Sticker‎and install theIoT Lab mobile app, giving consent to use its microphone. When his presence at the meeting room is detected, i.e., by means of the participant phone discovering a specific BT access point deployed in the existing IoT infrastructure, the crowdsource of specific sensor sources is performed. By running the provided script within the IoT Lab app, a record of the meeting is locally performed then automatically uploaded using the available WiFi network. Additionally, during the meeting, in order to know when to schedule meeting breaks, Michele uses the IoT Lab tools to inject questions/request for feedback into the participants’ mobile phones, either at pre-defined or random time, thus having the possibility to crowdsource participant answers. The collected answers gathered through the feedback mechanism can be also utilized to annotate additional data crowdsourced from



• End-users data • Testbed

infrastructure


• Meeting participant

• Meeting organizer

• Building Manager


Medium


Medium


19

participants mobile phone or other additional hardware, such as e-health wristbands, in order to detect and future prediction of the meeting mood. When a change in the mood is detected a rule can be defined by Michele so that a meeting break is automatically scheduled and communicate to participants by reconfiguring smart displays in the CCSR IoTtestbed infrastructure. When Alex leaves the meeting all the functionalities and the corresponding data collection are disabled, thus protecting its privacy.


Medium

Privacy Concern:

Medium

Table 8: Meeting record and mood monitoring scenario

ID: IOT-LAB-UC9 Title:IoT Lab as a tool to support Living Lab operations

Narrative/Descriptive: Marita is a project-manager working at a research institute in Sweden. She is an expert is user-participation and use-driven innovation and is often engaged in the Living Lab related activities at her institute. In one of their ongoing projects she is leading the process of user-engagement in a EU-funded initiative, USEMP, on new tools to give the end-users the control of their personal data in social media. To do so she wants to engage a number of volunteers in the design and testing of these new tools. Since before she is a participant in IoT Lab and has found it as an inspiring tool for her to be engaged in crowd-source driven research. Now she wants to initialize her project there. She posts her crowd-source initiative on the IoT Lab bulletin-board to find out the interest from the IoT Lab crowd to support her. To make a post on the bulletin-board is easy-she just logs in with her anonymous credentials on the webb-portal and then add specific information about her and the investigation to be approved as investigator. It´s also possible to propose investigations for the crowd via the IoT Lab UI. After two days she finds out that her initiative is highly ranked by the IoT Lab crowd and the IoT Lab host contacts her to formalize an SLA. When formal agreement has been arranged she is approved to start up her investigation. For her investigation she decided to manage the entire process by herself. The other option from IoT Lab was to get support via the IoT Lab Community manager to plan


• End-users data


• Citizens • Experimenters


High


Medium


Medium


20

and implement her investigation. But she is an expert-user. She receives log-in to a usage-account where she can plan and activate her specific investigation. As this is her first time as investigator at IoT Lab she has to fulfill an e-learning course to receive “the licens-to-drive at IoT Lab”. It takes her around one hour to go through all steps and to become accredited as IoT Lab investigator.

Next day she starts up her preparation. She logs in at her computer to the IoT Lab investigator portal and fill in relevant details for her investigation by using different forms. One important form includes to choose motivators for the investigation. When thinking about this for her specific investigation on Social media she believes it would attract many users easily and it will be a very small effort needed for each user – only 5 questions every evening in one week where individuals are asked to fill in their daily experiences from social media. She decides to go for the “volunteer motivator” and include a “social motivator” by showing up the number of participants and their geographical position to other participants.

She can pre-check the users view by using the IoT Lab “pre-check” feature or by using her mobile device for pre-test. Before inviting the IoT Crowd to her investigation she needs to get if qualified by the IoT Lab host.. The IoT Lab host checks the quality of the investigation and schedule the advertisement of the investigation in the IoT Lab scheduler. When approved Marita gets a message including details on when her investigation will start. It´s scheduled for next day.

Lisa is an IoT lab participant and has participated in several investigations. This morning she finds a new message in her IoT Lab App. Interesting, an investigation on social media habits. She remembers she voted for this investigation some weeks ago in the IoT Lab bulletin-board She reads the details about the social media investigation. It´s open to anyone and is not expected too much efforts. She chooses to apply and it´s now listed n her list on ongoing investigations. As she finds the topic very relevant and wants her friends to also support the research-team behind the initiative she shares the investigation with her social media contacts on Facebook and LinkedIn. Then she chooses “start investigation” The investigation starts at once. She is requested to fill in some basics about her Social media habits and next step will be to give details via the IoT Lab on her Social media usage on a daily basis during one week. The week passes by and the investigation is

Privacy Concern:

High


21

finalized. She receives a “thank you message” after the final step. She looks into the data she has entered and accepts it to be used for this specific investigation but she doesn´t want it to be re-used.

One week later Marita is waiting for the result. She has received a message with the information that the investigation is closed and that data is available. She is excited and as she has been able to keep track of the progress she knows there will be useful data to be analyzed. She logs in to her investigator account. It´s amazing – more than 1000 people has been supporting the study! She closes the investigation and send a personalized “thank-you message” for her respondents and invite them to follow the progress of the research project by accessing the project webbpage. Then she uploads the result-data to be stored at her research institute. As she has been using the IoT Lab questionnaire tool she can easily get a first summary of results in different diagrams. Next step for her will be to make more in-depth analysis of the raw data.

The investigation is closed and she is already thinking on what could be next. IoT Lab provides different types of investigation-formats and she is curious to know more about how others have used IoT Lab. She decides to take a quick look in the investigation library. Suddenly she finds her investigation in the list of performed investigations and her contact details are there. Hopefully she will get contacts from others doing similar studies or those who want to find new opportunities for collaboration. IoT Lab is not only a tool for crowd-source research – it´s also a community for collaboration and knowledge-sharing!

Table 9: IoT Lab as a tool to support Living Lab operations scenario

ID: IOT-LAB-UC10 Title: Managing Building Assets with Security Provisioning

Narrative/Descriptive: Researchers working at the premises of the UniGE building are localized, tracked as they move and uniquely identified inside the building. By using their smartphones they are able to set-up their personal preferences and interact with the building automations (e.g. specify personalized preferences regarding in-door lighting, access to their office, etc. switch between personal profiles and so on).


• End-users’ smartphones / NFC ID tags


infrastructure


22


• People working in the building



Medium


Medium


Medium

Privacy Concern:

Medium

Table 10: Managing Building assets with security provisioning scenario

ID: IOT-LAB-UC11 Title: Energy Efficiency Contest

Narrative/Descriptive:IoT Lab has just putted in run a contest between researchers of UniS, UniGe, MI and CTI. The goal of the contest is to reward the most energy efficient researcher of all the institutions. Each of the institutions has its own testbed facility measuring different parameters, this includes sensors placed in each of the working desks of the participants measuring the energy consumption at the working desk. Using the IoT Lab mobile app the following interaction with the participants can be easily achieved. In a first phase, to tune the platform, when a high energy consumption for a particular desk is detected, requests for the desk’s user to annotate his/her status are displayed on the user mobile phone. In a second phase, the IoT Lab platform receives and sends all this information from the sensors to the




infrastructure


• People working in the building



23

participants mobile phone. Additionally, to avoid tracking the participant, a small script is deployed in the mobile phone in order to trigger an alarm if the participant WiFi cannot detect a specific WiFi APs identifying participant office, thus meaning that the participant is out of office and wasting energy. After on month of experiment, the most energy efficient researchers is identified. The goal of this experiment is by one hand to make it fun to participate in such an experiment and by other hand make the researchers aware that energy should not be wasted.


Medium


Medium


Medium

Privacy Concern:

Medium

Table 11: Energy Efficiency contest scenario

ID: IOT-LAB-UC12 Title: Energy efficiency and user comfort in HOBNET enabled environments, using mobile crowdsensing hints

Narrative/Descriptive:

HOBNET enabled infrastructures: o Industrial environment (brewery factory) o Academic environment (U. Patras

classrooms) o Home/work environment (in-house/CTI-

offices deployment)

Mobile crowdsensing hints exploitation, provided online by the users:

o Mobility levels (e.g. when/where there is high crowd mobility, the temperature should be decreased and vice versa)

o Temperature maps and air quality (e.g. used for multi-HVAC fine-tuning)

o Sleeping/lying/sitting/moving states (e.g. for adjusting room conditions in order to maximize user comfort)

Target energy efficiency and user comfort.


• End-users’ smartphones • End-users data • Testbed infrastructure


End-users

Industries, companies

Universities

Home/Office buildings Experimenters/users

Industrial workers and employees

University students

Residents/Office employees

Consortium partners

CTI


24

Researchers/students

Master and PhD students (U. Patras):

o use for experimental reasons

o use cases proposal o use of results in

research/studies

FIRE researchers

Researchers will be able to design, implement and evaluate different crowdsensing methodologies:

o Different incentive policies, i.e. how a central server can expend a given budget in order to convince crowd members to participate in an experiment

o Different join policies, i.e. in what way crowd members can react to a potential payment in order to join an experiment


High


Medium


Medium


25

Privacy Concern:

Medium

Table 12: Energy Efficiency and user comfort in HOBNET enabled environments, using mobile crowdsensing hints scenario

ID: IOT-LAB-UC13 Title: HEPIA Sustainable Week – crowdsourcing driven energy efficient buildings

Narrative/Descriptive: The HEPIA (University on applied sciences) is organizing a week on sustainable developments on a yearly basis. Students are invited to develop projects in relation with the sustainable development. We are currently discussing with the HEPIA to deploy and equip a whole floor of the university with sensors and actuators to control the energy parameters: metering, sensing and actuation on light and blinds. The students will be invited to use the IoT Lab platform for crowd-sourcing driven research. They will be invited to suggest ideas on how to optimize the energy consumption. They will be invited to rank them, select and implement some of them, and assess the impact of the developed solutions through the IoT Lab mobile application.




infrastructure


• Students • Professors • Visitors and people

working in the building


High


High


High

Privacy Concern:

Medium

Table 13: HEPIA sustainable week - crowdsourcing driven energy efficiency buildings


26

scenario

ID: IOT-LAB-UC14 Title: IoT Lab Online Trading Game


Frank is a Finance researcher interested in the relationship between environmental conditions and trading decisions. He proposes to have IoT Lab participants participate in an online multi-player trading game experiment, whereby participants play using their smartphones or tablets via their IoT Lab app. Environmental conditions such as noise level, luminosity, temperature, motion detection, distance-from-home, distance-from-work, time-of-day, etc. will be recorded while player play the game. Frank will then analyse the data to determine the relationships between the environmental decisions and the buy/sell decision within the game. The specific nature of the trading game is yet to be determined. There are elaborate online business games like Virtonomics that could be used as a model. Alternatively, there are games that are built around illegal drug dealing that might attract a greater level of participant engagement. Frank is aware of at least one open-source trading platform that has been used in classroom settings where students trade with each other via netbooks, which could be adapted for use over smartphones/tablets.


• End-users smartphone sensor data

• User game interaction input


• Experimenter

• End Users


High


High


High

Privacy Concern:

Medium

Table 14: IoT Lab online trading game scenario

ID: IOT-LAB-UC15 Title: Demographic Migration Tracker


27


Steve is a market researcher in the (terrestrial) advertising industry. He is interested in knowing the gathering places, walking routes, driving routes, train journeys of various demographic groups in order to identify the optimal deployment of ads on billboards and on-train ad spaces that his company owns. He would like to track the movements of users as they go about their daily lives. He does not wish to know individual identities but only broad general demographic profile information of each user.


• Testbed infrastructure


• Citizens

• Researchers

• Professors

• Universities

• Research Institutes

• Entrepreneurs


High


High


High

Privacy Concern:

Medium

Table 15: Demographic migration tracker scenario

ID: IOT-LAB-UC16 Title: Colours and Customer Purchases


John is a marketing researcher in the clothing industry. He is interested in knowing the relationship between the colours of the shop (for instance: colours of the wall,




28

colours of the floor and the shelves, etc.) and the level of the customers’ purchase (analysis time: three months) in order to identify the optimal colours of the shop that maximize the level of business performance. He would like to know how change the level of purchase in relation to the different colours applied in the shop. He does not wish to know individual identities but only broad general informationon how colours affect the purchase.


• Universities


• Entrepreneurs


High


High


High

Privacy Concern:

Medium

Table 16: Colours and customer purchases scenario

ID: IOT-LAB-UC17 Title: Selling Policies and Customers Behaviour


David is a marketing management PhD Student in the retail-food industry. He is interested in knowing the selling policies of superstores in allocating products on the shelves in order to understand which marketing strategies dominated these selling policies. He would like to track the movements of users within superstores to assess if the selling policies affect the customers behaviour. He does not wish to know individual identities but only general profiles of ideal customers.




• Universities


• Entrepreneurs


High


29


High


High

Privacy Concern:

Medium

Table 17: Selling policies and customers behaviour scenario

ID: IOT-LAB-UC18 Title: Shops Temperature and Selling Percentage


Mark is a marketing researchers in the clothing industry. He is interested in knowing the best level of the shops’ temperature in order to maximize the sales total amount in a given period. He would like to track the different perceptions of the potential customers inside shops at any change of temperature. He does not wish to know individual identities bad only broad general perception of each users.




• Universities


• Entrepreneurs


High


High


High


30

Privacy Concern:

Medium

Table 18: Shops temperature and selling percentage scenario

ID: IOT-LAB-UC19 Title: Shops Light Effects and Maximization of Business Performance


Michael is a marketing researchers in the luxury industry (jewellery and Yacht). He is interested to detect how the effect (in terms of intensity) of the light affected the level of sales of luxury goods in order to increase the level of business performance. He would like to track the different perceptions of potential customers inside shops at any change of the light. He does not wish to know individual identities but only broad general perception of each users.




• Universities


• Entrepreneurs


High


High


High

Privacy Concern:

Medium

Table 19: Shops light effects and maximization of business performance scenario


31

ID: IOT-LAB-UC20 Title: Effects of Light Colours and Maximization of Business Performance


Lucas is a marketing researchers in the luxury industry (jewellery and Yacht). He is interested to detect how the effect (in terms of intensity) of the light colour affected the level of sales of luxury goods in order to increase the level of business performance. He would like to track the different perceptions of potential customers inside shops at any change of the light colours. He does not wish to know individual identities but only broad general perception of each users.




• Universities


• Entrepreneurs


High


High


High

Privacy Concern:

Medium

Table 20: Effects of light colours and maximization of business performance scenario

ID: IOT-LAB-UC21

Title: IoT Lab Online Focus Group


Valerio is a researcher in management interested in the relationship between internationalization, innovation and entrepreneurship in global markets. In particular, he want identify an innovative business models for new technology-based firms applicable both academic and


• End-users smartphone sensor data

• User game interaction input


32

real worlds. To do that, he propose to have a IoT Lab participants (entrepreneurs) who participate in an online multi-player focus group experiment, whereby participants play using their smartphones or tablets via their IoT Lab app. The specific nature of the focus groups is to identify one of the main business models applied to technology-based firms. New technology-based firms, particularly those that develop their business around a new technological platform, are likely to be impacted by globalization (in terms of both pace of innovation and pressure of competition. Valerio will then analyze the data obtained (opinion from entrepreneurs), whit qualitative methods, in order to understand which business models is more appreciate from entrepreneurs.


• Entrepreneurs

• Researchers

• Professors

• Universities


• End-Users


High


High


High

Privacy Concern:

Medium

Table 21: IoT Lab online focus group scenario

3.3 Use Cases selection metrics

After collecting the initial list of use cases we need a mechanism to select the most promising ones for implementation. We have therefore organized a small workshop in the Riederalp meeting for working on a metric for ranking of the use cases. In this workshop we have first brainstormed on the possible categories for ranking of use cases, they are as follows:

Feasibility – in terms of availability of data, algorithms and resources.

Sustainability – in terms of savings and resources.

Scalability – performance and resources.

Visibility – how visible is this scenario to the community.

Economic Impact – in terms of revenue potential and savings potential.

After deciding on the categories for the ranking of use cases and given that some characteristics have higher weight than others we have also brainstormed on the weight for each of the categories. The weight for each of the categories was voted


33

and distributed as follows:

Category Weight

Feasibility 0,45

Sustainability 0,18

Scalability 0,17

Visibility 0,16

Economic Impact 0,09

Table 22: Scenario Categories and Weights

From the results and the discussions in the workshop we can see that feasilibity is very important when classifying a scenario with particular focus on the resources needed for implementing such a scenario, whereas the other characteristics have similar weight.

As final step for the ranking of the scenarios we have asked all the partners to classify each of them in terms of these characteristics with a vote from 0 to 3, where 0 means that the scenario scores low in this characteristic (p.e. scenario not scalable), whereas 3 is the highest score (p.e. scenario has very high visibility). Moreover we have asked the partners for the most promissing features for each of the scenarios, as well as a selection of the three best scenarios in their perspective. The results of such voting can be seen in 6.4.

3.4 Scenario selection

As a result of the ranking of the scenarios we have selected a subset of them that will be further investigated for implementation. This selection takes into account the total scores of the scenarios in terms of their characteristics combined with the total number of votes from the partners. The subset of the scenarios, are as follows:

Use Case Functionality summary

UC11 – Energy efficiency contest Federated testbeds link

UC2 – Public reporting and participatory sensing

Core app (crowdsensing and crowdsourcing by events)+questionnaires

UC12 - Energy Efficiency and user comfort in HOBNET enabled environments, using mobile crowdsensing hints

Comfort hints


34

UC13 - HEPIA sustainable week - crowdsourcing

Event organisation for new ideas

UC1 – eCROWD Core platform

UC5 – Business and market studies Business angle

Table 23: Best ranked scenarios

For the above listed scenarios we can identify synergies between some of the them, leading us to further investigate the possiblity of merging similar scenarios. On the other hand, the degree of complexity of a scenario should be kept in a comprehensive level, meaning that each scenario should include a representativenumber of functionalities.

All these considerations led us to identify two different scenarios for implementation: one scenario focused on the physical testbeds interaction and the other one focused on smart city.

For the testbed related use case we will consider UC11, UC12, UC13 and UC5, whereas for the smart city scenario we will consider the scenarios UC1, UC2 and UC5.

For the business and market studies use case we decided to extend the scenario’s description in order for it to be transversal to both use cases. The description is the following:

Market Focused Use Case

IoT Lab technology is uniquely placed to measure the relationship between environmental conditions and consumer decisions. Academic research by psychologists and behavioural economists clearly shows that humans are not as objective or clinical in their decision making as many people might like to think and that environmental conditions can strongly bias the decisions that people make. Nobel prize (in Economics, 2002) winning research by Kahneman and Tversky showed that prior exposure of an audience to a high or a low number had a measurable influence on how that audience subsequently estimated a variable that most of them would not know the answer to (e.g. an American audience was asked what percentage of African countries are members of the UN). This bias has been shown to extend to people’s estimation of the value of an object and to the bidding behaviour of auction participants. In another study, the propensity of Israeli judges to free prisoners applying for early release was shown to be strongly affected by the time of day. In yet another study, getting an individual to hold a hot drink had a measurable influence on that individual’s propensity to have someone fired, while another study showed that sunny weather has a clearly measurable positive influence on stock market returns.

This knowledge is potentially valuable for businesses, e.g. if certain condition levels of light, temperature, etc. are associated with higher sales, a business can try to maximise sales by controlling those conditions to keep them at the levels associated with maximum sales. Some businesses already exploit such insights in order to


35

maximise sales. Perhaps the most striking example of this is the casinos of Las Vegas who are rumoured to use indoor lighting to distort their customers’ perception of daytime and to pump extra oxygen through their air conditioning systems in order to keep their customers awake and gambling for longer than they otherwise would. A similar reason is often put forward as to why bars serve free salty snacks. Indeed, a large part of the agenda of the advertising industry is to influence people to buy things they would not otherwise buy, which they do by associating products with known human motivations and aspirations.

From an individual’s perspective, some people might object to being manipulated in this way and might appreciate being informed of how environmental biases could be used to influence their decisions so that they could adopt strategies to negate these influences.

Decisions can be recorded in two forms: actions and opinions. An example of an action could be the purchase of an item, while opinions can be elicited via surveys. The time, location and environmental conditions associated with the decision can be recorded. If a large number of instances of decisions and environmental conditions can be recorded, then the relationship between the two can be studied and analysed.

There are many business applications that we could explore. However, there are two impediments to many of these. First, they can be complicated and therefore expensive to develop an application for. Second, there may be concerns about privacy that need to be addressed and/or accommodated before proceeding.

We propose to implement a relatively straightforward study in this area, whereby we will elicit opinions from consumers about products prior to the point of sale. We will achieve this by asking consumers to complete a smartphone/tablet based in-shop questionnaire (triggered by a QR code or NFC or by having the customers complete the questionnaire on a tablet we supply for the purpose) prior to purchasing an item. The consumer will be incentivised to engage with our survey by the offer of a discount on the purchasing price, which will be realisable immediately upon completion of the survey. Smartphone/tablet sensor reading can be recorded at the time the questionnaire is completed. All this information will be presented to the participant through the use of the IoT Lab mobile phone application.

Table 24: Market focussed use case

In the following subsections we will describe in detail the two scenarios for implementation, the descriptions will follow the IoT-A methodology[2].

3.4.1 Smart City Scenario

UC ID Scenario Name

GAME_SUPERMARKET_MARKETING Game and Supermarket Marketing


36

Description

This scenario proposes the use of the IoT Lab application in the form of a game playable on mobile phones.The game is envisaged to be something that can attract the “crowd” and through additional functionality facilitate their involvement in the IoT Lab experiments. These experiments can require both crowdsensing data (GPS, temperature, etc.) measured by the mobile phone’s sensors and crowdsourcing data (action to be taken by the user like recording noise at a given location, answer a questionnaire, etc.).

The first time the IoT Lab application starts device and user registration (minimal information is required by the participant) take place. This information is stored in the IoT Lab platform and used by the platform in order to identify the crowd resources that best fit the requirements of an experiment.

As an investigator the user has also to register on the platform(via IoT Lab web portal) to receive credentials for accessing the platform. The investigator can manage and define experiments by specifying the data needed, periodicity, algorithms to be used, crowd resources needed, etc. The platform validates the experiment and matches the required resources. In order to collect participants for the experiment the platform sends the experiment description information to the mobile phones, where the users can visualize the detailed description of the experiment, including the data needed for the experiment, as well as the privacy details. As a part of this, participants may be asked for more specific information (personal or device related). In case of participants’ acceptance the experiment will be executed and the results/data sent to the IoT Lab platform. After the experiment’s execution the investigator may retrieve the results and even export them to an external tool.

As a specific investigator role in this scenario we will try to involve a local business (supermarket). Their goal is to perform marketing of their services and products, receive feedback from their clients on the services delivered, as well as increase sales. This supermarket is deploying a mobile game as a promotional tool (driving a trolley through the shop aisles, everything branded according to the supermarkets’ corporate identity). We plan to expand this game and integrate IoT Lab tools into it to enable the supermarket to run the investigations they would like to perform.

This investigation will consist of two types of actions: 1) questionnaires that serve as market surveys on the services or specific products; 2) data about the routes customers take through the shop, including micro-locations that attract most interest of the customers. This second function will be implemented using indoor location system based on Bluetooth beacons. In case of participation, the citizens will receive discount cards through the application, valid for purchases in the shop.

These market campaigns’ data results can be evaluated and compared with previous sales data, allowing the investigator to assess the success of the campaign.


37

IoT Context View

Actors Involved (& Role played)

Physical entity: phenomena measured by the participant’s mobile phones’ sensors.

Virtual entity: data related to the knowledge of the crowd.

Experiment: digital representation of an investigation to be performed in the platform.

Experiment Result: virtual entity, i.e. data outcomes of the execution of an experiment.

Marketing Campaign: specific experiment specified by the supermarket admin.

Experiment Action: questionnaire/action to be performed by the participant as a part of an

experiment

Experiment Manager: component responsible for managing experiments; it interacts with

investigators and the crowd, as well as the resource manager, for resource lookup,

registration, rating, etc.

Resource Manager: component responsible for management of all resources, including

resource registration, lookup, etc.

Campaigns Tool/Experiment Manager Client: external tool and experiment manager client

the supermarket admin uses to create and manage his marketing campaign. This component

interacts with the experiment manager of the IoT Lab platform for specifying and executing

the experiment in the IoT Lab context.


38

Security and Privacy Requirements

Device registration

User registration

User data anonymization

Profile and virtual identity management must be supported

Privacy policies management must be supported.

Secure communication between mobile and the platform.

Identification and authentication mechanisms for the involved actors (participants and

investigators) must be provided.

Participant reputation mechanisms should be provided.

Secure communication between investigators (Supermarket admin included) and the

platform

Experiment Validation mechanisms must be supported.

The following diagram illustrates the different levels of scenario, use cases, services and requirements:

Figure 2: Supermarket marketing scenario diagram


39

3.4.2 Physical Testbed Scenario

UC ID Scenario Name

ENERGY_SCENARIO Energy efficiency and user comfort hints

Description

This scenario proposes the use of different testbeds, including CTI, HEPIA, Batelle, Surrey and potentially Athens airport and a Heineken breweryin Greece. The scenario provides three main functionalities as follows: the first one crowd sensing to adapt energy efficiency to crowd presence and behavior: HVAC, lightings, etc. Smart actuation for energy efficient personalized comfort based on detailed ambient information and user status. When a user’s smartphone starts the IoT Lab application his sensor readings (e.g. temperature) are sent to the energy optimization/automation server (ambient map); his phone’s sensor hints (accelerometer, gyroscope) are used to extract its status (lying, moving, etc.) (my status); the user selects a desired energy/comfort trade-off (my preferences).

According to the inputs mentioned above the actuation is triggered (lights, HVAC, windows, etc.)

The second functionality consists of crowdsourcing to collect end-users feedback on user acceptance, where users are requested to provide satisfaction feedback via the crowdsourcing tool using their smartphones. Comparative experiments are performed with distinct subgroups, following two main approaches: different energy-optimization solutions compared in the same building with different subgroups of users; same solution tested in various buildings located in different regions. The main parameters to be measured and monitored will include: energy consumption, end-user acceptance, experimenters’ satisfaction, market potential and finally societal impact.

The final functionality is a solutions contest and crowd-sourced driven optimization, where we will deploy and comparatively evaluate different automation policies (and corresponding manual/semi-manual operations), so as to identify a few most suitable ones according to defined criteria; users inside the smart building are being tracked by the system, which takes into consideration their positions and preferences and feeds them as input to the automation policy; the building automations are adjusted on the automation policy; users are prompted to evaluate the current conditions inside the building via their smartphones, feedback is provide to the automation policy.

The HEPIA (University on applied sciences) is organizing a week on sustainable development on a yearly basis. Students are invited to develop projects in relation to the sustainable development. We are currently discussing with the HEPIA to deploy and equip a whole floor of the university with sensors and actuators to control the energy parameters: metering, sensing and actuation on light and blinds. The students will be invited to use the IoT Lab platform for crowd-sourcing driven research. They will be invited to suggest ideas on how to optimize the energy consumption. These ideas will be ranked through the IoT Lab application and the best ranked solutions will be addressed and implemented by the students themselves. In a second stage the students will be invited to provide feed-backs as end-users on different implementations that will be tested in different rooms of the building, which are part of


40

the HEPIA testbed, with the possibility to control and automatize various parameter, such as lighting, heating and blinds. They will be invited to provide feedback on the comfort level and satisfaction for the implemented solutions. The IoT Lab application will enable to collect anonymized, but differentiated feed-backs, according to the time and location of the participants. It will also collect crowdsensing data, to assess the environmental temperature and behavioural activity. The solution with the highest level of energy saving and end-user acceptance will be awarded.

IoT Context View


Sensing Data: phenomena measured by the participant’s mobile phones’ sensors and the

testbed resources

Sourcing Data: data related to the knowledge of the crowd, this includes user acceptance and

comfort levels

Experiment: digital representation of an investigation to be performed in the platform.

Experiment Result: data outcomes from the execution of an experiment.

Experiment Manager: component responsible for managing experiments,interacts with both

investigators and the crowd, as well as the resource manager, for resource lookup,


41

registration, rating, etc.

Resource Manager: component responsible for management of all resources, including

resource registration, lookup, etc.

Testbed resource: resource providing sensing or actuation capabilities (HVAC, lights,

windows, thermometers, energy meters, etc)

Security and Privacy Requirements

Device registration

User registration



Privacy policies management must be supported.

Automation policies must be supported.

Secure communication between mobile and the platform.

Secure communication between the platform and the testbed resource.

Identification and authentication mechanisms for the involved actors (participants and

investigators) must be provided.

Participant reputation mechanisms should be provided.

Secure communication between investigators and the platform

Experiment Validation mechanisms must be supported.

The following diagram illustrates the different levels of scenario, use cases, services and requirements:

Figure 3: Physical testbed scenario diagram

3.4.3 Derived services

For the two scenarios we have identified five different services (four of them


42

common). In this subsection we will describe each of the services in detail.

3.4.3.1 Data Access Control Service

Service ID Service Name

IOTLAB_SERVICE_DATA_ACCESS_CONTROL DATA ACCESS CONTROL

Description

This service provides an access control to the system components through implementation of all authentication, authorization and accounting (AAA) mechanisms. Access to the virtual entities is provided for the registered users only. Data access is restricted to registered users allowing only those having a digital profile with sufficient privileges to retrieve certain information. Data access control handles several users’ roles.

IoTContext View


User (A): User with permission to register a new virtual entity, i.e. a profile for other users

User (B): A person that accesses the entities directory (mostly investigators)

Information: A virtual entity as a passive digital artefact, which is a digital representation of physical entities. In this case the main information includes the user identification as well as the other associated information such as roles, permissions etc.

Entity directory: Resource that contains global information about physical entities, services and other resources.


43

Service Requirements

Device ID registration/User registration


Entities directory

Secure communication between the user and the platform (AAA)


Identification and authentication mechanisms for involved actors must be provided

Entities directory (to implement Users Directory)

Depending on access control policies, access requests will be evaluated

Service Features

User management AAA

Secure communication between the user and the platform

Data access to virtual entity

User interface to show access result

3.4.3.2 Data Query


IOTLAB_SERVICE_DATA_QUERY DATA QUERY

Description

This service provides virtual entity as representation of information requested from the users. Access to the virtual entities is provided to the registered users that have the authorization to access this specific information. This service includes resource lookup, for crowd and testbed resources, as well as experiment data querying.

IoTContext View


44


Investigator: User with permission to query a virtual entity.

Resource (crowd or testbed): the resource to be accessed.







Context and influence on privacy policies must be properly formalized


Depending on access control policies, access requests will be evaluated

Secure communication between the resource and the platform

Access to requested data to be retrieved from a local database

Service Features



Data access to virtual entity in the entity directory

User interface to show data result

3.4.3.3 Data Submission


IOTLAB_SERVICE_VIRTUAL_ENTITY_SUBMISSION VIRTUAL ENTITY SUBMISSION

Description

This service is twofold: it comprises the submission of virtual entities (experiments) from the investigators, as well as virtual entities (experiment data) coming from the crowd or sensors (sourcing or sensing related data). For the submission of experiments a clear validation must be performed in order to check that it complies with the requirements of IoT Lab and it is trusted and secure experiment. After validating the experiment the system must find the resources that best fit the requirements of the experiment (resource recruitment), finally after the recruit phase the experiment can be scheduled to run.

For the crowdsourcing and crowdsensing data submission the communication must go through the AAA component and if validated the information must be stored in a database that contains the data related to the execution of an experiment.


45

IoTContext View


Investigator: User with permission to submit a virtual entity.

Resource (crowd or testbed): testbed resource contributing with data.






Secure communication between the resource (crowd or testbed) and the platform (AAA)


Mechanisms for saving the data persistently in the platform must be provided



Service Features



Interface for data submission

Possible acknowledge data received


46

3.4.3.4 Perform Experiment


IOTLAB_SERVICE_PERFORM_EXPERIMENT PERFORM EXPERIMENT

Description

This service also includes the service above mentioned (IOTLAB_SERVICE_VIRTUAL_ENTITY_SUBMISSION), providing the functionalities for virtual entities submitted from crowd and testbed resources. The IoT Lab platform must keep track on the resources status; in case a resource is not available a new resource must be assigned to complete the task. Virtual entity from the resources can also be processed locally and results saved persistently. Mechanisms for validation of virtual entity should also ensure that the information received from the resources is acceptable. Reputation mechanisms should be updated according to the performance and the quality of the data received from a resource.

IoTContext View


Investigator: User with permission to submit a virtual entity.

Crowd: crowd resource contributing with data (sensing and sourcing).

Testbed Resource: testbed resource contributing with data and actuation capabilities.




47




Secure communication between the resource (crowd or testbed) and the platform (AAA)


Reputation Framework must be implemented.

Participant status must be known

Participant reassignments if non available.



Service Features



Interface for data submission

Participant status lookup

Reputation Framework

3.4.3.5 Participant Localization


IOTLAB_SERVICE_PARTICIPANT_LOCALIZATION PARTICIPANT LOCALIZATION

Description

This service provides means for localizing the participant (indoors) based on Bluetooth beacons (supermarket case), as well as NFC and/or QR codes (testbed case). The platform must keep track of the participant’s location and actuate according to these values.


48

IoTContext View


Testbed Resource (Bluetooth beacon or NFC/QR): testbed resource that allows to localize the participant.




Secure communication between the resource and the participant device

Service Features


Bluetooth discovery component

This is an initial specification of the services to be provided by the IoT Lab platform tools. Further investigations and considerations will be made in the context of the other technical work packages.

4 Detailed requirements

In this section we derive the functional and non-functional requirements for the IoT Lab platform based on the provided use cases, core platform requirements as well as inputs from the other technical work packages. These requirements form the foundation of the architecture and components specification and work carried out in WP1, WP2, WP3 and WP4. During the project we will revisit the requirements in light


49

of new inputs for new use cases coming from the research community, the lessons learned from the technical work carried out in the other work packages and the advisory board.

In 4.1 we clarify the terminology and notation used to write down requirements. The general objectives and basic conditions relevant for the IoT Lab platform are lined out in section4.2. In section 4.3we discuss the privacy and data protection requirements. In section 4.4 we provide the functional requirements that are complemented by the non-functional requirements in section4.5.

4.1 Terminology and Notation

A requirement [3] is a statement about a property to be satisfied or a service to be provided by a product, a process or the people involved in the process. The definition of requirement can be done in three different levels of abstraction: objectives form the foundation of requirements; use cases and features form a rough definition of user requirements. The requirements in terms of functionality, quality and architecture are low-level details of the features and use cases. User requirements are more general than system requirements and reflect the specific needs from the end-user on the specific interaction with the process.

User requirements

o Use case template

o Features

System requirements

o Functional requirements

o Non-functional requirements

Quality requirements

Architectural requirements

Moreover functional requirements are used to describe required capabilities while non-functional requirements are used to describe required constraints.

A requirement can be written following the next structure:

Figure 4: Formal structure of a requirement

Example: When the investigator (actor) enters his credentials (condition) the IoT Lab platform (application) must verify (action) the user details (object) with the investigator database (details).

(Who?)

• Actor

(Under what conditions?)

• Condition The

(application) shall

(Process)

• Action

(Things to be processed)

• Object

(Process details)

• Details/Further Actors


50

Moreover a requirement has the following properties:

ID

Title

Comment

Attributes

o Need

o Stability

o Priority

o Source

Component and interaction

4.2 Objectives and Basic Conditions

The IoT Lab project aims at researching the potential of crowdsourcing to extend IoTtestbed infrastructure for multidisciplinary experiments with more end-user interactions. The IoT Lab platform shall enable investigators to carry out experiments that interact both with testbed resources, as well as with the crowd resources.

The IoT Lab platform shall provide features like scalability, network and resources heterogeneity and privacy and data protection mechanisms. The platform shall also provide means for the crowd to participate in such experiments, this participation shall include both as crowdsourcing and crowdsensing mechanisms.

The need for scalability requires federation and virtualization of testbeds to enable the creation and interaction with larger testbeds.

The need for heterogeneity of hardware requires modularity of design.

4.3 Privacy and data protection

Privacy and data protection are two very important concepts when conceptualising and designing the IoT Lab tools for the end-users. As information such as GPS location and other sensory information will be obtained from the user’s smartphones we need to embed privacy into the design of these tools. The crowd will have privacy as a default setting when using IoT Lab, meaning that the user is able to select what information he/she wants to share and when. User profiles are anonymous by default where only in case the user wants to share personal information he is able to add it to his/her profile. The user is also able to manage the data he/she has contributed with to the experiments, meaning that this data can be deleted or anonymised at any point in time.

All these considerations will be written as requirements to the platform and further analysis on these concepts will take place in other work packages (WP2 and WP5).

4.4 Functional requirements

4.4.1 Authentication, Authorization and Accounting


51

ID FR001

Requirement End-user profile management (application)

Comment When using the IoT Lab application participants must be able to configure their profiles, this includes the selection of sensors users would like to share, as well as the possibility of sharing their identities or keeping their anonymity.

Attributes Need v.high

Stability v.high

Priority v.high

Source General platform

Component and Interaction IoT Lab platform must provide an interface that allows the participant to create and manage his profile. The application communicates with the IoT Lab platform to perform these operations. The information must be stored persistently in a database.

ID FR002

Requirement Investigator profile management

Comment The investigator must be able to create and manage his IoT Lab account.


52


Stability v.high

Priority v.high


Component and Interaction The IoT Lab platform provides web interfaces that allow the investigator to create and manage his/her profile. The information must be stored persistently in a database.

ID FR003

Requirement Investigator authentication

Comment In order to use the system the investigator must authenticate himself by providing his credentials.


Stability v.high

Priority v.high


Component and Interaction The IoT Lab platform provides web interfaces that allow the investigator to insert his credentials and provide authentication functionality.


53

ID FR012

Requirement Investigator Authorisation

Comment When an investigator wants to execute any action the system has to verify that he is authorised to perform this action


Stability v.high

Priority v.high


Component and Interaction Account management - the system must have an overview of what the investigator can or cannot do

ID FR019

Requirement User account management

Comment The system administrator shall be able to grant and revoke user access privileges to both investigators and participants.


Stability high


54

Priority high


Component and Interaction User Accounts Management

ID FR022

Requirement Sharing of social media related data

Comment The system shall provide means so the participants (if willing) may share social media related data

Attributes Need Medium

Stability medium

Priority Medium


Component and Interaction Participant profile management

4.4.1.1 Reputation Framework

ID FR031

Requirement Reputation framework


55

Comment The system has to provide means for classifying the participants participation, this calculation takes into account parameters such as the availability of the participant, their commitment to participate in experiments, as well as the quality of the data contributed by the participant.

Attributes Need high

Stability high

Priority high


Component and Interaction Crowd Resource Classification

ID FR051

Requirement Incentive redeem and reputation review (IRC)

Comment The IoT Lab mobile app must provide the participant with functionalities to review his/her reputation and to redeem the gained incentive

Attributes Need v.High

Stability v.High

Priority v.High

Source IoT Lab mobile app/Generic platform


56

Component and Interaction The IoT Lab platform must be able to push to the IoT Lab mobile app participant reputation score and instruction on how to redeem incentive

4.4.2 Experiment Management

4.4.2.1 Experiment Configuration

ID FR004

Requirement Uniform experiment description

Comment An experiment requires a standardised representation within the information model of the IoT Lab platform


Stability v.high

Priority v.high


Component and Interaction Experiment Configuration - The IoT Lab platform a uniform way of representing an experiment.

ID FR005

Requirement Experiment configuration


57

Comment When the investigator uses the IoT Lab platform, the system must provide a mechanism to specify and configure experiments to be carried out. This includes a declarative specification of the experiment and its requirements (constraints on type and number of resources, target environment, etc)


Stability high

Priority high


Component and Interaction The IoT Lab platform provides web interfaces that allow the investigator to specify and configure his experiment.

ID FR008

Requirement Experiment configuration reuse

Comment The system shall provide a mechanism to save experiment configurations and reload them for further experiment iterations.

Attributes Need medium

Stability Medium

Priority Medium


58


Component and Interaction Investigator's "workbench" data should include a historical list of his experiments that easily give him the possibility of reusing such experiments.

ID FR016

Requirement Integration with tool for graphical representation of experiment results

Comment The system shall provide integration with an external tool that provides a graphical representation of the results of an experiment to the investigators.

Attributes Need medium

Stability medium

Priority Medium


Component and Interaction Experiment Configuration - a simple graphical representation of the experiment results shall be provided to the investigator

ID FR018

Requirement Participant experiment configuration

Comment The system must provide the participant with apossibility of accepting or rejecting to take part inan experiment. A clear description of the


59

experiment and the data needed from the investigator must be shown to the participant.


Stability v.high

Priority v.high


Component and Interaction Experiment Management/Configuration - The IoT Lab platform must interact with the mobile application for acceptance/rejection of the participation of the participant in a specific experiment.

ID FR036

Requirement Participant experiment opt out

Comment The system must provide the possibility for the participant to opt out from a previously accepted experiment at any time.


Stability v.high

Priority v.high

Source Generic platform/IoT Lab mobile app


60

Component and Interaction The IoT Lab platform must interact with the IoT Lab mobile app to receive request to opt out from an experiment and to remove already collected data.

ID FR038

Requirement SLA management between the IoT Lab host and the investigator

Comment Function to handle SLA´s between IoT lab and investigators before giving access to investigation by participants


Stability high

Priority high

Source Generic platform

Component and Interaction SLA functionality

ID FR040

Requirement Support for motivators

Comment Forms to choose motivators to help the investigator when planning an investigation


61


Stability high

Priority high


Component and Interaction Crowd incentives functionality

ID FR050

Requirement Investigation participation (ENC)

Comment The IoT Lab mobile app must provide the participant with functionalities to control his/her participation to investigation


Stability v.High

Priority v.High



62

Component and Interaction The IoT Lab platform must be able to start and stop collection of data for execution of investigation based on participant inputs

4.4.2.2 Experiment Validator

ID FR030

Requirement Validation of experiment data

Comment The platform has to provide means to validate data of an experiment and this can lead to a reputation score for the participant.


Stability High

Priority High


Component and Interaction Experiment Data Management - Data Validation

4.4.2.3 Experiment Scheduler

ID FR006

Requirement Experiment scheduling


63

Comment The platform must provide automatic scheduling of experiments (recruiting, start,stop, etc) according to the experiment's specifications. This also includes the selection of participants and their resources that best suit the experiment's description.

Attributes Need High

Stability High

Priority High


Component and Interaction Experiment Scheduler - this component provides functionalities for scheduling, selection of resources of an experiment

4.4.2.4 Resource Recruitment

ID FR023

Requirement Automatic experiment reassignment

Comment The system must be able to identify that a participant is not available and reassign the experiment to other participant that satisfy the experiment's requirements


Stability High


64

Priority High


Component and Interaction Experiment Management - Experiments automatic assignment to participants

ID FR025

Requirement Participants recruitment

Comment The system must provide means for recruiting participants, this includes a search for the participants that satisfy the experiment's requirements, retrieval of the participants willingness to participate in the experiment, as well as a backup list of participants, preventing that a participant drop-off does not affect the experiment.


Stability v.high

Priority v.high


Component and Interaction Experiment Configuration - crowd resources recruitment

ID FR048


65

Requirement Geo-localised investigation participation

Comment The IoT mobile app must provide the participant the possibility to join geo-localized investigation in a participatory way.


Stability High

Priority High


Component and Interaction The IoT Lab platform must be able to track the IoT mobile app using QR code/NFC tag

ID FR052

Requirement Participant location

Comment The IoT Lab platform must be able to compute the number of participants to a given investigation located in particular area.


Stability v.High

Priority v.High


66


Component and Interaction The IoT Lab platform should be able to update participant suggested investigation with the number of involved nearby participants

4.4.2.5 Reservation and Provisioning (Testbed and Crowd resources)

ID FR011

Requirement Uniform resource description

Comment A uniform resource description model is required to model any resource of IoT Lab.


Stability v.High

Priority v.High


Component and Interaction Resource Configuration - The IoT Lab platform provides a uniform way of representing a resource (static and mobile resources).

ID FR024

Requirement Automatic resource detection


67

Comment When a testbed administrator adds a new resource to the testbed and provides the resource description for that sensor and provides the physical connectivity with the testbed infrastructure, the IoT Lab platform shall provide automatic detection and configuration for the new resource.


Stability v.high

Priority v.high


Component and Interaction Resource Configuration

ID FR026

Requirement Automatic crowd resource detection

Comment When a new participant joins IoT Lab the system must provide automatic detection, registration and configuration for the new participant (including mobile phone registration)


Stability v.high

Priority v.high


68


Component and Interaction Crowd Resource Configuration

ID FR027

Requirement Crowd resource configuration

Comment The system must be able to provide functionalities that allow the configuration of a crowd resource to perform an experiment, this can be related to installing a new application or configuring an existing application on the participants smartphone.


Stability v.high

Priority v.high


Component and Interaction Crowd Resource Configuration

ID FR028

Requirement Testbed resource configuration


69

Comment The system must provide ways so the investigator configures a testbed resource to run an experiment; this includes the resource setup and uploading the code to the resource.


Stability v.high

Priority v.high


Component and Interaction Resource Configuration

ID FR035

Requirement Resource reservation and provisioning

Comment Each individual testbed should provide a resource reservation and provisioning mechanism that will be compatible with the experiment orchestration mechanism of the IoT Lab platform. Since several testbeds follow diverse architectures, possibly a custom reservation/provisioning mechanism should be developed.


Stability v.high

Priority v.high


70

Source Generic platform/Individual testbeds

Component and Interaction RESTful API implemented on each testbed, serving requests from the IoT Lab platform

ID FR044

Requirement Crowdsourcing sensor resources

Comment The IoT Lab mobile app must provide access to physical and/or virtual sensors


Stability v.High

Priority v.High

Source IoT Lab mobile app

Component and Interaction The IoT Lab mobile app must interact with underlying mobile phone resources to access raw physical sensor readings and with external social media APIs to extract other participant “virtual sensors”

ID FR045

Requirement Crowdsourcing execution capability


71

Comment The IoT mobile app must provide the capability to run small script or investigator provided app


Stability v.High

Priority v.High


Component and Interaction The IoT Lab platform must interact with the IoT Lab mobile app in order to push script or app to be executed

4.4.2.6 Experiment Querying

ID FR020

Requirement Stored experiments overview

Comment The system must provide ways to search and have an overview of the results of an experiment. This can be filtered by characteristics of an experiment


Stability v.high

Priority v.high


72


Component and Interaction Experiment API - all the experiments must be stored persistently in the platform so they can be searched and reused by other investigators.

ID FR043

Requirement Search for experiments

Comment Users should be able to search for ongoing and previous investigations


Stability High

Priority High


Component and Interaction Experiment management - search

4.4.2.7 Experiment Data Management

ID FR007

Requirement Experiment data management


73

Comment When running an experiment the platform must automatically record the experiment’s generated data.

Attributes Need v. high

Stability high

Priority high


Component and Interaction Experiment Data Management - The system provides interfaces that allow the mobile phones to send data to, this data must be stored persistently in the IoT Lab platform.

ID FR014

Requirement Crowdsensing data provision

Comment The IoT Lab application must be able to communicate crowdsensing data (i.e. Sensory information) to the IoT Lab platform. This takes into account the participant's preferences, as well as the experiment's requirements.


Stability v.High

Priority v.high


74


Component and Interaction Crowdsensing API - The IoT Lab platform must provide an interface that allows the mobile phones to send crowdsensing related data.

ID FR015

Requirement Crowd perception provision

Comment The IoT Lab platform must provide ways to pull crowdsourcing data of an experiment to the mobile phones (this can be for instance a questionnaire, etc) and provide ways to receive this data from the mobile phones.


Stability v.high

Priority v.high


Component and Interaction Crowdsourcing API - communication of crowdsourcing related data must be possible between the IoT Lab platform and the IoT Lab participant's mobile phones.

ID FR029

Requirement Experiment Data structure


75

Comment The experiment data should be accessible in a format that is easily interpreted by existing external tools (e.g. JSON, etc)


Stability high

Priority high


Component and Interaction Experiment API - interfacing with external tools, data formatting

ID FR037

Requirement Vote for investigations

Comment Users should be able to rank and vote for investigations


Stability high

Priority high


Component and Interaction Experiment Classification functionality


76

ID FR049

Requirement Participation policies

Comment The IoT mobile app must provide functionalities to configure basic policies for investigation participation


Stability v.High

Priority v.High


Component and Interaction The IoT Lab mobile app must be able to adapt participant description according to the selected policy and accordingly update the IoT Lab platform

4.4.3 Resource Management

ID FR009

Requirement Testbed Resources overview

Comment When the investigator uses the platform the system must provide an overview of the available testbeds including nodes information such as location and capabilities.


77


Stability v.high

Priority v.high


Component and Interaction TbaaS - Resource discovery

ID FR010

Requirement Crowd resources general overview

Comment When the investigator uses the platform the system must provide an overview of the available crowd resources (i.e. Participants and smartphone information)


Stability high

Priority high


Component and Interaction The IoT Lab platform provides a general overview of the available crowd resources to the investigator,;this will allow him to best target his experiment and have an overview of what is


78

possible or not possible.

ID FR013

Requirement Automatic participant status detection

Comment The system must be able to determine the change of availability of a participant;, this can be due to that the participant has no connectivity, is currently reserved to an experiment, etc.


Stability v.high

Priority v.high


Component and Interaction The IoT Lab platform must provide a functionality that allows the platform to have periodically an overview of the participant's availability

4.4.4 Federation

ID FR032

Requirement IPv6 interconnection

Comment Individual test-beds participating in the IoT Lab infrastructure should support IPv6 connectivity. This would facilitate their federation under a


79

common addressing scheme, thus yielding managerial and implementation gains (e.g. resource discovery and cross-testbed communication would be more direct if all resources belong to the same IPv6 sub-network)


Stability high

Priority high

Source Individual testbeds

Component and Interaction IPv6 tunnel broker service - Testbed virtualisation

ID FR033

Requirement Common description/announcing scheme for individual testbed resources

Comment 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.


Stability v.high


80

Priority v.high


Component and Interaction Extension of the SFA Wrap specs format - Testbed virtualisation

ID FR034

Requirement Experimental data collection mechanism

Comment Each individual testbed should support a common mechanism for uniform data collection by the IoT Lab platform. This would increase the efficiency of experiment orchestration and of the IoT Lab platform management/maintenance.


Stability v.high

Priority v.high

Source Generic platform/Individual testbeds

Component and Interaction OML server/client tools

4.4.5 Community/Forum


81

ID FR017

Requirement IoT Lab Forum/Community

Comment The system must provide ways to share knowledge, clarify issues, create challenges between platform users (investigators and participants)


Stability high

Priority high


Component and Interaction Forum/Community

ID FR039

Requirement Messaging functionality

Comment The system should make it possible to send messages to individual users or within a community


Stability high


82

Priority high


Component and Interaction Forum/Community

4.4.6 Trustworthiness

ID FR021

Requirement Sensor data privacy

Comment The system shall provide means to prevent unauthorised reading of private sensor measurements.


Stability v.high

Priority v.high


Component and Interaction Security - Sensor data and user data must be protected

ID FR046


83

Requirement Data anonymisation

Comment The system must store data generated by the IoT Lab mobile app using an unidentifiable pseudonyms


Stability v.High

Priority v.High


Component and Interaction The IoT Lab mobile app must be able to update the IoT Lab platform with the list of resources the participant wants to share.

4.4.7 IoT Lab application

ID FR041

Requirement Support social motivators

Comment Function to show the participants near you


Stability High


84

Priority High


Component and Interaction Crowd data management

ID FR042

Requirement Function to manage shared data

Comment Individual users must be able to track all data they have provided and to manage/delete data


Stability v.High

Priority v.High


Component and Interaction Data management

ID FR047

Requirement Participant location mode


85

Comment The IoT mobile app must provide the participant with the possibility to select the preferred tracking mechanism (disabled, coarse, GPS)


Stability v.High

Priority v.High


Component and Interaction The IoT Lab platform must interact with the IoT Lab mobile app to update the participant mobile phone position accordingly.

4.5 Non-functional requirements

4.5.1 Experiment Validator

ID NFR001

Requirement Experiment Validation

Comment After submitting the code of an experiment the code must be validated in the IoT Lab platform;, this will ensure that malicious code will not be accepted.


Stability High

Priority High


86


Component and Interaction Experiment Validator

4.5.2 User Interface

ID NFR002

Requirement IoT Lab web interface

Comment When the researcher wants to access the system this shall be possible via a web-based user interface.


Stability v.high

Priority v.high


Component and Interaction User interface

ID NFR003

Requirement Easy to use end-user application


87

Comment The end-user must find the user interface easy to use.


Stability high

Priority high


Component and Interaction User Interface

ID NFR010

Requirement Low threshold to enter and participate

Comment Minimum steps for every participant-interaction


Stability High

Priority High




88

ID NFR012

Requirement Visibility and transparency

Comment Keep it open to the users; This approach means that the component parts and operations must remain visible and transparent to users and providers alike.


Stability High

Priority High



ID NFR022

Requirement Investigation visualisation

Comment The IoT Lab mobile app shall be able to effectively visualize ongoing, finished, declined investigations.



89

Stability v.High

Priority v.High

Source IoT Lab mobile application


ID NFR023

Requirement Reputation visualisation

Comment The IoT Lab mobile app shall be able to effectively visualize participant reputation score


Stability High

Priority High



4.5.3 Community/Forum


90

ID NFR004

Requirement Simple and didactic IoT Lab tutorials

Comment The IoT Lab platform must provide key tutorials as part of its forum/community. This allows an easier understanding of the platform from the investigators.


Stability High

Priority High


Component and Interaction Community/Forum

ID NFR005

Requirement Guidelines for testbed virtualisation

Comment Based on gained experience, general testbed virtualisation guidelines should be available to testbed owners that wish to contribute their resources to the IoT Lab platform.



91

Stability High

Priority medium


Component and Interaction Community/Forum

4.5.4 Security and Privacy

ID NFR006

Requirement Proactive Platform

Comment The platform should be designed to be proactive rather than reactive,this will prevent privacy-invasive events.


Stability High

Priority High


Component and Interaction Security and Privacy


92

ID NFR007

Requirement Privacy as default setting

Comment This approach means that if the user does nothing their privacy will be intact and protected.


Stability High

Priority High



ID NFR008

Requirement Privacy embedded into the design

Comment Privacy is an essential component of the core functionality being delivered. Privacy is integrated into the system, without dishing functionality.


Stability High


93

Priority High



ID NFR009

Requirement Full functionality - Positive Sum

Comment The endeavour is to accommodate all legitimate interests and objectives in a win-win manner. It demonstrates that it´s possible and far more desirable to have for example both privacy and security


Stability High

Priority High



ID NFR011


94

Requirement End-to-end security

Comment Full lifecycle protection: This ensures that at the end of the process, all data are securely destroyed and in timely fashion.


Stability High

Priority High



ID NFR013

Requirement Respect for user privacy

Comment Keep it user-centric: This approach means that the individual isput in the centre, hence it empowers users to play an active role in the management of their personal data


Stability High

Priority High


95



ID NFR014

Requirement Build up a brand of "user an privacy centricity" of IoT Lab

Comment "Users are the core heart": IoT Lab for and by the IoT Lab users - safe and secure!


Stability High

Priority High



ID NFR016

Requirement Privacy safe profile

Comment The IoT Lab platform shall not store profile containing sensitive data,such as name, picture, etc.


96


Stability High

Priority High



ID NFR017

Requirement Pseudonyms uniqueness

Comment The IoT Lab mobile app shall generate new pseudonyms for each investigation.


Stability v.High

Priority v.High




97

4.5.5 Authentication, Authorization and Accounting

ID NFR018

Requirement Profile validity

Comment The IoT Lab platform shall consider the provided profile valid


Stability v.High

Priority v.High


Component and Interaction AAA

ID NFR020

Requirement Easy-to-access and configure policies

Comment The IoT Lab platform shall make it easy to retrieve policies’ configuration settings and to change them at any time



98

Stability High

Priority High


Component and Interaction AAA

4.5.6 Resource Management

ID NFR019

Requirement Easy-to-configure resources

Comment The IoT Lab platform shall make it easy to configure the shared resources

Attributes

Need High

Stability High

Priority High


Component and Interaction Resource Management


99

4.5.7 Experiment Configurator

ID NFR021

Requirement Intelligent investigation suggestion

Comment The IoT Lab platform shall be able to suggest the investigation based on participant preferences (shared resources, policies setting, etc)


Stability High

Priority High


Component and Interaction Experiment Configurator


100

5 Conclusions

This document presents a set of use cases considered for the IoT Lab project with the aim to build the foundations of a platform that extends IoT tesbed infrastructure for experiments in areas such as technology, societal and business and interactions with the crowd. Based on this list we have ranked and selected the most relevant and promissing use cases and features to be further investigated and implemented in the other technical work packages. A set of both user and system requirements (functional and non-functional) was derived. These requirements also include network heterogeneity, privacy and data protection, crowdsourcing contributors and authentication requirements.

Both requirements and use cases will serve as input for task 1.2 for further elaborations on the global architecture for the IoT Lab platform, as well as the components design and implementation in WP2, WP3 and WP4 respectively.

During the lifecycle of the project, requirements will be matched and updated according to the feedback from the other technical work packages. The same with the use cases, where updates coming from the advisory board, lessons learned from the project partners and new use cases coming from the research community will update current scenarios, as well as contribute with new relevant ones.


101

References

[1] Darren C. Brabham; “Crowdsourcing”, MIT Press Essential Knowledge, ISBN-10: 0262518473, ISBN-13: 978-0262518475, 10 May 2013

[2] Francois Carrez, et al.; "Final Architectural reference model for the IOT v3.0", IoT-A project, 15July 2013.

[3] Karl Wiegers, Joy Beatty, “Software Requirements”, 3rd edition, ISBN-10: 0735679665, ISBN-13: 978-0735679665, 26 August 2013

[4] D7.1 Ethical Approvals; IoT Lab project


102

6 Appendixes

6.1 Appendix 1: Existing crowdsourcing platforms

Name Threadless (https://www.threadless.com/)

Key Focus Online community of clothing designers and e-commerce website

Description Launched in 2000 by Jake Nickell and Jacob DeHart. The aim of Threadless is to crowdsource and promote creativity among a community of designers.

Crowdsourcing methodology and tools

• Community submits designs online

• Designs are put to public vote

• After one week staff reviews the top-scoring designs

• 10 designs selected and printed on clothing and other products

Motivators for participation and use

Printed work designers receive $2000 in cash and $500 in Threadless gift cards

Reprint $500 cash

Table 25: Threadless crowdsourcing platform

Name InnoCentive (https://www.innocentive.com/)

Key Focus Open innovation company framing research and development questions as challenge problems for the community to solve

Description Launched in 2001, the aim is to crowdsource research and innovation problems in areas such as engineering, computer science, math, chemistry, life sciences, etc putting them as challenges to be solved by a registered community of solvers.


103


• Seeker posts challenge and financial award (pay fixed fee to InnoCentive)

• Solvers view the challenge and submit solutions

• If seeker satisfied pre-specified award in exchange for IP rights

• InnoCentive ensures IP protection and transfer


Solvers receive announced financial award from seekers

Table 26: InnoCentive crowdsourcing platform

Name Amazon Mechanical Turk (https://www.mturk.com/mturk/welcome)

Key Focus Marketplace for work, the AMT gives businesses and developers access to an on-demand workforce. Workers select which and when to work on a task

Description AMT is an online crowdsourcing system which distributes tasks to a large number of workers. It began as an in-house service to support business processes, outsourcing piecemeal tasks to contractors that required them to identify duplicate product websites.


Amazon owns and develops the platform, upon which firms or third-party requesters broadcast tasks (HITs) and workers (turkers) complete and submit the HITs.


Turkers receive money for the work performed

Table 27: Amazon Mechanical Turk crowdsourcing platform

Name iStockPhoto (http://www.istockphoto.com/)

Key Focus Online, royalty free, international microstock photography provider

Description Founded in 2000 as a free stock imagery website. In 2001 began charging money. In was acquired by Getty Images.


104


Photographers upload their work, suplyingkeywords, categorize the images and submitting them. Purchasers can search and buy the images.


Contributors receive a commission of between 15% and 40% of each sale depending on their “canister level”. Canister milestones such as 250 sales, 2500 sales, 10000 sales, etc. Depending on the size of the image (Xsmall, Small, Medium, Large, Xlarge, XXLarge and XXXLarge) images cost 1,3,6,12,18,22,28 credits.

Table 28: iStockPhoto crowdsourcing platform


105

6.2 Appendix 2: Other project scenarios

The SMARTIE project works on security, privacy and trust for data exchange between IoT devices and consumers of their information. Results are demonstrated in smart cities in Germany, Serbia and Spain. SMARTIE project introduces two scenarios. The first one is focused on the Energy Management. Smart Energy Management in Smart Cities use case is implemented in The University of Murcia. Second scenario is focused on improvements in management of public transportation in smart cities.

ID: SMARTIE-01 Title: Smart Energy Management in Smart Cities

Narrative/Descriptive: The goal of this scenario is to provide a reference system able to manage intelligently the energy use of the most relevant contributor to the energy use at city level, i.e. buildings. In this sense, it is possible to identify different ecosystems compounding a city, for example residential neighborhoods, schools, hospitals, campus, etc. And all these ecosystems can be seen as sets of buildings where people carry out different tasks every day. Therefore, considering buildings as the common cornerstone of all these city systems, we propose to deal with energy efficiency in buildings as main contributor to achieve energy efficient and sustainable cities.

Smart Energy Management in Smart Cities use case is implemented in The University of Murcia. Buildings in this campus are equipped with several different types of sensors and connected to the Open Data Platform using IP connection links. Among others, energyefficiency is one of the most important challenges. Actors involved in the overall system are: Energy producer, Energy consumer, Energy monitoring entity, Energy supervisor entity and End user. End users introduces crowdsourcing mechanisms by using their smartphones in order to be able to interact with the management entity system to be detected in the nearby of some presence sensors points and based on this to allow the system to take into account her presence in order to act over the lights, streetlight, HVAC etc to provide some level on user comfort.


• Sensor devices mounted in buildings as well as outdoor environmental conditions monitoring devices

• Users’ reports and data collected by appropriate smartphone application


• Citizens

• City authorities


High


High


Low

Privacy Concern:


106

Medium

Table 29: Smart energy management in smart cities scenario

ID: SMARTIE-02 Title: Smart City Public Bus Transport

Narrative/Descriptive: This scenario aims to improve the management of the public transportation network in the city of Novi Sad starting from the Public City Bus Transport (JGSP) Network with the intention to extend it to other transport means and networks and thus promote and encourage the greater use of sustainable transport modes and to provide time and cost benefits to travellers.

The pilot to be set in Novi Sad, Serbia will be based on enabling smart transport options for users of a public transport focusing initially on 2 routes within a city public bus transport network operated by a local transport company JGSP.

Bus stops covering the 2 routes will be equipped with the Augmented Reality (AR) markers in the form of an image (e.g. logo or QR code). Furthermore, fleet management devices will be placed on the appropriate busses in order to track their location in real-time.

Users (travellers) will be able using their smart phones, dedicated application and the AR marker at the bus stop to find out the bus arrival time and also request the information on the best route to the specified destination depending on the user selected criteria.


• Fleet management (GPS/GPRS) devices mounted on the busses

• Traveller equipped with smartphone and proper application

• Web portal


• JGSP

• Citizens


• Touristic organizations


Medium


Low


High

Privacy Concern:

Medium

Table 30: Smart city public bus transport scenario

SocIoTal project has several scenarios oriented to citizens in smart cities, like event reporting system, children/elderly monitoring, car pooling, taxi sharing, nightlife


107

information, chat between users etc.

ID: SocIoTal-01 Title: Enabling Santander/Novi Sad

Narrative/Descriptive: This scenario implements several services to improve life quality in smart cities. Scenario implements following services:

• Incidence Reporting and tracking service

Register an incidence/event in a specified platform/environment (such as a city/council or community platform) reported by a user (citizen). The user data could contain plain text and/or multimedia files (audio, video, photo). It could also be complemented with physical sensing information such as GPS coordinates, noise, temperature, pressure data and so on, collected from the user device or WSN available.

• Community Chat

This service will allow users to communicate with other users belonging to the same community/bubble. Within the communities users can start a chat because in the profile of a community, a list of people available to chat would be available; also users can chat with people after a discovery process.

• Accessible Routes

The service will offer the user, after he has been authenticated in the system, an accessible route to go from one point to another along the city. This route will avoid barriers of different nature such as not accessible infrastructures, works in the city, blocked access to streets, broken traffic lights, etc. The information will be gathered from different sources such as municipality information, public transport, local authorities, utilities, reporting incidents/events applications, etc.

• Accessible Parking

The service will provide the user, once he has been authenticated, information about the location of disable parking spaces and the number of free available lots. This information is gathered through WSN thanks to sensors installed under the pavement.

• Children and elderly monitoring application

This service proposes application that will enable remote location monitoring of children and elderly and alerting in case of emergency. Application can


• Sensor observations collected from users’ smartphones

• Observations from deployed sensors, like parking sensors, health devices etc.

• Web portal


• Citizens


• Touristic organizations


Medium


Low


High

Privacy Concern:

High


108

be used for monitoring by sending location coordinates and using control points with NFC tags and/or QR placed in a check in points (schools, playgrounds, bus stations, home, etc). Elders/children in emergency situations can use panic button to alert their person of trust. The final user will be able to create groups so that other kids can be monitored as well. Each control point have camera which captures the screenshot during the check in process.

Healthcare introducing, like HR (Heart Rate) and stress level estimation on the smartphones with or without additional device may be attractive for end user monitoring.

Table 31: Enabling Santander/Novi Sad scenario

The main purpose of the Citi-Sense project is correlating real sensor measurements with user personal rates about air quality.

ID: Citi-Sense-01 Title: Subjective feeling of air pollution in correlation with observed measurements

Narrative/Descriptive: This scenario aims to raise environmental awareness in citizens as well as to raise user participation in societal environmental decisions. It will address the call’s request for effective participation by citizens in environmental stewardship, based on broad stakeholder and user involvement in support of both community and policy priorities.

Users will participate in this scenario by providing their subjective felling about air quality. Citi-Sense platform will correlate objective measurements with users’ reports.


• Environmental monitoring sensor equipped devices

• User’s evaluation


• Citizens



Low


High


High

Privacy Concern:


109

Low

Table 32: Subjective feeling of air pollution in correlation with observed measurements scenario

The goal of OUTSMART is to contribute to the Future Internet (FI) by aiming at the development of five innovation ecosystems. These ecosystems facilitate the creation of a large variety of pilot services and technologies that contribute to optimised supply and access to services and resources in urban areas. In Aarhus cluster the focus was on open data platforms on top of which a city dashboard was developed.

ID: OutSmart-01 Title: ODAA (Open Data Aarhus) and City Dashboard

Narrative/Descriptive:In the Outsmart project the focus of the Aarhus cluster was on open data and the ODAA (Open Data Aarhus) platform. The primary goal was to develop ways of enabling companies and public authorities to share data openly, without compromising the integrity of their internal information systems at the same time showing them the potential value of opening up their data. As a test case and together with Aarhus Vand (the water utility company in Aarhus) to show how production data relating to the water utility can be made easily available via ODAA without compromising the integrity of the SCADA system. Via the ODAA platform, Aarhus Vand provides a free data catalogue for non-commercial uses. Only parts of the data will be open to everybody, while other parts of the more sensitive data will be licensed, ensuring that only authorised users will be able to access it. The main intended user, at least in the short term, is educational institutions, but other potential relevant users (including application developers and experimenters) could also benefit from the service as well. In the long run, the vision is to create alongside the technical platform an ecosystem of app developers and hackers using the data to create useful applications of economic value, to open up a new platform for ideas and initiatives to prosper, potentially creating new business opportunities and value for the city and the citizens.


• Utility company databases

• Applications and services from developers


• Companies with data • City municipalities • Experimenters and

Service developers


High


High


High


110

A test case has been developed in the project gathering heterogeneous information from the city and presenting it to the user in the form of the “Aarhus City Dashboard”. This example will also be used in relation to relevant data owners (both private and public) who still need good examples as motivation for them to provide data for the platform. They need something that can show them how their data can be used to make life in the city better, smarter and more fun for the citizens – and what the value is for them and for the city. The Dashboard was tested as part of the OUTSMART evaluation and the insights gained will be used to qualify the design and to look into the different approaches for engaging citizens and motivate them to make part in the future development of the city by using and providing different types of open data.

There are many similarities between this case and the goals of IoT Lab, as both have the objective to build a platform where investigators (service developers and experimenters) can retrieve data from and build their services/applications or experiments. The experiences gained in the Outsmart project will definitely be a very good input for IoT Lab project.

Privacy Concern:

Medium

Table 33: ODAA (Open Data Aarhus) and city dashboard scenario

SmartSantander aims at providing a European experimental test facility for the research and experimentation of architectures, key enabling technologies, services and applications for the Internet of Things (IoT) in the context of the smart city. One very important scenario covered in the last year of the project focused on experimentation on top of smartphones.

ID: SmartSantander-01 Title: SmartSantander experimentation on top of smartphones

Narrative/Descriptive: In the scope of the SmartSantander project a scenario on experimentation on top of smartphones was addressed in the last year of the project. In this scenario the objectives were the following: virtualization of experiments on smartphones (deployment, execution, management, data exchange), integration with the SmartSantander platform, transparent execution – users simply enable/disable the application and the sensors, and finally end-user customization options for


• Citizens smartphones • Experiments from the research

community


• Researchers/Investigators • Citizens • City Municipality


111

privacy. The Android platform was chosen for the implementation of such an application due to its major user base in Spain, multitasking options, sensor APIs and Bluetooth and WiFi APIs, and the possibility of installing and executing arbitrary native code, which is not possible with iOS and WP. Moreover the platform Ambient Dynamix, an OSGi-based plug-and-play context sensing framework was selected. It allows the dynamic download and installation of plug-ins on demand, it provides also mechanisms for plug-in execution management as well as manage access rights to smartphone resources.

The Android application can be downloaded by the end-users and customized by them – e.g. which sensors to use for the experimentation, when to upload the results, etc. The device is registered to the SmartSantander platform and an experiment code is downloaded to the phone. Experiment readings are stored on the device and forwarded to the SmartSantander platform.

From the experimenter’s viewpoint experimenters can submit code written as plugins, the code is validated locally by SmartSantander and if validated the plugin is made available on the project’s plugin repository. When the experiment is being performed the readings are also made available in the SmartSantander portal server.

This scenario fits very well the scope of the IoT Lab core description and objectives. Further investigations and extensions to the scenario could be performed in order to make it fit the specifics of IoT Lab requirements.


High


Medium


Medium

Privacy Concern:

High

Table 34: SmartSantander experimentation on top of smartphones scenario

The IoT initiative (IoT-i) was a EU Framework Programme 7 project, started in September 2010. The focus was to bring together key actors from all relevant but currently fragmentedIoT communities in Europe to work jointly towards a common vision of the Internet of Things. One of the outcomes of this project was “The Internet of Things Comic Book”, the idea is to inspire and share with the community the benefits of IoT in different areas such as transportation, energy, business, etc.

ID: IoT-i-01 Title: Noise mapping by participatory sensing


112

Narrative/Descriptive: Excessive noise is a hindrance to enjoyable city life and general well-being. The City of Melbourne is receiving an increasing number of complaints from city residents, and hence need a large-scale monitoring system to track down and record sources of excessive noise. Static sensors can support only a fixed spatial sensing resolution. City residents can improve the spatial resolution by actively participating in the sensing process using their mobile phones. Before a person can participate, he/she must first download an application from the City of Melbourne. Ideally, the mobile phone has a Trusted Platform Module, which can verify the integrity of the application whenever the application is launched, to prevent the phone owner from tampering with the application. To measure noise at a particular location, the participant starts the application, records the noise and uploads the data to the City of Melbourne's server. Even when the integrity of the application is guaranteed, a dishonest participant may send in false data, for instance, by shouting into the microphone or covering the microphone. The City of Melbourne should implement various schemes to mitigate the impact of false data, for example, by requiring the data uploaders to register, by implementing a rating system like that of eBay, or by implementing an automatic rating system based on correlation with other participants' data.



• End-users data (annotations, ratings)




Medium


Medium


High

Privacy Concern:

High

Table 35: Noise mapping by participatory sensing


113

6.3 Appendix 3: Needfinding interviews – questions to be used by each partner

The result from these interviews should be used to develop the IoT Lab use cases and to identify the IoT Lab users and their needs and to scout potential real IoT Lab use cases.

1) Short introduction about IoT Lab: (slides by WP8)

a. IoT Lab Mission and vision b. Available testbeds and their usage c. What is crowd-sourced research and participatory sensing d. Potential usage e. Why are we doing this interview?

2) Ask the respondent to describe one of their current experiments– research project

a. What is the purpose of the experimentation? What will be experimented with (not focusing on the technology, but the knowledge/understanding that the experiment will render)?

b. What is the application/solution being developed/tested? c. What are the problems to be solved/what to be tested? Who owns the

problem? d. How is the experiment being implemented (technology used,

methodology, user-groups, etc)? e. Where is the experiment being implemented? f. Please describe the process of the experimentation.

i. Which steps will be carried out? What will be the first step of your experimentation and so forth?

g. Will you involve any people in the test? (Crowd?) Who will they be? What do you expect them to contribute with? How will you communicate with them and gather their feedback (technical support)?

h. What is your experiences from earlier experimentations you have been involved in, or from this one?

i. Which challenges and benefits do you experience with this approach?

ii. What has been especially difficult and what has been especially valuable?

iii. How have you worked with these issues to resolve them?

3) What if? - Dream the future a. If you could dream freely, how would you like to set up an experiment

with the IoT Lab scenario mind? (What type of technology would you experiment with, which stakeholders would be involved, how would you interact with the stakeholders in the project, what type of technological support would you have for these processes)

4) Would you be interested to be a pioneer experimenter partner for the


114

IoTLab? Yes

No

What we can offer for selected use-cases are:

1. Free access to the IoT Lab connected testbed as a service and crowdsourced resources for the experiments selected by the project.

2. Support in running the selected experiment using the IoT Lab platform.

3.3Visibility as an IoT Lab Pioneer use-case at the IoT Lab web page, in publications and in dissemination events

What is expected from an IoT Lab pioneer experiment is:

To be a lead-user of IoT Lab = Interest to share and contribute with your ideas and suggestions in how IoT Lab should function to work for your specific experiment. This involves to

1. Be involved in requirements and to trial an early prototype of the platform.

2. Validate its functionality by setting up your real IoT Lab experiment and validate and contribute with suggestions for future improvements.

The actual implementation of the experiment on the IoT Lab platform is planned to start in Summer-Fall 2014.

5) Who can we contact to continue the interaction?


115

6.4 Appendix 4: Use cases ranking scores

Scenario Score Votes

UC1 - eCROWD 18,22 (4th)

2

UC2 - Noise mapping by participatory sensing 17,2 (10th)

0

UC3 - ODAA and City Dashboard 17,76 (7th)

0

UC4 - SmartSantander experimentation on top of smartphones 16,77 (14th)

0

UC5 - Public reporting and participatory sensing 19,29 (2nd)

3

UC6 - City-Sense air quality estimation 14,3 (22nd)

0

UC7 - Lecture monitoring 16,18 (20th)

2

UC8 - Business and market studies 18,07 (6th)

2

UC9 - Participant contest 17,06 (12th)

0

UC10 - Gamification 14,28 (23rd)

0

UC11 - Meeting record and mood monitoring 17,15 (11th)

1

UC12 - Support Living Lab operations 17,59 (9th)

0

UC13 - Managing building assets with security provisioning 17,02 (13th)

0

UC14 - Energy Efficiency Contest 18,16 (5th)

4

UC15 - Energy efficiency and user comfort in HOBNET enabled environments, using mobile crowdsensing hints

17,62 (8th)

3


116

UC16 - HEPIA sustainable week - crowdsourcing driven energy efficient buildings

18,58 (3rd) 2

UC17 - IoT Lab Online Trading Game 16,29 (18th) 1

UC18 - Demographic Migration Tracker

19,44 (1st) 1

UC19 - Colours and Customer’ Purchases

16,24 (19th) 0

UC20 - Selling Policies and Customers Behaviour

16,3 (17th) 0

UC21 - Shops Temperature and Selling Percentage

16,62 (15th) 0

UC22 - Shops Light Effects and Maximization of Business Performance

15,89 (21st) 0

UC23 - Effects of Light Colours and Maximization of Business

Performance

16,57 (16th) 0

UC24 - IoT Lab Online Focus Group 13,68 (24th) 1

Table 36: Use Cases ranking results

deliverable d1.1 iot lab end-user requirements report · integrate them into the cloud to provide...

Documents