Subject: Re: IP over DVB-S2 - crc usage?

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 16 Oct 2005 15:29:16 +0100

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

---

From: Fausto Vieira <[email-masked]>
Date: Mon, 17 Oct 2005 15:20:35 +0200

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. In these cases, I imagine that some padding would be 
required at the end of the BB frame. Instead of wasting these bytes, you 
could insert a CRC that should decrease the number of errors at a frame 
level. It is my understanding that the standard guarantees something 
like 10^-7 BER.
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.

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

-- 
Fausto Vieira
Researcher
Dpt. Telecomunicació i d'Enginyeria de Sistemes
ETSE - UNIVERSITAT AUTÒNOMA DE BARCELONA
Campus Universitari, s/n
08193 Bellatera Barcelona SPAIN
Phone :(34) 935813843
Fax   :(34) 935814031

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 24 Oct 2005 14:19:21 +0100

Fausto Vieira wrote:

> 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 
> 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.

> considering the problem with transport layer retransmissions with high 

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