RE: [RFC] VHT fields

On Fri, 2012-06-15 at 08:15 +0000, Alwin Beukers wrote:

> The reason for splitting it up is to avoid extra overhead related to MU-MIMO 
> when describing VHT SU PPDUs. The separation is based on the different PLCP 
> header formats (VHT-SIG-A1/A2/B) for SU and MU PPDUs:
> 
> SU PPDUs:
> - Only one NSTS, MCS and Coding field.
> - Partial AID identifies recipient
> - Group ID is always 0 (addressed to AP/mesh STA) or 63 (addressed to STA)
> 
> MU PPDUs:
> - NSTS, MCS and Coding fields for up to four users
> - Partial AID is not applicable
> - Group ID is 1..62
> 
> All fields common to both SU and MU are in the SU_VHT field. The MU_VHT field 
> contains additional information for MU PPDUs. The GROUP_ID and PARTIAL_AID
> fields have varying value or applicability.

Ok.

> So for SU PPDUs you would likely have SU_VHT and PARTIAL_AID fields, and maybe
> a GROUP_ID field (for SU the GROUP_ID field only provides direction info that
> could also be determined from PARTIAL_AID and/or MAC header).

Ok, I'm not too familiar with 11ac yet.

> For MU PPDUs you would have SU_VHT (for the common fields as well as 
> NSTS/MCS/Coding for the first user), MU_VHT (for NSTS/MCS/Coding for
> additional users), and GROUP_ID.
> 
> By combining fields we can reduce complexity at the expense of some increased
> overhead, what are your thoughts on his? 

I don't really care much either way -- was mostly curious why you were
splitting it up so much.

I have a feeling though that the group ID would be useful to always
have, even if it's just 0/63 in the SU case, to make it easier on
filtering?

> Also, I was wondering if we need all
> of the 'known' flags in SU_VHT. The MCS field (after which SU_VHT was modeled)
> also has these, but I don’t know the rationale behind them. Can one assume a
> driver has full access to the PLCP header and thus can fill in most of fields
> in the SU_VHT field?

I know that's usually the case for your devices, but it isn't typically
the case for all the random devices out there ... so I think we should
have the known flags to not run into a situation later where a device
has to lie.

johannes