All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Barber <simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
To: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Cc: Wojciech Dubowik
	<wojciech.dubowik-ASv44eHyqLVBDgjK7y7TUQ@public.gmane.org>,
	radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org
Subject: Re: MCS field - STBC and Ness
Date: Fri, 11 May 2012 21:27:11 -0700	[thread overview]
Message-ID: <4FADE69F.9040100@superduper.net> (raw)
In-Reply-To: <1336761346.8739.3.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>

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
>>>>
>>
>
>

  parent reply	other threads:[~2012-05-12  4:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-11  0:31 MCS field - STBC and Ness Simon Barber
     [not found] ` <4FAC5DE0.90708-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2012-05-11  7:04   ` Wojciech Dubowik
     [not found]     ` <4FACBA13.9040509-ASv44eHyqLVBDgjK7y7TUQ@public.gmane.org>
2012-05-11 16:44       ` Simon Barber
     [not found]         ` <4FAD41E4.3090803-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2012-05-11 16:53           ` Simon Barber
     [not found]             ` <4FAD43F0.20807-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2012-05-11 18:35               ` Johannes Berg
     [not found]                 ` <1336761346.8739.3.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2012-05-12  4:27                   ` Simon Barber [this message]
     [not found]                     ` <4FADE69F.9040100-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2012-07-05  9:12                       ` Johannes Berg
     [not found]                         ` <1341479550.4455.36.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2012-11-01  0:22                           ` Simon Barber
     [not found]                             ` <5091C0BC.4040305-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2012-11-02  0:24                               ` Simon Barber
     [not found]                                 ` <509312DB.7070100-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2012-11-05 14:35                                   ` Johannes Berg
2012-11-17  6:32                                   ` Standardisation - adding 2 bit STBC and Ness to MCS Simon Barber
2012-07-04 17:06   ` MCS field - STBC and Ness David Young

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FADE69F.9040100@superduper.net \
    --to=simon-vp0mx6+5gkqfx2apin6yfw@public.gmane.org \
    --cc=johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org \
    --cc=radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org \
    --cc=wojciech.dubowik-ASv44eHyqLVBDgjK7y7TUQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.