Original URL: https://www.theregister.com/2006/12/15/cisco_iptv/
Cisco bids to control IPTV
Grabs for underlying architecture
Posted in Channel, 15th December 2006 08:59 GMT
Analysis Cisco has virtually re-invented IPTV services by dropping key elements of the IPTV experience – VoD, network PVR, fast channel change and packet re-transmission – down a layer into the network layer, sitting on Cisco routers and servers in the network.
The announcements virtually give all the feature functionality that Microsoft has spent three years trying to bring into IPTV at the application layer but lowers the capabilities firmly into Cisco network components.
Cisco is calling the key announcement Visual Quality Experience (VQE), effectively a network appliance that services requests for replacements for lost video packets. But it can also be configured to serve requests for fast channel change information.
One of the problems with IPTV the way it is implemented in most instances, is that the bit error ratio – the number of packet errors naturally occurring in a piece of DSL copper wire – are too numerous for error correction to handle on its own. When this results in an error in an I-frame which provides references points for other frames, an IPTV system cannot render the next 12 or so frames accurately. This affects around half a second of video, and during that time the screen becomes pixellated and unviewable and then rights itself.
This means that copper just won’t cut it when the system moves up to High Definition TV, when around 5 times as much data needs to be sent across the network. The result is that a pixellated frame, referred to as a visual artifact, happens around twice an hour, making it pointless to have a near perfect picture.
As more of the tools in H.264 compression codecs are used, designers want to be able to compress the bit stream further by referring to any of the most recent I-Frames, not just the last one, but in order to do this they would increase the frequency of visual artifacts, unless they had error free transmission.
The internet can manage this using the TCP part of the internet protocol, but it is very difficult and wasteful of network resources to implement this in the multicasting protocol IGMP which is the broadcast element in IPTV. So instead the simpler UDP is used to deliver internet packets in IPTV systems. As a result there are no packet re-transmissions in any IPTV systems that we know of except one designed into Fastweb.
Fastweb supplier Bitband placed packet re-transmissions into the application layer, and increased the buffer size in the set top to allow time for a re-transmission of lost packets, allowing enough time to reinsert them in the right place.
Now Cisco is doing this using the fastest element of the network, the 7600 Series routers that it will pitch to drive the multicast sessions, and reckons that packet retransmissions can be achieved in 100 milliseconds, which is less than the buffer period in existing IPTV set tops.
It will take some re-coding to use this new capability and other new Cisco capabilities, at the set top level, but it should be available in simple standard protocol calls once a network operator chooses to install it.
Cisco says that it is all based on industry standards, including Realtime Transport Control Protocol (RTCP) and Real-time Transport Protocol (RTP), initially shipping as an appliance, and later to be integrated into Cisco 7600 Series routers, which will have to continue to hold copies of the relevant internet packets for a slightly longer period.
This Cisco product might just as well have been invented directly for AT&T, and its well publicized issues with error correction as the way to go in IPTV, as prescribed by Microsoft’s IPTV system. Microsoft itself has gone on record pointing out that using advanced error correction does not exclude the use of packet re-transmission, in parallel and so may welcome this move.
But the genius in this announcement is that after all the fuss that Microsoft went to, to alter the format of IPTV, by introducing fast channel change from network servers, achieved by blending unicast data gradually with the multicast, has been copied by Cisco, but in the router.
So once a channel change is issued by a set top the system must calculate what I-frames it needs to render the next frame, and get them to the set top at breakneck speed, and instead of going back to the head end, they are supplied by the nearest Cisco 7600 router. This happens in parallel with subscribing to a new multicast channel. The two streams of data must be “blended” at the set top, so that it doesn’t attempt to render a frame before it is ready, but once again by putting this job into the fastest elements of the network, Cisco can ensure that this happens before the buffer from the last program has departed the set top, and before it fills the buffer for the channel change.
We think the channel change will come down to around 350 to 500 milliseconds before it is totally complete, which is roughly in line with the Microsoft IPTV system.
Cisco also announced other features relating to troubleshooting and proactive operator alerts to go with this VQE system.
The other half of the Cisco announcements relate to what sounds like a simple server architecture which allows modular upgrades to VoD servers and adds the load balancing and resilience that Cisco is used to adding for internet web servers.
Cisco calls the new VoD device its Content Delivery System (CDS) which it says will support VoD, network PVR, time-shift TV, but will also support multiple device types, so that VoD can be served just as well to PCs and handsets, as much as to set tops, managing the screen resizing and protocol differences. The system can also splice each video stream with its own advertising and Cisco says that it will be ready for a future when operators choose to offer targeted advertising or personalized content.
The Cisco CDS consists of networked Cisco Content Delivery Engines (CDEs) which can ingest, store, distribute, personalize, and stream content. These are grouped into arrays for storage and/or streaming, working together as a single logical system. Capacity can be expanded by simply attaching additional CDEs to the array.
In August Cisco bought privately held Arroyo Video Solutions, an on-demand TV server business, for about $92m in cash and it is likely that the Arroyo product line forms the basis of this announcement, but even if it is, there is a heavy hand of Cisco know-how in this announcement.
Cisco claims that the load balancing and resource pooling means that this systems has virtually nonstop service availability and if a CDE fails or is taken offline for maintenance, the platform continues to deliver uninterrupted video services to subscribers, without the need for idle standby units.
Another idea has been taken here from the original Fastweb IPTV system, which allowed for a central cache of content and then edge caching for the most popular content, again designed by Bitband.
Cisco’s system is perhaps even more efficient, eliminating the need to pre-position content at every streaming node. Instead its intelligent edge caching reduces bandwidth requirements on the network backbone by 95 per cent, but ensures that delivery of any VoD content begins within 300 milliseconds regardless of where the content is stored within the network.
A single Cisco CDE can work up to 12 Gbps of streaming bandwidth and can support a maximum ingest rate of more than 750 Mbps, and store a total of 12 TB of content.
Our take on all of this is that Cisco is putting the core IPTV intelligence into the network, at a level so deep that it will be difficult to beat. This can be harnessed by virtually any software above, mostly needing some re-coding at the set top, which of course Cisco can always supply through Kiss and Scientific Atlanta. In this way Cisco attacks Alcatel in IPTV, but not Microsoft nor any other vendor offering middleware only.
So while Cisco would be happy to support Alcatel’s OMP or Lucent’s Imagenio with these capabilities, we know that Alcatel would then lose key elements of the network equipment contract. Similarly Siemens would do the same when it implements Surpass and Myrio. We understand that Cisco has built implementation teams for Minerva IPTV software and it is likely to do this for other middleware systems.
What each of these can now do is sign up with Cisco, and go to their respective operators and say “If you want all the capabilities promised by Microsoft, we can now give you that with our software and our new partner Cisco,” which has a very credible ring to it, and which also drags Cisco into every IPTV RFQ out there.
Copyright © 2006, Faultline
Faultline is published by Rethink Research, a London-based publishing and consulting firm. This weekly newsletter is an assessment of the impact of the week's events in the world of digital media. Faultline is where media meets technology. Subscription details here.