1 / 10

Highest Supported Data Rate

Highest Supported Data Rate. Authors:. Date: 2012-03-13. 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.

oneida
Download Presentation

Highest Supported Data Rate

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Highest Supported Data Rate Authors: Date: 2012-03-13 Mark RISON (CSR)

  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 Mark RISON (CSR)

  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 2011-12-05 to the TGac mailing list that: • I believe that [the HSDR] is "the Highest Supported Data Rate the absolute maximum an implementation's data pipes can cope with" • In fact it was us (Mark) pressing for clarification (see 11-1508) that resulted in HSDR being qualified with long GI in D2.0 • But this was done just as a strawman to prime the discussion Mark RISON (CSR)

  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 NES) • NES should be specified explicitly, just like any other capability (256 QAM, LDPC, short GI, ...) Mark RISON (CSR)

  5. Point #1: NES restrictions • Allert wrote on 2011-12-07 to the TGac mailing list that: • I have a counter example from Table 22-48 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. Mark RISON (CSR)

  6. Point #1: NES restrictions (continued) • Observations • This is assuming an implied use of HSDR to specify maximum supported NES • There is quirkiness in 11ac not present in 11n, whereby NES 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 NES • But for long GI only, NESdoes grow monotonically with data rate, hence Allert’s workaround is viable • Counter • This is inelegant • Stems from NES not being monotonic • Hijacks HSDR to be linked to NES • 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 NES capability resolves Allert’s concern directly Mark RISON (CSR)

  7. Point #2: Link adaptation • Concern raised by Robert in 2012-03-01 teleconf: • If a receiver supports only long GI for the top rate, this complicates link adaptation • Counter • The link adaptation tx rate selection has to take HSDR into account, but it’s easy (same logic as non-link-adapted tx rate selection) • If the transmitter does not want to have to take HSDR into account, however, it can just always use long GI (since the MCS feedbacker is required to recommend an MCS which it can receive to the MCS feedbackee) Mark RISON (CSR)

  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: • 8.4.2.58.4 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 9.7.6.5.3. • 9.7.6.5.3 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. Mark RISON (CSR)

  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 implementation cannot directly support the HSDR being the HSDR, it can simply – if short GI is supported at both sides – reduce the HSDR received by 10% and then it is “safe” • See also the workaround for point #2 regarding LA in existing hardware implementations of D2.0 Mark RISON (CSR)

  10. References • https://mentor.ieee.org/802.11/dcn/06/11-06-1904-01-000n-tgn-highest-supported-rate.doc • https://mentor.ieee.org/802.11/dcn/11/11-11-1518-05-00ac-resolutions-for-highest-supported-data-rate-cids.doc Mark RISON (CSR)

More Related