[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ULE over DVB-H
See in-line for a few comments on the process...
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).
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.
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.
These are listed sections 3,4 of:
draft-ietf-ipdvb-arch-04.txt
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).
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