scalable infrastructures supporting ott and iptv in hospitality

White Paper

Scalable Infrastructures supporting OTT and IPTV in Hospitality, Health Care, and Corporate Networks Copyright © 2011 – 2014 by Motama GmbH, Saarbrücken, Germany

Live TV over IP networks (IPTV) is an important service for hospitality, health care and corporate

networks. While realizing such a service for a single site represented with a single local area network is

well-understood, different approaches exist for serving a larger number of sites. This White Paper

presents three different approaches for providing this service, namely

Option 1: Installation of a complete IPTV infrastructure, including DVB gateways and transcoders,

within the local area network (LAN) at each site.

Option 2: Installation of 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 by existing

Content Delivery Networks (CDN).

Option 3: Installation of IPTV servers, including DVB gateways and transcoders, at a single central

location and providing streams to a larger number of sites using the infrastructure provided by the

public Internet.

The advantages and disadvantages of all approaches are discussed, and an evaluation of both initial

and operational costs is presented. A video accompanying this document is available at

http://www.motama.com/videos.html

Keywords

IPTV, Hospitality, Health Care, Corporate Networks, Live TV Streaming, DVB gateway, Unicast,

Multicast, Streaming, UDP, TCP, HTTP, HLS, RCSP, Transcoder, Streaming Server, MPEG-2, MPEG-4,

AVC, H.264, Content Delivery, Content Delivery Network, CDN, Over-the-top, OTT

Copyright © 2011 - 2014 by Motama

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



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



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,



AVC/H.264 video and AAC audio are typically required for streaming to smartphones or tablets.

Transcoders also support transrating, which results in adapting the bitrate of original AVC/H.264

content without changing the codec.

Providing several different bitrates of the same TV channel allow the player software on the client

device to seamlessly switch between different bitrates. This allows for compensating changing network

conditions by adapting to the currently available bandwidth. This feature needs to be provided by the

streaming server for live TV.

Therefore, an important additional building block for an IPTV service is

� TranscodTranscodTranscodTranscodersersersers for real-time transcoding of IPTV streams in regards to bandwidth

requirements and media formats, including multi-bitrate transcoding/transrating for

adaptive bitrate streaming (ABR).

IPTV/OTT solutions by Motama

Motama offers a complete set of IPTV server solutions, including DVB gateways, transcoders, and

streaming servers and protocols for content distribution.

� TVCaster is a turn-key solution offering all cutting-edge functionality you expect from an

integrated DVB receiver, descrambler, remultiplexer, and IP streaming server. TVCaster

servers are available for DVB-S/S2, DVB-C, DVB-T and DVB-ASI.

� CodecCaster offers a high-performance real-time transcoding solution for IPTV streams in

MPEG-2 or AVC/H.264 format. The world-class encoder of CodecCaster allows for greatly

reducing bandwidth requirements of streams while keeping to the original quality, which

makes CodecCaster the ideal tool for supporting multiple devices and screens, and adaptive

streaming at different bitrates using HTTP Live Streaming (HLS) and other protocols.

� RelayCaster servers together with RelayCaster Streaming Protocol (RCSP) offer a turnkey

solution that enables optimized transmission of IPTV streams. With RelayCaster, reliability and

data rates of distributing live content can be greatly improved, and packet loss issues can be

solved efficiently. RelayCaster allows replacing expensive satellite links or expensive contracts

with CDN service providers.

� PolyCaster by Motama is a turn-key streaming server available as 19-inch rack mountable

appliance that comes with an easy-to-use web interface. PolyCaster enables you to distribute

live streams to a broad range of devices, including PC browser, mobile phones, tablets, and

set-top boxes. PolyCaster supports the major streaming formats and protocols, including

Adaptive Bitrate Streaming (ABR).

All products are available as turn-key server appliances. CodecCaster and RelayCaster are also

available as software-only packages for easy installation on existing servers hosted in data centers.



We will describe how these products can be used to realize an IPTV/OTT service. While TVCaster,

