RE: [RFC] VHT fields

RE: [RFC] VHT fields

[Alwin Beukers]

> On Tue, 2012-06-12 at 15:05 +0000, Alwin Beukers wrote:
> > Hi everyone,
> >
> > This is a proposal for adding support for 802.11ac. Four fields were
> added to the suggested-fields section:
> >
> > http://www.radiotap.org/suggested-fields/SU_VHT
> > http://www.radiotap.org/suggested-fields/MU_VHT
> > http://www.radiotap.org/suggested-fields/GROUP_ID
> > http://www.radiotap.org/suggested-fields/PARTIAL_AID
> >
> > A Wireshark patch for parsing SU_VHT, GROUP_ID and PARTIAL_AID is
> attached.
> 
> What's the reason for splitting it up?

Johannes,

The reason for splitting it up is to avoid extra overhead related to MU-MIMO 
when describing VHT SU PPDUs. The separation is based on the different PLCP 
header formats (VHT-SIG-A1/A2/B) for SU and MU PPDUs:

SU PPDUs:
- Only one NSTS, MCS and Coding field.
- Partial AID identifies recipient
- Group ID is always 0 (addressed to AP/mesh STA) or 63 (addressed to STA)

MU PPDUs:
- NSTS, MCS and Coding fields for up to four users
- Partial AID is not applicable
- Group ID is 1..62

All fields common to both SU and MU are in the SU_VHT field. The MU_VHT field 
contains additional information for MU PPDUs. The GROUP_ID and PARTIAL_AID
fields have varying value or applicability.

So for SU PPDUs you would likely have SU_VHT and PARTIAL_AID fields, and maybe
a GROUP_ID field (for SU the GROUP_ID field only provides direction info that
could also be determined from PARTIAL_AID and/or MAC header).
For MU PPDUs you would have SU_VHT (for the common fields as well as 
NSTS/MCS/Coding for the first user), MU_VHT (for NSTS/MCS/Coding for
additional users), and GROUP_ID.

By combining fields we can reduce complexity at the expense of some increased
overhead, what are your thoughts on his? Also, I was wondering if we need all
of the 'known' flags in SU_VHT. The MCS field (after which SU_VHT was modeled)
also has these, but I don’t know the rationale behind them. Can one assume a
driver has full access to the PLCP header and thus can fill in most of fields
in the SU_VHT field?

Thanks,
Alwin
 
> johannes
> 

RE: [RFC] VHT fields

[Johannes Berg]

On Fri, 2012-06-15 at 08:15 +0000, Alwin Beukers wrote:

> The reason for splitting it up is to avoid extra overhead related to MU-MIMO 
> when describing VHT SU PPDUs. The separation is based on the different PLCP 
> header formats (VHT-SIG-A1/A2/B) for SU and MU PPDUs:
> 
> SU PPDUs:
> - Only one NSTS, MCS and Coding field.
> - Partial AID identifies recipient
> - Group ID is always 0 (addressed to AP/mesh STA) or 63 (addressed to STA)
> 
> MU PPDUs:
> - NSTS, MCS and Coding fields for up to four users
> - Partial AID is not applicable
> - Group ID is 1..62
> 
> All fields common to both SU and MU are in the SU_VHT field. The MU_VHT field 
> contains additional information for MU PPDUs. The GROUP_ID and PARTIAL_AID
> fields have varying value or applicability.

Ok, makes sense.

> So for SU PPDUs you would likely have SU_VHT and PARTIAL_AID fields, and maybe
> a GROUP_ID field (for SU the GROUP_ID field only provides direction info that
> could also be determined from PARTIAL_AID and/or MAC header).

Right. I haven't looked into all these details of 11ac (yet)

> For MU PPDUs you would have SU_VHT (for the common fields as well as 
> NSTS/MCS/Coding for the first user), MU_VHT (for NSTS/MCS/Coding for
> additional users), and GROUP_ID.
> 
> By combining fields we can reduce complexity at the expense of some increased
> overhead, what are your thoughts on his? 

I don't really care much either way -- was mostly curious why you were
splitting it up so much.

I have a feeling though that the group ID would be useful to always
have, even if it's just 0/63 in the SU case, to make it easier on
filtering?

> Also, I was wondering if we need all
> of the 'known' flags in SU_VHT. The MCS field (after which SU_VHT was modeled)
> also has these, but I don’t know the rationale behind them. Can one assume a
> driver has full access to the PLCP header and thus can fill in most of fields
> in the SU_VHT field?

I know that's usually the case for your devices, but it isn't typically
the case for all the random devices out there ... so I think we should
have the known flags to not run into a situation later where a device
has to lie.

johannes

RE: [RFC] VHT fields

[Johannes Berg]

On Fri, 2012-06-15 at 08:15 +0000, Alwin Beukers wrote:

> The reason for splitting it up is to avoid extra overhead related to MU-MIMO 
> when describing VHT SU PPDUs. The separation is based on the different PLCP 
> header formats (VHT-SIG-A1/A2/B) for SU and MU PPDUs:
> 
> SU PPDUs:
> - Only one NSTS, MCS and Coding field.
> - Partial AID identifies recipient
> - Group ID is always 0 (addressed to AP/mesh STA) or 63 (addressed to STA)
> 
> MU PPDUs:
> - NSTS, MCS and Coding fields for up to four users
> - Partial AID is not applicable
> - Group ID is 1..62
> 
> All fields common to both SU and MU are in the SU_VHT field. The MU_VHT field 
> contains additional information for MU PPDUs. The GROUP_ID and PARTIAL_AID
> fields have varying value or applicability.

Ok.

> So for SU PPDUs you would likely have SU_VHT and PARTIAL_AID fields, and maybe
> a GROUP_ID field (for SU the GROUP_ID field only provides direction info that
> could also be determined from PARTIAL_AID and/or MAC header).

Ok, I'm not too familiar with 11ac yet.

> For MU PPDUs you would have SU_VHT (for the common fields as well as 
> NSTS/MCS/Coding for the first user), MU_VHT (for NSTS/MCS/Coding for
> additional users), and GROUP_ID.
> 
> By combining fields we can reduce complexity at the expense of some increased
> overhead, what are your thoughts on his? 

I don't really care much either way -- was mostly curious why you were
splitting it up so much.

I have a feeling though that the group ID would be useful to always
have, even if it's just 0/63 in the SU case, to make it easier on
filtering?

> Also, I was wondering if we need all
> of the 'known' flags in SU_VHT. The MCS field (after which SU_VHT was modeled)
> also has these, but I don’t know the rationale behind them. Can one assume a
> driver has full access to the PLCP header and thus can fill in most of fields
> in the SU_VHT field?

I know that's usually the case for your devices, but it isn't typically
the case for all the random devices out there ... so I think we should
have the known flags to not run into a situation later where a device
has to lie.

johannes

RE: [RFC] VHT fields

[Alwin Beukers]

Hi Johannes,

> I have a feeling though that the group ID would be useful to always
> have, even if it's just 0/63 in the SU case, to make it easier on
> filtering?

Good point, putting this into the SU_VHT field and dropping VHT_GROUP
will make things easier.
 
> > Also, I was wondering if we need all
> > of the 'known' flags in SU_VHT. The MCS field (after which SU_VHT was
> > modeled)
> > also has these, but I don’t know the rationale behind them. Can one
> > assume a
> > driver has full access to the PLCP header and thus can fill in most
> > of fields
> > in the SU_VHT field?
> 
> I know that's usually the case for your devices, but it isn't typically
> the case for all the random devices out there ... so I think we should
> have the known flags to not run into a situation later where a device
> has to lie.

Makes sense, I'll keep these in then.

Thanks,
Alwin

Re: [RFC] VHT fields

[Simon Barber]

I'm not very familar with 11ac - but does this information together 
with the packet data give you enough to calculate precisely the 
packet's duration in time? Are there any duration fields, as there are 
in 11n that might be useful?

Simon

