Cloud vs. Set Top Box

  • 13 May 2016 Igor Khotin 4116

Will the Cloud unlweash an acid rain on Set Top Boxes (STB)? This is what many people want you to think. Others provide rational arguments why this is not happening. If you take a “long view” though...

The STB is Morphing

By any measure the Set Top Box (STB) / Customer Premises Equipment (CPE) business is huge. Hearings in the U.S. Senate in 2015 estimated that there are over 220 Million STB’s in U.S. Television Households served by Multichannel Video Program Distributors. That’s over 2 STB’s per household; 99% of these units are rented which generates an average of $231 a year per household1. That’s $19.5 Billion a year folks. No wonder that ownership of Internet set-top boxes (iSTBs) such as Apple TV and Roku jumped 63% from 2013 to 2014. Today, over 20% of U.S. households now own an Internet STB (I-STB)2.

These I-STB’s essentially are very thin streaming clients and it’s very clear that the trend is moving strongly to increasing ownership of these devices — which you can view as the death of the traditional STB — and it’s “morphing” into an I-STB. Look for example at the at Alcatel-Lucent Cloud DVR or Charter/ActiveVideo Cloud. Why do we need STB at all when most of the functions can be moved to the server side leaving clients with low-powered streaming devices?

The hunger for more quality content by Subscribers/Viewers is growing, of that there is no doubt. A key question here is whether this growing hunger for ever more content means that Operators must expand network capacities and back-end capabilities to meet such increasing demands.

Or, can Operators manage this demand more strategically by providing customers with features and performance not achievable with simple streaming devices? Is there a way for Operators to use their networks to satisfy this growing demand cost-effectively — using latent capabilities to reduce potentially ruinous costs of ever-expanding capital plant? A serious candidate is: 

The STB is a Personal Cloud 

Let’s not forget something important. The STB itself is… a Cloud. Or it can be. The amount of storage can easily increase to the point where a set top box indeed can become a Personal Cloud. This means that content from a specific STB can be distributed to all other devices, and one could argue, more effectively and efficiently than using the UBER-Cloud (the Operator’s Network). Moreover, as content resides locally on a STB, opportunistic uploads of content based on algorithmic preference analytics would also ensure QoS on the STB when playback occurs. STB chips can provide adaptive streaming and optimize content for the correct bitrate and format. Lastly, if a STB is indeed a server, it can upload content real time if necessary. Thus a “Personal Cloud STB” allows a customer to (mostly) avoid Internet dependencies and provide personalized content with unparalleled QoS. And, for those of you who are wondering — dynamic ad inserts would work fine!

The demise of the STB was predicted as soon as the word “Cloud” replaced the word “storage”. Many issues would lead us into philosophical discussions about Cloud vs. Storage vs. Cloud storage. Regardless, STB’s are very much a fact of life today. As noted previously, the number and variety of STB’s are increasing, and this includes on-board storage capacity at levels similar to a number of server farms and petabytes in Cloud solutions. The current Wikipedia definition of STB is definitely out of date. The term STB in itself is fairly fluid but certainly not limited to Satellite or Cable STBs with TV tuners in traditional sense. One could argue that Apple TV, Roku, as well as any TV/IP Ecosystem-related device with storage is a virtual STB in the house. If anything, the number of these devices in households — and as the aggregate storage capacity of devices — is trending upward to ever-increasing levels. 

Storage Capacity Exists in Current STB Installations

There was a cable provider presentation at SCTE show with a fairly detailed road map indicating incredible scale of Cloud infrastructure required to support the MSO’s expanding VOD, OTT, IPPV services. I could not help myself thinking — with millions of subscribers, assuming multiple STBs in the house, and HDTV (and perhaps soon UHD) file sizes to serve just a STB with 1TB of local storage (which is becoming fairly standard), we are looking at millions of terabytes. 

"Why did you want to climb Mount Everest?" This question was asked of George Leigh Mallory. He responded, “Because it’s there.” Well — the storage is already there — in the TV household.

There is a significant difference between revolution and evolution. Cloud computing is more evolution than revolution. Different approaches and technologies combined over the years to bring what we now understand as the Cloud. However, for each particular company and use case, the word Cloud may mean something different. At a high level we understand that we are talking about a hardware device that uses a software platform to ingest data that is remotely delivered. 

Process in the Cloud, Store in the Personal Cloud STB

When we talk about the Cloud, we mostly mean Storage. The computing resources of the STB, although pretty powerful, are harnessed to the narrow purpose of audio/video processing. It's mostly done in hardware. The chipset and on-board CPU are usually not very powerful — their role mostly to orchestrate more specialized hardware. This argument is not suggesting utilizing STB CPU resources; most CPU-intensive tasks are accomplished more efficiently on the server side. Therefore traditional SaaS/PaaS Cloud platforms are much better candidates for handling CPU-intensive tasks. But storage is an abundant resource for modern STBs that is highly underutilized to boot. The question is can we improve storage utilization the way it would benefit our clients? We believe the answer is “Yes” — if we will turn client devices into Personal Cloud Storage devices.

Converting STB(s) into Personal Cloud Storage could not only save a lot of capacity from underutilization but also help with bandwidth problems, especially for UHD content.

Adaptive streaming is a great technology. That said, sending multiple Adaptive streams over the Internet to the same household where, for example, a sports event is being watched by multiple people (some with second screens) seems a very ineffective use of bandwidth. Internet bandwidth is not keeping up with progress in video definition. 4K is already here and 8K becoming reality. And TV manufacturers will not stop on that and are going to push new standards in video and audio fidelity — they need to keep innovation cycle otherwise they end up bankrupt. We must assume that fidelity will improve, which requires more bandwidth.

Balance and Optimize Use of Bandwidth 

How we can help with growing bandwidth problems? A good answer is in making all the content available locally. By off-peak downloading and storing content on the Personal Cloud STB (pushing the Edge down to the household level) we can stream it to all clients in the household, therefore allowing the Service Provider/Operator to save that bandwidth. STB’s already provide advanced streaming functionality like transcoding in hardware. Manipulating streams shouldn't be a problem. This way, the complex and expensive Adaptive streaming infrastructure of Service Providers/Operators becomes less of a requirement. No new HW is required — this can be done in people homes using today’s STB technology.

In-Home P2P Saves Bandwidth

A combined approach to utilizing storage and optimize bandwidth comes from P2P/mesh networks. A great example is Skype — it is not only a P2P network, but an actual composite Cloud, a mesh network of built using different constituent building blocks (like routers, servers etc.) that provisions its global communication network. VOD content can be stored on a self-load balancing mesh network of STBs, with the service provider still serving all the content. Content simply gets downloaded into the Personal STB cloud storage. However, once a particular content asset gets distributed over the network, new downloads would stream not only from the Service Provider/Operator, but also from the peer In-Home STBs that already have it. The more popular the video, the more STBs can share it, reducing the role of service provider in content availability and bandwidth limitations. The bandwidth in a P2P network is self-balanced to reduce any bottlenecks (service provider also can be that bottleneck). With that approach the problem only arises when using customer’s bandwidth for upload for out-of-home streaming. However, that bandwidth can be configurable and reasonably limited or switch to head-end streaming in that particular case. 

And, there are more opportunities this makes possible. For example, with use of advanced recommendation systems we can predict with a high degree of confidence user preferences for a particular content asset and pre-load it on a Personal STB Cloud Storage. That also should work along with recommendation lists in STB UI. When customer requests particular content, with high probability it's already present on their Personal STB Cloud Storage. There are hundreds of recommendations engines. They all work — sort of. Binge watching is the new norm thanks to services like Netflix. Studies that indicate a third to one-half of the prime time internet traffic these days is streaming video. Imagine the relief that the network would see if later episodes were downloaded overnight during low traffic hours. The could be immediately available to all household devices from the Personal Cloud STB without any further use of Service Provider / Operator network bandwidth required. 

Some may argue that the real benefit for virtualizing the STB in the Cloud is the reduction of costly truck rolls, but with improved routers, improved device connectivity, and better remote diagnostic visibility into the STB they will be greatly reduced. Apple TV and Roku devices don’t require truck rolls, and neither should a Personal Cloud STB device.

How Would This Work — the Technology Topology

So how would this work? All the elements necessary to build that kind of system currently exist.

Personal Clouds are today’s reality and you don't have to limit yourself to Dropbox or Google Drive. You can deploy Seafile or OwnCloud on your home server or acquire one of NAS devices currently available on the market that come with preinstalled Cloud functionality. So there is absolutely no reason why the STB can't play that role — it fits in organically.

There are number of cases where the In-Home P2P network used as a technology to provision Content Delivery Network. Peer5 and AceStream are great examples of this. Peer5 claim 20 times reduction of server load after applying their p2p technology for media streaming.

