RadioTap Archive on
 help / color / Atom feed
From: <>
To: 'Richard Sharpe'
	'Johannes Berg'
	'Ray Wang' <rwang-+OaQ/>,
	'Tasheng Lin' <tlin-+OaQ/>
Subject: RE: Radiotap header for S1G captures and associated changes and other definitions
Date: Wed, 6 Mar 2019 00:07:22 -0800
Message-ID: <015d01d4d3f3$a8776e60$f9664b20$> (raw)
In-Reply-To: <>

Hi all,

Thank you for your valuable comments.
For the NDP related questions, yes. Hardware and its firmware can capture whole NDP
and get the NDP indication value.
And 802.11ah defines frequency spectrum from 750-950MHz; 700 for China, 800 for EU,
and 900 for others in general.

Best regards,
-----Original Message-----
From: Richard Sharpe <> 
Sent: Tuesday, March 5, 2019 7:29 AM
To: Johannes Berg <>
Cc:; Ray Wang <rwang-+OaQ/>; Tasheng Lin <tlin-+OaQ/>; Aaron J. Lee <>
Subject: Re: Radiotap header for S1G captures and associated changes and other definitions

On Tue, Mar 5, 2019 at 3:58 AM Johannes Berg <> wrote:
> Hi Richard,
> > 1. Channel field:
> >
> > 3 new values for Mask: 0x0002 for 700 MHz, 0x0004 for 800 MHz and
> > 0x0008 for 900 MHz spectrum channels respectively.
> How much space do we have there btw? We're going to get 6-7 GHz 
> channels soon ... perhaps we should just give up on this field and put 
> the actual frequency & bandwidth etc. somewhere? If we don't already ...

Yes, although that is possibly a more general question. S1G will always be below 1GHz, I believe.

However, in general, I think we need a separate field that specifies the BW as a string, and probably even one per antenna.

> > NDP type:
> > 0x00: NDP Control frame
> > 0x01: NDP Management frame
> > 0x02-0xFF: Reserved
> >
> > NDP data:
> >
> > These are as defined in 802.11ah-2016 Section 9.9 except that the 
> > top two bits of data[4] are:
> >
> > 0x00: 1MHz
> > 0x01: 2MHz
> > 0x02-0x03: Reserved
> Is it really worth packing this into the end? You could have lots of 
> space in e.g. the data2 or NDP type fields (I guess, you reserved lots 
> of values there).
> > The S1G NPD format is essentially from section 9.9 of 802.11ah-2016 
> > with some additional syntactic sugar:
> >
> > It is a 40-bit field.
> Not sure I understand this sentence. What's the syntactic sugar in 
> being a 40-bit field?
> > In between, a 1MHz NDP CMAC frame contains 26 used bits and 13 
> > unused bits. The used bits are defined in section 9.9 of 
> > 802.11ah-2016. A 2MHz NDP CMAC frame contains 37 used bits and one 
> > unused bit. Again, the used bits are defined in 802.11ah-2016.
> Right.
> However, these also come with a 1-bit "NDP indication", 4-bit CRC and 
> 6- bit tail; perhaps it should be at least *possible* to capture those 
> too, even if nobody might do that right now? Then you'd need a total 
> of 48 bits for this, afaict.
> I guess a more fundamental question would be whether we should treat 
> these as metadata or payload. Obviously here we're treating them as 
> metadata and saying (by way of the 0-length field) that there's no 
> payload. But perhaps these *should* in fact be the payload instead, 
> and not use the 0-length field at all?
> I really don't know the answer to that. It seems fairly obvious that 
> this one is more convenient, and the format of those frames is very 
> specific to the S1G things, and they couldn't really be used outside 
> of S1G unlike the 802.11 header & frame. So I think I'm happy with 
> this, just wanted to note this design decision explicitly.

I will clean up the others over the next few days, but yes, I went back and forward between having the NDP info be a separate payload versus placing it in the S1G header. Placing it in the S1G header is more convenient but will mean moving code around over what we currently have, however, that is relatively easy.

It is a matter of convenience.

A question for Aaron and the WFA folks, however, is: Is there utility capturing the NDP indication, or is that already captured in IS NDP above? Similarly, is it useful to capture the CRC and tail etc. Does the hardware give you access to these extra fields?

Richard Sharpe

  parent reply index

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-05  3:18 Richard Sharpe
     [not found] ` <>
2019-03-05 11:58   ` Johannes Berg
     [not found]     ` <>
2019-03-05 15:29       ` Richard Sharpe
     [not found]         ` <>
2019-03-06  8:07           ` yodazhong-Re5JQEeQqe8AvxtiuMwx3w [this message]
2019-04-09  8:58   ` Johannes Berg
  -- strict thread matches above, loose matches on Subject: below --
2019-03-02  1:59 Richard Sharpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='015d01d4d3f3$a8776e60$f9664b20$' \ \ \ \ \
    --cc=rwang-+OaQ/ \
    --cc=tlin-+OaQ/ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

RadioTap Archive on

Archives are clonable:
	git clone --mirror radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ \
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone