Aggregation in Smartphone Sensor Networks

Nimantha Baranasuriya�, Seth Gilbert�, Calvin Newport†, Jayanthi Rao‡

�Department of Computer Science, National University of Singapore†Department of Computer Science, Georgetown University‡Research and Advanced Engineering, Ford Motor Company

{nimantha, seth.gilbert}@comp.nus.edu.sg, cnewport@cs.georgetown.edu, jrao1@ford.com

Abstract—The first wave of sensor network deployments fromthe early 2000s relied on aggregation—a strategy in which read-ings are combined locally using low-power radio links before theyare communicated to the gateway. Aggregation reduced depen-dence on battery-draining, long-distance radio links, and reducedredundancy among reported data. We are now experiencing asecond wave of sensor network research driven by ubiquitoussmartphone usage. In this paper, we study the application ofaggregation to the new smartphone sensor network setting,arguing that it can help reduce costs in contexts where existingcost-reduction strategies, such as opportunistic use of Wi-Fi anddata piggybacking, do not apply. In more detail, we propose twonew aggregation protocols, designed for the challenges of highmobility, that offer trade-offs in terms of bandwidth and energysavings. We then evaluate these protocols using both testbedexperimentation (using a collection of 11 Samsung Galaxy Nexussmartphones running a NoiseTube-like application) and trace-based simulation (using a large collection of mobility traces fromtaxi cabs in Singapore). Our experiments demonstrate that ouraggregation protocols reduce cellular bandwidth usage by up to95% while losing less than 5% of the data. Moreover, in manycommon cases, our protocols also yield significant energy savings.

Keywords—data aggregation; smartphones; mobile networks;

I. INTRODUCTION

In the early 2000s, the idea of deploying sensor networksto collect data on the world we live in became a major researchfocus within the computer science community. Teams aroundthe world soon developed the needed hardware platformsand then filled in the network stack layers above. By mid-decade, sensor networks had been successfully deployed inmany contexts, from zebras [1] to volcanoes [2].

Of the many technical insights needed to make the firstwave of sensor networks possible, one of the most importantwas the idea of aggregation. Early on, researchers noted that itis impractical to have every device in a sensor network reportits readings individually to the gateway using long-distanceradio links—these links are energy-intensive and many of thereported readings are redundant. The alternative approach wasto use low-power links to locally gather and aggregate networkdata before reporting [3]–[5].

In this current decade, we have seen a resurgence ofinterest in sensor networks, driven by the rise of the ubiquitoussmartphone usage. These phones, which have now passedthe billion user mark worldwide [6], provide ideal platformsto deploy sensor network applications: they are equippedwith sensors, they have both local/low-power (e.g., Bluetooth)

and long-distance/high-power (e.g., 3G/4G) radios, and aresupported by an infrastructure that makes it easy to disseminatenew applications. Not surprisingly, therefore, many researchershave taken advantage of this appealing platform to designand launch a large number of smartphone sensor networkapplications; e.g. [7]–[9].

We note that the issues that drove the original sensornetwork pioneers to aggregation strategies still exist in thecontemporary context of smartphone networks: devices havelimited batteries, reported readings are often redundant, andlong distance links are more power-intensive than local links.This setting also introduces a new issue: long-distance linksnow have a potential monetary cost as they typically usethe phone owner’s limited cellular data plan. There are twostandard solutions to these problems in the smartphone con-text. The first is to make opportunistic use of existing Wi-Fi infrastructure to upload data without relying on cellularlinks (e.g., [10], [11]), and the second is to piggyback sensorapplication data to other traffic, when possible (e.g., [12]).

These solutions have been shown effective in reducingcellular/energy costs in some scenarios. At the same time,however, we emphasize that there are many scenarios wherethese strategies do not apply. Open Wi-Fi networks, for ex-ample, are increasingly rare, and in highly mobile contexts(e.g., vehicular) discovering and connecting to such networkscan be difficult. In addition, smartphone sensor applicationsoften gather and upload data in periods where the phoneis not already in use (e.g., uploading traffic observationswhile driving), making piggy-backing inapplicable. In thesescenarios, existing smartphone sensor networks fall back tothe default expensive approach of requiring every device toindividually report its readings to the gateway using long-distance/high-power/non-free cellular links.

In this paper, we argue that aggregation strategies arewell-suited for these scenarios where smartphone applicationscannot count on other networks or unrelated phone usage toreduce costs. In other words, the aggregation idea that servedthe first wave of sensor networks so well has an importantrole to play for this new generation. To validate this claim,this paper provides the following contributions:

1. We first demonstrate that aggregation strategies studiedin the first wave sensor networks perform poorly in thecontemporary context of smartphone sensor networks, due tothe more dynamic mobility profile.

2. Based on this observation, we design two novel dataaggregation algorithms designed to meet the unique demands

2014 IEEE International Conference on Distributed Computing in Sensor Systems

978-1-4799-4618-1/14 $31.00 © 2014 IEEE

DOI 10.1109/DCOSS.2014.25

101

of smartphone sensor networks (partitioning, rapid topologychanges, etc.).

3. We present an Android-based framework with a simple APIfor application developers to use our protocols when designingsensor applications for smartphone sensor networks.

4. Using a prototype running on a 11 Samsung Galaxy Nexussmartphone testbed, we show that our protocols can yield a∼75% reduction of cellular links and cellular bandwidth usage,while providing non-negligible energy savings (∼20%).

5. Using trace-based simulations, we demonstrate that ourprotocols save cellular bandwidth (up to ∼95%) and energyusage (up to ∼75%) even in highly dynamic settings (i.e.,when devices move at vehicular speeds). Moreover, we showhow the performance varies with different network parameters.

The rest of this paper is organized as follows. Section IImotivates our aggregation strategies. Section III presents ouraggregation protocols, and we discuss the implementation ofan Android-based framework for aggregation in Section IV.Section V presents evaluation preliminaries. Our empiricalstudies are reported in Section VI and VII. We discuss deploy-ment practicalities in Section VIII followed by related work inSection IX. Finally, we conclude in Section X.

II. MOTIVATION

In the first wave of sensor networks, there were twomain approaches to aggregation: tree-based [5] and cluster-based [4]. The tree based approach constructs a spanning-tree rooted at the gateway. Parents collect readings from theirchildren and then aggregate it before passing it up to their ownparent. There were two shortcomings with this approach: (i)the structure was not robust—a single failure could partitionthe network; and (ii) it might place an unfair cost on the nodesnear the root (gateway) in the tree. These issues motivated thecluster-based alternatives, such as LEACH [4], where devicesconsolidate their data at the nearest clusterhead (which istypically selected randomly and in a rotating fashion); theclusterheads then aggregate the data and send it on to thegateway using long-distance links.

