In digital TV, developers have been concerned about fostering end-users' ability to take advantage of its wealth of programming. What good are hundreds of channels if the viewer lacks the means to sort and filter this information to enable meaningful choices? As growing bandwidth expands the offerings of networked multimedia in both the wired and wireless arenas, giving users the ability to zero in on the most relevant media option becomes a critical application goal.

The electronic programming guide (EPG) is one of the most important data containers of channel-rich digital TV. An EPG allows the user to scan available channel offerings and tune to current programs by pointing at listings with a remote control. The EPG informs the user of the most interesting programs that fit specified viewing criteria, and the user can check program availability over a series of days.

What requirements of EPG data management can be applied to device-based, Internet-centric wired and wireless multimedia development overall?

First is the general need to provide a localized and frequently updated catalog of media options that would enable users to browse and organize their choices.

This should apply equally to set-top box electronic programming guides, satellite-based radio receivers, DVD+CD jukeboxes, MP3 players and many other device-based systems.

Second, in the technical implementation of such guides, developers will confront a highly resource-constrained environment.

RAM and CPU cycles demanded for data management could be used elsewhere to enhance the end-user experience — for example, by expanding the time period or content covered by the guide, supporting new features or reducing the price to the consumer by using less expensive hardware. Thus, minimizing database footprint becomes an overriding goal.

Third, such systems' processing latency must be reduced to the unnoticeable level expected in consumer electronics.

Fortunately, much of the groundwork for such capabilities has been done for the EPGs developed for the emerging digital TV environment, which today is allowing users to browse available programs by themes such as movies, sports, news/business, family/children and education. Favorite channel lists can be customized for easy program selection and an info button on the remote instantly calls up program information. Some models even enable parents and others to block content, usually according to program ratings.

Systems designers will recognize these capabilities as entailing significant searching, filtering, sorting, selecting and storing tasks. In fact, the EPG, more than any other feature, has added a challenging data management component to the design of new digital television receivers (also known as integrated receiver decoders, IRDs or set-top boxes).

To support the growth in EPG features, developers increasingly must incorporate a database "layer" within receivers' embedded software that facilitates optimal data designs, supports transactions and data integrity, and minimizes the impact of data management tasks on performance and on RAM and CPU usage.

Developers have typically responded to this challenge with self-developed data management components. This solution often meets the performance and small-footprint requirements for set-top boxes. But when required to manage increased volumes of data or to adapt to new IRD requirements, the self-developed data management often proves difficult to upgrade, demanding an inordinate amount of quality assurance and extending development cycles.

Increasingly, IRD developers are turning to commercial embedded database systems, which offer stability, extensibility and scalability gained from years of usage. However, commercial databases' lack of real-time performance often rule out their use in digital TV receivers — viewers surfing through program offerings expect the zero-latency responses associated with consumer electronics.

The demands these databases make on processing resources also make them a poor fit. To minimize costs, companies developing IRDs incorporate minimal RAM and choose less-powerful processors.

A newer type of data management, the in-memory database system (IMDS), addresses those concerns and has proven a good fit in several commercial EPG implementations. Designed from the start for memory-only deployment, IMDSes like eXtremeDB, for example, accelerate processing through an architecture that eliminates disk I/O, caching and other high-overhead functions.

The EPG data that consists of program descriptions is issued in real-time from broadcast or terrestrial sources. The information cycle rates in the EPG streams vary and can be relatively long (i.e., hours). Because of this the set-top box cannot "wait" for data until a user makes a selection or makes some other query of EPG information. Rather, the set-top box receiver collects and retains the information beforehand.

Once the EPG data is received and stored locally in the set-top DRAM, the viewer can search, filter, sort and select programs for immediate or future viewing. Local storage of the program guide isolates the consumer from any transport delays.

For electronic programming guides, separate American and European standards define how program producers put program descriptions into the digital video stream, following the PSIP (in the United States) or DVB (in Europe) protocols. The intent is to enable receivers built by different manufacturers to build comprehensive programming guides using the same data. Like other standards developed for the European and U.S. markets, PSIP and DVB are not interoperable.

