ALDO CUGNINI /
10.01.2011
Originally featured on BroadcastEngineering.com
Interactive services
An upcoming ATSC standard supports interactivity.

The killer app of computer interactivity, when considering popularity, is probably the Web browser. But interactivity requires more than just a browser; a rich user experience requires access to live and cached multimedia content as well as static pages. This month, we'll look at how these capabilities will be supported in an upcoming ATSC standard.

Local interactivity with non-real-time services

When adding interactivity to a DTV broadcast service, both “local” and “system” interactivity can be provided. The former provides a complete mechanism within a DTV receiver, relying on stored content; users interact with their DTV, and the cached content can be retrieved and presented at a time after it was broadcast. The latter uses an out-of-band return channel that provides signaling back to the broadcaster.

ATSC NRT (Non-real time) is a Candidate Standard that provides support for delivery of content in advance of use (i.e., files, as opposed to streaming content) to both fixed and mobile broadcast receivers. NRT services will usually carousel (i.e., retransmit) content throughout an announced availability window, since receivers will begin “connecting” to a broadcast at different times. In the simplest use cases, the set of available files is fixed for the duration of an NRT session. However, dynamic update of available content is also supported.

NRT content carried in an ATSC broadcast stream is delivered via extensions to the File Delivery over Unidirectional Transport (FLUTE) protocol. Developed by the Internet Engineering Task Force (IETF), FLUTE provides for unidirectional delivery of files over the Internet, where error correction, and not bidirectional handshaking with retransmission, provides protection against data delivery errors. The specification builds on Asynchronous Layered Coding (ALC), an Internet protocol designed for massively scalable multicast distribution. When used with ATSC NRT broadcast streams, FLUTE applies to fixed receivers using the ATSC DTV Standard and mobile receivers per the ATSC Mobile DTV Standard. FLUTE file packets are allowed to use the entire transport, up to the maximum bit rate (i.e., 19.4Mb/s for fixed), minus signaling overhead.

NRT uses URL conventions that provide multiple capabilities to client browsing of HTML files. With these rules, receivers can distinguish between files that are available only via FLUTE versus files that are available via both FLUTE and an Internet link. Specific NRT URL constructions also facilitate using relative URLs for files delivered by FLUTE, rather than longer absolute URLs. They also support hyperlink resolution among the files within a FLUTE session, similar to how file paths are defined in a computer's file system. Thus, conventions like virtual folders can be used.

Three distinct consumption models are described in the ATSC NRT standard: Browse and Download, Push, and Portal. Browse and Download describes content that can be selected for later download. There are two basic operations expected to be supported: one where the user browses for content to be retrieved from the digital broadcast and one where the user chooses to view previously downloaded content. The Push service offers continuously updated content and is similar in function to an RSS news feed on the Internet. The Portal NRT service provides an experience similar to browsing the Internet using a Web browser.

When an out-of-band interaction channel is present in an ATSC DTV service using NRT (e.g., on a fixed receiver with an Internet connection), it must conform to ATSC A/96 Sections 6 (Application-layer protocols) and 7 (Network and Transport-layer protocols), and can additionally support other protocols. Network layer protocols enable communications between a remote server and the interactive television client in the DTV, over a return-channel network. Transport-layer protocols are deployed on top of the network-layer protocols and are used for end-to-end data exchange between the servers and clients. The A/96 specification does not define the physical and data-link layers.

Receiver customization provides personalization

NRT also supports a receiver targeting mechanism, which is based on the optional association of targeting criteria with services or individual content items. Using this mechanism, DTV receivers personalized by means of a user setup (or other automatic mechanisms) can be programmed to behave differently and present different content to different users, all in a seamless fashion. Various targeting criteria are currently supported in the NRT stream, such as geographical location, postal code or demographic category, and new criteria can potentially be added in future versions of NRT. Using the NRT specification, receivers can also be built that support different codecs, compression formats and container file formats, including AVC, MP3 and DTS-HD audio, and the multimedia container format profiled in the DECE Media Format Specification.

NRT services are fully backward-compatible with existing DTV receivers, which would simply ignore the additional content. (If a receiver firmware update mechanism is available, then current receivers could potentially access the new NRT features, too.) The Candidate Standard is expected to go to Draft Standard this month, unless otherwise extended by the ATSC.

Mobile devices support interactivity with other tools, too

ATSC Mobile DTV (A/153) provides for the delivery of auxiliary (graphical) components that support interactivity, based on the OMA-RME (Open Mobile Alliance Rich Media Environment) specification, written specifically for mobile devices. OMA-RME is an umbrella standard, encompassing elements of application creation, delivery and control. OMA-RME content consists of scenes of objects such as video, images, animation, text and audio that are composed together. By defining each object separately, the presentation can follow scripts that control the appearance and dynamic behavior of the objects.

OMA-RME includes Scalable Vector Graphics (SVG) Tiny 1.2 (a W3C standard), Dynamic and Interactive Multimedia Scenes (DIMS) and the ECMA Script Mobile Profile. SVG is an object coding specification, an alternative to the JPG or GIF formats, that provides a way to generate and render both static and dynamic (i.e., animated) graphical elements on display devices. DIMS is a 3GPP multimedia standard that provides for the development and delivery of rich media services over mobile networks, optimized for computationally constrained devices. DIMS is used to synchronize graphics elements with audio and video, and provides for the spatial and temporal layout of a multimedia scene. Scenes generated using DIMS can consist of any combination of still pictures, video, audio and animated graphics. DIMS also defines an update mechanism that supports partial updates of an existing scene, as well as on-the-fly tune-in functionality. ECMA Script is an OMA standardized version of JavaScript, which enables Web applications to have a compact environment within which to run computationally intensive programs and scripts.

The various interactive features described here are under development (NRT) or in early deployment (OMA-RME). (ATSC 2.0, currently in development, will include Internet connectivity and NRT file-based content delivery, as well.) Expect new tools and business models to emerge as interactivity and mobile broadcast go forward.

Aldo Cugnini is a consultant in the digital television industry.

Send questions and comments to: aldo.cugnini@penton.com



Comments
Post New Comment
If you are already a member, or would like to receive email alerts as new comments are
made, please login or register.

Enter the code shown above:

(Note: If you cannot read the numbers in the above
image, reload the page to generate a new one.)

No Comments Found




Monday 6:39AM
What Price Reliability?
Digitally delivered TV has seen a pile o’ fail lately.


 
Featured Articles
Discover TV Technology