White Paper Scalable Infrastructures supporting OTT and IPTV in Hospitality, Health Care, and Corporate Networks

Transcription

1 White Paper Scalable Infrastructures supporting OTT and IPTV in Copyright 2018 by GMIT GmbH, Berlin, 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 1 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 1GMIT GmbH, a subsidiary of Munich-based technology group Rohde & Schwarz, has acquired the technology of Motama GmbH.

2 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. GMIT, TVCaster, CodecCaster, RelayCaster, PolyCaster, and RCSP are registered trademarks of GMIT 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. Copyright 2018 by GMIT Page 2

3 Building blocks A solution for converting live TV from DVB to IPTV requires following components: DVB sources. 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 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 switches. 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 TCP based streaming with 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 infrastructure 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 ). 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. 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 Copyright 2018 by GMIT Page 3

4 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 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 Live 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 realtime 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, Copyright 2018 by GMIT Page 4

5 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 Transcoders 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 GMIT GMIT 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 GMIT 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. Copyright 2018 by GMIT Page 5

6 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. Figure 1: Installation of a complete IPTV infrastructure including DVB gateway and transcoders 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 Copyright 2018 by GMIT Page 6

7 and optionally Transcoding servers Streaming servers Figure 1 shows this setup. For the colored parts of this Figure, GMIT provides turn-key solutions; other parts are supported by various vendors, including GMIT 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. Copyright 2018 by GMIT Page 7

8 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) 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. Copyright 2018 by GMIT Page 8

9 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. Multicast enabled switches Network infrastructure, including Wi-Fi Access Points Clients IPTV Middleware Streaming servers 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, GMIT provides turn-key solutions; other parts are supported by various vendors, including GMIT 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 highbandwidth 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. Copyright 2018 by GMIT Page 9

10 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 GMIT 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. Copyright 2018 by GMIT Page 10

11 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, GMIT 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). 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. Overall setup According to the terminology introduced above, this setup results in following components at the central data center. Copyright 2018 by GMIT Page 11

12 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 Copyright 2018 by GMIT Page 12

13 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, GMIT provides turn-key solutions; other parts are supported by various vendors, including GMIT 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. Copyright 2018 by GMIT Page 13

14 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). Copyright 2018 by GMIT Page 14

15 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. Copyright 2018 by GMIT Page 15

16 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 GMIT 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 GMIT. 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. Copyright 2018 by GMIT Page 16

17 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 GMIT 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 costeffective 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 GMIT for more information, and getting an in-depth analysis of your project. Copyright 2018 by GMIT Page 17

18 GMIT GMIT - a Rohde & Schwarz company develops multiviewer and automated monitoring products for operating and monitoring broadcast and streaming infrastructures. These products feature top performance and availability and are based on GMIT software components and technologies for processing video, audio and data in realtime. With the acquisition of the technology of Motama GmbH, the product portfolio was extended in the areas of IP contribution, live transcoding, OTT streaming and DVB gateways. Further information about GMIT is available from Copyright 2018 by GMIT Page 18