Efficient Location-aware Message Delivery forEncounter Networks

Igor Zavalyshyn, Nuno O. Duarte, Nuno Santos

INESC-ID / Instituto Superior Tecnico, Universidade de Lisboa

Abstract. Location-aware mobile applications have grown in popular-ity. Existing applications, however, rely mostly on centralized architec-tures for nearby friend discovery and message forwarding, which forcesusers to constantly reveal privacy-sensitive location information to ser-vice providers. We present SpotNet, a middleware system for Androidthat provides location-aware message delivery service for opportunisticnetworks. SpotNet is based on short-range Bluetooth communicationto exchange messages while precluding the existence of a trusted cen-tralized service. SpotNet addresses the challenges of efficient messageforwarding and resource utilization, and uses location-aware routing toselect next hop for message forwarding based on ‘closeness’ to destina-tion. We implemented SpotNet on the Android platform. Experimentalresults demonstrate that our approach is practical in real life scenarios.

1 Introduction

Generalized interest is growing in a class of mobile applications for location-aware message delivery. Facebook, Foursquare, and FireChat are examples ofsuch applications, which allow users to search and communicate with friendsclosely located. Facebook and Foursquare rely on a centralized architecture toenable nearby friend discovery and message relay between users’ mobile devices.Friend discovery functionality is provided by maintaining a central database ofapproximate user locations inferred from a device’s WiFi or 3G network inter-faces. FireChat adopts a similar centralized architecture, but complements itwith a fallback mechanism in case there is no Internet connectivity. In particu-lar, FireChat leverages WiFi Direct or Bluetooth to detect nearby friends andto establish a peer-to-peer (P2P) network for local message exchange.

However, a consequence of such a centralized architecture is that location in-formation collected by users’ devices must be surrendered to the service provider.All this information can then be centrally aggregated by a single entity and beexploited or shared with third parties without users’ knowledge or consent, e.g.,to provide additional services or targeted advertisement [11, 12, 16, 21]. In suchsituations, users have little or no control of their data once its uploaded to serviceprovider servers [4, 6, 7].

In this paper, we aim to investigate the feasibility of an alternative but prac-tical architecture for providing location-aware message delivery while preservingusers’ privacy. In particular, we wish to explore a fully decentralized solution in

which both friend discovery and message forwarding operations can take placeby relying exclusively on the opportunistic interaction between users’ devices:no centralized service should be involved in order to provide this functionality.We seek to design a system that is practical (i.e., works with modern unmodifiedsmartphones and mobile devices), energy-efficient, and general enough to allowclient applications to take advantage of its services.

We present SpotNet, a middleware system for Android which provides pri-vate location-aware message exchange capability between any set of devices ina mobile ad-hoc network without relying on any cloud infrastructure or Inter-net connectivity. Through a simple API, application developers can easily embedSpotNet’s message delivery functions into their own mobile apps. Through Spot-Net, users can send messages either directly or through the set of intermediatenodes, so-called ‘carriers’, that are unaware of messages’ content. Messages canbe sent generically to all mobile devices located around certain spots, i.e., specificgeographical points such as coffee shops, streets, or indoor spaces within shop-ping malls, etc. To enable decentralized message delivery, we use location-basedforwarding to opportunistically select suitable ‘carriers’ based on their previouslocation track. For energy efficiency reasons, location-based routing is achievedby relying on small low-powered Bluetooth devices called beacons which serveas stationary markers deployed across the city in shops and restaurants, and areused for checkpointing the location track of each node in the network. Beaconsemit unique IDs which can then be used to refer to specific geographic spots.

Regarding its novelty, SpotNet can clearly distinguish itself from existingencounter-based applications previously developed for Android platforms suchas FireChat [8] or Haggle [17]. These applications use Bluetooth or WiFi Directcommunication to exchange files or messages between nearby devices. To the bestof our knowledge, SpotNet is unique at both: 1) providing a multi-hop messagedelivery capability without requiring any support from fixed infrastructure, and2) leveraging a beacon infrastructure for location-based message forwarding.We implemented SpotNet on Android and our preliminary experimental resultsdemonstrate the feasibility of our approach.

2 Related Work

