Middleware Support for Context-awareness inAsynchronous Pervasive Computing Environments

Jianping Yu1,2, Yu Huang1,2+, Jiannong Cao3, Xianping Tao1,2

1State Key Laboratory for Novel Software TechnologyNanjing University, Nanjing 210093, China

2Department of Computer Science and TechnologyNanjing University, Nanjing 210093, China

csjpyu@gmail.com, {yuhuang, txp}@nju.edu.cn3Internet and Mobile Computing Lab, Department of Computing

Hong Kong Polytechnic University, Hong Kong, Chinacsjcao@comp.polyu.edu.hk

Abstract—Context-awareness is an essential feature of per-vasive applications, and runtime detection of contextual prop-erties is one of the primary approaches to enabling context-awareness. However, existing context-aware middleware does notprovide sufficient support for detection of contextual propertiesin asynchronous environments. We argue that in asynchronousenvironments, the concept of time needs to be reexamined.Instead of assuming the availability of global time or synchronousinteraction, we should rely on logical time. To this end, wepresent the Middleware Infrastructure for Predicate detectionin Asynchronous environments (MIPA), which supports context-awareness based on logical time. Design and operation of MIPAare explained in detail. We also evaluate MIPA with a comprehen-sive case study. The evaluation results show the cost-effectivenessand scalability of MIPA.

I. INTRODUCTION

Pervasive applications are typically context-aware, usingvarious kinds of contexts, such as location and time, to providesmart services [1]. Context-aware applications need to monitorwhether contexts bear specified property, thus being able toadapt to the computing environment accordingly [2]. Thisbrings the primary issue of contextual property detection [3],[4], [5], [6]. Though detection of contextual properties hasbeen widely studied in pervasive computing and softwareengineering communities, it still remains a challenging issue,mainly due to the following two observations.

Contextual properties of concern to the context-aware appli-cations bear great variety and dynamism. Specifically, users arenot only interested in local contextual properties, which can beeasily obtained by singular context collecting devices, but alsointerested in global ones, which involve multiple decentralizeddevices for context collection.

Meanwhile, users are not only interested in static proper-ties of contexts. Though static properties capture interestingaspects of contexts, they inherently lack the delineation oftemporal and relative order [7], [6]. In many cases, users arealso interested in behavioral properties, delineating temporalevolution of the environment.

+Corresponding author.

In contrast to the variety and dynamism of contextualproperties, the detection is greatly complicated by the in-trinsic asynchrony in pervasive computing environments [2],[8], [5], [6], [9]. Specifically, context collecting devices donot necessarily have a global clock. They heavily rely onwireless communications, which suffer from finite but arbitrarydelay. Moreover, due to resource constraints, context collectingdevices (usually resource-constrained sensors) often schedulethe dissemination of context data. The different context updaterates also result in asynchrony.

In order to achieve context-awareness in asynchronousenvironments, the concept of time needs to be reexamined.Instead of assuming the availability of global time or syn-chronous interaction, we should rely on logical time. Thebasic rationale behind is to utilize the happen-before relationresulting from message causality [10], and its “on the fly”coding given by logical vector clocks [11], [12]. However,existing context-aware middleware does not provide sufficientsupport for detection of contextual properties in asynchronousenvironments.

To this end, we develop the Middleware Infrastructure forPredicate detection in Asynchronous environments (MIPA)[13]. MIPA is the first open-source context-aware middleware,which provides systematic support for coping with the asyn-chrony while achieving context-awareness in pervasive com-puting environments, as far as we know. Based on MIPA, userscan flexibly specify contextual properties by different typesof predicates defined over asynchronous pervasive computingenvironments. MIPA accepts such predicates and supportscontext-awareness by online predicate detection.

A comprehensive case study is conducted to evaluate MIPA.In the case study, we implement over MIPA a smart lockscenario. The evaluation results show the cost-effectivenessand scalability of MIPA in pervasive computing scenarios.

The rest of this paper is organized as follows. We firstdiscuss runtime detection of contextual properties in asyn-chronous environments in Section II. Section III and SectionIV present the design and operation of MIPA. Section V

