Coexistence Mechanisms at 5 GHz

1. Coexistence Mechanisms at 5 GHz • Authors: • Date: 2008-03-17 Hart (Cisco Systems)

2. Summary • There are several options to help VHT/legacy coexistence at 5 GHz • Coexistence with a dozen flavors of ignorant 11n legacy adds a lot of overhead and can be ineffective • VHT/legacy coexistence could be assisted by proposing functionality now for 802.11n devices • The sooner the functionality is identified and implemented, the more devices in the market can be VHT5-friendly, or at least SW-upgradeable to be VHT5-friendly, in the 3-5 years when & if VHT5 appears Hart (Cisco Systems)

3. Coexistence with Legacy Adds a Lot of Over-the-Air and Standards Overhead • To support 802.11b/11g coexistence, 802.11g provided: • MAC protection • A “mixed-mode” frame format with a DSSS preamble prefixed to an OFDM payload • 96 us of overhead • Not that much better than MAC protection • 802.11g performance (~6 Mbps at top-of-MAC) is poor relative to 11a (~20 Mbps at top-of-MAC • To support 802.11n/11a coexistence, 802.11n introduced many features: • Mixed-Mode frame format with an 11a preamble prefixed to an MIMO-OFDM payload • 12 us of overhead • More useful, but inefficient enough that Greenfield preamble added too • LSIG TXOP protection • No guarantee with legacy • PCO • And MAC protection is often enabled anyway • Performance degrades significantly with protection Hart (Cisco Systems)

4. Coexistence Options - 1 • Channel reservation • VHT5: • sends beacons at non-legacy rates • performs TXOP chaining to reserve 100% of the medium from legacy (e.g. 3ms CTS2self every 3ms) • has to leave some channels if legacy is present • Coexistence pros • 802.11n APs might recognize the behavior and move to another channel • Coexistence cons • This is the nuclear option, indistinguishable from a DoS attack • (It is a DoS attack) Hart (Cisco Systems)

5. Coexistence Options - 2 • Channel reservation • VHT5: • regularly sends a public action frame at a legacy rate to indicate “channel reserved for VHT5 devices” • has to leave some channels unused if legacy is present • Coexistence pros • 802.11n APs recognize the frame and avoid the channel • Coexistence cons • This is another nuclear option, indistinguishable from a DoS attack • (It is a DoS attack, and creates a new, gaping security hole) • (This might work if it were a hint, e.g. in a beacon) Hart (Cisco Systems)

6. Coexistence Options - 3 • Time-slicing • PCO for VHT5 • Requires channel reservation on every 20 (40?) MHz channel sought • For wide utility, the PCO phase needs to be shared between overlapping PCO BSSs • And in a large network of APs, this means AP synchronization • Coexistence pros • Reliable compliance • Coexistence cons • Time-slices above 10-20 ms may not allow adequate QoS for legacy applications • Channel access is slow Hart (Cisco Systems)

7. Coexistence Options - 4 • TXOP contention • Generalization of duplicate-mode CTS2self’s • N CTS2self’s sent on N/2 40 MHz channels • Coexistence pros • Reliable compliance • Coexistence cons • Not as efficient as later methods • Channel access is slow Hart (Cisco Systems)

8. Coexistence Options - 5 • Mixed-mode frame • Generalization of 11n mixed-mode frame • 11a preamble may be spoofed (if done with 3-5 years notice) • Reserved bit (L-Rate field possibly freed up) • Unused 11a rate code • 9 Mbps L-Rate field plus the 90deg phase shift • 6 Mbps L-Rate field plus the 90deg phase shift plus adding 1 to the spoofed L-Length (note: 3 values of L-Length field can spoof the same duration; 11n only needs to use 1 of these 3 values so VHT5 could use another) • Greenfield preambles may be spoofed via similar methods • Coexistence pros • Very efficient • Coexistence cons • Channel access is slow Hart (Cisco Systems)

9. Coexistence Options - 6 • LSIG-TXOP protection • Generalization of LSIG-TXOP protection • If VHT5 defined a new mixed-mode frame, with a spoofed L-Length, then allow the spoofed length to protect multiple frames • Coexistence pros • Most efficient • Coexistence cons • Channel access is slow Hart (Cisco Systems)

10. Coexistence – Slow Channel Access from Options 3-6 • Need to set the NAV on N = 4/6/8 channels to use N*20MHz bandwidth • Parallel channel access to N = 4/6/8 channels is unlikely – must backoff for a long time • Serial channel access on N = 4/6/8 channels is inefficient • Hybrid parallel/serial mode is better, but still far from perfect • First, reserve the clear channels, then wait until other channels become clear and reserve them, & repeat • Needs long TXOPs to justify the overhead – may not allow adequate QoS for legacy applications • The first iteration of the hybrid mode has acceptable overhead • Reserve the n <= N clear channels and transmit on n channels • Creates many new MAC/PHY issues yet passes the coexistence laugh test Hart (Cisco Systems)

11. Possible Requirements on 11n Devices • [Option 2] Understand the public action frame indicating channel reservation (!?) or hint in a beacon • [Option 5/6] Set the NAV for the duration indicated by L-Rate/L-Length if: • Reserved bit is set (can possibly use the L-LENGTH with an implicit PHY rate to free up L-RATE) • Unused 11a rate code • 9 Mbps L-Rate field plus the 90deg phase shift • 6 Mbps L-Rate field plus the 90deg phase shift plus adding 1 to the spoofed L-Length • [Option 6] Respect LSIG-TXOP protection even for VHT5 preambles • Enable/disable these behaviors via a MIB variable? Hart (Cisco Systems)

12. Questions? • ? Hart (Cisco Systems)

13. Strawpoll • If VHT produced a PAR for 5 GHz operation, do you believe 802.11n should pre-define an optional, VHT5-friendly spoofing mechanism, that may be disabled/enabled via a MIB variable? • Yes: • No: • Abstain: Hart (Cisco Systems)