Standardization of content steering within the two principle streaming architectures, MPEG’s DASH, and Apple’s HLS, is a key step in maturation of the internet for high quality content delivery. Although there is still work to be done optimizing content steering between multiple CDNs and pathways, the fundamental operation is set in stone now that DASH and HLS have more or less converged on a common architecture. 

This is based on the idea of a dedicated steering server orchestrating selection of CDNs and pathways on the basis of rules laid down by content providers at the origin. This also serves end consumers because the rules can stipulate that devices should obtain the best QoS possible over the multiple CDN infrastructure at all times.

The incorporation of content steering into streaming can be seen as a fundamental and perhaps final step in recapturing the deterministic and predicable performance of traditional broadcast delivery infrastructures, while being able to reach subscribers wherever they and whatever device over the internet. The streaming protocols themselves were developed to enable more predictable and resilient delivery over unmanaged broadband networks, but services were still subject to the vagaries of intermediate CDNs, with geographical and content related variations in performance and penetration.

The scale of these CDNs and their exposure to sometimes savage peaks and troughs made them susceptible to network congestion and variations in QoS. There were variations in peering arrangements with the Internet Service Providers (ISPs), which added to inconsistency in QoS for large scale streaming services.

This led to recruitment of multiple CDNs for redundancy, load balancing and greater QoS consistency, with several methods emerging since the rise of streaming for serious media delivery, dating back up to two decades. Under these approaches, either the same content is loaded simultaneously onto several different CDNs, or more efficiently, each of the CDNs draws content in parallel from a single origin server.

But all of these approaches were proprietary, and mostly rather cumbersome, only allowing switching between CDNs at the start of a session. They failed to allow CDN switching in near real time during playback, as is needed to optimize QoS and achieve the full operational benefits in terms of load balancing, resiliency and possibly minimum cost.

There were three fundamental methods applied: player-initiated switching, CDN fallback, and DNS-based CDN selection. Under player-based switching, clients such as smart TVs, laptops and smartphones require software for accessing the network via an API to find out the URL of the CDN they should currently fetch content from. They then go to that CDN on the basis of that instruction but cannot then change after playback.

Then the fallback mechanism, also initiated by the player, is invoked only when playback problems occur. The client consults the manifest file, which acts essentially as an index and map of content, to obtain fallback URLs of backup CDNs capable of delivering the same content. This addresses only backup and can be unstable when individual CDNs become flooded with requests they cannot handle in the event of outages affecting other parts of the delivery infrastructure.

Then there is the DNS server approach, which most closely resembles the current content steering method. The DNS server defines which CDN each client is connected with, allowing loads to be distributed with some insulation against individual CDN failures. There is usually no ability to distinguish between users within a cluster that are suffering from some performance problem, such as buffering or long startup time, and those that are not.

These methods tend to be insufficiently flexible and granular, while being confined to switching between CDNs at the start of playback, which limits the efficiency and performance improvements. CDN steering evolved to overcome these limitations and provide standardized frameworks for multiple CDN operation with both DASH and HLS.

The objective was then to converge DASH and HLS content steering specifications in terms of features and basic operational principles, while still allowing room for innovation on top. This is in keeping with the direction of DASH and HLS in general, not just content steering. There is movement towards standardized approaches for low latency streaming and integration of DRMs, straddling both HLS and DASH.

HLS was initially developed by Apple to favour its own devices and ecosystem for robust live streaming performance there. DASH then emerged as an open standard, designed to extend competent streaming across various multiple devices and codecs.

Apple will continue to evolve HLS, but increasingly features such as enhanced interactivity, spatial audio and HDR video, as well as machine learning driven optimizations of ABRS (Adaptive Bit Rate Streaming) delivery for smoother playback, will roll across both.

Apple pioneered the concept of the steering server, introducing the technology in April 2021 as a new HLS feature. The DASH Industry Forum followed in July 2022 with its version as an extension of DASH, essentially at that stage a subset of the already existing HLS content steering.

Content steering was also incorporated in a JavaScript library on top of HLS. This meant that content steering was supported out-of-the-box by Apple devices, including iPhones, and Apple TVs, as well as all standard web browsers such as Chrome, Firefox, Safari and Edge. This was crucial because it avoided the need for any additional API, or external DNS server. library, API or DNS server to enable the CDN switching.

Content steering then became integral to the respective ABRS platforms as both Apple and the DASH Forum implemented the changes. The DASH-IF version was then submitted for publication as the ETSI TS 103998 standard.

An idea of the underlying content steering mechanism can be obtained by considering a straightforward system comprising two CDNs labelled A and B. Each CDN has a base URL also referred to as a pathway in the specification, both attached to the independent steering server.

Both can deliver the same data, but only one at a time to a given client, with the other standing by. Architecturally it is a mesh arrangement with each of the two CDNs in principle having separate connections to every client. Then when say CDN A becomes unavailable to a given client, the steering server becomes aware via the content distributor and switches that client to CDN B.

Switching decisions can also made on any reasonable criteria the content distributor wants, such as to balance loads between the CDNs, which can be executed in near real time as traffic patterns change. The main benefit then is that the content provider is in control via the steering server, which in turn determines in near real time, even during playback, both when CDN switches occur and which one to switch to.

This raises the question of what happens to existing proprietary providers of multiple CDNs, such as France based Broadpeak as a pioneer in the field, having launched its version called Umbrella CDN as early as 2013. The answer is that these vendors are aligning their systems with the new CDN steering standard, which leaves scope for them to optimize the implementation on top.

Although the underlying mechanisms are specified, the actual rules or business logic used to determine when and where CDN switching occurs are still specified by the content or service provider. This is where the scope for innovation and specialization will lie.

These are still early days for content steering, and some operators are still seeking clear evidence that it delivers on its promise of improved efficiency. At least test results so far are promising, conducted by various bodies including the Streaming Video Technology Alliance (SVTA), as well as Apple and the DASH-IF.

Some of these tests took a three CDN model as a proving ground and the general finding was that combining the three through a content steering server outperformed even the best of the CDNs on its own. Naturally the gap was greater between content steering and the worst CDNs.

The implication is that the overhead incurred by yoking multiple CDNs together under content steering is more than paid back by improvements in performance. There are then the additional efficiency improvements for the operator in terms of load balancing and cost savings.

One other important point to consider is support for hybrid broadcast/broadband services, given that these are being driven by ATSC 3.0 in North America, and by DVB Interactive (DVB-I) in Europe, as well as potentially by 5G Broadcast. These enable viewers to access linear broadcast and streaming content via a single unified UI, so should be accommodated by content steering, bringing in the mobile dimension as well.

At least the DASH version of content steering has catered for this through the idea of the proxy steering server, that is a server sitting between the client devices and the actual steering server. The idea then is the proxy can mediate between the broadcast side through whatever medium that uses, and the broadband side through the steering server. The latter could be accessed from a mobile device.

This ability to switch dynamically between broadcast and broadband delivery in this way confers three key benefits. One is to enable continuous smooth service over the internet for users who move in and out of broadcast range, or sometimes the other way round, with both backing up the other.

Second, service providers can enable and disable broadcast delivery on the basis of factors such as consumption patterns to optimize costs, extending the utility of content steering within the broadband domain. Finally, it facilitates greater personalization, including revenue generating use cases such as targeted ad-insertion. In that case the primary content would be broadcast and the ad content inserted over the broadband network.