A lot of work, especially theoretical one, has been carried out in the field ofmobile ad hoc networks (MANETs). In general, MANETS consist of wirelessnetworks of mobile devices which can form opportunistically. In such networks,adequate routing algorithms are fundamental for network performance. Messagerouting must constantly adapt to moving network nodes (i.e., mobile devices).Many routing algorithms abound, ranging from epidemic [22] where informationpropagates by flooding the network with multiple copies of the same message,to more sophisticated algorithms that consider geographic location of the nodeand its distance from the destination [14, 15] as well as to node mobility pat-terns [10,13]. SpotNet leverages some of this work by using a combination of thegeographic routing algorithm with the spray-and-wait technique [18, 24]. Mes-

sages thus propagate in a specific direction of destination and their number islimited to efficiently use available resources and avoid network congestion.

Several mobile applications such as Haggle [17], AllJoyn [23] or FireChat [8]use device-to-device (D2D) communication to disseminate information in thenetwork. Users can express their interests in the specific topic and receive no-tifications from nearby users that have similar interests. These applications useBluetooth or WiFi Direct radio for communication between users. Internet con-nection is not needed in this case since messages are sent directly from device todevice. However, as opposed to SpotNet, in these applications, message deliveryis possible only between devices connected in the same wireless network.

EnCore is a social platform [1] that provides an interface for secure andprivacy-preserving communication. In EnCore, co-located devices establish aunique encounter ID and a shared key that is used for secure communicationbetween selected users. Similarly to SpotNet, discovery of new devices is doneperiodically. However, although EnCore provides a secure and reliable D2D com-munication platform, it does not support message forwarding between devicesthat are not immediate neighbors of each other. SpotNet on the other handprovides such functionality by default and relies on location-aware routing todeliver messages from sender to receiver in a timely manner.

3 SpotNet Design

We present the design of SpotNet, a middleware system for Android platformswhich provides a location-aware message delivery service for opportunistic net-works. This middleware consists of a library that is linked with client mobileapplications. Its basic message delivery service is provided through a simple APIwhich basically allows for sending and receiving messages. SpotNet API providessimple send and receive primitives. In addition to the message itself, send takesas input the location of the desired destination nodes (explained in Section 3.2).The receive primitive runs a service that waits for incoming messages.

The underlying infrastructure assumed by SpotNet comprises two types ofhardware components. On the one hand, there are mobile devices owned bySpotNet users. These devices coincide with the network nodes of SpotNet. Inaddition to offering end-users an interface for sending and receiving messages,nodes are responsible for relaying messages between users. Messages are stagedon the nodes and carried along until other nodes appear within their wirelessrange that can deliver the message closer to its destination with higher prob-ability. This is the so-called pocket-switched networks [10] which tend to havea structure that is correlated with human movement patterns and the set ofplaces visited on a daily basis. On the other hand, SpotNet also relies on a set ofstationary devices named beacons whose role is to advertise a fixed location toSpotNet’s mobile devices. Beacons can be deployed anywhere in places of interestand emit a unique ID. In order to send a message, users must specify the locationof receiver nodes. The location is denoted in terms of “spots”, i.e., collections ofbeacon IDs. SpotNet ensures that all the nodes that can sense the given beacon

can receive the messages destined for this location. SpotNet leaves message secu-rity up to the application layer and provides best-effort delivery guarantees. Dueto the opportunistic operation mode of SpotNet’s routing mechanism, messagedelivery latency may sometimes be too high for certain applications. We leaveit up to applications themselves to adopt a complementary transport service inorder to speed up message delivery if necessary.

Next, we describe the main design features of SpotNet focusing on: device dis-covery and basic D2D communication mechanisms, message addressing scheme,location-aware routing, and message forwarding.

3.1 Energy-efficient Device Discovery and Communication

To enable device discovery and communication, SpotNet leverages Bluetooth,which is widely deployed, and is more energy-efficient than comparable tech-nologies, such as WiFi [3]. Current Bluetooth specifications [3] require devicesto be paired before any data connection can be established. However, such kindof interaction is cumbersome in SpotNet scenarios. To send or receive a message,users would need to manually pair their devices with the devices of users theyencounter on the way. This process not only slows down device discovery andmessage transfer procedures, but also prevents device interaction in situationswhere users are not familiar with each other.

