WiFi Energy Management
WiFi : Saving Energy through Sleep
Between packet bursts, WiFi switches
to low-power sleep mode
Zzz…
Zzz…
Time
2
WiFi Sleep Under Contention
Zzz…
Zzz…
Time
Zzz…
Zzz…
Time
3
Beacon Wakeups
Bad wakeups =
burst contention
Traffic
Download
Key intuition: move beacons, spread
apart traffic, let clients sleep faster
4
Zzz…
Zzz…
vs
MEASUREMENTS
Energy performance on modern WiFi smartphones
5
Simultaneous measurements at 5K hertz
6
Power (mW)
Energy Profile of Nexus One
700
600
500
400
300
200
100
0
Time (s) 0.0
Idle/Overhear
Light Sleep
0.5
1.0
1.5
Time (s)
2.0
2.5
3.0
With contention:
↑ Idle/Overhear, ↓ Sleep
7
Total Energy in Joules (J)
Energy Cost of Contention
40
35
30
25
20
15
10
5
0
Energy costs grow with
number of contenders
File Download
Iperf
YouTube
1 AP 2 AP 3 AP 4 AP 5 AP 6 AP 7 AP 8 AP
Denser Neighborhood
8
Activity Percentages
100%
File Download
Time
80%
Increasing time in
Idle/Overhear
60%
40%
20%
High
Power
Transmit/Receive
Idle/Overhear
Light Sleep
Deep Sleep
0%
1 AP 2 AP 3 AP 4 AP 5 AP 6 AP 7 AP 8 AP
9
Wakeup later / go home later
Smarter commute = save gas
Smarter beacons = save battery
SLEEPWELL DESIGN
Avoiding the rush hours to save energy
10
SleepWell Techniques
● Traffic Monitoring
 APs maintain a map of peers in the wireless vicinity
● Traffic Migration
 APs select a new beacon position based on heuristics
● Traffic Preemption
 APs avoid traffic spillover into that of neighbors
11
Traffic Monitoring
beacon & traffic maps for
the one-hop neighborhood
12
Traffic Migration
0
85
Expected share =
100/(n + 1) = 25 ms
Claim expected share
from largest hole
25
75
70
CONVERGES
55
50
13
Key Implementation Challenge
● APs need to change the beacon timings
● But, no 802.11 protocol support
40
● Fortunately, clients synchronize to AP clocks
● AP can change beacon by “lying” about the time
Fully 802.11 compatible AP:
Hostapd + modified Atheros Ath9k 802.11n driver
14
Rescheduling Client Wakeups
heydelayed
client
I“
know
client
will
Yes,
this beacon
is
wakeup
40ms
client
byin40ms
60ms Late”
OK,
Iadjust
need to
I’llRight
wakeup in 40ms
on
my time
clock
0
0
Actual
Time
Client Clock
50
50
(sync to AP)
15
Energy TDMA
Power (mW)
800
600
SleepWell, 2 AP (Client A)
802.11,
2
AP
SleepWell, 2 AP (Client B)
400
200
0
0.0 0.4 0.8 1.2 1.6 2.0 2.4 2.8 3.2 3.6
Time (s)
16
Total Energy in Joules (J)
Energy Comparison
40
35
30
25
20
15
10
5
0
No Contention
802.11, 8 AP
SleepWell, 8 AP
Iperf
File Download
YouTube
Pandora
17
Activity Percentages: 802.11
100%
File Download
80%
60%
40%
20%
High
Power
Transmit/Receive
Idle/Overhear
Light Sleep
Deep Sleep
0%
1 AP 2 AP 3 AP 4 AP 5 AP 6 AP 7 AP 8 AP
18
Activity Percentages: SleepWell
100%
File Download
80%
60%
40%
20%
High
Power
Transmit/Receive
Idle/Overhear
Light Sleep
Deep Sleep
0%
1 AP 2 AP 3 AP 4 AP 5 AP 6 AP 7 AP 8 AP
19
Youtube CDF, Instantaneous Power
Empirical CDF
1
0.8
SleepWell closely matches
zero-contention energy profile
0.6
0.4
1 AP
802.11, 8 AP
SleepWell, 8 AP
0.2
0
0
200
400
Power in Milliwatts (mW)
600
20
Throughput under SleepWell
Empirical CDF
(per-link TCP on 4 AP testbed)
1
Negligible performance impact:
SleepWell just reorders traffic
0.8
0.6
0.4
802.11
SleepWell
0.2
0
0
0.5
1
1.5
Bandwidth (Mbps)
2
2.5
21
Limitations
● Not immediately suitable to interactive traffic (VoIP)
 True of 802.11 PSM in general
● Legacy APs lessen energy savings
 Won’t preempt for SleepWell traffic
● Contention from clients of the same AP
 Considered in NAPman [MobiSys 2010]
22
Prior Work
● WiFi PSM Sleep Optimization
 NAPman, Catnap [MobiSys 10]
 μPM [MobiSys 08]
● WiFi Duty Cycling
 Wake-on-Wireless [MobiCom 02] / revisited [MobiSys 07]
 Context-for-Wireless [MobiSys 07]
 Blue-Fi [MobiSys 09], Breadcrumbs [MobiCom 08]
 Also, Turducken, Coolspots, Tailender, etc.
● Sensor network TDMA
 Z-MAC [SenSys 05]
 S-MAC [INFOCOM 02]
23
Conclusion
to
Zzz…
Zzz…
● PSM is a valuable energy-saving optimization
● But, PSM designed with a single AP in mind
● Multiple APs induce contention, waste energy
● Staggered wakeups  clients sleep through contention
● SleepWell = PSM made efficient for high-density networks
24
THANK YOU!
Questions?
cs.duke.edu/~jgm
jgm@cs.duke.edu
25
Traffic Preemption
0
25
75
Traffic preemption
prevents spillover
50
26