managing wifi energy in smartphones by throttling...

MANAGING WIFI ENERGY IN SMARTPHONES BY

THROTTLING NETWORK PACKETS

by

Arun Bharadwaj

B.Tech., National Institute of Technology, 2008

a Thesis submitted in partial fulfillment

of the requirements for the degree of

Master of Science

in the

School of Computing Science

Faculty of Applied Sciences

c� Arun Bharadwaj 2014

SIMON FRASER UNIVERSITY

Spring 2014

All rights reserved.

However, in accordance with the Copyright Act of Canada, this work may be

reproduced without authorization under the conditions for “Fair Dealing.”

Therefore, limited reproduction of this work for the purposes of private study,

research, criticism, review and news reporting is likely to be in accordance

with the law, particularly if cited appropriately.

APPROVAL

Name: Arun Bharadwaj

Degree: Master of Science

Title of Thesis: Managing WiFi Energy In Smartphones by Throttling Net-

work Packets

Examining Committee: Dr. Nick Sumner, Chair

Assistant Professor, Computing Science,

Simon Fraser University

Dr. Arrvindh Shriraman, Senior Supervisor

Assistant Professor, Computing Science,


Dr. Alexandra Fedorova, Supervisor

Associate Professor, Computing Science,


Dr. Jiangchuan Liu, Internal/External Examiner

Associate Professor, Computing Science,


Date of Defence:

ii

Arun

April 25, 2014

iii

Partial Copyright Licence

Abstract

Smartphone applications that access the network can quickly drain a phone’s energy. The

WiFi radio consumes up to 25%-30% of the system’s total power, which could be twice as

much as the CPU. The wireless radio supports two modes of operation, a high performance

active mode and a low power mode. Determining when to transition between the two modes

is particularly challenging since applications demonstrate diverse network behavior. We

show that even when actively using the network, applications provide short idle windows

that can be exploited (tens of milliseconds). Current smartphones seek to exploit these

windows by transitioning after a fixed timeout during an inactive period. Selecting the

right timeout is challenging: If it is too long, the device may waste energy but if it is too

short, it may significantly delay the incoming data (bu↵ered at the access point).

In this paper we attempt to answer the following questions: how di�cult is it to configure

the timeout that determines when the WiFi radio goes into the power-saving mode? Is there

a time-out that works well for most applications? How significant are the e↵ects on energy

consumption and packet latency if the timeout is not configured optimally? How do we

dynamically tune the PSM timeout based on the applications’ network activity? How do

we modify the application tra�c to maximize the WiFi radio sleep time without a↵ecting

the user experience?

iv

Dedicated to Amma, Anna and Appi

v

Acknowledgments

I would like to thank Dr. Arrvindh Shriraman for his guidance and persevering with me

and believing in me. I would also like to thank Dr. Sasha Fedorova for her valuable inputs

to this work. Finally, I would like to thank my friends and colleagues for their help and

support.

vi

Contents

Approval ii

Partial Copyright License iii

Abstract iv

Dedication v

Acknowledgments vi

Contents vii

List of Tables ix

List of Figures x

1 Introduction 1

2 Background and Infrastructure 5

2.1 Smartphone Power Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Static PSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2 Dynamic or Adaptive PSM . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4.1 Android Kernel Instrumentation . . . . . . . . . . . . . . . . . . . . . 15

2.4.2 PowerLogger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

vii

2.4.3 WiFi Power Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Governor Design 19

3.1 PSM Governor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 What is the optimal PSM timeout? . . . . . . . . . . . . . . . . . . . . 19

3.1.2 PSM Governor Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.3 Selecting sampling period . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.4 Setting PSM timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 Packet Governor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.1 Tra�c Shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3 Reducing Dynamic Power for Packet Processing . . . . . . . . . . . . . . . . . 37

4 Conclusions 40

4.0.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.0.2 Looking Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Bibliography 42

viii

List of Tables

2.1 Number of idle periods in Applications (5s Run). . . . . . . . . . . . . . . . . 10

3.1 Energy and Performance characteristics at optimal PSM timeout. Opt. PSM:

Optimal PSM timeout for application. % PSM time: The percentage of time

spent in PSM. % Energy savings: the percentage of energy saved at the

optimal PSM timeout % Packets on time: the percentage of packets arriving

by the deadline observed when the radio is fully active. . . . . . . . . . . . . . 23

3.2 Percentage of packets delayed at the optimal PSM timeout. Group the per-

centage of packets delayed based on the amount of delay encountered. . . . . 24

3.3 Evaluating QoS of applications. A delay equal to (Wakeup Interval - Optimal

PSM timeout) is applied to each packet of the application. This gives us the

worst-case QoS for each of the applications listed in this table. . . . . . . . . 29

3.4 For applications Browser and Dropbox running concurrently, show the total

energy consumed and the percentage of delayed packets over all the windows

given each sampling period. The product of energy and percentage of delayed

packets is displayed in the last column. This helps us to choose the ideal

sampling window period. Lower is better. . . . . . . . . . . . . . . . . . . . . 31

3.5 Burst rate of applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.6 Measure of performance of application on applying tra�c shaping techniques 37

3.7 Show the amount of additional time needed to load each of the web pages

when the CPU is throttled during network packet processing. . . . . . . . . . 39

ix

List of Figures

2.1 Interaction between WiFi Radio Power state and Application Tra�c. . . . . . 7

2.2 Network Activity of Applications . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Fine-grain power measurement of SmartPhones. Monitoring PC is running

our PowerLogger Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Energy versus Performance. Each marker represents PSM timeout in ms.

Note the di↵erent scales for each group. X-axis: Percentage of delayed pack-

