help beacons

19
Help Beacons: Design and Evaluation of an Ad-Hoc Lightweight S.O.S. System for Smartphones Amro Al-Akkad 1 , Leonardo Ramirez 2 , Alexander Boden 1,3 , David Randall 3 , Andreas Zimmermann 1 1 Fraunhofer FIT 2 Fraunhofer 3 University of Schloss Birlinghoven Hardenbergstrasse 20 Hölderinstr. 3 53754 St. Augustin, Germany 10623 Berlin, Germany 57068 Siegen, Germany {FN.LN}@fit.fraunhofe r.de {FN.LN}@zv.fraunhofer .de {FN.LN}@uni- siegen.de ABSTRACT We present the design and evaluation of a lightweight mobile S.O.S. system that facilitates ad-hoc communication between first responders and victims in emergency situations in the face of disruptions of existing network infrastructure. Our approach leverages established protocols and standards in unforeseen ways to provide a platform supporting the creation of short-lived communication links. The system comprises two mobile applications: one victim application that allows the broadcasting of distress signals by a novel use of Wi-Fi SSIDs; and a responder application that allows first responders to discover and trace the people broadcasting the signals. The main difference of our system with other platforms enabling communication in crisis situations is, that our system is independent from existing network infrastructure and runs on off-the- shelf, commercially available smartphones. We describe the results of our evaluation process in the context of both a design evaluation during a real-world emergency response exercise and a s w e ll a s of two user workshops in preparation for an upcoming large-scale exercise. Author Keywords Mobile computing; ad hoc communication; emergency response; smartphones ACM Classification Keywords H5.m. Information interfaces and presentation (e.g., HCI): Miscellaneous. INTRODUCTION The availability of broadband (3G, 4G) and wireless (Bluetooth, Wi-Fi) communication technologies as well as portable wireless devices (smartphones, tablet computers) Paste the appropriate copyright/license statement here. ACM now supports three different publication options: ACM copyright: ACM holds the copyright on the work. This is the historical approach. License: The author(s) retain copyright, but ACM receives an exclusive publication license. Open Access: The author(s) wish to pay for the work to be open access. The additional fee must be paid to ACM. This text field is large enough to hold the appropriate release statement assuming it is single-spaced in TimesNewRoman 8 point font. Please do not change or modify the size of this text box.

Upload: arun-krishnan

Post on 23-Dec-2015

35 views

Category:

Documents


0 download

DESCRIPTION

Help Beacons

TRANSCRIPT

Page 1: Help Beacons

Help Beacons: Design and Evaluation of an Ad-HocLightweight S.O.S. System for Smartphones

Amro Al-Akkad1, Leonardo Ramirez2, Alexander Boden1,3, David Randall3, AndreasZimmermann1

1Fraunhofer FIT 2Fraunhofer Headquarters 3University of SiegenSchloss Birlinghoven Hardenbergstrasse 20 Hölderinstr. 3

53754 St. Augustin, Germany 10623 Berlin, Germany 57068 Siegen, Germany{FN.LN}@fit.fraunhofer.de {FN.LN}@zv.fraunhofer.de {FN.LN}@uni-siegen.de

ABSTRACTWe present the design and evaluation of a lightweight mobile S.O.S. system that facilitates ad-hoc communication between first responders and victims in emergency situations in the face of disruptions of existing network infrastructure. Our approach leverages established protocols and standards in unforeseen ways to provide a platform supporting the creation of short-lived communication links. The system comprises two mobile applications: one victim application that allows the broadcasting of distress signals by a novel use of Wi-Fi SSIDs; and a responder application that allows first responders to discover and trace the people broadcasting the signals. The main difference of our system with other platforms enabling communication in crisis situations is, that our system is independent from existing network infrastructure and runs on off-the-shelf, commercially available smartphones. We describe the results of our evaluation process in the context of both a design evaluation during a real-world emergency response exercise and as well as of two user workshops in preparation for an upcoming large-scale exercise.

Author KeywordsMobile computing; ad hoc communication; emergencyresponse; smartphones

ACM Classification KeywordsH5.m. Information interfaces and presentation (e.g., HCI): Miscellaneous.

INTRODUCTIONThe availability of broadband (3G, 4G) and wireless(Bluetooth, Wi-Fi) communication technologies as well as portable wireless devices (smartphones, tablet computers)

Paste the appropriate copyright/license statement here. ACM now supports three different publication options:

ACM copyright: ACM holds the copyright on the work. This is the historical approach.License: The author(s) retain copyright, but ACMreceives an exclusive publication license.Open Access: The author(s) wish to pay for the work to be open access. The additional fee must be paid to ACM.

This text field is large enough to hold the appropriaterelease statement assuming it is single-spaced in TimesNewRoman 8 point font. Please do not change or modify the size of this text box.

