HE (11ax) extensions

HE (11ax) extensions

[Johannes Berg]

Hi,

We're looking to add HE/11ax extensions to radiotap.

Has anyone else already identified the data that would be necessary?

So far I have - assuming 'presence bits' for each,

for HE_SU:
 * beam change (1 bit)
 * UL/DL (1 bit)
 * MCS (4 bits)
 * DCM (1 bit)
 * BSS color (6 bits)
 * spatial reuse (TBD)
 * bandwidth
 * GI+LTF size (2 bits)
 * Nsts
 * TXOP duration (7 bits)
 * Coding (BCC/LDPC)
 * LDPC extra symbol flag
 * STBC flag
 * TX BF flag
 * pre-FEC padding factor
 * PE disambiguity
 * doppler mode

for HE_MU:
 * UL/DL
 * MCS
 * DCM
 * BSS color
 * spatial reuse
 * TXOP Duration
 * bandwidth
 * # of HE SIGB symbols
 * SIG-B compression
 * GI+LTF size
 * # of HE-LTF symbols
 * LDPC extra symbol flag
 * STBC
 * pre-FEC padding factor
 * PE disambiguity
 * doppler mode
 * RU allocation
 * center 26 tone RU
 * per-user: STA-ID, Nsts, TX BF, MCS, DCM, Coding

for HE_TRIG:
(similar to HE_SU but a little restricted)


Obviously a number of these fields are in all three formats, and I
haven't really done a full size analysis, but perhaps we should split
the extra MU fields into a separate bit so that they don't have to have
space allocated to them when not used, for SU/TRIG formats?

johannes

Re: HE (11ax) extensions

[Simon Barber]

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

For HT and VHT one of the things that is missing is the total length of aggregates (including padding) - it’s in the L-SIG header, would be nice to have it exposed (since most chipsets pass up everything that’s in the header). I assume the same will be true for ax. Also some standardized way to put aggregates back together. My latest wireshark extension uses same TSF as that clue. See https://code.wireshark.org/review/#/c/20043/ <https://code.wireshark.org/review/#/c/20043/>

Simon

> On Feb 13, 2017, at 5:23 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> 
> Hi,
> 
> We're looking to add HE/11ax extensions to radiotap.
> 
> Has anyone else already identified the data that would be necessary?
> 
> So far I have - assuming 'presence bits' for each,
> 
> for HE_SU:
> * beam change (1 bit)
> * UL/DL (1 bit)
> * MCS (4 bits)
> * DCM (1 bit)
> * BSS color (6 bits)
> * spatial reuse (TBD)
> * bandwidth
> * GI+LTF size (2 bits)
> * Nsts
> * TXOP duration (7 bits)
> * Coding (BCC/LDPC)
> * LDPC extra symbol flag
> * STBC flag
> * TX BF flag
> * pre-FEC padding factor
> * PE disambiguity
> * doppler mode
> 
> for HE_MU:
> * UL/DL
> * MCS
> * DCM
> * BSS color
> * spatial reuse
> * TXOP Duration
> * bandwidth
> * # of HE SIGB symbols
> * SIG-B compression
> * GI+LTF size
> * # of HE-LTF symbols
> * LDPC extra symbol flag
> * STBC
> * pre-FEC padding factor
> * PE disambiguity
> * doppler mode
> * RU allocation
> * center 26 tone RU
> * per-user: STA-ID, Nsts, TX BF, MCS, DCM, Coding
> 
> for HE_TRIG:
> (similar to HE_SU but a little restricted)
> 
> 
> Obviously a number of these fields are in all three formats, and I
> haven't really done a full size analysis, but perhaps we should split
> the extra MU fields into a separate bit so that they don't have to have
> space allocated to them when not used, for SU/TRIG formats?
> 
> johannes


[-- Attachment #2: Type: text/html, Size: 3073 bytes --]

Re: HE (11ax) extensions

[Johannes Berg]

On Mon, 2017-02-13 at 11:33 -0800, Simon Barber wrote:
> For HT and VHT one of the things that is missing is the total length
> of aggregates (including padding) - it’s in the L-SIG header, would
> be nice to have it exposed (since most chipsets pass up everything
> that’s in the header).

I don't know about "most", but I know ours doesn't :-)

