Looking for an FEC coding scheme with variable coding bits

Background:
I am currently writing a lossy LPC source coder for real time transmission
over a wireless channel. This coder produces a stream with a fixed AVERAGE
bit rate (that means it varies around that rate). To keep the MOMENTARY bit
rate within certain limits, I reduce quality when the bit rate gets too
high and I INSERT USELESS BITS, WHEN IT GETS TOO LOW (hint: this was the
important part :). This way I can keep the overall bit rate within limits
all the time.
Now this stream is to be transmitted over a wireless simplex channel
(meaning I don't get any feedback from the receiver). Thus I have to add
forward error correction (FEC) bits to my stream.
So far so good.

Problem / Idea:
The idea is to use the bits I add in order to keep the lower bit rate
limit for forward error correction - instead of just adding nonsense. The
problem is, that the number of bits that are added is not constant.

Question(s):
Does anyone know of an FEC coding scheme that can cope with a varying
number of correction bits?

Or can anyone propose a scheme?
Something like:
- for one bit, make it the checksum of the next two bits
- for 2 bits, make it an FEC code for the next two bits
- for 3 bits, make it an FEC code for the next three and so on...

Any help, idea or suggestion is highly appreciated!

Thx in advance

Markus

dudelmann wrote:

> Background:
> I am currently writing a lossy LPC source coder for real time transmission
> over a wireless channel. This coder produces a stream with a fixed AVERAGE
> bit rate (that means it varies around that rate). To keep the MOMENTARY bit
> rate within certain limits, I reduce quality when the bit rate gets too
> high and I INSERT USELESS BITS, WHEN IT GETS TOO LOW

Why can't you just shut the transmitter down when there is nothing to 
transmit?

> (hint: this was the
> important part :). This way I can keep the overall bit rate within limits
> all the time.

Qualcomm employed variable bitrate codec (QCELP) in CDMA IS-95 standard. 
That provided for statistical multiplexing of the channel and some 
battery savings as well.

> Now this stream is to be transmitted over a wireless simplex channel
> (meaning I don't get any feedback from the receiver). Thus I have to add
> forward error correction (FEC) bits to my stream.
> So far so good.
> 
> Problem / Idea:
> The idea is to use the bits I add in order to keep the lower bit rate
> limit for forward error correction - instead of just adding nonsense. The
> problem is, that the number of bits that are added is not constant.

This is likely to be inefficient as the low bitrate parts are 
perceptually unimportant. There is little advantage in adding better 
protection to the unimportant data.

> Question(s):
> Does anyone know of an FEC coding scheme that can cope with a varying
> number of correction bits?
> Or can anyone propose a scheme?

Quick and dirty solution could be punctured convolutional code with the 
variable amount of puncturing.

> Something like:
> - for one bit, make it the checksum of the next two bits
> - for 2 bits, make it an FEC code for the next two bits
> - for 3 bits, make it an FEC code for the next three and so on...

Depending on the bit rate, you have several different bit layouts of the 
vocoder frame. Develop the encoding scheme for each layout.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

>Why can't you just shut the transmitter down when there is nothing to 
>transmit?

Usually this is just one, two or three bits in the middle of a lot of
data.

>> Now this stream is to be transmitted over a wireless simplex channel
>> (meaning I don't get any feedback from the receiver). Thus I have to
add
>> forward error correction (FEC) bits to my stream.
>> So far so good.
>> 
>> Problem / Idea:
>> The idea is to use the bits I add in order to keep the lower bit rate
>> limit for forward error correction - instead of just adding nonsense.
The
>> problem is, that the number of bits that are added is not constant.
>
>This is likely to be inefficient as the low bitrate parts are 
>perceptually unimportant. There is little advantage in adding better 
>protection to the unimportant data.

not quite true. i apply (modified) rice coding and the stream is not block
based - it works on a sample by sample basis. if a bit drops, the coder an
decoder might get out of step and thus create a total desaster.

>> Question(s):
>> Does anyone know of an FEC coding scheme that can cope with a varying
>> number of correction bits?
>> Or can anyone propose a scheme?
>
>Quick and dirty solution could be punctured convolutional code with the 
>variable amount of puncturing.

good idea, thanks I will have a look at it.

>> Something like:
>> - for one bit, make it the checksum of the next two bits
>> - for 2 bits, make it an FEC code for the next two bits
>> - for 3 bits, make it an FEC code for the next three and so on...
>
>Depending on the bit rate, you have several different bit layouts of the

>vocoder frame. Develop the encoding scheme for each layout.

Currently i don't have frames. i operate on a per sample basis. if I had
frames, things would be easier i admit, but this also increases overall
delay.

>Vladimir Vassilevsky
>DSP and Mixed Signal Design Consultant
>http://www.abvolt.com
>

On 11/9/2009 8:18 AM, dudelmann wrote:
>> Why can't you just shut the transmitter down when there is nothing to
>> transmit?
>
> Usually this is just one, two or three bits in the middle of a lot of
> data.
>
>>> Now this stream is to be transmitted over a wireless simplex channel
>>> (meaning I don't get any feedback from the receiver). Thus I have to
> add
>>> forward error correction (FEC) bits to my stream.
>>> So far so good.
>>>
>>> Problem / Idea:
>>> The idea is to use the bits I add in order to keep the lower bit rate
>>> limit for forward error correction - instead of just adding nonsense.
> The
>>> problem is, that the number of bits that are added is not constant.
>> This is likely to be inefficient as the low bitrate parts are
>> perceptually unimportant. There is little advantage in adding better
>> protection to the unimportant data.
>
> not quite true. i apply (modified) rice coding and the stream is not block
> based - it works on a sample by sample basis. if a bit drops, the coder an
> decoder might get out of step and thus create a total desaster.

This is important to accommodate, as bit slips do happen in practical 
systems, especially during a deep fade event.

>>> Question(s):
>>> Does anyone know of an FEC coding scheme that can cope with a varying
>>> number of correction bits?
>>> Or can anyone propose a scheme?
>> Quick and dirty solution could be punctured convolutional code with the
>> variable amount of puncturing.
>
> good idea, thanks I will have a look at it.

I was going to suggest some simple code rate adaptation schemes, and 
varying the puncturing on a convolutional code is one of them. 
Regardless of what you do, however, you need to include some sort of 
signalling scheme so that the decoder knows what to do with the incoming 
stream, i.e., where the adaptation points are and what changed.

>>> Something like:
>>> - for one bit, make it the checksum of the next two bits
>>> - for 2 bits, make it an FEC code for the next two bits
>>> - for 3 bits, make it an FEC code for the next three and so on...
>> Depending on the bit rate, you have several different bit layouts of the
>
>> vocoder frame. Develop the encoding scheme for each layout.
>
> Currently i don't have frames. i operate on a per sample basis. if I had
> frames, things would be easier i admit, but this also increases overall
> delay.

The delay for framing (or some sort of configuration signalling) is one 
of the prices you pay for being to implement adaptation.  Somehow you 
need to convey the coding scheme and relevant changes due to adaptation 
to the demodulator.   Usually this means a framing scheme, since it's 
ultimately a pretty efficient way to do it. FWIW, framing will also help 
to mitigate your catastrophic bit-slip problem, since detecting the 
framing will limit the scope of a bit-slip event.

-- 
Eric Jacobsen
Minister of Algorithms
Abineau Communications
http://www.abineau.com

Hi

thanks for all the helpful answers so far.

Concerning the framing:
In a bit error free scenario the codec does not need framing since all
adaptive coefficients are updated depending on the already received data.
Now I know of course that in practice I will have to send the coefficients
from time to time since there will be errors and I also don't know when the
receiver is going to start decoding. in other words: I am planning to have
some sort of framing and also some sort of FEC in these frames.

My idea was to additionally use the fill-up bits for FEC. But maybe it is
wiser to merely add FEC after my codec and use the fill-up bits for
additional data - like config, or names or time or whatever

dudelmann wrote:
> Hi
> 
> thanks for all the helpful answers so far.
> 
> Concerning the framing:
> In a bit error free scenario the codec does not need framing since all
> adaptive coefficients are updated depending on the already received data.

This approach is considerably less efficient then sending the 
coefficients upfront, because the coefficient update is based on the 
synthetic data from the past.

> Now I know of course that in practice I will have to send the coefficients
> from time to time since there will be errors

You don't have to. Properly designed algorithm can recover by itself.

> and I also don't know when the receiver is going to start decoding.

You don't have to. Properly designed algorithm can resync by itself.

> in other words: I am planning to have
> some sort of framing and also some sort of FEC in these frames.
> My idea was to additionally use the fill-up bits for FEC. But maybe it is
> wiser to merely add FEC after my codec and use the fill-up bits for
> additional data - like config, or names or time or whatever

There you go. But why reinventing wheels in the first time?


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com