Date post: | 27-Mar-2015 |
Category: |
Documents |
Upload: | allison-mason |
View: | 213 times |
Download: | 0 times |
March 2008
Chan et al. (Cisco Systems)Slide 1
doc.: IEEE 802.11-08/0301r0
Submission
VoIP Traffic by Draft-n Greenfield Devices Causes False RADAR Detection on DFS Channels
Date: 2008-03-12
Name Affiliation Address Phone email Douglas Chan Cisco Systems 170 West Tasman Drive,
San Jose, CA 95134 408-527-9344 [email protected]
Brian Hart Cisco Systems 170 West Tasman Drive, San Jose, CA 95134
408-525-3346 [email protected]
Lian Jiang Cisco Systems 170 West Tasman Drive, San Jose, CA 95134
408-853-1899 [email protected]
Jan Kruys Cisco Systems Haarlerbergpark, Haarlerbergweg 13-19, Amsterdam, Netherlands 1101 CH
+31-20-357-2447 [email protected]
Malik Audeh Tropos Networks 555 Del Rey Ave Sunnyvale, CA 94085
408-331-6835 [email protected]
Jorjeta Jetcheva Firetide, Inc.
16795 Lark Ave, Suite 200 Los Gatos, CA 9503
408-355-7215 [email protected]
Stephen Rayment BelAir Networks 603 March Road Kanata ON Canada K2K 2M5
613-254-7070 x112
Authors:
March 2008
Chan et al. (Cisco Systems)Slide 2
doc.: IEEE 802.11-08/0301r0
Submission
Straw polls have previously shown support to change 11n to avoid radar issues caused by GF • 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
March 2008
Chan et al. (Cisco Systems)Slide 3
doc.: IEEE 802.11-08/0301r0
Submission
The GF-DFS problem is an industry-wide 802.11a problem
• Since then we’ve continued to perform testing with various 11a chipsets and vendor’s DFS implementations
• In our analysis, we also found that the bin-5 radar profile which is part of the current FCC DFS certification strongly resembles a “GF voice detector” – thus this is a widespread problem
• 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
• In our latest tests, we went further and employed WiFi Draft n testbed devices and actual mixed data and VoIP traffic network traffic. The results showed these GF transmissions unmistakably and consistently caused an 11a device to trigger radar detects.
March 2008
Chan et al. (Cisco Systems)Slide 4
doc.: IEEE 802.11-08/0301r0
Submission
Latest tests with WiFi draft 11n testbed devices show GF-DFS problem is beyond theoretical
Vendor Z
(HT Greenfield AP)
Test SetupVendor Y
(HT Greenfield Client on laptop)
Vendor Y
(HT Greenfield Client on laptop)
Vendor X
(802.11a device)
All devices on Channel 52 (a DFS channel)
Experiment performed in screen room.
Two bi-directional VoIP streams and ping traffic
Radar detects
March 2008
Chan et al. (Cisco Systems)Slide 5
doc.: IEEE 802.11-08/0301r0
Submission
More details on the test setup:
• VoIP streams were generated by IxChariot, industry designated network traffic generation and testing tool for WiFi certifications
• Voice codec used was G.711U with default settings:
• Test performed with MCS 3, 4, 5, 6, 7 and 15. False radar triggers began on every trial shortly after VoIP traffic began, eg. less than 5 minutes
• Results did not change when laptop clients were loaded with ping traffic
Radar triggers with various test setup show GF-DFS is easy to occur and consistent
March 2008
Chan et al. (Cisco Systems)Slide 6
doc.: IEEE 802.11-08/0301r0
Submission
Sample screen shot of Chariot VoIP test
March 2008
Chan et al. (Cisco Systems)Slide 7
doc.: IEEE 802.11-08/0301r0
Submission
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.
March 2008
Chan et al. (Cisco Systems)Slide 8
doc.: IEEE 802.11-08/0301r0
Submission
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”.
Preferred
March 2008
Chan et al. (Cisco Systems)Slide 9
doc.: IEEE 802.11-08/0301r0
Submission
Illustration of Option 2’s proposed mechanism: AP detects non-HT OBSS (1/4)
HT Greenfield AP
Operation on a DFS Band
Non-HT AP
Beacon
During operations or when establishing a BSS,
an HT Greenfield AP receives beacon from a
non-HT AP, thus detecting a non-HT OBSS.
HT Greenfield Transmissions
HT Greenfield Clients
HT Greenfield Transmissions
Covered by proposed text changes in 08/0302r0.
March 2008
Chan et al. (Cisco Systems)Slide 10
doc.: IEEE 802.11-08/0301r0
Submission
Illustration of Option 2’s proposed mechanism: AP detects non-HT OBSS (2/4)
HT Greenfield AP
Operation on a DFS Band
Non-HT AP
Beacon
HT Greenfield AP sets its Greenfield support bit from 1 to 0 and OBSS Non-HT STAs
Present bit from 0 to 1.
HT Capabilities Info Field
Greenfield bit:
1 0
Covered by proposed text changes in 08/0302r0.
HT Infomration Element
OBSS Non-HT STAs Present
0 1
March 2008
Chan et al. (Cisco Systems)Slide 11
doc.: IEEE 802.11-08/0301r0
Submission
Illustration of Option 2’s proposed mechanism: AP detects non-HT OBSS (3/4)
HT Greenfield AP
Operation on a DFS Band
Non-HT AP
Beacon
Greenfield transmissions are then suppressed across this BSS.
Non-HT OBSS is not disrupted by 11n BSS.
HT Mixed Mode Transmissions
HT Greenfield Clients
HT Mixed Mode Transmissions
Covered by proposed text changes in 08/0302r0.
March 2008
Chan et al. (Cisco Systems)Slide 12
doc.: IEEE 802.11-08/0301r0
Submission
Illustration of Option 2’s proposed mechanism: AP detects non-HT OBSS (4/4)
HT Greenfield AP
Operation on a DFS Band
Non-HT AP
If non-HT AP does not exist anymore, HT Greenfield AP can revert to its previous settings after thirty minutes
HT Capabilities Info Field
Greenfield bit:
0 1
After waiting 30 min…
Covered by proposed text changes in 08/0302r0.
HT Infomration Element
OBSS Non-HT STAs Present
1 0
March 2008
Chan et al. (Cisco Systems)Slide 13
doc.: IEEE 802.11-08/0301r0
Submission
Option 2 solution resolves three comments:
CID Commenter
Type of Comment
Part of No Vote
Clause Comment Proposed Change Resolution
5123 Chan, Douglas
T Y 9.13.3 Transmission of GF preambles in DFS bands can cause DFS false alarms on legacy STAs. Thre 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.
Prohibit GF in DFS bands.
Accept; as in editor instructions in submission 08/0302r0.
5795 Stephenson, Dave
5363 Hart, Brian
LB 115 (Draft 3.0) comments:
March 2008
Chan et al. (Cisco Systems)Slide 14
doc.: IEEE 802.11-08/0301r0
Submission
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/301r0, i.e. the draft text changes with editor instructions in 08/0302r0.
Yes
No
Abstain
March 2008
Chan et al. (Cisco Systems)Slide 15
doc.: IEEE 802.11-08/0301r0
Submission
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
March 2008
Chan et al. (Cisco Systems)Slide 16
doc.: IEEE 802.11-08/0301r0
Submission
Backup slides
March 2008
Chan et al. (Cisco Systems)Slide 17
doc.: IEEE 802.11-08/0301r0
Submission
Excerpted from Nov 2007 (Atlanta) Coex Ad Hoc Minutes:
March 2008
Chan et al. (Cisco Systems)Slide 18
doc.: IEEE 802.11-08/0301r0
Submission
Recap of previous investigations on this issue
March 2008
Chan et al. (Cisco Systems)Slide 19
doc.: IEEE 802.11-08/0301r0
Submission
Recap of previous investigations on this issue