This preview shows page 1. Sign up to view the full content.
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 ) 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 ) 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 )
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
- Spring '14