BreadCrumbs:ForecastingMobileConnectivityAnthonyJ.NicholsonDepartmento - PDF document

BreadCrumbs:ForecastingMobileConnectivityAnthonyJ.NicholsonDepartmentofElectricalEngineeringandComputerScienceUniversityofMichigantonynich@umich.eduBrianD.NobleDepartmentofElectricalEngineeringandComputerScienceUniversityofMichiganbnoble@umich.eduABSTRACTMobiledevicescannotrelyonasinglemanagednetwork,butmustexploitawidevarietyofconnectivityoptionsastheytravel.Wearguethatsuchsystemsmustconsidertheofconnectivity„thechangesinherentinmovementbe- Thisworkmakesthefollowingcontributions:Weintroducetheconceptofconnectivityforecastsmobiledevices.Wedemonstratethatsuchforecastscanbeaccurateoverregular,day-to-dayuse,withoutrequiringGPShardwareorextensivecentralizedinfrastructure.Weillustratethepotentialbene“tsofthesystemthroughthreeexampleapplications.2.BACKGROUND2.1DeterminingAPQualityThereislittlepointtodevelopingacomplexsystemforforecastingthequalityandavailabilityofpublicwirelesscon-nectionsiftheyarefewandfarbetween,orallaccesspointshaveequivalentconnectionquality.Weexploredthecur-rentstateofaairsinourpriorwork[21],whichdescribedVirgil„anAPselectiontoolthatconsiderstheapplication-visiblequalityofaccesspoints.Incontemporaryoperatingsystems,wirelessconnectionmanagerstypicallyselecttheunencryptedAPwiththestrongestreceivedsignalstrength.Ratherthanconsidersuchlink-layercriteria,VirgilquicklyassociateswitheachcandidateAPandrunsabatteryoftestsdesignedtoestimatetheconnectionqualityapplica-tionswouldenjoyifthedeviceweretochoosethisaccesspoint.Virgilconnectstoreferenceserversinordertoestimatethisconnectionquality.Areferenceserverisawell-knownInternetdestinationthatrunsasimpleTCPserverprocess.Likeahoneypot,thisprocesslistensonawiderangeofTCPportnumbers.Toprobetheapplication-visiblequalityofanaccesspoint,VirgilconnectstoareferenceserverviatheAPandrunsthefollowingtests:EstimatedownstreambandwidthbyconnectingtotheTCPserverprocessonawell-knownportanddown-loadingrandomdataasfastaspossible.DetermineiftheAPisblockingcertainservicesbyat-temptingaTCPconnectiontocommonportnumbers.Estimatelatencybypingingthereferenceserver.WecomparedthesuccessofselectingAPsbasedonsignalstrengthwithselectingtheAPwiththebestdownstreambandwidthprobedbyVirgil,in“veneighborhoodsofvarieddensityinthreedierentcitiesintheUnitedStates.UseofVirgilresultedina22…100%increaseinthepercentageofscansthatsuccessfullyfoundanaccesspointwithausableInternetconnection.Muchinthesameway,BreadCrumbsusesareferenceservertoestimatetheconnectionqualityoftheaccesspointsencounteredbymobiledevices.Inadditiontodownstreambandwidth,BreadCrumbsalsoestimatesupstreamband-widthviatheAP.Ratherthansimplypingingtherefer-enceserver,weestimatelatencybyopeningaTCPconnec-tionandping-pongingaintegernoncebackandforth.Thiswasanattempttomorecloselymimichowrealapplicationswouldutilizeanetworkconnection.Finally,BreadCrumbsomitstheportstatustestsinordershortenthetestingpro-cess.Insummary,BreadCrumbsusesthetechniquesde-scribedabovetoestimatethefollowingthreevaluesforeachopenaccesspointthemobiledeviceencounters:(1)down-streamTCPbandwidthfromanInternethost,(2)upstreamTCPbandwidthtotheInternet,and,(3)latencyfromthedevicetoremotedestinations.2.2EstimatingClientLocationInorderforadevicetopredictitsfuturemobility,itneedssomewaytodetermineitslocation.Thislocationcouldbedescriptive(attheUnionŽ),relativetoknownlocations,orabsolute.Inourcase,BreadCrumbsuseslatitudeandlongitudecoordinatesasthebasicbuildingblocksofeachdevicesmobilitymodel.Typically,thiscanbeprovidedbyGPS.EvenfordeviceswithoutGPStechnology,itispos-sibletoestimateonespositionwithreasonableaccuracy,usingtechnologieslikePlaceLab[16].Thisprojectexploitsthefactthataplethoraof“xed-positionbeaconsexistintheeverydayenvironment„namely,WiFiaccesspointsandGSMmobilephonetowers.Anicebene“tofPlaceLabisthatitworkswellwhenGPSdoesnot„indoorsandinurbancanyons.PlaceLabreliesonpublicwardrivingdatabases,whichmapbeaconMACaddressestoGPSlocations.Forexam-currentlytracksover11milliondistinctac-cesspointsinitsdatabase.PlaceLabgeneratesaGPS“xby“rstscanningforallbeaconsinthedevicesvicinity,thentri-angulatingbasedontheGPSlocationofeachbeaconsource.Theirevaluationresults(in2005)foundthemeanaccuracyofPlaceLabslocationestimatestobeontheorderof20-30metersfromtheGPSgroundtruthŽwhenonlyWiFibeaconsourceswereutilized.Asweshallsee,sucherrorisacceptableforourneeds.3.CONNECTIVITYFORECASTINGByleveragingVirgilandeitherPlaceLaborGPSdata,onecandetermineboththelocationsauserhaspreviouslyvisitedandtheapplication-levelqualityofnetworkconnec-tivityatthoselocations.OurgoalistocombinethesetwosetsofdatatoyieldwhatwewillcallconnectivityforecastsAconnectivityforecastisanestimateofthequalityofagivenfacetofnetworkconnectivityatsomefuturetime.Anexamplewouldbetheestimatedupstreambandwidthfromtheclienttoaremotehost20secondsinthefuture.Thisisafunctionbothoftheusersmobility„whichAPswillbeinrangeatthattime„andofthequalityoftheseAPsnetworkconnections.Awidevarietyofapplicationscanexploitsuchforecasts.Forexample,consideradistributed“lesystemclientthatneedstore-integratesomedatatoaremote“leserver.Ifenergyconsumptionisa“rst-classconcern„asitisforhand-helddevices„thebestpolicyfortheclientwouldbetotrans-mitdatatothe“leserverwhenthemobiledevicehasthehighest-bandwidthnetworkconnectionthatitwillenjoyinthenearfuture.Thissection“rstdiscusseshowBreadCrumbsmaintainsapersonalizeddevicemobilitymodel,basedonthepastse-quenceofGPSlocationstheuservisits.Next,wedescribehowBreadCrumbsappliestheprinciplesofVirgil[21]toes-timatethequalityofdierentaccesspoints,andcombinesthisdatawiththepredictionsofthemobilitymodel.Thesectionconcludeswithaconcreteexampleofhowconnec-tivityforecastsaregenerated. State LastGPS CurrentGPS — (80.276,-80.747) (80.277,-80.746) (80.277,-80.746) (80.277,-80.745) Figure1:Generatingstatesfrommobilityhistory.Eachstateinthesecond-orderMarkovmodelencodesthecur-rentGPSlocationandthepreviouslocation.GPS“xesareestimatedatasetperiodthatisthetimeintervalbetweenstatetransitionsinthemodel.3.1PredictingFutureMobilityMobilitypredictionisawell-studiedarea,particularlyinthedomainofmobilephonenetworks.Themajorityofap-plicationsofsuchtechniquesfocusonallowingacentralau-thoritytotrackthemovementofdevicestopre-provisionnetworkresources[1,2,4,17,22,25,29].AsdidPlaceLab,wenotethattrackingmobilityhistoryatacentralpointisproblematic.Whensuchdatabasesarecompromised„eitheraccidentally,maliciously,orundersubpoena„thepre-cisemovementsofusersaredisclosedwithoutconsent.Fur-thermore,mobiledevicesmayneedthisinformationthemostatpreciselythetimeswhentheyaredisconnectedfromthenetworkandcannotquerythecentralizedserver.Syntheticmobilitymodels[27]oraggregatemodelsde-rivedfromthemovementsofmanyusers[14,28]areusefulwhenanetworkproviderneedsthebigpictureofhowtheirnetworkwillbeutilized.However,suchmodelshavelittlechanceofaccuratelycapturingtheveryuniquepathsoneusertakesthroughtheirenvironment.Themostcompellingreasontomaintainthemodelonthedeviceitselfisthat,unlikeforamobilephonenetwork,thereexistsnoonecentralizedauthoritywhocontrolsallpublicWiFiAPsthattheuserencounters.Thislimitsourchoiceofmobilitymodelstothosethatcanreasonablybemain-tainedonresource-constrained,handhelddevices.Songetal[26]previouslyevaluatedtheaccuracyofseveralcommonmobilitypredictionmodels,usingmobilitydatacollectedonthecampusofDartmouthCollegeduringthe2003-2004aca-demicyear[15].ThisdatasettrackstheAPassociationhis-toryofover7000userstoover550WiFiaccesspointsofknownlocation.Theirevaluationfoundasecond-orderMarkovmodel,withfallbacktoa“rst-ordermodelwhenthesecond-ordermodelhasnoprediction,wasthemostaccurateofalltechniquesexamined.Conveniently,Markovmodelsareidealforuseonresourceconstraineddevices.TheirCPUneedsarelowbecausemodelqueryingandmaintenanceinvolvesmerelyreadingandwritingindividualentriesinarrays.Sincethesearraysaregenerallysparse,storagerequirementsaremod-Wechosegeographiclongitudeandlatitudecoordinatesasthefundamentalbuildingblockofourmodel.Sincewehavechosenasecond-orderMarkovmodel,eachstateconsistsoftwosetsofcoordinates:thelocationwherethedevicewasduringthelaststate,anditscurrentlocation.Trackingthissecond-orderstateisusefulfordistinguishingbetweendierentmobilitypathsthatshareacommonpoint.Forexample,thiscandisambiguatebetweentheuserwalkingeastboundandwestboundonthesamestreet.Theresolutionofourmodelisboundedbothbytheac-curacyoflocationsensingandtheresourceconstraintsofmobiledevices.Toavoidastatespaceexplosion,Bread-CrumbsroundsallGPSvaluestothreedecimalplaces„oneone-thousandthofadegree.WhilethesizeofonedegreeoflatitudeisconstanteverywhereontheEarth,thedistancebetweentwodegreesoflongitudeshrinksasonemovesfur-therawayfromtheequator.Atourlatitude,a0.001gridsquareis110m80m.Whileahigherdegreeoflocationprecisionthan110meterswouldseemdesirable,thiswasimpracticalfortworeasons.First,locationestimatesinherentlyhavesomeam-ountoferrorfromthegroundtruthŽ.Aswenoteabove,BreadCrumbsreliesonPlaceLab[7]toestimateGPSloca-tionfromobservedWiFibeacons.TheauthorsofPlaceLabfoundanaverageerrorof20or30metersfortheirtech-nique,ascomparedtoGPS.Second,evenifaGPSantennaisavailableonamobiledevice,wemustbemindfulofthestate-spaceexplosionintheMarkovmodelthatwouldoccurifasmallgridsizewerechosen.BreadCrumbsisintendedforsmalldeviceswithlimitedstorage,CPUandbatterypower,allofwhichwouldbetaxedifmaintainingalargemobilitymodel.ThefrequencywithwhichBreadCrumbsestimatesthede-vicesGPSlocationboundstheresolutionofthemobilitymodel.Thismodelcanbethoughtofasadiscrete-timeMarkovchainwhereastatetransition“reseveryonds.Figure1illustrateshowthemodelgenerationprocessworks.The“rststateisstate1.ThisisaspecialstatewithnoLastGPSŽcomponent,justtheinitiallocation.Then,secondslaterBreadCrumbs“xesthedeviceslocationat747),andcreatesthenewstate2.Theremain-ingstatesintheexamplearegeneratedinasimilarfashion.Foreachstateinthemodel,BreadCrumbsupdatestheMarkovtransitionmatrixwheneverthemodelisinthestateandtransitionstoanother.Thesetransitionsoccureveryseconds.Notethatiftheuserremainsatonelocationforlongperiods,themodelwillhaveaheavytransitionproba-bilitytowardstheself-loop(backtothesamestate)atthatlocation.ThisisaneasywayforBreadCrumbstoidentifywhatothershavetermed[10]„popular,long-termdes-3.2ForecastingFutureConditionsSection2.1abovedescribedourpriorworkondetermin-ingtheapplication-visiblequalityofWiFiaccesspoints.WeusesimilartechniquesheretobuildanAPqualitydatabase.ThepurposeofmaintainingthisdatabaseistoestimatethequalityŽofaconnectiontotheInternet,forallthedier-entaccesspointsamobiledeviceencounters.AswithVir- foreachAPspreviouslyseenatstateap.bandwidth�bestap.bandwidth(a)Bestbandwidthalgorithm,int,steps(b)ConnectivityforecastalgorithmFigure2:Pseudocode:bestbandwidthatastateandconnectivityforecasts.Thebestbandwidthalgorithmhasbeensimpli“edtoassumeBreadCrumbstracksonetypeofbandwidth,wheninfactitdierentiatesbetweenupstreamanddownstreamconnectivity.gil,whenBreadCrumbs“rstencountersanunencryptedAP,itattemptstoassociateandobtainanIPaddressthroughDHCP.Ifsuccessful,BreadCrumbsthenopensthreeTCPconnectionstoaremotereferenceserver,toestimate(1)downstreambandwidth,(2)upstreambandwidth,and(3)latencytoremoteInternethosts.BuildinganAPqualitydatabasefromscratchisadmit-tedlytaxingonmobiledevices,giventheirlimitedbatterylife.Inourpriorwork[21],wediscusshowcachingresultsinalocaldatabasehidesthisexpenseafteraninitialtrainingperiod.Aspartoffuturework,wehopetodeployBread-CrumbsontheCOPSEmobiledevicetestbedtoinvestigatehowsharingofthesedatabasesamongco-locateduserscanreducethisscanningoverheadfurther.IfBreadCrumbswerebroadlydeployedandallusersre-liedonthesamereferenceserver,thesystemwouldclearlynotscalewell.However,dierentusersarefreetouseref-erenceserversoftheirownchoosing.BreadCrumbsisnotattemptingtoquantifythequalityofconnectiontoaspeci“cendhostbutrathertothemorefuzzynotionofanarbitraryInternetdestination.Itistruethatonereferenceservercannotpossiblyrep-resentthemyriadnetworkdestinationsthatapplicationsmightcontact.Butnotethatthe“rsthops„thewirelessAPanditsbackendconnection,e.g.aDSLorcablemodem„areconstantnomatterwhattheremotedestinationofaconnectionultimatelyis.Fromthere,thepaththroughthenetworkcoredependsonthepeeringagreementsbetweentheAPsISPandthatofthedestination.WearguethatwhenchoosingbetweentwoAPs,itisfarmorelikelythattheoverallqualityofanend-to-endlinkdependsonedgeef-fectsratherthancoreroutingissues.Thisclaimisvalidatedbyarecentmeasurementstudy[8]thatfoundresidentialbroadbandlinksareoverwhelminglythebottleneckinend-to-endInternetpaths.Asubtlepointisthatoneaccesspointmaybevisiblefrommultiplegridlocations,sinceourchosengridsize(0.001)isonly110m80matourlatitude.ThequalityofanAPmayvaryatdierentgridlocations,however,because ofvaryingdistancesfromtheAP,physicalinterference,etcetera.BreadCrumbsthereforetagsallAPtestresultswiththeGPScoordinatesatwhichtheyweretaken.MultipletestresultsforasingleAPco-existinthequalitydatabaseiftheywereprobedatdierentGPSgridlocations.ThetestdatabasetracksaccesspointsbothbyESSIDandbyMACaddress.Thisiscrucialtodierentiatebe-tweenAPssharingthesameESSID,eitherintentionallyaspartofacoordinateddeploymentorunintentionallybecausethedefaultESSID(e.g.linksys,netgear)hasnotbeenchanged.Thistestprocessincursareasonablebutnon-trivialover-headintermsoftimeandenergy.BreadCrumbsthereforecachestestresultsforperformance.Whenanaccesspointisdetected,BreadCrumbschecksifatestresultsexistsinthedatabaseforthatAPattheGPSgridlocationcontainingtheuserscurrentposition,anddoesnotretesttheAPifoneexists.Inordertoagestaletestresultsoutofthedatabase,however,BreadCrumbsretestssuchpreviously-probedAPsprobabilisticallyasmallfractionofthetime.BreadCrumbscombinesthecustomusermobilitymodelandtheAPqualitydatabasetoprovideconnectivityfore-casts.Figure2describesasimpli“edversionofthisalgo-rithm.Thisexampletakestwoarguments:astateinthemobilitymodel,andanintegernumberofstepsinthefu-ture.InouractualimplementationofBreadCrumbs,theal-gorithmalsoconsiderswhatnetworkqualityistobeforecast(downstream/upstreambandwidth,orlatency).Tosimplifythepseudocodeweassumethealgorithmonlyconsidersonenetworkqualitymetric,bandwidthFirst,considerthelimitingcasewhereisone.Thisisarequestfortheprojectednetworkbandwidthonetransitionpastthespeci“edstate.Inotherwords,forthemodeltran-sitionperiod,onestepissecondsinthefuture.Bread-Crumbscalculatesthisforecastastheweightedsum,acrossallstatesinthemodel,ofthebestbandwidthpreviouslyseenfromanAPatthatpotentialnextstate.Thissumisweightedbythetransitionprobabilitythatmodelwilltran-sitionfromstatetoastate.Thus,thebestbandwidthseenatstateswhicharelikelysuccessorsofthestatecon-tributesmoretotheconnectivityforecastthantransitionswhichareunlikely.Inpractice,thenumberofsuccessorstatesfromanygivenstatewillbesmallascomparedtothewholestatespace,becausestatesaregroundedingeographicreality.isgreaterthanone,connectivityforecastsarecal-culatedrecursively.Ateachstepuptherecursiontree,re-sultsfromleafnodesareweighted-summedinproportiontothetransitionprobabilities.3.3ExampleConsidertheMarkovchaininFigure3.Thevaluebeloweachstatesnameisthebestdownstreambandwidthprobedwhileatthatstate„forastate,thisis.Thecurrentstateis.Wewanttoknowtheexpecteddown-streambandwidthatthenexttimestep.FromFigure2(b)above,thisyields:1)=)(1)Inotherwords,theexpecteddownstreamnetworkband-widthonestepinthefutureisthesum(overallstatesintheMarkovchain)ofthebestbandwidthobservedateach Figure3:ExampleMarkovmodelwithbest-bandwidthstate,weightedbytheprobabilitythattheMarkovchainwilltransitionfromthecurrentstatetoeachgivenstate.Whencalculatingaconnectivityforecast,weneednotactuallysumacrossallthestatesintheMarkovchain,butonlyacrossthosewithanon-zerotransitionprobability.Re-turningtoourexample,weseefromFigure3thattheonlypossibletransitionsoutofstatearetostatesandaself-loopbackto.Therefore,Equation1aboveissimpli“edto:1)=91+007+0=52KB/sForinstance,ifthetimestepofthemodelwastenseconds,thenthiswouldbetheestimateddownstreamnetworkband-widthavailabletothedevicetensecondsfromthecurrenttime.Tocalculateconnectivityforecastsfurtherintothefuture,theconnectivityforecastalgorithmcallsitselfrecur-sivelyasshowninFigure2(b).Thedownstreambandwidth20secondsahead(twosteps)isthereforethefollowing:2)=1)+1)+4.IMPLEMENTATIONWehaveimplementedaBreadCrumbsprototypeonLinux,asauser-levelprivilegedprocess.Thisprocessconsistsoftwothreads,eachofwhichisdescribedinasubsectionbe-low.4.1ScanningThreadOnethreadperiodicallyscansforaccesspointsand“xesthedevicesGPScoordinatesbytriangulatingontheloca-tionsofAPbeaconsinthePlaceLabdatabase.Thisscan-ningperiodisacon“gurableparameter(),setto10sec-ondsinourcurrentimplementation.ThescanningthreadalsohandlestheprobingofAPconnectionquality,asde-scribedinSection2.1,wheneveranopenAPisencounteredthathasnotbeenprobedatthecurrentGPSgridlocation.Testresultsarethenstoredinalocaldatabase.After“xingitscurrentGPSlocationeveryseconds,thisthreadthenupdatestheMarkovmodel.Thisconsistsofup-datingthetransitionprobabilityfromthepreviousstatetothenewcurrentstate(becauseofthenewlocationestimate).ThereferenceserverusedtoestimateAPconnectionqual-itywaslocatedonouruniversitycampus,connecteddirectlytotheInternetonthewireddepartmentalnetworkwithno“rewall.Giventhatoursubsequentevaluationtookplaceinthesamecity,onemightbeskepticalthatconnectingtothisserverfromdierentwirelessaccesspointsinthesamecitywouldtrulyapproximatetheaveragelatencyandbandwidthonewouldencounterwhenconnectingtoarbi-traryremotedestinations.ThepeeringpointsbetweentheuniversitysISPandthecommonISPsseenaroundtown„overwhelmingly,ComcastandAT&T„arenotlocatedinthecity,however.Infact,forasubsetoflocationsweper-formedatothereferenceserver,andinallcasestheshortestpathfromthewirelessAPtothedepartmentalnetworkdetouredseveralhundredkilometersaway,intotheInternetcore,beforereturningtoourcity.Wearethere-forecon“dentthatthiscon“gurationreasonablyapproxi-matesthelatencyandbandwidthonewouldencounterwhencontactingtypicalInternetdestinationsthatrequireatripthroughthenetworkcore.4.2ApplicationInterfaceTheotherthreadhandlesapplicationrequestsforconnec-tivityforecasts.ApplicationssendrequeststoBreadCrumbsviaanamedpipe.Theserequestsconsistoftwovalues:(1)thecriterionofinterest„downstreambandwidth,upstreambandwidth,orlatency„and(2)anintegernumberofsec-ondsinthefuture.BreadCrumbsconvertsthevalueinsecondsintothenum-berofcorrespondingstatetransitionsinthefutureofthemodel.Thisdependsbothonthescanningperiodthenumberofsecondsleftuntilthestartofthenextscan,becausethemobilitymodelisadiscretetimeMarkovchainwhereastatetransition“reseveryFirst,BreadCrumbssubtractsthetimeleftuntilthestartofthenextscanfromthevaluepassedbytheapplication.Then,itperformsintegerdivisionoftheremainingtimeby.Theresultisthenumberofstepsinthefutureofthemodelatwhichtogenerateaconnectivityforecast.Forexample,assumethatBreadCrumbsscansforAPsandupdatesthemobilitymodelevery10seconds(asinourimplementation),startingat=0.At=9,anapplicationqueriesfortheforecasteddownstreambandwidth25secondsinthefuture(at=36).Thisis=3stepsinthefuture.BreadCrumbsthengeneratestheconnectivityforecastatthatpointinthefuture,forthegivencriterion,andreturnsthevaluetothecallingapplicationthroughthenamedpipe.5.SAMPLEAPPLICATIONSInevaluatingtheusefulnessofBreadCrumbs,wedesignedseveralsimpleapplicationsthatonemightcommonly“ndonmobiledevices.WethenexaminedhowwellBreadCrumbscanimprovetheuserexperiencefortheseapplications,ascomparedthebesteortonecouldmakewithoutanycon-nectivityforecastinformation.Theerrorbarsinallsubsequent“guresinthissectionrepresentthestandarderrorofthemean: n. Figure4:Visitedgridlocationsandcommutetruth.SmallsquaresareallGPSgridlocations“xesfromtwoweeksofusermobilitytracescollected.TheblacklineisthegroundtruthŽpaththroughthemaptakenbytheuseronhisdailycommutebetweenhomeandwork.5.1MethodologyRatherthanrelyonexistingmobilitytracesorsyntheticmodels,weinstalledBreadCrumbsonaniPAQh5555hand-held,withanintegrated802.11bWiFicard,runningFamil-iarLinux(adistributiontargetedforhandhelddevices[12]).Oneoftheauthorscarriedthehandheldwithhimcontin-uouslyfortwoweeksduringdaytimehours(beforesevenClearly,mostusersarerelativelystationaryforlargepor-tionsoftheirday„sittingattheirdesksatwork,ormovingaroundtheirhome.Predictingconnectivityinsuchsitu-ationsistrivial.WeweremoreconcernedwithhowwellBreadCrumbspredictsthederivativeofconnectivitywhenusersareinmotion.Wethereforeeditedthecollectedlogsbyhandtoremoveportionsoftimewhentheuserwassta-tionaryformorethan“veminutes.BreadCrumbsrancontinuouslyinthebackground,scan-ningfornewaccesspointseverytenseconds.Aftereachscan,BreadCrumbsestimatedthedevicescurrentGPSco-ordinatesbycross-referencingtheMACaddressesofde-tectedAPswiththePlaceLabdatabase(asdescribedinSection2.2).TheGPScoordinatesandMACaddresseswerethenlogged,alongwithatimestamp.ForeachAPinthescansetthathadnotbeenpreviouslyprobedatthosecoor-dinates,BreadCrumbsattemptedtoassociateandprobeAPqualityasdescribedinSection2.1.Theproberesults(up-streambandwidth,downstreambandwidth,latency)werethenappendedtoatestresultsdatabase.RecallfromSection3.1thatBreadCrumbsdividestheworldintogridlocations,whereeachgridboxis0.001latitudeby0.001oflongitude.Atourlatitude,thisis11080m.AllGPS“xesthatfallwithinthesameboxareconsideredtobethesameposition.ThesmallsquaresinFigure4arealltheuniquegridlocationsvisitedduringthetwoweeksofusertraces.Thesolidblacklinerepresentsgroundtruthpathoftheusersdailycommutebetweenhomeandwork.Thistripisamixofwalkingandbusrid-ing,andisresponsibleforthevastmajorityofmotionduring min APsperscan 7.73 32 uniqueAPs openAPs 282(17.40%) encryptedAPs 1339(82.60%) gridlocationsvisited locationswithusableAP 61(55.45%) Table1:Accesspointstatistics.LocationswithusableAParethosegridlocationswhereatleastoneaccesspointhadaprobeddownstreambandwidthgreaterthanzero. min downBW 114.41 385.54 0.00 110 downnon-zero 129.74 385.54 0.29 61 upBW 49.85 241.66 0.00 110 upnon-zero 52.44 241.66 4.10 58 Table2:Bandwidthatgridlocations.ValuesinKB/s.AccordingtoPlaceLabestimates,duringtheevalua-tionperiodthemobiledevicevisited110uniquegridlocations(0.001latitudeby0.001Non-zeroreferstoomittingthoselocationswherenoencounteredAPhadaprobedbandwidthgreaterthanzero.thetwoweekperiod.Thespreadofvisitedgridlocationsisnotstrictlylimitedtothecommutepath,however.ThisisaresultbothofPlaceLabGPSerrorandnoiseintroducedbyother,non-commutingtrips.Forexample,thetracesetincludesinstancesoftheuserwalkingfromhometovari-ousdowntowndestinations,anddrivingtoseveraldierentlocations.Tables1and2summarizethefrequencyandqualityofnetworkconnectivitythatBreadCrumbsencountereddur-ingthecourseofourevaluation.AsTable1shows,Bread-Crumbssawawidely-varyingnumberofAPseachtimeitscanned.Whileonly17%ofallaccesspointsencounteredwereunencrypted,BreadCrumbswasabletodiscoveraus-ableAPatoverhalfofallvisitedgridlocations.Wede“netomeanthereexistedanAPatthatlocationwhoseprobeddownstreambandwidthwasgreaterthanzero.AsTable2shows,wefoundthatthequalityofpublicly-availableaccesspointsvariessigni“cantly.Foreachofthe110gridlocationsvisitedduringthetwoweeksoftracecol-lection,wecalculatedthebestupstreamanddownstreambandwidthavailable.EvenwhenthoselocationswherenoAPhadanon-zerobandwidthareomitted,thevarianceisquitelarge.Thisbolstersourclaimthatnetworkconnectiv-ity”uctuatessigni“cantlyasusersmovearoundtheworld.5.2ForecastAccuracyWe“rstwantedtoquantifyhowaccurateconnectivityforecastsare,giventhetwoweeksoftraceswecollected.Asareminder,BreadCrumbsestimatesitsGPScoordinatesata“xedfrequency.Forourevaluationwesetthisperiodtotenseconds.Thus,thetracesareaseriesofscansets„listingallAPbeaconsdetected,pluscurrentGPScoordinatesandatimestamp„separatedbytensecondsofrealtime.Weusedthe“rstweekoftracesasthetrainingsetthatbuiltBreadCrumbsmobilitymodel.Thesecondweekoftraceswasthentheevaluationset.Foreachstep(scanset)intheevaluationsetoftraces,wecomparedthegridlocationwhereBreadCrumbspredictedthedevicewouldbeinthenextstepwithwhereitactuallydidmove.Werepeatedthis, 0 20 40 60 80 100 % steps in trace k=1 k=2 k=3 k=4 k=5 k=6 binary connectivity accurate Figure5:Mobilitymodelpredictionaccuracy.catesthenumberofstepsintothefutureBreadCrumbsvaryingthenumberofstepsBreadCrumbslookedahead(fromonethroughsix.ThewhitebarsinFigure5indicatethepercentageofstepsacrossalltwoweeksoftraceswhereBreadCrumbspredictedgridlocationwascorrect,for16.Theaccuracyisover70%for=1butquicklydegradesasBreadCrumbsmustextrapolatefurtherintotheThecrucialinsight,however,isthatwearenotreallyconcernedwithpredictingtheusersmobilityperfectly.IfBreadCrumbspredictstheuserwillmovetoonelocation,andtheyinfactmovetoanother,aslongasthequalityofnetworkconnectivityavailableatthetwolocationsiscom-parablethismistakeŽisunimportant.ThegraybarsinFig-ure5representthepercentageofstepswhereBreadCrumbspredictionandtheactualnextlocationmatchedwithregardtobinaryconnectivity.Agivenlocationisconsideredcon-nectedifatleastoneAPseenatthatlocationhadaprobeddownstreambandwidthgreaterthanzero.BreadCrumbswasover90%accurateinpredictingbinaryconnectivityonestepahead.Thisaccuracyremainedhighwhenlookingfur-therintothefuture„nearly80%accuratesixstepsahead.Next,weexaminedhowthebandwidthpredictedbycon-nectivityforecastsmatchedthebandwidthactuallyencoun-tered.Figure6chartsthegapbetweenpredictedandactualbandwidthasacumulativedistributionfunction(CDF).Evensixstepsinthefuture,BreadCrumbsbandwidthforecastswerewithin10KB/softheactualvalueforover50%ofthetraceperiod,andwithin50KB/sforover80%.Itisimportanttonotethattheseresultswereachievedwithatrainingsetofonlyoneweekduration.AsusersrunBreadCrumbsforincreasingly-longperiods,thedevice-centricmobilitymodelcanonlybene“tfromincreasedex-posuretotheuserspatterns.5.3SampleApplicationsTheprimaryaimofBreadCrumbsistoimprovetheappli-cation-leveland(mostimportantly)user-visibleexperienceformobiledevices.Totrulyevaluateoursystem,then,weneedtoexaminehowboththeoperatingsystemanddif-ferentmobileapplicationscouldbene“tfromconnectivity 0 20 40 60 80 100 0 50 100 150 200 250 300 % steps in trace bandwidth (KB/s) k=1 k=2 k=3 k=4 k=5 k=6 Figure6:CDF:bandwidthpredictionerror.thenumberofstepsintothefutureBreadCrumbsfore-Weevaluatetheperformanceofdierentapplicationsus-ingthetraceswecollected,ratherthanexecutingtheappli-cationsliveŽonamobiledevice.Thisallowsustodirectlycomparetheperformanceofprediction-unawarealgorithmsandBreadCrumbsonidenticalsequencesofusermotionandAPsseen,toensureanaccuratecomparison.Thesubsectionsthatfollowinvestigatethreesuchsce-narios.Clearly,connectivityforecastsaremostusefulforbackgroundoropportunistictasks,whereanapplicationhassome”exibilityinwhenanetworkoperationmustoccur.AsinSection5.2,the“rstweekoftraceswasthetrain-ingsetthatbuiltthemobilitymodel,andthesecondweektheevaluationset.Foreachscenariowedevisedthreeal-gorithmsthataccomplishedthesameobjective„onethatwasignorantofanyfuturepredictions,anotherthatutilizedBreadCrumbsconnectivityforecasts,andathirdthatusedarandomwalkmobilitymodel.Foreachtraceintheevalu-ationset,weranallthreealgorithms,recordedtheresults,andsubsequentlyaveragedacrossalltheruns.AstepŽineachtracecorrespondsto10secondsofrealtime.Ateachstepinthetrace,forallalgorithms,thesimula-tiondeclaredthedeviceassociatedtotheAPwiththebestdownstreambandwidthamongallAPspresentthatthatlo-cation.Thiscorrespondstothedeviceusingtheaforemen-tionedVirgilAPselectionsystem[21]tochoosethecurrentAP,ratherthansimplyselectingbasedonsignalstrength.NoPredictionalgorithmthereforerepresentsthebestonecoulddomakingnopredictionsoffutureconnectivity,butusingthebestAPavailableathecurrentlocationforeachstep.5.3.1MapViewerOur“rstsampleapplicationisamapviewer,commonlyfoundonmobiledevicesliketheNokiaN800.Thisappli-cationdisplaysamapoftheuserscurrentlocation,andistypicallylinkedtoaGPSreceiversoastheusermoves,thecurrently-displayedmaptileisupdatedtore”ectthismove-ment.Beyondsimplestreetmaps,thesemaptilescancon-tainrichcontextualinformation„suchasmenusandreviewsofnearbyrestaurants„ordetailedgeographicinformation,suchasprovidedbyGoogleEarth. 0 1 2 3 4 5 6 7 Current Tile Blank Tiles Fetched BreadCrumbs Figure7:MapViewer.CurrentTileBlankarestepsinthetracewherethetilecorrespondingtothecur-rentGPSlocationisnotpresentinthedevicescache,andinsucientnetworkbandwidthexiststodownloaditsynchronously.TilesFetchedisthetotalnumberofmaptilesfetchedoverthecourseofeachtrace.AllvaluesarenormalizedtothoseofanOraclealgorithmthatusesperfectknowledgeoffuturemobilitytominimizeCurrentTileBlank.TheBreadCrumbsalgorithmavoidsunneces-sarynetworktracbynotpre-fetchingneighboringtileswhenupcomingnetworkconditionsarepredictedtobegood,whileincurringaslightlyhigherrateofmissingWhentheusermovesoutofonemaptileandintoanother,thetilesinformationmusteitherbefetchedsynchronouslyoralreadybepresentinacache.Otherwisetheuserexperi-encedegradesasblanktilesappearinthemap.Apolicyofalwayspre-fetchingallneighboringmaptilesprovidesgoodcoverage,butatthecostofwastednetworkoperationsifthosetilesarenevervisitedordisplayed.WeinvestigatedifBreadCrumbsforecastscouldbeusedtorollthediceŽandavoidwastefulpre-fetchingincaseswhereBreadCrumbspredictedthatthedevicewillhavesuf-“cientnetworkbandwidthavailabletosynchronouslyfetchanewmaptileassoonastheusermovestothatlocation.Wethereforedesignedfouralgorithmsforcomparison.NoPredictionsimplyensuresthattheuserscur-rentmaptile,andalleightsurroundingtiles,arepresentinthecachewheneversucientnetworkbandwidthexiststodoso.Second,ateachstepineachtrace,theBread-algorithmgeneratesaconnectivityforecastonestepinthefuture.Iftheforecastindicatesthatthemobilede-vicewillhaveenoughbandwidthavailabletosynchronouslydownloaditsnewmaptile,theBreadCrumbsalgorithmdoesnotpre-fetchneighboringblocks.Ifthepredictednext-stepbandwidthislow,however,itpre-fetchesneighboringblocksjustasNoPrediction.Third,theRandomalgorithmisiden-ticaltoBreadCrumbs,butinsteadofusingBreadCrumbsconnectivityforecasts,thisalgorithmchoosesarandomsuc-cessorstatetothecurrentstate,andtakesthebestband-widthobservedatthatstateasthebandwidththedevicewillhaveatthenextstepinthetrace.Finally,theOraclealgorithmusesperfectknowledgeoffuturemobilitytoachievetheminimumpossiblenumberof 0.2 0.4 0.6 0.8 1 1.2 Gaps in Playback Radio Active BreadCrumbs Figure8:StreamingMedia.GapsinPlaybackisthetracedurationwherethestreamwasnotplayingonthedevicebecausethebuerwasemptyandinadequatenet-workconnectivityexistedatthatlocation.RadioActiveisthetracedurationthattheWiFiradiowasactivelydownloadingdata.AllvaluesarenormalizedtothoseofanOraclealgorithmthatminimizesGapsinPlaybackdownloadingtheentirestreamasfastaspossiblewithanin“nitebuersize.TheBreadCrumbsalgorithmavoidspre-“llingthebuerifforecastsindicatethatupcom-ingnetworkbandwidthwillbesucienttoservicethestream.Thisconservesenergywhilenotsigni“cantlyin-creasingplaybackgaps.blanktilespertrace.NotethatminimizingonecriterionCurrentTileBlank)doesnotnecessarilyoptimizefortheother(TilesFetched).Infact,wewillseethattheBread-algorithmfetchesfewertilesthantheOraclebe-causeitrisksblanktilesinordertofetchasfewtilesaspossiblefromtheremoteserver.Tilescorrespondtothe11080metertilesofourmodel,andeachtileisassumedtobe100KBinsize.TheresultsinFigure7areallnormalizedtothoseoftheOraclerithm.Oneseesthatbynotpre-fetchingneighboringtileswhenupcomingconnectivityispredictedtobegood,theBreadCrumbsalgorithmavoidswastingenergybyfetchingtilesthatwillneverbedisplayed.Atthesametime,thisgambleresultsinonlyathreepercenthigherrateofmissingmaptilesthantheNoPrediction5.3.2StreamingMediaNext,weconsideredissuesraisedwhenstreamingmediacontentfromaremoteserverontoahandhelddevicewhiletheuserisinmotion.Amediastreamhasawell-de“nedquality-of-servicemetric„speci“cally,theencodedbitrateofthestream.Whenmobileinpublic,however,theusersdevicemovesfromconnectiontoconnectionatdierentlo-cations.Somelocationsmayhavesucientbandwidthtoservicethestream,somemaynot,andsomelocationsmaybedevoidofnetworkconnectivityaltogether.Oneoptionistode“neabuersizeandfetchthestreamasfastaspossibleateverygivenmoment,uptothepointwherethebueris“lled.Thisisthestrategycommonlyemployedtodaybystreamingmediaapplications,correspondingtotheNoPredictionalgorithmforthisapplication.Thisalgorithm 0 2 4 6 8 10 Writeback Completed Radio Active BreadCrumbs Figure9:Opportunisticwriteback.WritebackCom-pletedisthetotalelapsedtracetimeuntilalldatawassafeontheremoteserver.RadioActiveisthetotaltracetimethattheWiFiradiowasactivelytransmittingdata.AllvaluesnormalizedagainstanOraclealgorithmthatusesperfectknowledgeoffuturemobilitytomini-RadioActive.ByutilizingBreadCrumbsconnectiv-ityforecasts,theprediction-awarealgorithmdelaysdatawritebackbrie”ytoselectivelyusehigh-bandwidthac-cesspoints.Asaresult,thetotaltimeuntildataissafeontheremoteserveriscomparable,butBreadCrumbsactivatestheWiFiradio30%lessoftenthanwithnoprediction,translatingintosigni“cantenergysavings.downloadsthestreamasfastaspossibleateachstepinthetrace,giventheavailablenetworkconnectivity,upuntilthepointthatatwo-minutebuerhasbeen“lled.Second,ateachsteptheBreadCrumbsalgorithmgener-atesconnectivityforecastsforeachofthenextsixsteps„uptooneminuteinthefuture.Ifthefutureconnectivityispredictedtobesucienttoservicethemediastream,thealgorithmdoesnotpre-fetchdataintothebuer.TheRandomalgorithmisidentical,exceptthatinsteadofusingconnectivityforecaststopredictfuturenetworkconditions,itgeneratesarandomwalkfromthecurrentlocationintothefuture.Finally,theOraclealgorithmdownloadstheentirestreamasfastaspossible,withoutabuersizecap.ThisislessofanoracleŽthanaboundonhowquicklyanyalgorithmcouldfetchthedatacomprisingthestreamforthetraceduration.NotethatwhilethisminimizesGapsinPlaybackitresultsintheradiobeingactiveforlongerthananyoftheotherWesimulateda64KB/svideostream.Figure8showsthatallthreealgorithms(NoPredictionBreadCrumbs,andRandom)resultincomparablegapsinplayback.TheBread-algorithm,however,activatestheWiFiradio30%lessoftenthantheprediction-unawarealgorithm.Byem-ployingBreadCrumbsconnectivityforecasts,thatalgorithmisabletoprovidethesameplaybackexperiencetotheuserwhileusingsigni“cantlylessofthemobiledevicesbatteryascomparedtoaprediction-ignorantalgorithm.5.3.3OpportunisticWritebackOur“nalscenarioconsidersauserwhohasgeneratedsomecontentonhishandhelddevicewhileawayfromhome.These“lesaredigitalphotostakenbythecameraonhissmartphone.Theuserpreviouslycon“guredadistributed“lesystemclienttoensureallcontenthegenerateswillbesafelyreintegratedtohisremote“leserver.This“leservercouldbeadedicatedmachineathishomeorwork,orawebservicesuchasFlickr.Weassumetheonlynetworkconnec-tivityavailabletothesmartphoneiswhateveropenWiFiisavailable.Forevaluationpurposes,wesetthenumberofphotosthatourhypotheticalusertookateight,eachwitha“lesizeran-domlyuniformbetween1MBand5MB.Thesetofeightrandom“lesizeswasgeneratedonceandthenthesamesetusedacrosstheentireevaluationforconsistency.NoPredictionalgorithmsimplytriedtotransmittheeightimage“lesasquicklyaspossible,ateachstepusingtheAPwiththebestupstreambandwidthavailableatthatlocation.ThealgorithmthatutilizedBreadCrumbssoughttoreducetheamountoftimetheWiFiradiowasactive,whilenotdelayingdatawritebackunreasonably.Oursimpleprediction-awarealgorithmworkedasfollows.Ateachstepoftraceplayback:1.DeterminewhichAPhasthebestupstreambandwidthatthecurrentlocation.2.QueryBreadCrumbsforitsconnectivityforecastofup-streambandwidth10,20,and30secondsinthefuture.Ifanyofthosethreefuturepointsarepredictedtohavebetterupstreambandwidth,donothingatthistime.Else,transmitdatatotheremoteserverasfastaspos-sibleduringthisstep.Thisalgorithmisadmittedlysomewhatnašve.ThiswasintentionalaswesoughttoevaluatehowusefulBreadCrumbsconnectivityforecastscouldbeforapplicationsthathavemadeveryminimalmodi“cations.Athirdalgorithm,Ran-,operatedthesameastheBreadCrumbsalgorithmbutinsteadofusingconnectivityforecaststopredictfuturenet-workconditions,RandomsimplygeneratedarandomwalkthroughthegeographicneighborsofagivenstateinordertopredictŽfuturemobilityandconnectivity.Finally,afourthalgorithm,Oracle,isourbaseline.Thisalgorithmusesperfectknowledgeofthefuturetogeneratetheminimalradioactivetimepossible,byonlytransmittingdataatthestatesofeachtracewiththehighestavailableAPbandwidth.Weranallfouralgorithmsonceforeachofthetracesintheevaluationset.Ourevaluationmetricswere(1)totalelapsedtimeuntilthealldatawassafelyontheremoteserver,and(2)totaltimetheWiFiradiowasactivelytransmitting.Fig-ure9illustratestheresults.Onaverage,theBreadCrumbsalgorithmcompleteswritebackonlyslightlyslowerthantheaggressive,prediction-ignorantalgorithm.Infactthedier-enceisnearlywithintheerrorboundsofthemeanforbothOntheotherhand,utilizingBreadCrumbsconnectivityforecastsletstheprediction-awarealgorithmactivatetheWiFiradio30%lessoften.Byattemptingtoonlytransmitdataathigh-bandwidthlocations,theprediction-awareal-gorithmmakesmoreecientuseofthewirelessradio.Whilesmallfordesktopsorevenlaptops,thisissigni“cantformo-biledeviceswherewirelessNICusageisalargefractionof #statesinmodel modelsize 27984bytes(42.92B/state) #testresults testDBsize 92132bytes(69.01B/entry) Table3:Overhead:spacerequirements.Thetestdatabaseiscurrentlystoredinunoptimized,ASCII 20 40 60 80 100 time (ms) k=2 k=3 k=4 k=5 k=6 k=7 k=8 k=9 Figure10:Connectivityforecastoverhead.ResultsonaCompaqiPAQhandheld(400MHzCPU),128MBtotalenergyexpenditure.Forexample,Anandetal[3]foundthat,foraniPAQhandheld,thepowerrequiredtoactivelytransmitdataovertheWiFiinterface(eveninpower-savemode)wasnearlyequaltothemeasuredquiescentpowerconsumptionoftheentiredevicewhentheradiowasinac-tive.5.4OverheadTable3showsthestoragerequiredontheiPAQtostorethemobilitymodelandtestdatabasegeneratedinthecourseofourevaluation.With652dierentstatesinthemodel,thetotalmodelsizeisapproximately27.3KB,or43bytesperstateonaverage.Recallthat,becauseoursisasecond-orderMarkovmodel,eachstaterepresentsthecurrentGPSgridlocationoftheuserandtheirpreviouslocation.FromTa-ble1,weknowthatBreadCrumbsvisited110dierentgridlocationsduringtheevaluationperiod.Ifeverycombinationofcurrentlocationandpreviouslocationweregeneratedasastate,themodelwouldhave110110=12100states.Evenamodelofsuchcomplexitywouldonlyrequire508KBofspaceonthemobiledevice.Giventhesparsenessofthesemodelsinpractice,amodelofthatsizewouldbemostlikelybesucienttocoveranentiremetropolitanarea.Likewise,theoverheadimposedtostorethetestdatabaseisreasonable„69bytespertestentryonaverage.Forcon-venience,thedatabasewasimplementedasanASCII”at“le,unoptimized.Evenso,therecordsforthe1335testre-sultsgeneratedbyourevaluationrequire90KBofstoragespace,butonly7.04KBwhenincompressedform.Figure10examinestheCPUoverheadimposedwhengen-eratingconnectivityforecasts.Theparameteristhenum-berofstepsinthefutureofthemodel,givenacurrentstate,thatwerequestedaconnectivityforecastofdown-streambandwidthfromBreadCrumbs.Thisgraphrepre-sentsonlytheinstrumentedCPUtimerequiredforthecal-culation,notanycommunicationsoverheadbetweenBread-Crumbsandtheapplicationrequestingtheforecast.Allre-sultsweremeasuredonaCompaqiPAQh5555,witha400MHzARMprocessorand128MBofsystemRAM.Werequestedaconnectivityforecastforeachofthe652statesinthemodelourevaluationgenerated,varyingthesizeoffrom1to10.Becausethisisarecursivealgorithm(seeFigure2)weexpecttheoverheadtogrowexponentially.Uptosixstepsahead,theoverheadislessthan2.5ms.Eventhemeanoverheadof75msat=9isnotprohibitiveforapplicationsthatperformsuchintensiveoperationsrarely.Notethatwedidnotimplementcachingofcalculatedfore-castsorotherpossibleoptimizationsinourimplementation.6.RELATEDWORKRahmatiandZhong[23]investigatedtheproblemofchoos-ingbetweenWiFiandcellulardatanetworks,giventhatalargenumberofmobiledevicesnowfeaturebothradios(e.g.theAppleiPhone).Ratherthanbuildandmaintainamobil-itymodelasBreadCrumbsdoes,theyusethesetofcellulartowerIDscurrentlyseenandsometime-of-dayheuristicstoestimatetheexpectedqualityofWiFiconnectivityatthecurrentlocation.Theirsystemdoesnotpredictfuturecon-ditions,asBreadCrumbsdoes.Rather,itdecideswhetheratagiventimeandplace,itismoreadvantageoustopowerontheWiFiinterfaceortousethelower-bandwidth,butubiq-uitious,cellularconnection.Also,identifyinglocationsolelybycelltowersignalsisnecessarilymorecoarse-grainedthanourapproachthatleveragesWiFibeaconsorGPS.Cellularsignalsreachatleastseveralkilometers,andtensofkilome-tersundergoodconditions.WiFisignalshaveafarshorterrange,typicallyseveralhundredmetersatbest.MobiSteer[20]focusesonimprovingwirelessnetworkcon-nectivityinonespeci“cusagesetting„whileinmotioninamotorvehicle.Theirsystemusesadirectionalantennatomaximizethedurationandqualityofconnectivitybetweenamovingvehicleandstationaryaccesspointsinthecommu-nity.ThisgoaliscomplementarytothatofBreadCrumbs,becauseMobiSteerperformswellinsituationswhereBread-Crumbsdoesnot.Whileportionsoftheevaluationtracescollectedinourpapertracktheuserridingonacitybus,duringthisperiodtheuseronlyhasreliableconnectivitywhilestoppedatintersections.AsexploredindetailbyBy-chkovskyetal[5],thisreducedperformancewasduetothebrieftimetheclienthastoassociatewiththeAP,obtainaDHCPaddress,anddousefulwork.Ontheotherhand,BreadCrumbsdoesnotrequireanyspecializedhardwareandworkswithwhateverusersalreadycarryintheirpocket.MobiSteerscachedmodeoperationisalsoreminiscentofthewayBreadCrumbsandVirgil[21]optimizefuturere-sourcediscoverybycachinghistoricalaccesspointqualitySongetal[25]applieddierentmobilitypredictionmeth-odstotheproblemofimprovingbandwidthprovisioningandhandoforVoIPtelephony.Theyuserealclienttracestoevaluatethesuccessofaconcreteapplicationthatisprediction-aware,andassumetheexistenceofacentralizedauthoritythatcollectsmobilityinformation,makespredic-tions,anddisseminatesinstructionstovariouswirelessac-cesspoints.Wearefocusedonapplicationsthatarestillusefulwhenthedevicekeepsitsmobilityhistory,andthisinformationneednotbedisclosedtoanyotherparty. Ghoshetal[10]predicttheprobabilitythatusersvisitpopularlocations,knownas.Theirfocusisonextrap-sociologicalorbitsfromtheclientmobilitydatabyidentifyingthefrequencywithwhichusersencounteroneanotheratthesehubs.Theauthorsdonotevaluatehowac-curatelytheirBayesiantechniquespredictedexplicitclientpaths(ratherthanjustthehubstheyvisit).Wethereforewereunabletocomparetheaccuracyoftheirtechniquewiththatofoursecond-orderMarkovmodel.Yoon[28]concentrated,asdidKimetal[14],onderivingrealisticmobilitymodelsfromactualusermobilitytraces.Theideaistotakemanydierentclienttracesandbuildaprobabilisticmodelthatcanbeusedtogeneratearbitraryclienttracks.Thesetraces,whilestillarti“cial,morecloselymodeltherealmovementsofusersthandosyntheticmod-elslikeRandomWaypoint[27].Inthispaper,weconsideronlythesituationwheredevicesmaintaintheiractualmo-bilityhistorythemselves,andpredicttheirfuturebehavioron-the-”yŽratherthanbasepredictionsonmobilitymodelsderivedfrommultipleusersbehavior.Marmasse[19]argues,aswedo,infavorofauser-centricmobilitymodel.HercomMotionsystemisconcernedchie”ywithtrackingusersmovementthroughvarioussemanticallymeaningfullocations,suchashomeŽorworkŽ.We,ontheotherhand,focusonlower-levelwaypoints„namely,GPSgridlocations.Thesemanticconceptofuser-de“nedloca-tionscouldeasilybelayeredatopsuchlow-levelinformation,however.Haggle[13]isaframeworkfordisseminatingdatabetweenmobileusersbasedonthe”eetingoccasionswhentheycomeintophysicalcontactwitheachother.InthesesituationsinfrastructuresuchasWiFinetworksneednotbeused,be-causeusersarewithinrangeoflow-power,point-to-pointlinktechnologieslikeBluetoothorZigBee.Theirsystemisclearlydependentonuser-centricmobilityinformation,butseekstopredictwhenpairsofuserswillcomeintocontactwitheachother.Ourwork,ontheotherhand,isfocusedmoreonleveraginginformationaboutwirelessaccesspointstheuserwillsoonencounter.Mostapplicationsoflocationpredictionhavebeeninmo-bilephonenetworks.Typically,acentralnetworkoperatorseekstoknowthesequenceofnetworktowerswithwhichahandsetwillassociate.Giventhisinformation,thenetworkoperatorcanreserveresources,suchasbandwidth,attheup-comingnodes,sohandoproceedsassmoothlyaspossible.BhattacharyaandDas[4]useavariantoftheLZpredictordescribedabovetopredictthenextcelluserswillassociatewith.YuandLeung[29]extendthisideatopredictnotonlywhereamobiledevicewillhandobutalsowhenthiswilloccur.LiangandHaas[17]useaGauss-Markovmodelinasimilarway.OthersuseRobustExtendedKalmanFil-tering(REKF)[22],integrateindividualpathinformationwithsystem-wideaggregatedata[1],orestimatefuturelo-cationsthroughtrajectoryanalysis[2].Liuetal[18]useasimilarhybridapproachformobilitypredictioninwire-lessATMnetworks,ratherthanformobiletelephony.Theycombinesystem-wideinformationwithlocalmobilityhistoryandpathtrajectoriestoreducesystemresourceconsumptionwhilemaintaininguserQoS.Alloftheselocationpredictorsareenabledbyaccuratees-timatesofamobiledeviceslocation.Insomecases,allthatisneededisinformationonwhichaccesspointormobilephonetowerthedeviceisassociatedwith.Forpredictorsandapplicationsrequiringmore“negrainedlocationinfor-mation,thereareawidevarietyofsolutions.PlaceLableveragespublicdatabasesofWiFiAPGPSco-ordinatestotriangulateoneslocationbasedontheAPsseenatagivenlocationandtheirsignalstrengths[16].ThesameideahasrecentlybeenextendedtouseGSMphonetowersratherthanWiFiAPs[6].Foxetal[9]showedthebene“tofBayesian“lteringtocoalesceresultsfrommultiplelocationsensorsandsmoothtransientuncertaintyinlocationesti-mates.Otherworkfocusesonindoorlocalizationatverysmallscales,eitherbydeployingcustomhardware[24]ormappingexistingWiFibeaconsources[11].7.CONCLUSIONOperatingsystemscurrentlyfocusonimmediatecondi-tionswhenmanagingwirelessnetworkconnections.Butto-day,usersaremoremobilethanever,utilizingapatchworkofpublicaccesspointsofvaryingcapabilitiesandunevengeographicdistribution.Applicationswouldliketousethispublicconnectivityopportunisticallytoperformbackgroundorlow-prioritywork,butcannotmakereliableassumptionsaboutconnectionqualityatanygivenmomentinthefuture.Wearguethattheincreasedmobilityofusersdemandsafocusonhowconnectivitychangesovertime„itsThispaperdescribedBreadCrumbs,oursystemthatletamobiledevicetrackthistrendofconnectivityqualityasitsownermovesaroundtheworld.BreadCrumbsmaintainsapersonalizedmobilityhistoryonthedevice,andtrackstheAPsencounteredatdierentlocations.BreadCrumbsalsoprobestheapplication-levelquality„bandwidthandlatencytotheInternet„oftheopenconnectionsthedeviceencoun-Together,thepredictionsofthemobilitymodelandtheAPqualitydatabaseyieldconnectivityforecasts.Thesefore-castsletapplicationstakedomain-speci“cactioninresponsetoupcomingnetworkconditions.Weevaluatedtheecacyoftheseforecastswithseveralweeksofreal-worldusage.BreadCrumbswasabletopredictdownstreambandwidthatthenextstepofthemodelwithin10KB/sforover50%oftheevaluationperiod,andwithin50KB/sforover80%ofthetime,withonlyoneweekoftrainingdatatobuildthemodelandAPqualitydatabase.Wealsoevaluatedhowthreeexampleapplications,withminimalmodi“cation,canutilizeconnectivityforecasts.Ourresultsfoundthatwithaslittleasoneweektrainingtime,BreadCrumbscanprovideimprovedperformancewhilereducingpowerconsumption,acriticalconcernforresource-constrainedmobiledevices.8.ACKNOWLEDGEMENTSThisworkwassupportedinpartbytheNationalSci-enceFoundationunderawardnumberCNS-0615086,andtheFordMotorCompany.Anyopinions,“ndingsandcon-clusionsorrecommendationsexpressedinthismaterialarethoseoftheauthor(s)anddonotnecessarilyre”ectthoseoftheNationalScienceFoundationorFordMotorCompany.Wewouldliketothanktheanonymousreviewers,fortheirinsightfulcommentsandsuggestionsthatgreatlyimprovedthequalityofourpaper.WealsogratefullyacknowledgethehelpfulfeedbackofJasonFlinn,MingyanLiu,Z.MorleyMao,JamesMickens,SamShahandKaushikVeeraragha-van. 9.REFERENCES[1]I.AkyildizandW.Wang.Thepredictiveusermobilitypro“leframeworkforwirelessmultimedianetworks.IEEE/ACMTransactionsonNetworking12(6):1021…1035,2004.[2]A.AljadhaiandT.Znati.PredictivemobilitysupportforQoSprovisioninginmobilewirelessenvironments.IEEEJournalonSelectedAreasinCommunications19(10):1915…1930,October2001.[3]M.Anand,E.Nightingale,andJ.Flinn.Self-tuningwirelessnetworkpowermanagement.InProceedingsof,pages176…189,September2003.[4]A.BhattacharyaandS.Das.Lezi-update:aninformation-theoreticapproachtotrackmobileusersinPCSnetworks.InProceedingsofMobicom,pages1…12,1999.[5]V.Bychkovsky,B.Hull,A.Miu,H.Balakrishnan,andS.Madden.AmeasurementstudyofvehicularinternetaccessusinginsituWi-Finetworks.InProceedingsofMobiCom,2006.[6]M.Chen,T.Sohn,D.Chmelev,D.Haehnel,J.Hightower,J.Hughes,A.LaMarca,F.Potter,I.Smith,andA.Varshavsky.Practicalmetropolitan-scalepositioningforGSMphones.InProceedingsofUbiComp,pages225…242,September[7]Y.Cheng,Y.Chawathe,A.LaMarca,andJ.Krumm.Accuracycharacterizationformetropolitan-scaleWi-Filocalization.InProceedingsofMobiSys,pages233…245,June2005.[8]M.Dischinger,A.Haeberlen,K.Gummadi,andS.Saroui.Characterizingresidentialbroadbandnetworks.InProceedingsofIMC,October2007.[9]D.Fox,J.Hightower,L.Liao,D.Schulz,andG.Borriello.Bayesian“lteringforlocationestimation.IEEEPervasiveComputing,2(3):24…33,July…September2003.[10]J.Ghosh,M.Beal,H.Ngo,andC.Qiao.Onpro“lingmobilityandpredictinglocationsofcampus-widewirelessnetworkusers.InProceedingsofREALMANpages55…62,May2006.[11]A.Haeberlen,E.Flannery,A.Ladd,A.Rudys,D.Wallach,andL.Kavraki.Practicalrobustlocalizationoverlarge-scale802.11wirelessnetworks.ProceedingsofMobiCom,pages70…84,2004.[12]FamiliarLinux.[13]P.Hui,A.Chaintreau,J.Scott,R.Gass,J.Crowcroft,andC.Diot.Pocketswitchednetworksandhumanmobilityinconferenceenvironments.InProceedingsoftheACMSIGCOMMWorkshoponDelay-tolerant,pages244…251,August2005.[14]M.Kim,D.Kotz,andS.Kim.Extractingamobilitymodelfromrealusertraces.InProceedingsofINFOCOM,April2006.[15]D.Kotz,T.Henderson,andI.Abyzov.CRAWDADtracesetdartmouth/campus/movement(v.2005-03-08),Mar.2005.[16]A.LaMarca,Y.Chawathe,S.Consolvo,J.Hightower,I.Smith,J.Scott,T.Sohn,J.Howard,J.Hughes,F.Potter,J.Tabert,P.Powledge,G.Borriello,andB.Schilit.PlaceLab:Devicepositioningusingradiobeaconsinthewild.InProcedingsofPervasive,pages116…133,May2005.[17]B.LiangandZ.Haas.Predictivedistance-basedmobilitymanagementformultidimensionalPCSnetworks.IEEE/ACMTransactionsonNetworking11(5):718…732,October2003.[18]T.Liu,P.Bahl,andI.Chlamtac.Mobilitymodelling,locationtracking,andtrajectorypredictioninwirelessATMnetworks.IEEEJournalonSelectedAreasinCommunications,16(6):922…936,August1998.[19]N.MarmasseandC.Schmandt.Auser-centeredlocationmodel.PersonalandUbiquitousComputing6(5…6):318…321,December2002.[20]V.Navda,A.Subramanian,K.Dhanasekaran,A.Timm-Giel,andS.Das.MobiSteer:Usingsteerablebeamdirectionalantennaforvehicularnetworkaccess.ProceedingsofMobiSys,June2007.[21]A.Nicholson,Y.Chawathe,M.Chen,B.Noble,andD.Wetherall.Improvedaccesspointselection.InProceedingsofMobiSys,pages233…245,June2006.[22]P.Pathirana,A.Savkin,andS.Jha.Mobilitymodellingandtrajectorypredictionforcellularnetworkswithmobilebasestations.InProceedingsofMobiHoc,pages213…221,2003.[23]A.RahmatiandL.Zhong.Context-for-wireless:Context-sensitiveenergy-ecientwirelessdatatransfer.InProceedingsoftheFifthInternationalConferenceonMobileSystems,ApplicationsandSystems(MobiSys’07),pages165…178,SanJuan,PuertoRico,June2007.[24]A.Smith,H.Balakrishnan,M.Goraczko,andN.Priyantha.TrackingmovingdeviceswiththeCricketlocationsystem.InProceedingsofMobiSyspages190…202,2004.[25]L.Song,U.Deshpande,U.Kozat,D.Kotz,andR.Jain.PredictabilityofWLANmobilityanditseectsonbandwidthprovisioning.InProceedingsofINFOCOM,April2006.[26]L.Song,D.Kotz,R.Jain,andX.He.EvaluatinglocationpredictorswithextensiveWi-Fimobilitydata.InProceedingsofINFOCOM,pages1414…1424,March2004.[27]J.Yoon,M.Liu,andB.Noble.Randomwaypointconsideredharmful.InProceedingsofINFOCOMpages1312…1321,March2003.[28]J.Yoon,B.Noble,M.Liu,andM.Kim.Buildingrealisticmobilitymodelsfromcoarse-grainedtraces.ProceedingsofMobiSys,pages177…190,June2006.[29]F.YuandV.Leung.Mobility-basedpredictivecalladmissioncontrolandbandwidthreservationinwirelesscellularnetworks.InProceedingsofINFOCOM,pages518…526,April2001.