MCS field - STBC and Ness

MCS field - STBC and Ness

[Simon Barber]

Hi all,

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

Re: MCS field - STBC and Ness

[Wojciech Dubowik]

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

Re: MCS field - STBC and Ness

[Simon Barber]

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
>

Re: MCS field - STBC and Ness

[Simon Barber]

OK - perhaps a simpler/better suggestion would be for the STBC2 bit to 
just be the second bit of STBC information.

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

Re: MCS field - STBC and Ness

[Johannes Berg]

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

Re: MCS field - STBC and Ness

[Simon Barber]

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

Re: MCS field - STBC and Ness

[Johannes Berg]

On Fri, 2012-05-11 at 21:27 -0700, Simon Barber wrote:
> 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?

I suppose you already have patches for wireshark for this? I can help
you out with a patch for the Linux kernel as an example producer of
this, and then I think just repost it to the list again to leave some
more discussion time.

johannes

Re: MCS field - STBC and Ness

[Simon Barber]

Hi Johannes & Wojciech,

My work has been on hold, but has recently come off hold. I'm getting 
the patches together. As I rebase my work onto the current wireshark 
trunk I've found a simpler implementation of STBC has been applied by 
Wojciech. My proposal extends the STBC from his implemented 1 bit to 
the full 2 bits allowed in the 11n specification, and also includes 2 
bits of Ness. I've posted an ieee80211 patch, and an intel driver patch 
(both attached to the proposed radiotap extension page). l'll post a 
wireshark patch shortly to start the comment period.

Simon


On Thu 05 Jul 2012 02:12:30 AM PDT, Johannes Berg wrote:
> On Fri, 2012-05-11 at 21:27 -0700, Simon Barber wrote:
>> 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?
>
> I suppose you already have patches for wireshark for this? I can help
> you out with a patch for the Linux kernel as an example producer of
> this, and then I think just repost it to the list again to leave some
> more discussion time.
>
> johannes
>

Re: MCS field - STBC and Ness

[Simon Barber]

OK - I have now posted 3 patches on the proposal page (see Attachments):

1. A patch that applies to the Linux kernel v3.7-rc1 to collect the new 
STBC and Ness parameters from a wireless driver, and add them into the 
MCS radiotap field.
2. A patch to the Intel wireless driver in the kernel to collect STBC 
and Ness information.
3. A patch to wireshark to display STBC and Ness information.

With this I believe we have everything needed to start the 3 week 
comment period.

Simon


On 10/31/2012 05:22 PM, Simon Barber wrote:
> Hi Johannes & Wojciech,
>
> My work has been on hold, but has recently come off hold. I'm getting
> the patches together. As I rebase my work onto the current wireshark
> trunk I've found a simpler implementation of STBC has been applied by
> Wojciech. My proposal extends the STBC from his implemented 1 bit to the
> full 2 bits allowed in the 11n specification, and also includes 2 bits
> of Ness. I've posted an ieee80211 patch, and an intel driver patch (both
> attached to the proposed radiotap extension page). l'll post a wireshark
> patch shortly to start the comment period.
>
> Simon
>
>
> On Thu 05 Jul 2012 02:12:30 AM PDT, Johannes Berg wrote:
>> On Fri, 2012-05-11 at 21:27 -0700, Simon Barber wrote:
>>> 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?
>>
>> I suppose you already have patches for wireshark for this? I can help
>> you out with a patch for the Linux kernel as an example producer of
>> this, and then I think just repost it to the list again to leave some
>> more discussion time.
>>
>> johannes
>>

Re: MCS field - STBC and Ness

[Johannes Berg]

On Thu, 2012-11-01 at 17:24 -0700, Simon Barber wrote:
> OK - I have now posted 3 patches on the proposal page (see Attachments):
> 
> 1. A patch that applies to the Linux kernel v3.7-rc1 to collect the new 
> STBC and Ness parameters from a wireless driver, and add them into the 
> MCS radiotap field.
> 2. A patch to the Intel wireless driver in the kernel to collect STBC 
> and Ness information.
> 3. A patch to wireshark to display STBC and Ness information.

Nice!

> With this I believe we have everything needed to start the 3 week 
> comment period.

Might be worthwhile to post a new thread so it gets everybody's
attention?

johannes

Standardisation - adding 2 bit STBC and Ness to MCS

[Simon Barber]

http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness

I have posted 3 patches on the proposal page (see Attachments):

1. A patch that applies to the Linux kernel v3.7-rc1 to collect the new
STBC and Ness parameters from a wireless driver, and add them into the
MCS radiotap field.
2. A patch to the Intel wireless driver in the kernel to collect STBC
and Ness information.
3. A patch to wireshark to display STBC and Ness information.

With this I believe we have everything needed to start the 3 week
comment period.

Simon Barber

Re: MCS field - STBC and Ness

[David Young]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

On Thu, May 10, 2012 at 05:31:28PM -0700, Simon Barber wrote:
> Hi all,
> 
> 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.

Just in case it is helpful, here is a report written by an undergraduate
project team that I mentored back in 2004.  The task I'd given them was
to produce a Wi-Fi visualizer.  They were not very successful in their
software development, but the report sets out the goal and some design
ideas.

Dave

-- 
David Young
dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org    Urbana, IL    (217) 721-9981

[-- Attachment #2: FinalFinalDocument.pdf --]
[-- Type: application/pdf, Size: 1119852 bytes --]

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Oleksij Rempel]

Hallo all,


> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness
>
> I have posted 3 patches on the proposal page (see Attachments):
>
> 1. A patch that applies to the Linux kernel v3.7-rc1 to collect the new
> STBC and Ness parameters from a wireless driver, and add them into the
> MCS radiotap field.
> 2. A patch to the Intel wireless driver in the kernel to collect STBC
> and Ness information.
> 3. A patch to wireshark to display STBC and Ness information.
>
> With this I believe we have everything needed to start the 3 week
> comment period.

There is a bit more then 3 week now. I would like to have this approved :)
Are there any thing needed to finish this?

Beside, i have one question about how STBC work. According to differnet 
docs, i assume that:
- STBC is done by sending, at least, two stream with same data in 
different order.
- It means for me, that real use of STBC can be made only on MIMO hardware.
- If 1x1 receiver indicates that it got STBC encoded frame, it dos not 
meant, it would be able to use redundant data from second stream.
- There are fallowing STBC schemes: Alamouti’s
STBC for 2 transmit antennas and orthogonal STBC for 3 and 4 transmit 
antennas.

According to this information, what do we call 1,2 or 3 stream STBC?
Since STBC should have minimal 2 stream, but in same time we have 1x1 
and 2x2 hardware which able to receive and decode STBC stream i assume:
	- RX-STBC1 is for compatibility only. No data redundancy.
	- RX-STBC12 - can be used Alamouti’s schema with 2 streams. Mostly used 
method.
	- RX-STBC123 - is orthogonal schema and not widely used method. Since 
last method use wide spectrum to transmit data comparable to SISO 
stream, it makes almost no sense. But 3-stream method get optimal error 
corect in compare with 2 and 4 strea schemas.

Do this assumptions correct?

PS: My assumptions based on "MIMO Space-Time Block Coding (STBC):
Simulations and Results"
-- 
Regards,
Oleksij

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Johannes Berg]

On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:

> > With this I believe we have everything needed to start the 3 week
> > comment period.

Yeah, I guess there was plenty of time. I would have preferred a
separate thread, but I guess there's little enough traffic on this list
so it doesn't really matter.

> There is a bit more then 3 week now. I would like to have this approved :)
> Are there any thing needed to finish this?

http://www.radiotap.org/Standardisation

johannes

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Oleksij Rempel]

Am 02.05.2013 22:44, schrieb Johannes Berg:
> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
>
>>> With this I believe we have everything needed to start the 3 week
>>> comment period.
>
> Yeah, I guess there was plenty of time. I would have preferred a
> separate thread, but I guess there's little enough traffic on this list
> so it doesn't really matter.
>
>> There is a bit more then 3 week now. I would like to have this approved :)
>> Are there any thing needed to finish this?
>
> http://www.radiotap.org/Standardisation
>
> johannes
>

ping.

Johannes, are you the one who says last word on standardisation for 
radiotap?

-- 
Regards,
Oleksij

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Johannes Berg]