> Also some standardized way to put aggregates back together. My latest
> wireshark extension uses same TSF as that clue.
> See https://code.wireshark.org/review/#/c/20043/

We already have that, in the A-MPDU status field there's a reference
number that's supposed to be constant within the same A-MPDU and change
between consecutive A-MPDUs.

johannes

Re: HE (11ax) extensions

[Simon Barber]

It’s not correctly implemented on captures from Macs - it increments for every MPDU. TSF is reliable on all platforms that I’ve seen, although has different reference points for different platforms.

One things that is very odd is the different parameters for MU - 4 sets, but I’ve only ever seen 1 MPDU reported. How is this supposed to be used?

Simon

> On Feb 13, 2017, at 11:39 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> 
> On Mon, 2017-02-13 at 11:33 -0800, Simon Barber wrote:
>> For HT and VHT one of the things that is missing is the total length
>> of aggregates (including padding) - it’s in the L-SIG header, would
>> be nice to have it exposed (since most chipsets pass up everything
>> that’s in the header).
> 
> I don't know about "most", but I know ours doesn't :-)
> 
>> Also some standardized way to put aggregates back together. My latest
>> wireshark extension uses same TSF as that clue.
>> See https://code.wireshark.org/review/#/c/20043/
> 
> We already have that, in the A-MPDU status field there's a reference
> number that's supposed to be constant within the same A-MPDU and change
> between consecutive A-MPDUs.
> 
> johannes

Re: HE (11ax) extensions

[Johannes Berg]

On Mon, 2017-02-13 at 11:42 -0800, Simon Barber wrote:
> It’s not correctly implemented on captures from Macs - it increments
> for every MPDU. TSF is reliable on all platforms that I’ve seen,
> although has different reference points for different platforms.
> 
> One things that is very odd is the different parameters for MU - 4
> sets, but I’ve only ever seen 1 MPDU reported. How is this supposed
> to be used?

I don't think it *can* be used by a real sniffer, unless it is somehow
able to decode for multiple users at once?

johannes

Re: HE (11ax) extensions

[Simon Barber]

And even then, where would the multiple MPDUs go, and how would they be delimited? If this option is unused, and unusable, and it causes big issues with UI, then could it be deprecated? (say only the first set of parameters are valid, all others are unused?)

Simon

> On Feb 13, 2017, at 11:49 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> 
> On Mon, 2017-02-13 at 11:42 -0800, Simon Barber wrote:
>> It’s not correctly implemented on captures from Macs - it increments
>> for every MPDU. TSF is reliable on all platforms that I’ve seen,
>> although has different reference points for different platforms.
>> 
>> One things that is very odd is the different parameters for MU - 4
>> sets, but I’ve only ever seen 1 MPDU reported. How is this supposed
>> to be used?
> 
> I don't think it *can* be used by a real sniffer, unless it is somehow
> able to decode for multiple users at once?
> 
> johannes

Re: HE (11ax) extensions

[Johannes Berg]

On Mon, 2017-02-13 at 12:08 -0800, Simon Barber wrote:
> And even then, where would the multiple MPDUs go, and how would they
> be delimited? 

That's a good point. Perhaps it was intended to convey some sort of
half-decoding? I frankly don't remember any discussions about this.

> If this option is unused, and unusable, and it causes big issues with
> UI, then could it be deprecated? (say only the first set of
> parameters are valid, all others are unused?)

Does it cause problems in any UI? wireshark just displays all the
fields, so it shouldn't really cause any problems.

Anyway, this has certainly never been generated on Linux, and probably
not elsewhere, so I have no objection to deprecating it and marking
those fields reserved or so.

johannes

Re: HE (11ax) extensions

[Johannes Berg]

On Mon, 2017-02-13 at 11:42 -0800, Simon Barber wrote:
> It’s not correctly implemented on captures from Macs - it increments
> for every MPDU. TSF is reliable on all platforms that I’ve seen,
> although has different reference points for different platforms.