Though these protocols were designed to be resilient tosome changes in network connectivity, they were not meantfor the rapid continuous topology changes of highly-mobilesmartphone sensor networks. In this section, we quantifythis intuition by simulating a pair of first-wave cluster-basedstrategies using the trace-based experimental setup describedin Section VII. (We do not simulate tree-based aggregation assuch algorithms assume static topologies that will clearly failunder even a small amount of topology churn.)

The first aggregation protocol we evaluate, which wecall Basic LEACH, is a simplified version of the classicalLEACH protocol [4]. In this protocol, each device electsitself to be a clusterhead with some fixed probability p. Theclusterheads then contact their neighbors. Devices join thecluster led by the nearest clusterhead, and then reverse routetheir data to this clusterhead for aggregation and uploading.

An obvious issue with LEACH in the mobile setting is thatthe reverse route to a clusterhead might be invalid by the timea device learns of it. With this in mind, we study a second

protocol, Simple Clustering, that replaces the reverserouting of data with a more aggressive bounded-flood.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

10 50 100 150 200

Dat

a Lo

ss (

%)

Number of Clusterheads

Basic LEACH

(a) Performance of Basic LEACH

0

50

100

150

200

250

300

350

400

50 200 400 600 800 1000 1200 1400 1600 1800 2000N

umbe

r of

Upl

oade

rsNetwork Density

Simple Clustering (p=0.2)Simple Clustering (p=0.11)Simple Clustering (p=0.025)

(b) Performacne of Simple Clustering

Fig. 1: Performance of first wave aggregation protocolsin mobile networks. (a) depicts the data loss percentage ofBasic LEACH in a mobile network with 200 devices. Plot (b)shows the number of uploaders that Simple Clusteringelects and its reliability for varying clusterhead election prob-abilities (p). The red dashed lines depict parameters that led toa 5% or more data loss. The error bars capture one standarddeviation of the simulation runs on 25 independent traces.

Figure 1(a) shows the performance of Basic LEACH, de-fined with respect to the number of sensor readings that make itto a clusterhead, with differing numbers of clusterheads elected(an indirect measure of p). The simulations describe a (small)network of 200 devices. Notice, over half the network mustbecome clusterheads before the loss percentage falls below5% (a threshold we use to indicate “reliable” aggregation).Such a large number of uploaders would not generate muchbandwidth or energy savings. This poor performance in the200 device network is enough for us to turn our attention fromBasic LEACH to the more resilient Simple Clusteringprotocol.

Figure 1(b) shows the performance of SimpleClustering under different network sizes and clusterheadelection probabilities. The ranges where the curve is plottedin red dashed lines indicate parameters that led to a 5% ormore data loss. The blue solid ranges indicate the parametersthat yielded reliable aggregation. Notice, for all three electionprobabilities, the aggregation eventually become reliable (withthe threshold size varying from 200 to 750 depending onthe election probability). As expected, reliable aggregationin small networks requires larger election probabilities. In

102

larger networks, however, such probabilities create an excessnumber of clusterheads. Furthermore, for a given networksize, our traces reveal that some regions are much more densethan others—leading to an uneven distribution of data lossheavily biased toward the sparse regions.

Combined, these results tell us: (1) the classical LEACHstrategy requires more stability than can be expected in amobile network; (2) replacing the local routing in LEACHwith more aggressive bounded-flooding can compensate forthis lack of stability, but requires clusterhead election thatcan adapt to differing network densities. In many ways, theprotocols we describe and evaluate next are motivated by theseconclusions. They are designed to adapt dynamically to localnetwork density while avoiding fragile local routing.

III. AGGREGATION PROTOCOLS

Aggregation in the smartphone setting makes use of twotypes of radios: local/low-power/free (e.g., Wi-Fi) and long-distance/high-power/non-free (e.g., 3G/4G). The goal is to uselocal links to aggregate sensor readings from multiple mobiledevices at a smaller number of devices that can then compressand upload the data using cellular links. This aggregationoccurs during a fixed-length of time we call an aggregationperiod: each device begins the period by taking a sensorreading; devices consolidate data during the period using locallinks, the devices that end up with the consolidated data thenupload it to the gateway at the end of the period.

A good aggregation protocol in this setting is one that:(i) uploads a sufficiently high percentage of the initial ob-servations (e.g., loss, if any, during the aggregation period islimited); (ii) minimizes the bandwidth used by expensive long-distance (cellular) link; (iii) minimizes the total energy usedby the mobile devices for all radio communication; and (iv)minimizes the latency induced by aggregation (i.e., works forthe shortest possible aggregation period).

Motivated by these goals, we now describe two aggrega-tion protocols: Pairwise Aggregation, and Two-WayAggregation. Formally, for the purpose of describing thealgorithms, let V be the set of devices and id(u), for u ∈ V ,be a unique id for device u. We use ou to describe thetoken generated by u for the current aggregation period. It isassumed that devices have partitioned time into synchronizedtime steps which we call rounds, each large enough to send adevice’s token(s) to another device. Let T be the length of anaggregation period in rounds. We label the rounds within anaggregation period, 1, 2, ..., T .

Every device u ∈ V begins each aggregation period witha unique token ou that describes the observation(s) it needs toreport during this period. Each device u maintains a set Su

(written as u.tokens in the algorithm pseudocode) of thetokens it currently owns.

Pairwise Aggregation. Our first protocol, which we callPairwise Aggregation (Algorithm 1), was motivatedby recent theoretical work on this problem by Cornejo etal. [13]. The basic idea is to elect clusterheads on demand—consolidating data to a small number of devices in regions ofthe network that happen to be dense and well-connected, whilepermitting many more clusterheads in regions that are sparse(Figure 2).

������

��������

������������

������������������������������������

���������� ����������

���������

Fig. 2: Network Density Adaptation. In sparse areas (i.e.,where there are fewer devices), the protocols require mostdevices to be clusterheads. However, in dense areas (i.e., wherethere are more devices), fewer clusterheads are elected.

At the beginning of an aggregation period, every devicehas a single piece of data, which we refer to as a “token,”and every device is active. Tokens will never be duplicated:each token is owned by at most one device at a time, and theowner at the end of the aggregation period is responsible foruploading the token.

Throughout the execution, every so often, an active deviceattempts to pair with a neighboring device by transmittingannouncements. We refer to each such pairing as a “round.”When two devices pair, one of the two devices (i.e., the“winner”) downloads all the data from the other (i.e., the“loser”), via a simple handshake. The loser then becomesinactive for the remainder of the aggregation period. Thedevices left with data at the end of the period aggregate thedata and upload the result using their cellular links.

