Linux-Wireless Archive on
 help / color / Atom feed
From: Igor Mitsyanko <>
To: Arend Van Spriel <>,
	Johannes Berg <>
Cc: "" <>,
	Jouni Malinen <>, Tova Mussai <>
Subject: Re: [RFC 0/8] nl80211: add 6GHz band support
Date: Fri, 12 Jul 2019 15:16:17 +0000
Message-ID: <> (raw)
In-Reply-To: <>

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 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 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 

  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 [this message]
2019-07-12 20:06                 ` Johannes Berg

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Wireless Archive on

Archives are clonable:
	git clone --mirror 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/ \
	public-inbox-index linux-wireless

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox