reconfigurable context-sensitive middleware for pervasive computing

1536-1268/02/$17.00 © 2002 IEEE PERVASIVEcomputing 33

Reconfigurable Context-Sensitive Middleware forPervasive Computing

Aprincipal goal of pervasive computingis to make the actual computing part ofit and its enabling technologies essen-tially transparent.1–3 This transparencyis partially possible because a pervasive

computing environment is a collection of embedded,wearable, and handheld devices wirelessly connected,possibly to fixed network infrastructures such as theInternet. Devices in such environments have seriousresource constraints and high vulnerability, and theyform numerous webs of short-range and low-powermobile ad hoc networks to exchange information. Thisnetworking characteristic distinguishes pervasive com-

puting environments from existingwireless and mobile phone net-works, where fixed infrastructuresenable communication.

Existing system prototypes andliterature indicate that pervasivecomputing applications operating

in ad hoc network environments usually exhibit twocharacteristics: context sensitivity and ad hoc com-munication.3–7An application software system’s con-text is any detectable and relevant attribute of thesoftware’s host device, the software’s user, the hostdevice’s surrounding environment, and the interac-tion between the host device and other devices.8–10

Context sensitivity (or context awareness) is an appli-cation software system’s ability to sense and analyzecontext from various sources; it lets application soft-ware take different actions adaptively in different con-texts. Ad hoc communication describes the links

among application software in various devicesbecause they tend to be spontaneously establishedand terminated due to changing contexts, devicemobility, and resource fluctuation.

Context sensitivity and ad hoc communication cutacross system and application layers. Sometimes,applications need to exploit their context sensitivityto communicate with other devices.11 A middleware-oriented approach can effectively address such issuesby providing development and runtime support andby striking a balance between awareness and trans-parency to the application software.12,13 In this arti-cle, we present Reconfigurable Context-SensitiveMiddleware to show how to achieve this balance (seewww.eas.asu.edu/~rcsm).10,14

What is RCSM?We can divide currently available middleware for per-

vasive computing applications into two main categoriesbased on how that middleware supports interactionamong devices. The first category lets application soft-ware indirectly communicate with each other by writingto and reading from one or more shared (but structured)spaces.15,16 Such middleware only treats contexts basedon the data stored in tuple spaces, thereby ignoring thedevice’s state (where the application software executes),network layers, and the surrounding environment aspart of the overall context. The second category pro-vides message-oriented semantics where application soft-ware objects see each other through mechanisms simi-lar to remote procedure calls.17–19

Our RCSM (see the “Glossary”for this and other

Context-sensitive applications need data from sensors, devices, anduser actions, and might need ad hoc communication support todynamically discover new devices and engage in spontaneousinformation exchange. Reconfigurable Context-Sensitive Middlewarefacilitates the development and runtime operations of context-sensitivepervasive computing software.

C O N T E X T - A W A R E C O M P U T I N G

Stephen S. Yau, Fariaz Karim, YuWang, Bin Wang, and Sandeep K.S. GuptaArizona State University

terms) is a middleware designed to facili-tate applications that require context-awareness or spontaneous and ad hoc com-munication. However, the mechanisms inRCSM that provide these two propertiesare not completely independent. In otherwords, we support these two characteris-tics in RCSM in such a way that it becomespossible to facilitate a third type of applica-tions that exhibits more complex behaviorthan context-aware applications or ad hoccollaborative applications do individually.

As Figure 1 shows, we characterize theproperty of this type of application as con-text-sensitive ad hoc communication. We

consider all three types of application tobe equally important for pervasive com-puting environments. Although findingexamples of simply context-aware or sim-ply ad hoc collaborative applications iseasy, we have observed that context-awaread hoc collaborative applications, such ascontext-aware messaging applications, aresteadily emerging.11,20,21

RCSM also has several major featuresthat address important middleware char-acteristics (see the related sidebar).

Object-based development frameworkSimilar to mature middleware stan-

dards and prototypes such as CORBA,COM (Component Object Model), andTAO (the ACE ORB, Advanced Comput-ing Environment Object Request Bro-ker)22 for fixed networks, RCSM providesan object-based framework for support-ing context-sensitive applications. Takingan object-based approach in RCSM pre-sents additional leverage beyond the ben-efits that simple object orientation pro-vides. RCSM models context-sensitiveapplication software as context-sensitiveobjects, which consist of two parts: a con-text-sensitive interface and a context-independent implementation. The inter-face encapsulates the description of theapplication’s context awareness, whereasthe implementation remains context free.

