[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IP over DVB-S2 - crc usage?


Fausto Vieira wrote:
Well, my idea was that sometimes it is not possible to fill the entire BB frame with packets, either because you want to expedite the transmission of the frame or because you don't have enough bytes left to start a new packet. 

Agreed.
In these cases, I imagine that some padding would be required at the end of the BB frame. 

OK.
Instead of wasting these bytes, you could insert a CRC that should decrease the number of errors at a frame level. 

First: Can we use padding to save overhead for CRC transmission?
That was the part I did not understand, you seem to suggest the CRC's would be inserted conditionally on the padding being present - but the requirement is the same whether padding is used or not - so I'd say if the analysis shows a CRC is needed, it will be needed in all cases, and the padding is irrelevent.
It is my understanding that the standard guarantees something like 10^-7 BER. 

On the second question : How much of a CRC is needed?
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.
My question is in fact if you can live without a CRC, especially considering the problem with transport layer retransmissions with high round trip times.
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. 

Best wishes,

Gorry
Maybe I'm seeing this with incorrect assumptions, especially on the nature of errors. 
Well, this was my reasoning for the optional CRC.

Regards

Fausto

Gorry Fairhurst wrote:


Fausto,

I'm trying to understand the main outstanding issues.
I agree there are a set of DVB-S.2 BB header fields that may be re-used to 
carry the protocol control information for the encapsulation layer. This
seems like the correct way to go. Many BB header fields are not defined/used for the Generic Mode, but I don't yet know (maybe others are wiser) exactly which fields may be safely (re)used and for a S.2 generic encapsulation and 
still remain compatible the DVB-S.2 spec.  This is probably an area that
needs to be cleared with the DVB S.2 group.

My main query relates to your comment about the optional CRC fields. I'm
puzzled by your suggestion that requirements for CRC usage may be related to 
the presence of padding in the BB frame.  My thoughts were that the CRC
requirement stemmed from:

   (i) The need to verify the integrity of the payload (PDU) before
   passing to the IP layer - to mitigate the impact of link errors
   and low level errors in data movement.

   (ii) To verify the framing (length) of PDUs - ensuring the next
   SNDU header was correctly located within the BB frame payload.

   (iii) To verify the integrity of reassembled SNDUs.

   (iv) To allow a receiver to monitor the quality of the
   received bitstream.

- I can see how (i) relates to worst case expected link error
characteristics, but don't see yet how this can be related to the presence 
or absence of padding bytes.

Thoughts?

Gorry