Last year (2016), Cablelabs published a very interesting document entitled “IP Multicast Adaptive Bit Rate Architecture Technical Report“, describing how to bring together two fundamental and previously incompatible network concepts: Multicast and Adaptive Bitrate delivery, in what it call Multicast ABR (M-ABR). But, does it make sense? If it does, on which use cases it works?

Let me spoil the surprise: It does make sense on one single use case. It spectacularly fails elsewhere.

To start with, lets have a look at the generic M-ABR architecture:

CableLabs presented a new video path architecture entitled “IP Multicast Adaptive Bit Rate Architecture Technical Report“, intended to describe a video delivery workflow which improves unicast network traffic for video content using Multicast ABR, including not requiring changes on the current ABR video clients.

Why is it relevant? Well, for cable operators, live unicast video is the greatest killer for a DOCSIS network bandwidth, as it requires low packet loss a huge constant bandwidth, depending on either it is SD, HD or 4K video. This issue was only theoretical only a few years ago, until the consumption of live content started to ramp up with the increase of mobile tablet applications being made available from MSOs.

As the latests Nielsen reports describes, TV consumption outside the traditional TV set is now a significant slice of the overall minutes consumed, although not replacing the STB as the main device, but on top of it. Users started to consume content on their mobiles and tablets.

As cable MSOs are concerned, the not-yet-there possibility of having mobiles devices replacing STBs as a significant video consumption device is nearly the worst possible case scenario: traffic which was before consumed from a broadcast method (usually QAM, including switched video) are now consumed using unicast, and everyone knows how tight DOCSIS networks are in terms of bandwidth. DOCSIS 3.1 does introduce some significant changes, but to no avail to the M-ABR field. More on that later.

The end result of this movement is that traffic is now not proportional to the number of linear channels, but to the number of individual devices consuming it, even inside the customer’s homes. Usage of M-ABR, althoug limited to live content, aims to bring closer the current ABR devices, with the network effectiveness of multicast.

M-ABR to the rescue

So, how to prevent unicast vídeo from clogging a DOCSIS network? Transport it over multicast and actively convert it on the home gateway. It seems simple, but it’s far from it.

The Multicast ABR architecture aims to comply with a number of objectives, including but not limited to:

• REQ1 – Decrease network usage from ABR content consumption;
• REQ2 – Keep the ABR client devices unchanged

Let’s recall the M-ABR architecture:

Comparing to the traditional ABR video path architecture, M-ABR adds a couple of components:

• Multicast Server – Has 2 main purposes: creating a carrousel with the ABR segments, on a technology similar to DSM-CC (although there’s no repetition of packets) and the retransmission of missing multicast packets.
• Multicast to unicast proxy – This is a home gateway software module, which converts multicast content into ABR segments.

Using this architecture, a video GOP follows the following sequence of events:

1. After being generated at the ABR-aware encoder, it’s sent to an already existing cDVR platform. Up until this point, nothing changes.
2. After being ingested by the cDVR, the newly generated ABR-Segment is fetched by the Multicast Server. It’s worth noting that the Multicast Server is a regular ABR client, which means it fetches both manifests (or MPDs) and segments using the ABR rules. This has a significant side effect: it only fetches a segment after it’s made available on the cDVR, but most importably, it broadcasts that segment at the same rate as the ABR profile. So, for a 2 seconds segment, it delays the video (at least) by same magnitude as the segment duration as compared with the regular ABR client
3. An end-user device requests a video segment, using the cDVR as Origin address. This request is captured by the home gateway, which does a number of actions:
   1. Joins the multicast group of the requested content and profile
   2. Until the first segments are totally received, it forwards all incoming requests directly to the cDVR, in order for the content to be played back as soon as possible.
   3. When the content segments start getting received, including any necessary error correction, the home gateway stops forwarding the requests to the cDVR and replies itself with the requested content.

If everything goes right, the end device is now consuming content without significantly incrementing network traffic on the DOCSIS network. And when we mean everything, we really means everything, namely:

• Zero packet loss on the DOCSIS network
• Zero packet loss on the home network
• WiFi bandwidth is always greater than the higher ABR profile

In this case, the traffic generated by this live content will never get higher than the bandwidth used by the content highest profile. Any other user consuming the same live content on the same DOCSIS network will not cause any additional traffic, thus implementing REQ1 – Reduce network utilisation due to video unicast content.