Wattson: Empowering Developers to
Estimate App Energy Consumption
Radhika Mittal‡ , Aman Kansal† , Ranveer Chandra†
‡ †
IIT Kharagpur, Kharagpur, India
radhikamittal.iitkgp@gmail.com
ABSTRACT
Battery life is a critical performance and user experience
metric on mobile devices. However, it is difficult for app de-
velopers to measure the energy used by their apps, and to ex-
plore how energy use might change with conditions that vary
outside of the developer’s control such as network conges-
tion, choice of mobile operator, and user settings for screen
brightness. These problems become even more challeng-
ing because a large fraction of mobile apps are developed
by small companies, freelance developers, or start-ups with-
out extensive laboratory infrastructure or expertise for power
measurement. We present an energy emulation tool that al-
lows developers to estimate the energy use for their mobile
apps on their development workstation itself. The proposed
techniques scale the emulated resources including the pro-
cessing speed and network characteristics to match the app
behavior to that on a real mobile device. We also enable
exploring multiple operating conditions that the developers
cannot easily reproduce in their lab. The estimation of en-
ergy relies on power models for various components, and we
also add new power models for components not modeled in
prior works such as AMOLED displays. We also present a
prototype implementation of this tool and evaluate it through
comparisons with real device energy measurements.
1. INTRODUCTION
Poorly written apps can sap 30 to 40% of a phone’s bat-
tery [8]. Battery lifetime is a common cause of frustration
in smartphone users. Several efforts in research and indus-
try are actively investigating techniques to improve the bat-
tery life of smartphones. These efforts range from improv-
ing battery density, to dedicated processors and accelerators
to offloading computations from the application processor.
However, despite these hardware innovations, the battery
improvements are not visible to the user. One of the pri-
mary culprits is poorly written software, which can callously
eat into the extra battery juice provided by the hardware im-
provements.
A significant portion of the battery is used when the phone
is actively used by the user. Over the last couple of years, the
active time has mostly translated to the time when the user is
running some app on her phone. Consequently, improving
1
Microsoft Research, Redmond, WA
{kansal,ranveer}@microsoft.com
the energy efficiency of the apps can significantly improve
the battery lifetime of smartphones.
However, very few tools are available for developers to
improve the energy efficiency of their apps. In fact, most
developers are not even aware of the amount of energy their
app consumes. While they could use a power meter to mea-
sure the actual energy draw for their app in a lab during
test runs, such an approach is not used in practice because
it requires the developers to purchase and set up the power
measurement equipment. Given that several developers are
hobbyists and students who may not have access to a mea-
surement lab, this approach becomes very cumbersome to
use. Furthermore, it is very difficult to perform these mea-
surements for all device hardware, all possible network con-
ditions, user settings for screen brightness, and so on. Also,
the measurement only reveals the total power used and it is
not obvious what the contribution of different components
(CPU, network, or display) is, which makes it harder to fo-
cus the optimization effort.
Another alternative is for developers to use the “battery
use” tool on Android phones, or the Nokia Energy Profiler
(NEP) on Nokia Symbian phones. These tools help end-
users identify apps that are energy hungry. However, they
do not provide useful information in the app development
phase, and furthermore, the data is not detailed enough to
help the developer improve the energy efficiency of the app.
Profiling how energy might change with varying conditions
is cumbersome with this approach.
In this paper we present a system, called Wattson, that al-
lows a developer to estimate the energy consumed by her app
over a custom run. It also enables the app developer to esti-
mate the energy consumption for different phone platforms
as well as different operating conditions. In addition to help-
ing app developers design energy efficient software, Wattson
also helps identify energy hungry portions of the code at an
early stage.
Wattson works in three steps. First, the app is run inside a
mobile device emulator by the developer on her workstation.
Wattson scales the resources from the development worksta-
tion that are provided to the mobile device emulator so that
the application takes similar time to run as it would on a real
mobile device. For instance, downloading a webpage over
a cellular data connection takes longer, and Wattson shapes
the network characteristics experienced by the mobile device
emulator to be similar to those of a real cellular data connec-
tion. The scaling of resources is tuned to match different
operating conditions, such as variable network connectivity.
Second, Wattson measures the resource consumption of the
app on the development workstation, and records a time se-
ries for each component (CPU, display, network) of the mo-
bile device emulator for the time that the app is run. This
resource consumption is scaled to express the utilization lev-
els as if the app was run on a real mobile device. Finally, it
processes the resource consumption time series through en-
ergy models of the display, processor and the network, for
desired operating conditions and user settings, and outputs a
time series of the energy consumed by the app, broken down
by component.
1.1 Contributions
Wattson design makes the following contributions:
First, to the best of our knowledge, we present the first
system that can estimate an app’s energy consumption in dif-
ferent operating conditions (carrier, signal strength, bright-
ness) without requiring expensive lab equipment and explicit
measurements with repeated runs for each operating condi-
tion.
Second, we present techniques to scale resources on the
PC to match resource consumption on the phone. For ex-
ample, we show how network traffic sent by an emulator
connected over a high speed Internet link can be scaled to
match the performance as if it were running over a cellular
network.
Third, we expand the catalog of power models available
for mobile device components. For displays, while prior
work provides models for LCD and OLED we found that
AMOLED screens are not modeled well, and hence we pro-
vide a new power model for AMOLED. For the cellular net-
work, we expand the measured parameters to include more
mobile operators.
We have tested our system with multiple applications, de-
vices, network conditions, and carrier networks. Wattson
achieves correct performance scaling for a variety of com-
monly performed application tasks. Average energy error
varied from 4% to 9% across different apps. The accuracy
of energy estimation when compared with the variability in
hardware energy measurement for the same task over multi-
ple runs indicates that Wattson can offer a better energy es-
timate by eliminating several variable factors such as back-
ground activity on the mobile device.
2. NEED TO ESTIMATE APP ENERGY
An app developer usually optimizes his app for perfor-
mance. In most cases, this implies reducing the processing
and network latency, avoiding excessive memory use, and
sometimes, also reducing the bandwidth consumption. Al-
though it might seem that performance optimizations would
2
also reduce the energy consumption of the app, performance
and energy consumption are not always correlated. In some
cases, two design choices can give exactly the same perfor-
mance but consume significantly more energy.
Scenario 1: Downloading two different images: An app
might need to display a picture, say as a background in their
game. Two pictures that have identical size and textural de-
tail, might take the same amount of time to download and
render. However, depending on the colors used in the pic-
ture, the amount of energy consumed when displaying the
picture might be very different [4]. For example, in Figure 1,
both the images have nearly the same resolution, but Image-
1 has colors that consume much higher power (1000mW)
compared to Image-2 that consumes less than 500mW. Thus,
using Image2 can greatly reduce the app energy consump-
tion.
(1) (2)
Figure 1: Image1 consumes display power of 1000mW
and Image2 consumes display power of 500mW
Scenario 2: Batching multiple downloads: An app might
need multiple files to be downloaded at some intervals. They
can either be downloaded as and when required or all of
them can be downloaded at one go. The bandwidth used and
user experience might remain the same in both cases. How-
ever, multiple downloads would result in a larger amount
of energy wastage as each download would incur some tail
energy cost for the network [15]. Batching the downloads
would consume a much lower amount of energy. For exam-
ple, both 10kB and 100kB downloads consume nearly 20J of
energy. Thus, ten spaced out 10kB downloads could result
in 200J of energy consumption, and batching them up could
save up to 90% of the energy.
Another design choice in app development is the trade-off
between native and hybrid apps. Native apps run nearly en-
tirely on the mobile device, and provide good performance.
Hybrid apps use less custom code on the phone, and down-
load a large fraction of their content from their web site.
Such a design offers portability across multiple mobile plat-
forms. There are obvious pros and cons of both designs.
However, there exists no easy mechanism for a developer to
realize the energy tradeoffs of hybrid vs. native apps.
3. Wattson SYSTEM DESIGN
The goal of Wattson is to compute the runtime energy
consumption of an app without explicitly executing it on a
mobile device. Both total energy and time series of power
consumption over time for each of the key components are
generated.
One way to generate the total energy number is to mea-
sure the actual current being drawn by the phone when the
app is running. However, requiring every app developer (a
number of whom are hobbyists and enthusiasts) to install the
measurement equipment is an arduous ask. Performing the
measurements also becomes tedious because the measure-
ments have variability due to differences in network condi-
tions, background activities, such as email synchronization
running on the phone, that may have no relationship to the
app that the developer is concerned with. While some of the
background activities can be disabled, not all operating sys-
tem activities are under the developer’s control. Further, the
measurement only shows the total energy use and does not
separate out the impact of display, network, and CPU that
can be important for the developer to make their optimiza-
tion decisions.
Instead, we investigate a modeling based approach in the
design of Wattson. Most mobile development toolchains
provide an emulator to assist in app development such as the
Android Emulator, or the Windows Phone Emulator. While
the emulators do not accurately reproduce all mobile device
characteristics, the low overhead of their use makes them
very beneficial for a variety of testing. The techniques de-
veloped in Wattson extend the capabilities of mobile device
emulators to provide an estimate of the app battery consump-
tion.
However, the design of Wattson is non-trivial. A key chal-
lenge is that the utilization of resources on the developer’s
workstation is very different than on the phone. The devel-
oper’s workstation, even if using a low end PC or a laptop,
is a much more powerful device compared to the phone. For
instance, a CPU utilization of 10% on a 3 GHz processor
with 6MB of last level cache is not a good indicator of how
much CPU will be consumed on the phone. Second, tim-
ing of events might be different when running the app on
the emulator than on the phone. Network packets may ar-
rive much faster on the development machine, causing the
user clicks for the subsequent tasks to be sooner and this
may completely change the time spent on application tasks.
These differences make it challenging to estimate the energy
correctly using the emulator on the developer’s machine.
3.1 Design Overview
We address the above challenges using a “resource scal-
ing” approach. We scale down the powerful components of
the developer machine to match the capabilities of the mo-
bile device. New scaling methods are developed for the CPU
and the network.
The other important component of Wattson is “power mod-
eling”. We use previously proposed models for CPU and
WiFi energy consumption. For the cellular interface, we
augment previously proposed models to work for different
3
carriers and signal strengths. Finally, we develop a new
model for AMOLED displays. The energy models may be
developed for all mobile devices for which app deployment
is intended; the number of models required may be reduced
by considering representative devices in various device classes
with different screen sizes and cellular network types.
A block diagram of Wattson design is shown in Figure 2.
The leftmost blocks represent the measurement of real de-
vice power characteristics required for power model gener-
ation. This is only required for the development of Wattson
and the mobile app developer does not have to perform any
of these measurements. They obtain the power models as
part of Wattson. On the developer machine, the execution
APIs for the mobile device are provided to the test appli-
cation, typically in the form of a mobile device emulator,
such as the Windows Phone Emulator or Android Emulator.
We insert resource scaling techniques between the emula-
tor and the actual hardware on the developer machine. As
the app under test is executed on the emulator, we monitor
the resource consumption using resource profiling methods
available on the development workstation. In our prototype,
the Windows performance profiling APIs are used to mon-
itor resource use. The resource consumption monitored on
the scaled resources is used in the energy calculation block
to estimate the app energy using power models.
Test Application
Emulated Mobile
Target Mobile Device Device APIs (Phone
Emulator)
Resource Scaling Resource
Resource Power
Profiling Profiling
Profiling
Hardware Resources
Power Model
Generation Developer
Workstation
Energy Calculation
App Energy use
Figure 2: Block diagram of Wattson components. The
blocks shaded in gray are used for app development in
existing systems. Wattson introduces additional blocks
enable energy estimation.
We describe resource scaling and power modeling meth-
ods for each of the modeled components in the rest of this
section.
3.2 Cellular Network (3G)
One of the significant energy hogs on the phone is the
cellular network interface. Prior work has shown that the
cellular data interface by itself can consume about 1 W of
power [15], and the instantaneous energy consumed by the
interface depends on the state of the network card.
3.2.1 Resource Scaling
The goal of resource scaling is to obtain the network re-
source consumption of the application as if executed on a
real cellular data link. One simple technique to simulate the
cellular network packet trace is to capture the packet activity
over the high speed network connection of the developer’s
machine and then stretch the timing characteristics to match
those on a lower speed link. For example, suppose a 10 sec-
ond trace would take 30 seconds over the cellular interface,
one could multiply all time-stamps of the Ethernet packet
trace by 3. A more sophisticated alternative to stretch the
trace would be replay the trace from the high speed interface
on a lower speed interface simulated using a fine grained
packet level simulator, such as QualNet or ns-3. However,
this technique has several drawbacks. A slower interface will
affect other parameters of the network flow, such as the TCP
window size, which are not captured by stretching the high
speed packet trace. Also, the stretching will not produce the
corresponding impact on other resources such as the timing
of user clicks or other tasks in the app that depends on net-
work activity.
The approach we have taken is to shape the network link
bandwidth and latency such that the observed network ac-
tivity in terms of packets sent and received is similar to the
activity that would be observed on a cellular data link for
the same communication task. We accomplish this by intro-
ducing our resource scaling code at layer 2.5 in the network
stack, that is, between IP and the MAC layer. The delay,
loss and bandwidth parameters are chosen to mimic differ-
ent network conditions. Figure 3 illustrates this approach.
The network characteristics are governed by the parameters
described below.
DEVELOPER
APPLICATION IN
EMULATOR
Wattson
Uploaded Frames Scaled Download
Layer 2.5 Traffic Shaper
Network Device Driver
Scaled Upload Downloaded Frames
Figure 3: Resource scaling for the network using layer
2.5 traffic shaping.
The latency, bandwidth and loss parameters for cellular
networks have been studied in several prior works in wireless
communications, and we rely on the existing literature to
guide our choice of these parameters.
Latency: The measurement and modeling work in [7, 10]
has characterized the cellular data link latency for 3G net-
works using a normal distribution with a mean of 200ms and
a standard deviation of 100ms. We found this model to be
valid in our own measurements of 3G network latency using
ping tests.
Bandwidth: The measurements in [20] show that 3G HS-
DPA download bandwidth varies from 500-2500 kbps and
upload bandwidth varies from 200-1600 kbps. Our measure-
ments showed bandwidths ranging from 1000-3000 kbps for
download and 800-980 kbps for upload. The bandwidth
varies due to various reasons including changes in network
congestion, wireless channel quality at the phone location,
and other factors. We model all these variations using three
different bandwidth parameters denoting bandwidth under
good, average, and poor network link quality. The parame-
ter values are set as shown in Table 1
Network quality Download (kbps) Upload (kbps)
Good 2500 1600
Average 1500 900
Poor 500 200
Table 1: Network scaling parameters for bandwidth.
Loss: Wireless links also suffer significantly more losses
compared to the high bandwidth Internet connection typi-
cally available on the development machine. To emulate link
losses, we use the well known Gilbert Elliot Channel Model,
described in [23]. According to this model, the network is
assumed to be in one of two states, denoted good and bad,
each with a different loss rate. The model also describes the
transition probabilities between the two states, that allows
simulating the losses over time. The transition probabilities
and the loss rates are shown in Figure 4. The loss rates vary
with the network link quality.
P=0.04
Network Loss Rate
Loss Rate = 0 Good 0.2
Average 0.5
Poor 0.8
Good
P=0.06
Bad
Figure 4: Loss rate parameters used for network scaling.
3G Network
Parameters State switching time is 100ms for the above transition di-
agram.
In certain instances, when the developer is using a slow
Internet connection for their developer machine, such as a
home Internet connection, then the underlying network may
itself have non-negligible latency and losses. In this case,
Wattson should first probe and estimate the network latency
using known methods [9] and then add on any additional
resource scaling to the measured characteristics.
3.2.2 Power Modeling
The power model for the 3G network must model not only
the active energy consumption when communicating data
but also the “tail” time, or the time for which the radio in-
terface remains in a higher power state after finishing the
communication activity. The tail time can be spent in the
active state itself, known as DCH, or an intermediate state,
4
known as FACH where the radio power consumption is re- with signal strength.
duced but any further communication would require a small
amount of channel slot acquisition overhead. Some radios Signal Strength DCH (mW) FACH (mW)
may have a second lower powered intermediate state known High 600 300
as PCH. After the tail time is over, the radio falls down to its Medium 800 300
idle state where the energy consumption is very low. This Low 1500 400
model was studied in depth in [15, 16] for the AT&T UMTS
network. The presented model, known as the ARO model, Table 2: Cellular interface power variation with signal
allows back-calculating the radio power state from a network strength.
packet trace. We use a cellular network power model based
on this technique. Mobile Operators. The second setup uses a power meter
However, there are two aspects that have not been looked attached to the battery terminals of a smartphone to measure
at before. First, to the best of our knowledge, prior work has power. We connected multiple devices from different mobile
not studied when the energy states change across different operators available in our region: AT&T (Samsung Focus),
carriers. Second, the energy consumed at varying received T-Mobile (HTC HD7), Verizon (HTC Trophy), and Sprint
signal strengths has not been studied. (HTC Arrive). While T-Mobile and AT&T use GSM based
To fill in the above gaps, we set up two different experi- networks with the UMTS standard from 3GPP for data. Ver-
ments, as follows, illustrated in Figure 5. izon and Sprint use the Evolution-Data Optimized (EVDO)
standard from the CDMA2000 family provided by 3GPP2.
The tail behavior on the CDMA networks is different from
that observed on the GSM based operators in that the in-
termediate states are not used. The power trace for a small
download using the device connected to Sprint’s network is
shown in Figure 6 as an example.