A simple strategy to determine winners and losers is foreach device to choose a random identifier at the beginning ofthe execution; when two devices pair, the one with the largeridentifier wins. We modify this simple strategy to prioritizefairness. Each device remembers when it last uploaded datain a previous aggregation period; the device that was leastrecently an uploader is the winner, with ties broken by therandom identifier.

The Pairwise Aggregation protocol is simple,which helps reduce the energy it consumes through local com-munication. Its token-passing strategy also makes it highly-reliable, i.e., zero data loss. On the other hand, the conserva-tiveness of the protocol can reduce bandwidth savings, whencompared to a more aggressive protocol.

Two-Way Aggregation. Our second protocol, which we callTwo-Way Aggregation (Algorithm 2), combines the Pair-wise strategy from above with a secondary stage of LEACH-style cluster aggregation. (The name comes from the protocol’suse of two different aggregation strategies.) The basic idea isto first estimate the local density which can then be used toelect the second-stage clusterheads with appropriately-tunedprobabilities (i.e., devices in denser regions will use smallerprobabilities than devices in sparser regions; see Figure 2).Overall, the protocol consists of three phases.

Phase 1 consists of Pairwise Aggregation (Algo-rithm 1), as described above, which runs from round 1 to�0.4T �.

103

Algorithm 1: Pairwise Aggregation Protocol (at u)

Input: current round1 if u.active = false then2 return3 for each received message m in previous round do4 if m.type = ‘BROADCAST’ then5 if m.sender id > id(u) and u.busy = 0 then6 sendMessage(to= m.sender id,

type=‘TOKEN TRANSFER’, payload= u.tokens)7 u.busy ← current round8 else if m.type = ‘TOKEN TRANSFER’ then9 if u.busy = 0 then

10 u.tokens.append(m.payload)11 sendMessage(to= m.sender id, type=‘ACK’)12 else if m.type = ‘ACK’ then13 u.active← false14 u.tokens← null15 return16 if u.busy = current round - 2 then17 u.busy ← 018 if current round % 3 = 0 and u.busy = 0 then19 sendMessage(to=all, type=‘BROADCAST’)20 current round← current round+ 1

Phase 2 consists of a Local Counting protocol (Algo-rithm 3), a simple counting strategy that determines the numberof devices that still have tokens at the end of the phase 1.During phase 2, each active device (with tokens) periodicallysends out an announcement; each active device keeps a countof the number of unique announcements it receives during thecounting phase. The Local Counting protocol runs fromround �0.4T �+ 1 to �0.55T �.

Phase 3 consists of a Simple Clustering protocol(Algorithm 4), which is a cluster-based aggregation protocol.Each device that remains active (i.e., with tokens) elects itselfto be a clusterhead with probability 1/(c + 1), where c isthe count discovered from the Local Counting protocol.Simple Clustering protocol runs from round �0.55T �+1 to T .

Each device with tokens that is not a clusterhead attemptsto route its tokens toward a clusterhead. Every so often (i.e.,each round), each device with tokens performs a controlledgossiping step, broadcasting a limited amount of tokens (de-fined by δ ≥ 1) to its neighbors. (Typically, we allow a deviceto broadcast up to 5 tokens, though in practice, this will dependon the token size.) It chooses which tokens to broadcast in around-robin fashion: it keeps a queue of tokens, broadcastingthe tokens from the front of the queue, and moving thosetokens to the back of the queue. At the end of the period,these clusterheads aggregate what they have received and thenupload to the gateway.

Algorithm 2: Two-Way Aggregation Protocol (at u)Input: rpairwise: Last round of Pairwise ProtocolInput: rcount: Last round of Local Counting ProtocolInput: rcluster : Last round of Simple Clustering Protocol

1 current round← 02 u.tokens = {ou}3 while current round < rpairwise run Pairwise Aggregation4 while current round < rcount run Local Counting5 while current round < rcluster run Simple Clustering6 if u.uploader = true then uploadData(u.tokens)

Algorithm 3: Local Counting Protocol (at u)

Input: current roundOutput: length(active neighbours)

1 if u.active = true then2 active neighbours = [ ]3 for each received message m in previous round do4 if m.type = ‘ACTIVE’ then5 if m.sender id /∈ active neighbours then6 active neighbours.append(m.sender id)7 sendMessage(to=all, type=‘ACTIVE’)8 current round← current round+ 1

Algorithm 4: Simple Clustering Protocol (at u)

Input: current round, active count1 u.uploader ← false2 if u.active = true then3 u.uploader ← true with probability( 1

active count+1)

4 for each received message m in round previous round do5 addToTheEndOfQueue(u.tokens, m.payload)6 if u.uploader = false then7 tokens to send← popδTokensFromQueue(u.tokens)8 addToTheEndOfQueue(u.tokens, tokens to send)9 sendMessage(to=all, sender id= id(u),

payload=tokens to send)10 current round← current round+ 1

The Two-Way Aggregation protocol leveragesbounded-flooding and carefully-tuned clusterhead election tomore aggressively reduce the number of devices uploadingat the end of the period, and therefore minimize cellularbandwidth usage. The trade-off for this aggression is a morecomplicated protocol that might consume more energy withits local links and can now lose data (during the third phase).

IV. AGGREGATION FRAMEWORK FOR ANDROID DEVICES

�������

����� �������������

�������������� ���� � ����

������������ � ���

!"#!� � ���

$%��&����� $%��'��(�� )&��&����� )&��'��(��

���� ���'������"*����(���

�����+ ����� % � &�,-������

.�����

$��������

������������� ����

'�����--��� ����

����� ������ ,�����

�������-�� �����'/���,

(a) Architecture Diagram

����������������������������

���������� �������������������� ���������������� �������������������� ��������������������������������������� ���������������������������� �������� ������!����������� �������� �����������������������"������������������� ������$������� �������� ������#������� �������� ������������$���������� ���

(b) API

Fig. 3: Architecture Diagram and the API of the Frame-work. (a) and (b) depict the high-level architecture diagramand the API of our aggregation framework, respectively.

104

In this section, we discuss the implementation details ofan application-level framework that sensor applications canuse to opportunistically aggregate data. We also discuss themodifications we made in the Android operating system.

Our framework boasts a modular design and exposes aneasy-to-use and intuitive API that applications can use to ag-gregate data. Figure 3(a) depicts; (i) the interactions between asensor application (that requires aggregation), the aggregationframework, which encapsulates our protocols and provides ac-cess to them via an easy-to-use API, and the Android OS; and(ii) the high-level architecture diagram of the framework thathighlights its main components. Figure 3(b) depicts the API ofthe framework that is exposed to applications that want to useour aggregation protocols. Currently, the framework supportsonly the aggregation of string based data (e.g., temperaturereadings, statuses of a taxi cabs), and file based data (e.g.,images and videos from surveillance applications, sound clips).It can be extended to support other types of data if required.

The application configures our framework at startup bysetting several parameters by calling the relevant API methods.Afterwards, when the application has data to be uploaded, itshould call the relevant upload method and pass the data tobe uploaded and a callback object. The framework then runsthe set aggregation protocol and attempts to opportunisticallyaggregate the application data. In the event of a data transfer,either to another device or to the server at the end of the ag-gregation period, the uploadStatus method of the callbackobject is called by the framework to return a result code.

To save energy, the framework turns off the Wi-Fi interfaceof the smartphone when it is not active—as in our protocols,when a device has handed off its data items. It also keeps thecellular interface switched off except when uploading data.

Device-to-Device Communication. Our protocols require lo-cal communication. We facilitate this requirement by puttingthe 802.11 drivers of the devices into ad-hoc mode. TheAndroid operating system does not directly support ad-hoccommunication (even though the wireless drivers do), sowe follow the strategy of [14] to modify the source of theCyanogenmod 10.1 (Android 4.2.2) [15] operating system toenable ad-hoc mode. The ad-hoc mode offers greater reliabilityand efficient broadcast communication when compared toBluetooth and Wi-Fi direct. When the framework is initialized,it creates an ad-hoc network (or joins an existing ad-hocnetwork created by another device in the vicinity). All devicesuse the same channel to discover and communicate with eachother.

We use both UDP and TCP transport protocols to imple-ment different types of local communication primitives neededby protocols. UDP is used when the phones want to broadcastmessages (e.g. identifier broadcasts). TCP is used to transferdata items between phones as we require application levelacknowledgments of the received data.

Parallel Cellular and Ad-hoc Communication. Our proto-cols use both cellular and Wi-Fi network interfaces in parallel,beginning a new aggregation period while the previous 3G/4Gupload completes. Currently, Android does not support thisfunctionality. To enable this concurrent use of both interfaceswe modified the ConnectivityService Java class of theOS. (The native OS implementation terminates the cellular

connection on connection to a Wi-Fi network.) The frameworkalso reconfigures the routing tables properly to ensure that thephones use the correct interface for each packet, i.e., Wi-Fi forlocal communication and cellular for uploading.

Multiple Application Support. As our framework is writtenin the form of a library, each application will have an exclusiveinstance of the framework. The framework listens on twoports—one each for UDP and TCP messages—and the ap-plications have to set unique port numbers for the frameworksto demultiplex messages accordingly.

V. EVALUATION PRELIMINARIES

A. Compression Schemes

A key advantage of aggregation is that uploaders cancompress data items before transmitting them. The choice ofcompression scheme is application specific, and has a largeimpact on energy/bandwidth savings. We focus on two types ofcompression—uniform and geographic; we believe that mostpractical schemes fall somewhere between these two.

Uniform Compression. This scheme compresses all dataitems to a fixed size (e.g., to the size of a single data item),regardless of the number of data items to be compressed. Manydata analysis functions, such as the average of a set of dataitems, have this property. This scheme is useful for applicationslike environmental monitoring that want to calculate broadaverage readings.

Geo(graphic) Compression. This scheme eliminates redun-dant data, only reporting one data item per geographic region;it performs no other data compression. Each device tags itsdata item with its geographic location at the time of the sensorreading (e.g., using GPS). An uploader considers a pair of dataitems redundant if their tagged locations are close, and discardsone of the two readings. We instantiate this greedily, addingelements one at a time to the upload set only if it is fartherthan some threshold distance (500m in our simulation studies)from any other data item being uploaded. This scheme is usefulfor applications like NoiseTube [16] and traffic monitoring [8]that want a single observation per region.

In our testbed experiments (Section VI), we used anapproximate implementation of geo compression, since indoorGPS readings have low accuracy. We decided that two deviceswere “nearby” if one received a message from the other. Eachphone maintained a list of neighbors, updated whenever aphone directly receives a message from another phone; theneighbor list was cleared every 5 minutes. Each uploaderdiscarded any data items that belonged to its neighbors.

B. Energy Model

A key metric in our evaluation is energy consumption. Webuild a smartphone energy consumption model using extensiveexperimental readings, and then use the resulting model inevaluating our testbed and simulation experiments.

Model. There are two primary energy costs: (1) communicat-ing locally via Wi-Fi Ad-hoc, and (2) uploading data via 3G1.Table I lists the parameters in our energy model.

1We only consider the energy consumed by 3G as we did not use 4G/LTEenabled phones in our experiements.

105

TABLE I: Energy Model Parameters and Measurements

Parameter Definition Energy Consumption (J)

erWi-Fi interface (persecond energy usage)

0.22507 ± 0.011645

ebs Send (UDP) 0.03846 ± 0.01574ebr Receive (UDP) 0.00761 ± 0.00283eas Send ack (TCP) 0.02391 ± 0.00626ear Receive ack (TCP) 0.0226 ± 0.00691

ets(D) Send, DKB (TCP) 0.03846 ± 0.01574 (D = 10)0.19037 ± 0.02719 (D = 200)0.31153 ± 0.02681 (D = 400)0.47082 ± 0.03360 (D = 600)0.59652 ± 0.05619 (D = 800)0.65267 ± 0.02769 (D = 1000)

etr(D) Receive, DKB (TCP) 0.02145 ± 0.00203 (D = 10)0.18022 ± 0.01991 (D = 200)0.28764 ± 0.03014 (D = 400)0.42313 ± 0.02810 (D = 600)0.52625 ± 0.046914 (D = 800)0.63801 ± 0.03684 (D = 1000)

e3g(D,m(i))Upload m(i) data itemsof size DKB, via 3G

1.4164 ×(m(i)

D

10

)+ 6.1679

For each device i, we also need certain other parameters:t(i) describes the duration in seconds a device was active in anaggregation period. (Recall, in Pairwise Aggregation, adevice becomes inactive when it passes off its data.) Bs(i) andBr(i) describe the number of UDP broadcasts i sent and re-ceived, respectively; Ts(i) and Tr(i) describe the total numberof data items sent and received, respectively, by i. As(i) andAr(i) describe the total number of acknowledgments sent andreceived, respectively, by i. Putting this together, we computethe energy used by device i, E(i), as:

E(i) = t(i)er +Bs(i)ebs +Br(i)ebr +As(i)eas+ Ar(i)ear + Ts(i)ets(D) + Tr(i)etr(D)

+ e3g(D,m(i))

Here, m(i) is the number of data items uploaded via 3Gat the end of the aggregation period by device i; for a devicethat does not upload data, e3g(D,m(i)) = 0.

Let N be the set of all devices in the system. Then, thetotal energy consumed by all the devices in an aggregationperiod k is given by: Etotal(k) =

∑j∈N E(j) .

We compare our protocols to the current prevailing strategywhere each device periodically uploads its own data directlyto the server. This approach has a total energy cost of|N |e3g(D, 1). The energy savings percentage is computed asfollows:

Esavings =|N |e3g(D, 1)− Etotal(k)

|N |e3g(D, 1)

Measurements. We conducted in-depth energy measurementson Samsung Galaxy Nexus phones using the Monsoon PowerMonitor [17] to quantify the parameters in Table I, similar tothe approach in [18]. To increase accuracy, we measured withthe screen switched off, stopped all other user applications,and killed all processes except the system processes. Beforeeach measurement, the idle power consumption of the phonewas measured, which was subtracted from the reading. Notethat ebs, ebr, eas, ear, ets(D), etr(D) measurements indicate

the additional energy that is consumed to send/receive amessage on top of the energy consumed by the Wi-Fi interface.Our measurements are summarized in Table I.

The value er was determined by connecting a phone to thead-hoc network used in our testbed (Section VI) and taking10 measurements for a minute each. The measurements wereaveraged and divided by 60 to find er.

Next, we connected another phone to the ad-hoc networkand installed a simple Android application on both devices.This application sends and receives UDP broadcast messages,TCP messages carrying data items of varying sizes, andacknowledgment messages (as from our protocols) via TCP.For each type of message, and for varying sizes of D, 10measurements each were averaged for both sends and receiptsto find ebs, ebr, eas, ear, ets(D) and ers(D).

Finally, to compute e3g(D,m(i)), a series of measurementswere performed using a SIM card from Singapore’s Starhubservice provider. These measurements were taken at differenttimes of the day to account for varying base-station workloads.

In an aggregation protocol, the aggregated data is up-loaded to the server in a single burst. Hence we neededan accurate estimate of e3g(D,m(i)) for any given m(i)and D. Since it is impractical to take measurements forevery value of m(i) and D, we measured specific pointsand did a regression fit. For 10KB, 10 measurements eachwere taken for m(i)∈{1, 10, 20, 30, 40, 50}. Then, we fitteda linear regression model to all of these data points. The R2

value of our regression model is 0.98, indicating a tight fit toour measurements. Then, this model was modified to estimatee3g(D,m(i)) for any given m(i) and data item size DKB. Theerror in using this model to estimate 3G energy consumptionfor all six data item sizes we consider is less than 10%.

VI. TESTBED EVALUATION

We evaluated our protocols in a testbed of 11 SamsungGalaxy Nexus Android phones running a modified version ofCyanogenmod 10.1 (Android 4.2.2) (Section IV).

A. Experimental Setup

We implemented a simplified version of NoiseTube [16], todemonstrate practical applicability of our protocols. NoiseTubeis an application that allows people to record and uploadambient sound clips to a server where they are further analyzedto measure noise pollution levels. The standard applicationrequires the server to process every recorded sample, eventhough many redundantly describe the same area.

Our implementation assumes that users upload a 5 secondsound sample once per minute. Combined with our aggregationframework (Section IV), users record a sample, then run ouraggregation protocols for a minute to aggregate the data. Weuse a round length of 2 seconds and compress data using the(neighbor-based) geo compression scheme (Section V-A).

We installed our test application on 11 Samsung GalaxyNexus smartphones and distributed them randomly amongstudent volunteers. We asked the students to carry the phonewherever they went during the experimental periods, i.e., theirmovements were unconstrained. Each phone was programmed

106

TABLE II: Summary of the Testbed Results

Protocol Reduction in Cellular Links Cellular Bandwidth Savings Energy Savings Data Loss

Pairwise Aggregation 77.39% 76.25% 21.49% 0%Two-Way Aggregation 75.59% 75.02% 3.76% 1.85%

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1 2 3 4 5 6 7 8 9 10 11

Cel

lula

r B

andw

idth

Sav

ings

(%

)

Smartphones

0.850

0.758

0.635

0.806 0.808

0.6690.7

0.7830.810

0.833

0.733

(a) Pairwise Aggregation

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1 2 3 4 5 6 7 8 9 10 11

Cel

lula

r B

andw

idth

Sav

ings

(%

)

Smartphones

0.812

0.656

0.794 0.781

0.633

0.727

0.7790.796

0.708

0.848

0.717

(b) Two-Way Aggregation

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

10 200 400 600 800 1000

Ene

rgy

Sav

ings

(%

)

Data Item Size (KB)

Pairwise AggregationTwo-Way Aggregation

(c) Energy Savings

Fig. 4: Results from the Testbed Experiments: Plot (a) and plot (b) depict the cellular bandwidth savings of the phones whenusing the Pairwise Aggregation and Two-Way Aggregation protocols, respectively. Plot (c) depicts energy savingsof the phones for varying data item sizes.

to log the number of seconds it was active (i.e., had its Wi-Fi interface on), as well as the number of broadcasts, dataitems, and acknowledgments that were sent and received, andthe number of data items that it uploaded. Some of the phoneswere equipped with SIM cards, in order to test end-to-endfunctionality; however, much of the analysis of 3G bandwidthand energy usage was based on the logs. We also built a simplePHP web server to accept the uploads.

As we consider fixed length aggregation periods, thephones need to be loosely synchronized. (We do not requiretight synchronization since the protocols do not involve anylockstep operations.) Before our experiments, we synchronizedthe clocks of the phones by connecting them to the campus Wi-Fi network and setting the network time. This scheme providedaccuracy on the order of seconds, which is sufficient.

For each protocol, the participants carried the phones fora total of 8 hours—4 hours one morning and 4 hours anotherafternoon. The aggregation period length was 1 minute, andour experiments yielded logs for 480 aggregation periods foreach phone and protocol. Table II summarizes the performanceof the protocols. We discuss these results below.

B. Cellular Bandwidth Savings and Fairness

We calculate cellular bandwidth savings by comparing thetotal amount of bandwidth the phones consumed running ouraggregation protocols with the amount of bandwidth used bythe default approach where every phone uploads its own data.We similarly calculated the savings in the number of cellularlinks, which is important in provisioning backend servers.

As shown in Table II, both our protocols reduced cellularbandwidth and total number of cellular links by at least 75%.We emphasize that given a fixed data plan for most cellphoneusers, a 75% reduction on the bandwidth used by sensor

network applications is a non-trivial improvement. This figure,however, captures overall cellular bandwidth reduction.

We also studied how fairly this reduction was spread acrossthe individual phones. Figure 4(a) and 4(b) show the bandwidthsavings of each of the 11 phones across all 480 aggregationperiods. The key observation is that all phones had at leasta 63% bandwidth saving—evidence that the uploading dutieswere fairly distributed over the phones. A closer look at ourlogs reveals that the devices at the lower side of the bandwidthsavings scale tended to be isolated for longer periods.

C. Energy Savings

Table II shows energy savings of our protocols for 10KBsized data items—the size of the sound samples recorded anduploaded by our NoiseTube sample application. The savingswere calculated using the behavior logs of the phones and theenergy model described earlier (Section V-B).

Overall, the Pairwise Aggregation protocol savedmore energy than the Two-Way Aggregation protocol.This result is unsurprising, as Two-Way Aggregationmakes more aggressive use of the Wi-Fi interface.

We also explore the relationship between the size of adata reading and the energy savings. The protocols save moreenergy as data size increases, as the ratio between the energyconsumed by the 3G interface and the Wi-Fi interface growswith the message size. Figure 4(c) summarizes this trend.

For larger data sizes, both protocols do equally well inenergy savings. This is because, for larger data sizes, a largerfraction of the total energy consumption is spent on the 3Ginterface, thus, offsetting the heavy Wi-Fi interface usage costof the Two-Way Aggregation protocol.

107

VII. SIMULATION STUDIES

Here we evaluate our protocols via simulation using alarge corpus of taxi cab mobility traces, obtained from thelargest taxi operator in Singapore. Our goal here is two-fold:(1) to study how our protocols perform with vehicular-speedmobility (which presumably creates more topology dynamismthan walking speed mobility); and (2) study how our protocolsbehave as factors, such as network density, scale, i.e., those thatare hard to exhaustively evaluate with a real-world deployment.

A. Experimental Setup

The basic corpus consists of GPS traces from over 15,000taxis operating in Singapore. From this large dataset, weextracted traces containing a subset of the vehicles, randomlychosen, ranging from small (100 taxis) to large (2000 taxis).The taxi traces cover the entire geographical area of Singapore,with regions of varying density. For example, the downtownarea is denser with taxis, while the suburbs have fewer taxis.The network is large enough to be globally disconnected.

To transform the mobility traces into connectivity traces,we assume that each taxi is equipped with a smartphone, andwe use NS-2 (v2.3.4) [19] to simulate a simple beaconingprotocol via a 802.11 ad-hoc network, where each devicebroadcasts a message once every 5 seconds. We used logs ofreceived messages to determine connectivity at each 5 secondinterval. The resulting connectivity traces are used as inputto a network emulator, written in Java, that allows for rapidexperimentation of protocols (the connectivity traces free theemulator from needing to model radio communication itself).

The emulator mimics the same NoiseTube-like application(Section VI). The round length of the protocols was set to 1second. As in our testbed experiments, in each experiment, foreach device, we logged the time it used its radio, the numberof broadcasts, data items, and acknowledgments that were sentand received, along with the number of uploaded data items.We then combined these results with our energy model (seeSection V-B) to calculate the relevant metrics.

B. Impact of Network Density

We begin by studying how cellular bandwidth usage varieswith the network density, i.e., the number of devices in thenetwork. The aggregation period was fixed at 2 minutes.We consider network densities of 200 to 2000 in incrementsof 200. For each case, we ran 25 simulation runs on 25independent traces. We plot the average bandwidth savingsin Figure 5(a). For each network density, the Two-WayAggregation protocol lost at most 5% of the data items.

Even in relatively sparse networks (e.g., 200 taxis spreadout across the entire island of Singapore), both protocols per-form well. Two-Way Aggregation always out-performsPairwise Aggregation under the uniform compressionscheme, because the Two-Way Aggregation protocol ag-gregates more aggressively. As the network becomes denser,the Two-Way Aggregation protocol adapts well by allo-cating an increasingly small number of uploaders—achievinghigher bandwidth savings. The savings of the PairwiseAggregation protocol, however, reduce slightly as thenetwork becomes denser. This is likely a result of the 2 minute

aggregation period, which is not sufficiently long for it to takeadvantage of the growing network density. Even with density-aware clusterhead election probabilities set, Basic LEACHhas lesser bandwidth savings, e.g., 70% in a 1000 devicenetwork. (Basic LEACH results are excluded for clarity’ssake. Please see [20] for those plots.)

We also studied our protocols with the geo compressionscheme. In sparse networks, bandwidth savings are reducedfor both protocols as there is little redundancy among thedata to be uploaded. As the network grows denser, however,this redundancy increases, which increases the efficiency ofcompression. This increases bandwidth savings; both protocolshave bandwidth savings of up to ∼50%.

C. Impact of Aggregation Period Length

A natural question is whether we can achieve highercellular bandwidth savings if we run the protocols longer. Theaggregation period length also determines the data latency,since the uploading process is postponed by the length of theaggregation period. Hence, we studied bandwidth savings ofour protocols under varying aggregation period lengths.

We ran simulations on three network densities—100, 1000,and 2000—while varying the aggregation period length from1 minute to 5 minutes, in increments of 1 minute. Sinceaggregation period length changes will also change the en-ergy consumption, we measured the energy savings metricas well. For each combination of network density, protocol,aggregation period length, data size, and compression scheme,we conducted 25 simulation runs on 25 independent traces andreport the average bandwidth and energy savings. The resultsare reported in Figure 5(b) and 5(c). Due to space limitations,we show only the plot for the 1000 taxi network whenaggregating a medium-sized data item of 600KB. Plots forother combinations of network density and data size showedsimilar relative behavior; for smaller data items, the energysavings are smaller, as discussed in Section VII-D.

Notice under both compression schemes, cellular band-width savings of the protocols increase with time. TheTwo-Way Aggregation protocol is clearly the best per-former if it is used with uniform compression—running it forjust one minute will provide bandwidth savings of 85% and itcan be increased by 7% by running it for 5 minutes. It alsoloses at most 5% of the data for all durations. The performanceof the Pairwise Aggregation protocol approaches thatof the Two-Way Aggregation protocol as the durationincreases. Geo compression also yields a improvement for bothprotocols as the aggregation period increases. The gap betweenthe two protocols, however, now remains small (1% to 4%)throughout the durations tested.

In terms of energy savings, we see that running Two-WayAggregation for a longer duration increases savings forboth compression schemes, though this gain begins to leveloff between 2–3 minutes. Pairwise Aggregation, bycontrast, has its savings decrease as the duration increases(with the exception of the first increase in the uniform setting).This is because after 2–3 minutes the number of uploaders nolonger decreases significantly. At the same time, however, theirWi-Fi radios stay on and consume energy, thus, outpacing theenergy savings as the aggregation period grows.

108

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

200 400 600 800 1000 1200 1400 1600 1800 2000

Cel

lula

r B

andw

idth

Sav

ings

(%

)

Network Density

Two-Way Aggregation (Uniform Compression)Pairwise Aggregation (Uniform Compression)

Pairwise Aggregation (Geo Compression)Two-Way Aggregation (Geo Compression)

(a) Bandwidth Savings

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1 2 3 4 5 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Cel

lula

r B

andw

idth

Sav

ings

(%

)

Ene

rgy

Sav

ings

(%

)

Aggregation Period Length (minutes)

Two-Way Aggregation (Bandwidth)Pairwise Aggregation (Bandwith)

Pairwise Aggregation (Energy)Two-Way Aggregation (Energy)

(b) Uniform Compression

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1 2 3 4 5 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Cel

lula

r B

andw

idth

Sav

ings

(%

)

Ene

rgy

Sav

ings

(%

)

Aggregation Period Length (minutes)

Two-Way Aggregation (Bandwidth)Pairwise Aggregation (Bandwith)

Pairwise Aggregation (Energy)Two-Way Aggregation (Energy)

(c) Geo Compression

Fig. 5: Results from the Simulation Studies: Plot (a) depicts the cellular bandwidth savings of our protocols. Plot (b) and (c)show cellular bandwidth (solid lines) and energy savings (dashed lines) of the phones in 1000 device network with data itemsof size 600KB when using uniform compression and geo compression, respectively. The error bars show one standard deviation.

D. Impact of Data Item Size

We also examined how energy use varied with the sizeof a data item being aggregated and uploaded. For eachcombination of network density, protocol, and compressionscheme, energy savings increase with data item size. This ef-fect closely resembles the behavior we observed in the testbed(Figure 4(c)); we omit these plots due to space restrictions.

VIII. DISCUSSION

In this section, we discuss some of the practicalities indeploying our protocols.

Trade-offs. Our evaluations indicate that our protocols matchthe requirements of an effective aggregation protocol, asoutlined in Section III. Our evaluations also indicate, how-ever, that in using our protocols there are certain trade-offs that application developers must consider. First, thereis a trade-off between cellular bandwidth savings and en-ergy consumption. For example, under uniform compres-sion, Two-Way Aggregation provides the highest cellularbandwidth savings. This protocol, however, uses more energythan Pairwise Aggregation. Next, there is a trade-offbetween cellular bandwidth savings and data latency. Clearly,if an application requires the continuous reporting of obser-vations (e.g., real-time streaming) then our protocols cannotbe used, as they induce latency between reports. Furthermore,running the protocols for a longer duration increases cellularbandwidth savings, but that increases the data latency. Lastly,the energy savings depend on the data size. We noted that insome cases (e.g., aggregating 10KB data items in a 2000 devicenetwork) aggregation does not yield energy savings. However,if energy savings are irrelevant (e.g., smartphones in cars canbe powered by the car battery), any data size will yield cellularbandwidth savings when our protocols are used with either ofthe compression schemes.

Security. Data security is another aspect that should be takeninto consideration when using our protocols, as devices can“see” the data of others. In this paper, we assumed that alldevices are co-operative, and hence we did not address data se-curity. However, if security is a major concern, applications canmake use of encryption schemes like public key cryptographyto encrypt their data before it is handed down to our framework

for aggregation. The framework is completely oblivious to thedata contents, thus allowing application developers to handlesecurity aspects as they wish.

Using Bluetooth/Wi-Fi Direct. For our prototype, we modi-fied the OS of the smartphones to enable 802.11 ad-hoc mode,since it has many advantages (e.g., easier neighbor discovery,efficient broadcast communication, etc.). If this modificationis infeasible, our framework (Section IV) can be extended touse Bluetooth and Wi-Fi Direct for local communication, thusallowing deployment with off-the-shelf devices.

Participants. As in any participatory sensor-application (e.g.,NoiseTube [16]), the quality of the reported data is highlydependent on the number of participants. Likewise, the savingsprovided by our protocols depend on the number of partici-pants. However, in centrally deployed sensor networks (e.g.,taxi cabs monitoring traffic congestion), our protocols willprovide significant savings, as there will be many participants.

IX. RELATED WORK

Aggregation in Wireless Sensor Networks. Research in thisdirection first focused on directed diffusion style protocols [3],and then considered tree-based structures [5], [21]. Researchersalso developed cluster-based protocols such as LEACH [4] andHEED [22]. Cluster protocols were shown to be more resilientto failures and link changes, and more fair in their per-deviceenergy consumption. These protocols are similar to the aggre-gation strategy we study (both consolidate and aggregate withlocal links, then report with long-distance links). The maindifference, however, is that the cluster protocols still requiresufficient topological stability. Our protocols are designed fortruly mobile networks where such stability cannot be expected.For a complete survey on in-network aggregation strategies inwireless sensor networks, refer to [23].

Aggregation in Mobile Sensor Networks. Mobile sensornetworks have grown in popularity with the growing smart-phone ownership; e.g., [7]–[9]. Though most deployed mo-bile sensor networks—including every example cited above—report observations using cellular links, two main alternativeshave been proposed in the literature. One alternative is toopportunistically upload using 802.11 when a device comes

109

within range of an open Wi-Fi access point [10], [11], orpiggybacking data to other traffic [12].

The other alternative is to use delay tolerant networkingto move data from device to device in the network, usingonly local links. Such protocols either replicate informationthroughout the network or forward data without replication. Asnaive replication wastes network resources, several protocolsthat limit replication or remove unnecessary packets fromthe network were designed [24]–[28]. On the other hand,forwarding protocols maintain just one copy of each packetduring the routing process, as done in [29]–[31].

The above protocols are designed for in-network routingin a mobile network. In contrast, our goal is to aggregateand upload the nodes’ data (e.g. sensor readings) to a centralserver in a cost-effective manner. However, our protocolsdo resemble the above in-network routing strategies; ourPairwise Aggregation protocol does data forwardingand the Two-Way Aggregation protocol uses a controlledreplication strategy.

Exploiting Multiple Interfaces. Researchers have previouslystudied the benefits of exploiting multiple network interfacesof smartphones (e.g., [32], [33]). Similarly, we use multipleinterfaces to reduce cellular bandwidth and energy usage.

X. CONCLUSION

In this paper, we presented two new aggregation algorithmsthat perform well in the context of highly dynamic smartphonesensor networks, where conventional aggregation algorithmsincur higher costs or data loss. Using testbed experiments andextensive simulation studies, we showed that our protocols,while making no assumptions on topology, device movementsand device connectivity, can achieve significant bandwidthsavings in uploading data from a collection of smartphones,while being fair and energy efficient.

ACKNOWLEDGMENT

We thank the anonymous reviewers for their feedbackthat helped us improve this paper; Chan Mun Choon forhis feedback on earlier drafts; and Seshadri PadmanabhaVenkatagiri, Girisha De Silva, and Dilini Baranasuriya forhelping us with the testbed experiments. This research is sup-ported by MOE2011-T2-2-042 “Fault-tolerant CommunicationComplexity in Wireless Networks” from the Singapore MOEAcRF-2, by the Ford University Research Program, and by theSMART Future Urban Mobility Project.

REFERENCES

[1] P. Juang, H. Oki, Y. Wang, M. Martonosi, L. S. Peh, and D. Rubenstein,“Energy-efficient computing for wildlife tracking: design tradeoffs andearly experiences with ZebraNet,” SIGOPS OSR, 2002.

[2] G. Werner-Allen, K. Lorincz, M. Ruiz, O. Marcillo, J. Johnson, J. Lees,and M. Welsh, “Deploying a wireless sensor network on an activevolcano,” IEEE Internet Computing, 2006.

[3] C. Intanagonwiwat, R. Govindan, and D. Estrin, “Directed Diffusion: aScalable and Robust Communication Paradigm for Sensor Networks,”in ACM MobiCom, 2000.

[4] W. Heinzelman, A. Chandrakasan, and H. Balakrishnan, “AnApplication-Specific Protocol Architecture for Wireless MicrosensorNetworks,” IEEE Trans. on Wireless Communications, 2002.

[5] B. Krishnamachari, D. Estrin, and S. Wicker, “The impact of dataaggregation in wireless sensor networks,” in IEEE ICDCSW, 2002.

[6] “One in Every 5 People in the World Own a Smartphone,”www.businessinsider.com/smartphone-and-tablet-penetration-2013-10.

[7] J. Eriksson, L. Girod, B. Hull, R. Newton, S. Madden, and H. Balakr-ishnan, “The Pothole Patrol: Using a Mobile Sensor Network for RoadSurface Monitoring,” in ACM MobiSys, 2008.

[8] A. Thiagarajan, L. S. Ravindranath, K. LaCurts, S. Toledo, J. Eriksson,S. Madden, and H. Balakrishnan, “VTrack: Accurate, energy-awaretraffic delay estimation using mobile phones,” in ACM SenSys, 2009.

[9] J. Biagioni, T. Gerlich, T. Merrifield, and J. Eriksson, “EasyTracker:Automatic Transit Tracking, Mapping, and Arrival Time PredictionUsing Smartphones,” in ACM SenSys, 2011.

[10] A. Balasubramanian, R. Mahajan, and A. Venkataramani, “AugmentingMobile 3G Using WiFi,” in ACM MobiSys, 2010.

[11] X. Hou, P. Deshpande, and S. Das, “Moving Bits from 3G to Metro-Scale WiFi,” in IEEE ICNP, 2011.

[12] N. D. Lane, Y. Chon, L. Zhou, Y. Zhang, F. Li, D. Kim, G. Ding,F. Zhao, and H. Cha, “Piggyback CrowdSensing (PCS): Energy EfficientCrowdsourcing of Mobile Sensor Data by Exploiting Smartphone AppOpportunities,” in ACM SenSys, 2013.

[13] A. Cornejo, S. Gilbert, and C. Newport, “Aggregation in DynamicNetworks,” in ACM PODC, 2012.

[14] “Ad-Hoc (IBSS) mode support for Android 4.2.2,”www.thinktube.com/android-tech/46-android-wifi-ibss.

[15] “Cyanogenmod Project,” www.cyanogenmod.org.

[16] N. Maisonneuve, M. Stevens, M. E. Niessen, P. Hanappe, and L. Steels,“Citizen noise pollution monitoring,” in dg.o, 2009.

[17] “Monsoon Power Monitor,” www.msoon.com/LabEquipment/PowerMonitor.

[18] S. Deng and H. Balakrishnan, “Traffic-aware Techniques to Reduce3G/LTE Wireless Energy Consumption,” in ACM CoNext, 2012.

[19] “NS-2,” http://www.isi.edu/nsnam/ns/.

[20] “Aggregation in Smartphone Sensor Networks,”www.comp.nus.edu.sg/ nimantha/papers/aggregation-techreport.pdf.

[21] S. Madden, M. Franklin, J. Hellerstein, and W. Hong, “TinyDB: anAcquisitional Query Processing System for Sensor Networks,” ACMTrans. on Database Systems, 2005.

[22] O. Younis and S. Fahmy, “HEED: a hybrid, energy-efficient, distributedclustering approach for ad hoc sensor networks,” IEEE Trans. on MobileComputing, 2004.

[23] R. Rajagopalan and P. Varshney, “Data-aggregation techniques in sensornetworks: a survey,” IEEE Communications Surveys and Tutorials,2006.

[24] M. Jelasity, A. Montresor, and O. Babaoglu, “Gossip-based aggregationin large dynamic networks,” ACM Trans. on Computer Systems, 2005.

[25] J. Burgess, B. Gallagher, D. Jensen, and B. Levine, “MaxProp: Routingfor Vehicle-Based Disruption-Tolerant Networks,” in IEEE INFOCOM,2006.

[26] A. Balasubramanian, B. Levine, and A. Venkataramani, “DTN routingas a resource allocation problem,” in ACM SIGCOMM, 2007.

[27] A. Vahdat and D. Becker, “Epidemic Routing for Partially ConnectedAd Hoc Networks,” in Tech. Report CS-200006, Duke University, 2000.

[28] T. Spyropoulos, K. Psounis, and C. S. Raghavendra, “Spray and Wait:An Efficient Routing Scheme for Intermittently Connected MobileNetworks,” in ACM WDTN, 2005.

[29] S. Jain, K. Fall, and R. Patra, “Routing in a delay tolerant network,” inACM SIGCOMM, 2004.

[30] E. P. Jones, L. Li, J. K. Schmidtke, and P. A. Ward, “Practical routingin delay-tolerant networks,” IEEE Trans. on Mobile Computing, 2007.

[31] P. Deshpande, X. Hou, and S. Das, “Single-copy Routing in Intermit-tently Connected Mobile Networks,” in IEEE SECON, 2004.

[32] G. Ananthanarayanan, V. N. Padmanabhan, L. Ravindranath, andC. A. Thekkath, “COMBINE: Leveraging the Power of Wireless PeersThrough Collaborative Downloading,” in ACM MobiSys, 2007.

[33] T. Pering, Y. Agarwal, R. Gupta, and R. Want, “CoolSpots: Reducing thePower Consumption of Wireless Mobile Devices with Multiple RadioInterfaces,” in ACM MobiSys, 2006.

110