Managing Alarming Situations with Mobile Crowdsensing Systems and Wearable Devices

DEGREE PROJECT IN INFORMATION AND COMMUNICATION TECHNOLOGY, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2020

VIKTORIYA KUTSAROVA

KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

Managing Alarming Situations with Mobile Crowdsensing Systems and Wearable Devices

VIKTORIYA KUTSAROVA

Master in Computer Science ICT Innovation, Cloud Computing and Services Date: August 18, 2020 Supervisor: Shatha Jaradat Examiner: Mihhail Matskin School of Electrical Engineering and Computer Science Host company: RISE Swedish title: Hantering av farliga situationer med Mobile Crowdsensing Systems och bärbara enheter

iii

Abstract

Dangerous events such as accidental falls, allergic reactions or even severe panic attacks can occur spontaneously and within seconds. People experienc- ing alarming situations like these often require assistance. On the one hand, wearable devices such as smartphones or smartwatches can be used to detect these situations by utilising the plethora of sensors built into them. On the other hand, mobile crowdsensing systems (MCS) might be used to manage the detection and mitigation of alarming situations. To be able to handle these events, an MCS requires integration with mobile sensory devices, as well as the voluntary participation of people willing to help. This thesis investigates how to incorporate wearables into an MCS. Furthermore, it explores how to utilise the gathered data and the participants in the system to manage alarming situations. The contributions of this thesis are twofold. First, we propose the extension of a mobile crowdsensing system for managing alarming situations that allows integration of wearables. We base our work on CrowdS - an MCS that facilitates the distributed interactions between people and sensory devices. We integrate a commodity smartwatch into CrowdS using different techniques (i.e. Internet and Bluetooth). The smartwatch’s sensors enable the detection of various alarming situations and their transmission to the MCS. The mobile crowdsensing system then relays the data and finds volunteers willing to help. Our solution can be adapted to handle various types of dangerous situations. Moreover, the system can easily be integrated with other types of wearables. Second, to test the usefulness of an MCS without actually deploying it in real life, we create a simulation that models different scenarios that represent dangerous events. It allows us to represent the event visually and to parametrise various factors that influence the effectiveness of the system. The simulation helps to identify how different parameters might affect the outcome of the alarming situation. Our results show that important attributes include but are not limited to the coverage of the system, the number of participants and their density, as well as distribution and means of transportation. We enhance the capabilities of CrowdS by enabling the integration of various Bluetooth wearable devices. Thus we expand CrowdS into a prototype of a system for managing alarming situations. Moreover, through the MCS simulation, we identify essential parameters that need to be considered when building such a system. The simulation is a tool that can also be used to find the optimal configuration of the MCS. iv

Sammanfattning

Farliga händelser som till exempel oavsiktliga fall, allergiska reaktioner eller till och med panikångest kan inträffa utan förvarning och inom några sekun- der. Människor som upplever livsfarliga situationer som dessa behöver ofta hjälp. Bärbara enheter som smartphones eller smartwatches användas för att upptäcka dessa situationer genom att använda en mängd sensorer som är in- byggda i dem. Mobile Crowdsensing Systems (MCS) användas för att hantera upptäckten av dessa situationer och hjälpa människor få de hjälp som behövs. För att kunna hantera dessa situationer kräver en MCS integration mellan mo- bila sensoriska enheter, såväl som ett deltagande av människor som är villiga att hjälpa. Denna avhandling undersöker hur man kan integrera wearables i en MCS. Man undersöker även hur man kan samla in data och deltagare i systemet för att hantera farliga situationer. Bidragen i denna avhandling är tvåfaldiga. För det första föreslår vi utök- ning av en MCS för att hantera farliga situationer som möjliggör integrationen av bärbara enheter. Vi baserar vårt arbete på CrowdS - ett MCS som under- lättar distribuerade interaktioner mellan människor och sensoriska apparater. Vi integrerar en smartwatch med CrowdS med hjälp av olika metoder (exem- pelvis. Internet och Bluetooth). Smartwatch-sensorerna möjliggör upptäckt av olika farliga situationer och deras överföring till MCS. MCS vidarebefordrar sedan datan och försöker hitta frivilliga som är villiga att hjälpa. Vår lösning kan anpassas för att hantera olika typer av farliga situationer. Dessutom kan systemet enkelt integreras med andra typer av bärbara enheter. För att testa nyttan av MCS utan att distribuera den i verkliga livet, skapar vi en simulering av olika scenarier som representerar farliga händelser. I simuleringen kan vi ändra parametrar och faktorer under händelseförloppet för att se hur det påverkar systemets effektivitet. Simuleringen hjälper till att iden- tifiera hur olika parametrar kan påverka resultatet av den farliga situationen. Våra resultat visar att en del viktiga attribut inkluderar men inte är begränsa- de till området som täcks av systemet, antalet deltagare och deras täthet, samt distribution av människor samt tillgång till transportmedel. Vi förbättrar förmågan hos CrowdS genom att möjliggöra integrationen av olika Bluetooth-bärbara enheter. Vi har utvecklat CrowdS till en prototyp av ett system för att hantera farliga situationer. Genom MCS-simuleringen iden- tifierar vi dessutom viktiga parametrar som måste uppmärksamma när man bygger ett sådant system. Simuleringen är ett verktyg som kan användas för att hitta den optimala konfigurationen av MCS. v

Acknowledgement

I am incredibly grateful to my examiner prof. Mihhail Matskin for the invalu- able insights and practical suggestions on how to tackle the work during the creation of this master thesis.

I am grateful to my supervisor Shatha Jaradat and to Ronja Jösch for the thor- ough feedback and advice on how to improve my work, as well as the relentless support.

Special thanks to Mikael Bengtsson for the vast amount of assistance when providing me with the necessary resources to ﬁnish this work.

I’d like to recognise the eﬀort that I received from Niklas Fürderer from Nec- tarine Health for our great discussions on how their product works.

I gratefully acknowledge the support of my friends and family that allowed me to pursue my higher education.

Last, but not least, I express my deepest gratitude to Milko Mitropolitsky who is my cornerstone in every aspect of life. Contents

1 Introduction 1 1.1 Motivation ...... 1 1.2 Problem statement ...... 2 1.3 Research questions ...... 3 1.4 Purpose ...... 3 1.5 Goals ...... 4 1.6 Thesis contributions ...... 4 1.7 Thesis limitations ...... 5 1.8 Research methodology ...... 5 1.9 Ethics and Sustainability ...... 6 1.10 Outline of the document ...... 6

2 Background 8 2.1 Risk management ...... 9 2.1.1 Health risk situations ...... 9 2.1.2 Fall detection and prevention ...... 9 2.2 Sensing wearables ...... 10 2.3 Crowdsourcing and crowdsensing ...... 11 2.3.1 Crowdsourcing ...... 11 2.3.2 Crowdsensing ...... 12 2.3.3 Mobile crowdsoucring and crowdsensing ...... 12 2.4 Mobile crowdsensing taxonomy ...... 13 2.4.1 Sensing scale ...... 13 2.4.2 User involvement and responsiveness ...... 13 2.4.3 Sampling rate ...... 14 2.4.4 Network infrastructure ...... 14 2.5 MCS for health care, emergency, safety ...... 14 2.5.1 Emergency management and prevention ...... 15 2.5.2 Healthcare and wellbeing ...... 15

vi CONTENTS vii

2.5.3 Mobile social networks ...... 16 2.6 Platform: Crowds ...... 16

3 Design and Implementation 19 3.1 Extending CrowdS Android application ...... 19 3.2 Smartwatch Application ...... 23 3.3 Smartwatch integration with CrowdS via Internet ...... 25 3.4 Smartwatch integration with CrowdS using Bluetooth . . . . . 25 3.5 Extended CrowdS sample scenario ...... 26 3.6 Nectarine’s platform ...... 29

4 Experiments 31 4.1 Motivation ...... 31 4.2 Experiments setup ...... 32 4.3 Parameters selection ...... 34

5 Results and Discussion 38 5.1 Smartwatch integration with CrowdS ...... 38 5.1.1 Communication protocols comparison ...... 38 5.1.2 Comparison between smartwatch-oriented and smartphone- oriented approaches ...... 40 5.2 Simulation experiments ...... 40 5.2.1 Scenario 1: Different density ...... 40 5.2.2 Scenario 2: Different transportation methods . . . . . 42 5.2.3 Scenario 3: Different probability of participation . . . 43 5.2.4 Scenario 4: Different distribution of participants . . . 44 5.2.5 Scenario 5: Constantly increasing density ...... 45 5.2.6 Scenario 6: Different radius of MCS ...... 46 5.2.7 Discussions ...... 48

6 Conclusion and Future Work 49 6.1 Conclusion ...... 49 6.2 Future work ...... 50 6.2.1 Smartwatch application ...... 50 6.2.2 CrowdS platform ...... 51 6.2.3 Simulation ...... 52 6.2.4 Ethics ...... 52 6.2.5 Discover opinions regarding participation in risk detection system ...... 52 viii CONTENTS

Bibliography 53

A Calculating the number of visitors and density for simulation 64 List of Tables

4.1 Diﬀerence between use cases used to derive parameters of an MCS for risky situation detection ...... 34 4.2 Parameters and default values used in experiments with a system for handling emergencies ...... 37

5.1 Advantages and disadvantages of integrating smartwatch with CrowdS directly via Internet ...... 39 5.2 Advantages and disadvantages of connecting smartwatch to a smartphone through Bluetooth ...... 40 5.3 Parameters used in Scenario 1: Diﬀerent density ...... 41 5.4 Parameters used in Scenario 3: Diﬀerent probability of participation ...... 43

ix List of Figures

3.1 CrowdS System Overview. Source: (V. Granfors et al. 2018) . 20 3.2 Device overview. Adapted from source: (V. Granfors et al. 2018) 21 3.3 Extended client side overview. Adapted from source: (V.Gran- fors et al. 2018) ...... 22 3.4 CrowdS platfrom emergency detection dataﬂow ...... 22 3.5 Basic Architecture of Fall Detection System. Source: (Casi- lari and Oviedo-Jiménez 2015) ...... 24 3.6 Smartwatch Application Components...... 24 3.7 Galaxy watch application for detecting a risky situation . . . . 26 3.8 CrowdS app: pairing with Bluetooth device ...... 27 3.9 CrowdS app: Task creation ﬂow ...... 28 3.10 Scenario of extended CrowdS ...... 29

4.1 Example setup of experiment ...... 32

5.1 Handled emergencies versus not handled emergencies . . . . . 41 5.2 Average time to reach target depending on density ...... 42 5.3 Average time to reach target depending on means of transportation ...... 43 5.4 Handled emergencies versus not handled emergencies . . . . . 44 5.5 Clustered distribution of agents ...... 45 5.6 Correlation between density and active participants. Active participants in logarithmic scale...... 46 5.7 Handled emergencies versus not handled emergencies . . . . . 47 5.8 Average time to reach target depending on radius of MCS system 47

A.1 Popular times in Hyde Park during Sunday. Source: Google Maps ...... 65 A.2 Popular times in Hyde Park during Tuesday. Source: Google Maps ...... 65

x Chapter 1

Introduction

This thesis discusses a system for managing alarming situations by connecting people in need with volunteers ready to provide help. In particular, the system we consider takes advantage of smartwatches and mobile crowdsensing (MCS) technologies. By using the watch’s sensors, the system can identify dangerous events and take action to resolve the arisen situation. The approach for mitigating risks is integrating a smartwatch application with CrowdS (V. Granfors et al. 2018) - an open-source mobile crowdsensing system that enables creation and distribution of various computing or human-oriented tasks. This research also provides simulation as a proof of concept how a system for managing risky situation would work and what are the important parameters that would make such a system beneﬁcial to its participants. This chapter discusses the motivation and context of the problem, as well as some additional aspects of the work performed.

1.1 Motivation

Dangerous situations can occur within seconds and can cause irreversible damage to a person’s mental and physical health. We can consider a few categories of such situations. First one is the safety category. Any situation or event that can endanger the safety or well-being of a person represents a safety risk. For example, walking alone in the park during the night or going through a part of a city that is with higher criminal activity can yield a safety risk. The second category is health. We consider any event that can directly impact the health of a person - for instance, an accidental fall of a person or a severe panic attack. Especially older people are exposed to much higher health risk compared to younger people. The third type of dangerous situations is the

1 2 CHAPTER 1. INTRODUCTION

emergence of a natural disaster. Any natural event such as earthquakes, hurri- canes or floods that cause enormous damage to people and communities fall into this category. The risks from the categories mentioned above are starting to be predictable or at least automatically detectable. This is possible thanks to various sensors that measure either biometric signals such as heart rate, movement, breathing or measure different environmental characteristics such as noise level, lights, etc. In order to automatically track specific events, sensory infrastructure needs to be installed. Such infrastructure can trigger an alarm if a dangerous situation has occurred or is about to happen. For example, if a person is walking and suddenly falls, sensors can trigger an alarm. Moreover, modern mobile devices contain most of these sensors. We use the term wearables to denote them. The combination of the non-intrusiveness and multiple sensors incorporated in the wearables makes them a suitable candidate for devices that could prevent risky situations. There is an approach that enables the combinations of multiple wearable devices to allow more sophisticated people-centric services. Utilising devices carried by people such as smartphones, tablets, smartwatches and other portable devices is the most cost-effective way of creating a sensory infrastructure. This approach is called mobile crowdsensing. It enables information sharing between sensory devices. Measuring tasks can be performed either by the devices or could involve the user for more specific insights. Appli- cations of crowdsensing are countless - from fostering healthy eating (Gao, Kong, and Tan 2009; Chen et al. 2009; Reddy et al. 2007) to monitoring traffic conditions (Singh et al. 2017) and air pollution (Hasenfratz et al. 2012). That is why plenty of researchers have explored the paradigm for facilitating rapid responses and adequate resource allocations during crises.

1.2 Problem statement

