An Architecture For The Delivery of DVB Services Over IP Networks

An architecture for the delivery
of DVB services over IP networks
Datasheet
User guide
White paper
Rennes, January 2007
INTRODUCTION
Present paper proposes to look around technologies used today for transporting compressed digital
video over a short (corporate) or long (national) distance, and will then introduce fundamentals about
video over IP transport. Conclusion will be made around the presentation of a typical broadcast chain with
primary distribution over IP.
DIGITAL VIDEO TRANSPORT

MPEG2 Multiplex, also called MPEG2 Transport Stream or MPEG2-TS, is a data stream carrying one or
several services, gathered into bouquets. A MPEG service is typically made of a video component, a couple
of audio components (audio channel translated in several languages for instance), or any other kind of
data (teletext, interactive data, program guide...). On top of that, many signalling technologies have been
standardized to enable receivers discovering the list of services carried in a
Transport Stream (MPEG,
DVB, ATSC). This paper will neither discuss MPEG2 TS service design and multiplexing nor video and
audio compression and synchronization.
While a final user who receives a digital TV stream at home gets access to carried services in a one by
one basis (user can watch only one movie at a time), video professionals have to carry the complete
MPEG2-TS through the broadcast chain, all programs of the bouquets inclusive. This is highly demanding
in terms of bandwidth as each program must still be decodable at any end of the transmission chain.
In addition, compressed video and audio services using MPEG2-TS assume perfect delivery over any
transport network. This is why innovative technologies had to be deployed to assist service and network
operators in transferring content in real-time from any affiliate site down to production centre in order to
allow then achieving live mixing and broadcasting to final users.
Copyright 2003-2007 ENENSYS Technologies S.A. / ENENSYS name and logo are registered trademarks of ENENSYS Technologies S.A.
DVB is a Trade Mark of the DVB Digital Video Broadcasting Project (1991 to 1996) All other trademarks are property of their respective owners.
USUAL MPEG2 TRANSFER RANGES

There are different use cases requiring broadcasters to transport a MPEG2-TS. Any of these cases can
be permanent and transmitted over fixed infrastructures, or else be temporary or on demand transfers.
Interconnection of equipments
In any head end room, broadcast equipments simply have to be connected with each other, from
encoders to multiplexers, scramblers, decoders... to build the broadcast chain. Such links have to be made
within the same building (a couple of hundred meters) and do not require long reach cabling.
Contribution
Contribution stands for live or deferred-time transport of video professional material between different
operational sites, located on different geographical areas. An operator usually builds programs by
aggregating services from remote sites (for example news relay sites, studio to studio link, stadium to
production centre...). Such an aggregation can be done using satellite or any other link: The contribution
network. Satellite contribution link can be used for that purpose, but it is very expensive, and most
operators do prefer alternate contribution solutions.
Distribution
In Digital Terrestrial TV (DTTV) systems, MPEG2-TS has to be delivered from the central (national)
head end platform to transmitters spread all around the country. This requires to have a primary
distribution network, made of satellite, microwave or any other one to many distribution links. Again,
broadcasters prefer already existing infrastructures (like national backbone) to handle such transport
needs at lowest rates.
DVB-ASI: NOT FOR LONG REACH

DVB-ASI is the most widely used baseband interface to transport an MPEG2 TS. It is used to locally
interconnect broadcast equipments but does not allow more than 300 meters of cable hop. To get longer
reach, specialized equalizers or repeaters are needed, that would rapidly increase the cost of transporting
a TS over kilometers.
In the US, the SMPTE 310M serial interface is still in use, enabling transport data rates of 19.38 or
38.76 Mbps. This interface is even more sensitive than DVB-ASI as regards cable lengths.
Other interfaces such as DVB-SPI, DVB-SSI, M2S, M2P, RS422... were also used, but not deployed on
brand new devices. More information on these can be found in a separate, dedicated white paper located
on http://www.enensys.com/whitepapers/whitepapers.html
ATM: MATURE BUT STILL COMPLEX

