1. IEEE P802.22 Wireless RANs Date: 2006-01-18
Month Year
doc.: IEEE yy/xxxxr0
January 2006
LDPC for IEEE
IEEE P Wireless RANs Date:
Authors:
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
Carl R. Stevenson 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
>
Yufei Blankenship, Motorola
John Doe, Some Company

2. Month Year
doc.: IEEE yy/xxxxr0
January 2006
Abstract
Many of the initial submissions proposed convolutional codes and convolutional turbo codes. While these codes have the endorsement of being accepted into the initial WiMAX profile, LDPC codes demand consideration due to their characteristic high performance for low complexity, as well as commonality with both e and (likely) n.
This primer will offer motivation for considering LDPC as the baseline code for
Yufei Blankenship, Motorola
John Doe, Some Company

3. Motivation for further consideration of LDPC as the baseline code
January 2006
Motivation for further consideration of LDPC as the baseline code
Convolutional turbo codes (CTC) and LDPC are the two advanced coding alternatives that have been submitted in .22 proposals
CTC was chosen for WiMAX because
early submission of proposal
decoder design is well understood
performance is good
LDPC wasn’t really hashed out until Jan. ‘05, a bit late for WiMAX
However, LDPC is widely perceived as the code of the future
High performance and low complexity
High throughput
LDPC is an option in e
Advanced standards are moving towards LDPC (DVB-S2, e, n… ?)
Yufei Blankenship, Motorola

4. Codec Reuse Scenario: 802.11n and 802.22
January 2006
Codec Reuse Scenario: n and
to/from rooftop antenna
radio
Common baseband elements
(e.g., LDPC codec)
ethernet
802.11n uses e-style LDPC, so encoder/decoder are the same
to/from indoor antenna
802.11n radio
Yufei Blankenship, Motorola

5. January 2006
Why LDPC?
Massive amount of research on LDPC codes by universities and manufacturers
Performance benefits, especially for longer block sizes
Low-complexity implementation
Highly amenable to parallel processing
Low hardware cost for given throughput target
LDPC offers complexity improvement over turbo codes
Flarion estimates an order of magnitude improvement
3 – 4x improvement achievable
Yufei Blankenship, Motorola

6. January 2006
802.16e LDPC
The e LDPC codes have special design features to further simplify hardware implementation
Structured block LDPC for low complexity encoding/decoding
One small base matrix (message interconnection) for 19 code sizes of a given code rate
Blockwise encoding/decoding
Block size of 24 to 96 (related to parallel processing factor), depending on code size
Low complexity differential style encoding
Compact representation of code matrices
Simplified structured decoder architecture across all rates
Yufei Blankenship, Motorola

7. January 2006
Take-Aways
Lower-complexity, higher throughput, better performance alternative to turbo codes
Standards: DVB-S2, e, n
Yufei Blankenship, Motorola