ets. Y-axis: Total Energy. Lower (#) and towards origin ( ) is better. . . . . 21

3.2 Optimal sampling period for Browser and Dropbox running concurrently. X

axis shows time and Y axis shows tra�c in bytes. The red dotted lines divide

the tra�c over time into buckets of 1s each. The black arrow shows the

sampling period considered and the value on top shows the optimum PSM

timeout for the particular window. . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Burst Duration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4 Burst Size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.5 Packets Per Burst. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.6 Burst Inter-Arrival Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

x

Chapter 1

Introduction

Mobile devices are becoming the de facto computing platform, as users increasingly substi-

tute desktop systems with smartphones and other hand-held devices. Microelectronics has

experienced significant development over last few decades. This makes powerful smartphone

development a reality. Now, smartphones are equipped with high processing capabilities, im-

proved graphical user interface, and multiple radio interfaces. These hardware enhancements

in smartphones lead to resource intensive software development. As a result, smartphones

have powerful operating systems like Android, iOS, Windows and Blackberry OS with large

number of attractive features. The fast expanding app markets for di↵erent smartphones

along with these development improvements, make smartphone one of the most popular and

desired devices in the market. Canalys report [7] for smartphone shipment analysis showed

that smartphones overtook client PCs in the number of units shipped by the vendors: ven-

dors shipped 488 million smartphones compared to 415 million client PCs in 2011. If we

look at the market growth rate over 2010, smartphone market grew by 63% while client PC

market experienced a growth of only 15%. These statistics show that users trend towards

smartphones and smartphones dominate the current market. According to Canalys VP and

Principal Analyst, Chris Jones, smartphones have grown from being a niche product to be-

come a truly mass-market proposition. Due to the relatively small size of the smartphones,

the size of the batteries that can fit into these devices is small. Hence, these batteries have

limited capacity leading to limited battery life. The most powerful battery for smartphones

in the market belongs to Motorola Droid Maxx, which has a battery capacity of 3500 mAh

[13]. Among other powerful smartphones, iPhone 5s comes up with a battery of 1570 mAh

and Samsung Google Nexus S is equipped with a battery of 1500 mAh. Because of this

1

CHAPTER 1. INTRODUCTION 2

limited battery life, energy consumption in smartphones is a very crucial aspect. This real-

ization of energy aspect of smartphones, makes smartphone energy saving an evolving and

important research area.

A major fraction of the energy consumption in smartphones comes from the wireless

network interface controller (WNIC) [9]. For example, the base energy consumption of

the HTC Tilt 8900 series phone ranges between 155-475mW, depending on the intensity

of the backlight while WiFi radio consumes over 1000mW during transmission [28]. As

an another example, the base energy consumption of Nokia N900 is about 12 mW. In

comparison, the WiFi radio consumes 765 mW during receiving and 1000mW during sending

[9]. Cellular networks (e.g. 3G or GSM) consume more energy than WiFi. For a download

of size 10K, WiFi consumes one-sixth of 3G’s energy and one-third of GSM’s energy, and

with the increase in data sizes WiFi’s e�ciency increases dramatically compared to that of

3G or GSM [5]. Although cellular networks are comparatively more energy hungry, WiFi

has been increasingly used by smartphones to o✏oad tra�c from the cellular network [4].

Hence, reduction of WiFi energy consumption is becoming essential for maximizing the

battery lifetime of smartphones, and understandably this work is aimed to reduce WiFi

energy consumption. In this work we are concerned with saving energy on smartphones.

Although battery technology is improving, the pressure to deliver more computing power

grows even faster. Mobile devices have become more and more network dependent, with

many applications requiring continuous network connectivity. Overall, the WiFi radio uses

up to 25% of the system total energy, which can be twice as much as the CPU itself.

On the positive side, if we examine how the WiFi radio operates and uses energy, we

discover that there is room for improvement. Broadly speaking, the WiFi radio can be in

one of the two states: CAM (Constant Active Mode) and PSM (Power Saving Mode). When

in CAM, our experimental device, a Google Nexus One, consumes around 404–700mW of

power, while in PSM the consumption drops to as little as 34mW, on our experimental

hardware. With such a discrepancy, there is a large incentive to stay in PSM during the

periods when applications do not use the network.

We demonstrate in this work, that an aggressively low PSM timeout will cause delays

in delivery of the incoming packets while a long PSM timeout does not exploit the short

windows of idleness predominant in applications. So, not surprisingly, we have a trade-o↵

between energy savings and application performance. The goal of our work is to measure

the extent of this trade-o↵ and understand the challenges in navigating it. We are interested


in learning how much extra latency we incur if the PSM timeout is set too aggressively, and

how much energy we save as a result.

Our measurements reveal that packets can be delayed by many milliseconds if the PSM

timeout is chosen to be in the order of tens of milliseconds. Typically, the PSM timeout

in Android is set to 200 ms. We can save up to 41% of the WiFi energy when running

standalone applications and 59% while having a maximum performance hit of 1-5% when

running concurrent applications when operating with optimal PSM timeout parameters. We

find that there is no single PSM timeout that works well across many applications and varies

between 10ms – 40ms. Clearly the default value of 200ms is too high. From observations

of dynamically changing tra�c patterns in applications, we conclude that the best way to

minimize WiFi energy waste is to dynamically regulate the PSM timeout to match the

tra�c.

Contributions of this work In Section 2.2, we explain the need to have a dynamically

changing PSM timeout value instead of the existing constant by using real world Android

applications. In section 2.4, we describe the technique used to instrument the kernel to

extract various parameters needed to track the network tra�c and the power model that is

used by this system to calculate the total energy consumed.

We present two techniques in this thesis: PSM Governor and Packet Governor. PSM

Governor enables us to dynamically set a PSM timeout based on the applications’ network

behaviour. It determines the PSM timeout value based on the energy-performance tradeo↵.

Packet Governor looks at shaping the tra�c in order to maximize the amount of time for

which the Wifi radio of the phone stays in the PSM state. The key di↵erence between

these two techniques is that, while PSM Governor leverages the idle periods present in

unmodified tra�c to implement micro-shutdown of the Wifi radio, Packet Governor tries to

create periods of idleness by overlapping busy periods of di↵erent applications. We study

the impact of doing this on the performance of the application and the amount of energy

gains obtained. We discuss PSM Governor in Section 3.1 and Packet Governor in Section

3.2.

In Section 3.1.1, using real smartphone applications we find that selecting the optimal

and universal timeout value is challenging. With timeout configured sub-optimally, packet

latency can increase and the radio may expend more energy. Furthermore, when applica-

tions are simultaneously using the network, we need to carefully orchestrate the PSM value


based on the overlap of the tra�c patterns. We present a PSM governor that dynamically

configures the PSM timeout based on the network activity of the applications. The PSM

governor (Section 3.1.2) starts with a default value and observes the change in network

tra�c to rapidly find the pareto-optimal PSM value that ensures optimal energy savings

while delaying a few packets. We quantitatively study the optimality of the timeout value

chosen by the PSM. We also qualitatively study the e↵ect of PSM Governor on the QoS of

the applications.

In Section 3.3 we hypothesize that a few applications can live with intermittent delays

in the packet delivery. To demonstrate our hypothesis, we study the load-times of popular

benchmarks on the browser while throttling the CPU during network processing; this helps

reduce the power consumed by the software overheads of packet processing. We find that

we can save between 10—48% of the energy used for packet processing while introducing a

maximum of 200ms increase in web-page load times which has minimal impact on overall

QoS.

Chapter 2

Background and Infrastructure

2.1 Smartphone Power Modes

There are two power modes that the WiFi interface of a smartphone can be in:

1. Constant Awake Mode (CAM) and

2. Power Saving Mode (PSM)

CAM is the performance mode where the radio interface is kept on all the time, resulting

in high energy consumption. Before the existence of PSM, it was the normal operating

mode for a smartphone. But because of the high energy consumption of the CAM state and

limited battery life of the smartphones, there was a need to develop a Power Save Mode

(PSM). IEEE 802.11 Access Point (AP) supports PSM [28]. While in the PSM state, the

radio interface periodically wakes up instead of constantly keeping it on to reduce energy

consumption. Hence, the energy consumption in PSM is quite low compared to that of CAM

at the cost of increased latency. For example, HTC Tilt 8900 series smartphone consumes

1120mW of power in CAM, while in PSM consumes as little as 72mW of power [28].

There are two types of algoithms used which puts a smartphone into PSM state:

1. Static PSM and

2. Dynamic or Adaptive PSM

Before going to the details of each of these PSM states, a few terms need to be introduced

which explains the di↵erent parameters influencing the WiFi radio state. When a phone

5

CHAPTER 2. BACKGROUND AND INFRASTRUCTURE 6

is in the PSM state, the AP bu↵ers the incoming packets for the smartphones currently

in PSM and informs the smartphones about the presence of bu↵ered packets via a bitmap

field called Tra�c Indication Map (TIM) in beacon messages [9]. Beacon messages are

periodically generated messages and the interval between two successive beacon messages

is called the beacon period or beacon interval. At the beginning of every beacon period,

the smartphone checks the beacon message from the AP. If it learns about any bu↵ered

packets waiting in the AP though the TIM, it notifies the AP and retrieves the packets.

Another important property is listen interval which is defined as the frequency at which the

wireless interface wakes up to receive beacon message [9]. For example, if listen interval is

set to 1, the smartphone wakes up every second to receive beacon message while in PSM.

It determines the PSM sleep granularity for incoming packets, since all incoming packets in

between are bu↵ered by the AP until the smartphone’s next wakeup time.

Figure 2.1 shows an incoming and outgoing tra�c window of 1.5s. Most applications op-

erate in a request—response mode, in which periods of activity are triggered by an outbound

tra�c phase followed by an inbound response from the server through the access point. The

time period elapsed between the completion of the outbound transmission and the start

of the incoming response is defined as the idle period. Applications have inherent idle

periods although the idle period length and the number of such idle windows varies between

applications. We characterize the idle period of applications in detail in the next section.

Seeking to exploit this idle period, today’s wireless radios provide at least one power saving

mode (PSM) that puts the radio to sleep (no outbound tra�c) and periodically wakes up

to check for incoming packets. The access point provides flow control, bu↵ering packets for

the PSM client.

The transition from CAM to PSM is regulated using a PSM timeout period, which

is the time period of zero tra�c following a transmission. After the PSM timeout period

the WiFi is transitioned from CAM to PSM. Interestingly if the idle period < PSM timeout

then the system will continue to operate in the CAM mode and will not save any energy.

When idle period > PSM timeout consider � = idle period - PSM timeout. If � is large

then a large fraction of the energy can be saved. However, if the � is small due to mismatch

between a large PSM timeout value and short idle period only minimal energy savings can

be achieved. Finally, when in PSM mode the WiFi radio is woken up at a periodic interval

which is a multiple of the beacon interval to check if the access point has any incoming

data in its bu↵er, unless it was woken up earlier by the outbound tra�c. In this paper we


Traffic!

Time!

Idle Period

PSM Timeout

OutboundTraffic

Inbound Traffic

BeaconInterval

Time

Traf

fic

Figure 2.1: Interaction between WiFi Radio Power state and Application Tra�c.

continue to use the default wakeup interval of 300ms. Overall, 1) The PSM timeout needs

to be short to ensure the radio detects idle periods early to save energy; optionally the CAM

to PSM transition (to sleep) could be controlled explicitly by software and 2) The operating

system needs to pro-actively control the PSM to CAM (wakeup) transition to ensure that

incoming packets su↵er minimal bu↵ering delays at the access point.

2.1.1 Static PSM

Static PSM was first standardized in [1]. In static PSM, the AP bu↵ers the incoming packets

for the smartphone in PSM and notifies it by setting the corresponding TIM bit in the next

beacon. The smartphone wakes up at the beginning of every beacon period and checks the

TIM. If the TIM indicates bu↵ered packets waiting at the AP, the smartphone switches to

CAM and sends PS-Poll frame to poll every bu↵ered packet until the AP notifies no more

bu↵ered packets by setting the More Data flag to 0. The smartphone then enters PSM right

away. For outgoing tra�c, the smartphone can wake up at any time to send packets and

immediately switch back to PSM afterwards. By entering PSM aggressively, static PSM

keeps the smartphone in CAM only when transmitting or receiving tra�c. Thus, static

PSM achieves high energy e�ciency.

Static PSM causes considerable delay on data transfer for two reasons [9]: (1) the delay

incurred in receiving bu↵ered packets via polling every packet can be high for interactive

applications and (2) the immediate transition from CAM to PSM after sending or receiving


data tra�c will cause packets arrived shortly later, to be bu↵ered at the AP until the next

beacon. For example, a TCP flow with 5 ms Round Trip Time (RTT), after a smartphone

sends SYN, the SYN/ACK packet arrives 5 ms later when the smartphone has already

entered PSM, thus can only be received at next beacon. Since the beacon interval is typically

set to 100 ms, with static PSM a short RTT flow behaves like a flow with 100 ms RTT. This

is called the RTT round up e↵ect [9]. Such an e↵ect can significantly elongate short flows.

2.1.2 Dynamic or Adaptive PSM

In Dynamic PSM, the smartphone does not enter PSM right after transmitting/receiving

data tra�c. Rather, it stays in CAM for a pre-defined duration. This amount of time is

called PSM timeout. This prevents the smartphone from going to PSM in the middle of a

data transfer when the PSM timeout is longer than RTT. While in PSM, the smartphone

wakes up periodically to receive beacons from the AP and checks the TIM similar to static

PSM. If its corresponding bit in TIM indicates bu↵ered packets in the AP, it switches to

CAM and receives the packets without polling. In order to avoid polling, the smartphone

notifies the AP of any transition to CAM or PSM by sending a Null data frame with the

