1 / 25

Greenfield VoIP Transmissions Cause False RADAR Triggers

This article discusses the issue of false RADAR triggers caused by Greenfield VoIP transmissions in the 802.11a industry. It presents the results of experiments and measurements, highlighting the need for a suitable mechanism to prevent Greenfield operations in the presence of legacy 11a devices. The proposed mechanism is simple to implement and does not hinder the evolution path of 11n Greenfield. Recommendations are provided to address the disruptive effects on legacy devices in the DFS bands.

jbillingsley
Download Presentation

Greenfield VoIP Transmissions Cause False RADAR Triggers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Greenfield VoIP Transmissions Cause False RADAR Triggers • Authors: • Date: 2008-02-19 Chan et al. (Cisco Systems)

  2. Recap of previous investigations on this issue • In LB 97 (Draft 1.0), there were CIDs which pointed out that GF transmissions can be falsely detected by legacy devices in the DFS band as radar • We performed experiments and presented a submission, 07/0329r2, in March 2007 (Orlando) to discuss the results • We showed that a widely used receiver hardware gave false positive radar detects for VoIP traffic using Greenfield mode • Strawpolls showed a significant fraction of the TGn Coex Ad Hoc members are concerned with this problem, but more investigations should be done to be certain • Subsequently, we performed a set of measurements with another legacy 11a receiver and presented them in submission 07/2849r0 in Nov 2007 (Atlanta) • Again, false positive radar detects are observed for VoIP traffic using Greenfield mode • Strawpoll showed an even more significant fraction of the TGn Coex Ad Hoc members – a majority – agreeing for a text change to address this Chan et al. (Cisco Systems)

  3. Latest tests show GF-DFS problem can be widespread in 802.11a industry • Since then we’ve continued to perform testing with various 11a chipsets and vendor implementations • In our analysis, we also found that the bin-5 algorithm that is part of the minimum present-day FCC DFS certification strongly resembles a “GF voice detector” – thus this is a widespread problem • In our measurements, our latest tests have shown at least two 11a chipsets and two vendors that would have falsing issues due to GF voice transmissions • Whether or not these include the bin-5 algorithm, with the same GF-DFS problem occurring on independently-implemented legacy 11a hardware, this is compelling evidence that GF-DFS is a serious 11n issue that we need to address Chan et al. (Cisco Systems)

  4. Preferred Recommendations: • 802.11n should be changed to prevent GF’s potentially disruptive effects to legacy 11a devices in the DFS bands • There’re two options to solving this problem: • 1. Prohibit Greenfield operations in DFS bands or • 2. Define a suitable mechanism to prevent Greenfield operation in DFS bands in the presence of legacy 11a devices • Simple to implement since it reuses existing 11n schemes to signal when GF can be used. • Involves only a software upgrade/change. • More importantly, this mechanism doesn’t affect 11n GF evolution path, as 11a devices get phased out in the next few years, GF wouldn’t be prevented from use due to this prohibition. • True to the definition of having a “greenfield”. Chan et al. (Cisco Systems)

  5. Illustration of Option 2’s proposed mechanism: AP detects non-HT OBSS (1/4) Operation on a DFS Band Covered by proposed text changes in Slide 15. HT Greenfield Transmissions HT Greenfield Transmissions Beacon HT Greenfield AP Non-HT AP HT Greenfield Clients During operations or when establishing a BSS, an HT Greenfield AP receives beacon from a non-HT AP, thus detecting a non-HT OBSS. Chan et al. (Cisco Systems)

  6. Illustration of Option 2’s proposed mechanism: AP detects non-HT OBSS (1/4) Operation on a DFS Band Covered by proposed text changes in Slide 15. HT Capabilities Info Field Beacon Greenfield bit: 1 0 HT Greenfield AP Non-HT AP HT Greenfield AP sets its Greenfield support bit from 1 to 0. Chan et al. (Cisco Systems)

  7. Illustration of Option 2’s proposed mechanism: AP detects non-HT OBSS (1/4) Operation on a DFS Band Covered by proposed text changes in Slide 15. HT Mixed Mode Transmissions HT Mixed Mode Transmissions Beacon HT Greenfield AP Non-HT AP HT Greenfield Clients Greenfield transmissions are then suppressed across this BSS. Non-HT OBSS is not disrupted by 11n BSS. Chan et al. (Cisco Systems)

  8. Illustration of Option 2’s proposed mechanism: AP detects non-HT OBSS (1/4) Operation on a DFS Band Covered by proposed text changes in Slide 15. After waiting 30 min… HT Capabilities Info Field Greenfield bit: 0 1 HT Greenfield AP Non-HT AP If non-HT AP does not exist anymore, HT Greenfield AP can set its Greenfield support bit from 0 to 1 after thirty minutes Chan et al. (Cisco Systems)

  9. Illustration of Option 2’s proposed mechanism: AP detects non-HT OBSS (1/4) A client detects non-HT OBSS Operation on a DFS Band Covered by proposed text changes in Slide 15. HT Mixed Mode Transmissions HT Greenfield Transmissions HT Greenfield Clients Beacon Non-HT AP HT Greenfield AP Greenfield transmissions are also suppressed by individual STAs if they detect any non-HT OBSS. (Note scenario here, the HT GF AP is out of range from the non-HT AP.) Chan et al. (Cisco Systems)

  10. Illustration of mechanism under consideration: Client notifies GF AP of non-HT OBSS (1/2) Operation on a DFS Band Not covered by proposed text changes in Slide 15. Should we consider this too?? HT Mixed Mode Transmissions HT Greenfield Transmissions HT Greenfield Clients Beacon Some action frame to notify detection of non-HT AP. Non-HT AP HT Greenfield AP HT Greenfield Transmissions HT GF clients also send some action frame to notify the HT GF AP of the non-HT OBSS. HT Greenfield Clients Chan et al. (Cisco Systems)

  11. Illustration of mechanism under consideration: Client notifies GF AP of non-HT OBSS (2/2) Operation on a DFS Band Not covered by proposed text changes in Slide 15. Should we consider this too?? HT Mixed Mode Transmissions This protocol is more involved, as an action frame is created, etc. HT Mixed Mode Transmissions HT Greenfield Clients Beacon Some action frame to notify detection of non-HT AP. Non-HT AP HT Greenfield AP HT Capabilities Info Field HT Mixed Mode Transmissions HT GF AP subsequently sets its Greenfield bit to 0 and suppress its BSS from using GF, for at least 30 min since the last non-HT OBSS notification was received or detected. Greenfield bit: 1 0 HT Greenfield Clients Chan et al. (Cisco Systems)

  12. False radar detects with GF is due to fundamental DFS requirements • Results from previous investigations lead us to postulate something fundamental must have been violated by GF transmissions… • It turns out, according to FCC Part 15 Subpart E (Appendix on DFS compliance), one of the waveforms required to be successfully detected looks exactly like typical VoIP traffic • This is the long-pulse radar or “bin-5” waveform: [Excerpted from Appendix to FCC Part 15 Subpart E] Chan et al. (Cisco Systems)

  13. Option 2 only requires a minor change to the 11n draft • TGn Editor: Editing instructions preceded by “TGn Editor” are instructions to the TGn editor to modify existing material in the TGn draft. As a result of adopting the changes, the TGn editor will execute the instructions rather than copy them to the TGn Draft. • TGn Editor: Please insert the following new subclause following subclause 11.9.8.4 Channel management at the AP and in an IBSS, on page 213 of D3.02. 11.9.8.5 HT Greenfield transmissions in DFS bands The requirements described in this subclause apply only when the HT STA is operating in a regulatory class subject to DFS procedures. A Non-HT OBSS Scan operation is a passive or active scan of the channel on which a STA currently uses or intends to use. During a Non-HT OBSS Scan, the channel scan duration is a minimum of 200 TU when scanning passively and a minimum of 20 TU when scanning actively. Before an HT STA starts a BSS supporting the HT Greenfield mode, it shall perform a Non-HT OBSS Scan to search for any existing non-HT BSSs. Before an HT STA changes the Greenfield bit in the HT Capabilities Info field in a beacon or probe response from 0 to 1, the HT STA shall perform a Non-HT OBSS Scan to search for any existing non-HT BSSs. Chan et al. (Cisco Systems)

  14. (Continued) An HT STA shall set the Greenfield bit of its HT Capabilities Info field in a beacon or probe response to 0 to indicate no support of HT Greenfield mode when there is one or more non-HT BSS overlapping (a non-HT BSS may be detected by the reception of a Beacon where the supported rates only contain Clause 17 rates). The value of this bit can be changed after a minimum of 30 minutes have elapsed since the last detection of an overlapping non-HT BSS. An HT STA shall not transmit PPDUs in the HT Greenfield format when there is one or more non-HT BSS overlapping (a non-HT BSS here may be detected by the reception of a Beacon where the supported rates only contain Clause 17 rates) for a minimum of 30 minutes since the last detection of an overlapping non-HT BSS. <End of editing instructions.> Chan et al. (Cisco Systems)

  15. Option 2 solution resolves three comments: LB 115 (Draft 3.0) comments: Chan et al. (Cisco Systems)

  16. Strawpoll • Task Group n should design the specification to appropriately account for and prevent GF’s potential disruptive effects to legacy 11a devices in the DFS bands. Accept the resolutions proposed for CIDs 5123, 5363 and 5795 in 08/0111r0, i.e. the draft text changes with editor instructions on Slide 13-14 of 08/0111r0. • Yes • No • Abstain Chan et al. (Cisco Systems)

  17. References • “Compliance Measurement Procedures for Unlicensed-national Information Infrastructure Devices Operating In The 5250-5350 Mhz and 5470-5725 Mhz Bands Incorporating Dynamic Frequency Selection”, Appendix to Revision of Parts 2 and 15 of the Commission’s Rules to Permit Unlicensed National Information Infrastructure (U-NII) devices in the 5 GHz band, FCC 06-96, June 30, 2006. • Submission 07/0329r2 • Submission 07/2849r0 Chan et al. (Cisco Systems)

  18. Backup slides Chan et al. (Cisco Systems)

  19. The bin-5 algorithm explained • In order to detect this waveform, a typical bin-5 algorithm will look for: • Pairs (or triplets) of pulses between 50 to 100 usec wide with spacing of 1 to 2 ms between pulses [Excerpted from Appendix to FCC Part 15 Subpart E] Chan et al. (Cisco Systems)

  20. The bin-5 algorithm and typical VoIP traffic • But this corresponds exactly to a typical VoIP transmission ! • For example, a 230-byte client transmission (76 usec) followed 1.016 ms later by the AP's 230-byte transmission (76 usec) • If the AP detects three or more such pairs in a sliding 12-second window, a radar detect will be triggered • Note: The ACKs do not affect this detection at all, since the "bin-5" algorithm only processes the 50-100 usec pulses • So legacy receivers implementing the minimum requirements for DFS compliance would produce false positive radar detects whenever in the presence of GF VoIP transmissions VoIP traffic pattern used in experiments Chan et al. (Cisco Systems)

  21. Detrimental consequences expected from GF on DFS Bands • Operations of legacy 802.11a networks which have no concept of Greenfield mode would be disrupted by their false detects from GF transmissions by moving to another channel each time • Many mesh network architectures use the 5 GHz band for backhaul • A single voice call using GF transmissions could bring down a mesh tree while it changes channel. • A small number of GF APs using efficient channel selection can totally occupy the 5 GHz band and cause a mesh network outage. • This type of behavior also facilitates possibilities of simple denial of service attacks • There is nothing in the DFS regulations that indicate radar may be ignored if preceded by MAC protection. Therefore protection is ineffective for GF preambles in DFS bands. Chan et al. (Cisco Systems)

  22. Excerpted from Nov 2007 (Atlanta) Coex Ad Hoc Minutes: Chan et al. (Cisco Systems)

  23. Recap of previous investigations on this issue Chan et al. (Cisco Systems)

  24. Recap of previous investigations on this issue • GF transmission sent according to a typical VoIP packet stream • 50 packet sequences at each power level … Chan et al. (Cisco Systems)

  25. Recap of previous investigations on this issue Chan et al. (Cisco Systems)

More Related