CodecCaster and RelayCaster are essential for building a distributed multicast setup, additional

PolyCaster servers allow for augmenting the service for wireless clients and PC browser served with

HTTP base unicast streaming.

Option 1: Local setup

The first and most traditional approach for realizing an IPTV service in hospitality, health care, or

corporate networks is to install the complete technical infrastructure within the local area network

(LAN) at each site.

According to the terminology introduced above, this includes following components at each site.

� DVB sources

� DVB gateways

� Multicast enabled switches

� Network infrastructure, including Wi-Fi Access Points

� Clients

� IPTV Middleware

Figure 1:

Installation of a complete IPTV infrastructure including DVB gateway and transcoders

within the local area network (LAN) at each site



and optionally

� Transcoding servers

� Streaming servers

Figure 1 shows this setup. 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: Centralized setup and CDN service

The second approach for realizing an IPTV service in hospitality, health care, or corporate networks is

to generate streams at a central location and then distribute streams to different locations using the

service provided by an existing Content Delivery Network (CDN). In this setup, the central location

needs to have a reliable and high-bandwidth connection to an existing CDN service provider in

upstream direction, for example by hosting servers in a data center. Each receiving site needs to have

sufficient downstream capacity, for example by upgrading the link capacity of an existing Internet

connection, or using several connections in parallel.

Obviously, this approach becomes more interesting when serving a larger number of sites, in particular

since a large part of the overall components required only needs to be provided once at the central

location.

While each stream is provided once to the CDN, each site will receive separate streams from the CDN.

The CDN service provider will charge the traffic according to either total volume (monthly), or overall

link capacity in downstream direction (i.e. the peak throughput to all receiving sites). Therefore,

transcoding becomes highly attractive in this setup since it allows for greatly reducing the overall

bandwidth while keeping close to the original quality of the content.

According to the terminology introduced above, this setup results in following components at the

central data center.

� DVB sources

� DVB gateways

� Switches

� Transcoders

An additional new component needs to be installed at the central location.

� CDN gateway (sender) (also called origin server) converting from the streaming protocol

available in the local area network (LAN) of the data center to the protocol required for the

particular CDN.



As an example, consider the provision of 50 transcoded TV channels, each at 2 Mbps. This requires

having a link of at least 100 Mbps with high reliability to the CDN.

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.

Figure 2:

Installation of IPTV servers including DVB gateway and transcoders at a single central location and providing streams

to a larger number of sites using the services offered by existing Content Delivery Networks (CDN)



� CDN gateway (receiver) converting from streams received by the CDN to 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

CDN. This requires having a link of at least 100 Mbps with high reliability to the CDN. Since the CDN

will typically deliver on TCP based protocols, such as HTTP Live Streaming (HLS), used for OTT

streaming, the actually required link capacity needs to be increased according to the measured TCP

performance available from the CDN to the local site.

For completing the local setup at each site, following components are required.



� Clients

� IPTV Middleware


Figure 2 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 3: Centralized setup and Internet transmission

The third approach for realizing an IPTV service in hospitality, health care, or corporate networks is to

generate streams at a central location and then distribute streams to different locations using the

public Internet infrastructure. In this setup, the central location needs to have a reliable and high-

bandwidth connection to the Internet, for example by hosting servers in a data center. Each receiving

site needs to have sufficient downstream capacity, for example by upgrading the link capacity of an

existing Internet connection, or using several connections in parallel.

Obviously, this approach becomes more interesting when serving a larger number of sites, in particular

since a large part of the overall components required only needs to be provided once at the central

location.

Similar to Option 2, transcoding becomes highly attractive in this setup since it allows for greatly

reducing the overall bandwidth while keeping close to the original quality of the content.

CDN vs. Public Internet: Bandwidth

In contrast to Option 2 presented in the previous section, this approach does not rely on Content

Delivery Networks (CDN) to distribute streams to a number of sites. Instead, streams are provided from

the central location to each receiving site individually by using public Internet infrastructure.



