European Project Nº: FP7-614154 Brazilian Project Nº: CNPq-490084/2013-3

Project Acronym: RESCUER

Project Title: Reliable and Smart Crowdsourcing Solution for Emergency and Crisis Management

Instrument: Collaborative Project

European Call Identifier: FP7-ICT-2013-EU-Brazil Brazilian Call Identifier: MCTI/CNPq 13/2012

Deliverable D1.3.2 Communication Infrastructure 2

Due date of deliverable: PM20

Actual submission date: October 12, 2015

Start date of the project: Europe: October 1, 2013 | Brazil: February 1, 2014 Duration: 30 months Organization name of lead contractor for this deliverable: DFKI

Dissemination level PU Public PP Restricted to other program participants (including Commission Services) RE Restricted to a group specified by the consortium (including Commission Services) CO Confidential, only for members of the consortium (including Commission Services)

2

Executive Summary Evaluation Model and General Evaluation Plan

This document presents deliverable D1.3.2 (Communication Infrastructure 2) of project FP7-

614154 | CNPq-490084/2013-3 (RESCUER), a collaborative project supported by the European Commission and MCTI/CNPq (Brazil). Full information on this project is available online at http://www.rescuer-project.org

Deliverable D1.3.2 provides the results of the second iteration of Task 1.3 (Communication Infrastructure). In this task, we develop the foundation for the communication between the users’ mobile phones and the command and control centre. We also research a AhHoc communication approach that enables mobile phones to exchange messages between each other and with the control centre while the fixed network infrastructure (i.e. cell phone towers) is temporarily unavailable.

This deliverable focuses on presenting RESCUER’s underlying communication infrastructure and the concept of the AdHoc approach. It also presents test results and a large-scale simulation of the latter.

List of Authors

Tobias Franke – DFKI George Kampis – DFKI

List of Internal Reviewers

Juan Torres – UPM (1st Version) Taslim Arif – Fraunhofer (1st Version) Vaninha Vieira – UFBA (1st Version) Jose Fernando Rodrigues Junior – USP (2nd Version) Dominik Magin – Fraunhofer (2nd Version) Karina Villela – Fraunhoger (2nd Version)

3

Contents

1. Introduction ..................................................................................................................................... 4

1.1. Purpose .................................................................................................................................... 4

1.2. Change Log .............................................................................................................................. 5

1.3. Partners’ Roles and Contributions .......................................................................................... 5

1.4. Document Overview ................................................................................................................ 5

2. Communication Infrastructure Overview ........................................................................................ 6

2.1. Communication under Normal Circumstances ....................................................................... 6

2.2. Communication without fixed Infrastructure ......................................................................... 8

3. AdHoc Communication .................................................................................................................. 10

3.1. AdHoc Principle ..................................................................................................................... 10

3.2. The RESCUER Approach to AdHoc Communication .............................................................. 11

3.2.1 The Basics ...................................................................................................................... 11

3.2.2 Details of the Methodology ........................................................................................... 17

3.2.3 Regarding Smartphone Operating Systems .................................................................. 19

3.3. Establishing Boundary Conditions ......................................................................................... 21

3.3.1 Device Type ................................................................................................................... 21

3.3.2 Message Size ................................................................................................................. 22

3.3.3 Packaging Strategy ........................................................................................................ 22

3.3.4 Distance between Devices ............................................................................................ 23

3.3.5 The Effects of Dense Crowds ......................................................................................... 24

3.3.6 Exchange Strategy ......................................................................................................... 24

3.3.7 Access Point Performance ............................................................................................. 25

3.3.8 Mode Switching Duration .............................................................................................. 25

3.4. Simulating the RESCUER AdHoc Approach ............................................................................ 25

3.4.1 Walking Model and Motion Data .................................................................................. 26

3.4.2 Simulation Runs and Parameter Sweeps....................................................................... 28

3.4.3 Comparison with Random Mode Switching .................................................................. 30

4. Conclusion ...................................................................................................................................... 32

References ............................................................................................................................................. 33

4

1. Introduction

RESCUER aims to develop an interoperable solution (the RESCUER Platform) that will support emergency and crisis management in command and control centres to quickly handle emergencies based on reliable and intelligent analysis of mobile crowdsourcing information mashed up with open data. In brief, the RESCUER Platform encompasses four main components:

1. Mobile Crowdsourcing Solution, which aims to support the communication between people at the incident place (eyewitnesses and operational forces) and people at the command and control centre.

2. Data Analysis Solutions, which use several algorithms to filter and process data obtained from the crowd in order to extract the relevant information.

3. Communication Infrastructure, which offers the required infrastructure (equipment and technology) in order to allow the information flowing among stakeholders.

4. Emergency Response Toolkit, which is a set of solutions that receive crowd sourced information and data analysis results in order to support command and control centres, e.g. by showing information in a clear manner using adequate visualization metaphors.

1.1. Purpose

The RESCUER project aims at developing a smart and interoperable computer-based solution for supporting emergency and crisis management, with a special focus on incidents in industrial areas and on large-scale events. The RESCUER solution will be composed of four main components, namely Mobile Crowdsourcing Solution, Data Analysis Solutions, Emergency Response Toolkit, and Communication Infrastructure.

This deliverable presents the communication infrastructure to support the information flow between the crowd and the command centre, which includes a message broker for connecting all system parts and a server for receiving data automatically gathered from the crowd via the Mobile Crowdsourcing Solution.

As network infrastructure tends to become unavailable during emergencies, this deliverable also presents an AdHoc networking approach, enabling message delivery during times of network outage.

5

1.2. Change Log

Table 1 summarizes the changes performed in this document after its last submission in January

31, 2015.

Table 1: Change log with regard to D1.3.1 (January 31, 2015)

Change Location Change Description Section 2.1: Communication under Normal Circumstances

• Inclusion of information on scalability

Chapter 3: AdHoc Communication

