1. BreadCrumbs: Forecasting Mobile Connectivity Anthony Nicholson and Brian Noble University of Michigan Presented by: Scott Winkleman

2. Premise Humans are creatures of habit Why not take advantage of this idea to predict the future connectivity of a particular user? BreadCrumbs put this idea into action by tracking your movement and developing connectivity forecasts. This allows your devices OS or individual applications to preserve battery life by waiting until a later moment to transfer data

3. Introduction Current mobile devices run on a wide range of connections, which may be sparse and unreliable BreadCrumbs looks at the derivative of connectivity to predict future available connections Mobility model connectivity forecast GOAL: Defer less time sensitive work if a better connection is available in the near future

4. Background: Determining AP Quality Currently: – Select the AP with the strongest signal Virgil: – Connects to reference servers to determine (for each AP): Downstream bandwidth Whether it blocks certain services Estimated latency – 22-100% increase in detection of AP with usable connection BreadCrumbs: – Adapted Virgil, detects: Downstream bandwidth, upstream bandwidth, estimated latency – Shorten the process and receive more practical information

5. Background: Estimating Client Location GPS Place Lab – Wardriving – Location of AP and GSM – As described in previous papers

6. Predicting Future Mobility Use second-order Markov Model for state locations States include previous and current GPS: GPS locations rounded to the nearest thousandth (= 110x80m in Ann Arbor) Takes readings every τ seconds Hubs Stored Locally

7. Forecasting Future Conditions AP Quality Database needed – Tags all AP quality results to the current location Connectivity Forecast = mobility model + AP quality database – Requires three arguments: Current state in mobility model Integer number of steps in the future Desired network quality (i.e. download, upload, latency) Forecast is the weighted sum of the bandwidth at all potential next states – Calculated recursively if steps > 1

8. Example Expected bandwidth one step in the future is the best observed bandwidth in each state multiplied by the probability of going to that state next. Multiple states is recursive:

9. Scanning Thread Prototype on Linux uses two threads Scanning thread scans for APs – Determines GPS coordinates using Place Labs – Determines quality of each AP – Updates mobility model with new probability based on current state Performed every τ seconds (BC uses 10)

10. Application Interface The second thread acts as the liaison between applications and BreadCrumbs Two criteria are required: – Choice of downstream, upstream, latency – Integer number of seconds in the future Number of seconds (s) is converted to steps: (s-(time left until next scan))/τ Ex: Requested 25 sec in future at t=9… (25-(10-9))/10 = 24/10 = 2.4 3 steps

11. Methodology Tested for two weeks every 10 seconds during the day – week 1: training, week 2: testing Used detected APs and Place Lab database to determine location and calculated quality for new APs Results: – Only 17% APs were open (non-zero downstream) – But 55% of locations had a usable AP

12. Accuracy – Location Prediction Compared the predicted future location with the actual destination Decent accuracy for k=1, but degrades Thought: state prediction doesnt matter as much as bandwidth prediction Binary connectivity = bandwidth available, even if the location was incorrectly guessed

13. Accuracy – Bandwidth Prediction Compared predicted vs. actual bandwidth Within 10 KB/s over 50% of time Within 50 KB/s over 80% of time

14. Application: Opportunistic Writeback Content uploaded from device to server – Ex: photos to flickr Determine the best current upstream bandwidth Predict 10, 20, 30 seconds in future Wait if future is better Radio active 45% less often

15. Application: Radio Deactivation Deactivate radio usage to save power Three algorithms: – Prediction-unaware: If no bandwidth available for 30 sec, sleep for 60 sec – BreadCrumbs: Sleep when no APs w/in 30 secs keep checking model – Baseline, always on

16. Application: Phone data network vs. WiFi Offload data transfer from EDGE/3G to Wi-Fi Two algorithms: – Prediction-unaware: Use Wi-Fi when downstream > EDGE – BreadCrumbs: Use EDGE when Wi-Fi downstream < EDGE during next 30 secs.

17. Overhead

18. Criticism / Future Work Localization / GPS energy & efficiency Unencrypted, open AP availability? Longer training period better results? – AP expiration? Uses best bandwidth in 80x110m area Time of day/week Ease to add into current applications

19. Thank you!