This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Content Delivery Networks (CDN) for Live TV Streaming
Permission to use this White Paper is granted, provided that (1) the above copyright notice appears in all copies and that both the copyright notice and this permission notice appear, (2) use of this White Paper is for informational and non-commercial or personal use only and will not be copied or posted on any network computer or broadcast in any media, and (3) no modifications of any kind are made. Use for any other purpose is expressly prohibited. Motama, TVCaster, CodecCaster, RelayCaster, PolyCaster, and RCSP are registered trademarks of Motama GmbH. Flash is a registered trademark of Adobe Systems Incorporated in the United States and/or other countries. Silverlight is either a registered trademark or trademark of Microsoft Corporation in the United States and/or other countries. All other trademarks are the property of their respective owners. Images first page (c) iStockphoto.com/ jjmm888 and iStockphoto.com/ShutterWorx
Content Delivery Networks (CDN) for Live TV Streaming
Building blocks
A solution for converting live TV from DVB to IPTV requires following components:
� DVB sourceDVB sourceDVB sourceDVB sourcessss. Available DVB sources are DVB-S / S2, DVB-T / T2, or DVB-C / C2. In the
following, DVB-S/S2 is used as an example; similar evaluations are possible for other sources.
Technically, DVB sources consist of
� Satellite dishes, for example with a Quattro LNB. Often a separate dish for each
satellite feed to be supported is used for better reception.
� One or more DVB multi-switches, for example for providing 16 (or more) separate and
independent DVB feeds from the four signals provided by the Quattro LNB.
� Cabling for connecting the satellite dishes and the DVB multi-switches, and also the
multi-switches to the DVB gateways.
� DVB gateways DVB gateways DVB gateways DVB gateways for converting live feeds of received DVB transponders to IP streams. DVB uses
the concept of transponders, where each transponder aggregates a number of TV channels. A
transponder is defined by certain frequency and other technical parameters. A DVB input can
only be tuned to a single transponder at a time. Therefore, the overall number of DVB inputs
required depends on how the list of TV channels to be supported is distributed to different
transponders. A typical setup in a hospitality network will offer 25 to 50 TV channels, and will
require 10 to 20 DVB inputs. DVB gateways then convert incoming data streams of DVB
transponders to separate IP streams for each TV channel.
� Multicast enabled Multicast enabled Multicast enabled Multicast enabled switchswitchswitchswitches.es.es.es. IPTV streams in wired networks are typically provided to clients
using UDP multicast, which enables serving the same content to a large number of clients,
while relying on the efficient distribution provided by multicast networking. Therefore, a switch
or several switches are required, which fully support multicast.
� Wireless streaming and TCPWireless streaming and TCPWireless streaming and TCPWireless streaming and TCP based streamingbased streamingbased streamingbased streaming with HTTPwith HTTPwith HTTPwith HTTP.... If wireless clients, such as tablets or
mobile phones, are to be used, HTTP based streaming is often a requirement. Most often,
HTTP Live Streaming (HLS) is the protocol of choice. If clients based on web browsers running
on PCs or laptop computers are to be used, streaming with Flash protocols needs to be
supported. Since HTTP is based on TCP, these protocols can also be considered to be TCP
based.
� Network infrastructureNetwork infrastructureNetwork infrastructureNetwork infrastructure for Local Area Networks (LAN)for Local Area Networks (LAN)for Local Area Networks (LAN)for Local Area Networks (LAN). . . . For connecting streaming servers to
clients, mostly Ethernet as wired network technology is used. Another option is Powerline
Communication (PLC), or Polymer Optical Fiber (POF), or wireless networks (Wi-Fi 802.11).
Wireless networks are particular interesting when installing IPTV in an existing building where
no IP infrastructure is available at all, and installing new cables for Ethernet or POF is not an
option, or Powerline is not working reliably at high data rates for a larger number of clients.
Please notice that PLC, POF, and Wi-Fi require additional network components to be installed,
such as Access Points (AP) for Wi-Fi. If multicast streaming is to be employed, these
components also need support it.
� Clients.Clients.Clients.Clients. Set-top boxes, TV sets with integrated streaming clients, or software media players for
PCs are used for receiving and presenting TV streams. Other options are wireless clients, such
Content Delivery Networks (CDN) for Live TV Streaming
as tablets or mobile phones. In case of multicast, channel hopping is performed by joining the
multicast stream of a particular TV channel. In case of unicast streaming with HTTP based
protocols, channel hopping is done by (re-)creating a streaming session and unicast
connection for each client.
� IPTV MiddlewareIPTV MiddlewareIPTV MiddlewareIPTV Middleware providing a consistent user interface layer for user of clients, such as set-top
boxes, including access to the list of available TV channels, channel hopping, and Electronic
Program Guide (EPG). Middleware often also provides access to Video on Demand (VoD)
served by additional servers. Middleware typically requires a separate server, which exports
HTML based user interfaces to browsers installed on clients.
Use cases for transcoding of IPTV streams In situations where an IPTV service is to be employed in a building without an existing IP network and
the installation of new cabling infrastructure is not possible, Wi-Fi is an interesting option. A typical use
case is a hospital where installation of new cables to the edges of patients’ beds would be required,
but patients cannot be relocated during the extensive and noisy process of laying cables.
Using wireless networks for IPTV services is also interesting for hotels or company sites that would like
to offer IPTV services to wireless clients, such as notebooks, tablets, or smartphones provided by
guests or employees. Either the already existing Wi-Fi infrastructure for general Internet access can be
used, or needs to be extended, or new additional access points need to be installed to take into
account the additional bandwidth requirements for IPTV. Since these client devices are not part of the
fixed IPTV infrastructure, but - for example – the property of the hotel guest, all commonly used
streaming protocols and media formats need to be supported, such as HTTP Live Streaming (HLS),
Flash streaming with RTMP / HTTP, or Silverlight Smooth Streaming, and others (often associated to
the term streaming protocols for Over-The-Top (OTT)). Streaming based on UDP unicast and multicast
is typically not supported by the mobile client devices and will often be blocked by firewalls running on
the devices themselves.
Please notice that such a service requires an additional streaming server for serving individual clients.
� Streaming servers for Streaming servers for Streaming servers for Streaming servers for Live TVLive TVLive TVLive TV providing interactive access to live streams for client devices,
such as notebooks, tablets, and smartphones. In contrast to IPTV streaming with multicast, a
separate streaming connection needs to be created for each client that requests content.
Video-on-Demand is functionality provided by streaming servers, but will not be discussed further.
Another important aspect is transcoding. Transcoding servers allow for converting IPTV streams in real-
time to other formats. Most importantly, this allows for reducing the bandwidth requirements for
wireless transmission, but also for Internet transmission as we will see in Option 2 and Option 3
presented in the following. Transcoders allow for converting from MPEG-2 video to AVC/H.264 for
reducing the required bandwidth while trying to keep to the original image quality and size. In addition,
streams can be adapted to screen sizes of mobile phones. Often transcoding is also a requirement to
change the audio or video encoding to formats supported by such mobile devices. For example,
Content Delivery Networks (CDN) for Live TV Streaming
As an example, consider the provision of 50 transcoded TV channels, each at 2 Mbps. This requires
having a link capacity at the sender side of at least 100 Mbps for each receiving site. The number of
receivers to be handled by a single sending RelayCaster server depends on the total number of
streams and total bandwidth.
At each receiving site - for example, a hotel, hospital, or company site – following components are to
be installed. An additional new component needs to be set up.
� RelayCaster server (receiver) converting streams received with the RelayCaster Streaming
Protocol (RCSP) to unicast or multicast streams to be served to clients, such as set-top boxes,
and other components.
As an example, consider again the reception of 50 transcoded TV channels, each at 2 Mbps, from the
sending RelayCaster. This requires having a link of at least 100 Mbps. The actually required link
capacity depends on the link quality in terms of packet loss rates and delays. However, compared to
TCP based protocols, RCSP provides a much better saturation of the link capacity.
For completing the local setup at each site following components are required.
� Multicast enabled switches
� Network infrastructure, including Wi-Fi Access Points
� Clients
� IPTV Middleware
� Streaming servers
Figure 5 shows this setup. From a central location, streams are provided to a local site; for each
additional site to be served this part of the overall setup needs to be provided. For the colored parts of
this Figure, Motama provides turn-key solutions; other parts are supported by various vendors,
including Motama’s partners.
Option 2 and 3: IPTV Middleware and Streaming Servers As discussed before, IPTV Middleware is running on an additional server at each receiving site. In both,
Option 2 and 3, IPTV streams are made available again in the local area network of each site.
Therefore, no or only little changes are required for existing IPTV middleware solutions. One can also
consider centralizing at least some parts of the IPTV Middleware to the central location as well.
Streaming servers for Video-on-Demand (VoD) should still be kept in the local area network of each
receiving site. VoD content will typically only be changed in a very low frequency (e.g. once per week),
and then only needs to be updated once for each VoD file. Having a local VoD server also avoids
additional Internet traffic whenever a VoD item is consumed by a client.
Content Delivery Networks (CDN) for Live TV Streaming
Comparison
The advantages and disadvantages of all approaches will be discussed, and an evaluation of both
initial and operational costs is presented.
Evaluation of Option 1: Local installation
As can be seen in Figure 1, this approach requires installing and maintaining the complete IPTV
infrastructure within the local area network (LAN) at each site, e.g. hotel, hospital, or corporate site.
This results in following advantages and disadvantages.
Advantages
� Installation is ‘owned’ by a particular site and can be freely configured without affecting other
sites.
� Different selections of TV channels can be made available at each site.
� All components are fully accessible at local site.
� Problems at DVB sources, DVB gateways, and transcoding servers only affect a single local
installation.
� No high speed Internet access is required; Internet is only required for remote administration.
Disadvantages
� Maximum initial costs, since each installation requires all components.
� Local installation of DVB sources including large satellite dishes and cabling from dishes to
DVB multi-switches might be problematic to set up.
� Local installation of larger number of DVB gateways and transcoders requires additional rack
space, cooling, power, etc. at each site.
� Remote administration needs to be enabled for a large number of components.
� Remote troubleshooting of DVB sources, such as problems with a DBV dish, is not possible.
� Troubleshooting more often requires a local intervention, which in general will result in higher
operational costs, in particular if on-site support requires additional working hours due to
travel, and travel & living expenses.
� Weak scalability: Changing the settings of streams requires administration of each site.
� Weak scalability: When adding an additional stream exceeds the available capacity of DVB
multi-switches, DVB inputs at gateways, or transcoding capacity, additional components and
installation is required at each site, which results in initial costs for each site to be updated.
� Adding redundancy (such as spare servers) requires additional initial costs at each site.
Evaluation of Option 2: Centralized setup and CDN service This approach improves scalability be installing IPTV servers, including DVB gateways and transcoders,
at a single central location and providing streams to a larger number of sites using the services offered
Content Delivery Networks (CDN) for Live TV Streaming
Evaluation of Option 3: Centralized setup and Internet transmission Compared to Option 1, this approach also improves scalability by installing IPTV servers including DVB
gateways and transcoders, at a single central location. Instead of using the services provided by an
existing CDN, an own network for providing streams to a larger number of sites is built, which relies on
Motama’s RelayCaster technology running within the infrastructure provided by the public Internet.
Advantages
� Greatly reduced initial costs at each receiving site: No DVB sources, DVB gateways, and
transcoders are required. Costs for additional RelayCaster servers are typically much smaller.
A single RelayCaster server can serve a larger number of streams and remote sites.
� Improved scalability: DVB sources, DVB gateways, and transcoders are only required once at
the central location.
� Selection of TV channels can be changed or extended easily and mostly only by modifications
at the central location.
� If additional TV channels will exceed available resource at the central location, additional
costs and installation will only be required at central location (for example, for additional DVB
sources, DVB gateways, and transcoders).
� Additional running costs scale more transparently per TV channel received at each receiving
site (costs of bandwidth / volume for Internet access).
� Compared to Option 2 (CDN), operational costs are typically much lower since public Internet
infrastructure can be used, together with Internet transit, depending on overall bandwidth.
Internet capacity is typically available at only 10 to 20% of the costs of CDN services.
� Compared to Option 2 (CDN), service is not depending on single CDN service provider, in
terms of pricing, reliability, and local and global reach, such as supported countries.
� Service is ‘owned’ by you, and can be scaled for more cost-effectiveness and more reliability
(e.g. by adding several independent Internet transit providers).
� Better reliability and higher bandwidths due to usage of RelayCaster Streaming Protocol
(RCSP), and thereby better link saturation and better cost-effectiveness of purchased
bandwidth, even for lossy long-distance links, and the last-mile to receiving sites.
� Single-vendor turn-key solution for all building blocks for setting up this kind of IPTV service is
available from Motama.
� All sites have access to high-quality transcoded streams. An IPTV service for Wi-Fi users can be
provided easily.
� Troubleshooting for components DVB sources, DVB gateways, and transcoders can be
handled at single central location.
� Redundancy (such as spare servers) and monitoring of a large part of the overall setup can be
handled at central location, which reduces the operational costs.
Disadvantages
� High-bandwidth Internet access required at upstream of central location.
� Reliable high-speed Internet access is required at each receiving site, which results in