To overcome existing limitations of Bluetooth pairing and preclude the in-volvement of the user in device discovery and message forwarding, we utilizeinsecure Bluetooth sockets [9]. Bluetooth sockets are supported by most of An-droid smartphones nowadays and enable connections to be established betweendevices without pairing. The side-effect of this is that built-in authenticationmeasures are disabled. Nevertheless, authentication and encryption may be per-formed on higher levels of the application. In SpotNet, the sender initiates aconnection by creating an insecure Radio Frequency Communication protocol(RFCOMM) socket connection waiting for a response from the receiver that isconstantly listening for incoming connections. Once the socket has been estab-lished, the RFCOMM protocol proceeds by creating a channel for data transfer.This channel is later destroyed when the data transfer is successfully completed.

3.2 Location-based Message Addressing Scheme

A central goal of SpotNet is to offer a location-based message delivery service.To specify device locations, one possible approach is to leverage GPS interfacesbundled into modern phones to obtain the current device position and use GPScoordinate ranges as addressing scheme. However, keeping the GPS sensor activeeven for short time periods yields high battery consumption. Due to severe bat-tery drainage, users tend to keep the GPS positioning system turned off mostof the time. Moreover, GPS can not be used indoors, thus limiting the scopeof possible locations in the user profile. WiFi- or 3G-based location servicescould alternatively be used. However, not only do they also require access tothe energy-inefficient WiFi interface, but can also reveal the device location to

a third-party, thereby potentially compromising users’ privacy. In fact, a devicecould be tracked by just following the device MAC and knowing the SSIDs ofdeployed WiFi APs, for example across a city or inside a shopping mall.

To overcome the hurdles of GPS and WiFi, we propose to use a network ofbeacons, i.e. small low-powered Bluetooth-enabled devices that are distributedacross the city. We envision beacons to be deployed at various places, e.g. at mainbus stations, business centers, shopping malls, universities, museums, restaurantsand cafes. Beacons play the role of location anchors that are constantly adver-tising their location to nearby devices such that passer-by users can detect thisadvertisement and store the location ID. The main advantage of this approachis its power efficiency [19]. Beacons use Bluetooth Low Energy (BLE) [3], alow-power wireless technology for communication with smartphones and otherdevices. Since many smartphone users keep the Bluetooth radio active, the in-teraction with beacons and other users becomes seamless. Moreover, beacons arepassive elements that emit wireless signals only. As a result, beacons cannot keeptrack of devices’ location therefore preserving users’ privacy. Another benefit isthat beacons can also be adopted for indoor location tracking.

Depending on beacons, however, could raise some concerns about cost andmaintenance effort. We address such concerns, firstly, by observing that beacontechnology is relatively inexpensive. As of now, the prices for BLE-beacons canstart from as cheap as 5 USD a piece with wireless range up to 50 meters depend-ing on the battery level and configured transmission power [2]. Secondly, ratherthan depending on a single entity to deploy and maintain beacon hardware,which requires significant investment and maintenance effort, SpotNet’s beaconinfrastructure is fully decentralized. In particular, beacons are deployed indepen-dently by unrelated parties (beacon providers), e.g., a coffee shop, a parking lot,a shopping mall, etc. A beacon provider only needs to buy and deploy beaconsto cover a geographical area of interest. Thus, any shop owner can buy a beaconand deploy it at his place. SpotNet devices can sense the MAC address emittedby each beacon and use it as a location anchor for routing purposes. This list oflocations is stored and constantly updated by SpotNet devices. To allow usersto easily refer to a given location, beacons’ MAC addresses can be named interms of spots, i.e., human-readable aliases that can refer to locations that userscan understand (e.g., “McDonalds”, “Downtown”). Spots can be used to identifythe destination of messages. SpotNet ensures it will be delivered to devices sur-rounding the beacons covered by that particular spot. Beacon addresses can bemapped to spot names by users themselves or through an intermediate directoryservice. SpotNet’s decentralized architecture allows the beacon infrastructure togrow organically and economically. Note that, although SpotNet uses beaconsas its primary location-sensing technology, GPS or WiFi may alternatively beused within the city areas where beacons have not yet been deployed.

