1 / 19

New Evidence that 11n Greenfield Devices Causes False RADAR Detections on DFS Channels

New Evidence that 11n Greenfield Devices Causes False RADAR Detections on DFS Channels. Authors:. Date: 2008-03-17. Latest tests provide conclusive evidence that Greenfield causes false detects in 11a devices on DFS channels.

aiko
Download Presentation

New Evidence that 11n Greenfield Devices Causes False RADAR Detections on DFS Channels

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. New Evidence that 11n Greenfield Devices Causes False RADAR Detections on DFS Channels • Authors: • Date: 2008-03-17 Chan et al. (Cisco Systems)

  2. Latest tests provide conclusive evidence that Greenfield causes false detects in 11a devices on DFS channels • Since D2.0, we’ve presented tests that showed Greenfield transmissions can cause false detects in 11a devices on DFS channels • 07/0329r2 (Mar 2007) and 07/2849r0 (Nov 2007) showed software MATLAB generated GF signals and those of VoIP traffic patterns cause false detects on 11a devices from different vendors • There were questions if this issue exists with GF transmissions by actual 11n hardware • So we performed tests with real VoIP traffic on WiFi certified Draft 11n Testbed devices and observed the same intensity of false detects • This is documented in 08/0301r1 and presented at the TGn pre-meeting last week • Because these tests involved one VoIP codec and were performed in a screen room, there were questions whether the codec was cherry-picked and whether the screen room represented real-world environment • Over the weekend, we performed the same tests with multiple different VoIP codecs and also on an open-space of an operating 11a deployed network • We observed the SAME INTENSITY of false detects on 11a devices • This new evidence dispels any uncertainty raised by doubters of this effect. • We can safely conclude that GF on DFS is indeed a real and common problem Chan et al. (Cisco Systems)

  3. Vendor X (802.11a device) Vendor X (802.11a device) Latest tests with WiFi draft 11n testbed devices show GF-DFS problem is beyond theoretical and commonly occurs Test Setup: Neighboring APs in range but on different channels Vendor Y (HT Greenfield Client on laptop) Bi-directional VoIP streams WAN Radar Detects!!! Vendor Z (HT Greenfield AP) Channel 52 Vendor Y (HT Greenfield Client on laptop) Vendor X (802.11a device) 11a clients generating real over the air network traffic Channel 52 Chan et al. (Cisco Systems)

  4. Same intensity of false detects with different VoIP codecs and open real WLAN environment More details on the test and setup: • VoIP streams were generated by IxChariot, industry designated network traffic generation and testing tool for WiFi certifications • Codec used include G.711U, G.723.1 (MPMLQ), G.723.1 (ACELP) and G.726 with default settings. • These codecs are very different and have large range of variations in their parameters, eg. packet size in bytes and time, interpacket spacing. (see backup slide for details) • Tests performed with various MCS (eg. 3, 4, 5, 6, 7 and 15) • False radar triggers began on every trial shortly after VoIP traffic began, eg. within 5 minutes • Results did not change when laptop clients were loaded with ping traffic • Vendor X Legacy APs did not have any record of falsing before tests commenced or between tests Chan et al. (Cisco Systems)

  5. Sample screen shot of Chariot VoIP test Chan et al. (Cisco Systems)

  6. 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)

  7. GF on DFS problem is not a late-breaking issue and is an industry-wide 802.11 concern • 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 • 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 • We performed a set of measurements with another legacy 11a receiver and presented them in submission 07/2849r0 in Nov 2007 (Atlanta) • Strawpoll showed an even more significant fraction of the TGn Coex Ad Hoc members – a majority – agreeing for a text change to address this • We hypothesized and presented in Feb 2008 telecon with 08/0111r2 that the problem may be related to DFS requirement for detecting the bin-5 radar profile • Now we show compelling and conclusive evidence of this problem • Overall our tests have shown at least two different 11a chipsets and at least two different vendors that would have falsing issues due to software generated GF VoIP transmissions • The problem is probably not limited to VoIP GF transmissions too • This is an industry-wide 802.11 concern Chan et al. (Cisco Systems)

  8. Preferred 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)

  9. 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 08/0302r5. 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)

  10. Illustration of Option 2’s proposed mechanism: AP detects non-HT OBSS (2/4) Operation on a DFS Band Covered by proposed text changes in 08/0302r5. Beacon HT Greenfield AP Non-HT AP HT Information Element OBSS Non-HT STAs Present 0 1 HT Greenfield AP sets its Greenfield support bit from 1 to 0 and OBSS Non-HT STAs Present bit from 0 to 1. Chan et al. (Cisco Systems)

  11. Illustration of Option 2’s proposed mechanism: AP detects non-HT OBSS (3/4) Operation on a DFS Band Covered by proposed text changes in 08/0302r5. 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)

  12. Illustration of Option 2’s proposed mechanism: AP detects non-HT OBSS (4/4) Operation on a DFS Band Covered by proposed text changes in 08/0302r5. After waiting 30 min… HT Greenfield AP Non-HT AP HT Information Element OBSS Non-HT STAs Present 1 0 If non-HT AP does not exist anymore, HT Greenfield AP can revert to its previous settings after thirty minutes. (Thirty min is a value defined as a the MIB variable that has range from 30 min to 48 hrs.) Chan et al. (Cisco Systems)

  13. Proposed prevention mechanism is simple and low impact to existing 11n implementations Merits of the proposed prevention mechanism • Simple to implement and deploy via a software upgrade • No monitoring or scanning on clients at all • Monitoring of non-HT OBSS only on the AP • Nothing required of clients other than changing their behavior according to AP’s beacon (which is the default and expected behavior for 11n STAs), and disabling GF for other (i.e. DLS) links on DFS channels when GF is disabled by the AP • No new fields but re-uses existing 11n bits and signaling schemes • Minor changes from D2.0 behavior • Preserves 11n GF evolution path • Achieves true definition of having a “greenfield”. Chan et al. (Cisco Systems)

  14. 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 • Submission 08/0111r2 • Submission 08/0301r0 • Submission 08/0302r0 Chan et al. (Cisco Systems)

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

  16. Default Parameters of VoIP Codecs show large variations Excerpted from http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml Chan et al. (Cisco Systems)

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

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

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

More Related