4.6 Operational Dynamics

iTV receivers are complex and it is not always clear how the components cooperate to deliver the intended viewer experience. This section presents some of the operational dynamics of a receiver in terms of control and data flow descriptions.

4.6.1 During Power-off

The operation of an iTV receiver begins as soon as it is connected to a power supply, and before it is turned on by the consumer. As soon as power is connected, the receiver can start scanning accessible broadcast channels. Further, as soon as the return channel of the receiver is connected to an ISP, the receiver can configure its IP-stack (e.g., obtain IP address) and start searching for available services.

4.6.2 Scanning Broadcast Channels

As opposed to traditional analog TV, DTV broadcast contain, for each transport stream, the identity, network description, and channel numbers (major and minor) for that transport. Although this information is encapsulated using different broadcast standards (Terrestrial vs. Cable, U.S. vs. Europe vs. Japan vs. China), in all cases some form of a virtual channel table is used. This table is references a number of virtual channels and associates a program to each. The information about that program is then obtained from the PSI data, which indicates whether it is a video-only program or interactive program. Further, in many transports the schedule of programs in the next day (or sometimes two weeks) can be retrieved. This information can be assembled during power-off time to form an EPG.

Beyond providing the viewer with an updated EPG, the scanning of channel content could be performed over all accessible channels. Such a scan enables the receiver to generate and cache a complete map of all channels available and perform subsequent index searches locally.

An important issue to address is channel surfing. What is required is an association of each channel with the next and previous channel presented when the ch+ and ch keys are selected respectively during the viewing of this channel. To illustrate the flexibility, note that a completely different order and set of channels can be induced by ch+ and ch. One could go as far as eliminating a different set of channels in each direction.

In some broadcast standards, this association is explicit in the transport. In others, this association is implicit. Regardless of the method used, it is important to note that the channel surfing experience may be significantly enhanced by customizing the sequence to the preferences of the viewer or the viewer's family.

4.6.3 Application Life-cycle

Different standards specify different application states and life cycles. The following is a list of characteristics common to many architectures. Although different architectures may assign these characteristics different names and semantics, the concepts are similar.

4.6.3.1 Availability Detection

An application life-cycle starts with the detection of its availability in the MPEG-2 broadcast. An application is detected as available as soon as a specific MPEG-2 private section arrives. In DVB, this is the AIT. In ATSC, this is the DST. Both the AIT and DST structures contain the UUIDs of all applications that are available in the transport. Some of those IDs are associated with a bit that indicates that the application should launch automatically. Applications could be detected on a channel change or on signalling initiated by a broadcaster . Often, when a new application is detected, a previous application needs to be terminated .

4.6.3.2 Application Load

As an application signaling is detected, a list of resources for that application should be extracted from the signaling. Specifically, for each application UUID in the AIT or DST, the data structure contains a list of resources (i.e., files and streams) belonging to that application. The loading of applications should start as soon as they are detected. Priority should be given to those applications signaled for automatic launch.

That signaling should contain sufficient information to specify which resources must be acquired before the application starts. For each of these resources, the application environment should search the cache to determine whether the resource is already loaded or whether it needs to be retrieved. If a resource is to be retrieved, then a determination needs to be made to determine the protocol with which the access can be made. If the resource is available through a return channel before it is available from a broadcast, then the return channel should be used for retrieval (recall the LBI described earlier).

Application resources are usually files delivered using the DSM-CC object carousel. The data service combined with the object carousel data structure are transmitted repeatedly. In case of a random channel change, a receiver may need to wait for, at most, the re-transmission of all required resources, introducing some delay. However, the data structures delivered with the data service usually provide sufficient information to assess whether a file is indeed transmitted and waiting for the data is fruitful. In other words, receivers may know whether a resource can be retrieved immediately as the data service is detected and before the data is transmitted.

4.6.3.3 Trust Determination

Applications must execute either as trusted or untrusted. Application trust determination occurs after it is loaded and before it is launched. Applications are trusted if they are successfully authenticated. Receivers should not start executing applications before attempting to authenticate them. If authentication fails, then the application might be executed as untrusted. Receivers should not launch applications whose authentication has failed and which require access to privileged operations, as their execution needs to be trusted.

4.6.3.4 Application Launch

Once the minimum required set of resources is loaded, the application could start executing. At that point the application environment should transition the state of the application accordingly .