Power Management bit set to 0 or 1, respectively.

Dynamic PSM improves the network performance in two ways compared to static PSM:

(1) it does not require PS-Poll frames for retrieving data from the AP; (2) lingering in CAM

for a PSM timeout period after every reception, avoids the RTT round up e↵ect. However,

the PSM timeout delay in entering PSM under dynamic PSM can cause extra smartphone

awake time, and hence can reduce energy saving.


2.2 Motivation

Although applications rarely have long contiguous durations of inactivity, they have many

short windows (tens of milliseconds) of idle periods that can be exploited. The problem

is that smartphones do not take full advantage of this opportunity. Modern smartphones

essentially use a timeout mechanism: following a period of network activity (incoming or

outgoing packets) if the WiFi radio observes the window of inactivity for a fixed period,

called the PSM timeout, the device enters the PSM state. While the device is in the PSM

state, incoming packets are bu↵ered at the access point and delayed while outgoing packets

reserve the option of transitioning the WiFi radio back to CAM. In this section, we motivate

the need to have a dynamic PSM timeout, specific to an application’s network behaviour.

We describe our methodology in detail in Section 2.4. Smartphone applications have varied

network activity. Applications such as the Browser, Maps, YouTube and Facebook show

a bursty behaviour; few applications like Skype show a continuous stream of tra�c. The

bursty applications cannot all be treated in the same manner, they have varied burst lengths,

tra�c rates and idle periods between the bursty periods. Figure 2.2 shows a snapshot of the

network activity pattern for all our applications and Table 2.1 quantifies the average idle

periods in the activity. Note that the idle period does not mean the application is inactive;

these are windows of idleness created when the application is waiting for inbound network

tra�c or in the midst of sending out tra�c. For instance, while YouTube’s incoming tra�c

demonstrates predictable behavior with 500ms windows of inactivity between 50ms tra�c

windows, the browser has multiple bursty periods. With such varied application tra�c

patterns it is imperative that we set the PSM timeout in a smart manner to save energy

while ensuring optimal performance.

To estimate the potential for switching to PSM state we characterize the idle periods in

applications. We measure average idle period, the average time window between consecutive

periods of network activity. The calculated values in Table 2.1 are for a 5 second snapshot

taken during the experiment.

As we see from the table, it is clear that an application like Maps with a high standard

deviation of 69.9ms from an average idle period of 21.4ms provides a great opportunity to

save power. Some of the applications like Browser have a relatively low average idle period

(9.9ms) and standard deviation (35.4ms), but can still be exploited to save power because

it has a large number of idle periods (25 idle periods > 50ms over a sample 5s activity).


In Skype, there are 223 periods of < 10ms and 232 periods of > 10ms and <= 50ms in a

snapshot of a 5s activity. Exploiting the PSM state in this case requires a short timeout

window (1ms) and fast CAM$PSM transition. The overheads of the software handler

managing such transitions also need to be low. To achieve higher e�ciency with application

with small idle period windows we may need to shape the network tra�c to overlap activity

periods and create wider windows of idleness that can be exploited.

Application Browser Skype Twitter Facebook Maps YouTubeAvg. idle period (ms)

9.9 10.3 12.8 11.4 21.4 6.2Standard Deviation (ms)

35.4 6.9 44.6 44.9 69.9 43.1# of idle periods

<1ms 297 29 246 262 132 6281–10ms 108 223 92 80 46 11810–50ms 75 232 28 44 37 8>50ms 25 0 24 20 18 15

Table 2.1: Number of idle periods in Applications (5s Run).


Why WiFi and not 3G? Energy-awareness of the cellular modem in the smartphone is

also an equally important problem to solve. The Radio Resource Control (RRC) protocol

influences the way the cellular modem consumes power depending on the data transfer rate,

signal strength and the network parameters configured by the RRC protocol. The cellular

modem has at least four power states [30], each with di↵erent levels of performance and

power consumption associated with it and statically set inactivity timers control the state

transitions. Since the WiFi radio has just two available power state transitions, it is critical

that we dynamically vary the timeout which controls the state transition based on the

applications’ network behaviour, while it is not so critical to do that for the cellular modem

because of the presence of intermediate states which consume less energy but still manage

to transmit and receive data.


0 0.25 0.5 0.75 1 1.25 1.500.30.60.91.21.5

Traf

fic (k

B)

Outgoing traffic

0 0.25 0.5 0.75 1 1.25 1.500.30.60.91.21.5

Time (s)

Traf

fic (k

B)

Incoming traffic

Browser

0 0.25 0.5 0.75 1 1.25 1.500.30.60.91.21.5

Traf

fic (k

B)

Outgoing traffic

0 0.25 0.5 0.75 1 1.25 1.500.30.60.91.21.5

Time (s)

Traf

fic (k

B)

Incoming traffic

Youtube

0 0.25 0.5 0.75 1 1.25 1.500.30.60.91.21.5

Traf

fic (k

B)

Outgoing traffic

0 0.25 0.5 0.75 1 1.25 1.500.30.60.91.21.5

Time (s)

Traf

fic (k

B)

Incoming traffic

Skype

0 0.25 0.5 0.75 1 1.25 1.500.30.60.91.21.5

Traf

fic (k

B)

Outgoing traffic

0 0.25 0.5 0.75 1 1.25 1.500.30.60.91.21.5

Time (s)

Traf

fic (k

B)

Incoming traffic

Twitter

0 0.25 0.5 0.75 1 1.25 1.500.30.60.91.21.5

Traf

fic (k

B)

Outgoing traffic

0 0.25 0.5 0.75 1 1.25 1.500.30.60.91.21.5

Time (s)

Traf

fic (k

B)

Incoming traffic

Maps

0 0.25 0.5 0.75 1 1.25 1.500.30.60.91.21.5

Traf

fic (k

B)

Outgoing traffic

0 0.25 0.5 0.75 1 1.25 1.500.30.60.91.21.5

Time (s)

Traf

fic (k

B)

Incoming traffic

Facebook

Figure 2.2: Network Activity of Applications


2.3 Related Work

There has been ongoing e↵ort in the energy management for network interface of mobile

devices [6, 8, 10, 17, 15, 24, 2, 18, 23]. Smartphones with their myriad of applications and

varied tra�c patterns based on the user introduce the need for dynamic adaptivity. Authors

of the paper EProf [21] have implemented a system-wide energy profiling technique that

tracks the amount of energy being consumed by each application and they find that a

surprisingly large portion of the energy is consumed by third party advertising modules in

free applications, the major share of it being network energy.

One of the earliest works in this area called STPM [3], proposes a self-tuning OS module

that adapts itself to the network access patterns and applications’ intent. STPM allows

the applications to disclose hints about their intent in using the wireless network. This

allows STPM to enable power management only when appropriate. This also helps STPM

to decide if the network interface can be disabled for periods longer than the beacon period

[9]. Also, if applications can specify the maximum delay that it can tolerate on incoming

packets, STPM can make power management decisions based on these constraints to ensure

that the applications don’t su↵er. STPM also allows applications to disclose the start and

end periods of each transfer. The important contribution of STPM was that it was able

to characterize the costs of switching between the power modes, CAM to PSM and vice

versa. The main issue was that it needed modifications to the applications’ source code

and application developers need to be aware of the API provided by STPM, to enable it to

work well with STPM. Furthermore, the tra�c pattern itself would vary based on the usage

(e.g., Browser) and dynamic conditions further compounding the challenge. SAPSM [25]

tags applications with a priority and allows the network interface to switch to CAM only

when a high priority application has a network activity and staying at PSM in the presence

of a low priority application. E-Mili [34] observed that a majority of energy is just spent

idle listening and hence adaptively downclocks the network radio to reduce the amount of

energy consumed during idle listening.

The above approaches to power management is done via changes to the operating system

and applications on the mobile device. There are also a few approaches which try to solve the

problem of saving network energy on the mobile device by adding energy-awareness at the

Access Point (AP). NAPman [28] combines energy e�ciency with fairness by implementing

a scheduler at the AP. NAPman tries to leverage the virtualization capability at the AP,


which enables one physical AP to pose as multiple APs, each having a separate beacon of

its own. NAPman enables one physical AP to pose as multiple virtual APs, each having a

beacon of its own. This enables the AP to avoid contention between clients in CAM and

clients in PSM. Percy [9] tries to enable predictable idle window periods by serving pages

from a proxy cached at the access point. Well behaved idle windows enable the system to

set a fixed optimal PSM timeout. Non-static web pages and interactive applications pose

a challenge to this method of having a fixed PSM timeout. Percy tries to combine the

benefits of both Static and Dynamic PSM power modes by deploying a web proxy at the

AP and having unchanged PSM client and unchanged AP. In essence, Percy intercepts each

TCP connection oriented from the mobile device, completes the TCP handshake with the

external server and acts as a relay between the external server and the mobile client. This

is done in a way that minimizes the extra flow delay incurred due to relaying and maximize

the energy savings from exploiting the Dynamic PSM of the mobile devices.

In the presence of multiple APs, each mobile client will have to wait longer to receive

it’s own packets since it faces contention from multiple mobile clients trying to communi-

cate with multiple APs. So, Sleepwell [19] devises a strategy where each AP monitors the

periodicity of network activity of other APs and adjusts it’s own tra�c pattern so that it

has minimal overlap with that of the other APs. This enables the mobile clients to avoid

waking up unnecessarily and wasting energy.

Some of the approaches try to understand the behaviour of the network application to

carefully manage power consumption. For example, SiFi [26] tries to exploit the periods of

silence in a VoIP conversation to e↵ectively control the PSM state of the network interface.

It uses a silence prediction algorithm which learns to predict the start and end periods of

