Re: Thoughts on CRC usage

2005/10/31, Gorry Fairhurst <gorry@erg.abdn.ac.uk>:

Let me pick-up this thread again -

Do you have any published (or technical data) to support your observations
about the S.2 link error properties?

Can I also make a plea for anyone else with understanding of this particular
physical layer to also come forward and comment on this topic...

Gorry

Juan Cantillo wrote:

> (This mail might appear twice in the list, since I sent it from another
> mail address... it looks like majordomo filters the senders it doesn't
> know, right?)
>
> Dear Gorry and Fausto,
>
> Gorry said:
>> >>BER performance is often hard to quantify. Does that mean that WHATEVER
>> >>distorted waveform is presented at the input to the receiver, the
> output of
>> >>the link FEC processing will result in either a BBframe being marked as
>> >>invalid, or one that has up to 10-7 errors in the forwarded frames?"
>> >>Even this is not exact, a single BBframe could (with small probability)
>> >>contain many errors - and somehow this has to be detected.
>> >>IMHO, this means we need to consider the worst-case lvele of residual
>> >>(undetected) errors that can be presented in any single BB frame.
>
> 1e-7 is the Packet Error Rate (PER). This is the probability that the
> FEC used to protect the BBFrame cannot *correct* all the erroneous bits
> in a BBFRAME. Say that 1 packet out of 10 000 000 cannot be corrected.
> One important strength of the BCH used is that he can also *detect* very
> accurately that this packet was indeed erroneous after decoding;
> theoretical estimates show that he will prove wrong only 1e-8 of the time.
> So if you ask your BCH to do error *correction + detection*, at the
> encapsulation layer, only 1e-15 of your packets will be wrong (this is
> the "small probability" Gorry refers to)!!! At 15 Mbits/s, for frames of
> length 384 Byte, this means one uncorrected packet every 6000 years more
> or less :-) That means that if you If you intend to use a CRC to correct
> link errors, it will only be activated once every 6000 years.
>
> To verify these estimations, we have been running some simulations under
> various link conditions here in Toulouse since July, full time, and as
> expected, we still have not detected a single erroneous BBFRAME on our
> platform after FEC correction + detection :-)
>
>> >>The question of retransmissions is irrelevent. The issue here is data
>> >>integrity - the probability that a corrupted block is (mis)delivered
> to and
>> >>accepted by an application.
>
> I agree with Gorry. Protecting data is the most important issue, and it
> should not depend on padding presence/absence. IMHO, the key point is
> analysing where the threats to data integrity come from: if we suppose
> that an error event is due *only* to the AWGN link, Maths and
> simulations clearly prove that CRCs could be removed. If on the other
> hand you suppose that there might be errors *other* than link ones (say,
> bit offsets due to bugs in the sofware/hardware), then making a CRC
> check can be the only way to spot them.
>
> Unfortunately, no figures nor precise measurements/litterature are
> available on that at our knowledge! If anyone has data on this
> particular issue we would gratefully appreciate it. If those became
> available you could then scale properly the length of the CRC you need,
> if that threat proves worth it.
>
> Any thoughts on this?
>
> Juan
>
>
> -----------------------------------------------------------------------
> Juan CANTILLO - SatComs PhD. Researcher
> Tel +33 6 23 54 59 65- Fax +33 5 61 61 86 88
> ENST/TeSA/ENSICA/AAS, Toulouse, FR