RE: ULE over DVB-H

["Allison, Art" <AAllison@nab.org>]

The content just got to heavy for the old name......
	Groan.
		Stagger...
Smile, 
Art	 

-----Original Message-----
From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On
Behalf Of Gorry Fairhurst
Sent: Monday, November 14, 2005 1:44 PM
To: ipdvb@erg.abdn.ac.uk
Subject: Re: ULE over DVB-H


Seems reasonable, but ULE was UNIDIRECTIONAL Lightweight Encapsulation,
you missed the name change a long time ago :-)

Gorry

Marie-Jose Montpetit wrote:

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