2500

2000
Figure 5: Experimental setups for the network power
Power (mW)

measurements using Windows Phone and the 3G proto- 1500

type board 1000

Signal Strength. This testbed uses a cellular data devel- 500

opment board from Ericsson that exposes the antenna ports. 0
We connected an RF signal strength attenuator to the antenna 0 5 10 15 20 25
Time (s)
port to vary the incoming signal strength and performed the
measurements on a weekend when the network conditions
Figure 6: Network tail energy measurement for Sprint.
were lightly loaded. The setup was located where we typi-
The data communication ends near time = 7s along the
cally observed good signal strength. The power supply leads
x-axis but the radio stays in a higher power state for an
of the development board were connected to a power meter.
additional 10 seconds after that.
The attenuator allows us to change the signal strength re-
ceived by the cellular data interface. We varied the amount Performing similar measurements for all operators with
of data downloaded and uploaded at different signal strengths multiple download sizes, we obtain tail-state parameters shown
and measured the DCH and FACH power and tail times. in Table 3.
We observed that the power consumption in DCH and
FACH states increases as the signal strength decreases and Operator DCH FACH PCH
recorded the power values. Since a developer will likely AT&T 5s 12s 0
only emulate their application with a small number of signal T-Mobile 5s 1s 1s
strength variations, we discretize the signal strength to three Verizon 6s 0 0
levels. The power measurements for the AT&T network are Sprint 10s 0 0
shown in Table 2. While these power measurements are
taken using a radio interface board and not a phone, the idle Table 3: Tail state power parameters for different oper-
power of the board can be different from that of the phone ators.
but the differences between the power levels at different sig-
nal strengths come from the radio primarily and can be used The parameters measured for the different networks might
to adapt the power model for varying signal strengths. The change after the 3GPP Rel8 fast dormancy standards are
tail times for DCH (5sec) and FACH (12sec) did not vary adopted since the new standards allow for shorter active tail

5
times under certain conditions. The models above will need
to be modified to change the tail times depending on the con-
ditions for fast dormancy.
3.3 WiFi Network
The WiFi network also consumes significant power when
in use but its power model and performance characteristics
are very different from the cellular network. The models
used for WiFi are described below.
For cases where the developer machine is connected to the
Internet using WiFi (as is common for laptops), the resource
scaling aspect is not needed. Otherwise, resource scaling
is performed using the same layer 2.5 approach as for the
cellular network. The scaling parameters may be adjusted
for WiFi characteritics that are well studied in literature [1].
The power model for Wifi is based on the PSM model
described in [11]. The Wifi interface can be in one of four
major states - Deep Sleep (10mW), Light Sleep (120mW),
Idle (400mW), and High (600mW). When no packet trans-
fer takes place, it remains in Deep Sleep state. Brief power
spikes of 250mW at intervals of 100ms are observed in this
state, and these correspond to reception of beacons from an
associated AP. When a packet is to be transmitted, the inter-
face moves to the High power state immediately. If a packet
is to be received, the radio can only learn about it at the next
beacon, and then it moves to the High power state. The ra-
dio remains at High power while the transfer is taking place,
and then moves to Idle state. It rises to High state from Idle
whenever it gets any packet to transmit or receive. If no
network activity occurs in Idle state for around 1s the radio
moves to the Light Sleep state. The Light Sleep tail time
is 500ms, after which, if no network activity occurs, it falls
back to Deep Sleep. If network activity does occur in ei-
ther the Idle or Light Sleep state, the radio changes its power
state to High again. Both Idle and Light Sleep states also
have regular spikes of additional 250mW of power spaced at
100ms to receive beacons.
The above power state transitions can be re-created di-
rectly if the network activity is known. Thus, we again cap-
ture the network trace using a network sniffing library as
part of Wattson. The trace can be combined with the power
model above to compute the power consumption.
3.4 Display
As for other components we need to resource scale the
display and model its power consumption. Fortunately, ex-
isting mobile device emulators already perform resource scal-
ing for the display: the emulated app is provided only a small
screen area representing the mobile device display. The only
scaling needed is that the emulator window may be re-sized
somewhat, changing the number of pixels in the display and
to overcome this, one may simply multiply the number of
pixels by the appropriate scaling ratio.
The power model for the display is more challenging. While
prior work has provided power models for LCD and OLED
6
displays [4], several modern mobile devices use Active Ma-
trix OLED (AMOLED) displays. The existing power mod-
els are not a good approximation for AMOLED displays
and hence we develop a new power model for this type of
displays. While the peak power of the display is similar to
that of the CPU and the network, the fraction of energy con-
sumed by the display can be much larger than the other com-
ponents since the display is constantly active throughout an
application’s use. An accurate estimation is thus important
for this most dominant energy consumer.
The OLED power model shows linear and additive prop-
erties: the energy consumption of the display as a whole is
the sum of the energy consumption of the individual pixels
and the the energy use of a pixel is the sum of the R,G, and
B components. Further, the power model for the R,G, and B
components is a linear function of the color component mag-
nitudes, provided they are converted from the standard RGB
(sRGB) color space to linear RGB. For AMOLED displays
this model breaks down as the magnitude of the pixel color
components increases. Figure 7 shows the power measured
for the Samsung Focus device with the AMOLED display
set to different colors. The R,G and B components labeled
are converted to linear RGB. The linear model holds at low
magnitudes. However, at high magnitudes (the colors in the
surface labeled B=255), the linear model no longer holds.
The power is scaled down when each of the color compo-
nents is emitting a higher intensity light.
1400
1200
B=255
1000
Power (mW)
800
600
400
200
300 B=0
300
200
200
100
100
0 0
R G
Figure 7: Power measurements for different colors on an
AMOLED display.
Studying the AMOLED display characteristics with more
measurements, we further found that the power consumed
is not just a function the color of a pixel but also depends
on the properties of the other pixels in the image. Thus, the
additive nature of the OLED model also does not apply to
AMOLED. Figure 8 shows the power consumption at vary-
ing fractions of the screen set to white. The graph shows
the power predicted using the additive OLED model where
the power would increase linearly with the area, as well as
the observed ground truth. It seems obvious that the power only significant for higher color magnitudes. The deviation
is scaled down as a greater portion of the screen is emitting does become significant at different threshold for different
brighter light levels. colors and we approximate that using four different thresh-
olds: one for R+G+B magnitude, and one each for R+G,
2500 G+B, and B+R magnitudes, denoted τRGB , τRG , τGB and
Measured OLED Model
2000 τBR respectively. The power scale down is assumed to be
1500 proportional to the fraction of such high intensity pixels.
Power (mW)

