3554 ieee transactions on mobile computing, vol...

TeamPhone: Networking SmartPhonesfor Disaster Recovery

Zongqing Lu ,Member, IEEE, Guohong Cao, Fellow, IEEE, and Thomas La Porta, Fellow, IEEE

Abstract—In this paper, we investigate how to network smartphones for providing communications in disaster recovery. By bridging

the gaps among different kinds of wireless networks, we have designed and implemented a system called TeamPhone, which provides

smartphones the capabilities of communications in disaster recovery. Specifically, TeamPhone consists of two components: Amessaging

system and a self-rescue system. Themessaging system integrates cellular networking, ad-hoc networking, and opportunistic networking

seamlessly, and enables communications among rescueworkers. The self-rescue system groups, schedules, and positions the

smartphones of trapped survivors. Such a group of smartphones can cooperatively wake up and send out emergencymessages in an

energy-efficient manner with their location and position information so as to assist rescue operations.We have implemented TeamPhone

as a prototype application on the Android platform and deployed it on off-the-shelf smartphones. Experimental results demonstrate that

TeamPhone can properly fulfill communication requirements and greatly facilitate rescue operations in disaster recovery.

Index Terms—Smartphone, routing, disaster recovery

Ç

1 INTRODUCTION

DURING last decade, many communication technologieshave been applied to improve rescue efforts following

a disaster, such as deploying wireless sensor networks foremergency response [1], [2] and employing smart badges toform a mobile ad-hoc network and then gathering informa-tion from trapped survivors of structural collapse [3]. How-ever, as learned from the 2011 Great East Japan earthquake,the only helpful services in disaster recovery are those thatare used daily by everyone [4]. To provide communicationsin disaster recovery, smartphones, equipped with both cel-lular and short-range radios (e.g., WiFi, Bluetooth), are themost promising communication tools. Although cellulartowers might also be destroyed by disasters, e.g., in the 2008Sichuan earthquake [5], short-range radios of smartphonescan still provide communications. Moreover, the ubiquityof smartphones further opens great opportunities to rein-vestigate disaster recovery from the network point of view.

In disaster recovery, smartphones have the potential to bethe most feasible communication tools. For example, trappedsurvivors of a structural collapse can communicate with res-cue workers and report their position information throughthe short-range radio (e.g., WiFi) of their smartphones whenthey are within the communication range of each other.Smartphones of rescue workers can also form networks usingWiFi andmeet the communication needs in disaster recovery.

To this end, in this paper, we propose TeamPhone, a plat-form for communications in disaster recovery, where smart-phones are teamed up and work together to provide datacommunications. By exploiting WiFi and cellular modules

of smartphones, TeamPhone seamlessly integrates cellularnetworking, ad-hoc networking and opportunistic network-ing, and supports data communications among rescueworkers in infrastructure-constrained and infrastructure-less scenarios. TeamPhone also enables energy-efficientmethods for trapped survivors to discover rescue workersand send out emergency messages, by carefully addressingthe wake-up scheduling of smartphones. The emergencymessage includes the coarse-grained location and positioninformation of trapped survivors, which is derived from thelast known locations of their smartphones and the networkformed by these smartphones. We implement TeamPhoneas an app on the Android platform and deploy it on off-the-shelf smartphones. Experimental results demonstrate thatTeamPhone can properly fulfill the communication require-ments and greatly facilitate rescue operations.

The main contribution of this paper is the design, imple-mentation and evaluation of TeamPhone. This contributionbreaks down into the following aspects:

� We design TeamPhone which consists of a messag-ing system and a self-rescue system to providecommunications and facilitate rescue operations indisaster recovery. The idea of TeamPhone is moti-vated by the fact that people heavily reply on smart-phones in their daily lives.

� Themessaging system can accomplish different typesof message transmissions by bridging cellular net-works, ad hoc networks and opportunistic networks,and by connecting different routing protocols.

� The self-rescue system can send out emergencymessages with location and position informationthrough self-rescue grouping, wake-up schedulingand positioning, where we design a communicationsprotocol that can fulfill these functions in an energy-efficient manner.

� The design, implementation and evaluation arebased on off-the-shelf smartphones, which enables

� The authors are with the Department of Computer Science and Engineer-ing, The Pennsylvania State University, University Park, PA 16802.E-mail: {zongqing, gcao, tlp}@cse.psu.edu.

Manuscript received 16 Apr. 2016; revised 23 Jan. 2017; accepted 9 Apr. 2017.Date of publication 19 Apr. 2017; date of current version 1 Nov. 2017.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference the Digital Object Identifier below.Digital Object Identifier no. 10.1109/TMC.2017.2695452

3554 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 16, NO. 12, DECEMBER 2017

1536-1233� 2017 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.See ht _tp://www.ieee.org/publications_standards/publications/rights/index.html for more information.

https://orcid.org/0000-0003-3967-2704

https://orcid.org/0000-0003-3967-2704

https://orcid.org/0000-0003-3967-2704

https://orcid.org/0000-0003-3967-2704

https://orcid.org/0000-0003-3967-2704

mailto:

TeamPhone to be installed as a factory default appli-cation on smartphones by manufacturers to facilitaterescue operations in disaster scenarios.

The rest of this paper is structured as follows. We startwith the motivation and challenges in Section 2, and thenpresent the design and implementation of TeamPhone inSection 3 and Section 4, respectively. Then, we present exper-imental evaluations in Section 5, followed by the review ofrelatedwork in Section 6 and the conclusion in Section 7.

2 MOTIVATION AND CHALLENGES

In this section, we first motivate the need of networkingsmartphones in disaster recovery for communications, andthen illustrate the challenges.

2.1 MotivationDisasters, such as earthquakes, may topple countless homesand kill thousands of people. Power failures and fallencellular towers caused by disasters further leave the affectedarea cut off from the outside and hinder rescue operations.In disaster recovery, communications are crucial for coordi-nating rescue operations. Moreover, if trapped survivorsin the rubble can send out emergency messages to rescueworkers, rescue operations can be greatly accelerated.Therefore, in this paper, we investigate how to providecommunications in disaster recovery.

With the increasing penetration of smartphonesequipped with short-range radios, GPS and sensors, smart-phones have been studied for various applications, includ-ing health monitoring [6], mobile sensing [7], ad-hoccommunications [8], WiFi-based localization [9], etc. More-over, smartphones have evolved to be much more powerfulthan before in terms of computing and communications,and users heavily rely on smartphones in their daily lives.As a result, users always carry their smartphones or placesmartphones where they can easily and immediately beaccessed even during disasters. However, in disaster recov-ery such as earthquakes, the cellular towers may bedestroyed, and thus cellular communication of smartphonesis cut off. Then, we have to set up communication withshort-range radios (e.g., WiFi) of smartphones.

Smartphones have recently been conceptually consideredfor disaster recovery to locate immobilized survivors usingBluetooth in [10] and to provide multi-hop communicationsin [11]. However, Bluetooth has limited communicationrange (a few meters). The design in [10] fails to considerenergy efficiency, which may quickly drain the battery of thesmartphone. [11] also fails to conserve energy and uses pro-active routingwhich reacts slowly to the frequently changingnetwork topology in disaster recovery. It also increases themaintenance overhead in terms of network traffic andenergy consumption. In contrast to these existing works, wepropose a much more functional and energy-efficient com-munication system using smartphones for disaster recovery,andwe address various design and implementation issues.

2.2 ChallengesDuring disaster recovery, communications satellites andmobile cellular towers may be deployed. However, commu-nications satellites are scarce. Although mobile cellular tow-ers can be used to set up the command center and providecritical communications for rescue workers, such vehiclecarried towers cannot cover all disaster areas. Therefore, it

is important to network smartphones with short rangeradios in disaster recovery.

Due to themobility of rescue crews and survivors, networktopology changes frequently; i.e., sometimes smartphonesmay form amobile ad-hoc network, and sometimes they onlycontact each other opportunistically. Therefore, the big chal-lenge is how to provide communication crossing differenttypes of networks including ad-hoc networks, opportunisticnetworks, and cellular networks, considering frequent topol-ogy changes; i.e., rescue workers can communicate with eachother and with the command center no matter if they arewithin the coverage of themobile cellular towers or not.

In addition, trapped survivors may be buried in debrisand be difficult to discover. With the capability of communi-cations between smartphones, the devices of trapped survi-vors can automatically send out emergency messages tonearby rescue crews with better discoverability and reach-ability. However, broadcasting emergency messages candrain batteries quickly. Since rescue operations may last fordays after disasters occur, the discovery of nearby rescuecrews and sending out emergency messages in an energy-efficient manner is another challenge.

Moreover, it is better for trapped survivors to includetheir location information into emergency messages to facil-itate rescue operations. However, in disaster recovery, GPSand network providers are not available for localization.Providing some coarse-regained location or position infor-mation of trapped survivors, which can yet be exploited forrescue operations, is also challenging.

3 TEAMPHONE

