Transcript Document

CoolSpots
Yuvraj Agarwal, CSE, UCSD
Trevor Pering, Intel Research
Rajesh Gupta, CSE, UCSD
Roy Want, Intel Research
Motivation: Wireless Power Is a Problem!
CPU:
47 m W
Depending on the usage
model, the power
consumption of emerging
mobile devices can be
easily dominated by the
wireless interfaces!
Other:
251 m W
WiFi:
786 m W
SDRAM:
86 m W
Bluetooth
112 m W
CPU
SDRAM
Bluetooth
Wi-Fi
Other
Power breakdown for a fully connected
mobile device in idle mode, with LCD
screen and backlight turned off.
CoolSpots
Opportunity: Devices With Multiple Radios
Many devices already have multiple wireless interfaces…
• PDA’s HP h6300 (GSM/GPRS, BT, 802.11)
• Mobile Phones - Motorola CN620 (BT, 802.11, GSM)
• Laptops (Wi-Fi, BT, GSM, …)
These radios typically function as isolated systems,
but what if their operation was coordinated to
provide a unified network connection?
CoolSpots
450
400
350
300
250
200
150
100
50
0
250
200
150
100
50
Energy/Bit (nJ/bit)
Idle Power (mW)
Properties of Common Radio Standards
0
Zigbee
BT
0.25Mbps 1.1Mbps
802.11
11Mbps
Higher throughput radios have a lower energy/bit value
… have a higher idle power consumption
…and they have different range characteristics!
CoolSpots
Low-power Access Within a WiFi Hot-spot
Mobile Device
(e.g., cell-phone)
Wi-Fi
HotSpot
CoolSpots
CoolSpots
Your entire house
would be covered
by a WiFi HotSpot…
Your TV would be a
Bluetooth-enabled
CoolSpot!
CoolSpots
Inter/Intra Technology Power Management
CoolSpots
Bluetooth
Wi-Fi
WiFi
Active
BT
Sniff
WiFi
Active
BT
Active
5.8 mW
81 mW
WiFi
WiFi
Active
PSM
264 mW
WiFi
Active
990 mW
CoolSpots implement inter-technology power management
on top of intra-technology techniques to realize better
power & performance than any single radio technology.
CoolSpots
CoolSpots Network Architecture
5
Backbone Network
4
Access point changes routing
table on “switch” message
from mobile device
CoolSpot
Access Point
BT
WiFi
Switching is transparent:
applications always use the IP
address of the local subnet.
Infrastructure
Computers
3
WiFi link is
dynamically activated
based on switching
determination
1
Low-power Bluetooth link
(always maintained, when
possible)
BT
WiFi
Mobile
Device
IP address on
Backbone Subnet
CoolSpots
2
Mobile device
monitors channel
and implements
switching policy
Switching Overview
Three main components contribute to the behavior of
a multi-radio system: where, what, and when
Position: Where you are
•
Need to address the difference in range between Bluetooth and WiFi
Benchmarks: What you are doing
•
Application traffic patterns greatly affect underlying policies
Policies: When to switch interfaces
•
A non-intrusive way to tell which interface to use
CoolSpots
Where: Position
Bluetooth and WiFi have very
different operating ranges!
(approx. 10m vs. 100m)
• Optimal switching point will
depend on exact operating
conditions, not just range
Position 1
Bluetooth channel
capacity depends on
range, so the further
away you are, the
sooner you need to
switch…
Base
Station
• Experiments and (effective)
policies will measure and
take into account a variety
of operating conditions
Position 2
In some situations,
Bluetooth will not
be functional and
WiFi will be the
only alternative
Position 3
CoolSpots
What: Benchmarks
Baseline: target underlying strengths
of wireless technologies
• Idle: connected, but no data transfer
• Transfer: bulk TCP data transfer
Video: range of streaming
bit-rates varying video quality
• 128k, 250k, 384k datarates
• Streaming data, instant start
WWW: realistic combination of idle
and data transfer conditions
• Idle: “think time”
• Small transfer: basic web-pages
• Bulk transfer: documents or media
CoolSpots
When: Policies
The switching policy determines how the system will react
under different operating conditions
cap-static-X
time > Y
kbps > X
bandwidth-X
bluetooth-fixed (using sniff mode)
Use Bluetooth Channel
CoolSpots
kbps < Z
cap-dynamic
time > Y
kbps < X
kbps < X
wifi-fixed (using PSM)
Z = kbps
Use WiFi Channel
wifi CAM (normalization baseline)
Experimental Setup
• Characterize power for WiFi and BT
–
–
–
Multiple Policies
Different locations
Suite of benchmark applications
Benchmark suite
Test Machine (TM)
• Stargate research platform
–
–
ETH
400Mhz processor, 64MB RAM, Linux
Allows detailed power measurement
mW
BT
Base Station (BS)
RM
Mobile Device (MD)
SP
WiFi
• Tested using “today’s” wireless:
–
–
Data Acquisition (DA)
WiFi is NetGear MA701 CF card
Bluetooth is a CSR BlueCore3 module
• Use the geometric mean to combine
benchmarks into an aggregate result
Distance
adjustment
ETH = Wired Ethernet
BT = Bluetooth
RM = Route Management
• Moved devices around on a cart to
vary channel characteristics
CoolSpots
mW = Power Measurements
WiFi = WiFi Wireless
SP = Switching Policy
Switching Example: MPEG4 streaming
- Simple bandwidth policy
Wi-Fi
- Switch from WiFi to BT when
application has buffered enough data
Bluetooth
Switch :
Wi-Fi -> BT
Demonstrates how
switching is
transparent to
unmodified
applications!
CoolSpots
Results Overview (Intermediate Location)
Normalized Energy
250%
80%
200%
60%
150%
40%
100%
20%
50%
0%
0%
w
C
ifi -
AM
Normalized Time
WiFi Energy
Bluetooth Energy
Time
100%
c
d
ed
-30
mi
-30
xe
i
x
c
h
i
f
a
i
t
f
t
n
ita
dy
wi d
l ue
s
wif
b
d
p
p
n
ca
ca
ba
Sw itching Policy (Fixed Range, Aggregate Benchm ark)
• blue-fixed does well in terms of energy but at the cost of increased latency
• cap-dynamic does well in terms of both energy and increased latency
CoolSpots
Impact of Range/Distance
80%
Location 1
70%
Location 2
Bandw idth Policies
60%
Cap-Static Policies
Location 3
Energy
50%
40%
30%
20%
10%
0%
ed
-fix
i
f
i
w
0
0
0
ithth-3
th-5
d
d
d
i
i
w
w
w
d
d
d
ban
ban
ban
ic
30
50
c-0
ti cti cnam
tati
y
a
a
s
t
t
d
s
s
c ap
c ap
c ap
c ap
x
e-fi
bl u
Sw itching Policy
Missing data indicates failure of at least one application,
and therefore an ineffective policy!
CoolSpots
ed
Energy
Results across various benchmarks
140%
wifi-fixed
120%
bandwidth-30
100%
cap-dynamic
blue-fixed
80%
60%
40%
20%
0%
Idle
transfer-1
transfer-2
www-intel
wwwgallery
video128k video250k video384k
Benchmark
wifi-fixed consumes lowest energy for data transfer, any bluetooth policy for idle
Overall, cap-dynamic does well taking into account energy and latency
Video benchmarks really highlight problems with wifi-fixed and bandwidth-x
CoolSpots
Cap-Dynamic Switching Policy
• Switch up based on measured channel capacity (ping time > Y)
• Remember last seen Bluetooth bandwidth (Z=kbps)
• Switch down based on remembered bandwidth (kbps < Z)
cap-dynamic policy
time > Y
Z = kbps
kbps < Z
CoolSpots
Switching Policies – Analysis
•
“Wifi-Fixed” Policy (WiFi in Power Save Mode)
–
–
•
Works best for as-fast-as-you-can data transfer
Higher power consumption, especially idle power
“Blue-Fixed” Policy
– Very low idle power consumption
– Increases total application latency, fails at longer ranges
•
“Bandwidth” Policy
– Static coded bandwidth thresholds, fails to adapt at longer ranges
– Switches too soon (bandwidth-0) or switches too late (bandwidth-50)
•
“Capacity-Static” Policy
– Estimates channel capacity and uses that to switch up
– Fails at longer ranges due to incorrect switch-down point
•
“Capacity-Dynamic” Policy
– Dynamic policy, remembers the last seem switch-up bandwidth
– Performs well across all benchmarks and location configurations!
CoolSpots
Conclusions
•
A dynamic system can leverage the different underlying radio
characteristics to reduce communication energy while still
maintaining good performance
•
Advanced policies can adapt well to changing operating conditions
– Application behavior
– Radio link quality
•
Evaluation of CoolSpots policies shows around a 50% reduction in
energy consumption over the present power management scheme in
WiFi (PSM) across a range of situations
CoolSpots
Thank you!
Questions?
CoolSpots