Re: ULE over DVB-H

[Bernhard Collini-Nocker <bnocker@cosy.sbg.ac.at>]

Dear Georgios,

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

Georgios Gardikis wrote:
> 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

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

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

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

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