OTT Delivery: Creating Strategies for Video Streaming
“Over the top” (OTT) is one of the most overused and ambiguous buzzwords in our industry.
In order to understand linear video delivery in OTT models, first, you have to look at what OTT means outside of video. To mobile operators, OTT is a scary proposition. Calls, text messaging, and image messaging had been entirely within operators’ control until now, and therefore presented an opportunity for revenue. For those operators, OTT services are an almost unavoidable symptom of smartphones requiring open internet access, and bring with them many services that compete with operators’ traditional revenue models. King of all these is Skype, and it provides a clear example of what “top” the service comes “over” to earn the moniker OTT: Namely the pay wall that is the per-minute billing system of the mobile operator.
In exactly the same way I often dogmatically emphasize that “cloud” is an economic term defining the move of CAPEX to OPEX when building IT infrastructure, OTT is also an economic term first and foremost. At best, it means that the operators are able to derive data transit and bandwidth-oriented revenues for the delivery of network service on behalf of providers who otherwise charge much higher premiums to end users or sponsors. At worst, operators are loss-leading that data transit to encourage subscribers to stay with them rather than take their business to other operators. All the while, OTT services are taking revenue from network operators’ subscribers and not (necessarily) sharing any of that revenue with the network operator.
However, with this economic common denominator noted, in any specific technical context the term OTT has a range of implementation models that ensure that the cost of this data transit and bandwidth delivery itself is as profitable as possible for the network operator, whether profit is measured in operator CDN revenues or in terms of subscriber retention.
Therefore, one group of operator-focused broadcast OTT models for the increasingly connected TV market typically uses subscriber ISPs to deliver OTT services. For this community, OTT evokes a tight coupling of application control, typically embedded securely in smart TVs or set-top boxes, with a primary content origination strategy.
This typically results in a streaming video-based workflow connecting content publishing sources with points of distribution in some form of content management system. This, in turn, is synchronized with the applications in the end user premises, and presented as some form of electronic program guide or other user interface on their device.
Broadcast OTT providers work closely with operator CDNs to ensure Quality of Service across well-managed IP networks, and they will work in regions. This is result of these operator CDN relationships, as well as the market-shaping caused by the existing TV content rights models.
For example, in the U.K., we see the BBC (iPlayer), Sky (SkyNOW), and BT (BTSport/BT Vision) as leading examples of common OTT propositions. While the content originates in a form that is delivered directly to the internet for general-purpose access through a device of the consumer’s choosing, each of these publishers also works very hard to also deliver their own services well to connected TVs and set-top boxes. This results in, for example, Freeview, YouView, BT Vision, and Virgin Media set top boxes in the U.K., with internet connections, that can access BBC iPlayer, or Sky Now, and these services typically appear along side other OTT providers such as YouTube, Netflix and Vimeo.
There is a key separation between simple streaming applications that the device can browse and the broadcast OTT providers -- the broadcast OTT provider’s services will appear ‘integrated’ with traditional broadcast TV, where services such as YouTube and Netflix will be entirely separate applications.
An example: A typical user might see TV, YouTube, and Netflix options on her main connected TV menu, but might not see BBC iPlayer as a standalone menu application. However, the traditional BBC1 linear TV broadcast might include extended features, such as red button, network DVR, pause and rewind live, or extended on demand viewing catalogues, perhaps related to the current broadcast. All of these are made possible by the tight integration of the BBC with the broadcast OTT provider’s app that is in effect native on the end device.
This native capability is brought about by the device manufacturers’ adoption of various “standard” OTT models that have formed within different schools and layers of the broadcast industry as it has worked out how to adopt IP in its distribution workflow.
Some examples of this are the U.K.’s Digital Television Groups’ D-Book standard, and YouView’s and HbbTV’s initiatives as well as the Open IPTV Forum. Each lays out parameters for how devices should respond to applications that are delivered over the air, giving those who are able to deliver such applications an exclusive reach and capability to derive additional revenue or value.
In the D-Book/Freeview Plus model, an MHEG (Multimedia and Hypermedia Experts Group) application is broadcast along with the digital television signal, and is received and decoded by the device, which in turn responds to any streaming content requests made by the user by using the device’s internet connection to acquire and play the stream back. Because the application is only available to those in the broadcast footprint, the users of the service are limited to that footprint too.
This means that an ISP covering the same footprint becomes a great candidate for a broadcast OTT provider’s content delivery network, and a direct connection from the broadcast OTT provider’s content aggregation and origination point effectively means that the broadcast OTT provider is delivering content directly to the end user. Again, partnerships between broadcast OTT platforms and particular network operators are common, if not imperative.
YouTube and Netflix, by contrast, are user-activated applications. These need to be specifically coded against the device’s native middleware and may simply be extensions of the device’s internet browsing capability. The content is delivered from the YouTube or Netflix CDN to the end user through the end user’s ISP. While this simplifies publishing for YouTube and Netflix (they don’t need to establish a new delivery workflow for each operator), the lack of tight integration with the end device limits them from offering certain broadcast-friendly premium features, such as the red button services overlayed on the broadcast services.
So this application “paywall” still exists and draws a protective boundary for the broadcasters to add value and maintain their subscriber revenues.
The Taxonomy of OTT Video
As you can see, the definition of OTT really depends on where the service is charged, rather than on any specific technical strategy.
While Netflix and YouTube are often cited as typical OTT services, they actually represent only one type: “pureplay OTT” for the purposes of this article, to distinguish them from the more tightly workflow-integrated broadcast OTT models discussed above.
Going further, we could loosely group the different models like this:
Digital terrestrial television (DTT)/direct to home (DTH) satellite operators. The operator may use a DTT or DTH system to provide traditional broadcast services. They may or may not use IP on these privately managed networks, and will require specific consumer devices/ set-top boxes to connect to these networks. The OTT application control (MHEG/ EPG data, etc.) needs to be transmitted over the (usually non-IP) broadcast network as part of the broadcast transmission. (The red button trigger is sent in the broadcast stream.)
IPTV operators. These are, in effect, ISPs with QoS controlled subscriber circuits, managed IP end to end. The consumer would have to subscribe to her network services to receive the IPTV packages, which come with a specific set-top box and a specific access circuit to the home.
Broadcast OTT operators. These are analogous to the traditional DTT/DTH multiple service operators, although they work entirely in the IP domain and they hand off the delivery responsibility to either their own operator CDN and access network, or third-party ISP subscriber networks. They target specific devices and often tightly integrate with the existing DTT/DTH and telco services to provide the OTT services as value added extensions of the existing DTT/DTH broadcasts. While the paywall may reside with the broadcast OTT operator, the partner DTT/DTH and telco networks often have a direct commercial relationship, even if that only extends to providing access to the set-top boxes with EPG and UI support (although it may extend to a near-IPTV like distribution model too).
Pureplay OTT Operators. These are completely distinct from the access networks and the application layer delivery. In reality the very large players such as YouTube and Netflix will work closely with connected TV and set-top box vendors to provide native optimized applications closer to the broadcast OTT model, although there are many PC-based set-top boxes on the market that can access Netflix and YouTube APIs and display the content in their local browsers as if there was a native application. Pureplay OTT operators might not develop relationships with the broadcast network operators, leaving the content distribution to partner pureplay CDNs. One thing they do share, and which defines them as pure play OTT operators, is that they do not have end-to-end QoS guarantees. In that respect they are technically indistinguishable from traditional streaming services found online throughout the web today.
These models are all shown on the topology schematic in Figure 1.
I would like to highlight a few key things that I have tried to represent in this diagram.
The gray circle shows the physical broadcast access networks that reach the end user. A subscriber who is connected to this wired physical network layer (which may well not be IP based) can connect through that physical layer to the cable TV broadcast signals. Consumers with IP access are able to reach the operator CDN, the IPTV services, and potentially third-party pureplay OTT services.
The blue circle outlines the broadcast operator’s operational networks, where the content is prepared and distributed to the physical access networks.
The small green circle shows a third-party telecoms (or cable) network which provides the end user with internet access through an ISP who is neither involved in the OTT services nor the broadcast services.
Note that in the top right corner the DTT and DTH broadcasters can use broadcast networks that are not physically connected to the end users. Broadcast models such as this provide no native return path, which is critical for IP-based OTT services. For DTT and DTH this means that a separate internet connection must be provided to the end user, typically by ADSL or FTTH, and this may or may not be bundled with the OTT service subscription (green or gray and blue circles).
Within and between the blue and gray circles, operators can control QoS, and the perimeters of these circles show the boundaries where that control ends.
The orange circle represents the internet, where, for example, a pureplay CDN might operate. The edges of that CDN network might offer public internet peering (shown as the red route) or private peering and transit connectivity (the yellow route), and this direct connection to the broadcast operator’s physical IP network could provide a QoS managed environment from the CDN hand-off forward to the end user.
This topology does not allow for guaranteed end-to-end QoS, since the CDN only offers a best-effort SLA. In turn, the pureplay OTT provider can only pass on “improved” QoS to the broadcaster. The typical approach to the non-QoS regions between the CDN and the ISPs or operator networks is to provision significant extra capacity in interconnects and peering and cross their fingers -- and to be honest this model works very well.
That approach, however, is not usually viewed positively when commercial contracts are put in place. Therefore, private links between the operator and the content provider are usually created for accountability reasons rather than technical ones. This can lead to certain OTT providers working closely with the broadcast operators, such as Netflix arranged with Comcast in the U.S.
This model is shown as the yellow line. It represents a service such as Netflix as an augmented service to IPTV (light blue) generated inside Virgin Media and delivered over their network with QoS guaranteed end to end, or even simply to the traditional cable, DTT, or DTH service with little operational overhead for the broadcast operator, beyond charging Netflix for the regional operator CDN distribution as an incremental revenue to their core broadcast subscriptions. In this model, end users may subscribe directly to Netflix as an extra expense on top of their basic broadcast package subscription.
Of course, free content such as YouTube or BBC iPlayer carries no premium subscription from the end users. In these circumstances the operator CDN costs may be perceived to be simply a loss leader for the OTT providers, so YouTube or BBC may simply opt to extend its web-facing streaming content to the Virgin Media set-top box audience through the public internet model. This approach avoids becoming relying on the operator CDN.
This tends to create a more level co-dependent playing field for both parties: The operator CDN might opt to internally bear the cost of bringing the content to the EPG, so that the pureplay OTT services can be browsed. This can be as straightforward as supporting the OTT services in the set-top box’s browser. The broadcast OTT provider would have to make an investment to do this, but the pureplay OTT providers’ content is a must-have that they cannot exclude from their package without losing subscribers.
In this case, the cost of network transit between the pureplay OTT providers’ CDN edge and the end user (shown in my diagram in red) is free to the broadcast network if it is delivered by the pureplay OTT operator and distributed through the end user’s chosen ISP. This is the lowest QoS SLA and accordingly the cheapest OTT model, but it is also usually good enough for most consumers.
At the other end of the spectrum, the purple IP-encoded video can be delivered directly from the operator network to the broadcast access network and, so long as the end user is “on net,” then QoS can be guaranteed. This would classify the IP delivered video as being IPTV; it is interesting to note that the same video delivered via a third-party ISP would change the terminology from IPTV to OTT, and this QoS differential is often (questionably) cited as the wall that we have gone over when defining OTT, leading many to think that OTT is of worse quality than IPTV or broadcast.
Finally, point A shows a critical interface where the MHEG app, or similar EPG details that announce the existence of any OTT content over the traditional broadcast network, is established.
This thin brown line (seen by marker A in the head end) represents metadata and small application data that is distributed over the broadcast network to facilitate access to the broadcaster OTT content. It is exclusively available as part of those traditional broadcasts, and this couples these services to relationships between the broadcast network operators, the broadcast OTT operators, and the content providers. This closeness creates commercial control and is driving revenue for all these parties, something that pureplay OTT services often do not do.
Are we closer—or further away—from one-size-fits-all media consumption? In this article from the 2014 Streaming Media Industry Sourcebook, we take a look at the OTT landscape from a technology, carrier, and multi-channel video programming distributor standpoint.
Are physical discs going away? Not any time soon. Study finds that people overwhelmingly prefer DVDs and Blu-ray to online sources.
Viewers are binge-watching, Netflix is taking over the internet, and bandwidth it growing. How Americans watch TV is changing at a rapid pace.