1. 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)

2. 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

3. 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 3 + X

4. Radio Characteristics 4 Higher throughput radios have a lower energy/bit value … have a higher idle power consumption …and they have different range characteristics

5. 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 5 Problem Statement: Reduce energy consumption by choosing appropriate radio interface, while taking into consideration other clients.

6. SwitchR Architecture 6 Bluetooth Link WiFi Link Ethernet Link Wi-Fi AP (WFAP) Infrastructure Network Wi-Fi Zone MD1 MD3 MD4 MD2 BTG (Bluetooth Gateway) MD = Mobile Devices Switching Mechanism: Network Level Reconfigurations ARPs and Routing updates Switching Policy: Hybrid Approach Application requirements at nodes (local) Channel quality and bandwidth (global)

7. 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

8. Evaluation: Testbed 8 Bluetooth (Always Connected) WiFi (Dynamically Switched) Static Wired Connection Wi-Fi AP Infrastructure Network Wi-Fi Zone MD1 MD3 MD4 MD2 BTG (Bluetooth Gateway) Mobile Device (MD) Stargate2 research platform WiFi + Bluetooth + Integrating power and data monitoring Benchmark applications are striped across devices Stargate2 node

9. Evaluation: Benchmarks 9 Baselines: Idle: connected, but no data transfer Transfer: bulk TCP data transfer Web: Combination of idle and data transfer Idle: “think time” Small transfer: basic web-pages Bulk transfer: documents or media Streaming: Media: 128k, 156k and g711 VoIP codec Various QoS requirements

10. 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

11. Results: Baselines 11 Switching policies perform better that WiFi policies for “idle” benchmark, similar for “transfer”

12. Results: 12 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

13. Summary SwitchR: Multi-radio switching architecture –Incrementally deployable –Energy Savings (72% over WiFi-PSM) –Can increase battery lifetime substantially 13

14. 14 Thank You! Website : http://mesl.ucsd.edu/yuvrajhttp://mesl.ucsd.edu/yuvraj Email : yuvraj@cs.ucsd.eduyuvraj@cs.ucsd.edu

15. Results: VoIP traffic 15 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