BreadCrumbs:
Forecasting Mobile Connectivity
Anthony Nicholson
and Brian Noble
University of Michigan
Presented by:
Scott Winkleman
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 device’s OS or individual
applications to preserve battery life by waiting
until a later moment to transfer data
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
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
Background: Estimating Client Location
• GPS
• Place Lab
– Wardriving
– Location of AP and GSM
– As described in previous papers
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
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
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:
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)
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
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
Accuracy – Location Prediction
• Compared the
predicted future
location with the
actual destination
• Decent accuracy for k=1, but
degrades
• Thought: state prediction
doesn’t matter as much as
bandwidth prediction
• Binary connectivity =
bandwidth available, even if
the location was incorrectly
guessed
Accuracy – Bandwidth Prediction
• Compared predicted
vs. actual bandwidth
• Within 10 KB/s
over 50% of time
• Within 50 KB/s
over 80% of time
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
Application: Radio Deactivation
• Deactivate radio usage to save power
• Three algorithms:
– Prediction-unaware:
• If no bandwidth
for 30 sec,
sleep for 60 sec
– BreadCrumbs:
• Sleep when no APs
w/in 30 secs
• keep checking
model
– Baseline, always on
available
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.
Overhead
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
Thank you!