• Inclusion of Subsection 3.2.2: Details of the Methodology • Inclusion of Subsection 3.2.3: Regarding Smartphone

Operating System • Inclusion of Section 3.3: Establishing Boundary Conditions • Inclusion of Section 3.4: Simulating the RESCUER AdHoc

Approach Section 4: Conclusion • Update

1.3. Partners’ Roles and Contributions

DFKI was the only partner involved in this task and therefore responsible for setting up the server infrastructure used to receive and process crowd sourced sensor data. It furthermore developed the RESCUER AdHoc approach. The message broker system is only mentioned in this deliverable as it is part of the communication infrastructure, but it was developed within the scope of Task 1.5 (Integrated Platform Demonstrator) by the project partner Vomatec.

1.4. Document Overview

The remainder of this document is structured as follows:

• Chapter 2 provides an overview about the communication infrastructure of the RESCUER solution in both cases with normal network connectivity and without a fixed network infrastructure.

• Chapter 3 describes the RESCUER approach for communication without a fixed network infrastructure. It starts by giving a theoretical introduction of the concepts of standard AdHoc/Peer-to-Peer communication before highlighting the challenges the RESCUER solution poses. The second half of the chapter presents the RESCUER AdHoc approach including test and simulation results.

• Chapter 4 draws a conclusion about this deliverable and Task 1.3 in general.

6

2. Communication Infrastructure Overview

2.1. Communication under Normal Circumstances

Given the fact that the RESCUER system is comprised of many sub components which work together to accomplish the project’s goals, it is of utmost importance that they can communicate in an efficient manner. The current details of the inter-component communication are described in Deliverable 1.5.2 (Integrated Platform Demonstrator 2).

To avoid duplicate contents within the RESCUER deliverables, we will only shortly summarize the communication between the RESCUER components at this point. In order to allow for the greatest possible flexibility and maintainability, a hub-and-spoke pattern has been chosen. This means that there is one central component (the hub) that has a communication interface to every other component (the spokes). Consequently, components can be modified without the need to adapt each and every other component. Instead, there is only the need to update the central communication component.

Within RESCUER, this communication pattern is implemented by using a message broker system (namely RabbitMQ – www.rabbitmq.com). System components can exchange information by sending and receiving messages which are managed by the central message broker component. Message dispatching is managed via specific message topics. If, for example, the image analysis component is done with the analysis of an image, it can publish the resulting data as a message to a topic “analysedresult” – all components that need those results for their own computations, can obtain them by subscribing to this topic.

Within D1.3.2 DFKI was responsible for setting up the server infrastructure used to receive and process crowd sourced sensor data. Given that this server component is heavily coupled with the mobile crowd sensing component (part of the Mobile Crowd Sourcing Solution), because it deals with a continuous stream of sensor data, the communication between those two components is handled via a direct HTTP connection, without the involvement of the message broker. However, the facts that both components are part of the same sub system (Crowd Sensing) and are developed by the same partner and the fact that the Crowd Sensing component has a message broker based interface to be used by the other RESCUER sub systems (in order to control its behavior, i.e. start and stop Crowd Sensing sessions) mean that the requirement for maintainability and flexibility is still achieved.

Some functional aspects of the Crowd Sensing component have already been described in D2.2.2 (Mechanisms for Information Gathering 2), in Section 2.2: Streaming Sensor Data. In the following we therefore only highlight the facts relevant to the server and communication architecture which have not already been discussed within D2.2.2.

When creating the Crowd Sensing server infrastructure, the main challenge was to provide a solution which is able to deal with a very large amount of incoming sensor data. The setup currently used for RESCUER can deal with more than 10.000 people sending data simultaneously. From our previous experiences at large scale events, between one and five per cent of people within a crowd can be expected to run a smartphone app with safety related components (such as the RESCUER system) on their devices – this means that the current RESCUER system can cater to event scenarios with crowd sizes between 200.000 and 1.000.000 people. However, should there be a need for

7

equipping larger scenarios, the scalable architecture allows for a relatively easy expansion by adding more computing power to the cluster. The current RESCUER system should also be able to deal with most scenarios in industrial parks since a potential of 18.000 workers having the RESCUER app installed on their phones seems sufficient for common industrial parks.

Figure 1: Components of the Crowd Sensing server infrastructure Figure 1 illustrates the components of the Crowd Sensing server infrastructure. Their function is

as follows: • The Clients are the smartphones with the Mobile Crowd Sourcing solution installed on

them. During active Crowd Sensing sessions they send data in specific time intervals. • The Load-Balancer has the task of distributing the incoming HTTP POST requests evenly

over a cluster of web servers. It has been realized with HAProxy (www.haproxy.org) which is an event-driven, single process solution offering vast performance advantages at low memory footprints compared to using a web server like the popular Apache HTTP Server.

• The next layer in our server infrastructure is a cluster of Webservers that are tasked with receiving and processing the data sent by the smartphones. We chose Lighttpd (www.lighttpd.net), an event-based and lightweight software which is optimized for high performance environments. The incoming POST requests are forwarded to so-called input worker threads (implemented in Python), which take the data out of the HTTP POST body and forward it to the queue layer.

