On Tue, 2025-08-26 at 21:02 +0200, Pablo MARTIN-GOMEZ wrote: > > The EHT PHY requirements state that 80 MHz must be supported on the 5 > > and 6 GHz bands unless the STA is 20 MHz only. So if the channel width > > is limited to 40 MHz on a band other than 2.4 GHz, then disable EHT and > > downgrade to HE. > > This is wrong one way or another. > > If we follow the 802.11 standard strictly [I'm going to use annex B's > items so it is easier to follow], we are implementing EHTP3.3, so a non I ... don't think that's a good (correct?) way to phrase it. "Implement EHTP3.3" means you have 80 MHz support, which is required unless it's 20 MHz only STA. Here we're not really implementing 80 MHz support but saying that this is a requirement ... > 20 MHz-Only STA has to support 80 MHz channel width, therefore a 40 MHz > (max) STA would not be compliant and we have to downgrade it. The issue > is that HEP3.3 also requires that a non 20 MHz-Only HE STA has to > support 80 MHz channel width, therefore downgrading to HE is not ok. Again this is misleading, HEP3.3 states no such thing, it just asks if you have it. Clause 27 states though that 40 and 80 MHz bandwidths must be supported (except for 20 MHz-only non-AP HE STA), so yes, you're still right that our downgrade is wrong, but talking about conforma items is confusing at best? (FWIW, I've also never seen an actual statement from anyone, it really doesn't seem to be relevant in practice at all.) > We > have the same issue with VHTP3.3 that requires a VHT STA to support 80 > MHz channel width, therefore downgrading to VHT is not okay either. Similarly, Clause 21, not VHTP3.3, and in this case there's not even an allowance for 20-MHz only STA. I guess VHTP3.3 is a mere formality then. Anyway I know you meant this only as something to talk about, but I still think it's confusing, you should state the normative text that actually requires something, not the (normative) text about what the manufacturer should state for a device that claims compatibility. > So > that means that the strictly compliant approach would be to disallow a > 40 MHz STA in the 6 GHz band and downgrade a 40 MHz STA to HT in the > 5GHz band. Looks like, yes. We should probably do that. These are corner cases anyway though, I don't think I've ever actually seen it happen. > If we follow the 802.11 standard more liberally, we never enforced > VHTP3.3 nor HEP3.3, so why begin now with EHTP3.3? Nobody found bugs with the other ones? ;-) Here it comes down to this actually _happening_ due some devices not allowing puncturing, and then we can't connect in the right way. And this doesn't matter to HE, if we connect to an AP with puncturing in the 80 MHz as an 80 MHz HE station, then it _must_ have HE not punctured so only 40 MHz. Then if the HE actually moves to 80 MHz the puncturing in EHT must go away, and the HE is 80 MHz unpunctured which is fine for the HE STA, so there isn't even a bug. The only bug would be if the downgrade happens for reasons other than puncturing (e.g. regulatory bands) but this is very unlikely in the first place. So practically, the only issue we had with this is that for EHT and puncturing, and then the downgrade to HE basically fixes that issue and we can connect with HE even if we pretend we can do 80 MHz because as long as the puncturing is there, the AP has to use 20 or 40 MHz operation for HE (and lower of course.) I agree though that this isn't really completely correct for HE/VHT if the downgrade were to happen for other reasons. However, I also don't think this is an argument _against_ fixing this issue for EHT. Clearly, for EHT there's the additional practical puncturing issue that matters. Yes, the APs rate scaling might be able to cope with it eventually, but if we remain connected with EHT and pretend we're 80 MHz when we're not, then we could get RUs in the unavailable part etc. and I think rate scaling would probably not deal with that well. This is true for HE as well, of course, but see above? johannes
