Architectural Issues for Pervasive Computing

Sam Weber James S. Jenningssamweber@watson.ibm.com jsj@watson.ibm.com

(914) 784-7662 (919) 543-3823IBM T. J. Watson Research Center

30 Saw Mill River RoadHawthorne, NY 10532

Abstract

Pervasive, wireless devices are becoming increasinglyavailable commercially. Unfortunately, althoughthese devices show incredible promise, this potentialisn’t being met due to the lack of a suitable applica-tion infrastructure. In order to address this lack, ourgroup is undertaking a rapid prototyping and itera-tion effort, building middleware which is being usedby students at Carnegie-Mellon University to developapplications.

In the course of this work, we have encountereda number of general issues which we think are bothimportant and under-emphasized in the current lit-erature. In particular, our application model encour-ages applications to be structured in such a way asto allow transcoding and similar modifications to beadded post-deployment. Also, we advocate the useof a security mechanism to protect application com-ponents from other misconfigured or malfunctioningcomponents.

Introduction

Small computing devices that have data network-ing capability are becoming increasingly pervasive.Some, like Personal Digital Assistants (PDA’s) areidentified 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 wirednetworks (e.g. intranets, the internet) is sufficientlywidespread, a new model of computing will emergein 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 manyusers to a much greater degree than current comput-ing infrastructure is shared, due to the high mobilityof pervasive computing devices.

We pose the following question: In a world inwhich networked computing devices are pervasive,what model will applications follow? Implicit in thequestion, of course, is the issue of what sort of infras-tructure is needed to support a proposed applicationmodel. Early computer applications were monolithic;subsequently many applications had a client/serverstructure, which presumed much about the net-work connecting the two; and recently a browser-based interface to remote distributed applications hasbeen adopted as a model for (desktop) platform-independence. The homogeneity of both browsersand networking enables applications to be accessedfrom many platforms, and from many places. Per-vasive computing devices, by contrast, have a widevariety of browser applications (due to variations inavailable computing resources and user interface ca-pabilities) and networking (from the slow but widelyavailable access of the 3COM Palm VII to the fast butlimited availability of “wireless ethernet” on machineswith PCMCIA wireless networking cards installed).Consequently, it appears that new application mod-els for pervasive computing should be proposed andevaluated.

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 embarkedon a collabaration with various staff and students atCarnegie-Mellon University (CMU). We undertook a

rapid prototyping effort, designing and implementingprototype infrastructure, on top of which a class ofCMU students are implementing applications. Theirresults will be fed back into further refinements of oursystem.

At the time of writing, we have finished our ini-tial design and implementation of our system, andthe CMU students are beginning to implement appli-cations.

Initially, the staff for the CMU class generateda list of scenarios for possible student development.These scenarios included:

• devices with completely audio-centric user in-terfaces,

• applications which determine the user’s physi-cal location, and use that information to deter-mine what information is appropriate for theuser,

• multi-user collaboration systems

These scenarios generated severe requirements for oursoftware infrastructure.

Given the nature of the student’s projects, ourmiddleware had to be non-trivially multi-user. How-ever, user privacy was essential: users had to havecomplete control over their own data, and data aboutthemselves.

The wide range of targetted devices, and theaudio-centric project, meant that device indepen-dance was crucial. Even for the sake of prototypingthere were very few device resources which we couldassume existed.

One of the most salient remaining features wascustomization of various types. Many of the scenar-ios proposed turned out, upon detailed examination,to be similar to other scenarios, except for the ad-dition, subtraction or modification of a component.Such customizations included:

• modification of a user-interface based upon de-vice characteristics,

• modification of a user-interface based upon per-sonal preference (such as wanting to listen toemail when walking),

• individually tailoring privacy concerns,

• filtering the output or input of an application ordata source, based upon some personal criteria

• causing two independently developed applica-tions to interact

This was not too surprising. The Palm brand of per-sonal organizer has had multitudes of applicationsmade available for it, many of which consist of varia-tions of earlier applications.

Because of this, there was pressure to create aflexible infrastructure – one that would allow and en-courage such customizations. Counteracting this, weneeded to have a secure and robust system. We de-cided upon the goal to have a system whereby non-expert programmers could easily create custom appli-cations. However, applications had to have a reason-able degree of protection from other, malfunctioning,applications. If a user decides to customize their de-vice, they might possibly render it inoperative, butthat shouldn’t endanger other users or the system asa whole.

Application model

Figure 1 shows a high-level view of our system. Asmall piece of system-level code on each device man-ages the device’s connection to the network. All ap-plications talk to the network through this object,which speaks a language-independent wire protocol.The corresponding object on the network is the de-vice proxy. The device proxy encapsulates all device-specific information (including the wire protocol spo-ken by the device, a model of the device’s abilities,etc.); to the rest of the network, the device proxydoes indeed act as a proxy for the device.

Above each device proxy is a user proxy, whichacts as a proxy for the end user. This is where theuser may deploy autonomous agents, or set policieswhich might cut across a user’s devices. An exampleof such a policy may be that notifications (e.g. in-stant messages) should be queued at certain times ofthe day (perhaps late at night) unless they come fromcertain people. When a message from an importantperson comes in, the user proxy might choose whichof the user’s devices should receive it based on recentusage or some other rule.

Finally, above the user proxies are services. Ser-vices interact with user proxies, as all authorizationand authentication is expected to be on a user ba-sis rather than a device basis. Consequently, deviceproxies only communicate (on the network) with theirassigned user proxy.

In this system, applications are considered to bea collection of one or more components. Each appli-cation component is associated with one of the abovesystem pieces: a device, device proxy, user proxy ornetwork service. Essentially, each application com-ponent can be considered a “plug-in” to one of these

pieces. This is what allows applications to be cus-tomized post-deployment. For instance, in order tosupport a new device, an additional application com-ponent could be added to the corresponding deviceproxy in order to apply the correct transcoding.

Figure 1: Architecture Diagram

Communication model

Probably our most important, as well as novel, as-pects of our infrastructure is our communicationmodel. As described above, an application will con-sist of one or more components, each component as-sociated with one of the basic parts of the system:a device, device proxy, user proxy, or service. Theonly means of interaction between components of thesame or different applications are through our com-munication mechanism.

Recall that one of our major design criterion wasthat, despite our systems flexibility, applications andthe system as a whole should be protected from mis-configured or malfunctioning applications.

In order to enable this, we used a security mech-anism, the “capability model”, that has been devel-oped in the operating systems community [2, 1]. Es-sentially, each component of our system will have zeroor more objects, called “capabilities”. Each capabil-ity contains a reference to another component. Thedifference between capabilities and simple pointers,or network addresses, is that capabilities have thefollowing properties:

1. A component A can communicate with compo-nent B if and only if A has a capability thatrefers to B.

2. Capabilities can’t be forged. A component Acan create a capability to itself. However, ifit doesn’t have a capability to another compo-nent B, it can’t simply create one, it must beexplictly given one by someone else. 1

One of the features that this security mechanismimplies is damage control: a malfunctioning compo-nent can only send messages to those components towhich it was given capabilities – it is impossible forit to affect others. For instance, a device proxy com-ponent would only be given capabilities to its ownuser’s proxy, or to the user’s device. It could neversend messages to other users, or to other devices.

Another feature is that it is easy to monitor acomponent. This is done by only issuing the compo-nent capabilities which refer to routines that monitoraccesses. The monitored component has no means todetermine whether or not it is being watched.

It is illustrative to contrast this with such securitymechanisms such as signed ActiveX controls. Thesemechanisms do cryptographic checks to make surethat the author of the control is “trusted.” How-ever, once these checks are performed, the controlis allowed to do anything. Essentially, one knowswhom to blame if a control misbehaves, but the sys-tem doesn’t limit the effects of such misbehaviour.

In the next section we explore some of the flex-ibility in our system in the context of an exampleapplication.

Example

Consider a simple chat service and chat client. Thechat service supports many simultaneous chat rooms,each with a single stream of dialog to which manyusers contribute in real time. The chat client is aprogram running on a device which allows the userto choose any number of rooms to listen to, and oneroom at a time in which to speak.

We will describe three different possible imple-mentations of this application in our system, demon-strating its flexibility.

Client/Server

A traditional client/server implementation of chatwould put all of the user interface functionality onthe device, and all of the back-end processing in thechat service. In other words, the chat service wouldmaintain a list of subscribers to each room. The chatclient would format messages arriving from the ser-vice for display, perhaps in different windows, one toeach room in which the user is listening. The clientalso handles directing the user’s output to the appro-priate room, etc.

1Other capability systems have the concept of one component having the ability to create capabilities for components thatit “owns”. However, our system does not.

In our system, this model would be instantiatedby writing a device component which talks to thechat service. The application would not have anycomponents which plug into the device proxy or userproxy. Of course, a user could add their own deviceor user proxy components, if they wished. For exam-ple, they could write a device proxy component whichintercepts chat service messages and buffers them ifthe device is not in contact with the network. Thisactivity would be invisible to the chat client runningon the device, and also to the chat service.

Transcoding

Another way to deploy chat would be to deliberatelyinclude a device proxy component. As mentionedabove, this module could serve as a buffer. But itcould also convert messages into a more appropriateform for a particular device. For example, messagesfrom 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 forthe device proxy to provide this function in orderto reduce the traffic on the wireless network to thedevice, and also to reduce the computation neededon the device, which is likely more limited than thatavailable on the wired network.

User Policies

The chat application could be further enhanced byadding a user proxy component. This module could,for example, redirect chat activity from one deviceto another (owned by the same user). A user who isparticipating in a chat session on a hand-held devicewhile sitting in the cafeteria may wish to redirect thesession to their desktop PC when they arrive backat their office. Since all communication to and fromthe chat service flows through the user proxy, theuser may use a “meta-application” which allows di-rect access to a specific component, such as the oneon the user proxy. This “meta-application” interface

might allow redirection of the current chat session(with buffering) to another device. (It is presumedthat the new device already has a chat client of itsown, with any corresponding Device Proxy compo-nents which might be necessary.)

Conclusion

We are in the second phase of this project at the timeof this writing: the students at CMU are writing ap-plications using our prototype system. While we donot yet have the benefit of their feedback, we canmake some statements about principles we applied ingetting 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 inthe people using it.

Security cannot be added later. Systems must bedesigned with security in mind from the outset. Thesecurity 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 comesat a price: one has to take into account applicationfailure. 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 computersecurity. Computing Surveys, 3(3):247–278, 1981.

[2] Jonathan Shapiro. What is a capability, anyway?http://www.eros-os.org/essays/capintro.html.