The final model is summarized as follows. Suppose the

1000
lookup entry for a color indexed by [r, g, b] by finding the
500 nearest index in the lookup table is denoted l(r, g, b). Let the
0 power consumption of the entire screen, obtained by sum-
10 30 50 70 90 ming up the powers over all pixels of a screen-shot s, be de-
White display fraction (%)
noted L(s). Suppose the fraction of pixels in s that exceed
Figure 8: AMOLED power changes as the fraction of either of the thresholds τRGB , τRG , τGB and τBR is denoted
white colored pixels changes. β(s). Also, suppose that the power consumption for the dis-
play using the additive OLED power model is computed as
Interestingly, we also found through additional measure- O(s). Then the power consumption when the screen display
ments that the scaling down of power not only depends on matches s is computed as:
area but varies by color. Figure 9 shows an example mea- Pdisplay = β(s) ∗ L(s) + (1 − β(s)) ∗ O(s) (1)
surement for two colors, compared with the OLED model
based predicted values. While the predicted values are dif- One further optimization to the above model is that in-
ferent for the two colors, what is important to note is that stead of considering all pixel values on the screen, we could
the difference between the measured and predicted values is randomly select a smaller fraction of the pixels and use those
also different for the two colors: s2 is significantly greater as representative of the entire screen. The accuracy of this
than s1. model along with sub-sampling is evaluated in Section 5.
From an implementation perspective, the pixel informa-
1480 RG - Meaured tion of the display is easy to obtain when an app is being
RG - OLED Model emulated. we simply capture the developer machine’s screen
1280
BR - Measured s1
1080 BR - OLED Model and extract the region corresponding to the emulator’s dis-
Power (mW)

880 s2 play area.

680 For completeness, we also measured the power consump-
480 tion of LCD displays with varying screen sizes at two dif-
280 ferent color levels, and the measurements are presented in
0 25 50 75 100 125 150 175 200 225 250 Table 4. The LCD can be modeled using simply the bright-
Linear R,G,B
ness level as the variation with color is not significant. As
expected, devices with different screen sizes do consume dif-
Figure 9: Change in power with color.
ferent amounts of energy and hence multiple models may be
incorporated in Wattson for different devices.
Such a power model becomes difficult to parameterize
since even though the area dependent power scaling could Brightness Color 3.6in 4.3in
be modeled using curve fitting, the curve parameters would Low Black 132 mW 294 mW
vary for each color. Thus, we use a lookup table spanning the White 127 mW 330 mW
entire R,G,B gamut of values, discretized to 16 color mag- Medium Black 363 mW 557 mW
nitudes per component, yielding a lookup table with 16 × White 359 mW 573 mW
16 × 16 = 4096 entries. The entries of this table contain High Black 559 mW 778 mW
the power value measured if the entire screen was set to White 554 mW 790 mW
that color, and in effect models the power scale down com-
pared to the additive model at 100% area coverage for that Table 4: Power measurements for LCD displays for HTC
color. The lookup table cannot be used directly however Arrive (3.6in screen size) and HTC HD7 (4.3in screen
because the power value does not follow the lookup table size).
when a color occupies less than the entire screen, and then its
power consumption is closer to that predicted by the additive
OLED model. Rather than fitting 4096 individual curves to 3.5 CPU
model the area dependant power variation for the basis col- Mobile devices use much lower power processors due to
ors, we make a implifying approximation that is based on their battery constraints compared to the processor used on
the observation that the deviation from the OLED model is the developer’s machine. The processor frequency, cache