When using a CDN, the outgoing bandwidth at the central location is increased once with each

additional stream to be provided, and the incoming bandwidth at each receiving location is increased

with every stream that is subscribed. Distribution of the same streams to different receiving sites is

handled by the CDN. When sending streams to each site individually by using public Internet

infrastructure, the overall outgoing bandwidth is increased with each additional stream and each

additional receiving site to be served by the central location. So, while the overall downstream

bandwidth is equal in both approaches, more upstream capacity needs to be made available when

using Internet transmission.

However, not using a CDN results in decreased operational costs since no fees for CDN service

providers are due. Internet bandwidth is not for free either, and depending on the overall upstream

bandwidth, additional agreements for IP traffic or Internet transit are required. However, the

operational costs of this approach are typically significantly lower than using a CDN as discussed

below.

CDN vs. Public Internet: Quality of Service (QoS)

An important aspect to consider when relying on public Internet transmission is Quality of Service

(QoS). Internet traffic is typically best-effort, and suffers from packet loss and bursty traffic. This is even

more true when link ‘distance’ in terms of transmission delays and number of hops increases.

To overcome this problem, the approach presented in this Section uses a special server and streaming

protocol for content delivery. RelayCaster server appliances by Motama offer a turn-key solution that

enables optimized transmission of IPTV streams to remote sites. By using the RelayCaster Streaming

Protocol (RCSP), reliability and data rates of streaming live content along lossy long distance links can

be greatly improved. Since RCSP is fully Internet compliant, it can be used between any two end-points

of the Internet providing a public IP address.

Figure 3 shows the usage of two RelayCaster streaming servers. Using the RelayCaster Streaming

Protocol (RCSP) between two RelayCaster servers allows for the optimized transmission of IPTV

streams to remote company sites, data centers, or networks.

Figure 3:

RelayCaster and RelayCaster Streaming Protocol (RCSP) allow for optimized streaming for lossy long-distance links by

providing increased reliability and higher data rates than other solutions.



On one side, a RelayCaster server receives IPTV streams available as unicast or multicast in the local

area network (LAN) and then re-transmits these streams using RCSP to a second RelayCaster server,

possibly located on a continent far away. The receiving server then forwards the streams as unicast or

multicast to the local area network it is connected to.

Compared to streaming with existing unreliable protocols, such as UDP or RTP, Motama’s RCSP greatly

reduces packet loss. Even packet loss rates of several percent, jittering, or break-downs of connectivity

can be compensated for.

Compared to content delivery with reliable protocols, such as TCP or higher-level protocols such as FTP

or HTTP, the new streaming protocol RCSP offers much higher bandwidths for transmission of live

content over lossy long distance.

To this end, RelayCaster servers allow for building your own cost-effective Content Delivery Network

(CDN) using public Internet infrastructure.

Of course, RelayCaster servers also allow for scaling your Content Delivery Network (CDN) by creating

more complex setups, for example star-shaped or tree-shaped networks of RelayCaster servers (see

Figure 4).

Overall setup

According to the terminology introduced above, this setup results in following components at the

central data center.

Figure 4: A tree-shaped network of RelayCaster servers connected by public Internet infrastructure:

IPTV streams from a central location are re-distributed to various intermediate and terminating locations

where streams can be forwarded to local area networks again.



� DVB sources

� DVB gateways

� Switches

� Transcoders

An additional new component needs to be installed at the central location.

� RelayCaster server (sender) distributing the unicast or multicast streams available in the local

area network to other locations connected by public Internet Infrastructure.

Figure 5:

Installation of IPTV servers including DVB gateway and transcoders at a single central location and providing streams to a

larger number of sites using the public Internet infrastructure



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.



� Clients

� IPTV Middleware


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.



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

by existing Content Delivery Networks (CDN).



Advantages

� Greatly reduced initial costs at each receiving site: No DVB sources, DVB gateways, and

transcoders are required. Costs for additional CDN gateways are typically much smaller.

� Improved scalability: DVB sources, DVB gateways, and transcoders are only required once at

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 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 CDN service).

� 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

� Service depends on CDN service provider and proprietary CDN architecture.

� Additional and potentially high operational costs due to CDN fees.

� Areas, or countries, that can be served efficiently from the central location depend on the

network of the CDN service provider, which cannot be influenced.

� Reliable high-speed Internet access is required at each receiving site, which results in

additional operational costs.

� Problems at DVB sources, DVB gateways, and transcoding servers potentially affect all

receiving sites, if no redundancy is made available.

� Problems at CDN affect all receiving sites, and can only be resolved by CDN service provider.

� An additional CDN gateway is required at both, the central location, and at each receiving site.

� If a single CDN gateway is not sufficient for sending all streams once to the CDN, additional

gateways need to be used.

� The CDN gateway is often not directly provided by the CDN service provider and needs to be

installed and maintained.

� Each site can only get access to streams provided by central location.

� Parameters, such as bitrate of the transcoded streams, cannot be changed for each receiving

site, i.e. only if additional servers are set up at central location.

� Additional TV streams received from the central location will automatically increase the

running costs to be paid to the CDN due to higher bandwidth or data volume to receiving sites.

� Additional TV streams received from the central location might increase the running costs for

Internet connectivity at the receiving sites.



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

additional operational costs.



� Problems at DVB sources, DVB gateways, and transcoding servers potentially affect all

receiving sites, if no redundancy is made available.

� An additional RelayCaster server is required at both, the central location, and at each

receiving site.

� If a single gateway is not sufficient for sending all streams, additional RelayCaster servers

need to be used.

� Each site can only get access to streams provided by central location.

� Parameters, such as bitrate of the transcoded streams, cannot be changed for each receiving

site, i.e. only if additional servers are set up at central location.

� Additional TV streams received from the central location will automatically increase the

running costs to be paid for Internet traffic due to higher bandwidth or data volume (but these

costs are typically less than for Option 2 with CDN).

� Additional TV streams received from the central location might increase the running costs for

Internet connectivity at the receiving sites.

Summary

This White Paper introduced three different approaches for IPTV infrastructures in hospitality, health

care, and corporate networks. Starting from a purely local setup, two options for realizing a more

scalable service were presented, one using paid CDN services, the other using public Internet

infrastructure. We described how Motama’s server products, namely TVCaster, CodecCaster and

RelayCaster together with RelayCaster Streaming Protocol (RCSP), help to implement such a service.

When compared to paid CDN services, the solution including RelayCaster technology allows for

realizing a more cost-effective solution. The advantages and disadvantage of all three options were

discussed.

While this overview is meant to provide good general guidance, a recommendation can only be made

based on an in-depth analysis of all involved parameters. We believe that since Internet capacity is

always increasing and traffic costs are constantly decreasing, a scalable solution can be more cost-

effective today in both initial and operational costs, and will be even more so in the future. Since the

scalability in terms of operational costs per receiving site is crucial, the Internet based transmission

presented as Option 3 often provides the best cost-effectiveness. Please contact Motama for more

information, and getting an in-depth analysis of your project.



Motama

Motama provides solutions for reception, delivery, processing, and presentation of audio and video

content in IP networks. Our product portfolio includes DVB gateways, encoder/transcoders, and

streaming servers and protocols for content distribution. These products drive applications in IPTV,

Content Delivery Networks (CDN), Internet/Over-The-Top (OTT), Telecommunication, Mobile, Hospitality,

and Corporate Networks.

Motama's key technology - called NMM – provides a software framework for networked multimedia

systems, spanning from embedded and mobile devices, to PCs, to large-scale computing clusters. This

software framework forms the basis of our own products and is licensed to world leaders in the areas

of home entertainment, networking, mobility, content processing and digital signage.

Motama was founded in 2005 in Saarbrücken, Germany.

Further information about Motama is available from http://www.motama.com

scalable infrastructures supporting ott and iptv in hospitality

Documents