1. DEUS
Deployment and Ease Use of wireless Services
Pervasive reasoning platform
for WSMN
Main challenges
Deus targets a service platform capable of dealing with geographically dispersed systems
connected through a Wireless Sensor and Mesh Network. The platform uses a variety of
devices and delivers services that cross device, platform and system administration
boundaries.
Efficient handling and quality-aware processing of the enormous amount of data coming
from a wireless sensor network (WSN) is extremely difficult: data samples are often lost
during transmission, many irregular and faulty measurements are produced, and sensor
nodes are frequently unavailable. Figure 1 illustrates a temperature management
application that drives an air conditioning system based on temperature samples from
the WSN installed in a building. Given the unpredictable and unreliable nature of WSNs,
the application must specify and enforce quality requirements: (1) the maximum period
between consecutive samples, (2) the minimum coverage (#samples/#available nodes)
per room, or (3) the maximum deviation from previous samples from the same sensor.
Deus approach:
The adoption of ontology technology supported by distributed reasoning mechanisms
facilitates transparent monitoring in this heterogeneous environment. The concept
definitions in the ontology and the rules according to which nodes and the environment
variables need to classified can be changed according to the locally deployed hardware,
specifications and environment. The developed platform demonstrates that, by
introducing intelligent and advanced technologies, such as ontologies and principles from
the Semantic Web, great improvements can be achieved both in extendibility and
maintainability. Changes over time to classification rules are easily implemented through
adaptation of the ontology deployed on the mesh nodes. New hardware can also be
included with minimal effort if new ontology graphs are created modelling the new
hardware. The inclusion of this new information, or the adaptation of local rules based on
the local environment is achieved transparently for the monitoring application.
Observations from a realistic test bed (iLab.t Wireless Lab) confirm the need for quality
control and show that aggregating faulty temperature samples can be highly problematic
for the aggregated end result.

2. DEUS
Deployment and Ease Use of wireless Services
To handle this problem, we studied and evaluated an approach to attach quality labels to
suspicious data samples. By describing (1) patterns of interest, (2) logic that associates
these patterns to application specific quality requirements, and (3) actions to pursue in
case of a positive match, we can resolve the problems stated above; in addition, by
handling the problems at the spot where they occur (for example dropping data) we can
avoid unnecessary (and power consuming) network communication.
Figure 1: The Quality of Data problem
Deus solutions:
A distributed platform needs a mechanism to deploy and connect collaborating agents
that run on the different processing nodes. Deus uses a service registry, advertisement
and discovery service that is based on an enhanced nameserver.
The naming service should support the dynamicity, abundance and transient behaviour of
sensor devices.
There are two steps in the discovery process. First the necessary information needs to be
fed into the discovery service. Secondly, entities needing to find devices/services should
be able to query the available information. An important aspect is the maintenance of the
information managed by the discovery service. The information in the discovery service
needs to reflect the actual status of the published devices/services. The best way to
achieve this is by assigning a lease period to the published information.
The standard DNS service has already most of the properties that are needed for a
naming and discovery service, except for 2 features:
• In DNS all inserted entries need to be explicitly removed
• DNS has no notification system
By extending the DNS server with a frontend supporting “lease time”, we are not forced
anymore to explicitly remove entries. By extending it with DNS Long Lived Queries (LLQ),
we implement a kind of subscription mechanism for DNS that solves the notification
problem.

3. DEUS
Deployment and Ease Use of wireless Services
The building blocks of the architecture presented in Figure 2 that are related to the
reasoning functionality are the Reasoning Distribution Module and Reasoning Engine
Module. Additionally, to improve the transparency to the outside world, an extra
indirection layer has been included at the interface level, namely the Interface Module.
This layer is introduced to facilitate multiple reasoning technologies without the need for
the clients to be aware of this. As such, only generic interface operations should be
defined, avoiding the use of reasoning technology dependent query and invocation
mechanisms, e.g. SPARQL. Additionally, to decouple the reasoning from the data storage,
two extra modules are introduced, namely the Data Provider/Resource Module and the
Aggregator Module. The Data Provider/Resource Module will collect the data from the
resources on which it has been deployed or for which it is responsible and feed it to the
Aggregator Module. Upon request of the Reasoning Engine Module, the Aggregator
Module will feed this collected data to the reasoning process. This way of working allows
including sensor devices in the workflow and thus facilitates the monitoring of the sensor
network, by means of sensor information generated from the Data Provider/Resource
Modules deployed on the sensor devices.
Figure 2: Distributed Reasoning Architecture

4. DEUS
Deployment and Ease Use of wireless Services
Figure 3: Distributed Reasoning Workflow
The Quality of Data aspects are covered in the architecture by means of a policy-based
approach based upon two key elements (see Figure 4):
• a component model that allows for easy inspection of data flows between
components that compose applications.
• a policy framework that allows for fine-grained control of data flows and
ensures that relevant policies are enforced on the data passing between a
pair of components.
In this context, various Event-Condition-Action (ECA) policies can be defined to describe
the actions to take when a particular pattern is recognized in the data flow between two
components; each policy can be dynamically installed, uninstalled, enabled, and disabled.

5. DEUS
Deployment and Ease Use of wireless Services
Figure 4: The Quality of Data policy framework
Deus Proof-of-Concept implementation:
The DEUS naming and discovery server is using the Apple implementation (dnsextd) of
update leases and long lived queries. This implementation uses a front-end to a regular
BIND dynamic DNS server. The regular DNS server listens on a non-standard UDP/TCP
port and only accepts updates coming from the front-end server. This front-end server
listens on the regular DNS UDP/TCP port 53. All regular DNS queries are forwarded to the
regular DNS server. The dynamic DNS server is authoritative for a domain within the
DNS hierarchy and handles all operations for this domain. Queries for other domains are
forwarded throughout the DNS tree as is done in regular DNS. The front-end server
intercepts all update and LLQ requests. Updates and LLQ without an associated lease
time are rejected. This requirement excluded the use of standard DNS update tools (e.g.
nsupdate) that do not supply an update lease with an update request.
The architecture defined for the DEUS project can be deployed on the different nodes of
heterogeneous networks, such as the WiLab.t infrastructure, facilitating a distributed
monitoring platform which can be tuned to the needs of each individual deployment.
Figure 5 illustrates this deployment. Although only a single type of sensors is currently
deployed on the testbed, future extensions with different types of hardware are possible.
After the integration of this new hardware, the addition of new ontology models and data
providers will suffice to include them in the monitoring workflow. After all, the specific
definitions of the concepts against which the observations are checked to realise the
correct Fault and Solution classification, can be changed independently from the end
monitoring application.

6. DEUS
Deployment and Ease Use of wireless Services
Figure 5: Distributed Reasoning Deployment Diagram
The DEUS proof-of-concept shows the Quality of Data policy framework in combination
with the underlying component model; it is provided for (1) SunSPOT sensor nodes, (2)
ALIX mesh nodes, and (3) back-end infrastructure, and leverages on SquawkVM on
SunSPOT, and OSGi on the ALIX nodes and in the backend.
The Quality of Data policy framework can deal with various qualities such as inaccurate
or missing sensor readings, by applying actions such as labeling, filtering, reporting, and
substitution of inaccurate readings by regularly approved readings.
In addition, the Quality of Data policy framework is integrated with reasoning solutions; if
local rules fall short, the policy framework can query the reasoning engine to determine
the most appropriate action to take for a particular observation in the data flow.
Results are promising: when compared to the original observations and data processing
quality achieved at the iLab.t Wireless Lab, backend applications can draw substantially
more accurate end-conclusions for a particular data flow when the data has been
inspected and processed by the Quality of Data policy framework.

7. DEUS
Deployment and Ease Use of wireless Services
Project partners
In cooperation with
IBBT research groups
UGent - IBCN http://www.ibcn.intec.ugent.be
UGent - WiCa http://www.wica.intec.ugent.be
UA - PATS http.www.pats.ua.ac.be
KU Leuven – DistriNet http.www.distrinet.cs.kuleuven.be
KU Leuven – CUO http://ww.soc.kuleuven.be/com/mediac/cuo
UHasselt - EDM http://www.edm.uhasselt.be/