1 / 39

LDPC for 11AC

LDPC for 11AC. Authors:. Date: 2010-11-8. Slide 1. Summary. Propose to use the same MCS table for both LDPC and BCC Propose to reuse 11n LDPC PPDU encoding process, regarding codeword length, shortening, puncturing and repetition.

dannon
Download Presentation

LDPC for 11AC

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. LDPC for 11AC Authors: Date: 2010-11-8 Slide 1 Jun Zheng, Broadcom

  2. Summary • Propose to use the same MCS table for both LDPC and BCC • Propose to reuse 11n LDPC PPDU encoding process, regarding codeword length, shortening, puncturing and repetition. • Propose a solution to clarify Npld length in 11AC for LDPC encoding and decoding process • Propose a tone mapping scheme for LDPC Jun Zheng, Broadcom

  3. Same MCS Table For BCC and LDPC

  4. Same MCS Table For LDPC and BCC • For 11AC BCC, some MCSs are excluded due to not satisfying: • Although LDPC PPDU encoding are not restricted from the above limitation, it does create complexity in MU packet when BCC and LDPC users are mixed. • For example, when AP selects MCS for BCC users, it has to omit the ones that are excluded. • Propose to use the same MCS table for both BCC and LDPC • This means those MCSs being excluded for BCC are also excluded for LDPC usage

  5. Reuse 11n LPDC PPDU Encoding Process

  6. Adopting 802.11n LDPC PPDU Encoding • LDPC code is a valuable optional feature of 802.11 • Provides additional coding gain to improve throughput and range • 802.11ac is an evolution of 802.11n • 11n already has an LDPC code defined • Adopting a different LDPC code in 11ac may not be of best interest to 11ac • It is not backwards compatible to 11n • 2 different sets of LDPC encoder/decoder algorithms need to be supported if 11ac devices would also like to support 11n LDPC • Propose to reuse 802.11n LDPC PPDU encoding process for 11ac • This means we adopt to use the same three LDPC codewords (lengths), the same shortening, puncturing and repetition scheme as used in 11n LDPC PPDU • A minor modification to PPDU encoding process is needed for MU packet. Please refer to slides 11-12 for more details.

  7. LDPC Npld Length Clarification

  8. Issues Regarding LDPC Encoding/Decoding • Changes in 11AC from 11n that impacts LDPC • No longer has the length field in unit of octets in VHT-SIG • The exact number of OFDM symbols can be calculated from L-SIG length field and VHT-SIGA2.B1 (i.e. mod(Nsym, 10) == 9 for SGI) • Most of the padding is done at MAC (PHY padding is within 0-7 bits) • Insufficient information at receiver: • RX needs to know Npld to derive all LDPC coding parameters (Ncw, Lldpc, Nshrt, Npunc, Nrep, etc.) • With Nsym only derived from LSIG-length, it’s impossible to recover all key parameters for LDPC decoding • VHT-SIG-B length is not sufficient to determine the LDPC coding parameters. It is because all bits (including pad bits) are encoded, but SIG-B length does not cover MAC/PHY padding

  9. Proposed Solution for SU LDPC PPDU • Number of initial payload OFDM symbols: • Number of final payload OFDM symbols: • flag is hosted in VHT-SIGA2.B3

  10. Proposed Solution (Cont.) • How to obtain Npld at RX side: • Number of payload OFDM symbols: • Nsym_init and Npld:

  11. LDPC PPDU For MU Packet • Propose a solution suitable for multi-encoder (mixture of LDPC and BCC encoders) MU-transmissions [1] • For each user in the MU packet, compute the initial number of OFDM symbols : • Finds the initial estimate of the longest symbol length: • For each LDPC users, go through LDPC PPDU math to find if extra OFDM symbol (or symbols) are needed: • If at least one of the LDPC users require extra OFDM symbol (or symbols), set (VHT-SIGA2.B3 = 1) . • Otherwise, set (VHT-SIGA2.B3 = 0).

  12. LDPC PPDU For MU Packet (Cont.) • L-SIG length is set based on the actual length of the packet: • For each user, construct PSDU by: • For LDPC users, add sufficient MAC padding to fill upsymbols • For BCC users, add sufficient MAC padding to fill up symbols • For each user in the MU packet, • For LDPC users, encode the PSDU using LDPC PPDU process • If , LDPC PPDU encoding process adds symbols • If , LDPC PPDU encoding does not add extra symbols • For BCC users, encode the PSDU using BCC encoder • Note that the tail bits are placed at the very end of the packet

  13. Tone Mapping For LDPC

  14. Motivation of LDPC Tone Mapping • In 11n, interleaving was not needed for LDPC, since • Each 1944-bit LDPC code covers almost all streams and tones within an OFDM symbol • LDPC has an intrinsic pseudo-randomness property that protects it against burst errors • In higher rates of 11ac, the length of the LDPC codeword (LCW) can be significantly smaller than the number of bits in an OFDM symbol (NCBPS) • 80MHz/160MHz and/or 256QAM lead to larger Ncbps • The coded bits from each LDPC codeword are transmitted only through a fraction of the tones, thus not achieving the full frequency diversity • We propose a tone mapping scheme to capture the full frequency diversity without the extra delay of interleaving

  15. LDPC Tone Mapping • Define the LDPC tone mapping distance, DTM • For LDPC-coded streams, map consecutiveQAM symbols to data tones which are separated by at least DTM -1 other data tones • Making sure modulation symbols from each LDPC codeword are transmitted through the full range of tones • Achieves the full frequency diversity • If , instead, we used bit interleaving/de-interleaving (similar to BCC), a receiver latency of up to one OFDM symbol would be added at Rx • To compensate for the added delay, we would need to decrease the number of iterations for the LDPC, resulting in performance penalty • At the receiver, LDPC tone mapping can be implemented as part of the FFT block, with no additional delay • FFT implementations already have tone processing logic, which can be reused with no extra delay Here DTM=3 With LDPC tone mapping

  16. LDPC Tone Mapping Operation • Tone mapping distance: DTM . • After constellation mapping, for user u we have the complex numbers • If LDPC encoding is used, the LDPC tone mapper permutes the stream of constellation numbers to obtain • where • This operation is equivalent to block-interleaving the constellation symbols per stream, per OFDM symbol, using a matrix with DTM rows and NSD /DTM columns, by writing row-wise, and reading back column-wise. • For 160 MHz, the LDPC tone mapping for LDPC-coded streams is performed separately for the upper and lower 80 MHz frequency segments

  17. Proper Choice of DTM • For each rate, it would be desirable to have a DTM which is • At least as large as , so that each LDPC codewords covers the full range of tones • Is an integer divisor of the number of subcarriers, NSD • Is constant over all rates within each bandwidth, so that the tone de-mapper can be implemented at Rx at the FFT block with fixed tone processing • Propose to use the following choice for DTM • For 160MHz, tone interleaving is implemented separately per 80MHz frequency segment • It is shown in Appendix B that tone mapping with the above DTM choice is equivalent to a special case of BCC channel interleaver

  18. LPDC Tone Mapping in MU-MIMO • Tone mapping will not be applied to BCC, since it interferes with the interleaving and degrades the performance in many scenarios • Transmitter structure in MU-MIMO with mixed BCC and LDPC: • At Tx, LDPC tone mapping can be done by an interleaver – able to tolerate the latency • Having the tone interleaver after constellation mapping enables a fixed tone interleaver • A BCC-only Tx or Rx is not affected

  19. Reference [1] “11-10-xxxx-00-00ac-MU-MIMO-support-for-Heterogeneous-Devices”, Byeongwoo Kang and etc.

  20. Straw Polls

  21. Pre-Motion #1 • Do you support to use the same MCS table for both BCC and LDPC? • Yes • No • Abs

  22. Pre-Motion #2 • Do you support to use the same LDPC PPDU encoding process from 802.11n (described in Section 20.3.11.6.5) for 11ac, regarding codeword length, shortening, puncturing and repetition? • Yes • No • Abs

  23. Pre-Motion #3 • Do you support to use the proposed solution in slide 9-12 for LDPC encoding/decoding process and modify the IEEE Specification Framework for TGac as suggested by Appendix A? • Yes • No • Abs

  24. Pre-Motion #4 • Do you support adopting the concept of LDPC tone mapping, as described in slide 15-18, for LDPC-coded streams with DTM=4/6/9/9 for 20/40/80/160 MHz? (Tone interleaving for 160 is done as 2 separate 80)? • Yes • No • Abs

  25. Appendix A:Specification Wording for Pre-Motion #3

  26. Appendix A • Encoding process for MU transmissions For each user in the MU packet, compute the initial number of OFDM symbols based on the following equation: Based on the above equation, the initial estimate of the longest symbol length can be obtained by: For each LDPC users in the MU packet, go through LDPC PPDU encoding process given by Section 20.3.11.6.5 to find if extra OFDM symbol (or symbols) are needed. If at least one of the LDPC users require extra OFDM symbol (or symbols), set , otherwise set .

  27. Appendix A (Cont.) L-SIG length is set based on the actual length of the packet, given by: When constructing each user’s PSDU, add sufficient MAC padding to fill up symbols for LDPC users. Specifically, when , LDPC users should make PPDU encoding process to add extra symbols and result in total payload symbols. When , LDPC users should make PPDU encoding process not to add extra OFDM symbols and result in total payload symbols. When constructing BCC user’s PSDU, add sufficient MAC padding to fill up payload OFDM symbols. Note that the BCC tail bits are placed at the very end of the packet

  28. Appendix B:LDPC Tone Mapping Versus BCC Interleaver

  29. BCC Channel Interleaver –Through Example • HT20, 16-QAM ½ • Ncbps = 208 • Nbpscs = 4 • s = max(1, Nbpscs/2) = 2 • Ncol = 13 • Nrow = 4 * Nbpscs = 16 • Nrot = 11 • Let’s forget about per stream rotation (interleaver 3) for now • Nss = 1

  30. BCC Channel Interleaver –Through Example • Interleaver 1 Write Read

  31. BCC Channel Interleaver –Through Example • Interleaver 2 Map to one subcarrier Interleaving among adjacent s bits Map to next subcarrier

  32. Tone Mapping as a Special Case ofBCC Channel Interleaver • Interleaver 1 w/ modified write orderQAM MAP Map to one subcarrier Read Nbpscs Tone Mapping

  33. LDPC Tone Mapping as a Special Case ofBCC Channel Interleaver BCC Tone Intlv Bit Intlv Tone Rot QAM IFFT LDPC Tone Intlv QAM IFFT W/ modified write sequence LDPC QAM LDPC Tone Mapper IFFT

  34. LDPC Tone Mapping as a Special Case ofBCC Channel Interleaver • Excellent compromise • Each implementation can choose to either • Make use of existing BCC channel interleaver, or • Use tone mapping in front of IFFT • Nrow/Nbpscs = 4/6/9/9 for 20/40/80/160 MHz • Large enough to satisfy in all cases • 20 MHz, Nss=8, 256-QAM 5/6: 3328 / 1944 = 1.7 • 40 MHz, Nss=8, 256-QAM 5/6: 6912 / 1944 = 3.6 • 80 MHz, Nss=8, 256-QAM 5/6: 14976 / 1944 = 7.7

  35. Appendix C:Simulation Results For LDPC Tone Mapping

  36. Simulation Environment for Slide 37-39 • Setup • D NLOS • MMSE MIMO receiver • Ideal channel estimation • Sum-Product LDPC decoding • 12 decoder iterations • 1500 bytes payload

  37. Simulation Results: 80MHz, 4x4, 4SS • 64-QAM, Rate 3/4 • 80MHz, 4x4, 4SS • 12 iterations • DTM =9 for LDPC tone mapping

  38. Simulation Results: 40MHz, 6x6, 6SS • 64-QAM, Rate 3/4 • 40MHz, 6x6, 6SS • 12 iterations • DTM =6 for LDPC tone mapping

  39. Simulation Results: 40MHz, 6x8, 6SS • 64-QAM, Rate 3/4 • 40MHz, 6x8, 6SS • 12 iterations • DTM =6 for LDPC tone mapping

More Related