TeamPhone is a tailored system for disaster recovery basedon smartphones, which provides seamless data communica-tion through several different types of networks and facili-tates rescue operations for trapped survivors. In thissection, we describe the network scenario of disaster recov-ery, and present the design of TeamPhone.

3.1 Network ScenarioFig. 1 illustrates the network scenario for disaster recovery.As can be seen, mobile cellular towers only cover limitedareas and provide cellular communications for rescue work-ers in these areas. A command center sits in the coveredregion and command centers in different regions may be con-nected via communications satellites. Survivors can also jointhe network to help data communications. Trapped survivorsin the debris are unable tomove and arewaiting for rescue.

When rescue workers fall out of cellular coverage, theycan only use short-range radios (e.g., WiFi) to communicate.They can communicate with each other or with the com-mand center via individuals or combinations of ad-hoc con-nections, opportunistic contacts, and cellular connections,

Fig. 1. Network scenario in disaster recovery.

LU ET AL.: TEAMPHONE: NETWORKING SMARTPHONES FOR DISASTER RECOVERY 3555

as shown in Fig. 1. Also, trapped survivors can construct agroup based on ad-hoc connections and send out emer-gency messages when rescue workers or survivors arewithin the communication range of the group. Therefore,the exploitation of smartphones can greatly extend the com-munication field far beyond the region covered by mobilecellular towers, and increase the opportunity of being dis-covered and rescued for trapped survivors.

3.2 OverviewAs shown in Fig. 2, TeamPhone includes two components:The messaging system and the self-rescue system. The mes-saging system runs on the smartphones of rescue workersor survivors and provides message transmissions. The self-rescue system runs on the smartphones of trapped survi-vors, which automatically forms groups with nearbytrapped survivors, performs positioning and sends outemergency messages.

TeamPhone works as follows. First, users need to specifywhich system to use. If smartphones are specified as part ofthe messaging system (we call them messaging nodes),users can send messages via their smartphones. Theirsmartphones will act as relays for both ad-hoc routing andopportunistic routing, and as gateways when they havecellular connections. The smartphones of trapped survivorswill be automatically configured as part of the self-rescuesystem (we call them self-rescue nodes), which is triggeredby other apps that measure seismic waves, such as iShake[12]. Self-rescue nodes are grouped and scheduled to wakeup and receive hello messages from messaging nodes. Whenself-rescue nodes receive hello messages, they will automati-cally generate an emergency message and send it to themessaging node, and then the messaging node can send theemergency message to the command center. Messagingnodes can also initiate emergency messages if needed.

3.3 Messaging SystemThe messaging system is designed to handle message trans-missions via three ways: Through cellular connections, byad-hoc communications and upon opportunistic contacts.When a messaging node needs to transmit a message (text,voice, photo, etc.), it first tries to reach the destination viathe cellular network. The message can be delivered onlywhen both the source and destination are within the regioncovered by mobile cellular towers. If direct transmission tothe cellular network fails (e.g., in the case the sender is outof the cellular coverage), the messaging system will try toreach the destination by the ad-hoc network and throughthe cellular network via ad hoc relays, i.e., the messagingnode will issue a routing request to construct a routing path

to the destination based ad-hoc communications and cellu-lar connections. If the request is fulfilled, the message canbe directly sent to the destination.

Since messaging nodes that have cellular connections actas gateways in the ad-hoc network, they can be exploited toreach the destinations that have cellular connections, such asthe command center. Therefore, the message might be trans-mitted to the gateway by ad-hoc connections and thenrelayed by the gateway to the destination by cellular connec-tions. If there is no routing path to the destination but thecommand center can be connected, the message will be sentto and stored at the command center and it will be forwardedto the destination once it enters the cellular region. Other-wise, the message will be stored locally and transmittedupon opportunistic contacts between messaging nodes, anddifferent opportunistic routing strategies can be applied.

The IP addresses of rescueworkers and survivors for theirWiFi interfaces can be assigned by the mobile cellular towerwhen they connect with the cellular network. For example,when a device first connects to the cellular network, themobile cellular tower will send out a static IP address for itsWiFi interface, and the information of other devices (e.g., thesmartphones of rescue workers) that have been alreadyassigned an IP address is shared to the device. The informa-tion is updated each time the device directly connects to thecellular network. In this way, survivors and rescue workersare aware of each other. Moreover, we do not assume thatany traffic goes beyond the cellular network and the networkformed by WiFi of smartphones. The traffic between thesetwo networks is handled by gateways as discussed above.Therefore, NAT and Internet public IPs are not needed.

3.3.1 Ad-Hoc Routing

To reach the command center via ad-hoc connections, mes-sages must be relayed at a gateway, i.e., a messaging nodein the cellular region. Suppose a reactive routing protocol isemployed (e.g., AODV routing). The messaging nodes willreply to the routing request differently, based on whetherthey are within or outside of the cellular region. Due tonode movement, messaging nodes need to monitor the sta-tus of their cellular connection and configure themselves asgateways for the routing protocol when they have cellularconnections, or vice versa.

In the following, we use AODV as an example to illus-trate how to bridge the ad-hoc network and cellular net-work via ad-hoc routing in our design. When a gatewayreceives a routing request for a destination, if it does nothave an active path to the destination, in addition to for-warding the routing request to its neighbors, it will alsosend back a routing reply with a ‘gateway’ flag and the hop

Fig. 2. Overview of TeamPhone.


count to the source. If the source receives a routing replywith an ad-hoc path to the destination before the timeout, itwill ignore the routing replies with the ‘gateway’ flag. Oth-erwise, the source will select the gateway with the mini-mum hop count, encapsulate the message and send it to thegateway. When the gateway receives the message, it willdecapsulate it, connect the destination and forward the mes-sage through its cellular interface.

3.3.2 Opportunistic Routing

In the messaging system, opportunistic routing acts as analternativewhen the destination cannot be connected via cel-lular or ad-hoc communications. Opportunistic routingworks as an application that forwards messages betweentwo nodes that encounter each other. The opportunistic rout-ing of the messaging system adopts two simple forwardingstrategies: (i) static routing where the message carried by amessaging node is forwarded only when it encounters thedestination, to save network resources such as energy andbandwidth; (ii) flood routing (also known as epidemic rout-ing) where messaging nodes that carry the message alwaysforward it to the encountered node such that the delay of themessage can be minimized. More sophisticated routingschemes tailored for rescue operation are to be considered infuturework. Note that TeamPhone is a system that can adoptany opportunistic routing protocol.

Unlike mobile opportunistic networks where nodes areisolated individually, the network in disaster recovery mostlikely consists of groups of nodes (e.g., groups of rescueworkers), where nodes within the group are well connectedvia ad-hoc communications and nodes between groups canalso be connected through other nodes, e.g., smartphones ofsurvivors. In such a scenario, ad-hoc routing is preferred formessage transmission rather than opportunistic routing.Therefore, in the messaging system, opportunistic routing isexplored only when network partitions occur and thus twosimple routing strategies are adopted rather than othersophisticated schemes based on historical contact informa-tion, such as [13], [14].

3.3.3 Routing Efforts

The messaging system differentiates messages into two cat-egories: General messages and emergency messages (byusing a flag in the message), on which the messaging systemmakes different routing efforts. Currently, the system treatsmessages from self-rescue nodes as emergency messagesand all other messages as general messages. General mes-sages are handled considering the balance between networkresource and delay, whereas emergency messages are delib-erately handled to minimize the delay. Different strategiesare adopted to handle these two types of messages.

General messages are handled in the order of cellularconnections, ad-hoc communications and opportunisticcontacts as aforementioned. If a general message has to beforwarded opportunistically, then static routing is adopted.

Emergency messages that are initiated by trapped survi-vors will be first received at nearby messaging nodes andthen forwarded to the command center for better coordina-tion of rescue operations. Since trapped survivors are usuallyfar from the regions covered by cellular towers, cellular isusually unavailable for nearby messaging nodes to send outthe emergency message. If the command center also cannotbe connected by ad-hoc communications, the emergency

message will be handled as follows. The nearby messagingnodewill forward a copy of the emergencymessage to all themessaging nodes that can currently be connected via ad-hoccommunications. Then, at each node the emergencymessageis stored and forwarded via opportunistic contacts by theflood routing. Whenever a node receives an emergency mes-sage, it will first examine whether it can forward the emer-gency message to the command center directly by a cellularor ad-hoc path. If not, it will continue the flood routing.

3.4 Self-Rescue SystemThe smartphones of trapped survivors are configured aspart of the self-rescue system and then the self-rescue sys-tem automatically sends out emergency messages when res-cue workers or survivors are nearby. The battery life ofsmartphones must last as long as possible, since rescueoperations may last for hours or even days. Therefore, theself-rescue system must be energy-efficient. Since trappedsurvivors are most likely difficult to discover, rescue crewsmay not infer the location of trapped survivors, even if theyhave received emergency messages from them. Thus, theemergency message should also provide location informa-tion to facilitate rescue operations.

3.4.1 Self-Rescue Grouping and Wake-Up Scheduling

