Discussion of 40Mhz coexistence with 20MHz BSS in secondary channel

1. Discussion of 40Mhz coexistence with 20MHz BSS in secondary channel • Authors: • Date: 2008-05-14 Andrew Myles (Cisco)

2. 802.11n D4.0, 11.14.9 defines two ways for a 40MHz STA to act when it detects secondary channel energy • Before transmitting into the secondary channel a 40MHz STA checks CCA for a period of PIFS • The goal of this energy detect is to stop the 40MHz STA transmitting into a SIFS gap between frames in the secondary channel • There are other comments to ensure it actually does this • If energy is detected, 802.11n D4.0, 11.14.9 specifies two choices: • If a STA was unable to transmit a 40MHz mask PPDU because the secondary channel was occupied during this PIFS interval, it has two choices: • a) Transmit a 20 MHz mask PPDU. • b) Restart the channel access attempt. In this case, the STA shall invoke the back off procedure as specified in 9.9.1 as though an internal collision had taken place. Andrew Myles (Cisco)

3. The author submitted a comment suggesting the secondary channel is at a disadvantage • CCID xxxx comment • In LB115, CID 58796, I claimed that there is a risk of significant unfairness based on some unfairness shown in 06/608r2 and other documents. I suggested that a full CCA backoff on the secondary channel was required, noting that the same simulations showed no significant disadvantage to the 40MHz devices. Please refer to CIF 58796 for the full comment • The response from the TG was, "The simulation results in 06/608r1 demonstrate minimal degradation to legacy performance when a 40MHz HT BSS shares a secondary channel with a non-HT BSS and CCA is monitored for PIFS before the expiry of the backoff window. For an HT STA to update its NAV based on secondary channel traffic greatly increases implementation complexity." Andrew Myles (Cisco)

4. The author submitted a comment suggesting the secondary channel is at a disadvantage • CCID xxxx comment (cont) • I believe this response is "non-responsive" to the issues raised: • It is true 06/608 only shows "slight" (but not necessarily minimal) degradation in the particular environments simulated. However the response ignored the assertion that these simulations do not necessarily show the "worst case", and that some ":thought experiments" have highlighted "worse cases" • The response ignores the comment that the simulation also shows no disadvantage from undertaking a full backoff on the secondary channel, and so it is a worthwhile mechanism given the risk of not doing it. • The response notes that NAV on the secondary channel increases complexity. However, I made no request for a change relating to NAV. I did ask some questions relating to NAV that were ignored. Andrew Myles (Cisco)

5. The author proposed a change that provides more fairness or protection for the secondary channel • CCID xxxx recommended change • Specify a full CCA based backoff in the secondary channel, or allow devices in the secondary channel to signal they are intolerant to being in a secondary channel. Assume that legacy devices are intolerant to being in a secondary channel.. Andrew Myles (Cisco)

6. In 08/0524, Eldad Perahia concluded from simulation that 11.14.9 does not need any change Good-put (Mb/s) 11n Scenario (with loaded networks) 11a Total Eldad’s comments Eldad comments 90 - Control) 11n 20MHz in primary, 11a 20MHz in secondary 28 118 a) 11n 40MHz, but 20 MHz in primary when secondary busy, 11a 20MHz in secondary 94 27 121 Unfair to 11n; and hard to implement b) 11n 40 MHz, with back off in primary, 11a in secondary 77 14 91 Fair to 11n (apparently because 11a good-put halves) Andrew Myles (Cisco)

7. The author concludes each of the options has significant problems that must be fixed, if possible Good-put (Mb/s) 11n Scenario (with loaded networks) 11a Total Andrew’s comments 90 Works pretty well, but does not allow flexibility of 40MHz operation when 11a at low load Control) 11n 20MHz in primary, 11a 20MHz in secondary 28 118 a) 11n 40MHz, but 20 MHz in primary when secondary busy, 11a 20MHz in secondary 94 27 121 Works pretty well, & allows 40MHz op when 11a at low load; but hard to implement b) 11n 40 MHz, with back off in primary, 11a in secondary 77 14 91 Works well when 11a at low load but a disaster at high load Andrew Myles (Cisco)

8. It is appears there is scope to fix only option b) “Works” at low load in secondary Scenario (with loaded networks) “Works” at high load in secondary Easy to build? (fundamentalissue) Control) 11n 20MHz in primary, 11a 20MHz in secondary   a) 11n 40MHz, but 20 MHz in primary when secondary busy, 11a 20MHz in secondary   (fundamentalissue?) b) 11n 40 MHz, with back off in primary, 11a in secondary  (fixable issue?)  Andrew Myles (Cisco)

9. It is likely that further understanding of the problem is required to fix option b) • The author suspects the problem with option b) is that the 40MHz “stomps” on the 20MHz secondary channel too much • This may also apply to option a) to a lesser extent • This is probably because the 40MHz device pays too little attention to the state of the 20MHz secondary channel • If true then this suggests the 40MHz device should execute some sort of backoff mechanism based on the state of the secondary channel over a longer period, ie not just during PIFS • However, there appears to be a lack of understanding as to the underlying causes of the simulation results for option b) • Therefore, it is probably premature to impose a solution, eg a full backoff in the secondary channel • In the meantime, either • option b) should be removed from the draft • Secondary channels should be protected from option b) using intolerance signalling (with default intolerance for legacy) Andrew Myles (Cisco)