On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
> Am 02.05.2013 22:44, schrieb Johannes Berg:
> > On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
> >
> >>> With this I believe we have everything needed to start the 3 week
> >>> comment period.
> >
> > Yeah, I guess there was plenty of time. I would have preferred a
> > separate thread, but I guess there's little enough traffic on this list
> > so it doesn't really matter.
> >
> >> There is a bit more then 3 week now. I would like to have this approved :)
> >> Are there any thing needed to finish this?
> >
> > http://www.radiotap.org/Standardisation
> >
> > johannes
> >
> 
> ping.
> 
> Johannes, are you the one who says last word on standardisation for 
> radiotap?

No? I thought the link made that pretty clear.

But since nobody poked holes in this and it's been a long time, I think
you should probably just post "this has been adopted now" ...

johannes

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Johannes Berg]

On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
> Am 02.05.2013 22:44, schrieb Johannes Berg:
> > On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
> >
> >>> With this I believe we have everything needed to start the 3 week
> >>> comment period.
> >
> > Yeah, I guess there was plenty of time. I would have preferred a
> > separate thread, but I guess there's little enough traffic on this list
> > so it doesn't really matter.
> >
> >> There is a bit more then 3 week now. I would like to have this approved :)
> >> Are there any thing needed to finish this?
> >
> > http://www.radiotap.org/Standardisation
> >
> > johannes
> >
> 
> ping.
> 
> Johannes, are you the one who says last word on standardisation for 
> radiotap?

No? I thought the link made that pretty clear.

But since nobody poked holes in this and it's been a long time, I think
you should probably just post "this has been adopted now" ...

johannes

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Johannes Berg]

On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote:
> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
> > Am 02.05.2013 22:44, schrieb Johannes Berg:
> > > On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
> > >
> > >>> With this I believe we have everything needed to start the 3 week
> > >>> comment period.
> > >
> > > Yeah, I guess there was plenty of time. I would have preferred a
> > > separate thread, but I guess there's little enough traffic on this list
> > > so it doesn't really matter.
> > >
> > >> There is a bit more then 3 week now. I would like to have this approved :)
> > >> Are there any thing needed to finish this?
> > >
> > > http://www.radiotap.org/Standardisation
> > >
> > > johannes
> > >
> > 
> > ping.
> > 
> > Johannes, are you the one who says last word on standardisation for 
> > radiotap?
> 
> No? I thought the link made that pretty clear.
> 
> But since nobody poked holes in this and it's been a long time, I think
> you should probably just post "this has been adopted now" ...

Or actually, go to step 5, preferably reposting it as a separate thread.

johannes

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Johannes Berg]

On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote:
> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
> > Am 02.05.2013 22:44, schrieb Johannes Berg:
> > > On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
> > >
> > >>> With this I believe we have everything needed to start the 3 week
> > >>> comment period.
> > >
> > > Yeah, I guess there was plenty of time. I would have preferred a
> > > separate thread, but I guess there's little enough traffic on this list
> > > so it doesn't really matter.
> > >
> > >> There is a bit more then 3 week now. I would like to have this approved :)
> > >> Are there any thing needed to finish this?
> > >
> > > http://www.radiotap.org/Standardisation
> > >
> > > johannes
> > >
> > 
> > ping.
> > 
> > Johannes, are you the one who says last word on standardisation for 
> > radiotap?
> 
> No? I thought the link made that pretty clear.
> 
> But since nobody poked holes in this and it's been a long time, I think
> you should probably just post "this has been adopted now" ...

Or actually, go to step 5, preferably reposting it as a separate thread.

johannes

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Oleksij Rempel]

Am 07.05.2013 15:55, schrieb Johannes Berg:
> On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote:
>> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
>>> Am 02.05.2013 22:44, schrieb Johannes Berg:
>>>> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
>>>>
>>>>>> With this I believe we have everything needed to start the 3 week
>>>>>> comment period.
>>>>
>>>> Yeah, I guess there was plenty of time. I would have preferred a
>>>> separate thread, but I guess there's little enough traffic on this list
>>>> so it doesn't really matter.
>>>>
>>>>> There is a bit more then 3 week now. I would like to have this approved :)
>>>>> Are there any thing needed to finish this?
>>>>
>>>> http://www.radiotap.org/Standardisation
>>>>
>>>> johannes
>>>>
>>>
>>> ping.
>>>
>>> Johannes, are you the one who says last word on standardisation for
>>> radiotap?
>>
>> No? I thought the link made that pretty clear.
>>
>> But since nobody poked holes in this and it's been a long time, I think
>> you should probably just post "this has been adopted now" ...
>
> Or actually, go to step 5, preferably reposting it as a separate thread.