Implementers of middleware often need to decide on appropriate application launch conditions. An appropriate launch condition, however, is dependent on context and strategy.

• Transport signal : Broadcasters control when applications are available through signaling in the transport. Such signaling may occur randomly , as a result of a broadcaster injecting an application into a transport, or as a result of random tuning to a transport that already has this signal present. This signaling includes an indication of whether an application should be launched automatically. Receivers should only start loading the applications that are signaled for auto-launch. Nevertheless, receivers should notify a viewer what other applications are available and can be launched.

• Initial Working Set (IWS) : Most applications have an IWS which is a set of resources that must be loaded for the application to present its flash screen and perform some minimal functionality. The IWS may include some plug-ins that are required to decode some content, as well as some hardware resources. There are different methods for signaling the IWS in the transport, but it is clear that applications should not be launched before the IWS is available.

• Resource availability : Applications require resources. When the collection of resources that an application requires can be obtained, receivers should not start execution applications with required resources that cannot be granted.

4.6.3.5 Lazy versus Eager Resource Acquisition

There are two extremes associated with the decision to launch an application. Receivers may choose lazy and eager acquisition of resources. The lazy approach calls for loading or releasing resources during the execution of a program only when a reference is made; this model was adopted by Java. The eager acquisition model calls for loading all the resources of an application before launching the application. Receiver implementations may choose any middle ground in between, namely start the application as soon as its IWS is available, or delay the launch until more resources become available.

4.6.3.6 Running the Application

To enable concurrent detection and loading of multiple applications, receivers should implement a multi-threaded architecture (see Figure 4.14). These threads should be running in the background, independent of whether the receiver is turned on or off, and as long as the receiver is connected to the power source. These threads should wake up as soon as resources appear in the transport and perform the following steps: (1) receive the data stream (i.e., using tuners and decoders); (2) analyze and structure the data; (3) store the data to a data buffer or storage model; and (4) send events to the application execution thread indicating which actions need to be performed.

Figure 4.14. Dynamic operation of a receiver executing a downloaded application.

As the minimum set of resources for an application is loaded, the application execution threads start executing, performing the following steps: (1) reception of an event from the tuner thread, (2) constructing an instantiation of the root resource or IWS of that application (e.g., JavaTV Xlet class file); and (3) executing the application, thus generating the GUI that is converted into the receiver's output signal feeding the display.

4.6.3.7 Interaction with the Viewer

Applications that interact with the viewer must have the input focus. Although many applications may run in the background during the interaction, none should have an impact on the quality of interactivity of the input-receiving application. For example, as the viewer selects channel up and down keys, the selection should update on the screen immediately, without regard to the resources utilized by applications running in the background. Further, if the application performs a financial transaction, this application should not be terminated when the data service carrying the application terminates.

4.6.3.8 Suspension of an Application

As an application executes, the viewer may perform operations that require temporarily hiding an application's GUI (e.g., launch the EPG). Further, during its execution an application may refer to a resource not found in the cache (e.g., when a lazy acquisition approach is used). In such cases, the application environment should transition the application into a loading life-cycle state, and suspend its execution until the required resource is made available; note that, when needed, application should be able to continue execution (i.e., not get suspended ) without some non-critical resources. Cache misses could occur as part of normal operation, and often occurs as channels and applications are switched in response to viewer's commands.

An application may also be suspended whenever its service is not needed immediately but likely to be. Such a suspension could occur when, e.g., the viewer or another application minimizes an application. It can occur when an application makes a reference to an unavailable resource. It can also occur for shared application during channel change, between the time the previous transport stream is lost and the time that the same application is detected in the new channel.

4.6.3.9 Application Termination

An application could be terminated either by itself or by other applications running on the receiver or by the signaling from the broadcast. The viewer may request the termination of an application by interacting with its GUI or the GUI of another application. Broadcasters terminate applications by signaling, in the broadcast, the end of the data service delivering that application. Issues arise when such a signal arrives during the engagement with a financial transaction. Switching channels has the effect of signaling the termination of an application unless the target channel carries the active application. Once an application terminates, the application environment should ensure to release all its run-time resources.

4.6.4 Plug-in Life-cycle

Plug-ins have a life-cycle that is more complicated than the life-cycle of application; the primary difference is in the launch and trust determination steps.