silence in the conversation using di↵erent modeling and prediction techniques like empirical

cumulative distribution function and time series analysis.


2.4 Methodology

2.4.1 Android Kernel Instrumentation

We have developed a low overhead kernel-level Ftrace-based logger to gather network-usage

information like TX-Bytes, RX-Bytes, TX-Packets and RX-Packets, which are respectively

the number of bytes and packets transmitted and received at every context switch. Ftrace

is a function tracer utility present in the Linux kernel that can trace various operating

system events by inserting static trace points at specific places in the kernel. We obtain this

information from the lowest level in the network stack at the device driver. This enables

us to observe the tra�c exchange (burst intervals, idle interval) at the point of WiFi power

control. Our experimental device Google Nexus One uses the bcm4329 WiFi driver.

Although we do not capture the timestamp when a packet is sent from or received by

the network interface, we feel that capturing this information at process context-switch is

su�cient because context-switches happen at a microsecond granularity, while the PSM

timeout is set to the order of a few milliseconds and hence it will not a↵ect our decision

switch to PSM.

Ftrace Overhead We compare our Ftrace-based logging to the baseline state where no

logging is done. The ftrace-based logger tracks network packet statistics at every process

context-switch, which is at a frequency of nearly 100Mhz. This logging frequency is su�-

cient to track the network tra�c at fine-grain time intervals given the inter-packet arrival

rates. Even at such a high rate of logging, this approach does not add much overhead to the

system. We used the benchmarks AnTuTu, Quadrant Pro and BBench to determine this

overhead. BBench [14] employs a more realistic workload scenario and is a web-page render-

ing benchmark which comprises of loading many popular websites. The ftrace-based logger

shows less than 1% performance loss compared to when no logging is done, while running

BBench. This ensures that we can log the network tra�c traces without perturbing the

behavior of the application. AnTuTu and Quadrant Pro include multiple microbenchmark

tests for each of the main hardware components of the smartphone, CPU, Memory and

I/O (external flash and internal storage). For AnTuTu, the ftrace logger shows almost zero

overhead for CPU and Memory tests and only 1.5% degradation for the I/O test. Quadrant

Pro demonstrates similar trends, except for CPU tests which show 4% degradation.


Phone

PC Interface

Powerguage

Power Logger

Figure 2.3: Fine-grain power measurement of SmartPhones. Monitoring PC is running ourPowerLogger Application.

2.4.2 PowerLogger

We use the following contraption to measure the overall current drawn from the smartphone

battery.

The LTC2941 is a coulomb counter which measures the voltage and coulombs (cur-

rent[Amps] ⇥ time [seconds]) consumed by phone and reports it to a PC via an USB com-

munication module (FTDI UM232H). With this set up the phone and battery each have

reliable connections to the sampling hardware with no modifications needed on the phone

itself. Furthermore, because the original battery is still being used to supply power, the

behaviour of the phone is una↵ected.

We developed a logging application, PowerLogger which runs on the PC connected to

the measurement hardware. This application polls the LTC2941 measurement chip at a

rate between 10-50hz, reading the instantaneous voltage (vn) and the number of coulombs

consumed by the phone thus far during the test (qn). It also records the time of the sample

(tn).

The PC based logging application converts the coulomb-counter and voltage readings

from the measurement hardware into instantaneous power and instantaneous current results.

It calculates the instantaneous current as:

in =qn � qn�1

tn � tn�1(2.1)

The instantaneous power (pn) is calculated by: pn = in ⇥ vn


The total hardware cost of our overall set up is $150 and is almost completely inde-

pendent of the phone model. Instrumenting a di↵erent phone model would simply require

