| Message ID | 1558353645-18119-1-git-send-email-arend.vanspriel@broadcom.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | nl80211: add 6GHz band support | expand |
Hi Arend, On Mon, 2019-05-20 at 14:00 +0200, Arend van Spriel wrote: > In 802.11ax D4.0 a new band has been proposed. This series contains > changes to cfg80211 for supporting this band. With 2GHz and 5GHz there > was no overlap in channel number. However, this new band has channel > numbers with a range from 1 up to 253. At the wireless workshop in Prague, we looked at this and sort of decided that it'd be better to put all the 6 GHz channels into the 5 GHz "band" in nl80211, to avoid all the "5 || 6" since they're really the same except for very specific places like scanning. The channel numbers problem came up, of course, but for nl80211 it's not that relevant since we deal with frequencies only, and we thought inside the kernel it'd be better to disambiguate them with operating classes, where needed - only few places really deal with channel numbers to start with. Do you have any reason to think that it's better as a separate band enum (which I notice you put before 60 GHz thus breaking the API/ABI :P)? Thanks, johannes
On May 24, 2019 1:56:43 PM Johannes Berg <johannes@sipsolutions.net> wrote: > Hi Arend, > > On Mon, 2019-05-20 at 14:00 +0200, Arend van Spriel wrote: >> In 802.11ax D4.0 a new band has been proposed. This series contains >> changes to cfg80211 for supporting this band. With 2GHz and 5GHz there >> was no overlap in channel number. However, this new band has channel >> numbers with a range from 1 up to 253. > > At the wireless workshop in Prague, we looked at this and sort of > decided that it'd be better to put all the 6 GHz channels into the 5 GHz > "band" in nl80211, to avoid all the "5 || 6" since they're really the > same except for very specific places like scanning. Would have liked to be there, but attending is no longer an option for me. We now have two autistic, non-verbal children and I am the primary caregiver for the oldest because my wife can't handle him. Guess I should have checked the workshop notes before working on this :-) Do you have URL? Agree that most functional requirements for 6 GHz are same as 5 GHz. There are some 6 GHz specifics about beaconing as well. > The channel numbers problem came up, of course, but for nl80211 it's not > that relevant since we deal with frequencies only, and we thought inside > the kernel it'd be better to disambiguate them with operating classes, > where needed - only few places really deal with channel numbers to start > with. > > Do you have any reason to think that it's better as a separate band enum No specific reason. Just that the few cfg80211-based drivers tend to use channel number as hwvalue. > (which I notice you put before 60 GHz thus breaking the API/ABI :P)? Right. Now I feel wet behind the ears :-p I will go with 6G being additional 5G range and see how that works for us. Gr. AvS
On 5/24/2019 8:38 PM, Arend Van Spriel wrote: > On May 24, 2019 1:56:43 PM Johannes Berg <johannes@sipsolutions.net> wrote: > >> Hi Arend, >> >> On Mon, 2019-05-20 at 14:00 +0200, Arend van Spriel wrote: >>> In 802.11ax D4.0 a new band has been proposed. This series contains >>> changes to cfg80211 for supporting this band. With 2GHz and 5GHz there >>> was no overlap in channel number. However, this new band has channel >>> numbers with a range from 1 up to 253. >> >> At the wireless workshop in Prague, we looked at this and sort of >> decided that it'd be better to put all the 6 GHz channels into the 5 GHz >> "band" in nl80211, to avoid all the "5 || 6" since they're really the >> same except for very specific places like scanning. > > Would have liked to be there, but attending is no longer an option for > me. We now have two autistic, non-verbal children and I am the primary > caregiver for the oldest because my wife can't handle him. Guess I > should have checked the workshop notes before working on this :-) Do you > have URL? Found the netdev wifi workshop page and looked over the slides quickly, but the notes page is pretty empty ;-) > Agree that most functional requirements for 6 GHz are same as 5 GHz. > There are some 6 GHz specifics about beaconing as well. This came up in discussion with my colleagues today and I would say from mac80211 perspective there is more to it than just scanning. In short the 6GHz band is for HE-only operation so for example only HE rates may be used. As the bitrates are in ieee80211_supported_band having a separate 6GHz band seems to have a (slight?) advantage. Regards, Arend
On 5/27/2019 10:46 PM, Arend Van Spriel wrote: > On 5/24/2019 8:38 PM, Arend Van Spriel wrote: >> On May 24, 2019 1:56:43 PM Johannes Berg <johannes@sipsolutions.net> >> wrote: >> >>> Hi Arend, >>> >>> On Mon, 2019-05-20 at 14:00 +0200, Arend van Spriel wrote: >>>> In 802.11ax D4.0 a new band has been proposed. This series contains >>>> changes to cfg80211 for supporting this band. With 2GHz and 5GHz there >>>> was no overlap in channel number. However, this new band has channel >>>> numbers with a range from 1 up to 253. >>> >>> At the wireless workshop in Prague, we looked at this and sort of >>> decided that it'd be better to put all the 6 GHz channels into the 5 GHz >>> "band" in nl80211, to avoid all the "5 || 6" since they're really the >>> same except for very specific places like scanning. >> >> Would have liked to be there, but attending is no longer an option for >> me. We now have two autistic, non-verbal children and I am the primary >> caregiver for the oldest because my wife can't handle him. Guess I >> should have checked the workshop notes before working on this :-) Do >> you have URL? > > Found the netdev wifi workshop page and looked over the slides quickly, > but the notes page is pretty empty ;-) > >> Agree that most functional requirements for 6 GHz are same as 5 GHz. >> There are some 6 GHz specifics about beaconing as well. > > This came up in discussion with my colleagues today and I would say from > mac80211 perspective there is more to it than just scanning. In short > the 6GHz band is for HE-only operation so for example only HE rates may > be used. As the bitrates are in ieee80211_supported_band having a > separate 6GHz band seems to have a (slight?) advantage. Hi, Johannes Any thoughts on this? Regards, Arend
On 6/3/2019 12:39 PM, Arend Van Spriel wrote: > On 5/27/2019 10:46 PM, Arend Van Spriel wrote: >> On 5/24/2019 8:38 PM, Arend Van Spriel wrote: >>> On May 24, 2019 1:56:43 PM Johannes Berg <johannes@sipsolutions.net> >>> wrote: >>> >>>> Hi Arend, >>>> >>>> On Mon, 2019-05-20 at 14:00 +0200, Arend van Spriel wrote: >>>>> In 802.11ax D4.0 a new band has been proposed. This series contains >>>>> changes to cfg80211 for supporting this band. With 2GHz and 5GHz there >>>>> was no overlap in channel number. However, this new band has channel >>>>> numbers with a range from 1 up to 253. >>>> >>>> At the wireless workshop in Prague, we looked at this and sort of >>>> decided that it'd be better to put all the 6 GHz channels into the 5 >>>> GHz >>>> "band" in nl80211, to avoid all the "5 || 6" since they're really the >>>> same except for very specific places like scanning. >>> >>> Would have liked to be there, but attending is no longer an option >>> for me. We now have two autistic, non-verbal children and I am the >>> primary caregiver for the oldest because my wife can't handle him. >>> Guess I should have checked the workshop notes before working on this >>> :-) Do you have URL? >> >> Found the netdev wifi workshop page and looked over the slides >> quickly, but the notes page is pretty empty ;-) >> >>> Agree that most functional requirements for 6 GHz are same as 5 GHz. >>> There are some 6 GHz specifics about beaconing as well. >> >> This came up in discussion with my colleagues today and I would say >> from mac80211 perspective there is more to it than just scanning. In >> short the 6GHz band is for HE-only operation so for example only HE >> rates may be used. As the bitrates are in ieee80211_supported_band >> having a separate 6GHz band seems to have a (slight?) advantage. > > Hi, Johannes > > Any thoughts on this? Hi Johannes, It has been a while so maybe your thoughts are more concrete? ;-p I really would like this to move forward as I also noticed hostapd changes being posted for 6GHz support yesterday. Thanks, Arend
Hi Arend, all, Sorry. No, my thoughts aren't really more concrete, but Tova is starting to work on this now. > This came up in discussion with my colleagues today and I would say from > mac80211 perspective there is more to it than just scanning. In short > the 6GHz band is for HE-only operation so for example only HE rates may > be used. As the bitrates are in ieee80211_supported_band having a > separate 6GHz band seems to have a (slight?) advantage. Hmm, that's a good point too, I hadn't really looked _too_ much at 6GHz stuff. Jouni, what do you think? Perhaps we should just have both. I mean, we can treat this as a separate band, and still have code to handle operating classes properly, right? johannes
On 6/28/2019 3:04 PM, Johannes Berg wrote: > Hi Arend, all, > > Sorry. No, my thoughts aren't really more concrete, but Tova is starting > to work on this now. > >> This came up in discussion with my colleagues today and I would say from >> mac80211 perspective there is more to it than just scanning. In short >> the 6GHz band is for HE-only operation so for example only HE rates may >> be used. As the bitrates are in ieee80211_supported_band having a >> separate 6GHz band seems to have a (slight?) advantage. > > Hmm, that's a good point too, I hadn't really looked _too_ much at 6GHz > stuff. > > Jouni, what do you think? > > Perhaps we should just have both. I mean, we can treat this as a > separate band, and still have code to handle operating classes properly, > right? 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. Regards, Arend
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. 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? 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 ... 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? Thanks, johannes
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
On 7/12/19 1:40 PM, Arend Van Spriel wrote: > > > 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? Maybe not for transmission, but we probably will need to parse peer's IEs at least to properly fill SCAN information and properly report peer's capabilities. >> 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. Unless I'm wrong myself, this leaves us with 5GHz OFDMA PHY (802.11a). Further in 26.17.2.1 spec states the following regarding beacons: "the Beacon frames may be sent in non-HT duplicate PPDUs." > >> 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. It reads as a requirements for HE Beacons transmission in 6GHz band if STA chose to transmit such beacons, but it does not state HE station can transmit HE beacons only in 6GHz band. >> >> 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. >> I think we do need a new value in band enum, it seems natural because: - it has different capabilities - it has different rates maintaining this information in any other way seems will be much more cumbersome.
On Fri, 2019-07-12 at 15:16 +0000, Igor Mitsyanko wrote: > On 7/12/19 1:40 PM, Arend Van Spriel wrote: > > > > > > 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? > > Maybe not for transmission, but we probably will need to parse peer's > IEs at least to properly fill SCAN information and properly report > peer's capabilities. Probe requests may also be transmitted there though 6 GHz scanning is sufficiently complicated this might not happen; as well as association request which definitely this is relevant to. > > > 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. > > Unless I'm wrong myself, this leaves us with 5GHz OFDMA PHY (802.11a). > Further in 26.17.2.1 spec states the following regarding beacons: > "the Beacon frames may be sent in non-HT duplicate PPDUs." OFDMA is HE :-) 802.11a is OFDM (Clause 17, at least in 802.11-2016), but I think you're otherwise right. > I think we do need a new value in band enum, it seems natural because: > - it has different capabilities > - it has different rates > maintaining this information in any other way seems will be much more > cumbersome. I'm starting to agree here despite having initially thought it wasn't necessary, and so I'll review Arend's patches again with an eye towards actually merging them. johannes
In 802.11ax D4.0 a new band has been proposed. This series contains changes to cfg80211 for supporting this band. With 2GHz and 5GHz there was no overlap in channel number. However, this new band has channel numbers with a range from 1 up to 253. The only place I could find an issue with this is in cfg80211_wext_freq(). Not sure how to deal with that so it is not part of this series. The series applies to the master branch of the mac80211-next repository. Arend van Spriel (8): nl80211: add 6GHz band definition to enum nl80211_band cfg80211: add 6GHz UNII band definitions cfg80211: util: add 6GHz channel to freq conversion and vice versa cfg80211: extend ieee80211_operating_class_to_band() for 6GHz cfg80211: add 6GHz in code handling array with NUM_NL80211_BANDS entries cfg80211: use same IR permissive rules for 6GHz band cfg80211: ibss: use 11a mandatory rates for 6GHz band operation cfg80211: apply same mandatory rate flags for 5GHz and 6GHz include/uapi/linux/nl80211.h | 2 ++ net/wireless/chan.c | 3 ++- net/wireless/ibss.c | 16 +++++++++++----- net/wireless/nl80211.c | 1 + net/wireless/reg.c | 21 +++++++++++++++++++-- net/wireless/trace.h | 3 ++- net/wireless/util.c | 14 +++++++++++++- 7 files changed, 50 insertions(+), 10 deletions(-)