Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-EDITORS] MCS terminology update

--- This message came from the IEEE 802.11 Editors' Reflector ---

Hello Adrian,


I apologize for not expressing myself very well. Scheme 2 has the following for 11ad “(optional) Rename all DMG MCS to DMG_MCS”. Given that the term MCS is fine for 11ad, my suggestion was that we do not need to implement this optional step under scheme 2.






From: Stephens, Adrian P
Sent: Monday, August 06, 2012 10:59 PM
To: Cordeiro, Carlos; Robert Stacey
Cc: Brian Hart (brianh); STDS-802-11-EDITORS@xxxxxxxxxxxxxxxxx
Subject: RE: MCS terminology update


Hello Carlos,


I didn’t quite understand “Scheme 2 seems to make more sense indeed” combined with “The use of the term MCS should be fine for 11ad.


Scheme 2 includes replacing MCS with DMG_MCS in the .11ad material.



I’m wondering if a new scheme 3 is more appropriate.  

This would:

·         create a “protected namespace” for VHT by renaming MCS to VHT_MCS,   with similar changes for VHT variables

·         refer to <VHT_MCS,N_SS> and <VHT_MCS,N_SS,CHANNEL_BANDWIDTH> tuples where appropriate

·         add appropriate definitions (not like the mixed up one below!)

·         not make any changes to .11n and .11ad uses,  in the expectation that REVmc would tackle it,  once the trail has been broken by .11ac on the terminology front.


This is attractive to me because:

·         We solve only VHT’s problems

·         Less work

·         Less likely to attract negative comment on “scope” from those not party to the detailed argument

Additional comments please?    Who prefers this change?


Best Regards,




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


From: Cordeiro, Carlos
Sent: Tuesday, August 07, 2012 12:06 AM
To: Robert Stacey; Stephens, Adrian P
Cc: Brian Hart (brianh); STDS-802-11-EDITORS@xxxxxxxxxxxxxxxxx
Subject: RE: MCS terminology update


Scheme 2 seems to make more sense indeed.


Also, while Robert is making a valid observation regarding the use of “modulation” in subclause 21.1 of 11ad, I must say that the draft is not so rigorous and probably some work is needed to unify it use. That said, this should be pretty straightforward to do (search for “SC PHY”, “Control PHY” and “OFDM PHY” and replace “PHY” by “modulation”). The use of the term MCS should be fine for 11ad.






From: Robert Stacey [mailto:rstacey@xxxxxxxxx]
Sent: Monday, August 06, 2012 10:03 AM
To: Stephens, Adrian P
Cc: Brian Hart (brianh); STDS-802-11-EDITORS@xxxxxxxxxxxxxxxxx; Cordeiro, Carlos
Subject: Re: MCS terminology update


Hi Adrian,


I too prefer scheme 2.


Regarding MCS as it relates to 11ad. I believe they made a partial move away from describing the DMG PHY as composed of 3 PHYs (early on I had some comments on this) and now talk about "control" modulation, "single carrier" modulation, etc. At least in the introductory paragraph to clause 21. So M in MCS in its broadest sense covers control, single carrier and OFDM modulation and there is no need for PMCS.





On Aug 6, 2012, at 2:36 AM, Stephens, Adrian P wrote:


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)

  1. Rename all existing MCS to HT_MCS
  2. Rename all VHT type of MCS to VHT_MCS
  3. (optional) Rename all DMG MCS to DMG_MCS
  4. 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,




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



 Robert Stacey





IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.

SELF SERVICE OPTION: Point your Browser to - and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.

Further information can be found at: _______________________________________________________________________________