doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems A Technique for Fast Passive Scanning Charles R. Wright Azimuth Systems

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems Introduction Fast roaming requires timely information about nearby access points –On the order of hundreds of milliseconds Active scanning only possible in regulatory domains that permit it –11h, 11d issues Active scanning does not scale for large numbers of roaming clients –Imagine 100’s of voice over wireless handsets sending probe requests once a second…

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems Passive scanning would be appealing if it could be done quicker Currently, passive scanning means waiting for a beacon on every channel of interest –Takes on average ½ the beacon period per channel; can be worse than this Many stations all require the same sort of information at a relatively high frequency Would be nice to broadcast this information

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems What information does a STA need when scanning? Signal quality/strength assessment of a known AP –Obtained from a transmission known to be from an AP AP capabilities not needed if passed through infrastructure

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems How can we make AP signals more predictable to STAs? We could synchronize the TBTT of APs in a coverage area –STAs would know precisely when to expect a beacon transmission on another channel Drawbacks –STAs would miss the beacon in their own BSS when scanning –Full scan of all channels would take a long time –Really bad for overlapping BSS situations Other Traffic Ch 36 Beacon(36) Ch 40 Beacon(40) Ch 44 TBTT Beacon(44)

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems Other Traffic We could sync TBTTs with an offset Schedule TBTT of each AP in a coverage area to occur at a fixed time offset from an AP on an adjacent channel –“Incrementally-staggered TBTTs” –Also a problem in overlapping BSS case Ch 36 TBTT(36) Beacon(36) Ch 40 TBTT(40) Beacon(40) Ch 44 TBTT(44) Beacon(44) Et Cetera… time

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems What does the STA do? Informs AP it’s going to “sleep” by the usual mechanisms (legacy power management mode) Switches to next highest channel at appropriate time (knowing the offset) and listens for beacon Repeat previous until all channels scanned Return to original channel and return to “active” mode by usual mechanisms

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems How fast could such a scan take place? Notes: 11b PHY rate of 1 Mbps with long preamble assumed 11a PHY rate of 6 Mbps assumed Beacon delay assumed due to one low PHY rate, 1500 byte packet Other Traffic TBTT Beacon STA tuning time Beacon delay STA hops to another channel Live Spreadsheet

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems How fast could scans take place in a QoS BSS? It’s a function of the EDCA TXOP limit –QAP interrupts polling to send the beacon, so that makes beacon more predictable Spreadsheet below considers the default values for EDCA TXOP limits Notes: DSSS/CCK longest default TXOP limit is 6 ms OFDM longest default TXOP limit is 3 ms Other assumptions are same as previous slide Live Spreadsheet

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems How precise should sync be? The tighter the better, but beacons can be delayed from TBTT by other traffic limits Transceiver tuning time should not be a limiting factor Author proposes that accuracy in the low millisecond range is sufficient

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems What if beacon is so delayed STA cannot listen for it? Beacon can be delayed by other traffic STA can potentially snoop other traffic to detect frames transmitted by AP –Problem: AP may be using power control so RSSI measurment may not be useful Probably not catastrophic to miss the beacon –Can always try again later –If BSS is so busy the beacon is significantly delayed, might not want to go there anyway

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems Incrementally-staggered TBTT method not the only way This method assumes adjacent channels are assigned to nearby APs –Not true of good cellular reuse plans –Also want to avoid having simultaneous beacons in overlapping BSS situation Could instead use “alternately-staggered TBTTs” –Instead of always switching to adjacent channel, switch to next-adjacent channel –Or every 3 rd channel, or pseudorandom hopping, or… Could also use neighbor list information (TGk) to define a subset of channels over which to make TBTTs predictable Predictability of TBTT on other channels is all that is needed to support a wide variety of beacon scheduling schemes –Let your imagination run wild...

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems What if scan time exceeds beacon interval? STAs must request association with an appropriate ListenInterval so as not to miss too many TIMs –Must also do this to hear a beacon transmitted at an offset overlapping the beacon on channel of association Scanning all channels may not be necessary anyway, depending on configuration of system –Nonsensical to expect that STA would hear an AP on every defined channel –Left as an exercise to the designer Scanning all channels in one sweep probably not necessary –Can jump around to channels of interest, knowing the beacon schedule

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems How to Synchronize Access Points? First note that sync relationship between TBTTs on the order of 1 TU is all that is necessary For AP aggregation systems, it’s a no brainer –Aggregation switch controls all its APs and can coordinate the sync For traditional APs, use Network Time Protocol –NTP can achieve sync to USNO atomic clocks to accuracy of several milliseconds across the Internet –Should certainly provide similar or better accuracy among local AP clocks

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems What is actually adjusted by NTP? TSF in any AP is typically driven by a crystal oscillator –Oscillators are unsynchronized between APs NTP protocol and algorithm would establish how many microseconds an AP’s beacon was advancing or retarding relative to master AP would then advance or retard the TBTT by the estimated amount –This would be much smaller than a TU – on order of 10 us per 100 ms beacon interval –Actual TSF value would always be inserted in the beacon If anyone know whether changing the TSF counter in these small steps would cause a problem, author would like to know

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems Example NTP hierarchy Switch/Router NTP Server NTP Client running in each AP No need for sync with NIST; provided only to give APs a common reference

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems What is needed within for interoperability? Standardized sync relationship between TBTTs on each channel Mechanism for promulgating sync relationship to: –All participating APs –Associated STAs Method for ensuring sync among APs is out of the scope of , but is possible with NTP –Would be helpful for interop to establish a recommended practice describing use of NTP or other standard mechanism Anything else?

doc.: IEEE /0768r0 Submission September 2003 Charles R. Wright, Azimuth Systems Conclusion Presented a method for providing fast, passive scanning –Uses time-synchronized TBTTs It is substantially faster than traditional passive scanning It causes no additional network traffic load –Beacons are already transmitted –No probe requests, therefore no extra traffic All changes are in the MLME, except for TSF adjustment Basic idea can be expanded on or enhanced in many ways to meet the needs of fast roaming