Remarks concerning IP-over-DVB

[Torsten.Jaekel@FTK.rohde-schwarz.com]

Dear all,

Actually I watch and usually I read all the emails from this reflector.
Unfortunately I am so busy or often not in the office.
Therefore I am not able to answer immediately. I applogize that I am still so
quite here in this group.

Therefore I would like "take" the buck to put across some thoughts, remarks and
questions according to the
topic of this group.

1. In order to make IP-over-DVB more efficient I still believe that the approach
"MPLS" could work:
     Imagine we transmit each IP connection in a dedicated DVB sub-channel,
given by the PID, we could
     drop the IP headers. We have an unambiguous mappimng between IP and PID.
The PID acts as our
     label. On the receiving side (the engress of our "DVB-MPLS cloud") we
recreate the IP header.
     Think, saves a lot of recources (the complete header).
     Works just in case single IP in a dedicated PID. Often we transmitt many IP
connections in one PID (or all
     in a single PID). Here we could compress headers but not remove. We still
need the IP addresses as
     sub-labels inside PID-channels.

2. In order to have routing function (we are working on our MediaRouter) we need
this mapping between IP
    and PIDs. Problem here, you have to use a free PID and create a new one (if
you insert behind a
    multiplexer). Perhaps it is necessary to read the SI tables to know which
PID is in use and which could be
    use (to modify the tables to signal where is the data stream/IP is not a big
deal).
    When the tables are connected with the routing engine it is guaranteed that
you can change the PID for
    your TV program (new PID) and this is not disturb by the inserted data.
    But: how flexible could be this ? Could you change and use a new PID
on-the-fly ? Does the receiver is
    able to find the new PID to have an uninterrupted data flow ?

3. Next problem: Everything in such a MPEG network is fixed, means the PIDs are
setup permantently.
    And just the system designer knows exactly which bandwidth is used by which
PID for which service.
    How we could define an interface to have access to such a DVB/MPEG network ?
Means: how I can
    allocate a channel, with bandwidth for a limited time period (similar to
Call Setup and Release in telephone
    networks or Resource Reservation Protocols). As far as I know there is no
approach fopr such functions.
    In DAB systems (Digital Sound Broadcasting) we have the STI interface which
support such functions in
    a very flexible way. The service provider can manage his assigned resoruces,
remotely and automated.

4. Question: Should all this work here (a more efficient IP-over-MPEG) consider
to have a mixed TV and data
    system ? Means: We have to share the "wires" with ongoing running TV
programs ? Or is the approach
    to use an entire transport stream just for data (pure data transmission) ?
    Next question: How important is interoperability, with exiting receivers and
decoders and with transport stream
    devices ? Imagine that there is a MPEG-2 infrastructure using MPEG-2 routers
operating on SI tables, PIDs
    etc. Has this still be working ?

5. One remark was to use an ATM-like approach. Why not (know a bit ATM), and I
think the satellite guys are doing
     this already. But MPLS is also based on ATM, therefore again MPLS. Instead
of the ATM header (not so complex
     as IP but still needed to be scanned and parsed) we can use again the PID
as label.
     But an approach like: IP-over-ATM, ATM-over-MPEG is not efficient. ATM does
not support service reliability without
     higher layers (error handling, flow control). The quality of service aspect
(QoS) which we know from ATM comes from
     the very small cells. In MPEG-2 we have larger "cells", the 188 byte
packets. To put ATM on it does not make the
     "cells" smaller.
     To support different service especially CBR (constand bit rate, for
streaming media), VBR (for real-time service)
      and ABR (available bit rate for email, file transfer) is needed. But flow
control for CBR works just with very small cells.
      Problem: how to perform traffic shaping with "MPEG-cells" (the 188 byte
blocks) ? If we add latency and jitter we
      influence dramatically the running TV programs. Works just in a pure data
environment (no PCRs, Program Clock
      References used and needed inside MPEG-2 streams) but not so efficient
like ATM due to the larger units.

6. If we want make IP-via-MPEG more efficient it does not makes sense to drop
just the DSM-CC overhead. We save a
    few bytes but another large wasted bandwidth is within the SI tables. Short
tables are filled with stuffing due to the 188 byte
    borders. Here we could increase the available bandwidth, too. And, the
processing of the complex tables could also
    be canceled.
    Is this the intention ? If yes, what does it mean: IP-over-What ? I belive
just over 188 byte cells (just the sync word 0x47 is
    still used). But than ATM over a coax link is even more efficient and
protocols are existing for the applications and services.

7. Unicast and Multicast:
    Is there a problem: The difference is just the type of IP address and
perhaps some IP header information. The MPEG-2 transport
    stream network itself is not a multicast network, or is it ? Means: is there
an device to duplicate streams in order to send it as
    identical copies to different locations ? If wou want do this you have to
use remultiplexers. But if you bear in mind to design
    your IP-to-PID mapping well, it should work to route transport streams. But
the same problem. Perhaps you have to know
    the PID allocation and useage, the routes in such a MPEG network to decide
in which PID hI have to put my multicast IP in
    order to have many outgoing data connections.

My summary: an exciting and interesting topic but what is the target ? Just to
save a few bytes to increase the bandwidth for
IP ? Not enough. We have to think in services, applications. 100 Kbit/s more
throughput is not a "unique selling proposition"
because with a better service compression (Internet-MPEG-4-movies, MP3 vs. AAC,
HTML text compression) I could have
the same effect. More important, which type of connections or type of traffic
profiles we have to support and how we could manage
this. This seems to me as complex as the ATM challenge was and is (traffic
engineering and management).
I see a lot of opportunities, interesting and challanging items but does this
effort is valuable ? Is a MPEG infrastructure the common
basis of IP networking in future ? I do not think so. IP via MPEG remains the
extension and supplement of digital TV or isn' it ?

Sorry for my brains emission but I have wanted to chip in some ideas and
thoughts. Do not hesitate to reflect to my "none-sense".

Best regards.

Torsten

Torsten Jaekel
Product Marketing Datacasting
Rohde & Schwarz FTK GmbH
Wendenschlossstr. 168, Haus 28
12557 Berlin
Germany
Phone: +49 30 65 89 1 - 103
FAX:     +49 30 65 55 02 21
email: Torsten.Jaekel@FTK.rohde-schwarz.com

PS: Please, I apologize my English mistakes, not my native language and written
quite in hurry.