Simon,

will you do it? You stared it and did most of the work...


-- 
Regards,
Oleksij

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Oleksij Rempel]

Am 07.05.2013 15:55, schrieb Johannes Berg:
> On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote:
>> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
>>> Am 02.05.2013 22:44, schrieb Johannes Berg:
>>>> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
>>>>
>>>>>> With this I believe we have everything needed to start the 3 week
>>>>>> comment period.
>>>>
>>>> Yeah, I guess there was plenty of time. I would have preferred a
>>>> separate thread, but I guess there's little enough traffic on this list
>>>> so it doesn't really matter.
>>>>
>>>>> There is a bit more then 3 week now. I would like to have this approved :)
>>>>> Are there any thing needed to finish this?
>>>>
>>>> http://www.radiotap.org/Standardisation
>>>>
>>>> johannes
>>>>
>>>
>>> ping.
>>>
>>> Johannes, are you the one who says last word on standardisation for
>>> radiotap?
>>
>> No? I thought the link made that pretty clear.
>>
>> But since nobody poked holes in this and it's been a long time, I think
>> you should probably just post "this has been adopted now" ...
>
> Or actually, go to step 5, preferably reposting it as a separate thread.


Simon,

will you do it? You stared it and did most of the work...


-- 
Regards,
Oleksij

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Jonathan Bither]

On 05/07/2013 09:55 AM, Johannes Berg wrote:
> On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote:
>> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
>>> Am 02.05.2013 22:44, schrieb Johannes Berg:
>>>> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
>>>>
>>>>>> With this I believe we have everything needed to start the 3 week
>>>>>> comment period.
>>>>
>>>> Yeah, I guess there was plenty of time. I would have preferred a
>>>> separate thread, but I guess there's little enough traffic on this list
>>>> so it doesn't really matter.
>>>>
>>>>> There is a bit more then 3 week now. I would like to have this approved :)
>>>>> Are there any thing needed to finish this?
>>>>
>>>> http://www.radiotap.org/Standardisation
>>>>
>>>> johannes
>>>>
>>>
>>> ping.
>>>
>>> Johannes, are you the one who says last word on standardisation for
>>> radiotap?
>>
>> No? I thought the link made that pretty clear.
>>
>> But since nobody poked holes in this and it's been a long time, I think
>> you should probably just post "this has been adopted now" ...
>
> Or actually, go to step 5, preferably reposting it as a separate thread.
It looks as if someone already proposed this as a suggested field on 
'2012-05-14 23:49:35' without any replies as far as I can tell.
http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Oleksij Rempel]

Am 07.05.2013 16:59, schrieb Jonathan Bither:
>
>
> On 05/07/2013 09:55 AM, Johannes Berg wrote:
>> On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote:
>>> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
>>>> Am 02.05.2013 22:44, schrieb Johannes Berg:
>>>>> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
>>>>>
>>>>>>> With this I believe we have everything needed to start the 3 week
>>>>>>> comment period.
>>>>>
>>>>> Yeah, I guess there was plenty of time. I would have preferred a
>>>>> separate thread, but I guess there's little enough traffic on this
>>>>> list
>>>>> so it doesn't really matter.
>>>>>
>>>>>> There is a bit more then 3 week now. I would like to have this
>>>>>> approved :)
>>>>>> Are there any thing needed to finish this?
>>>>>
>>>>> http://www.radiotap.org/Standardisation
>>>>>
>>>>> johannes
>>>>>
>>>>
>>>> ping.
>>>>
>>>> Johannes, are you the one who says last word on standardisation for
>>>> radiotap?
>>>
>>> No? I thought the link made that pretty clear.
>>>
>>> But since nobody poked holes in this and it's been a long time, I think
>>> you should probably just post "this has been adopted now" ...
>>
>> Or actually, go to step 5, preferably reposting it as a separate thread.
> It looks as if someone already proposed this as a suggested field on
> '2012-05-14 23:49:35' without any replies as far as I can tell.
> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness

Yes, Simon did it last year. I send this link on my first email...
In my opinion, this should be just ACKed. Every thing what was needed to 
do, is already done.

-- 
Regards,
Oleksij

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Jonathan Bither]

