4.3 Platform Components

4.3.1 Operating System Layer

The OS layer is similar to that of most modern computer systems. Popular OSs such as Windows CE and Linux are used in iTV receivers. Their iTV specific configurations include drivers for the IEEE 1394 interface, HAVi display configuration drivers, MPEG-2 system decoders, video frame buffer, transport system target decoder drivers, data service decoding drivers, and an iTV specific event interpretation module.

iTV platforms differ from PC-based platforms in that they are optimized for presentation of pushed content. The event interpretation module is a collection of drivers responsible for capturing and dispatching those push events to the platform components that consume those events (e.g., middleware components). Event capture is performed by directly accessing the section buffers to determine when new sections arrive and deciding the impact of their reception on previously acquired data. Dispatching could be performed through the use of interrupts, or through the construction of shared data structures such as event queues. This interpretation and dispatching is challenging, non-standard, and a source of a wide range of interpretability problems.

The operating system is typically native code supporting the set-top hardware to provide basic services. The operating system middleware is typically comprised of the following subsystems:

Task/Process Scheduling : This module ensures that the all applications are allocated CPU time and are not starved or blocked from executing.
Interrupt Handling : This module dispatches interrupts to the appropriate devices for managing real-time events.
Device Drivers : These are the software modules designed to initialize and manage the devices available on the set-top box.
Memory Management : This module manages the OCAP 1.0 host device's memory resources [OCAP1.0].
Timers : Timers are used to trigger task execution to support process scheduling and dispatching.
Synchronization : This module provides a means by which to access and synchronize shared resources.

4.3.2 Middleware Implementations

iTV Middleware technology was designed to enable application to run on multiple hardware and OS platforms without regard to specifics. Whereas standardization of transport protocols primarily benefits broadcasters and manufacturers of transport decoders, standardization of middleware primarily benefits content producers and ensures that content will exist to enable the transition to the age of interactive TV. Today, the middleware software market is heavily populated by companies such as Canal+ Technologies (the largest in Europe), Liberate Technologies, MSTV (Microsoft TV), OpenTV (one of the largest in the US), PowerTV (platform and middleware), Wink Communications (services and tools), and WorldGate Communications (cable service provider). See Chapter 1 for a list of vendors .

One key component of iTV middleware is its conditional access and security capabilities. Conditional access features enable cable system owners to block access by those who are connected but do not subscribe (or wish not to receive) specific services. Security features include authentication of content and ensuring its integrity. As an example, financial transactions cannot take place without secure communication lines. Smart-cards can be used in a secure manner to prevent loss of sensitive information. Numerous vendors provide such services. Canal+ Technologies, OpenTV, and PowerTV provide both conditional access capabilities and security services.

Middleware implementation should also include a persistence manager, which is responsible for allocating persistent storage space (e.g., disk space), for all data that is rendered persistent. For example, applications running on top of the middleware may have some features controlled by broadcasters (via transport events), whereas other features are controlled by the viewer (via a remote control or keyboard). As an example, viewer-controlled applications may have embedded advertisement slots, which are controlled by the broadcaster. In another example, it is valuable for play-along game applications to have practice options that are controlled by the viewer whereas live play-along options are controlled by the broadcaster .

Middleware implementations should support the Java programming environment. As such, they should include a JVM and should implement PersonalJava, JavaTV APIs, JMF APIs, and HAVi Level 2 GUI APIs. Nevertheless, middleware implementation should not preclude non-Java applications from running side by side with the Java applications.

4.3.3 System Services Layer

4.3.3.1 Input Capabilities

An application is expected to interact with the viewer through a collection of user input facilities. Minimum capabilities of application environments include support for a navigation device that permits viewers to perform or enter the following:

Movement : move left, right, up, down
Numerics : digits zero through nine
Commands : activate, select, or enter

Support for a keyboard should be provided; if a physical keyboard is not available, a virtual entry of printable ASCII characters should be supported, e.g., using virtual keyboard applications or graphite-writing capabilities. Support for a pointer device is usually optional, and if such exists, it should probably be a trackball .

4.3.3.2 Display Configuration

