DSPRelated.com
Forums

channel coding gain

Started by kbc April 14, 2004
On Thu, 15 Apr 2004 10:06:03 -0400, Jerry Avins <jya@ieee.org> wrote:

>Vikram Chandrasekhar wrote: >> Hello >> >> Here is my take on it. The Shannon capacity for a AWGN channel is >> defined by >> C=W*log(1+P/(N0*W)). One can see that we get a linear increase in >> capacity with coding, but only a logarithmic increase with increase in >> P. >> >> So what a code does to reach close to capacity is simple. The addition >> of an (n,k) code implies that the bandwidth has increased by a factor >> of (n/k). However, the transmit power P is unchanged since the energy >> per bit has decreased by a factor of (n/k), while the transmit rate >> has increased by a factor of (n/k). So the transmit power is >> unchanged. The increase in W implies that the effective SNR has >> decreased but the linear increase in W outside the bracket overcomes >> this effect. The net result is an increase in capacity with bandwidth >> expansion, which is effectively the outcome of inserting a channel >> code. >> >> such codes is only true coding gain. the coding gain definition, apart >> >>>>from "same ber" should also include "same bandwidth". only then we >>>>would know how far are we from shannon's limit. >> >> >> This statement is not correct. Coding=>bandwidth expansion. One >> achieves performance improvement (BER) using a higher bandwidth. The >> improvement achieved using bandwidth expansion is measured by the >> coding gain which is the difference between the Eb/No values with and >> without coding for a given probability of error. This implies that one >> can potentially achieve a given BER at a lower Eb/No by employing >> higher bandwidth transmission. >> >> Thanks >> Vikram > > ... > >But after coding, one can return to the former bandwidth by reducing the >data rate. (This has the effect of keeping the energy per bit constant >if the transmitted power is unchanged.) With suitable coding, there is >an increase in "bits made good" despite the lower data-bit rate. We see >this in practice with modems at fixed-bandwidth land lines. Especially >when the lines are noisy, error correction reduces the data-bit rate >(because some data bits are replaced by ECC bits), put throughput rises. > >Jerry >-- >Engineering is the art of making what you want from things you can get.
Yes, Jerry has some insight here that I think some others may be missing (why am I not surprised?)... ;) The idea of using Eb/No as a metric is to normalize the required power so that performance can be isolated with respect to power efficiency. Any curves showing BER vs Eb/No are pretty much power efficiency curves, as they say nothing about the bandwidth efficiency of the underlying system. If one wants to balance power efficiency and bandwidth efficiency, then additional comparisons are needed (e.g., BER vs SNR). So coding gain shown on BER vs Eb/No curves show how output power can be used most efficiently to transmit data reliably. A system that does worse may have given up power for other tasks (e.g., pilots for synchronization, whatever), but bandwidth is assumed to be a non-concern or compared some other way. If output power is cheap and not regulated, but spectrum is scarce, then one really doesn't care about BER vs Eb/No and the worry is about spectral efficiency instead. Capacity curves can be translated either way, and the best balance of power and bandwidth efficiency can be seen on plots of the so-called bandwidth-efficiency plane, where bps/Hz is typically shown on the vertical axis, and SNR on the horizontal. Operating points for various schemes can be plotted at some given BER or PER, and whichever is closest to capacity (which is an arc on such a plot) is arguably the most efficient (not considering other cost metrics, like cost). But to get back to the question at hand, coding is typically applied for power efficiency reasons, so comparing codes on BER vs Eb/No plots is usually very appropriate. The idea of "coding gain" then is exactly as Jerry has been gently alluding: It takes less power to get the same bit through reliably with more coding gain. The difference in power required to transmit a bit with a given reliability between the uncoded (i.e., matched filter bound) and coded case is properly called "coding gain". Just like antenna gain allows one to back off the required transmit power for the same reliability, so does coding gain. It really is that simple. Historically Power Amplifiers have represented a large part of both the cost and power consumption of wireless systems, so anything that can be done cheaply and practically to reduce the size of the PA is worthwhile. Coding is a good way to do that. Eric Jacobsen Minister of Algorithms, Intel Corp. My opinions may not be Intel's opinions. http://www.ericjacobsen.org
Jerry Avins <jya@ieee.org> wrote in message news:<407d5241$0$2776$61fed72c@news.rcn.com>...
> kbc wrote: > > > Hi > > > > After channel coding , why do we get coding gain ? > > > > To elaborate - After coding, the energy per bit is less and hence > > Oh? How so? >
Assuming that I dont change the transmit power after doing channel-coding. ( More bits are transmitted with same power. )
kbc wrote:

> Jerry Avins <jya@ieee.org> wrote in message news:<407d5241$0$2776$61fed72c@news.rcn.com>... > >>kbc wrote: >> >> >>>Hi >>> >>> After channel coding , why do we get coding gain ? >>> >>>To elaborate - After coding, the energy per bit is less and hence >> >>Oh? How so? >> > > > Assuming that I dont change the transmit power after doing channel-coding. > ( More bits are transmitted with same power. )
Some of those are redundant. What about energy per infobit? Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
Jerry Avins <jya@ieee.org> wrote in message news:<407e96d3$0$16471
> > But after coding, one can return to the former bandwidth by reducing the > data rate. (This has the effect of keeping the energy per bit constant > if the transmitted power is unchanged.) With suitable coding, there is > an increase in "bits made good" despite the lower data-bit rate. We see > this in practice with modems at fixed-bandwidth land lines. Especially > when the lines are noisy, error correction reduces the data-bit rate > (because some data bits are replaced by ECC bits), put throughput rises. > > Jerry
Are you talking here about schemes such as puncturing ? Note that puncturing does not throw away all the redundant bits and thus you cannot return to the former bandwidth. I am not aware of any scheme where you can use the same bandwidth after coding. Can you explain ? On the other hand, if i can reduce message data-rate, I would do that and thereby increase energy per bit ( at same power. ) I will not do coding at all.
kbc wrote:
> Jerry Avins <jya@ieee.org> wrote in message news:<407e96d3$0$16471 > >>But after coding, one can return to the former bandwidth by reducing the >>data rate. (This has the effect of keeping the energy per bit constant >>if the transmitted power is unchanged.) With suitable coding, there is >>an increase in "bits made good" despite the lower data-bit rate. We see >>this in practice with modems at fixed-bandwidth land lines. Especially >>when the lines are noisy, error correction reduces the data-bit rate >>(because some data bits are replaced by ECC bits), put throughput rises. >> >>Jerry > > > > Are you talking here about schemes such as puncturing ? > Note that puncturing does not throw away all the redundant bits and > thus > you cannot return to the former bandwidth. > I am not aware of any scheme where you can use the same bandwidth > after > coding. Can you explain ? > > On the other hand, if i can reduce message data-rate, I would do that > and thereby increase energy per bit ( at same power. ) I will not do > coding at all.
I'm not that clever. Redundant bits permit error recovery. Somewhere along the line, it was said that that increased bandwidth. I meant only to point one that one could keep the original bandwidth by keeping the original bit rate. That necessarily reduces the data rate, but under many path conditions, it increases the throughput nonetheless. Assuming that the transmitter power remains unchanged, the energy per bit does also, but the energy per data bit decreases. (Not all bits are data bits.) With increased throughput, the energy per received valid data bit can decrease even more. (The energy in fewer invalid bits is discarded.) \ Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
The point made by plots showing coding gain is that there are error
correcting codes available that have enough gain that they much more
than overcome the "loss" associated with transmitting the redundant
bits.   One can recover the "loss" by eliminating the coding overhead,
but the system will be less efficient.

Forward Error Correction is used because there are many code
availabble for which this tradeoff is heavily lopsided toward use of
the code.  In the last ten years we've had a number of codes developed
which let us approach the Shannon capacity, and that's a far cry from
the matched filter bound.