There are numerous challenges around the combination of sensory devices and mobile crowdsensing systems. Plenty of scientists have investigated architecture, data and communication with mobile crowdsensing systems that combine multiple heterogeneous devices. Since such platforms rely on human participants, problems like encouragement and motivation of people to participate have also been considered. Researchers have also discussed the process of verifying contributed data. In the context of health and safety risk management, though, there are fewer researches. Most of them focus on using devices carried by people and CHAPTER 1. INTRODUCTION 3

mobile crowdsensing to monitor the environment or to allocate resources after a natural disaster event has occurred. However, in those works, the user is engaged only with contributing sensed data and not actively reacting to an alarming event. Moreover, the parameters needed for a risk management system to be valuable and practical are unexplored. Thus in this master thesis, we consider the problem of how to use wearables together with mobile crowdsensing to manage a risky situation. Moreover, we explore how to mitigate a dangerous situation by providing a rapid response from the users within the network. We also explore what parameters we need to make such a platform a viable alternative to other approaches for handling emergencies.

1.3 Research questions

Generally, mobile crowdsensing has been explored by researchers and it has proved to be a good way of using distributed expertise. In solving the task of how to use crowdsensing to detect and mitigate the alarming situation, we ﬁrst examine the integration of smart wearable devices with an existing crowdsensing platform. Next, we showcase what are the essential parameters that can make this approach a feasible solution in providing risk reduction and mitigation. We can formulate the following three research questions:

1. How to use a smartwatch to monitor a person’s behaviour and environment for risk situations?

2. How can a smartwatch be integrated into a mobile crowdsensing system to enable ﬁring an alarm in case of a risky situation/behaviour?

3. How eﬀective is a mobile crowdsensing system when an emergency occurs and what are the parameters that people who are building such a system need to consider?

1.4 Purpose

The purpose of this project is to explore how integrating smartwatches with a mobile crowdsensing system can be beneﬁcial for identifying alarming situations and reacting to them promptly. Furthermore, it shows how ﬂexible and extensible such a system can be and how easy it is to add various devices 4 CHAPTER 1. INTRODUCTION

with different sensors. The experiments conducted in this thesis can serve to any person who wants to develop and deploy such a system. The results can help identify the essential characteristics of an MCS solution. For example, what density within the system’s radius is needed to provide a specific cer- tainty about how many people will respond to a call for help or how does the different speed of participants affect the time to reach a person.

1.5 Goals

The main goals of the project are as follows: 1. Develop a prototype application on a commodity smartwatch that utilises the watch’s Motion API to perform movement detection. 2. Extend an existing crowdsensing system to support Bluetooth integration. 3. Integrate the prototype smartwatch application with the crowdsensing system by using two diﬀerent channels - directly through the Internet and also via Bluetooth. 4. Implement a parametrised simulation where we mock how the developed prototype would work in case of an emergency and allows the ex- ploration of required properties of the system.

1.6 Thesis contributions

This thesis produces three main contributions: 1. We provide an extension to CrowdS platform that allows easy integration of Bluetooth wearable devices into the mobile crowdsensing platform. More concretely, we extend the CrowdS Android client application to enable the incorporation of Bluetooth devices (Kutsarova 2020a). 2. We develop a smartwatch application that utilises its sensor to emulate the detection of alarming situations and mitigate the risk (Kutsarova 2020b). 3. We implement a simulation of a system for managing alarming situation using mobile crowdsensing. Such a simulation provides valuable insights on important metrics that need to be considered before designing a mobile crowdsensing based solution. CHAPTER 1. INTRODUCTION 5

1.7 Thesis limitations

Due to time constraints and feasibility, we impose some constraints regarding the produced work from this thesis. First of all, even though we discuss wearable devices throughout the whole thesis, we focus mostly on commodity smartwatches. They do not require specific hardware and generally support standard OS and communication protocols. Furthermore, smartwatches are both easily accessible and affordable. Second, the smartwatch application that we built is only used as a prototype and in no way aims to build a proper fall detection model. The goal is to explore different communication channels that allow the integration of the smartwatch with the MCS. Third, we do not test our prototype application in real life but instead chose to build a simulation. Testing the prototype would have been infeasible as it needs recruitment of volunteers, their coordination, choosing a proper place to perform the test and many other considerations. Finally, we do not perform interviews with people to extract the default values of our simulation parameters. To collect enough information from people, it would have taken too much time and resources. We choose to find research public statistical data which give us the base values for our simulation.

1.8 Research methodology

There are two primary objectives of this research. The first one is to build a prototype system for managing alarming situations by integrating commodity smartwatch with an MCS. The prototype allows us to explore various alternative components and to evaluate our idea. We explored different protocols for connecting the smartwatch to the MCS as well as different methods for utilising the smartwatch’s capacity. These actions allowed us to perform a qualitative analysis and to give a better perspective of the positive and negative sides of each approach. The second objective is to build a simulation that represents the emergence of a risky situation and how the discussed system can handle it. The simulation is performed by feeding quantitative data into a built model of a system for managing alarming situations. The simulation allows us to use parameters for each property that we want to explore. Parameters can easily be changed and adapted according to what hypothesis is being tested. The simulation produces quantitative results, and its objective is to gain understanding, which requires a qualitative point of view. Study of relevant literature, as well as the best practices of designing and building simulations, are used in this 6 CHAPTER 1. INTRODUCTION

thesis.

1.9 Ethics and Sustainability

Wearable devices can contribute to beneficial outcomes in plenty of aspects. They could help people with specific health problems or could serve a specific part of the population. For example, fall detection devices decrease the risks of permanent injuries among the older population, or electronic glasses could benefit people with problematic sight. Some wearable devices can also be used among the entire population. Monitoring various health aspects, location or sounds around a person could improve their health, safety and decrease the risks of various types of incidents. The biggest ethical concerns connected to sensing wearables are privacy, safety and data management. Questions like where are the person’s data stored, who owns it and can it be deleted once collected are topics that need to be considered when implementing a solution using such a device. The idea of crowdsensing is to improve access to knowledge, resources and skills. Utilising a crowdsensing system in combination with wearable devices can tremendously improve people’s safety and provide faster and cheaper disaster management. However, crowdsensing faces plenty of ethical challenges. Most notable of those is preserving privacy. Crowdsensing systems collect sensitive personal information and using state-of-the-art techniques of preserving that data and complying with the latest regulations is essential.

1.10 Outline of the document

The ﬁrst chapter introduces the problem and describes the context of the thesis. The next Section 2 provides a review of existing literature. The focus of the chapter is sensing wearables and crowdsensing systems. The chapter ends with a brief introduction to CrowdS - a mobile crowdsensing platform used as a base for the current work. Chapter 3 describes the design and implementation of the smartwatch application and how it integrates with CrowdS. A discussion is made between integrating the watch directly with CrowdS or connecting the smartwatch with a smartphone via Bluetooth and letting the smartphone handle the communication with CrowdS. The following sections 4 and 5 discuss the simulation of mobile crowdsensing system. The results are then summarised and analysed. Findings of the thesis are described in a brief CHAPTER 1. INTRODUCTION 7

but succinct manner in chapter 6. In the same chapter, the limitations of this research are discussed, and directions for future work are proposed. Chapter 2

Background

The rise of popularity of wearable devices filled with a plethora of sensors has driven forward personal safety and healthcare. This thesis investigates the possibility of integrating wearable electronics into a more comprehensive system, where all of the devices can share computational power, measuring capabilities and can facilitate help in case a risky situation occurs. The following Chap- ter provides the necessary background knowledge, which the reader should possess to grasp the ideas behind this thesis fully. First, we discuss the definition of risk, what is a risky situation and how such an event can be detected (Section 2.1). The segment provides a more general discussion of existing terminology and approaches. In this work, we try to build a system that can manage risky situations. The importance of health prevention has inspired our platform. We use a very simplified approach for fall detection and try to create an abstraction of a risky situation. Thus we also present current state-of-the-art research for fall detection and prevention (Section 2.1.2). Next, the focus moves towards wearable devices (Section 2.2), more specif- ically smartwatches, and the possibilities of using their embedded sensors to identify risks. A connection between mobile smartwatches and mobile crowdsensing systems is described. A big component of this work is the integration of a commodity smartwatch into a mobile crowdsensing system. Understand- ing both topics is essential to understanding the solution we propose. After that, we briefly explain the terms crowdsourcing and crowdsensing (Section 2.3). They take a central place in this thesis, as the proposed solution is an integration between wearables and such a system. Furthermore, we present a short discussion of mobile crowdsensing taxonomies (Section 2.4). We focus on the MCS categories that are relevant to our work. We also

8 CHAPTER 2. BACKGROUND 9

describe applications of mobile crowdsensing systems such as emergency prevention, healthcare and mobile social networks since they are closely related to this thesis. (Section 2.5). Last, we discuss the CrowdS platform (Section 2.6). This platform had been developed by Ville Granfors (2019) and is an example of a working mobile crowdsensing system. The architecture and approaches implemented within the platform are reviewed. Understanding of the CrowdS software is crucial to understanding the current thesis as it extends and enhances the capabilities of CrowdS. Readers with a background in smartwatches and their sensors can skip section 2.2. Readers with knowledge about crowdsensing platforms can go directly to Section 2.6 where CrowdS is described. The platform is the base for detecting a risky situation using mobile devices.

2.1 Risk management

According to the Oxford Dictionary, the definition of risk is "the possibility of something bad happening at some time in the future; a situation that could be dangerous or have a bad result" (Definition of risk 2020). For a long time, the use of technology has been explored as an opportunity to detect risky situations and to help to prevent them from happening. Alternatively, at least to give people more time for reaction. For instance, gamma rays have been examined for detecting dangerous materials at ports (Shurkin 2015). Moreover, simulation technology has been investigated for preventing financial crisis (Simulation technology and financial crisis 2009).

2.1.1 Health risk situations With the advancement of smartphones and wearable devices, the risks connected with personal health have become of great interest to the research community (Piwek et al. 2016). The hope is that these devices can detect issues before they even happen. Moreover, instead of just collecting and relaying health data, those devices would be able to mitigate health problems (Woyke 2016).

2.1.2 Fall detection and prevention Fall detection is a clear example of how technology can help detect or even prevent a risky situation from happening with an application, particularly in 10 CHAPTER 2. BACKGROUND

health care. Fall can cause unanticipated injuries, and its detection on time is essential to minimising the eﬀects caused by such an event (Xu, Y. Zhou, and Zhu 2018). Fall detection is an active research area and there are various implementations of such a system - starting from dedicated wearables devices (Vilarinho et al. 2015; H. Nguyen et al. 2017; Ngu et al. 2017; Khojasteh et al. 2018; Yacchirema et al. 2018), combination of smartphones and smartwatches (Casilari and Oviedo-Jiménez 2015) to using Commodity Wiﬁ (Wang, Wu, and Ni 2017; Palipana et al. 2018), Deep Learning approaches (Putra et al. 2018), cameras (Tao and Yun 2017) and combinations of the above mentioned approaches (Lu et al. 2019). In general, the advancement of IoT and smart sensor devices have stimulated the development of this area even further (Xu, Y. Zhou, and Zhu 2018).

2.2 Sensing wearables

Wearables are lightweight devices worn close to, on or in the body that monitor, transmit and analyse data, providing bio-feedback (Düking et al. 2018) such as commercial wrist-watches (Galaxy Watch 2020; Fitbit Official Site 2020), medical patches (Smart patches 2020), pendants (Fall Detector Pen- dant 2020) and others. Plenty of research is being done around wearable technologies and how they could help to detect, assess and mitigate health risks and what are the main concerns around their usage (Lutze and Waldhör 2015; Heikenfeld et al. 2018; Staff 2019). Those devices can continuously monitor meaningful data extracted from the human body, for instance, heart rate, body temperature, breathing, sweat and others (Heikenfeld et al. 2018). All of this information could be used when treating someone with a specific disease or just monitoring their health status daily - either by professionals or caregivers (Oswald and Zhang 2016). The ultimate goal for all wearables is not only to collect and send health data but rather to detect and mitigate health problems and risk situations (Woyke 2016). Anticipation and prevention of "adverse health events" would bring countless benefits to their users and the healthcare system in general. For example, a wrist band that uses pulse oximetry that is a predictor for oxygen levels in the blood is also the most reliable indicator of an overdose (Staff 2019). Furthermore, it is critical to identify an overdose on time for the person suffering to receive the necessary help promptly. It is beyond the present scope to discuss all relevant wearables. The focus of this thesis is commodity smartwatches. Most smartwatches are full of sensors which give them great potential for health risks prevention. To name a few sensors: electrical heart sensor to take ECG readings; an accelerome- CHAPTER 2. BACKGROUND 11

ter to keep tabs on movement; an optical heart sensor to measure heart rate; a gyroscope to track movement and rotation, and an ambient light sensor to control the brightness of the screen (Caddy 2019). The combination of the discreteness of a smartwatch and the plethora of sensors incorporated in the device makes it a suitable candidate for managing risky situations.

2.3 Crowdsourcing and crowdsensing

2.3.1 Crowdsourcing Jeff Howe and Mark Robinson (Howe 2006) first introduced the term crowdsourcing. During the last decade, the phrase has earned enormous popularity, especially with the rise of e-commerce, social media and smartphones. According to Jacquelyn White (White 2019), crowdsourcing is the prac- tice of utilising the knowledge of a group of people for a common goal. It is best applied when tackling significant complex problems that can be split into smaller chunks. Crowdsourcing provides the ability to streamline intri- cate processes. It represents outsourcing a task to an undefined (and generally extensive) network of agents via an open call instead of directly assigning the task to a particular agent. Crucial to this technique is the use of an open call format and the vast network of potential agents. According to Phuttharak and Loke (2019), the ultimate goal of crowdsourcing is to utilise mobile sensing and humans to collect and analyse information of people and the surrounding environment. The collected data enables crowdsourcing to provide useful information and services to end-users. Crowdsourcing allows companies to use agents located anywhere in the world and allows tapping into an enormous quantity of skills and expertise with little overhead costs. The approach has shown its effectiveness for plenty of tasks, including building the online encyclopedia Wikipedia, the Chess match of Kasparov against the world in 1999, and many more (Howe 2009). A great example of how companies use crowdsourcing is the toy company Lego. "The company allows users to design new products and at the same time, test the demand. Any user can submit a design that other users can vote for. The idea with the most amount of votes gets moved to production, and the creator receives a 1% royalty on the net revenue." (Kearns 2015). 12 CHAPTER 2. BACKGROUND