To save energy, instead of continuously staying awake, aself-rescue node can wake up periodically to discover mes-saging nodes. However, this will increase the possibilitythat a self-rescue node is asleep when a messaging nodepasses by. Since survivors in the same building may betrapped together or nearby when the building collapses,they can group together as a self-rescue group via WiFi andwake up in a coordinated way to save energy.

The group coordination must be carefully done, since theymay still miss passing by nodes if only one node in the groupis scheduled to wake up during some time. For example, asshown in Fig. 1, node D moves around the group of trappedsurvivors. If the leftmost node is scheduled towake up and allothers are sleeping, the self-rescue node will not receive thehello message since it is out of the communication range ofnodeD. Therefore, the design of the self-rescue system shouldtake this into consideration. Note that our wake-up schedul-ing problem is similar to the sensor activity scheduling prob-lem [15] in sensor networks. However, existing work focuseson achieving full coverage by scheduling among redundantnodes, satisfying coverage ratio requirement, andmaximizingcoverage lifetime. Unlike these problems, in disaster scenar-ios, a self-rescue group most likely does not have redundantnodes (i.e., impossible to achieve full coverage by scheduling),and there is no imposed requirements of coverage ratio andlifetime. Given a network randomly formed by smartphones,our goal is achieve a good tradeoff between coverage andenergy cost, considering the characteristics of disaster scenar-ios. In the followingwe present the details of our solution.

Clique. Considering a group of nodes that coordinatewaking up, we need to decide which nodes should beawake during each time period so as to reduce energy costwhile maintaining good coverage. To do so, we consider cli-ques. In a clique there exits an edge between every twonodes, and hence any node in a clique can cover all othernodes. Therefore, in a clique nodes are close to each other,and the area covered by one node takes a large proportionof the area covered by all nodes in the clique.


Fig. 3 illustrates the ratios between the coverage of onenode and the coverage of all nodes in two-node, three-nodeand four-node cliques. In Figs. 3a, 3b and 3c, the percentageindicates the least coverage ratio for each case; i.e. the leastcoverage ratio for two-node clique, three-node clique andfour-node clique are 62.2, 48.8 and 48.9 percent, respectively,when the longest distance between nodes is exactly the trans-mission radius r. The coverage ratio increases with thedecrease of such distance. For example, when it is decreasedto r=2, as shown in Figs. 3d, 3e and 3f, the coverage ratio ofone node greatly increases and it is close to the coverage ofall nodes in the clique. Thus, instead of waking up individu-ally, nodes in a clique should wake up alternately (i.e., thereis no more than one awake node at any time in a clique) todiscover nearbymessaging nodes so as to save energy.

Wake-Up among Maximal Independent Sets. Since a networkcan be seen as being composed of maximal cliques,1 e.g., thenetwork shown in Fig. 4a consists of three maximal cliqueswhich are A ¼ fi; j; l; ng, B ¼ fi; j; kg and C ¼ fi;mg. Theproblem is how to choose a node from each maximal cliqueto wake up together so as to yield better coverage. UsingFig. 4a as an example, let us consider two node sets fn; k;mgand fj; k;mg, where three nodes of each node set are fromthese three maximal cliques, respectively. Comparing thesetwo node sets, fn; k;mg is better than fj; k;mg since the cov-erage of node k overlaps more with the coverage of node jthan node n. In other words, it is because nodes j and k areadjacent. Therefore, it is better to select the nodes from themaximal cliques such that they are not adjacent. Such a nodeset is also called themaximal independent set.2 For the networkin Fig. 4a, the maximal independent sets are fig, fj;mg,fl; k;mg and fn; k;mg, whose union equals to the node set ofthe network. A maximal independent set with more nodeshas larger coverage. However, to balance the energy con-sumption at each node, the maximal independent sets haveto be scheduled to wake up alternately.

To determine the wake-up schedule for a network, weneed to find all maximal independent sets. However, find-ing all maximal independent sets is a NP-hard problem andrequires global information of the entire network. More-over, as we will discuss later, wake-up scheduling among

maximal independent sets may not save much energy forsome nodes, compared to being always awake. To this end,we break this NP-hard problem into easier problems anddetermine the wake-up scheduling at each node in a distrib-uted way. More specifically, each node builds a one-hopnetwork, finds all maximal cliques, and determines thewake-up schedule based the schedules of other nodeswithin a maximal clique. In the following, we first brieflydescribe how to build the one-hop network at each node.

One-Hop Network. Self-rescue nodes broadcast beaconmessages to learn their neighbors. As the configuration ofself-rescue nodes is triggered automatically, e.g., by the seis-mic detection, self-rescue nodes most likely start the processsimultaneously. After a short period time a node shouldhave received beacon messages from all its one-hop neigh-bors. Let Nu denote the set of one-hop neighbors of node u.Then, they broadcast their one-hop neighbor set such that allnodes know their two-hop neighbors. Note that self-rescuenodes do not consider unidirectional links; i.e., for example,if node u receives the one-hop neighbor set of node v but Nv

does not include u, node uwill not count node v as a one-hopneighbor. Based on the information of two-hop neighbors,they can construct one-hop networks that include one-hopneighbors and edges among them, for example, as shown inFig. 4a, which is built by node i. Note that to determine themaximal cliques a node belongs to, the one-hop network issufficient, since nodes in a cliquemust be fully connected.

Scheduling Within/Across Maximal Cliques. Each nodeacknowledges its one-hop network and it can also find allmaximal cliques in the one-hop network. Although findingall maximal cliques is alsoNP-hard (it is complement to find-ing all maximal independent sets) [16], it can be easily per-formed by a node since the one-hop network is usually smallregardless of the size of the rescue group. In a maximal inde-pendent set, there are no two adjacent nodes; i.e., there has tobe no more than one awake node at any time in a maximalclique. Therefore, our scheduling should follow this rule.

Moreover, when all maximal independent sets are sched-uled alternately, the wake-ups may not be well balancedamong nodes since some nodes may belong to multiplemaximal independent sets. For example, for the networkshown in Fig. 4a, as discussed above there are four maximalindependent sets (i.e., fig, fj;mg, fl; k;mg and fn; k;mg)and node m belongs to three of them, and hence the wake-up frequency of node m is 3

4 (i.e., 34 of total rotations). This

only saves 14 energy for node m compared to always staying

awake. Therefore, we have to consider a way to further saveenergy for such nodes.

A node may belong to multiple maximal cliques and thusthe node should determine a wake-up schedule across allthese cliques. For example, in Fig. 4a, node i belongs to cli-ques A, B and C and the wake-up fraction of node i is 1=4(since there are four nodes in clique A), 1=3 and 1=2 forA, B and C, respectively. To save energy, for each node,we choose the lowest wake-up fraction of the maximalcliques it belongs to, denoted as g, as the wake-up fre-quency (e.g., gi ¼ 1=4 for node i). By doing so, the wake-up frequency for all nodes is less than or equal to thefrequency using maximal independent sets. For example,the wake-up frequencies of nodes m and k are reducedfrom 3

4 to12 and from 1

2 to13, respectively.

Furthermore, since the wake-up schedules of self-rescuenodes in the same maximal clique are dependent, to deter-mine the wake-up schedule at each node in a distributed

Fig. 3. Illustration of wireless coverage of one node in two-node clique,three-node clique, and four-node clique, where r is the transmission radius.

1. A maximal clique is a clique to which no more nodes can beadded to form another clique.

2. A maximal independent set is an independent set such that add-ing any other node to the set forces the set to contain two adjacentnodes.


way, we have to decide a scheduling order. We use the sumof wake-up fractions of the maximal cliques that a nodebelongs to as the criterion, denoted as u, to determine thescheduling order. Within a maximal clique, the node with alarger u decides first.

Fig. 4b shows the wake-up schedule of each node in thenetwork of Fig. 4a, assuming the wake-up schedule starts attime 0 and each wake-up time period is t, which is a systemparameter. The wake-up schedule of the nodes is easilydetermined following the scheduling order discussed aboveand two rules: (i) the wake-up frequency for each nodemust be g; and (ii) there is no more than one wake-up nodeat any time in a clique. Fig. 4c shows the wake-up schedulefor each clique, which is the cumulative schedule of nodesin each clique. We can see for cliques B and C, there arevacancies because node i is scheduled at gi ¼ 1=4 ratherthan 1=2 in clique C and node j is scheduled at gi ¼ 1=4rather than 1=3 in clique B. Since the vacancy ratio is low,i.e., 16.7 percent for clique B and 25 percent for clique C,and the coverage ratios are high as discussed above, theschedule vacancy only slightly affects the overall coverage;yet such wake-up scheduling can greatly save energy.

Nodes may belong to more than one clique, such asnodes i and j in Fig. 4c. When such nodes are awake, noother nodes in its clique need to wake up to save energy. Asan example, for the network of Fig. 4a, the total number ofscheduled wake-up periods of all the nodes is 22 (27 if usingmaximal independent sets) for a time period 12t as shownin Fig. 4b, while if all the nodes stay awake, the total numberof wake-up periods is 72. Therefore, we can see the schedul-ing can save about 70 percent of the energy, assuming eachnode spends the same amount of energy for each wake-upperiod t; in other words, it can extend the battery life of theself-rescue group more than three times.