has significantly increased over the last decade. People have become used to the omnipresence of mobile services such as map-based services, communication services, or social networks in their daily life. However, the availability of such services can be severely disrupted in crisis situations, when people are most dependent on their ability to communicate. Several studies (cf. ) have found that people immediately affected by a crisis as well as people near or far away to the affected crisis zone, are often trying to use services such as SMS, web sites, blogs, social networks or micro-blogging, to respond to the contingent needs created by a crisis. For example, X investigated the use of texting services during the 2002-2003 SARS epidemic in China to spread information about the locality of infected persons. Also, the study of Y examined how, in the aftermath of the 2007 Southern California wildfires, the use of blogs and web sites supported people in reconnecting geographically dispersed communities. Such incidents, however, also sometimes show that in cases of emergencies people often face the intermittent or temporarily complete cut-off from their mobile platforms due to damage tos or congestion ins of the network infrastructure. This inability to communicate also hinders emergency response personnel in finding immobilized or trapped victims, especially in cases of large-scale emergencies.

Research in Mobile Computing and HCI communities has striven for the design of systems that enable people in distress to communicate with each other, as well as with emergency response personnel (cf. ). However, most of these systems rely upon an existing network infrastructure. Other studies (cf. ) have explored the use of Bluetooth (BT) or Wi-Fi in Ad Hoc mode to provide communication platforms that are independent from existing network infrastructure, usually relying on special hardware or rooted mobile systems. In this paper, we contribute to this stream of research by presenting an implementation of a system that runs on off-the-shelf smartphones and is independent from existing network infrastructure. Our system enables people in distress to use their smartphones to communicate their situation in the form of an ad-hoc emergency signal that can be received by professional first responders, helping them to locate victims and danger zones in emergency situations. To do For doing so, our approach leverages

Page 2: Help Beacons

established wireless network protocols and standards to create ad-hoc communication links between portable wireless devices in proximity. One device (the “Beacon”) advertises an emergency message inside the Wi-Fi service identifier (SSID), i.e. the human readable network name of an access point. In turn, another device (the “Seeker”) scans the environment for devices that advertise themselves as Beacons and instantiates brief connections to those in order to notify each Beacon that it has been discovered. In cases where connectivity is strong enough, both Beacon and Seeker can exchange further information that exceeds the32 characters constraint of the SSID.

In this paper, we explore the potential uses of ad-hoc networking technology in crisis situations and how first responders and victims can benefit from the use of this technology. Using a proof-of-concept system in the context of emergency response training, we observe how our technology fits into existing practice and discuss the implications of our findings for the design of ad-hoc networking applications for emergency response. Our paper is organized as follows: We open with a description of the background of our work and the methodology we applied for our study. Then, we discuss the related work and how our approach contrasts with existing approaches. We describe in detail the design and implementation of our proof-of-concept system. In the second half of the paper, we present a design evaluation as well as results from two user workshops in the context of emergency response training. After a discussion of the limitations of our system and findings from our evaluation, we conclude the paper with implications for the design of ad hoc communication systems for emergency situations.

BACKGROUND AND METHODOLOGYOur study is part of a large European research project thataims to support first responder organizations in handling large-scale emergency situations by providing a means of communication despite disruptions to existing network infrastructure. In such situations, to locatinge and communicatinge with victims is an important need for first responders. Over the last two years, we have conducted several interviews with practitioners in the field of emergency response and people who have personally experienced or were otherwise affected by a crisis. A detailed account of our fieldwork and its implications for design is described in ???.

Based on Resulting from our work in the project, we have collected several high level requirements for our system (see Table 1). I n a d d i t i o n t o t h o s e i d e n t i f i e d i n the literature on dangerous and disrupt[tive , whicht ypi call y occur in dangerous environments , summarized in R1-R4, From our own fieldwork, we further elicited five additional requirements (R5-R9).

From this requirements, and following the approach of Edwards et al. , we have started with the design of a prototypical system, in order to test the benefits and

ID Summary (The system should…)

R1

R2

R3

R4

R5

R6

R7

R8

R9

Operate under harsh conditions in terms of temperature, vapor, or vibration.

Operate despite environmental impacts that weaken communication signals or hamper sensor reading.Work reliably and accurately as possible.

Only augment users in their actions with the physical world, but not to distract them.

Use established technologies to exploit opportunities, e.g. everyday services as Twitter or commercial OSs.

Enable quick construction of networks requiring no cumbersome configuration efforts.

Operate fault-tolerant to cope with limitations, such as intermittent disconnections.

Facilitate distribution of data to co-existing networks.

Support dynamic re-configurations of networks as needs rapidly change in the aftermath of a crisis.

Table 1. Set of System Requirements.

constraints of our core ideas in an early stage. To explore the feasibility and implications of our concept, we have tested our first prototype in a fire fighting exercise in an underground tunnel, where communication was difficult and intermittent due to the high amount of steel and curves. We considered this as a very important process for identifying constraints at an early stage of our design, before making it more robust in order to provide give a prototype for ‘real world’ into the hands of end-users. We explored the potential of our technology in two ways: 1) through a design evaluation as part of a real-world exercise and 2) through workshop participation with emergency response workers. We gathered feedback through semi-structured interviews. We captured all interviews in audio and video and we kept field notes along the process. Interviewees were asked to sign an informed consent form prior to the interview. All interviews were transcribed and translated into English, if necessary.

