A Technique for Fast Passive Scanning

1. A Technique forFast Passive Scanning Charles R. Wright Azimuth Systems charles_wright@azimuthsystems.com Charles R. Wright, Azimuth Systems

2. 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… Charles R. Wright, Azimuth Systems

3. 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 Charles R. Wright, Azimuth Systems

4. 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 Charles R. Wright, Azimuth Systems

5. 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 Beacon(36) Ch 36 Beacon(40) Other Traffic Ch 40 Beacon(44) Ch 44 TBTT Charles R. Wright, Azimuth Systems

6. 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 Beacon(36) Ch 36 time TBTT(36) Beacon(40) Other Traffic Ch 40 TBTT(40) Beacon(44) Ch 44 TBTT(44) Et Cetera… Charles R. Wright, Azimuth Systems

7. 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 Charles R. Wright, Azimuth Systems

8. How fast could such a scan take place? STA hops to another channel STA tuning time Beacon delay Beacon Other Traffic TBTT 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 Live Spreadsheet Charles R. Wright, Azimuth Systems

9. 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 Charles R. Wright, Azimuth Systems

10. 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 Charles R. Wright, Azimuth Systems

11. 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 Charles R. Wright, Azimuth Systems

12. 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 3rd 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... Charles R. Wright, Azimuth Systems

13. 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 Charles R. Wright, Azimuth Systems

14. 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 Charles R. Wright, Azimuth Systems

15. 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 Charles R. Wright, Azimuth Systems

16. Example NTP hierarchy NTP Server Switch/Router No need for sync with NIST; provided only to give APs a common reference NTP Client running in each AP Charles R. Wright, Azimuth Systems

17. What is needed within 802.11 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 802.11, 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? Charles R. Wright, Azimuth Systems

18. 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 802.11 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 Charles R. Wright, Azimuth Systems