Re: MCS field - STBC and Ness

Simon Barber <[email protected]> Fri, 11 May 2012 21:27:11 -0700
Newsgroups org.netbsd.radiotap
Message-ID <[email protected]>
Another slight tweak - I think STBC is more commonly used than Ness (as 
witnessed by Wojciech's interest), so give STBC the simpler encoding. I 
believe Ness is used for beamforming soundings.

Spec would look like this:

known    definition
0x01    bandwidth
0x02    MCS index known (in mcs part of the field)
0x04    guard interval
0x08    HT format
0x10    FEC type
0x20    STBC
0x40    Ness - Number of extension spatial streams is known
0x80    Ness2 - bit 1 (MSB) of Number of extension spatial streams.

The flags field is any combination of the following:

flag    definition
0x03    bandwidth - 0: 20, 1: 40, 2: 20L, 3: 20U
0x04    guard interval - 0: long GI, 1: short GI
0x08    HT format - 0: mixed, 1: greenfield
0x10    FEC type - 0: BCC, 1: LDPC
0x60    STBC - 0, 1 or 2: number of STBC streams
0x80    Ness - bit 0 (LSB) of Number of extension spatial streams.

What should I do to advance this as an approved radiotap extension?

Simon


On Fri 11 May 2012 11:35:46 AM PDT, Johannes Berg wrote:
> On Fri, 2012-05-11 at 09:53 -0700, Simon Barber wrote:
>> OK - perhaps a simpler/better suggestion would be for the STBC2 bit to
>> just be the second bit of STBC information.
>
> Seems reasonable to me, then we'll have filled all the bits anyway.
>
> johannes
>
>> Simon
>>
>>
>> On Fri 11 May 2012 09:44:20 AM PDT, Simon Barber wrote:
>>> One possible solution would be to adopt your proposal to add a single
>>> bit STBC, but also add a second bit to the 'knows' byte - STBC2. If
>>> this second bit is set, then it indicates STBC=2. This would leave one
>>> remaining bit in the 'knows' byte, to indicate the presence of Ness
>>> information, and 2 bits in the 'flags' byte for 2 bits of Ness
>>> information.
>>>
>>> Copying the MCS definition from the radiotap.org website:
>>>
>>> The known field indicates which information is known:
>>>
>>> known definition
>>> 0x01 bandwidth
>>> 0x02 MCS index known (in mcs part of the field)
>>> 0x04 guard interval
>>> 0x08 HT format
>>> 0x10 FEC type
>>> 0x20 STBC - STBC is known
>>> 0x40 STBC2 - 2 STBC streams are present
>>> 0x80 Ness - Number of extra spatial streams is known
>>>
>>> The flags field is any combination of the following:
>>>
>>> flag definition
>>> 0x03 bandwidth - 0: 20, 1: 40, 2: 20L, 3: 20U
>>> 0x04 guard interval - 0: long GI, 1: short GI
>>> 0x08 HT format - 0: mixed, 1: greenfield
>>> 0x10 FEC type - 0: BCC, 1: LDPC
>>> 0x20 STBC - 0: no STBC streams, 1: 1 or 2 STBC streams (see STBC2)
>>> 0xc0 Ness - Number of extra spatial streams.
>>>
>>> Simon
>>>
>>>
>>>
>>> On Fri 11 May 2012 12:04:51 AM PDT, Wojciech Dubowik wrote:
>>>> Hello,
>>>> Atheros families 9002 and 9003 support only one STBC stream. I think I
>>>> have seen a Ralink chipset
>>>> which supports 2 stream at least on receive. I am not sure about
>>>> transmiter.
>>>> On Atheros you get STBC flag and two bits Ness field for received
>>>> packets but In the patch there is is only flag reading but you could
>>>> add Ness yourself it's only two bits left from the flag.
>>>>
>>>> Myself I have tested only one stream but I did it only by looking
>>>> whether other party is setting rx descriptor bit. I don't know how it
>>>> looks "in the air". I trust manufacturer;o)
>>>>
>>>> It's true that only one bit was allocated in wireshark extension.
>>>> Should have been two but it's a bit waste. My proposal wasn't accepted
>>>> but in the end I think it's ok becasue I have managed to get all info
>>>> in vendor namesapes where I can do what I want.
>>>>
>>>> Br,
>>>> Wojtek
>>>>
>>>>>
>>>>> I am writing a Wireshark extension to visualise 802.11 frames on a
>>>>> timeline. In order to do this I need to be able to calculate the
>>>>> duration from start of TX to end of TX for each frame.
>>>>>
>>>>> For 802.11n I need to know the number of HT-DLTF and HT-ELTF training
>>>>> symbols that are sent in the header - I have everything else needed
>>>>> to calculate the duration. Given the MCS and the STBC and the Ness
>>>>> (Number of extension spatial streams) I can calculate the number of
>>>>> training symbols.
>>>>>
>>>>> Both STBC and Ness are encoded in the HT-SIG transmitted at the start
>>>>> of each HT frame.
>>>>>
>>>>> The current proposal (or has it not yet been accepted?) for STBC
>>>>> allocates just 1 bit - but the STBC field can have values or 0, 1 or 2.
>>>>>
>>>>> Ness can be 0-3, so the remaining 2 bits could be allocated to Ness,
>>>>> but this does not solve the problem of how to encode the modes with 2
>>>>> spatial streams and 2 additional streams for STBC.
>>>>>
>>>>> Does anyone know what current hardware supports - STBC values or
>>>>> 0,1,2? Ness values of 0-3?
>>>>>
>>>>> Any suggestions for how to convey these
>>>>>
>>>>> Simon
>>>>
>>
>
>