1. Architectural Issues for Pervasive Computing
Sam Weber
James S. Jennings
samweber@watson.ibm.com jsj@watson.ibm.com
(914) 784-7662
(919) 543-3823
IBM T. J. Watson Research Center
30 Saw Mill River Road
Hawthorne, NY 10532
Abstract
Pervasive, wireless devices are becoming increasingly
available commercially.
Unfortunately, although
these devices show incredible promise, this potential
isn’t being met due to the lack of a suitable application infrastructure. In order to address this lack, our
group is undertaking a rapid prototyping and iteration effort, building middleware which is being used
by students at Carnegie-Mellon University to develop
applications.
In the course of this work, we have encountered
a number of general issues which we think are both
important and under-emphasized in the current literature. In particular, our application model encourages applications to be structured in such a way as
to allow transcoding and similar modifications to be
added post-deployment. Also, we advocate the use
of a security mechanism to protect application components from other misconfigured or malfunctioning
components.
Introduction
Small computing devices that have data networking capability are becoming increasingly pervasive.
Some, like Personal Digital Assistants (PDA’s) are
identified as palm-sized or hand-held computers,
while others, such as internet-ready cell phones, appear to only incidentally provide computing functions to their users. When these devices are sufficiently common, and when their access to wired
networks (e.g. intranets, the internet) is sufficiently
widespread, a new model of computing will emerge
in which users regularly interact with a highlydistributed heterogeneous infrastructure. Further,
this infrastructure is expected to be a highly avail-
able resource, and one which is shared among many
users to a much greater degree than current computing infrastructure is shared, due to the high mobility
of pervasive computing devices.
We pose the following question: In a world in
which networked computing devices are pervasive,
what model will applications follow? Implicit in the
question, of course, is the issue of what sort of infrastructure is needed to support a proposed application
model. Early computer applications were monolithic;
subsequently many applications had a client/server
structure, which presumed much about the network connecting the two; and recently a browserbased interface to remote distributed applications has
been adopted as a model for (desktop) platformindependence. The homogeneity of both browsers
and networking enables applications to be accessed
from many platforms, and from many places. Pervasive computing devices, by contrast, have a wide
variety of browser applications (due to variations in
available computing resources and user interface capabilities) and networking (from the slow but widely
available access of the 3COM Palm VII to the fast but
limited availability of “wireless ethernet” on machines
with PCMCIA wireless networking cards installed).
Consequently, it appears that new application models for pervasive computing should be proposed and
evaluated.
Project Overview
Designers of middleware often face a “chicken-andegg” problem: it is hard to design middleware without concrete applications that will use it, but applications can’t be built until at least the middleware has been prototyped. Therefore, we embarked
on a collabaration with various staff and students at
Carnegie-Mellon University (CMU). We undertook a

2. rapid prototyping effort, designing and implementing
prototype infrastructure, on top of which a class of
CMU students are implementing applications. Their
results will be fed back into further refinements of our
system.
At the time of writing, we have finished our initial design and implementation of our system, and
the CMU students are beginning to implement applications.
Initially, the staff for the CMU class generated
a list of scenarios for possible student development.
These scenarios included:
This was not too surprising. The Palm brand of personal organizer has had multitudes of applications
made available for it, many of which consist of variations of earlier applications.
Because of this, there was pressure to create a
flexible infrastructure – one that would allow and encourage such customizations. Counteracting this, we
needed to have a secure and robust system. We decided upon the goal to have a system whereby nonexpert programmers could easily create custom applications. However, applications had to have a reasonable degree of protection from other, malfunctioning,
applications. If a user decides to customize their de• devices with completely audio-centric user in- vice, they might possibly render it inoperative, but
terfaces,
that shouldn’t endanger other users or the system as
a whole.
• applications which determine the user’s physical location, and use that information to determine what information is appropriate for the Application model
user,
Figure 1 shows a high-level view of our system. A
• multi-user collaboration systems
small piece of system-level code on each device manThese scenarios generated severe requirements for our ages the device’s connection to the network. All applications talk to the network through this object,
software infrastructure.
Given the nature of the student’s projects, our which speaks a language-independent wire protocol.
middleware had to be non-trivially multi-user. How- The corresponding object on the network is the deever, user privacy was essential: users had to have vice proxy. The device proxy encapsulates all devicecomplete control over their own data, and data about specific information (including the wire protocol spoken by the device, a model of the device’s abilities,
themselves.
The wide range of targetted devices, and the etc.); to the rest of the network, the device proxy
audio-centric project, meant that device indepen- does indeed act as a proxy for the device.
Above each device proxy is a user proxy, which
dance was crucial. Even for the sake of prototyping
acts as a proxy for the end user. This is where the
there were very few device resources which we could
user may deploy autonomous agents, or set policies
assume existed.
One of the most salient remaining features was which might cut across a user’s devices. An example
customization of various types. Many of the scenar- of such a policy may be that notifications (e.g. inios proposed turned out, upon detailed examination, stant messages) should be queued at certain times of
to be similar to other scenarios, except for the ad- the day (perhaps late at night) unless they come from
dition, subtraction or modification of a component. certain people. When a message from an important
person comes in, the user proxy might choose which
Such customizations included:
of the user’s devices should receive it based on recent
• modification of a user-interface based upon de- usage or some other rule.
Finally, above the user proxies are services. Service characteristics,
vices interact with user proxies, as all authorization
• modification of a user-interface based upon per- and authentication is expected to be on a user basonal preference (such as wanting to listen to sis rather than a device basis. Consequently, device
email when walking),
proxies only communicate (on the network) with their
assigned user proxy.
• individually tailoring privacy concerns,
In this system, applications are considered to be
• filtering the output or input of an application or a collection of one or more components. Each applidata source, based upon some personal criteria cation component is associated with one of the above
system pieces: a device, device proxy, user proxy or
• causing two independently developed applica- network service. Essentially, each application comtions to interact
ponent can be considered a “plug-in” to one of these