creating plastic housing for the battery (' 20$).

This technique also needs online power modeling described in the next section to estimate

the per-component power values.

2.4.3 WiFi Power Estimation

We conducted our experiments on a Google Nexus One phone. Measuring the amount

of power consumed by only the WiFi chip is currently challenging as there are no external

power lines and manufacturers do not provide power counters. Even the development boards

provided by Qualcomm [16] do not provide such fine-grain per-component power measure-

ments at ms granularity. Since we would like to estimate and study the potential for power

savings without being restricted by the limitations of power-measuring equipment, we had

to use a power model. We measure the overall power drawn by the battery by instrumenting

the Battery Monitoring Unit (BMU) [32, 11]. Like others [33, 22, 20, 32] we derive a power

model to estimate the instantaneous power consumed by the WiFi radio. The instantaneous

power consumed by the WiFi radio depends on whether it is in the PSM or CAM state.

The power consumed in the CAM varies with the number of packets transmitted or received

per second. When the phone is in the PSM state, there is a constant power consumption

of 34.37mW (estimated from manufacturer sheets). In the CAM state, the power consump-

tion is a sum of two components: a constant value of 404.46mW and a variable value which

depends on the Uplink Rate, Ru and the WiFi link ratio.

Overall, the amount of power consumed by the WiFi radio is given by the following:

PowerPSM = 34.37.

PowerCAM = 404.46 + (6.4271⇥Ru)

We simulate the device driver and the access point at various PSM timeout values using

tra�c traces generated from running the applications. We transition the WiFi radio from

CAM to PSM following a timeout period of inactivity, so any incoming packets are scheduled

to be delayed up to the subsequent beacon period at the access point. The PSM to CAM

transition occurs when there is some outgoing tra�c and the access point schedules incoming

tra�c to arrive at the client. We do not delay the outgoing packets because the OS on the


client can immediately wake up the WiFi radio from PSM in this case. But in the case

where the incoming packets are delayed at the access point, we delay the outgoing packets

since it is dependent on the previously delayed incoming packets. Modeling both the device

WiFi radio state and the access point bu↵ering enables us to estimate the power saved

due to the time spent in the PSM and the delay on the inbound tra�c to the client. The

reason for simulating the device driver and access point at various PSM timeout values is

that we were not successful in changing the PSM timeout value on the Android device that

we used for our experimental purposes. In fact, nobody has been successful in doing this

on an Android device. The authors of the paper Percy [9] have been able to modify PSM

timeout, but it was done on a Nokia N900 device. We chose to use Android instead because

the kernel code is open source and that was critical to our work and our main focus was

to study the potential for exploiting idle periods untainted by the limitations of the current

implementation.

Chapter 3

Governor Design

3.1 PSM Governor

In this section, we describe the design of the PSM Governor and present our results. To

summarize the contributions of this section:

Result 1: We can save up to 41% of the WiFi energy in individual applications by choosing

an optimal PSM timeout.

Result 2: There is no fixed PSM timeout value that demonstrates optimal delay-energy

trade-o↵ across all applications. We need to tune PSM timeout based on tra�c behavior

demonstrated by the application.

Result 3: By choosing an optimal PSM timeout we can save energy while delaying between

1% — 5% of the packets.

3.1.1 What is the optimal PSM timeout?

We considered six popular smartphone applications from the Android Play Store, which

represent a diverse nature of network activities: Facebook and Twitter (social network-

ing), Google Maps (direction and navigation), Skype (voice communication), Browser (web

browsing) and YouTube (video streaming). We performed several common user activities

on these applications and observed the network activity during the active execution.

We also considered three scenarios where pairs of applications were run concurrently:

Browser and Dropbox, Browser and Tune-In Radio (Internet Radio app), Google Maps and

Tune-In Radio. In each of these pairs, there was one application running in the background

19

CHAPTER 3. GOVERNOR DESIGN 20

performing network activity like downloading a large file or streaming music from the in-

ternet, while the user was interacting with the other application in the foreground, which

also produced network tra�c. In these scenarios we ran the Browser and Maps always in

foreground while the Dropbox and Tune In Radio were run in the background; a typical

usage scenario.

Figure 3.1 plots the energy-performance trade-o↵ for di↵erent PSM timeout values. The

wakeup interval (when the radio checks for inbound packets), which is usually a multiple of

the beacon interval is set to 300ms by default on the device that we tested. Our experiments

show that di↵erent applications have a di↵erent optimal PSM timeout values based on the

energy-performance trade-o↵. On the X-axis, we show the percentage of packets delayed

due to packets needing to wait for a beacon period compared to the delivery of packets when

the WiFi radio was always in CAM state (zero delay). The Y-axis plots the total energy

consumed by the radio based on the packets transmitted and received.

Optimal PSM Timeout As Figure 3.1 demonstrates, the PSM timeout is a critical

parameter that directly impacts the idle periods exploited by the CAM$PSM transition

algorithm. When we scale down the PSM timeout from 200ms all the way to 10ms, we

observe that the percentage of delayed packets increases monotonically as more inbound

packets find the radio asleep and need to wait until the following beacon period. However,

the fraction of packets delayed depends on the number of idle periods that the PSM timeout

value can exploit.

As explained in Section 2.2, if the PSM timeout value is greater than the length of

the idle periods in the application, then the WiFi spends a large fraction of the time in

the CAM mode. With most applications, idle periods are typically short (< 50ms — see

Table 2.1), so we need to use a much shorter PSM timeout than a typical value of 200ms.

However, the exact value highly depends on the application. A PSM timeout of 30ms would

suit an application like Browser (with many idle periods in 10–50ms range), while a value

of 50ms would be better suited for the Twitter application, as it has more idle periods >

50ms. Overly short PSM timeouts tend to increase packet delay quite significantly; in most

applications (other than Skype) a short timeout increases the average delay by 2⇥.Interestingly, applications like Skype tend to have many short windows of idleness, and as

compared to many other applications they do not operate in a request-response mode. Most

packets in Skype are independent, as the client and the server both transmit asynchronously.


0 0.75 1.5 2.25 3 3.75 4.5 5.25 614

15.75

17.5

19.25

21

22.75

24.5200160120100

807060

5040

3020 15 10

Percentage of delayed packets

Tota

l Ene

rgy

(J)

Browser

0 1 2 3 4 5 6 7 8 9 107

8.5

10

11.5

13

14.5

16200160

120100

8065

5040

30 2010


Tota

l Ene

rgy

(J)

Facebook

0 5 10 15 20 25 30 350

2

4

6

8

10

12>30

2015

10

5

1


Tota

l Ene

rgy

(J)

Skype

0 0.75 1.5 2.25 3 3.75 4.5 5.25 6 6.752

3

4

5

6

7200160

120100

80655040 30

2010

Percentage of delayed packetsTo

tal E

nerg

y (J

)Maps

0 1 2 3 4 5 6 7 8 9 103.5

4.5

5.5

6.5

7.5

8.5

9.5 200160

120100

8060

50 4030

2010


Tota

l Ene

rgy

(J)

Twitter

0 0.25 0.5 0.75 1 1.25 1.5 1.75 2 2.253

3.5

4

4.5

5

5.5

6

200160120

1008060

40 30 20 15 12 10


Tota

l Ene

rgy

(J)

YouTube

0 1 2 3 4 5 6 7 8 9 100

2

4

6

8

10 1201007060

4030

2015

10


Tota

l Ene

rgy

(J)

Browser-TuneInRadio

0 1 2 3 4 5 6 7 8 9 100

2

4

6

8

102001201007060

4030

2015 10


Tota

l Ene

rgy

(J)

Maps-TuneInRadio

Figure 3.1: Energy versus Performance. Each marker represents PSM timeout in ms. Notethe di↵erent scales for each group. X-axis: Percentage of delayed packets. Y-axis: TotalEnergy. Lower (#) and towards origin ( ) is better.


This leads to small windows of idleness as the incoming and outbound tra�c that have no

coordination. Overall, as Table 2.1 indicated, Skype has almost 450 idle periods in the 1–

50ms range, but no idle periods greater than 50ms. Exploiting idle periods in Skype requires

a very low PSM timeouts. However, low timeout values also tends to delay incoming packets.

For instance, when we compare PSM timeout of 50ms with 10ms, we save 41% of the energy

but increase the latency of the packets by 20%, which may a↵ect the QoS. While the current

system-default PSM timeout of 200ms is ine�cient in terms of energy consumption, fixing

an optimal PSM timeout is challenging, and we need to adapt it based on the network

activity of the application (e.g., interactive short idle windows v/s non-interactive bursty

tra�c).

We select optimal timeout for each application based on the pareto-optimal point (the

knee) in the energy v/s performance curve. As we decrease PSM timeout and measure energy

and performance, the pareto-optimal point is defined as the point after which, decreasing

the PSM timeout further results in large percentage of packets being delayed.

Impact of PSM Timeout on Packet Latency By applying the optimal PSM timeout

values selected using this method, we can see an improvement in energy consumption by

30% – 41% among the evaluated applications. But what price do we pay for these energy

savings? To better understand the performance impact when we apply the optimal PSM

timeout we focus on the latency increase in packets. Essentially, with PSM timeout packets

could find the radio switched-o↵ and could be delayed. We measure the distribution of

packets delivered late compared to when the radio is always active (CAM mode).


Application Opt. PSM(ms)

%PSM time % EnergySaving

% Packets OnTime

Standalone Applications.Browser 30 76.49 30.03 98.15Facebook 50 82.6 41.25 96.8Twitter 50 75.45 38.35 96.5Maps 40 77.4 40.72 97.3Skype 20 48.5 41.50 95.2YouTube 20 93.22 31.72 99.11

Concurrent Applications.Browser + Dropbox 30 70.97 55.5 96.99

Browser + Tune In Radio 20 72.14 59.2 96.27

Maps + Tune In Radio 40 51.69 50.1 98.32

Table 3.1: Energy and Performance characteristics at optimal PSM timeout. Opt. PSM:Optimal PSM timeout for application. % PSM time: The percentage of time spent in PSM.% Energy savings: the percentage of energy saved at the optimal PSM timeout % Packetson time: the percentage of packets arriving by the deadline observed when the radio is fullyactive.

Table 3.1 shows the optimal timeout value for each application and lists the percentage

of packets delivered on time. It is apparent that in spite of having a low PSM timeout that

proactively shuts down the radio at every opportune moment, more than 95% of packets are

delivered on time. Note that when outbound packets need to be sent, the radio will wakeup

from PSM mode; in many cases this period coincides with packets to be received.

The table also shows the amount of energy saving obtained at the optimal PSM timeout,

compared to the current setting of 200ms. Table 3.2 shows the distribution of delayed packets

when we use the optimal PSM timeout.

It is apparent that although the application might see 1% – 4% of its packets delivered

late, less than 1.5% of the packets incur a significant delay of 250–300ms. At the same time

the energy savings we observe are quite substantial: more than 30%. These findings inspire

us to design a dynamic power management algorithm that adapts the PSM timeout to the

characteristics of the application.

Impact of PSM Timeout on the QoS QoS is an important aspect of the performance

of the applications which directly impacts the experience of a user of the smartphone. QoS


Application (PSM Time-out)

0–50ms 50–100ms

100–150ms

150–200ms

200–250ms

250–300ms

Standalone Applications.Browser (30ms) 0.01 0.03 0.05 0.20 0.69 0.85Facebook (50ms) 0.02 0.11 1.13 0.48 1.01 1.50Twitter (50ms) 0.05 0.15 0.68 0.73 1.10 0.73Maps (40ms) 0.11 0.05 0.55 0.60 0.77 0.60Skype (20ms) 1.01 0 0 0 0 0YouTube (20ms) 0 0.02 0.11 0.11 0.24 0.38

Concurrent Applications.Browser + Dropbox(30ms)

0 0.01 0 0.01 0.92 2.05

Browser + Tune In Radio(20ms)

0 0 0 0 0.12 3.60

Maps + Tune In Radio(40ms)

0 0 0 0 0.84 0.82

Table 3.2: Percentage of packets delayed at the optimal PSM timeout. Group the percentageof packets delayed based on the amount of delay encountered.

is a very di�cult parameter to measure in case of smartphone applications because there

is no one way to quantify the user experience of using an application. An exception was

the case of using a Browser where we were able to quantify the QoS by calculating the load

times of a web page since QoS is directly related to how fast a page loads on the Browser.

In case of an application like Facebook, we cannot really quantify the QoS and so we rely

on the feedback from a blind experiment conducted on the user.

We conducted a blind experiment on five di↵erent users who used the phone in a regular

manner for a week to browse web pages, search for locations and directions on Google Maps,

scroll through the feeds on Facebook and Twitter, make voice calls using Skype and also

watch videos on YouTube. This is not an exhaustive workload characterization study of

the impact of modifying PSM timeout on the QoS of the applications as that is not the

main focus of this thesis. This is just to show that the users did not perceive any change in

the behaviour of some of the most commonly used applications in spite of the applications’

network packets being delayed due to an aggressive setting of PSM timeout.

In order to study the QoS of applications, we use the following intuition. From Table 3.1,

we observe the value of optimal PSM timeout for an application (example: Browser, 30ms).

We know that WiFi interface wakes up every 300ms (default wakeup interval) to query the


AP for any incoming packets. So, the maximum delay an incoming packet might face in case

of setting an aggressively low PSM timeout for the Browser is 270ms. From Table 3.2, we

observe that only 0.85% of the total number of Browser packets are delayed by this amount.

But, just to consider the worst case scenario, we delay all incoming packets by this amount

in order to observe the QoS. We do the same for some of the other applications and tabulate

the results in Table 3.3. In the case of Browser, we used the BBench benchmark to measure

the page load times of various web pages. We observed that the Geometric Mean of the

web page load times increased by 150ms for an experiment running close to five minutes.

In case of Maps, we searched for a particular location and observed an average increase in

search time by 0.2s which was imperceptible to the user. For YouTube, we played a ten

minute video and tested for lag. We found that the video took 0.4s more on an average to

load, but there was no lag when the playback started. We also used Skype to make a voice

call, Facebook and Twitter to scroll through the feeds and click on pictures and the user

did not observe any di↵erence in experience.

3.1.2 PSM Governor Design

Result 1: The PSM Governor starts from an initial high value of PSM timeout and quickly

converges to the optimal value and constantly re-adjusts itself to stay close to the optimal

value.

Result 2: The sampling period, which defines how frequently we sample the network tra�c

is chosen such that we can calculate the optimal PSM timeout.

The PSM governor essentially implements a micro-shutdown of the WiFi radio, exploit-

ing millisecond windows of inactivity present in the tra�c generated by an active application.

It is implemented directly at the radio device driver layer where the OS is aware of the net-

work pattern of the application and can transition the WiFi to PSM or CAM state without

any delay. The algorithm in charge of managing the WiFi power state needs to carefully

tune the PSM timeout rates in order to minimize packet delays and maximize energy sav-

ings. To maximize energy savings the PSM governor needs to shutdown the radio as early

as possible, right after the trailing edge of a tra�c spike. However, the radio will not be

woken up until the next beacon period or if there is outbound tra�c and this could possibly

delay inbound tra�c.

The design of PSM governor algorithm involves the following two steps:


• Choosing the right sampling period : This step defines how often we sample the network

tra�c. The sampling period needs to capture the shape of the current tra�c conditions

to enable us to determine an optimal PSM value while ignoring tra�c conditions in

a wider window that may lead to setting a sub-optimal value. By the shape of the

tra�c we mean that, we do not want to choose a sampling period which is either

too sensitive to changes in the tra�c or too insensitive. We need to strike a balance

between the two cases. So, we try various sampling periods by calculating energy and

percentage of packets delayed for each case and choose the sampling period which has

the least value for the product of energy and percentage of packets delayed.

• Setting the PSM timeout : This step defines how we dynamically explore the space of

PSM timeout values to determine the knee in the energy-performance trade-o↵.

We illustrate our approach with the following 3 usage scenarios in which we have two

applications running concurrently:Browser and Dropbox, Browser and Tune-In Radio, Maps

and Skype. While Dropbox is syncing a 1GB file in the background, we have the user

interactively using the Browser in the foreground. As demonstrated previously, there is

now a need to vary the PSM timeout dynamically as the network activity pattern varies

based on Dropbox’s bursty sync behavior and the Browser’s website loading. The interactive

applications Browser and Skype run in the foreground while Maps and Tune-In Radio run

in the background. In the following section, we describe the PSM governor that is used to

dynamically adapt to this situation and change PSM timeout at a fine granularity.

3.1.3 Selecting sampling period

Here we consider how often we sample the network activity to determine the pareto-optimum

value of PSM timeout, which strikes a good balance between performance and energy, for

the period of sampled network activity. The sampling window size is a critical parameter.

If the sampling window is too large, the optimal PSM timeout we determine would be less

sensitive to changes in tra�c pattern causing performance degradation during short bursts

of activity and energy wastage during periods of inactivity. If the sampling window is too

small, the PSM timeout we determine would be too sensitive to changes in tra�c pattern

and constantly vary between high and low values. Both scenarios are not ideal and we need

to find a sampling window that strikes a balance.


We run the applications Browser and Dropbox concurrently, varying the sampling period.

For each sampling period we find the optimum PSM timeout value in each time window. We

then calculate the total energy consumed and total percentage of packets delayed. We select

the sampling period for which the total energy ⇥ percentage of packets delayed product is

minimal. We use this sampling period for the online algorithm to determine the optimal

PSM timeout value at runtime. To illustrate the influence of the sampling period, we collect

o✏ine traces of the tra�c with Browser and Dropbox running concurrently and determine

the PSM timeout that would have been determined for a specific window size.

Table 3.4 shows the numbers for di↵erent values of sampling windows for the Browser

and Dropbox scenario and it is clear that we would choose a 3s sampling period in this case.

Note that the sampling period simply provides a window of tra�c to determine the PSM

timeout value; it is not the rate at which we control the timeout itself. Figure 3.2 looks

more closely at how the optimum PSM timeout varies as we vary the sampling window size.

In the figure we see a 10s window of the tra�c pattern for the above example of Browser

and Dropbox. The x-axis indicates time and the sampling buckets are illustrated by the red

dotted lines. We consider the area between each pair of dotted lines as a sampling interval.

The y-axis shows the network tra�c in bytes. We see that for lower sampling periods, the

optimum PSM timeout varies dramatically between neighboring windows. But even then,

a lower sampling period may lead us to tune the PSM to be overly specific to a small tra�c

interval that may be sub-optimal for other windows.


Figure 3.2: Optimal sampling period for Browser and Dropbox running concurrently. Xaxis shows time and Y axis shows tra�c in bytes. The red dotted lines divide the tra�cover time into buckets of 1s each. The black arrow shows the sampling period consideredand the value on top shows the optimum PSM timeout for the particular window.


Application Delayapplied onpackets

Experiment conducted Comments about QoS

Browser 270ms Run bbench benchmark, mea-sure the Geometric Mean of loadtimes of all websites browsed.Experiment runs close to 5 min-utes. GM(no delay applied) =3625ms, GM(270ms delay ap-plied) = 3863ms

We see an overall increase in ge-ometric mean of web page loadtimes by 150ms for an experi-ment running close to 5 minutes.

Maps 260ms Searching for a particular loca-tion: Time taken(no delay ap-plied) = 6s, Time Taken(260msdelay applied) = 6.2s Find direc-tion between 2 locations: Timetaken(no delay applied) = 4.3sand Time taken(260ms delay ap-plied) 4.5s

On an average we see an increasein search time by 0.2s which wasimperceptible to the user.

YouTube 280ms Play a video of 10 minutes inlength and test for lag: Case 1(no delay applied) - Video took2s to load and no lag in the play-back after that. Case 2 (280msdelay applied) - Video took 2.4sto load and no lag in the play-back after that

Video takes 0.4s more on an aver-age for a 10 minute video, to loadbut the user does not observe alag when the playback starts.

Skype 280ms Make a voice call and test for lagin the call: Skype did not reportany call quality issues in either ofthe cases.

The user did not observe any dif-ference in call qualities.

Facebook 250ms Scroll through feeds, click on pic-tures and videos embedded in theposts.

The user did not observe any dif-ference in experience.

Twitter 250ms Scroll through feeds, click on pic-tures.

The user did not observe any dif-ference in experience.

Table 3.3: Evaluating QoS of applications. A delay equal to (Wakeup Interval - OptimalPSM timeout) is applied to each packet of the application. This gives us the worst-case QoSfor each of the applications listed in this table.


3.1.4 Setting PSM timeout

We explain how the PSM timeout of the WiFi radio is set at runtime based on the sample of

network tra�c. We need to obtain an energy v/s percentage of packets delayed curve similar

to the one in Figure 3.1. In order to obtain the energy v/s percentage of packets delayed

curve, we look at the tra�c in the previous sampling window. With the tra�c pattern, we

measure the energy and percentage of packets delayed using the model described in Section

2.4 at various PSM timeout values between 200ms and 10ms in steps of 10ms. Once we

obtain the curve, we need to find the knee point on the pareto-optimal frontier of the curve

so that it can be set as the PSM timeout.

There are a few existing approaches – Angle-based, EWMA and Menger Curvature

[29, 35]– to detect the knee point for a discrete data set. We use the angle-based approach

since it is the simplest of the three; because we are running the knee-detection algorithm

online, we need to keep the number of computations to a minimum and our dataset is not

large enough to warrant an elaborate algorithm.

Knee Detection The angle-based approach used by Zhao [35] finds the successive di↵er-

ences (y1 + y3 � 2y2) for each consecutive sets of three points (x1, y1), (x2, y2) and (x3, y3).

For any (nearly) straight segment, this di↵erence would be 0 or close to 0. However, if

the three points form a knee, y1 + y3 � 2y2 > 0. The sharper the knee is, the greater this

di↵erence is. This helps us to identify a knee in the energy-performance curve. Since this

measures successive di↵erences, the process tends to ignore the overall trend of the curve.

So, the algorithm sorts these local minima and calculates the two angles formed by the

y-axis and the line going through each successive pair of points assosiated with a di↵erence

value. Knee pointed is detected at the maxima of the sum of these two angle values.


SamplingPeriod (s)

Total En-ergy (J)

% DelayedPackets

Energy *% DelayedPackets

1 6.078 6.00 0.3652 5.178 6.00 0.3103 5.189 5.87 0.3044 5.260 5.88 0.3095 5.717 5.85 0.3346 5.710 5.73 0.3277 5.645 5.74 0.3248 5.553 5.77 0.3209 5.742 5.69 0.32710 5.867 5.68 0.333

Table 3.4: For applications Browser and Dropbox running concurrently, show the totalenergy consumed and the percentage of delayed packets over all the windows given eachsampling period. The product of energy and percentage of delayed packets is displayed inthe last column. This helps us to choose the ideal sampling window period. Lower is better.

3.2 Packet Governor

In this section we look at characterizing the network tra�c of some of the commonly used

Android applications. We notice that majority of the uplink and downlink network tra�c

happens in bursts of activity while the WiFi interface remains in PSM during times of

idleness. The ideal situation would be when we have continuous burst of activity followed

by a considerable period of inactivity, driven by the PSM timeout. But this is not always the

situation. Often applications have services running in the background which periodically

send packets on the network which results in the WiFi being woken up. We define a burst

as a series of network packets which occur at a time di↵erence less than a parameter called

the Burst Threshold, which is set to 5ms. In our experiments we find that several bursts

contain just 1 or 2 packets. Although, in the strict sense, these are not really a burst of

network activity, we still maintain the definition of a burst here because it becomes easier

to apply some of the tra�c shaping techniques that we will be discussing. We look at the

following things in this section:

• We describe the following parameters which we use to study bursty behaviour, similar

to the prior work done [27] : burst duration, burst size, packets per burst and burst

inter-arrival times.


• We measure the above mentioned burst parameters by capturing real-life network

traces for a number of commonly used Android applications.

• We identify situations where we can improve WiFi power e�ciency by aggregating

stray packets to schedule them along with the next burst.

• Using the power model described previously, we measure the power savings obtained

by this technique.

Burst Rate When we think about an application which produces bursty network pattern,

usually the first question would be ”What is the burst rate?”. Burst rate is defined as the

number of bursts occuring per second. We would think that this would give us an idea of

how bursty an application is. Table 3.5 lists the burst rate for some of the applications that

we conducted the experiment on. But the problem with characterizing an application based

on the burst rate is that, we cannot say anything meaningful about what kind of opportunity

exists in the tra�c pattern that can be used for better energy management. For example, if

the burst rate is low, we cannot say whether it is because there are a few really large bursts

or if there is not much network activity. If we are aware of this knowledge, we can apply

some kind of scheduling to delay packets resulting in better energy management. Hence, we

discuss the following four parameters to characterize a burst of network activity.

Application Burst Rate (bursts/s)Browser 10.4Skype 17.6Maps 7.3Twitter 4.4Facebook 7.7YouTube 2.9Browser+Dropbox 26.2Browser+TuneInRadio 23.2Maps+TuneInRadio 29.8Maps+Skype 28.4

Table 3.5: Burst rate of applications

Burst Characterestics We collected network traces for many popular Android applica-

tions and measured the following four characterestics for each application: Burst duration,

size, packets per burst and the burst inter-arrival times. We felt that these parameters are


su�cient to understand the characterestics of the tra�c pattern and we have identified sev-

eral situations where we can modify the shape of the tra�c to enable the WiFi interface to

stay idle for longer duration and measured the power savings obtained as a result. We define

a parameter called Burst Threshold, which is the minimum amount of time that separates

any two bursts of activity. Based on experimental observation, we set the value of the burst

threshold to be 5ms.

Burst Duration

Burst Duration is the di↵erence in timestamps of the first packet in a burst and the last

packet in the same burst. We measured burst duration for various applications and observed

that the bursts have durations as small as 250 microseconds to as big as 20 milliseconds.

Although we observed the Browser to have more number of bursts of 1ms and 5ms duration

on an average, the other applications used have burst durations almost evenly distributed

between 500 microseconds and 10 milliseconds.

We utilize this information in the next section where we explore a technique to delay

certain packets in order to increase the WiFi idle time.

Figure 3.3: Burst Duration.

Burst Size


Burst Size is defined as the total number of bytes of all the packets which belong to a

particular burst. From our experiments, we note that most applications have bursts which

are of size 65 bytes - 500 bytes. Only a few applications like Twitter and Facebook have a

very few bursts which are larger that 1MB in size. Understanding the burst size gives us

an opportunity to explore the technique of combining smaller bursts to form a larger burst

which might be useful in saving WiFi energy, which we explore in the next subsection.

Figure 3.4: Burst Size.

Packets Per Burst

As the name indicates, Packets Per Burst is the total number of packets present in each

burst. From our experiments, we notice that between 80-90% of all the applications have

bursts which are just 1 or 2 packets long. This gives us a great opportunity to delay packets

belonging to such bursts by a small amount so that we can obtain energy savings.

Burst Inter-Arrival Time

Burst Inter-Arrival Time is defined as the amount of time between consecutive bursts,

or the di↵erence in time between the timestamp of the last packet of one burst and the first

packet of the next burst. We observe that around 92% of the burst inter-arrival times are

between 10 and 30ms. We explore techniques where we try to increase this burst inter-arrival


Figure 3.5: Packets Per Burst.

time by scheduling the burst. By scheduling, we mean that we are delaying the transmitting

of the packets belonging to a burst by a certain amount of time. This kind of scheduling is

useful because we have seen in section 3.1 that applications usually have their optimal PSM

timeout in the 20-50ms range, and increasing the burst inter-arrival times enable the WiFi

interface to go to low power mode in-between bursts.

3.2.1 Tra�c Shaping

In this section, we make use of our understanding of the bursty nature of the applications’

network tra�c pattern in order to make minimal modifications in the tra�c which would

result in energy savings for the WiFi interface. We use techniques to schedule bursts so that

the WiFi interface is busy or idle for longer periods of time rather than having intermittent

activity which results in poor energy management. We find that we can have energy savings

upto 37% for some applications when we apply minimalistic tra�c shaping techniques. An

important point to be noted here is that we only schedule outgoing packets and all the

numbers listed here are specific to outgoing tra�c, unless specifically mentioned.

From our characterization of the bursty nature of tra�c for the Browser application, we


Figure 3.6: Burst Inter-Arrival Times.

noticed that > 50% of the bursts contained just 1 or 2 packets. Browser also has about

30% of the bursts which are < 65 bytes. So, we delayed these bursts so that they are

scheduled along with the next outgoing burst and compared the energy consumption using

the energy model described in 2.4. We were able to achieve a maximum reduction in energy

consumption of 37% by applying this technique for the Browser. Skype, on the other hand

has around 10% of the bursts which have a very short duration of < 250 microseconds. By

combining these bursts with subsequent bursts of larger duration, we were able to achieve a

reduction in energy consumption by 8%. In the case of Facebook, we found that the burst

inter-arrival times to be less than 10ms (but greater than the burst threshold of 5ms) in

30% of the cases. So we combined such bursts to be scheduled together to form larger bursts

and managed to obtain about 7% energy savings. By applying similar technique to Google

Maps and Twitter, we were able to obtain 7.5% and 14% reduction in energy consumption

respectively.


Application Percentage of packetson time

Browser 97.3Skype 99.2Maps 97.4Twitter 96.5Facebook 97.7YouTube 94.3Browser+Dropbox 97.1Browser+TuneInRadio 94.8Maps+TuneInRadio 95.6Maps+Skype 92.6

Table 3.6: Measure of performance of application on applying tra�c shaping techniques

3.3 Reducing Dynamic Power for Packet Processing

In this section we describe a technique to reduce the active power consumption for applica-

tions which create heavy network tra�c. Dynamic Voltage and Frequency Scaling (DVFS)

is a commonly-used technique which helps in the reduction of dynamic power consump-

tion by lowering the clock frequency and CPU voltage levels. We use frequency scaling to

throttle the CPU when the packets are processed in the OS. In general, applications can

adapt to intermittent delays in packet delay as they typically overlap with other processing

(e.g., page rendering in the browser). Furthermore, in the default system packets experience

some amount of delay in the network code of the OS, and the primary latency impact is the

interaction with the wider area network. This enables us to throttle the packet processing

in the OS without a↵ecting the QoS of the application while reducing the CPU power.

In the Android system, when an application sends data over the network, it initially

makes a write syscall. When the write syscall is invoked, the control reaches the socket

layer where sock_sendmsg() invokes the TCP processing tcp_sendmsg() which writes

the data into the socket and copies the data from the user-space memory to kernel-space

memory. This is essentially an I/O operation which does not require the CPU to be running

at it’s peak frequency and so, at this point, we dynamically scale down the frequency. We

boost the CPU frequency back to the default peak 998Mhz when transferring control back

to the application following a call into the device driver that sends and receives packets from

the radio.

To estimate the energy benefit of the throttling strategy Consider that the energy spent


in processing the network packets without any frequency scaling (system is running at peak

frequency 998MHz) is given by E. P is the instantaneous power consumed in this scenario

and t is the time spent in doing packet processing. Let Edvfs be the energy spent when we

apply the DVFS technique to packet processing. Let Pdvfs and tdvfs be the corresponding

power and time. The amount of energy saved by applying DVFS is given by:

E

Edvfs=

P

Pdvfs⇥ t

tdvfs

We used the Bbench suite [14] on the Android browser to study our throttling strategy.

Bbench loads a set of webpages in a loop and uses webpage load time as a proxy metric

for performance and QoS. We measured the web page load times without throttling and

estimated the increase in page load time for each website when the CPU is throttled to

691Mhz and 245Mhz (the lowest frequency on our phone’s processor). We choose these

particular frequencies as voltage of the processor is also dropped at these frequencies which

provides quadratic benefits for power reduction. The voltage readings at these frequencies

were 1.15mV and 1.0mV respectively. The voltage at the peak frequency of 998MHz was

1.275mV. The latency of packet processing at each frequency value is, t998 = 2.22s, t691 =

3.55s and t245 = 7.63s for the entire Bbench suite. Overall, the energy benefit of throttling

the frequency can be estimated as:

E691Mhz = 0.90⇥ E998Mhz

E245Mhz = 0.52⇥ E998Mhz

Table 3.7 also lists the extra amount of time taken to load each website in the Bbench

suite when we apply the above mechanism. As we can see, packet processing latency dramat-

ically increases with the frequency drop, however, perhaps more importantly it has minimal

impact on overall webpage load times. Even, with a low latency website such as Google we

see a < 3% increase in latency.


Website loadtime(ms)at998MHz

extra loadtime(ms)at691MHz

extra loadtime(ms)at245MHz

Amazon 1369 22 32BBC 2303 67 101CNN 4254 7 49Craigslist 1018 -52 15EBay 1833 10 43ESPN 3929 82 104Google 254 30 54MSN 2397 37 197Slashdot 3546 98 190Twitter 3956 11 133

Table 3.7: Show the amount of additional time needed to load each of the web pages whenthe CPU is throttled during network packet processing.

Chapter 4

Conclusions

4.0.1 Conclusions

Wireless radio on the smartphone supports at least one Power Save Mode (PSM). Smart-

phone applications have many short windows of idle periods (tens of ms and < 1ms) even

while actively running that we can exploit. However, given the diverse network behavior

of each application it is challenging to design a simple algorithm makes decisions about to

and out-of PSM. Current wireless algorithms use a fixed large timeout period (of 200ms)

to make decisions on transitions to PSM, which tend to lose many opportunities for saving

energy during active applications.

We explored the option of shortening the PSM timeout value and characterizing the

performance delays introduced in the packets. We presented a PSM governor which dy-

namically varies the PSM timeout based on tra�c characteristics and choose an optimal

PSM timeout. We study the tra�c behavior from a variety of applications and explore the

energy-saving v/s performance tradeo↵ in the quest for optimal PSM timeout values. We

show that optimality can vary significantly between applications (20ms for Skype versus

50ms for the Facebook) and sub-optimal values tend to either increase energy consumption

or delay i.e., the optimal value has a narrow window. We show that when multiple appli-

cations are actively using the network the optimal PSM timeout value changes with the

tra�c characteristics. Our PSM governor is able to react to the tra�c changes and track

the optimal PSM timeout. Overall, we show that by operating at the optimal PSM timeout

value, we can obtain up to 41% WiFi energy gains for standalone applications and up to

59% WiFi energy gains for concurrent applications over the current default setting with a

40

CHAPTER 4. CONCLUSIONS 41

maximum of 1–5% of packets delayed.

We characterized the bursty nature of application tra�c and showed that by modifying

the application tra�c slightly, we can obtain reduction in energy consumption by up to 37%

in some cases.

4.0.2 Looking Forward

The possible avenues of exploration based on the Governor design can be described as

follows:

Need for per-component sensors We have used a power model similar to many other

prior work in this area. Since a model can never be 100% accurate, this calls for the need

to have per-component hardware sensors to measure power consumed by each component

more accurately.

Bibliography

[1] Ieee standard for information technology- telecommunications and information ex-change between systems-local and metropolitan area networks-specific requirements-part 11: Wireless lan medium access control (mac) and physical layer (phy) specifica-tions. IEEE Std 802.11-1997, pages i–445, 1997.

[2] Yuvraj Agarwal, Ranveer Chandra, Alec Wolman, Paramvir Bahl, Kevin Chin, andRajesh Gupta. Wireless wakeups revisited: energy management for voip over wi-fismartphones. In Proceedings of the 5th international conference on Mobile systems,applications and services, MobiSys ’07, pages 179–191, New York, NY, USA, 2007.ACM.

[3] Manish Anand, Edmund B. Nightingale, and Jason Flinn. Self-tuning wireless networkpower management. Wirel. Netw., 11(4):451–469, July 2005.

[4] Aruna Balasubramanian, Ratul Mahajan, and Arun Venkataramani. Augmenting mo-bile 3g using wifi. In Proceedings of the 8th International Conference on Mobile Systems,Applications, and Services, MobiSys ’10, pages 209–222, New York, NY, USA, 2010.ACM.

[5] Niranjan Balasubramanian, Aruna Balasubramanian, and Arun Venkataramani. En-ergy consumption in mobile phones: A measurement study and implications for net-work applications. In Proceedings of the 9th ACM SIGCOMM Conference on InternetMeasurement Conference, IMC ’09, pages 280–293, New York, NY, USA, 2009. ACM.

[6] D. Bertozzi, L. Benini, and B. Ricco. Power aware network interface management forstreaming multimedia. In Wireless Communications and Networking Conference, 2002.WCNC2002. 2002 IEEE, volume 2, pages 926–930 vol.2, 2002.

[7] Canalys. Smart phones overtake client pcs in 2011, 2011.

[8] Surendar Chandra and Amin Vahdat. Application-specific network management forenergy-aware streaming of popular multimedia formats, 2002.

[9] Ning Ding, Abhinav Pathak, Dimitrios Koutsonikolas, Clayton Shepard, Y. CharlieHu, and Lin Zhong. Realizing the full potential of psm using proxying. In INFOCOM,pages 2821–2825, 2012.

42

BIBLIOGRAPHY 43

[10] Fahad R. Dogar, Peter Steenkiste, and Konstantina Papagiannaki. Catnap: exploitinghigh bandwidth wireless interfaces to save energy for mobile devices. In Proceedings ofthe 8th international conference on Mobile systems, applications, and services, MobiSys’10, pages 107–122, New York, NY, USA, 2010. ACM.

[11] Mian Dong and Lin Zhong. Self-constructive high-rate system energy modeling forbattery-powered mobile systems. In Proceedings of the 9th international conferenceon Mobile systems, applications, and services, MobiSys ’11, pages 335–348, New York,NY, USA, 2011. ACM.

[12] Hossein Falaki, Dimitrios Lymberopoulos, Ratul Mahajan, Srikanth Kandula, and Deb-orah Estrin. A first look at tra�c on smartphones. In Proceedings of the 10th ACMSIGCOMM conference on Internet measurement, IMC ’10, pages 281–287, New York,NY, USA, 2010. ACM.

[13] Gsmarena. Full smart phone specifications, 2013.

[14] A. Gutierrez, R.G. Dreslinski, T.F. Wenisch, T. Mudge, A. Saidi, C. Emmons, andN. Paver. Full-system analysis and characterization of interactive smartphone appli-cations. In Workload Characterization (IISWC), 2011 IEEE International Symposiumon, pages 81–90, 2011.

[15] Hao Han, Yunxin Liu, Guobin Shen, Yongguang Zhang, and Qun Li. Dozyap: power-e�cient wi-fi tethering. In Proceedings of the 10th international conference on Mobilesystems, applications, and services, MobiSys ’12, pages 421–434, New York, NY, USA,2012. ACM.

[16] Qualcomm Inc. Snapdragon mobile development platform (mdp), 2014.

[17] Ronny Krashinsky and Hari Balakrishnan. Minimizing energy for wireless web accesswith bounded slowdown, 2002.

[18] Jiayang Liu and Lin Zhong. Micro power management of active 802.11 interfaces. InProceedings of the 6th international conference on Mobile systems, applications, andservices, MobiSys ’08, pages 146–159, New York, NY, USA, 2008. ACM.

[19] J. Manweiler and R.R. Choudhury. Avoiding the rush hours: Wifi energy managementvia tra�c isolation. Mobile Computing, IEEE Transactions on, 11(5):739–752, 2012.

[20] A.A. Nacci, F. Trov, F. Maggi, M. Ferroni, A. Cazzola, D. Sciuto, and M.D. San-tambrogio. Adaptive and flexible smartphone power modeling. Mobile Networks andApplications, 18(5):600–609, 2013.

[21] Abhinav Pathak, Y. Charlie Hu, and Ming Zhang. Where is the energy spent insidemy app?: fine grained energy accounting on smartphones with eprof. In Proceedingsof the 7th ACM european conference on Computer Systems, EuroSys ’12, pages 29–42,New York, NY, USA, 2012. ACM.

BIBLIOGRAPHY 44

[22] Abhinav Pathak, Y. Charlie Hu, Ming Zhang, Paramvir Bahl, and Yi-Min Wang. Fine-grained power modeling for smartphones using system call tracing. In Proceedings ofthe Sixth Conference on Computer Systems, EuroSys ’11, pages 153–168, New York,NY, USA, 2011. ACM.

[23] Trevor Pering, Yuvraj Agarwal, Rajesh Gupta, and Roy Want. Coolspots: reducingthe power consumption of wireless mobile devices with multiple radio interfaces. InProceedings of the 4th international conference on Mobile systems, applications andservices, MobiSys ’06, pages 220–232, New York, NY, USA, 2006. ACM.

[24] C. Poellabauer and K. Schwan. Energy-aware tra�c shaping for wireless real-timeapplications. In Real-Time and Embedded Technology and Applications Symposium,2004. Proceedings. RTAS 2004. 10th IEEE, pages 48–55, 2004.

[25] Andrew J. Pyles, Xin Qi, Gang Zhou, Matthew Keally, and Xue Liu. Sapsm: Smartadaptive 802.11 psm for smartphones. In Proceedings of the 2012 ACM Conference onUbiquitous Computing, UbiComp ’12, pages 11–20, New York, NY, USA, 2012. ACM.

[26] Andrew J. Pyles, Zhen Ren, Gang Zhou, and Xue Liu. Sifi: exploiting voip silence forwifi energy savings insmart phones. In Proceedings of the 13th international conferenceon Ubiquitous computing, UbiComp ’11, pages 325–334, New York, NY, USA, 2011.ACM.

[27] Ajit Singh Rajesh Palit, Kshirasagar Naik. Anatomy of wifi access trac of smartphonesand implications for energy saving techniques. International Journal of Energy, Infor-mation and Communications, 2012.

[28] Eric Rozner, Vishnu Navda, Ramachandran Ramjee, and Shravan Rayanchu. Napman:network-assisted power management for wifi devices. In Proceedings of the 8th inter-national conference on Mobile systems, applications, and services, MobiSys ’10, pages91–106, New York, NY, USA, 2010. ACM.

[29] V. Satopaa, J. Albrecht, D. Irwin, and B. Raghavan. Finding a ”kneedle” in a haystack:Detecting knee points in system behavior. In Distributed Computing Systems Work-shops (ICDCSW), 2011 31st International Conference on, pages 166–171, June 2011.

[30] E.J. Vergara and S. Nadjm-Tehrani. Energy-aware cross-layer burst bu↵ering for wire-less communication. In Future Energy Systems: Where Energy, Computing and Com-munication Meet (e-Energy), 2012 Third International Conference on, pages 1–10, May2012.

[31] E.J. Vergara, J. Sanjuan, and S. Nadjm-Tehrani. Kernel level energy-e�cient 3g back-ground tra�c shaper for android smartphones. InWireless Communications and MobileComputing Conference (IWCMC), 2013 9th International, pages 443–449, July 2013.

BIBLIOGRAPHY 45

[32] Chanmin Yoon, Dongwon Kim, Wonwoo Jung, Chulkoo Kang, and Hojung Cha. App-scope: application energy metering framework for android smartphones using kernelactivity monitoring. In Proceedings of the 2012 USENIX conference on Annual Tech-nical Conference, USENIX ATC’12, pages 36–36, Berkeley, CA, USA, 2012. USENIXAssociation.

[33] Lide Zhang, Birjodh Tiwana, Zhiyun Qian, Zhaoguang Wang, Robert P. Dick, Zhuo-qing Morley Mao, and Lei Yang. Accurate online power estimation and automaticbattery behavior based power model generation for smartphones. In Proceedings of theeighth IEEE/ACM/IFIP international conference on Hardware/software codesign andsystem synthesis, CODES/ISSS ’10, pages 105–114, New York, NY, USA, 2010. ACM.

[34] Xinyu Zhang and Kang G. Shin. E-mili: energy-minimizing idle listening in wire-less networks. In Proceedings of the 17th annual international conference on Mobilecomputing and networking, MobiCom ’11, pages 205–216, New York, NY, USA, 2011.ACM.

[35] Qinpei Zhao, Ville Hautamaki, and Pasi Frnti. Knee point detection in bic for detectingthe number of clusters, 2008.

managing wifi energy in smartphones by throttling...

Documents