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

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



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

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,

 

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

 

_______________________________________________________________________________

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 - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-EDITORS 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: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________