One of the main problems of any OTT service is the traffic. The problem is that OTT services use delivery via the http Protocol, in other words, the delivery of point-to-point (unicast). In this case, each subscriber “generates” his own traffic and the traffic of all the service increases in proportion to the subscriber. And this is an additional cost for video service. And it is an absolute minus of OTT technology compared with the old IPTV.

The main method of controlling traffic is CDN. Modern CDN allows reducing the amount of traffic several times (especially given the 80 to 20 rule, when 80% of subscribers watch 20% of content). However, for Live TV, the savings is not as high as for VOD. In any case CDN does not provide such saving as multicast Protocol in the good old IPTV.

So today I want to talk about how it is possible for the existing infrastructure of delivering of broadband operator (IP Multicast) to ensure the saving of the traffic when transferring heavy video for OTT. We are talking about Smart-Multicast technology.

Smart-Multicast technology allows you to save a broadcast delivery method of digital video stream (UDP/multicast), as the primary delivery method, as the most saving method of delivery without any additional traffic on the network of operator.

It is possible to completely neutralize the disadvantage of UDP/multicast delivery through the use of HLS/DASH delivery at the moments of loss of UDP packets on the operator’s network – by using a combination of the advantages of both technologies: HLS/DASH and UDP/multicast.

Implementation

Actually the solution is very simple; it allows combining different methods of delivery and switching between them is seamless, i.e. transparent to the user and transparent to the player. Because as the primary delivery method that will always work for any content (including VOD and DVR) we use HTTP live streaming. And the broadcast Protocol IP-multicast we use only as a way to reduce the load on the operator’s network for Live-content.

On the client device we add a special module, which actually is a micro-node of CDN. A module configured to receive a broadcasting signal, which corresponds to the channel playing by device. Using the packages from the signal, the module reconstructing chunks and saves successfully collected chunks in the cache.

There are two options to implement the solution. The first is when there is the possibility to modify the firmware on the console and the second – when this is not possible.

In the first case, the client device (console) uses a standard OTT player and the usual HLS/DASH Protocol to reproduce the TV signal. However, to play the player gets a link to the local MICROTEL CDN, and, as described above, the module receives all HTTP requests of the player (excluding requests of the encryption keys, which are sent directly to the server of the DRM keys). The module checks the availability of the necessary chunks in the cache and if available – immediately gives to the player. Otherwise it grants the request through a proxy like a normal CDN node. However, the low quality of broadcast signal or even its absence does not affect the service because the chunks that failed to safely get through a broadcast Protocol, downloaded from HTTP.

In the second case, the module is installed on the client router. In this case, the technology is absolutely identical to the first method, only as a system that unpacks multicast there is a router, not a console.

It is necessary to install two models for the work of the system. The first module is “Lifestream HLS Mcast Transmitter”. This module accepts a Live-stream format HLS from the standard system of OTT broadcasting, wraps it in a Lifestream Smart-Multicast format. In this format, each segment is encrypted, is supplied with a special header and is divided into transport packages, which are sent to the multicast network via UDP. Each channel uses a separate multicast group; also the broadcasting of several quality options in different multicast groups is supported. The second module is “HLS Mcast Receiver”, micro-CDN module, which is embedded in the router or the Xbox. The module includes an HTTP server, on which all requests for HLS playback from devices inside the home network of the user are going. In the absence of data received via Smart-Multicast, the module processes the requests through the proxy on the upstream Edge server of CDN. In the presence of the multicast group in Smart-Multicast format containing the segments for the requested channel, there is subscribing to it and receiving the multicast stream, the module reconstruct, decrypts and stores the segments in the cache. This cache is used to satisfy HTTP requests from user devices without recourse to the ordinary CDN, which significantly reduces the load on it.

An important feature of the system is that rare package loss does not affect the service because HLS Mcast Receiver requests corrupted segments from normal CDN via HTTP. Even the complete absence of the multicast signal will not lead to degradation of the server; in this case 100% of chunks will be requested via HTTP. This important feature allows using the system in conditions when part of the subscribers connected via the internal network, and part via the exterior.

Goal – fast switching

Technology has a second unexpected advantage: if you have fast HTTP connection it is greatly accelerates the start of the channel, as the first chunks are downloaded with a maximum speed of HTTP and there is no need to wait until they are received by the broadcast Protocol. This leads to a significant improvement in the quality of service for the user in comparison with competitive services.

The main advantages of Smart Multicast:

• Saving traffic in the network: maximum use of infrastructure of the delivery with the support of the existing broadcast Protocol (IP Multicast), without need to invest in creating new CDN capacity
• Versatility: works with any player. Ensuring seamless transition between on-air (live) and archive (DVR) broadcasting, as well as between OTT and IPTV modes
• High quality: the quality of the final service does not suffer from potential losses of the signal delivered by the broadcast Protocol (if such losses only the degree of savings decreases)
• Fast channel switching: the solution allows you to quickly switch the channels by loading the first data with a maximum speed of HTTP and there is no need to wait until they are received by the broadcast Protocol
• Security: additional built-in encryption of the broadcast signal is supported.

More about Smart-Multicast technology can be found on the website of the developer of the Lifestream.