RELATED WORKThere are a number of systems available to meet peopleduring emergency response. (e.g. ) (cf. ). M-Urgency (cf. ). enables mobile Android or iOS users to stream live audio and video reports over the cellular network to a local public-safety answering point. In order to support the dispatcher and responders in making time-critical decisions, M-Urgency provides, besides audio and video, contextual data, such as the real-time position through GPS or Wi-Fi fingerprint, disability or gender to prepare aid accordingly, or information relevant to approach the incident scene such as weather or traffic. The Federal Emergency Management Agency (FEMA) provides an application that enables people in distress to receive shelter information and also to submit images with a short description to the FEMA website, which will be placed on a map for public viewing. Before images become available online, the images need to

Page 3: Help Beacons

go through a basic approval process in order to guarantee privacy and ensure relevance. that they are relevant and do not disclose any personal information. SafeCity allows the reception of live video streams from mobile devices reporting crimes or other distress situations. Professional responders use a dedicated application to stream video along with their GPS position to the command center or to other colleagues in the field. Users can install a free application called Bambuser , which enables them to view and stream live video. In order to report any video to authorities, users need to register for specific “shares”, such as “Crime stoppers” or “Public Officials”. All these existing emergency response systems represent promising tools for communication between the public and authorities or non-governmental organizations during a crisis. However, their use is constrained to crisis situations in which network infrastructure is still operable.

OthFurther existing technologies can be utilized for building ad hoc communication networks during a crisis. For instance, OpenGarden enables people who are being offline to consume online services provided that at least one device can connect to the Internet to which other devices can tether using low-power BT radio. For our research, we assumed that devices were completely disrupted from the online world, and focused on interaction among connected devices. Wi-Fi Direct also provides an interesting potential for ad hoc communication. We initially considered initially leveraging it for ad hoc communication, though our experiments with it on Android 4.0-4.1 were not promising; for iOS it is not available. We could not failed to implement two basic operations without the need for user interaction: first, to enablinge Wi-Fi Direct, and second, to accepting incoming connections (see also ), which means that Wi-Fi Direct implementations for Android does not comply with R6. Another constraint is that its key mechanisms only work between Wi-Fi Direct certified devices, but not legacy Wi-Fi devices , which fails to comply with R5. In general terms, Wi-Fi Direct has been designed for quick, easy and secure peering of home devices, such as connecting a camera with a printer, while our system design originated from the need toof allowing for serendipitous communications between devices.

Much research (cf. ) has also evolved around the challenge of providing communication channels in situations of disrupted network infrastructure. For instance, the Twimight application enables Twitter users in proximity to still communicate with each other in spite of disruptions toof the fixed communication network. It runs on commercial Android devices and facilitates communication between devices in proximity via BT. Twimight builds on BT, as it operates more energy efficiently than Wi-Fi. For our research project, we decided against BT due to its range constraints and cumbersome pairing process, which fails to comply with R6 and hence makes it less suitable for our purposes. The Haggle platform enables mobile users in proximity to exchange content requiring no fixed infrastructure. Through a publish-subscribe system users can express interests via

keywords and then receive content from other peers according to how well available content matches their interests. Haggle runs on Windows Mobile and Android, though for the latter, however, being the most widespread mobile operating system (OS) , However, Haggle requires special privileges not available to all users (so called root access) for both BT and Wi-Fi, and thus does not comply with R5. The work of ZZ supports the discovery and connection of wireless devices by Wi-Fi in IEEE 802.11 Ad Hoc Mode in order to allow for opportunistic communication. A device announces its presence by broadcasting beacons filled with relevant information in the SSID field, such as the device ID, and thus allows the discovery of multiple devices at the same time as one device receives several beacons from various devices without trying to establish a connection to them. While this approach shows good results in terms of energy efficiency and satisfactory connection speed between peered devices, it does not run on commercially available smartphones (R5). This is due to the fact that it uses of Wi-Fi in Ad Hoc mode ( that is not available in mobile OS) . From a technical perspective Wifi-Opp comes the closest to our mobile S.O.S. system. Wifi-Opp facilitates opportunistic networking requiring not changes in the mobile OS, i.e. their technology leverages Wi-Fi in Infrastructure mode and utilizes the same Android API to deploy hotspots conveying messages. With regard to this mailing list there exists no OpenSource distribution for Wifi-Opp, which made it difficult for us to verify its current state functionality.

The systems and approaches, then, have certain discussed represent interesting contributions, but the y have some drawbacks in r e l a t ion to the frame of our work:

