1. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 1 Duo-binary_Turbo-codes: questions and answers IEEE P802.22 Wireless RANs Date: 2006-01-06 Authors: Notice: This document has been prepared to assist IEEE 802.22. 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 IEEEs name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEEs 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.22. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures http://standards.ieee.org/guides/bylaws/sb-bylaws.pdf 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 Chairhttp://standards.ieee.org/guides/bylaws/sb-bylaws.pdf Carl R. StevensonCarl 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 802.22 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at patcom@iee.org.patcom@iee.org >

2. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 2 Abstract This set of slides intends to give some answers to the questions that followed the presentation of November 2005

3. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 3 Duo-Binary input: two decoded bit output at a time –Reduction of latency and complexity per decoded bit (compared to Binary TC) –Better convergence –Circular (tail-biting) encoding –No trellis termination overhead –Original interleaving scheme –Larger minimum distances –Improved asymptotic performances Duo-Binary Turbo-code Single-binary could also be designed to process two bits at once if needed: no advantage. More parellel sub-blocks could also be used for single-binary. Complexity (ignoring overhead): duo-binary 8-state decoder require 50% more comparisons per info bit and more than 50% more memory for extrinsics than single-binary TC. Duo-binary may allow more parallelism than single-binary. LDPC can allow massive parallelism. Duo-binary is not expected to be better than single- binary. It may be better than some LDPC implementations. Both duo-binary and single-binary TC implementations will tend to have the similar performance in the waterfall and same convergence performance with good spread interleavers. Not unique to duo-binary, should be used also for single-binary. 3GPP standard termination technique is not recommended because it generate high BER flare. With a good interleaver design, single-binary gives larger distances and thus better flare performance. Best trade-off to date: single-binary turbo code with Crozier (dithered relative prime, DRP[1,2]) interleavers: dmin=51 for R=1/3 and K=1504, while duobinary 8- state DVB-RCS gives dmin=33 and with Y. Ould- Cheikh-Mouhamedou interleaver[3], dmin= 40. As long as a good interleaver design approach is used, single- binary will tend to give better distances, and lower flares. Single-binary tends to give better distances because the interleaver is effectively twice as long as the one for duo-binary. In general, the main advantages of double- binary Turbo codes apply to single-binary Turbo codes as well (i.e., flexibility, fixed encoder/decoder pair, tail-biting).

4. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 4 Internal Interleaver Algorithmic permutation –One equation, 4 parameters (P0, P1, P2, P3) –Parameters selected such that interleaver is contention-free Adjusting the TC to a blocksize only requires modification of the 4 parameters Quasi-regular permutation (easy connectivity) Inherent parallelism i = 0, …, N-1, j = 0,...N-1 level 1: if j mod. 2 = 0, let (A,B) = (B,A) (invert the couple) level 2: -if j mod. 4 = 0, then P = 0; -if j mod. 4 = 1, then P = N/2 + P 1 ; -if j mod. 4 = 2, then P = P 2 ; -if j mod. 4 = 3, then P = N/2 + P 3. i = P 0 *j + P +1 mod. N DVB-RCS standard interleaver. Better distances have been found with dithered relative prime (DRP) interleavers which are also highly structured to save memory. All these features also apply to DRP interleavers.

5. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 5 Answers: complexity (1) "Raw comparison" of 8-state Duo-Binary TC and 8-state binary TC (UMTS) Study case: (54 bytes, rate ½) BinaryDuo-binaryRatio Gate count1310024100+ 80% Memory (bits)2900040088+ 38% Silicon area (0.13 um) 0.23 mm²0.36 mm²+ 50% Decoded bit per clock cycle 12+ 100% Complexity per decoded bit(constant clock rate) 10.78- 22%

6. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 6 Answers: complexity (2) In a first approach, the complexity of an 8-state duo-binary turbo- decoder is about 50% higher than the one of a simple binary decoder But, using the same computing clock, a duo-binary decoder processes the data by pairs, and outputs 2 decision data at each cycle. Therefore, using the same clock, a duo-binary turbo-decoder achieves twice the throughput of a binary decoder with only 50% hardware more. In the same clock condition and throughput requirements, the hardware of a binary decoder should be duplicated. And then, referring to the complexity per decoded bit, a duo-binary decoder is about 22% less complex than a binary decoder

7. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 7 Answers: comparison with single-binary TC We believe that Duo-Binary TC represent the best compromise in terms of performance/complexity trade- off(see previous answer). The advantages described in our slides are not limited only to Duo-Binary TC. Single-binary TC can also be designed to be parallelized. Duo-Binary TC has an inherent capability to parallelism, enabled by the internal interleaver.

8. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 8 Answers: Interleavers It is true that well-designed single-binary TC can provide better distances than DVB-RCS standard interleaver, but the Duo-Binary TC can benefit from the two-level permutations (inter-couples and intra- couples) We have proposed the interleaver as defined into DVB- RCT/RCS standard, but are open to discussion on other possible interleavers if they represent better alternatives

9. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 9 Answers: Performance (1) Convergence: Duo-Binary TC show better convergence due to the lower density of erroneous paths –See "The advantages of nonbinary turbo codes", C. Berrou, M. Jezequel, C. Douillard and S. Kerouedan, Proceedings of Information Theory Workshop, Cairns, Australia, pp. 61-63, Sept. 2001 Following slides: Performance comparison of Duo- Binary TC and single-binary TC (UMTS) on AWGN for different coding rates and blocksizes

10. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 10 Answers: Performance (2) Coded blocksize N=864 bits –Information blocksize K=432 bits for R=1/2 –Information blocksize K=648 bits for R=3/4 Max-Log-MAP decoding, 8 iterations

11. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 11 Answers: Performance (3) Coded blocksize N=1440 bits –Information blocksize K=720 bits for R=1/2 –Information blocksize K=1080 bits for R=3/4 Max-Log-MAP decoding, 8 iterations

12. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 12 Flexibility Can be easily adjusted to any blocksize –Storage of the 4 parameters for all blocksizes considered –Possibility of a generic approach (default parameters) All coding rates are possible –Through puncturing patterns –Natural coding rate is ½: increased robustness to puncturing Performance vs complexity: several adjustments are possible –Number of iterations, Decoding algorithm, … Implementation: interleaver enables different degrees of parallelism –Can be adjusted to meet complexity/throughput requirements Most of these features apply to any highly-structured approach.

13. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 13 Flexibility The number of iterations can be adjusted for a better performance- complexity trade-off

14. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 14 Performance Duo-Binary TC, 8 iterations, Max-Log- MAP decoding IEEE 802.16e structured LDPC, BP decoding, 50 iterations AWGN, R=1/2, QPSK N=576 and 2304 (coded blocksize) Rather poor performance for LDPC, implementation? 8 iterations for duo-binary TC versus 50 iterations for LDPC!

15. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 15 Answers: performance (4) The simulation settings used in the previous slides correspond to the ones adopted in IEEE 802.16e standardization group during the selection process of the LDPC code –50 iterations with BP algorithm The results presented correspond to simulation results of the LDPC defined in IEEE 802.16e specification, and not implementation results

16. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 16 Short blocksize performance Hardware measurements Low BER (down to 10 -11 ) are achievable without error floor Why different block size for BER and FER? Error flare barely appears. Larger block sizes need to be used to be more realistic. Are block lengths of 16 and 18 bytes pertinent to WRAN operation? Even VoIP with 20 ms latency would likely produce longer blocks. [1] presented DVB-RCS results for a larger block size (484 bits) and a lower code rate (1/3) than these cases and shows evidence of flares starting between PER=1e-3 and 1e-4.

17. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 17 Answers: Short Blocksize Performance The blocksizes employed in the previous simulations correspond to blocksizes standardized in DVB-RCT This figure was included to dismiss some misconceptions that Turbo Codes don't perform well for short block sizes –Please refer to other plots in proposal to see performance for the larger block sizes.

18. doc.: IEEE 802.22-06/0017r0 Submission January 2006 Patrick Pirat, France TelecomSlide 18 Summary: Gains brought by OQAM and DTC OFDM/OQAM brings 10% more bit-rate –When converted in error protection enables to go from ¾ rate to 2/3 –Gain between 1 and 1,5 dB in C/N Duo-binary TC offers 3,5 to 4 dB When combined the gain is at least 4,5 dB that allows to increase the radius by 7,6 km (17%) with QPSK modulation in a Gaussian channel. Compared to what?