Checking Behavioral Consistency Constraints for Pervasive Context in Asynchronous Environments

Abstract

Context consistency checking, the checking of specified constraint on properties of contexts, is essential to context-aware applications. In order to delineate and adapt to dynamic changes in the pervasive computing environment, context-aware applications often need to specify and check behavioral consistency constraints over the contexts. This problem is challenging mainly due to the distributed and asynchronous nature of pervasive computing environments. Specifically, the critical issue in checking behavioral constraints is the temporal ordering of contextual activities. The contextual activities usually involve multiple context collecting devices, which are fully-decentralized and interact in an asynchronous manner. However, existing context consistency checking schemes do not work in asynchronous environments, since they implicitly assume the availability of a global clock or relay on synchronized interactions. To this end, we propose the Ordering Global Activity (OGA) algorithm, which detects the ordering of the global activities based on predicate detection in asynchronous environments. The essence of our approach is the message causality and its on-the-fly coding as logic vector clocks in asynchronous environments. We implement the Middleware Infrastructure for Predicate detection in Asynchronous environments (MIPA), over which the OGA algorithm is implemented and evaluated. The evaluation results show the impact of asynchrony on the checking of behavioral consistency constraints, which justifies the primary motivation of our work. They also show that OGA can achieve accurate checking of behavioral consistency constraints in dynamic pervasive computing environments. Comment: 9 pages, 9 figures

Full text

Page 1

arXiv:0911.0136v1 [cs.SE] 1 Nov 2009
Checking Behavioral Consistency Constraints for
Pervasive Context in Asynchronous Environments
Yu Huang1,2, Jianping Yu1,2, Jiannong Cao3, Xiaoxing Ma1,2, Xianping Tao1,2, Jian Lu1,2
1State Key Laboratory for Novel Software Technology
Nanjing University, Nanjing 210093, China
2Department of Computer Science and Technology
Nanjing University, Nanjing 210093, China
{yuhuang, xxm, txp, lj}@nju.edu.cn, yujianping@ics.nju.edu.cn
3Internet and Mobile Computing Lab, Department of Computing
Hong Kong Polytechnic University, Hong Kong, China
csjcao@comp.polyu.edu.hk
Abstract—Context consistency checking, the checking of spec-
ified constraint on properties of contexts, is essential to context-
aware applications. In order to delineate and adapt to dynamic
changes in the pervasive computing environment, context-aware
applications often need to specify and check behavioral consis-
tency constraints over the contexts. This problem is challenging
mainly due to the distributed and asynchronous nature of
pervasive computing environments. Specifically, the critical issue
in checking behavioral constraints is the temporal ordering of
contextual activities. The contextual activities usually involve
multiple context collecting devices, which are fully-decentralized
and interact in an asynchronous manner. However, existing con-
text consistency checking schemes do not work in asynchronous
environments, since they implicitly assume the availability of a
global clock or relay on synchronized interactions.
To this end, we propose the Ordering Global Activity (OGA)
algorithm, which detects the ordering of the global activities
based on predicate detection in asynchronous environments. The
essence of our approach is the message causality and its on-the-fly
coding as logic vector clocks in asynchronous environments. We
implement the Middleware Infrastructure for Predicate detection
in Asynchronous environments (MIPA), over which the OGA
algorithm is implemented and evaluated. The evaluation results
show the impact of asynchrony on the checking of behavioral
consistency constraints, which justifies the primary motivation
of our work. They also show that OGA can achieve accurate
checking of behavioral consistency constraints in dynamic per-
vasive computing environments.
I. INTRODUCTION
Pervasive applications are typically context-aware, using
various kinds of contexts, such as location and time, to provide
smart services [1], [2], [3], [4]. Context-aware applications
need to monitor whether contexts bear specified property, thus
being able to adapt to the pervasive computing environment
accordingly [5], [6], [7], [8]. This brings the essential issue
of context consistency checking, i.e. checking of specified
constraints on properties of contexts [9], [10].
Context consistency checking has been widely studied in
pervasive computing and software engineering communities
[11], [9], [12], [13], [14], [15], [10]. For example in [9],
consistency constraints are expressed in first order logic,
and contextual properties like “location of the user is the
meetingroom and a presentation is going on” can be spec-
ified. However, existing schemes mainly focus on checking
of static consistency constraints, i.e. constraints delineating
properties of contexts at given snapshot of time. Though static
consistency constraints can capture interesting properties of
the pervasive computing environment, they inherently lack the
notions of relative temporal order [16], [17]. Such constraints
cannot characterize behavioral patterns of contexts, such as
“C1: the user in in his office (detected by the RFID reader
and the light sensor in the office); then the user leaves the
office (detected by the RFID reader and the light sensor in the
corridor)”.
The discussions above necessitate the checking of be-
havioral consistency constraints, i.e. constraints delineating
behavior patters of contexts. The key issue in checking be-
havioral consistency constraints is how to decide the temporal
order among contextual activities. This issue is challenging in
pervasive computing environments, mainly due to the follow-
ing two observations:
• Contextual activities are often global, involving multiple
decentralized context collection devices. For example,
in constraint C1 discussed above, the location context
is decided by two different sensors (RFID reader and
light sensor), in order to improve the accuracy of con-
text. Pervasive applications and context collecting devices
usually coordinate in a fully-distributed manner, based on
wired/wireless communications.
• The pervasive computing environment is often asyn-
chronous [18], [10], [17]. Specifically, context collecting
devices do not necessarily have a global clock. They
heavily rely on wireless communications, which suffer
from uncertain delay. Moreover, due to resource con-
straints, context collection devices, e.g. battery-powered
sensors, often need to buffer context data for certain time.
Periodic or adaptive schemes are employed to schedule
the dissemination of context data [18]. The different
context update rates also result in the asynchrony of per-
vasive computing environments, which cannot be easily

