IPTV: The Need for Standards

Over the last few years, we’ve been witnessing the emergence of a new and exciting medium for carrying digital video to the customer premises. In addition to satellite, cable and terrestrial, broadband data networks supporting Internet protocol (IP) have gained acceptance as a suitable and profitable means of delivering video. Whether one calls it IP television (IPTV), broadband TV or TV over digital subscriber line (DSL), it always refers to the delivery of digital content through the customer’s broadband connection, which was formerly used only for high-speed Internet (and sometimes for IP telephony). But as the deployments of IPTV solutions have begun, and in spite of the fact that its success seems imminent, it’s far from achieved. There is currently no standardized solution for an end-to-end system to deliver rich content over IP. Only a few aspects of such a system have been deeply studied and standardized, and a lot of issues, new to both the broadcasters who produce the content and to operators ensuring its delivery, have yet to be addressed. IPTV today These four letters are on the lips of every carrier, content provider, and consumer electronics manufacturer out there. Indeed, IPTV was still unknown some five years ago. It has now, however, become the most fashionable way to deliver video to a customer. What makes this solution so trendy? We will not go through all the advantages of IPTV here, but flexibility, ease of deployment, interactivity and triple-play readiness are cited often. Of course, the drawbacks are rarely raised, and a few people have spoken about the lossy nature and the range problems of DSL access, not to mention the constraints on the operator network. Nevertheless, the number of deployments, be they commercial or simple trials, is huge for such a young technology, and it keeps increasing. Table 1 illustrates some of the most promising ones in terms of number of potential subscribers. It looks like a success; it tastes like a success. But below the surface of these figures lies the reality. It’s one of battalions of network engineers struggling to maintain a network with tools that are as young as the IPTV solution itself, and legions of system engineers at the equipment providers desperately trying to make machines that were not designed to work together interoperate. It’s scores of customers bombarding the hotlines with complaints. And inevitably, the same excuses arise: The solution is immature, it still needs some adjustments, and so on. But at that point, with millions of customers in place, it is not adjustments that are needed, but a real framework in which IPTV solutions can be implemented and deployed. IPTV needs standards much like satellite or cable networks—probably more so because IP networks were not originally designed for television. Standardizing IPTV Setting a standard for IPTV would be difficult at best. There are multiple areas to cover because IPTV is a very broad subject, and the medium was not intended to transport audio and video when it was created. Moreover, some specific features of this medium allow new services while outdating some of the former schemes based on broadcast. Technical overview The main advantage of IPTV, and in some aspects its main drawback, is that it relies on an existing IP network. On this network, the operator has already deployed high-speed Internet access and may also have put in place IP telephony. Assuming that the core network has sufficient data capacity and that the access network is also suitably proportioned for carrying a video stream, IPTV deployment roughly consists in adding new servers, configuring the network properly, and giving to the customer the proper equipment to receive and decode the stream (an IP set-top box). All this equipment, which would ideally be bought from different providers to maintain the strategy of divide and conquer, will have to interact with each other. Standards will help accelerate implementation of the solution, as well as ensure its operation and the quality of service it will deliver. Many areas are to be covered, and without tackling the physical aspects of the system, we can list the following items. (See Figure 1.) The transport layer We are talking about the network, so the main thing to standardize when tackling the transport of video over a network is how to achieve that. Of course, IP will be the base layer of the transport scheme here. But above that, mainly solutions can be foreseen. Members of the Internet Engineering Task Force have spent a great deal of effort in defining protocols for carrying time-sensitive traffic (audio and video) over an IP network. These efforts are still ongoing, but one of the main achievements is the real-time transport protocol (RTP), which is recognized worldwide as a valuable technique to use when streaming time-sensitive content. But RTP doesn’t solve all the problems because it gives a transport layer for carrying the multimedia streams without specifying how the data will be organized inside this transport layer. Currently, two solutions for that are available. One is directly inherited from the previous digital broadcasting networks (satellite, cable). On these systems, video and audio are encapsulated in an intermediate packetized layer, which is video format agnostic. Called transport stream, it is defined in the Moving Picture Experts Group (MPEG)-2 systems standard and ensures synchronization, signaling and security. The proposed solution consists of carrying the transport stream packets into RTP packets as if they were on an old digital broadcasting network. Since current equipment used on IPTV deployments is often coming from the satellite or cable world, using transport stream encapsulation cuts down on the initial costs of deployment. And because it is a widely deployed solution that has been used for ages, content providers and aggregators are confident with it. But it also brings an additional overhead to the network, where bandwidth and data capacity become scarce resources as we get closer to the customer, and it lacks flexibility and scalability. All the information for a stream must be present in the same transport stream, so it is for instance difficult to propose a lot of audio tracks for a single movie. Another relatively new solution consists of putting the video data directly inside the RTP packets without the transport stream encapsulation. The IETF has issued many recommendations to achieve this for different video formats. It has the advantages of consuming less capacity, allowing more flexibility and scalability, and enabling new features and services easily. The downside may be that it requires changes in broadcasting equipment, many adaptations in current schemes, new schemes altogether, and is strangely new. Both approaches are available and satisfactory—but they are neither compatible nor interoperable. Whereas the Digital Video Broadcasting Forum has issued a standard for the transport stream-based approach, the Internet Streaming Media Alliance has issued specifications using the nontransport-stream based approach. Solving this dilemma would be a first step to get a standardized framework for IPTV. Broadcast TV Broadcast TV is the first purpose of an IPTV system: providing the same basic access to television as if the customer were using cable or satellite. But the comparison stops here. The first issue to solve is how the user will have access to all the services that are available. On a satellite or cable network, it is quite simple since each client has the list of frequencies it can listen to, and when it tunes into one of these frequencies, it receives a flow of data containing all the available channels on that frequency. The client just has to select the one channel it wants according to some information provided inside the data flow. But on an IPTV system, the client cannot receive all the channels simultaneously because of bandwidth limitation. So the traditional scheme doesn’t apply here, and the client must know which IP address (corresponding roughly to the channel and frequency together) from which to receive the data it expects. In a nutshell, the client must have access in advance to the list of the available channels and the corresponding IP addresses, in the most transparent and dynamic way. Up to now, only DVB has worked on that issue, called service discovery and selection (SD&S), and has issued a standard for the market. Moreover, for television, the packets will be carried over multicast IP. This is because it allows a stream to be distributed to all the clients that want to have access to it without duplicating it on the common paths between the server and the clients. This technique is well-established, and it has raised (almost) no problem on the IPTV networks up to now because customers are not allowed to use IP multicast on their high-speed Internet access. But what would happen if an operator wanted to allow the use of IP multicast for its clients in parallel with IPTV? How does the operator ensure that the IP multicast addresses in use for IPTV channels will not be overloaded with other content using the same address (which is possible at the protocol level)? Solutions for that exist in within IETF, but nothing has been specified in any IPTV-related work. Content on demand Content on demand is probably one of the key applications that will drive the success of IPTV. In addition to broadcast TV, the customer can have access to a wide range of content whenever he wants. This feature raises many technical problems, mainly on the network side—for example, how to absorb thousand of simultaneous unicast IP streams on the network, which are dependent on the considered architecture. Nevertheless, some areas can be standardized. For instance, many people agreed on the use of the real-time streaming protocol (RTSP) to control content servers. But this protocol covers a wide range of services, and the way it is used must be specified. Here’s where disagreements begin. Some enable certain options while others don’t; private fields are widely used to carry information that is essential to the system. In short, even using the same protocol, different solutions might not interoperate. A glaring example is the description of the content: The two main solutions available now, DVB and ISMA, are using two different and incompatible ways to describe stored content. In the same context, the storage format for on-demand content could also be specified. Currently, only ISMA has recommended the use of International Standardization Organisation file formats for storage applications. Such a specification would allow the operator to deploy different solutions while using the same content and the same storage facilities. Another possible outcome would help network architects to differentiate between the streaming part of the system and the storage part. The latter could be a separate storage area network, fed by an independent contribution network that may not be aware of the streaming solution in use, and serve multiple solutions. Metadata Metadata are intrinsically part of a digital TV system. In the satellite or cable world, the ability to have a light description of the current program and the next program to come is a well-appreciated feature. In IPTV, because of the always-on return channel, the user experience can be greatly improved if a detailed description of the programs, on air or to come during a large period of time, can be provided on demand. Presentation of this information through an electronic program guide (EPG) is one of the enhancements expected from IPTV. Obviously, the look and feel of an EPG is not to be standardized; that is an element of differentiation among vendors. However, the way the information it contains is formatted, presented and accessed needs to be standardized to allow the exchange of the data independent of the system that will use them. Some solutions exist in the professional world for the description of content (such as the Material Exchange Format, MXF), as well as for the description of TV content to be used in personal video storage (such as TV Anytime). But nothing is integrated so far in an end-to-end specification to provide the customer with valuable and interoperable data to be used in an EPG. Specifying such a framework for the operation on metadata could allow the expected emergence of a rich EPG. Some groups—within DVB, for instance—are working on similar issues, focusing on the TV-related contents. But their work may need to be adapted to cope with IPTV-specific features and to address both operator and customer expectations in that area. Subscriber management Subscriber management is the part of the system that will allow the operator to manage the rights of a customer on the IPTV network, track his actions, bill him accordingly and also manage connected equipment. Carriers already have a user management system for customer access rights and connection parameters. And most of the time, these systems are built on open solutions developed within the IETF or elsewhere. These solutions often work upon the authentication, authorization and accounting (AAA) functionalities required and deployed on large-scale commercial networks. So a basis for an IPTV subscriber management framework exists, but no video-related information is part of such systems. One of the most important features that may be required is security in general and rights management and encryption in particular. This part will manage the content protection scheme on the IPTV system so that only authorized customers will have access to the streams they are allowed to access and will be able to use it in a predefined way. For instance, a user may have access to only a part of the available channel, thanks to the subscription fee he pays (this is the bouquet paradigm), and he may have some additional rights on content, such as the ability to record to his personal video recorder (PVR), keep the content for a certain time, view it a predefined number of times, and so on. In addition to those rights, the protection of content between the server and the customer can be done by encrypting the data, and therefore the system must implement a secure key exchange mechanism so that the customer can decrypt the data and have access to the content he paid for. Currently, this is often done through a mechanism similar to the one deployed on cable and satellite through conditional access (CA) systems. There are a lot of providers of CA systems on the market, which means a lot of different and noninteroperable solutions competing in the broadcast field. But in IPTV systems, the availability of the return channel and the possibility to implement content on demand shows the limits of a broadcast-only oriented solution. For instance, the key distribution mechanisms are built on a unidirectional delivery assumption (no information sent from the customer equipment to the key management system), which prevents the use of the always-on return channel. Therefore, CA systems mainly address access to the broadcast network, but in the case of broadband, access control can be done in other ways (it is one of the functions of the AAA architecture). On the contrary, security systems for IPTV must focus on access to the content, which means protecting the content on its way to the customer, signaling it and distributing the keys for content access to the authorized customer. For video distribution, only ISMA at the moment has issued a specification targeting the protection of audio and video streams over IP (ISMA Crypt), which would be suitable for IPTV. But this specification doesn’t address the key management issues and must therefore be extended. Some other entities are also working on open digital rights management (DRM) systems, but in other fields (mobile, mainly), and their work needs to be adapted to fit IPTV schemes. The use of a DRM system is mandatory for a wider deployment of IPTV. Indeed, content providers want to keep control over their content at any time; therefore, it must be protected in the most efficient way during its life cycle on the network and in the customer premises. Without DRM, the offer of appealing content (especially on demand) as well as future use of the content in the home (whether for storage or family sharing) will not take off, and the future of IPTV will be jeopardized. Another area that may be required for large scale deployments is the remote management of customer equipment. (It is not mandatory because it is not a fundamental building block.) This is an area where a lot of efforts are being deployed at the moment on the operator side, as they absolutely want to control equipment that’s plugged into their network. The work done so far is mainly concentrated in the DSL Forum. Their technical report TR-069 defines a protocol for remote management covering network provisioning, client firmware management, monitoring, identification and diagnostics. Because of the wide recognition of the DSL Forum by operators, this work seems to be a good basis for a common framework for remote management. It must then be checked to verify if it is complete enough for IP set-top box management or if it needs to be adapted. At any rate, remote management would bring an undeniable added value to a system specification for IPTV. The remaining part, such as billing or actions tracking, does not need to be standardized since it’s really not mandatory for a working IPTV system. Conclusion Among the different areas that an IPTV solution needs to address, one can see that the standardization process is in its early stages. Many entities are working on different parts of the system, but there’s little coordination so far. Issuing a standard for one component of a system is a good step forward, but too little. In order to gain acceptance and to reach the technical and commercial success everyone expects from it, the IPTV market must free itself from closed solutions that hamper innovation, development and competition. The future of IPTV can only follow a path close to what the market has witnessed in the traditional broadcast world, notably building an open system that relies on well-defined and open standards. To guarantee interoperability between all the building blocks necessary to make an IPTV system work, a conformance program is critical. The next step is to coordinate the efforts of all entities working in various parts of IPTV. To that end, ISMA has formed a workgroup whose goal is to select the best solutions among those available, to help develop promising solutions, and to identify and fill the gaps for a comprehensive IPTV deployment. Along with its experience in interoperability testing and conformance programs, ISMA’s goal is to build an open solution that would bring maturity and success to the IPTV market. Jean-Francois Fleury is project leader for Thomson Broadband R&D in Beijing. Reach him at [email protected]. This article was adapted from a paper first published in the IBC2005 Conference Publication.