Existing systems mostly work over existing network infrastructure (mobile broadband, Wi-Fi hotspots), which in crisis is likely to be disrupted, e.g. due to damage or overloading.

Systems using BT are inadequate for serendipitous communications between devices, as BT initial pairing mechanism for devices requires cumbersome configuration efforts.

Wi-Fi in Ad Hoc mode does not run on commercially available devices, it requires devices to be rooted (Android) or jail broken (iOs).

Wi-Fi Direct is still an emerging standard that is either not available for mobile OSs such as iOS, or it is not working properly yet on the latest distributions, such as in Android.

Our work leverages opportunities which already existing in current standard, off-the-shelf technology and . The research whichof resulted in the “Tweak the Tweet” (TtT) syntax that supports computational filtering and classification of information coming from Twitter streams. TtT specifies the use of specific hashtags before the relevant data, such as their “#loc” placed in front of GPS information. Analoguouse

Page 4: Help Beacons

or to

Figure 1. Exploiting SSIDs to convey emergency needs.

to the way in which TtT piggybacks on Twitter’s hashtag mechanism, our approach piggybacks instead on the Wi-Fi connection process, exploiting Wi-Fi SSIDs to convey short emergency messages. Conti (ref) has pointed out that novel ideas and creative uses of vulnerabilities inherent in technology are often triggered by non-mainstream communities such as the hacking community. An interesting example of this emergence is the Emergency S.O.S Beacon system, a system similar to our own, which emits help messages through Morse codes over AM radio which is receivable in a one-mile range by search and rescue teams using simple radio transceivers.

THE HELP BEACONS APPROACH AND CONCEPTThe concept of our mobile S.O.S. system was inspired by how people make use of the names of Wi-Fi home networks (SSIDs) to broadcast short messages conveying simple, anonymous information. Such messages can express political ideas (e.g. “ILoVeObAma!!”) , simple requests or complains (e.g. “Turn the noise down”) , or convey intention or ownership of a network (e.g. “ChrisNet”) . A Wi-Fi network is visible in a certain range and the advertised SSID is usually the first thing people become aware of in terms of wireless networks. Essentially, people can easily relate and understand SSID names. They represent an interesting point of contact between people and the intangible element that wireless networks represent. We saw in this an interesting potential for emergency response which lead to the creation of the Help Beacons concept, illustrated in Figure 1, which explores the idea of using Wi-Fi SSID as beacons to ask for help, to offer resources,

Figure 2 Set up of Beacon.

Figure 3. Flow chart of Seeker Loop for Beacon Discovery.

And disclose location during a disaster. The creation of an emergency beacon defines a sort of “I’m here” signal, which has the potential toof supporting responders in finding missing persons and reestablishing communication.

Our approach initially comprises two or more devices. Figure 2 depicts the setup process: at first, a Device A deploys a Wi-Fi hotspot that advertises itself by means of a particular string of characters contained inside the SSID. The deployed hotspot runs a DHCP server for IP address configurations, and listens to a specific socket address, i.e. the combination of an IP address and a port number, to exchange of details, when the Seeker device associates to it. Figure 3 illustrates Device B, the Seeker, which enables its Wi-Fi interface, performs a scan, and finds the Beacon by the particular string of characters placed inside its SSID. Figure 4 illustrates how Device B connects to Device A and writes its details to the specific socket address, receives details from Device A, and finally disconnects.For our system, we aimed for a design combining the networking mechanisms prevalent in smartphones and other portable wireless devices (R5) in order to allow for quick creation of networks between neighboring devices without the need forof any cumbersome configuration efforts on the part of the user (R6). We decided to use Wi-Fi in Infrastructure Mode instead of BT, as the latter lacks range

Figure 4. Sequence Diagram of Connection Process.

Page 5: Help Beacons

and requires an initial paring of devices, making it less suitable for serendipitous communications between mobile devices focused on a short-lived, one time only network infrastructure. The Wi-Fi SSID sent out by a Beacon can carry useful information entered by the user, such as his or her name, health status, or other important information. Technically, the idea can be implemented by placing short messages inside the SSID, the network name of a Wi-Fi network, in order to create an emergency beacon. A Seeker device uses its wireless interface to search for any Beacon devices in range, collecting the information broadcasted by the different devices calling for help. By piggybacking the handshaking process of Wi-Fi networks, i.e. by associating with an open (i.e. unencrypted) network, the Seeker can confirm that it has received the broadcast signal. Afterwards, it can request further information or store additional information to support the logistics of the rescuing process by connecting to a network socket provided by the Beacon.

