Re: MCS field: RFA

Johannes Berg <[email protected]> Tue, 02 Feb 2010 19:24:05 +0100

Newsgroups	org.netbsd.radiotap
Message-ID	<[email protected]>

On Mon, 2010-02-01 at 22:09 +0000, Bill Stafford wrote:

> I also have a question about how the RadioTap design deals with information
> that may not be available. 

That's a good point.

> So if it was in this longer format the flags might be something like this:
> 0x0001 20 MHz
> 0x0002 40 MHz
> 0x0004 20L (20 MHz in lower half of 40 MHz channel)
> 0x0008 20U (20 MHz in upper half of 40 MHz channel)
> 0x0010 Long GI
> 0x0020 Short GI
> 0x0040 HT Format - Mixed
> 0x0080 HT Format - Greenfield
> 0x0100 FEC type BCC
> 0x0200 FEC type LDPC
> 
> It seems like this expanded bitfield might be better than the more compact
> version.

Which speaks much in favour of this way, even though it may seem
redundant it would allow implementations to say "don't know about
upper/lower but do know it's 20mhz".

> When the radio is tuned to a 40 MHz channel, then the 20L and 20U bits could
> indicate a 20 MHz packet on the lower or upper side of the 40 MHz channel. I
> think leaving in the 20L/U bits would be better than changing the channel field
> to indicate the modulation of the packet. It might be better to leave the
> channel field describing the channel to which the radio is tuned, and these
> 20U/L bits to indicate how the receiver saw the packets. When capturing packets,
> it would seem surprising to see the channel field indicating channel changes on
> what might be a packet by packet basis.

That was my gut feeling as well, but it's a pure definition problem. We
do currently use the OFDM/CCK etc. bits in there on a per-packet basis
too, for instance, and they don't really make sense per-channel anyway.

johannes

signature.asc (application/pgp-signature, 801 B)