Application-specific adaptive objectcontainers

For context-sensitive application soft-ware, RCSM provides adaptive objectcontainers (ADCs) for runtime contextdata acquisition, monitoring, and detec-tion. Each application object needs dif-ferent contexts. Thus, as Figure 2 shows,RCSM’s context-aware interface descrip-tion language (CA-IDL) compiler gener-ates a custom-made ADC tailored for aparticular context-sensitive object. Dur-ing runtime, the ADC communicates withthe underlying system to acquire contextdata and then performs periodic contextanalysis as specified in the context-sensi-tive interface. It also communicates withthe object implementation to activate dif-ferent actions whenever the ADC detects

suitable contexts as a result of the contextanalysis.

Context-sensitive object request brokerFor pervasive application software that

needs ad hoc communication support, weprovide RCSM a context-sensitive objectrequest broker (R-ORB) as the key mech-anism for providing communication trans-parency for context-sensitive applicationsoftware. R-ORB hides the intricacies ofad hoc networking. It also performs deviceand service discovery on the behalf of thecontext-sensitive objects whenever theobjects’ context specifications become true.We use a symmetric communication modelin R-ORB to allow ad hoc and application-transparent information exchange betweena pair of remote context-sensitive objects.

A classroom example: Twoscenarios

Consider an instructor and his studentsusing their PDAs to collaborate in a class-room. In one scenario, when the instruc-tor is near the projection screen and thelight in the classroom is turned down, thecontext indicates that the instructor isabout to present some teaching material,which triggers the instructor’s PDA to dis-tribute the presentation material to the stu-dents’ PDAs. In another scenario, studentsare divided into small groups to collabo-ratively solve a specific in-class problem.During group discussion, the instructormoves from one group to another to checkthe students’ progress. When the instruc-tor is near a particular group of studentsand he is facing the group, the instructor’sPDA interprets this activity as an interest inthat group. This context data lets theinstructor’s PDA join the student group fora short duration to download that group’sdiscussion material.

These two scenarios show the followingthree common characteristics of pervasivecomputing applications.

Context sampling and detectionThe facts that the instructor is near the

projection screen and that the classroombecomes dark are two key pieces of datathat the application software in the first

34 PERVASIVEcomputing http://computer.org/pervasive


Context sensitivity (1)

Ad hoc communication (2)

Context-sensitive ad hoccommunication (3)

Figure 1. Pervasive computingapplications with properties one, two,and three facilitated by ourReconfigurable Context-Sensitive Middleware (RCSM).

ADC Adaptive object container

CA-IDL Context-aware interface

definition language

CAEG Context-aware ephemeral

group

CTC Context-triggered

communication channel

FPGA Field programmable

gate array

RCSM Reconfigurable Context-

Sensitive Middleware

R-ORB RCSM object request

broker

R-GIOP RCSM general inter-ORB

protocol

Glossary

JULY–SEPTEMBER 2002 PERVASIVEcomputing 35

M iddleware addresses two broad characteristics of perva-

sive computing: the trade-off between awareness and

transparency and cooperation between development support

and runtime services. However, it must address specific charac-

teristics as well.

Broad characteristicsLooking into other research,1–5 we learn an important lesson about

building effective middleware for pervasive computing environments:

how to provide a balance between awareness and transparency.6 This

contrasts with middleware for traditional computing environments,

where providing complete transparency of the underlying technology

and the surrounding environments is the ultimate goal. Such an ap-

proach does not work for pervasive computing applications because

being aware of the surrounding environment is the key to their effec-

tiveness. However, emerging applications for pervasive computing

indicate that an appropriate level of transparency is a desirable feature

to reduce the application software’s complexity and to optimize the

use of system resources in adverse conditions.

Although we mostly see the real benefits of middleware during soft-

ware execution, the difference between just good and widely success-

ful middleware is how easily it lets the application software developers

exploit its various capabilities. Well-defined development processes

and programming environments are equally important to developers.

Specific characteristicsIn light of these broad characteristics, middleware for pervasive

computing should also demonstrate specific characteristics to

facilitate pervasive computing applications.

Uniform development support. Almost all the commonly

used programming languages that exist today do not have basic

support for expressing context awareness. Even if context-aware

languages exist in the future, support for expressing context aware-

ness on a conceptual level will most likely differ across different lan-

guages. This poses a problem when developers of context-sensitive

application software need to reuse their designs in a different lan-

guage, hardware, or operating system. As such, middleware must

provide a uniform and common way to express the software’s con-

text awareness without restricting itself to a specific language,

operating system, or environment.

Application-specific context acquisition, analysis, and

detection. Providing a uniform and platform-independent inter-

face for applications to express their need for different context

data without knowing how that data is acquired is beneficial.

Application software is often concerned with observing multiple

contexts that follow a specific pattern of occurrence. Achieving

this requires continuous data acquisition, analysis, and pattern

detection. Middleware can help developers focus mainly on devel-

oping the applications’ functionality rather than diverting their

effort to hardware-specific issues.

Context-triggered action. Application software often decides

what action to take based on the current context. The action

could involve adapting to the new environment, notifying the

user, communicating with another device to exchange informa-

tion, or performing any other task. Middleware should provide the

facilities for application software to define such context-triggered

actions so as to transparently invoke them whenever the

corresponding contexts are valid.

Transparent support for ad hoc communication. We need

middleware to abstract the details of ad hoc communication from

applications to facilitate interoperability independent of network

type. The topologies in ad hoc networks change dynamically, and

devices might not know each other a priori. On the other hand, a

device in an ad hoc network could connect to a previously known

computer (via a file or a Web server) in a wired network. Thus, mid-

dleware should transparently facilitate a task-oriented or publish-sub-

scribe communication model so that application software can flexi-

bly interact in different network environments. This middleware

should also proactively discover new devices and functionalities,

establish new communication links, and notify the application layer

whenever it finds a compatible device. Furthermore, to let multiple

devices transparently join and communicate in short-lived groups,

the middleware should proactively check whether it should create

new groups or continue to maintain existing ones, depending on

application-specific criteria.

REFERENCES

1. A. Murphy, G. Picco, and G.-C. Roman, “LIME: A Middleware for Physi-cal and Logical Mobility,” Proc. 21st Int’l Conf. Distributed ComputingSystems, IEEE CS Press, Los Alamitos, Calif., 2001, pp. 524–533.

2. C. Mascolo et al., “XMIDDLE: A Data-Sharing Middleware for MobileComputing,” J. Wireless Personal Comm., vol. 21, no. 1, Apr. 2002, pp.77–103.

3. T. Kindberg and A. Fox, “System Software for Ubiquitous Computing,”IEEE Pervasive Computing, vol. 1, no. 1, Jan.–Mar. 2002, pp. 70–81.

4. D. Garlan et al., “Project Aura: Toward Distraction-Free Pervasive Com-puting,” IEEE Pervasive Computing, vol. 1, no. 2, Apr.–June 2002, pp.22–31.

5. B. Schilit, N. Adams, and R. Want, “Context-Aware Computing Applica-tions,” Proc. IEEE Workshop Mobile Computing Systems and Applications,IEEE CS Press, Los Alamitos, Calif., 1994, pp. 85–90.

6. L. Capra, W. Emmerich, and C. Mascolo, “Middleware for Mobile Com-puting: Awareness vs. Transparency,” Proc. 8th Workshop Hot Topics inOperating Systems, IEEE CS Press, Los Alamitos, Calif., 2001, pp. 164-169.

Middleware Characteristics

scenario needs. The second scenariorequires the analysis of two context attrib-utes: the instructor’s location and direction.

Spontaneous context-aware ad hoccommunication

The first scenario indicates that theinstructor’s PDA distributes the lecture mate-rials to the students’ PDAs as soon as appro-priate contexts are valid. This also impliesthat the instructor’s PDA must discover otherPDAs in the vicinity, check that they doindeed “need” the lecture material, andestablish temporary communication links.

Ad hoc ephemeral group establishmentThe second scenario indicates that stu-

dents’ PDAs dynamically form a group,which is valid only for the class’s duration.Moreover, the instructor’s PDA dynami-cally joins a particular group of studentsfor a short duration to download thegroup’s solutions to the in-class problem.

RCSM’s key capabilitiesAlthough contexts can conceptually

cover all aspects of a pervasive computingapplication’s environment, the context cap-tured by a specific application software islimited by the scope and capabilities of thehost device’s sensors and operating system.

Using context information is sometimesdifficult due to complex sensor handling,

context abstraction, and heterogeneous con-text sources.23 How to incorporate contextawareness into an application to make itmore intelligent is also a practical problem.Moreover, because pervasive computingapplications can have different requirementsfor using contexts, the current developmentprocess of such applications lacks a uniformand standard procedure for developers tofollow.

Several research groups have tried toovercome the difficulties in developing con-text-sensitive applications. In the ContextToolkit, a predefined context is acquired andprocessed in context widgets and thenreported to the application through appli-cation-initiated queries and callback func-tions.23 The Tea project provides queryprimitives for applications to acquire con-text information.24

