On 7/12/2019 11:30 AM, Johannes Berg wrote:
On Thu, 2019-07-11 at 13:30 +0200, Arend Van Spriel wrote:
I assume user-space does not necessarily need the band, but hostapd
needs to be aware that it is operating in 6GHz to setup the correct
(information) elements in the beacon. Obviously the operating classes
can be used there, but I don't think there is any issue with nl80211
exposing a 6G band.
Yeah, I don't really see any *issue* with it, in many places we don't
really even care about the band enum.
In a sense, *most* of the places that consider the channel don't
actually care about the band, the channel num/freq conversion helpers
are a bit of the odd ones out in that regard. In the chandef, for
example, we don't have the band.
Really the original use for the band enum was mostly around the
advertising if capabilities. As you pointed out, 6GHz actually *does*
have different capabilities, though it's not clear to me what exactly
the behaviour differences are. Scanning is a big area, of course.
For starters a 6G STA has to add "HE extended capabilities" element.
This contains capabilities that are taken from HT/VHT. Reason being that
there is following requirement (clause 26.17.2.1):
"""
A 6 GHz HE STA shall not transmit an HT Capabilities element, VHT
Capabilities element, HT Operation
element, VHT Operation element or an HE Operation element that contains
a VHT Operation Information
field.
"""
The inclusion of the "HE extended capabilities" element is determined by
the dot116GOptionImplemented option. (band[6G] != NULL) provides that
condition although there are other ways to solve that I guess :-p
Come to think of it. Does mac80211 need that. Guess IEs are provided by
user-space, right?
When we discussed splitting up or not the band, I think what we mostly
considered was the channel num/freq conversion helpers, and Jouni
pointed out that really what we should be doing for those isn't to
consider the band but the operating class instead.
So I'm starting to think that perhaps the decision we came to in Prague
was a little hasty, without considering the full impact?
I do completely agree that we should have knowledge about the operating
classes in the kernel eventually, and probably we will need to have it
here if we need to parse reduced neighbor reports etc. OTOH, we have
already ieee80211_operating_class_to_band(), and that seems sufficient,
though probably we should consider a combined helper that takes
opclass/chan# instead of having to call two functions?
However, from a feature advertisement point of view, we might very well
consider 6 GHz to be a separate nl80211 band, in particular if there
*are* indeed differences around what rates are permitted? Which is
really the only place where we care. Or maybe, thinking about this more,
if there could be devices that have different capabilities in 6 GHz than
in 5 GHz, in the sense of HT/VHT/HE capabilities?
Regarding rates the answer seem to be in clause 26.17.2.1 as well:
"""
A STA shall not transmit an HT PPDU in the 6 GHz band. A STA shall not
transmit a VHT PPDU in the
6 GHz band. A STA shall not transmit a DSSS, HR/DSSS, or ERP-OFDM PPDU
in the 6 GHz band.
"""
I may be wrong but that seems to say only HE rates are allowed.
Can somebody do the legwork and really go look at the spec to figure out
what the differences are? I'm not even sure now legacy rates are
permitted or not - you (Arend) seemed to imply they're not, and Igor
said only for beacons ...
Regarding beacons the rate requirement is in clause 26.15.6, which
basically states that beacons have to be transmitted with HE rate where
NSS equals 1.
I tend to think that this would be the deciding factor. For example, if
we do end up sending a probe request on 6 GHz, would we include a
different supported rates element than on 5 GHz? Or might there even be
devices that have different PHY paths and thus possibly different
capabilities for 5 and 6 GHz, essentially requiring a new place (a new
band enumerator) to store those capabilities, so we don't have to try to
figure out the difference in code later?
I'm almost tempted to say that given all these possibilities we should
in fact add a new value to the band enum, worst case we just duplicate
some data, but if there do end up being differences we can handle them
much more gracefully than if we put everything into 5 GHz.
Jouni, what do you think?
Regards,
Arend
