Digital television is happening in many countries and business environments. Its diffusion, however, is not happening at the pace many had predicted in the past and many are expecting now. The main reason lies in the proprietary nature of set top box (STB) access control (AC), the technology that allows a Service Provider (SP) to permit access to content only to those who have acquired the necessary rights. This situation has produced unreasonably expensive STBs, market segmentation with a reduced number of customers in each segment, heavy subsidisation of STBs or commitment of substantial resources to lease STBs on the part of SPs, regulatory interventions in certain countries where efforts to achieve a larger audience on the part of SPs are thwarted by regulators as anti-competitive.
This was probably unavoidable until a few years ago because of technology limitation. Fortunately it is now possible to develop open specifications that will allow users to navigate, select, pay and view the offers of any SP.
The Open Platform Initiative for Multimedia Access (OPIMA) is a recently-established industry consortium with the goal of developing such open specifications by September 1999. A Call for Proposals (CfP) has been issued in May (http://www.cselt.it/ufv/leonardo/opima). This requests interested parties to submit proposals of technologies that are believed to enable the attainment of OPIMA goals. Deadline for submissions is 31st August 1998.
This paper describes the hooks provided by the MPEG-2 standard for access control (section 2.), its limits (section 3.) and the solutions developed so far, the new possibilities offered by technology (section 4.), the requirements that an open solution brings forward (section 5.) and the OPIMA reference architecture. Sections 4. to 6. draw heavily from the said CfP.
2. MPEG-2 and its legacy
Three and a half years after MPEG-2 reached International Standard status it may be time to have a dispassionate look at the practical results of the international collaborative effort that produced such a renowned standard.
MPEG-2 Video is capable of compressing the 166 Mbit/s of ITU-R 601 to a few Mbit/s. The MPEG-2 Video verification test campaign has proved that at 6 Mbit/s MPEG-2 pictures are subjectively equivalent to composite video in the studio. The same tests has proved that at 9 Mbit/s MPEG-2 pictures are subjectively equivalent to component video in the studio These result apply for Constant Bit Rate (CBR). Even more interesting results can be obtained by the use of Variable Bit Rate (VBR) coding, even though publicly available results produced by independent bodies are not known.
MPEG-1 Audio, used in many digital television systems in practical use, is capable of compressing the 1.5 Mbit/s of a stereo channel sampled at 48 kHz down to 256 kbit/s with subjective transparency. MPEG-2 Audio Backwards Compatible (BC) mode compresses 5.1 sound with good quality down to 320 kbit/s, while MPEG-2 Advanced Audio Coding (AAC) compresses a stereo channel at 128 kbit/s and 5.1 sound at 320 kbit/s transparently.
MPEG-2 Systems provides multiplexing and synchronisation of audio and video in addition to a host of other functionalities. The Transport Stream version provides physical layer adaptation for transmission over a hostile environment while the Program Stream, unsuitable in general to transmission over an error-prone channel, provides other features such as editability.
In other words MPEG-2, in its Transport Stream version, provides the one-stop shop for the digitisation of analogue television and, in its Program Stream version, the ideal solution for locally interactive television, thanks also to the very high performance of the audio and video coding algorithms. This has decreed the success of MPEG-2 to the extent that today MPEG-2 decoding chips are worth a few dollars and are available from multiple sources. MPEG has created a single common digital television industry that did not exist before!
Television, it must be remembered, is not just about Hertz and bits. Television is a business. MPEG was not just populated by engineers, incidentally, the best in the world. That is why MPEG-2 contains two features in support of those who want to use the standard as a tool for their business.
The first feature is the so-called Copyright Identifier. The audio and video components individually, as well as their combination at the systems layer, can be identified by a number assigned by an agency managing the rights of those streams. In its turn the agency is identified by a number assigned by an ISO-appointed Registration Authority.
The second feature is provided by the so-called Entitlement Control Messages (ECM) and Entitlement Management Messages (EMM). These provide an infrastructure that enables the sending of the audio-visual payload descrambling keys to remote decoders.
Fig. 1 The role of ECM and EMM in MPEG-2 (example)
The payload is scrambled with a control word. This is sent scrambled with a service key via an ECM message. The control word is changed with a period of the order of 1 second. The service key is scrambled using a key drawn from the users data base and sent via an EMM message. As all users must receive the scrambled service key, this information reaches the intended user with a period of the order of 1 hour. At the receiver the scrambled service key is extracted from the EMM message, and is converted to clear text using the key stored in a smart card. In its turn this descrambles the control word which can eventually be used to descramble the audio-visual payload. This is where MPEG-2 Systems stops. Nothing is said about the nature of the keys, the scrambling algorithms etc.
3. The limits of MPEG-2 and its extensions
This was probably as much as an international body like ISO could specify in 1994, when MPEG-2 received its final touches. Therefore MPEG-2 has produced a standard technology where clear text transmission is universally interoperable, but encrypted transmission is SP-specific, unless a standard interface is defined that separates the source decoding and multiplexing from the content management and protection.
Several attempts have been made to make the system more open. A single STB may still be used to view different SPs if they team up to provide common access to their combined services. This is the so-called "Simulcrypt" (see Fig. 2).
Fig. 2 - Simulcrypt
In this case SP1 and SP2 send EMM messages (dotted lines) to the combined set of their subscribers, so that encrypted content (full lines) from both SP1 and SP2 can be viewed by subscribers of both. The shortcoming is that users can still view content that comes from somebody not selected by him/her but by somebody else for which they have no control.
Other attempts were made by industry consortia to decouple MPEG-2 decoding from access control. Two of these consortia are the European project Digital Video Broadcasting (DVB) and the international consortium called Digital Audio-Visual Council (DAVIC).
Fig. 3 - The DVB and DAVIC interfaces
Fig. 3 represents the two interfaces CA0 (defined by DVB and called Common Interface CI) and CA1 (defined by DAVIC). CA0 is simply an interface where an external, SP-specific, box is plugged: high bitrate scrambled streams enter the box and leave the box in clear text. CA1 is a more elaborate interface where low bitrate signals such as ECM and EMM enter an external device (a smart card) and the control word enters the set top box.
Both solutions are still to see large scale deployment. This means that the STB is SP-specific and, if one wishes to view content from more than one SP, in general one needs more than one STB. Apparently, a contradiction was not perceived by European regulators when they mandated, in one of their directives, the use of MPEG-2 for source coding and multiplexing but remained silent about the access control part. Much as the author is flattered by the idea that the use of MPEG-2 is made legally binding in European digital television, he is riddled with doubts about its value. If the STB is proprietary, so could be source coding and multiplexing.
4. What users would like
The absence of standard STBs enabling access to multiple SPs is one of the causes why digital television services are having a slow take off. Fig. 5 illustrates what is the desire of the vast majority of people (next to view content for free).
Fig. 4 An ideal digital television world
The user would like to be able to navigate through the different offers of multiple SPs, choose the one that is most interesting or convenient, pay and view. And that without even the need to stand up from the armchair in which he/she is sitting.
This is what the OPIMA has set out to make possible. OPIMA is based on the belief that the market would see a faster development if a standardised technology existed that would allow a user to acquire a device, and consume and pay for services, without having prior knowledge of which services would be consumed, in a simple way such as by operating a remote control device.
OPIMA seeks to support the basic services and service models such as
While a new technology is being developed it may be interesting to see whether other services cannot be supported, e.g.
This section deals with the requirements OPIMA has developed for its platform. The word "shall" is used to indicate that a certain feature shall mandatorily be supported while "may" indicates that the feature may be supported if possible.
The platform shall be as open as possible. In particular, the platform:
The platform needs to be secure and trustworthy. This means that:
If different levels of security and robustness against piracy are allowed, systems with lower security levels shall never be able to compromise systems with higher security levels.
The platform shall support access control by
The platform shall support service models in which the users identity is not disclosed to the service provider and/or to other parties.
This section lists requirements in the area of the type of connection and the form of interaction.
The following types of connection shall be supported:
a. Broadcast, with the following return channel characterisations:
- without return channel
- with intermittent return channel
- with persistent return channel
b. Interactive, with the following return channel characterisations:
- symmetric and asymmetric bandwidth
- similar or different paths to and from the user
It is understood that these models and their sub-categories are not mutually exclusive.
Along a slightly different axis describing the connection, the platform shall be able to support:
Along the same axis, the following may also be supported:
The platform shall at least support:
In addition, it may also support:
The platform shall allow a wide range of transaction models. At least the following types of transactions shall be supported:
Both on-line and off-line connection modes are foreseen with these types of transactions. Please indicate which types of transactions are supported for each of the connection modes.
Again it is recognised that these transaction models are not mutually exclusive.
A device is a system that is used to access and consume information. In principle, the platform shall support any device that can be used to consume multimedia services. At least the following devices need to be supported:
The platform shall support mobility. In particular, it shall:
It is to be noted that user mobility could be provided through personalisation and the usage of user profiles.
The focus of OPIMA is currently on the relationship between the end user, and the service provider. It is recognised that many other roles exist in the value network. The platform shall not exclude the interests of these parties from being served.
These parties include:
- on content
- on algorithms (e.g., coding algorithms)
It is understood that several of these roles can be unified in one entity.
6. The OPIMA Reference Architecture
Fig. 6 is a representation of the system addressed by OPIMA specifications. It comprises four entities: the Service Provider System (SP), the Service Provider Support (SP') as seen from the end-terminal perspective, the trusted middleware (TMW); and the Smart Card (SC). In principle, OPIMA specifications can address any subsystem in a similar context.
Fig. 6 - The OPIMA Reference Model
Notes to the picture:
Smart Card (SC)
The smart card is viewed as the user identification and service enabling module. The smart card may be provided to a consumer by a Service Provider or an independent vendor. It should not be limited to enabling access to a single service provider or to a single application. The smart card should be a secure environment whose integrity the consumer is confident of.
Service Provider System (SP) and Service Provider Support (SP')
The service provider is an entity which presents a unified image to a consumer who wishes to consume the services or products offered by the service provider. A service provider may have unique and proprietary applications requirements and interfaces. These are made transparent to the consumer by a secure download technology enabled by an OPIMA compliant terminal. This is accomplished by the presence of a generic (and secure) service provider support function (SP') in combination with a trusted middleware component (TMW) that is resident in each OPIMA compliant terminal at the time of manufacture.
Legitimate Third Party
A legitimate third party (LTP) is an entity whose presence in the system is authorised. This excludes unauthorised third parties such as pirates. The presence of an LTP is optional.
Trusted Middleware (TMW)
Trusted Middleware (TMW) is the core element in the systems ability to provide secure and trusted services. Only a certified middleware component has the ability to incorporate and certify additional or replacement functionalities including replacing itself in a trusted manner.
The trusted middleware component is capable of communicating with the smart card and the service provider support functions. The trusted middleware component manufactured within each OPIMA terminal contains the necessary functions to facilitate the addition of the Service Provider elements of the TMW. This can be achieved via secure download or other trusted methodology. The basic TMW, without any additional elements, will allow the operation of the basic functions for which the terminal is intended. For example, a digital television without these additional elements can receive and display free TV services.
Functions that are specific to individual Service Providers may be added to the basic TMW. This allows one or more service providers to offer available services on an OPIMA terminal. Security and application protection and management are required when additional service enabling is provided.
The SP' and TMW functionality may be combined in a single entity. If they are not, an interface such as IEEE 1394 may be used.
6.2 The OPIMA approach to specifications
21st, The VXM Network, http://www.vxm.com