We chose to design our context-pro-cessing system to directly trigger the appro-priate actions in an application objectrather than have the object itself decidewhich method (or action) to activate basedon context. Our primary motivation wasto extend existing context-sensitive appli-cations by adding new context sources. Wealso wanted to easily let multiple concur-rent contexts trigger a specific action. Aswe mentioned earlier, we divide context-sensitive application software into two sep-arate parts as shown in Figure 2. The first

is an interface that encapsulates the appli-cation’s context sensitivity. More specifi-cally, this interface lists the contexts theapplication uses, a list of actions (func-tionality) the application provides, and amapping between the specified contextsand these actions that clearly indicateswhen an action should be completed basedon specific context values. The second partis the actual implementation of the actionsthat the application software must provide.

The important characteristic of this struc-ture is that the implementation is com-pletely isolated from context specification,meaning it is context independent. This iswhere RCSM’s strength becomes visible.Using the context-sensitive interface,RCSM determines which context to mon-itor and which of the applications’ actionsto activate whenever a specified context isvalid. The developer simply focuses onimplementing the actions in his or herfavorite language without worrying aboutcontext monitoring, detection, and analysis.Our CA-IDL lets application developersuniformly specify the context-sensitiveobject interface. Instead of being static con-text-processing mechanisms, the type ofADCs that can be generated by the CA-IDLcompiler is virtually unlimited. For a dif-ferent requirement, the application devel-oper just needs to specify a different inter-face in the CA-IDL file and compile it togenerate a new ADC. Figure 3 shows anexample of a context-sensitive interface inCA-IDL. In this interface, three contextvariables are defined from our first scenarioexample: the instructor’s being near thescreen, darkness, and light. The expressionC1 ̂ (C2 → C3) uses our operators to spec-ify the temporal relationships among C1,C2, and C3. This particular expression indi-cates that C1 (instructor is near the screen)and C3 follows C2 (darkness follows light)must occur to transparently activate the dis-tribute method.