3. One of the features that this security mechanism
implies is damage control: a malfunctioning component can only send messages to those components to
which it was given capabilities – it is impossible for
it to affect others. For instance, a device proxy component would only be given capabilities to its own
user’s proxy, or to the user’s device. It could never
send messages to other users, or to other devices.
Another feature is that it is easy to monitor a
component. This is done by only issuing the component capabilities which refer to routines that monitor
accesses. The monitored component has no means to
determine whether or not it is being watched.
It is illustrative to contrast this with such security
mechanisms such as signed ActiveX controls. These
mechanisms do cryptographic checks to make sure
Figure 1: Architecture Diagram
that the author of the control is “trusted.” However, once these checks are performed, the control
Communication model
is allowed to do anything. Essentially, one knows
whom to blame if a control misbehaves, but the sysProbably our most important, as well as novel, as- tem doesn’t limit the effects of such misbehaviour.
pects of our infrastructure is our communication
In the next section we explore some of the flexmodel. As described above, an application will conibility in our system in the context of an example
sist of one or more components, each component asapplication.
sociated with one of the basic parts of the system:
a device, device proxy, user proxy, or service. The
only means of interaction between components of the
Example
same or different applications are through our communication mechanism.
Consider a simple chat service and chat client. The
Recall that one of our major design criterion was
chat service supports many simultaneous chat rooms,
that, despite our systems flexibility, applications and
each with a single stream of dialog to which many
the system as a whole should be protected from misusers contribute in real time. The chat client is a
configured or malfunctioning applications.
program running on a device which allows the user
In order to enable this, we used a security mech- to choose any number of rooms to listen to, and one
anism, the “capability model”, that has been devel- room at a time in which to speak.
oped in the operating systems community [2, 1]. EsWe will describe three different possible implesentially, each component of our system will have zero
mentations of this application in our system, demonor more objects, called “capabilities”. Each capabilstrating its flexibility.
ity contains a reference to another component. The
difference between capabilities and simple pointers,
or network addresses, is that capabilities have the Client/Server
following properties:
A traditional client/server implementation of chat
1. A component A can communicate with compo- would put all of the user interface functionality on
nent B if and only if A has a capability that the device, and all of the back-end processing in the
chat service. In other words, the chat service would
refers to B.
maintain a list of subscribers to each room. The chat
2. Capabilities can’t be forged. A component A client would format messages arriving from the sercan create a capability to itself. However, if vice for display, perhaps in different windows, one to
it doesn’t have a capability to another compo- each room in which the user is listening. The client
nent B, it can’t simply create one, it must be also handles directing the user’s output to the approexplictly given one by someone else. 1
priate room, etc.
pieces. This is what allows applications to be customized post-deployment. For instance, in order to
support a new device, an additional application component could be added to the corresponding device
proxy in order to apply the correct transcoding.
1 Other capability systems have the concept of one component having the ability to create capabilities for components that
it “owns”. However, our system does not.

4. In our system, this model would be instantiated
by writing a device component which talks to the
chat service. The application would not have any
components which plug into the device proxy or user
proxy. Of course, a user could add their own device
or user proxy components, if they wished. For example, they could write a device proxy component which
intercepts chat service messages and buffers them if
the device is not in contact with the network. This
activity would be invisible to the chat client running
on the device, and also to the chat service.
Transcoding
Another way to deploy chat would be to deliberately
include a device proxy component. As mentioned
above, this module could serve as a buffer. But it
could also convert messages into a more appropriate
form for a particular device. For example, messages
from the chat service which use a multi-byte international character encoding could be converted to plain
(single-byte) ASCII for a device which can only display the plain ASCII character set. It is natural for
the device proxy to provide this function in order
to reduce the traffic on the wireless network to the
device, and also to reduce the computation needed
on the device, which is likely more limited than that
available on the wired network.
User Policies
The chat application could be further enhanced by
adding a user proxy component. This module could,
for example, redirect chat activity from one device
to another (owned by the same user). A user who is
participating in a chat session on a hand-held device
while sitting in the cafeteria may wish to redirect the
session to their desktop PC when they arrive back
at their office. Since all communication to and from
the chat service flows through the user proxy, the
user may use a “meta-application” which allows direct access to a specific component, such as the one
on the user proxy. This “meta-application” interface
might allow redirection of the current chat session
(with buffering) to another device. (It is presumed
that the new device already has a chat client of its
own, with any corresponding Device Proxy components which might be necessary.)
Conclusion
We are in the second phase of this project at the time
of this writing: the students at CMU are writing applications using our prototype system. While we do
not yet have the benefit of their feedback, we can
make some statements about principles we applied in
getting to this stage.
Keep infrastructure flexible. By providing infrastructure, we are imposing an application model.
However, we want that model to be as flexible as possible, to encourage as much innovation as possible in
the people using it.
Security cannot be added later. Systems must be
designed with security in mind from the outset. The
security of a system is always suspect, and can rarely,
if ever, be proven otherwise.
System robustness is crucial, and requires support.
The flexibility that pervasive systems call for comes
at a price: one has to take into account application
failure. This requires infrastructural support.
Acknowledgements
The authors would like to thank James Beck for helping to prototype our device support. Dr. Siewiorek,
Asim Smailagic, and numerous Carnegie-Mellon students have provided ample feedback.
References
[1] Carl E. Landwehr. Formal models for computer
security. Computing Surveys, 3(3):247–278, 1981.
[2] Jonathan Shapiro. What is a capability, anyway?
http://www.eros-os.org/essays/capintro.html.