On this point, btw, you should probably just tell somebody to fix it :)

We can add all the standard ways we want to, but if people don't use
them correctly there's not much we can do about it. I don't want to add
yet another standard way to do this, just to have the next guy use it
wrong ...

johannes

Re: HE (11ax) extensions

[Guy Harris]

On Feb 13, 2017, at 11:42 AM, Simon Barber <simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> wrote:

> It’s not correctly implemented on captures from Macs - it increments for every MPDU.

bugreport.apple.com is your friend (well, it'll be all of our friends again once they fix the damn redirect loop).  You'll need to get an Apple developer account in order to file bugs.  (Note: the more duplicates a bug has, the more attention is paid to it.)

The spec says

	The reference number is generated by the capture device and is the same across each subframe of an A-MPDU. Since the capture device might be capable of capturing multiple channels or data from multiple (concurrent) captures could be merged, the reference number is not guaranteed to be unique across different channels. As a result, applications should use the channel information together with the reference number to identify the subframes belonging to the same A-MPDU.

So are you saying that it increments for each *subframe* in macOS?

Re: HE (11ax) extensions

[Johannes Berg]

On Mon, 2017-02-13 at 11:33 -0800, Simon Barber wrote:
> For HT and VHT one of the things that is missing is the total length
> of aggregates (including padding) - it’s in the L-SIG header

It is, btw, very tempting to define fields for the various headers like
L-SIG, SIG-A, SIG-B etc, but most chipsets won't be able to report
everything there so we'd have to support masks, and we generally don't
support anything with variable length.

johannes

Re: HE (11ax) extensions

[Johannes Berg]

On Mon, 2017-02-13 at 11:33 -0800, Simon Barber wrote:
> For HT and VHT one of the things that is missing is the total length
> of aggregates (including padding) - it’s in the L-SIG header, would
> be nice to have it exposed (since most chipsets pass up everything
> that’s in the header).

Come to think of this - that really should have been part of the A-MPDU 
field, but I don't think it makes sense to put it into an HE extension
either, so it'd probably be better as a separate field.

johannes

Re: HE (11ax) extensions

[Johannes Berg]

On Mon, 2017-02-13 at 14:23 +0100, Johannes Berg wrote:
> Hi,
> 
> We're looking to add HE/11ax extensions to radiotap.

I looked more, and decided that it didn't really make a lot of sense to
parse it all and put it back together ... so instead, how about we just
put SIG-A1/A2/B common/B multiuser in?

Something like

http://www.radiotap.org/fields/HE

but I'm not really sure
* if sig_B_user[1] should be in HE or in HE multiuser
* if 3 bits are really needed for the Center 26-tone RU field, I'm not
sure how it could be non-present

Does this make sense?

johannes

Re: HE (11ax) extensions

[Johannes Berg]

> Something like
> 
> http://www.radiotap.org/fields/HE
> 
> but I'm not really sure
> * if sig_B_user[1] should be in HE or in HE multiuser
> * if 3 bits are really needed for the Center 26-tone RU field, I'm
> not sure how it could be non-present

It really can be non-present, obviously SIG-B common field is already
variable length :)

Anyway, that proposal missed a number of things and didn't really make
any sense, here's a new one:

http://www.radiotap.org/fields/HE
http://www.radiotap.org/fields/HE-MU-common
http://www.radiotap.org/fields/HE-MU-user

One thing I like less about this is that the bitrate of the MPDU will
be recorded in the "HE" field for SU/trigger-based PPDUs, but in the
"HE-MU-user" field for MU PPDUs. But since all the data is present, I
guess that's actually fine.

johannes

Re: HE (11ax) extensions

[Johannes Berg]

On Wed, 2017-02-22 at 12:54 +0100, Johannes Berg wrote:
> > 
> Anyway, that proposal missed a number of things and didn't really
> make any sense, here's a new one:
> 
> http://www.radiotap.org/fields/HE
> http://www.radiotap.org/fields/HE-MU-common
> http://www.radiotap.org/fields/HE-MU-user

FWIW, I've not pursued this further for now since the spec is still a
moving target. I'm told HE-SIG-B is fairly stable, but HE-SIG-A is
still a heavily contended topic (at least some parts of it)

