Re: MCS field: RFA

["Joshua (Shiwei) Zhao" <swzhao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

For the existing chips on market, I guess none of them would receive
20MHz packets on the secondary channel though they are configured for
40MHz, i.e. they would only receive 40MHz packets or 20MHz packets on
the primary channel.
And, for the 20MHz packet you receive, isn't it enough to know their
channel? Why would I care whether it's received on the sniffer chip's
U or L channel?

Good point for LPDC. I'd say STBC also. Personally I think we can
extend the rx flags definition and add coding or other additional
informations.

Thanks,
Joshua


On Wed, Feb 3, 2010 at 9:50 PM, Bill Stafford <bill.stafford-BUHhN+a2lJ4@public.gmane.org> wrote:
> On Feb 3, 2010, at 5:11 PM, Joshua (Shiwei) Zhao wrote:
>> In 802.11, there is no official concept of 20L or 20U. There is
>> primary channel and secondary channel used in a BSS.
>
> I know what you mean about about the channel definition. The IEs
> in beacons and probe responses will describe a 40 MHz BSS as
> having the control (primary) and extension (secondary)
> channel. So if you were setting up the channel pair {36,40}, you
> might pick channel 36 as control and have the extension channel
> above on 40. You could also set it up as ctl 40 with extension
> below on 36. Both would cover the same 40 MHz, but as you say,
> the 20 MHz traffic should always go on the control channel.
>
> But the spec does have the concept of 20U and 20L in terms of the
> phy layer. Section 20.2.2 "TXVECTOR and RXVECTOR parameters"
> defines the CH_OFFSET field with values {CH_OFF_20, CH_OFF_40,
> CH_OFF_20U, CH_OFF_20L}. So it is not a BSS attribute, which is
> where I think you are coming from, but it is an attribute of
> packets both on TX and RX.
>
>> However, as a
>> sniffer sees a packet on the air, sniffer can only tell the packet's
>> bandwidth and operating channel. But we know, if a 40MHz-capable
>> AP/STA sends a 20MHz signal, it must use its primary channel.
>
> Sure, any 20 MHz traffic from the first BSS I mentioned {ctl 36,
> ext 40} would be on channel 36 (CH_OFF_20L, or just 20L as I
> suggested). But that does not mean all 20 MHz traffic will be on
> 36. 20 MHz traffic from the other BSS {ext 36, ctl 40} would be
> on 40, and legacy BSSs might be on either. So the sniffer would
> pick up the packets as 20L or 20U while the radio was tuned to
> {36,40}.
>
> As I mentioned, you are loosing what seems like important
> information if you just capture a packet as (channel 36 20MHz)
> instead of (20L, channel 36-40). You can always have the sniffer
> app display the resulting channel (ch36) with the second form
> because it has more information. But with the first form, you've
> lost the info about what the receiver mode was at the time of
> capture. Also, for a user app using radio tap, using the
> first form would not allow for the 20U/L transmissions.
>
>> So I agree with what David described using channel flag indicating
>> bandwidth and guard interval. A MCS field is good for HT case.
>
>
> And LDPC vs BCC?
>
> -Bill
>