DEVELOPMENT: HELP BEACONSThe Help Beacons system consists of two applications. The first is a victim application that enables its users to create an emergency beacon by placing short messages inside the SSID of a Wi-Fi hotspot. The other application is a first responder application that allows professional first responders to discover the requesting Beacons. Both applications can be deployed on devices running Android (supported APIs range from 2.3.3 to 4.x). Android is the most widespread mobile OS and by supporting lower API versions, our system can be installed on a wide range of devices which complies with R5. The purpose of our system would be rather constrained if it were not linked to other emergency response systems. In our research project, the responder application sends the collected data acquired from deployed Beacons to a command center using for this a mesh network (R8), which routes the data to a publish-subscribe system that pushes the data to the command center. At the command center, people can use the collected data for response purposes.

Victim ApplicationWith regard to R4 our goal was to design this application in a very minimalist way, requiring no cumbersome configuration efforts from the side of the user. To create a Beacon the user only needs to push the S.O.S. button. As soon as the creation of a Beacon is triggered, a Wi-Fi network is deployed. As Android provides this feature through a hidden API, we used JAVA reflection to invoke the relevant methods for creating a Wi-Fi network. To indicate that a Wi-Fi network constitutes a Beacon we use a prefix consisting of an uncommon string (*#%) in order to distinguish a Beacon from other available hotspots. According to the Wi-Fi protocol a SSID contains a maximum of 32 characters. Our design considers a Beacon to comprise four parts inside a SSID (see Figure 5): a prefix that indicates the presence of a Beacon, a persistent id (2

Figure 5. Composition of Help Beacons SSID name.

chars), optionally a suffix (the prefix backwards), and, most importantly, the emergency message. To be able to distinguish between equally labeled Beacons or to track devices that updated their SSID, as the situation of the owner changes, we used a “persistent” identifier. Initially, we considered using the BSSID (mac address of a Wi-Fi interface), which is received automatically when discovering a hotspot. With Android 4.x, however, the second half of the BSSID is generated randomly. Thus, the application puts inside the SSID a shortened fingerprint consisting of two chars. To hamper a reverse look up of a fingerprint, we combine a random seed with the IMEI (unique device ID) to generate an MD5 hash. Finally, we include inside the SSID the first two chars of the hash to avoid name collisions of networks of up to 11 devices (according to the birthday paradox) and store this shortened device ID for later use inside the phone’s cache.

In the application, users can select from predefined help messages or manually type in one (see Victim App in Figure 6). When their status changes, users can update their SSID broadcast accordingly (R9). Also, users can select a specific entry (“I’m safe”) from the list, which triggers the application to deploy a network with the above-mentioned additional suffix. The responder application will interpret this information automatically and will not connect to it (as the greyed out entry in Figure 6 shows). When a user enters a message manually, the application will provide visual feedback in form of a pop-up message.

Figure 6. Victim App (left), Responder App (Right).

Page 6: Help Beacons

After a Wi-Fi network has been deployed the Android OS automatically performs two internal actions that are beneficial for our application: 1) it creates a DHCP server, and 2) it flushes its cache of the address resolution protocol (ARP). The DHCP server assigns an IP address to each connecting client, enabling clients to address the Beacon. The IP address of the Wi-Fi network is always the same:192.168.43.1. We piggyback this static address for exchanging details, which cannot be placed inside the SSID due to the 32 ASCII characters constraint. This informationincludes elements such as the unique ID of a device (IMEI), or the time a Beacon has been enabled. To facilitate the exchange of details, the Beacon device listens on a specific address (192.168.43.1:8888). After connecting to a Beacon, the responder application tries to establish a connection to this address in order to exchange details. A proprietary protocol has been designed for this purpose. Flushing the ARP clears the history of registered physical addresses of clients that are or which have been connected to a Beacon device. Therefore, the victim application deploys a dedicated thread that regularly checks the ARP cache for new entries in order to detect if a Seeker device (i.e. a client) has associated to the Beacon device. If a new entry appears in the ARP cache the application immediately informs its users that another device has associated to the Wi-Fi network, which was created through their device. The notification is performed by means of a short visual pop-up message and an audio cue, explaining to the users that a device carried by a first responder has associated to their device.

To avoid having other devices not taking part of our experiment connecting to one of our Beacons, the victim application configures an encrypted Wi-Fi network, although the work of XX suggests that people in crisis situations are willing to open their private Wi-Fi networks. The time to enable a Beacon can range from 0.5 to 2 seconds. Given the transmission range capabilities available in current smartphones, the Beacon and Seeker devices can connect within a range of up to 100m. In the case that a responder cannot see or hear a victim, within this reach, s/he can at least receive a signal conveying that a victim’s phone is within this range. In terms of energy consumption, the work of YY shows acceptable values associated to the use of the same APIs used by our system.

Responder ApplicationThe second element of our platform is a responderapplication that sniffs radio signals in order to seek for Beacons. To trigger the discovery of Beacons the user needs to push the “Search” button (see right image in Figure 6). Then, the application enables the Wi-Fi interface of the device, i.e. the application sets up the Seeker device. The Seeker device continuously searches the environment for Beacons and the received scan results are filtered based on the particular SSID prefix set by the Beacon device. When one or more Beacons have been discovered,