7
hierarchy, and various computational units are different, re-
sulting in very different execution performance across the
two processors for the same computation. As for the net-
work, a simple mapping of phone CPU resource utilization
level to the developer machine processor will not suffice as
the entire timing of the app activities depends on the CPU
timing. Hence we need a resource scaling technique that
preserves the timing behavior of the emulated app execu-
tion. We also need a power model to compute the energy
consumption from the measured scaled resource use.
3.5.1 Resource Scaling
One approach to resource scaling would be to use a cycle-
accurate simulation of the mobile device processor on the
developer machine and then execute the mobile application
on the cycle accurate processor simulator. The cycle-accurate
simulators can reproduce the activities of the mobile proces-
sor very accurately. However, the resource consumption of
cycle-accurate simulator is very high and it does not in fact
run in real time on a development machine. A unit time
worth of computation on the real phone processor may ac-
tually consume more than one time units on the simulator.
Since the simulator tracks the time ticks, the trace produced
is usable for simulating the CPU alone but when the timing
affects the activities on other components such as the net-
work, the energy calculation will get skewed.
Hence, we take a light-weight approach where we attempt
to scale down the performance of the emulated process run-
ning on the development machine by allowing it access to
fewer processor cycles. This is an approximation in that the
nature of computation can affect how many cycles of one
processor correspond to the other processor, given that the
processor architectures are vastly different and aside from
the number of cycles, the size of processor caches, acceler-
ators and bus speeds will matter as well. We compare the
execution time on a mobile device processor (Samsung Fo-
cus with a 1GHz Scorpion CPU) and a development ma-
chine using a 2.7GHz Intel Core-2 Quad-core processor for
a few simply computational tasks including floating point
computations, fixed point computations, and memory inten-
sive compute tasks. The slow-down in execution time did
not vary greatly across these tasks and for this pair of pro-
cessors, the slow down was a factor of 7.2, implying that
a 100% CPU utilization on the phone processor can be ap-
proximated using a 100/7.2 = 13.8% utilization of one core
on the developer machine processor.
The scaling factor can be easily measured for different
developer machines as follows. Suppose the computational
task used for measuring the above scaling factor consumed
t0 seconds on the developer machine used above. This same
computation can be run by Wattson on a new developer ma-
chine, and the execution time measured purely in software.
Suppose the time measured is t1 . The scaling factor can be
modified as 13.8 ∗ t1 /t0 .
One way to scale down the development machine CPU is
8
to use dynamic voltage and frequency scaling (DVFS). How-
ever, DVFS only provides a few scaling levels and none of
these may correspond to the desired setting. Also, in typical
implementations of DVFS all cores of a processor share the
same supply rail and scaling down one core scales down the
entire processor. This is undesirable as this will cause the en-
tire developer machine, including the emulator and Wattson
activities to be scaled down.
Hence, we use an alternative approach where the cycles
allocated to the mobile device emulator running the test app
are limited. One way to do this would be to modify the mo-
bile device emulator such as the Android Emulator or the
Windows Phone Emulator to run the app in a limited num-
ber of cycles and leave other cycles idle. This of course re-
quires separate porting to each mobile emulator and unlike
the network scaling technique is not generically applicable
to all emulators. Instead we use an external technique where
the emulator is not modified.
The approach is illustrated in Figure 10. In this approach,
the mobile device emulator, denoted E in the figure (in our
prototype, the Windows Phone Emulator, encapsulated in
process XDE.exe) is affinitized by Wattson to one core, shown
as core 0 in the figure. The priority level of the emulator
process is set to one level lower than normal. Affinity and
priority modifications are performed using the relevant OS
APIs. In addition, Wattson starts an additional thread, de-
noted by P in the figure, also affinitized to core 0. All other
active threads, including the threads running as part of Watt-
son are affinitized to other processor cores 1 through n. The
end result is that P gets a priority to run and cycles left un-
used by P are available for E. This way, by controlling the
number of cycles used up by P , we can control the resource
scaling for E. Other methods to control the resource scaling
for the processor are also possible, such as using OS sched-
uler modifications or Virtual Machine containers, and may
be employed depending on developer platform constraints.
Control Thread
DEVELOPER
Wattson
APPLICATION IN
EMULATOR
OS APIs
KERNEL E - lower P - higher
(Affinity, Priority)
priority priority
CPU 0 Remaining
COMPUTER E and P threads
HARDWARE affinitized to … affinitized to
CPU 0 other cores
CPU n
Figure 10: CPU resource scaling. E denotes the mo-
bile device emulator and P denotes the resource control
thread started by Wattson.
3.5.2 Power Modeling
Power models for the CPU are available in the literature [18]
and we used a simple utilization based power model where
the CPU power is expressed as a linear function of the phone’s
CPU utilization:
Pcpu = α ∗ ucpu
where ucpu represents the phone CPU utilization and α is a
power model parameter. The CPU utilization measured by
Wattson for the emulator process on the developer machine
is scaled according to the scaling factor in Section 3.5.1 to
obtain ucpu .
We measured the value of α on the Samsung Focus device
for different computations (Table 5) and use an average value
of 722.6mW for simplicity.
Computation Power (mW)
Floating Point 665
Fixed Point 722
Memory Intensive 781
Table 5: CPU power consumption at 100% utilization,
excluding device idle power
A practical complication that arises in implementing the
CPU power model is that sometimes, depending on OS schedul-
ing behavior, the cycles consumed by the controlled thread
P and the emulator E may not exactly follow the scaling fac-
tor, and the converted ucpu could be higher than 100%. In
such cases we stretch out the excess CPU utilization over the
subsequent time slot, iteratively to as many slots as needed,
to keep the CPU utilization within any single time slot to be
at most 100%.
3.6 Other Components
Some of the other components are also significant from
an energy standpoint. The most notable one is the Graph-
ics Processor (GPU). The GPU is mostly hardware managed
and no software observable metrics regarding its utilization
level are easily available. Power models for the GPU are
thus not widely studied in the literature. Resource scaling
for the GPU will also be non-trivial.
We largely omit the GPU from our model. One approx-
imation that we do include is that the GPU is heavily used
during video playback. Thus, we measured the power con-
sumption on a mobile device for several video playback tests
and found that while some portion of the power measure-
ment can be explained using the CPU and display, a signifi-
cant portion remains attributable to the GPU. On an average
the GPU power was estimated to be 231mW across three
different videos. Thus, if the emulated app is detected to
be playing video, we can add this power value for the dura-
tion that the video is played. Other uses of the GPU such as
graphics intensive games, are not covered by this approxi-
mation.
The GPS sensor used for location is another component
that consumes non-trivial energy. While the GPS does not
require any resource scaling and the power model is also not
too difficult, we exclude the GPS because there is no easy
9
way to detect if and when the app used the GPS from outside
the existing emulators.
4. IMPLEMENTATION
We implemented Wattson for the Windows Phone Devel-
opment framework as an extension to Visual Studio. The
emulator process (XDE.exe) starts once an app developer
chooses to debug his app on the emulator. During any run
of the app, the developer can choose to activate Wattson. It
works alongside the app running on the emulator with dif-
ferent threads for network resource scaling, packet capture
and filtering, CPU resource scaling, CPU usage monitoring,
and display screen capture.
The developer can select different operating conditions for
the run, such as network conditions (good, medium, bad),
display brightness (low, medium, high), phone brand and
model, network carrier (AT&T, Verizon, T-Mobile, or Sprint),
and received signal strength. Since display brightness and
signal strength do not affect the timing of the app execution,
these parameters can even be changed after the test run and
the energy estimates are updated on the fly using a previ-
ously obtained resource consumption trace.
The output of Wattson includes: (i) a time series of power
consumed for every component, and (ii) the total energy con-
sumed. Using the battery capacity specification, we can also
estimate how long the battery would last if a user continu-
ously ran the app on her phone. A screenshot of Wattson
output is shown in Figure 11. The UI elements on the left al-
low the developer to change operating conditions while the 4
graphs show the energy used on the network, display, CPU,
and the overall device respectively.
Figure 11: Wattson output showing energy data.
We capture the network packet trace from the developer
machine’s network interface card using a Windows library
for network sniffing, available as part of Network Monitor
3.4 [13]. The packets transmitted/received by the emulator
process (XDE.exe) are filtered out based on the source and
destination IP addresses and ports obtained from IPHelper
API (GetTCPTable and GETUDPTable) by matching the cor-
responding process ID.
For CPU loading and binding, WinAPI functions present
in kernel32.dll are used to set the affinities for the em-
ulator and the controlled loading thread, P , to a single core
and all the other threads in Wattson to the remaining cores. domly selected pixels instead of considering all pixels is also
CPU usage is captured using the Performance Monitor API. shown. Again the model has very little error.
WinAPI user interface functions are used for capturing the
screen as required to obtain pixel information for the display 1500
power model. Measured
Estimated, All Pixels
5. PERFORMANCE EVALUATION Estimated, Subsampled 1%

