A number of respondents to our study have indicated that industry remains concerned that the existing regulatory framework applied to CAS may be extended to APIs without a thorough analysis and assessment of perceived competitive problems that relate to ensuring interoperability of iTV services.
Accordingly, the Commission has asked us to consider whether the development of common authoring tools can address perceived barriers to the development and delivery of interactive television, or iTV, and whether this would reduce the need to consider mandating API standards or imposing API access obligations. In particular, we have been asked to consider the links between such authoring tools,
interoperability and access.
The European institutions have recently re-emphasized the importance that is placed on developing Information Society services and other e-services, and ensuring that they are available to as many European citizens, over the broadest range of platforms
and using the widest variety of end user terminals as is possible.81 In this light, this chapter briefly describes the types and forms of iTV content to which that term refers, before identifying the potential barrier to competition, otherwise characterised as an interoperability issue, that we consider to be relevant to authoring tools (i.e.,
portability of content/ applications). In doing so, we will seek to draw out each factor that impacts on cross-platform portability of iTV services. It concludes by assessing the extent to which the development and adoption of common authoring formats might facilitate porting.
What is iTV?
We have considered the types of services that should be encompassed in an
examination of the potential role of authoring tools in relation to the development and delivery of iTV. In essence, this chapter focuses on interactive services that are designed specifically for TV, both:
• enhanced TV services (based on the programmed or cyclical downloading of data associated with signals from a linear TV service), including services providing viewers with the ability to bet on the video content, choose camera angles or ‘play-at-home’ quiz games. A return path may or may not be required;82 and
• non-TV-related or ‘interactive’ services (e.g., banking, shopping and games).83
81
See, inter alia, the “Communication from the Commission to the European
Parliament, the Council, the European Economic and Social Committee and the Committee of the Regions on Barriers to widespread access to new services and applications of the information society through open platforms in digital television and third generation mobile communications”, 9 July 2003, COM(2003)410 final.
82
Enhanced television consists of the transmission of the televised programme along with related complementary information. This information can be any
combination of texts, images, sound and/ or video sequences, and is usually linked to the course of the programme. As such, it is valid for a limited duration (defined by the programme broadcaster). The video stream may not be interrupted by accessing complementary information, in that information continues to be displayed as a
‘vignette’ or in the background (where the complementary information is embedded in the video image) or the viewer may have to quit the programme in order to access to complementary information. Enhanced television relies on local interaction between the user and the application temporarily residing in the receiver, rather than a return channel.
83
Non-related TV services also involve the broadcast of textual information, sound, images and video destined for TV reception, but does not necessarily imply the presence of, or any links to, a continuous stream of video images. These
applications generally require an interaction channel, usually via integrated modem communication (over the PSTN or a bi-directional cable network).
The chapter does not expressly consider VoD or NVoD, because such services currently operate essentially as advanced pay-per-view services (allowing viewers to choose both the programme and the viewing time). Nor does it consider Internet access services accessed via TV sets, entailing “full screen” Internet browsing using a keyboard and Internet-specific software. However, we note that such services must be considered in developing medium-term iTV policy, to ensure that the service and platform convergence that they represent is not hampered by policy decisions. Finally, we note that the production and delivery of, and consumer demand for, iTV content and applications is currently embryonic at best across the Member States. In addition, it does not appear that there is a significant amount of pent up demand for such services. A Statistical Research Institute survey performed in the second half of 2002 indicated that 72% of the consumers surveyed did not want iTV services, with very similar results among those have currently have, and those who do not have, such services.84
Potential barriers to competition in the supply of iTV services
Much of the current debate about APIs and their potential to function as barriers to the supply of iTV services centres on whether STBs, containing APIs, are
“interoperable”. The interoperability concept appears to be being used in a number of senses in this debate, including:
• the ability to be able to run an application or service on any appropriately configured delivery platform;
• compatibility across interactive digital services and applications that require consumer-side middleware to support them;
• the operation of receiving equipment between networks (supporting delivery platforms); and
• the ability of networks to inter-work with other networks.
Broadly speaking, it appears that the concept is being used to embrace two distinct ‘families’ of interpretability issues related to the development of iTV services, namely:
• content/ application - the ability of content/ application producers to author once and to then port the content/ application between networks (or varying
capabilities) with the minimum amount of reauthoring possible and the reciprocal ability of consumers to access content so authored;85 and
84
Quoted in “ITV Standards: The Interoperability Challenge”, Patrick Griffis, Nov- Dec 2002, at www.studio-systems.com/Broadcasting/NovDec2002/ITV%20Standards/94.htm.
85
In this respect, Recital 31 of the Framework Directive refers to interoperability of digital iTV services at the consumer level, in order to ensure the free flow of
information, media pluralism and cultural diversity. It goes on to provide that it is desirable for consumers to have the capability of receiving, regardless of the transmission mode, all digital iTV services.
• network/ equipment – the ability of all receivers (STBs) to be successfully used on all or most multiple networks and delivery platforms.
It is clear that authoring tools do not provide effective mechanisms to facilitate the compatibility of all receivers with all platforms. As such, they will in no way facilitate consumers switching between platforms (or operators) without being required to acquire terminal equipment (i.e., STBs) that is compatible with the platform to which they are switching.86 Equally, it is clear that authoring tools have the ability to facilitate the cross-platform availability of iTV services, Information Society services and other e-services, ensuring that they are available to as many European citizens, over the broadest range of platforms and using the widest variety of end user terminals, as is possible.
The adoption of a standardised API (whether mandated or on a voluntary basis) would address both the content/ application and network/ equipment families of interoperability issues identified above. However, the Commission may only mandate a standard,87 under Article 17(3) of the Framework Directive, to “the extent strictly
necessary to ensure [interoperability of services] and to ensure freedom of choice for users.” The balance of this chapter considers the potential role of authoring tools in
facilitating the production of interoperable iTV services, in an effort to provide guidance as to the extent to which it is ‘strictly necessary’ to mandate an API standard to ensure service interoperability.
Issues associated with the porting of content/ applications
The fundamental issue in relation to the production of, and receipt of, iTV content and applications is whether they can be made portable across platforms (i.e., can they be authored in a manner that ensures that they are compatible with, and run on, at least the vast majority of platforms (including their middleware). A number of factors tend to reduce the extent to which content and applications can be ported, namely:
• transmission bandwidth (particularly the return channel);
• network integration;
• computational (or ‘processing’) resources in the STB;
• different APIs in the STBs;
• transaction processing; and
• linguistic and cultural issues.
86
Article 17 of the Framework Directive is directed at these issues.
87
It would appear that the existing variety of standards in the installed bases of STBs across the Member States would render it difficult to permit standardisation by individual Member States, without infringing the single market principles enshrined in the Treaty.
This section describes each of these issues and reflects estimates of portion of authoring costs that industry have indicated that they would attribute to each of these issues.
Transmission Bandwidth
There are significant differences in (down-link) transmission capacity between networks. In general, satellite tends to have the largest available capacity; terrestrial has considerably less (due to both a smaller number of available channels and lower transmission capacity per channel). In the UK, for example, Freeview carries 27 TV channels, 4 interactive services and 12 radio channels. Sky carries 331 TV channels, 182 interactive services and 67 radio channels. As such, the balance between
providing services on TV channels (which can be locally stored on the STB for access to a limited interactive experience) and interactive channels differs between platforms (in addition to the clear raw capacity-related distinctions). Resizing content/
applications requires reworking of code, graphics and data to adjust to the amount of available bandwidth, particularly when downsizing.
There are also not insignificant differences in the return paths. Cable STBs (with cable modems) give a relatively high bandwidth, always-on connection. Satellite and terrestrial STBs have used telecommunications modems, to date, providing a
relatively low bandwidth, dial-up connection. The characteristics of the different return paths require content reauthoring to allow for the speed and availability
differences between platforms. Even more reauthoring is required to adapt services to run without any return path (e.g., through storage of functionality that has some interactive characteristics on the STB).
It is useful to consider the different approaches required for the different return paths by reference to an example, i.e. a pay-for-play gaming application. Platforms without a return path can provide such services only using ‘pre-paid’ credits stored on the STB (credited by the operator in response to a call from the consumer requesting crediting) and paid for either in advance or billed on the next periodic bill. Platforms with dial-up return paths could use the narrowband return path, with explicit
authorisation from the consumer to do so. Platforms with an always on return path can interact with the consumer in real-time, requiring and obtaining consumer authorisation at the outset. Adjusting content/ applications for this wide range of alternatives requires significant adjustments to code, graphics and data.
The BBC has noted that cross-platform divergence is more a result of the different technical capabilities of the different platforms than of the divergence in APIs.88
88
BBC R&D White Paper “Delivering Interactive DTV services to multiple target
Network integration
The dynamic function of a number of iTV applications, including current news headlines, weekly game shows with a ‘play at home’ element, seasonal sports coverage and services leading to the delivery of goods (including pizzas etc), uses network infrastructure to access information necessary to trigger interactive elements. Porting such applications requires integration work with the operator’s head-end equipment and servers.
The costs of reauthoring content/ applications to address such integration issues clearly vary on a case-by-case basis. However, Open TV has indicated to us that its own experience with porting dynamic data indicates that infrastructure-related porting costs alone frequently amount to 20% of the original application cost.
Computational/ processing resources
In the initial stages of DTV deployment, STBs with mid-range processing capacity were deployed, at least in part to manage costs while volumes increased and economies of scale in production developed. However, the range of STBs is
increasingly diversifying, from basic “zapper” STBs with little functionality to high-end STBs (some incorporating sophisticated functionality like PVRs). The processing capabilities of a selection of currently available STBs is set out in Figure 4.2, below.
Figure 4.2 Processing Capacity of STBs.
STB Processor RAM ROM
Zapper 30 MHz+ 1-2 MB 1-2 MB
MHEG-5 50 MHz+ 4 MB 2 MB
OpenTV 50 MHz+ 4-8 MB 4 MB
MediaHighway 50 MHz+ 4-8 MB 4 MB
MHP Interactive Broadcast Profile 80-130 MHz+ 8-16 MB 8 MB
MHP Internet Access Profile 150-200 MHz+ 16-32 MB 16 MB
A white paper produced by Philips, Sony, Panasonic and Nokia89 states that, when comparing like with like, the bill-of-materials90 cost difference between MHP
89
“The Costs of MHP in television receivers”, Philips, Sony, Panasonic, Nokia, undated.
90
The bill-of-materials figures in the paper include, in addition to the costs of building STBs with additional processing capability, the total costs of all components. It should also be noted that the white paper (and the numbers that it contains) reflects the technical characteristics (in terms of processor, RAM and ROM) set out in 3.4,
Interactive and Open TV/ MediaHighway Interactive was approximately €17 in 2001, €4 in 2003 and would reverse (in MHP Interactive’s favour) to be €4 in 2004.91 It goes on to indicate a bill-of-materials differential between MHP Interactive and a basic MHEG-5 zapper box of approximately €55 in 2001, €37 in 2003 and €34 in 2004.92 The authors anticipate that memory and processor cost reductions will be the main drivers for the cost reductions for all STBs. However, we note that the white paper makes no provision for the costs of the intellectual property right licences required. These costs are as yet unknown,93 as the relevant patent pool is not yet operating.
The processing resources of an STB have a direct impact on the type and number of applications that can run on the platform of which it is part. However, such resources can not be ‘remotely’ upgraded. Upgrade requires physical modification or
replacement of the STB. The likely costs of such switching out are described above.
APIs
In most cases, an API is effectively an operating system that incorporates both a basic operating system and an application interface. In providing the interface between the operating system and the applications running over it, an API enables, limits and controls the iTV services that run over the platform of which it forms part. Content and application producers must have access to the specifications of an API and the authoring tools that are compatible with that API to be able to produce content/ applications that will run on that API.
To the best of our knowledge, content/ application producers are not currently experiencing difficulties in gaining access to the largely proprietary specifications of APIs, to the extent that access is required to author content/ applications.94 Nor have we seen evidence that the terms and conditions on which such access is provided
above, and include the cost of 56 kbps modems for the MHP and Open TV/
MediaHighway STBs.
91
The (unsubsidised) retail cost differences were anticipated to be a multiple of three of these figures.
92
Again, the (unsubsidised) retail differences were anticipated to be a multiple of three of these figures.
93
At this stage, the only agreed element is the $1 ceiling for each STB on the Java components.
94
It appears that Article 18 of the Framework Directive provides a clear policy support for the adoption and use of ‘open’ APIs. However, the ‘open’ concept is not defined. While the APIs currently in use are proprietary (at least in part), it does not appear that access to the rights necessary for authoring is restricted. In this context, Article 18.2 requires API providers to make available the necessary authoring tools.
operate as barriers to competition. 95 Given that demand for iTV services is a function of the content/ applications available, API rights holders (i.e., middleware producers) do not have an incentive to restrict the availability of API specifications (at least those elements necessary for authoring).96
There are currently at least seven APIs in use in Europe. The major deployed APIs, as at March 2003, are set out in Figure 4.3. These APIs are not compatible, in that STBs with one API cannot operate on another platform and services written for one platform cannot run on others without a degree of reauthoring.
There is significant disagreement within the industry in relation to the portion of the total cost of reauthoring content that can be attributed to the use of different APIs. The breadth of the range of values attributed was highlighted at the October 2002 meeting of the DVB Commercial Module: Open TV, NDS and others estimated attributable reauthoring costs to be in the range of 5 to 15% of total porting cost. Philips, IRT and others estimated the costs to be almost 100%. Disagreement of this magnitude must reflect, inter alia, consideration of fundamentally different types of content/ applications (e.g., content originally authored to be portable, as opposed to transaction-based content written specifically for a particular platform).97 In addition, the higher estimates may also reflect the incorporation of costs related to the STB (rather than to the API itself).
95
As such, it does not appear to us that there are issues relating to access, in most Member States, that warrant the extension of the ‘fair, reasonable and non-
discriminatory’ access standard to operators of APIs, under Article 5(1)(b) of the
Access Directive.
96
We note that Oxera reached a similar conclusion at page 27 of their February 2003 report “Study on Interoperability, Service Diversity and Business Models in
Digital Broadcasting Markets”.
97
In this respect, it is clear that the adoption of authoring tools or formats for new content will have no impact on (and will not facilitate) the portability of existing content authored without using such tools.
Figure 4.3 APIs currently in use
API Platform
Liberate UPC (Austria, The Netherlands, Scandinavia), ntl, Telewest
MediaHighway Canal+ (Belgium, The Netherlands), Canal Satellite (France, Spain), Canal Digital, Le Bouquet, Numericable, Tele+, Telenor Avidi
MHP YLE, Helsinki Television
Open TV Noos, TPS, UPC (France), FTC, Stream, AUNA, Casema/ Mediakabel, Comhem, Senda, TeleDanmark, Via Digital, Sky, Cablecom
Betanova Premiere
MHEG-5 Freeview
Microsoft TV TV Cabo
Transaction processing
In relation to transaction-based applications (e.g., banking applications), platform operators typically process transactions in relation to purchaser identification and verification and delivery information. Any application using the platform’s resources for such purposes must be adjusted to work with the platform’s database system and the relevant transaction (and billing) model(s). In addition, given the sensitivity of such applications in relation to a broad range of matters including data protection, transaction security and fiscal regulation, extensive (and expensive) testing is required.
The costs of porting transaction processing applications vary enormously. As such, it is essentially meaningless to generalise in relation to such costs. However, we note that a number of application providers have indicated that these costs can actually exceed the total cost of developing the application for the original platform.
Linguistic and cultural issues
There are a number of linguistic and cultural issues that must be taken into account when porting content/ applications. At a minimum, there are often translation requirements. These may also require graphics, audio and text layout revisions, to reflect the fact that messages in different languages require different amounts of space (and time). For example, German requires more space than English.