2.3.2 Crowdsensing The terms crowdsourcing and crowdsensing are often interchanged within the literature even though there is a subtle diﬀerence between the two methods. Crowdsourcing is the more general term; thus, crowdsensing can be viewed as a subset of crowdsourcing. The focus of crowdsensing is on using ubiquitous devices (e.g. smartphones, smartwatches and even mobile robots) and their sensors to perform particular work (Pilloni 2018) with or without explicit actions from the user. The term crowdsensing was coined by Ganti, Ye, and Lei (2011). It is a new sensing paradigm that allows the contribution of gen- erated/sensed data from mobile devices. This data can later be processed to provide human-centric service delivery. Crowdsensing can take advantage of the active participation of citizens (Capponi et al. 2019). Sensor’s coverage can be improved as well as humans with their intelligence can provide more in-depth context compared to traditional sensing systems. For instance, large-scale data that concerns urban planning can be collected using the crowdsensing technique. Karamshuk et al. (2013) tried to identify the optimal placement of new retail stores by using, among other features, crowdsensed user mobility data (transitions between venues or the incoming ﬂow of mobile users from distant areas).

2.3.3 Mobile crowdsoucring and crowdsensing As Pilloni (Pilloni 2018) summarises, crowdsensing and crowdsourcing, often referred to as mobile crowdsensing and mobile crowdsourcing, provide a new way to collect data collaboratively, by exploiting the pervasive presence of Internet-connected geolocated smart user devices, such as smartphones, smartwatches and tablets (Shu et al. 2017). The main focus of crowdsensing is that devices serve as moving sensors to collect data from different places (Guo et al. 2014). The goal in crowdsourcing (Peng et al. 2016) is to enable users to complete a dedicated task, usually by providing some form of feedback. These techniques are powerful approaches incorporating human wisdom into mobile computations to solve problems while exploiting the advantages of mobility and context-awareness (Phuttharak and Loke 2019). In the rest of this thesis, when no further differentiation is needed, Mobile crowdsensing (MCS) will be used to refer to both mobile crowdsensing and mobile crowdsourcing. The benefits that MCS provides boost its popularity. The approaches mentioned above allow easy scaling out and giving away small portions of tasks to be completed by remote workers. Also, the remote nature of the work provides excellent flexibility. MCS gives access to unavailable skills and expertise. It CHAPTER 2. BACKGROUND 13

can also accelerate various processes as group agents can perform a task faster than a single agent (White 2019). These benefits explain why the ideas behind mobile crowdsensing attract more and more research and business. MCS has proven to be useful both for scientific and business purposes (Phuttharak and Loke 2019). Typical application areas include environmental monitoring and disaster management, infrastructure monitoring, community healthcare, transportation and many more. Sensors that enable the development of applications in those scenarios are accelerometer, gyroscope, GPS, microphone, camera and others. For instance, GasMobile (Hasenfratz et al. 2012), HazeWatch (Sivaraman et al. 2013), and Third-Eye (Liu et al. 2018) rely on active citizen participation to monitor air pollution. Other examples are HealthAware (Gao, Kong, and Tan 2009), MPCS (Chen et al. 2009), and DietSense (Reddy et al. 2007), which try to encourage healthy eating habits by extracting time and location of where specific food has been consumed. To improve recycling, WasteApp (Bonino et al. 2016) has been developed to monitor the content of recycling bins and user behaviour regarding the topic. This unexhaustive list shows the potential that a paradigm like MCS has to provide new perspectives to urban societies (Capponi et al. 2019).

2.4 Mobile crowdsensing taxonomy

Boubiche et al. (2019) has devised a taxonomy of mobile crowdsensing applications based on existing literature. In this section, we are going to brieﬂy discuss them and show their connection with the current master thesis.

2.4.1 Sensing scale There are three categories concerning sensing scalability: separate, cluster and community sensing. In separate sensing, the data is collected for personal use only. The cluster sensing is more applicable for a smaller group of users. They share a common interest and share and collect data to achieve their goals. Community sensing is the highest level of scalability. It utilises large call sensing and is mostly used to predict global trends. In this thesis, we explore the cluster sensing category.

2.4.2 User involvement and responsiveness • Opportunistic sensing - in this group, the data is automatically collected, and the user involvement is as little as possible. In the current research, 14 CHAPTER 2. BACKGROUND

we use this approach for our smartwatch application. It automatically collects data and ﬁres an alarm when it encounters unusual activity. This category can be considered as mostly implicit sensing. This category is also known a passive crowdsensing and can include even data submitted for purposes diﬀerent than original intention (Ghermandi and Sinclair 2019).

• Participatory sensing - in this category, the user is active in the data collection process. We use this approach once the MCS system has received the alarming event and is looking for a person within a radius that is ready to provide help. This category is part of the explicit sensing paradigm.

2.4.3 Sampling rate In this category, Boubiche et al. (2019) compares continuous sensing to sensing executed depending on speciﬁc periods or places (context dependant). In the current research, the smartwatch application performs continuous sensing to be able to determine if an uncommon event has occurred. The drawbacks of this type of sensing is that it may exhaust the sensing resources. Once our mobile crowdsensing platform is searching for a candidate to provide support and help, we employ the context-aware sensing category.

2.4.4 Network infrastructure In this category, MCS can either exploit existing infrastructures (access points and GSM) or adopt peer-to-peer infrastructure. There is also a hybrid approach that combines both the groups mentioned above. The platform we base our work on is making use of existing infrastructure.

2.5 MCS for health care, emergency, safety

This thesis is limited to perform research in the ﬁeld of mobile crowdsensing connected to health care, emergency and safety. The applications of mobile crowdsensing are much more than that. However, in the current master thesis, we are going to focus on the areas mentioned above. The fact that MCS can capture real-time data about the rapid development of a crisis makes the technology a great candidate to simplify rapid response and eﬀective resource allocation. CHAPTER 2. BACKGROUND 15

Capponi et al. (2019) classify MCS into domain-speciﬁc and general-purpose according to their scope. With regards to the application domains of mobile crowdsensing, Boubiche et al. (2019) based on Ganti, Ye, and Lei (2011), or- ganise applications into four categories based on the type of sensed phenom- ena: environmental, infrastructure, social, and behaviour. A brief discussion of the categories important for this research can be found below.

2.5.1 Emergency management and prevention Emergency response applications are critical regarding their time-sensitivity and usually require more sensors. Examples of applications included in this category are those that monitor and response in case of accidents, natural disasters such as floods, fires or even nuclear disasters. For instance, Bengts- son et al. (2011) explore the use of mobile phone positioning data to monitor population movements during disasters and outbreaks, which can be used for assisting in coping with disasters, such as earthquakes and floodings. The authors of (D.-A. Nguyen et al. 2014) investigate the gas shortage that occurred after Hurricane Sandy in 2012 using crowdsensed data. Another example is Creekwatch - an application developed by the IBM Almaden research centre (Kim et al. 2011). Using crowdsensed data such as the estimation of the amount of water in the river bed, the amount of trash in the river bank, the flow rate, and a picture of the waterway the application allow monitoring the watershed conditions. Citizens movements and shared data are successfully used in CrowdMonitor - a crowdsensing approach in monitoring emergency services, coordinating real and virtual activities and providing an overview of an emergency, overall in unreachable places (Ludwig et al. 2015).

2.5.2 Healthcare and wellbeing An ageing society like ours is going to rely more and more on better approaches to improve health and wellbeing, starting as early as possible. Mobile crowdsensing helps in this ﬁeld as well by collecting a huge amount of health data. Applications that range from self-diagnosis to physical activities tracking and also community healthcare ﬁt into this category. The main focus is to allow diagnosis, treating and preventing illnesses, injuries, and providing timely assistance. 16 CHAPTER 2. BACKGROUND

Community healthcare In (Ferguson et al. 2006), Google researchers estimated illness distribution in the US by taking advantage of health-related search queries. This research was pioneering work in 2006 and started a sparkle of research in the area of combining MSC with healthcare data. Wesolowski et al. (2012) analysed the spread of malaria in Kenya using widespread dispersion of mobile phones. Similarly, the authors in (Haddawy et al. 2015) demonstrated how MCS could help mitigate the problem of tracking cholera outbreaks.

Personal healthcare In (Rabbi et al. 2011), authors present an MCS system for measuring mental wellbeing from behavioural indicators in natural everyday settings as primary healthcare, e.g. weight loss. Dong et al. (2012), authors present an MCS system for measuring intake via automated tracking of wrist motion in healthcare.

2.5.3 Mobile social networks These networks allow people to connect by exploiting mobile devices. The most fundamental aspect of this category is the collaboration between users. They can share the data sensed by a mobile device and establish social rela- tions. Crowdsense@place (Chon et al. 2013) is a system that tries to provide place related information, including the relationship between users and coverage of the system. This category of mobile crowdsensing applications focuses not only on user behaviour but also on their emotional state and social needs. Rachuri et al. (2010) is a tool suitable for conducting social and psycholog- ical studies. The basic concept is to map user activities to their emotions in order to create a correlation between them. The application collects user emotions and also proximity and patterns of conversations using the audio of the microphone.

2.6 Platform: Crowds

V.Granfors et al. (2018) have developed a crowdsensing system called CrowdS. The platform connects mobile devices such as smartphones or tablets and allows those devices to provide or request data. The data refers to information about the surrounding environment of the users, for example, the user’s location, traﬃc conditions, weather, noise level or air pollution. Currently, CrowdS CHAPTER 2. BACKGROUND 17

supports two types of data: text and numeric. The former type includes textual answers to questions such as "What is the current weather?". The latter is any numeric value corresponding to the needs of the requester, for instance, answers to the question "How many live in Stockholm" or measurements collected from the sensors of the participants’ devices. The platform supports both opportunistic and participatory sensing approaches. The proposed system consists of a server, a set of requesters and a set of providers. "The requester creates a task, pays for completion and has access to the results. The provider replies to received tasks, either manually by providing input personally or automatically when gathering sensor data, and collects the promised payment afterwards" as described by (V. Granfors et al. 2018). A task is an act of requesting data. The server has the primary responsibility for allocating the tasks. All devices that are part of the system can be considered as both a requester or a provider. As long as the smartphone or tablet contains the necessary sensor to execute a particular task, it can be recognised as a provider. The server also takes care of the quality control, reputation management and reward management. All of these components are crucial for every crowdsensing system that would like to provide valuable results. To start with, the data in MCS is very heterogeneous, and also users of the system are generally not experts in the necessary fields. Quality control is the mechanism that en- sures a better quality of the contributed data. How it is accomplished depends on the data. In CrowdS, verifying textual data uses majority voting, while distance formula performs the check for correctness of numeric values. Further- more, reputation management is used to discourage malicious behaviour and to provide high-quality data. In CrowdS, the approach is to classify providers by their willingness to participate in the system and by previous experience. Last but not least, the crowdsensing activities drain battery and computing power of participants’ devices. Therefore, an incentive mechanism is essential to reward the efforts and resources consumption, as well as for keeping participation in the system high. In CrowdS, micropayments mechanism provides payment and enforce a reward management system. For more information regarding the control and management mechanisms in CrowdS, check (V. Granfors et al. 2018). The example below illustrates CrowdS’ capabilities. Imagine an area without any specific sensors installed, but with enough people with smart devices, participants of CrowdS. Someone needs to monitor the level of noise in that environment. This person (requester) creates a task in CrowdS such as asking the question "What is the noise level in location X?" and proposes a reward 18 CHAPTER 2. BACKGROUND

for each participant that would execute the task. The server identifies the possible providers of the data and allocates the task to them. The people and their devices execute the measurement and submit their result in CrowdS. They receive the reward specified once the task was created. Now the requester can see the noise level in the specified location. The cost of the achieved result is much lower than installing and maintaining a specific infrastructure for measuring the noise level. Furthermore, the platform can be successfully used to perform surveillance tasks and emergency management in various geograph- ical areas. All of the above leads to the conclusion that CrowdS is a suitable base platform for developing a solution that could detect and mitigate risky situations. Chapter 3

Design and Implementation

This chapter describes the two components that extend the existing CrowdS system: a smartwatch application and additional Bluetooth support for CrowdS’ smartphone application. The selected smartphone used to perform a demo is Samsung Galaxy S7 Edge, Samsung Exynos Octa 8890 2.60 GHz CPU, 4GB RAM, 32 GB internal storage and 3600 mAh battery capacity with Android version 8.0.0 and Samsung Experience version 9.0. The selected smartwatch was Galaxy Watch 46mm LTE, Exynos 9110 Dual-core 1.15GHz CPU, 1.5GB RAM, 4GB Internal Memory and 472 mAh battery capacity with Tizen Based Wearable OS 4.0. Sensors available on the smartwatch were Accelerometer, Gyro, Barometer, HRM, Ambient Light.

3.1 Extending CrowdS Android application

As of the time of writing, CrowdS system includes a server side and a device side - set of smart devices that can both make requests to the server, as well as provide data on request. The server side is the part responsible for task allocation as well as quality control and reputation management. The architecture of the system is a typical representative of centralised architecture - there is no direct communication among the smart devices. All of the requests and responses go through the server.

19 20 CHAPTER 3. DESIGN AND IMPLEMENTATION

Figure 3.1: CrowdS System Overview. Source: (V. Granfors et al. 2018)