associations to Beacons are carried out in a pessimistic manner, i.e. the application first connects to the Beacon with the strongest signal. Typical times to associate to a Beacon, including the trial of exchanging details, are 1.5-4s. As soon as the Seeker device is connected to the Beacon the application plays a short sound to indicate the success of connection to the device the victim is carrying. Subsequently, a background process triggers the exchange of details. Finally, the Seeker device disconnects in order to associate with remaining Beacons, which the application highlights through the “Not Notified” label (see Figure 6). Where In the case that details have been exchanged, the responder application also plays another sound and highlights this visually to the user through an eye icon (see right image in Figure 6). To look for details the user can tap on the corresponding item. Data is not persistent on the Seeker device, i.e. the victim application removes all SSIDs from its phone cache after it disconnects from a Beacon.

In order to deal with “fake” Beacons that might hamper the loop of connecting to available Beacons, the responder application tries to connect to a Beacon with a 30s timeout. If the connection to a Beacon fails the corresponding SSID is put for one minute on a blacklist. This does not hinder the process of notifying the other Beacons in range (R7).

We developed our application for the Android OS, and deployed it on a commercial phone. We don’t expect a professional first responder to use our application in such a configuration. A firefighter wearing heavy gloves cannot touch or type the small icons displayed in the UI, and any action that goes beyond two buttons is already problematic. For prototypical exploration, however, the common mobile phone used in our evaluations fitted our purposes nicely. In this caseThus, we would have already manually initiated the action to seek for Beacons, before giving the phone to an end-user.

EVALUATION

Design evaluationIt is well-known that evaluation of devices in crisis situations is problematic (see … citation mentioned in review). We evaluated our design in an underground facility used by teams of responders (ambulance, fire brigade, police and others) to train different aspects of their work. Our evaluation consisted on the introduction of our prototype in a real exercise based on the following scenario: Inside the middle of a tunnel, several people get stuck inside their vehicles due to an explosion in the back part of the tunnel. As some casualties lost network access in their phones, they launch an application that enables them to advertise emergency beacons. After a while a phone carried by a first responder discovers those beacons and connects to them in order to notify the victims of the responder’s presence. As soon as the responder is able to connect to the outside world, a report generated from the data coming from the beacons is sent to the local command center.

That is, it was as close to ‘real world’ as we could make it. During our initial tests, we placed a set of smartphones

Page 7: Help Beacons

inside some vehicles available in the facility for training purposes (see left images in Figure 7). We discovered that

Page 8: Help Beacons

Figure 7. From left to right: Field tests, Beacon placed inside bus, Boxed phone for responder, and evaluation in real exercise.sometimes the Seeker device would connect to a Beacon, but then get stuck, instead of disconnecting from the Beacon and notifying the remaining Beacons previously discovered. The reason for this was that after the connection to a Beacon succeeded, the Seeker device tries to bind to a TCP/IP socket to exchange details. For the creation of a socket connection, a certain link speed is required, which was sometimes not given as the large amount of steel inside of the tunnel weakened the signals. Also, we found out that when obtaining a scan result of a Beacon, we received a strong signal resulting in a link speed, which would normally be sufficient for establishing a socket connection. However, as we were walking or running, our position sometimes changed at the same time as the responder application tried to establish a connection. To deal with this, we revised our implementation, and introduced a connection timeout of 3s. Looking over our logs we found out that this strategy was quite helpful, as sometimes the required link speed was available right away or a bit later. After this improvement, we were able to run our tests without any technical problems in spite of the effects that the environment had on communication signals or other limitations due to the environment (R2, R3, and R7).

As our prototype proved to be robust enough, we tested it as part of a larger emergency response exercise that took place in the same underground facility. Figure 8 depicts three Beacon devices placed inside a bus and two train wagons. After a conceptual introduction, we demonstrated our prototype to the frontline officer (FO) assigned for the exercise, i.e. the firefighter who first enters the disaster scene and who provides a quick impression to the rest of the responder team. Initially, the FO expressed some reservations about the deployment of any digital technology due to bad experiences with a digital breathing device. Though, Even so, hhe agreed to test our technology. We placed the Seeker phone inside a plastic box attached to a cord hanging around the neck of the FO (see third image in Figure 7). This way we hoped the FO would not be distracted by the device (R4), and would have the possibility to grab the smartphone when he preferred to do so. During the exercise (see right image in Figure 7) the FO was able to quickly receive the help calls that convey an idea of the status of trapped people despite the situated

harsh conditions (R1). At some point the phone broke out of the plastic box, so the FO simply put the device inside his pocket, a solution that- it turned out- for the FO worked better than as our protective box.

User FeedbackAfter the design evaluation, we conducted interviews with the participants to gather feedback from end-users. The interview with the FO who used the responder application was particularly informative. From the first impression, the FO felt that using the responder application could be distracting from the actual work, especially when the first responders first enters an emergency site.

