- This topic has 32 replies, 1 voice, and was last updated 8 years, 7 months ago by
.
-
Posts
-
On Sun, Sep 27, 2015 at 2:59 PM -0700, “Chuck Lukaszewski”
Starting a thread on this among a handful of us based on yesterday’s discussion. Ronald clued me into the Twitter feed on this topic but I think we want to have this discussion offline for now. Oh, and I’m not on Twitter…
Let me start by saying that I would love to be wrong, and part of the reason I pulled this material together was to force the discussion so that I would be corrected if that is the case.
But this has been an active area of discussion in 802.11ax in the spatial reuse ad hoc and none of the numerous silicon vendor representatives has ever stood up and said this is false. In fact, some of them have presented CCA research using a -92 threshold. (e.g. 14/0846r0 and 14/1199r1 by QCA).
Anyway, I will go back through some of my field/lab tests and look for specific evidence to back up the claim. In the meantime, here are a couple of ways to test for this:
- Set up 2 BSS with 1 STA each, where each BSS can only hear the other at say -85 or -90 dBm. Sum of an iPerf test with both BSS at same time should be same as running either BSS solo.
- Could be done with 2 RF enclosure boxes joined by variable attenuators
- Could be done in a building perhaps 150’ x 150’ putting APs in offices on opposite sides of building
- Set up 1 BSS with 1 STA, with a sensor machine separated by -85 or -90dBm. Sensor machine (vendor AP?) must have a stats counter that will show CCA state. Run an iperf test in the BSS and check the CCA status on the sensor machine
- Fire up InSSIDer, AirMagnet Survey, Ekahau, etc. etc. and see whether you can see anything below -82. I already showed yesterday that this is easily the case.
Devin argued that just being able to RX beacons is not the same as CCA=busy. Thinking about this further, I think I can explain in the context of the standard why that isn’t the case. To baseline the discussion, here is the clause to which Devin refers from 802.11-2012:
It is true that CCA-CS is -82dBm (in a 20-MHz channel) and that CCA must be set busy for valid PLCP headers at or above this level. (CS=carrier sense. But this also is the same thing as CCA-PD preamble detect, or CCA-SD signal detect, whatever works for you as the standard does not actually use a consistent term for this). However, the standard is silent on what should occur if valid CCA-CS occurs below this. It specifically does not prohibit setting of CCA=BUSY. And in fact if the RX_PHY did not do so all kinds of other nastiness would ensue.
Anyway, put aside the CCA threshold logic for a moment. Let us look at the RX state machine. It specifically does not allow an exit from the RX process for the scenario Devin describes.
Here is the state machine for clause 18 legacy OFDM from 802.11-2012. I have circled certain sections in color.
- In the red box, during initial lock-on and decode of preamble, the only way out back to CCA=idle is an error in the decode.
- In the orange box, if there is a valid PLCP decode but the contents are out of spec, then CCA must be busy until the L-SIG length decrements to 0.
- In the purple box, if carrier is lost mid-frame the RX logic is still explicitly required to wait until the L-SIG length decrements to 0.
i.e. there is no way for Devin’s suggestion to work of AP or STA deciding unilaterally set CCA=idle once it begins RXing a valid frame.
Now here is the Clause 22 VHT RX state machine from 802.11ac-2013 with same colors applied. The interpretation I gave above is even more explicitly stated (note highlighted text).
In other words, for any node on which an L-SIG is successfully decoded – whether it complies with the standard or not – and whether the rest of the PPDU is decoded properly or not – the full duration indicated in the L-SIG must elapse before CCA can go back to idle.
My interpretation is that this RX state machine behavior supersedes the CCA threshold level from 18.3.10.6, and specifically it governs what happens below the -82 dBm minimum requirement.
This means that those decoded beacons at -90 or lower I showed in InSSIDer yesterday effectively mean that the radio is precluded from doing anything else while the PPDU is being decoded.
Now, if a specific AP or STA vendor decides to override this logic in their device, that’s another story completely. But such modifications would technically not comply with the state machines shown above. For example, Cisco’s RXSOP and Aruba’s Cell Size Reduction features achieve this by raising RX sensitivity levels across the board (e.g. prevent the RX state machine from even firing in the first place).
As mentioned earlier, there are very active discussions in 11ax about this topic. In Bangkok last week, BSS Coloring was affirmatively motioned into the Spec Framework Document. (MAC Motion #34, PHY Motions #47, #49. See 15.0987r6 for the motions and vote tallies). MAC Motion #34 is exactly Devin’s proposal. Namely that there would be a new CCA threshold applied after a BSS Color test, if an OBSS frame is below this new level then CCA could go idle and thereby allow spatial reuse. See the highlighted text in red:
Finally, if you have not seen my High Density Theory Guide, I have attached a copy. I really wrote this for you guys, it’s way over the heads of most people working on Wi-Fi day in and day out. Chapter 5 specifically is the full presentation of collision domain operation.
I have had very little technical feedback on this volume so far. Would greatly appreciate any critical comments on the whole thing, especially if I’ve got anything wrong. Also any suggestions for improving how the concepts are communicated, if any of it is unclear.
Can somebody add Chris O’Donnell to this thread? I don’t have his addy.
Thanks.
-cl
Chuck Lukaszewski, CWNE #112, AWMP, ACMP
CTO Office
Aruba Networks
+1.408.393.1900On Sep 27, 2015, at 4:03 PM, Devin Akin
Thanks a MILLION Chuck! We really appreciate your engagement on this!
I’ve copied COD to this thread.
Once we dig through this together, we’ll take it to the public on Twitter and in classes.
Devin
On Sep 27, 2015, at 3:11 PM, Andrew vonNagy [mailto:andrew.vonnagy@gmail.com] wrote:
Thanks for starting this discussion Chuck! I’ll dig into this email further on Monday since today is my one family day at home between two weeks of travel.
Cheers,
Andrew von NagyOn Sep 27, 2015, at 11:36 PM, Ronald van Kleunen ronald@globeron.com> wrote:
Hi Chuck,
Thank you to put this together offline first. I have sent COD a linkedin msg. I believe the @cwne.com domain does not exist anymore (?)
(I remember something reading about this). I am back online on Tue. (boarding flight now).Ronald van Kleunen
On Sep 27, 2015, at 11:56 PM, Peter Mackenzie [mailto:pmackenzie@marquest.com] wrote:
Thank you for starting this thread Chuck. I won’t be back in the office for two weeks, but I hope to start some testing when I’m back. I will share progress and results when I have something.
Thanks
Peter MackenzieSent from my iPhone
On Sep 28, 2015, at 11:30 AM, Rick Murphy
Chuck,
You’ve made a very good case for this but I will dig a little deeper before adding my comments. Thanks for including me.
Rick Murphy
On Sep 28, 2015, at 10:47 AM, Chuck Lukaszewski
…adding Coleman to the thread…
On Sep 28, 2015, at 10:25 PM, Devin Akin
Hi Chuck,
I read this, and I believe you’re right on how to test it. We’ll test this as soon as possible, and update each other via this email thread.
I really appreciate you articulating this so well. I didn’t know that it had been motioned (#34) to clarify what happens below -82dBm. That seems like good news if it’s adopted….or at least I hope so.
The state machine was way over my barely-adequate head, so I’ll have to take your word for that part. 🙂
Devin
On Sep 29, 2015, at 9:24 AM, Devin Akin
Looking up who Ron Porat and Jianhan Lin are, and the fact that they are requesting the -82dBm (@20MHz) limit tells me that it’s likely that the -82dBm limit isn’t already in place. 🙁Devin
On Sep 30, 2015, at 11:08 PM, Devin Akin
See attached. This is a GREAT read about this topic.
Devin
On 1 Oct 2015, at 05:52, Rick Murphy
I keep returning to paragraph 1 on slide 3. That seems to verify Chuck’s premise. Also, I have not found any exceptions to Chuck’s claim that there is no way to exit the RX state machine based on CCA once a valid preamble has begun decoding. I will attempt to test this in the next couple of weeks in our lab.
Rick
On Oct 1, 2015, at 8:44 PM, Peter Mackenzie [mailto:pmackenzie@marquest.com] wrote:
Unless you never enter the RX state machine. The trigger which kick starts the RX state machine is CCA=busy. So if CCA remains idle because the receive level is less then -82dBm, my question is can you continue to, or have you already, receive(d) enough to report stats e.g. receive signal level.
I have not had any time yet to research if the premise above carries any wait, I just wanted to throw it into the mix.
Thanks
PeterSent from my iPhone
On Oct 1, 2015, at 11:10 PM, Chuck Lukaszewski [mailto:clukaszewski@arubanetworks.com]wrote:
No, you have it backwards. CCA is set to busy as a direct result of sensing a valid carrier signal, not the other way around. “Carrier signal” means that valid L-STF / L-LTF training fields (TFs) immediately prior to the L-SIG are detected. This happens at the hardware RX sensitivity (RXS) level. These are shown in red boxes below.
Once the TFs are detected successfully, then CCA is asserted. This occurs immediately before the L-SIG is decoded (orange box).
My understanding is that the RX state machine really begins when the first L-STF is detected (really there is no other way it can work).
The Perahia and Stacey book on 11ac is the definitive work on the subject, if you have not read it buy a copy today. Every CWNE should be thoroughly familiar with it.
The only way not to enter the state machine is to administratively set the RXS level to a higher value than the hardware supports, such that the TFs are never heard. Once the TFs are in, the radio has already set its AGC, timing and done channel estimation for phase correction. In other words, the roller coaster has left the platform and you can’t get off unless there’s an accident.
For example you could force RXS to -82 dBm which would override the hardware value for any data rates that could otherwise be decoded below. This would force the HW to behave in the way Devin was arguing it should.
Here is an example of a typical RXS table for one of our currently shipping APs. Note these values are per chain. We will successfully decode legacy OFDM 6 Mbps rate at -93 dBm!!!
On Oct 1, 2015, at 8:40 PM, Peter Mackenzie [mailto:pmackenzie@marquest.com]wrote:
Hi Chuck,
Thanks for your response. I’m not sure I explained myself very well, I agree with you CCA is set to busy as a direct result of sensing a valid carrier.
My point was, if you force RXS -82dBm then my understanding is you would not leave the first (idle) state of the RX state machine. I agree once the RX state machine has stated there is no way off unless an error occurs.
From all the evidence it looks like you are right on this one, I just wanted to keep the alternative argument there until we test. Also I like playing “Devils advocate” a bit.
Thanks
PeterSent from my iPhone
On Oct 1, 2015, at 6:32 PM, Devin Akin [mailto:Devin.Akin@DivDyn.net] wrote:
I’m definitely on board with this now…and it makes me want to cry a little. 🙁 Let’s hope that 802.11ax includes some fun new parts and pieces to improve this situation.
A huge thanks to Chuck for such thorough and helpful work!
#GoTwitter!
Devin
On Oct 22, 2015, at 1:14 PM, Rick
Attached find my preliminary test results using a platform similar to what Chuck described in his first message. Please, share your comments and let me know if you spot any flaws or inaccuracies in my procedure. I want to run another set of tests (different location, different vendor equipment, different band, and lower RSSI) before committing one way or the other on this.
I would like to know if anyone else has achieved similar results.
Rick
- Set up 2 BSS with 1 STA each, where each BSS can only hear the other at say -85 or -90 dBm. Sum of an iPerf test with both BSS at same time should be same as running either BSS solo.
- You must be logged in to reply to this topic.