Like IP networks, ATM is a packet based network technology which is today used across the world for
transfer of digital TV, supporting both synchronous channel networking (PDH, SDH/SONET) and packetbased networking (IP, Frame relay, etc.). It was designed to carry any type of data, from data (emails,
files) to voice or video transport, providing flexible bandwidth assignment and different levels of QoS
(Quality of Service). ATM's adaptation layer guaranties QoS by reserving a constant bandwidth to a client
application, ensuring constant delay in the transport which is a key constraint required by the transport of
MPEG2 TS. It also implements Reed Solomon / Interleaving mechanism to add protection against errors
that occurred along the ATM network.
When a broadcaster needs to transfer a MPEG2 TS contribution or distribution using ATM, a special
interface is required to perform adaptation between baseband MPEG2 TS multiplex and the ATM network.
This interface is also needed to initiate network transactions according to the user's required bandwidth,
traffic profile, QoS parameters.
Lots of telecommunication operators use ATM networks, but ATM was not largely deployed as a LAN
technology because of its great complexity. One of the main goals of ATM was to reduce jitter in the
multiplexing of data streams at a time where IP protocol was not ready yet to provide such servicing. To
date, improvements of IP layers make it possible to carry voice over IP, and video also !
IP: SIMPLE AND COST EFFECTIVE

Originally made for data transfers (such as emails, FTP, telnet sessions...), IP has become the universal
communication protocol around the world. IP usually stands for IP network layer with Ethernet data
link layer. Prices of IP technology equipments dropped down significantly, and the never-ending
IP
networks interconnections make it possible to send data from one part of the world to anywhere without
any additional infrastructure cost. The broadcast engineering community logically thought of using such a
transport technology to carry their digital video programs at lower costs while moving to a multi service
network.
Challenge stays in the fact that a MPEG2 program has its video and audio components precisely
synchronized (using PCR time stamping information contained in the stream), and it is mandatory to
preserve this synchronization all along the transport network. Data transfer (such as e-mail, file transfer,
web browsing...) is sensitive to data loss and errors, while delay and jitter are of relatively low
importance. In contrast, multimedia services (with synchronized audio and video) are very sensitive to
delay and jitter, whereas data loss and errors are of limited importance.
The Internet Engineering Task Force (IETF) launched Working Groups to fill the gap and define
protocols fitted to [the well suited protocols for] real-time transmission of audio and video over IP. Those
new protocol stacks shall be able to manage bandwidth and network resources, gain control over the QoS,
avoid congestion...
DVB-IPI: DISTRIBUTION OF MPEG SERVICES OVER IP

DVB-IPI (ETSI TS 102 034) specifies protocols at the IP networking layer (IP Infrastructure) that must
be supported on key system interfaces to deliver DVB services over IP networks.
Below are presented the main points on MPEG2 TS over IP Encapsulation set by DVB-IPI:
All MPEG-2 transport streams shall be encapsulated in RTP (Real-time Transport Protocol) according to
RFC 1889 in conjunction with RFC 2250. Transport service is provided jointly by UDP (checksum and
multiplexing) and RTP (sequencing and time stamping / jitter removing). RTP always uses an even UDP
port number.
IP
20 bytes
UDP
8 bytes
MPEG2-TS
n * 188 bytes
RTP
12 bytes
40 bytes + n * 188 bytes

Figure 1 : RTP packet structure
32 bits
V
P X
CC
PT
Sequence number
Timestamp
SSRC
CSRC (0-15)
Figure 2 : RTP header structure
Version, 2 bits. This field identifies the version of RTP.
Padding, 1 bit. If the padding bit is set, the packet contains one or
more additional padding bytes.
Extension, 1 bit. If set, the fixed header is followed by exactly one

header extension.
CC
CSRC count. The CSRC count contains the number of CSRC identifiers
that follow the fixed header.
Marker, 1 bit. The interpretation of the marker is defined by a profile.
PT
Payload type, 7 bits. Identifies the format of the RTP payload and
determines its interpretation by the application.
Sequence number
Sequence number, 16 bits. The sequence number increments by one