In this research, the server side of CrowdS is used without any adaptation. The only changes done are fixing a few minor issues which occurred while testing the system. For more information on how CrowdS performs task allocation, what is reputation and reward management, and how does quality control work, please refer to (V. Granfors et al. 2018). We have extended the device side of CrowdS to fit the current research purpose. First, we briefly describe the existing architecture of the client side, and then we explain the modifications and their purpose. The main components of the client side of CrowdS are communication manager, Sensor task (ST) manager and Human intelligence task (HIT) manager as shown in Figure 3.2. The communication manager is responsible for handling all of the communication and redirecting messages to the proper des- tination. The ST manager handles the collection of data from sensors and sending the data to the communication manager. HIT manager takes care of new and expired human intelligence tasks. CHAPTER 3. DESIGN AND IMPLEMENTATION 21

Figure 3.2: Device overview. Adapted from source: (V. Granfors et al. 2018)

For example, think of a user that wants to measure the temperature in a room within a public building. The user creates a sensing task for measuring the temperature. The communication manager relays the task to the server side. The server finds appropriate devices within CrowdS that can execute the task, e.g. devices that can measure temperature in the defined location. After the devices finish with the temperature measuring, the communication manager notifies the requester that its task has completed. User involvement is not necessary in this case which is why this particular type has the name sensor task. On the other hand, human intelligence task could be considered a task that requires the involvement of the user. For instance, if the participants in CrowdS need to say how long is the queue in front of a canteen, they need to actively take out their devices and take a picture of the queue. We have extended the current version of CrowdS’ client side by adding a new Bluetooth manager, in addition to the ST and HIT managers. The new manager is depicted in Figure 3.3 The Bluetooth manager enables the phone to receive information from paired Bluetooth devices. This approach allows smart devices connected to the phone to access CrwodS using the same communication channels as for the ST and HIT managers. Furthermore, such a layer provides tremendous flexibility and can include a diverse set of wearables quickly and straightfor- wardly. Currently, this layer enables a connected device to send data via Blue- tooth. This data represents an alarm event, which indicates that a risky sit- 22 CHAPTER 3. DESIGN AND IMPLEMENTATION

Figure 3.3: Extended client side overview. Adapted from source: (V. Granfors et al. 2018) uation has occurred. After the smartphone receives the event, it relays the collected data to the CrowdS server side. Figure 3.4 visualises the standard dataﬂow in CrowdS platform when using a smartwatch connected to the system via Bluetooth.

Figure 3.4: CrowdS platfrom emergency detection dataﬂow

We have implemented the Bluetooth service using a standard approach for Android OS (Bluetooth overview 2020). This way, we can easily extend the CHAPTER 3. DESIGN AND IMPLEMENTATION 23

Bluetooth manager and add multiple devices. One constraint of this approach is that the smartwatch and the smartphone ought to be close to each other as Bluetooth protocol implementation has a limited range of transmitting and receiving data (Understanding Bluetooth Range 2020).

3.2 Smartwatch Application

The smartwatch used in this research is Galaxy Watch 46mm LTE (Galaxy Watch 2020). The sensors that are being utilised in this thesis are the gyroscope, accelerometer and GPS. The goal was to create an application that can fire alarms when it detects abnormal behaviour or situation. We have been strongly inspired by research in the field of fall detection and prevention. There is an enormous amount of literature focused on fall detection (Habib et al. 2014; Khojasteh et al. 2018; Casilari and A.Santoyo-Ramón 2018), which provide various models that enable easy and effective fall detection using wearables. In the current master thesis, the focus is not on building an accurate and reliable fall detection model. Falls are being simulated by merely tracking the changes in the accelerometer’s Z-axis. Once a certain threshold is reached, a fall is simulated, and the application can notify CrowdS that an emergency occurred. The goal is to showcase how, after a risky situation appears, the smartwatch can connect to our mobile crowdsensing system. Then the MCS takes care of relaying the signal to people nearby who can provide help. Falls are just one example of such a system. Other examples could be detecting dangerous situations by using a microphone or identifying dangerous locations for allergic people by using pollen sensors. The architecture of our system is similar to the standard architecture of a fall detection system, displayed in Figure 3.5. 24 CHAPTER 3. DESIGN AND IMPLEMENTATION

Figure 3.5: Basic Architecture of Fall Detection System. Source: (Casilari and Oviedo-Jiménez 2015)

Figure 3.6 shows the architecture of our smartwatch software. It has been developed using the Tizen Platfrom (Tizen Platform 2020). The application is a web-based application (Tizen Web Application 2020) that utilises existing APIs to access the necessary sensors - DeviceMotion API (comprised from accelerometer and gyroscope) (DeviceMotion API 2020), as well as Geolocation API (Geolocation API Speciﬁcation 2020).

Figure 3.6: Smartwatch Application Components.

There are two main extensible components in the smartwatch application architecture - Risk Identifier and Risk Mitigator. The Risk Identifier is the main module utilising the smartwatch sensors. It can perform the required calculations and based on specific rules - identify CHAPTER 3. DESIGN AND IMPLEMENTATION 25

if a dangerous situation has occurred. In this particular research, we chose to showcase how the Risk Identifier would work by using the smartwatch’s De- viceMotion API. For this purpose, we created a class that extends the Risk Identifier, called Fall Identifier. Using standard OOP, the Risk Identifier becomes vastly extensible - the addition of any other type of Risk Identifier would mean simply extending the Risk Identifier class. There are a few reasons why we chose to showcase how such a platform would work by using a fall detection mechanism. First of all, there is plenty of research (Section 2.1.1 and Section 2.1.2) around how device movement can be used to detect falls and other risky situations connected to movement. Fur- thermore, the DeviceMotion API is easily accessible and can provide accurate data to detect the device’s speed and orientation. The other main module of the smartwatch application is Risk Mitigator. Currently, Risk Mitigator has two implementations - BluetoothRiskMitigator and CrowdsensingRiskMitigator. The implementations are discussed in Sec- tion 3.3 and Section 3.4 below. It allows for easy integration of new devices using different protocols.

3.3 Smartwatch integration with CrowdS via Internet

Initially, the integration between the Tizen smartwatch and CrowdS platform was implemented by adopting the smartwatch capabilities of Internet support. The Galaxy Watch has the capability of fetching resources across the network. We have implemented the smartwatch integration with the Internet by using the Fetch API (Fetch API 2020). It allows for creating requests and receiving responses from CrowdS remote server. Section 5.1.1 discusses the advantages and disadvantages of the direct integration of the Tizen application with CrowdS.

3.4 Smartwatch integration with CrowdS using Bluetooth

The limited battery capacity of most smartwatches and wearables has inspired another approach of connecting them to another device or platform. "Most of the smartphone-dependent smartwatches overcome this [limitation] by of- ﬂoading power-consuming sensing and computing operations to the phone and 26 CHAPTER 3. DESIGN AND IMPLEMENTATION

use low-power Bluetooth to communicate." (Rawassizadeh, Price, and Petre 2014) Generally, any wearable device that has Bluetooth capabilities can be easily connected to a smartphone. Once the smartwatch has detected a risky situation, it transmits the current location of the watch to a paired phone. The user should be logged into the CrowdS platform on the phone. This way, the connection between the CrowdS phone application and the CrowdS server is performed as described in (V. Granfors et al. 2018). Section 5.1.1 discusses the advantages and the drawbacks of connecting the smartwatch to CrowdS through a smartphone.

3.5 Extended CrowdS sample scenario

In this section, we demonstrate how to use the extended CrowdS platform that we have developed as part of this master thesis. Figure 3.7 display the user interface of the Galaxy watch application. The button on Figure 3.7a allows the smartwatch to pair with CrowdS Android application. The user needs to execute this as the first step in order to be able to fire alarms. Generally, firing alarms happens as a background process. The smartwatch application tracks the necessary sensors and notifies CrowdS application if an unexpected event occurs. Nevertheless, we have added a button that can be explicitly pressed and simulate such an event. The button’s purpose is to lighten the testing process and is displayed in Figure 3.7b.

(a) Connect with CrowdS app (b) Request help through CrowdS

Figure 3.7: Galaxy watch application for detecting a risky situation

Figure 3.8 depicts CrowdS Android application and its screens that handle the Bluetooth connection. On Figure 3.8a, we can see the extension of CHAPTER 3. DESIGN AND IMPLEMENTATION 27

CrowdS - a new section that allows the user to control the connected Blue- tooth device. The current implementation is straightforward - the user can see the name of the connected device. If there is no connected device, the name "default" is used (Figure 3.8b). The button "Open socket for connection" is the one that allows CrowdS application to connect to a Bluetooth device. Figure 3.8c displays the same screen, but after the user has paired the app and the smartwatch.

(a) Bluetooth menu (b) Initial Bluetooth (c) Connecting with in drawer screen Bluetooth device

Figure 3.8: CrowdS app: pairing with Bluetooth device

After an alarming situation occurs, we can have a look at the CrowdS An- droid application more in detail. We have created two user accounts in CrowdS named Account 1 and Account 2. Figure 3.9 displays both accounts. Account 1 represents the user that has the smartwatch. Alarms, fired by the smartwatch, are displayed as "Ongoing tasks" in CrowdS. The task we have created using the smartwatch is visualised on Figure 3.9a. The behaviour would be the same as if the user had manually created the task through the CrowdS application. On Figure 3.9b and Figure 3.9c Account 2 is displayed. Account 2 belongs to the user that receives the fired alarm. At the time the emergency happened, this user was nearby (within predefined radius) from the user that fired the alarm. On the first screen from Account 2, the user receives a push notifica- tion that a new task has been assigned to the account and the system expects some actions. On the next account, the newly created task, corresponding to the emergency, is visible. Now the user can decide whether or not to help the person in need. 28 CHAPTER 3. DESIGN AND IMPLEMENTATION

(a) Account 1: On- (b) Account 2: Push (c) Account 2: As- going task created by notiﬁcation for signed task created smartwatch assigned task by smartwatch

Figure 3.9: CrowdS app: Task creation ﬂow

To get a better grasp of how the system as a whole would work, we show a sample scenario of Figure 3.10. On the left, we have a monitored user. The person holds a wearable device that has CrowdS application installed. Once an alarming event occurs, the wearable sends a signal to CrowdS smartphone application via Bluetooth. The CrowdS app creates a task for this event in the CrowdS server, which is in the middle. Alternatively, the smartwatch can create the task directly on the CrowdS server via the Internet. Next, CrowdS server takes care of task allocation. All of the participants that are within a certain proximity of the monitored user receive the task. This is displayed on the right of the ﬁgure. Potentially, one of the participants agrees to execute the task and becomes an active participant. We expect that the active participant will oﬀer assistance to the monitored person. CHAPTER 3. DESIGN AND IMPLEMENTATION 29

Figure 3.10: Scenario of extended CrowdS

3.6 Nectarine’s platform

As part of this master thesis, we have connected with a company that is building a remote care wristband - Nectarine Health (Nectarine Remote Care 2020). Nectarine Health is a Swedish healthtech company that specialises in providing AI-powered remote care solutions for an ageing population. Founded in 2015, and formerly known as Aiﬂoo AB and Noomi AB, Nectarine Health was acquired in 2020 by the health innovator Brighter AB. Nectarine’s solution has been designed to give older people the conﬁdence to live independently in their own home for longer, without having to compro- mise on their privacy or dignity. Nectarine connects a state-of-the-art wearable wristband worn by the older person with Nectarine’s system. Data collected by the wristband is streamed 24/7 directly to the Nectarine cloud platform allowing the well-being of the wearer to be assessed. Nectarine uses millions of data points, analysed in real- time using deep learning modules, to detect falls, understand patterns of activity, manage alerts, and provide health insights with ever greater accuracy. The wristband wearer has the reassurance of knowing that Nectarine can proac- tively detect an issue, such as a fall, and alert carers so they are able to provide timely, proactive and relevant care, reducing the need for acute or residential care. Nectarine has been deployed in nursing homes across Sweden for the last three years. With the data and learning from the residents, Nectarine is devel- 30 CHAPTER 3. DESIGN AND IMPLEMENTATION

oping a consumer version of the product for people to use in their own homes. The company is developing both hardware and its software, whose primary purpose is helping seniors living a more independent life and providing assistance to caregivers. The hardware of Nectarine’s solution consists of a wristband and multiple receiver nodes. The wristband has built-in sensors that collect raw motion data of the wearer. The location of the receivers is within the monitored space. The wristband sends the collected information to the closest receiver through a secure connection. The received motion data and its location allow the closest node to detect different types of activities such as walking, standing, being out of bed, going to a specific room, sleeping, bathroom visits and others called events. All data is sent to the cloud-based Nectarine platform via the Internet. Once the data reaches this platform, different artificial intelligence based algorithms start processing it. The software learns from the collected information and can detect patterns or events that could go unnoticed. For instance, the system can detect if the wearer is up during night time unusually long or if an unexpected fall occurs. Once such an unpredictable situation happens, the system sends alerts to a smartphone application, used by caregivers. Caregivers take further action to help the person in need. Another feature of interest is the manual alarm button on the wristband. When the wearer presses the button, the wristband broadcasts the event through Bluetooth. Any Bluetooth enabled device can catch the incoming message using standard Bluetooth communication. Nectarine’s system has very sophisticated software that improves over time by gathering more data from the wearer. As of now, the platform’s design limits its usage to indoors only. A possible solution for using the platform outdoors is to integrate it with a mobile crowdsensing system. The receiver node has a backup battery, which allows the wearer to bring it outside. Once outside, the receiver node could perform the same functions as before, e.g. process raw data and detect particular events (assuming a stable Internet connection is en- sured). Besides, the node could send the detected event not only to Nectarine’s cloud platform but also to an MCS. Another option would be that the cloud platform directly communicates with the mobile crowdsensing server. Such an approach could improve the scope of Nectarine’s platform, providing even more safety and security when the wearer decides to get out of the monitored area. This proposal is not yet properly discussed from a practical point of view with Nectarine Health. Nevertheless, it serves as an example of how the system implemented in the current master thesis can be integrated not only with commodity smartwatches but also with different wearable devices. Chapter 4

Experiments

In this thesis, we used an Intel(R) Core(TM) i7-8750H 2.20GHz CPU, 16GB RAM, Windows 10 Home operating system and GAMA Platform - V1.8.0 (GAMA-Platform · GAMA 2020) to perform the simulations. Table 4.2 contains the parameters that represent variables in the simulation and their default values. The goal is to achieve a ﬂexible simulation that can be useful for people wanting to build a crowdsensing system for risk mitigation.

