Subject: RE: ULE over DVB-H

From: <[email-masked]>
Date: Mon, 14 Nov 2005 13:32:38 +0200

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

As such, the original mandate to use ULE (2-way links) does not apply.
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.

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.

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

MPE-FEC was created through a design process I was not involved in.
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.

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.

Cheers, Rod.

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Georgios Gardikis
>Sent: 11 November, 2005 14:36
>To: [email-masked]
>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
>
>
>

---

From: Bernhard Collini-Nocker <[email-masked]>
Date: Mon, 14 Nov 2005 14:32:19 +0100

Hi,

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

> time slicing and MPE-FEC frames may interfere with your packing and

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.

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

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

> approach with R-S and the same framing parameters.

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

> 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

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 14 Nov 2005 14:02:19 +0000

See in-line for a few comments on the process...

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

I think the above is simply wrong:
The UNIDIRECTIONAL Lighweight Encapsulation (ULE) is just that, it works on 
1-way links.

True, there are cases where two-way links could use ULE (or any of the 
variants of MPE for the matter), but you can always use two unidirectional 
bearers to provide bi-directional connectivity.

> time slicing and MPE-FEC frames may interfere with your packing and

These are listed sections 3,4 of:
draft-ietf-ipdvb-arch-04.txt

> no viability in anycase).

That seems a reasonable summary of DVB's method of operation.

The IETF process is different, and in this case, I'd encourage experimental 
implementation of things that may be useful, along with use-cases that show 
how you envisage the usage in real networks. The WG could then see if there is 
sufficient interest in developing something. Of course, an eye to how this 
relates to the DVB activity would certainly be of value.

If you decide to look at FEC and ULE, it would also be useful to relate this 
to IETF work on transport packet-level FEC (FECFrame, for instance).

<snip>

Gorry