The display model common to Interactive TV receivers is defined by the HAVi standard and depicted in Figure 4.10. This model was designed to best fit the needs of consumer electronics devices in general, and TV displays in particular. There are four layers of graphic display: (1) the background plane, containing a static image or uniform pattern and color , (2) the video plane displaying the video-stream for the current virtual channel, (3) the application graphics plane displaying the GUI, and (4) the cursor plane displaying icons used for selection and status notification.

Figure 4.10. Display planes.

The four planes are overlaid so that the content of the cursor plane is always visible (i.e., on top). Consider, for example, a configuration in which all planes are either visible or not. The content of the application graphics plane is visible only at pixel locations where the cursor plane is transparent. The video-plane is visible only at pixel locations where both the graphics and cursor planes are transparent. The background plane is visible only at pixel locations where the video, graphics, and cursor planes are transparent.

As opposed to having a single transparent color, with alpha blending, all colors are semi-transparent . This enables all the planes to be partially viewed , regardless of whether they specify the transparency color or not. Alpha blending is best implemented using a hardware Alpha channel.

A graphic display configuration must specify the relative location of the planes, as well as the pixel format for each plane. The location is specified using a reference display frame, as depicted in Figure 4.11. The reference frame has a canonical coordinate system in which 0.00,0.00 represents the top-left corner and 1.00,1.00 represents the bottom-right corner. Each of the planes has its top-left and bottom-right corner specified using coordinates relative to the 0 “1 coordinate system of the reference frame. More information about graphic configuration issues are presented in Chapter 8.

Figure 4.11. Parameters defining the graphic configuration.

The graphics capabilities of a platform with respect to the graphics plane should support 1920 x 1080, 1280 x 720, 960 x 540, and 640 x 480. Although the virtual color model visible to applications is true-color, consideration should be given to support of the following actual color models: 8-bit pseudo-color, 16-bit direct color (RGBA4444 or RGBA5551 or RGBA5650), 24-bit direct color (RGBA6666 or RGBA8880), and 32-bit direct color (RGBA8888). Receivers should support embedding active video formats in the display as specified in Table 4.1.

Table 4.1. Embedding of Video Format in 4:3 and 16:9 Display Formats

Video Format	Display 4:3	Display 16:9
4:3
16:9
14:9
Box >16:9

4.3.4 Transient File System

Although the transient file system is not specified by any iTV standard, its presence is implied by all iTV standards and implementers of an iTV receiver should regard it as an entity of its own.

The transient file system consists of files and meta-data loaded over the transport. Each of these files is associated with meta-data that minimally includes the application it belongs to, the virtual channel and ID of transport delivering it, its URI (or sufficient information to assemble the URI) [URI], its content type, the time it was received, and the time it was last modified.

The transient storage model should contain at least three components: (1) scratch-pad memory for temporary storage in support of data analysis, (2) a meta-data component (i.e., both announcement and signaling), and (3) a data essence component, which includes the downloaded resources, general data files, and any other archived content. Portions of this transient storage may be volatile, whereas other portions may persist over long periods of time.

The transient file system is a virtual hierarchical file system that could be mounted. For example, it is not unreasonable to mount it under the '/tfs' directory as its root. The first level of directories under '/tfs' should be the list of all accessible transports by their IDs, namely '/tsf/ts4A89C8B5',' /tsf/tsF149D815', and so on. The directory layer under the transport should be the virtual channel directory, which contains one entry per virtual channel. Implementations may further divide the directory of each virtual channel with time slots. Receivers that have sufficient memory may choose to keep recently used files in addition to currently used files. The next level in the transient file system hierarchy could be the application level, which contains a directory for each application transmitted within that virtual channel or within a time slot of a virtual channel. Within each application directory the files should be organized according to the structure provided by the content author.

4.3.4.1 Transient Data Essence

Another possible structure, depicted in Figure 4.12, partitions data according to data-essence and meta-data of applications and their files. The data-essence folder should contain a list of folders and files, e.g., XML files, class files, image files, etc.; when applicable , each data-essence folder could be further divided into sub-folders.

Figure 4.12. An example organization of the transient file system.

Transient file systems in general, and the transient data essence component in particular, should be implemented carefully , and should be treated as a cache management subsystem. Each file has in the data essence an expiration date. Further, some files may require dynamic updates from the transport (e.g., stock ticker). It is easy to allow a single transport to occupy the whole buffer, thus requiring a complete flush of the transient file system at the time of channel change.