4.1 Motivation

In the previous chapter, we have discussed the design and implementation of smartwatch application. Also, we have elaborated on different integration techniques between wearable devices and CrowdS application. There are many requirements to test this setup. First, we need many people that would represent active participants in CrowdS. Participants’ actions need constant coordination while performing the experiment. Also, we need to figure out the probability of participation in the system and how it would affect participation in it. Furthermore, it would be infeasible to test scenarios with different density and distribution of participants. Additionally, testing the usage of different transportation means adds another layer of complexity to the system’s evaluation. Due to time limitation and feasibility reasons, we have decided to build a simulation of the system instead of testing it with real users in a real environment. Simulation allows the use of parameters for each property that we want to explore. Parameters can easily be changed and adapted according to what hypothesis is being tested. In the next section, we discuss the design and setup of the simulation. We provide a brief explanation and motivation of the

31 32 CHAPTER 4. EXPERIMENTS

chosen parameters.

4.2 Experiments setup

In this section, we describe the setup of our experiments. Using the GAMA platform, we simulate that an emergency occurs in a speciﬁc area, ﬁlled with people. Figure 4.1 shows how an example experiment looks like.

Figure 4.1: Example setup of experiment

The rectangle represents a speciﬁc place such as a park or a suburban area. The dimension of the rectangle can be adjusted according to the needs of the simulation’s user. All of the small yellow spheres, as well as the red sphere, represent people. Within the GAMA platform, they are called agents, and from now on, we are going to use this terminology. All of the agents are potential participants in the mobile crowdsensing system. The red agent represents a single person for whom an emergency occurs. The bigger circle around the red agent represents the radius of the MCS system. The system does not have CHAPTER 4. EXPERIMENTS 33

to include the whole experimental area, and the radius should be chosen depending on the requirements of the particular system. Each yellow agent contains the following attributes: location (coordinates), is_helping (boolean) and speed (m/s). Depending on the experiment type, the location is either a random point within the defined area or agents are grouped into clusters. The attribute is_helping is initialised based on a flip function1. The flip function returns true with a predefined probability. In the default case, the probability is 0.27. This would mean that approximately 3 out of 10 times a person will be responding positively. The speed is based on different movement types and is also decided based on a predefined probability. There are four movement types: walking, running, cycling and using a car. For more information on the parameters and their default values, check the next section, Section 4.3. Depending on the experiment, the agents can either freely move around the area or stay still on their initial location. The red agent represents the person that sends a help request. We always initialise it with a location in the middle of the area. For consistency, the agent does not move until the end of the simulation. Within a single experiment, we simulate the appearance of a dangerous situation 500 times. The red agent sends a signal for help to all agents within the radius of the mobile crowdsensing system, which means that a dangerous situation has occurred. These agents are called participants of the system. From those agents, only a percentage will respond positively to the request. The rest will reject it. The agents that respond positively represent the active participants of CrowdS platform. In a real-life scenario, one of the platform participants would take the "task" to go and check what is happening with the person in need. We model this behaviour into our simulation. A single agent is randomly selected from all of the active participants. The time needed to reach the target agent (the agent that needs help) is calculated based on the selected participant. We take the location and speed of the agent using the standard dependency between distance, time and speed:

t = S/v (4.1)

where t means time, S represents the distance, and v is the speed. The distance we calculate by using the Euclidean distance formula2 using the location of the red agent and the location of the agent that responded positively. Let

1Gama Flip Operator: https://gama-platform.github.io/wiki/ OperatorsDH#flip 2Euclidean distance: https://en.wikipedia.org/wiki/Euclidean_ distance 34 CHAPTER 4. EXPERIMENTS

us say the location of the target agent is (x1, y1) and the location of the active participant is (x2, y2). Then we an calculate the Euclidean distance: q 2 2 distance = (x1 − x2) + (y1 − y2) (4.2)

The speed we have as an attribute of the responded. It is now trivial to calculate the time needed to reach the target. In the simulation, the colour of the selected agent turns purple. The user can observe how the selected agent reaches the target. Once the target is reached, the simulation goes back to its initial state. We designed a few scenarios which can support us in exploring how a mobile crowdsensing system will behave under diﬀerent conditions. We were mainly inspired by two particular use cases - usage of such a system either in a city park or in a suburban area. Table 4.1 below depicts more speciﬁc characteristics of the terms park and suburban area as they are both quite broad.

Use case 1: Park Use case 2: Suburban area Smaller in terms of km2 Bigger in terms of km2 Higher density in p/km2 Lower density in p/km2 People are walking freely People are mostly in an open space inside their homes People are either walking, Introduce also a car running or cycling as a way of transportation Mostly strangers to each other; Usually form a community; little trust higher level of trust

Table 4.1: Diﬀerence between use cases used to derive parameters of an MCS for risky situation detection

In this section, we discussed how we constructed our experiments environment. We defined a few important metrics and the relationships between them. Use cases of MCS showed different characteristics suitable for such a platform. Using the defined use cases as guidelines, in the next Section 4.3, we define the parameters of our system. Each parameter is explained in details, and at the end, all parameters are summarised.

4.3 Parameters selection

In this section, we provide a brief description of each parameter used in the conducted experiments. We provide default values as well as value variations CHAPTER 4. EXPERIMENTS 35

according to the speciﬁc scenarios tested. We also provide reasoning about why we have chosen those parameters speciﬁcally.

• Area size: determines the size of the area in km2 where we would like to use the mobile crowdsensing system for detecting dangerous situations. For instance, such an area could be a park, city centre, a small town or a suburb. The default value we chose for this parameter is 1.5 km2. The number is the average from the standards for outdoor recreational areas3 and the size of a top-rated park in London, UK - Hyde park4.

• Number of people: depicts the number of people located in the area where the MCS is installed. This value can vary significantly depending on the type of the area and the time of the day. For instance, the number of people visiting a park such as Hyde park varies significantly during peak and off-peak hours. The same concerns are valid when calculating the number of people in the city centre or a suburban area. The default value of this metric is 600 people. Detailed information on how we calculated this value can be found in A

• Density: sometimes we combine the size of the area with density instead of the number of people. The density is described as people/km2. Density, together with distribution type, can describe the diﬀerent types of areas where an MCS solution is feasible. Generally, the density of an area can change depending on the time of the day. We take the parameter density as the current density of an area within a speciﬁc smaller time- frame such as 10 minutes. We assume that the density will not change during the explored period.

• Distribution type: we chose two diﬀerent distribution types - random or clustered. In the random distribution, each person has a random location within the area of the MCS. Such an allocation is more suitable for the city centre, where people are randomly walking around and exploring every corner of the area. The clustered distribution depicts more precisely a suburban area. Communities with smaller streets and houses where people generally stay within the borders of their homes.

• Probability of participation: this parameter depicts with what probability a participant in the mobile crowdsensing system will become an

3Standards for Ourdoor recreational area: https://www.planning.org/pas/ reports/report194.htm 4Hyde Park area: https://www.royalparks.org.uk/parks/hyde-park 36 CHAPTER 4. EXPERIMENTS

active participant. The act of helping someone is a voluntary activity. We used information about how many people volunteer5 and chose a default value of 0.27. The higher the probability is, the more reliable are the participants in the MCS.

• Probability of different means of movement: the movement types we chose to use are walking, running, cycling or using a car. We exclude taking a train or a plane from this research as we focus on shorter dis- tances. The selected means of transportation correspond to predefined speed. The speed for each of them is as follow: walking - 1.5 m/s; running - 5 m/s; cycling - 7 m/s; using a car - 13-30 m/s6. Speed of a car during the morning (before work) and evening (after work) we take at the lower bound of the speed due to traffic - 13 m/s. During the day, we take the upper bound of 30 m/s. We have four values representing what probability participants in the MCS use each of the means of transportation. The sum of the probabilities for each type should give exactly 1. For example, if a participant is walking 80% of the time, running 5% of the time, cycling 15% of the type and never using a car, then the corresponding probabilities are 0.8, 0.05, 0.15 and 0.0. For simplicity sake and easier comparison, the default values we chose for the different transportation types are: [1.0, 0.0, 0.0, 0.0]. Those values mean that participants are walking exclusively.

• Radius of emergency system: this parameter the coverage of the mobile crowdsensing system. The person that request help through the system sends the signal to people within this range. It is generally less than the whole area. Some of the areas considered suitable for an MCS are quite big in term of area size, and it would be infeasible for a participant to pass too many km to reach a person.

Table 4.2 below summarises the selected parameters and their default values.

5How many people volunteer and what do they do: https://data.ncvo.org.uk/ volunteering/ 6Typical everyday speeds: https://www.bbc.co.uk/bitesize/guides/ zq4mfcw/revision/1 CHAPTER 4. EXPERIMENTS 37

Name Default value Area size 1.5 km2 Number of agents 600 Density 400 p/km2 Distribution type random Probability of participation 0.27 Probability of walking 1.0 Probability of running 0.0 Probability of cycling 0.0 Probability of using a car 0.0 Radius of emergency system 300m

Table 4.2: Parameters and default values used in experiments with a system for handling emergencies

The parameters described in the section above inﬂuence diﬀerent properties of the mobile crowdsensing system with various degree. The properties we are most interested in are the number of active participants in the system and the time needed to reach the target person. In the next section, we present results from the conducted experiments and discuss how each parameter affects the properties of interest. Chapter 5

Results and Discussion

In this chapter, we elaborate on our findings from integrating the smartwatch application with CrowdS platform. Different communication protocols are compared. We also discuss executing tasks mostly on the smartwatch versus offloading the watch by utilising the smartphone’s capabilities. Furthermore, we depict the results from different experiment scenarios that we have executed using our simulation. We discuss the results and make conclusions.

5.1 Smartwatch integration with CrowdS

In this section, we provide a qualitative analysis of the two main topics explored in this thesis - protocols for communication between a Galaxy smartwatch and CrowdS platform as well as advantages and limitation of implementing a model for risk detection on the smartwatch. This section does not provide any measurement, rather our opinion and lessons learned while performing the implementation part of this work.

5.1.1 Communication protocols comparison

Via the Internet We have explored two diﬀerent communication protocols while integrating Galaxy smartwatch Tizen application with CrowdS platform. First, we used the smartwatch’s capabilities of connecting to the Internet. We called this approach "direct integration". Table 5.1 depicts the advantages and disadvantages of the direct integration of the Tizen application with CrowdS. This approach allows the smartwatch to be completely independent of any other device. Moreover, it can directly communicate with the CrowdS server without

38 CHAPTER 5. RESULTS AND DISCUSSION 39

any intermediary. However, this approach has disadvantages when it comes to the device’s battery capacity. The small size of most wearables imposes severe limits on device performance and battery consumption (Williamson et al. 2015). Any disturbance of the network connection, e.g. the inability to connect to CrowdS in a fast and reliable manner, could make the system highly unreliable. In the case of detecting a risky situation, reliability is of extreme importance. That is why we decided to explore another approach, which is more commonly employed when working with wearables devices.

Advantages Disadvantages No need to bring both Battery is very limited smartphone and smartwatch One device performs all the operations; Needs a speciﬁc application for each no need for synchronisation speciﬁc version as not all smartwatches are with Tizen OS or Android OS If update is necessary, Need to create additional account only one device needs to be updated in CrowdS Would not work with a wearable that does not have access to the Internet

Table 5.1: Advantages and disadvantages of integrating smartwatch with CrowdS directly via Internet

Via Bluetooth The other communication protocol that we used was Bluetooth. It is a well known standard way of connecting smartwatches to smartphones. Table 5.2 below shows the advantages and the drawbacks of connecting the smartwatch to CrowdS through a smartphone. There is no need to create a new account in CrowdS for the smartwatch as it would reuse the existing account of the user. Moreover, the smartwatch or any wearables does not need WiFi or mobile network connection, and only its sensors can be used. The most notable positive side is that we open the CrowdS platform for integration with any device that has Bluetooth support. 40 CHAPTER 5. RESULTS AND DISCUSSION

Advantages Disadvantages Oﬄoads searching for network Smartwatch depends on smartphone Any wearable with Bluetooth support Need to support 2 applications: can be integrated for smartwatch and smartphone

Table 5.2: Advantages and disadvantages of connecting smartwatch to a smartphone through Bluetooth

5.1.2 Comparison between smartwatch-oriented and smartphone-oriented approaches Both smartwatches and smartphones contain sensors that can detect user’s movement, location, sounds around the user and other characteristics depending on the device. There are two main approaches when we talk about smartwatch application - execute everything on the smartwatch or oﬄoad the smartwatch by connecting it to the phone. Smartwatches have limited storage and battery capacity. Their computational power is also relatively smaller compared to the smartphone. Some applications that take advantage of smartwatch’s sensors send the raw data to the phone and leave the latter device to perform the computation. Others rely strictly on the smartwatch and make the phone either a simple intermediary or unnecessary. In this thesis, we used the capabilities of the smartwatch. First of all, this simpliﬁed the development process. Moreover, we avoided the constant communication between the smartwatch and the smartphone. Both approaches have their pros and cons. The one that suits the best should be chosen depending on the requirements.

5.2 Simulation experiments

In this section, we explore how a system for managing risks would perform under diﬀerent constraints. Our simulation allows us to easily change the parameters that aﬀect the system and to visualise the results immediately.

5.2.1 Scenario 1: Diﬀerent density In this scenario, we ran two experiments with parameters depicted in Table 5.3. The rest of the parameters in both experiments stay the same as in Table 4.2. The goal was to compare what is the inﬂuence of density on two properties of interest. The properties are the ratio between saved emergencies and not CHAPTER 5. RESULTS AND DISCUSSION 41

Parameter Experiment 1 Experiment 2 Number of agents 100 600 Area size 1.5 km2 1.5 km2 Density 67 p/km2 400 km2

