wireless body area networks: where does energy go?
TRANSCRIPT
Wireless Body Area Networks: Where Does Energy Go?
Sangwon Lee1, Murali Annavaram2
1Department of Computer Science, 2Ming Hsieh Department of Electrical EngineeringUniversity of Southern California, Los Angeles, CA, USA
{sangwon.lee, annavara}@usc.edu
Abstract—Wireless Body Area Networks (WBANs) promiseto revolutionize health care in the near future. By integratingbio-sensors with a mobile phone it is possible to monitor anindividual’s health and related behaviors. Monitoring is doneby analyzing the sensor data either on a mobile phone or ona remote server by relaying this information over a wirelessnetwork. However, the “wireless” aspect of WBAN is beinglimited by the battery life of the mobile phone. A WBANdesigner has a range of options to trade-off limited batterywith many important metrics. From the choice of program-ming languages to dynamically choosing between computationversus communication under varying signal strengths, there areseveral non-obvious choices that can have dramatic impact onbattery life. In this research we use an in-field deployed WBANcalled KNOWME to present a comprehensive quantificationof a mobile phone’s energy consumption. We quantify theenergy impact of different programming paradigms, sensingmodalities, data storage, and conflicting computation and com-munication demands. Based on the knowledge gained from themeasurement studies, we propose an Active Energy Profilingstrategy that uses short profiling periods to automaticallydetermine the most energy efficient choices for running aWBAN.
I. INTRODUCTION
Wireless Body Area Network (WBAN) is an excitingtechnology that promises to bring health care to a new levelof personalization. Miniaturized sensors can be worn onthe body and they can non-intrusively monitor a person’sphysiological state. Multiple sensors communicate with amobile phone using wireless interfaces forming a WBAN.WBANs enable monitoring an individual’s health continu-ously in free living conditions, where the individual is free toconduct his/her daily activity. The mobile phone in a WBANis used to collect health data from sensors, store and evenpartially process data locally, and transmit the health dataover wireless links to a back-end processing server.
A typical mobile phone based WBAN consists of threelayers as shown in Figure 1. The first component is thesensor layer which measures physiological and even emo-tional signals and transmits this data wirelessly. The secondlayer is a mobile phone which acts as a data collectionhub and receives the external sensor data. It may furtherenrich the sensor data with GPS , audio and video tags toget an accurate state of a person’s health and environmentalconditions. The mobile phone may also process data locally.The last layer is a back-end server that processes and
Internet
Back-End ServerBody Sensors Smart Phone
ECG
SpO2
ACC
ACC
GSR End-to-end encryption of
sensitive data
Figure 1. An Example 3-Tier WBAN System
stores the data. As WBANs operate continuously, one ofthe major bottleneck to data collection and analysis is thelimited battery life of mobile phones. For instance, in [1] theauthors report that a Nokia N95 phone battery has nearly200 hours of standby time, but when it is used for user statedetection, the battery drains in 4 hours. For WBANs to beused pervasively, it is necessary to first understand where theenergy is spent in a WBAN and then use energy efficientstrategies to operate a WBAN.
At each stage of a WBAN design and operation, thesystem designer has a wide range of options to trade-off battery life for other important metrics. During systemsoftware development phase the designer has a choice ofprogramming platforms for improving software productivity.The designer may use Python, Java or a phone’s nativeprogramming model such as Symbian C++ or iPhone SDKto develop the system software. The choice of languagecan tradeoff software productivity with potential runtimeoverheads of managed environments that lead to energyinefficiency.
During the data transmission phase, the designer has tomake energy tradeoff decisions on computation and commu-nication costs. Storing data on flash may allow the mobilephone to compress large chunks of data and send compresseddata to the remote server. Data compression places morecompute demands. On the other hand, compression mayreduce the transmission energy cost. Local storage of dataalso allows mobile phone to process the data locally andonly send interesting events to the back-end. For instance,detecting an abnormal heart beat signal from Electrocardio-graphy will reduce the need to continuously transmit normaloperational data thereby reducing transmission energy.
As demonstrated with these ample examples, the systemdesigner is faced with a daunting list of tradeoffs . Whilesome previous studies have quantified the energy tradeoffsin specific domains, such as communication versus compu-
Device Manager
Local Storage[User Configuration]
[Analyzed Data][Raw Data]
Transmitter[Encrypt/Decrypt]
Analyzer[Plug-in modules]
ACC GPS ECG SpO2
Data Collector
Service Manager
Client Application with GUI
Local Socket or IPC
(a) (b)
P
R
QS
T
(c)
Figure 2. KNOWME Application: (a) The Components of KMCore (b)A Screenshot of KMClient Running on N95 (c) ECG Signal
tation [2], [3], sampling rate versus accuracy [4], [5], [6], tothe best of our knowledge, there is no published work thatprovides a comprehensive quantification of energy costs ofthe various choices a designer has to make. Thus the goalof this paper is twofold: first, we provide a comprehen-sive energy consumption evaluation of the various WBANdesign choices using a Nokia N95 phone. As a secondgoal, using the knowledge gained from the evaluations wepropose Active Energy Profiling (AEP) strategy that usesshort profiling intervals to automatically determine the bestenergy efficient operating point of a WBAN. In this studywe use KNOWME [7], a WBAN used for pediatric obesitymonitoring, as a demonstration vehicle to highlight theenergy consumption tradeoffs.
The rest of this paper is organized as follows: Section IIdescribes KNOWME, the WBAN framework used in thisstudy. Section III shows the experimental setup used toevaluate the effectiveness of our proposed architecture andpresents results from our evaluations. We then make use ofthe observed energy consumption tradeoffs to describe andevaluate AEP in Section IV. Section V describes previousstudies that are related to our work. Finally, we conclude inSection VI and discuss future directions.
II. KNOWME PLATFORM
In this section, we provide details of the KNOWMEWBAN platform. KNOWME is a low cost mobile phonecentric WBAN which is currently deployed in Los Angelesfor pediatric obesity prevention and treatment. In the currentimplementation, each KNOWME node consists of a NokiaN95 mobile phone (N95) and four sensors, namely tri-axialaccelerometers (ACC), electrocardiograph sensor (ECG) ,blood oxygen saturation sensor (OXI), and GPS. The ACC,ECG and OXI are Bluetooth enabled off-the-shelf sensorsfrom Alive Technologies, while GPS is a built-in sensoron N95. The ECG samples at 300Hz, OXI uses 100Hzsampling, ACC uses 30Hz sampling while GPS can besampled at any user-specified rate.
KNOWME software runs as a mobile application on N95.The mobile application has two components: a backgroundprocess (KMCore) for data collection in background anda client interface application (KMClient) for configuringthe sensors and data visualization. The KMCore comprises
of seven components arranged in a four-tier hierarchy: (1)device manager at the bottom-most tier (2) data collector atthe second tier (3) at the third tier there are data analyzer,local storage manager, and data transmitter and (4) a servicemanager at the top tier. Figure 2(a) shows how variouscomponents in the KMCore interact each other. There isone thread per each sensor called device manager threadthat receives data from its associated sensor. By creating aseparate thread per each sensor KNOWME continues to getdata from working sensors without being hindered by a sin-gle non-functional sensor. The data collector thread receivessensor data from each device manager and synchronizes allthe sensor data with the same timestamp into a single healthrecord. It combines several such records into a single writebuffer and sends it to the local storage manager to write thedata to the flash storage. When the flash storage runs out ofspace old data is replaced with new data in a FIFO manner.
The analyzer modules are designer defined modules thatperform domain specific tasks. In pediatric obesity man-agement domain these modules perform user state classi-fication using multi-modal signal processing algorithms. Incurrent implementation the analyzer classifies user state aseither sedentary or non-sedentary using just ACC data withSedentary Analyzer (SA) based on Support Vector Machineclassifier [8]. The transmitter module transfers data to back-end and handles data compression and encryption for privacyand energy saving.
The back-end server runs a more comprehensive suite ofclassification algorithms to detect a range of user states suchas walking, running, fidgeting, standing, sitting using ECGand ACC sensor data with multi-modal signal processing [9].Such finer classification is used by the physicians at theback-end to get a comprehensive understanding of userbehavior and to precisely measure the calories burned. Back-end server stores sensor data indefinitely. In other words, thedata stored on the back-end server is a complete record of aperson’s physical activity history, and the most recent timewindow of this history is stored on the mobile phone’s flashstorage.
The last component of the KMCore application is aservice manager thread that uses sockets or inter-processcommunication (IPC) to provide the sensor data to othermobile applications running on the phone such as datavisualization application, KMClient. Figure 2(b) shows avisualization screen of the KMClient that shows how longa user is sedentary from SA.
III. ENERGY IMPACT OF DESIGN CHOICES
Using the KNOWME framework described in the priorsection, we will now provide a comprehensive evaluationof the energy consumption of the various components inKNOWME. While KNOWME is one particular implemen-tation of a WBAN, we would like to note that most WBANsthat we are aware of have very similar architecture [10], [11].
13.83
0.07
1.24
13.82
0.06
0.79
3.52
35.33
0.54
25.9738.76
0.42
12.65
0.04
517.00
147.88
2.42
377.19
91.76
1.74
0.61
0
1
10
100
1000
QDA AES Gzip QDA AES Gzip Q A G
Nokia N95 Nokia E75 iPhone 3GS
Exec
utio
n Ti
me
(Sec
onds
)
C++J2MEPyS60
Figure 3. Execution Time of Three WBAN Functions on Three Programming Languages
Model QDA AES GzipC++ J2ME PyS60 C++ J2ME PyS60 C++ J2ME PyS60
N95 6.6J 19.34J 270.97J 0.03J 0.30J 77.62J 0.50J 12.22J 1.35JE75 5.75J 15.95J 151.63J 0.02J 0.16J 36.89J 0.33J 4.93J 0.70J
iPhone 3GS 2.58J n/a n/a 0.04J n/a n/a 0.55J n/a n/a
Table IENERGY CONSUMPTION FOR THREE PROCESSING FUNCTIONS
Furthermore, where possible we quantify the energy con-sumption of basic operations without relying on KNOWMEsemantics. For instance, energy consumed for a byte of datacompression and transmission is independent of whether it isperformed within the KNOWME framework or otherwise. Ineach subsection below we evaluate the energy cost of eachcomponent of KNOWME design using multiple availablechoices.
A. Impact of Software Platform on Energy ConsumptionSelecting an appropriate software development platform
is arguably the most important factor in any system de-sign. The programming platform choice can determine thedevelopment cost in terms of person-hours as well as thesystem performance. Hence, in this section we first evaluatethe design choices available for mobile phone softwaredevelopment in terms of their energy efficiency. There arethree popular SDKs for programming Symbian OperatingSystem based phones such as N95; namely, Symbian C++,Java 2 Micro Edition (J2ME), and S60 Python (PyS60),and show their relative energy efficiency. For Android andiPhones the programming interfaces are similar to the J2MEinterfaces on Symbian.
We selected three functions that are of particular interestto WBANs, namely a heart beat detection algorithm (QRSDetection [12]), Advanced Encryption Standard (AES) en-cryption, GNU zip (Gzip) data compression. AES encryptionis commonly used to transmit the data from the mobilephone to the back-end server for data protection. Gzip isalso another commonly used function to compress databefore transmitting the data to the back-end server to reducetransmission costs. ECG signal is characterized using theP, QRS and T waves as shown in Figure 2(c). The QRSDetection Algorithm (QDA) detects R peak used as basis
of reference in ECG segmentations and is necessary torecognize heart beat. We selected QDA implementationfrom the Open Source ECG Toolbox [13]. We ported thisalgorithm to each of the three programming languages.
The first 9 bars in the Figure 3 show the execution time ofthe three functions using the three programming platforms(the remaining bars will be discussed in the next section).Table I, row labeled N95, shows the corresponding energyconsumption in joules. In this paper, we used the NokiaEnergy Profiler Tool to report energy consumption values.The tool itself is fairly lightweight and adds negligibleoverhead. We used 10 minutes of ECG data, which is180KB of data, as input to each of the three functionsQDA, AES and Gzip. Results from Figure 3 show thatPyS60 performance on AES is three orders of magnitudeworse than C++ implementation!, since PyS60 doesn’t havea just-in-time(JIT) compiler unlike PC’s. However, for QDAPyS60 is about 40X slower than Symbian C++ (comparingBars 1 and 3 in Figure 3) and has a corresponding 40Xhigher energy consumption (Column1 and Column 3 inTable I). The improved performance of PyS60 in QDA caseis attributed to efficient implementation of several built-in library functions, such as low-pass filtering in PyS60.For Gzip, PyS60 performed as fast as Symbian C++. Fur-ther analysis of PyS60 Gzip function showed that PyS60implements Gzip as a native function written in SymbianC++ and included in PyS60 as an extension module. Inessence, PyS60 implementation of Gzip is a Symbian C++implementation of Gzip.
B. Sensitivity to Hardware PlatformOne may raise the obvious concern, are the results from
prior section are specific to the underlying hardware plat-form of N95? Do these application behave differently on a
different mobile phone. In order to clarify these concerns,we repeated the same set of experiments on a Nokia E75and Apple iPhone. Table II shows relevant hardware andsoftware specifications where the mobile phones differ. Allplatforms are based on ARM cores but iPhone processoris nearly twice as fast as the other two and has also twicethe amount of memory. Hence, memory related issues likegarbage collection are likely to be more severe on Nokiaplatforms compared to iPhone. iPhone provides only oneprogramming interface, namely iPhone SDK, which is closerto the Symbian C++ in terms of programming complexity.
The second set of 9 bars in the Figure 3 show theexecution time of the three functions while running onE75. The last set of 3 bars in the Figure 3 show theexecution time of the three functions while running oniPhone. Similarly in Table I, rows labeled E75 and iPhone,show the corresponding energy consumption in joules. Com-paring results between N95 and E75 the relative impactof programming language on execution time (and energy)across all applications remain the same. Also execution timedecreases in almost all cases on E75. The primary reason forthe improved performance and energy efficiency on E75 isthat these applications are all single threaded and the higherfrequency ARM 11 processor on E75 executes them faster.iPhone executes these applications even faster compared toSymbian C++ implementation on E75. Again, the reasonis that iPhone processor is nearly 2X faster than E75. Allthese applications have similar code footprint, given that allplatforms use ARM ISA. Hence, the relative execution timedifferences of the three application remain the same.
A complete evaluation across multiple platforms for allthe results is beyond the scope of this paper since itrequires significant additional resources. Hence, we restrictour evaluation in the rest of this paper to only N95 and showresults only on this phone model.
Spec N95 E75 iPhone 3GS
CPU Dual ARM 11 ARM 11 ARM A8332Mhz 369HMz 600Mhz
Memory 128 MB RAM 85MB RAM 256MBOS Symbian S60 Symbian S60 iOS4
Table IISPECIFICATION OF THE MOBILE PHONES
C. Energy Consumption of the Sensors
After establishing the energy impact of software develop-ment choice, we now focus on the energy costs of sensingitself. In KNOWME built-in sensors such as ACC consumesenergy to perform the sensing operation while externalsensors (ECG and OXI) cause mobile phone’s battery draindue to Bluetooth communication. Table III shows the energyconsumption of the built-in phone sensors and the energyconsumption when reading data from external sensors usingBluetooth. This data is obtained while sensing for a 10minute interval using the sampling rates shown in the
table III. A Symbian C++ application is used for reading thesensor information. ECG generates 300 sample per secondwhile OXI generates 100 samples per second. However,these sensor samples are internally buffered in the sensor andbulk transmitted over the Bluetooth channel. Although ECGtakes 300 samples it only transmits 4 packets per second,each packet has 75 sensor samples. OXI transmits 10 packetsper second. Hence, the energy consumption while receivingdata from OXI sensor is slightly higher than when commu-nicating with ECG. Interestingly, when both ECG and OXIconcurrently send data the mobile phone is more energyefficient since the energy expenditure is much less than thesum of the energy spent when both sensors transmit datain isolation. The energy expended in putting the bluetoothradio in an active listening mode is amortized over bothsensors when hearing from the two sensors simultaneously.The Built-in ACC consumes 38 Joules for 10 minutes whilegenerating 30 samples per second.
Sensor Energy (J) Sampling Rate Xmit RateBuilt-in ACC 37.804 30 30
ECG 114.846 300 4OXI 137.433 100 10
ECG&OXI 156.419 300 & 100 4 & 10Assisted GPS 53.994 0.003 0.003
Table IIIENERGY COST OF SENSOR READINGS
D. Energy Consumption of GPS
Table III also shows the GPS energy consumption usingassisted GPS technology used in N95. In the 10 minute in-terval we made two GPS readings and hence the sample rateis 0.0033 samples per second. GPS consumes significantlyhigher power per each sample than any of the other sensingfunctions in KNOWME. Given that GPS is an energy-intensive operation mobile phones provide multiple optionsfor obtaining location information. In particular, when usingN95 the user has four choices: Bluetooth based externalGPS, Assisted GPS, Traditional GPS with no assist, andnetwork-based GPS that uses only cell towers to provideapproximate position information. Figure 4 shows energyconsumption when GPS is processing a first request usingall four approaches. Generally, once the position is known,the next GPS reading cost is reduced. For example, in theassisted mode GPS, the first reading cost for GPS is 29Joules per sample, whereas from the second reading it isreduces to 25 Joules. The figure shows tradeoffs in the powerconsumption and the time to obtain the first GPS readingusing all four methods. In Figure 4 the Bluetooth basedexternal GPS power consumption shows only the mobilephone power consumption for establishing a Bluetooth linkand read the GPS coordinates. There is a spike in thepower consumption when the connection is established andthe data is read over the Bluetooth channel and the powerconsumption drops down to the idle power when Bluetooth
0
0.5
1
1.5
2
2.5
0 25 50 75 100
Pow
er (W
)
Time (Seconds)
Bluetooth GPS
0
0.5
1
1.5
2
2.5
0 25 50 75 100
Pow
er (W
)
Time (Seconds)
Assisted GPS
0
0.5
1
1.5
2
2.5
0 25 50 75 100
Pow
er (W
)
Time (Seconds)
Integrated GPS
0
0.5
1
1.5
2
2.5
0 25 50 75 100
Pow
er (W
)
Time (Seconds)
Network based
Figure 4. Energy Cost of Positioning Methods
is ON but not actively sending/receiving data. The AssistedGPS curve shows a large power spike when it communicateswith the cell tower to get the rough location first. Once thecell tower provides the orbital data of GPS satellites theGPS receiver on the mobile phone can narrow the search forsatellite signals and quickly obtain the position information.In our measurements this approach took roughly 15 secondsto receive the position information from network and further35 seconds to retrieve the precise position from a cold start.The third curve labeled Integrated GPS is the basic nonassisted GPS. In this mode the GPS receiver continuouslyscans for the satellite information. This approach uses lowerpeak power but takes nearly 100 seconds before obtainingthe position information due to the absence of any assistancefrom the cellular network; the total energy consumed byIntegrated GPS is 33.9 Joules. The last curve shows thepower consumption of Network based position informationwhich, like Assisted GPS, communicates with cell towerto triangulate its approximate position information but nofurther data is retrieved from satellites. Hence network-basedGPS also consumes roughly the same power as AssistedGPS initially when communicating with the cell tower forthe 15 seconds. The power consumption then drops to idlepower since it does not try to compute accurate positioninformation by communicating with the satellites. Based onthe total energy consumption (Power consumption * time toget GPS reading) our evaluations show Network-based GPSis best for saving energy in a WBAN (13 Joules per sample),even though location data is only approximate. Network-based GPS is more than 2X energy efficient than AssistedGPS. When precise location is needed then Assisted GPS isthe best option.
E. Storage Costs
Once the sensor data is received the mobile phonemay write the data to phone’s flash memory for furtheranalysis. Figure 5 shows the battery level of the mobilephone as we continuously sense data from ECG, OXI andwrite sensor data to the flash memory. The curve labeledALL UnBuffered shows the battery level on the mobilephone as we write each packet of data immediately to thelocal flash without any buffering. In other words, everysensor sample received is immediately written to the flashmemory. It is well known that flash energy efficiency issignificantly compromised for small writes. Flash writesmust be done at the size of a page granularity, typically 4KB
pages. If a smaller than page size write is performed usuallythe page that is being modified must be first read from theflash into a DRAM buffer and the bytes that are going tobe written are updated in the DRAM buffer. Then the entireDRAM buffer is written back to flash. Hence, writes lead toa read-modify-write sequence in the Flash memory, whereeven a few bytes of write translate to a full page write, whichis referred to as write amplification effect [14].
The curve labeled ALL Buffered shows the battery levelif we buffer the writes to DRAM and send large chunks towrite to the flash. In this case we buffered sensor data till wereceive at least 100 packets from a sensor. Then we write thebuffered data to the flash. As can be seen buffering improvesthe battery life from 240 minutes to 299 minutes. Just a noteof caution that the battery life time here does include the costof using Bluetooth to receive data as well. Hence, the 240minutes of battery life is not just due to flash writes only.Rather we focus on the difference in the battery life timewith and without buffered writing to the flash, rather thanthe absolute values. The difference of 50 minutes translatesinto an additional 25% increase in the battery life time inthis experiment.
0 50 100 150 200 250 300 3500
20
40
60
80
100
Time (Minutes)
Bat
tery
Life
(%)
All UnbufferedAll Buffered
Figure 5. Battery Drain With Storage
F. Compute Versus CommunicateThe mobile phone in KNOWME is not just a sensor data
collection node but as described in Section II there is anAnalyzer module that can perform local data analysis ofthe sensed data and a Transmitter module that transmitsdata to the back-end server, optionally using compressionand-or encryption. Hence, the last tradeoff we consider inthis study is the energy consumption cost of performinglocal data analysis versus performing data analysis on theback-end server but pay for the data communication energy.This compute versus communication cost is not uniqueto KNOWME as we expect most WBANs to make thisfundamental tradeoff.
0.0
0.4
0.8
1.2
1.6
2.0
0 10 20 30 40
Pow
er (W
)
Time (Seconds)
ConnectionTransferTail
WiFi
EDGE
3G
Figure 6. Three Phases of Transmissions
1) Communication Costs: To quantify the energy costs ofcommunication we created a testbed. The testbed can senddata from mobile phone to the back-end server using either:3G, EDGE, Wi-Fi. AT&T broadband network is used for3G and EDGE, while an 802.11g Linksys router is usedfor Wi-Fi. We varied the data size transmitted to the back-end from 100KB to 1000KB. As the performance of mobilewireless networks vary from place to place and from carrierto carrier, we tested all of data transfer measurements fromthe same location during early morning within one hour toreduce network congestion problems with other users. Werepeated this study multiple times, but always done at thesame time of the day, to measure day to day variations.
A data transmission consists of three phases, namely aconnection phase, a transfer phase and a tail phase. Figure 6shows the power consumption during the three phases forthe three wireless data transmission approaches. In thisexperiment we used a 200KB data transfer. Due to shorterrange, even though Wi-Fi has much higher bandwidth thepeak power consumed is only slightly worse than 3G andEDGE radios on N95.
Figure 7 shows data transmission (uplink) energy costs ofthree of wireless interfaces as we increase the size of datatransfer from 100KB to 1000KB. Wi-Fi is the most energyefficient across all data packet sizes. Hence, the overallenergy consumption using Wi-Fi is significantly less thaneither 3G/EGDE in our setup. Obviously, due to limited Wi-Fi coverage a practical WBAN implementation will mostlikely use either 3G/EDGE for real time data transfer formobile users. In this experiment, 3G consumes more energythan EDGE until about 400KB of data size. In order tounderstand the reason, Table IV shows average connectionand tail energy costs of all three network interfaces. Theconnection and tail energy of 3G are much higher thanEDGE, while the transfer energy is lower. Hence for smalldata packets 3G consumes more energy than EDGE. As thedata packet size increases beyond 400KB, the transfer energydominates the overall energy costs and hence 3G consumesless energy than EDGE.
2) Local or Remote Computation: In KNOWME themost complex data analysis function is to detect user state
30
40
50
60
70
Ener
gy (J
oule
s)
TailTransferConnection
10.85
23.89
43.04
63.74
70.06
19.98
26.72
34.77
43.8346.24
1.17 1.99 3.53 5.36 6.11
0
10
20
30
40
50
60
70
100 300 600 900 1000 100 300 600 900 1000 100 300 600 900 1000
EDGE 3G Wi-Fi
Ener
gy (J
oule
s)
Data Size (KB)
TailTransferConnection
Figure 7. Data Transmission Costs (Uplink)
Meidum Connection Energy (J) Tail EnergyEDGE 0.346 2.987
3G 2.331 10.752Wi-Fi 0.132 0.166
Table IVCONNECTION AND TAIL ENERGY COSTS
to identify long phases of physical inactivity (sedentarybehavior). The choice of whether to perform the user statedetection on the mobile phone or on the back-end dependson the total energy cost taking several factors into account.Consider a simple case where we are interested in perform-ing QDA on 10 minutes of ECG data, which is 180KB ofdata. Figure 8 shows the energy cost of this computationfor local and remote computation. The first two bars in thegraph show the energy cost of local computation when QDAis implemented in C++ or J2ME. The second set of threebars show the transmission cost to perform data analysison the remote server using three different transfer options:EDGE, 3G and WiFi. The last set of 6 bars show the energycost when data is compressed and then transmitted. Thecompression algorithm is implemented in C++ and J2MEand the transfer options are EDGE, 3G and WiFi.
Let us consider J2ME implementation of QDA. The localcomputation cost is 19.34 Joules. The remote computationcost (without Gzip) varies between 1.46 Joules using WiFiup to 22.72 Joules using 3G. On the other hand the remotecomputation cost with Gzip implemented in J2ME variesfrom 13.46 Joules using WiFI to 32.89 Joules using 3G.Now consider C++ implementation of the QDA. The localcomputation cost is 6.6 Joules. The remote computationcost without Gzip remain the same as before since there isno software platform dependence on transmission cost. Butwhen Gzip is also implemented in C++ the energy cost variesbetween 1.74 Joules using WiFi up to 21.17 Joules using3G. When WiFi is available it is clearly energy efficient toperform remote computation. But when the user is roaming,which will be a common case in WBAN operation, localcomputation is better than EDGE or 3G cost when QDA isimplemented in C++. But if QDA implemented using J2MEthen then remote computation using EDGE and without Gzipcompression (15.86 Joules) is better.
6.6
19.34
15.86
22.72
1.46
12.6
21.17
1.74
24.32
32.89
13.46
0
5
10
15
20
25
30
35
Ener
gy (J
oule
s)EDGE 3G WiFi
C++ J2MEC++ J2ME
XMIT ZIP_XMITRemote Computation
LocalComputation
Figure 8. Local vs Remote Computation of QDA
Even in this simple scenario the choice of remote versuslocal computation is a complex function of which softwareplatform the application is developed under, the wirelessradio being used and whether or not data is compressed.We even simplified the discussion by removing the networksignal quality issues that may alter the energy costs dy-namically; as explained earlier, in our setup we used thenetwork during the least congested time and from a locationwith the best signal quality. Through this simple experimentwe demonstrate that there is no single statically best choicewhen it comes to trading off energy costs of computationwith communication.
G. Optimal ConfigurationIn this section we summarize our results and conclusions
from the WBAN characterization experiments.• It is qualitatively obvious that interpretive languages
are likely to be slower than languages that run natively.But, there is growing trend in traditional computing touse interpretive languages due to their programmingsimplicity and portability. However, in the WBANdomain given the stringent battery constraints nativeexecution provides significant energy savings.
• It is more energy efficient to communicate with multi-ple Bluetooth-enabled sensors concurrently rather thansequentially. Concurrent connections amortize the en-ergy cost of connection establishment as well as reduceenergy due to improved utilization of residual band-width.
• For localization service, we considered four differenttypes of services with different energy and locationaccuracy tradeoffs. This tradeoff is an application de-pendent choice but our results show at least 2X im-provement when using Network-based GPS comparedto Assisted GPS.
• Buffering data in the flash storage before transmissionadds a small delay before the data is received at theback-end. Even for WBANs that need real-time data atthe back-end the additional delay due to buffering isminimal while it improves energy efficiency by at least25%.
• For data transmission, WiFi has the lowest energy costfor data transmission. On cellular network, however, 3Gis not always more energy efficient than 2G network,
since for small data packets 2G network is more energyefficient that 3G due to smaller connection and tail costsof 2G.
IV. ACTIVE ENERGY PROFILING METHOD
The previous section quantified the energy cost of eachsub-component within a WBAN. It is clear that there isno single design choice that optimizes energy cost underall operating conditions. To improve energy efficiency evenin the presence of dynamic in energy usage we present adynamic approach to energy management, called the ActiveEnergy Profiling (AEP) approach.
We first present a general approach for implementing AEPin any WBAN. Later we present our specific implementationof AEP within the KNOWME implementation limitations.An idealized AEP uses a short profiling phase where ittests the various choices for WBAN operation. The profilingphase first decides how much sensor sampling is necessaryfor achieving the required user state detection accuracy.Optimal sensor sampling rate for user state detection maybe computed using approaches described in [15]. It thenruns the sensor analysis algorithms, that are specific to theWBAN implementation, locally on the mobile phone. Itwill use sensor samples collected over a short profile timewindow to perform local analysis. AEP then measures theenergy consumption for local computation. AEP measuresthe communication cost of transmitting the same sensor datato a back-end where the analysis algorithms may run on aserver. It then receives the results from data analysis from theserver. AEP measures the energy consumption of the datatransmission using both uncompressed and compressed data.Once the profiling phase is complete AEP then switches toa regular operating mode. During regular operation sensorsare sampled at the optimal rate as calculated during profilingphase for achieving desired accuracy. If local computationis more energy efficient than remote computation then AEPselects that option for data analysis. If remote computationis more efficient AEP then selects the wireless radio withleast energy consumption as measured during profiling phasebased on network signal quality. Thus during regular op-eration energy consumption is same as the lowest energyoption measured during profile phase. However, the regularoperating mode may drift from the optimal operating modeover time. Hence, the regular operating mode is interruptedwhenever there is change in the system state. A change canbe triggered due to three reasons: (1) when the user movesto a different location, or (2) when an interesting event isdetected during sensor data analysis, or (3) after a predefinedtime quantum has elapsed. AEP as described above is asimple and yet powerful approach to automatically optimizeWBAN’s energy consumption.
A. AEP Implementation in KNOWMEThe implementation of AEP within KNOWME is shown
in the flowchart in Figure 9. In this implementation we use
AEP to optimize on the two most energy consuming oper-ations in KNOWME, namely GPS and data transmission.The flow chart on the left shows the sequence of stepsin the baseline KNOWME. The system collects activitydata by sampling the sensors. It buffers sensor samplesfor 10 minutes. KNOWME runs the sedentary analyzerroutine (SA) once every minute that uses just ACC datato determine if a user is sedentary or not. It then getsposition information using Network-based GPS once every10 minutes. KNOWME then uploads the 10 minute geo-stamped sensor data to a back-end server using 3G.
The flow chart on the right in Figure 9 shows AEPapplied to KNOWME. The system still collects sensor dataand buffers sensor samples for 10 minutes, just as in thebaseline KNOWME. At the start of the WBAN operationAEP collects basic information regarding compression en-ergy cost per bit and how it scales with data size. It alsocomputes the typical compression ratios obtained for thedata collected from the first few data samples. It storesthe energy costs of compression and compression ratios ina local database. AEP uses SA to decide if the user hasmoved. In other words, if the user state is classified assedentary, AEP assumes the user has not moved position.When the user has not moved then it simply operates theWBAN using the current operational settings. In our currentimplementation the operational settings include (1) Whetheror not to collect GPS information, (2) whether or not to dodata compression, and (3) which wireless radio to use in thepresence of multiple transmission options. If the user stateis classified as not-sedentary then the system assumes thatthe user has moved. If the user has moved AEP then scansfor WiFi access points (APs) to detect change in locationbased on detected APs. If APs have changed then the systemrequests for position information using GPS. If a WiFi AP isavailable it then probes its internal database to see if thereis any existing profile information for that WiFi AP andGPS position. If such a profile information exists it thenuses that profile information to set the WBAN operationalsettings. If no such profile information exists then it runsa profile phase with 10 minute sensor data to measure theenergy consumption with various wireless radios and datapacket sizes with and without compression. Note that whenmultiple WiFi APs are available AEP profiles the energycost for sending data from each of the WiFi APs. It thenselects the most energy efficient setting from the profile runand sets the WBAN’s operational settings. These settings arealso stored in the profile information database and that entryis associated with a key formed by combining WiFi AP andGPS.
Using the above algorithm energy savings come frommultiple optimizations: First, AEP can skip GPS sensingwhenever a user has not moved within a 10 minute interval.Second, AEP selects between cellular and WiFi AP. Fewlimitations are worth noting. First, the sampling rate for ex-
Use 3G Networks
START
Transmit Data
END
Get Activity Data
Get GPS Coordinate
Profiling data Exist?
Energy Profiling
Choose most energy efficient method
START
Transmit Data
No
Yes
END
Get Activity Data
Moved?
Yes
No
Use previous config
Get GPS Coordinate
Changed?
Yes
No
Scan Available Access Point
(a) Baseline
Use 3G Networks
START
Transmit Data
END
Get Activity Data
Get GPS Coordinate
Profiling data Exist?
Energy Profiling and Store Data
Calculate energy cost and Choose
most energy efficient method
START
Transmit Data and Update Profiled
Data
No
Yes
END
Get Activity Data
Moved?
Yes
No
Use previous config Changed?
Yes
No
Get GPS Coordinate
Scan Available Access Point
Changed?YesNo
Retrieval data
(b) Profile Energy and Store Data
Figure 9. Comparing Energy Saving Method
ternal sensors in KNOWME are currently not programmable.Hence, we can not optimize external sensor sampling rate incurrent KNOWME. Second, KNOWME runs SA on ACCdata for providing real time feedback to the user regardingtheir sedentary state. SA consumes little energy for doing theclassification. Hence, SA computation is always run locally.The more complex user state detection using multi-modalsignal processing is done on the back-end. The last limitationis that Symbian S60 does not allow user level access forselecting EDGE or 3G network. Hence, we could not selectEDGE network even when EDGE uses less energy in caseswhere the data packet size is small. We always ended with3G in our operating locations.
B. Results from AEP Implementation
For the data presented in this section we ran KNOWMEon two N95 phones (identical in all respects, including bat-tery age). On one phone we ran the baseline KNOWME andthe second phone ran AEP implementation of KNOWME,as described in the previous section. In this experiment theuser is moving throughout the experiment, detected as nonsedentary by SA, between different locations and comes incontact with WiFi AP as well. The sensor layer consistedof two external sensors, ECG and ACC sensors. Figure 10shows how the power consumption varies with time withboth approaches for a 40 minute KNOWME run where datais transmitted to back-end once every 10 minutes. The figureis divided into three segments. The first segment (left mostsegment) shows how power consumption varies with timein the baseline KNOWME. The first spike in the powerconsumption is the GPS and second spike is 3G upload.The small spikes that occur once every minute correspondto the power consumption of SA that runs every minute.This pattern repeats every 10 minutes irrespective of userstates.
The last two segments of Figure 10 show the powerconsumption with AEP. The second segment shows when
0
0.4
0.8
1.2
1.6
2
2.4
10 15 20
Pow
er (m
W)
Time (Minutes)
0
0.4
0.8
1.2
1.6
2
2.4
10 15 20 25 30 35 40Time (Minutes)
Bluetooth Communication with Two Alive Heart Rate Monitors
3G w/o AEP 3G w/ AEP
3G Upload Positioning
Bluetooth Communication with Two Alive Heart Rate Monitors
3G Upload w/ Gzip Energy Profiling
Positioning
WiFi Scan
Two WiFi APs & 3G w/ AEP
WiFi Upload w/ Gzip Profiling with Three Networks Positioning
WiFi Scan
SA SA
Figure 10. Power usage of various cases
the user is roaming and hence there is only 3G network. Thelast segment shows power consumption when the user comesin proximity of two known WiFi APs. The system first doesa WiFi scan to see if user has moved. But at the start ithas no position information. So it gets position informationby GPS sensing just as in baseline KNOWME. After GPSsensing the new power spike corresponds to energy profiling.During this profile run the system tries to upload data using3G with and without Gzip. Once the profiling phase is overthe system uses 3G to upload compressed data as it wasdetermined to be the best energy saving option. At the nextinterval there is a short WiFi scan power spike since the useris not sedentary. In this case the user has not moved to anew location and hence WiFi scan also determines the samesince no APs are detected. During this intervals there is aclear absence of GPS and profiling power spikes since thesystem detects that the user has stayed within the same areaas during the profile phase. Hence AEP simply uses WBANsettings that were selected from the previous profile phase.
At time 25 the user has moved to a new location wherethere are two WiFi APs in addition to 3G. At 30 beforestarting energy intensive GPS and data transmission oper-ation AEP starts the profile phase. There is a power spikecorresponding to WiFi scan which now determines that userhas moved and it also determines that there are two new APsat this location. The system then uses GPS sensing whichconfirms that the user has in fact moved to a new location.The profile phase now has three spikes that correspond to thesystem sending data using the two WiFi APs and 3G. Onceprofiling is complete it selects WiFi. It continues to use WiFiaccess point to reduce overall energy consumption as longthe user has not moved too far away. Note that this figurejust demonstrates how AEP dynamically adapts to changingconditions. In a true WBAN operation the user does notmove as frequently as we have shown in this figure. Hence,profiling is not done as frequently and the system operatesin optimal mode for long periods of time before needing anew profile run.
The net energy reduction after one hour of operation withAEP is shown in Figure 11. Each bar measures the totalenergy for one hour of KNOWME operation. The first baris the baseline KNOWME. The second bar is AEP with
only 3G. The third bar is AEP with 3G and two WiFiAPs. The bluetooth data transmission costs stay the samein all approaches, as to be expected given that externalsensor sampling rate could not be programmed, due tohardware limitation in our current off-the-shelf componentsimplementation. The cost of profiling is less than 1% ofthe total energy cost. However, the benefits of profiling areclear. AEP with just 3G reduces the energy consumptionfrom 1114 Joules to 980 Joules, a 12% improvement. AEPwith two WiFis and 3G reduce the energy cost to 918Joules, an 18% energy reduction. targets for reduction itreduces the energy consumption to 118 joules, a 62% energyimprovement.
918.329
980.549
1114.187
0 200 400 600 800 1000 1200
(c)
(b)
(a)
Energy (Joules)
Bluetooth SA Transmission GPS Energy Profiling WiFi Scan Gzip
Figure 11. Comparison of Energy Consumption (a) Baseline (b) AEP with3G Only (c) AEP with Two Wi-Fi APs & 3G
V. RELATED WORKS
The popularity of WBANs for health monitoring has beenincreasing in the recent years. They are being deployed toassist in physical rehabilitation [16], obesity monitoring [7],[17], assisted living [18]. All these prior studies focusedon the usability of the system in terms of computer-humaninterface. But as shown in our research, understandingenergy implications of WBAN, from design to operation,will significantly improve the battery life and benefit manyof these prior WBAN implementations.
In [3] the authors described MAUI which is an automatedsystem that can switch between local and remote computa-tion based on round trip time of a request response cycle.MAUI relies on flexibility of managed code environmentto create two versions of any computational task, one thatruns locally on a phone and second that runs remotelyon a server. During runtime it computes the energy cost
of local computation versus transferring state to a remotesite based on current network conditions. It then invokesremote computation using RPC whenever that option ismore energy efficient. Our research differs in two notableways. We first characterizes the energy consumption of allaspects of a typical WBAN, software development platform,sensing, GPS, data buffering, and finally remote versuslocal computation. Furthermore, the AEP approach takes abroader set of criteria into consideration to automaticallydecide on the best WBAN operational point.
Viredaz et al. [19] discussed methods for improving en-ergy consumption in hand-held devices. They detect periodsof idle time in a mobile device and use voltage frequencyscaling to reduce power consumption. Shih et al. [20]showed that using wake-on-wireless a PDA can be put intosleep mode and woken up only on an incoming call orwhen the user is actively using the device. Turdecken [21]demonstrates how to use hierarchical power managementto reduce energy consumption. In this context they attacha low power mote to a mobile node and use the mote tocontinuously monitor incoming packets. The mote wakes upthe mobile device when an incoming packet is detected. Thenotion of hierarchical energy management is exploited at amuch finer granularity in EEMSS [1]. EEMSS categorizesall the sensors on a mobile phone into a hierarchy and thenactivates low energy sensor which will in turn decide whento activate a higher energy intensive sensor.
Energy efficiency in the context of communication iswell studied. Energy efficient algorithms for wireless sensornetworks have been proposed in [22], [23], [24]. Recentlystudies have also done energy measurement of wireless datatransmission using various network interfaces [25]. Theyshow that data transmission energy varies widely from onelocation to another and may also vary at the same locationdepending on the time. Hence, they also argue that dynamicrouting is necessary for optimizing energy. In [26] theauthors introduce Wiffler which is designed for a vehicularnetwork for optimizing data throughput. Wiffler can changenetwork interface between WiFi and 3G depending onnetwork condition. It uses historical data to predict futureavailable WiFi APs. Since Wiffler is geared toward vehicularnetwork it cares more about bandwidth, whereas a WBANis sensitive to battery consumption. Breadcrumbs [27] tracksuser’s movement to generate connectivity forecasts Ra etal. [28] focused on dynamically selecting between variouswireless radios. They introduce SALSA that uses Lyapunovoptimization framework to automatically decide when tosend data and when to defer data transmission and waitfor better channel availability so as to optimize the overallenergy-delay tradeoffs. Again many of these approachesuse prediction of WiFi APs or user movement to optimizeenergy of at least one component that is used in KNOWME.We need to carefully develop these prediction models inKNOWME context and we can then take advantage of these
prior studies to further reduce energy. Even without relyingon user movement prediction AEP provides significant ben-efits.
While there are disparate sources of some of the energyconsumption information none of the previous studies havedone a systematic and comprehensive analysis of the energyconsumption of a WBAN starting with the initial systemdesign choices to the data transmission. We believe that ourresearch also sheds new light on issues such as programma-bility and energy efficiency, energy compression costs ofsensor data and the energy cost of storing data locally onmobile phones. Given the energy consumption uncertaintyin WBAN it is necessary to use a profile based dynamicadaptation to minimize energy consumption across all layersof a WBAN.
VI. CONCLUSIONS
Limited battery life of mobile phones is a significant bot-tleneck to a wider deployment of WBANs. As the popularityof WBANs continue to increase there is a need to understandwhere exactly the energy consumption goes in a WBAN.This paper presents a comprehensive quantification andanalysis of energy consumption of the various components inKNOWME, which is one implementation of a WBAN. Thereare several tradeoffs a designer has to make to reduce energyconsumption. At the software level our results showed thatimproving energy efficiency is as important a metric asprogrammer productivity in WBANs. We also quantifiedhow energy consumption can be curtailed by reducing thesensor sampling rate or using approximate sensing, such asnetwork based location sensing. We also show that whilethe quantitative results presented here may differ from onemobile phone to another the qualitative conclusions drawnare more broadly valid. We should also note that the findingsof this work may also be helpful for other classes ofapplications that use sense-compute-communicate cycle.
Inspired by the results from our measurement study weimplemented Active Energy Profiling (AEP). AEP is adynamic approach that automatically optimize the energyconsumption based on the real time operating conditions of aWBAN. Given the uncertainty of energy consumption acrossvarious WBAN tasks no single statically selected operatingpoint can effectively reduce WBAN energy consumption.Hence, AEP uses a short profile run to dynamically computethe energy costs of various WBAN tasks and automaticallyselects the operating point that best reduces energy consump-tion during that time interval. In a one hour operation ofKNOWME AEP can reduce the energy consumption by 12%even when there are no alternatives to 3G data transmission.When multiple network interfaces are available AEP canreduce the overall KNOWME energy by 18%.
REFERENCES
[1] Y. Wang, J. Lin, M. Annavaram, Q. A. Jacobson, J. Hong,B. Krishnamachari, and N. Sadeh, “A framework of energy
efficient mobile sensing for automatic user state recognition,”in MobiSys ’09: Proceedings of the 7th international confer-ence on Mobile systems, applications, and services, 2009, pp.179–192.
[2] P. Aghera, T. Rosing, D. Fang, and K. Patrick, “Posterabstract: Energy management in wireless healthcare systems,”in Information Processing in Sensor Networks, 2009. IPSN2009. International Conference on, april 2009, pp. 363 –364.
[3] E. Cuervo, A. Balasubramanian, D.-k. Cho, A. Wolman,S. Saroiu, R. Chandra, and P. Bahl, “Maui: making smart-phones last longer with code offload,” in MobiSys ’10:Proceedings of the 8th international conference on Mobilesystems, applications, and services, 2010, pp. 49–62.
[4] S. Kang, J. Lee, H. Jang, H. Lee, Y. Lee, S. Park, T. Park,and J. Song, “Seemon: scalable and energy-efficient contextmonitoring framework for sensor-rich mobile environments,”in MobiSys ’08: Proceeding of the 6th international confer-ence on Mobile systems, applications, and services, 2008, pp.267–280.
[5] A. Krause, M. Ihmig, E. Rankin, D. Leong, S. Gupta,D. Siewiorek, A. Smailagic, M. Deisher, and U. Sengupta,“Trading off prediction accuracy and power consumption forcontext-aware wearable computing,” in ISWC ’05: Proceed-ings of the Ninth IEEE International Symposium on WearableComputers, 2005, pp. 20–26.
[6] Y. Wang, B. Krishnamachari, Q. Zhao, and M. Annavaram,“Markov-optimal sensing policy for user state estimationin mobile devices,” in MobiCASE ’09: Proceedings of TheFirst Annual International Conference on Mobile Computing,Applications, and Services, 2009.
[7] M. Annavaram, N. Medvidovic, U. Mitra, S. Narayanan,G. Sukhatme, Z. Meng, S. Qiu, R. Kumar, G. Thatte, andD. Spruijt-Metz, “Multimodal sensing for pediatric obesityapplications,” in Proceedings of International Workshop onUrban, Community, and Social Applications of NetworkedSensing Systems (UrbanSense08), November 2008.
[8] M. Li, V. Rozgica, G. Thatte, S. Lee, A. Emken, M. An-navaram, U. Mitra, D. Spruijt-Metz, and S. Narayanan, “Mul-timodal physical activity recognition by fusing temporal andcepstral information.” IEEE Trans Neural Syst Rehabil Eng,vol. 18, no. 4, pp. 369–80, 2010.
[9] J. C. Sriram, M. Shin, T. Choudhury, and D. Kotz, “Activity-aware ecg-based patient authentication for remote healthmonitoring,” in ICMI-MLMI ’09: Proceedings of the 2009international conference on Multimodal interfaces, 2009, pp.297–304.
[10] K. Patrick, W. G. Griswold, F. Raab, and S. S. Intille, “Healthand the mobile phone,” American Journal of PreventiveMedicine, vol. 35, no. 2, pp. 177 – 181, 2008.
[11] J. Ryder, B. Longstaff, S. Reddy, and D. Estrin, “Ambulation:A tool for monitoring mobility patterns over time usingmobile phones,” in CSE ’09: Proceedings of the 2009 Interna-tional Conference on Computational Science and Engineering- Volume 04, 2009, pp. 927–931.
[12] J. Pan and W. J. Tompkins, “A real-time qrs detectionalgorithm,” Biomedical Engineering, IEEE Transactions on,vol. BME-32, no. 3, pp. 230–236, March 1985.
[13] The Open Source ECG Toolbox, http://ee.sharif.edu/∼ecg.[14] N. Agrawal, V. Prabhakaran, T. Wobber, J. D. Davis, M. Man-
asse, and R. Panigrahy, “Design tradeoffs for ssd perfor-mance,” in ATC’08: USENIX 2008 Annual Technical Con-ference on Annual Technical Conference, 2008, pp. 57–70.
[15] Y. Wang, B. Krishnamachari, Q. Zhao, and M. Annavaram,“Markov-optimal sensing policy for user state estimation in
mobile devices,” in Proceedings of the 9th ACM/IEEE In-ternational Conference on Information Processing in SensorNetworks, 2010, pp. 268–278.
[16] E. Jovanov, A. Milenkovic, C. Otto, and P. de Groen, “Awireless body area network of intelligent motion sensorsfor computer assisted physical rehabilitation,” Journal ofNeuroEngineering and Rehabilitation, vol. 2, no. 1, p. 6,2005.
[17] S. Consolvo, D. W. McDonald, T. Toscos, M. Y. Chen,J. Froehlich, B. Harrison, P. Klasnja, A. LaMarca,L. LeGrand, R. Libby, I. Smith, and J. A. Landay, “Activitysensing in the wild: a field trial of ubifit garden,” in CHI ’08:Proceeding of the twenty-sixth annual SIGCHI conference onHuman factors in computing systems, 2008, pp. 1797–1806.
[18] N. Noury, “Ailisa : experimental platforms to evaluate remotecare and assistive technologies in gerontology,” in Enterprisenetworking and Computing in Healthcare Industry, 2005.HEALTHCOM 2005. Proceedings of 7th International Work-shop on, june 2005, pp. 67 – 72.
[19] M. A. Viredaz, L. S. Brakmo, and W. R. Hamburgen, “Energymanagement on handheld devices,” Queue, vol. 1, no. 7, pp.44–52, 2003.
[20] E. Shih, P. Bahl, and M. J. Sinclair, “Wake on wireless:an event driven energy saving strategy for battery operateddevices,” in MobiCom ’02: Proceedings of the 8th annual in-ternational conference on Mobile computing and networking,2002, pp. 160–171.
[21] J. Sorber, N. Banerjee, M. D. Corner, and S. Rollins, “Tur-ducken: hierarchical power management for mobile devices,”in MobiSys ’05: Proceedings of the 3rd international confer-ence on Mobile systems, applications, and services, 2005, pp.261–274.
[22] L. Stabellini and J. Zander, “Energy efficient detection ofintermittent interference in wireless sensor networks,” InInternational Journal of Sensor Networks (IJSNet), vol. 8,no. 1, 2010.
[23] M. Shin, P. Tsang, D. Kotz, and C. Cornelius, “Deamon:energy-efficient sensor monitoring,” in SECON’09: Proceed-ings of the 6th Annual IEEE communications society con-ference on Sensor, Mesh and Ad Hoc Communications andNetworks, 2009, pp. 565–573.
[24] A. Silberstein, R. Braynard, and J. Yang, “Constraint chain-ing: on energy-efficient continuous monitoring in sensor net-works,” in Proceedings of the 2006 ACM SIGMOD interna-tional conference on Management of data, 2006, pp. 157–168.
[25] N. Balasubramanian, A. Balasubramanian, and A. Venkatara-mani, “Energy consumption in mobile phones: a measurementstudy and implications for network applications,” in IMC’09: Proceedings of the 9th ACM SIGCOMM conference onInternet measurement conference, 2009, pp. 280–293.
[26] A. Balasubramanian, R. Mahajan, and A. Venkataramani,“Augmenting mobile 3g using wifi,” in MobiSys ’10: Proceed-ings of the 8th international conference on Mobile systems,applications, and services, 2010, pp. 209–222.
[27] A. J. Nicholson and B. D. Noble, “Breadcrumbs: forecastingmobile connectivity,” in Proceedings of the 14th ACM inter-national conference on Mobile computing and networking,2008, pp. 46–57.
[28] M.-R. Ra, J. Paek, A. B. Sharma, R. Govindan, M. H. Krieger,and M. J. Neely, “Energy-delay tradeoffs in smartphone appli-cations,” in MobiSys ’10: Proceedings of the 8th internationalconference on Mobile systems, applications, and services,2010, pp. 255–270.