1. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 1 Responses to reasons and cures comments on TGn Sync LDPC codes Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2005-05-11 Authors:

2. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 2 Abstract This presentation contains the TGn Sync responses to the reasons and cures comments concerned specifically with the LDPC Advanced Coding option

3. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 3 “No” Vote Comments 6 “No” vote comments received from TGn members concerned specifically with the TGn Sync LDPC coding scheme Topics (no. of comments): –Complexity (3) –Performance (2) –Concatenation rules (1)

4. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 4 LDPC Comments (1) Dave Hedberg: The current proposal does not result in good “airtime” efficiency for shorter packets and does not consider minimizing the excess decoder complexity required to meet short end of packet latency decoding time requirements at full data rates. The PPDU algorithm does not work to minimize the number of transmitted OFDM symbols. After determining ceiling of codewords required for a packet, the algorithm pads out the last symbol, rather than shortening or some other method of minimizing the number of OFDM symbols, consistent with the rate goal. All codewords are of equal length and rate, thus requiring a full number of iterations in the tail code-blocks to achieve the targeted PER performance. This drives decoder speed and complexity to higher levels than otherwise required. The shorter codeblock option still does not result in good efficiency with shorter packet lengths, because it is not tailored to achieve a closest “fit” to a minimum number of OFDM symbols, and wasted pad bits are transmitted in the last symbol. Better efficiency is critical to minimizing power consumption in applications such as cell-phone WLANs with VoIP.

5. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 5 LDPC Comments (2) Feng-Wen Sun: Performance issue of LDPC: it has been demonstrated that code with better performance is achievable with the same or even lower implementation complexity. It is not acceptable to have an inferior FEC. Although LDPC is optional at this point, the advantage provided by LDPC will make it the de-facto required feature. John Benko: No specific complexity information is given for the decoder design of the TGnSync LDPC code. This is essential to ensure the best code with lowest complexity. With this particular information I will be able to better judge the proposed code, and potentially change my vote to yes (assuming the below points are also satisfied). Nico van Waes: The optional FEC is poorly designed and requires too many parallel decoders or achieves too few iterations. Paul Gray: The maximum data rate that the Advanced FEC must support in the TGnSync proposal is 600 Mbps. Thus the LDPC decoder will dominate the gate count in high speed products (and even in the 70-80 Mbps low power, handheld devices where advanced FEC will be required for longer range). However, no complexity estimates for the advanced FEC have been provided, and no attempt has been made to minimise the complexity. Rather, the FEC proposed is just a minor variant of the (much slower speed) 16e FEC design. Stefano Valle: LDPC codes with better performance and same complexity can be designed.

6. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 6 Outline Background: High level comparison of TGn Sync and WWiSE LDPC code features Comment responses: 1.Complexity 2.Performance 3.Concatenation rules

7. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 7 Comparison of Features: TGn Sync vs WWiSE (1) FeatureTGn SyncWWiSEComments Key featuresStructured code based on expansion of base matrices Similar concepts H matrixSub blockCyclically shifted identity matrices Stair case matrices Sub-diagonal matrices WWiSE R=2/3 code does not lend itself to LBP decoding quite as easily as the corresponding TGn Sync code Block sizeSame number of column blocks (24) for all code rates Different number of column blocks per code rate TGn Sync has better regularity; also enables reuse of 802.16e designs Max. column degree “Low” (8, 7, 6, 4)“High” (11, 9, 7, 6)WWiSE’s higher column degrees result in higher decoding complexity Parity portionWeight-2, except one block column Variable depending on code rateTGn Sync structure enables somewhat lower encoding complexity FlexibilityFrame sizes576, 1152, 17281944TGn Sync more flexible Code rates1/2, 2/3, 3/4, 5/6 Perfect harmony ComplexityEncodingLow (RU, back substitution)Low (back substitution)Relatively similar encoding complexity DecodingBP, LBPBP, LBP (except R=2/3 code)Somewhat higher for WWiSE due to higher max. column degree and higher average row degree Decoder memory requirements Similar; slightly higher for WWiSE due to higher average column degrees Performance – FER/PER vs SNR (1728 vs 1944) AWGN1.5 – 3 dB better than K=7 convolutional code Up to 0.1 dB better than TGn Sync performance WWiSE better due to higher density (max. column degree) and slightly larger frame size FadingVirtually identical performance

8. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 8 Comparison of Features: TGn Sync vs WWiSE (2) FeatureTGn SyncWWiSEComments Concatenation rulesPuncturing, shortening of each codeword in a packet; minimizes no. of OFDM symbols needed Shortening of last codeword only in a packet WWiSE simpler but less efficient; requires more zero-padding and extra OFDM symbols

9. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 9 1. Complexity Summary of comments received: No complexity estimates have been provided for the decoder The current proposal does not minimize encoder and decoder complexity The LDPC is poorly designed The LDPC code requires too many parallel decoders or achieves too few iterations The proposed code is just a minor variant of the 802.16e FEC design

10. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 10 Responses to Complexity Comments (1) No complexity estimates have been provided for the decoder –Detailed complexity estimates for LDPC implementations are difficult to quantify since they will be implementation dependent. There are a wide variety of possible architectures, algorithms and processing kernels that can be used. Tradeoffs can be made between parallelism and iteration count using various algorithms as well. This large selection space for decoding solutions makes it difficult to provide a meaningful detailed analysis. An early presentation to TGn Sync (Doc. 11-03-0865-01) contained a general estimate which is still reasonable for the codes being proposed by both WWiSE and TGn Sync. Careful selection of tradeoffs and use of advanced algorithms may be expected to result in implementations that are more efficient than estimated in that presentation.

11. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 11 Responses to Complexity Comments (2) –In relative terms, the decoding complexity of the TGn Sync LDPC proposal can be readily compared to that of the WWiSE proposal. Both codes accommodate decoding by Layered Belief Propagation. The decoding complexity has proportionalities with the block sizes and the ones density (or maximum degree) of the matrices. The TGn Sync LDPC proposal uses a smaller maximum block size as well as lower matrix densities (i.e., lower maximum degrees) than the WWiSE proposal. The base matrix column dimensions are also smaller. These factors can be expected to result in less complexity for solutions based on the TGn Sync proposal than for those using the WWiSE proposal.

12. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 12 Responses to Complexity Comments (3) –Decoding Complexity Comparison -- TGn Sync vs WWiSE: Assumptions: Layered Belief Propagation decoding algorithm based on well known reference (Mansour’s paper). Storage (on chip register memory) is proportional to the codeword size, N ( N WWiSE = 1944, N TGnSync = 1728), and the average column density, D. Complexity of Message Processing Units (MPU) is approximately the same (although WWiSE appears to be slightly more complex).

13. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 13 Responses to Complexity Comments (4) Complexity = C Complexity ratio: C W/T = C WWiSE /C TGnSync = N WWiSE /N TGnSync x D WWiSE /D TGnSync WWiSETGn Sync C W/T WWiSE more complex by (%) N WWiSE D WWiSE N TGnSync D TGnSync R=1/219443.58317283.3751.1919 R=2/319443.66717283.3751.2222 R=3/419443.47217283.5421.1010 R=5/619443.47217283.2921.1919

14. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 14 Responses to Complexity Comments (5) The current proposal does not minimize encoder and decoder complexity –The TGnSync LDPC code seeks to minimize encoder complexity by accommodating low complexity and linear time encoding using the “Richardson-Urbanke” algorithm and/or back substitution. In this respect, it is similar to the WWiSE LDPC proposal. However, due to the modified dual-diagonal structure of the parity check sub-matrix corresponding to the parity bits, the TGn Sync construction enables further reduction in encoding complexity. –The TGnSync LDPC code has been designed to accommodate decoding by Layered Belief Propagation, which enables a substantial reduction in decoding complexity. We feel that the actual parity matrix designs that accommodate LBF strike a good balance between performance and decoding complexity, and compare favorably with the WWiSE LDPC design.

15. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 15 Responses to Complexity Comments (6) The LDPC is poorly designed –We do not believe that this statement is true and submit the current presentation as supporting evidence. The LDPC code requires too many parallel decoders or achieves too few iterations –Parallelism and iteration capability are tradeoffs that can be made by the implementers. The TGn Sync proposal has been designed to provide as many opportunities for tradeoff exploitation as possible. This can be seen in the use of Layered Belief Propagation, common column widths of all base matrices, the structure of the parity check portion of the base matrices, the use of a small number of block sizes, and other features of the proposal.

16. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 16 Responses to Complexity Comments (7) The proposed code is just a minor variant of the 802.16e FEC design –The codes proposed here are not the codes proposed in 802.16e. The primary commonalities are the use of expansion factors to accommodate Layered Belief Propagation, the structure of the parity check portion of the base matrices, and the use of 24- column base matrices. The base matrices are not common with 802.16e. The use of 24-column base matrices helps to facilitate hardware reuse with solutions compatible with 802.16e. Reduction in development time and core reuse across 802.16e and 802.11n also provides an advantage for implementers.

17. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 17 2. Performance Summary of comments received: Codes with better performance are achievable with the same or lower implementation complexity It is not acceptable to have an inferior FEC

18. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 18 Responses to Performance Comments (1) Codes with better performance are achievable with the same or lower implementation complexity –We agree that better performance is achievable. However, significant performance improvement comes at the expense of increased complexity. Indeed, we have improved the performance of our rate-2/3 code somewhat (~0.2 dB in AWGN), but further improvements would require increasing the row degree, which would result in increased complexity. We believe that the TGn Sync LDPC code strikes a good balance between performance and implementation complexity. It is not acceptable to have an inferior FEC –We completely agree, and believe that the TGn Sync LDPC code represents the superior choice among the advanced coding schemes that have been proposed in TGn so far. –In the following slides, we compare the performance of the TGn Sync and WWiSE LDPC codes in AWGN (decoding by standard Belief Propagation with max. 50 iterations) and fading (decoding by Layered Belief Propagation with max. 15 iterations). While the WWiSE codes have a slight advantage in AWGN (~0.1 dB - due to larger codeword size and higher decoding complexity), the two codes have virtually identical performance in fading.

19. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 19 Responses to Performance Comments (2) Frame error rate vs SNR in AWGN; standard Belief Propagation with 50 iterations

20. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 20 Responses to Performance Comments (3) Packet error rate vs SNR in fading ch. B; 1000 B packets; Layered Belief Propagation with 15 iterations

21. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 21 Responses to Performance Comments (4) Packet error rate vs SNR in fading ch. D; 1000 B packets; Layered Belief Propagation with 15 iterations

22. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 22 Responses to Performance Comments (5) Summary of performance comparisons –WWiSE codes perform up to 0.1 dB better in AWGN with standard Belief Propagation (50 iterations), due to higher density and slightly larger frame size (both result in higher decoding complexity). –The performance in fading with Layered Belief Propagation decoding is virtually identical for TGn Sync and WWiSE codes.

23. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 23 3. Concatenation Rules Summary of comments received: The current proposal does not result in good air-time efficiency for short packets The encoding algorithm does not minimize the number of transmitted OFDM symbols All codewords in a packet are of equal length, requiring a full number of iterations in the tail code blocks The shortest codeword does not result in good efficiency with short packets; does not minimize the number of OFDM symbols

24. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 24 Responses to Concatenation Rules Comments (1) The current proposal does not result in good air-time efficiency for short packets –TGn Sync has re-designed the concatenation rules in order to achieve the best tradeoff between efficiency and performance. Features of the re- designed proposal include: Codeword length selection –selected from a set of 3 sizes (576, 1152, 1728) to best fit packet size and total number of OFDM coded bits. Encoding method –both shortening and puncturing are applied in order to ensure minimum overhead without degrading performance. –shortening and puncturing distributed across all codewords in a packet. Puncturing –based on minimum allowed shortening-to-puncturing ratio. –additional OFDM symbols are added only when necessary to ensure performance. –at most 2 additional OFDM symbols allowed to adhere to minimum shortening-to- puncturing ratio requirement.

25. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 25 Responses to Concatenation Rules Comments (2) The encoding algorithm does not minimize the number of transmitted OFDM symbols –The updated concatenation rules are designed to minimize the number of transmitted OFDM symbols subject to the constraints in our design (see features on previous slide). –TGn Sync air-time penalty compares favorably to that of WWiSE (see analysis on next two slides)

26. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 26 Air Time Penalty is OFDM symbol interval, in ms We define Air Time Penalty (AP), in %, the following way where, is number of OFDM symbols used for LDPC coded transmission is number of OFDM symbols used for CC coded transmission is preamble time, in ms * Average Air Time Penalty calculated under the assumption of traffic model found in the following report: Jihwang Yeo, Moustafa Youssef, Ashok Agrawala, Characterizing the IEEE 802.11 Traffic: The wireless Side, University of Maryland, College Park, March 2004

27. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 27 Air Time Penalty Payload, bytes MCS 0.27% 2.15% Air Time, % Average Air time penalty, %, based on UMD traffic model * TGnSync WWiSE

28. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 28 Responses to Concatenation Rules Comments (3) All codewords in a packet are of equal length, requiring a full number of iterations in the tail code blocks –The TGn Sync LDPC coding scheme applies shortening and puncturing across all codewords to improve the PER performance. –With a reasonable decoding throughput, the decoder can finish decoding the last codeword within the SIFS decoding budget.

29. doc.: IEEE 802.11-05/0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 29 Responses to Concatenation Rules Comments (4) The shortest codeword does not result in good efficiency with short packets; does not minimize the number of OFDM symbols –The TGn Sync scheme chooses the appropriate codeword size based on packet size and number of OFDM symbols. The shortest codeword is used for packets of size less than 40 Bytes. The number of transmitted OFDM symbols is minimized by applying shortening and puncturing.