3.3 Location-aware Routing

A message is considered to have arrived to its destination if it has been receivedby the nodes located in the vicinity of destination spot, i.e., to the nodes that can

sense at least one of the beacons of the spot’s beacon set. The question is thenhow to route the messages between sender and destination nodes considering thatmessages must be propagated as SpotNet devices interact opportunistically.

SpotNet exploits the fact that individuals tend to follow certain patterns byvisiting the same set of places over and over again: their homes, working places(e.g., office, university), restaurants, etc. Such patterns normally reflect users’daily routines and tend to be fairly stable over time [5]. SpotNet leverages thatregularity as a way to predict which spots a given device will likely visit in thefuture: messages that are destined to one of such spots, can then be piggybackedin that device in order to reach its destination with high probability.

To materialize this idea, each SpotNet device maintains a location profile foreach user which includes a history of the spots visited by the user. Periodically,each user device runs a Bluetooth discovery process in order to detect nearbybeacons. Once a beacon is detected, the node adds the location ID and currenttimestamp to the user’s location profile. The location profile keeps track of thespots’ visiting patterns of a given user. If other users know at least some of thosefrequently visited spots they can efficiently forward their messages towards thedestination’s location. To do so, they would need to relay the message throughthe phones of other users, i.e., carriers, that are more likely to go near thedestination. To determine potential message carriers for certain spots, in additionto detecting nearby beacons, SpotNet’s Bluetooth discovery process also locatesnearby user devices and exchanges location profiles with them. Based on theinformation contained in the received location profile, a node updates a routingmatrix which indicates for each carrier node C (indicated in the matrix’s lines)the probability that C visits a given destination spot S (indicated in the matrix’scolumns). This probability is calculated by determining the fraction of time (e.g.hours) in which C was able to sense a beacon of spot S considering a predefinedtime period (e.g., a day or a week). This fraction can be determined triviallythrough direct inspection of C’s location profile. For privacy issues, users mayspecify which places from their location profile they do not want to be disclosed(e.g. home or office locations). Alternatively, users may decide not to share thefull location profile with other users, but only its probability vector, i.e., the lineof the routing matrix which corresponds to the spot visiting probability of thatparticular device. To avoid unlimited growth of the routing matrix, it is alsopossible to limit its maximum number of lines (NL) and columns (NC). In thatcase, SpotNet fills in the routing matrix based on the most recently visited NL

spots and encountered NC carrier nodes. The routing matrices maintained bySpotNet nodes represent then each node’s location pattern and play a centralrole in the message forwarding algorithm, as explained in the next section.

3.4 Message Forwarding Algorithm

As mentioned above, SpotNet’s routing decisions are based upon devices’ prob-ability to visit certain spots. The message forwarding algorithm implementedby SpotNet leverages this information to identify which devices are potentiallygood candidates to speed up message delivery by carrying it to its destination.

SpotNet’s message forwarding algorithm has to analyze the line in the routingmatrix that corresponds to the encountered device and compare it with the des-tination spot specified in the message. The message is relayed if the spots of boththe encountered location profile and the destination location are equal—i.e., amatch exists—otherwise it is stored until a better candidate is found.

The main challenge, however, is to decide if a match exists. For efficient mes-sage forwarding, the number of devices involved in the delivery of each messagemust be limited but still provide high delivery rates. At the same time, devicediscovery has to be performed as often as possible to detect beacons and othernearby users while keeping in mind battery consumption. In other words, mes-sage forwarding solely based on the location profile results in multiple carriers ofthe same message. Every message consumes memory and CPU resources of thecarrier and limits the amount of messages it can create and store. This kind ofapproach is similar to epidemic routing [22] where information is disseminatedbetween all the encountered nodes using pair-wise message exchange. Even if thescope of possible message carriers is limited by selecting only those whose prob-ability of reaching the destination spot is non-null, multiple message duplicateswill still be produced, thereby increasing network resource usage inefficiency.

