2
$\begingroup$

Let's say I hypothetically have a forward error correction (FEC) code with coding rate $k/n= 1/2$. Let's say it is given for now that for a fixed signal-to-noise ratio (SNR) in an additive white Gaussian noise (AWGN) channel, this hypothetical FEC has a coding gain of 3 dB, where coding gain is defined as the reduction in $E_b/N_0$ that achieves the same bit error rate (BER) as the uncoded modulation.

What would be the advantages of such a code (if any) as compared to simply halving the symbol rate to double the $E_b/N_0$? For a fixed SNR $$ \text{SNR} = \frac{P_r}{N_0 B} = \frac{E_b/T_b}{N_0 B} = \frac{E_b}{N_0} \frac{R_b}{B} = \frac{E_b}{N_0} \eta $$ where $P_r$ is the received signal power, $E_b$ is the energy per bit, $T_b$ is the bit period (in seconds), $R_b$ is the data rate (in bits per second), $N_0$ is the noise power spectral density, $B$ is the effective noise bandwidth, and $\eta = R_b/B$ is the spectral efficiency. For a scenario where the SNR is fixed, halving the spectral efficiency should double the "SNR per bit" $E_b/N_0$.

Does this mean that for a half-rate code to be "good", it would need to have a coding gain of greater than 3 dB? "Good" in this context meaning that it is better than just reducing the symbol rate by the factor $k/n$ with no coding.

By extension, does that mean that a code with code rate $k/n$ would need to have a coding gain of greater than $n/k$ to be "good"?

$\endgroup$
2
  • $\begingroup$ We use codeword error rate, or block error rate (BLER), not BER, to evaluate the performance of FEC codes. Does your question target specifically BER? Also, is the codeword length $n$ finite? Because the difference between this finite blocklength regime and the infinite counterpart, which is characterized by Shannon-liked capacity where error rates are arbitrarily small, is fundamental. $\endgroup$
    – AlexTP
    Commented Feb 19, 2022 at 9:09
  • $\begingroup$ This just doesn't fit as an answer, given how your question is worded, but the term "coding gain", when applied to forward error correction, only applies at one $E_b/N_0$. In general, especially for long codes, coding gain tends to be tremendous when noise is low, then absolutely fall off a cliff when it gets bad. There is no one coding gain. I think you're trying to answer the question "when should I use FEC, and when should I just use a lower bit rate?". If that's the case, then you need to look to Shannon's Capacity Theorem and you need to get a lot deeper into coding theory. $\endgroup$
    – TimWescott
    Commented Feb 20, 2022 at 16:39

1 Answer 1

2
$\begingroup$

Increasing the bit energy is always an option when the objective is to reduce the BER. In your example, you increase the bit energy by reducing the bit rate while keeping the power constant. In this case, the benefits are exactly equal to those obtained with a rate-1/2 code.

This is the situation described in the question. The green line is the coded system, the red line is uncoded. We require the system to operate at a BER equal to $P_d$.

enter image description here

We have two options: operate the uncoded system at 9 dB, or the coded system at 6 db. If the assumption is that the transmitted power does not change, then we can remove the code and halve the bit rate, and keep the BER at $P_d$.

Note that this is not true in general! Code gains are seldom exactly a multiple of 3 dB. In addition, even a code with a small gain (< 3 dB) can be useful, if the assumption is that the energy per bit is constant.

The whole point of coding theory is that, in many cases, coding does result in an actual gain, which is larger than that obtained by an increase in SNR effected by reducing the bit rate at constant transmit power.

It is always a trade-off, though, since nothing comes from free. I highly recommend Chapter 5 from Wozencraft and Jacobs for a very clear explanation. Sklar (1st edition), Chapter 7, Modulation and Coding Tradeoffs, is also good and approachable.

$\endgroup$
4
  • 1
    $\begingroup$ Not OP, but I would like to also see a practical example. Let's take a 16K block length rate 1/2 LDPC code, Pgs 12/13 here show the BER and code word error rates cwe.ccsds.org/sls/docs/SLS-CandS/Meeting%20Public%20Materials/… These indicate ~9dB coding gain (from BER plot), which for a 50% reduction in info rate, there is a ~4x larger gain than if we had just reduced the bitrate by half at the transmitter. Of course we have to deal with latency & added complexity, but it seems a very fair trade. Is this an accurate comparison? $\endgroup$
    – user67081
    Commented Feb 19, 2022 at 19:02
  • $\begingroup$ @user67081 A couple of things to keep in mind. Figure 1-5 in the document you linked shows the undetected word error rate, which is not equal to the BER (see comment by AlexTP). Second, it's not true in general that reducing the rate by half will net you a 3dB BER gain. The gain depends on the SNR where you measure it. In the original question, the OP assumed operating conditions where this was true, but it is not so in general. $\endgroup$
    – MBaz
    Commented Feb 19, 2022 at 20:14
  • 1
    $\begingroup$ sorry I think I referenced the wrong pages, I meant pgs11&12 (Figure1-3 BER, 1-4 word error rate). Also I should have specified my assumptions, in most systems I work with, we have a fixed average transmit power, so when I say reducing the bitrate by half I am assuming Eb is doubled. It seems like this mostly agrees with your edit though which was helpful. $\endgroup$
    – user67081
    Commented Feb 19, 2022 at 20:50
  • 1
    $\begingroup$ @user67081 Your comment makes sense. IOW, at constant transmit power, each halving of the bit rate increases your Eb/No by 3 dB. By coding, you get to keep the information rate constant, at the price of latency, complexity and bandwidth. Those are the tradeoffs. $\endgroup$
    – MBaz
    Commented Feb 19, 2022 at 21:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.