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 applica-
tion infrastructure. In order to address this lack, our
group is undertaking a rapid prototyping and itera-
tion 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 lit-
erature. In particular, our application model encour-
ages 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 com-
ponents from other misconfigured or malfunctioning
components.
Introduction
Small computing devices that have data network-
ing 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, ap-
pear to only incidentally provide computing func-
tions to their users. When these devices are suf-
ficiently 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 highly-
distributed 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 comput-
ing 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 infras-
tructure 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 net-
work connecting the two; and recently a browser-
based interface to remote distributed applications has
been adopted as a model for (desktop) platform-
independence. The homogeneity of both browsers
and networking enables applications to be accessed
from many platforms, and from many places. Per-
vasive computing devices, by contrast, have a wide
variety of browser applications (due to variations in
available computing resources and user interface ca-
pabilities) 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 mod-
els for pervasive computing should be proposed and
evaluated.
Project Overview
Designers of middleware often face a “chicken-and-
egg” problem: it is hard to design middleware with-
out concrete applications that will use it, but ap-
plications can’t be built until at least the middle-
ware has been prototyped. Therefore, we embarked
on a collabaration with various staff and students at
Carnegie-Mellon University (CMU). We undertook a
rapid prototyping effort, designing and implementing This was not too surprising. The Palm brand of per-
prototype infrastructure, on top of which a class of sonal organizer has had multitudes of applications
CMU students are implementing applications. Their made available for it, many of which consist of varia-
results will be fed back into further refinements of our tions of earlier applications.
system. Because of this, there was pressure to create a
At the time of writing, we have finished our ini- flexible infrastructure – one that would allow and en-
tial design and implementation of our system, and courage such customizations. Counteracting this, we
the CMU students are beginning to implement appli- needed to have a secure and robust system. We de-
cations. cided upon the goal to have a system whereby non-
Initially, the staff for the CMU class generated expert programmers could easily create custom appli-
a list of scenarios for possible student development. cations. However, applications had to have a reason-
These scenarios included: able 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 physi-
cal location, and use that information to deter-
mine 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 man-
These scenarios generated severe requirements for our ages the device’s connection to the network. All ap-
software infrastructure. plications talk to the network through this object,
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 de-
ever, user privacy was essential: users had to have vice proxy. The device proxy encapsulates all device-
complete control over their own data, and data about specific information (including the wire protocol spo-
themselves. ken by the device, a model of the device’s abilities,
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.
dance was crucial. Even for the sake of prototyping Above each device proxy is a user proxy, which
there were very few device resources which we could acts as a proxy for the end user. This is where the
assume existed. user may deploy autonomous agents, or set policies
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. in-
ios 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
Such customizations included: person comes in, the user proxy might choose which
of the user’s devices should receive it based on recent
• modification of a user-interface based upon de- usage or some other rule.
vice characteristics, Finally, above the user proxies are services. Ser-
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 ba-
sonal 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 appli-
data 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 com-
tions to interact ponent can be considered a “plug-in” to one of these
pieces. This is what allows applications to be cus- One of the features that this security mechanism
tomized post-deployment. For instance, in order to implies is damage control: a malfunctioning compo-
support a new device, an additional application com- nent can only send messages to those components to
ponent could be added to the corresponding device which it was given capabilities – it is impossible for
proxy in order to apply the correct transcoding. it to affect others. For instance, a device proxy com-
ponent 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 compo-
nent 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.” How-
ever, 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 sys-
Probably 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 flex-
model. As described above, an application will con-
ibility in our system in the context of an example
sist of one or more components, each component as-
application.
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
same or different applications are through our com-
Example
munication 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 mis-
users 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]. Es-
We will describe three different possible imple-
sentially, each component of our system will have zero
mentations of this application in our system, demon-
or more objects, called “capabilities”. Each capabil-
strating 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
refers to B. chat service. In other words, the chat service would
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 ser-
can 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 appro-
explictly given one by someone else. 1 priate room, etc.
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.

 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 exam-
ple, 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 interna-
tional character encoding could be converted to plain
(single-byte) ASCII for a device which can only dis-
play 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 di-
rect 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 compo-
nents 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 ap-
plications 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 in-
frastructure, we are imposing an application model.
However, we want that model to be as flexible as pos-
sible, 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 help-
ing to prototype our device support. Dr. Siewiorek,
Asim Smailagic, and numerous Carnegie-Mellon stu-
dents 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.