LDPC Performance vs. Number of Iterations

advertisement
Jet Propulsion Laboratory
California Institute of Technology
LDPC Performance vs. Number of Iterations
[JPL Action Item, Columbia, MD, 3/05]
K. Andrews, C. Jones, S. Dolinar, F. Pollara
Athens
April 13, 2005
April 13, 2005
LDPC Performance
JPL Proprietary Material
1
Introduction
Jet Propulsion Laboratory
California Institute of Technology
• An action item was given to JPL at the Columbia MD, USTAG
meeting(3/23/05) to determine performance of AR4A LDPC codes vs.
number of iterations for intermediate code rates (>1/2 and <7/8)
• Motivation: GSFC is building an ASIC decoder with 10 (fixed) iterations.
JPL is building an FPGA decoder with variable no. of iterations
• GSFC is investigating the cost of upgrading their decoder to higher or
variable no. of iterations
April 13, 2005
LDPC Performance
JPL Proprietary Material
2
Background
Jet Propulsion Laboratory
California Institute of Technology
• Codes are compared in power and bandwidth efficiency at BER = 10-9
• (1) JPL family of AR4A codes. Variable number of iterations.
1.00
• (2) GSFC RS-based LDPC codes [Presented at Toulouse, 11/04]. 50 iterations
fixed
BER=10-9
GSFC C2 SW
k=7K
0.95
GSFC C2 HW
k=7K
JPL HW
k=7K
0.90
10 it
0.85
0.80
(7,7/8)+(255,223)
0.75
Rate
JPL HW
k=4K
0.70
0.65
50 it
GSFC RSbased
0.60
0.55
0.50
0.45
0.0
0.5
1.0
1.5
2.0
2.5
3.0
(7,1/2)+(255,223)
April 13, 2005
LDPC Performance
3.5
4.0
4.5
5.0
Eb/No, dB
JPL Proprietary Material
3
Performance vs. Number of Iterations
Jet Propulsion Laboratory
California Institute of Technology
• JPL code performance measured at 10, 15, 20, 50 and 200 iterations fixed
• Also shown is the average number of iterations of JPL decoder
1.00
BER=10-9
GSFC C2 SW
k=7K
0.95
0.90
GSFC C2 HW k=7K
50 it 10 it
JPL HW
k=7K
AR4A
JPL HW
k=4K
0.85
12 it
ave
8.5 it
ave
5.7 it ave
0.80
(7,7/8)+(255,223)
Rate
0.75
16 it
ave
0.70
6.1 it ave
0.65
11 it
ave
0.60
20 it
ave
0.55
12 it ave
0.50
0.45
0.0
200 it
fixed
0.5
1.0
50 it
fixed
1.5
15 it fixed
20 it fixed
2.0
5.5 it ave
2.5
10 it fixed
3.0
(7,1/2)+(255,223)
April 13, 2005
LDPC Performance
3.5
4.0
4.5
5.0
Eb/No, dB
JPL Proprietary Material
4
Performance vs. Number of Iterations
Jet Propulsion Laboratory
California Institute of Technology
• Codes with the best threshold (e.g., AR4A) degrade dramatically with small no. of
iterations, for rates < 7/8
• Regular codes degrade much less
• In both cases 10 iterations fixed is a poor choice for code rates < 7/8
• A variable no. of iterations is a better choice for rates < 7/8
• The additional implementation cost for variable iterations must be compared to the
cost of performance improvement ( 1 dB ≈ $80Million )
1.00
BER=10-9
GSFC C2 SW
k=7K
0.95
GSFC C2 HW
k=7K
JPL HW
k=7K
0.90
0.85
0.80
(7,7/8)+(255,223)
0.75
Rate
JPL HW
k=4K
0.70
0.65
AR4A
GSFC?
200 it
50 it
0.60
10 it
50 it
SW GSFC
0.55
200 it
50 it
0.50
0.45
0.0
10 it
reg (3,6)
0.5
1.0
1.5
2.0
10 it
2.5
3.0
(7,1/2)+(255,223)
April 13, 2005
LDPC Performance
3.5
4.0
4.5
5.0
Eb/No, dB
JPL Proprietary Material
5
BER or FER: That is the question
Jet Propulsion Laboratory
California Institute of Technology
• JPL has made the point that codeword error rate (WER) is preferred since whole bad frames (including one or
more entire codewords) are usually discarded.
• KFC has made a valid counterpoint that WER does not tell the whole story if some parts of bad frames are
salvaged. But then KFC concludes invalidly that bit error rate (BER) is the relevant measure in this case. In fact,
however, WER continues to be a better indicator of code performance than BER even in KFC application.
• Here's an illustration. Take as an example, GSFC's code C2 operating at Eb/No = 4 dB. Here it achieves (using
JPL's stopping-rule decoder with a variable number of iterations) a WER of 7*10^{-7} and a BER of 1*10^{-8}. At
this point the ratio BER/WER is about 1.4%. If we only report to a potential user of the code that its average BER is
1*10^{-8}, this gives a completely misleading picture that there are only about 10^{8} good bits between successive
bad bits. In actuality, this decoder produces runs of about 10^{10} good bits between successive clusters of about
100 bad bits each, all residing within the same codeword.
• Quoting BER without WER gives no indication whatsoever of the burstiness of the decoder's bit errors.
• Conversely, knowing WER but not BER, one can still make a very good estimate of both the average BER and the
burstiness of the errors if the code is not operating on its error floor. Here's how, using the same example. At
Eb/No = 4 dB, the channel symbols input to the rate-7/8 decoder have a hard-decoded error rate of 1.8%. Note that
this is not significantly higher than the actual BER/WER ratio of 1.4%, which is the bit error rate after decoding within
bad codewords. In other words, on those rare codewords where the iterative decoder fails, the decoder hardly
makes any improvement on the error rate at its input.
• Thus, as long as one knows the WER, one can derive a decent estimate of average BER by bounding/estimating
the BER/WER ratio by the channel's uncoded input error rate.
• An alternative (lower) estimate of BER/WER can also be obtained by evaluating the uncoded error rate at a channel
SNR of Eb/No rather than Es/No. Generally these two uncoded error rates bracket the actual BER/WER ratio and
are sufficient to estimate it with reasonable precision.
• Summarizing, if we know the WER characteristics of a given code/decoder, then its BER characteristics can be
roughly inferred with reference only to characteristics of the channel and not to any other characteristics of
the code/decoder. That's why BER is basically a superfluous measure of code performance even in KFC’s
application.
April 13, 2005
LDPC Performance
JPL Proprietary Material
6
BER or FER: That is the question
Jet Propulsion Laboratory
California Institute of Technology
• An exception to the rule-of-thumb about bracketing the BER/WER ratio between two uncoded error rates
occurs when a code is operating on its error floor. In this case, the BER/WER ratio is much lower than either
of the benchmark uncoded error rates. However, the lowering of the BER in this case is very artificial; what's
happening is actually a flattening of the WER due to low-weight error events. The flattened WER is what
causes problems for a user of the code. Where the WER flattens out is where the length of runs of good bits
stops increasing. Never mind that the BER still continues to fall precipitously for another order of magnitude
of two. The BER is just a lagging indicator of where the error floor really starts.
April 13, 2005
LDPC Performance
JPL Proprietary Material
7
Degree of Familial Relationships
[What is a family of codes?]
Jet Propulsion Laboratory
California Institute of Technology
• The degree to which a set of codes qualifies as a “family” of codes is very difficult to
quantify.
• Basically there are two important benchmarks at the extremes.
• 1 - One could simply design separate encoders and decoders for every member of the
purported family, package them together, and call that a “single hardware
implementation”. The total amount of hardware needed for this implementation is a
sum over that needed for each individual code.
• 2 - At the other extreme, one could hope for a fully nested familial relationship for
which the maximum amount of hardware needed for any single code in the family is
sufficient to encode or decode all of the remaining codes as well.
• Thus, two suitable metrics for the degree of familial relationships among a set of
encoders or decoders are the ratios of the actual amount of hardware needed for the
“single hardware implementation” for the entire family to, respectively,
(1) the maximum amount of hardware needed for any single member of the family
and
(2) to the total amount of hardware needed for all members of the family designed
separately.
• A set of codes is deemed to be a closely knit family if the first ratio is near 1 but the
second is not.
• If both ratios are near 1, this would mean that the family is dominated by one
member, and the familial relationships would be pretty much irrelevant in this
case.
• For a code family consisting of a wide range of rates and sizes, the two
benchmarks at the extremes will be well separated, and at most one of the ratios
will be near 1.
April 13, 2005
LDPC Performance
JPL Proprietary Material
8
Download