• The Queue serves as a buffer to make sure that no data is lost in case of bottlenecks in the speed of the database write operations. We decided to use Beanstalkd (http://kr.github.io/beanstalkd/) for this task as it is very lightweight offering a generic ASCII-based interface and is optimized for running time consuming tasks asynchronously. In contrast to other (more common) queue solutions, Beanstalkd offers the option to create binary logs on the server’s hard drive, which would allow the queue to resume its work after a system crash without the loss of data.

• The Database finally stores the data sent by the smartphones for later analysis like for example the crowd density computation. MongoDB (www.mongodb.org) was chosen as it currently is the leading No-SQL database which allows for an efficient storage of JSON based data. It furthermore allows the creation of clusters which provide the basis for fault tolerance and high availability. Finally, MongoDB offers the option to query the stored data based on its geographic location, which is a key requirement for analysing geographic data as it is required from the Crowd Sensing system. Storage worker threads (implemented in Python) receive the data from the queue and write it to the data base.

8

Once the crowd sensing data has arrived in the database, it is analysed and visualised in the form of a heat map. Since this process does not concern the communication part of the RESCUER system, it is not further described in this document. The interested reader may refer to [1][2][3][4].

2.2. Communication without fixed Infrastructure

Since the RESCUER System is geared towards the handling of emergencies, it needs to be able to deal with situations that are not common in everyday life. One of those situations is a complete failure of the communication infrastructure in a given region. Such outages of the cell phone network might be caused temporarily by an overload (e.g. when too many people are trying to make phone calls) or in the longer term by a destruction of parts of the infrastructure (e.g. through an explosion or earthquake).

In those cases traditional means of communication (like phone calls or SMS messages) cannot be used to reach the people located in the affected area. However, exactly these situations are the ones where communication is most crucial. For that reason RESCUER developed an opportunistic networking mechanism that will allow emergency forces to get in touch with people in areas where the communication infrastructure has failed.

RESCUER uses an AdHoc-like approach for this goal. This means that people’s smartphones build a spontaneous communication network by connecting themselves in a peer-to-peer fashion. Consequently, each device acts as a node in the network being able to send and receive data. Messages therefore “hop” from device to device until they reach their destination in the crowd. The border of such a spontaneous AdHoc-like network is formed by devices that still have connectivity to the internet. These devices have the task to receive messages from the RESCUER system and propagate them into the AdHoc network (and vice versa in the other direction) – they therefore serve as connections to the internet.

Please note, that the term “AdHoc“ has been used loosely in the scope of the RESCUER project because it best describes our approach. Strictly speaking, the system is more related to delay tolerant opportunistic networks, a sub category of AdHoc networks.

Due to the fact that the performance of an AdHoc network is considerably lower than that of a modern LTE cell phone network, it is clear that the amount of services that can be offered by the RESCUER Mobile Crowdsourcing Solution has to be reduced when using this means of communication. The reason for this is obvious: smartphones are not able to route large amounts of data from potentially thousands of devices in an efficient manner. As a consequence, it seems likely that Crowd Sensing (which requires constant streaming of data) will have to be disabled while the AdHoc communication is active. Furthermore, sending images and videos as parts of incident reports will have to be disabled as this kind of data is simply too large to be transported in an AdHoc fashion via smartphones. Imagine a scenario where only 20 people want to send a video which is 10 MB in size. This would result in the smartphones having to route 200 MB worth of extra data packages – a value that is much too large for commonly used devices.

Taking all of the above into consideration, it becomes clear that the main purpose of the RESCUER Mobile Crowdsourcing Solution is to facilitate text based communication between the crowd and the emergency staff during times when the AdHoc system is enabled. However, looking at the current state of the art in disaster management, this will be a huge advancement already. Images

9

and videos can be sent by the smartphones once normal connectivity has been restored. Those multimedia contents will then amend incident reports received by the command and control centre during the network outage.

10

3. AdHoc Communication

3.1. AdHoc Principle

Figure 2: Principle of AdHoc networking using mobile devices

As it was already mentioned in Section 2.2 of this deliverable, AdHoc networks are a way for devices to communicate amongst each other without a central infrastructure (like a cell phone tower network or WiFi access points) being in place. Therefore, the devices form a peer-to-peer network where data is being transported via “hops” from device to device until it reaches its destination. Figure 2 illustrates this principle in a rough sketch.

The obvious way to implement such a communication system would be to use WiFi AdHoc (since most smartphones have a WiFi adapter) which works on the transport layer of the TCP/IP stack. Usually, this layer only forwards data packets received by the network adapter to the layers which are higher up in the hierarchy, if those data packets are addressed to that very client. Using the WiFi AdHoc approach however, the WiFi adapter is put into the so called “promiscuous mode” which causes the network adapter to pass all data packets to the operating system regardless of their recipient’s address. This is the basis for turning a device into a communication node which can route data packets to other devices in its vicinity.

In the scope of RESCUER however, this approach is not applicable as the Mobile Crowdsourcing Solution will have to run on ordinary off-the-shelf smartphones whose WiFi adapters cannot be put into the promiscuous mode. This would only be possible through major modifications of the smartphones (like jailbreaking or installing a modified firmware), which is unfeasible, as the general public cannot be asked to perform such an operation before being able to use the RESCUER system.

In [5] several other shortcomings of smartphones with respect to AdHoc networking in emergency scenarios are listed. The authors come to the conclusion that the opportunistic

11

networking approach seems to be the most promising way to achieve an AdHoc-like communication using off-the-shelf smartphones. [6] comes to the same conclusion and presents a proof of concept for an opportunistic networking approach for unmodified smartphones. The idea behind this approach is that some of the smartphones in a crowd could turn into access points, while the smartphones in those devices’ vicinity could become clients connecting to those access points to exchange data. If the roles of access point and client are changed between devices often enough, the data would be propagated through the network. The RESCUER approach to AdHoc is built on this theory and explained in detail in the following section.

3.2. The RESCUER Approach to AdHoc Communication

3.2.1 The Basics

Building upon the theory explained in Section 3.1, the RESCUER AdHoc approach is based on the capability of smartphones to act as mobile WiFi hotspots. The approach can be summarised as follows.

In AdHoc mode, a certain number of devices turn themselves into WiFi access points. This decision is based on a set of rules (which are explained in the next subsection) and a random factor. The other devices are scanning their surroundings for available access points and connect to one of them – the choice which access point they connect to is again based on a set of rules and a random factor.

Once the connection is established, all phones that are connected to an access point exchange their data (i.e. messages) amongst each other – this does also include the phone that is currently acting as an access point. This “micro network” is now synchronised, meaning that all participating phones have the same data stored. After a while, the connection is broken up.

At this point, new access points are created – phones that were previously an access point are now more likely to become a client. During the following data exchange phase, the micro networks are synchronised again. As we aim to maximize the chance of devices being connected to devices that were previously part of different micro networks (see the next subsection for details), all devices should get the chance to receive new data – i.e. previously unknown messages.

After a number of iterations of this process, all messages will have spread through the network. The figures on the following pages illustrate the basics of this process in more detail. Please note that it is not necessary to go through the phases shown below in a synchronized manner according to a global schedule. Given a large enough amount of devices, there will always be some acting as access points and others acting as clients. Our tests showed that the approach already works with only 17 phones in total.

12

13

14

15

16

17

3.2.2 Details of the Methodology

The crucial element defining the efficiency of an opportunistic networking implementation is the mode switching strategy (i.e. the assignment of access point and client roles to devices and the definition of micro networks). A good strategy should ensure that the devices communicate in a way that maximizes the amount of new messages being exchanged within each micro-network. Hence, the case where the same devices are part of the same micro network in consecutive mode switching iterations should be avoided, if possible. Taking this goal as a basis, we implemented a novel mobility based mode switching strategy which is based on the following two assumptions:

1. Devices with a high mobility carry potentially more new messages than those with a low mobility. The reasoning is intuitive: if a device travelled a long distance, it potentially carries messages from a source that is physically further away from its current location. Since opportunistic networking is mainly about bridging physical distances as quickly as possible, device mobility should clearly be regarded as an important factor. We therefore introduce the quality factor device mobility as DM and the device mobility threshold as DMthresh.

2. Ideally, each micro network consists of devices that have not been connected for a long time. Again, the reasoning is rather intuitive: the likelihood of new and therefore relevant messages being exchanged between devices in an opportunistic network is higher when the devices have not been in touch with another device for a long time, since they will have had the chance to collect new messages in the meantime. We therefore introduce the quality factor last seen as LS and the last seen threshold as LSthresh.

Our mode switching strategy follows a strictly asynchronous approach: as soon as a device loses connectivity for a certain amount of time, it enters into opportunistic networking mode and initiates a so-called decision phase where it decides whether it becomes an access point or a client without complying with a global schedule. Within the decision phase, the following main steps are taken:

1. The device collects information about all available access points that are within reach. Access point devices broadcast their DM value as part of their SSID.

2. All access points with DM ≥ DMthresh are inserted into a list LDM ranked according to their DM values.

3. All access points with LS ≥ LSthresh are inserted into a list LLS ranked according to their LS values. Each device keeps a local record of when it was last connected to another device so that this ranking can be created individually for each device.

4. An overall ranking is computed based on each access point's ranking within LDM and LLS. Both rankings can be weighted (see Section 3.4 for details on the optimal weight factors DMweight and LSweight).

5. The device goes into client mode and connects to the access point with the highest overall ranking.

6. If no suitable access point could be found (because either none was available or none exceeded DMthresh or LSthresh), the device counts the number of available devices that are within reach.

7. If there are at least n devices within reach, the device goes into access point mode and waits for clients to connect. Please note that due to the limitations of some devices

18

discovered during our investigations with respect to establishing boundary conditions imposed by smartphones (see Section 3.3 for details), the initial value of n should not be greater than 5.

The devices also need to be able to make a decision about their modes when the parameters DMthresh, LSthresh and n are not met by their surrounding peers. In those cases the decision phase is repeated, this time with lower values for DMthresh, LSthresh and n, effectively relaxing the requirements regarding the quality factors a little bit. Furthermore, with each iteration of the decision phase, a random factor is added to the decision process so that after a large enough number of iterations, the decision basically defaults to a random mode switching strategy. In those extreme cases, 20% of the devices become access points while the rest goes into client mode. The reasoning for this 20/80 distribution is again found in the limitations of some smartphones with respect to their access point performance. We chose this upper bound instead of a distribution with a higher access point ratio for battery drainage reasons (devices in access point mode have a higher battery drain than those in client mode). Section 3.4 will show that from a performance point of view, more access points ensure a faster spreading of information – however, for our fall-back random strategy we decided to rank battery drain higher than overall performance.

Furthermore, an approach is needed for defining the actual communication within the micro-networks. While the main parameters of our communication protocol are defined in the Section 3.3, an integral element of the actual mode switching strategy is to define when a device currently acting as a hotspot should quit its current mode and go back into the decision phase. Our approach makes hotspots responsible for breaking up connections – clients stay connected to an access point until that access point decides to go back into a decision phase. This happens when a certain amount of time has passed without any data being exchanged within the micro network – we made the decision against a pre-defined global duration for the existence of access points as it can always be the case that new clients connect to the access point and deliver potentially new data to the micro network. Only when no data exchange has taken place for a set duration U is the micro network dissolved by the access point going back into a decision phase, which triggers the clients to do the same. For further elaboration on the value of U please see Section 3.4. Clients are automatically disconnected from the micro-network when they move out of the access point's range.

Since our mode switching strategy is heavily based on device mobility, we wanted to assess how it would fare under worst-case conditions – i.e. in a scenario where all devices are immobile. We therefore laid out 14 devices over an area of approximately 500 m2 and let them each create random messages in a way that resulted in a total number of 200 messages each 100 characters long. The parameter U was set to a length of 3 minutes for this test (a rather high value which would be well suited for a scenario with high device mobility).

19

The following table summarizes our findings: Table 2: Results of live tests under worst case conditions without device mobility

avg med Std

Reception Duration 309,43s 219,00s 301,09s

Full Message Coverage 774,26s 750,45s 187,03s

Hop Count 3,2 3,0 1,2

Max Hop Count 4,5 4,0 0,9

In Table 2, one can see that it took an average of roughly 3 minutes for each message to make it to another device and almost 13 minutes for all 200 messages to be available on all 14 devices. While those values might seem high at first glance, they can be easily explained by the fact that each decision phase needed to be iterated numerous times as all devices were stationary – i.e. there were no usable DM parameters and LS could not be used as intended, either. Furthermore the fact that U was set to 3 minutes – a value that makes sense in a moving crowd when there is a chance of new clients connecting to an access point – slowed the entire test down considerably, as it meant that 3 minutes needed to pass before a new micro-network could be established. In summary, we come to the conclusion that our approach works even under conditions that are actually destructive to the mode switching strategy's underlying concepts.

3.2.3 Regarding Smartphone Operating Systems

As already mentioned above, the RESCUER Mobile Crowdsourcing Solution has to run on unmodified off-the-shelf smartphones. This imposes a few restrictions on the details of the AdHoc algorithm. Most of them are to be found in the fact that different operating system vendors offer different degrees of freedom to developers.

The RESCUER solution will support Android and iOS smartphones and will therefore cover about 95% of the smartphone market. Android offers quite a large degree of freedom to developers, which is why the first prototypes of the AdHoc system were implemented on this platform. Once a suitable configuration of the algorithm’s parameters was found, the solution was adapted to the specifics of iOS.

Apple’s iOS is very restrictive when it comes to granting developers access to low-level functionalities of the hardware. At the time of the writing of this deliverable (May 2015, current iOS version: 8.3) this results in two problems:

1. It is not possible to turn an iOS device into a WiFi hotspot programmatically. The only way to do this is for users to access the system settings manually – this is clearly not feasible in our fast switching application context. We are therefore forced to limit the devices who can act as access points to Android devices. In the big picture this is not a real problem though, because a) Android has a much larger market share than iOS (as of Q1/2015: 78% Android vs. 18.3% iOS, Source: IDC, May 2015) and b) does the nature of our approach require more clients than access points anyway.