CA-IDL compiler(can generate ADCs in

different languages, such as C++, Java, or C#)

Context-independent implementation ofobject O (for example, C++, C, C#, or Java)

Context-sensitive interface for object O(expressed in CA-IDL)

Contextexpression

Methodsignature

+

Custom ADC for object O

Context-sensitive application object OFigure 2. RCSM’s context-aware interfacedescription language (CA-IDL) compilersbuild application-specific adaptive objectcontainers (ADCs) based on a context-sensitive interface description.

If multiple context triggers occur formethods in the same object, the corre-sponding ADC invokes the correspondingmethods in the order in which they appearin the object’s interface. If these context trig-gers correspond to different objects, no con-flict occurs because each object has its ownADCs that run independently of each other.

Spontaneous interaction support inR-ORB

Several challenges exist to letting appli-cation objects easily participate in sponta-neous interaction. First, network connec-tions in mobile ad hoc networks—the usualnetwork technologies for enabling sponta-neous networking—are often instanta-neously established and terminated due todevice mobility. Second, changes in the var-ious contexts cause application objects toadapt their operations continuously. Thisadaptation also affects communication,thereby demanding a seamless interopera-tion between context detection, triggering,and communication establishment mecha-nisms. Third, the heterogeneity of devices,network technologies, network types, inte-gration with the physical objects, and thebreadth of functional heterogeneity makeachieving interoperability among applica-tion objects difficult.5 Fourth, a set of corereusable services (such as service discovery,resource management, and object persis-tence) is usually required for any system sup-port to provide more practical solutions fordistributed collaboration.

Some notable client-server middlewaretechnologies for both enterprise and mobilenetworks support an asymmetric commu-nication model in which the ORB propa-gates a method invocation request from aclient to a particular server object. Clearly,connecting to a server implies that a clientmust discover the server dynamically or useprior information. Application objects exe-cuting in ad hoc environments are com-pletely autonomous and thus, characteriz-ing them as either clients or servers is hard.Moreover, there is no guarantee that theyhave any prior knowledge of each other. Weneed a symmetric communication modelthat lets a pair of remote objects commu-nicate without really knowing or seeing

each other. Other middleware technologiespromote such communication models. Forexample, Lime15 and Tspaces16 use tuplespaces to let objects transparently commu-nicate with each other.

We prefer a message-oriented and appli-cation-transparent communication modelbecause it lets us take a publish-subscribeapproach, easily support more complexcommunication patterns, and allow context-sensitive communications. We adopted thisapproach in RCSM and call it a context-trig-gered communication model. The RCSMORB supports communication in this fash-ion. However, having a context-triggeredcommunication protocol, which is internalto the R-ORB, does not suffice. We still needa good “packaging” solution to uniformlyease both the development and runtimeaspects between the context-processing layer(the ADCs) and the communication layer(the context-triggered communicationmechanism). We chose this (the CORBA,ORB-oriented) approach because the ORBfunctions as a single gathering point for

• Appropriately isolating the intricacies ofvarious transport protocols from theapplication objects by providing plat-form-independent interfaces

• Providing uniform interfaces to deployand use various distributed services inthe middleware for enhancing the appli-cation objects’ capabilities

• Providing reusable mechanisms to facili-tate object and service discovery, objectregistration, object activation and methodinvocation, and data marshalling overdistributed environments

Without an ORB, these capabilities are dif-ficult and often cumbersome to provide inthe transport layer, operating system, andapplication layer.

Context-triggered point-to-point com-munication channel management. A con-text-triggered communication channel(CTC) between two devices is a type ofcommunication link between two remoteR-ORBs. Such an inter-ORB link is estab-lished and terminated primarily based onapplication-specific context specification.During application execution, the R-ORBperforms proactive device discovery anduses its R-GIOP (RCSM General Inter-ORB Protocol) to establish and maintaina CTC with a remote device. The proto-col establishes a new channel based on thefollowing conditions:

• Reachability. Two devices—A and B—exist such that they are in each other’stransmission range.

• Existence of context-aware objects. Aand B each have at least one context-sensitive object.

• Suitability of activation in the current context. There exists at least one ADCcomponent in both A and B that hasrecently generated a context-match event,implying that the application object asso-ciated with such an ADC has at least onemethod that can be invoked currentlybased on its context specification. Letthese objects be Oa and Ob and theirmethods be Ma and Mb for A and B,respectively.

• Compatibility. Ma and Mb are suitable toexchange data with each other in the senseof matching interface signatures, includ-ing the number and types of parameters,


Figure 3. A context-sensitive interfacethat uses CA-IDL in a classroom scenario.

//context sourceRCSMContext dc {

char [] string location;boolean light;

};

//beginning of context-sensitive interfaceinterface instructor_object {

//context variablesRCSMContext_var dc C1

where location=”screen”;RCSMContext_var dc C2

where light=true;RCSMContext_var dc C3

where light=false;

//context-sensitive method[outgoing] [activate when C1^(C2->C3)] void distribute (string lectures);

};

//end of context-sensitive interface

or other application-specific criteria, suchas compatibility of radio-frequency iden-tifiers, security attributes, and so on.

To perform channel establishment, theR-ORB provides an adaptive device andservice discovery mechanism. As such, ifno object in the device is currently suitableto be activated, then the device and servicediscovery services are completely turnedoff to save bandwidth.

Ad hoc ephemeral group communicationusing the R-ORB. In the second scenarioexample described earlier, students formdynamic groups only for the class’s dura-tion, and the instructor joins and leavesthese groups for even shorter durations. Asopposed to groups in traditional distributedsystems, these student groups are dynami-cally formed and ephemeral. We call thiskind of group a context-aware ephemeralgroup. CAEG management and communi-cation use context as the collaborationagreement among several devices. TheCAEG communication mechanism is anoptional module of RCSM and relies on theR-ORB for ad hoc communication and onthe ADCs for context analysis.

RCSM component integrationFigure 4 shows how all of RCSM’s com-

ponents are layered inside a device. TheR-ORB assumes the availability of reli-

able transport protocols; only one R-ORBper device is sufficient. The number ofADCs depends on the number of context-sensitive objects in the device. ADCsperiodically collect the necessary “rawcontext data” through the R-ORB, whichin turn collects the data from sensors andthe operating system. Initially, each ADCregisters with the R-ORB to express itsneeds for contexts and to publish the cor-responding context-sensitive interface.RCSM is called reconfigurable because itallows addition or deletion of individualADCs during runtime (to manage new orexisting context-sensitive applicationobjects) without affecting other runtimeoperations inside RCSM.

To show how the integrated componentsin RCSM work together, consider the firstscenario in the earlier example. When theinstructor is near the screen, the ADC gen-erated from Figure 3’s interface finds thatthe new location is screen. At the same time,the light intensity is high, thus the ADC seesthat light value as true. Then, the instructorturns off the light in the classroom at thebeginning of the lecture, so the ADC seesthis light value as false. Thus, the contextexpression specified in Figure 3, C1 ̂ (C2 →C3), is found to be true. The ADC conveysthis context-match event immediately to theR-ORB, which then looks for a communi-cation partner—that is, a remote context-aware object that has a matched interface.

When the R-ORB finds that partner (anobject on a student’s PDA, for example), itsets up a communication channel with thatpartner and notifies the ADC. The ADCthen activates the associated action to down-load the materials. Both objects in theinstructor’s and the students’ PDAs areinvoked transparently through their respec-tive ADCs while the R-ORB addresses theactual information exchange. This, ineffect, achieves transparent and peer-to-peer interactions.

To evaluate RCSM, we are cur-rently implementing a projectcalled Smart Classroom as atestbed. Smart Classroom mon-

itors the classroom context (location of stu-dents or instructor, noise, light, and mobil-ity) and uses this context to triggercommunication activity among the studentsand the instructor. Related work in this areais based on different infrastructures and hasdifferent objectives. For example, SmartKindergarten uses sensor data on childrenor toys to make a record for the instructorto review children’s activities and track theirlearning progress.25 Smart Kindergartenanalyzes and stores context data in a wiredinfrastructure. Classroom 2000 capturesclassroom context (teaching material or stu-dent notes) to automatically generate Web-accessible multimedia class files for theinstructor and students.26 Both projects con-vert context information and the analysis ofcontext to permanent data (a record or anoutput file) for later use—neither uses con-text dynamically.

All the RCSM components in Figure 4could be implemented in software. How-ever, we have chosen a software-hardwarecodesign approach to explore the possibil-ity of providing some of RCSM’s function-ality in commodity hardware cards and toidentify the unique issues related to RCSM’shardware implementation. We are alsobuilding a software-only version of RCSMto quantify the potential performance ben-efits of the software-hardware codesigned



RCSM

Optional components

Context-sensitive application objects

RCSM ephemeral groupcommunication service

Core components

Adaptive object containers (ADCs)(providing awareness of context)

RCSM object request broker (R-ORB)(providing transparency over ad hoc communication)

Other services

Operating

system

Transport layer protocols for ad hoc networks Sensors

Figure 4. RCSM’s integrated components.

version. In the software-only version, theADCs, CAEG, and R-ORB run as separateprocesses on a Windows CE operating sys-tem. In the software-hardware codesignedversion, the R-ORB runs on hardware.Field programmable gate arrays facilitateour hardware design, because we can eas-ily load alternative gate-level designs of theR-ORB onto the same FPGA without fab-ricating custom hardware. We are using theCeloxica DK-1 tool to write the R-ORBbehavior in HandelC, a parallel version ofthe C language. The VHDL (or Verilog)code generated by DK-1 is fed into a Syn-opsis FPGAExpress synthesis tool to gen-erate the FPGA’s gate-level design.

In our current design, each node in thetestbed has the configuration in Figure 5,which consists of the following components:a Casio E-200 PDA; a Radiometrix radiopacket controller (RPC); a Trenz ElectronicUSB-compatible Xilinx Spartan II FPGAboard; a noise, light, and motion sensor; anda location-tracking component. We havealso developed simple location-beaconingboards by integrating an FPGA with theRPC controller. The current CA-IDL com-piler generates the ADCs in C++ for theWindows CE operating system. Each ADCtakes on the average 3 Kbytes. The R-ORB’sinitial hardware prototype runs on a Spar-tan II FPGA. A particular version of the R-ORB designed to support 16 applicationobjects (with 16 context-sensitive methods)

and 16 concurrent communication chan-nels currently occupies approximately31,000 logic gates in this FPGA. The FPGAwith this particular version of the R-ORBhas a maximum clock cycle of 150 MHz.In each cycle, this version of the R-ORB canprocess 1 byte of data to and from the appli-cation layer and other devices. The currentdesign only represents one particular imple-mentation of RCSM. Figure 6 shows thefuture configuration, which will have amuch more compact layout and can beused as a plug-in module on a PDA.

ACKNOWLEDGMENTSThis research is supported in part by the NationalScience Foundation under grants ANI-0123980 andANI-0196156. Microsoft Research and Tektronixdonated part of the equipment used in the testbed’sdevelopment. We thank the anonymous reviewersfor their comments and suggestions. We especiallythank Guerney Hunt of IBM T.J. Watson Research forproviding valuable assistance in improving this arti-cle. We also appreciate the assistance of SiddharthSeth, Pavankumar Nallamothu, and Deepak Chan-drasekar in the development of the testbed.

REFERENCES1. M. Weiser, “The Computer for the Twenty-

First Century,” Scientific Am., vol. 265, no.3, Sept. 1991, pp. 66–75.

2. S.K.S. Gupta et al., “An Overview of Per-vasive Computing,” IEEE Personal Comm.,vol. 8, no. 4, Aug. 2001, pp. 8–9.

3. G. Abowd and E.D. Mynatt, “Charting

Past, Present, and Future Research in Ubiq-uitous Computing,” ACM Trans. Com-puter Human Interaction, vol. 7, no. 1,Mar. 2000, pp. 29–58.

4. G. Chen and D. Kotz, A Survey of Context-Aware Mobile Computing Research, tech.report TR2000-381, Dept. of ComputerScience, Dartmouth College, Hanover,N.H., 2000.

5. T. Kindberg and A. Fox, “System Softwarefor Ubiquitous Computing,” IEEE Perva-sive Computing, vol. 1, no. 1, Jan.–Mar.2002, pp. 70–81.

6. D. Garlan et al., “Project Aura: Toward Dis-traction-Free Pervasive Computing,” IEEEPervasive Computing, vol. 1, no. 2,Apr.–June 2002, pp. 22–31.

7. M.L. Dertouzos, “The Future of Comput-ing,” Scientific Am., vol. 281, no. 2, Aug.1999, pp. 52–55.


Figure 5. A PDA, equipped with our current RCSM prototype, for the Smart Classroomtestbed. A software-only version of RCSM is currently under development.

Figure 6. (a) An expected future RCSMprototype and its use as a plug-in moduleat the (b) back of a PDA.

FPGA

(a)

(b)

PROM

Sensors

USB

8. B. Schilit, N. Adams, and R. Want, “Con-text-Aware Computing Applications,”Proc. IEEE Workshop Mobile ComputingSystems and Applications, IEEE CS Press,Los Alamitos, Calif., 1994, pp. 85–90.

9. A.K Dey, “Understanding and Using Con-text,” J. Personal and Ubiquitous Com-puting, vol. 5, no. 1, Feb. 2001, pp. 4–7.

10. S.S. Yau and F. Karim, “Context-SensitiveMiddleware for Real-Time Software inUbiquitous Computing Environments,”Proc. 4th IEEE Int’l Symp. Object-Ori-ented Real-Time Distributed Computing,IEEE CS Press, Los Alamitos, Calif., 2001,pp. 163–170.

11. N. Marmasse and C. Schmandt, “Location-aware Information Delivery with comMo-tion,” Proc. 2nd Int’l Symp. Handheld andUbiquitous Computing (HUC 2K), LectureNotes in Computer Science, P. Thomas andH.-W. Gellersen, eds., vol. 1927, no. 1,Springer-Verlag, Berlin, 2000, pp. 157–171.

12. P.A. Bernstein, “Middleware: A Model forDistributed Services,” Comm. ACM, vol.39, no. 2, Feb. 1996, pp. 86–97.

13. K. Geihs, “Middleware Challenges Ahead,”Computer, vol. 34, no. 6, June 2001, pp.24–31.

14. S.S. Yau and F. Karim, “Context-SensitiveObject Request Broker for UbiquitousComputing Environments,” Proc. 8th IEEEWorkshop Future Trends Distributed Com-puting Systems, IEEE CS Press, Los Alami-tos, Calif., 2001, pp. 34–40.

15. A. Murphy, G. Picco, and G.-C. Roman,“LIME: A Middleware for Physical andLogical Mobility,” Proc. 21st Int’l Conf.Distributed Computing Systems, IEEE CSPress, Los Alamitos, Calif., 2001, pp.524–533.

16. T.J. Lehman et al., “Hitting the DistributedComputing Sweet Spot with TSpaces,”Computer Networks, vol. 35, no. 4, Mar.2001, pp. 457–472.

17. C. Mascolo et al., “XMIDDLE: A Data-Sharing Middleware for Mobile Comput-ing,” J. Wireless Personal Comm., vol. 21,no. 1, Apr. 2002, pp. 77–103.

18. M. Haahr, R. Cunningham, and V. Cahill,“Supporting CORBA Applications in aMobile Environment,” Proc. 5th Int’l Conf.Mobile Computing and Networking(Mobicom 99), ACM Press, New York,1999, pp. 36–47.

