When the word cloud first entered broadcasting and pay TV it was presented as an alternative or competitor to the home gateway, storing and delivering content from a network without needing a fat device in the home. But like many new concepts in broadcast service delivery, this was misleading because it depended on how both were defined. The gateway as a storage device for recorded content either specified by the user or downloaded preemptively by an operator, almost certainly will head up in the cloud eventually, especially if relaxation in rights issues allows content to be stored just once for all users of a service.
It is even possible that user generated content including home videos and photos could be hosted in the cloud, although that seems unlikely for the foreseeable future. Broadband connections are still not so reliable that people will want to rely completely on them, which has also been a factor discouraging some enterprises from migrating all their IT to cloud based models. The outages affecting public cloud services such as Amazon’s Elastic Cloud have also served as a reminder that these models are not quite ready yet to be trusted completely for critical applications.
But there are other reasons why the home gateway will survive both as a function and piece of hardware. One is a purely pay TV reason, or more specifically cable TV. MSOs have been groping for IP migration strategies for five years, the challenge being to enable emerging IP devices in the home to access content delivered over their QAM infrastructures, transparently without having to run conversion software in the devices themselves. This is not so conveniently done within the cloud, given that each home and its growing constellation of IP devices would have to be addressed separately with individual QAM to IP conversion functions. It would all be rather messy.
Therefore MSOs’ infrastructure vendors, or some of them anyway, answered the call with transport gateways incorporating QAM tuners that convert incoming programming into IP streams that are then transmitted onto devices such as PCs or tablets in the home. Such devices incorporate cable modems and routers, enabling them also to bring in data or video over DOCSIS, and forward to devices over WiFi or wired options such as MOCA. One of the first off the blocks in 2008 was Motorola, but others then piled in, such as Cisco with what it calls a multi-screen gateway.
In the long term no doubt MSOs will migrate to all IP-delivery over one single fat pipe, but that will not happen anytime soon in most cases, and meanwhile the transport gateway answers the call for a migration towards that distant end game. With that in mind, cable operators have been deploying gateways that allow them to extend their QAM services to multiscreen devices and at the same time provide access to OTT content over IP, such as YouTube or Netflix.
There is also a third way ‘ delivery of their own content over IP using bonded DOCSIS 3.0 channels as part of their overall migration strategy towards all IP. The transport gateway should support all three of these options, as well as obvious essential features such as video rendering and the home networking functions of an HD set top box or DVR. It must be capable of being connected to a TV or video device using a traditional output method, usually HDMI these days, replacing the digital set top. Other typical features include DOCSIS 3.0 support coupled with perhaps up to eight downstream channels and four upstream, six tuners if you are lucky, along with MPEG-2 and MPEG-4 transcoding, with WiFi, MOCA and perhaps Home Plug AV physical media support.
Then among capabilities to look for that some gateways do not have is support for unmanaged as well as managed IP devices within the home, which means having the transcoding capability combined with adaptive bit rate streaming to deliver content in the correct format and resolution.
So far from being in opposition to the cloud, the transport gateway is actually part of the migration strategy towards it, certainly for MSOs. It allows introduction of IP and DOCSIS 3.0 based video, while continuing to use the existing multicast HFC infrastructure, which meets the cloud challenge of embracing legacy.
There is another reason why the gateway will survive in the cloud era that has less to do with the TV service itself. This is that the range of connected IP devices within the home will extend beyond video to include many more vaguely defined as belonging to the Internet of Things. This will embrace applications such as energy management and security monitoring, which promise to bring additional revenues for service providers, but only if they are in control of the network that carries the data. Such applications will involve integration with various third parties that pay TV and broadband operators have not had to deal with before, such as security companies, energy utilities and healthcare agencies, and given that these will vary from user to user, doing this within the cloud would not be cost effective or scalable.
This will be much better accomplished via a home gateway device to handle the communications while maintaining separation between applications that will not necessarily interact at all, using different transport, possibly even within the home. For example video may go over WiFi, while signaling data may be transmitted over a different wireless system such as Zigbee or DECT CAT-iq (Cordless Advanced Technology’ Internet and Quality), the extension of the original DECT cordless telephony standard for low bandwidth applications within the home, now gaining interest from broadband providers.
Having established that the gateway will be with us for a while yet, operators will be faced with deciding how and in what form to embrace the cloud within some form of hybrid model. The first point is that the cloud is no universal panacea, and will only deliver on its promises if the correct choices of technology and provider are made. Those promises are elastic provisioning with load balancing to cope with fluctuating demand; reduced storage and processing costs through scale economies and pooling of resources to reduce over provisioning; offloading of complexity through shared effort using common software, standards and components; and faster time to market because changes affecting multiple platforms and end consumer devices can be executed in one place. But a badly configured cloud using the wrong vendors and technologies can fail to deliver on any one or all of these promises, as has already been discovered by some enterprises in their data centers where the model evolved.
For such enterprise IT in the data center, a dichotomy emerged between public clouds, which provide resources, platforms and software shared between multiple clients, and private clouds, built in principle by a single enterprise for its users. At first the private cloud was often dismissed as a second rate option because it failed to benefit from the scale economies possible by sharing infrastructure and services among multiple clients, perhaps at a global scale. The private cloud as originally conceived also failed to deliver another important benefit we have not mentioned so far, which is converting Capex to Opex through a pay as you go model allowing customers to buy resources on demand, only when they need them.
But the distinction became blurred as it was realized that a private cloud could still make use of shared hardware and technology, which itself could be outsourced in the conventional way, making use of virtualized hardware, where a single system may run multiple applications, or alternatively a single application can be split across many servers, the idea being to make optimum use of processing and storage resources.
This blurring of the line between private and public cloud was taken further by Amazon, which has become the world’s most successful public cloud provider with its EC2 (Elastic Compute Cloud). Amazon then launched its Amazon Virtual Private Cloud (VPC), offering a ring fenced firewalled section of the Amazon Web Services Cloud for creating resources in a virtual network that can be defined by the user. The main advantage of VPC over Amazon’s mainstream EC2 public cloud offering is that customers can define their own network topology, select their own range of IP addresses, configure router tables and so on. Of course this is the last thing many cloud customers want, since avoiding such complexities was why they had gone into the cloud into the first place. But for a number of large enterprises, including some pay TV operators, it addressed one major criticism of the public cloud model, which is that it presented an amorphous black box providing little control over end to end security, and making it hard to offer differentiated quality of service.
As Amazon itself claims, VPC allows greater segregation and control, with the ability to create a public-facing subnet for web servers that have access to the Internet, and then locate backend systems such as databases or application servers in a private-facing subnet with no Internet access. It also enables multiple layers of security, including separate security groups and network access control lists, with different access privileges for each subnet connecting to multiple servers ‘ sometimes called ‘instances’ – within the customer’s VPC domain.
Amazon has left its major competitors flailing in the cloud market with its VPC offering especially, with both Microsoft and Google recently enhancing their platforms in an attempt to catch up. The real test perhaps is to assess how elastic these clouds really are, given that is their biggest promise. Elasticity is particularly important for pay TV and broadcasting, where with growing amounts of HD there can be huge swings in data traffic and loading on individual servers. Video content distribution can really stretch elasticity to the limit. It also has rather different dynamics than traditional enterprise data center applications, in that there is a huge bias towards data read rather than write operations. This might seem a relatively arcane technical point, but has great bearing on the performance of a cloud. Providers of cloud services that have not taken this on board will fail to meet their promises over elasticity.
Of course there is plenty of data writing going in the world of pay TV and broadcasting as content is created and edited, for example to add subtitles and graphics. But the scale is not enormous and is rather predictable. Content consumption on the other hand is much harder to predict, and involves a lot of storage access and database reads. Some vendors of cloud technologies have become aware of this, and it will be worth poking around at IBC 2012 coming up in Amsterdam to glimpse at some of the emerging solutions designed to facilitate scalable load balancing across cloud infrastructures.
This brings us neatly back to the home gateway. Network PVR has been touted as a killer app for cloud, even though it has been hampered so far by rights restrictions insisting that each piece of content is stored separately for every user that wants to access it. Even then a cloud offers the potential to make use of archive type storage that costs much less per byte than a home DVR. A greater deterrent is the unpredictable load and bandwidth consumption associated with network PVR. This is a concern that cloud technology and service providers will have to allay.