ethan goldblum & marinos bernitsas · 2014-11-28 · ethan goldblum & marinos bernitsas the...

1
STA d (m) AP1 Channel 3 v (m/s) PI1 SI1 PI1 SI1 Ethan Goldblum & Marinos Bernitsas The Problem • 802.11 does not specify a specific handoff scheme • The Mobile Host will switch Access Points only when there is a significant deterioraIon in the received signal • Typical handoff Ime ranges from 100ms to several seconds • Long handoffs disrupt applicaIon performance for mobile users switching between Access Points, especially for latency‐sensiIve applicaIons like VoIP The ObjecIve Reduce the 7me spent when switching between two 802.11 Access Points in the same network The Approach • We focus on reducing the Probe Delay • Probe Delay: the Ime it takes for the Mobile Host to acIvely scan each channel to find which Access Point it should connect to t handoff =t probe +t assoc +t auth • Probe Delay accounts for 90% of the handoff delay • We implement two handoff protocols on the MadWifi Driver for Atheros Chipsets • Each Access Point has two antennas, the Primary Interface and the Secondary Interface • The Secondary Interface iteraIvely sends a beacon to each channel, signifying the presence of the Primary Interface • The Mobile Host uses the Received Signal Strength Indicator of the beacons sent by the Secondary Interfaces to predetermine the best Access Point to associate with during the Handoff • Once it is Ime for the Handoff to take place, the Mobile Host can avoid the probing process and move directly to the AssociaIon Process Leapfrog Shared Beacon • Each Access Point is preconfigured with a table of its nearest Access Points • Every beacon contains the table of nearest Access Points’ Channel and MAC Address • When it is Ime to handoff to a new network, only the list of nearest Access Points is probed, saving the Mobile Host of having to iterate through all channels Experimental Setup • We use the CMU Wireless Emulator to run our experiment • We first run the stock MadWifi driver to establish our benchmark • We implement each scheme by modifying the MadWifi Driver’s beacon, send/receive and scan procedures • We use a generic model of signal propagaIon: • LogDistance loss model with n=3, Ricean Fading with k=3 (rooms with brick walls) and 0 addiIonal Delay Results STA d (m) AP1 AP2 v (m/s) 1 5 11 1 3 Scan List 1 5 11 AP1 Channel 5 AP3 Channel 1 AP4 Channel 11 Run Assoc Scan Auth Assoc Run Beacons are missed and the Handoff begins. The staIon first tries to reassociate with the old Access Point AssociaIon Imeout acer 5 seconds, proceed to acIve probing Acer each of the 11 channels is probed (11*200ms), the next closest Access Point is chosen. An authenIcaIon request is sent to the new Access Point The Mobile Host associates with the new AP and the handoff is complete MadWifi state transiIons during handoff Element ID Length OUI Primary Interface’s Channel & MAC Address Vendor‐Specific Element in Leapfrog’s Beacon Frame bytes: 1 1 3 8 Element ID Length OUI Channel & MAC Address List for Neighboring APs bytes: 1 1 3 8*SHAREDBEACON_MAX Vendor‐Specific Element in Shared Beacon’s Beacon Frame Key Variables • We vary the size of the region for which the two Access Points overlap, by varying the Access Point separaIon d (in meters) for a fixed v of 1 m/s d>90m: There is no overlap, so leapfrog degrades to default MadWifi driver’s performance d<90m: There is an overlap region d<60m: The Mobile Host does not disassociate with the first Access Point Key Metrics t(disassociate‐>scan) Time from disassociaIon to decision to perform scan t(scan‐>auth) Time from scan to transmission of authenIcaIon frame to the new Access Point t(auth‐>run) Time from transmission of authenIcaIon frame to successful associaIon with the new Access Point 0 5,000 10,000 15,000 20,000 25,000 90 85 80 75 70 Default Driver Handoff Delay ms m 0 5,000 10,000 15,000 20,000 25,000 90 85 80 75 70 Leapfrog Handoff Delay m ms 0 5,000 10,000 15,000 20,000 25,000 90 85 80 75 70 Shared Beacon Handoff Delay ms m Assessment • Leapfrog and Shared Beacon managed to decrease the probing delay significantly • Unlike Shared Beacon, Leapfrog may not need to probe when there is enough overlap between two Access Point ranges • Total Handoff Delay decreased, however, since in MadWifi probe delay accounts for the smallest porIon of total handoff delay, the overall improvement was minor

Upload: others

Post on 08-Aug-2020

4 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Ethan Goldblum & Marinos Bernitsas · 2014-11-28 · Ethan Goldblum & Marinos Bernitsas The Problem • 802.11 does not specify a specific handoff scheme • The Mobile Host will

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