Linux-Wireless Archive on lore.kernel.org
 help / color / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>,
	Arend Van Spriel <arend.vanspriel@broadcom.com>
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 22:06:16 +0200
Message-ID: <a4c6be4ba7cf8594d05af78a7e4dfa1310d0c3b9.camel@sipsolutions.net> (raw)
In-Reply-To: <4ea863a3-656e-0c7a-57f0-b7cf88614233@quantenna.com>

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


      reply index

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-20 12:00 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
2019-07-12 20:06                 ` Johannes Berg [this message]

Reply instructions:

You may reply publically 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=a4c6be4ba7cf8594d05af78a7e4dfa1310d0c3b9.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=arend.vanspriel@broadcom.com \
    --cc=igor.mitsyanko.os@quantenna.com \
    --cc=j@w1.fi \
    --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

Linux-Wireless Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-wireless/0 linux-wireless/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-wireless linux-wireless/ https://lore.kernel.org/linux-wireless \
		linux-wireless@vger.kernel.org linux-wireless@archiver.kernel.org
	public-inbox-index linux-wireless


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-wireless


AGPL code for this site: git clone https://public-inbox.org/ public-inbox