Architectural Concepts for Integrating Broadcast Data and

Streaming Services into a Mobile Internet-Based Platform

Gil Müller, Antonio Barletta, Boris Moser, Tobias Schulz-Hess and Rudolf Bittner
Sony International (Europe) GmbH, Advanced Technology Center Stuttgart - ATCS
Home Network Company Europe R&D – Mobile Multimedia
Phone: +49-711-5858-735 FAX: +49-711-5858-740 E-mail: gmueller@sony.de

Abstract
Many users of information services are well acquainted with the Internet interaction model. Therefore, broadcast
applications, which are introduced to an Internet platform, shall be based on this model. This results in a software
architecture, which combines a high-level application framework based on a standard web browser with native
middleware. The approach enables the rapid development of highly portable broadcast applications. The architecture
was utilized in a project, which combined data services and audio streaming via DAB with Internet services.

1. Introduction Basically, the same hierarchy can be used to embed a

Digital broadcast technologies like DAB [8] offer data
services similar to what is available in the WWW – based
on HTML, XML or Java. Last but not least, they provide
digital A/V streaming.
When digital broadcasting is introduced to an Internet
platform (e.g. a laptop), not only the data services have to
be presented like Internet services, but also the application
framework should be adapted to the platform itself.
This approach enables the rapid deployment of highly
portable and easily modifiable applications, which can
even be downloaded via broadcast [4].
2. The Architecture
In Fig. 1-A, the typical architecture for Internet terminals
(cf. [1], [10]) is shown. On top we have a web application
like an HTML page, which is rendered by a web browser.
This browser uses a pluggable protocol handler (PPH) to
resolve requests for Internet resources (for each protocol
there is a different handler). The PPH then uses an
operating system component to retrieve the resource. The
component itself utilizes one or more devices for
broadcast system into an Internet terminal (cf. Fig. 1-B).
The Web Browser is used to present the data services. A
special protocol handler is used to handle requests to
broadcast resources. The protocol handler uses some
middleware to access to broadcast receiver.
For applications like an EPG it is necessary to provide
direct access to broadcast information (e.g. to retrieve
service information). Additionally, broadcast data services
may contain updates of service information. This is not
supported by the current architecture of Internet terminals
as the information is only sent when the client requests it.
(The client-pull and server-push models offered by internet
technologies [2] are not satisfactory, because it either
requires the client to actively check for updates or is not
supported by all web browsers). A solution to this problem
is to send notifications from the middleware to the
application, which is presenting the data services. This
application then is able to request the updated information
using the protocol handler.
Broadcast Application

accomplishing the retrieval.

Web Browser
Web Application Broadcast Application

Pluggable
Bridge
Web Browser Protocol Handler
Web Browser

Broadcast Middleware
Pluggable Protocol Handler Pluggable Protocol Handler

OS Component (e.g. Network Broadcast Receiver

Broadcast Middleware
Protocol Stack)

Device (e.g. Network Card) Broadcast Receiver

Figure 2: Extended Architecture for Combined Broadcast and
(A) (B) Internet Terminal

Figure 1: Architecture of Internet Terminals (A) and a basic These two scenarios show that it is necessary to add a
Architecture for Combined Broadcast and Internet Terminals (B) separate path from the application to the middleware (cf.

Session: 06, 05
Figure 2). This kind of bridge (cf. Figure 2) can be
realized using technologies like Java or ActiveX.
With this architecture it is not only possible to deploy
resident broadcast applications, but also the applications
may be downloaded.
3. The Structure of the Middleware
The structure of the middleware is shaped by the need to
provide a suitable API for broadcast applications and the
pluggable protocol handler. The actual API style depends
on the application technology (e.g. [3], [4], or [5]). The
other shaping force originates from the functionality.
Functionality depends on the used devices and services.
But nevertheless, there are some indepedendent functional
building blocks (e.g. a building block which provides the
functionality of the broadcast system or does encryption).
In terms of functionality there are independent, but in non-
functional terms they share some behaviour. There are four
areas for the middleware management:
• Interface/Lifecycle Management: Each building block
provides one or more interfaces. An interface
undergoes a certain use cycle to which the lifecycle of
the building block is connected. E.g. when a certain
interface is requested, the related building block has to
be initialised. When it is later released, also the related
building block can be released. The management of
interface and related components is an essential part
of component technology (e.g. as in COM [6]), so we
will speak of components henceforth - instead of
building blocks.
• Client Management: For broadcast applications an
asynchronous interface has many advantages ([3]). To
realise this, the state of a transaction might have to be
managed.
• Security Management: As applications may be
downloaded, it is necessary to control the use of an
interface of a component. Conceptually, this is similar
to [9].
• Resource management: Different applications may
share a component, which leads to resource conflicts
(e.g. scanning for available services is requested,
while still a data application is used). The resolution
of the resource conflicts can be handled using some
protocol (e.g. [7]), but also administration is needed.
The resulting structure allows not only tailoring the
middleware to the needs of the application statically, but
also dynamically. This is especially important for mobile
applications, which are typically sensitive in terms of
resource and power consumption.
4. The Implementation
The architecture was realized in a project with the target to
provide audio and data broadcast services on a VAIO
laptop, which is connected to a portable Sony DAB
receiver (cf. Picture 1).
Session: 06, 05
Picture 1: The DAB Navigator
The system consists of a JavaScript application on top of
the Internet Explorer 5.5 from Microsoft. A native
middleware was used which included broadcast related
functionality and access to Internet streaming. As part of
the middleware management currently only interface/
lifecycle management is realized.
5. Conclusion
The discussed system was shaped by the need to integrate
broadcast data services tightly into an Internet platform.
This resulted not only on the use of Web technology for
the overall system design, but also it had significant
influence on the design of the native middleware.
Future steps will be to integrate more advanced Internet
technologies (Java mobile code, IP over DAB, UMTS
feedback channel) to have an integrated seamless mobile
platform.
6. References
[1] D.Esposito: „Pluggable Protocols“, Microsoft MSDN,
http://www.microsoft.com/mind/0199/cutting/cutting0199.htm , 1999.
[2] „ An Exploration of Dynamic Documents in Netscape 1.1“,
Netscape, http://home.netscape.com/home/demo/1.1b1/pushpull.html.
[3] R.Schäfer and R. Bittner: “Broadcast API – An application
programming interface for accessing information services provided by a
broadcast system”, European Patent Application No. 99 108 701.6 -2216,
1999.
[4] „DAB Java“, WorldDAB, forthcoming ETSI standard.
[5] G.Müller and A.Barletta: „ A high level DAB API for scripting
languages“, Internal Document, 2001.
[6] D.Box: „Essential COM“, Addison Wesley 1998.
[7] G.Müller and R.Schäfer: „Resource Conflict Resolution“, European
Patent Application No. 00 122988.9 -2216, 2000.
[8] Digital Audio Broadcasting (DAB): http://www.worlddab.org.
Official Website, World DAB Forum.
[9] Java Security: http://java.sun.com/security/, Sun Microsystems.
[10] W.Harris and R.Potts: “necko: the new netlib project”, Mozilla
Project, http://www.mozilla.org/docs/netlib/necko.html, 1999.