20

2. It is not possible on iOS to programmatically connect to a specific WiFi hotspot. Again, the user has to connect manually to a hotspot before the operating system can connect to it automatically.

The second problem has a more meaningful influence on our approach. Ideally, iOS devices would also automatically search for the WiFi networks created by the access points and join those networks. Since this is not possible, a workaround needed to be found. We therefore decided to implement the following steps in order to make sure that iOS users can participate in AdHoc networking:

1. Whenever the RESCUER application running on an iOS device recognizes that there is no connectivity, it switches into AdHoc mode, like Android devices do. However, instead of automatically entering the decision phase, the devices prompt their users to open the network settings, look for a WiFi access point with the RESCUER SSID and connect to this access point. From now on, the device will always connect to hotspots with this SSID automatically. Hence, if the Android access point devices used this SSID, iOS devices could join their micro networks and participate in the message exchange.

2. Usually, the SSIDs used by the Android access point devices are formed by a static prefix and a dynamic suffix representing the device’s DM value. Hence, the SSIDs of the access points are different – in fact, the same device will never use the same SSID twice as its DM value will constantly change. However, in order to make sure that iOS devices can participate in the RESCUER AdHoc approach, it must be ensured that some access points use the static RESCUER SSID which iOS devices will auto-connect to after their users have manually selected it once. Therefore, the Android devices will use the static RESCUER SSID once every three times they become access points. Such access points will only be used by Android clients for connections in case no “full feature” access points specifying their DM value are available. Assuming a large enough number of users running the RESCUER application on their devices, it is thus guaranteed that there are always some access points which are able to include iOS devices into their micro networks.

