Re: Thoughts on CRC usage

[Juan Cantillo <juan.cantillo@gmail.com>]

Dear MJ,

 

Indeed,our approach is not concerned with Fausto's proposal of a variable length of an optional CRC, that would be inserted according to padding absence/presence :-)

 

Our approach concerns a "classical" and fixed-length CRC as we have in the encapsulation layer, that we suppose implemented and running. We are concerned about the number of times it is activated in real life. Our results suggest that it could be removed *totally* under some error-pattern hypothesis, that are those of the AWGN channel. 3G or other systems may not be AWGN, but a forward link under DVBS2 is AWGN as far as we know at bit level.

 

Bets regards,

 

Juan

 

2005/10/26, Marie-Jose Montpetit <marie@mjmontpetit.com>:

This is all interesting but for me the fundamental issue is that as far
as I know, unless all your packets are fixed length (ATM cell? VOIP?
Ethernet Frames) and you are not trying some app level queue management
to increase throughput (like packing packets until a timer is set which
may or may not mean a constant number of packets) resulting in a fixed
padding at the end of each MPEG frame then, in general, padding will be
variable. How do you signal which CRC was used? And yes AWGN may not be
the right model for all DVB networks: 3G or HFC etc. could have very
different characteristics.

Maybe I'm missing something?

/mjm

> -------- Original Message --------
> Subject: Thoughts on CRC usage
> From: "Juan Cantillo" < juan.cantillo@ensica.fr>
> Date: Wed, October 26, 2005 6:01 am
> To: "IPDVB" <ipdvb@erg.abdn.ac.uk>
>
>
>
>
>
> (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 <!-- D(["mb","
> >>>accepted by an application. \r\n
>
> 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. \r\n\r\n
>
> 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. \r\n
>
> Any thoughts on this?
>
> Juan
> \r\n\r\n",0] ); D(["ce"]); D(["ms","221"] ); //-->
> >>>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