From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
To: Arend Van Spriel <arend.vanspriel@broadcom.com>,
Johannes Berg <johannes@sipsolutions.net>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
Jouni Malinen <j@w1.fi>, Tova Mussai <tova.mussai@intel.com>
Subject: Re: [RFC 0/8] nl80211: add 6GHz band support
Date: Fri, 12 Jul 2019 15:16:17 +0000 [thread overview]
Message-ID: <4ea863a3-656e-0c7a-57f0-b7cf88614233@quantenna.com> (raw)
In-Reply-To: <d22d5159-60d3-5926-5b3f-bdc3ff07af82@broadcom.com>
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.
next prev parent reply other threads:[~2019-07-12 15:57 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-20 12:00 [RFC 0/8] nl80211: add 6GHz band support Arend van Spriel
2019-05-20 12:00 ` [RFC 1/8] nl80211: add 6GHz band definition to enum nl80211_band Arend van Spriel
2019-05-30 14:53 ` Jeff Johnson
2019-05-30 16:07 ` Arend Van Spriel
2019-05-30 17:43 ` Jeff Johnson
2019-05-30 17:52 ` Arend Van Spriel
2019-05-20 12:00 ` [RFC 2/8] cfg80211: add 6GHz UNII band definitions Arend van Spriel
2019-05-20 12:00 ` [RFC 3/8] cfg80211: util: add 6GHz channel to freq conversion and vice versa Arend van Spriel
2019-05-20 12:00 ` [RFC 4/8] cfg80211: extend ieee80211_operating_class_to_band() for 6GHz Arend van Spriel
2019-05-20 12:00 ` [RFC 5/8] cfg80211: add 6GHz in code handling array with NUM_NL80211_BANDS entries Arend van Spriel
2019-05-20 12:00 ` [RFC 6/8] cfg80211: use same IR permissive rules for 6GHz band Arend van Spriel
2019-05-20 12:00 ` [RFC 7/8] cfg80211: ibss: use 11a mandatory rates for 6GHz band operation Arend van Spriel
2019-05-20 12:00 ` [RFC 8/8] cfg80211: apply same mandatory rate flags for 5GHz and 6GHz Arend van Spriel
2019-05-24 11:56 ` [RFC 0/8] nl80211: add 6GHz band support Johannes Berg
2019-05-24 18:38 ` Arend Van Spriel
2019-05-27 20:46 ` Arend Van Spriel
2019-06-03 10:39 ` Arend Van Spriel
2019-06-21 19:41 ` Arend Van Spriel
2019-06-28 13:04 ` Johannes Berg
2019-07-11 11:30 ` Arend Van Spriel
2019-07-12 9:30 ` Johannes Berg
2019-07-12 10:40 ` Arend Van Spriel
2019-07-12 15:16 ` Igor Mitsyanko [this message]
2019-07-12 20:06 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ea863a3-656e-0c7a-57f0-b7cf88614233@quantenna.com \
--to=igor.mitsyanko.os@quantenna.com \
--cc=arend.vanspriel@broadcom.com \
--cc=j@w1.fi \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=tova.mussai@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).