It is clear that the above approach is not ideal and also partially undermines our novel concept of mobility based role switching as iOS devices do not get the chance of picking the ideal access point based on its DM value. However, with the present state of technology, this seems to be the only feasible compromise to make sure that smartphones with both operating systems can participate in RESCUER’s AdHoc networking approach. In addition, from a user’s point of view, it might be a nuisance to have to manually connect to an “emergency access point” in case of network issues. It is our belief, however, that people will be fine with this as anybody looking for advice in a critical situation will be happy to connect to a network by hand if this means that he can communicate with emergency forces.

With respect to iOS, all that remains to be said is that we will have to wait for Apple to improve its API in future versions of the operating system, making sure that apps can trigger the connection to any available WiFi network automatically or even create WiFi hotspots automatically. Once this is the case, iOS devices will be able to also make use of the full potential of the RESCUER AdHoc networking approach. For the record it must be said that switching to Bluetooth instead of WiFi is no option as it suffers the same iOS problems with respect to automatic connections without user interference.

21

3.3. Establishing Boundary Conditions

In order to design a communication protocol and a mode switching strategy optimal for our scenario, an understanding about the capabilities and limitations of smartphones from an opportunistic networking perspective is needed.

Given that to our knowledge no such research has been carried out up to now, we performed a series of experiments with a host of smartphones. The set of devices was assembled based on the most popular smartphones manufactured between 2010 and 2014, thereby providing a good overview about the market. In the following subsections we present the outcome of our experiments.

For the tests we built the AdHoc micro networks manually (in order to make sure that their topology was identical during the test runs) and triggered each test case by hand.

3.3.1 Device Type

Figure 3: Dependency between device type and transfer time

To learn if older smartphones perform worse with respect to opportunistic networking than the latest flagship models, we performed a series of tests where a fixed number of messages (each 100 characters long) was transmitted between an access point device and a client device. We chose the Google Nexus S (released 12/2010), the Samsung Galaxy S3 (released 05/2012) and the Google Nexus 5 (released 10/2013) as reference devices. Our findings clearly show that the oldest device performs broadly on the same level as the newest device, with the ``middle aged'' device surprisingly outperforming both. The reason for this might be found in the different operation system variant: while both Nexus devices use “clean” Android, Samsung customizes the operating system for its own needs. As a result we can say that the device type does not have to be considered when selecting access points as it has no implications on the performance of the system.

22

3.3.2 Message Size

Figure 4: Dependency between message size and transfer time