Page 2

synchronized by message exchanging. However, existing
consistency checking schemes implicitly assume that the
contexts being checked belong to the same snapshot of
time [11], [9], [12], [13], [14]. This assumption does not
hold in asynchronous pervasive computing environments.
To address the challenges discussed above, we study in this
paper the checking of behavioral consistency constraints in
asynchronous pervasive computing environments. Specifically,
• We define behavioral consistency constraints based on
the ordering of global activities. We first define global
activities based on the concurrency among local contex-
tual activities on decentralized context collection devices.
Then, both the concurrency among local activities and the
relative order among global activities are defined based on
the happen-beforerelationship resulting from the message
causality in asynchronous environments [19].
• We propose the Ordering Global Activities (OGA) algo-
rithm to detect the ordering of global contextual activi-
ties and check behavioral consistency constraints. OGA
assumes the availability of an underlying middleware
infrastructure for asynchronous consistency checking of
pervasive context. We have developed such a middleware
named Middleware Infrastructure for Predicate detection
in Asynchronous environments (MIPA) [20], on which
OGA can be implemented, deployed and evaluated.
• We evaluate OGA in a smart-lock scenario, which is fist
investigated in our previous work [21]. The evaluation
results show how the asynchrony in the pervasive com-
puting environment affects the checking of behavioral
consistency constraints. The results also show the accu-
racy of OGA in context consistency checking in pervasive
computing environments.
The rest of this paper is organized as follows. In Section
II, we describe our system model. In Section III, we present
design of the OGA algorithm. In Section IV and V, we
overview the design of MIPA and present the experimental
evaluation. Section VI overviews the existing work. In Section
VII, we conclude the paper with a brief summary and the
future work.
II. SYSTEM MODEL
In this section, we fist discuss how we model asynchronous
pervasive computing environments. Then we discuss how
to specify behavioral consistency constraints, which includes
specification of global activities and specification of the rela-
tive order among global activities. Notations used in the system
model are listed in Table I.
A. Asynchronous Pervasive Computing Environments
We model context-aware applications in asynchronous per-
vasive computing environments as a loosely coupled message-
passing system, without any global clock or shared memory.
Communications suffer from uncertain delay. Dissemination
of context data may be postponed due to resource constraints.
We assume that no messages are lost, altered, or spuriously
TABLE I
NOTATIONS IN THE SYSTEM MODEL
NotationExplanation
number of all non-checker processes
number of global activities
the kthglobal activity (1 ≤ k ≤ m), which might
be either GAAND
k
or GAOR
number of non-checker processes involved in GAk,
?m
the ithnon-checker process, 1 ≤ i ≤ n
the jthnon-checker process in GAk, 1 ≤ j ≤
size(GAk) (P(k,j)and Pi are different notations
of the same non-checker process)
vector clock timestamp on Pi
the ithlocal activity
the jthlocal activity involved in GAk on P(k,j)
(LAiand LA(k,j)are different notations of the same
local activity)
interval of a global / local activity
n
m
GAk
k
size(GAk)
k=1size(GAi) = n
Pi
P(k,j)
V Ci
LAi
LA(k,j)
I(GA),I(LA)
introduced. We do not assume that the underlying communi-
cation channel is fist-in-first-out (FIFO). Justifications for the
assumptions are discussed in Section III.D.
A context-aware application consists of a collection of
processes, among which n non-checker processes (denoted by
P1,P2,···,Pn) are involved in the checking of behavioral
consistency constraints. One checker process (denoted by
Pche) is dedicated for the checking of context consistency.
The consistency checking is based on the classical Lamport’s
definition of the happen-before (denoted by ‘→’) relationship
resulting from message causality [19] and its “on the fly”
coding given by Mattern and Fidge’s vector clocks [22], [23].
Each non-checker process Pjkeeps V Cj, its own vector clock
timestamps. V Cj[i](i ?= j) is ID of the last message from Pi,
which has a causal relationship to Pj. V Cj[j] for Pj is the
next message ID Pj will use. Messages passed in the system
can be classified into two types:
• Control message. Non-checker processes send control
messages among each other to establish the happen-
before relationship among contextual activities.
• Checking message. Non-checker processes send vector
clock timestamps of contextual activities via checking
messages to the checker process. The checker process
decides whether the consistency constraint is satisfied
based on the collected timestamps.
B. Global Activities
Contextual activities can be either local or global. A local
activity takes place on some Pi without any interaction with
other processes. We delineate local activities of our concern
on non-checker process Pi with local predicate LAi. LAi is
true if the local activity is taking place on Pi. Otherwise, it
is false. We record the interval in which LAi = true. The
false-to-true and the true-to-false transitions (denoted by ↑
and ↓ respectively) of LAi correspond to the beginning and
ending of the interval, which are denoted by Ii.lo and Ii.hi
respectively.
A global activity results from the interaction among local
activities. The interaction projected on the time axis is the

Page 3

Fig. 1.Concurrent local activities
concurrency among local activities, i.e., the overlapping of
intervals of local activities. To detect whether I1,I2,···,In
overlap, we need to check whether the following Formula (1)
is satisfied:
(Ij.lo → Ik.hi) ∧ (Ik.lo → Ij.hi),∀1 ≤ j ?= k ≤ n
(1)
The case of three concurrent local activities is shown in Fig.
1. Detection of concurrent activities has been studied in [24],
as well as in our previous work [10].
We can further classify global activities based on how we
care about the time scope of the interaction, i.e., how we define
the interval of the global activity. Specifically, we can define
two types of global activities, which are discussed in detail
below.
GAk
:=
GAAND
k
LA(k,1)∧ ··· ∧ LA(k,size(GAAND
LA(k,1)∨ ··· ∨ LA(k,size(GAOR
| GAOR
k
GAAND
k
GAOR
:=
k
))
k
:=
k
))
1) And-activity: An and-activity takes place in the period
in which multiple local activities are interacting with each
other. For example, “Alice and Bob are in the meeting room”
is an and-activity. It takes place in the period when Alice
and Bob are both in the meeting room. The interval of an
and-activity is defined as the intersection among the intervals
of overlapping local activities. For and-activity GAAND
LA(k,1)∧ LA(k,2)∧ ··· ∧ LA(k,size(GAk)), its interval is:
k
=
I(GAAND
k
) =
?
1≤i≤size(GAk)
I(LAi)
For example in Fig. 2, GA = LA1∧ LA2. Based on the
happen-before relationship established, we have that:
I(GA) = I1∩ I2= [I2.lo, I1.hi]
2) Or-activity: An or-activity takes place in the whole
period of interaction, i.e., from the happening of the first local
activity to the ending of the last local activity. For example,
imagine that Alice first waits for Bob in the meeting room.
When Bob comes, they have discussions. Then Alice leaves
the meeting room. In this case, the or-activity “Alice or Bob
is in the meeting room” takes place in the period starting from
the time Alice enters the meeting room and ending at the time
Fig. 2.Intervals for and- and or-activities
Bob leaves. The interval of an or-activity is defined as union
of the intervals of overlapping local activities. For or-activity
GAOR
k
= LA(k,1)∨LA(k,2)∨···∨LA(k,size(GAk)), its interval
is defined as:
I(GAOR
k
) =
?
1≤i≤size(GAk)
I(LAi)
For example in Fig. 2, if we define GA′= LA1∨ LA2, we
have that:
I(GA′) = I1∪ I2= [I1.lo, I2.hi]
C. Ordering Global Activities
Due to the distributed nature of contexts, we often rely on
global activities to delineate the static properties of contexts.
To delineate the behavioral patterns of contexts, applica-
tions are interested in (global) activities which take place
in specified temporal order, such as “GA1 happens, then
GA2happens, ..., finally GAmhappens”. For example, in the
behavioral consistency constraint C1 discussed in Section I,
the application is interested in the relative order between two
global activities “the user is in the office” and “the user is in
the corridor (leaves the office)”. A sequence of ordered global
activities is defined as:
SGA
:=
GA1≺ GA2≺ ··· ≺ GAm
Here, GAk proceeds GAk+1is defined as the happen-before
relationship between the corresponding intervals:
GAk≺ GAk+1:= I(GAk).hi → I(GAk+1).lo
(2)
In the next section, we discuss how to check the ordering
of global activities in asynchronous pervasive computing en-
vironments.
III. ORDERING GLOBAL ACTIVITIES IN ASYNCHRONOUS
PERVASIVE COMPUTING ENVIRONMENTS
In this section, we present design of the proposed Ordering
Global Activities (OGA) algorithm. The OGA algorithm con-
sists of three parts: 1) the non-checker process specifies the
message activities upon changes in the local predicate value; 2)
the checker process first detects global activities; 3) then the
checker process builds the ordering among global activities.
Notations used in the design of OGA are listed in Table I and
II.

