RE: ULE over DVB-H

[Marie-Jose Montpetit <marie@mjmontpetit.com>]

In our ESA study of 2 years ago we did simulate ULE for 2-way but it was
not the intended usage. I think it was understood that it was one-way or
the return channel would use something else in general.

On acceptance I think that before someone in industry (and a consortium
of major players in this case because of the scope of DVB-H) really
thinks ULE work better it will may be hard to push. Bandwidth savings
is one selling point but how much depends as you know on traffic
profiles and service scenarios.  IPv6 is still not a given. Multicast
maybe as IPTV needs it. We need to have someone (but who?) do a real
commercial viability assessment. Also the cost of redoing firmware may
kill all other benefits and should be looked at.

What was RCS's feedback?

BTW I thought ULE was "Ultra light Encapsulation" but I may have been
wrong all the time ;-)

/mjm

> -------- Original Message --------
> Subject: Re: ULE over DVB-H
> From: Bernhard Collini-Nocker <bnocker@cosy.sbg.ac.at>
> Date: Mon, November 14, 2005 8:32 am
> To: ipdvb@erg.abdn.ac.uk
>
> 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
> >>
> >>
> >>
> >
> >