In order to find out what impact the payload size has on the transmission speed, we performed a series of tests where messages of varying size were exchanged between two devices. The payload size ranged between 100 and 10.000 characters. Figure 4 demonstrates that while there is a linear dependency between message size and transmission time, the increase factor is very small: the average transmission time only grows by 32% when the message size is increased by a factor of five (~280ms vs. ~370ms).

It is also noticeable, that the message size makes little difference below a threshold of about 1.000 characters. Since this threshold will most likely rarely be crossed in an emergency messaging scenario, when people typically use short and precise messages, we can reason that the size of a message does not have any meaningful impact on the communication protocol.

3.3.3 Packaging Strategy

Figure 5: Dependency between message count and transfer time

23

One key design decision for our communication protocol was whether to exchange all messages within one large packet or to transmit each message as a single small packet. We therefore performed a series of experiments where we altered the packaging strategy for each iteration. The first iteration consisted of a single 100.000 character packet being sent while the last iteration consisted of 100 packages each 1.000 characters long. Since our findings showed that the former performed about 7 times better than the latter (see Figure 5), we made the decision to exchange messages between devices in bulks. Thus our system bundles as many messages as possible into one data chunk for transmission during the synchronization of the micro networks.

3.3.4 Distance between Devices

Figure 6: Dependency between inter-device distance and transfer time

A further experiment was performed to find out if the distance between two devices had a large impact on transmission times – especially in scenarios with a lot of mobility this would be an important factor. We therefore performed outdoor tests where messages were exchanged between two devices at varying distances. The distance was increased from 10m to 100m in 10m increments. Our findings clearly show that under line-of-sight (LOS) conditions, the distance between the devices can be disregarded (the mean transmission time of our test messages was around 400ms regardless of the distance between the devices).

However, the situation looks completely different when there is no LOS between the two devices. Especially, in indoor scenarios, a smartphone's ability to act as an access point over longer distances can be severely weakened due to dense multi-path effects in the environment and reflection, diffraction and scattering of the WiFi signals. While our scenario is focused purely on outdoor situations, one still should not make the mistake to assume that smartphones will be able to communicate via opportunistic networking over distances of 100+ m in the average case, as no LOS condition is very likely (please also see the next subsection for details on this topic).

24

3.3.5 The Effects of Dense Crowds

WiFi signals are mainly transmitted in the 2.4 GHz range – this happens to be about the same as the resonance frequency of water [7]. Incidentally, the human body is made up of up to 72% water [8]. Therefore, people must have an effect on the transmission of WiFi signals – a fact that is even more relevant in our scenario consisting of (potentially very dense) crowds.

[9] establishes that attenuation due to the human body on the WiFi signal strength is stronger when a person is closer to an access point than when it is further away. [10] quantifies these findings: when a person is standing 1m away from an access point facing the device, the RSSI of the WiFi signal drops over 40 dBm when receiving the signal behind that person compared to receiving it in front of her/him. In a distance of 10m, however, there is no noticeable difference anymore.

In practice, this means that smartphones which are carried in a pocket by their users are ``weak'' access points and we cannot assume that they will cover the same distance that we observed during our LOS experiments where the devices were hand-held. Tests in crowded open air environments have shown that the smartphones carried inside of trouser pockets were still able to communicate over a distance of approximately 50m, but would sporadically lose their connection when the test subjects moved away even further. This has a direct influence on the simulation performed in Section 3.4, which was used to fine-tune the parameters of our AdHoc algorithm.

3.3.6 Exchange Strategy

Figure 7: Comparison between message sending strategies

The communication within a micro-network consisting of one device in access point mode and several devices in client mode can be described best as a synchronization between all participating devices which is, in our case, controlled by the access point device. The question was, consequently, if synchronization should happen via flooding (i.e. all clients send all their messages to the access point which in turn sends the combined set back to all clients) or if it makes sense for the synchronization to take place in a filtered way. The latter would introduce an additional stage taking place before the actual synchronization, where each client sends the access point a message

25

containing the IDs of all messages the client has stored. The server would return a list containing only those message IDs that are new to it so that the amount of transferred data can be optimized.

Under ideal conditions (i.e. no duplicate messages exist in the micro-network), flooding is about 15% (or about 58ms) faster than the filtering approach. However, in a real world scenario, it is very likely that a meaningful portion of the messages is already known to the clients from previous iterations of the AdHoc algorithm. We therefore decided to implement the ID polling algorithm for the RESCUER AdHoc approach.

3.3.7 Access Point Performance

During our experiments we realized that smartphone vendors actually limit their devices when it comes to the number of clients that can connect to an access point device simultaneously. This limit does not seem to depend on hardware factors alone as we discovered that identical phones running different operating systems (stock Android vs. the Cyanogen Mod, for example) imposed different limitations on the access point feature. Furthermore, some network operators impose limits on the amount of clients per smartphone access point.

After having analyzed 14 different phones in total, we came to the conclusion that it is safe to assume that each device can handle 5 clients when in access point mode – an important number when designing the mode switching strategy, which resulted in our definition of the parameter n’s upper threshold. However, it needs to be said that some devices we tested were able to handle as much as 13 connected clients, so in practice there will be micro-networks with more than just six participating devices.

3.3.8 Mode Switching Duration

Critical performance parameters are the time it takes an access point device to provide clients with a WiFi network and the time it takes a client to connect to an access point. Since our scenario is very mobile, devices potentially do not have much time to connect to each other and synchronize before they are out of range again.

Our experiments showed that it can take a device anything between 5 and 10s to create a usable WiFi hotspot. On the other hand, client devices took a maximum of 5s to connect to an access point. Based on the dataset recorded at the Zurich festival we found out that the average speed of a pedestrian at an event is rarely above 1m/s under normal conditions. Assuming an average access point range of 50m and a total micro-network setup time of 15s, this leaves enough time for information synchronization to occur even when the two devices are moving in opposite directions.

3.4. Simulating the RESCUER AdHoc Approach