Page 4

TABLE II
NOTATIONS IN DESIGN OF OGA
Notation
CurIntv
Explanation
interval of local activity on the non-
checker process
boolean value
whether there have been new mes-
sage activities
vector clock timestamp on P(k,t)
queue for P(k,t)in GAk on the
checker process
queues for recording results of de-
tecting GAk
current global activity to be ordered
previous global activity which has
been ordered
flagMsgAct
usedtodenote
V C(k,t)
Que(k,t)
QueLok,QueHik
CurQueLo,CurQueHi
PreQueLo,PreQueHi
A. Message Activities on Non-checker Process P(k,t)in GAk
On the non-checker process P(k,t), different message activ-
ities are specified upon the beginning and ending of the local
activity:
• Upon LA(k,t)↑, a control messages is sent to every
P(k,s)(1 ≤ s ≤ size(GAk),s ?= t), i.e., all other non-
checker processes in the same global activity with P(k,t).
The message activity here aims at building the happen-
before relationship required in Equation (1), in order to
detect GAk.
• Upon LA(k,t)↓, a control message is sent among every
other non-checker processes Pi(Pi?= P(k,t)). The mes-
sage activity here aims at the ordering among different
global activities, as required in Equation (2). Mean-
while, a checking message is sent to Pche. This check-
ing message sends vector clock timestamps ([lo,hi]) of
I(LA(k,t)) to Pche for the detection and ordering of
global activities, as discussed in Section III.B and III.C
respectively.
Boolean variable flagMsgAct is used to reduce redun-
dant message passing, as in [24], [10]. The initial value of
flagMsgAct is true. Pseudo codes of OGA on the non-
checker process side are listed in Algorithm 1.
B. Detecting Global Activities
1) Checking the concurrency: Checking messages from all
the non-checker processes are grouped according to the global
activity they belong to. For given global activity GAk, we
check the concurrency among local activities based on For-
mula (1). The checker process has a separate queue Que(k,t)
for each P(k,t)in GAk. Incoming checking messages are
enqueued in the appropriate queue.
We assume that Pche receives messages from each non-
checker process in FIFO order as in [25], [24]. Note that
this is not a restrictive assumption. We do not require FIFO
for the underlying communication. Pcheneeds to implement
the FIFO property for efficiency purposes. If the underlying
communication is not FIFO, Pche ensures this property by
using sequence numbers in messages.
Each element of Que(k,t)is timestamp [lo,hi] of an interval.
The los and his are compared to check the concurrency
Algorithm 1 OGA on P(k,t)in GAk
1: Upon LA(k,t)↑
2: sendcontrol(V C(k,t)) to each P(k,s)in GAk, s ?= t;
3: if flagMsgAct then
4:
CurIntv.lo := V C(k,t);
5: end if
6: Upon LA(k,t)↓
7: sendcontrol(V C(k,t)) to each Pi(1 ≤ i ≤ n,Pi?= P(k,t));
8: if flagMsgAct then
9:
CurIntv.hi := V C(k,t);
10:
sendchecking(CurIntv[lo,hi]) to Pche;
11:
flagMsgAct := false;
12: end if
13: Upon receive control msg(V Ci) from Pi
14: for j = 1 to n do
15:
V C(k,t)[j] = max{V C(k,t)[j],V Ci[j]};
16: end for
17: flagMsgAct := true;
among intervals. The checker process reduces the number of
comparisons by deleting any interval at the head of any queue
whose hi is not greater than lo of the interval at the head of
all other queues. Pchedetects GAkif it finds a set of intervals
at the head of queues such that they are pairwise overlapping.
The detection of concurrency is mainly based on the strong
conjunctive predicate algorithm in [24] and our previous work
[10].
2) Calculating the interval of GAk: After the detection of
GAk, we need to calculate I(GAk), the interval of this global
activity, for further ordering of global activities. For and-
activities, we need to calculate the intersection of intervals,
while for or-activities, we need to calculate the union of
intervals, as shown in Fig. 2.
In the ideal case, for an and-activity, we calculate the
latest lo (every other lo happens before it) and the earliest
hi (happening before every other hi). However, we may not
alway be able to obtain the latest/earliest lo/hi in asynchronous
environments. For example in Fig. 3, we cannot decide which
one is later for I2.lo and I3.lo. Neither can we decide which
one is earlier for I1.hi and I3.hi. Thus, for all the los, we
prune those which happens before any other lo (must not
be the latest), and keep all the remaining (concurrent) los.
Similarly, for all the his, we prune those which “happens
after” any other hi (must not be the earliest), and keep all
the remaining (concurrent) his. For example in Fig. 3, we
need to keep I2.lo and I3.lo, as well as I1.hi and I3.hi.
The or-activity is the dual of and-activity. Similar duality
remains in calculating the interval of and- and or-activities.
For an or-activity, we need the earliest lo and the latest hi.
Pseudo codes for the detection of global activities are listed
in Algorithm 2.

