On 7/26/2012 11:12 PM, Johannes Berg wrote:
On Thu, 2012-07-26 at 12:00 +0530, Mahesh Palivela wrote:
11ac Draft3.0 section 22.3.14 says VHT channel is specified by
dot11CurrentChannelBandwidth, dot11CurrentChannelCenterFrequencyIndex0,
dot11CurrentChannelCenterFrequencyIndex1 and dot11CurrentPrimaryChannel
primary channel comes from HT Op IE.
chanBW, chanCenterFreq0, chanCenterFreq1 comes from VHT Op IE.
So multiple secondary channels doesn't seem to be a valid?
Hmm. But that means we have to specify the channel completely
differently? I think we should stick to our scheme of center freq of a
20 MHz channel + surrounding bandwidth,
ok. Let's stick to old way of channel config. Basically freq value and
channel type which kind of specifies channel widths. so how about for
VHT channel types as below. Its similar to what you proposed.
For 80 MHz:
VHT80_3PLUS
VHT80_MINUS_2PLUS
VHT80_2MINUS_PLUS
VHT80_3MINUS
For 160 MHz:
VHT160_7PLUS
VHT160_MINUS_6PLUS
VHT160_2MINUS_5PLUS
VHT160_3MINUS_4PLUS
VHT160_4MINUS_3PLUS
VHT160_5MINUS_2PLUS
VHT160_6MINUS_PLUS
VHT160_7MINUS
Yeah, that would work. Lots of channel types ...
Yea, So I am thinking how about passing channel width and secondary
channel center frequency from which we know chan_below or chan_above,
instead of channel_type.
> though it obviously won't work for 80+80. The question will be where
> we deviate from our previous scheme. I tend to think that HT80+80
> should deviate, I have a feeling it won't be implemented soon
> (or ever?) anyway.
>
Yea, even I feel the channel config representation what we are proposing
is not really extendable to discrete bands. That's my only worry...
? What do you mean?
I mean 80+80 scenario is not possible to represent.
CHAN_NO_VHT80 is actually 2 bits. NO_VHT80MINUS & NO_VHT80PLUS.
Is that ok?
+ IEEE80211_CHAN_NO_VHT80PLUS = 1<<6,
+ IEEE80211_CHAN_NO_VHT80MINUS = 1<<7,
+#define IEEE80211_CHAN_NO_VHT80 \
+ (IEEE80211_CHAN_NO_VHT80PLUS | IEEE80211_CHAN_NO_VHT80MINUS)
Right. But did you mean to check that all of them are set? What if one
of them is set but the other isn't?
If one of them is set, then we accept VHT80 for that channel.
Yes, but is that really correct?
I think so. If one of the configuration is allowed we can perform VHT80
operation.
johannes
Thanks,
Mahesh
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
