Transcript SwitchR: Reducing System Power Consumption in a Multi

SwitchR:
Reducing System Power Consumption
in a Multi-Client Multi-Radio Environment
Yuvraj Agarwal
(University of California, San Diego)
Trevor Pering, Roy Want (Intel Research),
Rajesh Gupta (UC San Diego)
Wearable and Mobile Devices:
• Increasing Functionality
– Faster processors, more memory
• Applications are increasingly communication intensive
– Streaming video, VoIP, Downloading files
• Multiple wireless radios often integrated on single device
– (Bluetooth for PANs, WiFi for high-bandwidth data access)
• Wearable/Mobile Computers  Power Consumption is very important!
– Limited by battery lifetime
– Communication over WiFi reduces battery lifetime even further….
 In some cases up to 50% of total energy drain!
2
Reducing the energy for communication
• Opportunity: Availability of multiple radio interfaces …
– Can all be used for data transfer
– Different characteristics : bandwidth, range, power consumption
• Typically function as isolated systems,
– Can we coordinate usage to provide a unified network connection ?
 Seamlessly switch between radios
– Primary Goal: Save energy
+
X
3
450
400
350
300
250
200
150
100
50
0
250
200
150
100
50
Energy/Bit (nJ/bit)
Idle Power (mW)
Radio Characteristics
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
4
Multi-Radio Switching
• CoolSpots [Mobisys ‘06]:
– Multi-Radio switching for a single-client scenario
– Specialized access point (Bluetooth + WiFi)
– Switching decisions – Local to client
• SwitchR:
–
–
–
–
Leverage existing WiFi APs : Incrementally deployable
Considers traffic imposed by other devices in a multi-client scenario
Switching decision – global since it affect other clients
Evaluate energy savings on a distributed testbed
Problem Statement: Reduce energy consumption by choosing appropriate radio
interface, while taking into consideration other clients.
5
SwitchR Architecture
Infrastructure Network
BTG
(Bluetooth Gateway)
Bluetooth Link
MD1
WiFi Link
Wi-Fi
Zone
MD2
Ethernet Link
Wi-Fi AP
(WFAP)
MD3
MD4
MD = Mobile Devices
Switching Mechanism:
• Network Level Reconfigurations
Switching Policy:
• Hybrid Approach
• ARPs and Routing updates
• Application requirements at nodes (local)
• Channel quality and bandwidth (global)
6
Multi-Client Switching Policy
• Hybrid approach to make switching decisions
– Local knowledge (node level)
– Global (channel utilization by other nodes)
• Switching up (Bluetooth  WiFi)
– ICMP response time and radio RSSI values
– Capture application needs and channel characteristics
• Switching-down (WiFi  Bluetooth)
– Measure application bandwidth requirements
– Periodically query BTG for residual capacity
– Measure channel/link quality (local)
7
Evaluation: Testbed
BTG
(Bluetooth Gateway)
Infrastructure Network
Bluetooth (Always Connected)
MD1
WiFi (Dynamically Switched)
Static Wired Connection
Wi-Fi
Zone
MD2
Wi-Fi AP
MD3
MD4
Mobile Device (MD)
Stargate2 node
• Stargate2 research platform
• WiFi + Bluetooth + Integrating power and data monitoring
• Benchmark
applications are striped across devices
8
Evaluation: Benchmarks
Baselines:
• Idle: connected, but no data transfer
• Transfer: bulk TCP data transfer
Streaming:
• Media: 128k, 156k and g711 VoIP codec
• Various QoS requirements
Web:
• Combination of idle and data transfer
• Idle: “think time”
• Small transfer: basic web-pages
• Bulk transfer: documents or media
9
Evaluation: Switching Policies
• Baselines policies
– “Wifi-CAM” (Awake Mode)
– “Wifi-PSM” (Power Save Mode)
•
Single-Client based “cap-dynamic” switching policy
• SwitchR: “multi-client” switching policy
– Combines both local (per client) and global knowledge
10
Average
m
u
ca ltip- cli
dy en
n t
w am
if i
w i-PS c
ifi M
-C
AM
m
u
ca lti-c
p- lie
dy n
n t
w am
if i
w i-PS c
ifi M
-C
AM
m
ul
ca tip- cli
dy en
n t
w am
ifi ic
w - PS
ifi M
-C
AM
m
u
ca ltip- cli
dy en
n t
w am
if i
w i-PS c
ifi M
-C
AM
Power (Normalized)
Bluetooth-Power
1.2
0.2
0
idle
g711
WiFi-power
web
transfer
1
0.8
0.6
0.4
2
1.8
1.6
1.4
1.2
1
0.8
0.6
0.4
0.2
0
Energy-per-bit (Normalized)
Results: Baselines
Basic Benchmark Suite
Energy-Per-Bit
Switching policies perform better that WiFi policies for “idle” benchmark, similar for “transfer”
11
Results:
Loaded Benchmark Suite
1
g711
web
stream
128 kbps
Energy-Per-Bit
stream
156 kbps
0.8
0.6
0.4
0.2
0
2
1.8
1.6
1.4
1.2
1
0.8
0.6
0.4
0.2
0
Energy-per-bit (Normalized)
1.2
WiFi-power
m
u
ca ltip- cli
dy en
n t
w am
if i
w i-PS c
ifi M
-C
AM
m
ul
ca tip- cli
dy en
n t
w am
if
w i-PS ic
ifi M
-C
AM
m
ul
ca tip- cli
dy en
n t
w am
if i
w i-PS c
ifi M
-C
AM
m
ul
ca tip- cli
dy en
n t
w am
if i
w i-PS c
ifi M
-C
AM
Average Power (Normalized)
Bluetooth-Power
multi-client policy saves up to 62% over single-client cap-dynamic policy
VoIP and streaming benchmarks benefit most since streams can use BT channel
12
Summary
• SwitchR: Multi-radio switching architecture
– Incrementally deployable
– Energy Savings (72% over WiFi-PSM)
– Can increase battery lifetime substantially
13
Thank You!
Website : http://mesl.ucsd.edu/yuvraj
Email : [email protected]
14
Results: VoIP traffic
VoIP Benchmark Suite (Using both g711 and g729 codecs)
Energy-Per-Bit
1.2
1
2
g711
g729
g729
web
0.8
0.6
0.4
0.2
1.8
1.6
1.4
1.2
1
0.8
0.6
0.4
0.2
0
0
Energy-per-bit (Normalized)
WiFi-power
m
u
ca lti-c
p- l i e
dy n
n t
w am
ifi ic
w -PSM
ifi
-C
AM
m
u
ca lti-c
p- l i e
dy nt
n
w am
ifi ic
w -PSM
ifi
-C
AM
m
u
ca lti-c
p- l i e
dy n
n t
w am
ifi ic
w -PSM
ifi
-C
AM
m
u
ca lti-c
p- l i e
dy n
n t
w am
ifi ic
w -PSM
ifi
-C
AM
Average Power (Normalized)
Bluetooth-Power
Although, bandwidth requirements less than bluetooth channel capacity
Web benchmark causes VoIP streams to switch to WiFi
multi-client policy saves upto 65% over cap-dynamic, allows VoIP streams to switch back
15