On Fri 15 Jun 2012 01:15:26 AM PDT, Alwin Beukers wrote:
>> On Tue, 2012-06-12 at 15:05 +0000, Alwin Beukers wrote:
>>> Hi everyone,
>>>
>>> This is a proposal for adding support for 802.11ac. Four fields were
>> added to the suggested-fields section:
>>>
>>> http://www.radiotap.org/suggested-fields/SU_VHT
>>> http://www.radiotap.org/suggested-fields/MU_VHT
>>> http://www.radiotap.org/suggested-fields/GROUP_ID
>>> http://www.radiotap.org/suggested-fields/PARTIAL_AID
>>>
>>> A Wireshark patch for parsing SU_VHT, GROUP_ID and PARTIAL_AID is
>> attached.
>>
>> What's the reason for splitting it up?
>
> Johannes,
>
> The reason for splitting it up is to avoid extra overhead related to MU-MIMO
> when describing VHT SU PPDUs. The separation is based on the different PLCP
> header formats (VHT-SIG-A1/A2/B) for SU and MU PPDUs:
>
> SU PPDUs:
> - Only one NSTS, MCS and Coding field.
> - Partial AID identifies recipient
> - Group ID is always 0 (addressed to AP/mesh STA) or 63 (addressed to STA)
>
> MU PPDUs:
> - NSTS, MCS and Coding fields for up to four users
> - Partial AID is not applicable
> - Group ID is 1..62
>
> All fields common to both SU and MU are in the SU_VHT field. The MU_VHT field
> contains additional information for MU PPDUs. The GROUP_ID and PARTIAL_AID
> fields have varying value or applicability.
>
> So for SU PPDUs you would likely have SU_VHT and PARTIAL_AID fields, and maybe
> a GROUP_ID field (for SU the GROUP_ID field only provides direction info that
> could also be determined from PARTIAL_AID and/or MAC header).
> For MU PPDUs you would have SU_VHT (for the common fields as well as
> NSTS/MCS/Coding for the first user), MU_VHT (for NSTS/MCS/Coding for
> additional users), and GROUP_ID.
>
> By combining fields we can reduce complexity at the expense of some increased
> overhead, what are your thoughts on his? Also, I was wondering if we need all
> of the 'known' flags in SU_VHT. The MCS field (after which SU_VHT was modeled)
> also has these, but I don’t know the rationale behind them. Can one assume a
> driver has full access to the PLCP header and thus can fill in most of fields
> in the SU_VHT field?
>
> Thanks,
> Alwin
>
>> johannes
>>
>
>

RE: [RFC] VHT fields

[Alwin Beukers]

Hi Simon,

> I'm not very familar with 11ac - but does this information together
> with the packet data give you enough to calculate precisely the
> packet's duration in time? Are there any duration fields, as there are
> in 11n that might be useful?

Haven't tried it, but I think you would have all the required info.

Section 22.3.2 of the 11ac draft has the durations of the training and
signal fields. The duration of VHT-LTF depends on the total number
of space-time streams (NSTS), which you can get from the SU_VHT
and MU_VHT fields.

The radiotap header doesn't contain the data length from the 
VHT-SIG-B field, but I guess you can get that from the packet data
itself. There is a datarate calculation in the Wireshark patch I sent
with the proposal.

Alwin

> 
> Simon

RE: [RFC] VHT fields

[Alwin Beukers]

> On Tue, 2012-06-12 at 15:05 +0000, Alwin Beukers wrote:
> > Hi everyone,
> >
> > This is a proposal for adding support for 802.11ac. Four fields were
> added to the suggested-fields section:
> >
> > http://www.radiotap.org/suggested-fields/SU_VHT
> > http://www.radiotap.org/suggested-fields/MU_VHT
> > http://www.radiotap.org/suggested-fields/GROUP_ID
> > http://www.radiotap.org/suggested-fields/PARTIAL_AID
> >
> > A Wireshark patch for parsing SU_VHT, GROUP_ID and PARTIAL_AID is
> attached.
> 
> What's the reason for splitting it up?

Johannes,

The reason for splitting it up is to avoid extra overhead related to MU-MIMO when describing VHT SU PPDUs. The separation is based on the different PLCP header formats (VHT-SIG-A1/A2/B) for SU and MU PPDUs:

SU PPDUs:
- Only one NSTS, MCS and Coding field.
- Partial AID identifies recipient
- Group ID is always 0 (addressed to AP/mesh STA) or 63 (addressed to STA)

MU PPDUs:
- NSTS, MCS and Coding fields for up to four users
- Partial AID is not applicable
- Group ID is 1..62

All fields common to both SU and MU are in the SU_VHT field. The MU_VHT field contains additional information for MU PPDUs. The GROUP_ID and PARTIAL_AID fields have varying value or applicability.

So for SU PPDUs you would likely have SU_VHT and PARTIAL_AID fields, and maybe a GROUP_ID field (for SU the GROUP_ID field only provides direction info that could also be determined from PARTIAL_AID and/or MAC header).
For MU PPDUs you would have SU_VHT (for the common fields as well as NSTS/MCS/Coding for the first user), MU_VHT (for NSTS/MCS/Coding for additional users), and GROUP_ID.

By combining fields we can reduce complexity at the expense of some increased overhead, what are your thoughts on his? Also, I was wondering if we need all of the 'known' flags in SU_VHT. The MCS field (after which SU_VHT was modeled) also has these, but I don’t know the rationale behind them. Can one assume a driver has full access to the PLCP header and thus can fill in most of fields in the SU_VHT field?

Thanks,
Alwin
 
> johannes
> 

[RFC] VHT fields

[Alwin Beukers]

Hi everyone,

This is a proposal for adding support for 802.11ac. Four fields were added to the suggested-fields section:

http://www.radiotap.org/suggested-fields/SU_VHT
http://www.radiotap.org/suggested-fields/MU_VHT
http://www.radiotap.org/suggested-fields/GROUP_ID
http://www.radiotap.org/suggested-fields/PARTIAL_AID

A Wireshark patch for parsing SU_VHT, GROUP_ID and PARTIAL_AID is attached.

Any thoughts?

Thanks,
Alwin

---

Index: epan/dissectors/packet-ieee80211-radiotap-defs.h
===================================================================
--- epan/dissectors/packet-ieee80211-radiotap-defs.h	(revision 43220)
+++ epan/dissectors/packet-ieee80211-radiotap-defs.h	(working copy)
@@ -204,6 +204,10 @@
 	IEEE80211_RADIOTAP_DATA_RETRIES = 17,
 	IEEE80211_RADIOTAP_XCHANNEL = 18, /* Unofficial, used by FreeBSD */
 	IEEE80211_RADIOTAP_MCS = 19,
+	IEEE80211_RADIOTAP_SU_VHT = 20,
+	IEEE80211_RADIOTAP_GROUP_ID = 21,
+	IEEE80211_RADIOTAP_PARTIAL_AID = 22,
+	IEEE80211_RADIOTAP_MU_VHT = 23,
 
 	/* valid in every it_present bitmap, even vendor namespaces */
 	IEEE80211_RADIOTAP_RADIOTAP_NAMESPACE = 29,
@@ -270,4 +274,60 @@
 #define IEEE80211_RADIOTAP_MCS_FEC_LDPC		0x10
 #define IEEE80211_RADIOTAP_MCS_STBC		0x20
 
+/* For IEEE80211_RADIOTAP_SU_VHT */
+#define IEEE80211_RADIOTAP_SU_VHT_HAVE_STBC	0x01
+#define IEEE80211_RADIOTAP_SU_VHT_HAVE_TXOP_PS	0x02
+#define IEEE80211_RADIOTAP_SU_VHT_HAVE_GI	0x04
+#define IEEE80211_RADIOTAP_SU_VHT_HAVE_CODING	0x08
+#define IEEE80211_RADIOTAP_SU_VHT_HAVE_BF	0x10
+#define IEEE80211_RADIOTAP_SU_VHT_HAVE_BW	0x20
+#define IEEE80211_RADIOTAP_SU_VHT_HAVE_NSTS	0x40
+#define IEEE80211_RADIOTAP_SU_VHT_HAVE_MCS_NSS	0x80
+
+#define IEEE80211_RADIOTAP_SU_VHT_STBC		0x01
+#define IEEE80211_RADIOTAP_SU_VHT_TXOP_PS	0x02
+#define IEEE80211_RADIOTAP_SU_VHT_SGI		0x04
+#define IEEE80211_RADIOTAP_SU_VHT_SGI_NSYM_DA	0x08
+#define IEEE80211_RADIOTAP_SU_VHT_CODING_LDPC	0x10
+#define IEEE80211_RADIOTAP_SU_VHT_LDPC_EXTRA	0x20
+#define IEEE80211_RADIOTAP_SU_VHT_BF		0x40
+
+#define IEEE80211_RADIOTAP_SU_VHT_NSTS		0x0f
+#define IEEE80211_RADIOTAP_SU_VHT_BW		0xf0
+
+#define IEEE80211_RADIOTAP_SU_VHT_MCS		0x0f
+#define IEEE80211_RADIOTAP_SU_VHT_NSS		0x70
+
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20		IEEE80211_RADIOTAP_MCS_BW_20
+#define IEEE80211_RADIOTAP_SU_VHT_BW_40		IEEE80211_RADIOTAP_MCS_BW_40
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20L	IEEE80211_RADIOTAP_MCS_BW_20L
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20U	IEEE80211_RADIOTAP_MCS_BW_20U
+#define IEEE80211_RADIOTAP_SU_VHT_BW_80		4
+#define IEEE80211_RADIOTAP_SU_VHT_BW_40L	5
+#define IEEE80211_RADIOTAP_SU_VHT_BW_40U	6
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20LL	7
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20LU	8
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20UL	9
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20UU	10
+#define IEEE80211_RADIOTAP_SU_VHT_BW_160	11
+#define IEEE80211_RADIOTAP_SU_VHT_BW_80L	12
+#define IEEE80211_RADIOTAP_SU_VHT_BW_80U	13
+#define IEEE80211_RADIOTAP_SU_VHT_BW_40LL	14
+#define IEEE80211_RADIOTAP_SU_VHT_BW_40LU	15
+#define IEEE80211_RADIOTAP_SU_VHT_BW_40UL	16
+#define IEEE80211_RADIOTAP_SU_VHT_BW_40UU	17
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20LLL	18
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20LLU	19
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20LUL	20
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20LUU	21
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20ULL	22
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20ULU	23
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20UUL	24
+#define IEEE80211_RADIOTAP_SU_VHT_BW_20UUU	25
+
+/* For IEEE80211_RADIOTAP_MU_VHT */
+#define IEEE80211_RADIOTAP_MU_VHT_NSTS_MASK	0x07
+#define IEEE80211_RADIOTAP_MU_VHT_CODING_LDPC	0x08
+#define IEEE80211_RADIOTAP_MU_VHT_MCS		0xf0
+
 #endif				/* IEEE80211_RADIOTAP_H */
