SCTE Seeks Middleware Standard for Set-Tops

Author:
Updated:
Original:

The cable industry's quest to establish a middleware standard for advanced digital set-top boxes is now under the purview of the Society of Cable Telecommunications Engineers.

Earlier this spring, the SCTE created the Common Applications Platform subcommittee, chaired by Jean-Pol Zundel, chief software architect for Comcast Corp.'s cable unit.

The effort, Zundel said, is an extension of Cable Television Laboratories Inc.'s OpenCable initiative-particularly the OpenCable software request for proposal that was issued last year.

The competitive middleware-selection process is designed to produce a single application-programming interface, which is composed of a common set of instructions which applications and/or services on the OpenCable platform can execute.

Conceptually, the API will allow content developers to write applications that will run on multiple hardware platforms, independent of the operating system or processor.

"We don't expect application developers to code [their applications] to raw metal," Zundel said.

Canal Plus U.S. Technologies, Liberate Technologies, OpenTV Inc., PowerTV Inc. and Microsoft Corp. are participating with the SCTE subcommittee to hammer out a standard.

"If we did nothing, we'd have five or six [set-top middleware] platforms," Zundel said.

As an example, he referred to the dilemma faced by Web-page designers, who often write code to adapt to the slightly different manner in which the competing Netscape Communications Corp. and Microsoft browsers display Web pages.

"The whole purpose [of the standards effort] is to take away those variations," he added.

Canal Plus U.S. vice president of marketing Arthur Orduna took the concept one step further, calling for an "internationalization" of application interoperability across geographic boundaries.

"Our concern is making sure applications written in the United States can run in Europe and America," he said.

Zundel said the subcommittee would adopt the same procedures used by the industry to develop the Data Over Cable Service Interface Specification standard. Leading vendors are selected to participate and work out the differences in their products. Key elements for the specification, representing each company's intellectual property, will be placed into a pool. The API definition, he added, will belong to CableLabs.

Various vendors' implementations of the middleware specification will be subject to certification by CableLabs. Vendors outside of the five participating in the subcommittee's standards effort will be free to develop their own middleware that conforms to the standard.

The establishment of a middleware standard is expected to help facilitate the interoperability of so-called digital-ready TV sets and OpenCable advanced digital set-top boxes to be sold at retail.

Cable operators have their own private plans to develop and roll out interactive-TV applications-for example, video-on-demand, electronic commerce, e-mail and Web browsing.

But it's important that the middleware layer be consistent from operator to operator so consumers can "preserve their investment" in digital TVs and set-tops as they move from one operator's territory to another, Zundel said.

"Private plans do not work best for the retail market," he added.

Zundel went on to say that software vendors-now locked in a highly competitive battle for placement on digital set-top boxes-will benefit from contributing their intellectual property to the standard effort. "There will be a lot more market and lot more business than if they all go their separate ways," he added.

Representatives of Canal Plus U.S., PowerTV and Microsoft all agreed with Zundel's assessment.

"All of the middleware vendors have a great incentive to cooperate because everybody wants to get the market off the ground," Microsoft director of TV-platform marketing Alan Yates said.

Thus far, the middleware specification has been divided into two portions: the presentation engine and the execution engine.

The presentation engine will be derived from the Advanced Television Enhancement Forum (ATVEF) specification, which relies on HyperText Markup Language, cascading style sheets and JavaScript to draw graphics, display animation and execute links and other on-screen controls.

The execution engine will be Java-based, Zundel said, incorporating the same subsets of JavaTV that the Europe-based Digital Video Broadcasting group adopted for its Multimedia Home Platform API in November.

The purpose of adopting Java for the execution engine is to "provide real programming capabilities behind the scenes," Zundel said. A full-fledged programming language such as Java will help to enable applications such as home networking, electronic program guides, personal-video recording and Internet protocol streaming.

The execution engine is the "get-out-of-jail-free card, PowerTV chief technology officer Ken Morse said. For example, XML (extensible markup language) might not be supported in the presentation engine. But if XML proves to be necessary for emerging applications, a Java developer can write code in Java to support XML.

The adoption of Java for the execution engine presents a dilemma for Microsoft, which is embroiled in a legal dispute with Java creator Sun Microsystems Inc. over its implementation of Java.

When asked if the legal situation would hinder Microsoft's ability to develop middleware that utilizes Java, Yates said diplomatically, "I hope not. We're very interested in making sure Microsoft can provide an open implementation" of the standard.

But, he added: "Most content and services out there can be accomplished through HTML and JavaScript ... you don't necessarily need Java for most content and services." He acknowledged that there was a role for Java, although he said, "We're not religious about the issue."

During the standards process, participating companies will be contributing portions of their intellectual property and raising issues regarding the standard to ensure a competitive, multivendor environment.

Morse's get-out-of-jail-free card reference also alludes to a critical aspect of the standard effort: deciding which versions of which existing standards to adopt. "Endorsing an API by itself isn't good enough," he said.

In addition, Morse said, the standard should "explain implementation [or functional] requirements." Key among those standards the common applications platform must consider are the various versions of HTML, including XML, HTML 3.2, HTML 4.0 and XHTML 1.0, Orduna said.

He pointed out that the Advanced Television Systems Committee's Digital Television Applications Software Environment (DASE) HTML implementation is based on XML, while the current version of DVB-MHP employs the XHTML module.

Despite the tendency to opt for the "latest and greatest," Orduna said, the 3.2 implementation of HTML is a good starting point for the CAP subcommittee.

On the other hand, Yates said, HTML 4.0 should be considered, pointing out, "Our [Web] browser is 4.0-compliant." He believes in the Internet as a model for setting "a minimum level of compatibility." By selectively taking the best of the Web, Yates said, there will be "a lot of room for innovation."

But Morse is wary of the subcommittee adopting standards that have yet to be universally embraced. "By raising the bar superhigh, [the subcommittee] may be favoring one vendor," he added.

Morse also questioned how the middleware API would address JavaScript. How would it support "multithreaded" JavaScript instances used for "program-synchronous" content in which two or more applications, such as a program guide and a Web browser, rely on JavaScript to execute functions at the same time? Without multithreaded JavaScript support, the potential exists for the set-top to "lock up."

By supporting multiple instances of JavaScript, middleware can avoid the "single point of failure syndrome" when trying to execute multiple applications that use JavaScript, Morse said.

Besides supporting multithreaded JavaScript, he added, the subcommittee needs to address how many threads and what kinds of latency should be supported in the standard.

While creating a standard would turn set-top software into a commodity that any software maker could produce (provided that it conformed to the specification), Zundel said, there would still be room for product differentiation based on quality, speed, delivery and support.

"The differentiation has to come above and below the middleware, and also as you move back in the network," Morse said.

On the surface, the development of a standard may hurt companies that have focused solely on middleware for set-tops, while companies such as PowerTV and Microsoft, which both make set-top operating systems and applications, will be able to bundle their middleware with their operating systems.

But how each vendor reacts to the standard and how it brings its standard-compliant middleware to market remains to be seen.

As Morse explained, once the standard is established and effectively becomes commoditized, middleware vendors "better have something else up their sleeves."

A number of economic models come into play here, including a price war, which could fatally wound a company with large middleware development teams. A large company may be able to undercut its competition through aggressive pricing schemes.

From Morse's point of view, "the fundamental concern is to not create another Microsoft." By that, he meant enabling one software company to dominate the market, as Microsoft has done in the PC market.

As Morse suggested, another solution for differentiating middleware could be a further consolidation of middleware providers.

PowerTV recently acquired Prasara Technologies Inc., and Morse hinted that the company could be still on the prowl.

Orduna cited a key differentiator for Canal Plus U.S.: a track record established in Europe of running middleware on multiple central-processing units and operating systems. "That's where we see bringing a lot of value to the table," he added.

The cable industry's push to get OpenCable-compliant set-tops and TVs in retail stores by the 2001 Christmas season means that a middleware specification needs to be ready by early next year at the latest to make sure the certification process can proceed and manufacturers can place products into retail channels.

But perhaps a more pressing force is the hot breath of cable's competitors, especially satellite providers.

Once the SCTE forges a standard, Zundel said, it will be submitted to the American National Standards Institute or to the U.S. State Department for eventual consideration by the International Telecommunications Union in Geneva.

The next meeting of the Common Applications Platform subcommittee will be Aug. 9 in Vail, Colo.

Related