On Wed, 2025-06-18 at 16:55 +0530, Rameshkumar Sundaram wrote: > > I think it might make more sense for _mesh_ to do this, and honestly > > mesh probably doesn't have much 6 GHz language in the spec anyway? I > > didn't check now. > > Guess mesh is defined for 6 GHz as well, > > 26.17.2 HE BSS operation in the 6 GHz band > A mesh STA with dot11HE6GOptionImplemented equal to true and operating > in the 6 GHz band is a 6 GHz mesh STA. OK fair :) > > I don't see why multi-radio would behave differently, sure, something > > else could be occupying the 6 GHz band but that's also true for a "non- > > multi-radio design", after all that doesn't mean it doesn't have > > multiple radios, it just manages them differently. > > > > That makes sense, thanks for the explanation, but is there a reason we > should include the 6 GHz band capabilities element even-though the link > STA/ mesh BSS that is going to send the beacon/assoc req frames is > operating in a lower band (say 5GHz) ? It's probably not useful in a *beacon*, I guess? > Does this help in discovery of any out of band capabilities ? Just > trying to understand how this is useful. > > With current implementation, an ML STA negotiating 5 GHz and 6 GHz links > with an ML AP would send HE 6 GHz Band capabilities element in both the > links as part of association request. There was, afaik, some discussion here in the spec asking explicitly to have it included if the STA is 6 GHz capable, but don't ask me why. Now that I look at it again though, it says for both beacon and probe - _request_ to include it when dot11HEOptionImplemented and dot11HE6GOptionImplemented are (both) true... We always though, with some discussions with Cisco IIRC, that we should then always include it even on the other bands for probe requests etc. But does that make sense for beacons? Not really? johannes
