Re: ULE over DVB-H

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

Hi,

Rod.Walsh@nokia.com wrote:
> Hi All
> 
> DVB-H is (like DVB-T) specifically intended to be a unidirectional
> system with any ancillary point-to-point data occurring over IP (and
> none-MPEG2) bearers (i.e. GPRS and friends).

Well said, although I am not sure that it is equally well understood by
all the mobile operators.

> As such, the original mandate to use ULE (2-way links) does not apply.

ULE stands for "Unidirectional Lightweight Encapsulation". Did I
misunderstand something.

> So please, please, please check the ULE design assumptions. E.g. the
> time slicing and MPE-FEC frames may interfere with your packing and
> timing assumptions.

I hvae pointed out my concerns about this possible interference as well,
but was addressing more the implementation issue. Operationally also for
DVB-H ULE (especially in case of IPv6, which seems to be condidate
protocol and IP-multicast [video streaming] as killer app) is very well
suited. ULE could even assist in cases where MPE completely fails, such
as availability of NPA (MAC) addresses of transmit gateways in
multi-service environments and SSM multicast.

> Also, the DVB-H and ULE design assumptions because the intended
> applications - hence I feel it has no bearing on the viability of ULE
> whether it is every used over DVB-H. conversely, use over 2-way DVB-S
> links seems to be essential to prove ULE's viability.

Again, I do not get the point. ULE was never ever solely intended for
2-way links. Actually 2-way DVB links are just one possible scenario.

> DVB operates on a process of commercial requirements -> technical
> requirements -> technical proposals and specifications -> technical
> standards and guidelines. A commercial requirement within DVB-CM
> demonstrating the need for something other-than-MPE would be needed for
> ULE to be viable over DVB-H. (Assuming, you share my opinion that
> without DVB and thus ETSI adoption of a DVB-H bearer technology, it has
> no viability in anycase).

That is very true. However, commercial requirements are driven by
commercial aspects. If someone in the commercial module of DVB finds out
that ULE saves money (less overhead) and adds extra functionality (more
services) it is quite likely that ULE is being requested.
Who knows that someone in the CM?

> MPE-FEC was created through a design process I was not involved in.

Me neither, would have loved to be.

> However it would be prudent to try and get an understanding of it's
> design selections and assumptions if you were to attempt a ULE-FEC. For
> academic purposes it would be interesting to merely copy the MPE-FEC
> approach with R-S and the same framing parameters.

As mentioned above, it is academic interest driven by economic and
technical considerations.

> For the "delta-t", I came to the conclusion that (c) a header extension
> would be the best approach (a few years ago when I was curious about the
> feasibility of ULE for DVB-H - another lifetime :)

> I think it would be interesting to check the feasibility of ULE over
> DVB-H, but am not currently optimistic about it's uptake potential.

I was as optimitistic about ULE over DVB-S, and was terribly surprised
about the feedback even from DVB-RCS.

> Cheers, Rod.

A bientot,
Bernhard


> 
> 
>>-----Original Message-----
>>From: owner-ipdvb@erg.abdn.ac.uk 
>>[mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of ext Georgios Gardikis
>>Sent: 11 November, 2005 14:36
>>To: ipdvb@erg.abdn.ac.uk
>>Subject: ULE over DVB-H
>>
>>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
>>
>>
>>
> 
>