2010 IEEE/IFIP International Conference on Embedded and Ubiquitous Computing

978-0-7695-4322-2/10 $26.00 © 2010 IEEE

DOI 10.1109/EUC.2010.29

136

presents the case study and Section VI reviews the existingwork. In Section VII, we conclude the paper with a briefsummary and the future work.

II. RUNTIME DETECTION OF CONTEXTUAL PROPERTIESIN ASYNCHRONOUS ENVIRONMENTS

In this section, we first discuss how we model the asyn-chronous pervasive computing environment. Then we discusshow users specify contextual properties on MIPA.

Detection of contextual properties assumes the availabilityof an underlying context-aware middleware. The middlewareaccepts contextual properties specified by the application,detects at runtime whether the properties are satisfied, andinforms the application of the results (see detailed discussionsin Section III). Specifically, in order to detect contextual prop-erties, a collection of non-checker processes P1, P2, · · · , Pn

are deployed to monitor specific regions/aspects of the en-vironment. Examples of non-checker processes are sensoragents manipulating physical sensors. One checker processPche collects context information from non-checker processes,and achieves runtime detection of contextual properties. Pche

is usually a third-party service deployed on the context-awaremiddleware.

A. System Model

We model the non-checker processes as a loosely-coupledmessage passing system, without any global clock or sharedmemory. Communications suffer from finite but arbitrarydelay. Dissemination of context data may also be delayed dueto resource constraints. The detection of contextual propertiesis based on the classical Lamport’s definition of the happen-before (denoted by ‘→’) relation resulting from messagecausality [10], and its “on the fly” coding given by Matternand Fidge’s logical vector clocks [11], [12].

Messages passed in the system can be classified into twotypes: i) Control message: non-checker processes send controlmessages among each other to establish the happen-beforerelation among contextual activities. This enables further de-tection of contextual properties confronting the asynchrony; ii)Checking message: non-checker processes send vector clocktimestamps of contextual activities via checking messages tothe checker process.

The execution of Pk is represented by a series of local statesconnected by contextual events: “sk0ek0, sk1ek1, sk2ek2 · · ·” 1.A global state is defined as a vector of local states with onelocal state from each Pk. If the constituent local states arepairwise concurrent, the global state is a Consistent GlobalState (CGS), which denotes a meaningful observation of theglobal system state [14].

We define the “precede” (denoted by ‘≺’) relation betweentwo CGSs: g ≺ g′ iff g′ is obtained via advancing g byexactly one step on one non-checker process. The “lead-to”relation (denoted by ‘ ’) between two CGSs is defined asthe transitive closure of ‘≺’. The set of all CGSs with the

1For the ease of presentation, we omit the events and only refer to the statesin the rest of this work.

Fig. 1. The lattice of computation

‘ ’ relation define a lattice[7], [14]. The run of a context-aware system can be viewed as the advancement from oneCGS to the next over the lattice. We define a sequence ofCGSs, where adjacent CGSs has the ‘ ’ relation, as a GlobalSequence (GSE).

B. Specification of Contextual Properties

The key notion of our system model is the hierarchyconsisting of Local States, CGSs and GSEs [15]. Users canspecify predicates on each level of the hierarchy. Specifi-cally, i) A Local predicate is specified over contexts localto some computing device; ii) A CGS predicate consists oflocal predicates combined by logic operators, one from eachPi(1 ≤ i ≤ n) in the CGS; iii) A GSE predicate is defined asthe conjunction of CGS predicates defined on the constituentCGSs.

Note that the happen-before relation we obtain is usuallya partial order among the contextual events. Due to the un-certainty resulting from this partial order, we need to interpretpredicates under modality Pos(φ) and Def(φ). More detaileddiscussions on the definition of predicates can be found in [16],[7], [15].

In our model, users can use local predicates to specify prop-erties limited to specific region the computing environment.CGS predicates can be used to specify properties of specificsnapshot of the asynchronous environment. GSE predicatescan be used to specify behavioral properties concerning tem-poral evolution of the environment. In our previous studies [5]and [6], we studied the detection algorithms for CGS and GSEpredicates respectively.