Among the data that should be stored in a transient file system are the data objects transported over a DSM-CC object carousel. Files and directories are encapsulated as objects within modules that are delivered asynchronously. This means that the data is repeatedly sent using a carousel method, such that their arrival time is unpredictable but within the time frame of the carousel period.

Access to transient data obtained from transport file systems should be provided through the JavaTV class CarouselFile , that serves as a handle to the file rather than encapsulating the file itself. An instance of CarouselFile may be constructed from a JavaTV Locator instance, which may be constructed from a URI. Construction of a CarouselFile object causes its contents to be loaded asynchronously from the broadcast stream. Subsequent attempts to read the data of a CarouselFile object will block until its contents are loaded. The mounting point of CarouselFile , which is implementation and possibly time dependent, can be determined by calling getCanonicalPath() on the CarouselFile instance representing the top-level directory of the carousel. Transient files for which there are no remaining CarouselFile instances or open file descriptors, are eligible for unloading from the cache. Broadcast carousels for which there are no remaining CarouselFile instances or open file descriptors are eligible for un-mounting from the local file system.

Each file in the transient file system should be associated with a URI [URI]. URIs provide a simple unified and extensible mechanism for identifying a resource, which is the concatenation of the base-URI with the relative-URI. The URI framework merges Uniform Resource Locators (URL) and Relative URL in order to define a single, generic syntax for all URI. As a result, a URI can be classified as a locator, a name , or both. The term URL refers to the subset of URI that identify resources via a representation of their primary access mechanism (e.g., their network address), rather than identifying the resource by name or by some other attributes of that resource.

In general, there are a variety of methods that attach URIs to content and enable their resolution. Files and modules delivered in the broadcast are referenced by lid URIs, and Virtual channels are referenced by tv URIs. Files and data accessible through the Internet are usually referenced using the HTTP protocol [HTTP]. Regardless of the method used, it should be possible to resolve URIs to the data essence utilizing only the information stored in the transient file system.

4.3.4.2 Transient Meta-data

The meta-data component should contain at least meta-data which applies to an entire transport (e.g., EPG data), Conditional Access information, and application meta-data specifying at least application identification, compatibility info , URI mappings, and event queues and logs.

The structure of EPG data could be further organized in a variety of ways as it may contain up to two-weeks of advance information for hundreds of virtual channels. It is possible to introduce a folder for each virtual channel, and within that folder to introduce a folder for each time slot. Alternatively, it is possible to introduce a folder for each time slot, and within that folder, introduce a folder for each virtual channel.

The transient file system should also be used to store a variety of signaling information. The data service information, signaled in an MPEG table, should be converted into files residing in the transient file system. In ATSC, this implies transcoding the DST into a file, and in DVB, this implies transcoding the AIT into a file.

4.3.5 Persistent File System

The persistent file system should be used for two purposes: Storing resident software components considered part of the platform, and storing downloaded applications and content files that are rendered persistent. The resident software components could be placed in dedicated directories different from those used to store downloaded content. Content downloaded from a broadcast should be stored in directories that correspond to their source virtual channel. Alternatively, for each file in the persistent file system, it should be possible to determine whether it is considered part of the platform, a resident application, or downloaded content. Software components that are typically resident and considered part of the platform include the OS kernel, device drivers, JVM files, and class files implementing middleware components such as PersonalJava, JavaTV, JMF, and HAVi libraries.

Note that the directory tree of the downloaded application should be placed in the transient file system and thus should be outside the portion of a local file system retaining persistent information. Further, the application should not be allowed to access data not in its directory tree unless a security permission to that effect was requested and granted.

4.3.6 Applications

4.3.6.1 Proprietary Applications

Proprietary applications are all applications that are not interoperable. These are applications not covered by standardization and thus considered proprietary extensions of these standards. Examples of such applications include EPG, PVR, DVD players, and email clients .

4.3.6.2 Interoperable Applications

Interoperable applications are either procedural or declarative and are assembled from files and data streams downloaded either via a broadcast transport stream, a return channel, or a combination of both. Interoperable applications rely on the existence of standardized middleware. Examples of such standards are ATSC-DASE, DVB-MHP, and OCAP.

4.3.6.3 Types of Interoperable Applications

