User-Profile-Driven Collaborative
Bandwidth Sharing for Mobile Phones
Eric Jung, Yichuan Wang, Iuri Prilepov, Frank Maker,
Xin Liu, & Venkatesh Akella
University of California, Davis
eajung@ucdavis.edu
1
Outline
 Introduction
 Resource Aware Collaborative Execution (RACE)
 RACE Modeling and Policies
 Evaluation
 Conclusion
2
Mobile Apps are Cloud Apps
Social Networking
Synchronization
Location
3
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
4
New Problems for Providers/Users
 Phones - battery life performance, crowded
spectrum
 Service providers - Network loads
5
Outline
 Introduction
 Resource Aware Collaborative Execution
(RACE)
 RACE Modeling and Policies
 Evaluation
 Conclusion
6
Resource Aware Collaborative Execution
(RACE)
 A relay scheme – Phones act as data relay nodes to
augment network connectivity
7
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
8
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
9
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
10
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
11
Outline
 Introduction
 Resource Aware Collaborative Execution (RACE)
 RACE Modeling and Policies
 Evaluation
 Conclusion
12
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
13
RACE Decision Policy
14
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
15
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
16
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
17
Energy Threshold
 Predicts energy required to handle all future voice activity with
certain probability
 Calculated from call history
 Can be calculated on phones
18
Heavy Call Profile
Light Call Profile
Heavy Energy Threshold
Light Energy Threshold
19
Policy 3-Energy Threshold Heuristic
 Decentralized
 Simple Heuristic Policy
Requester:
 Self-Serve if
Energy>threshold
Helper:
 Serve request if
Energy>threshold
20
Outline
 Introduction
 Resource Aware Collaborative Execution (RACE)
 RACE Modeling and Policies
 Evaluation
 Conclusion
21
Evaluation
 Power measurement
 Simulations
 Real call traces
 Controlled data traffic
22
Power Measurement Setup
 Power measured through DC power supply,
PyVISA Python Package
23
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
24
Energy Transitions
Legend
ec: call cost (1 min)
eoi: WiFi wakeup
ef/eg : forwarding/
receiving cost (WiFi)
edl: download cost
(1MB file)
25
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
26
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
27
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
28
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
29
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
30
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
31
eajung@ucdavis.edu
32
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
33
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