140 likes | 340 Views
MCS Selection and Padding Equations. Authors:. Date: 2010-07-13. In an earlier submission [1], we discussed the possibility of using 802.11n encoder and stream parsing rules for 802.11ac, i.e.
E N D
MCS Selection and Padding Equations Authors: Date: 2010-07-13 Sudhir Srinivasa et al.
In an earlier submission [1], we discussed the possibility of using 802.11n encoder and stream parsing rules for 802.11ac, i.e. Encoder parsing is done in the same way as 11n (i.e., the encoder parser cycles through the encoders in a round robin fashion assigning one bit to each encoder in each cycle. Each encoder is assigned an equal number of bits.) Stream parsing is done as in 11n (i.e., in any cycle, NSS blocks each with s bits (# bits/constellation-axis) from a given encoder are allocated to different spatial streams. The stream parser moves from one encoder to the next in each cycle in a round robin fashion) Simplifies transmitter/receiver implementation, avoids extra hardware Some VHT frame padding concepts were described in [2]. Background Sudhir Srinivasa et al.
TGac has converged on the following aspects of the transmitter flow during the previous plenary (May 2010 meeting) 234 data tones for 80MHz packets (3 DC + 8 pilots) Addition of 256QAM rate 3/4 and rate 5/6 to the list of MCSs We also noted [1] that 11ac will require multiple BCC encoders to support the high data rates of VHT packets In a few MCS-Nss combinations (specifically 80MHz and above), owing to multiple encoders, the 11n encoder and stream parser rules could result in a prohibitive number of extra padding symbols. We first propose a set of MCS exclusion rules to identify and avoid such MCSs from the MCS parameters table. We then summarize the padding equations that conform to the previously described encoder parser, stream parser and frame padding rules. Overview Sudhir Srinivasa et al.
In order to avoid extra padding symbols, we will need to ensure that we have an integer number of punctured blocks from all encoders, i.e. both NCBPS/NES and NDBPS/NES are integers. Mathematically we need Based on this condition, the MCS parameters table will need to exclude some (different) MCSs for 20/40/80MHz. MCS Selection Rules Sudhir Srinivasa et al.
To illustrate the MCS selection rules, we consider the following example: 80MHz, 7 stream, 64QAM packet coded using the rate 3/4 BCC in long GI NCBPS = 234 * 6 * 7 = 9828 The number of encoders NES, assuming a data rate of 600Mbps/encoder will be ceil(NCBPS * (3/4) / (4e-6 * 600e6)) = 4 Although NCBPS/NES is an integer, NDBPS/NES = 7371 / 4 (not an integer). Since we have equal distribution of information bits across the 4 encoders, the number of OFDM symbols will have to be a multiple of 4 extra padding symbols might be necessary in some cases. The receiver also needs to store multiple OFDM symbols (extra buffer needed). We propose that such combinations be avoided in the MCS tables. Further, although the MCS exclusions are only for BCC, we propose that such MCSs also be excluded for LDPC This avoids separate MCS tables for BCC and LDPC MCS Selection Rules (Example) Sudhir Srinivasa et al.
Padding Equations (BCC) • Padding equations are identical to 11n • Padding Flow: • After computing NSYM and NPAD, the MAC pads to the last byte boundary • MAC indicates the number of PHY bits to be padded (through TxVector) • PHY first adds 0-7 padding bits and then NES tail bits at each encoder. Sudhir Srinivasa et al.
With multiple users, each user’s packet is padded to the length of the longest packet Padding Flow: MAC calculates NSYM for each user separately using the equation below: For each user, based on the maximum number of symbols over all users, MAC pads to the last byte for each user. The number of PHY padding bits for any user is calculated as in the SU case For each user, the encoding and stream parsing is done as in the SU case mSTBC=1 if all users do not apply STBC; mSTBC=2 if all users apply STBC. Padding in DL-MUMIMO Sudhir Srinivasa et al.
Depending on the MCS selection constraint, some MCS will need to be excluded for 20MHz and 80MHz. To avoid confusion, we propose that we exclude these MCSs for both BCC and LDPC. i.e. for the range of data rates that allows both BCC and LDPC, the MCS table is unified for BCC and LDPC. Padding equations for 20/40/80MHz BCC presented. Discussion Sudhir Srinivasa et al.
Straw Poll 1 (MCS Exclusions for BCC) • Do you support adding the following to the specification framework document (11-09/0992, Section 3.3.x (Modulation and Coding Scheme)): • For BCC encoding, some of the MCS-NSS combinations are excluded from the MCS table to avoid additional padding symbols • Allowed MCSs are selected such that the number of coded bits in each OFDM symbol contains an integer number of punctured blocks from all encoders, i.e., mathematically every allowed MCS-NSS satisfies: • Yes: • No: • Abstain: Sudhir Srinivasa et al.
Straw Poll 2 (Exclusions for LDPC) • Do you support adding the following to the specification framework document (11-09/0992, Section 3.3.x (Modulation and Coding Scheme)): • For the data rates that allows both BCC and LDPC, 802.11ac have a common MCS table for both BCC and LDPC, i.e., • The MCS-NSS combinations excluded for BCC also be excluded for LDPC • Yes: • No: • Abstain: Sudhir Srinivasa et al.
Straw Poll 3 (SU Padding) • Do you support adding the following to the specification framework document (11-09/0992, Section 3.2.4.x (VHT Data Field)): • For BCC, the padding equation and padding flow should be as shown in slide 6, for SU packets (identical to 11n) • Yes: • No: • Abstain: Sudhir Srinivasa et al.
Straw Poll 4 (MU Padding) • Do you support adding the following to the specification framework document (11-09/0992, Section 3.2.4.x (VHT Data Field)): • For BCC, the padding equation and padding flow should be as shown in slide 7, for MU packets. • Yes: • No: • Abstain: Sudhir Srinivasa et al.
References • [1] 80MHz Transmission Flow (https://mentor.ieee.org/802.11/dcn/10/11-10-0548-01-00ac-80mhz-transmission-flow.ppt) • [2] VHT Frame Padding (https://mentor.ieee.org/802.11/dcn/10/11-10-0064-05-00ac-vht-frame-padding.ppt) Sudhir Srinivasa et al.