Subject: ULE over DVB-H

From: Georgios Gardikis <[email-masked]>
Date: Fri, 11 Nov 2005 14:36:24 +0200

Dear all,

Regarding ULE, I think it is important for its viability to study the 
issue of its migration to DVB-H. It is unfortunately true that ULE 
cannot be applied to DVB-H ploatforms "as-is", because:

i) DVB-H "steals" four bytes from MAC address field of MPE to use in 
time slicing signalling. These bytes convey the "delta-t" time i.e. the 
time interval until the next burst containing data from the same stream. 
Of course the whole process is a hack, and stems from the fact that DVB 
recognised that the MAC bytes are almost never used for what they were 
initially designed to.
Possible solutions: a) using the NPA field in ULE (and destroy its 
initial purpose, i.e. hack ULE itself), b) adding extra bytes in DVB-H 
header (i.e. altering the candidate standard), c) using and 
standardizing an extension header

ii) DVB-H uses the "MPE-FEC" structure, which is built upon MPE, and 
uses the table_id (first byte in MPE header) to discriminate between 
data bytes and FEC overhead bytes.
Possible solution: directly port ULE to carry FEC frames (no action 
needed) and use of a new Typefield value to declare FEC data.

What do you think?

G.Gardikis
-------
Dr. Georgios J. Gardikis
Associate Researcher
NCSR "Demokritos", Institute of Informatics and Telecommunications
Athens 153 10, Greece
Tel: +30 210 650 3108
Fax: +30 210 653 2175

---

From: Bernhard Collini-Nocker <[email-masked]>
Date: Fri, 11 Nov 2005 14:55:24 +0100

Dear Georgios,

it is indeed fascinating to investigate ULE over DVB-H, especially in
the case of IPv6/ULE/DVB-H.

> standardizing an extension header

I vote for a new extension header rather than hacking :-)

> needed) and use of a new Typefield value to declare FEC data.

That sounds reasonable and seems straight-forward to be implemented.
In my opinion one more option could be to treat data+FEC as special kind
of SNDU in which case another type value (data+FEC) might be
appropriate. However, that would make the CRC being calculated over the
whole data+FEC, and FEC recovery would start even if only FEC is
corrupted. Again an extension header might be necessary to describe the
type of FEC?
Yet another option would be to send data and FEC in different IP packets
and do the recovery on top of IP. But that changes the semantics of the
current FEC mode completely.

> What do you think?

I see a generic problem with ULE and DVB-H related to the implicit
packing of ULE, which is a little more tricky to implement following the
current ULE spec where packing timeout would interfere with time slicing.

> G.Gardikis

Kind regards,
Bernhard

---

From: Georgios Gardikis <[email-masked]>
Date: Mon, 14 Nov 2005 15:26:25 +0200

>current FEC mode completely.
No, don't worry. The second option is exactly what DVB-H does. Data and 
FEC are transmitted separately, so that the system is backwards 
compatible. A FEC-ignorant receiver just decapsulates the datagram and 
discards the FEC bytes (which are transmitted in separate SNDUs). So, 
CRC is calculated over the data bytes and over the RS overhead 
seperately. No problem on that.

But unfortunately, I forgot something: DVB-H also uses the 
section_number and last_section_number of the MPE header. Seems like DVB 
decided to revive all unused fields of MPE! Prior to calculating the 
FEC, a bunch of incoming IP datagrams are organized in a two-dimensional 
array, over each row of which the R-S is calculated. These two one-byte 
fields of MPE show the position which the encapsulated datagram has 
within this array. It is essential for proper FEC decoding.
So, this issue also has to be solved for ULE (maybe with an extension 
header again, it just has to be incorporated in ULE).

>current ULE spec where packing timeout would interfere with time slicing.

Indeed. Time slicing is very tricky itself, not mentioning its possible 
conflict with packing timeout. It has nothing to do with traditional TDM 
with time slots, since both burst length and inter-burst time can be 
altered on a per-burst basis. In order to make an efficient bandwidth 
management and not throw capacity away (by transmitting empty bursts), 
you need a rather smart and adaptive algorithm at the encapsulator. If 
you decide to use ULE packing simultaneously, things become even more 
complicated. That's an interesting research field, though.

G.Gardikis