To reduce the number of message copies circulating across the network, Spot-Net limits the number of times each message is forwarded by leveraging thespray-and-wait technique [20]. According to it, during the first phase of the rout-ing process, the sender ‘sprays’ a message into the network by forwarding it tothe number of encountered devices. During the second phase, all the resultingmessage carriers including the sender itself store the message and ‘wait’ untilreaching the destination device. Once the final recipient appears within the ra-dio range of any of them, the message is finally delivered. We use spray-and-waittechnique in combination with location-aware forwarding. Each message has aspray counter in the header which is updated by each message carrier. Once thiscounter reaches a specific value, the message can not be forwarded further but isinstead stored until reaching the destination. By doing so we specifically limit thenumber of hops in order to reduce the message delivery overhead. Initiating theBluetooth connection and establishing the RFCOMM sockets with the detecteddevices is a time- and resource-consuming process. Therefore, devices perform itonly if the messages they carry can still be forwarded further according to thespray count, or if they come across the destination device. To avoid repeatedconnections, every device maintains the list of devices it contacted recently. Theconnection to a device is only initiated if it does not appear in the list.

4 Implementation

We implemented the SpotNet functionality as a middleware layer for AndroidOS. SpotNet code was written in Java. To test our system, we implementeda client application which provides users with a simple interface to send andreceive messages to and from other users visiting specific spots. This applicationallows users to communicate even if they do not know each other in person. It

Fig. 1: Location profiles of two users: Alice (left) and Bob (right).

could be used, for example, to ask for directions to the nearest metro station, ornotify visitors of a specific place of upcoming events.

Once the client application is installed and activated, it requests permissionsto turn on Bluetooth radio and make a device discoverable. As mentioned above,the SpotNet middleware runs a device discoverability service to allow the deviceto participate in the SpotNet network. Every device runs the discovery processevery 20 seconds. The list of detected devices is then analyzed and processedaccordingly. If a beacon is detected, the SpotNet middleware updates the locationprofile with the beacon’s MAC address and current time. If any other device isdetected, it exchanges profiles, refreshes the routing matrix, and implements themessage forwarding algorithm described in Section 3.4. In case there are messagesto be delivered to the device (i.e., the current device location coincides with themessage’s destination spot), the SpotNet middleware notifies the application ofthe incoming message. The application reads the message from an internal bufferof the SpotNet middleware, and displays the message to the local user. (Figure 1illustrates the location profiles of two users as shown by our client application.)

In order to send a message to a specific user, the sender needs to know thedestination spot. In our implementation, the SpotNet middleware provides anAPI call that allows the client application to associate spot names to beacon’sMAC addresses. The application offers a simple visual interface that allows theuser to manage their spots and internally propagates that association to theSpotNet middleware through this API call.

Internally, the SpotNet middleware appends multiple parameters to everymessage. These parameters include: a unique identifier, the number of timesit was forwarded (spray count), the MAC addresses of sender and destinationspot’s beacons, name of sender spot, and name of destination spot. In our cur-rent implementation, the list of all the deployed beacons is hard-coded into theapplication so that the user can just select them from a drop-down list.

Fig. 2: Location of beacons during the indirect message forwarding experiment

5 Evaluation

We evaluated our SpotNet prototype using a small-sized experimental setup.The main goal of the experiments was to address the following questions:

– How do messages propagate in a SpotNet network, particularly if next hopis selected based on its location profile? (Section 5.1)

– How does the SpotNet client application running on users’ devices affectbattery consumption? (Section 5.2)

Experimental Setup. We used a small setup consisting of: three LG Nexus 4 andone Samsung Galaxy S4 smartphones all running Android OS, with the SpotNetapplication installed, and four Bluetooth Low Energy beacons iBKS105. Thesmartphones were given to 4 users working at different rooms of the same floorat the INESC building. We deployed beacons at each room and integrated theirIDs and corresponding locations into the application (see Figure 2). Users couldcommunicate either directly by being at the same room, e.g. during a meeting,or by message passing through other users’ devices. To avoid false records in thelocation profiles, the advertising power of each beacon was configured in a waythat it could only be detected within a couple of meters around it.

5.1 Message Propagation

To evaluate SpotNet’s message propagation mechanism, we tested our clientapplication under two scenarios. In the first scenario, a message is sent directlyto another device located in the same room. In the second scenario, a message issent to a remote device indirectly using intermediate devices as message relays.