Index: epan/dissectors/packet-ieee80211-radiotap.c
===================================================================
--- epan/dissectors/packet-ieee80211-radiotap.c	(revision 43220)
+++ epan/dissectors/packet-ieee80211-radiotap.c	(working copy)
@@ -79,6 +79,137 @@
 #define	IEEE80211_CHAN_108PUREG \
 	(IEEE80211_CHAN_PUREG | IEEE80211_CHAN_TURBO)
 
+#define MAX_MCS_VHT_INDEX	9
+
+/*
+ * Maps a VHT bandwidth index to ieee80211_vhtinfo.rates index.
+ */
+static const int ieee80211_vht_bw2rate_index[] = {
+		/*  20Mhz total */	0,
+		/*  40Mhz total */	1, 0, 0,
+		/*  80Mhz total */	2, 1, 1, 0, 0, 0, 0,
+		/* 160Mhz total */	3, 2, 2, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0
+};
+
+struct mcs_vht_info {
+	char *modulation;
+	char *coding_rate;
+	float rates[4][2];
+};
+
+static const struct mcs_vht_info ieee80211_vhtinfo[MAX_MCS_VHT_INDEX+1] = {
+		/* MCS  0  */
+		{	"BPSK",		"1/2",
+				{		/* 20 Mhz */  {    6.5f,		/* SGI */    7.2f, },
+						/* 40 Mhz */  {   13.5f,		/* SGI */   15.0f, },
+						/* 80 Mhz */  {   29.3f,		/* SGI */   32.5f, },
+						/* 160 Mhz */ {   58.5f,		/* SGI */   65.0f, }
+				}
+		},
+		/* MCS  1  */
+		{	"QPSK",		"1/2",
+				{		/* 20 Mhz */  {   13.0f,		/* SGI */   14.4f, },
+						/* 40 Mhz */  {   27.0f,		/* SGI */   30.0f, },
+						/* 80 Mhz */  {   58.5f,		/* SGI */   65.0f, },
+						/* 160 Mhz */ {  117.0f,		/* SGI */  130.0f, }
+				}
+		},
+		/* MCS  2  */
+		{	"QPSK",		"3/4",
+				{		/* 20 Mhz */  {   19.5f,		/* SGI */   21.7f, },
+						/* 40 Mhz */  {   40.5f,		/* SGI */   45.0f, },
+						/* 80 Mhz */  {   87.8f,		/* SGI */   97.5f, },
+						/* 160 Mhz */ {  175.5f,		/* SGI */  195.0f, }
+				}
+		},
+		/* MCS  3  */
+		{	"16-QAM",	"1/2",
+				{		/* 20 Mhz */  {   26.0f,		/* SGI */   28.9f, },
+						/* 40 Mhz */  {   54.0f,		/* SGI */   60.0f, },
+						/* 80 Mhz */  {  117.0f,		/* SGI */  130.0f, },
+						/* 160 Mhz */ {  234.0f,		/* SGI */  260.0f, }
+				}
+		},
+		/* MCS  4  */
+		{	"16-QAM",	"3/4",
+				{		/* 20 Mhz */  {   39.0f,		/* SGI */   43.3f, },
+						/* 40 Mhz */  {   81.0f,		/* SGI */   90.0f, },
+						/* 80 Mhz */  {  175.5f,		/* SGI */  195.0f, },
+						/* 160 Mhz */ {  351.0f,		/* SGI */  390.0f, }
+				}
+		},
+		/* MCS  5  */
+		{	"64-QAM",	"2/3",
+				{		/* 20 Mhz */  {   52.0f,		/* SGI */   57.8f, },
+						/* 40 Mhz */  {  108.0f,		/* SGI */  120.0f, },
+						/* 80 Mhz */  {  234.0f,		/* SGI */  260.0f, },
+						/* 160 Mhz */ {  468.0f,		/* SGI */  520.0f, }
+				}
+		},
+		/* MCS  6  */
+		{	"64-QAM",	"3/4",
+				{		/* 20 Mhz */  {   58.5f,		/* SGI */   65.0f, },
+						/* 40 Mhz */  {  121.5f,		/* SGI */  135.0f, },
+						/* 80 Mhz */  {  263.3f,		/* SGI */  292.5f, },
+						/* 160 Mhz */ {  526.5f,		/* SGI */  585.0f, }
+				}
+		},
+		/* MCS  7  */
+		{	"64-QAM",	"5/6",
+				{		/* 20 Mhz */  {   65.0f,		/* SGI */   72.2f, },
+						/* 40 Mhz */  {  135.0f,		/* SGI */  150.0f, },
+						/* 80 Mhz */  {  292.5f,		/* SGI */  325.0f, },
+						/* 160 Mhz */ {  585.0f,		/* SGI */  650.0f, }
+				}
+		},
+		/* MCS  8  */
+		{	"256-QAM",	"3/4",
+				{		/* 20 Mhz */  {   78.0f,		/* SGI */   86.7f, },
+						/* 40 Mhz */  {  162.0f,		/* SGI */  180.0f, },
+						/* 80 Mhz */  {  351.0f,		/* SGI */  390.0f, },
+						/* 160 Mhz */ {  702.0f,		/* SGI */  780.0f, }
+				}
+		},
+		/* MCS  9  */
+		{	"256-QAM",	"5/6",
+				{		/* 20 Mhz */  {    0.0f,		/* SGI */    0.0f, },
+						/* 40 Mhz */  {  180.0f,		/* SGI */  200.0f, },
+						/* 80 Mhz */  {  390.0f,		/* SGI */  433.3f, },
+						/* 160 Mhz */ {  780.0f,		/* SGI */  866.7f, }
+				}
+		}
+};
+
+static const value_string vht_bandwidth[] = {
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20, "20 MHz" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20L, "20 MHz lower" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20U, "20 MHz upper" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_40, "40 MHz" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20LL, "20 MHz, channel 1/4" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20LU, "20 MHz, channel 2/4" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20UL, "20 MHz, channel 3/4" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20UU, "20 MHz, channel 4/4" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_40L, "40 MHz lower" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_40U, "40 MHz upper" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_80, "80 MHz" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20LLL, "20 MHz, channel 1/8" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20LLU, "20 MHz, channel 2/8" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20LUL, "20 MHz, channel 3/8" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20LUU, "20 MHz, channel 4/8" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20ULL, "20 MHz, channel 5/8" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20ULU, "20 MHz, channel 6/8" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20UUL, "20 MHz, channel 7/8" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_20UUU, "20 MHz, channel 8/8" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_40LL, "40 MHz, channel 1/4" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_40LU, "40 MHz, channel 2/4" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_40UL, "40 MHz, channel 3/4" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_40UU, "40 MHz, channel 4/4" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_80L, "80 MHz lower" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_80U, "80 MHz upper" },
+	{ IEEE80211_RADIOTAP_SU_VHT_BW_160, "160 MHz" },
+	{ 0, NULL }
+};
+
 #define MAX_MCS_INDEX	76
 
 /*
@@ -553,6 +684,29 @@
 static int hf_radiotap_mcs_format = -1;
 static int hf_radiotap_mcs_fec = -1;
 static int hf_radiotap_mcs_stbc = -1;
+static int hf_radiotap_su_vht = -1;
+static int hf_radiotap_su_vht_known = -1;
+static int hf_radiotap_su_vht_have_stbc = -1;
+static int hf_radiotap_su_vht_have_txop_ps = -1;
+static int hf_radiotap_su_vht_have_gi = -1;
+static int hf_radiotap_su_vht_have_coding = -1;
+static int hf_radiotap_su_vht_have_bf = -1;
+static int hf_radiotap_su_vht_have_bw = -1;
+static int hf_radiotap_su_vht_have_nsts = -1;
+static int hf_radiotap_su_vht_have_mcs_nss = -1;
+static int hf_radiotap_su_vht_stbc = -1;
+static int hf_radiotap_su_vht_txop_ps = -1;
+static int hf_radiotap_su_vht_gi = -1;
+static int hf_radiotap_su_vht_sgi_nsym_da = -1;
+static int hf_radiotap_su_vht_coding = -1;
+static int hf_radiotap_su_vht_ldpc_extra = -1;
+static int hf_radiotap_su_vht_bf = -1;
+static int hf_radiotap_su_vht_bw = -1;
+static int hf_radiotap_su_vht_nsts = -1;
+static int hf_radiotap_su_vht_mcs = -1;
+static int hf_radiotap_su_vht_nss = -1;
+static int hf_radiotap_gid = -1;
+static int hf_radiotap_aid = -1;
 
 /* "Present" flags */
 static int hf_radiotap_present_tsft = -1;
