Proposal for an S1G header for radiotap

Proposal for an S1G header for radiotap

[Richard Sharpe]

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

Hi folks,

Attached is a git format-patch patch that contains a proposal for an S1G header.

This proposal was created by Aaron Lee and underwent a couple of
rounds of modifications among the WFA folks.

All I have done here is to transcribe it to the format required by the
documentation web site. Hopefully I have not changed any intent.

Below is some feedback from Johannes about the proposal so he does not
have to retype it along with some comments from me.

We should try to get this finalized as quickly as possible as quite a
bit of work is going on in this area.

Those who are interested in this topic should join the mailing list
because people may forget to reply-all!

> Channel field: This is a really old field, almost certainly somebody
> somewhere uses those bits they suggest already ... but I guess if
> wireshark doesn't parse them then that doesn't really matter, so I guess
> that'd be OK. I'd probably suggest using higher bits anyway, which are
> less likely to already be used.
>
> HALOW field: Mostly looks fine.
>
> I think the NDP indication (0x10 in data1) should probably be moved out
> into the 0-length psdu field we already have, so we don't need to handle
> special cases for it this in wireshark and other dissectors. The known
> bit for that (in known field) makes no sense anyway because clearly you
> have to know whether a packet was NDP or not. Unless I'm completely
> misunderstanding the meaning of this field.

The issue may be that an NDP actually carries non-MAC data. 25 bits in
the case of 1MHz NDPs and 37 bits in the case of 2MHz NDPs. If we can
shoehorn them into the 0-length-PSDU maybe we should.

> The "NSS" field is only 2 bits and can only capture values 0-3, not 1-4,
> so they probably mean the value inside is NSS-1, or NSS==field+1. Fine,
> but needs clarification.

Yeah. I unilaterally clarified that, so Aaron will have to look at it
and correct me if I am wrong.

> Aggregation bit isn't clear - don't they do things similarly to normal
> HT/VHT/HE A-MPDU and could re-use that field for aggregation? That can
> (optionally) also hold whether it was first/last and a cookie which
> frames belong together in an aggregation, so that's useful to have. IMHO
> should be moved to A-MPDU unless somebody can really explain why they
> need something special.
>
> And with that it easily fits into 2 u16 fields rather than 3 (actually
> it fits now even) so might be something to consider, though I don't
> really think space is much of a concern.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)