johannes

Re: HE (11ax) extensions

[Johannes Berg]

On Tue, 2017-02-28 at 08:28 +0100, Johannes Berg wrote:
> On Wed, 2017-02-22 at 12:54 +0100, Johannes Berg wrote:
> > > 
> > 
> > Anyway, that proposal missed a number of things and didn't really
> > make any sense, here's a new one:
> > 
> > http://www.radiotap.org/fields/HE
> > http://www.radiotap.org/fields/HE-MU-common
> > http://www.radiotap.org/fields/HE-MU-user
> 
> FWIW, I've not pursued this further for now since the spec is still a
> moving target. I'm told HE-SIG-B is fairly stable, but HE-SIG-A is
> still a heavily contended topic (at least some parts of it)

In the meantime, I've come to the conclusion that it's a stupid idea to
encode the data like in HE-SIG-A, for multiple reasons:

1) the encoding heavily depends on the PPDU type (SU, ER SU, MU, TB),
and there's practically nothing common between them - this means
decoding has lots of special cases

2) the encoding is really really tight on bits, doing tricks like
DCM=STBC=1 to indicate a 5th possibility for the 2-bit LTF+GI field,
this also makes it awkward to decode again in tools like wireshark

3) TB PPDUs don't even contain the necessary rate data, it's given by
the trigger frame, so one would have to correlate that during encoding.
For pure sniffer mode, that may be necessary, but for some "monitor
while operating" modes, the real rate etc. would be available

(and there are probably more reasons)

I'm going on sabbatical soon, but I'll revisit this in September or
later to come up with a better proposal.

johannes

Re: HE (11ax) extensions

[Johannes Berg]

Hi all,

I've updated my HE proposal:

http://www.radiotap.org/fields/HE
http://www.radiotap.org/fields/HE-MU
http://www.radiotap.org/fields/HE-MU-user

This now basically just requires the HE field even for MU
transmissions, with the HE-MU field giving some more detail of those;
the HE-MU-user is just for completeness so one can capture the SIG-B
for multiple users even if the frame isn't captured.

I'll still wait for the spec to settle down more until formally
proposing this, but feedback is very welcome.

johannes

Re: HE (11ax) extensions

[Johannes Berg]

On Fri, 2017-09-08 at 10:35 +0200, Johannes Berg wrote:
> Hi all,
> 
> I've updated my HE proposal:
> 
> http://www.radiotap.org/fields/HE
> http://www.radiotap.org/fields/HE-MU
> http://www.radiotap.org/fields/HE-MU-user

And again, for D2.0

johannes

Re: HE (11ax) extensions

[Arend Van Spriel]

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

Op 25 okt. 2017 13:54 schreef "Johannes Berg" <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>:
>
> On Fri, 2017-09-08 at 10:35 +0200, Johannes Berg wrote:
> > Hi all,
> >
> > I've updated my HE proposal:
> >
> > http://www.radiotap.org/fields/HE
> > http://www.radiotap.org/fields/HE-MU
> > http://www.radiotap.org/fields/HE-MU-user

The last link doesn't work (for me?).

Regards,
Arend

> And again, for D2.0
>
> johannes

[-- Attachment #2: Type: text/html, Size: 850 bytes --]

Re: HE (11ax) extensions

[Johannes Berg]

On Wed, 2017-10-25 at 14:17 +0200, Arend Van Spriel wrote:
> Op 25 okt. 2017 13:54 schreef "Johannes Berg" <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>:
> >
> > On Fri, 2017-09-08 at 10:35 +0200, Johannes Berg wrote:
> > > Hi all,
> > >
> > > I've updated my HE proposal:
> > >
> > > http://www.radiotap.org/fields/HE
> > > http://www.radiotap.org/fields/HE-MU
> > > http://www.radiotap.org/fields/HE-MU-user
> The last link doesn't work (for me?).

Indeed, it should be

http://www.radiotap.org/fields/HE-MU-other-user

I also notice that github hasn't updated the HE page with the data6
part of the field yet.

johannes