On Tue 07 May 2013 11:03:32 AM EDT, Oleksij Rempel wrote:
> Am 07.05.2013 16:59, schrieb Jonathan Bither:
>>
>>
>> On 05/07/2013 09:55 AM, Johannes Berg wrote:
>>> On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote:
>>>> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
>>>>> Am 02.05.2013 22:44, schrieb Johannes Berg:
>>>>>> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
>>>>>>
>>>>>>>> With this I believe we have everything needed to start the 3 week
>>>>>>>> comment period.
>>>>>>
>>>>>> Yeah, I guess there was plenty of time. I would have preferred a
>>>>>> separate thread, but I guess there's little enough traffic on this
>>>>>> list
>>>>>> so it doesn't really matter.
>>>>>>
>>>>>>> There is a bit more then 3 week now. I would like to have this
>>>>>>> approved :)
>>>>>>> Are there any thing needed to finish this?
>>>>>>
>>>>>> http://www.radiotap.org/Standardisation
>>>>>>
>>>>>> johannes
>>>>>>
>>>>>
>>>>> ping.
>>>>>
>>>>> Johannes, are you the one who says last word on standardisation for
>>>>> radiotap?
>>>>
>>>> No? I thought the link made that pretty clear.
>>>>
>>>> But since nobody poked holes in this and it's been a long time, I
>>>> think
>>>> you should probably just post "this has been adopted now" ...
>>>
>>> Or actually, go to step 5, preferably reposting it as a separate
>>> thread.
>> It looks as if someone already proposed this as a suggested field on
>> '2012-05-14 23:49:35' without any replies as far as I can tell.
>> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness
>>
>
> Yes, Simon did it last year. I send this link on my first email...
> In my opinion, this should be just ACKed. Every thing what was needed
> to do, is already done.
>

Whoops, one of those days I guess. Sorry for the noise.

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Jonathan Bither]

On Tue 07 May 2013 11:03:32 AM EDT, Oleksij Rempel wrote:
> Am 07.05.2013 16:59, schrieb Jonathan Bither:
>>
>>
>> On 05/07/2013 09:55 AM, Johannes Berg wrote:
>>> On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote:
>>>> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
>>>>> Am 02.05.2013 22:44, schrieb Johannes Berg:
>>>>>> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
>>>>>>
>>>>>>>> With this I believe we have everything needed to start the 3 week
>>>>>>>> comment period.
>>>>>>
>>>>>> Yeah, I guess there was plenty of time. I would have preferred a
>>>>>> separate thread, but I guess there's little enough traffic on this
>>>>>> list
>>>>>> so it doesn't really matter.
>>>>>>
>>>>>>> There is a bit more then 3 week now. I would like to have this
>>>>>>> approved :)
>>>>>>> Are there any thing needed to finish this?
>>>>>>
>>>>>> http://www.radiotap.org/Standardisation
>>>>>>
>>>>>> johannes
>>>>>>
>>>>>
>>>>> ping.
>>>>>
>>>>> Johannes, are you the one who says last word on standardisation for
>>>>> radiotap?
>>>>
>>>> No? I thought the link made that pretty clear.
>>>>
>>>> But since nobody poked holes in this and it's been a long time, I
>>>> think
>>>> you should probably just post "this has been adopted now" ...
>>>
>>> Or actually, go to step 5, preferably reposting it as a separate
>>> thread.
>> It looks as if someone already proposed this as a suggested field on
>> '2012-05-14 23:49:35' without any replies as far as I can tell.
>> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness
>>
>
> Yes, Simon did it last year. I send this link on my first email...
> In my opinion, this should be just ACKed. Every thing what was needed
> to do, is already done.
>

Whoops, one of those days I guess. Sorry for the noise.

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Oleksij Rempel]

