(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