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