Avoiding the Rush Hours: WiFi Energy Management via Traffic - PowerPoint PPT Presentation

Avoiding the Rush Hours: WiFi Energy Management via Traffic Isolation Justin Manweiler Romit Roy Choudhury ACM MobiSys 2011

: Saving Energy through Sleep WiFi 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
conten+on
 Traffic

 Download
 Key
intui8on:
 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


Energy Profile of Nexus One 700 600 Power (mW) 500 400 Idle/Overhear
 300 200 100 Light
Sleep
 0 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Time (s) Time (s) With
conten*on:
 ↑ 
 Idle/Overhear ,
 ↓ 
 Sleep 
 7


Energy Cost of Contention 40
 Energy
costs
 grow 
with
 Total
Energy
in
Joules
(J)
 35
 number
of
contenders
 30
 Iperf
 File
Download
 25
 YouTube
 20
 15
 10
 5
 0
 1
AP
 2
AP
 3
AP
 4
AP
 5
AP
 6
AP
 7
AP
 8
AP
 Denser
Neighborhood
 8


Activity Percentages File
Download
 100%
 80%
 Increasing
Ume
in

 Idle/Overhear
 60%
 Time
 High
Power
 40%
 Transmit/Receive
 Idle/Overhear
 Light
Sleep
 20%
 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
ba\ery 
 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
posiUon
based
on
heurisUcs
 
 ● 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
 25
 75
 Claim
 expected
share
 from
largest
hole
 70
 CONVERGES 
 55
 55
 50
 13


Traffic Preemption 0
 25
 75
 Traffic
 preemp+on 
 prevents
spillover 
 50
 14


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
compa+ble
AP :
 Hostapd
+
modified
Atheros
Ath9k
802.11n
driver
 15


Rescheduling Client Wakeups “ hey
client
 OK,
I
need
to
 Right
 
 I’ll
adjust

 I
know
client
will

 Yes,
delayed

 wakeup
in
40ms 
 my
clock 
 on
+me 
 wakeup
in
40ms 
 this
beacon
is
 client
by
40ms
 60ms
Late”
 0
 0
 Actual
 Client
Clock
 Time 
 (sync
to
AP) 
 50
 50
 16


Energy TDMA 800
 800
 800
 SleepWell,
2
AP
(Client
A)
 802.11,
2
AP
 SleepWell,
2
AP
(Client
B)
 Power
(mW)
 Power
(mW)
 Power
(mW)
 600
 600
 600
 400
 400
 400
 200
 200
 200
 0
 0
 0
 0.0
 0.4
 0.8
 1.2
 1.6
 2.0
 2.4
 2.8
 3.2
 3.6
 0.0
 0.4
 0.8
 1.2
 1.6
 2.0
 2.4
 2.8
 3.2
 3.6
 0.0
 0.4
 0.8
 1.2
 1.6
 2.0
 2.4
 2.8
 3.2
 3.6
 Time
(s)
 Time
(s)
 Time
(s)
 17


Energy Comparison 40
 Total
Energy
in
Joules
(J)
 No
ContenUon
 35
 802.11,
8
AP
 30
 SleepWell,
8
AP
 25
 20
 15
 10
 5
 0
 Iperf
 YouTube
 Pandora
 File
Download
 18


Activity Percentages: 802.11 File
Download
 100%
 80%
 60%
 High
Power
 40%
 Transmit/Receive
 Idle/Overhear
 Light
Sleep
 20%
 Deep
Sleep
 0%
 1
AP
 2
AP
 3
AP
 4
AP
 5
AP
 6
AP
 7
AP
 8
AP
 19


Activity Percentages: SleepWell File
Download
 100%
 80%
 60%
 High
Power
 40%
 Transmit/Receive
 Idle/Overhear
 Light
Sleep
 20%
 Deep
Sleep
 0%
 1
AP
 2
AP
 3
AP
 4
AP
 5
AP
 6
AP
 7
AP
 8
AP
 20


Youtube CDF, Instantaneous Power 1
 0.8
 Empirical
CDF
 SleepWell
closely
matches
 zero‐conten8on 
energy
profile 
 0.6
 0.4
 1
AP
 802.11,
8
AP
 0.2
 SleepWell,
8
AP
 0
 0
 100
 200
 300
 400
 500
 600
 Power
in
Milliwa\s
(mW)
 21


Throughput under SleepWell (per-link TCP on 4 AP testbed) 1
 Negligible
performance
impact:
 0.8
 SleepWell
just
reorders
traffic
 Empirical
CDF
 0.6
 0.4
 802.11
 0.2
 SleepWell
 0
 0
 0.5
 1
 1.5
 2
 2.5
 Bandwidth
(Mbps)
 22


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]
 23


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]
 24


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 25


THANK
YOU!
 Ques8ons?
 cs.duke.edu/~jgm
 jgm@cs.duke.edu
 26