Foreword
Technical papers on Multicast ABR (M-ABR) are often limited to long and complex disputes on whether or not it can really save bandwidth on the last-mile. Or if it’s worth implementing it today considering the significant investment that has been done recently on this part of the network, whether that involves the DOCSIS migration to 3.1, cable nodes splitting or even fiber deployment.
The goal of this article is, on the contrary, to show that this is not the right debate.
The most important added value of Multicast ABR is NOT to reduce traffic on the last mile
The fact is that there are a number of operators that have already commercially deployed MABR and their feedback consistently confirms this statement. The most evident proof is probably that most MABR deployments in the world today are on fiber networks, a topology where network optimization is not a big concern, at least for the moment.
Very briefly summarized, MABR is a technology that allows you to distribute one physical copy of video content to all users in an ABR format (i.e., DASH and HLS) via multicast rather than HTTP individual connections. Technically, MABR is composed of a transcaster — also called multicast server — usually placed in the video headend. The transcaster takes in content via standard ABR streaming from an origin server, encapsulates it into multicast and sends it throughout the network. At the other end, an agent embedded in a CPE — typically a router or set-top box (STB) — unwraps the multicast layer and serves the content in an ABR format to standard streaming devices.
Generally, MABR distribution is combined with traditional HTTP unicast delivery, with multicast being used for most popular content, in particular live channels, and unicast for lower popularity content. 
Multicast ABR standard architecture
M-ABR has been one of the ABR innovations that has generated the most traction in 2019. A lot of articles have been published on this topic, with companies such as Akamai, Synamedia and Velocix advertising their own MABR solutions. Tier-1 operators such as Astro in Malaysia and Beeline in Russia have announced technology deployments, and the DVB standard is near completion, making it an important part of its DVB-I initiative. So, where does this interest come from?
Going beyond the network savings debate
Before examining the actual benefits expected by MABR adopters, we should probably get this bitrate optimization topic out of the way once for all. The fact is that MABR does actually save bandwidth compared with unicast. To be faithful to the title of this article, this section will remain as simple and short as possible.
We can basically split the network in two:
- Last-mile: How much multicast can save very much depends on the distribution technology and topology. But two very simple statements remain true in all cases:
- Multicast ABR always consumes less bandwidth than unicast and, in the unlikely worst case scenario, when all users of a same node are tuned to a different program, it consumes the same.
- Multicast ABR consumes the same as traditional IPTV, simply because the network only cares about the transport layer, and transport in both cases is multicast IP, it doesn’t matter if inside the multicast is ABR or traditional MPEG-TS. And this can actually be extended to QAM distribution as well when using SDV, since it follows the same principle, which is one same stream to all users and sending it only when at least one user on the segment is requesting it.
- Core network: There, the comparison is pretty straightforward, unicast implies one streaming session per active user versus one session per channel source for multicast. Let’s take, for example, a system provided with 100 channels, each with five resolutions, and serving 500,000 users, then multicast distribution means 1000 times less sessions, allowing quite some savings on the network infrastructure, in terms of bitrate capacity as well as CDN streamers. So, even in the case of an over-dimensioned core network where bitrate reduction is not necessarily critical, it’s interesting to note that, compared with a pure unicast ABR system, the implementation of an MABR system is already paid several times over with only the savings made on the streaming servers.
Unicast vs multicast sessions on core network
In summary, we can leave the bitrate saving topic to this simple observation:
- MABR does just as good as traditional IPTV or cable
- Always better than ABR unicast, it can be significantly or just a little bit better on the last mile but always dramatically better on the core network.
Now that it’s been said, we can tackle the real question of this article. If not for bitrate saving, then what is Multicast ABR really used for?
Why MABR? Lessons learned from commercial deployments
The first thing to observe is that MABR finds itself at the intersection of two worlds that tend to work in parallel. It uses both the video format of ABR on one side and the distribution based on traditional multicast/broadcast on the other side. So, when comparing MABR to existing technologies, it is important to clarify which of the two worlds we want to compare it to. And this is the key, as most people tend to take MABR as an optimization of ABR distribution when it actually makes much more sense as an evolution of traditional IPTV. In simple words, the opportunity is to have existing IPTV systems keep the same delivery infrastructure but trade legacy MPEG-TS video formats for more modern ABR formats like MPEG-DASH or Apple HLS. That involves upgrading IPTV-TS systems to IPTV-DASH.
The best illustration of this is that nearly all MABR deployments today are targeting live on the big screen as their primary application. MABR streams are therefore consumed mainly by STBs today. All adopters see an opportunity to improve their multiscreen service as well but that is really their second priority and usually occurs later in the process.
Now, one critical thing to take into account is that live on the big screen still represents most of operators’ pay-TV revenues. This application is consequently incomparably more sensitive than video distribution on mobile devices, and the first requirement of an MABR system is always: no regression versus the existing broadcast/IPTV system.
Source: “Television tribes” white paper – Nagra-Ampere – Nov 2017
What are the benefits of IPTV-DASH vs IPTV-TS as seen by MABR adopters? They actually mostly come from the fact that ABR formats are used instead of MPEG-TS. A non-exhaustive list is presented below, in the order of priority as we perceive it from the market.
1. MPEG-TS is outdated. The format hasn’t been evolving for a while, and most of the industry is now exclusively investing in ABR. There are many features that are already more developed in ABR than MPEG-TS, for example ad insertion, content personalization, and watermarking. Now, considering that MPEG-TS is stalled and ABR is evolving fast, the technological gap will only get bigger with time. Maintaining a legacy technology also has an impact on cost. All evolutions turn into pricy, complex and custom development projects. We can very easily find ourselves in a paradox where we get the best video experience on mobile devices rather than on big TVs while the second application remains by far the core of our business.
2. One single converged technology in the STB. Most newer STBs today are hybrid and use MPEG-TS for their live and ABR for all other applications, including VOD, nPVR, catch-up, and start-over. This implies first a redundant co-existence of two technologies, two different players, two different reception processes, both CAS and DRM content protection and so on. It also means complex interactions between them, in particular to handle pause or start-over applications that start on live MPEG-TS and end up with time-shifted ABR, or ad insertion where the main program is typically MPG-TS when its inserted ads have to be ABR. On the other hand, using MABR for live instead MPEG-TS only involves one single unified and future-proof technology for all applications.
IPTV DASH vs hybrid TS/ABR model
3. Streaming devices support. While MPEG-TS is only supported on common STBs, having live in ABR means that all mobile devices, tablets, smartphones, can also benefit from the same user experience as the big screen. But, more importantly, we can see that the access to the big screen is no longer exclusive to STBs. Many consumers have chosen to use preferentially streaming devices instead such as Apple TV, Chromecast, Amazon Fire or Roku, and we can probably include smart TVs in that category. Pay-TV operators are therefore offering a TV app, including live content, for these devices, as an alternative to their traditional STB. Anticipating that this mode of consumption will gain popularity in the future is already a widespread assumption, and it’s quite doubtful that these devices will ever support MPEG-TS.
4. Wireless STBs. Traditional STBs are mostly wired. Technically, it would be possible to connect a traditional STB via Wifi but the weakness is that MPEG-TS can only be carried over UDP, which is by definition unreliable. With MPEG-TS loss packets are not recovered, making it in general unsuited to wireless transmissions. When the multicast is terminated at the home gateway level, MABR provides a TCP connection to the STB so, just as the other streaming devices, it can be connected over Wifi, and the TV set no longer needs to be placed in the room next to the nearest “TV plug.”
5. Technology price. Of course, having one technology in the STB rather than two is more cost efficient but we can also observe that ABR is generally significantly cheaper than MPEG-TS. One of the reasons is probably because ABR is web-oriented in its essence. It benefits from a wider and more open environment as well as some technologies that are pretty much given away by big web players, in particular Google with its player and DRM solutions. MPEG-TS technology tends to rely more on video-specific products, such as bespoke middleware or custom CAS content protection, which makes the technology less flexible and more expensive. This also makes skilled resources harder to find.
Why is ABR unicast not usually considered an option for live on the main screen?
Now, if the benefits of using MABR mainly relies on ABR format versus legacy MPEG-TS, one frequent question is why not simply use plain ABR unicast instead, including on the main screen? This question has mostly been answered negatively so far by operators around the world, as most implementations are still based on hybrid technology, basically keeping MPEG-TS for live on the main screen and adding ABR for all other devices and applications. So, what is the rationale behind this? Based on the same model as the previous section, we’ve created a list of the frequent reasons given by the market.
1.Live TV in HTTP would represent an unprecedented extra load on the network. The amount of video delivered through HTTP has dramatically increased these past few years, and a lot of investment has been done on IP networks to cope with this new traffic. It could give the false impression that we wouldn’t be too far from being able to deliver all the content this way. The graph below shows that, for example, even if decreasing, over two-thirds of the time spent watching video in the U.S. is still on TV. In terms of network occupation, the proportion would even be much more accentuated for at least two reasons. First, because TVs tend to use video at much higher bitrates than most mobile devices. Second, because this only shows an average, when the network is actually dimensioned against peaks of traffic, and live video is much more likely to produce peaks than SVOD, for example. Assuming that each reason would add a factor of two, it would mean that the investment already made on the network would have to be multiplied tenfold to be able to carry live TV on the top of existing HTTP videos. And this would be for the U.S., the situation would certainly be worse in other countries where HTTP video delivery is not as popular yet. Is it necessarily an issue? Maybe not. An investment in fiber infrastructure and a good CDN architecture, for instance, might make it possible to carry that extra load, but it’s difficult to know for sure in advance, and even more difficult to predict if it will still be OK in 5 or 10 years from now, which leads to the second point below.
2. HTTP distribution is not deterministic. HTTP means one individual connection per user so its traffic follows pretty much proportionally the number of users at a given time. In video, even more than with other types of data, this generates steep peaks of traffic, in particular during primetime or specific popular events. The challenge is that the infrastructure needs to be dimensioned for the highest of these peaks, which incidentally occurs for the most popular event of the year. Hence it’s the event that requires the most irreproachable quality of experience, and the amplitude of this peak is largely unpredictable. What we know for sure is that, with the growing popularity of streaming, it will increase higher year after year and no one can really tell to what extent. Underestimating this peak leads to loss of video resolution in the best cases, and to freezes and denial of service in the worst cases. And, in the case of operated network, charged to the content provider on actual network usage, it also means that the price of the distribution of a given event is not known in advance.
Example of bitrate variations within one week
3. Latency issue. This is probably the most debated limitation of HTTP streaming at the moment. It is indeed a critical limitation, as latency through HTTP streaming generally induces a latency that is much higher than traditional broadcast and an obvious regression for live events compared with what viewers are used to. Surprisingly, most solutions on the market claiming to resolve that issue forget to tackle the one essential problem, which is that HTTP delivery is best-effort and that the time it takes to deliver the different pieces of video is variable on most real-life networks. Since video is a real-time application, the latency in the player is necessarily fixed, and a buffer has to be set on the worst case, typically 4 to 10 seconds. Using less buffer might work in labs but, unless there’s an exceptional network, the chance of encountering bad surprises during a real deployment are high. Note that there is no such limitation with multicast or broadcast. Streams take a limited and deterministic amount of resources and can therefore be prioritized on a managed network. Traditional IPTV has been working flawlessly for years now with no more than 200ms of buffer in the player.
HTTP vs multicast distribution mode
4. Screens synchronization issue. Broadcasting means pushing the same content to everyone at the same time. It is received and displayed simultaneously on all devices. Video streaming in HTTP, on the contrary, is initiated by each device individually, and these devices can only start playing at certain points in the video stream, on past key frames, so the time of the displayed video depends on how far they were from the nearest key frame at the moment of the zap. This induces desynchronization between players, which can be particularly annoying in some cases like when having several receivers within the same home or in public places, especially for the audio interference it produces
How players get de-synchronized when using unicast ABR streaming
5. Most TVs are still connected on broadcast distribution. Even if video IP delivery is growing faster than delivery on any other traditional media, the reality today is still that less than a third of the global population have a good enough IP connection to receive decent quality television. In the map below, all countries in orange or red have an average connection speed below 10 Mbps, and good performances are essentially concentrated in larger cities while the expectations are much lower outside of these zones. Besides North America and Europe, television still very much relies on unidirectional satellite and terrestrial, which are not compatible with HTTP delivery. Fortunately, this limitation doesn’t apply to IP multicast, which also follows broadcast principles and can easily be encapsulated for modulation. This makes multicast ABR a very good option to bring HLS and DASH packets via satellite or terrestrial networks down to the end-user.
Source: Digital TV research Oct’19
In summary, doubts about whether to switch the whole legacy TV broadcast to unicast ABR essentially rely on two questions:
- Would the addition of live TV via HTTP fit on the network?
- Would it match the quality of experience that consumers are used to with my current broadcast?
Conclusion
If Multicast-ABR does save bandwidth on the distribution network, that is not the main reason why it gets adopted today. Rather, it comes from the fact that broadcast and IPTV have to evolve and both options, whether preserving MPEG-TS for live or switching everything to unicast ABR over HTTP, expose worrying limitations:
- MPEG-TS technology is pretty much stalled, and there’s a pressing need to move to ABR in order to benefit from the latest video experience improvements. It has generally already been done for time-shift or VOD but it also concerns live on the main screen, which is still by far the most popular way of consuming pay-TV today, to keep up with new features implementations and to maintain a consistent system based on one single technology.
- ABR unicast applied to live on main screens would totally change the dimensioning of an IP distribution network, to a level that is not only much higher but also hardly predictable, already for the next big event but even more if looking a few years ahead as the popularity of video streaming continues to grow. Securing a quality of experience is also a very complicated challenge, because of the uncertainty on the dimensioning previously mentioned but also because of limitations inherent to the HTTP protocol, in particular latency and screen synchronization.
Interestingly, the inconvenience of the MPEG-TS option concerns the outdated video format and not the distribution mode, while the inconvenience of the full unicast ABR option resides in its HTTP distribution and not the video format. Quite logically, all these shortcomings can be alleviated by keeping the best of each option (i.e., ABR format within a multicast distribution). This is exactly what MABR achieves.
IPTV-DASH: ABR format over Multicast distribution