for each RTP data packet sent and may be used by the receiver to
detect packet loss and to restore packet sequence.
Timestamp
Timestamp, 32 bits. The timestamps reflects the sampling instant of

the first byte in the RTP data packet.
SSRC
Synchronization source, 32 bits. Identifies the synchronization source.
CSRC
Contributing source, 0 to 15 items, 32 bits each. An array of 0 to 15

CSRC elements identifying the contributing sources for the payload
contained in this packet.
For most streams, the RTP/UDP/IP overhead of 40 bytes per RTP packet is relatively low (for example
3% with a 1 316 byte payload).
IP packets can carry from 1 to 7 TS packets, knowing that:
overall size of RTP payload must not exceed the MTU (Maximum Transfer Unit) in order to
prevent RTP packets fragmentation around the network,
short packets cause a high overhead.
There is no requirement for every RTP packet in a stream to contain the same number of transport
stream packets. The receiver should use the length field in the UDP header to determine the number of
transport stream packets contained in each RTP packet.
The time stamp field in RTP header is based on the PCR values from MPEG-2 with a resolution of 90
Khz.
Streams must include PAT (Program Association Table) & PMT (Program Map Table) other tables are
optional. SI (Service Information) is intended to be delivered via separate IP streams, in e.g. XML format.
RTCP (Real-time Transport Control Protocol) can be included to periodically inform the sending side
about network quality (e.g. lost packets, delay, jitter, etc.).
The fact is that, at the output of the IP network, delivered Transport Stream must be fully ISO/IEC
13818-1 compliant (40ms maximum jitter, 1 artifact every hour...).
What about error protection ?

The Pro-MPEG Forum (association of broadcasters, program-makers, and vendors) approved an open
standard to improve QoS in
professional
professional
video over IP networks, while
keeping
interoperability between equipment manufacturers. Standard is provided as a set of guidelines and

recommendations (Codes of Practice).
Code of Practice #3 describes a Forward Error Correction (FEC) method for protection against errors in
delivering professional MPEG-2 TS data over IP networks. With that method implemented in IP adapters,
packet errors, out of order packets, network jitter and delay can be compensated. Such process is done in
real-time along with TS over IP encapsulation: FEC protection data is calculated and embedded in regular
RTP packets with a specific payload type, and relies on simple XOR arithmetics (if F=ABC, then if only
A,B,F are present, C can be recovered with C=ABF). A FEC matrix is generated (cf figure 3) and
transmitted on two separate UDP ports, FEC columns on UDP port + 2 and FEC rows on UDP port + 4 (cf
figure 4).
Figure 3 : The dual FEC mode structure
IP
20 bytes
UDP
8 bytes
RTP
12 bytes
MPEG2-TS
n * 188 bytes
Port n
40 + n*188 bytes
IP
20 bytes
UDP
8 bytes
RTP
FEC Header
12 bytes
4 bytes
FEC Data (column)
Port n + 2
IP
20 bytes
UDP
8 bytes
RTP
FEC Header
12 bytes
4 bytes
FEC Data (row)
Port n + 4
Figure 4 : FEC packets transmission
Head end evolution with all-IP

Definitions : IP Multicasting and IGMP
IP multicasting is defined as the transmission of an IP datagram to a group of destinations, a set of
zero or more hosts identified by a single IP destination address. A multicast datagram is delivered to all
members of its destination host group. The membership of a host group is dynamic; that is, hosts may
join and leave groups at any time. There is no restriction on the location or number of members in a
group. A host may be a member of more than one group at a time. A host need not be a member of a
group to send datagrams to it.
Internet Group Management Protocol (IGMP) is a communications protocol used to manage the
membership of Internet Protocol multicast groups. IGMP is used by IP hosts and adjacent multicast
routers to establish and maintainmulticast group memberships. It is an integral part of the IP multicast
specification.
Primary distribution for Terrestrial TV

While transporting compressed video over IP using RTP, unicast addresses or multicast addresses can
be used. Packets using unicast addresses are sent to a single destination while packets using multicast
addresses are sent to any number of destinations. Multicast packets do not require any more bandwith
than unicast packets: The packets are sent once (as would be unicast packets) and are spread accros the
network if the receiving devices implement the IGMP protocol. For all those reasons, multicast addresses
are perfectly fitted to the need to transport compressed video over IP: UDP provides
application
multiplexing and checksumming, RTP provides sequencing and time stamping, FEC provides error
correction and multicast addresses provide a broadcast behaviour on IP at no cost.
SAMPLE APPLICATION
The figure below shows a broadcast chain using DVB over IP. The primary distribution network uses
DVB over IP.
ENENSYS Technologies, propose a highly reliable DVB over IP solution: The eASI-IP and IP-eASI
network adapters provide a perfect solution for transporting DVB over IP. Those adapters combine 24/7
operation, forward error correction (ProMPEG Forum CoP#3), high performance smoothing algorithm,
intuitive and easy to use user interface. More information on this technology can be found on ENENSYS
Technologies web site :
http://www.enensys.com/products/network_adapters/mpeg2_ts_over_ip_interface/mpeg2_ts_over_ip_interface.html
About ENENSYS Technologies

ENENSYS Technologies is specializing in broadcast solutions
for interworking issues. Designed by experienced technical
and commercial experts from the Digital TV field, ENENSYS
Technologies product lines are convergence oriented, aiming
at interworking of network/IT and broadcast equipments. The
products cover MPEG, DVB, ATSC fields and are providing
solutions for ASI, SSI, SMPTE-310M, GigaEthernet, QPSK,
OFDM These products are far from these expensive swissknife interfacing products that can potentially cope with many
formats but run only one. ENENSYS Technologies interfaces
are the clean and direct answer to one interfacing need.
Secret behind is compactness, portability and professional
robustness ENENSYS' product lines are the real proof that it
is no more required to engage new operating expenses to
protect your [past or forthcoming] investments.
More information on www.enensys.com
ENENSYS Technologies
Le Germanium,
80 av. des Buttes de Coesmes,
35700 Rennes,
FRANCE
Office +33 (0)1 70 72 51 70

Fax
+33 (0)2 99 36 03 84
www.enensys.com
[email protected]

An Architecture For The Delivery of DVB Services Over IP Networks

Uploaded by

Copyright:

Available Formats

An Architecture For The Delivery of DVB Services Over IP Networks

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An Architecture For The Delivery of DVB Services Over IP Networks

Uploaded by

Copyright:

Available Formats

An architecture for the delivery

of DVB services over IP networks

Rennes, January 2007

DIGITAL VIDEO TRANSPORT

Transport Stream (MPEG,

USUAL MPEG2 TRANSFER RANGES

DVB-ASI: NOT FOR LONG REACH

ATM: MATURE BUT STILL COMPLEX

IP: SIMPLE AND COST EFFECTIVE

DVB-IPI: DISTRIBUTION OF MPEG SERVICES OVER IP

40 bytes + n * 188 bytes

Figure 2 : RTP header structure

Version, 2 bits. This field identifies the version of RTP.

Extension, 1 bit. If set, the fixed header is followed by exactly one

Marker, 1 bit. The interpretation of the marker is defined by a profile.

Sequence number, 16 bits. The sequence number increments by one

Timestamp, 32 bits. The timestamps reflects the sampling instant of

Synchronization source, 32 bits. Identifies the synchronization source.

Contributing source, 0 to 15 items, 32 bits each. An array of 0 to 15

short packets cause a high overhead.

What about error protection ?

video over IP networks, while

interoperability between equipment manufacturers. Standard is provided as a set of guidelines and

Figure 3 : The dual FEC mode structure

FEC Data (column)

FEC Data (row)

Figure 4 : FEC packets transmission

Head end evolution with all-IP

Primary distribution for Terrestrial TV

About ENENSYS Technologies

Office +33 (0)1 70 72 51 70

You might also like