January 2006 doc IEEE 802 22 060017 r

January 2006 doc. : IEEE 802. 22 -06/0017 r 0 Duo-binary_Turbo-codes: questions and answers IEEE P 802. 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 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. 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 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 802. 22 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at patcom@iee. org. > Submission 1 Patrick Pirat, France Telecom

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

In general, the main advantages of doublebinary Turbo codes apply to single-binary January 2006 Turbo codes as well (i. e. , flexibility, fixed encoder/decoder pair, tail-biting). Complexity (ignoring overhead): duo-binary 8 -state decoder require 50% more comparisons info bit 802. 22 -06/0017 r 0 and more than 50% more memory doc. : per. IEEE for extrinsics than single-binary TC. Duo-binary may allow more parallelism than single-binary. LDPC can allow massive parallelism. 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. Duo-Binary input: two decoded bit output at a time – Reduction of latency and complexity per decoded bit (compared to Binary TC) Duo-binary is not expected to be better than singlebinary. It may be better than some LDPC – Better convergence implementations. Both duo-binary and single-binary TC – Circular (tail-biting) encoding implementations will tend to have the similar performance in the waterfall – No trellis termination overhead and same convergence performance with good spread interleavers. – Original interleaving scheme – Larger minimum distances With a good interleaver design, single-binary gives – Improved asymptotic performances larger distances and thus better flare performance. Best Not unique to duo-binary, should be used also for single-binary. 3 GPP standard termination technique is not recommended because it generate high BER flare. Submission As long as a good interleaver design approach is used, singlebinary will tend to give better distances, and lower flares. 3 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. Single-binary tends to give better distances because the interleaver is effectively twice as long as the. Pirat, one for duo-binary. Patrick France Telecom

January 2006 doc. : IEEE 802. 22 -06/0017 r 0 Internal Interleaver • DVB-RCS standard interleaver. Algorithmic permutation –One equation, 4 parameters (P 0, P 1, P 2, P 3) –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) Better distances have been found with dithered relative prime (DRP) Inherent parallelism interleavers which are also highly structured to save memory. 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 All these features also apply to DRP interleavers. Submission 4 Patrick Pirat, France Telecom

January 2006 doc. : IEEE 802. 22 -06/0017 r 0 Answers: complexity (1) • "Raw comparison" of 8 -state Duo-Binary TC and 8 -state binary TC (UMTS) Study case: (54 bytes, rate ½) Binary Duo-binary Ratio Gate count 13100 24100 + 80% Memory (bits) 29000 40088 + 38% Silicon area (0. 13 um) 0. 23 mm² 0. 36 mm² + 50% Decoded bit per clock cycle 1 2 + 100% Complexity per decoded bit(constant clock rate) 1 0. 78 - 22% Submission 5 Patrick Pirat, France Telecom

January 2006 doc. : IEEE 802. 22 -06/0017 r 0 Answers: complexity (2) • In a first approach, the complexity of an 8 -state duo-binary turbodecoder 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 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 Submission 6 Patrick Pirat, France Telecom

January 2006 doc. : IEEE 802. 22 -06/0017 r 0 Answers: comparison with single-binary TC • We believe that Duo-Binary TC represent the best compromise in terms of performance/complexity tradeoff(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. Submission 7 Patrick Pirat, France Telecom

January 2006 doc. : IEEE 802. 22 -06/0017 r 0 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 intracouples) • We have proposed the interleaver as defined into DVBRCT/RCS standard, but are open to discussion on other possible interleavers if they represent better alternatives Submission 8 Patrick Pirat, France Telecom

January 2006 doc. : IEEE 802. 22 -06/0017 r 0 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 Submission 9 Patrick Pirat, France Telecom

January 2006 doc. : IEEE 802. 22 -06/0017 r 0 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 Submission 10 Patrick Pirat, France Telecom

January 2006 doc. : IEEE 802. 22 -06/0017 r 0 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 Submission 11 Patrick Pirat, France Telecom

January 2006 doc. : IEEE 802. 22 -06/0017 r 0 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 Submission 12 Most of these features apply to any highly-structured Patrickapproach. Pirat, France Telecom

January 2006 doc. : IEEE 802. 22 -06/0017 r 0 Flexibility • Submission 13 The number of iterations can be adjusted for a better performancecomplexity trade-off Patrick Pirat, France Telecom

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

January 2006 doc. : IEEE 802. 22 -06/0017 r 0 Answers: performance (4) • The simulation settings used in the previous slides correspond to the ones adopted in IEEE 802. 16 e 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. 16 e specification, and not implementation results Submission 15 Patrick Pirat, France Telecom

January 2006 Aredoc. : block lengths of 16 and 18 bytes pertinent to IEEE 802. 22 -06/0017 r 0 WRAN operation? Even Vo. IP with 20 ms latency would likely produce longer blocks. Short blocksize performance Why different block size for BER and FER? Error flare barely appears. Larger block sizes need to be used to be more realistic. • Hardware measurements • Low BER (down to 10 -11) are achievable without error floor [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=1 e-3 and 1 e-4. Submission 16 Patrick Pirat, France Telecom

January 2006 doc. : IEEE 802. 22 -06/0017 r 0 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. Submission 17 Patrick Pirat, France Telecom

January 2006 doc. : IEEE 802. 22 -06/0017 r 0 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 d. B in C/N • Duo-binary TC offers 3, 5 to 4 d. B Compared to what? • When combined the gain is at least 4, 5 d. B that allows to increase the radius by 7, 6 km (17%) with QPSK modulation in a Gaussian channel. Submission 18 Patrick Pirat, France Telecom