eric jung, yichuan wang, iuri prilepov, frank maker, xin liu, & venkatesh akella university of...

Eric Jung, Yichuan Wang, Iuri Prilepov, Frank Maker,

Xin Liu, & Venkatesh AkellaUniversity of California, Davis

eajung@ucdavis.edu

User-Profile-Driven Collaborative Bandwidth Sharing for Mobile Phones

1

OutlineIntroductionResource Aware Collaborative Execution

(RACE)RACE Modeling and PoliciesEvaluationConclusion

2

Mobile Apps are Cloud Apps

3

Social Networking

Location

Synchronization

Network OverloadingSmartphones have changed the game for

providersMobile 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 solutionsNew Infrastructure Rollout (LTE, WiMAX, Femto)Tiered servicing models 4

New Problems for Providers/UsersPhones - battery life performance,

crowded spectrumService providers - Network loads

5

OutlineIntroductionResource Aware Collaborative

Execution (RACE)RACE Modeling and PoliciesEvaluationConclusion

6

Resource Aware Collaborative Execution (RACE)A relay scheme – Phones act as data relay

nodes to augment network connectivity

7

Benefits of RACENetwork performance

Improve network coverage Possibly offload data traffic onto femtocell or

non-cellular networks

Energy efficiencyEnergy for WiFi is significantly less than

3G/EDGEUsers with heavy usage profiles can leverage

resources of less constrained users

8

User-Profile-Driven ManagementBandwidth Sharing/Tethering

Microsoft – COMBINE UMich- TCP-level Inverse Multiplexing

(PRISM)UCSB/Microsoft - Cool-Tether

What’s new?User ProtectionDynamic and User-Profile-Driven Decisions

9

Design IssuesUser Protection

Helpers reserve resources for their own useReject requests if it endangers future activityIn the current work, voice is considered

primary phone activity to be protected

Dynamic User-Profile-Driven DecisionsDecision 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 varyingUser 3 likely has significant extra energy over time

11

OutlineIntroductionResource Aware Collaborative Execution

(RACE)RACE Modeling and PoliciesEvaluationConclusion

12

System Modeling1 requester, 2 helpers assumedSystem state consists of

Time to recharge – 16 hour discharge time assumedBattery levelsSignal StrengthDownload queue

Actions: Self-serve, request, serve/reject request

Rewards: successful call minutes, downloads, service

13

RACE Decision Policy

14

RACE FormulationPolicy 1 – Altruistic RACE

Central server with global knowledge of all phone states makes collaborative execution decisions

Policy 2 – RACE with helper protectionHelper phones with self protection

Policy 3 - Decentralized HeuristicHeuristic 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

17

Cloud Server controls requester decisions

Helper phone has its own MDP Reward for helping,

call minutesRewards determine

protection for call time

Helper MDP calculated on phone

Energy ThresholdPredicts energy required to handle all future voice

activity with certain probabilityCalculated from call historyCan be calculated on phones

18

19

Heavy Energy Threshold

Light Call Profile Light Energy Threshold

Heavy Call Profile

Policy 3-Energy Threshold Heuristic

20

DecentralizedSimple Heuristic

PolicyRequester: Self-Serve if

Energy>threshold

Helper:Serve request if

Energy>threshold

OutlineIntroductionResource Aware Collaborative Execution

(RACE)RACE Modeling and PoliciesEvaluationConclusion

21

EvaluationPower measurementSimulations

Real call tracesControlled data traffic

22

Power Measurement SetupPower measured through DC power

supply, PyVISA Python Package

23

Power ProfilingPower discharge downloading 1MB file

24

EDGE: ~55 J WiFi: ~5.3J

Ad-Hoc WiFi Connection Setup: ~6.5JFor requester, potential reduction in energy of almost

10x for 1MB

Energy Transitions

25

Legendec: call cost (1 min)eoi: WiFi wakeupef/eg : forwarding/

receiving cost (WiFi)

edl: download cost (1MB file)

SimulationsConstant download arrival probability pd

Simulate over multiple download arrival probabilities

Constant download size of 1MBUser 1 is requester, user 2 & 3 are helpersSimulated over 10 days for each phoneMetrics

Average throughputDownloads servedAverage 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 ServedThroughput 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 hrsPolicy 1 helpers: lower lifetimes because of global

rewardHelper phones > 920 min for all energy-threshold

policiesTradeoff: Protection and Requester Throughput

29

ConclusionRACE exploits smart phone technology, user diversity to

improve energy efficiency/network connectivityRACE is dynamic decision process based on energy

costs, user profiles, system states3 policy types: centralized, helper protected, heuristic

Centralized, helper-protected formed as MDPHeuristic is decentralized, based on energy threshold concept

Policy trends:MDP policies favor throughput over helper phone protectionHeuristic protects better with lower throughput to requester

30

Future WorkNetwork-side improvement

Amount of data offloadedStudy energy/bit reductionsIncentive possibilities

IncentiveUse social networking sites to implement incentive

structure

More extensive profiling, thresholding improvements

31

eajung@ucdavis.edu

32

Cloud ServicesCloud services can be used to mitigate

many overhead issuesLocating 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

server33

IncentivesService provider oriented

Better connectivity/coverageHigher data rateExtend coverage of WiFi/femto cells

Social network orientedCar-pool groupSocial groups

Current practiceSeveral Phones already with WiFi hotspot capability