Optimality. Obviously, keeping all nodes awake can guar-antee the optimality of coverage, but drain the battery quickly,while keeping only one node awake can guarantee the opti-mality of efficiency (coverage/energy), i.e., no coverage over-laps, but with the minimal coverage. Assume self-rescuenodes have the sameWiFi range and energy cost per wake-upperiod. As at most one node in a maximal clique is scheduledto wake up, there is no coverage overlap in the clique, butthere may be overlaps with nodes from other cliques. Thecombination of awake nodes in the self-rescue group at a timedetermined by our solution maximizes the coverage with itsefficiency, i.e., adding one more awake node cannot increasethe coverage without decreasing the efficiency. The proof isstraightforward. As each awake node is selected from an indi-vidual clique, additional nodewill contribute a larger overlapto the coverage and thus reduce the efficiency.

Distributed Wake-Up Scheduling. In the following, wedescribe how to determine the wake-up schedule in a dis-tributed way. Note that the distributed scheduling workson the entire network, not just the one-hop network.

As discussed above, by exchanging neighboring informa-tion, each node can construct the one-hop network and find allmaximal cliques, and it can further calculate u and g based onthemaximal cliques. Then each node floods u into the network,and after that each node acknowledges u of all other nodes.The node that has the maximum u will initiate the schedulingprocedure; i.e., it decides a reasonable start time for the wake-up schedule, determines its own wake-up schedule based ong, and then broadcasts the schedule to its one-hop neighbors.

The nodes that receive the schedule and belong to a samemaximal clique, e.g. j and k in clique B in Fig. 4a, need todetermine the scheduling order. Since uj > uk, node j goesfirst. As node k also acknowledges uj > uk, it will not pro-ceed until it receives the schedule of j. For the nodes fromdifferentmaximal cliques, e.g. nodes j andm, their schedulesare independent and thus the scheduling order does notapply to them. Since node i decides the start time of thewake-up schedule, clock synchronization is required for allthe nodes in the self-rescue group. However, smartphonesusually get the local time from network providers such thatself-rescue nodes are already synchronized with millisecondaccuracy before disasters occur. Therefore, no additionalsynchronization is required since t is at the second level.

In summary, when a node receives a schedule from aneighboring node, it first checks whether it has received theschedules from all other nodes with larger u in the samemaximal clique of the sender. If it has, it will determine itsown wake-up schedule based on the received schedulesand and broadcast the schedule to its neighbors, otherwiseit will wait for other schedules. If there are more than onenode in the maximal clique that have the same value of u,the order is determined based on node id. Eventually, eachnode has its wake-up schedule.

3.4.2 Location and Positioning

Last Known Location. When sending out emergency mes-sages, it is desired to include location information oftrapped survivors to better help rescue crews to find them.However, since trapped survivors are buried in the debris,GPS is not available. In addition, cellular towers aredestroyed and thus localization by network providers [17]is also unavailable. Therefore, for each individual smart-phone, the only location information it has is the lastknown location which is kept by the operating system(e.g., the last known location that can be retrieved from theAndroid system consists of location, timestamp, accuracyand provider). Although many apps on smartphonesrequire a user’s location to be periodically updated inbackground, the last known location does not necessarilyindicate current location. However, given a self-rescuegroup, there are still chances that the last known locationis close to the current location for some self-rescue nodes.While self-rescue nodes themselves cannot determine thatbased on the last known location they currently have, it is

Fig. 4. Illustration of one-hop network, individual wakeup schedule, and cumulative wakeup schedule of maximal cliques.


easy for rescue workers to verify the location since theyacknowledge their current location. Therefore, it is neces-sary to include all last known locations of the self-rescuegroup into emergency messages.

Coordinate System. Moreover, based on the communica-tions among self-rescue nodes, it is possible to build a rela-tive coordinate system in which the positions of self-rescuenodes can be computed. Node positions together with lastknown locations can be very helpful for rescue crews tolocate the trapped survivors quickly, e.g., the last knownlocation close to current location can be plugged into thecoordinate system to reveal the locations of other self-rescuenodes. In the following, we detail how to build the coordi-nate system for a self-rescue group.

Given a wireless network and the distances betweendirectly connected nodes (one-hop neighbors), the coordinatesystem for the network can be built as investigated in [18].The distance between one-hop neighbors can bemeasured bydifferent methods, such as Angle of Arrival, Time of Arrivaland Time Difference of Arrival. However, due to the limita-tion of the WiFi chips in off-the-shelf smartphones, the onlymethod that can currently be exploited is the Signal Strengthmethod, but this method can be easily replaced whenever amore accurate method becomes available for off-the-shelfsmartphones. The positioning method in [18] is designed formobile ad hoc networks (distances between nodes arerequired to be periodically updated and positions have to bere-computed periodically) but does not address communica-tion overhead, which is indeed very important for the self-res-cue system due to the energy constraint. Thus, we design amore efficient positioning scheme to establish a coordinatesystem for the self-rescue group. The positioning scheme isspecifically designed on top of self-rescue grouping andscheduling so as to reduce communication overhead.

First, when a node broadcasts beacon messages to buildone-hop networks, it will also include the information (e.g.,transmit power, antenna gain, etc.) that is required to com-pute the distance at receivers. When a node broadcasts itsset of one-hop neighbors, it will also enclose the distances tothese neighbors. Thus, a node will acknowledge the dis-tance of each edge in its one-hop network. For example, inFig. 4a, node i will know the distance of each edge in thenetwork. Then, node i chooses the maximal clique that con-tains the maximum number of its one-hop neighbors, i.e. cli-que A, to define a coordinate system, as illustrated inFig. 5a, and then all the nodes contained in clique A can bepositioned in the coordinate system by triangulation sinceall the distances are known (refer [18] for detail).

For other maximal cliques in the one-hop network, ifthey share an edge with the maximal clique that has been

positioned, then they can be also positioned in the coordinatesystem, e.g., cliqueB in Fig. 5a, though there are two possiblepositions for some nodes due to symmetry. For example,based on the coordinates of nodes i and j and the distancesbetween i and k and between j and k, another possible posi-tion of node k is k0. However, if node k is located at k0, itshould have discovered nearby nodes l and n, consideringtheir distances in the coordinate system. Although it is possi-ble in rare cases that node k is at the position k0, node k ismostlikely at the position shown in the figure. Therefore, the posi-tioning scheme is designed to choose the most likely positionif such cases occur. For themaximal clique that does not sharean edge with the positioned clique, the position cannot bedetermined, e.g., nodem in cliqueC, which is called outlier.

After computing the coordinate of each one-hop neigh-bor, node iwill send the coordinate information to its neigh-bors. The information also includes the distances to outliers,though they cannot be positioned by node i in the coordi-nate system. However, outliers may be positioned by othernodes in the self-rescue group with the help of the includeddistance information.

When node j receives the information, it acknowledgesits position in the coordinate system built by node i and willuse the information to compute the position of a node thatis not yet positioned in its one-hop network, i.e., node o asdepicted in Fig. 5b. Finally, in the self-rescue group, onlynode m is not positioned as illustrated in Fig. 5c. Althoughit is possible that some nodes in the self-rescue group can-not be positioned, the positioning scheme can provide theposition information of self-rescue nodes as much as possi-ble based on their connections.

Self-Rescue Group Communications Protocol. In the following,we detail how to integrate the positioning schemewith the dis-tributed wake-up scheduling so as to minimize the communi-cation overhead. The positioning is designed to be initiated atthe node with the maximum sum of wake-up fractions as thescheduling does. The node determines a coordinate system,computes the positions of its one-hopneighbors and broadcaststhem together with the determined wake-up schedule to itsneighbors. For all other nodes in the network, when it is readyto determine its own wake-up schedule, it will also computethe positions of its one-hop neighbors if needed (it is possiblethese nodes are already positioned). If the wake-up schedulingis completed, which means all of its one-hop neighbors arealready scheduled, it will flood the position information it hasinto the network. Otherwise, it broadcasts the schedule andpositions, and the process continues. Finally, all nodesacknowledge the position information of the self-rescue group.

Let us use Fig. 6 as an example to illustrate how the wake-up scheduling and positioning work together in a self-rescue

Fig. 5. Illustration of building the coordinate system for self-rescue group.