Am 07.05.2013 16:59, schrieb Jonathan Bither:
>
>
> On 05/07/2013 09:55 AM, Johannes Berg wrote:
>> On Tue, 2013-05-07 at 15:54 +0200, Johannes Berg wrote:
>>> On Tue, 2013-05-07 at 09:40 +0200, Oleksij Rempel wrote:
>>>> Am 02.05.2013 22:44, schrieb Johannes Berg:
>>>>> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
>>>>>
>>>>>>> With this I believe we have everything needed to start the 3 week
>>>>>>> comment period.
>>>>>
>>>>> Yeah, I guess there was plenty of time. I would have preferred a
>>>>> separate thread, but I guess there's little enough traffic on this
>>>>> list
>>>>> so it doesn't really matter.
>>>>>
>>>>>> There is a bit more then 3 week now. I would like to have this
>>>>>> approved :)
>>>>>> Are there any thing needed to finish this?
>>>>>
>>>>> http://www.radiotap.org/Standardisation
>>>>>
>>>>> johannes
>>>>>
>>>>
>>>> ping.
>>>>
>>>> Johannes, are you the one who says last word on standardisation for
>>>> radiotap?
>>>
>>> No? I thought the link made that pretty clear.
>>>
>>> But since nobody poked holes in this and it's been a long time, I think
>>> you should probably just post "this has been adopted now" ...
>>
>> Or actually, go to step 5, preferably reposting it as a separate thread.
> It looks as if someone already proposed this as a suggested field on
> '2012-05-14 23:49:35' without any replies as far as I can tell.
> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness

Yes, Simon did it last year. I send this link on my first email...
In my opinion, this should be just ACKed. Every thing what was needed to 
do, is already done.

-- 
Regards,
Oleksij

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Oleksij Rempel]

Am 02.05.2013 22:44, schrieb Johannes Berg:
> On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:
>
>>> With this I believe we have everything needed to start the 3 week
>>> comment period.
>
> Yeah, I guess there was plenty of time. I would have preferred a
> separate thread, but I guess there's little enough traffic on this list
> so it doesn't really matter.
>
>> There is a bit more then 3 week now. I would like to have this approved :)
>> Are there any thing needed to finish this?
>
> http://www.radiotap.org/Standardisation
>
> johannes
>

ping.

Johannes, are you the one who says last word on standardisation for 
radiotap?

-- 
Regards,
Oleksij

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Johannes Berg]

On Wed, 2013-05-01 at 16:34 +0200, Oleksij Rempel wrote:

> > With this I believe we have everything needed to start the 3 week
> > comment period.

Yeah, I guess there was plenty of time. I would have preferred a
separate thread, but I guess there's little enough traffic on this list
so it doesn't really matter.

> There is a bit more then 3 week now. I would like to have this approved :)
> Are there any thing needed to finish this?

http://www.radiotap.org/Standardisation

johannes

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Simon Barber]

I did post example code as attachments to the suggested-fields page a 
few months ago. Click on 'attachments' to view them. There are 3:

1. Intel wlan driver patch
2. Kernel patch
3. Wireshark patch.

Simon


On 05/01/2013 07:34 AM, Oleksij Rempel wrote:
> Hallo all,
>
>
>> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness
>>
>>
>> I have posted 3 patches on the proposal page (see Attachments):
>>
>> 1. A patch that applies to the Linux kernel v3.7-rc1 to collect the new
>> STBC and Ness parameters from a wireless driver, and add them into the
>> MCS radiotap field.
>> 2. A patch to the Intel wireless driver in the kernel to collect STBC
>> and Ness information.
>> 3. A patch to wireshark to display STBC and Ness information.
>>
>> With this I believe we have everything needed to start the 3 week
>> comment period.
>
> There is a bit more then 3 week now. I would like to have this approved :)
> Are there any thing needed to finish this?
>
> Beside, i have one question about how STBC work. According to differnet
> docs, i assume that:
> - STBC is done by sending, at least, two stream with same data in
> different order.
> - It means for me, that real use of STBC can be made only on MIMO hardware.
> - If 1x1 receiver indicates that it got STBC encoded frame, it dos not
> meant, it would be able to use redundant data from second stream.
> - There are fallowing STBC schemes: Alamouti’s
> STBC for 2 transmit antennas and orthogonal STBC for 3 and 4 transmit
> antennas.
>
> According to this information, what do we call 1,2 or 3 stream STBC?
> Since STBC should have minimal 2 stream, but in same time we have 1x1
> and 2x2 hardware which able to receive and decode STBC stream i assume:
>      - RX-STBC1 is for compatibility only. No data redundancy.
>      - RX-STBC12 - can be used Alamouti’s schema with 2 streams. Mostly
> used method.
>      - RX-STBC123 - is orthogonal schema and not widely used method.
> Since last method use wide spectrum to transmit data comparable to SISO
> stream, it makes almost no sense. But 3-stream method get optimal error
> corect in compare with 2 and 4 strea schemas.
>
> Do this assumptions correct?
>
> PS: My assumptions based on "MIMO Space-Time Block Coding (STBC):
> Simulations and Results"

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Simon Barber]

