1. doc.: IEEE 802.11-08/0315r1 Submission Mar 2008 Hart (Cisco Systems) Slide 1 Coexistence Mechanisms at 5 GHz Date: 2008-03-17 Authors:

2. doc.: IEEE 802.11-08/0315r1 Submission Mar 2008 Hart (Cisco Systems) Slide 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

3. doc.: IEEE 802.11-08/0315r1 Submission Mar 2008 Hart (Cisco Systems) Slide 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

4. doc.: IEEE 802.11-08/0315r1 Submission Mar 2008 Hart (Cisco Systems) Slide 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)

5. doc.: IEEE 802.11-08/0315r1 Submission Mar 2008 Hart (Cisco Systems) Slide 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)

6. doc.: IEEE 802.11-08/0315r1 Submission Mar 2008 Hart (Cisco Systems) Slide 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

7. doc.: IEEE 802.11-08/0315r1 Submission Mar 2008 Hart (Cisco Systems) Slide 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

8. doc.: IEEE 802.11-08/0315r1 Submission Mar 2008 Hart (Cisco Systems) Slide 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

9. doc.: IEEE 802.11-08/0315r1 Submission Mar 2008 Hart (Cisco Systems) Slide 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

10. doc.: IEEE 802.11-08/0315r1 Submission Mar 2008 Hart (Cisco Systems) Slide 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

11. doc.: IEEE 802.11-08/0315r1 Submission Mar 2008 Hart (Cisco Systems) Slide 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?

12. doc.: IEEE 802.11-08/0315r1 Submission Mar 2008 Hart (Cisco Systems) Slide 12 Questions? ?

13. doc.: IEEE 802.11-08/0315r1 Submission Mar 2008 Hart (Cisco Systems) Slide 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: