The Advanced Television Systems Committee (ATSC) with the help of dozens of companies worldwide, is designing the foundation for what is expected to become the cornerstone of advanced digital video services for the home.
The DTV application software environment (DASE) is an ambitious four-year effort nearing completion within the ATSC (specialist group T3/S17) to define a platform for advanced receiver functions. As such, it will form the basis for a wide range of new services. DASE makes it appear as if it is interactive programming content running on a so-called common receiver. This common receiver contains a well-defined architecture, execution model, syntax and semantics. The benefits of this approach include the following:
- It affords the capability to write content once and run successfully on all compliant receivers.
- Consumer electronic equipment manufacturers have the freedom to independently choose the hardware and operating system for their receiver products.
- Content and application authors have the assurance that their content will be decoded and displayed on all receiver brands uniformly.
- All receivers have certain common functions and features, such as remote control, service selection, MPEG decoding and so on.
The DASE standard is the next step in the evolution of DTV functionality following the ATSC data broadcast standard (specified in document A/90). The DASE system builds upon A/90, which builds upon the core DTV standard described in A/53, the PSIP standard described in A/65, and the conditional access standard described in A/70.
General concepts
There are certain fundamental building blocks involved in the DASE system, the most basic of which are:
- Application – information that expresses behavior (i.e., a program)
- Application environment – a system that interprets an application to produce a specific behavior (i.e., a program or document processing system)
To develop an advanced interactive service, there are three basic application approaches:
- Embedded application approach, where the application is pre-installed on the receiver. Such a service is generally non-portable and requires re-implementing or porting for new receivers or new technology. As such, it is difficult to change or innovate with new applications. This approach is very stable, but allows only simple features.
- Thin-client application approach, where the application is shared between a server and the receiver. The application is executed or interpreted on a remote server. This approach requires a low-latency, high-bandwidth, point-to-point communication channel. It typically does not scale well.
- Full-client application approach, where the application is dynamically installed on the receiver through broadcast or a point-to-point channel. The application is executed or interpreted at the receiver. This system requires more resources and greater performance than the thin-client approach, but offers significantly greater flexibility.
But there are challenges to implementing any of those approaches:
- Installing the application. If the application is pre-installed (embedded), it is difficult to innovate. If the application is dynamically installed, it must be downloaded to the receiver and prepared for processing in sufficient time to be ready for presentation. For the DASE standard, the application is downloaded through the broadcast stream.
- Application form. An application can take a range of forms divided into two categories: procedural and declarative. If procedural, options include native compiled code, portable byte code (p-code) and source code. If declarative, options include HTML, XHTML, SMIL, SVG, XML and MHEG. For DASE, the approach is a standardized form with strict conformance.
- Environment. The system designer must identify the “native” resources that an application can reference or use. Examples of resources include graphics, video, audio, user input (remote/keyboard), broadcast stream, network, memory and processor functions. Other issues relate to the method used to reference or use these resources. If the mechanism is proprietary, applications cannot remain portable. For DASE, the approach is a standardized environment with strict compliance.
There are three basic types of DASE applications:
- Declarative applications, including: 1) declarative-content type (XDML and XHTML subset), 2) supporting-content types (CSS, ECMAScript, graphics and others), 3) document-object model (DOM), and 4) declarative-application environment (which controls system behavior).
- Procedural applications, including: 1) procedural-content type (Java class file format), 2) supporting-content types (graphics, audio, video and so on), and 3) procedural-application environment (Java virtual machine, APIs and system behavior).
- Hybrid applications, including: 1) declarative using procedural content (embedded active object content) and 2) procedural using declarative content (synthesize markup, style and script content).
The DASE content environment is illustrated in Figure 3. A return channel, which probably will be supported in a future version of DASE, is commonly described as DASE-2.
The API is a platform-independent abstraction of receiver software libraries and built-in functions such as remote-control input, network communications, graphics and other basic features.
Specifically, the DASE API categories include:
- Network communication – navigation, event information, programselection and data broadcast services
- Content management – audio/video and media decoder, playback control, audio control, video presentation, presentation and synchronization, and decoder/player synchronization services
- Presentation and user interface – graphics presentation, font and color management, and user input services
- Application and resource management – application life cycle, registration, verification and application state (diagnostic) services
- Security management – authentication, security (policy) and signature-checking (certificate-exchange) services
The architecture of the DASE declarative environment is built around six basic elements:
- Markup language, which defines the structure of a presentation
- Style language, which defines the presentational aspects such as position and color
- Event model, which defines a means for interaction with a presentation
- Document object model, which defines a means for programmatically manipulating a presentation
- Media types, which define what type of content may be used in a presentation
- Locations, which define how to find resources
Evolution of the DASE system
Because of the complexity of DASE, the rollout of this technology has been partitioned into multiple levels. The basic specification is identified as DASE Level 1; subsequent releases are designed to build upon this foundation:
- DASE Level 1 – provides for local interaction of enhanced television. This level is the basic foundation. It is broadcast-only in scope; there is no return channel. Examples of DASE-1 applications include play-along games (such as “Jeopardy” or “The Price is Right”), “for more information” services (such as sports statistics, product information, local weather and traffic updates), and a rudimentary “mini” program guide.
- DASE Level 2 – is expected to provide remote interaction with interactive television. This version will build upon DASE Level 1. It will provide for a return channel and enhanced security framework with digital-signature capability and return-channel encryption. With DASE-2, interactive television commerce (T-commerce) applications become practical. Examples of DASE-2 applications might include community gaming (where users play each other), gambling (where legal), instant produce purchase, coupon printing and a full-featured program guide.
- DASE Level 3 – is expected to provide Internet-enabled services or Internet television. This version builds upon Level 2 and facilitates general Internet content. As such, DASE Level 3 must handle invalid, non-well-formed content to be interoperable with the existing Web practice. DASE-3 applications include Internet browsing, general Web access, Internet commerce, banking and investment management. There are a number of deployment challenges for the DASE standard. End-to-end issues include metadata management, format conversion and synchronization requirements. Interoperability issues include conformance requirements and compliance testing. Distribution issues involve the preferred authoring standard (i.e., will authors create native DASE content format or other content to be transcoded into DASE format?) and distribution (i.e., will non-terrestrial media – cable and satellite – distribute DASE content?). Harmonization of the DASE system with other technologies has been an ongoing priority for the ATSC T3/S17 specialist group. The group has put substantial efforts into making DASE compatible – to the extent possible – with the multimedia home platform (MHP) of DVB and the open-cable platform (OCAP) of Cable Labs. Although many of the operational details differ, the general approach and key technology choices are identical.
The work continues
Work to produce a set of DASE standards documents is still underway within the ATSC. The entire suite of documents will consist of nine separate elements. The target date for completion of DASE Level 1 and formal acceptance by ATSC as a standard is early 2002.
Jerry Whitaker is technical director of the ATSC.
