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:

Slides:



Advertisements
Similar presentations
Doc.: IEEE /0570r0 Submission Zander LEI, I2R Singapore December 2007 Slide 1 Beacon Structure Requires Shorter Sensing Windows for the IEEE
Advertisements

Doc.: IEEE /0049r0 Submission Zander LEI, I2R Singapore January 2007 Slide 1 Proposed Beacon Design vs. Baseline Date: Authors: Notice:
Doc.: IEEE /90r0 Submission Nov., 2012 NICTSlide b NICT Proposal IEEE P Wireless RANs Date: Authors: Notice: This document.
Doc.: IEEE /0255r0 Submission March 2005 John Ketchum, Qualcomm IncSlide 1 Responses to WWiSE Points on Beamforming Notice: This document has.
Doc.: IEEE /0227r0 Submission Nov 2006 Wu Yu-Chun, Huawei HisiSlide 1 Beacon Sync Frame Proposal for the IEEE P Wireless RANs Date:
Doc.: IEEE /0930r0 Submission July 2006 Nancy Cam-Winget, Cisco Slide 1 Editor Updates since Jacksonville Notice: This document has been prepared.
Doc.: IEEE /00463r0 Submission Zander LEI, I2R Singapore Sept 2007 Slide 1 Beacon Design Comparison for the IEEE Standard Date:
Doc.: IEEE /0094r0 Submission November 2009 Steve Shellhammer, QualcommSlide 1 Comments on PAR Notice: This document has been prepared.
Doc.: IEEE /0050r0 Submission January 2007 Monisha Ghosh, PhilipsSlide 1 Low PAPR Binary Preamble Design IEEE P Wireless RANs Date:
Doc.: IEEE /0267r0 Submission Jack Winters March 2005 Slide 1 Proposal for Higher Spatial Reuse Date: Authors: Notice: This document.
Doc.: IEEE /1645r2 Submission January 2005 C. Hansen, BroadcomSlide 1 Preambles, Beamforming, and the WWiSE Proposal Notice: This document has.
Doc.: IEEE /0099r0 Submission March 2007 Wu Yu-Chun, Huawei HisiSlide 1 FEC on Sync Burst and PSDU for the IEEE P Wireless RANs.
Doc.: IEEE /0644r2 Submission May 2006 Päivi Ruuska, NokiaSlide 1 Measurement Pilot Transmission Information as optional information in Probe.
Doc.: IEEE /0534r0 Submission May 2005 Steve Shellhammer, Intel CorporationSlide 1 Thoughts on Modifications of the TGn Functional Requirements.
Doc.: IEEE /0129r2 Submission March 2007 David Mazzarese, Samsung ElectronicsSlide Beacon Frame Options IEEE P Wireless RANs.
Doc.: IEEE /0179r0 Submission April 2007 Wu Yu-Chun, Huawei HisiSlide 1 CRC_Length_and_FEC_gain_of_PSDU for the IEEE P Wireless.
Doc.: IEEE /0044r0 Submission November 2005 Steve Shellhammer, Qualcomm Inc.Slide 1 Au Update on Estimating Packet Error Rate Caused by Interference.
Doc.: IEEE /0018r0 Submission January 2006 Patrick Pirat, France TelecomSlide 1 OQAM performances and complexity IEEE P Wireless RANs Date:
Doc.: IEEE /860r0 Submission June 2006 Bjorn A. Bjerke, Qualcomm, Inc.Slide 1 LB84 Resolution of Selected Comments Notice: This document has been.
Doc.: IEEE /1499r0 Submission September 2006 Andrew Storm, BandspeedSlide 1 Enhancement of the Compressed steering matrix performance with power.
Doc.: IEEE /1212r0 Submission TGT and MEF Liaison Notice: This document has been prepared to assist IEEE It is offered as a basis for.
Doc.: IEEE /1936r0 Submission December 2006 Bruce Kraemer, Marvell Adrian Stephens, IntelSlide 1 TGn Proposed Draft Revision Notice Notice: This.
Doc.: IEEE /1528r0 Submission 22 September 2006 Naveen Kakani, Nokia, IncSlide 1 TGn PSMP adhoc Group September Closing Report Notice: This document.
Doc.: IEEE /0520r1 Submission November 2007 Soo-Young Chang, Huawei TechnologiesSlide 1 New Code for RTS/ANP for Lower Probability of Collision.
Doc.: IEEE /0288r0 Submission March 2005 Sean Coffey, Realtek.Slide 1 TGn Editor election statement Notice: This document has been prepared to.
Doc.: IEEE /0022r0 Submission January 2007 Wu Yu-Chun, Huawei HisiSlide 1 Enhanced Beacon Sync Frame for the IEEE P Wireless RANs.
Doc.: IEEE /0477r0 Submission March 2007 C. Wright, AzimuthSlide 1 Proposal for fixing additional issues in some subclauses Notice: This document.
Technical comparison of the value of proposed MAC features
IEEE P Wireless RANs Date:
Closed versus Open Loop Comparisons
Coexistence Motions for LB84 Comment Resolution
WWISE LDPCC performance
[ Interim Meetings 2006] Date: Authors: July 2005
Closed versus Open Loop
FEC on Sync Frame for the
IEEE P Wireless RANs Date:
LB73 Noise and Location Categories
LB73 Noise and Location Categories
Waveform Generator Source Code
Preambles, Beamforming, and the WWiSE Proposal
[ Policies and Procedure Summary]
Complex Beacon Pros and Cons
LB84 Submission: Updated LDPC Encoding Figure to Resolve CID #940
Power Variations with WWiSE Cyclic Preamble Structures
Power Variations with WWiSE Cyclic Preamble Structures
LB84 PHY Ad-hoc Comment Resolution CID# 690
TGn Sync Simulation Results – Goodput versus PHY overhead
Binary Preamble Sequence Set
IEEE P Wireless RANs Date:
[PAPR Evaluation on SCH in IEEE ]
IEEE P Wireless RANs Date:
Detailed Responses to “Reasons and Cures” Comments on MCS Set
IEEE P Wireless RANs Date:
IEEE WG Opening Report – July 2007
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
IEEE P Wireless RANs Date:
IEEE P Wireless RANs Date:
[ Policies and Procedure Summary]
OFDM Parameters And Preambles
Preambles, Beamforming, and the WWiSE Proposal
Beamforming and Link Adaptation Motions
Beam Ad Hoc Agenda Date: Authors: March 2007 March 2007
High-Speed Broadband Wireless LAN Solution
New Code for Symbol-to-Chip Spreading for Multiple PPDs
New Code for RTS/ANP for Lower Probability of Collision
STC with CSI feedback IEEE P Wireless LANs Date:
Decoding Latency for STBC and LDPC
WNG SC Closing Report Date: Authors: November 2005
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
Selection Procedure Recommendation
Presentation transcript:

doc.: IEEE /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 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at. Date: Authors:

doc.: IEEE /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

doc.: IEEE /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)

doc.: IEEE /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.

doc.: IEEE /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 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.

doc.: IEEE /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

doc.: IEEE /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 e 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, TGn 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

doc.: IEEE /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

doc.: IEEE /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 e FEC design

doc.: IEEE /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 ) 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.

doc.: IEEE /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.

doc.: IEEE /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).

doc.: IEEE /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/ R=2/ R=3/ R=5/

doc.: IEEE /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.

doc.: IEEE /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.

doc.: IEEE /0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 16 Responses to Complexity Comments (7) The proposed code is just a minor variant of the e FEC design –The codes proposed here are not the codes proposed in e. 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 e. The use of 24-column base matrices helps to facilitate hardware reuse with solutions compatible with e. Reduction in development time and core reuse across e and n also provides an advantage for implementers.

doc.: IEEE /0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 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

doc.: IEEE /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.

doc.: IEEE /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

doc.: IEEE /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

doc.: IEEE /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

doc.: IEEE /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.

doc.: IEEE /0431r0 Submission May 2005 Bjorn A. Bjerke, QualcommSlide 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

doc.: IEEE /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.

doc.: IEEE /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)

doc.: IEEE /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 Traffic: The wireless Side, University of Maryland, College Park, March 2004

doc.: IEEE /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

doc.: IEEE /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.

doc.: IEEE /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.