Title: Chan et al. (Cisco Systems) Slide 1. doc.: IEE
1New Evidence that 11n Greenfield Devices Causes
False RADAR Detections on DFS Channels
Authors
2Latest tests provide conclusive evidence that
Greenfield causes false detects in 11a devices on
DFS channels
- Since D2.0, weve 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
3Latest 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
4Same 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
5Sample screen shot of Chariot VoIP test
6Detrimental 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.
7GF 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
8802.11n should be changed to prevent GFs
potentially disruptive effects to legacy 11a
devices in the DFS bands
- Therere 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 doesnt affect
11n GF evolution path, as 11a devices get phased
out in the next few years, GF wouldnt be
prevented from use due to this prohibition. - True to the definition of having a greenfield.
9Illustration of Option 2s 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.
10Illustration of Option 2s 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
HT Greenfield AP sets its Greenfield support bit
from 1 to 0 and OBSS Non-HT STAs Present bit from
0 to 1.
0 1
11Illustration of Option 2s 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.
12Illustration of Option 2s 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
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.)
1 0
13Proposed 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 APs 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.
14References
- 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 Commissions 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
15Backup slides
16Default Parameters of VoIP Codecs show large
variations
Excerpted from http//www.cisco.com/en/US/tech/tk6
52/tk698/technologies_tech_note09186a0080094ae2.sh
tml
17Excerpted from Nov 2007 (Atlanta) Coex Ad Hoc
Minutes
18Recap of previous investigations on this issue
19Recap of previous investigations on this issue