group, where the order of the process is labeled by red num-bers. 1) Since the sum of wake-up fractions of node i is themaximum, node i will initially determine its wake-up sched-ule, setup a coordinate system, compute positions for its one-hop neighbors, and then broadcast the schedule and the posi-tion information, denoted by ði�; j�; k�; l�; n�;mÞ, where �indicates the position of the node is known in the coordinatesystem. 2) Then, nodes m and j will proceed to schedulingaccording to the rules discussed in Section 3.4.1. Node j willcompute the position of node o and then broadcastði�; j�; k�; l�; n�;m; o�Þ. Since all nodes in the maximal cliquenode m belongs to have scheduled wake-up, node m willflood ði�; j�; k�; l�; n�;mÞ into the network. The process contin-ues similarly for 3), 4) and 5). Similar to nodem, nodes o and pwill flood ði�; j�; k�; l�; n�;m; o�Þ and ði�; j�; k�; l�; n�;m; o�; p�Þ,respectively, after they determine the wake-up scheduling.Finally, every node has its wake-up scheduling and the loca-tion and position information of all other nodes in the self-rescue group. The location and position information will beincluded in the emergencymessage.

The positioning works as an add-on function of self-rescue grouping and wake-up scheduling, and they areimplemented together as the self-rescue group communica-tions protocol as detailed in Protocol 1. The procedureslabeled in red are exclusively exploited for positioning,which are involved with computing positions and floodingposition information. However, these procedures incur verylittle additional overhead. The computation overhead is lowand positions are computed only once. Since only somenodes need to flood the position information, the communi-cation overhead is also low. Moreover, the last known loca-tion is flooded together with u and computed positions arebroadcast with wake-up schedules.

Note that all self-rescue nodes have to be awake duringexecuting this communications protocol. However, everynode knows when this process is complete, i.e., after it hasreceived the position information of all other self-rescuenodes. Then, each node goes to sleep and wakes up accord-ingly based on the determined schedule.

Self-rescue nodes have different battery levels and mayconsume different amounts of energy. However, each nodein such a self-rescue group always consumes much lessenergy than if it stays awake alone, while maintaining asimilar coverage. Since trapped survivors with a high bat-tery level may or may not be willing to consume moreenergy than it has to when joining the self-rescue group, wecurrently do not consider how to balance the battery levelamong self-rescue nodes, but leave it for future work.

3.4.3 Message Overhead

Let us analyze the message overhead of the self-rescue sys-tem according to Protocol 1. Each node needs to broadcast

three messages (hellomessage, one-hop neighbors andwake-up scheduling) and flood a message of u. A node also needsto flood a message of position information if it is the last onein the maximal cliques it belongs to determine the wake-upscheduling. LetN denote the number of self-rescue nodes. Inthe self-rescue group, there are 3N broadcast messages andflood messages are at most 2N2 �N . Note that nodes thatneed to flood the position information are at most N � 1.Therefore, the total message overhead of the self-rescuegroup 2ðN2 þNÞ, i.e., 2ðN þ 1Þ transmissions per node.

Protocol 1. Self-Rescue Group Communications Protocol

1: for all i 2 V2: broadcast hellomessages3: discover neighbors4: compute distances5: broadcast one-hop neighbors6: construct one-hop network7: find all maximal cliques and calculate ui and gi

8: flood ui and last known location into network9: end for10: if i ¼ argmaxj2V uj then11: determine wake-up schedule12: computing positions of one-hop neighbors13: broadcast schedule and positions14: end if15: for all i 2 V do16: when received a schedule do17: if not already scheduled && received enough

schedules then18: if received enough schedules do19: determine wake-up schedule20: computing positions of one-hop neighbors21: ifwake-up scheduling not completed22: broadcast schedule and positions23: else24: flood positions25: end if26: end if27: else28: continue to wait29: end if30: end when31: end for

3.4.4 Emergency Message

Each self-rescue node acknowledges last known locationsand position information of nodes in the group. This infor-mation will be included in emergency messages and sent torescue crews. Therefore, an emergency message includes:(1) the number of trapped survivors; (2) the time when theywere trapped; (3) the latest known location of each node; (4)the position of each node in the group.

4 TEAMPHONE IMPLEMENTATION

In this section, we describe the detailed implementation,which includes TeamPhone interface, TeamPhone routing,and TeamPhone application, where the network interfaceconfiguration and routing are implemented in C, C++ basedon Linux, and the application is implemented in Java basedon Android. The architecture of TeamPhone implementa-tion is illustrated in Fig. 7. Note that the implementationrequires the root privilege of the smartphone.

Fig. 6. Example of integrated wake-up scheduling and positioning in aself-rescue group.


4.1 The InterfaceBesides the cellular interface, smartphones are usuallyequipped with Bluetooth and WiFi. Since Bluetooth has lim-ited transmission range, WiFi is used for ad-hoc communica-tions between smartphones. Although WiFi Direct or WiFiTethering can be used to setup ad-hoc or opportunistic net-working [19], [20], they are not feasible to support multihopcommunications, which is critical in disaster scenarios, andhence we choose WiFi ad-hoc mode. However, WiFi ad-hocmode is not officially supported by Android. To enable WiFiad-hoc mode, we need to compile wireless extension supportinto the Linux kernel and also compile the wireless tool iwcon-fig for smartphones, which will be utilized to configure theWiFi driver. The configuration of WiFi includes switchingWiFi from managed mode (also known as station infrastruc-ture mode), which is the default mode of WiFi on off-the-shelfsmartphones, to ad-hoc mode, and manipulating sleep andwake-upperiods ofWiFi. Fig. 8 illustrates the status ofWiFi onSamsungGalaxy S3when being configured asmanagedmodeand ad-hocmode (theWiFi chip is BCM4330 from Broadcom).In TeamPhone, the ad-hoc routing exploits both the cellularinterface (in gateway mode) and WiFi interface, while theopportunistic routing only employs theWiFi interface.

4.2 TeamPhone RoutingAODV. In TeamPhone, we implemented AODV instead ofproactive routing protocols (e.g., OLSR) and other on-demandsource routing protocols (e.g., DSR) based on two major con-siderations: (i) network topology changes are frequent in adisaster recovery scenario, which incurs high maintenanceoverhead including network traffic and power consumptionfor proactive routing; (ii) on-demand source routing reactsslowly on path setup, restructuring and failures.

We modified the Linux implementation of AODV [21],which also has some extra features (i.e., unidirectional linksupport and a signal quality threshold) to improve theperformance of hello messages, and cross-compiled it forsmartphones. The implementation includes two compo-nents: A loadable kernel module and a user-space daemon.The kernel module captures data packets usingNetfilterwithPOSTROUTING, which requires the Linux kernel with Net-filter enabled, and instructs the user-space daemon to issue arouting request if the destination of the packet is out of routeentries. In addition, the kernel module is in charge of encap-sulating and decapsulating the packet that goes throughgateways. The user-space daemonmaintains the kernel rout-ing table and controls neighbor discovery, routing requestand routing reply. The communications between these twocomponents are based onNetLink socket.

In disaster recovery, messaging nodes monitor the avail-ability of cellular connections and configure themselves as

gateways for AODV if the cellular connection is valid. Tomaximize the reachability of messages, if the destinationcannot be reached by AODV, the message can be temporar-ily stored at the command center through gateways and themessage will be delivered to the destination once it connectsto the command center. We have integrated this functioninto the implementation of AODV. Table 1 shows the set-tings of major parameters of AODV in our implementation.

DTN2. In TeamPhone, opportunistic routing is accom-plished by DTN2 [22], which is a Linux implementation ofthe DTN bundle protocol defined in RFC 5050 [23]. We cus-tomized and cross-compiled DTN2 for smartphones. DTN2is a platform that can adopt any opportunistic routing proto-cols, working at the application layer and running as a user-space daemon. The network interface configured for DTN2is WiFi in ad-hoc mode. The basic workflow of DTN2 onsmartphones is as follows. First, a convergence layer needsto be configured, which is used to transmit messagesbetween smartphones. We choose the TCP convergencelayer to guarantee the message transmission. Next, servicediscovery will advertise the convergence layer’s presence toneighbors. Meanwhile a node also listens for neighbor bea-cons and distributes each event of neighbor discovery to theconvergence layer. Then, DTN2 performs message transmis-sions with neighbors according to the configured routingprotocol. Static routing and flood routing are two currentlysupported routing protocols in TeamPhone.

4.3 TeamPhone ApplicationThe TeamPhone application wraps the messaging systemand self-rescue system together, implemented in Java onAndroid system. When TeamPhone is launched, WiFi will

Fig. 7. Architecture of TeamPhone implementation.

Fig. 8. WiFi status when being configure as managed mode and ad-hocmode.

TABLE 1Parameter Settings of AODV

Parameter Setting

hello broadcast interval 1 s# of hellos before treating as neighbor 3Allowed hello loss 2Routing request timeout 4 sRouting request retries 2Routing reply ACK timeout 50 msActive route timeout 10 s


be configured as ad-hoc mode and users need to specifywhich system to use.