Table 5.3: Parameters used in Scenario 1: Different density saved emergencies as well as the time needed to reach the person in need. For both experiments, we simulate 500 emergencies, and we measure the number of active participants compared to all emergencies that happened. We used two different densities - 67 p/km2, which represents an off-peak hour and 400 p/km2, which corresponds to a peak-hour, respectively. For more information on how we reached these numbers, check Appendix A. In the first experiment, Figure 5.1a, out of 500 emergency cases, only 31 had positive responses. During the second experiment, Figure 5.1b, 146 times at least one person responded positively out of 500. We have 6% success rate for the first case, while in the second one we have 29%.

2 (a) Density: 67p/km2 (b) Density: 400p/km

Figure 5.1: Handled emergencies versus not handled emergencies

Next, we explore the time needed to reach the target person. Figure 5.2 displays the average time to reach the target person depending on the density. The x-axis depicts the average density, and the y-axis shows the average time to reach the target person in seconds. The green bar corresponds to density ≈ 67 p/km2. The red bar corresponds to density 400 p/km2. What we observe in this graph is that there is an insigniﬁcant time diﬀerence for both experiments. The time needed to reach the target is ≈ 180s. 42 CHAPTER 5. RESULTS AND DISCUSSION

Figure 5.2: Average time to reach target depending on density

This scenario allows us to conclude that the density parameter aﬀects the number of active participants but does not aﬀect the time needed to reach the person in need.

5.2.2 Scenario 2: Different transportation methods The goal of this scenario is to visualise how introducing new transportation methods in a crowdsensing system can affect the time to reach the target in need. We again performed two experiments by keeping all parameters the same except for the transportation methods. In the first experiment, we used three means of transportation - walking, running and cycling. We have assigned probabilities 0.8, 0.1 and 0.1 to each of them. The probabilities mean that 8 out of 10 times a person will be walking. Moreover, 1 out of 10 the person will be either running or cycling. In the second experiment, we used only a single transportation type - walking. On the chart below, Figure 5.3, we measured the time need to reach the person in need for both experiments. The x-axis of the figure depicts the means of transportation. The green bar corresponds to the first experiment, e.g. transportation types are walking, running and cycling. The red bar corresponds to the second experiment, where participants are only walking. The y-axis shows the average time to reach the target person in seconds. The graph shows that when introducing new transportation types, the time to reach the target drops tremendously. For the first experiment, the average time to reach a target is a bit below 70s, while for the second - it is around 180s. The difference is more than double. We can conclude that the various CHAPTER 5. RESULTS AND DISCUSSION 43

Figure 5.3: Average time to reach target depending on means of transportation transportation types have a substantial impact on the time to reach the target person.

5.2.3 Scenario 3: Diﬀerent probability of participation This scenario depicts how the probability of participation in a crowdsensing system aﬀects the number of active participants. We conduct two experiments with the following parameters:

Parameter Experiment 1 Experiment 2 Number of agents 300 600 Area size 1.5 km2 1.5 km2 Density 200 p/km2 400 km2 Probability of participation 0.5 0.27

Table 5.4: Parameters used in Scenario 3: Diﬀerent probability of participation

For the ﬁrst experiment, we have decreased the number of agents to 300, respectively, the density of the area to 200 p/km2. At the same time, the probability of participation increases to 0.5. The second experiment has two times more agents - 600 and density 400 p/km2. The probability stays the default probability - 0.27. Figure 5.4 shows the results from the two experiments. The whole circle depicts the number of emergencies. In our case, it is predeﬁned to be 500. The blue section of the pie chart represents the number of positive responses and 44 CHAPTER 5. RESULTS AND DISCUSSION

the green one - the times when nobody reacted to an emergency. We can see that the blue section of both charts is similar in size. On Figure 5.4a pie, 190 out of 500 emergencies somebody accepted the request for help. On Figure 5.4b, the numbers are very close - 181 out of 500 had a positive outcome.

(a) Density: 200 p/km2 and prob- (b) Density: 400 p/km2 and probability: 0.5 ability 0.27

Figure 5.4: Handled emergencies versus not handled emergencies

The conclusion is that having more members in the crowdsensing platform does not necessarily lead to having a better platform. Providing a good incentive for people to be active participants can achieve similar results with fewer people.

5.2.4 Scenario 4: Different distribution of participants In this scenario, we compare how different distributions affects the crowdsensing system. We have used the same parameters from Table 4.2 except for the distribution, which is clustered instead of random. Figure 5.5 shows how a clustered distribution looks like. CHAPTER 5. RESULTS AND DISCUSSION 45

Figure 5.5: Clustered distribution of agents

Observations about this scenario show that when the distribution is clustered, the density within the radius decreases. The results confirm what we have discovered in Section 5.2.1, namely that the density parameter affects the number of active participants but does not affect the time needed to reach the person in need.

5.2.5 Scenario 5: Constantly increasing density For this scenario, we explored how constantly increasing the density aﬀects the number of active participants. Our initial assumption was that even if we increase the density, we are going to observe diminishing return after a particular density. The experiment we designed for this scenario was the following: we started by having zero agents in the area of interest. Every second we added a new agent, which lead to increasing the density in the area with a constant. After adding the new agent, we measured the number of active participants. Figure 5.6 below shows the results from the experiment. The x-axis represents the 46 CHAPTER 5. RESULTS AND DISCUSSION

density of the area at every second on a logarithmic scale. The y-axis corresponds to the number of active participants. We can see the trend - in the beginning, the active participants’ number was increasing much faster compared to the second half of the chart. Towards the end of the experiment, the number of active participants was not going above 150 disregarding the continuous increase of density.

Figure 5.6: Correlation between density and active participants. Active participants in logarithmic scale.

We can conclude that there is a saturation of active participants. We do not need to continually increase the number of potential participants in the system to be sure we are going to have enough active participants.

5.2.6 Scenario 6: Diﬀerent radius of MCS This scenario examines what is the eﬀect of changing the coverage of the mobile crowdsensing system on the results it can achieve. We have used the same parameters from Table 4.2, except for the radius of the system. We experimented with radius 150m and 300m. Figure 5.7 shows the results from the two experiments we conducted in terms of how many dangerous situations were dealt with and how many were not. To visualise the results from both experiments, we have used a pie chart. The green part of the chart shows emergency cases that had no positive response, while the blue part shows handled emergencies. Figure 5.7a depicts the result from the experiment with radius 150m. The number of emergencies that were handled is 47 against 453 that were not handled. The success rate of the system with this radius is only 9%. CHAPTER 5. RESULTS AND DISCUSSION 47

Figure 5.7b displays the result from the experiment with radius 300m. Here the number of saved dangerous situations is 211 versus 289 not save. This is a success rate of around 42%.

(a) Radius of MCS: 150m (b) Radius of MCS: 300m

Figure 5.7: Handled emergencies versus not handled emergencies

On Figure 5.8, we show the results of the same two experiments but with regards to the average time to reach a person. The x-axis corresponds to what radius in the particular experiment. The green bar represents the experiment with radius 150m, while the red bar shows the result from the experiment with radius 300m. The diﬀerence between the two cases is noticeable. When the radius of the system is smaller, the time to reach a target person drops significantly. In our experiment, the time to reach a person is ≈ 90s with radius 150m and ≈ 180s with radius 300m respectively.

Figure 5.8: Average time to reach target depending on radius of MCS system

We can conclude that the bigger the radius, the better in terms of the number of people that would become active participants in the mobile crowdsensing network. On the other hand, the bigger radius leads to also longer time to reach the target in need. 48 CHAPTER 5. RESULTS AND DISCUSSION

5.2.7 Discussions The designed simulation is a powerful tool that helps explore the system’s parameters and how they aﬀect the properties of interest. People designing a crowdsensing platform can use the simulation to check if the system would produce the desired results. Through the conducted experiments, we can summarise our ﬁndings:

1. Density aﬀects the number of positive responses, but not the time to reach the target.

2. Random distribution of agents generally performs better than clustered distribution.

3. Diﬀerent means of transportation decrease the time to reach the target agent.

4. The higher the amount of trust in the network, the fewer members it needs.

5. After we reach density above 1000 p/km2, adding more people does not increase the number of active participants.

6. Bigger radius increases the chances of having a person to react to an emergency but also increases the time need to reach a person in need. Chapter 6

Conclusion and Future Work

In the ﬁnal chapter of this thesis, we present a summary of the content and provide possible extensions of the smartwatch application. Also, we describe other devices suitable for integration with CrowdS. Finally, we propose how to enhance the simulation further to suit particular use-cases.

6.1 Conclusion

In this work, we have considered how technology can help in detecting emergencies on time. On the one hand, wearable devices with their sensors provide an enormous amount of data that is useful in identifying unexpected behaviour or events. On the other hand, connecting those devices is of crucial importance to make use of all the information they gather. Mobile crowdsensing technology becomes the glue between people and sensors. It is becoming much more accessible, and ubiquitous thanks to all the sensors placed everywhere. We based our work on existing crowdsensing system - CrowdS. We created a smartwatch application that utilises the device’s sensors to detect abnormal events. We explored two approaches for integrating the smartwatch with CrowdS platform. First, we explored direct connection through the Internet, and then we experimented with connecting the smartwatch application to a smartphone via Bluetooth. Both approaches have advantages and drawbacks, which we discussed and summarised in this research. We have provided analysis about different parameters that affect the properties of a mobile crowdsensing system for detecting alarming situations. For example, the coverage area of such a system can affect the density of people within that area. In turn, the density affects the number of participants in the crowdsensing network. Transportation methods used by people and the prob-

49 50 CHAPTER 6. CONCLUSION AND FUTURE WORK

ability of being an active participant can also aﬀect the time to reach a person in need. We have built a simulation in order to test how these above-mention properties aﬀect the system. The simulation provides an easy and fast way of observing changes in the crowdsensing platform performance.

6.2 Future work

6.2.1 Smartwatch application

Enhance fall detection model Newest commodity smartwatches1,2 support fall detection built-in. Utilising the watch’s API would give a more reliable model for fall detection. For devices that do not support fall detection, integrating an already tested and developed model is a better approach rather than building it from scratch. Multiple papers describe such models and would be a great extension of the existing master thesis (Ngu et al. 2017; Mauldin et al. 2018; Khojasteh et al. 2018; Yacchirema et al. 2018; Putra et al. 2018; Lu et al. 2019).

Add other types of alarming situations Following the discussion on the fall detection model, it would be interesting to extend the smartwatch application by adding diﬀerent types of alarming situations. For instance, dangerous path detection could be added by using the microphone and light sensors of the device. Another example is using the heart rate and breathing measure for detecting a heart attack.

Add proper UI and voice commands Our primary focus has been showing how the smartwatch can be integrated with CrowdS platform. We have used the most simple UI possible - a single button that mimics the emergence of an alarming situation. Thus providing a user interface following the best practices in the ﬁeld of wearables development is another possible future direction. Due to their small size, wearables often use voice commands to perform various tasks. Voice to text functional- ity is suitable for creating a registration in CrowdS platform instead of typing everything on the limited screen space of the device.

1Apple Watch fall detection: https://support.apple.com/en-us/HT208944 2Galaxy Watch fall detection: https://www.digitaltrends.com/mobile/ samsung-galaxy-watch-3-hand-gestures-fall-detection/ CHAPTER 6. CONCLUSION AND FUTURE WORK 51

6.2.2 CrowdS platform

Integration with Nectarine’s platform We have described Nectarine’s solution in Section 3.6. The platform closely relates to what this master thesis is trying to achieve - provide a system that detects dangerous situations and allows a timely reaction. We have enabled CrowdS to support Bluetooth integration and proven this is a viable option for communication with wearables devices (Section 3.4). As a starting point, Nectarine’s wristband alarm button could be used to broadcast alarm events. When the wearer presses the manual button, the wristband broadcasts those events, and any device that supports the right Bluetooth requirements can lis- ten to them. We have extended the CrowdS mobile application to support Bluetooth communication. After CrowdS catches the broadcasted events, the normal ﬂow of the crowdsensing platform can continue. The manual press of the button would simulate that an alarming situation has occurred and the wristband wearer needs some assistance. Another possibility for integrating the two platforms is to utilise the wristband, the receiver node, and the cloud platform. The receiver node could be taken outside (due to its internal battery) together with the wristband. The receiver node could send the processed events both to Nectarine’s cloud platform (which would require more custom-build adaptations) and to either the CrowdS mobile application or even directly to the CrowdS server. The integration possibilities have not been thoroughly discussed with Nec- tarine Health and are in no way considered from a practical point of view. The goal is to discuss how the extension of the CrowdS mobile application could enable the integration of diﬀerent wearable devices that support either Blue- tooth or have a stable Internet connection.

Build a map that shows the shortest path to a person in need CrowdS smartphone application can provide a map to the person, volunteer to help, which depicts the shortest path to the person in need. Such an extension would make the software easier to use from the side of the volunteer. It could also improve the time to reach a risky situation as the location of where the situation has happened will be displayed immediately. 52 CHAPTER 6. CONCLUSION AND FUTURE WORK

6.2.3 Simulation

Build simulation using GAMA’s cartography support GAMA platform allows usage of shapeﬁle format. The format represents a geospatial vector data format for a geographic information system (GIS) software. Such a model can tremendously improve the simulation with particular characteristics. For instance, it can visualise every pathway with the exact path length in a park. Agents on the simulation can be restricted to use only the dedicated paths. Such an implementation allows the creation of a much more realistic simulation.

6.2.4 Ethics

Improve security and privacy To be successful, MCS require a large number of participants. The current implementation of CrowdS does not follow best practices in data security and privacy protection. In order to install and use CrowdS as a real-life system, all participants need to trust the system fully. Generally, there is a lack of incentive to join mobile crowdsensing platforms. "Effective incentive-compatible mechanism is of significant importance to elicit the private information of device owners, and motivate them to offer their communication, computing, and storage resources for performing sensing tasks." (Z. Zhou et al. 2018). Part of this mechanism is the guarantee that the participant’s data is safe and securely stored according to security and privacy policy recommendations.

6.2.5 Discover opinions regarding participation in risk detection system