@@ -573,6 +727,7 @@
 static int hf_radiotap_present_rxflags = -1;
 static int hf_radiotap_present_xchannel = -1;
 static int hf_radiotap_present_mcs = -1;
+static int hf_radiotap_present_su_vht = -1;
 static int hf_radiotap_present_rtap_ns = -1;
 static int hf_radiotap_present_vendor_ns = -1;
 static int hf_radiotap_present_ext = -1;
@@ -601,6 +756,8 @@
 static gint ett_radiotap_vendor = -1;
 static gint ett_radiotap_mcs = -1;
 static gint ett_radiotap_mcs_known = -1;
+static gint ett_radiotap_su_vht = -1;
+static gint ett_radiotap_su_vht_known = -1;
 
 static dissector_handle_t ieee80211_handle;
 static dissector_handle_t ieee80211_datapad_handle;
@@ -905,6 +1062,11 @@
 		  FT_BOOLEAN, 32, NULL, RADIOTAP_MASK(MCS),
 		  "Specifies if the HT field is present", HFILL}},
 
+		{&hf_radiotap_present_su_vht,
+		 {"VHT information", "radiotap.present.su_vht",
+		  FT_BOOLEAN, 32, NULL, RADIOTAP_MASK(SU_VHT),
+		  "Specifies if the VHT field is present", HFILL}},
+
 		{&hf_radiotap_present_rtap_ns,
 		 {"Radiotap NS next", "radiotap.present.rtap_ns",
 		  FT_BOOLEAN, 32, NULL, RADIOTAP_MASK(RADIOTAP_NAMESPACE),
@@ -1261,6 +1423,100 @@
 		 {"MCS index", "radiotap.mcs.index",
 		  FT_UINT8, BASE_DEC, NULL, 0x0, NULL, HFILL}},
 
+		{&hf_radiotap_su_vht,
+		 {"VHT information", "radiotap.vht",
+		  FT_NONE, BASE_NONE, NULL, 0x0, NULL, HFILL}},
+		{&hf_radiotap_su_vht_known,
+		 {"Known VHT information", "radiotap.vht.known",
+		  FT_UINT8, BASE_HEX, NULL, 0x0,
+		  "Bit mask indicating what VHT information is present", HFILL}},
+		{&hf_radiotap_su_vht_have_stbc,
+		 {"STBC", "radiotap.vht.have_stbc",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_HAVE_STBC,
+		  "Space Time Block Coding information present", HFILL}},
+		{&hf_radiotap_su_vht_have_txop_ps,
+		 {"TXOP_PS_NOT_ALLOWED", "radiotap.vht.have_txop_ps",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_HAVE_TXOP_PS,
+		  "TXOP_PS_NOT_ALLOWED information present", HFILL}},
+		{&hf_radiotap_su_vht_have_gi,
+		 {"Guard interval and SGI Nsym disambiguation", "radiotap.vht.have_gi",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_HAVE_GI,
+		  "Short/Long guard interval and SGI Nsym disambiguation information present", HFILL}},
+		{&hf_radiotap_su_vht_have_coding,
+		 {"Coding and LDPC extra symbol", "radiotap.vht.have_coding",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_HAVE_CODING,
+		  "Coding and LDPC extra OFDM symbol information present", HFILL}},
+		{&hf_radiotap_su_vht_have_bf,
+		 {"Beamformed", "radiotap.vht.have_beamformed",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_HAVE_BF,
+		  "Beamformed information present", HFILL}},
+		{&hf_radiotap_su_vht_have_bw,
+		 {"Bandwidth", "radiotap.mcs.have_bw",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_HAVE_BW,
+		  "Bandwidth information present", HFILL}},
+		{&hf_radiotap_su_vht_have_nsts,
+		 {"Nsts", "radiotap.vht.have_nsts",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_HAVE_NSTS,
+		  "Number of Space-time streams information present", HFILL}},
+		{&hf_radiotap_su_vht_have_mcs_nss,
+		 {"MCS index and Nss count", "radiotap.vht.have_mcs_nss",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_HAVE_MCS_NSS,
+		  "MCS index and Nss information present", HFILL}},
+		{&hf_radiotap_su_vht_stbc,
+		 {"STBC", "radiotap.vht.stbc",
+		  FT_BOOLEAN, 8, TFS(&tfs_on_off), IEEE80211_RADIOTAP_SU_VHT_STBC,
+		  "Space Time Block Coding flag", HFILL}},
+		{&hf_radiotap_su_vht_txop_ps,
+		 {"TXOP_PS_NOT_ALLOWED", "radiotap.vht.txop_ps",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_TXOP_PS,
+		  "Flag indicating whether STAs may doze during TXOP", HFILL}},
+		{&hf_radiotap_su_vht_gi,
+		 {"Guard interval", "radiotap.vht.gi",
+		  FT_UINT8, BASE_DEC, VALS(mcs_gi), IEEE80211_RADIOTAP_SU_VHT_SGI,
+		  "Short/Long guard interval", HFILL}},
+		{&hf_radiotap_su_vht_sgi_nsym_da,
+		 {"SGI Nsym disambiguation", "radiotap.vht.nsym_da",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_SGI_NSYM_DA,
+		  "Short Guard Interval Nsym disambiguation", HFILL}},
+		{&hf_radiotap_su_vht_coding,
+		 {"Coding", "radiotap.vht.coding",
+		  FT_UINT8, BASE_DEC, VALS(mcs_fec), IEEE80211_RADIOTAP_SU_VHT_CODING_LDPC,
+		  "Coding", HFILL}},
+		{&hf_radiotap_su_vht_ldpc_extra,
+		 {"LDPC extra OFDM symbol", "radiotap.vht.ldpc_extra",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_LDPC_EXTRA,
+		  "LDPC extra OFDM symbol", HFILL}},
+		{&hf_radiotap_su_vht_bf,
+		 {"Beamformed", "radiotap.vht.beamformed",
+		  FT_BOOLEAN, 8, NULL, IEEE80211_RADIOTAP_SU_VHT_BF,
+		  "Beamformed", HFILL}},
+		{&hf_radiotap_su_vht_bw,
+		 {"Bandwidth", "radiotap.vht.bw",
+		  FT_UINT8, BASE_DEC, VALS(vht_bandwidth), IEEE80211_RADIOTAP_SU_VHT_BW,
+		  "Bandwidth", HFILL}},
+		{&hf_radiotap_su_vht_nsts,
+		 {"Nsts", "radiotap.vht.nsts",
+		  FT_UINT8, BASE_DEC, NULL, IEEE80211_RADIOTAP_SU_VHT_NSTS,
+		  "Number of Space-time streams", HFILL}},
+		{&hf_radiotap_su_vht_mcs,
+		 {"MCS index", "radiotap.vht.mcs",
+		  FT_UINT8, BASE_DEC, NULL, IEEE80211_RADIOTAP_SU_VHT_MCS,
+		  "MCS index", HFILL}},
+		{&hf_radiotap_su_vht_nss,
+		 {"Nss", "radiotap.vht.nss",
+		  FT_UINT8, BASE_DEC, NULL, IEEE80211_RADIOTAP_SU_VHT_NSS,
+		  "Number of spatial streams", HFILL}},
+
+		{&hf_radiotap_gid,
+		 {"Group Id", "radiotap.gid",
+		  FT_UINT8, BASE_DEC, NULL, 0x0,
+		  "VHT Group Id", HFILL}},
+
+		{&hf_radiotap_aid,
+		 {"Partial AID", "radiotap.aid",
+		  FT_UINT16, BASE_DEC, NULL, 0x0,
+		  "VHT partial AID", HFILL}},
+
 		{&hf_radiotap_vendor_ns,
 		 {"Vendor namespace", "radiotap.vendor_namespace",
 		  FT_BYTES, BASE_NONE, NULL, 0x0,
@@ -1304,6 +1560,8 @@
 		&ett_radiotap_vendor,
 		&ett_radiotap_mcs,
 		&ett_radiotap_mcs_known,
+		&ett_radiotap_su_vht,
+		&ett_radiotap_su_vht_known
 	};
 	module_t *radiotap_module;
 
@@ -1509,6 +1767,10 @@
 			proto_tree_add_item(present_tree,
 					    hf_radiotap_present_mcs, tvb,
 					    offset + 4, 4, ENC_LITTLE_ENDIAN);
+			proto_tree_add_item(present_tree,
+					    hf_radiotap_present_su_vht, tvb,
+					    offset + 4, 4, ENC_LITTLE_ENDIAN);
+
  always_bits:
 			proto_tree_add_item(present_tree,
 					    hf_radiotap_present_rtap_ns, tvb,
@@ -1939,6 +2201,7 @@
 			}
 			break;
 		}
+
 		case IEEE80211_RADIOTAP_MCS: {
 			proto_item *it;
 			proto_tree *mcs_tree = NULL, *mcs_known_tree;
@@ -2045,7 +2308,178 @@
 			}
 			break;
 		}