III. MAPPING CHARACTERISTICS OF PROPERTYDETECTION TO MIDDLEWARE STRATEGIES

In this section, we first discuss the characteristics of contex-tual property detection in asynchronous environments. Thenwe discuss how such characteristics motivate design of theMiddleware Infrastructure for Predicate detection in Asyn-chronous environments (MIPA) [13]. In the next section, wefurther explain the operation of MIPA.

137

A. Characteristics of Predicate Detection

The detection of contextual properties is transformed tothe detection of logic predicates specified over the contexts.Predicate detection in asynchronous environments has thefollowing salient characteristics:C1. Dynamic composition of predicate checkers. Predicatedetection can be viewed in a top-down manner based onthe hierarchy of predicates discussed in Section II.B. In thehighest level, detection of a GSE predicate requires detectionof the constituent CGS predicates. It also requires that all theCGSs involved form a GSE. Similarly, detection of a CGSpredicate requires detection of the constituent local predicates.It also requires all the local states involved form a CGS. Dueto the hierarchical structure of predicates, the checker of anupper level predicate can be constructed from checkers forlower level predicates. Moreover, checkers for the constituentpredicates may lie on multiple distributed devices. The upperlevel checker may need to coordinate multiple distributedcheckers.C2. Monitoring the dynamic environment. Checking a localpredicate is simple in the sense that it does not requireinteraction among distributed devices. However, the criticalissue is that checking of local predicates must capture dynamicchanges in the computing environment.C3. Integration of new sensors. Users’ requirements oncontext-awareness is open-ended. When new types of con-text collecting devices are available, users need to integratesuch new devices, obtain new types of contexts, and specifypredicates over such new contexts.

B. Overview of MIPA Design

Design of MIPA is motivated by the characteristics ofpredicate detection. From MIPA’s point of view, a pervasivecomputing environment is composed of an application layer, aproperty detection layer and a context source layer, as shown inFig. 2. The context source layer persistently collects contextsof concern. The property detection layer receives contexts frommultiple decentralized and asynchronous context sources, anddetects specified contextual properties at runtime. The keycomponents of MIPA are outlined below. They are discussedin detail in the following Section III.C to Section III.E.

Predicate detection in groups. Motivated by C1 discussedabove, i) MIPA supports composition of lower level predicatecheckers to obtain higher level checkers; ii) MIPA supportsdistributed deployment of the checkers. This is achieved bygrouping of different checkers. Specifically, the grouping canbe decided by the predicate structure, i.e., lower level checkersconsisting the same upper level checker belong to the samegroup. We can also further group the checkers according tothe network condition.

Contextual event notification. In order to achieve accu-rate and timely monitoring of the environment as requiredin C2, we adopt the Event-Condition-Action (ECA) mecha-nism. Changes in the environment are modeled as contextual“events”. Local predicates are interpreted as the “condition”

Fig. 2. System architecture of MIPA

to filter raw contextual events. Non-checker process serves asthe event listener (“action”).

Pluggable sensor agents. To ease the inevitable processof integrating new types of context collecting devices, asrequired in C3, MIPA treats the sensor agents (in charge ofmanipulating the hardware sensors) as plug-ins. New types ofsensors encode their configurations in XML, which followsthe DTD specified by MIPA.

The operation of MIPA also requires a number of systemcomponents, as discussed in Section III.F.

C. Property Detection Manager

Contextual properties of concern to the application is in-tercepted by the property detection manager. The propertydetection manager employs the predicate parser to parse theproperties encoded in XML and obtains structure of thepredicate. Further initiation of the checkers and the contextualevent notification modules depends on parsing of the predicate.

Based on the predicate structure, the manager initiates pred-icate checkers in a bottom-up manner. The manager contactsthe context modeling and context retrieval modules to obtainwhere to initiate the contextual event notification modules(discussed in Section III.D). The contextual event notificationmodule persistently updates values of the local predicates.The CGS predicate checker receives online updates of localpredicate values and checks the CGS predicate. In the highestGSE level, the GSE checker collects CGS predicate valuesfrom the CGS checkers and decides whether the user-specifiedcontextual property holds.

