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

[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

Post by Simon Barber
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

[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

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

Post by Simon Barber
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

[Simon Barber]

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

Simon

Post by 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.
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
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

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

Post by Simon Barber
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

[Johannes Berg]

Post by Simon Barber
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

Post by Simon Barber
Simon

Post by 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.
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
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

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

Post by Simon Barber
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

[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

Post by Johannes Berg

Post by Simon Barber
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

Post by Simon Barber
Simon

Post by 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.
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
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

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

Post by Simon Barber
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

[Johannes Berg]

Post by 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.
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.
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

[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

Post by Johannes Berg

Post by 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.
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.
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

[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

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

Post by Johannes Berg

Post by 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.
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.
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

[Johannes Berg]

Post by Simon Barber
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!

Post by Simon Barber
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

[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

[David Young]

Post by 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.

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