=Paper= {{Paper |id=None |storemode=property |title=Towards an Ambient Data Mediation System |pdfUrl=https://ceur-ws.org/Vol-908/paper3.pdf |volume=Vol-908 |dblpUrl=https://dblp.org/rec/conf/immoa/HuynhFB12 }} ==Towards an Ambient Data Mediation System== https://ceur-ws.org/Vol-908/paper3.pdf

Towards an ambient data mediation system

Kim Tâm Huynh Béatrice Finance Mokrane Bouzeghoub
PRiSM Laboratory PRiSM Laboratory PRiSM Laboratory
University of Versailles University of Versailles University of Versailles
Saint-Quentin-en-Yvelines Saint-Quentin-en-Yvelines Saint-Quentin-en-Yvelines
Versailles, France Versailles, France Versailles, France
kth@prism.uvsq.fr beatrice@prism.uvsq.fr mok@prism.uvsq.fr

that AmI can provide sophisticated support for everyday
living, but the information capabilities it may use for this

ABSTRACT purpose can also potentially provide an invisible and com-
prehensive surveillance networks walls literally can have
In this paper, we address the problem of integrating many
ears . It inevitably opens up issues of privacy risk, accep-
heterogeneous and autonomous tiny data sources, available
tance and security.
in an ambient environment (AmI). Our goal is to facili-
In many ambient environments, data arrives as streams
tate the development of context-aware and personalized em-
or as alerts/notications and is only relevant for a period of
bedded applications on mobile devices. The originality of
time; its interpretation depends on the user's context and
the approach is the new ambient mediation architecture
preferences. For instance, an information about a free park-
which provides declarative and dynamic services, based on
ing place can be relevant for a user if this information is
rules/triggers. These services provide facilities to develop
recent and if the parking place is nearby the user's location.
and deploy ambient applications over devices such as smart-
Another example is the heat setting to the right tempera-
phones. This paper reports also on our rst experimental
ture in the room where a given person is in and accordingly
prototype, combining Arduino+Android.
to his/her own comfort preferences.

1. INTRODUCTION In the database community, a lot of work has been devoted
to eciently monitor huge amount of data streams coming
Over the last 20 years there have been some signicant
from sensors that continuously push their data to a xed
progresses on the miniaturization of hardware components
centralized system, without being concerned in privacy, mo-
and wireless networks. The number and capabilities of mo-
bility, context-awareness and reactivity. But as soon as a
bile devices, wireless sensors and sensor networks open new
sensor is linked to my personal life (e.g, my home location,
research elds and applications. Terms such as the Web of
my traveling itinerary, etc), the applications using the cap-
sensors , the Internet of Things and Ambient Intelligence
tured data may become intrusive in my private life. More-
(AmI) emphasize the trend towards a tighter connection
over, in the opposite, as soon as I leave the smart environ-
between the cyberspace and the physical world.
ment, I may lose the ambient capabilities that may support
Today, we are witnessing an unprecedent explosion of mo-
my everyday life (e.g. tension and heart beat measurement,
bile data volumes (i.e. ambient data). According to a study
mandatory presence in a certain place). Consequently, the
from ABI Research [1], in 2014 the volume of mobile data
ambient environment and applications are considered as un-
sent and received every month by users around the world
desirable constraints in some cases and helpful tools in oth-
will exceed by a signicant amount the total data trac for
ers. Since my ambient environment is changing over the time
all of 2008. In 2011, 1.08 billion of mobile phone users have a
and over the space (e.g. at home, at work, at the hospital),
Smartphone and in the near future they will be surrounded
the query processing should adapt itself to these two dimen-
by many sensors/actuators.
sions. As Feng said [10] AmI imposes strong user-centric
In his survey, Sadri [18] denes AmI as the vision of a
context-awareness requirement on data management, but
future in which the environments support the people inhab-
also strong system requirements in terms of hardware con-
iting them. For example, instead of using mice, screens and
straints (i.e. energy consumption, wireless communication).
keyboards, we may communicate directly with our clothes,
As seen before, smartphones and the underlying applica-
household devices,... The identied key features of AmI
tions are, under some restrictions, good support for everyday
are: embedment, intelligence, context-awareness, personal-
life. However, their repetitive development from scratch is
ization, adaptation and anticipation. It is also mentioned
time and money consuming, it makes the software evolution
quite dicult, in particular because components updates are
frequent. We claim that an embedded data management
system for AmI may signicantly contribute to ease the de-
velopment and maintenance of such applications.
The contribution of this paper is to propose an ambient
mediation system (called CAIMAN for C ontext-aware dAta
I ntegration and M anagement in Ambient eN vironments)
which :

13
• facilitates personalized and contextual integration and • The mediator can dynamically connect to the sources
monitoring of heterogeneous data streams through con- when and as long as they are active (i.e. visible over
tinuous query execution; the wireless network and ready to provide data).

• enables applications to dynamically sense and control, • The mediator should provide, for each application, the
according to some preferences, the ambient environ- capability to dene its data requirements in terms of
ment of the user, which is changing over time and event types, so oering a concept of a virtual schema
space; similarly to conventional mediators, and a mechanism

• enables the user to keep some control over his personal which handles continuous queries.

data as the monitoring is done exclusively on his per-
• The mediator should be able to aggregate data ows
sonal device.
originated from the same source and integrate data
In the remaining of this paper, Section 2 denes the re- ows originated from dierent sources on the basis
quirements and the constraints imposed on the design of an of specic rules provided by the applications. As in
ambient mediation system, and presents the architecture of conventional mediators, data heterogeneity should be
CÄIMAN. In Section 3, the ambient mediation approach is transparent to the user, adaptors are aware of data
described and illustrated through a scenario. In Section 4, transformation.
we detail the main components of our system and report on
our experimental prototype combining Arduino+Android. • The mediator should adapt itself to the user's con-
Section 5 concludes with some open issues. text by continuously searching for the appropriate data
sources. It should also satisfy user's preferences in
2. MOTIVATIONS terms of data delivery, relevance to domain of inter-
To develop ambient applications, there is a need of an est, privacy, etc.
ambient data mediation system (ADMS) which allows in-
teroperability between a set of dynamic and loosely-coupled
• The mediator should be aware of energy consump-
tion and manage consequently the connections to the
ambient data sources. An ambient data source is a (xed or
sources and the usage of its resources.
mobile) communicating object which generates or consumes
continuous (or discontinuous) ows of data. Among such
These requirements clearly distinguish an ambient mediator
objects, we can distinguish a wide spectrum of sensors and
from a conventional one [21] where the mediation schema
mobile phones as well as any other data services which can
and the sources are known in advance. Here the environment
push specic data to the applications. In addition to these
is dynamic as data sources enter and leave continuously the
data sources, there exist other ambient objects called actu-
eld of detection. The personalized and contextual integra-
ators, that do not exchange data, but simply perform some
tion and monitoring of heterogeneous data streams rely on
actions on other objects. Notice that a single physical object
continuous query evaluation.
can play both the role of a data source and actuator. All
ambient physical objects are abstracted by software services 2.2 Related work
which encapsulate them and make visible their capabilities, In this section, we list the CAÏMAN main objectives and
especially their data exchange protocol. compare them with existing related works.
The design choices of our system have been motivated by The rst goal of CAÏMAN is to provide a high-level declar-
the requirements of AmI applications in general, and mo- ative approach which permits user applications to interop-
bile/ubiquitous users/equipments in particular; the key is- erate over distributed ambient objects. The expected data
sue being the continuity of ambient services whatever the streams are relatively small in their length/size. Many for-
dynamic changes are. In this section we review them and malisms for event streams processing and querying have
compare our design choices with existing related work. The been proposed, see [9] for a good survey. In Data Stream
proposed CAIMAN architecture is built on the basis of these Management Systems (DSMS) [4], many CQL-like query
choices. languages which extend SQL have been dened. They are

2.1 The requirements based on the concept of window used to manage and lter
data streams in a declarative way [5, 14, 8, 13]. In Com-
An ambient information system (AmIS) is a set of data
plex Event Processing (CEP), some formalisms based on
ows provided by a collection of ambient objects to achieve
composition operators (i.e. sequence, conjunction, disjunc-
the needs of AmI applications (e.g. intelligent home, intel-
tion,etc), or time-based automata are used. The goal of
ligent city, health care, mobile social network, etc). Some
CEP is to detect event patterns (i.e. situation) with tempo-
AmIS objects can play the role of a mediator which is able to
ral constraints in data streams. Today, the two approaches
integrate and interpret data of many ambient data sources,
are seen as complementary [9, 16]. Both approaches focus
as well as to perform actions over their environment. Most
on events detections but none on the events reactivity which
of the AmIS data may persist only a few seconds or minutes
is an important feature of AmI applications, e.g. the abil-
in the system, unless the application or the user decides oth-
ity to identify the context during which active behavior is
erwise for various reasons. The main specic requirements
relevant and the situations in which it is required. Both ap-
imposed to the design of an ADMS are the following :
proaches assume that the data (i.e. events) are continuously
• Data sources are heterogenous. They may be xed pushed to a centralized system known in advance. These as-
or mobile and arbitrarily connect and disconnect from sumptions do not t with our constraints, as the push mode
the mediator, during variable intervals of time. Data consume a lot of energy.
sources have dierent capacities in terms of storage In Sensor Databases such as TinyDB [15], data is acquired
and computation. in a pull mode to avoid battery consumption. The query

14
(i.e. Tiny SQL) is sent through the network and evaluated
in a distributed mode. Sensors are active only when they
are queried. The advantages of this approach is its adapt-
ability to the features of hardware devices and to their con-
straints. The sensor network can contain a large number
of sensors. However, the sensors are homogeneous, they all
have a TinyOS and there is no mechanism of source discov-
ery because the sensors are all known in advance.
The second goal of CAÏMAN is to make the ADMS aware
of the user's context and user's preferences. Again, a lot
of work has been devoted to context and preference-aware
queries by the database community. Traditionally, the inte-
gration of context and preferences in queries is made in two
ways [10]. The query pre-processing consists in enriching the
query with context or preference informations before execut-
ing it. The query post-processing ranks the query's answers
according to these informations. Unfortunately, this mecha-
Figure 1: CAÏMAN
nism works only for one-time queries and not for continuous
queries in which the notions of pre and post-processing do sors can only send data during a period of time xed by

not exist. Indeed, in traditional DBMS, data are permanent the mediator, enabling the sensors and actuators to fall au-

and queries are transient. In DSMS, data are transient and tomatically asleep when they have nished their duty and

queries permanent as they are continuously evaluated over thus turn back to their default state.

the transient data. To our knowledge, no solution has been As the mediator should t into lite clients such as smar-

proposed to handle the context and the user preferences on phones and function in a complete autonomy, no system

continuous queries. functionality is delegated to a central server. We don't rely

In existing context-aware frameworks [6], the context man- on a global data source registry that might not be avail-

ager is generally represented by a centralized server which able at all time. Meta-data exchange between AmIS objects

is in charge of collecting context information, interpreting should be done instead at runtime and the context and pro-

and providing them to the client applications. However in le managers should be local.

pervasive environments, there are frequent disconnections CAÏMAN provides a declarative language which allows to

and low connectivity, making this architecture not robust describe most of the system and application semantics which

enough and adequate for this type of application. In the is based on the ECA (Event-Condition-Action) paradigm

literature, only few systems [7, 11] have proposed a local used in active databases [17]. Thus, the rule processor is a

context server to overcome this problem. However, in [11], core component of our system. It will be detailed in the next

the context sources are known in advance and correspond section. Notice that in this paper our goal is not to propose

to built-in sensors. Conversely in [7], the authors have de- yet another query language nor a complex context-aware

veloped a sentient object model for ad-hoc mobile environ- model, but rather to select a subset of existing formalisms,

ments where the context is only used to adapt the applica- keep them simple and tractable as much as possible to t

tion behavior. It doesn't allow to enhance application data into lite clients.

with contextual information. For instance, many applica-
3. THE AMBIENT MEDIATION APPROACH
tions need to add the location to the data produced.
In this section, we detail our mediation approach. First,
we describe the dierent types of ambient sources on which
2.3 The CAÏMAN architecture the CAÏMAN is built on, then the virtual mediation schema
The overview of the CAÏMAN architecture is depicted in is presented. To understand the approach, we illustrate it
the Figure 1. The resource discovery component facilitates with a scenario. In this scenario, Paul is a student and
objects discovery and handles dynamic connections and dis- lives at the university residence. He wants to benet of an
connections to these objects. AmIS objects should be able intelligent home behavior, by automatically controlling the
to rely on their own battery, so short-range wireless com- air conditioning of the room where he is located according
munication such as Bluetooth are assumed in CAÏMAN as to his preferences. He also needs to organize his evenings
these personal area networks are known to have a low con- and wants to be notied about interesting cultural events
sumption of energy. Once, a data source is discovered the located not far from his current location. In order to do so,
data collectors are responsible for acquiring the data. Data Paul will have to deploy two AmI applications which have
sources do not push their data continuously, but rather spo- been specied in a declarative manner by some designers.
radically in response to the mediator request. This requests During the deployment, the declarative description will be
is done only if the data source can serve the needs of the ap- used to instantiate the virtual schema of the mediator, i.e.
plications which have been deployed on top of the mediator. the application meta-data as described in the Figure 1.
The originality of our ADMS is to oer an hybrid approach
combining both the push and the pull modes. 3.1 The Ambient Sources
In our environment, we assume that sensors/actuators re- Three types of data sources [12] are considered: (1) physi-
main passive most of the time with a default behavior un- cal sources (e.g. GPS built-in sensors, smartphone, external
less someone requests a service (i.e. light o, that can be temperature sensor such Arduino), (2) virtual sources (e.g.
turned on). All sensors/actuators implement some generic user, agenda alerts, SMS, emails, contacts) and (3) logi-
functions (e.g. services) and some that are optional. Sen- cal sources which combine physical and virtual sources with

15
information from databases. These sources can be either
xed (e.g. already embedded in a mobile device where the
mediator is), or dynamic (i.e., another smartphone, a sen-
sor/actuator). Fixed ambient sources are known in advance
and always connected to the mediator, e.g.built-in sensors.
Dynamic ambient sources correspond to sources that ap-
pear and disappear to the mediation system over time due
to the source mobility itself or due to the mobility of the
user which embeds a mediator on his personal smartphone.
If a smartphone is close to a mobile device, a communication
can be established and some messages can be exchanged as
long as the device is reachable. If suddenly it disappears due
to the user mobility, some messages can be lost. Moreover,
the user himself can be an ambient data producer as he/she Figure 3: Active Rules & their Execution Semantics
behaves like any other sensor (intelligent sensor). For in-
2. chronicle: the oldest instances are considered and
stance, the user is discovering a broken window and wants
then discarded; i.e. events are consumed in a chrono-
the mediation system to inform automatically the technical
logical order. It is preferred when there is a causal
sta in charge of repair.
dependency between events.
In the remaining of the paper, we focus more on the dy-
namic data sources. Each one exports its capabilities (e.g., The granularity of processing denes whether the rule pro-
metadata) in an XML document as depicted in the Figure cessor reacts after the detection of each event (instance-
2. Each dynamic source corresponds to a physical device oriented processing) or after a detection of a set of events
characterized by an 'id', a 'type' (e.g., Arduino, Android) (set-oriented processing). An example of instance-oriented
and a version number. processing is to call emergency after detecting a critical situ-
ation like the unconsciousness of a person. In order to avoid
a false alarm, we can wait for multiple events before call-
ing the emergency. In CAÏMAN, this latter dimension can
be oered by dening windows on the events arrival. The
rule priorities determines how rules are selected among a
conict set of rules (i.e. rules triggered by the same event).
The EC and CA coupling modes indicates when condition
(resp. action) is evaluated after event detection (resp. con-
dition evaluation). The dierent options are: immediate,
Figure 2: Sources Description deferred, or detached. CAÏMAN proposes immediate cou-
pling modes. In our system, we do not consider cascading

3.2 A declarative approach execution because we assume that our actions have no side
eect.
The declarative approach used in CAÏMAN is ECA. ECA
In our experimental prototype, only one semantics is im-
rules are a generalization of several methods to achieve ac-
plemented for the rule processor. Rules are evaluated in par-
tive behavior, such as triggers and production rules. ECA
allel and no cascading executions is allowed, but the event
rules are evaluated in three steps: (1) when an occurrence
consumption and the granularity of processing can be pa-
of an event is detected, (2) the system evaluates the condi-
rameterized.
tion under which the event is considered relevant, and (3)
if it is veried, the rule action is executed. The separation 3.3 The Ambient Mediation Schema
between E-C-A is important for many reasons and has been The CAÏMAN mediation schema is composed of: (1) a
emphasized by the active database community [17]. set of events types, corresponding to the data ows required
When designing a mediator based on the ECA paradigm by ambient applications, and events detectors, (2) a context
it is important to carefully take into account the life cycle of model and a default user prole, and (3) a set of personalized
a rule and the dimensions related to its semantic execution. and contextual continuous queries (dened as ECA rules).
Indeed this knowledge is mandatory for those designing an
application. Moreover by separating the dimensions, there
3.3.1 Events & Event Detectors
is more exibility, dierent behaviors can be proposed for An event type can be either simple (SE) or complex (CE).
specic applications. In the Figure 3, we summarize them. A complex event type is a combination of other simple or
Here we shortly explain some of the dimensions. The event complex events types. These event types are dened by the
detection and composition and the visible DB states will be application designer.
explained in the next section. Each event type (SE & CE) is dened by a set of at-
There exist many modes of event consumption, among tributes:
them we selected two modes more suitable to our environ- • name : name of the event type,
ment:
• lifespan: default time interval during which the event
1. recent: only the most recent instances of any event instance is valid,

are considered; older events are discarded. It is most • aggrFunction : function which aggregates events to pro-
suitable for fast-changing environments in which new duce a complex event. For simple events, there is no
events supersede old ones. aggregation function.

16
Each event type can be instantiated at runtime according to
data ows arriving to the mediation system. These event
instances (SE & CE) are dened by a set of attributes:
• value : event instance value,
• source : source name that captured the event instance,
• raisingDate : moment when the event instance is pro-
duced/observed by its source,

• systemTime : moment when the event instance is de-
tected by the mediation system,

• lifespan: time interval during which the event instance
is valid after its raisingDate,

• raisingLocation: geo-location where an event instance
Figure 4: Simple & complex event detectors
is produced/observed by its source.
mobile, he will not have time to establish proper con-

The lifespan is a metadata which can be provided by the nections with all equipments around him. The other

event source or assigned by the application. Event instances important aspect is the location. It can be expressed

are relevant during a limited period of time. Pervasive en- in many ways depending on the application: GPS co-

vironments can cause delays between the raising date of an ordinates, an address, or a locality label (e.g. Room

event instance and the time for treating this instance. Con- 305B, Administration Building). The spatial informa-

sequently the validity V of an event ei is dened by: tion can be provided by GPS built-in sensors or mobile
networks or derived from Google Maps or databases.
(
1 if raisingDate(ei ) + lif espan(ei ) < currentT ime)
V (ei ) = 2. The temporal dimension is an important information
0 otherwise
that can be used for personalizing an application. For
The raisingLocation is a useful notion for many location- instance, a user can be interested to receive events only
aware applications. Indeed, the location can inuence the in the morning. Designers can change the notion of
relevance of a given event instance. For example, an event moment in the core context, e.g. when the morning
ood detected far away from a user can be irrelevant for begins and ends. This information can be provided
him. by the phone clock (i.e. date, time) or derived from
Once event types are dened, one should specify how and context denition (i.e. moment).
when event instances are created or captured. This is done
3. The environmental dimension concerns all the sensors
by specifying event detectors. Depending on the event type
describing the environment of the user (e.g. temper-
and on the target data source, an event detector may be
ature, humidity, luminosity). This information is im-
dened in various ways: a listener, a lookup function or any
portant when the environment is xed, for example a
other procedure able to transform a specic signal into a
smart home.
semantic event.
For our scenario, the designers have separately dened 4. The equipment dimension characterizes all informa-
three simple event types : UnvalidTemperature, UnvalidHu- tion about the media used by the user to interact with
midity and Advertisement, with respectively a default lifes- the application: the used device (e.g. type, battery au-
pan of 5 min, 5 min and 1 week, and one complex event tonomy, memory storage, computing power) and the
type UncomfortableSituation with its associated aggregate connectivity (e.g. type of connection, rate). This di-
function Foo as depicted in the Figure 4. For each event, mension is important to adapt dynamically the system
the designer must dene a detector. Here, we only give the accordingly with the equipment constraints (e.g. low
simple event detector DT on temperature expressed as a battery, uncertain connectivity).
CQL query and the complex event detector US expressed
5. The user state dimension allows to know if a user is
as a CEP-like manner. Others are omitted as they can be
available or not, and how he feels. In our case, we are
expressed in a similar way.
more interested in the user availability which can have
an impact on the system behavior.
3.3.2 Context Model
According to [20], there exist six dierent models for rep- Designers have to provide the context model used by their
resenting the context information. Some models like the application and the set of context rules to the mediator that
ontology-based model is very expressive and allows power- can compute the current context. For that, a list of context
ful context processing. However in CAÏMAN the model used models is proposed with default context rules. For example,
is the simple key-value model as it should be embedded. if the application designer is interested in the location infor-
Following our previous work [3], we dene a context by mation, there exists a rule associated with this dimension
ve dimensions : spatial , temporal, environmental, equip- which captures the GPS coordinates from the smartphone
ment and user state. GPS sensor every minute. However designers can also write
their own context rules and submit them to the mediator.
1. The spatial dimension is an important characteristics
of mobile and pervasive environments. Indeed, de- 3.3.3 Profile Model
pending on how much the user is mobile, the system The survey [19] highlights the diculty of choosing the
will react dierently. For instance, if a user is highly good representation for the user preferences: qualitative or

17
quantitative. The quantitative approach allows a total order actuators located in the same room where the user is cur-
between preferences but is not intuitive because this implies rently located. Some variables have a default value set by
that the user put weights on his preferences. While the the designer. If not, they will be lled by the user when
qualitative approach is very intuitive but makes dicult the installing his application on his mobile device. For instance,
usage because there is not necessarily a total order between the default temperature variables are ($1=18°, $2=22°) for
preferences. In CAIMAN the user preferences considered are the day time and ($13=16°,$4=18°) for the night. In the
viewed as dynamic criteria by the application. Thus there same manner, advertisements relevant to a user are those
is no order between preferences as all preferences must be within $6='15km'. Others variables are set by the user.
considered by the application. For instance, Paul decides to change the default value $6 to
Following the denition given in [3], a user prole is or- 25km, and set the $$5 to (`music','sport').
ganized into several dimensions, possibly decomposed into
sub-dimensions. Each dimension and its sub-dimensions 3.3.4 Application ECA Rules
contain a set of attributes and their values on which prefer-
The last task of the designer consists in dening his set of
ences are expressed. We retain four important dimensions:
ECA application rules. For example, let's consider the fol-

1. Personal data contains all information about the user lowing rules dened in the Figure 6 that model our scenarii.

(e.g. his name, his address, his birthday). This dimen- As said before rules are contextual and personalized. Thus,

sion may also contain data on social groups to which the context and the user prole can be either explicitly used

the user belongs to (e.g. student, professor). by designers in their rules and in particular in the condition,
or implicitly used by the system during the runtime when
2. Domain of interest is generally the central dimension specied within the user prole.
of the user prole, it represents the user domain of in- The rst rule of the smart oce scenario explicitly uses the
terest and preferences. For example, the domain of in- user prole and in particular the UserPref.Temperature.min
terest may be the types of events the user is interested and UserPref.Temperature.max variables described above.
in and the preferences on how/when event instances As these variables are context-dependent (i.e. day or night),
are received or treated. their values are changing over time. So, they will be instan-
tiated just before evaluating the rule condition.
3. Resource discovery contains the user preferences on
In the second rule, a user receives advertisements. Here
the remote resources (i.e. type of resource, associated
no condition is specied; however one will be added by the
data collectors, related security issues and all meta
system at runtime since an implicit preference has been de-
data useful to understand data stream semantics). An
ned on this event type in the default prole. The reason
example can be receiving events only from sources lo-
why the condition is not directly written in the rule, is to
cated in the same place as the user.
allow the user to change his condition at any time. Here,

4. System adaptation groups user preferences on how the users receive advertisements relevant to their personal topics

system should adapt to the user context or to its own and within the required distance. When an event is relevant

behavioral parameters. An example can be to disable for the user, he is informed by email.

the resource discovery component during the night. A
set of preference rules can also be dened to adapt
the system behavior in case of low battery, that is
either disabling some functionalities or changing the
frequency of the captured data.

In the same way as the context, designers specify a default
user prole for their application. The Figure 5 describes
the application default prole set by the designers for our
scenario. We have gathered the prole of each application Figure 6: Rule Examples
into a global one, but in reality each application has its own.
$name and $$name variables represent respectively a string
Up to now, we have given some intuitions of our rule lan-
or a set of strings.
guage, now the semantics of rules is briey described.
The granularity of processing (e.g. instance or set-oriented)
is dened as a window. The default window [Now] is a time-
based window of size 1 and corresponds to the instance-
oriented. Others windows are dened as in any continu-
ous query language and correspond to the set-oriented. For
instance, range 5 min represents all events that appear
within the last ve minutes. Notice that we do not allow
unbounded windows. The visible state of conditions and
actions is dened by the window and the event type. The
event consumption mode is dened as a xed parameter of
the mediator and is taken into account in event detectors
Figure 5: User Prole that specify how to raise events.
For each application, the designer has specied the re- Some generic actions are possible and are dened by a
source discovery constraints. Indeed, to control the tem- template. The rst action inform($who,$how,$what) in-
perature in a room, we are only interested by sensors and forms a user or a group of users, or an application through a

18
delivery mode (i.e. local, wireless, email, SMS), of a partic- a given location and at a given time, according to the pref-
ular message or event. We separate messages from events, erences of the application or the user. Once the source is se-
messages are generated to users and denitively leave the lected and a communication established, a dynamic binding
system, by opposition to events that will be ltered and re- enables to link the data source to the mediator, by instan-
injected later in a mediator that can interpret them. The tiating the suitable data collector.
action activate($type, $service, $serviceparameters) acti-
vates a service with some parameters on a specic actuator
4.3 Profile & Context Manager
type that satises some user preferences. As many context-aware systems [6], the mediation system
proposed makes a separation between the context acquisi-
tion, the context processing, and the context information

4. THE CAÏMAN MEDIATION SYSTEM usage. In fact, data collectors are in charge of retrieve con-
text raw data, the context manager processes these data
In this section, we briey describe the behavior of the
to infer context information which will be stored and used
main components of our system at runtime. Thus, we as-
by applications and in particular application rules. These
sume that AmI applications have been deployed on the smart-
context information are also used by the prole manager to
phone, and that their default prole, detectors and rules
derive the active prole (i.e., all prole information which
have been transmitted to the mediator and uploaded in the
is valid for this current context). Indeed, the user prole
application metadata database.
is composed of a static part and a dynamic part. In the
rst one, the prole information doesn't change frequently
4.1 Data Collectors & Actuator Commands while the second one depends on a context that can change
As the data sources are heterogeneous, a set of generic rapidly. As we have seen in the Figure 5, the user prole can
data collectors and actuator commands are needed to al- be contextual and it will be the role of the context and prole
low communications with the mediation system. The Data managers to keep the active prole up to date for the ap-
Collectors are used to collect and transform any kind of het- plication. For simplicity reasons, an assumption is made on
erogeneous data so it can be understood and integrated in dening a contextual prole. Only If-then-else statements
the mediator. Each source is bound with one instance of a are allowed in order to avoid conicts between contextual
data collector that is responsible for querying and control- predicates. Only one active prole is valid at any instant of
ling this data source. All communications are asynchronous. time. Notice also that all variables can be changed at any
Another issue also considered is the data transformation as time by the user, via a simple interface on his smartphone.
the data provided by a source is not necessarily compati-
4.4 Rule Processor
ble to the coding, format, unit and scale of the expected
The Rule Processor is an idempotent service to which
data at the mediator level. The data collector is in charge
ECA rules with their associated detectors are submitted. As
of transforming these raw data into events, thus it activates
said earlier, it is important to follow rule execution seman-
the simple event detector associated with the source.
tic as described in the Figure 3. The query processor relies
Actuator Commands allows the mediator to transform
on a multi-threaded execution framework. The approach we
commands into real actions on the environment through ac-
follow is, in a way, very similar to what has been proposed
tuators services.
by Krämer [14] and especially their SweepArea that models
a dynamic data structure to manage a collection of events
4.2 Resource discovery & Bindings of the same type. ECA rules act as continuous queries over
Due to the numerous communicating objects that enter collection of events and react over their environment when
and leave the eld of detection because of the user mobility, a situation is encountered.
there is a need of a Resource Discovery component which is As events of the same type can be used in many rules,
continuously aware of the equipment's environment. events are not removed when used for triggering a rule.
Ambient data sources may connect and disconnect arbi- Thus, a garbage collector is necessary and events are re-
trarily. As the mediator cannot rely on a centralized re- moved from the dynamic structure when their lifespan has
sources registry, the resource discovery service is dened as expired. In order to avoid triggering multiple times a rule
a seeking function which detects the surrounding objects, with the same events, each rule has a context summarizing
identies them through some metadata exchange and estab- the past execution. When the rule processor is looking for
lishes connections to them if they are relevant at least for the rules that can be triggered, it uses the context which is
one active application deployed on the mediator. also computed in a continuous way. Only the most recent
As connections/disconnections can be frequent, the re- event is kept for each dimension.
source discovery component stores a history of all the dis-
covered sources with their version number. This version 4.5 The prototype
number is useful to know if the source has changed since Smartphones as well as computers cannot really sense the
the last time it was discovered. This is to avoid unnecessary world. For AmI environments, there is a need for tools for
metadata exchanges. The history plays the role of a local making computers that can sense and control more of the
resource registry which can be deleted at anytime, since it physical world than any other desktop computer. This is the
can be rebuilt at runtime. role of the Arduino [2] platform to sense the environment by
Before communicating with a data source, one should receiving input from a variety of sensors and to aect its sur-
know if the information it contains is relevant. For doing roundings by controlling lights, motors, and other actuators.
so, a matching is made between the source metadata and a A rst prototype combining Arduino and Android validating
part of the mediation schema. At the same time the context the approach has been implemented. Many sensors and ac-
and prole information is used to select only the sources in tuators have been prototyped. The CAÏMAN mediator and

19
many simple AmI applications can be deployed on an AN- [7] G. Biegel and V. Cahill. A framework for developing
DROID platform. For the time being, data collectors and mobile, context-aware applications. In Proc. of the 2nd
actuators are operational, as well as the resource discovery. IEEE Int. Conf on Perv. Comp. and Comm.
Simple and complex event detectors, as well as simple ECA (PerCom'04), pages 361, Washington, USA, 2004.
rules are supported. When the validity of events expires, the [8] I. Botan, R. Derakhshan, N. Dindar, L. Haas, R. J.
garbage collector automatically deletes the events. We are Miller, and N. Tatbul. SECRET: a model for analysis
currently integrating the context and the user prole within of the execution semantics of stream processing
the rules. The user agrees or not to install an AmI applica- systems. Proc. VLDB Endow., 3(1-2):232243, Sept.
tion on top of CAÏMAN. He can turn it on/o whenever he 2010.
wants to. He can also checked the types and the number of [9] M. Eckert, F. Bry, S. Brodt, O. Poppe, and
events, the mediator is currently monitoring. S. Hausmann. A CEP Babelsh: Languages for
Complex Event Processing and Querying Surveyed. In
5. CONCLUSION S. Helmer, A. Poulovassilis, and F. Xhafa, editors,
In this paper, we have presented the dierent require- Reasoning in Event-Based Distributed Systems,
ments posed by ambient environments and proposed an am- volume 347 of Studies in Computational Intelligence,
bient mediation system called CAÏMAN. As we have seen, pages 4770. Springer Berlin / Heidelberg, 2011.
a declarative approach based on ECA rules is proposed. [10] L. Feng, P. P. M. Apers, and P. W. Jonker. Towards
The main originality is that it combines in an elegant way context-aware data management for ambient
the context, the user prole and the continuous queries to- intelligence. In 15th Int. Conf. on Database and
gether. Some dimensions of the proles can be integrated Expert Systems Applications, pages 422431, 2004.
and changed at anytime by the user. Another important [11] T. Hofer, W. Schwinger, M. Pichler,
contribution of our work is that it is based on personal mo- G. Leonhartsberger, J. Altmann, and
bile devices and local computation that better fulll the user W. Retschitzegger. Context-awareness on mobile
privacy. To our knowledge CAIMAN is the rst ambient devices - the hydrogen approach. In Proc. of the 36th
mediation system embedded in a smartphone oering such Annual Hawaii Int.Conf. on Syst. Sci. (HICSS'03),
functionalities. pages 292.1, Washington, DC, USA, 2003.
Some open issues still remain to be considered such as [12] J. Indulska and P. Sutton. Location management in
how to adapt the system if the context is critical (i.e., low pervasive systems. In Proc. of the Australasian inf.
battery), what to do when many mediators are acting in sec. workshop conf. on ACSW frontiers, pages
a conicting way on specic resources, how an event that 143151, Darlinghurst, Australia, Australia, 2003.
has been sent several times by dierent data sources can be [13] N. Jain, S. Mishra, A. Srinivasan, J. Gehrke,
discovered to avoid repeating the same actions again and J. Widom, H. Balakrishnan, U. Çetintemel,
again. M. Cherniack, R. Tibbetts, and S. Zdonik. Towards a

Acknowledgment streaming SQL standard. Proc. VLDB Endow.,
1(2):13791390, Aug. 2008.
This work is partially funded by the French National Agency [14] J. Krämer and B. Seeger. Semantics and
for Research (ANR) project under grant KISS (2011-INSe- implementation of continuous sliding window queries
005-03). over data streams. ACM Trans. Database Syst.,
34(1):4:14:49, 2009.
6. REFERENCES [15] S. R. Madden, M. J. Franklin, J. M. Hellerstein, and

[1] ABI research. http://www.abiresearch.com/press/ W. Hong. TinyDB: an acquisitional query processing

1466-In+2014+Monthly+Mobile+Data+Traffic+Will+ system for sensor networks. ACM Trans. Database

Exceed+2008+Total. Syst., 30(1):122173, 2005.

[2] Arduino site. www.arduino.cc. [16] A. Margara and G. Cugola. Processing ows of
information: from data stream to complex event
[3] S. Abbar, M. Bouzeghoub, D. Kostadinov, S. Lopes,
processing. In Proc. of the 5th ACM int. conf. on
A. Aghasaryan, and S. Betge-Brezetz. A personalized
Distributed event-based system, DEBS '11, pages
access model: concepts and services for content
359360, New York, NY, USA, 2011. ACM.
delivery platforms. In Proc. of the 10th Int. Conf. on
Information Integration and Web-based Applications [17] N. W. Paton and O. Diaz. Active database systems.

and Services., pages 4147, New York, USA, 2008. ACM Comput. Surv., 31(1):63103, 1999.

[4] A. Arasu, B. Babcock, S. Babu, M. Datar, K. Ito, [18] F. Sadri. Ambient intelligence: A survey. ACM

I. Nishizawa, J. Rosenstein, and J. Widom. STREAM: Comput. Surv., 43(4):36:136:66, Oct. 2011.
the Stanford stream data manager (demo). In Proc. of [19] K. Stefanidis, G. Koutrika, and E. Pitoura. A survey
the ACM SIGMOD Int. Conf. on Management of on representation, composition and application of
data, pages 665665, New York, USA, 2003. preferences in database systems. ACM Trans.

[5] A. Arasu, S. Babu, and J. Widom. The CQL Database Syst., 36(3):19, 2011.
continuous query language: semantic foundations and [20] T. Strang and C. L. Popien. A context modeling
query execution. The VLDB Journal, 15(2):121142, survey. In UbiComp 1st Int. Workshop on Advanced
2006. Context Modelling, Reasoning and Management, pages
[6] M. Baldauf, S. Dustdar, and F. Rosenberg. A survey 3141, September 2004.

on context-aware systems. Int. J. Ad Hoc Ubiquitous [21] G. Wiederhold. Mediation in information systems.
Comput., 2(4):263277, 2007. ACM Comput. Surv., 27(2):265267, 1995.