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.