And there have been even more elaborate attempts to bring P2P technology into media streaming industry by using dedicated devices. One of early pioneers is the VUDU STB, a streaming box that relies on P2P protocol for content streaming.

As for recommendation engines, new advances and technologies in Big Data finally make this eminently possible. It would be unthinkable to store your data in an SQL database management system. But now you can actually store and process events and most importantly extract business-valuable analytics from the device. So we are really thrilled that current technology finally allows us to build a recommendation engine that works based on actual customer behavior and doesn't resembles a primitive keyword-based matching systems used for so many years and delivering poor-quality results.

As you can see, all the building blocks for such a concept to become reality are there. We just have to integrate that into STB and server-side infrastructure.

How Would This Be Integrated — the Technology Integration

How would this Personal Cloud STB system be integrated? The first step would be to join STBs in a reliable and self-balancing mesh network. That can be done locally in user's home by combining all STB devices together. But the most effective would be to create such a network based on an installed base of STB’s. Eventually (once rights-holders allow), this network could include any storage-capable device able to run custom apps (like iPad/iPhone, Android tablet or regular PC).

Bittorrent protocol is probably the best candidate to build such an In-Home P2Pnetwork. There are numerous implementations for many languages/platforms and the protocol itself has proven its capabilities for reliable content delivery.

The best part of Bittorrent protocol is that you can build a private P2P network on top of it. That can solve number of security and DRM problems along the way, since this improves Operator control on how the content gets distributed and played.

How the content gets to the In-Home P2P network doesn't matter very much. It can be via CATV, Satellite, or Internet. For the last case, the Operator CDN would be a peer participant in the same P2P network (e.g. each location server would run Bit Torrent software that talks the same protocol as client STBs). Trackers for the In-Home P2P network are become part of that CDN. And instead of direct URLs each asset would have a Torrent file. For VOD, all available content initially would be seeded by the Service Provider / Operator CDN. But more popular it becomes, more nodes in the network would be able to provide bits of the same content effectively solving the first-mile bandwidth problem. Usually Operators have to keep 3 times server capacities to handle peak loads for big events. This is not the case in the P2P world. Peak loads are handled by natural ability of the P2P network to distribute load.

Adaptive streaming for multiple clients at home can be solved on the STB side. The latest generation of STB’s have hardware transcoding support. There is no real need to get multiple streams from the Operator. The content is delivered in best quality and then it is up to STB to do the adaptation locally — spawn the relevant stream profile and distribute it throughout the home network..

However, there is an additional, important element that can make this In-Home P2P network even more effective — and that is “opportunistic content delivery”: Pre-delivery of content to the Viewer. This would be done using the aforementioned recommendation engine. 

All user actions from any device would be reported back on server side and processed. Any user-related event brings valuable insights that enables the generation of user modelling for each individual that can predict her/his preferences with high probability.

Technologies like Hadoop and Cassandra make perfect candidates for event processing and user profiles storage. Both provide elasticity, so can be scaled to user bases of millions and tens of millions. All events would be fed and processed via Hadoop.

Then it is the essence of simplicity to individually model recommended content by a. We use that information to deliver content on the client side before it has been requested. And the same list naturally will be presented to the Viewer in their UI, thus increasing chances to pick the already-available asset.

Summarizing this very basic approach:

  • Use the STB as Personal Cloud Storage and utilize its hardware resources for Adaptive streaming.
  • Use a “smart” recommendation engine to provision pre-position the asset, “opportunistic content delivery”.
  • Use In-Home P2P on to distribute content delivery locally and reduce the first-mile/last-mile congestion of traditional CDNs for high-load scenarios.

This also partially solves the problem of STB storage underutilization as well as bandwidth overutilization — both from customer and CDN sides.

You can apply any single element in this equation individually. But we believe the optimal effect would be when used all together.

The Ability to Mitigate Traffic Peaks

Peak bandwidth is one of the major concerns for anyone participating in the content delivery — from content provider to major ISPs. According to The Global Internet Phenomena Report by Sandvile3, 36% of all downstream traffic in North America is generated by Netflix. And the data on Netflix traffic clearly shows bandwidth peaks on weekends when House of Cards episodes have been released when compared to regular weekends.

The Service Provider/Operator wants to avoid a show release that generates significant spikes (red line) over the normal distribution (blue line). And the opportunistic content delivery gives you just that. script

The recommendation engine can be used to identify users who have a high probability of wanting to view that asset. For any non-live show, the content would be pre-positioned in advance. We can discretely distribute the asset among all potential viewers days before the release. And then make the show available exactly on schedule.