To test the effect of those various parameters on our AdHoc algorithm, and to study operational domains lying outside the current experimental tests, we have developed and analyzed a large-scale agent-based simulation model (ABM) using the framework NetLogo. The simulation example is based on a real world dataset obtained during the 2013 Zurich festival [11] and uses the map of Zurich,

26

where pedestrians are randomly located with a desired density and motion parameters. In this way we define abstract pedestrians that are “as good as real”, which allow us to study realistic motion patterns as well as their effect on communication.

The simulation allows for broader parameter sweeps, which we have obtained using NetLogo's own BehaviorSpace module. We developed two varieties of the model and both have been parameterized using real data. One version uses city street maps (shape files) for pedestrian motion and the other a free area to reduce complexity and to obtain a general model. The shape file based version is domain independent and has been tested on various city layouts (e.g. Torino and Budapest) and it is here studied at the example of Zurich. A rectangular area can be outlined to define a signal outage, i.e. an area within which our AdHoc communication approach is simulated. Pedestrians can be put on streets randomly or by mouse commands to define “hot spots”, which are common during large scale events. Using our simulation combining the motion and communication models, various scenarios can be tested.

Figure 8: The agent based model versions (left: shape file based, right: abstract model)

3.4.1 Walking Model and Motion Data

The biggest challenge for making the simulation useful was to equip the agents with a realistic motion model. We therefore analyzed a data set recorded during a previous project. This data set contains movement traces recorded with smartphones from more than 23.000 people during the Zurich festival 2013 – according to our knowledge, this data set was the largest of its kind at the time of the experiment.

Using the Zurich festival dataset we estimated the key walking parameters and used them in the simulation’s motion model. Specifically, we obtained data for average walking speed as well as average walking/standing times, together with their error terms. Our approach takes these values as averages over various crowd densities experienced in the dataset, referring to the fact that in the interesting range (3.000 – 4.000 pedestrians using the smartphone app) these parameters do not change dramatically.

27

Shape files represent streets by their segments, and our motion model consists of navigation along a network defined by these segments. Pedestrians share a common average walking speed but have individual walking and staying times taken from two normal distributions, characterized by the average walking/standing times and their standard errors, respectively. Pedestrians are heading towards an adjacent segment and upon reaching it select a new adjacent destination segment, never turning back in a single selection step.

Sample walking data is presented in Figure 9. Our motion model is based on a “mean field” approximation of the pedestrian population, hence we use the averages for walking speed 0,5 m/s, standing length 55s (std 100) and time between standing 40s (std 65), respectively. We take these as fixed external parameters in our simulations to test the internal parameters of the AdHoc algorithm. With the motion model realized, we found out that about half of all agents are immobile at any given time, about 20% never move at all and another 20% never stand still – those values seem intuitive for anyone having visited a large street festival.

Figure 9: Sample walking data from the Zurich data set (left: walking speed, middle: averaged movement data, right: movement data variance). At the time of the outliers (at around 23:00) the fireworks display started which explains the low movement speeds and long standing durations.

28

3.4.2 Simulation Runs and Parameter Sweeps

Table 3: Simulation parameters tested

Parameter Value Range Population N 1.000 fixed

Device Range r 50m fixed Access Point Mode Uptime U 180s fixed

Uptime Standard Error stdU 35s fixed Max # Clients per Access Point k 5 fixed

# Clients required per Access Point n 1 1 – 4 Device Mobility Weight DMweight 1,0 0 – 1,0

Device Mobility Threshold DMthresh 0 0 – 0,6 Last Seen Weight LSweight 0 0 – 0,6

Last Seen Threshold LSthresh 0 0 – 60 Here we present key results directly bearing upon open questions left about parameters in the

empirical tests. In the simulation runs, we have used the parameters given in Table 3. The model is consistently scaled for all values as 1 patch = 7 meters and 1 tick = 1 sec. A useful visualization renders 1 patch as 4x4 pixels. The area tested was 1.500 x 1.500 meters, i.e. 2.250.000 square meters.

We are here presenting two cross-sections of analysis, first keeping the algorithmic parameters related to DM and LS fixed at <1,0;-0;_0;_0> as in Table 2, and looking for the effects of n. In the second study we set n to the best value found and perform multi-dimensional sweeps for the four DM and LS parameters (prior tests justify this strategy and have indeed been suggesting optimization of n first). The simultaneous analysis of all parameters of Table 2 would require advanced design of experiment tools such as adaptive sampling and is therefore beyond the focus of this work.

Figure 10: Left: convergence time t versus n. Right: The number of access points versus n

29

Among the output variables studied, of utmost importance are the ones related to efficiency, i.e. convergence time t (the time that a single initial message originating from a single device reaches all devices) and the percentage of devices in access point mode. The first study shows a tradeoff between these two variables as a function of n using 10 random runs with identical parameters, as shown in Figure 10.

The number of access points used stands clearly in a strong negative linear relation with n (also tested but not shown using correlation package car in R). The effect of n on convergence speed is less profound however, and t has a flat minimum at n = 1 or 2. If access point efficiency is also taken into account this indicates n = 2 as best value. To appreciate these results, we observe that at this value (using approximately 40% of agents as access points) the message reaches all 1.000 individual users moving over more than 2 million square meters in a time of about 33 minutes; the same would be achievable by only 20 - 25% of servers in approximately 40 minutes.

While these numbers may seem high at first sight, we refer back to the choice that we did not test U values smaller than 3 minutes on average. Clearly that value is a bottleneck in scenarios with low mobility. A dramatic increase of speed can be expected using smaller values (and a faster establishment of connections with the next generation of WiFi chips). Furthermore, please note that this simulation takes only one single device as a starting point for the propagation of the message, whereas in reality there would be more people moving into the affected area and thus more devices injecting the message into the AdHoc network. For reasons of reproducibility, however, we decided for having only one device as initial information source for the scope of this simulation.

Figure 11: Left: DMthresh and LSthresh affecting convergence speed. Right: DMthresh and DMweight affecting convergence speed