Cheers,

Eric


On Sat, 17 Apr 2004 21:29:32 -0400, Jerry Avins <jya@ieee.org> wrote:

>kbc wrote: >> Jerry Avins <jya@ieee.org> wrote in message news:<407e96d3$0$16471 >> >>>But after coding, one can return to the former bandwidth by reducing the >>>data rate. (This has the effect of keeping the energy per bit constant >>>if the transmitted power is unchanged.) With suitable coding, there is >>>an increase in "bits made good" despite the lower data-bit rate. We see >>>this in practice with modems at fixed-bandwidth land lines. Especially >>>when the lines are noisy, error correction reduces the data-bit rate >>>(because some data bits are replaced by ECC bits), put throughput rises. >>> >>>Jerry >> >> >> >> Are you talking here about schemes such as puncturing ? >> Note that puncturing does not throw away all the redundant bits and >> thus >> you cannot return to the former bandwidth. >> I am not aware of any scheme where you can use the same bandwidth >> after >> coding. Can you explain ? >> >> On the other hand, if i can reduce message data-rate, I would do that >> and thereby increase energy per bit ( at same power. ) I will not do >> coding at all. > >I'm not that clever. Redundant bits permit error recovery. Somewhere >along the line, it was said that that increased bandwidth. I meant only >to point one that one could keep the original bandwidth by keeping the >original bit rate. That necessarily reduces the data rate, but under >many path conditions, it increases the throughput nonetheless. Assuming >that the transmitter power remains unchanged, the energy per bit does >also, but the energy per data bit decreases. (Not all bits are data >bits.) With increased throughput, the energy per received valid data bit >can decrease even more. (The energy in fewer invalid bits is discarded.) >\ >Jerry >-- >Engineering is the art of making what you want from things you can get. >&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295; >
Eric Jacobsen Minister of Algorithms, Intel Corp. My opinions may not be Intel's opinions. http://www.ericjacobsen.org
Eric Jacobsen wrote:

> The point made by plots showing coding gain is that there are error > correcting codes available that have enough gain that they much more > than overcome the "loss" associated with transmitting the redundant > bits. One can recover the "loss" by eliminating the coding overhead, > but the system will be less efficient.
That's what I've been, in my awkward way, trying to get across.
> Forward Error Correction is used because there are many code > availabble for which this tradeoff is heavily lopsided toward use of > the code. In the last ten years we've had a number of codes developed > which let us approach the Shannon capacity, and that's a far cry from > the matched filter bound.
Now we're into detail that (happily for me) I don't need to deal with. ... Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
eric.jacobsen@delete.ieee.org (Eric Jacobsen) wrote in message news:<40825e99.68524343@news.west.earthlink.net>...
> The point made by plots showing coding gain is that there are error > correcting codes available that have enough gain that they much more > than overcome the "loss" associated with transmitting the redundant > bits. One can recover the "loss" by eliminating the coding overhead, > but the system will be less efficient. > > Forward Error Correction is used because there are many code > availabble for which this tradeoff is heavily lopsided toward use of > the code. In the last ten years we've had a number of codes developed > which let us approach the Shannon capacity, and that's a far cry from > the matched filter bound. > > Cheers, > > Eric >
My question is a follow-up to the old thread asking whether matched filter improves with longer pulse ( keeping energy of pulse same ). The answer turned out to be "yes" ( Refer kailath's paper I had provided link to ). I felt that the coding gain is also a consequence of the same property. ( I have understood that the answer to questions like these whose answer lies hidden in come complicated equations cannot be obtained through a newsgroup. ) A newsgroup is more of a place to get answers to implementation issues.
kbc wrote:
> ... A newsgroup is more of a place to get answers to > implementation issues.
A newsgroup is in some respects similar to patent medicines and universal nostrums: "Good for what ails you." Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;