Since EPG data is only between 0.5 percent and 3 percent of the total digital content of a program, an MPEG-2 stream could carry both ATSC and DVB program guide data. In actual practice, this is usually not done. A cable system may carry dozens of independent MPEG-2 data streams, and real-time gathering of program descriptions broadcast in the MPEG-2 stream can be slow and system-dependent. For this reason, most digital broadcasting networks in the United States use a separate out-of-band data carrier to transport EPG data to the receiver.

Integrated services
Cable, satellite and over-the-air digital receivers are usually built as embedded systems with limited amounts of DRAM as the primary storage. Set-top boxes often don't run such traditional operating systems as those found in PCs and workstations. Only multitasking, real-time operating systems can support the high data rates and performance demands of an IRD solution.

On the other hand, as set-top boxes evolve in their capabilities and features, their embedded software is becoming more robust and multiple applications now co-exist within the box. In addition to video display and basic television functions, the growing list of add-ins includes e-mail, video-on-demand and personal video recorder (PVR).

Often those services are integrated with the EPG. Not only does the EPG have to store the data in a timely fashion, it also must provide various search capabilities to the applications. Thus, the EPG needs a database system that will serve as underlying storage and expose an application programming interface to EPG functions. This underlying database storage has to integrate seamlessly with the OS environment. It must be robust to handle complex requests for data storage and retrieval, but not monopolize the CPU, which is required to handle other tasks like PVR.

On-screen program guides are composed of two major parts:

- The application software (often called the EPG presentation engine) that runs in the set-top and

- The data that the application software receives and formats for display. The EPG-equipped set-top must be frequently updated with guide data via an external source.

The IRD extracts the program guide data, stores it in memory (DRAM) and keeps it for display as either a full-screen grid guide or as an overlay to active video. The amount of future programming covered by a guide is determined by the amount of DRAM storage available in the set-top box. In this sense, the EPG storage-management subsystem competes with EPG content for the use of those memory resources, so that minimizing the application's memory footprint enhances the end user's experience by enabling richer, more complete content.

The amount of memory available for local EPG data storage is usually quite limited. In general, the more RAM that a receiver devotes to processing and storing the EPG, the more capable the IRD will be.

IRD capabilities that affect RAM usage include the number of days of schedule information to retain, use of short vs. long descriptions, which credits to retain, language(s) supported and graphics. Therefore, it is imperative that the storage-management module make efficient use of IRD memory.

The storage management should be able to support various data alignments. EPG data elements commonly occupy just one byte, for example. About 90 percent of all EPG data is, in fact, dynamic text. The storage management should not store dynamic data, such as variable-length strings, in data types demanding excessive memory. That could easily become prohibitive.

Service providers usually require the IRD to keep three, seven or 14 days of guide data. The three-day schedule means that the IRD always carries two days of programming into the future, plus the current day's schedule.

The EPG should be able to handle "boundary conditions" gracefully. When all the memory dedicated for storage is used up, the data management should allow the EPG to run such "cleanup" procedures as removing expired data and returning memory to the memory pool for reuse. Ideally, the EPG would implement OS-independent dynamic-memory management, since embedded operating systems usually lack efficient memory managers.

The EPG database is accessed by multiple threads (tasks) simultaneously, including those dedicated to writing new data into the EPG database, user-interface queries, conditional-access queries and Wink support tasks. Some of those tasks — such as writing new data to its permanent location as soon as it is available — should gain prioritized access to the database, while lower-priority tasks can execute in the background during otherwise idle CPU time. The storage-management module must, therefore, provide multithreaded functionality to the EPG, and implement a transaction prioritization mechanism.

EPG data must be transmitted at a high rate. The rates vary from one service provider to another, but all providers try to utilize the available bandwidth to the greatest extent possible. IRD software processes received packets before storing this data in the EPG database. Such processing may include assembling EPG objects from frames, decompressing the data and filtering.

Generally, the transmission rate is in the range of tens of megabits per second. For the IRD to be accepted by service providers, the storage-management software must be able to keep up with this or even higher rates on the order of hundreds of megabits per second. Accordingly, the storage management should use a specialized and extremely fast transaction control mechanism as well as memory-oriented search algorithms.

At the same time, it is important for the EPG database management module not to monopolize the CPU, because other important functions of the IRD, such as video recording, require its cycles. EPG storage algorithms should be optimized to minimize CPU cycles.

See related chart