Using n = 2, our further simulation runs were intended to clarify the relations of DMweight, DMthresh, LSweight and LSthresh. In the intervals given in Table 2, the output variable t varied between 1.800 and 4.100 seconds, with all t values below 2.000 reached at DMthresh = 0 at any value of the other 3 parameters. On the other end, high t values are characterized by high values of DMthresh, but also by high values of the other parameters. Motivated by these findings, we look into the 3D sections of the resulting space (Figure 11). Convergence speed versus DMweight and LSweight, or versus LSweight and LSthresh do not give any interesting insight, reinforcing the recognition that LS is not

30

offering the most relevant contribution in the event scenario. The 3D plots using the threshold variables (Figure 11, left) and the plot of convergence speed against DMweight and DMthresh (Figure 11, right) have a clearer message: Lower values of DMthresh combined with higher values of DMweight give best results largely independent from LSweight and LSthresh values.

Figure 12: The effect of population size N on the spreading of messages (i.e. convergence time t)

Finally, we asked about the impact of t on N, the number of agents. Results are shown in Figure 12. It can be seen that above approximately 1.000 agents the time for a message to reach all agents remains constant, which justifies our choice of N = 1.000 for the main part of this study.

As a summary, we may conclude that LS is suppressed by the effects of high mobility values DM – using a realistic motion model this is expected indeed, as many agents are immobile or have low mobility, designating them as weak candidates for quick information propagation.

3.4.3 Comparison with Random Mode Switching

Degrees of mobility have been tested and evaluated in the previous subsection with the conclusion that the amount of mobility is a decisive factor in the speed of signal propagation. Next, we also performed direct comparisons of our switching algorithm with a purely random mode switching strategy using the same optimal parameters. This also ensures fairness of comparison as it keeps the ratio of access points at around the same low level. It was found that our algorithm outperforms random mode switching by 10% or more (see Figure 13), with asymmetric error terms. Thus, the RESCUER mobility based mode switching strategy has been proven to be an advancement.

31

Figure 13: Comparison of mode switching strategies

32

4. Conclusion

This deliverable presented the outcome of Task 1.3 (Communication Infrastructure). It presented the foundation for the communication between the users’ mobile phones and the command and control center. It also presented an AdHoc approach enabling mobile phones to exchange data without the presence of a fixed network infrastructure (i.e. cell phone towers).

With respect to AdHoc communication it was also shown that the RESCUER approach is feasible for our scenarios. Furthermore, our mobility based switching strategy has been proven to be superior to purely random switching strategies.

With respect to future work, it remains to be seen how the AdHoc communication will fare in a real world evaluation which will be performed together with the evaluation of other system components of the RESCUER solution.

33

References

[1]. Martin Wirz, Tobias Franke, Daniel Roggen, Eve Mitleton-Kelly, Paul Lukowicz, Gerhard Tröster. Inferring and visualizing crowd conditions by collecting GPS location traces from pedestrians' mobile phones for real-time crowd monitoring during city-scale mass gatherings. Collaborative Technology for Coordinating Crisis Management (CT2CM) track of WETICE, 2012

[2]. Tobias Franke, Paul Lukowicz, Martin Wirz, Eve Mitleton-Kelly. Participatory Sensing and Crowd Management in Public Spaces. Proceeding of the 11th annual international conference on Mobile systems, applications, and services, MobiSys 2013

[3]. Martin Wirz, Eve Mitleton-Kelly, Tobias Franke, Vanessa Camilleri, Matthew Montebello, Daniel Roggen, Paul Lukowicz, Gerhard Tröster. Using Mobile Technology and a Participatory Sensing Approach for Crowd Monitoring and Management During Large-Scale Mass Gatherings. Co-evolution of Intelligent Socio-technical Systems, Springer, pp. 61 - 78, ISBN 978-3-642-36613-0, 2013

[4]. Martin Wirz, Tobias Franke, Daniel Roggen, Eve Mitleton-Kelly, Paul Lukowicz, Gerhard Tröster. Probing crowd density through smartphones in city-scale mass gatherings. EPJ Data Science Journal Volume 2, Issue 1, Springer, June 2013

[5]. Franck Legendre, Theus Hossmann, Felix Sutton, Bernhard Plattner. 30 Years of Wireless Ad Hoc Networking Research: What about Humanitarian and Disaster Relief Solutions? What are we still missing?. ACWR ’11, Dec 18-21 2011, Amritapuri, Kollam, Kerala, India

[6]. Sacha Trifunovic, Bernhard Distl, Dominik Schatzmann, Franck Legendre. WiFi-Opp: Ad-Hoc-less Opportunistic Networking. CHANTS’11, September 23, 2011, Las Vegas, Nevada, USA

[7]. Kaemarungsi, Kamol, and Prashant Krishnamurthy. "Properties of indoor received signal strength for WLAN location fingerprinting." Mobile and Ubiquitous Systems: Networking and Services, 2004. MOBIQUITOUS 2004. The First Annual International Conference on. IEEE, 2004.

[8]. Lukaski, Henry C. "Methods for the assessment of human body composition: traditional and new." The American journal of clinical nutrition 46.4 (1987): 537-556.

[9]. Kaemarungsi, Kamol. "Distribution of WLAN received signal strength indication for indoor location determination." Wireless Pervasive Computing, 2006 1st International Symposium on. IEEE, 2006.

[10]. Fet, Ngewi, Marcus Handte, and Pedro José Marrón. "A model for WLAN signal attenuation of the human body." Proceedings of the 2013 ACM international joint conference on Pervasive and ubiquitous computing. ACM, 2013.

[11]. U. Blanke, G. Tröster, T. Franke, and P. Lukowicz, “Capturing crowd dynamics at large scale events using participatory GPS-localization” Intelligent Sensors, Sensor Networks and Information Processing (ISSNIP), 2014 IEEE Ninth Conference on, 2014, pp. 1-7