acc6ch20.ppt acc6ch20.ppt acc6ch20.pptacc6ch20.ppt acc6ch20.ppt acc6ch20.ppt acc6ch20.ppt
PPT]
-
Upload
garry54 -
Category
Technology
-
view
1.126 -
download
0
description
Transcript of PPT]
CoolSpots
Yuvraj Agarwal, CSE, UCSD Trevor Pering, Intel Research
Rajesh Gupta, CSE, UCSDRoy Want, Intel Research
CoolSpots
Motivation: Wireless Power Is a Problem!
Power breakdown for a fully connected mobile device in idle mode, with LCD screen and backlight turned off.
Depending on the usage model, the power consumption of emerging mobile devices can be easily dominated by the wireless interfaces!
CoolSpots
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, …)
Opportunity: Devices With Multiple Radios
These radios typically function as isolated systems, but what if their operation was coordinated to provide a unified network connection?
CoolSpots
Properties of Common Radio Standards
050
100150200250300350400450
Zigbee BT 802.11
Idle
Po
we
r (m
W)
0
50
100
150
200
250
En
erg
y/B
it (
nJ
/bit
)
0.25Mbps 1.1Mbps 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
Wi-Fi HotSpot
Mobile Device(e.g., cell-phone)
CoolSpots
CoolSpots
Your entire house would be coveredby a WiFi HotSpot…
Your TV would be a Bluetooth-enabled CoolSpot!
CoolSpots
WiFiActive
CoolSpots implement inter-technology power management on top of intra-technology techniques to realize better power & performance than any single radio technology.
WiFiActive
WiFiPSM
WiFiActiveBT
Active
WiFiActiveBT
Sniff
Bluetooth Wi-Fi
CoolSpots
Inter/Intra Technology Power Management
264 mW 990 mW81 mW5.8 mW
CoolSpots
CoolSpots Network Architecture
Infrastructure Computers
CoolSpotAccess PointBT WiFi
BT WiFiMobile Device
IP address onBackbone Subnet
Low-power Bluetooth link(always maintained, when possible)
1
Mobile device monitors channel and implements switching policy
2
WiFi link is dynamically activated based on switching determination
3
Access point changes routing table on “switch” message from mobile device
4
Switching is transparent: applications always use the IP address of the local subnet.
5
Backbone Network
CoolSpots
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
• Experiments and (effective) policies will measure and take into account a variety of operating conditions
Position 1
Position 3
Bluetooth channel capacity depends on range, so the further away you are, the sooner you need to switch…
Base Station
In some situations, Bluetooth will not be functional and WiFi will be the only alternative
Position 2
CoolSpots
What: Benchmarks
Baseline: target underlying strengths of wireless technologies
• Idle: connected, but no data transfer
• Transfer: bulk TCP data transfer
WWW: realistic combination of idle and data transfer conditions
• Idle: “think time”
• Small transfer: basic web-pages
• Bulk transfer: documents or media
Video: range of streamingbit-rates varying video quality
• 128k, 250k, 384k datarates
• Streaming data, instant start
CoolSpots
When: Policies
The switching policy determines how the system will react under different operating conditions
bluetooth-fixed (using sniff mode)
wifi CAM (normalization baseline)
wifi-fixed (using PSM)
bandwidth-X cap-static-X cap-dynamic
kbps
> X
kbps
< X
kbps
< X
time
> Y
time
> Y
kbps
< Z
Z =
kbp
s
Use WiFi Channel
Use Bluetooth Channel
CoolSpots
Experimental Setup
• Characterize power for WiFi and BT– Multiple Policies – Different locations – Suite of benchmark applications
• Stargate research platform– 400Mhz processor, 64MB RAM, Linux– Allows detailed power measurement
• Tested using “today’s” wireless:– WiFi is NetGear MA701 CF card– Bluetooth is a CSR BlueCore3 module
• Use the geometric mean to combine benchmarks into an aggregate result
• Moved devices around on a cart to vary channel characteristics
Test Machine (TM)
Base Station (BS)
RMMobile Device (MD)
SP
Data Acquisition (DA)
ETH
BT
WiFi
mW
Distanceadjustment
ETH = Wired Ethernet mW = Power MeasurementsBT = Bluetooth WiFi = WiFi WirelessRM = Route Management SP = Switching Policy
Benchmark suite
CoolSpots
Switching Example: MPEG4 streaming
Switch : Wi-Fi -> BT
Bluetooth
Wi-Fi
- Simple bandwidth policy
- Switch from WiFi to BT when application has buffered enough data
Demonstrates how switching is transparent to unmodified applications!
CoolSpots
Results Overview (Intermediate Location)
0%
20%
40%
60%
80%
100%
wifi-CAM
wifi-fixed
bandwidth-30
cap-static-30
cap-dynamic
blue-fixed
Switching Policy (Fixed Range, Aggregate Benchmark)
No
rmal
ized
En
erg
y
0%
50%
100%
150%
200%
250%
No
rmal
ized
Tim
e
WiFi EnergyBluetooth EnergyTime
• 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
0%
10%
20%
30%
40%
50%
60%
70%
80%
wifi-fixed
bandwdith-0
bandwidth-30
bandwidth-50
cap-static-0
cap-static-30
cap-static-50
cap-dynamic
blue-fixed
Switching Policy
En
erg
y
Location 1
Location 2
Location 3
Bandw idth Policies
Cap-Static Policies
Missing data indicates failure of at least one application, and therefore an ineffective policy!
CoolSpots
Results across various benchmarks
0%
20%
40%
60%
80%
100%
120%
140%
Idle transfer-1 transfer-2 www-intel www-gallery
video128k video250k video384k
Benchmark
En
erg
y
wifi-fixed
bandwidth-30
cap-dynamic
blue-fixed
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
kbps < Z
Z = kbps
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?