2 and in the original turbo code paper by berrou et

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: ying the choice of constituent codes that led to the recommended CCSDS turbo codes. Number and Type of Constituent Codes — Turbo codes with more than two constituent codes are feasible in principle, but to this point they have not been well studied — mainly because two-component turbo codes already perform so well. The best performing and best understood constituent codes discovered thus far are the class of recursive convolutional codes, as recommended in 7.2 and in the original turbo code paper by Berrou et al. Constraint Length — The recommended turbo code is formed from two recursive convolutional codes with constraint length K = 5. Higher constraint lengths are more complex to decode, and they seem to offer negligible performance improvement. In the other direction, constituent codes with constraint lengths less than 5 sacrifice some performance to achieve higher decoding speeds. CCSDS 130.1-G-1 Page C-2 June 2006 TM SYNCHRONIZATION AND CHANNEL CODING —SUMMARY OF CONCEPT AND RATIONALE Code Generator Polynomials — Considerable theory has been developed to guide the choice of constituent code generator polynomials. This theory is based on the transfer function bounds that are used to predict the turbo decoder error floor. The error floor can be lowered the most if the divisor polynomial (G0 in figure 7-3) is a primitive polynomial. Additional theoretical considerations guide the choice of the remaining polynomials. Code Transparency — Turbo codes are inherently non-transparent, meaning that a totally inverted codeblock cannot be an exact codeword. However, a turbo code can be made ‘approximately transparent’ except near the edges of the codeblock. It is a system design issue to decide whether an approximately transparent turbo code would be preferred, at some sacrifice of performance, to one designed without any transparency constraints. The turbo codes in the Recommended Standard (reference [3]) are not constructed to be approximately transparent. C5 PERMUTATION The (analytically) best-understood permutations for turbo codes are completely random. The best-performing permutations are manually optimized for each block size, and they also look very random. Manually optimized permutations generally outperform purely random permutations by only a small amount, except that they may significantly lower the error floor. However, such a permutation needs to be stored in ROM as a lookup table, because it is infeasible to recompute it on the fly for every codeword. The permutation in the Recommended Standard (reference [3]) can be generated on-the-fly by applying a simple rule. It also looks very random and performs nearly as well (within 0.1 dB, see figure C-2) as the manually optimized permutation. The recommended permutation gives the implementer an option to calculate the permutation on-the-fly in preference to using a look-up table. Note that a simple rectangular interleaver, such as the interleaver recommended for Reed-Solomon codes (see 5.3), is not suitable for turbo codes. The interpretation of the permutation numbers in the Recommended Standard (reference [3]) is such that the sth bit read out on line ‘in b’ (in figure 7-3) is the π(s)th bit of the input information block, as shown in figure C-3. C6 SOME SYSTEM ISSUES PERTINENT TO THE USE OF TURBO CODES Lower symbol SNR — To take advantage of the improved performance of turbo codes, the receiving system must operate at a significantly lower symbol signal-to-noise ratio (SSNR) than that of a less powerful code with the same code rate. This imposes more stringent demands on the receiver’s ability to perform symbol synchronization. The performance advantages of turbo coding may be negated if the receiver cannot lock onto the lower-SSNR symbols. Since the threshold SSNR drops in direct proportion with the code rate, whereas the threshold bit signal-to-noise ratio (BSNR) converges to a fixed limit as code rate →0 (see 3.4.2), lowering the code rate too far toward 0 produces diminishing returns in overall code performance while continuing to tax the receiver heavily. It is a systems issue to decide on the code rate that provides the best tradeoffs. For turbo codes, the variation of code performance with code rate more or less mirrors that of the ultimate limits on performance, as given in 3.4.2. CCSDS 130.1-G-1 Page C-3 June 2006 TM SYNCHRONIZATION AND CHANNEL CODING —SUMMARY OF CONCEPT AND RATIONALE Bit Error Rate (BER) and Frame Error Rate (FER) 10 iterations 10 Algorithmic -2 FER 10 10 10 10 10 FER Optimized FER -3 -4 -5 -6 BER BER BER BER -7 C opyright©- JPL, California Instite of Technology rate 1/6 10 FER rate 1/4 rate 1/3 rate 1/2 -8 -0.5 0.0 0.5 1.0 1.5 Eb/No (dB) Figure C-2: Performance Comparison for Pseudo-Random and Algorithmic Permutations ... 1st 2nd π (k)th ... ... s th π (s)th ... π(1)th ... ... bits on line "in a" (input of encoder a) k th bits on line "in b" (input of encoder b) Figure C-3:...
View Full Document

Ask a homework question - tutors are online