FO: For the officer in charge at the front it is difficult, as the officer does not know what is expecting her or him. For me personally it was rather distracting. (…) You know when you stand there inside the tunnel it is really difficult to focus on the application.

Apart fromof the possible distractions, the FO also mentioned that the initial focus of first responders would not be to find all trapped persons.

FO: For example, if I see there is fire, I will command that the fire hoses will be rolled out, regardless of finding persons there or not. Further, if your application detects a beacon, and tells me a person is stuck inside on one of the train wagons, but I see another person over there near to the fire, I will first rescue the person next to the fire.

The FO found the concept useful, however, for later stages of the response operation, or whereif the data collected in the field mightcould be routed to the personnel working at the remote command center. The command center could then analyze the data in order to support responders in the field to find people who may have been overlooked.

Figure 8. Beacon devices placed inside bus and two train wagons; and frontline officer entering the disaster scene.

Page 9: Help Beacons

FO: But, I see the benefit of the application in its implicit use. I mean when it is linked to a rear command center. For example, if I tell the command center we checked everything and rescued all persons, but they received a beacon call that does not match to one of the rescued persons. They can say stop, go back there and check if somebody is there.

The FO also added that the system would be useful in larger scale emergencies, which are not as constrained as the tunnel scenario, and where the focus would be more on finding missing persons.

FO: Inside the tunnel you usually find all people easily. I think it is rather helpful in large-scale disasters, such as a flooding or an earthquake. You could set up a beacon conveying a GPS or a message saying, “I live in the Main Street No. 15 and I’m stuck inside the debris”. This could be a big advantage for the search and rescue teams. You could direct upon this information a helicopter to get people from the roof. Of course, you could try to make an emergency call, but usually the dispatch center is too busy or the network is congested or damaged.

In addition to the evaluation, we conducted user workshops to prepare for an upcoming large-scale exercise. In the first workshop (see Figure 9), we explained our system in detail to a fire fighter (FF) and a police officer (PO). In general, the findings from the workshops provided additional evidence to support the finding that our technology would be useful for later stages of rescue missions:

PO: I think it would help (…) later when a search and rescue team is sent to look for any overlooked persons.

In the second workshop a professional for technical relief explained that rescue teams would follow a system of grids and sectors that they sweep systematically. The Help Beacons could be useful for making such efforts more efficient if the received information couldan be used to prioritize certain grids and sectors.

The participants provided also some feedback around the interaction of our system. The PO mentioned, for example, that both the responder application and victim application should not make any sounds but rather vibrateion in order to avoid distraction and and avoid drawing unwanted attention to the user in dangerous situations such as acts of terrorism.

Figure 9. Demo of our system during one user workshop.

LIMITATIONS AND LESSONS LEARNEDA limitation to our user study was that no “victims” havebeen evaluated. This was not possible due to safety regulations within the impact zone of the exercise (people were not allowed not allowing people to stay inside the vehicles). Alsothough, we would argue that it is difficult to define what ich person has the expertise or authority qualifies to claim being a “victim”. Even so, w, we plan to conduct evaluations in which people play the role of civilians being in distress. By doing so we hope to gain further feedback on the constraints of our system.

As indicated by ZZZ often “first responders”, in practice, are not professionals, but people from local or surrounding areas. As our system uses Wi-Fi, volunteers carrying smartphones could become aware of Beacons. Having said that, we need to consider more the larger implications when deploying our system. In this context, we need to consider to extend our s yst em for an extensible authentication protocol for our system , e.g. EAP-TLS, making it more secure against malicious Seeker devices. How our system scales in a dense environment in which many Beacons could be deployed that cause multiple reporting of the same needs, is a broader issue we need to tackle when testing our system with more than a few devices and persons. Entangled with this are situations in which behind one Beacon even more than one victim may be present behind behind one Beacon. ex posed.

Turoff points out that a system not used on a daily basis will not be used in an emergency. At the same time, the possible influences of our technologies on the prioritiz ation of help efforts raises some ethical concerns which need to be addressed in further resear ch, such as the possibility of giving people who have the technology and skills to broadcast distress signals an advantage over others. We believe that our approach of designing technology in a minimalist way, leveraging established technologies, is just a first step in making to make the technology as open and easy to use as possible, and hopefully lessens the training curve when using our system for the first time, making it more likely in the end that it will be embedded in routinely used devices. Other choices have to be made. The meanswa y of exchanging details between Seeker and Beacon devices could be improved to use UDP instead of TCP sockets, as UDP is usually faster, or a combination of both to increase the probability of exchanging packets. Further, to replac e Oour proprietary protocol might be replaced with a standard protocol installed on every mobile device, similar to emergency localization features on phones. Another open issue is to investigate into further styles of interaction with our system, such as to use vibration feedback instead of sound as proposed by the PO.