+
+		case IEEE80211_RADIOTAP_SU_VHT: {
+			proto_item *it;
+			proto_tree *mcs_tree = NULL, *mcs_known_tree;
+			guint8 mcs_known, mcs_flags, mcs_bw, mcs;
+			guint bandwidth = 0;
+			guint gi_length = 0;
+			guint nss = 0;
+			guint mcs_index = 0;
+			gboolean can_calculate_rate;
+
+			/*
+			 * Start out assuming that we can calculate the rate;
+			 * if we are missing any of the MCS index, channel
+			 * width, or guard interval length, we can't.
+			 */
+			can_calculate_rate = TRUE;
+
+			mcs_known = tvb_get_guint8(tvb, offset);
+			mcs_flags = tvb_get_guint8(tvb, offset + 1);
+			mcs_bw = tvb_get_guint8(tvb, offset + 2);
+			mcs = tvb_get_guint8(tvb, offset + 3);
+
+			if (tree) {
+				it = proto_tree_add_item(radiotap_tree, hf_radiotap_su_vht,
+						tvb, offset, 4, ENC_NA);
+				mcs_tree = proto_item_add_subtree(it, ett_radiotap_su_vht);
+				it = proto_tree_add_uint(mcs_tree, hf_radiotap_su_vht_known,
+						tvb, offset, 1, mcs_known);
+				mcs_known_tree = proto_item_add_subtree(it, ett_radiotap_su_vht_known);
+
+				proto_tree_add_item(mcs_known_tree, hf_radiotap_su_vht_have_stbc,
+						tvb, offset, 1, ENC_LITTLE_ENDIAN);
+				proto_tree_add_item(mcs_known_tree, hf_radiotap_su_vht_have_txop_ps,
+						tvb, offset, 1, ENC_LITTLE_ENDIAN);
+				proto_tree_add_item(mcs_known_tree, hf_radiotap_su_vht_have_gi,
+						tvb, offset, 1, ENC_LITTLE_ENDIAN);
+				proto_tree_add_item(mcs_known_tree, hf_radiotap_su_vht_have_coding,
+						tvb, offset, 1, ENC_LITTLE_ENDIAN);
+				proto_tree_add_item(mcs_known_tree, hf_radiotap_su_vht_have_bf,
+						tvb, offset, 1, ENC_LITTLE_ENDIAN);
+				proto_tree_add_item(mcs_known_tree, hf_radiotap_su_vht_have_bw,
+						tvb, offset, 1, ENC_LITTLE_ENDIAN);
+				proto_tree_add_item(mcs_known_tree, hf_radiotap_su_vht_have_nsts,
+						tvb, offset, 1, ENC_LITTLE_ENDIAN);
+				proto_tree_add_item(mcs_known_tree, hf_radiotap_su_vht_have_mcs_nss,
+						tvb, offset, 1, ENC_LITTLE_ENDIAN);
+			}
+
+			if (mcs_known & IEEE80211_RADIOTAP_SU_VHT_HAVE_STBC) {
+				if (mcs_tree)
+					proto_tree_add_boolean(mcs_tree, hf_radiotap_su_vht_stbc,
+							tvb, offset + 1, 1, mcs_flags);
+			}
+
+			if (mcs_known & IEEE80211_RADIOTAP_SU_VHT_HAVE_TXOP_PS) {
+				if (mcs_tree)
+					proto_tree_add_boolean(mcs_tree, hf_radiotap_su_vht_txop_ps,
+							tvb, offset + 1, 1, mcs_flags);
+			}
+
+			if (mcs_known & IEEE80211_RADIOTAP_SU_VHT_HAVE_GI) {
+				gi_length = (mcs_flags & IEEE80211_RADIOTAP_SU_VHT_SGI) ? 1 : 0;
+				if (mcs_tree) {
+					proto_tree_add_uint(mcs_tree, hf_radiotap_su_vht_gi,
+							tvb, offset + 1, 1, mcs_flags);
+					proto_tree_add_boolean(mcs_tree, hf_radiotap_su_vht_sgi_nsym_da,
+							tvb, offset + 1, 1, mcs_flags);
+				}
+			} else {
+				can_calculate_rate = FALSE;	/* no GI width */
+			}
+
+			if (mcs_known & IEEE80211_RADIOTAP_SU_VHT_HAVE_CODING) {
+				if (mcs_tree) {
+					proto_tree_add_uint(mcs_tree, hf_radiotap_su_vht_coding,
+							tvb, offset + 1, 1, mcs_flags);
+					proto_tree_add_boolean(mcs_tree, hf_radiotap_su_vht_ldpc_extra,
+							tvb, offset + 1, 1, mcs_flags);
+				}
+			}
+
+			if (mcs_known & IEEE80211_RADIOTAP_SU_VHT_HAVE_BF) {
+				if (mcs_tree)
+					proto_tree_add_boolean(mcs_tree, hf_radiotap_su_vht_bf,
+							tvb, offset + 1, 1, mcs_flags);
+			}
+
+			if (mcs_known & IEEE80211_RADIOTAP_SU_VHT_HAVE_BW) {
+				guint bw_index = (mcs_bw & IEEE80211_RADIOTAP_SU_VHT_BW) >> 4;
+				if (bw_index <= sizeof(ieee80211_vht_bw2rate_index)/sizeof(ieee80211_vht_bw2rate_index[0]))
+					bandwidth = ieee80211_vht_bw2rate_index[bw_index];
+				else
+					can_calculate_rate = FALSE; /* unknown bandwidth */
+
+				if (mcs_tree)
+					proto_tree_add_uint_format(mcs_tree, hf_radiotap_su_vht_bw,
+							tvb, offset + 2, 1, bw_index,
+							"Bandwidth: %s",
+							val_to_str(bw_index, vht_bandwidth, "Unknown (0x%02x)"));
+			} else {
+				can_calculate_rate = FALSE;	/* no bandwidth */
+			}
+
+			if (mcs_known & IEEE80211_RADIOTAP_SU_VHT_HAVE_NSTS) {
+				guint nsts = (mcs_bw & IEEE80211_RADIOTAP_SU_VHT_NSTS);
+				if (mcs_tree)
+					proto_tree_add_uint_format(mcs_tree, hf_radiotap_su_vht_nsts,
+							tvb, offset + 2, 1, nsts,
+							"Space-time streams: %u", nsts);
+			}
+
+			if (mcs_known & IEEE80211_RADIOTAP_SU_VHT_HAVE_MCS_NSS) {
+				mcs_index = (mcs & IEEE80211_RADIOTAP_SU_VHT_MCS);
+				nss = ((mcs & IEEE80211_RADIOTAP_SU_VHT_NSS) >> 4) + 1;
+				if (mcs_index > MAX_MCS_VHT_INDEX)
+					can_calculate_rate = FALSE;	/* Invalid index */
+
+				if (mcs_tree) {
+					proto_tree_add_uint_format(mcs_tree, hf_radiotap_su_vht_nss,
+							tvb, offset + 3, 1, nss,
+							"Spatial streams: %u", nss);
+					ti = proto_tree_add_uint_format(mcs_tree, hf_radiotap_su_vht_mcs,
+							tvb, offset + 3, 1, mcs_index,
+							"MCS: %u", mcs_index);
+
+					if (mcs_index > MAX_MCS_VHT_INDEX)
+						proto_item_append_text(ti, " (invalid)");
+					else
+						proto_item_append_text(ti, " (%s %s)",
+								ieee80211_vhtinfo[mcs_index].modulation,
+								ieee80211_vhtinfo[mcs_index].coding_rate);
+				}
+			} else {
+				can_calculate_rate = FALSE;	/* no MCS index */
+			}
+
+			if (can_calculate_rate) {
+				if (ieee80211_vhtinfo[mcs_index].rates[bandwidth][gi_length] != 0.0) {
+					float rate = ieee80211_vhtinfo[mcs_index].rates[bandwidth][gi_length] * nss;
+					col_add_fstr(pinfo->cinfo, COL_TX_RATE, "%.1f", rate);
+					if (radiotap_tree) {
+						rate_ti = proto_tree_add_float_format(radiotap_tree,
+								hf_radiotap_datarate,
+								tvb, offset, 5, rate,
+								"Data Rate: %.1f Mb/s", rate);
+						PROTO_ITEM_SET_GENERATED(rate_ti);
+					}
+				}
+			}
+
+			break;
 		}
