From: Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
To: "radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org"
<radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org>
Cc: Simon Barber <simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>,
Richard Sharpe
<realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Subject: Re: Correct radiotap header for 802.11ad
Date: Thu, 10 Sep 2015 11:25:02 -0700 [thread overview]
Message-ID: <1135A126-6A5A-4C84-A52D-13C0387609CC@alum.mit.edu> (raw)
In-Reply-To: <126B842D-05EA-4510-BC9B-DB1A4AABEC12-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
On Aug 26, 2015, at 6:17 PM, Guy Harris <guy-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org> wrote:
> On Aug 26, 2015, at 3:59 PM, Simon Barber <simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> wrote:
>
>> The HT and VHT fields are missing various bits of phy layer info, and are defined missing enough bits for other fields. I've always thought It would be much simpler if these fields could convey the whole SIGNAL bits from the PLCP header, along with a mask in case it's not all available. The drivers I've seen have the whole PLCP SIGNAL field available.
>
> So that's the L-SIG bits from 20.3.9.3.5 "L-SIG definition"
I.e., L_DATARATE and L_LENGTH?
> and either the HT-SIG bits from 20.3.9.4.3 "HT-SIG definition"
I.e.:
the MCS index
CBW 20/40
HT Length
Smoothing
Not Sounding
Aggregation (PPDU contains an A-MPDU)
STBC
FEC coding
Short GI
N(ESS)
CRC of the bits
Tail Bits
The ones that aren't in the MCS field or the A-MPDU field are:
HT Length - is that just the length of the data following the radiotap header?
Smoothing
Not Sounding
CRC - is this of any interest?
Tail Bits - always 0, so these are presumably not of interest
Can:
whether "20" means "20", "20L", or "20U";
HT mixed vs. greenfield;
both of which are available from the MCS field, be determined from the PLCP header?
Or is what "20" means not fully determinable for received packets, so that "20L", "20U", and "40" are indistinguishable, similar to what the Radiotap spec for the VHT field says?
20.3.9.5.4 "HT-greenfield format HT-SIG" says "The content and format of the HT-SIG of an HT-greenfield format frame is identical to the HT-SIG in an HT-mixed format frame, as described in 20.3.9.4.3.", so if that information can be determined for received frames, it sounds as if greenfield vs. mixed *can't* be determined from the HT-SIG bits.
> or the VHT-SIG-A bits from 11ac's 22.3.8.3.3 "VHT-SIG-A definition" and the VHT-SIG-B bits from 11ac's 22.3.8.3.6 "VHT-SIG-B definition"?
I.e.:
BW
STBC
Group ID
NSTS/Partial AID
TXOPS_PS_NOT_ALLOWED
Short GI
Short GI NSYM Disambiguation
SU/MU[0] Coding
LDPC Extra OFDM Symbol
SU VHT-MCS/MU[1-3] Coding
Beamformed
CRC
Tail Bits
The ones that aren't in the MCS field are:
CRC - is this of any interest?
Tail Bits - always 0, so these are presumably not of interest
The spec for the VHT field says that NSTS "can be calculated from the NSS for that user and the STBC flag" and that, for received frames, the only bandwidth information you get is 20/40/80/160, which is presumably what you can get from BW.
For *transmitted* frames, I guess you have more control over how it's transmitted, which is presumably why there's a VHT field rather than just a PLCP header field.
I.e., as radiotap is used for transmission, it needs to include at least some of the parameters to the PHY service's transmission operation, which may not be available in the PLCP header.
> And for 11ad, would it be the bits from 21.5.3.1.1 "General"?
I.e.:
Scrambler Initialization - probably not of interest
MCS
Length - is this just the length of the data following the radiotap header?
Additional PPDU
Packet Type
Training Length
Aggregation (PPDU contains an A-MPDU)
Beam Tracking Request
Tone Pairing Type
DTP Indicator
Last RSSI
Turnaround
HCS (a CRC)
So do we need all of those?
And is there anything more that would be needed for *injected* 11ad frames? If so, that's an argument for a "DMG" field containing the interesting information from the PLCP header combined with information necessary for injected frames?
next prev parent reply other threads:[~2015-09-10 18:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-22 19:41 Correct radiotap header for 802.11ad Richard Sharpe
[not found] ` <CACyXjPzq-ePB1ux6wi_Rv3onPKXomcJcm15XJwA51u0E4W2txw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-22 20:59 ` Guy Harris
[not found] ` <38F46E1D-1C4A-48DC-A906-9522006E8474-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2015-08-22 22:06 ` Richard Sharpe
[not found] ` <CACyXjPx81fh_jeQSUjE-_w8NQ_Jr-ajmnVWSopfzcLPOWoGmGg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-22 22:24 ` Guy Harris
2015-08-22 23:34 ` Guy Harris
[not found] ` <1606812C-649C-4C06-ABE0-AE2F4474BCD0-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2015-08-24 7:40 ` Johannes Berg
[not found] ` <1440402013.3735.1.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2015-08-24 16:21 ` Richard Sharpe
[not found] ` <CACyXjPwSZPV+U_=zQpDBpeBnhMntzEFhyJnBOw3-N8qPfyHc1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-24 16:28 ` Johannes Berg
2015-08-26 22:59 ` Simon Barber
[not found] ` <55DE44EB.6080603-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>
2015-08-27 1:17 ` Guy Harris
[not found] ` <126B842D-05EA-4510-BC9B-DB1A4AABEC12-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2015-09-10 18:25 ` Guy Harris [this message]
[not found] ` <1135A126-6A5A-4C84-A52D-13C0387609CC-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
2015-09-17 16:37 ` Johannes Berg
2019-12-10 23:51 ` Guy Harris
2019-12-11 8:32 ` Johannes Berg
2019-12-11 9:39 ` Krishna Chaitanya
2019-12-11 12:57 ` Johannes Berg
2019-12-11 13:20 ` Krishna Chaitanya
2019-12-20 21:56 ` Guy Harris
2015-09-17 16:32 ` Johannes Berg
2015-08-26 22:56 ` Simon Barber
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1135A126-6A5A-4C84-A52D-13C0387609CC@alum.mit.edu \
--to=guy-frubxkncsvf2fbvcvol8/a@public.gmane.org \
--cc=johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org \
--cc=radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org \
--cc=realrichardsharpe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).