Grouping of the checkers is first decided by the predicatestructure. Contextual event notification modules belonging tothe same CGS predicate are organized in the same property de-tection group. Similarly, since MIPA may support concurrentchecking of multiple GSE predicates, CGS checkers belongingto the same GSE checker are also organized in the samegroup. Grouping of the checkers can be further decided by thenetwork condition. As we know, a pervasive application mayspan multiple smart spaces [1]. Communications within onesmart space is usually much less expensive than those acrossmultiple smart spaces. In light of this, if predicate checkersin the same group span different smart spaces, they can befurther divided into multiple groups to reduce the expensivecross-space communications.

138

<!ELEMENT s e n s o r ( name , id , c l a s s ,l o c a t i o n , ValueType , DataSchema ,D a t a D i s s e m i n a t e , a rgumen t s )>

<!ELEMENT name (#PCDATA)><!ELEMENT i d (#PCDATA)><!ELEMENT c l a s s (#PCDATA)><!ELEMENT l o c a t i o n (#PCDATA)><!ELEMENT ValueType (#PCDATA)><!ELEMENT DataSchema EMPTY><!ATTLIST DataSchema t y p e ( push | p u l l )

#REQUIRED><!ELEMENT D a t a D i s s e m i n a t e EMPTY><!ATTLIST D a t a D i s s e m i n a t e u p d a t e F r e q

CDATA #REQUIRED><!ELEMENT a rgumen t s ( a rgument ) +><!ELEMENT argument (#PCDATA)>

Fig. 3. The DTD of sensor configurations

D. Contextual Event Notification

To cope with dynamic changes in the pervasive computingenvironment, we adopt the ECA mechanism [3] to achievepersistent monitoring of the environment. We model updatesof the environment as contextual events. The non-checkerprocess serves as the event listener (“action”). The non-checker process first registers the contextual events. The eventcondition module adopts the local predicate as the condition.The raw events are filtered by local predicates and then sent tothe non-checker process. The non-checker process proactivelybuilds the happen-before relation among contextual events,which enables further predicate detection. Then it reports localpredicate values to the checkers.

E. Pluggable Sensor Agents

With the development of sensing technologies, users in-evitably need to integrate new types of context collectiondevices, in order to obtain new types of contexts. Then userscan specify predicates over the newly obtained contexts. MIPAadopts sensor agents to manipulate the hardware sensors.Sensor agents are implemented as plug-ins. When new typesof sensors are available, their configurations are specified inXML, following the definition (DTD) specified by MIPA.We also need to update the context modeling module toassociate raw data from the newly integrated sensor agent withexisting / newly-added contextual events. The DTD of sensorconfigurations is listed in Fig. 3. An exemplar configurationof an RFID reader is listed in Fig. 4.

F. System Components

Operation of MIPA also relies on multiple system compo-nents, which are presented below:Resource management. The resource manager maintains in-formation about context collecting devices in different smartspaces. It also supports the adding and removal of contextcollecting devices.

Naming. When non-checker processes are initiated, the namingservice facilitates the binding between the sensor agents andthe corresponding context-collecting devices.Context modeling and retrieval. The context modeling modulebuilds the mapping between local predicates and contextualevents. The context retrieval module provides information forthe ECA modules to be launched for the corresponding localpredicates.

IV. MIPA IN ACTION

Based on the design of MIPA discussed above, we havedeveloped a set of middleware components that collectivelyaddress the smart lock scenario first explored in our previousstudies [17], [6]. We use this scenario (Fig. 5) to exemplifythe operation of MIPA.

A. The Smart Lock Scenario

In this scenario, the smart lock application automaticallylocks the office when the user leaves. As discussed in SectionII, we can derive the contextual property for the smart lockapplication by traversing the predicate hierarchy in a bottom-up manner:Local predicate. User’s location can be easily detected by onesingular type of sensor. In this scenario, we can use the RFIDreader or the light sensor to detect the location. Delineation ofwhether the user is in the office can be easily achieved by localpredicate “φ1

LP = the user is detected by the RFID reader inthe office”, or “φ2

LP = the user is detected by the light sensorin the office”.CGS predicate. Obviously, the smart lock application requiresaccurate detection of the user’s location. However, the contextis usually quite noisy [3], [4]. To improve quality of thelocation context, we use both the RFID reader and the lightsensor to decide user’s location. To delineate that the user isin the office, we can specify the CGS predicate “φ1

CGS = (theuser is detected by the RFID reader in the office)

∧(the user

is detected by the light sensor in the office)”. Similarly, we can

<? xml v e r s i o n =” 1 . 0 ” e n c o d i n g =”UTF−8” ?><!DOCTYPE s e n s o r SYSTEM ” s e n s o r . d t d ”><s e n s o r>

<name>RFID 506< / name><i d>RFID 12345< / i d><c l a s s>n e t . s o u r c e f o r g e . mipa . eca .

s e n s o r . RFID< / c l a s s>< l o c a t i o n>n j u< / l o c a t i o n><ValueType>S t r i n g< / ValueType><DataSchema t y p e =” push ” /><D a t a D i s s e m i n a t e u p d a t e F r e q =” 1 ” /><a rgumen t s>

<argument>d a t a / RFID< / a rgument>< / a rgumen t s>

< / s e n s o r>

Fig. 4. Configurations of an RFID reader

139

Fig. 5. MIPA in action

detect whether the users is outside the office (in the corridor)by the CGS predicate “φ2

CGS = (the user is detected by theRFID reader in the corridor)

∧(the user is detected by the

light sensor in the corridor)”.GSE predicate. Though the CGS predicate can improve qualityof the location context, it can only capture static status of theuser (e.g, in the office). In order to delineate user’s behavior ofleaving the office, we interpret this behavior as “the users isstaying in the office and then he is outside the office”. Wespecify the GSE predicate “φGSE = φ1

CGS φ2CGS” to

delineate this behavior. The smart lock application is expectedto lock the door when “Def(φGSE)” becomes true.

B. Enabling the Smart Lock Scenario with MIPA

To enable automatic locking of the office, the user launchesthe smart lock application on his smart phone or laptop.The smart lock application encodes the contextual property“Def(φGSE)” in XML and transmits it to MIPA via asyn-chronous message passing.

The predicate parser parses this property and obtains thepredicate structure. The property detection manager finds outhow to relate the constituent local predicates to contextualevents from the context modeling module. For example inthis scenario, the property detection manager obtains from thecontext modeling module that φ1

LP should be associated withcontextual events from the RFID reader. Then the managerfinds out where to launch the contextual event notificationmodule associated with φ1

LP from the context retrieval module.It associates φ1

LP to the RFID reader inside the office.When the contextual event notification module is launched,

the ECA manager parses the configuration files of all sensorsinvolved in this application, and then launches the correspond-ing sensor agents. The ECA manager launches the non-checkerprocesses and starts persistent monitoring of the dynamicenvironment. When the non-checker process finds changes inlocal predicate values, it reports the results to the predicatecheckers. In this scenario, the RFID reader inside the officeperiodically detects whether there are RFID tags within itscoverage. Thus the reader generates periodical contextual

events of the user is or is not in the office. The events thatthe user is not detected are pruned and only the events thatthe user is in the office are passed to the non-checker processassociated with φ1

LP .The property detection manager initiates the CGS checkers.

The CGS checkers wait for local predicate values from thenon-checker processes. The property detection manager initi-ates the GSE checker, which waits for CGS predicate valuesfrom the constituent CGS checkers. In this scenario, the GSEchecker for Def(φGSE) waits for the results from the CGScheckers for φ1

CGS and φ2CGS . The checker of φ1

CGS waits forresults from contextual event notification modules of φ1

LP andφ2

LP . Finally, when the GSE checker detects that contextualproperty Def(φGSE) holds, MIPA notifies the smart lockapplication. Then, the application triggers locking of the door.

V. CASE STUDY

In our case study, we implement MIPA with Java SE 1.6.In our case study, we run MIPA over Sun JVM 1.6.0 16on Gentoo Linux 10.0 (kernel 2.6.31). We use a machinewith an Intel Core Duo T2450 (2.0GHz) and 2GB RAM. Weimplement the smart lock scenario discussed in Section IV. Wefirst study the memory consumption and response latency ofMIPA when it detects one single predicate. Then, we evaluatethe scalability of MIPA. We increase the number of predicates,as well as the number of non-checker processes. We generatethe user’s stay in and out of the office with the exponentialdistribution. The average stay in and out of the office are 10and 5 minutes respectively. The lifetime of the case study isup to 9 hours.

A. Memory Consumption and Latency of Detection

In this experiment, we first study the memory consumptionon both the predicate detection side (PD-side) and the contex-tual event notification side (ECA-side). Then, we evaluate thelatency of each component on the PD-side. We evaluate bothφCGS and φGSE .

As for the memory consumption, since φGSE consists oftwo φCGS , the memory consumption of φGSE is higher thanthat of φCGS , as shown in Table I. The memory consumptionof φGSE is more than that of φCGS by up to 16% on the PD-side. On the ECA-side, the memory consumption of φCGS isapproximately the same with that of φGSE . This is becausethough the checking of φCGS and φGSE is different, theircontextual notification modules are quite similar.

As for the latency, we measure the latency induced by thepredicate parser and the property detection manager on thePD-side, as shown in Table II. The property detection managerof φGSE is more complicated than that of φCGS . It needs tocreate two CGS checkers and look up more context modelingand retrieval information than the manager of φCGS . As shownin Table. II, the latency of property detection manager of φGSE

is more than φCGS by up to 9.04%. Since both predicates arequite simple, the parsing time is quite similar. The total latencyof φGSE is more than that of φCGS by 9.03%.

140

φCGS (Kb) φGSE (Kb)PD 630 750

ECA 1209 1208

TABLE IMEMORY CONSUMPTION

φCGS (ms) φGSE (ms)Predicate parser 0.149 0.158

Property detection manager 106.701 117.299Total 106.852 117.458

TABLE IILATENCY

B. Scalability

An important goal of MIPA is to ensure that the predicatedetection and contextual notification modules can scale to asufficiently large number of interactions. In this study, boththe predicate detection and the contextual event notificationmodules run on a typical desktop machine. To put MIPA understress, multiple predicates checkers and multiple non-checkerprocesses are concurrently running.

1) Scalability on the Predicate Detection Side: In thissection, we study the scalability of MIPA, in terms of mem-ory consumption and latency, on the PD-side. As for thememory consumption, we first investigate the raw memoryconsumption statistics. We increase the number of predicatesto 3000 at a constant speed within 500 seconds. First, wefind that the memory consumption increases linearly, whenthe number of predicates increases linearly, as shown in Fig.6. Then the memory consumption remains relatively stable, asthe maximum number of predicates has been reached.

We also study how the average of memory consumptionincreases as the number of predicates increases, as shown inFig. 7. The memory consumptions of both φCGS and φGSE

increase linearly when the number of predicates increases. Thisis in accordance with the result in Fig. 6. The structure ofφGSE is more complex than that of φCGS . So the memoryconsumption of φGSE is more than that of φCGS by up to35%.

As for the latency performance, we first increase the numberof predicates to 8000 and study the changes in latency. Asshown in Fig. 8, most queries are served within around 600 ms(as the number of predicates increases to 8000, the latency is611.3 ms). The increase in the latency of most queries is linear.We also see that certain number of queries encounter abruptincreases in the latency. This is mainly because when thesequeries are being served, there also come predicate detectionquests and nontrivial computing resources are occupied. Wefind that the unusually long latencies also increase linearly.

We then study the average the latency imposed by φCGS andφGSE , as shown in Fig. 9 and 10 respectively. Since φGSE ismore complex, MIPA supports a much larger number of φCGS

when achieving similar latency performance. Overall, the

Fig. 6. Memory consumption (PD-side)

Fig. 7. Average memory consumption (PD-side)

latency increases almost linearly as the number of predicatesincreases.

2) Scalability on the Contextual Event Notification Side:In this section, we study the scalability of MIPA, in termsof memory consumption and latency, on the ECA-side. Asfor the memory consumption, we first study the raw memoryconsumption statistics. We increase the number of non-checkerprocesses to 500 at a constant speed within 500 seconds. Thememory consumption increases linearly when the number ofnon-checker processes increases, as shown in Fig. 11. Whenthe maximum number of non-checker processes is reached,the memory consumption remains stable. The average memoryconsumption also increases linearly, as shown in Fig. 12. Thisis similar to the increase in memory consumption on the PD-side.

