We have worked out an
interoperable application, the electronic newspaper example, in considerable detail. We do
not give a single solution for this application, but we present options for such
solutions. These solutions may also be applicable to other kinds of application, but we
have not looked at that here.
Please note that the work presented needs completion, before it is suitable for DAVIC
specification.
In Section 0 a sample application scenario of the electronic newspaper is given. In the
Sections 0, 0, and 0 some issues and possible solutions are presented. Section 0 describes
a provisional API.
At the end of this document, in Section 0, we also describe a mechanism through which a
service provider can indicate what it would like to have cached.
An electronic newspaper
can consist of many objects in the carousel. These objects are to be presented to the user
in some manner; e.g., a viewer application presents a front page representing the
table of contents with links to other elements of the newspaper. Typical elements are
headlines, current affairs in politics, sports, the weather, etc. These elements are
typically only relevant for a limited time and they can be replaced by more recent ones.
A customer can subscribe to an electronic newspaper server of some service provider. This
will result in the installation of a so-called filter, which will be responsible to
cache objects related to the service on local storage. Also a certain amount of local
storage is reserved for the service. A storage manager will be responsible for the
handling and the administration of storage.
Since we do not want the viewer to be aware of local storage, i.e., we pursue transparent
access, we also introduce a resolver to take care of resolving the correct name of
a requested object.
To facilitate the electronic newspaper service, objects in the carousel need to have certain properties, like
Properties can either be assigned to individual objects or to sets of objects. When properties are assigned to individual objects, we have at least the following options:
However, assigning
priorities to individual objects has serious disadvantages. First, it requires
non-negligible bandwidth. Second, the set-top box must do considerable processing to
examine all the properties of the individual objects.
It is therefore much better to assign properties to sets of objects. Here we have at least
two options:
The second option enables easy pre-fetching, as will be explained in Section 0 on filtering.
This section describes
in more detail how an end-user could subscribe to an electronic newspaper.
The electronic newspaper application can be an MHEG-5 (or MHEG-6) application, associated
with a particular service. When the end-user selects that service, the set-top box
retrieves the application from the broadcast stream and starts up the electronic newspaper
application. The application asks the end-user whether he wants to subscribe and to which
parts of the newspaper. Based on the end-users’ answers, the application constructs a
filter and ‘installs’ it. This completes the subscription phase.
Note that the same MHEG application can also contain the functionality to view the newspaper.
An electronic newspaper
application may wish to cache (pre-fetch) two types of data. The first type of data is a
set of objects contained in an object carousel. The second type of data is (MPEG-2) video
streams. This section focuses on the first type of data. Currently, we are still
investigating the second type.
Two possible ways for a filter to specify which objects in a carousel should be cached
are:
The first option has a number of disadvantages. First, it requires that the set-top box must parse the module that contains an object in which the set-top box is interested. It must also parse the modules that contain an intermediate directory object in the path to the object. Also, all the directory objects in the specified sub-tree must be parsed, so the set-top box knows which other objects are part of the sub-tree. In short, this requires a lot of processing. Second, the set-top box must decompress modules if they are compressed. However, the set-top box ideally wants to store the objects in local storage in a compressed form. This means that first a module is decompressed and that subsequently the individual objects are compressed. This is waste of processing power.
The one advantage of this first option, however, is that it can be used for objects that must be accessed through the back channel, whereas the second option cannot be used for those objects. The reason for this is that the module concept is only used for object carousels, and not on the back channel, where DSM-CC uses an RPC-like mechanism.
The second option does not have the disadvantages of the first option: the set-top box no longer needs to parse any module when pre-fetching and it can store modules in a compressed form if they were broadcast in compressed form, thus saving storage space.
Another advantage is that it is easy to find out which modules should be pre-fetched. The service provider periodically broadcasts a message listing the modules that are part of an object carousel, the ‘DownloadInfoIndication’ message. This message contains for each module a ‘ModuleInfo’ structure. This structure has a field ‘userInfo’. The DSM-CC standard does not specify the use of this field; it is meant as an extension mechanism. This ‘userInfo’ field can easily contain the module tags. Thus, the set-top box retrieves the ‘DownloadInfoIndication’ message(s), and compares for each module the listed tags (in the ‘userInfo’ field) with the tags in the filter. If a tag matches, it pre-fetches the module.
Finally, it is easy to see whether a pre-fetched module needs updating. DSM-CC assigns to each module a version number (listed in the ‘Down-loadInfoIndication’ message). Thus, to check whether a pre-fetched module is still up-to-date, the set-top box retrieves again the ‘DownloadInfoIndication’ message and compares the version numbers.
Note: This API needs completion before it is suitable for DAVIC specification.
- by specifying a set of module tags. The objects contained in a module that matches (at least one of) the specified tags should be cached.
- by specifying a sub-tree of objects.
An open issue is how long the filters (cache requests) stay active. For example, what if the end-user runs the electronic news program once, subscribes, and then ‘never’ runs it again? It could be possible that the storage system tracks which data has been accessed and which not and when the data was stored. Then data that has been stored for a long time and that was never accessed, could be a candidate for being removed, and the filter that captured it, could be a candidate for being removed also.
Another open issue is whether there are limits on how many filters are allowed to be active at one time.
The logical place to add
the functionality that fulfils the requirements above is the DSM-CC UU API. Next to this
API, it may be desirable to add a small set of MHEG resident programs for similar
functionality, especially for MHEG-5 programs.
As each DSM-CC service domain has its own Service Gateway, representing the root of the
object tree, the ServiceGateway class of the DSM-CC UU API may be a good place to add
caching related functionality for that service domain. Methods similar to the following
could be added to this class:
/** This method starts
the pre-fetching of modules whose tags
* match at least one of the specified tags (subject to
*.storage space limitations). The modules are part of
* the service domain of this ServiceGateway.
* If ‘temporarily’ is true, the caching request applies
* only to the lifetime of the current execution of
* the application, otherwise it also applies afterwards. */
public void SetModuleTagsForCaching(String[] tags, boolean temporarily);
/** Stops the
pre-fetching of modules based on the specified
* tags (for this service domain). */
public void RemoveModuleTagsForCaching(String[] tags);
/** Returns all the
module tags that are used to pre-fetch
* modules of this service gateway.
* If ‘temporarily’ is true, then the returned values
* represent cache requests with the lifetime of the
* current application, otherwise the returned values
* represent cache requests that are not limited by
* the lifetime of the application.
**/
public String[] GetModuleTagsForCaching(boolean temporarily);
/** This method starts
pre-fetching the sub-tree with the
* root specified by the pathName (subject to storage space
* limitations). In principle, it will cross possible
* service boundaries,
* if needed. However, if a ‘newly needed’ service domain
* needs to be accessed through the back channel, then
* that part of the sub-tree that is part of that
* service domain will not be pre-fetched.
* If ‘temporarily’ is true, the caching request applies
* only to the lifetime of the current execution of
* the application, otherwise it also applies afterwards. */
public void SetSubtreeForCaching(NameComponent[] pathName, boolean
temporarily);
/** Stops the
pre-fetching of the sub-tree with the root
* specified by the pathName. */
public void RemoveSubtreeForCaching(NameComponent[] pathName);
/** Returns all the
names of the sub-tree roots that are
* used to pre-fetch objects.
* If ‘temporarily’ is true, then the returned values
* represent cache requests with the lifetime of the
* current application, otherwise the returned values
* represent cache requests that are not limited by
* the lifetime of the application.
**/
public NameComponent[][] getSubtreesForCaching( boolean temporarily);
A method similar to the following could be added to the Directory class:
/** Returns whether the
object specified by the pathName
* that is relative to this directory object is currently
* in the cache. */
public boolean isCached(NameComponent[] pathname);
Note that the appropriate exceptions, e.g. for indicating that an application is not allowed to request caching beyond the lifetime of its current execution, are to be added.
The above described how
an interoperable application can take the initiative to cache data. However, it may also
be desirable that the service provider indicates what it would like to have cached.
Suppose a service provider has been allocated a certain amount of local storage. Since
storage capacity is limited, the service provider may indicate the relative importance of
its data by giving priorities to its data elements.
As an example, a service provider may broadcast multiple applications, like an EPG,
play-along game and a banking application. It considers the EPG as its most important
application in the sense that the EPG should give the best response times. Thus, it wants
that this application to be in the cache whenever possible. The service provider can
signal this by giving the EPG application the highest priority.
An obvious way to provide the cache priorities is to include them in the Service Information (SI) tables/descriptors that describe cacheable data. For example, an Event Information Table could indicate the cache priority of each individual event, or the descriptor announcing an interactive application could indicate with which priority the application should be cached.
There is, however, a problem with providing cache priorities this way. If a STU wants to be sensitive to the cache priorities determined by the service provider and thus cache only those data and linear TV content that have a high enough priority, then the STU must have a complete view of all cacheable data and linear TV content and their associated cache priorities. Without such a complete view, the STU may miss cacheable data that it would have cached if the STU had known about it. The problem is that the STU must scan all tables/descriptors that can contain a cache priority, in all TSs, in order to get this complete view. This is a tedious way to obtain the cache priorities, because it requires sequential tuning to all TSs and the parsing of all the potentially interesting tables/descriptors.
A way to circumvent the
problem described above is to provide a SI table or descriptor that lists all cacheable
data to which the service provider has assigned a cache priority. The scope of such a
table/descriptor can be TS or a network. An item in the list is a < pointer to
cacheable data, cache priority > tuple. Optionally, a list item can contain a field
giving information on the required storage.
The pointer to the cacheable data can for instance be the SI identification of a service
event ("TV program") or an identification of where to find an interactive
application or other kind of data. The information on the required storage gives an
indication on how much storage the STU needs, to cache all the cacheable data that is
pointed to by the first element in the tuple.
By using the TS-wide or network-wide table/descriptor, the STU can quickly get a complete
view of all the cacheable data. For each TS/network, it simply parses a single SI
table/descriptor, and it combines the results.
The required bandwidth for broadcasting the table/descriptor can be low; i.e. the table
only needs to be broadcast occasionally. The STU does not need instant access to the
table/descriptor, because an access latency does not affect the performance of a direct
interaction with the end-user.