• Plug-in download: The download of a plug-in is similar to the download of an application; it could be downloaded from the broadcast, or over the return channel. The download could be initiated by the application environment as a response to a request to perform a task (e.g., render a content type) that the plug-in can perform.

• Plug-in registration: Plug-ins need to provide the platform with sufficient information about their capabilities and interfaces. This information is often stored in persistent plug-in registry. Plug-ins are registered by adding their meta-data to the plug-in registry. It should be possible to register a plug-in before downloading it. In a PC-centric environment, the registration process is often referred to as installation and is often performed by an application that does not contain the plug-in. In an iTV environment, registration could be performed with a middleware API call either by the plug-in itself or by another application.

Registration of plug-ins may map plug-ins to content types to enable automatic invocation. For example, a JPEG decoder could be mapped to a JPEG content type. Such mapping would enable automatic launching of the plug-in whenever a JPEG image is encountered .

• Invocation : A plug-in may be invoked indirectly by the execution environment or by the application itself. For declarative content, the declarative application environment is likely to automatically invoke plug-ins based on declarative specification (e.g., of specific content-types). Plug-ins could be invoked to render an entire page's markup content or a component (e.g., image) within a page. Further, the plug-in rendering the page may invoke another plug-in rendering a component.

For procedural content, plug-ins may be invoked by API function calls. These APIs should not directly invoke the plug-in, but rather pass control to the middleware, which in turn invokes the plug-in.

• Trust Determination : As for applications, trust determination should precede execution. If the plug-in authenticates successfully, and the invocation is performed by a trusted application, then the plug-in should execute in trusted mode and should have access to privileged operations. In all other cases, the plug-in should be executed in untrusted mode and should not have access to privileged operations.

• Execution : The execution of a plug-in is similar to the execution of an application. Access to privileged operations is granted only for applications running in trusted mode. For declarative content, each plug-in is usually allocated a fixed rectangular GUI region. In contrast, procedural plug-ins may control the entire graphic configuration.

• Termination : Plug-ins used to decode components of applications (e.g., images), should not survive the termination of that application. However, plug-ins used to decode entire applications may survive the application they service.

• Rendering persistent : In some situations, it may be useful and possible to save or record the plug-in code for future use. In these cases, there is a need to grant it a name which is unique to the receiver; the name could be a URI. Once stored, its code resources (i.e., class files) should be made available to any application that may require its services. This operation could be performed at anytime before the de-registration step.

• De-registration : De-registration may occur as a side-effect of modification of the set of content types mapped to a plug-in. Plug-ins may be de-registered at any time when they are not running. De-registration could occur automatically, when the plug-in expires or by explicit operation by an application, often on behalf of the viewer.

• Disposal : Once de-registered, plug-ins may be purged. The mechanism should be performed as part of a global garbage collection process purging all plug-ins that cannot be invoked by any means.

4.6.4.1 Plug-in Scope

A single plug-in may be capable of decoding multiple content types. Similarly, there may be several plug-ins capable of decoding a specific content type. Therefore, issues may arise when attempting to resolve conflicting registration. Scoping is one approach for addressing these issues:

• Program scoped : A plug-in may be intended for use only for the duration of a specific program. This scope should have higher priority than any other scope, as it is the most specific. For example, an art-auctioning application may introduce a JPEG decoder that renders decorated frames around the images. Such registration expires as soon as the program expires.

• Channel scoped : A plug-in may be used as a channel differentiation feature of a virtual channel or an entire channel. As such, it could be scoped to automatically launch whenever the appropriate content type appears in the virtual channel or major channel (as scoped). This registration should be deactivated and reactivated on channel switching. Registration with a virtual channel scope should have higher priority than registration with a major channel scope, which should have higher priority than an affiliated channel scope.

• Affiliated channels scoped : A plug-in may be used as a network differentiation feature. For example, Disney may introduce certain features common to all the channels it owns. This registration should be deactivated and reactivated by channel switching. This registration should only have higher priority than the un-scoped registration.

• Author scoped : A plug-in may serve as a differentiating characteristic of a studio or producing organization. Such a registration should become active during execution of any application with author identifier meta-data that matches the identifier specified by the plug-in. If such a scope is enabled, several issues arise with regard to the priority of this scope.

• Unscoped : This is the broadest possible scope applicable whenever none of the other scopes are not applicable .

The scope may be resolved either at registration time, implying constraints on the content of the registry, or at run time, implying the needs of scoping logic during plug-in invocation.