The accuracy of the energy estimate produced by Watt- 1000

Power (mW)
son depends both on the correctness of resource scaling as
well as the accuracy of the power models used. To evalu-
ate the overall performance, we compare the estimated en-
500
ergy use as well as the measured energy use for multiple
tasks performed on the mobile device. Since apps cannot be
downloaded to the emulator from the app marketplace, we
developed our own apps to perform these tests. 0
Application 1: Display only. We begin our evaluations 5 10 15 20 25 30
Image Number
with the display power model. While the LCD and OLED
power models are available in prior work, the AMOLED
model and is new and we evaluate its accuracy using an Figure 13: Measured and emulated energy for Applica-
application that consumed energy only in the display. The tion 1, with 30 different images.
display is also the single most dominant energy consuming
Another parameter worth exploring is the loss in accuracy
component that must be used by any foreground application.
suffered by sub-sampling only a small fraction of the pixels
We first test the accuracy of our discretized lookup table
rather than using all pixels. Using fewer pixels can reduce
that only stored 4096 colors out of the possible 255 × 255 ×
the computational overhead as well as the data overhead of
255 = 16581375, which is approximately only 0.024% of
tracing app resource use, enabling higher frame rate tracing.
all possible color values. This test is performed with 100
We compare the accuracy achieved when all pixels are in-
random colors that are not in the lookup table, set to oc-
cluded and the incremental increase in error at sub-sampling
cupy 100% of the display area. This tests the accuracy of the
1% and 0.1% of the pixels. From the results shown in Fig-
modified AMOLED model for color dependent power scal-
ure 14, reducing to 1% from 100% does not change the accu-
ing. Figure 12 shows both the estimated an the measured
racy much (the gray bars indicating the loss in accuracy are
power and suffers from very little error.
very small) while reducing down to 0.1% does start intro-
ducing significant changes in accuracy. The implementation
1400
Measured
of Wattson may be tuned to different subsampling levels de-
1200
Modeled pending on accuracy and resource use trade-offs desired.
Errors

1000
25
All Pixels
Power (mW)

800

Subsampled 1%
600 20 Subsampled 0.1%
400

15
Error (%)

200

0
0 10 20 30 40 50 60 70 80 90 100
10
Image Number

5
Figure 12: Testing the AMOLED display power model
with 100 random colors.
0
0 5 10 15 20 25 30
For a more realistic test, we use an application that sim- Image Number
ply displays a static image and performs no CPU or network
activity. Thirty different images encompassing various typi- Figure 14: Display model error when all pixels are con-
cal app displays including simple GUIs to rich textures and sidered, or only 1% or 0.1% of the pixels are considered.
photographic imagery were included in this set. Figure 13
shows the measured and estimated energy (using equation Application 2: Local Computation. This test is designed
(1)) for all 30 images. The energy estimated using 1% ran- to model applications that include only local computation

10
without network use or heavy graphics. The mobile app has
a simple GUI display, largely black with some white buttons.
25 Measured
Clicking the buttons causes computations to take place for
Estimated
5s, 10s, or 20s. An example power trace captured using the 20

Energy (J)
power meter is showed in Figure 15(a). For the same run, the
measured power trace averaged over 1s intervals as well as 15
the emulated power from Wattson is shown in Figure 15(b).
Power was measured with the mobile device in the airplane 10
mode to avoid cellular network background activity. How- 5
ever, the device does have some background activity as seen
in the raw trace near time 12s, and such activity, being inde- 0
5s 10s 20s
pendent of the app, should be excluded from consideration
for the app developer. This is difficult in the measured power
but is easy when using Wattson. Figure 16: Experimental evaluation of emulation accu-
racy for Application 2.
2000
Power (mW)

ure 17. The power trace shows significant power spikes

1000 above the radio’s high power state due to the CPU activ-
ity corresponding to processing of packet arrivals during the
download.
0
0 5 10 15 20 25 30
Time 2000

(a) Raw Trace Power (mW)

1000
Power (mW)

1000 Measured
Emulated
0
500 0 5 10 15 20 25 30
Time

0
0 5 10 15 20 25 30 Figure 17: Example data capture for Application 3.
Time
(b) Averaged over 1s Performing the above test for different downloaded file
sizes ranging from small to large, and repeating each test 5
times, the measured and estimated energy use is shown in
Figure 15: Comparing measured and emulated energy Figure 18. The emulation energy is close enough for the de-
for Application 2. veloper to make the correct design choices based on the es-
timates provided by Wattson. Average error is 4.73% across
Performing such an evaluation for the three different com- all tests.
pute units, the total energy consumed over a 30s period, as Application 4: Internet Browsing. This application down-
measured and emulated is shown in Figure 16. Each mea- loads a webpage and renders it on the display. We test em-
surement is averaged over 5 random runs and the standard ulation accuracy over five different web pages differing in
deviations are shown as error bars. Since the resource scal- content size and complexity. The web pages are chosen to be
ing can behave differently from one run to another, the emu- static pages without variable advertisement content to make
lated energy can also vary slightly across runs. Overall, the the experiment repeatable across a real device and Wattson.
emulated energy is lower since certain background activities The webpages used are listed in Table 6.
are absent from the emulated trace. The mean error across all
these runs is 9.3%. The primary factors leading to the error Web page Size Images
include any errors in the power model, the fact that back- AMOLED Wiki Page 357kB 9
ground activities cause the measured energy to be artificially ACM 353kB 16
higher, and the error in resource scaling that may cause the MSDN Mobile Apps 828kB 9
emulated CPU usage to be different from measured. Google 117kB 4
Application 3: Networked Apps. Next we consider ap- NPS/Yose 532 14
plications that use the network in addition to the CPU and
display. A simple application is developed that can down- Table 6: Webpages used for testing Application 4.
load files of different sizes from a predetermined web server.
As before, a sample power measurement is shown in Fig- Energy is measured over a common session length of 50s

11
 may keep a local cache of images used for different weather
conditions and only download succinct weather data from
Measured
25 its web server. Second, the app may use different images for
Estimated
depicting a weather condition such as a cloudy day: a sim-
20 ple cloud icon (such as Figure 20-(a)) that has a very small
Energy (J)