+
+		case IEEE80211_RADIOTAP_GROUP_ID:
+			if (tree) {
+				proto_tree_add_uint(radiotap_tree,
+						hf_radiotap_gid, tvb,
+						offset, 1,
+						tvb_get_guint8(tvb, offset));
+			}
+			break;
+
+		case IEEE80211_RADIOTAP_PARTIAL_AID:
+			if (tree) {
+				proto_tree_add_uint(radiotap_tree,
+						hf_radiotap_aid, tvb,
+						offset, 2,
+						tvb_get_letohs(tvb, offset));
+			}
+			break;
+		}
 	}
 
 	if (err != -ENOENT && tree) {
Index: epan/dissectors/packet-ieee80211-radiotap-iter.c
===================================================================
--- epan/dissectors/packet-ieee80211-radiotap-iter.c	(revision 43220)
+++ epan/dissectors/packet-ieee80211-radiotap-iter.c	(working copy)
@@ -50,11 +50,16 @@
 	/* [IEEE80211_RADIOTAP_RTS_RETRIES] = 16 */		{ 1, 1 },
 	/* [IEEE80211_RADIOTAP_DATA_RETRIES] = 17 */		{ 1, 1 },
 	/* [IEEE80211_RADIOTAP_XCHANNEL] = 18 */		{ 0, 0 }, /* Unofficial, used by FreeBSD */
-	/* [IEEE80211_RADIOTAP_MCS] = 19 */			{ 1, 3 }
+	/* [IEEE80211_RADIOTAP_MCS] = 19 */			{ 1, 3 },
+	/* [IEEE80211_RADIOTAP_SU_VHT] = 20 */			{ 1, 4 },
+	/* [IEEE80211_RADIOTAP_GID] = 21 */			{ 1, 1 },
+	/* [IEEE80211_RADIOTAP_AID] = 22 */			{ 2, 2 },
 	/*
 	 * add more here as they are defined in
 	 * include/net/ieee80211_radiotap.h
 	 */
+	{ 0, 0 }, // TODO
+	{ 1, 5 }
 };
 
 static const struct ieee80211_radiotap_namespace radiotap_ns = {

Re: [RFC] VHT fields

[Johannes Berg]

On Tue, 2012-06-12 at 15:05 +0000, Alwin Beukers wrote:
> Hi everyone,
> 
> This is a proposal for adding support for 802.11ac. Four fields were added to the suggested-fields section:
> 
> http://www.radiotap.org/suggested-fields/SU_VHT
> http://www.radiotap.org/suggested-fields/MU_VHT
> http://www.radiotap.org/suggested-fields/GROUP_ID
> http://www.radiotap.org/suggested-fields/PARTIAL_AID
> 
> A Wireshark patch for parsing SU_VHT, GROUP_ID and PARTIAL_AID is attached.

What's the reason for splitting it up?

johannes

RE: [RFC] VHT fields

[Alwin Beukers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1185 bytes --]

:tî{m5ÛNµÙ«uçN~ÓM4\x02\"œ\x17®‘êìº-xxž½êò¢w“†+"±ªk¢š,jWè­§]Šx,ºšh®×è¯Í6×Vœ\x16‹«~'¥vÌ\x1e­æuçm¢Ø^²è zË^uøž•Û,yËb¢xm¶ŸÿÃ\f+iبµªh®\x0fìº\b\x1e²×~'¥vÏÒQQÓ†Ûiÿü0¶Š‹Z¦ŠàþË ë-y×âzWlüÅ\x15\x1d8m¶ŸÿÃ\f+iبµªh®\x0fìº\b\x1e²×~'¥vÏÆDå\x0f 8m¶ŸÿÃ\f+iبµªh®\x0fìº\b\x1e²×~'¥vÏÏ\x01\x14È\0°\b\f\x05¢­ë!j¹)j×!~Šéj»"ž\x04”TtÆDå\x0f 6§tð\x11L€\v\0€â±«miÈ^uhZ¶Ëaz·š²‰ß¢»)–+mŠx"¶êI¢\x16§ë\x13…êÞjÊ'~Šì¦X­¶)àŠÛ©ŠËhjú"uìm­ª/z¸^iÚÞ•«^vÚ\fPÂ\f;\b^×¬r¸›Šx\x15\x1d4”<ðÔ±8^±êZ­«b¢x¬m«\x1ev‰í…çb}÷«z{O,#áy§^­ú+™«lTtÒ `5ü\r¿\x05ú+IF§tÅ\x0f<5,ICÏ\rK\x0ež\¨ãRM#\x02I©Ý
‡bž\aâzWOj»bjP\b\x0e'^žØŸ‰ë+yÈ©‰éí\x1aº.¤€â±©pk+4i×kzË\x1evÚ\0?ùž²\x14“\x02Šúݧ]­ë,yÛhI0\fPóÃRÃRM#\x02I©Ý
‡bž\aâzWl~Šî¦Ú\x1f¢êî±êì=ªí‰©@ 8¬ž‹Z¦™bq¦åxj躒\x03ŠÍzØ	e~'¥vÇ(šj'¶†è¶\x14”jwLQªÞŠ{ay%\x15\x1d7âzWS…ã\x14Tt߉é]r‰íj)ìi×b¶*'jX§~Šæjبú+1CÏ\rK\x13…á‘9CÈ\r©Ý<\x04S \x02À 7âzWl…«Þ½ªòŠx/j[ž¢¶©¦Xœi¸¥ŠÜ’¡ú+ICÏ\rK2¢ì(ºWeŠG¥Ê\x16¯y%\x15\x1d6§tð\x11L€\v\0€ß‰é]±©Ý™¬›y¡‘9CÈ\røž•×è­%-…á‘9CÈ\røž•Ú'—*k¢øzÇb­ç-Š‰âú-…«\¢é]j[(mç^µêæŠw~º&<\x04S \x02À 6§wú+0\0¡y§^¬Z+1CÏ\rK2¢ì(ºWaj÷’QQÓ~Ší…ç(šj'~'¥vƬÁéejÃRM/Ì	/¡اú+¶\x17ŸŠ»-ºÇ«1EGMú+5$ÒüÀ’ü*\x1dŠx\x1f¢¶v+b¢v¥ºÇ«±©Ý\x19\x13”<€ÁÉÊ&n)âž\aâzWlÁç\x1až·¹Çœ¢je{\x18­É«m…ç±¥éìz‡ì¢g¢ÊÞjǝ¢÷«…æÂ\x16­j·²¢ê톋 †Û(ž\x18¬\x02[(#\x06¬Â‰Ýz¸§‚'ðzwžu©e¡ûazIèÂwåj\v"%\x15\x1d4áxÀ’~'¥u§íz¼!‰ÈRQQÓÁ«&¡×¥yÖ¥²ˆZ²Ø^±æî´‡hžÙ'£\vaz¶­Š‰Ú•æÞ†)ݶ\x17¦	©èæ¬²éžiÚâ½êájÇî–Vœqë,¶‹axòÂ>\x17šuêڝÛaºÇ\x1aø¥–)æ¢Ëh}øž•Û"žØ^IEGMøž•Ôájy,\x02\"ž:!jyÞ

Re: [RFC] VHT fields

[Arend van Spriel]

On 06/14/2012 01:20 PM, Johannes Berg wrote:
> On Thu, 2012-06-14 at 08:19 +0000, Alwin Beukers wrote:
>> Hi Johannes,
>>
>> I'm not seeing my reply to you (and cc to radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org) showing up on the list, am I doing something wrong?
> 
> Not sure, I don't see it either but never had issues with the list
> before
> 
> johannes
> 

I registered to radiotap list a couple of weeks ago, but never received
any email from it apart from the confirmation email (from
majordomo-qavaossjCcEdnm+yROfE0A@public.gmane.org). Any idea who to contact. First let me see if this
message is getting through ;-)

Gr. AvS

RE: [RFC] VHT fields

[Alwin Beukers]

Hi everyone,

Thanks for the feedback on the 802.11ac fields.

If there are no further suggestions, I would like to request the SU_VHT, MU_VHT and 
PARTIAL_AID fields to be moved to the defined-fields section and have their bit numbers
assigned. As the group ID was merged into SU_VHT, the GROUP_ID field can be dropped.

With the bit numbers assigned I can deliver the Wireshark patch for parsing these fields.

Thanks,
Alwin

> Hi everyone,
> 
> This is a proposal for adding support for 802.11ac. Four fields were added to the suggested-fields section:
> 
> http://www.radiotap.org/suggested-fields/SU_VHT
> http://www.radiotap.org/suggested-fields/MU_VHT
> http://www.radiotap.org/suggested-fields/GROUP_ID
> http://www.radiotap.org/suggested-fields/PARTIAL_AID
>
> A Wireshark patch for parsing SU_VHT, GROUP_ID and PARTIAL_AID is attached.
> 
> Any thoughts?
> 
> Thanks,
> Alwin

Re: [RFC] VHT fields

[Johannes Berg]

On Wed, 2012-07-04 at 17:18 +0000, Alwin Beukers wrote:
> Hi everyone,
> 
> Thanks for the feedback on the 802.11ac fields.
> 
> If there are no further suggestions, I would like to request the SU_VHT, MU_VHT and 
> PARTIAL_AID fields to be moved to the defined-fields section and have their bit numbers
> assigned. As the group ID was merged into SU_VHT, the GROUP_ID field can be dropped.
> 
> With the bit numbers assigned I can deliver the Wireshark patch for parsing these fields.

Can we also have a producer of the fields? I realise that may be hard to
do now without a driver? :-)

Please just use the next free bit numbers though, swapping those out
later will be easy, and that way we can see the code before adopting the
changes, this helps flush out implementation issues.

See also http://www.radiotap.org/Standardisation

johannes

RE: [RFC] VHT fields

[Alwin Beukers]

> On Wed, 2012-07-04 at 17:18 +0000, Alwin Beukers wrote:
> > Hi everyone,
> >
> > Thanks for the feedback on the 802.11ac fields.
> >
> > If there are no further suggestions, I would like to request the SU_VHT,
> > MU_VHT and
> > PARTIAL_AID fields to be moved to the defined-fields section and have
> > their bit numbers
> > assigned. As the group ID was merged into SU_VHT, the GROUP_ID field
> > can be dropped.
> >
> > With the bit numbers assigned I can deliver the Wireshark patch for parsing
> > these fields.
> 
> Can we also have a producer of the fields? I realise that may be hard to
> do now without a driver? :-)

Yes, that is somewhat of a challenge :-) 

I do have packet captures with the VHT field that could be made available,
although I realize it's not ideal...

Alwin
 
> Please just use the next free bit numbers though, swapping those out
> later will be easy, and that way we can see the code before adopting the
> changes, this helps flush out implementation issues.
> 
> See also http://www.radiotap.org/Standardisation
> 
> johannes
> 

Re: [RFC] VHT fields

[Johannes Berg]

On Tue, 2012-06-12 at 15:05 +0000, Alwin Beukers wrote:

> http://www.radiotap.org/suggested-fields/GROUP_ID

(I just deleted that)

> http://www.radiotap.org/suggested-fields/SU_VHT
> http://www.radiotap.org/suggested-fields/MU_VHT
> http://www.radiotap.org/suggested-fields/PARTIAL_AID

So one thing that strikes me is that this is not extensible at all any
more now inside the VHT fields, all the known flags are already used up.
I don't know if there's anything else in VHT that could possibly be of
relevance in the future though? Also, how stable is the VHT amendment? I
haven't followed it closely.

With the SU_VHT field being 5 bytes and the PARTIAL_AID requiring 2 byte
alignment, having them follow each other wastes a byte. I'm not worried
about that at all, but I wonder if splitting this into three fields is
really worth it? Given the many dependencies on SU/MU in all fields, it
almost seems that making them all one (slightly bigger) VHT field would
be easier to use?

If we wanted to go there, we could even use a union:

require 2 byte alignment of the VHT field, and then have
u8 known
u8 flags
u8 bw
u8 mcs
u8 gid
union {
	struct {
		u8 pad
		u16 partial_aid
	} su
	struct {
		u8 user1, user2, user3
	} mu
}



Also, looking at the fields in more detail, does it really make sense to
have the bits packed so tightly? NSTS and bandwidth for example, do they
really belong into the same field?

Also I think the coding/NSTS for the first and three other users should
be more regular? It seems then it wouldn't be possible to squeeze it all
into one byte per user, but ... does that really matter so much? This
isn't a huge amount of data.

Ok wait, I don't even see now how to distinguish between SU and MU
frames, except by the presence of the other fields? That's a bit
awkward, don't you think?

I think overall I'd probably just use a bit more space and make the
format more regular instead of packing MU/SU fields like MCS in with
common fields like NSS.


How about this:

u8 known         - maybe split this up further, or are there technical
                   reasons that e.g. if the coding is known the LDPC
                   extra symbol must also be known?
u8 flags         - add a MU/SU flag (and hope that all receivers know
                   this, or add a known flag?)
u8 bw            - only the bandwidth, not NSTS
u8 nss           - or maybe this could be packed with the bandwidth
u16 P_AID        - partial AID, valid only if SU
u8 NSTS[4]       - NSTS for up to 4 users
u8 mcs_coding[4] - MCS/coding/coding_known(?) for up to 4 users


Overall, this is just 6 bytes longer than your previous encoding (or
maybe 7 or 8 if flags/known now need to be extended), but I think it's
much more regular?

johannes

RE: [RFC] VHT fields

[Alwin Beukers]

> On Tue, 2012-06-12 at 15:05 +0000, Alwin Beukers wrote:
> 
> > http://www.radiotap.org/suggested-fields/GROUP_ID
> 
> (I just deleted that)
> 
> > http://www.radiotap.org/suggested-fields/SU_VHT
> > http://www.radiotap.org/suggested-fields/MU_VHT
> > http://www.radiotap.org/suggested-fields/PARTIAL_AID
> 
> So one thing that strikes me is that this is not extensible at all any
> more now inside the VHT fields, all the known flags are already used up.
> I don't know if there's anything else in VHT that could possibly be of
> relevance in the future though? Also, how stable is the VHT amendment? I
> haven't followed it closely.

I agree, it's a tight fit. I can't comment on the stability of the VHT amendment,
but it would be good to have some room left anyway. We might even want 
to add some info for 802.11ad at some point in the future, as it's also VHT.

> With the SU_VHT field being 5 bytes and the PARTIAL_AID requiring 2 byte
> alignment, having them follow each other wastes a byte. I'm not worried
> about that at all, but I wonder if splitting this into three fields is
> really worth it? Given the many dependencies on SU/MU in all fields, it
> almost seems that making them all one (slightly bigger) VHT field would
> be easier to use?
> 
> If we wanted to go there, we could even use a union:
> 
> require 2 byte alignment of the VHT field, and then have
> u8 known
> u8 flags
> u8 bw
> u8 mcs
> u8 gid
> union {
> 	struct {
> 		u8 pad
> 		u16 partial_aid
> 	} su
> 	struct {
> 		u8 user1, user2, user3
> 	} mu
> }
> 
> 
> 
> Also, looking at the fields in more detail, does it really make sense to
> have the bits packed so tightly? NSTS and bandwidth for example, do they
> really belong into the same field?
> 
> Also I think the coding/NSTS for the first and three other users should
> be more regular? It seems then it wouldn't be possible to squeeze it all
> into one byte per user, but ... does that really matter so much? This
> isn't a huge amount of data.
> 
> Ok wait, I don't even see now how to distinguish between SU and MU
> frames, except by the presence of the other fields? That's a bit
> awkward, don't you think?
> 
> I think overall I'd probably just use a bit more space and make the
> format more regular instead of packing MU/SU fields like MCS in with
> common fields like NSS.

These are all valid points. If using a bit more space is not an issue,
combining these three fields would simplify things significantly.
 
> How about this:
> 
> u8 known         - maybe split this up further, or are there technical
>                    reasons that e.g. if the coding is known the LDPC
>                    extra symbol must also be known?
> u8 flags         - add a MU/SU flag (and hope that all receivers know
>                    this, or add a known flag?)
> u8 bw            - only the bandwidth, not NSTS
> u8 nss           - or maybe this could be packed with the bandwidth
> u16 P_AID        - partial AID, valid only if SU
> u8 NSTS[4]       - NSTS for up to 4 users
> u8 mcs_coding[4] - MCS/coding/coding_known(?) for up to 4 users

I have put a new proposal at http://www.radiotap.org/suggested-fields/VHT
which is basically the format you are proposing but with a few tweaks.

As there is a fixed relation between NSS and NSTS, we can get by with only
having four per-user NSS values in the field and drop NSTS[4], which saves
one byte. The per-user MCS and NSS values are combined as they go
naturally together.

There is no explicit difference between MU and SU frames, all the info
is available in the VHT field. If required, one can still determine MU or SU 
from the group ID and hide information that is not applicable.
 
> Overall, this is just 6 bytes longer than your previous encoding (or
> maybe 7 or 8 if flags/known now need to be extended), but I think it's
> much more regular?

The combined field is now 12 bytes and has some room to spare. I think
it's a nice improvement over the previous proposal, would you agree?

Alwin
 
> johannes
> 

Re: [RFC] VHT fields

[Johannes Berg]

On Mon, 2012-07-23 at 14:47 +0000, Alwin Beukers wrote:

> > So one thing that strikes me is that this is not extensible at all any
> > more now inside the VHT fields, all the known flags are already used up.
> > I don't know if there's anything else in VHT that could possibly be of
> > relevance in the future though? Also, how stable is the VHT amendment? I
> > haven't followed it closely.
> 
> I agree, it's a tight fit. I can't comment on the stability of the VHT amendment,
> but it would be good to have some room left anyway. We might even want 
> to add some info for 802.11ad at some point in the future, as it's also VHT.

Yeah, though that could be done as a separate field too.

> I have put a new proposal at http://www.radiotap.org/suggested-fields/VHT
> which is basically the format you are proposing but with a few tweaks.
> 
> As there is a fixed relation between NSS and NSTS, we can get by with only
> having four per-user NSS values in the field and drop NSTS[4], which saves
> one byte. The per-user MCS and NSS values are combined as they go
> naturally together.

Makes sense.

> There is no explicit difference between MU and SU frames, all the info
> is available in the VHT field. If required, one can still determine MU or SU 
> from the group ID and hide information that is not applicable.

Right, that also makes sense.
 
> The combined field is now 12 bytes and has some room to spare. I think
> it's a nice improvement over the previous proposal, would you agree?

Yes, I like it.

One question on this:

"Note: for receive capture, the total bandwidth of the transmitter is
not generally known, so the bandwidth will only be recorded as 20, 40,
80, or 160, with the Channel field indicating the transmission center
frequency."

I'm not sure that's generally true, though it points out something that
we may need to define in more detail: we have (in Linux at least) always
had the Channel field indicate the control channel, not the transmission
center frequency.

johannes

RE: [RFC] VHT fields

[Alwin Beukers]

> One question on this:
> 
> "Note: for receive capture, the total bandwidth of the transmitter is
> not generally known, so the bandwidth will only be recorded as 20, 40,
> 80, or 160, with the Channel field indicating the transmission center
> frequency."
> 
> I'm not sure that's generally true, though it points out something that
> we may need to define in more detail: we have (in Linux at least) always
> had the Channel field indicate the control channel, not the transmission
> center frequency.

I think indicating the control channel wouldn't work very well in this case, 
especially for >40MHz bandwidths.

How do you feel about extending [X]Channel with a flag that indicates 
we're specifying transmission center frequency?

Alwin

Re: [RFC] VHT fields

[Johannes Berg]

On Fri, 2012-07-27 at 14:41 +0000, Alwin Beukers wrote:
> > One question on this:
> > 
> > "Note: for receive capture, the total bandwidth of the transmitter is
> > not generally known, so the bandwidth will only be recorded as 20, 40,
> > 80, or 160, with the Channel field indicating the transmission center
> > frequency."
> > 
> > I'm not sure that's generally true, though it points out something that
> > we may need to define in more detail: we have (in Linux at least) always
> > had the Channel field indicate the control channel, not the transmission
> > center frequency.
> 
> I think indicating the control channel wouldn't work very well in this case, 
> especially for >40MHz bandwidths.
> 
> How do you feel about extending [X]Channel with a flag that indicates 
> we're specifying transmission center frequency?

I don't think that'd be a good idea, it wouldn't be backward compatible.
We're just discussing for Linux how to specify the channel parameters
and we need to consider 80+80 as well. Maybe these discussions should
cross-pollinate.

I see two basic options:
 * continue what we do now, and specify the control channel & type
   around it (40+/40+,...)
   + this is how linux works now
   - many many channel types (4 for 80 MHz, 8 for 160 MHz)
   - doesn't handle 80+80
 * specify the center frequency, width & control channel offset
   + more aligned with the spec (?)
   - requires backward compat handling
   - doesn't handle 80+80

johannes

RE: [RFC] VHT fields

[Alwin Beukers]

> We're just discussing for Linux how to specify the channel parameters
> and we need to consider 80+80 as well. Maybe these discussions should
> cross-pollinate.

Yes. However, this issue isn't directly related to or blocking the VHT field 
proposal, is it? Can I go ahead and post an adaptation request for that?

> I see two basic options:
>  * continue what we do now, and specify the control channel & type
>    around it (40+/40+,...)
>    + this is how linux works now
>    - many many channel types (4 for 80 MHz, 8 for 160 MHz)
>    - doesn't handle 80+80

When it comes to radiotap, this might do as an interim solution for chips
that don't support 80+80 yet. The new channel types would fit in the
XChannel field.

>  * specify the center frequency, width & control channel offset
>    + more aligned with the spec (?)
>    - requires backward compat handling
>    - doesn't handle 80+80

I feel this is the best long-term solution. The 80+80 case could be handled 
By adding a secondary center frequency.

Regards,
Alwin

Re: [RFC] VHT fields

[Johannes Berg]

On Fri, 2012-08-24 at 07:46 +0000, Alwin Beukers wrote:
> > We're just discussing for Linux how to specify the channel parameters
> > and we need to consider 80+80 as well. Maybe these discussions should
> > cross-pollinate.
> 
> Yes. However, this issue isn't directly related to or blocking the VHT field 
> proposal, is it? Can I go ahead and post an adaptation request for that?

Right.

> > I see two basic options:
> >  * continue what we do now, and specify the control channel & type
> >    around it (40+/40+,...)
> >    + this is how linux works now
> >    - many many channel types (4 for 80 MHz, 8 for 160 MHz)
> >    - doesn't handle 80+80
> 
> When it comes to radiotap, this might do as an interim solution for chips
> that don't support 80+80 yet. The new channel types would fit in the
> XChannel field.

We could even do both unless the channel is 80+80 for older parsers like
existing wireshark since they'd then be able to parse at least
something.

> >  * specify the center frequency, width & control channel offset
> >    + more aligned with the spec (?)
> >    - requires backward compat handling
> >    - doesn't handle 80+80
> 
> I feel this is the best long-term solution. The 80+80 case could be handled 
> By adding a secondary center frequency.

Yeah, something like that. We need to work that out in Linux too, not
even sure there are chips that will support 80+80 though?

johannes