A distributed reasoning platform is presented to reduce the energy consumption of Wireless Sensor Networks (WSNs) o ering geospatial services by minimizing the amount of wireless communication. It combines local, rule-based reasoning on the sensors and gateways with global, ontology-based reasoning on the back-end servers. The Semantic Sensor Network (SNN) Ontology was extended to model the WSN energy consumption. One exemplary prototype is presented, namely the Garbage Bin Tampering Monitor (GBTM).
The GreenWeCan [
Therefore, a distributed reasoning platform (Section 2) was utilized. Rulebased reasoning on the sensors allows for conclusions concerning measured variables to be drawn locally. A back-end ontology-based reasoning mechanism, which has a complete overview of the senor data being produced, can in uence the behavior of the WSN nodes. Section 3 describes the ontology, which is used to model and reason on the sensor knowledge to reduce energy consumption.
The use of proven standard reasoning mechanisms in WSNs is still premature. However, the reduction in energy consumption by a reduced transmission rate, compared to the extra power needed for such processes, should result in a positive balance. Moreover, using standard reasoning algorithms, instead of proprietary ones, makes the approach more generic and facilitates reusability. A prototype was developed to demonstrate these advantages (Section 4).
(Local) Rule-based sensor reasoning (Global) Ontology-based overall reasoning
Wireless Sensor Network (WSN)
Router
Sensor gateway
Back-end server
User requests
D2R MySQL Database As shown in Figure 1, information requested by the users is gathered from the sensors, which measure environmental parameters and pre-process them by performing rule-based reasoning. As such, less data is transmitted to the back-end. The complexity of the local reasoning can be adapted to the sensor's capabilities, e.g., battery, to optimize energy consumption. Moreover, the local reasoning is able to monitor the sensor's inner workings, e.g., CPU usage, in order to detect problems that in uence energy consumption.
The pre-processed data is forwarded to the back-end via a gateway, optionally multi-hopping over routers. The sinks perform local, rule-based reasoning, e.g., to avoid retransmissions and preserve energy, the network load is monitored.
The back-end maintains an ontology to model the knowledge about the WSN and its observations. Static information, e.g., sensor speci cations, is gathered from a database using D2R3. The received sensor data is integrated into this ontology to answer user requests and optimize the overall energy consumption.
Using an ontology ensures reusability and adaptability. Should new types of sensors be deployed, their semantic description and measurements can be mapped on the existing ontology. Moreover, by making the ontology publicly available as well as the data and conclusions corresponding to the run-time situation of the WSN, new applications can be created by anyone persuing a new usage and easy integration of this information.
The ontology can also be used to de ne the local, rule-based reasoning algorithms. The developed Reasoning Sensor App Generator generates sensor application code based on an XML-based application description. This description speci es a rule set and a template. The rst contains the reasoning logic, which is executed each time the sensor wakes up. The second contains the code needed to run the reasoning logic on hardware. 3
A SSN Ontology extension modeling energy usage The W3C Semantic Sensor Network Incubator group has developed the SSN Ontology4 for modeling sensor devices and their capabilities, systems and processes. Based on brainstorms with GreenWeCan partners, i.e., OneAccess and Bausch Datacom, the requirements for the modeling concepts were de ned. These were mapped on the SSN Ontology and some extensions were made. The relations
between the sensor con gurations, networks and applications and the in uence on the energy consumption were also derived.
As shown in Figure 2, the SSN Ontology allows to model sensors, their observations and measurement capabilities. To avoid error propagation and retransmissions, the SNN was extended with concepts to make the quality of the observations explicit as they can be imprecise, ambiguous or erroneous. Symptoms de ne rules, which allow detecting speci c phenomena in the observations. Axioms are de ned that reclassify these Symptoms as Faults and Solutions.
The SSN Property concept models the type of metrics that can be observed. The Data- and InternalProperty subclasses are added to group the application-relevant observations monitored and the hardware-speci c properties internally measured by the sensor. Figure 2 shows some internal properties to minimize energy consumption, e.g., sleeping schemes and radio settings can be adjusted to avoid bu er over ows and thus the amount of retransmissions.
The type of a sensor indicates which local reasoning techniques can be adopted. The Sensor concept in the SSN Ontology is annotated with a reference towards SensorML5. This speci cation can be used to re ect all the sensor's details.
Battery, Harvester, ROM, CPU and Radio concepts are introduced as these in uence the reasoning complexity that can be used. The SSN Ontology already de nes the Battery LifeTime property. Some other battery properties were added. The Current- and Potential Configurations of the radio and CPU are also modelled. The rst models the currently used values for the characteristics, while the second represents the combination of values that can potentially be used together. Similarly, new sensors can be modeled, as shown in Figure 2 for the Magnetic Sensor and its settings, e.g. Sensitivity.
The location of the sensors can in uence the energy consumption. The SSN Ontology models the WSN's deployment. To represent the physical locations the SSN Ontology aligns with the DOLCE Ultra Lite Ontology6. These concepts are preceded by the DUL namespace in Figure 2. Link and NetworkRole concepts are introduced to represent the network components used to interconnect the
nodes and the role each node plays. Characteristics can be attached to the links, e.g., LinkQuality, which in uences packet drops and retransmissions.
Finally, the context in which the WSN operates plays a role. Therefore, the ontology is linked to existing ones, e.g., the OWL Time ontology and DBPedia7.
The GBTM monitors garbage bins in Ghent, which are used for small-scale litter disposal and are equipped with a sensor to detect the opening and closing of their cover. The cover can only be removed by a special-purpose key. Any other manipulations are illegitimate. A web-based interface8 allows personnel to consult the observations, either as raw data, as an alligned table clustering data per bin or on a map. Anomalies are highlighted by combining the observations with external data, e.g., garbage collection timetables. The views also allow optimizing garbage collection routes and timetables.
Rule-based sensor reasoning The garbage bins are equipped with a magnetactivated reed switch, which stores a type, i.e., open or close, and timestamp in the sensor's ROM when a hardware interrupt occurs. To reduce the number of transmissions, rule-based reasoning accumulates the sensor readings during a con gurable time interval, after which they are transported in bulk to a database on the back-end server, which exposes them via a D2R-based RESTful interface.
Ontology-based back-end reasoning The sensors issue their measurements once per time interval to the back-end. The Next-Wake-Up-Time con guration parameter determines the timepoint at which this happens. It is preferably avoided that sensors wake up at the same time as this increases the amount of retransmissions, particularly in single-hop topologies, due to collisions. Therefore, if such a situation is discovered, the back-end reasoner will use the WSN ontology to recalculcate a dephazed next wake-up time scheme.
Rule-based gateway reasoning When the gateway receives a request, it rst checks if the required up-to-date info is available in its cache. If it is, the cached data is sent to back-end to reduce the amount of data transmitted and thus the energy consumption. If not, the measurements are retrieved from the sensors. Determining the time after which data in the cache should be refreshed is di cult. Applications preferably use the most recent measurements. However, they need to comply with legislation concerning how much Radio Frequency communication is used, e.g., 6 minutes per hour for a 169 MHz radio. Therefore, the gateway monitors the duty cycle and adapts its caching strategy accordingly.
gbtm.php