1. doc.: IEEE 802.11-08/0633r0 Submission May 2008 Andrew Myles (Cisco)Slide 1 Discussion of 40Mhz coexistence with 20MHz BSS in secondary channel Date: 2008-05-14 Authors:

2. doc.: IEEE 802.11-08/0633r0 Submission May 2008 Andrew Myles (Cisco)Slide 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.

3. doc.: IEEE 802.11-08/0633r0 Submission May 2008 Andrew Myles (Cisco)Slide 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."

4. doc.: IEEE 802.11-08/0633r0 Submission May 2008 Andrew Myles (Cisco)Slide 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.

5. doc.: IEEE 802.11-08/0633r0 Submission May 2008 Andrew Myles (Cisco)Slide 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..

6. doc.: IEEE 802.11-08/0633r0 Submission May 2008 Andrew Myles (Cisco)Slide 6 In 08/0524, Eldad Perahia concluded from simulation that 11.14.9 does not need any change Unfair to 11n; and hard to implement Fair to 11n (apparently because 11a good-put halves) - Eldad comments 90 28118 11n 11aTotal 9427121 771491 Scenario (with loaded networks) Good-put (Mb/s) Eldad’s comments Control) 11n 20MHz in primary, 11a 20MHz in secondary a) 11n 40MHz, but 20 MHz in primary when secondary busy, 11a 20MHz in secondary b) 11n 40 MHz, with back off in primary, 11a in secondary

7. doc.: IEEE 802.11-08/0633r0 Submission May 2008 Andrew Myles (Cisco)Slide 7 The author concludes each of the options has significant problems that must be fixed, if possible Control) 11n 20MHz in primary, 11a 20MHz in secondary 90 28118 11n 11aTotal a) 11n 40MHz, but 20 MHz in primary when secondary busy, 11a 20MHz in secondary 9427121 b) 11n 40 MHz, with back off in primary, 11a in secondary 771491 Scenario (with loaded networks) Good-put (Mb/s) Works pretty well, & allows 40MHz op when 11a at low load; but hard to implement Works well when 11a at low load but a disaster at high load Works pretty well, but does not allow flexibility of 40MHz operation when 11a at low load Andrew’s comments

8. doc.: IEEE 802.11-08/0633r0 Submission May 2008 Andrew Myles (Cisco)Slide 8 It is appears there is scope to fix only option b) Control) 11n 20MHz in primary, 11a 20MHz in secondary  (fundamental issue) “Works” at low load in secondary “Works” at high load in secondary Easy to build? a) 11n 40MHz, but 20 MHz in primary when secondary busy, 11a 20MHz in secondary  (fundamental issue?) b) 11n 40 MHz, with back off in primary, 11a in secondary  (fixable issue?) Scenario (with loaded networks)

9. doc.: IEEE 802.11-08/0633r0 Submission May 2008 Andrew Myles (Cisco)Slide 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)