radiotap.netbsd.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: radiotap-S783fYmB3Ccdnm+yROfE0A@public.gmane.org
Subject: Re: [RFC] VHT MU-MIMO correction
Date: Fri, 04 Dec 2015 11:48:40 +0100	[thread overview]
Message-ID: <1449226120.2574.0.camel@sipsolutions.net> (raw)
In-Reply-To: <1445418906.4558.7.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>

I guess this has passed a three-week minimum review time - bump, I'll
make those changes unless I hear objections within ~a week?

johannes

On Wed, 2015-10-21 at 11:15 +0200, Johannes Berg wrote:
> Hi,
> 
> As we're looking into MU-MIMO again, we found some issue with the way
> the VHT radiotap field is defined. The issue is the following: the VHT
> SIG-A field defines the NSTS (NSS) for each user, and it would be good
> to have that shown. However, radiotap ties the validity of the MCS to
> the existence of the NSS, which is incorrect.
> 
> Therefore, I suggest to make the following edit:
> 
> Change this language:
> 
>     If the NSS field for a user is zero, the user is not present and
>     the MCS and coding (in the coding field) associated with that user
>     are not valid. For SU PPDUs, only the first user will have a
>     nonzero NSS field.
> 
> To read:
> 
>     If the NSS field for a user is zero, the user is not present and
>     the MCS and coding (in the coding field) associated with that user
>     are not valid. If the NSS field for a user is non-zero, but the MCS
>     is not known (for example due to receiving only data for a single
>     user), the MCS shall be set to 15.
>     For SU PPDUs, only the first user will have a nonzero NSS field.
> 
> 
> The coding should be known for all, since it's also part of VHT-SIG-A,
> so I'm not suggesting to add validity flags for that. Does anyone think
> that is necessary?
> 
> A wireshark patch won't really be necessary since it will already
> display the MCS as "15 (invalid)" in this case, which seems reasonable
> though it could be changed to just "not known" instead.
> 
> johannes
> 

  parent reply	other threads:[~2015-12-04 10:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-21  9:15 [RFC] VHT MU-MIMO correction Johannes Berg
     [not found] ` <1445418906.4558.7.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2015-12-04 10:48   ` Johannes Berg [this message]
     [not found]     ` <1449226120.2574.0.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2016-01-20 12:44       ` Johannes Berg

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=1449226120.2574.0.camel@sipsolutions.net \
    --to=johannes-cdvu00un1vgdhxzaddlk8q@public.gmane.org \
    --cc=radiotap-S783fYmB3Ccdnm+yROfE0A@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).