Conduct interviews with people Performing interviews is crucial to discovering how people feel about partici- pating in a risk detection system. Such work would give detailed information about the probability of participation, what types of transportation would the users use, which area do they think is the right place for running a pilot. The results from the interviews could be applied in the simulation to produce a more accurate model of the mobile crowdsensing system. Bibliography

[1] V. Granfors et al. “CrowdS: Crowdsourcing with Smart Devices - Pro- Quest”. en. In: Proceedings on the International Conference on Internet Computing (ICOMP) (2018). url: https://search.proquest. com/openview/870db281ae5a5cb555b1b299611f9571/ 1 (visited on 04/13/2020). [2] Chunming Gao, Fanyu Kong, and Jindong Tan. “HealthAware: Tack- ling obesity with health aware smart phone systems”. In: 2009 IEEE International Conference on Robotics and Biomimetics (ROBIO). Dec. 2009, pp. 1549–1554. doi: 10.1109/ROBIO.2009.5420399. [3] Guanling Chen et al. “MPCS: Mobile-phone based patient compliance system for chronic illness care”. In: 2009 6th Annual International Mo- bile and Ubiquitous Systems: Networking Services, MobiQuitous. July 2009, pp. 1–7. doi: 10.4108/ICST.MOBIQUITOUS2009.6829. [4] Sasank Reddy et al. “Image browsing, processing, and clustering for participatory sensing: lessons from a DietSense prototype”. In: Pro- ceedings of the 4th workshop on Embedded networked sensors. EmNets ’07. Cork, Ireland: Association for Computing Machinery, June 2007, pp. 13–17. isbn: 978-1-59593-694-3. doi: 10 . 1145 / 1278972 . 1278975. url: https : / / doi . org / 10 . 1145 / 1278972 . 1278975 (visited on 06/16/2020). [5] Gurdit Singh et al. “Smart patrolling: An eﬃcient road surface monitoring using smartphone sensors and crowdsourcing”. en. In: Perva- sive and Mobile Computing 40 (Sept. 2017), pp. 71–88. issn: 1574- 1192. doi: 10 . 1016 / j . pmcj . 2017 . 06 . 002. url: http : / / www . sciencedirect . com / science / article / pii / S1574119216301262 (visited on 06/16/2020). [6] David Hasenfratz et al. “Participatory Air Pollution Monitoring Using Smartphones”. en. In: (Apr. 2012), p. 5.

53 54 BIBLIOGRAPHY

[7] Viktoriya Kutsarova. Extended CrowdS. original-date: 2020-08-17T12:24:46Z. Aug. 2020. url: https://github.com/viktoriya-kutsarova/ extended-crowds (visited on 08/17/2020). [8] Viktoriya Kutsarova. Smartwatch application for managing risky situations. original-date: 2020-04-24T13:26:07Z. Aug. 2020. url: https: //github.com/viktoriya-kutsarova/risk-situation- detection (visited on 08/17/2020). [9] Ville Granfors. Server Design to Ensure Quality and Fairness in Mobile Crowdsourcing. eng. 2019. url: http://urn.kb.se/resolve? urn=urn:nbn:se:kth:diva-247622 (visited on 08/08/2020). [10] Definition of risk. url: https://www.oxfordlearnersdictionaries. com/definition/english/risk_1 (visited on 04/14/2020). [11] Joel Shurkin. New Technology Could Better Detect Dangerous Mate- rials At US Ports. en. Library Catalog: www.insidescience.org. Apr. 2015. url: https : / / www . insidescience . org / news / new-technology-could-better-detect-dangerous- materials-us-ports (visited on 04/14/2020). [12] Simulation technology and financial crisis. en. Library Catalog: www.finextra.com. Nov. 2009. url: https://www.finextra.com/newsarticle/ 20809/simulation-technology- can- help- prevent- financial-crises---ec (visited on 04/14/2020). [13] Lukasz Piwek et al. “The Rise of Consumer Health Wearables: Promises and Barriers”. en. In: PLOS Medicine 13.2 (Feb. 2016). Publisher: Pub- lic Library of Science, e1001953. issn: 1549-1676. doi: 10.1371/ journal.pmed.1001953. url: https://journals.plos. org / plosmedicine / article ? id = 10 . 1371 / journal . pmed.1001953 (visited on 07/12/2020). [14] Elizabeth Woyke. These Wearables Detect Health Issues Before They Happen. en. Library Catalog: www.technologyreview.com. Nov. 2016. url: https://www.technologyreview.com/2016/11/ 30/6210/these-wearables-detect-health-issues- before-they-happen/ (visited on 04/14/2020). [15] Tao Xu, Yun Zhou, and Jing Zhu. “New Advances and Challenges of Fall Detection Systems: A Survey”. en. In: Applied Sciences 8.3 (Mar. 2018), p. 418. doi: 10.3390/app8030418. url: https://www. mdpi.com/2076-3417/8/3/418 (visited on 02/21/2020). BIBLIOGRAPHY 55

[16] Thomas Vilarinho et al. “A Combined Smartphone and Smartwatch Fall Detection System”. en. In: 2015 IEEE International Conference on Computer and Information Technology; Ubiquitous Computing and Communications; Dependable, Autonomic and Secure Computing; Per- vasive Intelligence and Computing. LIVERPOOL, United Kingdom: IEEE, Oct. 2015, pp. 1443–1448. isbn: 978-1-5090-0154-5. doi: 10. 1109/CIT/IUCC/DASC/PICOM.2015.216. url: http:// ieeexplore . ieee . org / document / 7363260/ (visited on 03/03/2020). [17] Hoa Nguyen et al. Detecting Falls Using a Wearable Accelerometer Mo- tion Sensor | Proceedings of the 14th EAI International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services. Nov. 2017. url: https://dl.acm.org/doi/abs/10.1145/ 3144457.3144484 (visited on 02/27/2020). [18] Anne Ngu et al. “Fall Detection Using Smartwatch Sensor Data with Accessor Architecture”. en. In: Smart Health. Ed. by Hsinchun Chen et al. Lecture Notes in Computer Science. Cham: Springer International Publishing, 2017, pp. 81–93. isbn: 978-3-319-67964-8. doi: 10.1007/ 978-3-319-67964-8_8. [19] Samad Barri Khojasteh et al. “Improving Fall Detection Using an On- Wrist Wearable Accelerometer”. en. In: Sensors 18.5 (May 2018), p. 1350. doi: 10.3390/s18051350. url: https://www.mdpi.com/ 1424-8220/18/5/1350 (visited on 02/21/2020). [20] Diana Yacchirema et al. “Fall detection system for elderly people using IoT and Big Data”. en. In: Procedia Computer Science. The 9th Inter- national Conference on Ambient Systems, Networks and Technologies (ANT 2018) / The 8th International Conference on Sustainable Energy Information Technology (SEIT-2018) / Aﬃliated Workshops 130 (Jan. 2018), pp. 603–610. issn: 1877-0509. doi: 10.1016/j.procs. 2018.04.110. url: http://www.sciencedirect.com/ science / article / pii / S1877050918304721 (visited on 02/21/2020). [21] Eduardo Casilari and Miguel A. Oviedo-Jiménez. “Automatic Fall De- tection System Based on the Combined Use of a Smartphone and a Smartwatch”. en. In: PLOS ONE 10.11 (Nov. 2015). Ed. by Antony Bayer, e0140929. issn: 1932-6203. doi: 10.1371/journal.pone. 0140929. url: http://dx.plos.org/10.1371/journal. pone.0140929 (visited on 03/03/2020). 56 BIBLIOGRAPHY

[22] Yuxi Wang, Kaishun Wu, and Lionel M. Ni. “WiFall: Device-Free Fall Detection by Wireless Networks”. In: IEEE Transactions on Mobile Computing 16.2 (Feb. 2017). Conference Name: IEEE Transactions on Mobile Computing, pp. 581–594. issn: 1558-0660. doi: 10.1109/ TMC.2016.2557792. [23] Sameera Palipana et al. “FallDeFi: Ubiquitous Fall Detection using Com- modity Wi-Fi Devices”. In: Proceedings of the ACM on Interactive, Mo- bile, Wearable and Ubiquitous Technologies 1.4 (Jan. 2018), 155:1– 155:25. doi: 10.1145/3161183. url: https://doi.org/10. 1145/3161183 (visited on 02/21/2020). [24] I. Putu Edy Suardiyana Putra et al. “An Event-Triggered Machine Learn- ing Approach for Accelerometer-Based Fall Detection”. en. In: Sensors 18.1 (Jan. 2018), p. 20. doi: 10.3390/s18010020. url: https: //www.mdpi.com/1424-8220/18/1/20 (visited on 02/21/2020). [25] Xu Tao and Zhou Yun. “Fall prediction based on biomechanics equilib- rium using Kinect”. en. In: International Journal of Distributed Sensor Networks 13.4 (Apr. 2017), p. 1550147717703257. issn: 1550-1477. doi: 10 . 1177 / 1550147717703257. url: https : / / doi . org/10.1177/1550147717703257 (visited on 02/21/2020). [26] Na Lu et al. “Deep Learning for Fall Detection: Three-Dimensional CNN Combined With LSTM on Video Kinematic Data”. In: IEEE Jour- nal of Biomedical and Health Informatics 23.1 (Jan. 2019), pp. 314– 323. issn: 2168-2208. doi: 10.1109/JBHI.2018.2808281. [27] Peter Düking et al. “Integrated Framework of Load Monitoring by a Combination of Smartphone Applications, Wearables and Point-of-Care Testing Provides Feedback that Allows Individual Responsive Adjust- ments to Activities of Daily Living”. en. In: Sensors 18.5 (May 2018). Number: 5 Publisher: Multidisciplinary Digital Publishing Institute, p. 1632. doi: 10.3390/s18051632. url: https://www.mdpi.com/ 1424-8220/18/5/1632 (visited on 05/05/2020). [28] Galaxy Watch. en-US. Library Catalog: www.samsung.com. url: https: //www.samsung.com/us/mobile/wearables/smartwatches/ galaxy-watch--46mm--silver--lte--sm-r805uzsaxar/ (visited on 06/22/2020). [29] Fitbit Oﬃcial Site. en-EU. Library Catalog: www.ﬁtbit.com. url: https: //www.fitbit.com/eu/home (visited on 07/12/2020). BIBLIOGRAPHY 57

[30] Smart patches. en-US. Library Catalog: www.wearable-technologies.com. url: https://www.wearable-technologies.com/tag/ smart-patches/ (visited on 07/12/2020). [31] Fall Detector Pendant. en-GB. Library Catalog: www.lifeline24.co.uk. url: https://www.lifeline24.co.uk/fall-detector- pendant/ (visited on 07/12/2020). [32] Rainer Lutze and Klemens Waldhör. “A Smartwatch Software Archi- tecture for Health Hazard Handling for Elderly People”. In: 2015 Inter- national Conference on Healthcare Informatics. ISSN: null. Oct. 2015, pp. 356–361. doi: 10.1109/ICHI.2015.50. [33] J. Heikenfeld et al. “Wearable Sensors: Modalities, Challenges, and Prospects”. In: Lab on a chip 18.2 (Jan. 2018), pp. 217–248. issn: 1473- 0197. doi: 10.1039/c7lc00914c. url: https://www.ncbi. nlm . nih . gov / pmc / articles / PMC5771841/ (visited on 07/13/2020). [34] MD Staﬀ. 3 Emerging Applications for Sensor Technology in Wearable Medical Devices. en-us. Library Catalog: www.machinedesign.com. June 2019. url: https://www.machinedesign.com/mechanical- motion - systems / article / 21837889 / 3 - emerging - applications-for-sensor-technology-in-wearable- medical-devices (visited on 05/05/2020). [35] Tom Oswald and Mi Zhang. Wearable Technology Could Help Detect Health Risks, Depression. en-US. Library Catalog: research.msu.edu. May 2016. url: https://research.msu.edu/wearable- technology-could-help-detect-health-risks-depression/ (visited on 05/05/2020). [36] Becca Caddy. 5 sensor technologies that are set to break out in wearables. en. Library Catalog: www.wareable.com Section: Wearables. Feb. 2019. url: https://www.wareable.com/wearable-tech/ 5 - wearable - sensor - technologies - incoming - 7026 (visited on 05/05/2020). [37] Jeﬀ Howe. “The Rise of Crowdsourcing”. en. In: 14 (2006), p. 5. url: https://www.wired.com/2006/06/crowds/ (visited on 03/18/2020). 58 BIBLIOGRAPHY

[38] Jacquelyn White. What Is Crowdsourcing and How Does It Work? Def- inition and Example. en-us. Library Catalog: www.thestreet.com. July 2019. url: https : / / www . thestreet . com / personal - finance/education/what-is-crowdsourcing-15026002 (visited on 04/09/2020). [39] Jurairat Phuttharak and Seng W. Loke. “A Review of Mobile Crowd- sourcing Architectures and Challenges: Toward Crowd-Empowered Internet- of-Things”. In: IEEE Access 7 (2019). Conference Name: IEEE Access, pp. 304–324. issn: 2169-3536. doi: 10 . 1109 / ACCESS . 2018 . 2885353. [40] Jeﬀ Howe. Crowdsourcing: Why the Power of the Crowd Is Driving the Future of Business. English. New York: Currency, Sept. 2009. isbn: 978-0-307-39621-1. [41] Kathryn Kearns. 9 Great Examples of Crowdsourcing in the Age of Empowered Consumers. en-US. Library Catalog: tweakyourbiz.com. July 2015. url: https://tweakyourbiz.com/marketing/ 9-great-examples-crowdsourcing-age-empowered- consumers (visited on 07/13/2020). [42] Virginia Pilloni. “How Data Will Transform Industrial Processes: Crowd- sensing, Crowdsourcing and Big Data as Pillars of Industry 4.0”. en. In: Future Internet 10.3 (Mar. 2018). Number: 3 Publisher: Multidisci- plinary Digital Publishing Institute, p. 24. doi: 10.3390/fi10030024. url: https://www.mdpi.com/1999-5903/10/3/24 (visited on 04/09/2020). [43] Raghu K. Ganti, Fan Ye, and Hui Lei. “Mobile crowdsensing: current state and future challenges”. In: IEEE Communications Magazine 49.11 (Nov. 2011). Conference Name: IEEE Communications Magazine, pp. 32– 39. issn: 1558-1896. doi: 10.1109/MCOM.2011.6069707. [44] Andrea Capponi et al. “A Survey on Mobile Crowdsensing Systems: Challenges, Solutions and Opportunities”. In: IEEE Communications Surveys & Tutorials 21 (Apr. 2019), pp. 2419–2465. doi: 10.1109/ COMST.2019.2914030. [45] Dmytro Karamshuk et al. “Geo-spotting: mining online location-based services for optimal retail store placement”. In: Proceedings of the 19th ACM SIGKDD international conference on Knowledge discovery and data mining. KDD ’13. Chicago, Illinois, USA: Association for Com- puting Machinery, Aug. 2013, pp. 793–801. isbn: 978-1-4503-2174-7. BIBLIOGRAPHY 59

doi: 10.1145/2487575.2487616. url: https://doi.org/ 10.1145/2487575.2487616 (visited on 07/14/2020). [46] Lei Shu et al. “When Mobile Crowd Sensing Meets Traditional In- dustry”. In: IEEE Access 5 (2017). Conference Name: IEEE Access, pp. 15300–15307. issn: 2169-3536. doi: 10.1109/ACCESS.2017. 2657820. [47] Bin Guo et al. “From Participatory Sensing to Mobile Crowd Sens- ing”. In: 2014 IEEE International Conference on Pervasive Computing and Communication Workshops, PERCOM WORKSHOPS 2014 (Jan. 2014). doi: 10.1109/PerComW.2014.6815273. [48] Jia Peng et al. “When data contributors meet multiple crowdsourcers: Bilateral competition in mobile crowdsourcing”. en. In: Computer Net- works 95 (Feb. 2016), pp. 1–14. issn: 1389-1286. doi: 10.1016/j. comnet.2015.11.027. url: http://www.sciencedirect. com/science/article/pii/S1389128615004764 (visited on 07/14/2020). [49] Vijay Sivaraman et al. “HazeWatch: A participatory sensor system for monitoring air pollution in Sydney”. In: 38th Annual IEEE Conference on Local Computer Networks - Workshops. Oct. 2013, pp. 56–64. doi: 10.1109/LCNW.2013.6758498. [50] Liang Liu et al. “Third-Eye: A Mobilephone-Enabled Crowdsensing System for Air Quality Monitoring”. In: Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies 2.1 (Mar. 2018), 20:1–20:26. doi: 10 . 1145 / 3191752. url: https : / / doi.org/10.1145/3191752 (visited on 07/15/2020). [51] Dario Bonino et al. “WasteApp: Smarter waste recycling for smart citizens”. In: 2016 International Multidisciplinary Conference on Com- puter and Energy Science (SpliTech). July 2016, pp. 1–6. doi: 10 . 1109/SpliTech.2016.7555951. [52] Djallel Eddine Boubiche et al. “Mobile crowd sensing – Taxonomy, applications, challenges, and solutions”. en. In: Computers in Human Behavior 101 (Dec. 2019), pp. 352–370. issn: 0747-5632. doi: 10. 1016/j.chb.2018.10.028. url: http://www.sciencedirect. com/science/article/pii/S0747563218305181 (visited on 07/13/2020). 60 BIBLIOGRAPHY

[53] Andrea Ghermandi and Michael Sinclair. “Passive crowdsourcing of social media in environmental research: A systematic map”. en. In: Global Environmental Change 55 (Mar. 2019), pp. 36–47. issn: 0959-3780. doi: 10 . 1016 / j . gloenvcha . 2019 . 02 . 003. url: http : / / www . sciencedirect . com / science / article / pii / S0959378018309920 (visited on 04/13/2020). [54] Linus Bengtsson et al. “Improved Response to Disasters and Outbreaks by Tracking Population Movements with Mobile Phone Network Data: A Post-Earthquake Geospatial Study in Haiti”. en. In: PLOS Medicine 8.8 (Aug. 2011). Publisher: Public Library of Science, e1001083. issn: 1549-1676. doi: 10.1371/journal.pmed.1001083. url: https: / / journals . plos . org / plosmedicine / article ? id = 10.1371/journal.pmed.1001083 (visited on 07/15/2020). [55] Dong-Anh Nguyen et al. “On Critical Event Observability Using Social Networks: A Disaster Monitoring Perspective”. In: 2014 IEEE Military Communications Conference. ISSN: 2155-7586. Oct. 2014, pp. 1633– 1638. doi: 10.1109/MILCOM.2014.268. [56] Sunyoung Kim et al. “Creek watch: pairing usefulness and usability for successful citizen science”. In: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI ’11. Vancouver, BC, Canada: Association for Computing Machinery, May 2011, pp. 2125– 2134. isbn: 978-1-4503-0228-9. doi: 10.1145/1978942.1979251. url: https://doi.org/10.1145/1978942.1979251 (visited on 07/15/2020). [57] Thomas Ludwig et al. “CrowdMonitor: Mobile Crowd Sensing for As- sessing Physical and Digital Activities of Citizens during Emergen- cies”. In: Proceedings of the 33rd Annual ACM Conference on Hu- man Factors in Computing Systems. CHI ’15. Seoul, Republic of Ko- rea: Association for Computing Machinery, Apr. 2015, pp. 4083–4092. isbn: 978-1-4503-3145-6. doi: 10 . 1145 / 2702123 . 2702265. url: https://doi.org/10.1145/2702123.2702265 (visited on 07/15/2020). [58] Neil M. Ferguson et al. “Strategies for mitigating an inﬂuenza pan- demic”. en. In: Nature 442.7101 (July 2006). Number: 7101 Publisher: Nature Publishing Group, pp. 448–452. issn: 1476-4687. doi: 10 . 1038 / nature04795. url: https : / / www . nature . com / articles/nature04795/ (visited on 07/15/2020). BIBLIOGRAPHY 61

[59] Amy Wesolowski et al. “Quantifying the Impact of Human Mobility on Malaria”. en. In: Science 338.6104 (Oct. 2012). Publisher: American Association for the Advancement of Science Section: Report, pp. 267– 270. issn: 0036-8075, 1095-9203. doi: 10.1126/science.1223467. url: https://science.sciencemag.org/content/338/ 6104/267 (visited on 07/15/2020). [60] Peter Haddawy et al. “Situation awareness in crowdsensing for disease surveillance in crisis situations”. In: Proceedings of the Seventh Inter- national Conference on Information and Communication Technologies and Development. ICTD ’15. Singapore, Singapore: Association for Computing Machinery, May 2015, pp. 1–5. isbn: 978-1-4503-3163-0. doi: 10.1145/2737856.2737879. url: https://doi.org/ 10.1145/2737856.2737879 (visited on 05/06/2020). [61] Mashﬁqui Rabbi et al. “Passive and In-Situ assessment of mental and physical well-being using mobile sensors”. In: Proceedings of the 13th international conference on Ubiquitous computing. UbiComp ’11. Bei- jing, China: Association for Computing Machinery, Sept. 2011, pp. 385– 394. isbn: 978-1-4503-0630-0. doi: 10.1145/2030112.2030164. url: https://doi.org/10.1145/2030112.2030164 (visited on 07/15/2020). [62] Yujie Dong et al. “A New Method for Measuring Meal Intake in Hu- mans via Automated Wrist Motion Tracking”. en. In: Applied Psychophys- iology and Biofeedback 37.3 (Sept. 2012), pp. 205–215. issn: 1090- 0586, 1573-3270. doi: 10.1007/s10484- 012- 9194- 1. url: http://link.springer.com/10.1007/s10484- 012- 9194-1 (visited on 07/15/2020). [63] Yohan Chon et al. “Understanding the coverage and scalability of place- centric crowdsensing”. In: Proceedings of the 2013 ACM international joint conference on Pervasive and ubiquitous computing. UbiComp ’13. Zurich, Switzerland: Association for Computing Machinery, Sept. 2013, pp. 3–12. isbn: 978-1-4503-1770-2. doi: 10.1145/2493432.2493498. url: https://doi.org/10.1145/2493432.2493498 (visited on 07/15/2020). [64] Kiran K. Rachuri et al. “EmotionSense: a mobile phones based adaptive platform for experimental social psychology research”. In: Proceed- ings of the 12th ACM international conference on Ubiquitous computing. UbiComp ’10. Copenhagen, Denmark: Association for Computing Machinery, Sept. 2010, pp. 281–290. isbn: 978-1-60558-843-8. doi: 62 BIBLIOGRAPHY

10.1145/1864349.1864393. url: https://doi.org/10. 1145/1864349.1864393 (visited on 07/15/2020). [65] Bluetooth overview. en. Library Catalog: developer.android.com. url: https : / / developer . android . com / guide / topics / connectivity/bluetooth (visited on 06/23/2020). [66] Understanding Bluetooth Range. en-US. Library Catalog: www.bluetooth.com. url: https://www.bluetooth.com/learn-about-bluetooth/ bluetooth-technology/range/ (visited on 06/23/2020). [67] Mohammad Ashfak Habib et al. Smartphone-Based Solutions for Fall Detection and Prevention: Challenges and Open Issues. Apr. 2014. url: https://www.mdpi.com/1424-8220/14/4/7181 (visited on 02/27/2020). [68] Eduardo Casilari and Jose A.Santoyo-Ramón. UMAFall: Fall Detection Dataset (Universidad de Malaga). June 2018. doi: 10.6084/m9. figshare.4214283.v7. url: https://figshare.com/ articles/UMA_ADL_FALL_Dataset_zip/4214283 (visited on 01/22/2019). [69] Tizen Platform. url: https : / / www . tizen . org/ (visited on 06/22/2020). [70] Tizen Web Application. url: https://docs.tizen.org/application/ web/index (visited on 06/22/2020). [71] DeviceMotion API. url: https://docs.tizen.org/application/ web/api/4.0/device_ api/mobile/tizen/cordova/ device-motion.html (visited on 06/22/2020). [72] Geolocation API Speciﬁcation. url: https : / / docs . tizen . org/application/web/guides/w3c/location/geolocation/ (visited on 06/22/2020). [73] Fetch API. en. Library Catalog: developer.mozilla.org. url: https: / / developer . mozilla . org / en - US / docs / Web / API / Fetch_API (visited on 07/03/2020). [74] Reza Rawassizadeh, Blaine A. Price, and Marian Petre. “Wearables: has the age of smartwatches ﬁnally arrived?” en. In: Communications of the ACM 58.1 (Dec. 2014), pp. 45–47. issn: 00010782. doi: 10. 1145 / 2629633. url: http : / / dl . acm . org / citation . cfm?doid=2688498.2629633 (visited on 07/07/2020). BIBLIOGRAPHY 63

[75] Nectarine Remote Care. en-US. Library Catalog: nectarinehealth.com. url: https://nectarinehealth.com/ (visited on 07/23/2020). [76] GAMA-Platform · GAMA. Library Catalog: gama-platform.github.io. url: https : / / gama - platform . github . io/ (visited on 06/17/2020). [77] James Williamson et al. “Data sensing and analysis: Challenges for wearables”. In: The 20th Asia and South Paciﬁc Design Automation Conference. ISSN: 2153-697X. Jan. 2015, pp. 136–141. doi: 10.1109/ ASPDAC.2015.7058994. [78] Taylor R. Mauldin et al. “SmartFall: A Smartwatch-Based Fall Detec- tion System Using Deep Learning”. en. In: Sensors 18.10 (Oct. 2018). Number: 10 Publisher: Multidisciplinary Digital Publishing Institute, p. 3363. doi: 10.3390/s18103363. url: https://www.mdpi. com/1424-8220/18/10/3363 (visited on 07/26/2020). [79] Zhenyu Zhou et al. “Robust Mobile Crowd Sensing: When Deep Learn- ing Meets Edge Computing”. In: IEEE Network 32.4 (July 2018). Con- ference Name: IEEE Network, pp. 54–60. issn: 1558-156X. doi: 10. 1109/MNET.2018.1700442. Appendix A

Calculating the number of visitors and density for simulation

In this appendix, we describe in detail how we reached the numbers used in our simulation. For our simulation, we were inspired by two scenarios - city park and suburban area. We calculated the number of people visiting a park during peak and off-peak hours using the number of visitors per year in Royal Park in the United Kingdom from 20141. We have taken the parks with more than 8 million people per year which are Kensington G’dens (8.6 million), Hyde Park (9.3 million), Green Park (10.9 million) and St. James’s Park (13 million). The average value for those parks is 10 million per year. To get the daily visits of people, we divide the 10 million by 12 and then by 30. This gives us approximately 830 000 people per month and 27 000 per day. The numbers vary significantly based on factors such as season, a specific day of the week, the weather outside. We can exclude the hours between 10 p.m. and 8 a.m. as most of the parks are not even open. Even if they are, there are very few people. We are left with 14 active hours (from 8 a.m. to 10 p.m.), which gives us around 2 000 people per hour. On Figure A.1 and Figure A.2 below, we have displayed the popular times for visiting Hyde Park depending on the day of the week and particular hours. Thus we roughly estimate that during peak hours approximately 600 people are in the park. In off-peak hours there could be as little as 100 people. We can now calculate the density of people. During peak hour, it is estimated to 400 p/km2, while during off-peak hours it is approximately 67

1Number of visitors to Royal Parks in the United Kingdom (UK) in 2014, by park(in millions): https://www.statista.com/statistics/422397/ number-of-visitors-in-royal-parks-uk/

64 APPENDIX A. CALCULATING THE NUMBER OF VISITORS AND DENSITY FOR SIMULATION 65

Figure A.1: Popular times Figure A.2: Popular times in Hyde Park during Sunday. in Hyde Park during Tuesday. Source: Google Maps Source: Google Maps p/km2.

TRITA-EECS-EX-2020:597