19. C. Hess, M. Roman, and R.H. Campbell,“Building Applications for UbiquitousComputing Environments,” to be publishedin Proc. Int’l Conf. Pervasive Computing,2002; http://choices.cs.uiuc.edu/gaia.

20. Y. Nakanishi et al., “Context-Aware Mes-saging Service,” J. Personal and UbiquitousComputing, vol. 4, no. 4, Sept. 2000, pp.221–224.

21. N. Sawhney and C. Schmandt, “NomadicRadio: Speech and Audio Interaction forContextual Messaging in Nomadic Envi-ronments,” ACM Trans. Computer HumanInteraction, vol. 7, no. 3, Sept. 2000, pp.353–383.

22. D.C. Schmidt et al., “Software Architec-tures for Reducing Priority Inversion andNon-Determinism in Real-Time ObjectRequest Brokers,” Real-Time Systems, vol.21, nos. 1–2, July–Sept. 2001, pp. 77–125.

23. A.K. Dey and G. Abowd, “The Context-Toolkit: Aiding the Development of Con-text-Aware Applications,” Proc. Conf.Human Factors in Computing Systems(CHI), ACM Press, New York, 1999, pp.434–441.

24. A. Schmidt et al., “Advanced Interaction inContext,” Proc. 1st Int’l Symp. Handheldand Ubiquitous Computing (HUC 99), Lec-ture Notes in Computer Science, G. Goos,J. Hartmanis, and J. van Leeuwen, eds., vol.1707, no. 1, Springer-Verlag, Berlin, 1999,pp. 89–101.

25. A. Chen et al., “A Support Infrastructurefor Smart Kindergarten,” IEEE PervasiveComputing, vol. 1, no. 2, Apr.–June 2002,pp. 49–57.

26. G.D. Abowd, “Classroom 2000: An Exper-iment with the Instrumentation of a LivingEducational Environment,” IBM SystemsJ., vol. 38, no. 4, Oct. 1999, pp. 508–530.

For more information on this or any other comput-ing topic, please visit our Digital Library at http://computer.org/publications/dlib.



the AUTHORS

Stephen S. Yau is a profes-sor in the Department ofComputer Science and Engi-neering at Arizona State Uni-versity. He has served as thepresident of the IEEE Com-puter Society and the editor-in-chief of Computer maga-

zine. His research is in distributed computingsystems, software engineering, mobile comput-ing, and adaptive middleware. He received a BSfrom National Taiwan University, and an MSand PhD from the University of Illinois, Urbana,all in electrical engineering. He is a life fellow ofthe IEEE and a fellow of American Associationfor the Advancement of Science. Contact himat [email protected]; www.eas.asu.edu/~ssyau.

Fariaz Karim is a PhD can-didate in the Computer Sci-ence and EngineeringDepartment at Arizona StateUniversity. His research inter-ests include middleware,software–hardware codesignof embedded systems,mobile and pervasive com-

puting, wireless networks, and component-based software development. He received a BSin computer science from Arizona State Univer-sity. He is a member of the ACM, IEEE, and UPE.Contact him at [email protected]; www.fariakarim.com.

Yu Wang is a PhD candidatein the Department of Com-puter Science and Engineer-ing at Arizona State Univer-sity. Her research interestsinclude context-sensitiveand situation-aware applica-tions, mobile and distri-buted computing, pervasive

computing, and software engineering. She re-ceived her BS in computer science from WuhanUniversity in China. She is a member of UpsilonPi Epsilon. Contact her at [email protected];www.eas.asu.edu/~cse355s.

Bin Wang is a PhD studentin the Department of Com-puter Science and Engineer-ing at Arizona State Univer-sity. His research interestsinclude wireless networks,mobile computing, pervasiveand ubiquitous computing,and group communication.

He received his BEng in computer engineeringand an MS in computer science from the BeijingUniversity of Post & Telecommunications, China.Contact him at [email protected]; http://enws849.eas.asu.edu/~bwang.

Sandeep K.S. Gupta is anassociate professor in theDepartment of ComputerScience and Engineering atArizona State University. Hisresearch interests includewireless networks, mobileand pervasive computing,middleware, and embedded

sensor networks. He received the BTech incomputer science and engineering from theInstitute of Technology, Banaras Hindu Univer-sity, India, his Mtech in computer science andengineering from the Indian Institute of Tech-nology, Kanpur, and his MS and PhD in com-puter and information science from Ohio StateUniversity. He is a member of the ACM and asenior member of the IEEE. Contact him [email protected]; www.eas.asu.edu/~gupta.

reconfigurable context-sensitive middleware for pervasive computing

Documents