1. Direct message transmission. We start from the first application scenario inwhich two users Alice and Bob are sitting in the same room within the rangeof beacon B1 (see Figure 2). Alice creates a message which is addressed to Bob,

writes a message text, specifies his location and clicks the Send button. Themessage is then stored in the message buffer. Since both devices are within thewireless range of each other they are detected during the discovery process andall the available messages are sent directly without requesting the location profileinformation. The message was delivered in 17 seconds. The delay is caused by thediscovery process since it takes 12 seconds on average to complete. Additionaltime is needed to initiate a connection and open the socket. (This process maybe accelerated by using the latest 4.1 version of Bluetooth.) Although a messagewas delivered directly to destination, spray count was still incremented by one.

2. Indirect message transmission. In the second application scenario, a messageis relayed from the sender to the receiver by intermediate users. In this experi-ment, Alice sends a message which arrives to Bob’s location relayed by Charlie.Initially, Alice, Bob, and Charlie are placed apart from each other located closeto beacons B1, B2, and B3, respectively. Since Bob and Charlie work in contin-uous rooms, Charlie’s device is also able to sense beacon B2. The experimentstarts when Alice creates a message for Bob using the SpotNet application. Asdestination spot of the message, Alice uses a spot ID that comprises beacon B3,which is placed in the meeting room of Bob’s department. Since there is no directconnection between Alice and Bob’s devices, the message is then stored in thebuffer while the application is looking for devices to deliver it to the recipient.We then recreate a scenario in which Alice and Charlie meet each other in thekitchen area during the coffee break. This opportunity allows devices to becomedirectly reachable and exchange location profiles. Since Charlie and Bob workin the same department, Charlie’s device probability of reaching B2 is greaterthan zero and SpotNet forwards Alice’s message to Charlie’s device. Eventually,Charlie returns to his office and encounters Bob. Once SpotNet detects Bob’sdevice, the message is automatically sent to his device through direct communi-cation and the message arrives to its final destination. In total, this experimenttook approximately 1 minute, from which 34 seconds were taken up by SpotNet’spoint-to-point protocols performed between devices.

Summary. The experiment results showed that the forwarding mechanism worksas intended in case of direct and indirect communication. For direct communica-tion the message delivery delay mainly depends on the device discovery duration.For indirect communication next hop is selected based on location profile infor-mation. In case of multiple devices detected with the same location profile, thealgorithm selects the device that is supposed to be at the location of destinationearlier. Location-aware routing based on beacon deployments provides a simpleand energy-efficient alternative to GPS-based routing protocols.

5.2 Battery Consumption

As mentioned in Section 3, device discovery and message forwarding are costlyprocedures in terms of energy consumption. To measure the battery consump-tion of SpotNet, we carry out an experiment in which two SpotNet clients are

Fig. 3: Battery consumption of SpotNet application

constantly exchanging messages between each other every 20 seconds during a 6hour period. The spray count update function is intentionally disabled so thateach client repeatedly discovers nearby devices, requests their location profileand forwards the message. Batteries are initially fully charged on both devicesand the battery level is measured every minute while the experiment is running.All other applications are disabled on both devices and flight mode is activated.We consider the case when neither SpotNet nor other applications are runningas a baseline for the experiment.

Figure 3 shows our results. SpotNet continuously running on the device andexchanging messages every 20 seconds consumes only 10% of the battery in 6hours. The battery level changes linearly and steadily. These results show thatSpotNet can be efficiently used on modern smartphones without significantlydegrading their autonomy. Combined with automatic sleep mode in user-definedlocations, it can seamlessly run in the background during the whole day. Thisfactor is essential for network growth and overall user satisfaction.

6 Conclusion

We presented SpotNet a privacy-aware decentralised message delivery middle-ware that allows users to communicate without relying on Internet connectivityand cloud infrastructure. Location-aware message forwarding based on beaconsmay be efficiently used in a city environment where they are deployed in variouspublic places. Interaction with these devices is seamless to the user and does notrequire any user attention. We implemented the SpotNet logic in the form ofmiddleware for Android OS. Preliminary evaluation demonstrates the feasibilityof this approach in real life scenario and display modest energy-consumption.

Acknowledgments: This work was partially supported by the EC through project

