User-Profile-Driven Collaborative Bandwidth Sharing for Mobile Phones

1. Eric Jung, Yichuan Wang, Iuri Prilepov, Frank Maker, Xin Liu, & Venkatesh Akella University of California, Davis eajung@ucdavis.edu User-Profile-Driven Collaborative Bandwidth Sharing for Mobile Phones TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: AAAAAAAAAAAAAAAAAA

2. Outline • Introduction • Resource Aware Collaborative Execution (RACE) • RACE Modeling and Policies • Evaluation • Conclusion

3. Mobile Apps are Cloud Apps • Synchronization • Social Networking • Location

4. Network Overloading • Smartphones have changed the game for providers • Mobile data usage will double annually through 2014 (Cisco)  • Driven by smartphone ascent – for AT&T, 3% of smart-phone customers take up 40% of data usage(WSJ) • Smartphones were ~ 15% of device sales in 2009, 41% in 2013 (Telecom Industry Association) • Expected long-term solutions • New Infrastructure Rollout (LTE, WiMAX, Femto) • Tiered servicing models

5. New Problems for Providers/Users • Phones - battery life performance, crowded spectrum • Service providers - Network loads

6. Outline • Introduction • Resource Aware Collaborative Execution (RACE) • RACE Modeling and Policies • Evaluation • Conclusion

7. Resource Aware Collaborative Execution (RACE) • A relay scheme – Phones act as data relay nodes to augment network connectivity

8. Benefits of RACE • Network performance • Improve network coverage • Possibly offload data traffic onto femtocell or non-cellular networks • Energy efficiency • Energy for WiFi is significantly less than 3G/EDGE • Users with heavy usage profiles can leverage resources of less constrained users

9. User-Profile-Driven Management • Bandwidth Sharing/Tethering • Microsoft – COMBINE • UMich- TCP-level Inverse Multiplexing (PRISM) • UCSB/Microsoft - Cool-Tether • What’s new? • User Protection • Dynamic and User-Profile-Driven Decisions

10. Design Issues • User Protection • Helpers reserve resources for their own use • Reject requests if it endangers future activity • In the current work, voice is considered primary phone activity to be protected • Dynamic User-Profile-Driven Decisions • Decision based on state of phone (Battery, Signal Strength, Queue) • User Profile used as input to decision process

11. User Profiles – can people afford to help? • Normalized histogram of 53-day call history for 3 users • User profiles are widely varying • User 3 likely has significant extra energy over time

12. Outline • Introduction • Resource Aware Collaborative Execution (RACE) • RACE Modeling and Policies • Evaluation • Conclusion

13. System Modeling • 1 requester, 2 helpers assumed • System state consists of • Time to recharge – 16 hour discharge time assumed • Battery levels • Signal Strength • Download queue • Actions: Self-serve, request, serve/reject request • Rewards: successful call minutes, downloads, service

14. RACE Decision Policy

15. RACE Formulation • Policy 1 – Altruistic RACE • Central server with global knowledge of all phone states makes collaborative execution decisions • Policy 2 – RACE with helper protection • Helper phones with self protection • Policy 3 - Decentralized Heuristic • Heuristic policy based on “energy-threshold” • Note: 1 requester, 2 helpers assumed

16. Policy 1-Altruistic RACE • Cloud Server determines decision for ALL phones • Objective to maximize the global reward • “Altruistic” : helper phones may sacrifice their protection for greater global performance

17. Policy 2-RACE with Helper Protection • Cloud Server controls requester decisions • Helper phone has its own MDP • Reward for helping, call minutes • Rewards determine protection for call time • Helper MDP calculated on phone

18. Energy Threshold • Predicts energy required to handle all future voice activity with certain probability • Calculated from call history • Can be calculated on phones

19. Heavy Call Profile • Heavy Energy Threshold • Light Call Profile • Light Energy Threshold

20. Policy 3-Energy Threshold Heuristic • Decentralized • Simple Heuristic Policy Requester: • Self-Serve if Energy>threshold Helper: • Serve request if Energy>threshold

21. Outline • Introduction • Resource Aware Collaborative Execution (RACE) • RACE Modeling and Policies • Evaluation • Conclusion

22. Evaluation • Power measurement • Simulations • Real call traces • Controlled data traffic

23. Power Measurement Setup • Power measured through DC power supply, PyVISA Python Package

24. Power Profiling • Power discharge downloading 1MB file EDGE: ~55 J WiFi: ~5.3J • Ad-Hoc WiFi Connection Setup: ~6.5J • For requester, potential reduction in energy of almost 10x for 1MB

25. Energy Transitions Legend ec: call cost (1 min) eoi: WiFi wakeup ef/eg : forwarding/ receiving cost (WiFi) edl: download cost (1MB file)

26. Simulations • Constant download arrival probability pd • Simulate over multiple download arrival probabilities • Constant download size of 1MB • User 1 is requester, user 2 & 3 are helpers • Simulated over 10 days for each phone • Metrics • Average throughput • Downloads served • Average phone lifetime

27. User Profiles • User 1 (requester) has heavy profile: will likely make requests • User 2 (helper) has moderate profile: may or may not accept request • User 3 (helper) has sparse profile: should have extra energy to serve

28. Throughput, Number Served • Throughput higher for any RACE type policy than without • Policy 1 achieves highest throughput • Energy threshold achieves lowest out of RACE • Phone 3 (light user) serves much more than phone 2

29. Phone Lifetime (16 hour max) • Well protected helper: lasts (close to) 16 hrs • Policy 1 helpers: lower lifetimes because of global reward • Helper phones > 920 min for all energy-threshold policies • Tradeoff: Protection and Requester Throughput

30. Conclusion • RACE exploits smart phone technology, user diversity to improve energy efficiency/network connectivity • RACE is dynamic decision process based on energy costs, user profiles, system states • 3 policy types: centralized, helper protected, heuristic • Centralized, helper-protected formed as MDP • Heuristic is decentralized, based on energy threshold concept • Policy trends: • MDP policies favor throughput over helper phone protection • Heuristic protects better with lower throughput to requester

31. Future Work • Network-side improvement • Amount of data offloaded • Study energy/bit reductions • Incentive possibilities • Incentive • Use social networking sites to implement incentive structure • More extensive profiling, thresholding improvements

32. Thanks eajung@ucdavis.edu

33. Cloud Services • Cloud services can be used to mitigate many overhead issues • Locating Peers • BrightKite, Loopt • Service provider-enabled solutions • Incentive • Social Networking Sites/Groups for Participation • Service Provider Tracker/Incentives • Policy Determination • Policies for sharing can be calculated in the cloud server

34. Incentives Service provider oriented Better connectivity/coverage Higher data rate Extend coverage of WiFi/femto cells Social network oriented Car-pool group Social groups Current practice Several Phones already with WiFi hotspot capability