For the messaging system, AODV and DTN2 are initial-ized for routing, and themessaging app is provided for usersto send and receive messages. Messages can be sent in threeways: (i) through AODV to reach the destination; (ii) by gate-ways to store the message at the command center fromwhich the message will be eventually delivered when thedestination connects to the command center (e.g., nodes peri-odically fetch messages from the command center directly orthrough gateways); (iii) by DTN2 in static routing mode andflood routing mode. In the prototype, the first method is thedefault and other two are optional. The messaging system isalso designed to receive emergency messages from self-res-cue nodes and forward them to the command center. Thehellomessage from the messaging node and self-rescue nodeis flagged differently so as to deal with the unidirectionallink between messaging node and self-rescue node, whereonly the messaging node can receive hellomessages from theself-rescue node. In that case, the messaging node will notreceive the emergency message from the self-rescue nodessince the self-rescue nodes are unable to discover the mes-saging node. The messaging node can still be alerted byreceiving the hello message, and this alert function is imple-mented together with the user-space daemon of AODV.

The self-rescue system performs self-rescue grouping,wake-up scheduling and positioning in the background. Forthe case that trapped survivors may not have the opportunityto start self-rescue system manually, TeamPhone can employ

iShake [12], which exploits smartphones as the seismic sensor,3

to trigger the self-rescue system automatically when an earth-quake occurs. After wake-up scheduling, self-rescue nodescan configure the determinedwake-up schedule ofWiFi usingiwconfig; i.e., they need to enable WiFi power managementand set up the period between wake-ups and the timeoutbefore going back to sleep (i.e., �). When self-rescue nodes areawake, they run AODV to detect messaging nodes in theirvicinity and send out the emergency message once they dis-cover themessagingnode. The function of sending emergencymessages is embedded into the daemon of AODV.

5 EVALUATIONS

TeamPhone is deployed on off-the-shelf Android smart-phones, i.e., Samsung Galaxy S3. We built a small testbed offour S3 smartphones, as shown in Fig. 9, to evaluate the per-formance of TeamPhone. We do note that there exist designsfor communications in disaster recovery. However, few areimplemented as real systems and none provides system

evaluation. Thus, we cannot compare themwith TeamPhonein the evaluation. As discussed in Section 2, TeamPhoneclearly outperforms these works inmany aspects of design.

5.1 Messaging SystemIn the experiments, one smartphone has a cellular connec-tion and works as a getaway. We also deploy a server whichcan be connected through the cellular network by smart-phones to store and forward messages. This server acts asthe command center in disaster recovery. Fig. 10 illustratesthe user interface for sending messages, viewing messagesand settings.4 In Fig. 10a, the first checkbox corresponds tothe ad-hoc routing with the getaway mode and the secondcheckbox corresponds to the opportunist routing. In themessaging system, messages are transmitted over TCP con-nections (TCP convergence layer for DTN2) to guaranteethe delivery.5 The current implementation of TeamPhonecan accomplish the following ways of message transmis-sions: i) sending by AODV (including through gateways);ii) sending by AODV-Gateway-Server-Gateway-AODV;iii) sending by DTN2. In the following, we evaluate the mes-saging system in terms of power consumption, throughputand delay, which are important aspects of a communicationsystem in disaster recovery. We also show how opportunis-tic routing can facilitate messaging transmissions and obtainbetter performance than with only ad-hoc routing.

Power. The message system should be energy-efficient.To measure the power, the Monsoon Power Monitor is usedto provide constant power to the smartphone instead ofusing battery. Fig. 11 illustrates the power when the smart-phone is operating in different modes, where all the meas-urements are conducted when the smartphone’s screen isoff and the power is averaged over one minute. As can beseen, when WiFi is off, the smartphone consumes about10 mW. When WiFi is on and configured in ad-hoc mode,the power consumption increases significantly, to about200 mW, because WiFi in ad-hoc mode has to be at theworking stage to transmit and receive messages. When themessaging system with AODV (the hello message interval isone second) is running on the smartphone without user-space data traffic, it incurs very little additional power.Similarly, the running of DTN2 only consumes very little

Fig. 9. Testbed.

Fig. 10. Messaging system.

3. iShake needs to continuously measure the seismic wave. How-ever, since a large earthquake typically lasts more than 30 seconds, itonly needs to perform the measurement in a 30-second interval andhence its energy consumption should not be significant.

4. The messaging app is developed based on the open-source soft-ware MANETManager [24].

5. TCP in ad hoc wireless networks may experience throughput deg-radation [25], due to path length, packet loss, etc. However, since themessaging system is not throughout-intensive and requires more reli-able transportation of packets, we choose TCP.


power. From Fig. 11, we can conclude that the basic powerconsumption of the messaging system (with both AODVand DTN2) is about 200 mW, which is mainly consumed bythe WiFi module. For the Samsung Galaxy S3 with batteryof 2100mAh and 3.8V, the estimated standby time is about40 hours when running the messaging system.

Table 2 gives the measured average power of the smart-phone during oneminutewhenAODV is configuredwith dif-ferent hello message intervals. As can be seen, the power fordifferent intervals varies slightly. Although intuitively morefrequent hello messages should incur more power, the differ-ence is too small compared to the power when WiFi is in ad-hoc mode (as shown in Fig. 11). Therefore, the power is notthemajor concernwhenwe choose the hellomessage interval.

The hello message interval of AODV in TeamPhone is setto one second based on the following considerations. WhenAODV sends hello messages more frequently, such as twohello messages per second, it will cause more network traf-fic, especially when the network has many nodes. Whenhello messages are sent less frequently, AODV will react tothe change of network topology slowly and thus in turnaffect the performance of AODV. For example, when thehello interval is four seconds, the reaction delay to a neigh-bor change is about eight seconds, since the allowed loss ofhello messages is two as in Table 1. Moreover, as observedfrom the experiments, the power consumption for differenthello message intervals only vary slightly. Therefore, inTeamPhone, the hellomessage interval is set to one second.

Throughput. Since transmitted messages could be photo,voice, even video, we also measure the throughput of themessaging system as shown in Figs. 12 and 13, where the

WiFi module of the smartphone S3 supports IEEE 802.11 a/b/g/n. Fig. 12 illustrates the throughput between twodirectly connected smartphones. The maximum throughoutis over 20Mb/s, and it decreases linearly with the increase ofthe distance between two smartphones. When the transmis-sion distance is 100 meters, the throughput drops to about 2Mb/s. Fig. 13 shows the throughput on a two-hop ad-hocpath, constructed by AODV. As can be seen, the throughputof both one-hop paths is about 6 Mb/s. The throughput oftwo-hop drops to 3Mb/s due to the increase of hop count.

Delay. Fig. 14 shows the round-trip delay of message pass-ing with AODV. As expected, the delay increases with thehop count, and the delay for one-hopmessage passing is low(about 20 ms). For two-hop and three-hop, the delay is about40 ms and 60ms, respectively. Unlike one-hop, where neigh-bors are already in the routing table, multi-hop requires rout-ing path discovery if the destination is not in routing table.Thus, the delay variations of two-hop and three-hop aremuch higher than themedian values as shown Fig. 14.

Benefits of Opportunistic Routing. The incorporation ofopportunistic routing is designed to enhance the performanceof themessaging system as demonstrated in Figs. 15 and 16.

In Fig. 15, node S needs to send a message to node D.Node S first performs path discovery of AODV. However,neither S, R1 nor R2 can contactD due to a physical obstacle

Fig. 11. Power consumption when the smartphone is in different modes.

TABLE 2Power When AODV with Different HelloMessage Intervals

hello interval 0.5 s 1 s 2 s 3 s 4 s

Power (mW) 203.86 203.30 203.56 203.21 201.79

Fig. 12. Throughput as a function of distance between two directly con-nected smartphones.

Fig. 13. Throughput in terms of hop count.

Fig. 14. Round-trip delay of AODV on smartphones.

Fig. 15. Movement helps data transmission.


as shown in Fig. 15. Therefore, the connection between Sand D cannot be established using AODV (or any ad-hocrouting) and the message transmission is failed. Such a sce-nario is common in disaster recovery. Nevertheless, ifopportunistic routing is deployed, the message can be repli-cated at R1 and R2 first since R1 and R2 can be reached fromS, and then the message can be delivered when any of themmoves closer to D and establishes a connection with D.Therefore, opportunistic routing can take advantage ofnode movement to accomplish message transmissions; thedelay is mainly determined by the physical movement.

In Fig. 16, node S is sending amessage toD throughmulti-hop connection between them. However, the link betweenR2

and D is suddenly broken due to channel interference, orphysical obstacles. If only ad-hoc routing is used, S has to re-transmit the message toDwhen the link betweenR2 andD isback, and a new route discovery has to be initiated. Withopportunistic routing, the messaging system can handle sucha scenario with better performance as follows. When the linkbetween R2 and D is broken, the messaging system can dis-tribute the message to other nodes (i.e., R1 and R2) on thepath to the destination. When the link is valid again, the mes-sage can be directly transmitted to node D by R2 instead ofthree-hop communications from S to D. Therefore, messagereplication of opportunistic routing can greatly acceleratemessage transmissions. Based on the experiments on thetestbed, for the scenario in Fig. 16, the round-trip delay can bedecreased from about 60ms to 20ms, and the throughput canbe increased from about 1Mb/s tomore than 6Mb/s.