H2020-645342 (reTHINK), and by national funds through Fundacao para a Ciencia e

a Tecnologia (FCT) with reference UID/CEC/50021/2013 (INESC-ID).

References

1. Aditya, P., Erdelyi, V., Lentz, M., Shi, E., Bhattacharjee, B., Druschel, P.: En-Core: Private, Context-based Communication for Mobile Social Apps. In: Proc. ofMobiSys (2014)

2. Aislelabs: The Hitchhikers Guide to iBeacon Hardware: a Comprehensive Reportby Aislelabs (2015) (2015), http://www.aislelabs.com/reports/beacon-guide

3. Bluetooth, S.: Bluetooth Specification Version 4.2. Bluetooth, SIG (2014)4. Boggs, B.C., Edwards, M.L.: Does What Happens on Facebook Stay on Facebook?

Discovery, Admissibility, Ethics, and Social Media. ILL. BJ (2010)5. Camp, T., Boleng, J., Davies, V.: A survey of mobility models for ad hoc network

research. Wireless communications and mobile computing (2002)6. Cheng, J.: Are Deleted Photos Really Gone from Facebook? Not Always. Ars

Technica (2009)7. Cheng, J.: ‘Deleted’ Facebook Photos Still Not Deleted. Ars Technica (2010)8. Cohen, N.: Hong Kong Protests Propel FireChat Phone-to-Phone App. The New

York Times pp. 26–28 (2014)9. Google: Android API documentation (2016), http://developer.android.com

10. Hui, P., Chaintreau, A., Scott, J., Gass, R., Crowcroft, J., Diot, C.: Pocket SwitchedNetworks and Human Mobility in Conference Environments. In: Proc. of theWDTN (2005)

11. Kincaid, J.: Senators Call Out Facebook on Instant Personalization, Other PrivacyIssues. TechCrunch, April (2010)

12. Kravets, D.: Judge Approves $9.5 Million Facebook ‘Beacon’ Accord. The Wired,March 5, 125–126 (2010)

13. Lindgren, A., Doria, A., Schelen, O.: Probabilistic Routing in Intermittently Con-nected Networks. ACM SIGMOBILE 7(3) (2003)

14. Mauve, M., Widmer, J., Hartenstein, H.: A Survey on Position-based Routing inMobile Ad Hoc Networks. Network, IEEE 15(6), 30–39 (2001)

15. Perkins, Charles and Belding-Royer, Elizabeth and Das, Samir: Ad Hoc On-demand Distance Vector (AODV) Routing. Tech. rep. (1999)

16. Sandberg, S.: The Role of Advertising on Facebook. The Facebook blog, July (2010)17. Scott, J., Crowcroft, J., Hui, P., Diot, C.: Haggle: a Networking Architecture De-

signed Around Mobile Users. In: Proc. of WONS (2006)18. Shah, R.C., Roy, S., Jain, S., Brunette, W.: Data Mules: Modeling and Analysis

of a Three-tier Architecture for Sparse Sensor Networks. Ad Hoc Networks (2003)19. Siekkinen, M., Hiienkari, M., Nurminen, J.K., Nieminen, J.: How Low Energy

is Bluetooth Low Energy? Comparative Measurements with ZigBee/802.15.4. In:Proc. of WCNCW (2012)

20. Spyropoulos, T., Psounis, K., Raghavendra, C.S.: Spray and Wait: an EfficientRouting Scheme for Intermittently Connected Mobile Networks. In: Proc. ofWDTN (2005)

21. Steel, E., Fowler, G.: Facebook in Privacy Breach. The Wall Street Journal 18,21–22 (2010)

22. Vahdat, A., Becker, D., et al.: Epidemic Routing for Partially Connected Ad HocNetworks. Technical Report CS-200006, Duke University (2000)

23. Wang, Y., Wei, L., Jin, Q., Ma, J.: AllJoyn Based Direct Proximity Service Devel-opment: Overview and Prototype. In: Proc. of CSE (2014)

24. Zhao, W., Ammar, M., Zegura, E.: A Message Ferrying Approach for Data Deliveryin Sparse Mobile Ad Hoc Networks. In: Proc. of MobiHoc (2004)