(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