[-- Attachment #2: 0001-Add-an-S1G-field.patch --]
[-- Type: application/octet-stream, Size: 2890 bytes --]

From 68e60d051b459a1144fc805c7b71492815cbfa59 Mon Sep 17 00:00:00 2001
From: Richard Sharpe <rsharpe@localhost.localdomain>
Date: Thu, 31 Jan 2019 15:47:50 -0800
Subject: [PATCH] Add an S1G field.

The author is Aaron Lee. Transcribed by Richard Sharpe.
Signed-off-by: Richard Sharpe <realrichardsharpe@gmail.com>
---
 fields/Channel.md   |  3 +++
 fields/S1G.md       | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
 fields/suggested.md |  1 +
 3 files changed, 53 insertions(+)
 create mode 100644 fields/S1G.md

diff --git a/fields/Channel.md b/fields/Channel.md
index 784c5c4..5747862 100644
--- a/fields/Channel.md
+++ b/fields/Channel.md
@@ -21,6 +21,9 @@ Currently, the following flags are defined:
 
 | **Mask** | **Meaning** |
 | 0x0010 | Turbo Channel |
+| 0x0002 | S1G 700MHz spectrum channel |
+| 0x0004 | S1G 800MHz spectrum channel |
+| 0x0008 | S1G 900MHz spectrum channel |
 | 0x0020 | CCK channel |
 | 0x0040 | OFDM channel |
 | 0x0080 | 2 GHz spectrum channel |
diff --git a/fields/S1G.md b/fields/S1G.md
new file mode 100644
index 0000000..a719de8
--- /dev/null
+++ b/fields/S1G.md
@@ -0,0 +1,49 @@
+---
+title: S1G
+categories: [suggested]
+---
+Bit Number
+: 16
+
+Structure
+: u16 known, u16 data1, u16 data2
+
+Required Alignment
+: 2
+
+Unit(s)
+: none
+
+The presence of this field indicates the frame was capture using an S1G phy.
+
+This field contains data to allow correct handling by programs like
+Wireshark etc.
+
+## known
+
+| **`0x0001`** | S1G PPDU Format known |
+| **`0x0002`** | Response indication known |
+| **`0x0004`** | NDP known |
+| **`0x0008`** | Guard interval known |
+| **`0x0010`** | NSS known | 
+| **`0x0020`** | Bandwidth known |
+| **`0x0040`** | MCS known |
+| **`0x0080`** | Color known |
+| **`0x0100`** | Aggregation known |
+| **`0xFE00`** | Reserved |
+
+## data1
+
+| **`0x0003`** | S1G PPDU Format: 0=S1G_1M, 1=S1G_SHORT, 2=S1G_LONG |
+| **`0x000C`** | Response indication: 0=NO_RESPONSE, 1=NDP_RESPONSE, 2=NORMAL_RESPONSE, 3=LONG_RESPPNSE |
+| **`0x0010`** | NDP: 0=Not NDP, 1=NDP |
+| **`0x0020`** | Guard interval | 0=Long GI, 1=Short GI |
+| **`0x00C0`** | Number spatial streams: 0=1 Spatial stream, 1=2, .. 3=4 Spatial streams |
+| **`0x0F00`** | Bandwidth: 0=1MHz, 1=2MHz, 2=4MHz, 3=8MHz, 4=16MHz |
+| **`0xF000`** | MCS (MCS rate index, 0-10, 11-15 reserved) |
+
+## data2
+
+| **`0x000F`** | Color: 0-7 |
+| **`0x0010`** | Aggregation: 0=No aggregation, 1=aggregation |
+| **`0xFFE0`** | Reserved |
diff --git a/fields/suggested.md b/fields/suggested.md
index 32577d9..ec598bb 100644
--- a/fields/suggested.md
+++ b/fields/suggested.md
@@ -18,3 +18,4 @@ This table lists the fields some OSes assigned by bit number:
 | 16 | [RTS retries](/fields/RTS retries), [RSSI](/fields/RSSI) |
 | 17 | [data retries](/fields/data retries) |
 | 18 | [XChannel](/fields/XChannel) |
+| 28 | [S1G](/fields/S1G) |
-- 
1.8.3.1

Re: Proposal for an S1G header for radiotap

[Johannes Berg]

Hi Richard,

> Attached is a git format-patch patch that contains a proposal for an S1G header.
> 
> This proposal was created by Aaron Lee and underwent a couple of
> rounds of modifications among the WFA folks.
> 
> All I have done here is to transcribe it to the format required by the
> documentation web site. Hopefully I have not changed any intent.

Thanks for doing this! :)

> Below is some feedback from Johannes about the proposal so he does not
> have to retype it along with some comments from me.

:-)

Some *additional* feedback below - please do check my previous note
about aggregation handling, this is very unclear to me.


> > I think the NDP indication (0x10 in data1) should probably be moved out
> > into the 0-length psdu field we already have, so we don't need to handle
> > special cases for it this in wireshark and other dissectors. The known
> > bit for that (in known field) makes no sense anyway because clearly you
> > have to know whether a packet was NDP or not. Unless I'm completely
> > misunderstanding the meaning of this field.
> 
> The issue may be that an NDP actually carries non-MAC data. 25 bits in
> the case of 1MHz NDPs and 37 bits in the case of 2MHz NDPs. If we can
> shoehorn them into the 0-length-PSDU maybe we should.

Oh. Maybe not then. How would these bits even be represented in
wireshark though?

Clearly, the 25/37 bits are not part of the radiotap header proposal
right now, but if they're non-MAC data they probably should be?

I'd almost think we should be doing something like:

 * add a new "S1G NDP" sub-item to "0-length PSDU" field, even if now
   strictly it's no longer "0-length" but more like "no-MSDU"... which
   really is the effect in wireshark anyway
 * remove NDP from the S1G field
 * add a separate radiotap field for S1G NDP data, containing a length
   bit and 37 data bits?

>  | **Mask** | **Meaning** |
>  | 0x0010 | Turbo Channel |
> +| 0x0002 | S1G 700MHz spectrum channel |
> +| 0x0004 | S1G 800MHz spectrum channel |
> +| 0x0008 | S1G 900MHz spectrum channel |
>  | 0x0020 | CCK channel |
>  | 0x0040 | OFDM channel |
>  | 0x0080 | 2 GHz spectrum channel |

That seems misplaced, should be after "Turbo Channel" I guess.

But also like I said above, some research on prior use of these bits
would be useful.
Looking at FreeBSD:
https://github.com/freebsd/freebsd/blob/master/sys/net80211/ieee80211_radiotap.h

they seem to have a few *higher* bits, but not lower ones. Maybe we can
risk it.

johannes

Re: Proposal for an S1G header for radiotap

[Richard Sharpe]

On Fri, Feb 1, 2019 at 3:33 AM Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>
> Hi Richard,
>
> > Attached is a git format-patch patch that contains a proposal for an S1G header.
> >
> > This proposal was created by Aaron Lee and underwent a couple of
> > rounds of modifications among the WFA folks.
> >
> > All I have done here is to transcribe it to the format required by the
> > documentation web site. Hopefully I have not changed any intent.
>
> Thanks for doing this! :)
>
> > Below is some feedback from Johannes about the proposal so he does not
> > have to retype it along with some comments from me.
>
> :-)
>
> Some *additional* feedback below - please do check my previous note
> about aggregation handling, this is very unclear to me.

I will look at the other comments separately, but I think Aggegration
relates to A-MPDU if I am reading section 9.7 of 802.11ah-2016
correctly.

In which case, we already have an A-MPDU header but we might need some
changes. Perhaps the WFA folks or Aaron can comment on this/

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)

RE: Proposal for an S1G header for radiotap

[yodazhong-Re5JQEeQqe8AvxtiuMwx3w]

Hi Johannes and Richard,

Thank you for your work and great comments.

For the S-MPDU issue, S-MPDU is same as VHT single MPDU in 802.11ac.
If there's pre-defined field for VHT single MPDU, we could use that.

For the S1G NDP issue, I found that there's PHDR_802_11_SOUNDING_PSDU 
for "0-length PSDU" field. That sounding PSDU means NDP sounding frame, I guess.
So I think we could add S1G NDP frames under "0-length PSDU" field.

--
Best,
Aaron J. Lee

-----Original Message-----
From: Richard Sharpe <realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 
Sent: Friday, February 1, 2019 10:35 AM
To: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Cc: radiotap-sUITvd46vNxg9hUCZPvPmw@public.gmane.org; Aaron J. Lee <yodazhong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>; Ray Wang <rwang-+OaQ/Okkt+3YtjvyW6yDsg@public.gmane.org>; tlin-+OaQ/Okkt+3YtjvyW6yDsg@public.gmane.org
Subject: Re: Proposal for an S1G header for radiotap

On Fri, Feb 1, 2019 at 3:33 AM Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>
> Hi Richard,
>
> > Attached is a git format-patch patch that contains a proposal for an S1G header.
> >
> > This proposal was created by Aaron Lee and underwent a couple of 
> > rounds of modifications among the WFA folks.
> >
> > All I have done here is to transcribe it to the format required by 
> > the documentation web site. Hopefully I have not changed any intent.
>
> Thanks for doing this! :)
>
> > Below is some feedback from Johannes about the proposal so he does 
> > not have to retype it along with some comments from me.
>
> :-)
>
> Some *additional* feedback below - please do check my previous note 
> about aggregation handling, this is very unclear to me.

I will look at the other comments separately, but I think Aggegration relates to A-MPDU if I am reading section 9.7 of 802.11ah-2016 correctly.

In which case, we already have an A-MPDU header but we might need some changes. Perhaps the WFA folks or Aaron can comment on this/

--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)

RE: Proposal for an S1G header for radiotap

[Ray Wang]

Hi Johannes and Richard,

As to Aggregation related to A-MPDU, from 802.11ah -2016 spec it can be seen the field is defined in SIG-2 of SIG field of S1G_SHORT preamble, SIG-A2 of SIG-A field of S1G_LONG preamble, and SIG-2 of SIG field of S1G_1M preamble.

If looking at 802.11-2016 and Draft P802.11ax_D3.3 specs, the same field is defined only in HT-SIG, but not in VHT-SIG-A and VHT-SIG-B, and not in HE-SIG-A.

From the spec perspective regarding the Aggregation field, 802.11ah is different from 802.11n/ac/ax.

As you pointed out, Richard, if the existing field can be reused it might need some changes. If defining a new one, the existing one probably also needs to be handled. 

What would you suggest is the best way to tackle it?


Thanks,
Ray


-----Original Message-----
From: yodazhong@gmail.com [mailto:yodazhong@gmail.com] 
Sent: Friday, February 01, 2019 2:04 PM
To: 'Richard Sharpe' <realrichardsharpe@gmail.com>; 'Johannes Berg' <johannes@sipsolutions.net>
Cc: radiotap@radiotap.org; Ray Wang <rwang@wi-fi.org>; Tasheng Lin <tlin@wi-fi.org>
Subject: RE: Proposal for an S1G header for radiotap

Hi Johannes and Richard,

Thank you for your work and great comments.

For the S-MPDU issue, S-MPDU is same as VHT single MPDU in 802.11ac.
If there's pre-defined field for VHT single MPDU, we could use that.

For the S1G NDP issue, I found that there's PHDR_802_11_SOUNDING_PSDU for "0-length PSDU" field. That sounding PSDU means NDP sounding frame, I guess.
So I think we could add S1G NDP frames under "0-length PSDU" field.

--
Best,
Aaron J. Lee

-----Original Message-----
From: Richard Sharpe <realrichardsharpe@gmail.com>
Sent: Friday, February 1, 2019 10:35 AM
To: Johannes Berg <johannes@sipsolutions.net>
Cc: radiotap@radiotap.org; Aaron J. Lee <yodazhong@gmail.com>; Ray Wang <rwang@wi-fi.org>; tlin@wi-fi.org
Subject: Re: Proposal for an S1G header for radiotap

On Fri, Feb 1, 2019 at 3:33 AM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Hi Richard,
>
> > Attached is a git format-patch patch that contains a proposal for an S1G header.
> >
> > This proposal was created by Aaron Lee and underwent a couple of 
> > rounds of modifications among the WFA folks.
> >
> > All I have done here is to transcribe it to the format required by 
> > the documentation web site. Hopefully I have not changed any intent.
>
> Thanks for doing this! :)
>
> > Below is some feedback from Johannes about the proposal so he does 
> > not have to retype it along with some comments from me.
>
> :-)
>
> Some *additional* feedback below - please do check my previous note 
> about aggregation handling, this is very unclear to me.

I will look at the other comments separately, but I think Aggegration relates to A-MPDU if I am reading section 9.7 of 802.11ah-2016 correctly.

In which case, we already have an A-MPDU header but we might need some changes. Perhaps the WFA folks or Aaron can comment on this/

--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)

Re: Proposal for an S1G header for radiotap

[Johannes Berg]

Hi,

> For the S-MPDU issue, S-MPDU is same as VHT single MPDU in 802.11ac.
> If there's pre-defined field for VHT single MPDU, we could use that.

Since it's kind of packed into an A-MPDU header, we have indeed added
the A-MPDU field for this to capture the EOF bit in VHT single MPDU.

> For the S1G NDP issue, I found that there's PHDR_802_11_SOUNDING_PSDU 
> for "0-length PSDU" field. That sounding PSDU means NDP sounding frame, I guess.
> So I think we could add S1G NDP frames under "0-length PSDU" field.

Sounds good to me. It would mean wireshark shows no PSDU.

johannes

Re: Proposal for an S1G header for radiotap

[Johannes Berg]

Hi,

> As to Aggregation related to A-MPDU, from 802.11ah -2016 spec it can
> be seen the field is defined in SIG-2 of SIG field of S1G_SHORT
> preamble, SIG-A2 of SIG-A field of S1G_LONG preamble, and SIG-2 of SIG
> field of S1G_1M preamble.
> 
> If looking at 802.11-2016 and Draft P802.11ax_D3.3 specs, the same
> field is defined only in HT-SIG, but not in VHT-SIG-A and VHT-SIG-B,
> and not in HE-SIG-A.
> 
> From the spec perspective regarding the Aggregation field, 802.11ah is
> different from 802.11n/ac/ax.

Well, OK. But we still use the A-MPDU field for HT/VHT/HE, even if those
are also different. We've gone for a more semantic view I guess, and you
can easily distinguish which kind of frame you had by the presence of
HT/VHT/HE fields and/or channel information.

> As you pointed out, Richard, if the existing field can be reused it
> might need some changes. If defining a new one, the existing one
> probably also needs to be handled. 
> 
> What would you suggest is the best way to tackle it?

Can you say what you actually want to capture for aggregation data? So
far you only had an "aggregation" bit, which could be easily indicated
by the presence of the A-MPDU field. But the A-MPDU reference number in
radiotap, which is something that obviously doesn't even exist in the
802.11 spec, would make sense so you know which PSDUs belonged into the
same aggregate.

johannes

RE: Proposal for an S1G header for radiotap

[Ray Wang]

Hi Johannes,

Thank you so much for your insight!

I agree with you that it is only an "aggregation" bit, The currently defined A-MPDU status field should be sufficient for that purpose as long as the SIG and SIG-A fields can be decoded in the corresponding S1G preambles, and A-MPDU status is populated or not populated accordingly.


Thanks,
Ray


-----Original Message-----
From: Johannes Berg [mailto:johannes@sipsolutions.net] 
Sent: Tuesday, February 05, 2019 1:55 AM
To: Ray Wang <rwang@wi-fi.org>; yodazhong@gmail.com; 'Richard Sharpe' <realrichardsharpe@gmail.com>
Cc: radiotap@radiotap.org; Tasheng Lin <tlin@wi-fi.org>
Subject: Re: Proposal for an S1G header for radiotap

Hi,

> As to Aggregation related to A-MPDU, from 802.11ah -2016 spec it can 
> be seen the field is defined in SIG-2 of SIG field of S1G_SHORT 
> preamble, SIG-A2 of SIG-A field of S1G_LONG preamble, and SIG-2 of SIG 
> field of S1G_1M preamble.
> 
> If looking at 802.11-2016 and Draft P802.11ax_D3.3 specs, the same 
> field is defined only in HT-SIG, but not in VHT-SIG-A and VHT-SIG-B, 
> and not in HE-SIG-A.
> 
> From the spec perspective regarding the Aggregation field, 802.11ah is 
> different from 802.11n/ac/ax.

Well, OK. But we still use the A-MPDU field for HT/VHT/HE, even if those are also different. We've gone for a more semantic view I guess, and you can easily distinguish which kind of frame you had by the presence of HT/VHT/HE fields and/or channel information.

> As you pointed out, Richard, if the existing field can be reused it 
> might need some changes. If defining a new one, the existing one 
> probably also needs to be handled.
> 
> What would you suggest is the best way to tackle it?

Can you say what you actually want to capture for aggregation data? So far you only had an "aggregation" bit, which could be easily indicated by the presence of the A-MPDU field. But the A-MPDU reference number in radiotap, which is something that obviously doesn't even exist in the
802.11 spec, would make sense so you know which PSDUs belonged into the same aggregate.

johannes