I did post example code as attachments to the suggested-fields page a 
few months ago. Click on 'attachments' to view them. There are 3:

1. Intel wlan driver patch
2. Kernel patch
3. Wireshark patch.

Simon


On 05/01/2013 07:34 AM, Oleksij Rempel wrote:
> Hallo all,
>
>
>> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness
>>
>>
>> I have posted 3 patches on the proposal page (see Attachments):
>>
>> 1. A patch that applies to the Linux kernel v3.7-rc1 to collect the new
>> STBC and Ness parameters from a wireless driver, and add them into the
>> MCS radiotap field.
>> 2. A patch to the Intel wireless driver in the kernel to collect STBC
>> and Ness information.
>> 3. A patch to wireshark to display STBC and Ness information.
>>
>> With this I believe we have everything needed to start the 3 week
>> comment period.
>
> There is a bit more then 3 week now. I would like to have this approved :)
> Are there any thing needed to finish this?
>
> Beside, i have one question about how STBC work. According to differnet
> docs, i assume that:
> - STBC is done by sending, at least, two stream with same data in
> different order.
> - It means for me, that real use of STBC can be made only on MIMO hardware.
> - If 1x1 receiver indicates that it got STBC encoded frame, it dos not
> meant, it would be able to use redundant data from second stream.
> - There are fallowing STBC schemes: Alamouti’s
> STBC for 2 transmit antennas and orthogonal STBC for 3 and 4 transmit
> antennas.
>
> According to this information, what do we call 1,2 or 3 stream STBC?
> Since STBC should have minimal 2 stream, but in same time we have 1x1
> and 2x2 hardware which able to receive and decode STBC stream i assume:
>      - RX-STBC1 is for compatibility only. No data redundancy.
>      - RX-STBC12 - can be used Alamouti’s schema with 2 streams. Mostly
> used method.
>      - RX-STBC123 - is orthogonal schema and not widely used method.
> Since last method use wide spectrum to transmit data comparable to SISO
> stream, it makes almost no sense. But 3-stream method get optimal error
> corect in compare with 2 and 4 strea schemas.
>
> Do this assumptions correct?
>
> PS: My assumptions based on "MIMO Space-Time Block Coding (STBC):
> Simulations and Results"

Re: Standardisation - adding 2 bit STBC and Ness to MCS

[Oleksij Rempel]

Hallo all,


> http://www.radiotap.org/suggested-fields/MCS%20extension%20for%20STBC%20and%20Ness
>
> I have posted 3 patches on the proposal page (see Attachments):
>
> 1. A patch that applies to the Linux kernel v3.7-rc1 to collect the new
> STBC and Ness parameters from a wireless driver, and add them into the
> MCS radiotap field.
> 2. A patch to the Intel wireless driver in the kernel to collect STBC
> and Ness information.
> 3. A patch to wireshark to display STBC and Ness information.
>
> With this I believe we have everything needed to start the 3 week
> comment period.

There is a bit more then 3 week now. I would like to have this approved :)
Are there any thing needed to finish this?

Beside, i have one question about how STBC work. According to differnet 
docs, i assume that:
- STBC is done by sending, at least, two stream with same data in 
different order.
- It means for me, that real use of STBC can be made only on MIMO hardware.
- If 1x1 receiver indicates that it got STBC encoded frame, it dos not 
meant, it would be able to use redundant data from second stream.
- There are fallowing STBC schemes: Alamouti’s
STBC for 2 transmit antennas and orthogonal STBC for 3 and 4 transmit 
antennas.

According to this information, what do we call 1,2 or 3 stream STBC?
Since STBC should have minimal 2 stream, but in same time we have 1x1 
and 2x2 hardware which able to receive and decode STBC stream i assume:
	- RX-STBC1 is for compatibility only. No data redundancy.
	- RX-STBC12 - can be used Alamouti’s schema with 2 streams. Mostly used 
method.
	- RX-STBC123 - is orthogonal schema and not widely used method. Since 
last method use wide spectrum to transmit data comparable to SISO 
stream, it makes almost no sense. But 3-stream method get optimal error 
corect in compare with 2 and 4 strea schemas.

Do this assumptions correct?

PS: My assumptions based on "MIMO Space-Time Block Coding (STBC):
Simulations and Results"
-- 
Regards,
Oleksij