Date post: | 17-Dec-2015 |
Category: |
Documents |
Upload: | charity-doyle |
View: | 216 times |
Download: | 1 times |
Eric Jung, Yichuan Wang, Iuri Prilepov, Frank Maker,
Xin Liu, & Venkatesh AkellaUniversity of California, Davis
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
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