Cisco bids to control IPTV
Grabs for underlying architecture
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.
Sponsored: DevOps and continuous delivery