An important issue that impacts viewer experience and impacts the entire TV business model is the relationship between application life-cycle and channel surfing. Some applications are designed such that, although acquired from a specific channel, they continue their operation even when that channel is changed from 'under-them'; for example, when a viewer performs a financial transaction, the application should not be interrupted until the transaction is complete. Others applications are designed such that their life-cycle is tightly bound to the channel from which they were acquired; in case of a channel change, those applications terminate.

In general, the relationship between the application life-cycle and the life-cycle of the iTV program can be divided into the following categories:

Bound : The life-span of an application is subsumed in the life-span of the program within which it is delivered. These applications cannot be launched before the iTV program starts, and must terminate before (or at the time) the iTV program is over.
Shared bound : This is similar to the bound relationship, but extended with the capability to specify a collection of programs, possibly broadcast on different channels, so that watching them provides the viewer with the right to use the application. The challenge is to ensure smooth resumption of application execution under random channel surfing. If the affiliated program is encountered either immediately after the channel change or within seconds thereafter, application execution should resume smoothly. Such applications are powerful, as they can serve as a strong differentiating feature of a group of affiliated channels thus strengthening their branding as a group (e.g., discovery channels, health channels, music channels).
Persistent bound : An application can be loaded and recorded (i.e., saved) on the receiver's disk, but cannot be launched until an appropriate signal is received from the broadcast. It could be the case that a collection of resources is loaded overnight, allowing launches to the application during prime time with transmission of a small initial file. Such applications are very powerful and may enhance the advertising business model, as they allow broadcasters to load advertisements days or weeks in advance and replay them as needed, leading to the ability to lease time as a percentage of weekly or monthly ad space. Further, it is possible to customize the collection of commercials loaded and replayed to the individual preferences of the viewer or the viewer's family.
Unbound : As soon as it is loaded, an application can be launched without regard to any broadcast channel. The application may have access to some broadcasts; however its life-span is not controlled by any signal broadcaster, but rather by the viewer or a receiver resource policy (e.g., memory usage).

4.3.6.4 Management of Applications

The application manager is responsible for loading, launching, suspending, and terminating applications. An application is loaded when it is signaled as available in the transport. Applications are signaled in the transport when the stream of packets contain an MPEG program component that encodes a data service table, such as the ATSC DST or the DVB AIT.

An application can be launched once it is loaded. There are many situations in which applications that are loaded are not executed:

Pending viewer's confirmation : An indicator could be presented to the viewer that an application is loaded and ready to execute.
Pending broadcaster signaling : The application is loaded and waiting until the broadcaster signals that its execution is requested; this enables coordinating execution times across a range of receivers having a wide range of capability gaps.
Pending activation by other applications : An application is loaded by another application, yet not launched until a launch request is invoked. This model can be used when downloading software for future off-line use.
Pending availability of resources : The launch is delayed until the resources required for an application to execute may be used by the platform, (e.g., TV executive), are released.

Once the application is launched, it may be active until some event occurs that implies the suspension of an application. There may be several situations that warrant suspension of an application:

Triggered by viewer's operation : The viewer may request temporary suspension of an application, e.g., so as to enable the viewer to answer the phone. Viewer initiated suspension could also occur implicitly, by simply launching or activating another application thus hiding the GUI of the currently active application.
Triggered by the broadcast : For bounded applications, a signal is transmitted in the broadcast that indicates to the receiver when it is time to launch and allow execution of an application. Once launched, an executing application with a signal that is gone should be suspended . This may occur as a result of bad reception, channel switching, or scheduled omission by a broadcaster.
Triggered by the applications : An application may suspend itself or it may be suspended by another application. This capability enables, for example, a single application to serve as a dispatcher to other applications. In another example, a precursor download scheduler application is loaded, which then monitors the transport for a requested application for download and subsequent execution.
Triggered by availability of resources : An application may be suspended when the resources needed for its execution (e.g., display area) are temporarily not available. This may occur when a setup application is temporarily locking all resources.

Applications that are suspended could either be reactivated or terminated . However, fatal error conditions may cause the application to terminate before it is loaded, launched, or suspended.

Terminating application does not imply their unloading. Resources of terminated application may be stored in the local memory or cache for some time before they are purged. This may occur in the following situations:

Continuous signaling : An application was terminated but continues to be signaled by the broadcast.
Persistent applications : An application was rendered persistent (i.e., save) for future use.