Page 5

Fig. 3.Calculating the interval of a global activity
C. Ordering Global Activities
The essential issue in ordering two global activities is
to establish the relative order between I(GAk).hi and
I(GAk+1).lo. As discussed in the previous section, we may
encounter multiple (concurrent) los and his when detecting
global activities. We have stored all these los and his in ap-
propriate queues as shown in Algorithm 2. Now, we compare
all the stored los and his. This comparison continues until
I(GAk).hi → I(GAk+1).lo is established for every stored hi
and lo. When we reach the last global activity, we finish the
ordering of global activities. Pseudo codes for the ordering of
global activities are listed in Algorithm 3.
D. Discussions
The number of comparisons for detecting a global activity
is O(s2p), where s is the upper bound of size of the global
activity, p is the upper bound of length for each queue in
detecting the global activity. The number of comparisons for
ordering global activities is O(s2m). On the normal process
side, the number of message activities is O(p). Note that
existing work may impose less message complexity, but they
rely on the assumption of a global clock or synchronized
interactions. The message complexity of OGA is mainly due
to building the happen-before relationship between los and
his, which is a requisite for detecting temporal properties in
asynchronous environments.
We assumed reliability of message passing. Note that even
with this assumption, we cannot guarantee correct ordering of
global activities. Without this assumption, we only need to re-
vise our algorithm to tolerate incomplete message information.
Rationale of our algorithm remains the same. The probability
of detecting global activities is analyzed in our previous work
[10]. In Section V, we further evaluate OGA by experiments.
IV. IMPLEMENTATION
The OGA algorithm we propose assumes the availability
of an underlying middleware infrastructure for asynchronous
consistency checking of pervasive context. We have developed
such a middleware named Middleware Infrastructure for Pred-
icate detection in Asynchronous environments (MIPA) [20].
From MIPA’s point of view, a pervasive computing environ-
ment is composed of an application layer, a middleware layer
and a context source layer, as shown in Fig. 4.
Algorithm 2 Detecting GAkin OGA
1: Upon receiving CurIntv[lo,hi] from P(k,t)
2: insert CurIntv[lo,hi] to Que(k,t);
3: if CurIntv[lo,hi] ?= Que(k,t).head() then
4:
return;
5: end if
/* if CurIntv is the head element in Que(k,t), continue
the checking */
6: changed := {P(k,t)};
7: while changed ?= φ do
8:
newchanged := φ;
9:
for each P(k,i)in changed and P(k,j)in GAkdo
10:
if Que(k,j).head().lo ?→ Que(k,i).head().hi then
11:
newchanged := newchanged ∪ {P(k,i)};
12:
end if
13:
if Que(k,i).head().lo ?→ Que(k,j).head().hi then
14:
newchanged := newchanged ∪ {P(k,j)};
15:
end if
16:
end for
17:
changed := newchanged;
18:
for each P(k,i)in changed do
19:
delete head(Que(k,i));
20:
end for
21: end while
/* if GAkis detected */
22: if ∀i, Que(k,i)is not empty then
23:
calculate I(GAk);
24:
enqueue each lo and hi remained after the pruning to
QueLo(GAk) and QueHi(GAk) respectively;
25: end if
The middleware layer is the kernel part of MIPA. Its
fundamental functionalities include:
• Predicate broker. The predicate broker accepts consis-
tency constraints specified by the context-aware appli-
cation. It first parses the consistency constraint, and
then initiates the non-checker processes and the checker
process accordingly.
• Non-checker process. The non-checker process monitors
the local predicate value based on the Event-Condition-
Action (ECA) mechanism [26]. It accepts source contex-
tual events from the corresponding sensor agents. The
local predicate serves as the event condition. When value
of the local predicate changes, the consistency checking
algorithm on the checker process side is triggered. The
non-checker process sends messages to build the requisite
happen-before relationship. It also sends checking mes-
sage to the checker process, which finally decides whether
the consistency constraint is satisfied.
• Checker process. The checker process collects vector
clock timestamps of local contextual activities. It executes
the predicate detection algorithm to decide whether the
application-specified consistency constraint is satisfied.
The checking result is sent back to the application via