image size (18kB), a rich photographic cloud image which

15 has significant detail but requires a larger file size of 138kB
to be stored or downloaded (Figure 20-(b)) or even an ani-
10 mated image that shows a simple set of moving cloud icons
(such as two frames with varying cloud locations, with one
5 frame shown in Figure 20-(c)), with a file size of 90kB.
0
1kB 100kB 1MB
Download Size

Figure 18: Estimated and measured energy for Applica-

tion 3 with varying download sizes.

for each URL. A variable portion of the session is spent on (a) (b) (c)

fetching the webpage for each case. Nevertheless, there are

variations across multiple runs due to network variability
and web server variability. The measured and estimated en-
ergy is shown in Figure 19. The average error over all these
experiments is 4.64% which is very similar to the variabil-
ity in measurement one may observe even with real device
measurements due to changing network conditions and de-
vice background activity.
100
Measured Estimated
80
Energy (J)
Figure 20: Three sample images considered for a
weather app design.
The smallest image, Image 1, size is likely to save energy
on the network. Image-2 appears to be the darkest and may
save energy on the display. Image-3 seems attractive in that
it shows animation but it is not clear what the overhead for
animation is in terms of energy. The decision depends on
understanding energy consumption in multiple dimensions.
Simply optimizing the app for lower CPU utilization will not
necessarily reduce energy. Also, the display power model
depends on color implying that even two images that appear

60 similarly bright may consume different energy. The decision

would be much easier if the energy data for all these options
40 was easy to obtain and that is exactly what Wattson enables.
Trying the three different images in the app and recording
20
the Wattson output, we obtain the data summarized in Fig-
ure 21.
0
Wiki ACM MSDN Goog NPS
80
Display CPU Network
Figure 19: Estimated and measured energy for Applica- 60
tion 4.
Energy (J)

40

5.1 Case Study: Weather Application Design

20
Let us consider a fairly common application that is in-
stalled on a large fraction of mobile devices: a weather appli- 0
cation. The developer has at least a couple of design choices Image 1 Image 2 Image 3
and we show how Wattson assists in making the correct de-
cisions. Figure 21: Energy estimate summary from Wattson for
First, the app may always download the content to be dis- weather app design choices.
played, such as weather icons or images, from the web1 , or it
1
such application designs are sometimes referred to as hybrid apps Several facts become obvious from this data. First, even
and using the HTML standard, such apps can operate seamlessly on multiple platforms.

