Subject: Thoughts on CRC usage

From: "Juan Cantillo" <[email-masked]>
Date: Wed, 26 Oct 2005 12:01:50 +0200

(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

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 31 Oct 2005 21:28:33 +0000

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:
> 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 :-)
> 
> 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
> 
>