From these two scenarios, we can see opportunisticrouting can greatly facilitate message transmissions andimprove the performance of the messaging system.

5.2 Self-Rescue SystemFor the self-rescue system, we first need to determine thewake-up period t. As self-rescue nodes wake up to discoverthe messaging node, t should be long enough such that theycan receive the hello message from the messaging node andsend out the emergency message. Since self-rescue nodeswake up alternately in a clique, t should be short enough sothat the self-rescue node is awake when messaging nodes arepassing by. Based on these considerations and the parametersettings of AODV, t is set to 5 seconds in the experiments.

Power and Energy. Table 3 shows the power and energyconsumption of the self-rescue system. When nodes areasleep (WiFi goes to sleep), they consume very little power,similar to that when WiFi is turned off. When they areawake, the power consumption is similar to that of messag-ing nodes as in Fig. 11. According to the wake-up schedul-ing, the worst case of energy consumption is when the sleepperiod of a self-rescue node is also t (i.e., the self-rescuenode only belongs to a two-node clique). In that case, theenergy consumption is about 1076mJ for a sleep period anda wake-up period (totally 10 seconds) as shown in Table 3.

To measure the power consumption of the self-rescuegroup, we use the four smartphones to form groupswith dif-ferent network topologies, as shown in Fig. 17a. There arefive different network topologies, denoted as t1, t2, t3, t4 andt5. For each topology, we first determine the wake-up sched-ule and then measure the total power consumption of thegroup. In Fig. 17b, awake indicates the power consumptionwhen all the nodes stay awake. As can be seen in Fig 17b, ourwake-up scheduling is always better than awake, andthe power consumption is less than half of awake. When thenetwork contains a larger clique, the self-rescue group con-sumes less power. For example, as t3 contains a three-nodeclique while t2 contains a two-node clique, the power con-sumption of t3 is less than that of t2. Similarly, t5 (four-nodeclique) is less than t4 (three-node clique). Moreover, thepower consumption of t5 is only 1=3 of awake. For smart-phone S3, the standby time of the group when running theself-rescue system is about 70 hours for t1 and 125 hours fort5. Therefore, we can conclude that the self-rescue systemcan greatly save energy and thus increase the possibility ofbeing discovered in rescue operations for trapped survivors.

Message Overhead and Positioning. Fig. 17c shows themessage overhead of the self-rescue system for differenttopologies. The message overhead includes both wake-upscheduling and positioning. As depicted in the figure, theoverhead of wake-up scheduling is the same for differenttopologies since it only depends on the number of nodes inthe self-rescue group.Meanwhile the overhead of positioningvaries on different topologies, which depends on the numberof nodes that belong to only one clique or are the last one inthe cliques it belongs to determine the wake-up scheduling,as discussed in Section 3.4.3. Fig. 17d depicts the percentageof positioned nodes in these network topologies. For t1 andt2, half of nodes can be positioned; while all the nodes can be

Fig. 16. Replication reduces transmission delay.

TABLE 3Power and Energy Consumption of the Self-Rescue System

Power (mW) Energy (mJ) Time period (s)

Wake-up 202.30 1011.5 5Sleep 12.98 64.9 5

Fig. 17. Power, message overhead and positioned nodes of self-rescue groups in different topologies.


positioned in t4 and t5. Therefore, we can see thatmore nodescan be positioned if the group contains a larger clique.

To investigate the performance of positioning in a self-rescue group, we use the four smartphones to form a10 m� 10 m square (a four-node clique). The smartphonesare placed as the black square in Fig. 18b. Each node meas-ures the distances to its neighbors using signal strength asdiscussed in Section 3.4.2. As there are two distance meas-ures for each node pair, e.g., the measures of nodes A andDfor AD, the smartphone will use the mean value as the dis-tance. The distance measures on the smartphones are shownin Fig. 18a. Fig. 18b shows the coordinate built by node Ausing AB0 as the x-axis and the positions of other nodes (B0,C0 and D0). There is distortion of the positions due to themeasurement error. D00 could be a possible position for D.However, as the measured distance between BD (13.97 m)is much larger than the distance of B0D00, D00 can beexcluded. The edges in red are used by A to calculate theposition of each node, and the measured distance of BD isused to exclude D00. Fig. 18c shows the coordinate built bynode B. Since the measure of BD is more accurate than AC(compare to 10

ffiffiffi

2p

m), the distortion is alleviated. Similarly,C00 can be excluded as a possible position of C. As the nodepositions in the coordinates built by different nodes can bedifferent, the self-rescue group has to use one coordinate toposition all the nodes as discussed in Section 3.4.2.

Fig. 19 illustrates the message overhead of self-rescuesystem in terms of the size of self-rescue group. Figs. 19aand 19 b respectively give the total message overhead of thegroup and the message overhead per node. Since varioustopologies may have different message overhead, in thefigure, we label the minimum and maximum overhead ofall possible topologies for a certain size of self-rescue group.As the message overhead for a given network topology isfixed, we calculate the message overhead for each networktopology based on the communications protocol for a cer-tain size of self-rescue group. As depicted in Figs. 19a and19b, the message overhead increases with the size of thegroup. Although larger group incurs more message over-head, the overhead at each node just increases linearly andthe self-rescue group is usually small in disaster recovery.With a few exchanged messages, self-rescue nodes are ableto cooperatively and efficiently wake up and compose theemergency message that includes location and positioninformation of the self-rescue group.

6 RELATED WORK

Research efforts have been made to apply communicationtechnologies to disaster recovery. Many researchers focus onusing ad-hoc networks. Zussman et al. [3] proposed toemploy the network formed by smart badges to collect infor-mation from trapped survivors. Reina et al. [26] extensively

evaluated ad-hoc routing protocols in disaster scenarios.Aschenbruck et al. [27] modeled mobility in disaster areasand investigated how the model affected network perfor-mance of ad-hoc routing protocols. Other researches takeopportunistic networks into consideration. Mart�ın-Campilloet al. [28] proposed a random walk gossip protocol that runsover ad-hoc networks. Asplund et al. [29] evaluated the effi-ciency of opportunistic routing protocols in disaster scenar-ios. Uddin et al. [30] proposed a multicopy opportunisticrouting for disaster response networks. Fujihara and Miwa[4] proposed disaster evacuation guidance using opportunis-tic communications. A more detailed survey of ad-hoc net-works for disaster scenarios can be found [31].

Although many researchers have contributed to improv-ing rescue and evacuation operations, only few considersmartphones. In the literature, [10] and [11] are the mostrelated work to this paper. Suzuki et al. [10] proposed adesign to assist the search for immobilized persons in adisaster area using Bluetooth of smartphones. However,Bluetooth of smartphones only has limited communicationrange (maximum 10m), and the design does not considerenergy efficiency and can quickly drain the battery.

Nishiyama et al. [11] assume that smartphones can becharged by mobile solar cells and thus did not considerenergy efficiency. However, in disaster scenarios, solar cellsmay not be accessible for survivors, and thus the designedsystem can only provide temporary communications.Among the related works, few are implemented as real sys-tems and none provides system evaluation. However,TeamPhone is designed, implemented, and evaluated basedon off-the-shelf smartphones and ready to be installed onsmartphones to provide communications and facilitate res-cue operation in disaster scenarios.

7 CONCLUSION

In this paper, we propose TeamPhone, which is designed tonetwork smartphones in disaster recovery. TeamPhoneincludes two components: The messaging system that pro-vides data communications for rescue workers, and the self-rescue system that groups the smartphones of trapped sur-vivors together, energy-efficiently discovers nearby messag-ing nodes and sends out emergency messages includinglocation and position information. TeamPhone is imple-mented as a prototype application on the Android platformusing the WiFi interface and cellular interface to provideseveral ways of communications. TeamPhone has beendeployed and evaluated on the off-the-shelf smartphones.The evaluation results demonstrate that TeamPhone canaccomplish various message transmissions with affordablepower consumption and delay, and greatly reduce theenergy consumption of sending out emergency messagesby grouping and wake-up scheduling.

Fig. 18. Positioning in a self-rescue group (a four-node clique), wherefour smartphones form a 10m� 10m square. Fig. 19. Message overhead in terms of the size of self-rescue group.


ACKNOWLEDGMENTS

This work was supported in part by Network Science CTAunder grant W911NF-09-2-0053 and CERDEC via contractW911NF-09-D-0006. A preliminary version of this workappeared in Proceedings of IEEE PerCom 2016 [32].

REFERENCES

[1] K. Lorincz, et al., “Sensor networks for emergency response:Challenges and opportunities,” IEEE Pervasive Comput., vol. 3,no. 4, pp. 16–23, Oct. 2004.

[2] S. George, et al., “Distressnet: A wireless ad hoc and sensor net-work architecture for situation management in disaster response,”IEEE Commun. Mag., vol. 48, no. 3, pp. 128–136, Mar. 2010.

[3] G. Zussman and A. Segall, “Energy efficient routing in ad hoc disas-ter recovery networks,” in Proc. IEEE INFOCOM, 2003, pp. 682–691.