12
though Image 1 is much simpler and has a smaller file size,
it does not help save any energy on the network. This hap-
pens because for such small downloads the network energy
is dominated by the tail states of the radio. A related implica-
tion is that saving the images locally and only downloading
the text data related to weather will not help save much en-
ergy. In fact, downloading content from the web may make
app design more portable across mobile platforms.
Second, the display is consuming the largest fraction of
the energy for this scenario. Clearly an image that saves
energy on the display is likely to be beneficial, and other
factors are less important.
Third, looking in detail at the component breakdowns, one
also notices that the CPU power consumption of the third
image is the highest. Looking at the emulation output from
Wattson (not shown for brevity) also shows that, while for
the first two images the CPU energy is nearly zero, after the
download completes, the CPU is consuming an average of
150mW continually while Image 3 is displayed. This im-
plies that while one could choose darker colors to reduce the
display portion of the energy, the CPU portion will not re-
duce if animation is used. Since Wattson shows the exact
overhead of animation, the developer can determine if it is
important for their app scenario or not. Armed with such
data, the developer can also decide if the app should high-
light important information, such as a hazardous weather
alert, using brighter colors or animation.
6. RELATED WORK
Wattson builds upon a large body of work on modeling
the energy consumption of phones [2,5,22]. The work in [2]
focused specifically on a Palm device and measured several
components including the CPU, LCD, device buttons, touch
pen, and the serial link which was the primary communica-
tion channel on that device. It also discussed methods for
synchronizing power and resource usage traces. On simi-
lar lines [22] is a more recent work that presents tools for
automated execution of test benchmarks and measurement
of power, to enable generation of power models for vari-
ous components on the mobile device. The modeling ap-
proach was refined further in [5] by providing a tool named
Sesame, that makes the model generation process even eas-
ier by eliminating the need for external power measurement
equipment, by using the battery drain measurements avail-
able on the mobile device itself. Our work builds upon such
prior modeling work by using the available power models as
inputs for our techniques. We also expand the set of avail-
able models to cover additional technology variations.
Some of the most energy intensive components, includ-
ing the display and network have been modeled extensively.
OLED display power models [3] have been used for develop-
ing innovative methods for display energy optimization [4].
LCD based screens were modeled in [22]. Many newer de-
vices including the iPhone, use AMOLED based displays for
which power models were not available. We have expanded
13
the catalogue of models to include AMOLED.
Power models for the cellular data network have been de-
veloped in [15, 16], where multiple power states of the net-
work hardware were inferred using external measurement.
The times spent in various states depend on the configuration
settings used by the specific mobile network. Prior work has
already provided the models inferred for the AT&T network,
and we expanded the measurements to develop similar mod-
els for three other mobile operators. Network energy mea-
surements for the cellular and WiFi networks were also pre-
sented in [17], where the differences in energy and perfor-
mance were used to determine the best network for commu-
nicating large data segments. Another aspect of cellular data
network energy is its variation with signal strength, which
was studied in [19]. Since testing applications in varying
channel conditions is difficult through actual measurements,
using the modeling information from [19] is useful in en-
abling emulation of the application energy behavior in mul-
tiple channel conditions.
Prior work has also looked at determining the energy con-
sumed by each app. [21] tracks the resource usage of each
component, and applies power models from the data sheet
specs. PowerScope [6] tracks the application with the active
context on the processor (a single core CPU without hyper-
threading was used) and measures the power at fine time res-
olution. The power consumed by the device during the time
the application had active processor context is used as an
approximation of the application’s power consumption. A
limitation of both these approaches is that asynchronous ac-
tivities performed when the application does not have active
processor context, and tail-state energy use by certain com-
ponents are not correctly attributed.
Another powerful modeling approach, eProf [14], traces
system calls made by applications and uses power state mod-
els for various components to infer energy used. It can incor-
porate tail-energy use, such as when a component remains
in a higher energy state after the application is done using it.
We incorporate such state based models for the cellular net-
work. Detailed system call tracing also enables fine grained
attribution of energy to specific OS activities performed by
the application and the use of such techniques can help fur-
ther refine the energy attribution view provided by Wattson.
While the above systems are intended to track multiple ap-
plications, the attribution problem is simplified in Wattson
since a developer typically wishes to optimize the single ap-
plication that they are developing. In Wattson, we emulate a
single application and hence avoid attribution complexity.
7. CONCLUSIONS AND FUTURE WORK
In this paper we presented Wattson, a system to estimate
the energy consumption of apps during the development and
emulation stage. The goal is to enable app developers to use
this feedback to design more energy efficient code. Wattson
works in two stages. First, it scales down the emulation en-
vironment on the developer’s machine (network, CPU, dis-
play) to mimic the phone. Second, it applies empirically-
derived models to estimate the energy consumed by the app.
This approach gives us the flexibility to test an app’s energy
consumption under various scenarios and operating condi-
tions. We have prototyped Wattson for the Windows Phone
platform and shown its effectiveness for a variety of apps.
Moving forward, we realize that Wattson is just the first
step in improving the energy efficiency of apps. Other use-
ful steps would be to obtain actual energy measurements
from the wild, and provide users with real feedback about
the energy consumed by different apps on her phone. Al-
though Android phones have the “battery use” tool for the
latter, it is not accurate because of lack of supporting hard-
ware. We are actively working on ways to modify existing
phone hardware to obtain detailed energy consumption num-
bers from the phone. Furthermore, we are also investigating
techniques to augment the models of Wattson with real mea-
surement data. This will help reduce any inaccuracies of
the energy models shown in [12]. Together, we believe that
these efforts will help developers produce apps that will sig-
nificantly increase the battery lifetime of mobile phones.
8. REFERENCES
[1] A. Balasubramanian, R. Mahajan, and A. Venkataramani.
Augmenting mobile 3g using wifi. In Proceedings of the 8th
international conference on Mobile systems, applications,
and services, MobiSys ’10, pages 209–222, 2010.
[2] T. L. Cignetti, K. Komarov, and C. S. Ellis. Energy
estimation tools for the palm. In Proceedings of the 3rd ACM
international workshop on Modeling, analysis and
simulation of wireless and mobile systems, MSWIM ’00,
pages 96–103, 2000.
[3] M. Dong, Y.-S. K. Choi, and L. Zhong. Power modeling of
graphical user interfaces on oled displays. In Proceedings of
the 46th Annual Design Automation Conference, DAC ’09,
pages 652–657, 2009.
[4] M. Dong and L. Zhong. Chameleon: a color-adaptive web
browser for mobile oled displays. In Proceedings of the 9th
international conference on Mobile systems, applications,
and services, MobiSys ’11, pages 85–98, 2011.
[5] M. Dong and L. Zhong. Self-constructive high-rate system
energy modeling for battery-powered mobile systems. In
Proceedings of the 9th international conference on Mobile
systems, applications, and services, MobiSys ’11, pages
335–348, 2011.
[6] J. Flinn and M. Satyanarayanan. Powerscope: A tool for
profiling the energy usage of mobile applications. In
Proceedings of the Second IEEE Workshop on Mobile
Computer Systems and Applications, WMCSA ’99, pages
2–, 1999.
[7] J. Huang, Q. Xu, B. Tiwana, Z. M. Mao, M. Zhang, and
P. Bahl. Anatomizing application performance differences on
smartphones. In Proceedings of the 8th international
conference on Mobile systems, applications, and services,
MobiSys ’10, pages 165–178, 2010.
[8] S. Jha. Poorly written apps can sap 30 to 40% of a phone’s
juice., June 2011. CEO, Motorola Mobility, Bank of America
Merrill Lynch 2011 Technology Conference.
[9] H. V. Madhyastha, T. Anderson, A. Krishnamurthy,
N. Spring, and A. Venkataramani. A structural approach to
latency prediction. In Proceedings of the 6th ACM
SIGCOMM conference on Internet measurement, IMC ’06.
14
[10] J. Manweiler, S. Agarwal, M. Zhang, R. Roy Choudhury, and
P. Bahl. Switchboard: a matchmaking system for multiplayer
mobile games. In Proceedings of the 9th international
conference on Mobile systems, applications, and services,
MobiSys ’11, pages 71–84, 2011.
[11] J. Manweiler and R. Roy Choudhury. Avoiding the rush
hours: Wifi energy management via traffic isolation. In
Proceedings of the 9th international conference on Mobile
systems, applications, and services, MobiSys ’11, pages
253–266, 2011.
[12] J. C. McCullough, Y. Agarwal, J. Chandrashekar,
S. Kuppuswamy, A. C. Snoeren, and R. K. Gupta. Evaluating
the effectiveness of model-based power characterization. In
Proceedings of the 2011 USENIX annual technical
conference, USENIXATC’11, pages 12–12, 2011.
[13] Microsoft. Network monitor 3.4.
http://www.microsoft.com/download/en/
details.aspx?displaylang=en&id=4865.
[14] A. Pathak, Y. C. Hu, M. Zhang, P. Bahl, and Y.-M. Wang.
Fine-grained power modeling for smartphones using system
call tracing. In Proceedings of the sixth conference on
Computer systems, EuroSys ’11, pages 153–168, 2011.
[15] F. Qian, Z. Wang, A. Gerber, Z. Mao, S. Sen, and
O. Spatscheck. Profiling resource usage for mobile
applications: a cross-layer approach. In Proceedings of
International Conference on Mobile Systems, Applications,
and Services, MobiSys ’11, pages 321–334, 2011.
[16] F. Qian, Z. Wang, A. Gerber, Z. M. Mao, S. Sen, and
O. Spatscheck. Characterizing radio resource allocation for
3g networks. In Proceedings of the 10th annual conference
on Internet measurement, IMC ’10, pages 137–150, 2010.
[17] M.-R. Ra, J. Paek, A. B. Sharma, R. Govindan, M. H.
Krieger, and M. J. Neely. Energy-delay tradeoffs in
smartphone applications. In Proceedings of the 8th
international conference on Mobile systems, applications,
and services, MobiSys ’10, pages 255–270, 2010.
[18] S. Rivoire, P. Ranganathan, and C. Kozyrakis. A comparison
of high-level full-system power models. In Proceedings of
the 2008 conference on Power aware computing and
systems, HotPower’08, pages 3–3, 2008.
[19] A. Schulman, V. Navda, R. Ramjee, N. Spring, P. Deshpande,
C. Grunewald, K. Jain, and V. N. Padmanabhan. Bartendr: a
practical approach to energy-aware cellular data scheduling.
In Proceedings of the sixteenth annual international
conference on Mobile computing and networking, MobiCom
’10, pages 85–96, 2010.
[20] W. L. Tan, F. Lam, and W. C. Lau. An empirical study on the
capacity and performance of 3g networks. IEEE
Transactions on Mobile Computing, 7:737–750, June 2008.
[21] H. Zeng, C. S. Ellis, A. R. Lebeck, and A. Vahdat.
Ecosystem: managing energy as a first class operating system
resource. In Proceedings of the 10th international conference
on Architectural support for programming languages and
operating systems, ASPLOS-X, pages 123–132, 2002.
[22] L. Zhang, B. Tiwana, Z. Qian, Z. Wang, R. P. Dick, Z. M.
Mao, and L. Yang. Accurate online power estimation and
automatic battery behavior based power model generation
for smartphones. In Proceedings of the eighth
IEEE/ACM/IFIP international conference on
Hardware/software codesign and system synthesis,
CODES/ISSS ’10, pages 105–114, 2010.
[23] X. Zhao, Y. Dong, H. tao Zhao, Z. Hui, J. Li, and C. Sheng.
A real-time congestion control mechanism for multimedia
transmission over 3g wireless networks. In Communication
Technology (ICCT), 2010 12th IEEE International
Conference on, pages 1236 –1239, nov. 2010.