May 2008

Andrew Myles (Cisco)

Slide 1

doc.: IEEE 802.11-08/0633r0

Submission

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

Date: 2008-05-14

Name Company Address Phone E-mail

Andrew Myles Cisco +61 2 84461010 andrew.myles@cisco.com

Authors:

May 2008

Andrew Myles (Cisco)

Slide 2

doc.: IEEE 802.11-08/0633r0

Submission

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.

May 2008

Andrew Myles (Cisco)

Slide 3

doc.: IEEE 802.11-08/0633r0

Submission

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."

May 2008

Andrew Myles (Cisco)

Slide 4

doc.: IEEE 802.11-08/0633r0

Submission

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.

May 2008

Andrew Myles (Cisco)

Slide 5

doc.: IEEE 802.11-08/0633r0

Submission

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..

May 2008

Andrew Myles (Cisco)

Slide 6

doc.: IEEE 802.11-08/0633r0

Submission

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 28 118

11n 11a Total

94 27 121

77 14 91

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

May 2008

Andrew Myles (Cisco)

Slide 7

doc.: IEEE 802.11-08/0633r0

Submission

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 28 118

11n 11a Total

a) 11n 40MHz, but 20 MHz in primary when secondary busy,

11a 20MHz in secondary 94 27 121

b) 11n 40 MHz, with back off in primary, 11a in secondary

77 14 91

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

May 2008

Andrew Myles (Cisco)

Slide 8

doc.: IEEE 802.11-08/0633r0

Submission

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

(fundamentalissue?)

b) 11n 40 MHz, with back off in primary, 11a in secondary

(fixable issue?)

Scenario (with loaded networks)

May 2008

Andrew Myles (Cisco)

Slide 9

doc.: IEEE 802.11-08/0633r0

Submission

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)