Sandvile notes that during release of such popular show as House of Cards, Friday and Saturday evenings saw 10-15% increase in Netflix traffic. Sunday evenings amounted for up to 30-35% increase. Not a surprise, considering that subscribers can stream when they have free time.

However, that shouldn't be the case for the Personal Cloud STB scheme described above. These 10%-35% spikes would be eliminated (and for the mentioned Netflix case that would amount to 3%-11% of all downstream traffic in North America!). The asset can be uploaded on STBs using low traffic consumption windows.

The In-Home P2P network in this case doesn't play the major role, since the decision is driven by the recommendation engine and associated delivery-scheduling mechanism. But In-Home P2P usage can reduce outgoing CDN traffic significantly, since not only CDN server would be participating in the content delivery. 


Peer connections are inherently prone to personal security issues because they expose IP-Content tuple which may not be the wish of a user who streams the content to other users in the Cloud STB network. We have to emphasize this is not a technical security hole, but a "privacy hole". Although it is still very difficult for private entities to associate an IP address with a real person, the network should guarantee anonymization of such information sharing among users. The solution may rely on foundation principles in relatively secure networks like Tor where it is virtually impossible to identify the original content streamer. Although anonymization techniques may introduce some degradation of service quality (latency and bandwidth), with a relatively large mesh network the effect will be asymptotically diminishing.

DRM/Content Security

Traditional DRM approach that relies on “security-by-obscurity” works, but its weaknesses are obvious and cannot be solved. The blockchain-based decentralized platform with Smart Contract applications and authoring of the content would embrace the inherent requirement for network mesh for its operation and long term cryptological strength of the data protection. The beauty of the platform foundation is manifested in the principle: “the larger the network, the more robust and unbreakable the system is”. Effectively, the DRM approach will evolve into “security-by-distribution”.

The opportunistic pre-delivery of content is the most sensitive feature to DRM. We don’t want anybody to be able to see a show in advance. At the same time we want to deliver the content to as many people as possible who have a high probability of requesting the asset. These semi-contradictory requirements must resolved in order for the whole scheme to work. 

The best option would be to reuse existing DRM hardware capabilities of STBs to encrypt the content so it can’t be played without its predefined token. And make this token available for download only at the moment of scheduled release. 


When we are considering solution based on p2p, privacy/anonymization is not the only issue. Client-side CPU, memory, HD space and bandwidth also will be utilized for the system support. And when some of those resources could be delivered along with service provider owned equipment (STB) others like bandwidth are owned by users. And it is not only user agreement issue. Customers should be happy to commit some of their resources to the system and understand the resulting benefits. Some P2P networks provide share points or health indicator that gives the ratio or upload/download traffic. Majority of peers should keep it above some level in order for the mesh network to stay healthy. Reward can be the key element to make that network viable.

The before mentioned blockchain technology for DRM and content authoring requires a large number of participants who are essentially standalone STB CPE’s capable of processing and generating blocks. Mobile devices are traditionally excluded from this cohort because nobody wants to drain their battery in a single hour. This “limitation” of the system demands the reward for users spending their equipment power and bandwidth. In traditional Bitcoin network the reward is crypto-currency4. In our case crypto-currency can also be a reward, but more subtle compensations could be devised, like access to new content before prime time, ads “optimizations”, etc. So instead of abstract currency points we can reward with valuable benefit tokens.


To sum all of this up, the rationale for the Personal Cloud STB is to leverage installed in-home infrastructure (STB/CPE) as/when possible (and if not possible then replacing the units with lower cost but far more powerful I-STB’s) which will in turn :

  • Reduce First-Mile/Last-Mile congestion
  • Reduce Back-End CapEx 
  • Improve QoS/QoE in the TV household

The Cloud model extends and exacerbates issues associated with predictable peak network traffic periods. Its reliance on real time content distribution continues to negatively impact customer QoS. 

With the STB evolving to a Personal Cloud STB device, the network load can be balanced much more effectively, reducing the investment required in the entire network. Customer QoS is no longer dependent upon real time content delivery from the head-end. TV Everywhere is supported with a superior customer experience.



(1) Cable TV Box Rental Fees and Costs

(2) Internet Set-Top Boxes Now Present in 21% of US Broadband Households

(3) The Global Internet Phenomena Report: North America and Latin America, Sandvine, May 2015

(4) Bitcoin: A Peer-to-Peer Electronic Cash System, Satoshi Nakamoto