As for the latency performance, we find that when load onthe ECA-side is small, it can serve a request of creating a newnon-checker process immediately. The latency only slightlyincrease as the number of non-checker processes increases,as shown in Fig. 13. Similar to the latency on the PD-side,we also see that certain number of queries encounter abruptincreases in the latency. This is mainly because such queriesencounter the predicate detection which greatly consume com-puting resources. The unusually long latencies also increaselinearly.

We also study how the average latency increases. We findthat the average latency increases more quickly than linearly,

141

Fig. 8. Latency (PD-side)

Fig. 9. Average latency ( PD-side, φCGS )

as shown in Fig. 14. This is mainly because when there aremore updates from the ECA-side, the load on the PD-side alsoincreases.

The readers are referred to [5], [6], for detailed discussionson whether the predicate detection schemes for φCGS andφGSE work correctly, confronting different types and differentlevels of asynchrony in pervasive computing environments.

VI. RELATED WORK

Recently, a variety of context-aware middleware have beendeveloped, such as Gaia [1] and Cabot [3]. Based on suchmiddleware infrastructures, a number of contextual propertydetection schemes have been proposed for pervasive context,such as [3], [4]. However, such schemes implicitly assumethat contexts being checked belong to the same snapshot oftime, thus not working in asynchronous environments. OurMIPA supports contextual property detection in asynchronousenvironments.

