doc.: IEEE /401r1 Submission May 2012 Mark RISON (CSR)Slide 1 Highest Supported Data Rate Date: Authors:

doc.: IEEE /401r1 Submission May 2012 Mark RISON (CSR)Slide 2 Abstract This document justifies the proposal to make the Highest Supported Data Rate in the VHT Supported MCS Set indicate the highest supported data rate, and addresses some points which have been made regarding this

doc.: IEEE /401r1 Submission May 2012 Mark RISON (CSR)Slide 3 History of HSDR HSDR was introduced in 11n –Earliest mention appears to be 06/1904 –A pure limit on the max rx data rate supported by a station, not qualified by GI length (or anything else) – see later slide HSDR was transferred to 11ac –Early drafts and D1.0 of 11ac also do not mention any link to GI length Vinko wrote on to the TGac mailing list that: –“I believe that […] the Highest Supported Data Rate [is] the absolute maximum an implementation's data pipes can cope with” –In fact it was us (Mark) pressing for clarification (see 11/1518) that resulted in HSDR being qualified with long GI in D2.0 But this was done just as a strawman to prime the discussion

doc.: IEEE /401r1 Submission May 2012 Mark RISON (CSR)Slide 4 Justification of proposal Allows for implementation flexibility –A HSDR can be specified regardless of what limits data rate in any particular implementation and context Including limits due to host interface speed, memory bandwidth/availability, etc. In some cases a given implementation (ASIC or wider system) may have different HSDR depending on its context, e.g. type of host interface, etc. Keeps the HSDR concept clean –The HSDR should not be implicitly linked to any individual station capability (in particular N ES ) N ES should be specified explicitly, just like any other capability (256 QAM, LDPC, short GI,...)

doc.: IEEE /401r1 Submission May 2012 Mark RISON (CSR)Slide 5 Point #1: N ES restrictions Allert wrote on to the TGac mailing list that: –I have a counter example from Table of D1.4 (80 MHz, number of spatial streams (N_SS) = 4), where it can be seen that MCS4, 5 and 6 require 2 encoders/decoders (N_ES = 2), and MCS7, 8 and 9 require N_ES = 3. For MCS6, the long GI data rate is 1053 Mbps, the short GI data rate is 1170 Mbps. For MCS7, the long GI data rate is 1170 Mbps, the short GI data rate is 1300 Mbps. Now, if this STA supports short GI and only 2 decoders for whatever reason, then it could potentially receive 1170 Mbps (MCS6, short GI). But with your proposal it cannot set the Rx Highest Supported Data Rate to 1170 Mbps, because it can only indicate support for MCS0-7, MCS0-8, or MCS0-9, because if it would set the Rx Highest Supported Data Rate to 1170 Mbps it could potentially get MCS7 with long GI from the sender, which it cannot receive. So by your proposal this STA is forced to set the Rx Highest Supported Data Rate to 1053 Mbps and take a throughput hit of 10% at its highest rate.

doc.: IEEE /401r1 Submission May 2012 Mark RISON (CSR)Slide 6 Point #1: N ES restrictions (continued) Observations –This is assuming an implied use of HSDR to specify maximum supported N ES –There is quirkiness in 11ac not present in 11n, whereby N ES does not grow monotonically with data rate –Therefore if a receiver says its HSDR is N, there can be modulations with data rate <= N with different N ES –But for long GI only, N ES does grow monotonically with data rate, hence Allert’s workaround is viable Counter –This is inelegant and inefficient Stems from N ES not being monotonic Hijacks HSDR to be linked to N ES Forces stations that cannot support data rate for top MCS with short GI to also not support long GI for that MCS ‘Funny’ logic: if a station indicates HSDR is 540 Mbps, say, this means that the highest data rate supported by that station is in fact 600 Mbps –Proposal to explicitly specify N ES capability (see 12/238) resolves Allert’s concern directly

doc.: IEEE /401r1 Submission May 2012 Mark RISON (CSR)Slide 7 Point #2: Link adaptation Concern raised by Robert in teleconf: –If a receiver supports only long GI for the top rate, this complicates link adaptation Counter –The MCS feedbackee is already required to cope with being recommended something the MCS feedbacker cannot receive (apart from N_STS; see minutes of teleconf minutes in 12/488) –If the transmitter does not want to have to take HSDR into account, however, it can simply always use long GI

doc.: IEEE /401r1 Submission May 2012 Mark RISON (CSR)Slide 8 Point #3: Consistency with 11n Concern raised by Adrian: –Making the HSDR be the HSDR would be a change from the 11n semantics Counter –11ac/D2.0 changed the 11n semantics –The 11n semantics are that the HSDR is the HSDR, not qualified by the GI length: Supported MCS Set field The Rx Highest Supported Data Rate subfield of the Supported MCS Set field defines the highest data rate that the STA is able to receive, in units of 1 Mb/s, where 1 represents 1 Mb/s, and incrementing by 1 Mb/s steps to the value 1023, which represents 1023 Mb/s. If the maximum data rate expressed in Mb/s is not an integer, then the value is rounded up to the next integer. The value 0 indicates that this subfield does not specify the highest data rate that the STA is able to receive; see Control response frame MCS computation If a bit in the Rx MCS Bitmask subfield is equal to 1 and the integer part of the data rate (expressed in megabits per second) of the corresponding MCS is less than or equal to the rate represented by the Rx Highest Supported Data Rate subfield, then the MCS is supported by the STA on receive. If the Rx Highest Supported Data Rate subfield is equal to 0 and a bit in the Rx MCS Bitmask is equal to 1, then the corresponding MCS is supported by the STA on receive.

doc.: IEEE /401r1 Submission May 2012 Mark RISON (CSR)Slide 9 Point #4: Backward compatibility Concern raised: –Making the HSDR be the HSDR would be problematic for existing hardware implementations of P802.11ac/D2.0 Counter –If an existing transmitter hardware implementation cannot directly support the HSDR being the HSDR, one can simply proceed as follows: If both the transmitted and the receiver support short GI at a given bandwidth, reduce the HSDR indication received by 10% and then it is safe to use short GI at that bandwidth from an HSDR perspective for any rate If the transmitter or the receiver does not support short GI at a given bandwidth then nothing needs to be done for that bandwidth –The above solution will not cause any performance loss compared to the current draft –See also the workaround for point #2 regarding LA in existing hardware implementations of D2.0

doc.: IEEE /401r1 Submission May 2012 Mark RISON (CSR)Slide 10 References 000n-tgn-highest-supported-rate.dochttps://mentor.ieee.org/802.11/dcn/06/ n-tgn-highest-supported-rate.doc 00ac-resolutions-for-highest-supported-data-rate- cids.dochttps://mentor.ieee.org/802.11/dcn/11/ ac-resolutions-for-highest-supported-data-rate- cids.doc 00ac-resolutions-for-highest-supported-rate-cids-11ac- d2-0.dochttps://mentor.ieee.org/802.11/dcn/12/ ac-resolutions-for-highest-supported-rate-cids-11ac- d2-0.doc 00ac-tgac-teleconference-minutes dochttps://mentor.ieee.org/802.11/dcn/12/ ac-tgac-teleconference-minutes doc