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(-)
--
1.9.1
In the 802.11ax specification a new band is introduced, which
is also proposed by FCC for unlicensed use. This band is referred
to as 6GHz spanning frequency range from 5925 to 7125 MHz.
Reviewed-by: Pieter-Paul Giesberts <[email protected]>
Reviewed-by: Leon Zegers <[email protected]>
Signed-off-by: Arend van Spriel <[email protected]>
---
include/uapi/linux/nl80211.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 6f09d1500..5ea3c8c 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4515,6 +4515,7 @@ enum nl80211_txrate_gi {
* enum nl80211_band - Frequency band
* @NL80211_BAND_2GHZ: 2.4 GHz ISM band
* @NL80211_BAND_5GHZ: around 5 GHz band (4.9 - 5.7 GHz)
+ * @NL80211_BAND_6GHZ: around 6 GHz band (5.9 - 7.2 GHz)
* @NL80211_BAND_60GHZ: around 60 GHz band (58.32 - 69.12 GHz)
* @NUM_NL80211_BANDS: number of bands, avoid using this in userspace
* since newer kernel versions may support more bands
@@ -4522,6 +4523,7 @@ enum nl80211_txrate_gi {
enum nl80211_band {
NL80211_BAND_2GHZ,
NL80211_BAND_5GHZ,
+ NL80211_BAND_6GHZ,
NL80211_BAND_60GHZ,
NUM_NL80211_BANDS,
--
1.9.1
For the new 6GHz band the same rules apply for mandatory rates so
add it to set_mandatory_flags_band() function.
Reviewed-by: Pieter-Paul Giesberts <[email protected]>
Reviewed-by: Leon Zegers <[email protected]>
Signed-off-by: Arend van Spriel <[email protected]>
---
net/wireless/util.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 03e7176..fd90c86 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -156,6 +156,7 @@ static void set_mandatory_flags_band(struct ieee80211_supported_band *sband)
switch (sband->band) {
case NL80211_BAND_5GHZ:
+ case NL80211_BAND_6GHZ:
want = 3;
for (i = 0; i < sband->n_bitrates; i++) {
if (sband->bitrates[i].bitrate == 60 ||
--
1.9.1
Extend the functions ieee80211_channel_to_frequency() and
ieee80211_frequency_to_channel() to support 6GHz band according
specification in 802.11ax D4.1 27.3.22.2.
Reviewed-by: Pieter-Paul Giesberts <[email protected]>
Reviewed-by: Leon Zegers <[email protected]>
Signed-off-by: Arend van Spriel <[email protected]>
---
net/wireless/util.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index cf63b63..081637e 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -91,6 +91,11 @@ int ieee80211_channel_to_frequency(int chan, enum nl80211_band band)
else
return 5000 + chan * 5;
break;
+ case NL80211_BAND_6GHZ:
+ /* see 802.11ax D4.1 27.3.22.2 */
+ if (chan <= 253)
+ return 5940 + chan * 5;
+ break;
case NL80211_BAND_60GHZ:
if (chan < 7)
return 56160 + chan * 2160;
@@ -111,8 +116,11 @@ int ieee80211_frequency_to_channel(int freq)
return (freq - 2407) / 5;
else if (freq >= 4910 && freq <= 4980)
return (freq - 4000) / 5;
- else if (freq <= 45000) /* DMG band lower limit */
+ else if (freq < 5940)
return (freq - 5000) / 5;
+ else if (freq <= 45000) /* DMG band lower limit */
+ /* see 802.11ax D4.1 27.3.22.2 */
+ return (freq - 5940) / 5;
else if (freq >= 58320 && freq <= 70200)
return (freq - 56160) / 2160;
else
--
1.9.1
The default mandatory rates, ie. when not specified by user-space, is
determined by the band. Select 11a rateset for 6GHz band.
Reviewed-by: Pieter-Paul Giesberts <[email protected]>
Reviewed-by: Leon Zegers <[email protected]>
Signed-off-by: Arend van Spriel <[email protected]>
---
net/wireless/ibss.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/net/wireless/ibss.c b/net/wireless/ibss.c
index d1743e6..ae8fe66 100644
--- a/net/wireless/ibss.c
+++ b/net/wireless/ibss.c
@@ -104,13 +104,19 @@ int __cfg80211_join_ibss(struct cfg80211_registered_device *rdev,
* use the mandatory rate set for 11b or
* 11a for maximum compatibility.
*/
- struct ieee80211_supported_band *sband =
- rdev->wiphy.bands[params->chandef.chan->band];
+ struct ieee80211_supported_band *sband;
+ enum nl80211_band band;
+ u32 flag;
int j;
- u32 flag = params->chandef.chan->band == NL80211_BAND_5GHZ ?
- IEEE80211_RATE_MANDATORY_A :
- IEEE80211_RATE_MANDATORY_B;
+ band = params->chandef.chan->band;
+ if (band == NL80211_BAND_5GHZ ||
+ band == NL80211_BAND_6GHZ)
+ flag = IEEE80211_RATE_MANDATORY_A;
+ else
+ flag = IEEE80211_RATE_MANDATORY_B;
+
+ sband = rdev->wiphy.bands[band];
for (j = 0; j < sband->n_bitrates; j++) {
if (sband->bitrates[j].flags & flag)
params->basic_rates |= BIT(j);
--
1.9.1
In nl80211.c there is a policy for all bands in NUM_NL80211_BANDS and
in trace.h there is a callback trace for multicast rates which is per
band in NUM_NL80211_BANDS. Both need to be extended for the new
NL80211_BAND_6GHZ.
Reviewed-by: Pieter-Paul Giesberts <[email protected]>
Reviewed-by: Leon Zegers <[email protected]>
Signed-off-by: Arend van Spriel <[email protected]>
---
net/wireless/nl80211.c | 1 +
net/wireless/trace.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index fffe4b3..c0224fc 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -627,6 +627,7 @@ static int validate_ie_attr(const struct nlattr *attr,
nl80211_match_band_rssi_policy[NUM_NL80211_BANDS] = {
[NL80211_BAND_2GHZ] = { .type = NLA_S32 },
[NL80211_BAND_5GHZ] = { .type = NLA_S32 },
+ [NL80211_BAND_6GHZ] = { .type = NLA_S32 },
[NL80211_BAND_60GHZ] = { .type = NLA_S32 },
};
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index 2abfff9..a7f39a8 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -2446,10 +2446,11 @@
sizeof(int) * NUM_NL80211_BANDS);
),
TP_printk(WIPHY_PR_FMT ", " NETDEV_PR_FMT ", "
- "mcast_rates [2.4GHz=0x%x, 5.2GHz=0x%x, 60GHz=0x%x]",
+ "mcast_rates [2.4GHz=0x%x, 5.2GHz=0x%x, 6GHz=0x%x, 60GHz=0x%x]",
WIPHY_PR_ARG, NETDEV_PR_ARG,
__entry->mcast_rate[NL80211_BAND_2GHZ],
__entry->mcast_rate[NL80211_BAND_5GHZ],
+ __entry->mcast_rate[NL80211_BAND_6GHZ],
__entry->mcast_rate[NL80211_BAND_60GHZ])
);
--
1.9.1
The function cfg80211_ir_permissive_chan() is applicable for
6GHz band as well so make sure it is handled.
Reviewed-by: Pieter-Paul Giesberts <[email protected]>
Reviewed-by: Leon Zegers <[email protected]>
Signed-off-by: Arend van Spriel <[email protected]>
---
net/wireless/chan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 7dc1bbd..7c9d204 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -894,7 +894,8 @@ static bool cfg80211_ir_permissive_chan(struct wiphy *wiphy,
if (chan == other_chan)
return true;
- if (chan->band != NL80211_BAND_5GHZ)
+ if (chan->band != NL80211_BAND_5GHZ &&
+ chan->band != NL80211_BAND_6GHZ)
continue;
r1 = cfg80211_get_unii(chan->center_freq);
--
1.9.1
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 <[email protected]> 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 <[email protected]> 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 2019-05-20 05:00, Arend van Spriel wrote:
> [...snip...]
> enum nl80211_band {
> NL80211_BAND_2GHZ,
> NL80211_BAND_5GHZ,
> + NL80211_BAND_6GHZ,
> NL80211_BAND_60GHZ,
>
> NUM_NL80211_BANDS,
Is it not a concern that this changes the value of NL80211_BAND_60GHZ
and hence will break any ABI which expects the current value?
On May 30, 2019 4:53:13 PM Jeff Johnson <[email protected]> wrote:
> On 2019-05-20 05:00, Arend van Spriel wrote:
>> [...snip...]
>> enum nl80211_band {
>> NL80211_BAND_2GHZ,
>> NL80211_BAND_5GHZ,
>> + NL80211_BAND_6GHZ,
>> NL80211_BAND_60GHZ,
>>
>> NUM_NL80211_BANDS,
>
> Is it not a concern that this changes the value of NL80211_BAND_60GHZ
> and hence will break any ABI which expects the current value?
Sigh! Obviously that is a concern. Johannes already mentioned it.
Thanks,
Arend
On 2019-05-30 09:07, Arend Van Spriel wrote:
> Sigh! Obviously that is a concern. Johannes already mentioned it.
Sorry, overlooked his comment on the [0/8] patch. I'll climb back under
my rock.
On May 30, 2019 7:43:27 PM Jeff Johnson <[email protected]> wrote:
> On 2019-05-30 09:07, Arend Van Spriel wrote:
>> Sigh! Obviously that is a concern. Johannes already mentioned it.
>
> Sorry, overlooked his comment on the [0/8] patch. I'll climb back under
> my rock.
No need to do that. It is mainly me feeling stupid about making such a
mistake that makes me sigh ;-)
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 <[email protected]>
>> 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 <[email protected]>
>>> 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