Coping with the asynchrony has been a critical issue inpervasive computing. In his pioneering work, Anind Deypointed out that computing devices must share the same notionof time and be synchronized to the greatest extent possible.However, in some cases, just knowing the ordering of eventsor causality is sufficient [2]. In [8], the possible faults whichcan be caused by asynchronous update of context data isinvestigated, but it is not discussed how to cope with theasynchrony. In our previous studies [5], [6], we investigated

Fig. 10. Average latency ( PD-side, φGSE )

Fig. 11. Memory consumption (ECA-side)

the design and evaluation of property detection algorithms forCGS and GSE predicates. These work are implemented asproperty detection services over MIPA.

Development of MIPA is based on one of our ongoingresearch projects 2. A preliminary report based on version 0.3of MIPA is presented in [15]. In this work, we significantlyextend MIPA in the following aspects. In this work, we addthe property detection manager, which supports combiningCGS checkers and obtaining GSE checkers. We also adddetailed design of pluggable sensor agents (In [15], onlyCGS predicates can be implemented). Moreover, we add asmart lock scenario to explain the operation of MIPA, and thescenario is implemented over MIPA using both CGS and GSEpredicates. Based on these implementations, a comprehensivecase study is conducted to evaluate the cost-effectiveness andscalability of MIPA, and the evaluation results are discussedin detail.

VII. CONCLUSION

In this work, we study how to provide middleware supportfor achieving context-awareness in asynchronous pervasivecomputing environments. Toward this objective, our contri-butions are: i) we introduce runtime detection of contextualproperties based on logical time, to cope with the asynchronyin pervasive computing environments; ii) we design and im-plement MIPA to provide middleware support for runtime de-

2http://mipa.googlecode.com

142

Fig. 12. Average memory consumption (ECA-side)

Fig. 13. Latency (ECA-side)

tection of contextual properties in asynchronous environments;iii) a comprehensive case study is conducted to evaluate MIPA.

Currently, the MIPA middleware still suffers from severallimitations. In our future work, we will investigate how todesign a general algorithmic skeleton, to enhance the designand implementation of various predicate detection algorithms.We also need to study how to reduce the message complexityinduced by our property detection schemes. Moreover, we willdeploy MIPA to multiple distributed devices and conduct morerealistic experimental evaluations.

ACKNOWLEDGMENT

This work is supported by the National Natural ScienceFoundation of China (No. 60903024, 60736015, 60721002),the National 973 Program of China (2009CB320702), and theNational 863 Program (2009AA01Z117).