With regard to the design of the victim application, we have presented a first proof of concept. The technology works in contexts such as the tunnel of our design evaluation, which posed a complex environment to the operation of existing infrastructures. The field test and the user feedback hinted at some possible improvements to our design. The first open issue is to provide some positioning of the victims as

Page 10: Help Beacons

envisioned by the FO. In future, we plan to extend our system to log GPS positions for both applications. With

Page 11: Help Beacons

this, even if the victim application fails to retrieve a GPS fix, at least the responder application can still provide a rough indication of the position of the Beacon device. A further issue is the question of how people can install the victim application on their devices. For our field test, we assumed that the application was already installed on the devices. As this will not be always the case in practice, and as the usual app stores cannot be accessed in the conditions we are designing for, we have begun to evaluate about deployment mechanisms requiring no Internet access.

Our evaluation revealed interesting insights into the implications of our design for the practice of emergency response. The first insight is related to the design of the Seeker device. The design evaluation showed that frontline officers were skeptic towards the introduction of new technologies in general. They were considered to be potentially distracting, and that a time to appropriate the technology would be important.

FO: A few a years ago I said that I just need a simple cell phone. I don’t need to check the Internet or send emails. But, now I got used to this technology and using it to surf the Web. I think your system has a great potential. But it would need time to establish it for response work.

The emergency workers were able to see a benefit of the technology for the command room, especially in large-scale emergencies. According to our field test, the Seeker device should be designed in a way that does not require user interaction and does not hinder the work of the emergency responder in any noticeable way. To fit these requirements, we designed our device to be carried on the person and to automatically relay discovered Beacon devices to the incident command room, so that distress signals can be processed and forwarded back to the emergency response teams. The possibility of showing collected beacons on an overview map for the incident commander or in the headquarters of the first responder organizations seems to be particularly promising in this regard.

During the user workshops, it became clear that the biggest advantage identified by the emergency personal in our technology was the potential of providing a better overview over the incident site, allowing the discovery of people that might have been overlooked by the first responders entering the emergency site, and supporting more coordinated help efforts. In this sense, our technology fits into the discussion on the design of systems supporting coordination and knowledge sharing for emergency response . Not least, there is definitely value in leveraging systems that exploit established technologies as simple Wi-Fi. With regard to our study, our system proved not to interfere with existing procedures or technologies responders used during the exercise, such as walkie-talkies using analogue radio as a communication technology.

CONCLUSIONEmergency response is a domain with high stakes, and it is

important to understand more deeply how technology works in this context, which motivated us to apply a qualitative and practice-centered approach. In this paper, we have presented a design and evaluation of a lightweight mobile S.O.S system, whose use can be helpful for situations in which existing network infrastructure has become disrupted. To enable offline communications our system facilitates the discovery of emergency beacons by exploiting the Wi-Fi SSID and allows for ad-hoc constructed, short-lived connections between neighboring devices by piggybacking on the Wi-Fi handshake. From a high-level design perspective, an important aspect in the design of our system was the unforeseen exploitation of established technologies, inspired by the work in hacking and DIY communities. W e think that man y insights can be won b y payin g particular attention to the work, methods and approaches of these communities.

We need to continue evaluations of our system in ‘ close to real-world’ crisis conditions to inform our design in an iterative process. Overall, we received in our evaluation positive feedback on the potential of our technology for supporting the practices of emergency response teams, particularly in the context of large-scale emergencies. Having said that, our attention was drawn to a number of contingencies that defined the patterns of use of the proposed system. In our evaluations, we gained a better understanding of how response staff prioritize their activities, and how new technology needs to fit within priorities. As expected, finding victims is an important, but it is only one of many goals. Due to the evolving nature of emergency response work, the introduction of our system was perceived to be more useful at later stages in the process, as it needed a time for the network to emerge and stabilize.

Although systems for similar purposes or similar technologies have already been designed, our contribution lies in a simple and robust design that relies on established standards and provides a working solution in crisis situations. We designed our system with the specific goal of being used with commonly available Android devices, requiring no complex changes in the underlying mobile OS. This has significant advantages in situations where surviving network infrastructure is fragile or completely disrupted. Currently, our system is in a prototypical stage and further work is necessary. By solving technical limitations, we expect to further enhance the value of our system and widen its reach to further commercial mobile platforms.

ACKNOWLEDGEMENTSOur special thank goes to the practitioners for providing uswith thoughtful insights for emergency response. We thank the VSH Test Gallery, in particular Thomas Kulbe, for supporting us to explore our system at their premises; Wolfram Gottschlich, Mark Vinkovits and Erion Elmasslari for technical support; Monika Büscher and Volker Wulf for

Page 12: Help Beacons

reviewing earlier versions and providing valuable feedback. This work has been partially supported by the European

Union as part of the BRIDGE project (FP7SEC-2010-1).

REFERENCES