[4] A. Fujihara andH.Miwa, “Disaster evacuation guidanceusing oppor-tunistic communication: The potential for opportunity-based service,”inBigData Int Things ARoadmap Smart Environ., 2014, pp. 425–446.

[5] “Powerful quake ravages china, killing thousands,” (2008). [Online].Available: http://www.nytimes.com/2008/05/13/world/asia/13china.html

[6] X. Sun, Z. Lu, W. Hu, and G. Cao, “Symdetector: Detecting sound-related respiratory symptoms using smartphones,” in Proc. ACMInt. Joint Conf. Pervasive Ubiquitous Comput., 2015, pp. 97–108.

[7] M.-R. Ra, B. Liu, T. F. La Porta, and R. Govindan, “Medusa: A pro-gramming framework for crowd-sensing applications,” in Proc.10th Int. Conf. Mobile Syst. Appl. Services, 2012, pp. 337–350.

[8] C. Shi, V. Lakafosis, M. H. Ammar, and E. W. Zegura,“Serendipity: Enabling remote computing among intermittentlyconnected mobile devices,” in Proc. 13th ACM Int. Symp. MobileAd Hoc Netw. Comput., 2012, pp. 145–154.

[9] Y. Wang, J. Liu, Y. Chen, M. Gruteser, J. Yang, and H. Liu,“E-eyes: Device-free location-oriented activity identification usingfine-grained WiFi signatures,” in Proc. 20th Annu. Int. Conf. MobileComput. Netw., 2014, pp. 617–628.

[10] N. Suzuki, J. L. F. Zamora, S. Kashihara, and S. Yamaguchi,“SOSCast: Location estimation of immobilized persons throughSOS message propagation,” in Proc. 4th Int. Conf. Intell. Netw. Col-laborative Syst., 2012, pp. 428–435.

[11] H. Nishiyama, M. Ito, and N. Kato, “Relay-by-smartphone: Realiz-ing multihop device-to-device communications,” IEEE Commun.Mag. vol. 52, no. 4, pp. 56–65, Apr. 2014.

[12] M. Ervasti, S. Dashti, J. Reilly, J. D. Bray, A. Bayen, and S. Glaser,“iShake: Mobile phones as seismic sensors – user study findings,”in Proc. 10th Int. Conf.Mobile UbiquitousMultimedia, 2011, pp. 43–52.

[13] Z. Lu, X. Sun, Y. Wen, and G. Cao, “Skeleton construction inmobile social networks: Algorithms and applications,” in Proc.IEEE 11th Annu. Int. Conf. Sens. Commun. Netw., 2014, pp. 477–485.

[14] Z. Lu, X. Sun, Y. Wen, G. Cao, and T. La Porta, “Algorithms andapplications for community detection in weighted networks,”IEEE Trans. Parallel Distrib. Syst., vol. 26, no. 11, pp. 2916–2926,Nov. 2015.

[15] B. Wang, “Coverage problems in sensor networks: A survey,”ACM Comput. Surveys, vol. 43, no. 4, pp. 32:1–32:53, 2011.

[16] D. Eppstein, M. L€offler, and D. Strash, “Listing all maximal cli-ques in large sparse real-world graphs,” J. Exp. Algorithmics,vol. 18, pp. 3.1:3.1–3.1:3.21, 2013.

[17] Wireless Emergency Response Team, “Final report for the Sep-tember 11, 2001 New York City world trade center terroristattack,” 2001, [Online]. Available: http://www.emtel.etsi.org/Workshop/Non-presented_papers/Wert%20final%20report.pdf

[18] S. �Capkun, M. Hamdi, and J.-P. Hubaux, “GPS-free positioning inmobile ad hoc networks,” J. Cluster Comput., vol. 5, no. 2, pp. 157–167, 2002.

[19] S. Trifunovic, B. Distl, D. Schatzmann, and F. Legendre, “WiFi-opp: ad-hoc-less opportunistic networking,” in Proc. 6th ACMWorkshop Challenged Netw., 2011, pp. 37–42.

[20] M. Raj, K. Kant, and S. K. Das, “E-DARWIN: Energy aware disas-ter recovery network using WiFi tethering,” in Proc. 23rd Int. Conf.Comput. Commun. Netw., 2014, pp. 1–8.

[21] “AODV-UU,” (2015). [Online]. Available: http://aodvuu.sourceforge.net

[22] “DTN2,” (2015). [Online]. Available: http://www.dtnrg.org[23] “RFC 5050,” (2007). [Online]. Available: https://tools.ietf.org/

html/rfc5050

[24] “MANET Manager,” (2015). [Online]. Available: https://github.com/ProjectSPAN/android-manet-manager

[25] C. S. R.Murthy and B.Manoj,AdHocWireless Networks: Architecturesand Protocols. Upper Saddle River, NJ, USA: PrenticeHall PTR, 2004.

[26] D. Reina, S. Toral, F. Barrero, N. Bessis, and E. Asimakopoulou,“Evaluation of ad hoc networks in disaster scenarios,” in Proc. 3rdInt. Conf. Intell. Netw. Collaborative Syst., 2011, pp. 759–764.

[27] N. Aschenbruck,M. Frank, P.Martini, and J. Tolle, “Humanmobilityin MANET disaster area simulation-a realistic approach,” in Proc.29th Annu. IEEE Int. Conf. Local Computer Networks, 2004, pp. 668–675.

[28] A. Mart �ın-Campillo, J. Crowcroft, E. Yoneki, and R. Mart,“Evaluating opportunistic networks in disaster scenarios,”J. Netw. Comput. Appl., vol. 36, no. 2, pp. 870–880, 2013.

[29] M. Asplund and S. Nadjm-Tehrani, “A partition-tolerant many-cast algorithm for disaster area networks,” in Proc. 28th IEEE Int.Symp. Reliable Distrib. Syst., 2009, pp. 156–165.

[30] M. Y. S. Uddin, H. Ahmadi, T. Abdelzaher, and R. Kravets,“Intercontact routing for energy constrained disaster responsenetworks,” IEEE Trans. Mobile Comput., vol. 10, no. 12, pp. 1986–1998, Oct. 2013.

[31] D. Reina, et al., “A survey on ad hoc networks for disasterscenarios,” in Proc. Int. Conf. Intell. Netw. Collaborative Syst., 2014,pp. 433–438.

[32] Z. Lu, G. Cao, and T. La Porta, “Networking smartphones fordisaster recovery,” in IEEE Int. Conf. Pervasive Comput. Commun.,2016, pp. 1–9.

Zongqing Lu received the BE and ME degreesfrom Southeast University, China, and the PhDdegree in computer engineering from NanyangTechnological University, Singapore, 2014. He iscurrently working as a postdoctoral scholar in theDepartment of Computer Science and Engineer-ing, Pennsylvania State University. His researchinterests include networked mobile systems,mobile and pervasive computing, and networking.He is the member of the IEEE.

Guohong Cao received the BS degree from XianJiaotong University, China, and the MS and PhDdegrees in computer science from the Ohio StateUniversity, in 1997 and 1999, respectively. Sincethen, he has been with the Department of Com-puter Science and Engineering, PennsylvaniaState University, where he is currently a profes-sor. His research interests are wireless networksand mobile computing. He has published morethan 150 papers in the areas of wireless sensornetworks, wireless network security, vehicular ad

hoc networks, cache management, data access and dissemination, anddistributed fault tolerant computing. He has served on the editorialboards of the IEEE Transactions on Mobile Computing and IEEE Trans-actions on Wireless Communications and has served on the organizingand technical program committees of many conferences. He was arecipient of the NSF CAREER award in 2001. He is a fellow of the IEEE.

Thomas F. La Porta received the BSEE andMSEE degrees from The Cooper Union, NewYork, NY, and the PhD degree in electrical engi-neering from Columbia University, New York,NY. He is the director of the School of ElectricalEngineering and Computer Science at PennState University. He is an Evan Pugh Professorand the William E. Leonhard Chair professor inthe Computer Science and Engineering Depart-ment. He joined Penn State, in 2002. He was thefounding director of the Institute of Networking

and Security Research at Penn State. Prior to joining Penn State, hewas with Bell Laboratories where was the director of the Mobile Network-ing Research Department. He also won two Thomas Alva Edison PatentAwards. He was the founding editor-in-chief of the IEEE Transactionson Mobile Computing. He has published numerous papers and holds39 patents. He is the fellow of the IEEE and Bell Labs.

" For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.


http://www.nytimes.com/2008/05/13/world/asia/13china.html

http://www.nytimes.com/2008/05/13/world/asia/13china.html

http://aodvuu.sourceforge.net

http://aodvuu.sourceforge.net

http://www.dtnrg.org

https://tools.ietf.org/html/rfc5050

https://tools.ietf.org/html/rfc5050

https://github.com/ProjectSPAN/android-manet-manager

https://github.com/ProjectSPAN/android-manet-manager

3554 ieee transactions on mobile computing, vol...

Documents