REFERENCES

[1] M. Roman, C. Hess, R. Cerqueira, A. Ranganathan, R. H. Campbell,and K. Nahrstedt, “A middleware infrastructure for active spaces,” IEEEPervasive Computing, vol. 1, no. 4, pp. 74–83, 2002.

[2] A. Dey, “Providing architectural support for building context-awareapplications,” Ph.D. Thesis, Georgia Institute of Technology, Nov. 2000.

[3] C. Xu and S. C. Cheung, “Inconsistency detection and resolution forcontext-aware middleware support,” in Proc. ACM SIGSOFT Interna-tional Symposium on Foundations of Software Engineering (FSE’05),Lisbon, Portugal, Sep. 2005, pp. 336–345.

[4] C. Xu, S. C. Cheung, and W. K. Chan, “Incremental consistencychecking for pervasive context,” in Proc. International Conference onSoftware Engineering (ICSE’06), Shanghai, China, May 2006, pp. 292–301.

Fig. 14. Average latency (ECA-side)

[5] Y. Huang, X. Ma, J. Cao, X. Tao, and J. Lu, “Concurrent eventdetection for asynchronous consistency checking of pervasive context,”in Proc. IEEE International Conference on Pervasive Computing andCommunications (PERCOM’09), Galveston, Texas, USA, Mar. 2009.

[6] Y. Huang, J. Yu, J. Cao, and X. Tao, “Detection of behavioral contextualproperties in asynchronous pervasive computing environments,” in Proc.IEEE International Conference on Parallel and Distributed Systems(ICPADS’10), Shanghai, China, Dec. 2010.

[7] O. Babaoglu and M. Raynal, “Specification and verification of dynamicproperties in distributed computations,” J. Parallel Distrib. Comput.,vol. 28, no. 2, pp. 173–185, 1995.

[8] M. Sama, D. S. Rosenblum, Z. Wang, and S. Elbaum, “Model-basedfault detection in context-aware adaptive applications,” in Proceedingsof the 16th ACM SIGSOFT International Symposium on Foundations ofsoftware engineering (SIGSOFT’08/FSE-16). New York, NY, USA:ACM, 2008, pp. 261–271.

[9] Y. Huang, J. Cao, B. Jin, X. Tao, J. Lu, and Y. Feng, “Flexible cacheconsistency maintenance over wireless ad hoc networks,” IEEE Trans.Parallel Distrib. Syst., vol. 21, no. 8, pp. 1150–1161, 2010.

[10] L. Lamport, “Time, clocks, and the ordering of events in a distributedsystem,” Commun. ACM, vol. 21, no. 7, pp. 558–565, 1978.

[11] F. Mattern, “Virtual time and global states of distributed systems,” inProc. International Workshop on Parallel and Distributed Algorithms,Holland, 1989, pp. 215–226.

[12] C. J. Fidge, “Partial orders for parallel debugging,” in Proc. ACM SIG-PLAN and SIGOPS Workshop on Parallel and Distributed Debugging,Madison, Wisconsin, US, May 1988, pp. 183–194.

[13] MIPA - Middleware Infrastructure for Predicate detection in Asyn-chronous environments, version 1.3.0, http://mipa.googlecode.com/.

[14] O. Babaoglu, E. Fromentin, and M. Raynal, “A unified framework for thespecification and run-time detection of dynamic properties in distributedcomputations,” J. Syst. Softw., vol. 33, no. 3, pp. 287–298, 1996.

[15] Y. Huang, J. Yu, X. Ma, X. Tao, and J. Lu, “Monitoring properties ofopen environments (in chinese),” Journal of Software, accepted, availableat: http://www.jos.org.cn/1000-9825/3800.htm.

[16] V. K. Garg and B. Waldecker, “Detection of strong unstable predicatesin distributed programs,” IEEE Transactions on Parallel and DistributedSystems, vol. 7, pp. 1323–1333, Dec. 1996.

[17] Z. Wu, X. Tao, and J. Lu, “An ontology based dynamic context model,”Frontiers of Computer Science and Technology, vol. 2, no. 4, pp. 356–367, 2008.

143