SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

Highest Supported Data Rate

boyd avatar
boyd
11 diapositives · 379 Views · Aug 24, 2014

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

Highest Supported Data Rate - slide 1
01 / 11Highest Supported Data Rate
1 / 17

Télécharger la présentation

Highest Supported Data Rate
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  1. Highest Supported Data Rate Authors: Date: 2012-05-16 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 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 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. Justification of proposal (continued) • Allows throughput tobe maximised • Illustrative example: • Imagine we are operating in 20 MHz bandwidth with 1SS, both sides support short GI, and the receiver has a host interface which limits the PHY rate to 40 Mbps • In D2.0, the receiver HSDR would have to be set to a value corresponding to the long GI rate of 26.0 Mbps as this is the highest long GI rate for which the receiver’s host interface can support the corresponding short GI rate of 28.9 Mbps. The maximum PHY rate which the transmitted can use is thus 28.9 Mbps • If the HSDR is the HSDR, the receiver would simply signal that it can support 40 Mbps and the maximum rate which the transmitter can use is thus 39.0 Mbps • Thus, we here get a 38% improvement in throughput by going with the proposed change! May 2012 Slide 5 Mark RISON (CSR)

  6. 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)

  7. 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 and inefficient • 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 (see 12/238) resolves Allert’s concern directly Mark RISON (CSR)

  8. 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 MCS feedbackee is already required to cope with being recommended something the MCS feedbacker cannot receive (apart from N_STS; see minutes of 2012-04-05 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 Mark RISON (CSR)

  9. 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)

  10. 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 • See also the workaround for point #2 regarding LA in existing hardware implementations of D2.0 Mark RISON (CSR)

  11. 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 • https://mentor.ieee.org/802.11/dcn/12/11-12-0238-00-00ac-resolutions-for-highest-supported-rate-cids-11ac-d2-0.doc • https://mentor.ieee.org/802.11/dcn/12/11-12-0488-00-00ac-tgac-teleconference-minutes-20120405.doc Mark RISON (CSR)