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

Re: IP over DVB-S2 - crc usage?

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

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





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