Some service providers and also vendors have been dazzled by the bright lights of OTT into exiting the IPTV field just when it is looking fit for purpose itself. They have been swayed by the promise of OTT to break out from the shackles imposed by the walled garden of IPTV and deliver TV Everywhere, both to existing subscribers when away from home and off footprint to new customers.
All this is well and good but wise heads within the industry can see there is plenty of life left in IPTV, not just in developing markets where it is set for huge growth, but also mature ones where IPTV is becoming more competitive through its increasing ability to deliver multichannel premium quality HD services combined with catch up, network PVR and interactive TV. This is leading to talk of IPTV 2.0, which will sound like d’j’ vu to those who can recall Cisco and a few others using the term back in 2006, but then oddly for the idea of the network as a platform enabling users to become their own broadcasters by creating and distributing content.
This time round a few specialist vendors such as Broadpeak and Edgeware, along again with Cisco, are hijacking the term to denote the maturation of server, caching, CDN and streaming technologies to convert IPTV into a blazing platform with all the advantages of IP in terms of interactivity and network efficiency through use of IP multicast, while at last approaching the broadcast capacity of cable or satellite. IPTV will also be able to benefit from investment made for OTT in CDNs and adaptive bit rate streaming (ABRS) to solve lingering performance issues, particularly over DSL networks where bandwidth can still be a significant constraint over ability to deliver premium services. After all many so called IPTV services have really been hybrids reliant on traditional broadcast media for linear programming, most commonly digital terrestrial and IP delivery. The IP part is usually confined to VoD delivery.
Bandwidth constraints are lifting with increased fiber penetration, either reaching the home or more commonly getting close enough to enable VDSL 2 over copper to achieve bit rates up to 100 Mbps, with the assistance of vectoring technology to mitigate crosstalk interference between adjacent wires. The ratification early in 2013 of HEVC (High Efficiency Video Coding) was also a big step forward by halving the bit rate required for a given video quality compared with H.264 and with potential to do even better than this at high resolutions. This is because at higher resolutions there are more pixels representing picture areas such as sky which vary little in color, increasing scope for compression.
For IPTV this can either increase the quality of experience across the existing base, or extend the range of premium services further out from the DSLAM to increase the customer base. Orange has been deploying HEVC for both these use cases for Europe’s largest IPTV service, although confined initially to Samsung smart TVs which support the codec. Orange’s partnership with Samsung over HEVC was announced at the Consumer Electronics Show in Las Vegas in January 2013, accompanied by a demo of a full HD movie at 1080p resolution (1920 x 1080 at 24 fps), streaming at just 3 Mbps, while H.264 struggles to manage with 6 Mbps. Most HD services are currently only 720p or 1080i for linear TV and these could be delivered via HEVC at 2 Mbps or less.
Even with HEVC and VDSL2, IPTV is still subject to the vagaries of IP transmission, with the potential for dropped packets and occasional congestion imposing unacceptable delays, even on the best managed IP core networks. Being a connectionless protocol, IP packets enter an IP network without a guaranteed path to their destination, which means that transit cannot be guaranteed given varying traffic levels that can impose different delays at router nodes on the network. To some extent this was fixed by MPLS (Multi Protocol Label Switching), which effectively nails down an end to end path through the network for the duration of a session, but even this cannot guarantee that such a path will always be available at the desired bandwidth at the time required.
CDNs have evolved to provide higher levels of assurance, but to achieve efficient distribution IP multicast is deployed to avoid transmitting the same linear programming more than once across any given network hop while pruning back to avoid sending channels at all when there is nobody downstream wanting to receive them. But IP multicast comes at a price, in that it cannot be used with the TCP transport protocol which guarantees IP packet delivery. This is because multicast is a subscription based mechanism sending the same information to multiple subscribers, while TCP by its nature is unicast, or one to one, because it requires a message back from the destination to tell whether each packet has been received or not. If there are multiple destinations, some may have received the packets and others not.
As a result multicast is usually deployed with UDP (User Datagram Protocol) with no acknowledgement, so that other methods have to be deployed to overcome packet loss. The first line of defense is Forward Error Correction (FEC), which trades extra bandwidth for resilience against packet loss, with various methods that have improved in efficiency to minimize the network capacity overhead. However even the latest FEC techniques can only cope with relatively low levels of packet loss without imposing unacceptable bandwidth overhead and so local caching combined with acknowledgement has emerged as a second line of defense. Cisco for example has deployed RTCP (Real Time Control Protocol) with NACK (Negative Acknowledgement) and local caching to enable packets that are still lost despite FEC’s efforts to be resent. This is like a local level of TCP, except that messages are only sent when packets have not been received, for improved efficiency. Also by coming from a local cache latency is kept down, this being another reason TCP is often unsuitable for distributing linear video services.
Cisco also has other techniques for optimizing video transmission in the core network, such as embedded flow monitoring to provide a degree of content awareness in following relevant packets through the network, so that remedial action can be taken in the event of congestion occurring, to avoid packets effectively being lost as a result of excessive delays.
Apart from packet loss, video quality is affected by variations in available bit rate, which is a major factor for OTT but also for IPTV. Here ABRS has potential for IPTV as well to ensure that the best QoS possible is delivered for prevailing network conditions. The problem is that ABRS normally requires the client to select the chunk stream on the basis that only it can see what bandwidth is available at a given time.
However we are now seeing server side versions of ABRS being deployed, for example from Broadpeak with its C-CAS (CAS Compliant Adaptive Streaming). Here the server rather than the client player selects the appropriate streaming quality based on available bandwidth, which relies on monitoring on an end to end basis, although without the ability to drill right down into the client to assess its current playback capability as is possible with standard client side ABRS. C-CAS is available for any pay TV operator migrating to IP architectures, including MSOs and DTH providers, but is pitched particularly at established IPTV services. Its key advantage is its ability to work with legacy set tops, while still delivering most of the benefits of ABRS. Operators can continue using their CAS (Conditional Access System) without having to change the firmware in their set tops. Like HEVC, ABRS can improve quality for existing customers while also extending the range of IPTV, although the level of improvement is less predictable.
Broadpeak has another trick up its sleeve for IPTV with its nanoCDN, which extends the benefits of multicasting right across the access layer to the home for multiscreen services. Normally to serve multiple devices within the home IPTV establishes unicast sessions with each device, even when two or more are consuming the same linear content. But with nanoCDN, the set top or gateway in the home becomes the end node in the CDN, replicating content to the devices in the home. This therefore can only work for IPTV operators as they own the access network that is now part of the CDN, making it easier for them to support multiscreen devices via their existing infrastructure without to having to increase their DSL bandwidth.
Although legacy IPTV operators are the main target for many of these innovations, as they present a captive market, most of them are equally applicable to Telcos entering the IPTV field for the first time. For this reason some of these mechanisms are being adopted by providers of wholesale IPTV services, such as Netstream in Switzerland, which has amassed a loose coalition of infrastructure partners to meet demand for IPTV 2.0. Foremost among them is Edgeware, whose Distributed Video Delivery Network (D-VDN) package for multiscreen delivery was released at TV Connect in London in March.
The main pitch there was scalability through distributed clustering to enable services to be extended in distance and subscriber numbers through addition of individual servers closer to the end points. Like Broadpeak’s C-CAS this supports ABRS combined with real time monitoring and analytics to provide feedback for optimizing the delivery to large numbers of devices.
Each cluster operates effectively as a single server and can be built up as required to keep the use of the backhaul network behind it within acceptable levels, just to serve less popular niche content. The clusters can also be arranged in a hierarchy to fine tune the process further so that intermediate content could be held in a middle layer.
Netstream uses Edgeware’s D-VDN to support nPVR and VOD for several Swiss ISPs, with other partners including Harmonic for the IPTV headend with encoding, and Agama for monitoring.