Hello Brian and Robert,
I have an action in .11ac (shared with Robert) to update the MCS terminology to remove
confusion it causes in 802.11ac. There’s a lot of work here, so I want to get feedback from
interested parties. Everybody – please comment.
I proposed at the last meeting (11-12/0847) two alternatives:
The outline of the proposed change is as follows: (scheme 1)
- Include instructions to rename MCS to MCSS in the baseline (excluding .11ad uses), also catching things like field, parameter (e.g., BasicMCSSet) and MIB variable names.
- Reflect these changes into the baseline quoted material
- Provide definitions and abbreviations for MCS and MCSBS
- Review and adjust new material in .11ac to refer to the correct thing.
An alternative: (scheme 2)
- Rename all existing MCS to HT_MCS
- Rename all VHT type of MCS to VHT_MCS
- (optional) Rename all DMG MCS to DMG_MCS
- Not introduce a special term for MCSBS, because its uses are limited
We took a straw poll: (yes/no)
- I like scheme 1 – 7/0
- I like scheme 2 – 2/1
- I want to do as little as possible and can live with the contradictions involved – 3/1
The more I think about it, the more I prefer scheme 2, even though it got the lowest support, and Brian opposed it.
I’m hoping that I can garner Brian’s support and am looking to find a means of doing it. If we can’t get that support,
or there is opposition from other editors, I suggest we go for a very conservative solution in .11ac and bump the
problem up to REVmc (where Brian and I also probably get the job to fix it).
Where scheme 1 breaks down is with .11ad. The .11ad MCS includes selection of PHY type, and depending on
that, may or may not select a modulation order. A possible abbreviation is P[M]CS. This is weird and wacky
and will create more angst than it relieves.
Also use of “MCS” is so ingrained, it would be nice to retain it as part of the new terms.
Really MCS is a shorthand for a mapping from a number to a potentially partial set of parameters that controls the tx
waveform. MCS is carried directly in the PHY signal field and is used either alone (.11n, .11ad) or with other
signal fields (.11ac) to demodulate the data field of the PPDU. The naming of MCS is poor because more than
just modulation and coding rate is implied in both .11n and .11ad, but we already know that.
In a sense the argument as to exact abbreviations is secondary to the work of turning an ambiguous
identifier into unambiguous ones. I think we can press on with the latter work, and continue to have
the argument about exactly what to call them continuously into the distant future.
Regarding editorial changes. I checked with Michelle Turner (IEEE-SA boss editor, from our perspective),
I asked her if:
“Change all isolated occurrences of “MCS” to “MCSS”
Change all BasicMCSSet to BasicMCSSSet”
was an OK editing instruction to put in an amendment. She says it’s OK.
Our work is more difficult than that because we need to separate .11n and .11ac uses of MCS.
The number of .11ad uses of MCS is about 180, half of which are in the PHY. So, I suppose it
is possible to review cite the 80 or so instances outside the PHY individually. I can’t imagine we’ll
get it right first time, and 802.11REVmc will have work to do fixing it up.
So, I’m anticipating editing instructions of the form:
“
Change (list of 80 occurrences) of MCS to “VHT_MCS”
Change all occurrences of “MCS” in clause 21 to “VHT_MCS”
Change all isolated occurrences of “MCS” to “HT_MCS”
Change all BasicMCSSet to BasicMCSSSet”
Plus definitions and abbreviations for the terms
e.g.: in the section 3.2 (802.11-specific)
Very high throughput modulation and coding scheme (VHT_MCS):
A specification of the directional multi-gigabit (DMG) physical layer (PHY) parameters that selects the modulation type and forward error correction (FEC) coding rate, and for some modulation types, selects the modulation order.
The current definition for MCS
(modulation and coding scheme (MCS): A specification of the high-throughput (HT) physical layer (PHY)
parameters that consists of modulation order (e.g., BPSK, QPSK, 16-QAM, 64-QAM) and forward error
correction (FEC) coding rate (e.g., 1/2, 2/3, 3/4, 5/6).)
would be made HT-specific.
And a new definition introduced:
modulation and coding scheme (MCS): A number that determines one or more parameters of the PHY waveform, such as modulation rate and coding. The MCS is carried in a PHY signalling field and is used either alone, or together with other PHY signalling fields to receive the data field of the PPDU.
We still have to resolve the issue of consistency in whether the CandidateMCS set for VHT contains just MCS values, or
<MCS,#SS> tuples. I think this should be a straightforward task.
BTW, FWIW, YARA, I think 9.7 is so horrible that I would propose to rewrite it in REVmc.
My sketch outline is to define a number of contexts:
· Group – all possible receivers
· Group – outside context of BSS
· Group – my BSS
· Individual – outside context of BSS
· Individual – BSS member, unknown capabilities
· Individual – control response
· Individual – BSS member, known capabilities
(no guarantee this is correct, I’m just thinking aloud)
and then map frame types and other contextual information into one of these types,
e.g. CTS in response to RTS -> control response
RTS and protection required -> all possible receivers
BA (not aggregated) -> control response
BA (aggregated) -> individual – BSS member, known capabilities
I’m hoping we can halve the size of the current text and remove a number of anomalies created
by .11n and promulgated by .11ac.
Best Regards,
Adrian P STEPHENS
Tel: +44 1954 204 609 (office)
Tel: +44 7407 366878 (mobile)
Skype: adrian_stephens
----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
** YARA – yet another random acronym