Post on 03-Jan-2016
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)