ethan goldblum & marinos bernitsas · 2014-11-28 · ethan goldblum & marinos bernitsas the...
TRANSCRIPT
STA
d(m)
AP1Channel3
v(m/s)PI1 SI1 PI1 SI1
EthanGoldblum&MarinosBernitsas
TheProblem
• 802.11doesnotspecifyaspecifichandoffscheme
• TheMobileHostwillswitchAccessPointsonlywhenthereisasignificantdeterioraIoninthereceivedsignal
• TypicalhandoffImerangesfrom100mstoseveralseconds
• LonghandoffsdisruptapplicaIonperformanceformobileusersswitchingbetweenAccessPoints,especiallyforlatency‐sensiIveapplicaIonslikeVoIP
TheObjecIve
Reducethe7mespentwhenswitchingbetweentwo802.11AccessPointsinthesamenetwork
TheApproach
• WefocusonreducingtheProbeDelay• ProbeDelay:theImeittakesfortheMobileHosttoacIvelyscaneachchanneltofindwhichAccessPointitshouldconnectto• thandoff=tprobe+tassoc+tauth• ProbeDelayaccountsfor90%ofthehandoffdelay
• WeimplementtwohandoffprotocolsontheMadWifiDriverforAtherosChipsets
• EachAccessPointhastwoantennas,thePrimaryInterfaceandtheSecondaryInterface
• TheSecondaryInterfaceiteraIvelysendsabeacontoeachchannel,signifyingthepresenceofthePrimaryInterface
• TheMobileHostusestheReceivedSignalStrengthIndicatorofthebeaconssentbytheSecondaryInterfacestopredeterminethebestAccessPointtoassociatewithduringtheHandoff
• OnceitisImefortheHandofftotakeplace,theMobileHostcanavoidtheprobingprocessandmovedirectlytotheAssociaIonProcess
Leapfrog SharedBeacon
• EachAccessPointispreconfiguredwithatableofitsnearestAccessPoints
• EverybeaconcontainsthetableofnearestAccessPoints’ChannelandMACAddress
• WhenitisImetohandofftoanewnetwork,onlythelistofnearestAccessPointsisprobed,savingtheMobileHostofhavingtoiteratethroughallchannels
ExperimentalSetup
• WeusetheCMUWirelessEmulatortorunourexperiment• WefirstrunthestockMadWifidrivertoestablishourbenchmark• WeimplementeachschemebymodifyingtheMadWifiDriver’sbeacon,send/receiveandscanprocedures
• WeuseagenericmodelofsignalpropagaIon:• LogDistancelossmodelwithn=3,RiceanFadingwithk=3(roomswithbrickwalls)and0addiIonalDelay
Results
STA
d(m)
AP1 AP2
v(m/s)1
5
11
1
3
ScanList
1
5
11
AP1Channel5
AP3Channel1
AP4Channel11
Run
Assoc
Scan
Auth
Assoc
Run
BeaconsaremissedandtheHandoffbegins.ThestaIonfirsttriestoreassociatewiththeoldAccessPoint
AssociaIonImeoutacer5seconds,proceedtoacIveprobing
Acereachofthe11channelsisprobed(11*200ms),thenextclosestAccessPointischosen.
AnauthenIcaIonrequestissenttothenewAccessPoint
TheMobileHostassociateswiththenewAPandthehandoffiscomplete
MadWifistatetransiIonsduringhandoff
ElementID Length OUIPrimaryInterface’s
Channel&MACAddress
Vendor‐SpecificElementinLeapfrog’sBeaconFrame
bytes: 1 1 3 8
ElementID Length OUIChannel&MACAddressListforNeighboringAPs
bytes: 1 1 3 8*SHAREDBEACON_MAX
Vendor‐SpecificElementinSharedBeacon’sBeaconFrame
KeyVariables
• WevarythesizeoftheregionforwhichthetwoAccessPointsoverlap,byvaryingtheAccessPointseparaIond(inmeters)forafixedvof1m/s
• d>90m:Thereisnooverlap,soleapfrogdegradestodefaultMadWifidriver’sperformance
• d<90m:Thereisanoverlapregion• d<60m:TheMobileHostdoesnotdisassociatewiththefirstAccessPoint
KeyMetrics
t(disassociate‐>scan)TimefromdisassociaIontodecisiontoperformscan
t(scan‐>auth)TimefromscantotransmissionofauthenIcaIonframetothenewAccessPoint
t(auth‐>run)TimefromtransmissionofauthenIcaIonframetosuccessfulassociaIonwiththenewAccessPoint
0
5,000
10,000
15,000
20,000
25,000
90 85 80 75 70
DefaultDriverHandoffDelayms
m0
5,000
10,000
15,000
20,000
25,000
90 85 80 75 70
LeapfrogHandoffDelay
m
ms
0
5,000
10,000
15,000
20,000
25,000
90 85 80 75 70
SharedBeaconHandoffDelayms
m
Assessment• LeapfrogandSharedBeaconmanagedtodecreasetheprobingdelaysignificantly
• UnlikeSharedBeacon,LeapfrogmaynotneedtoprobewhenthereisenoughoverlapbetweentwoAccessPointranges
• TotalHandoffDelaydecreased,however,sinceinMadWifiprobedelayaccountsforthesmallestporIonoftotalhandoffdelay,theoverallimprovementwasminor