| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- 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)
An alternative: (scheme 2)
We took a straw poll: (yes/no)
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”
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”
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) ---------------------------------------------- ** 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 _______________________________________________________________________________ |