1. Introduction
Wireless sensor network (WSN) technologies that are available today allow easy network installation. However, the true cost of WSNs has shifted into the area of the maintenance costs that are inherent to networks with a large number of nodes and a limited battery life. Since the majority of the sensors used are still battery powered, these batteries require regular changing and/or recharging. Moreover, when used for long-term monitoring, a network evolves: new nodes may be added to the system; failed nodes are removed from the system; and user requirements and system functionality change over time. In addition, for an in-building WSN, the building itself may evolve: physical obstacles, such as walls and doors, that affect sensing coverage and communications, are often removed or added when a refurbishment is carried out. In long-term deployments, it is these evolutionary changes that can be highly disruptive to the network, affecting its ability to operate as expected.
Contiki’s Cooja [
1] is a very popular WSN simulator. Similar to other WSN simulators, such as OMNeT [
2], TOSSIM [
3], OPNET [
4], Ns-2 [
5] and Ns-3 [
6], it lacks support for modelling sensing coverage, focusing instead on network connectivity and protocol performance. However, in practice, it is the ability of a sensor network to provide a satisfactory level of coverage that defines its ultimate utility for end-users. In this paper, we introduce WSN-Maintain, a Cooja-based tool for coverage and network lifetime evaluation in an in-building WSN. It takes the floor plan of a building specifying the locations of obstacles, such as walls and doors, the coverage requirement of each region and the locations of sensor nodes. With WSN-Maintain, users can specify different degrees of coverage to different regions. For example, a server room and an electrical room require that each point in the area is covered by at least two sensors, and the rooms must be 100% covered, while it is enough for an office space to be 75% covered, and each point is covered by one sensor. WSN-Maintain runs in parallel with the collect-view tool of Contiki, which was integrated into the Cooja simulator and allows an interactive view of a data-gathering application.
Application developers can use WSN-Maintain to implement and evaluate different techniques/algorithms to maintain coverage, where the tool finds coverage redundant nodes, puts them to sleep and turns them on when active nodes fail and coverage quality decreases. As our use cases, we implement two redundant node algorithms: greedy-maintain, a centralised algorithm, and local-maintain, a localised algorithm to configure the initial network and to turn on redundant nodes. We also incorporate the concept of reading correlation using the inverse distance weighting interpolation method. Sensors whose reading can be predicted using the reading of nearby active sensors can be considered as redundant and can be put to sleep to conserve energy. WSN-Maintain and Cooja simulation results using data from five real deployments show that utilising simple redundant node algorithms with reading correlation can improve energy efficiency by putting more nodes to sleep.
3. WSN-Maintain
Cooja [
1] is a very popular network simulator within the WSN research community, but it does not model sensor coverage, focusing instead on network connectivity and protocol performance. However, in practice, it is the ability of a sensor network to provide a satisfactory level of coverage that defines its ultimate utility for end-users. WSN-Maintain is designed to allow users to evaluate different techniques to turn on redundant nodes to maintain coverage requirements. This tool is run in parallel with Cooja. The relationship between WSN-Maintain and Cooja is depicted in
Figure 1.
Draw building floor plan and deploy sensor nodes: With WSN-Maintain, users can import the floor plan of a building from an XML file or manually draw one by clicking and dragging walls and doors on its canvas. While we use walls and doors as indoor obstacles that can limit communication and sensing capabilities, for simplicity, we currently do not consider the types of construction materials used. In addition to the floor plan, users can click on the canvas to place sensor nodes, click on a room to automatically deploy all nodes for 100% coverage or load their locations from a file.
To automatically deploy sensor nodes in a room, the boundary of the room must be identified. To identify the boundary, we create and scan rectangular grids, starting from the location on the canvas that is clicked by a user. The rectangular grids augment until they hit the obstacles. After the room is identified, sensor nodes are added one by one until the room is 100% covered. The first sensor node is deployed at the user’s clicked location, and the rest are greedily added to maximise the coverage of the room.
Create network connectivity: To calculate network connectivity, WSN-Maintain currently supports two types of radio mediums,
i.e., the unit disk graph model (UDGM) and directed graph radio medium (DGRM). With UDGM, the topology file contains node locations, transmission range, interference range, transmission success ratio and receive success ratio. As we follow the specified format of files from Cooja, we can only create a network with homogeneous communication capabilities using UDGM. That is, all sensor nodes have the same range and receive success ratio. To create a heterogeneous network, users may opt for DGRM. With DGRM, WSN-Maintain can either automatically calculate received signal strength and receive success ratio for every pair of sensor nodes using the formula specified in [
9,
10] or take real link quality traces as a topology file.
The received signal strength (RSS) at a distance
d (
) is:
where
is the output power of the transmitter and
is the path loss.
Table 1 shows the Tmote Sky output power configuration for CC2420 [
7], an IEEE 802.15.4-compatible radio.
The in-building radio propagation model that takes into account the effects of obstacles (walls) between the transmitter and the receiver on the same floor is given by [
10]:
where
d is the transmitter-receiver distance,
a reference distance,
n the path loss exponent (the rate at which the signal decays), and WAF is the
wall attenuation factor. Based on the measurement in [
11], WAF is chosen to be 3.1 dBm.
Table 2 shows the real signal propagation measurements conducted using Tmote Sky with the maximum power level (
= 0 dBm) in line-of-sight (LOS) and non-line-of-sight (NLOS) conditions reported in [
12].
The packet reception rate (PRR) at a distance
d (
) is given by:
where
f is the frame size, which is 128 bytes for Tmote Sky’s CC2420.
is the signal-to-noise ratio (SNR) at a distance
d and is given by:
is the noise floor, which is given by [
10]:
F is the noise figure,
k the Boltzmann’s constant,
the ambient temperature and
B the equivalent noise bandwidth. The values for these parameters for Tmote Sky’s CC2420 are given in
Table 3 [
13]. One can change all of these parameters according to the type of hardware used.
Identify node on/off status based on coverage and connectivity: To create a coverage map of the building, WSN-Maintain currently supports two types of coverage models,
i.e., the binary detection model and Elfes’s model [
14]. These models can be used to approximate, for example, passive infrared (PIR) sensors. While at the moment, only these two models are implemented in WSN-Maintain, one can add other models based on their own requirements.
With the binary model, the probability
that a sensor node
i senses a point
v in a floor plan is one if the distance
between
v and
i is less than or equal to a threshold distance
,
i.e., the node’s sensing range (
Figure 2a).
In Elfes’s model, as depicted in
Figure 2b, the probability that sensor
i detects a target on grid point
v is:
where
r is the sensing range,
(
) is a measure of uncertainty in sensor detection,
λ and
β are parameters that model different sensor characteristics and
. The parameters
r,
,
λ and
β are adjusted according to the physical properties of the sensor. In particular,
r and
affect the threshold distances of target detection. In [
15],
, and
. We approximate
and set the probability threshold to 0.9,
i.e., a point cannot be sensed if its probability is less than this threshold.
In this work, we assume that sensor nodes cannot sense through walls and doors. We also assume that users may require different coverage degrees for special rooms, such as a server room and an electrical room. WSN-Maintain allows users to do this by clicking a point inside a room and specifying the coverage requirement. The total coverage percentage is calculated as the ratio of the total area satisfying the coverage requirements to the total interior area of the building.
Export topology file, export on/off binary file, read topology file and read node on/off status: WSN-Maintain communicates with Cooja by exporting a topology file specifying network connectivity and a binary file specifying the on/off status of nodes. Note that with UDGM, the topology file specifies transmission range and interference range in meters, as well as the transmission success ratio and the receive success ratio in the range of [0, 1]. With DGRM, the topology file contains received signal strength in dB and received success ratio in the range of [0, 1] for every pair of sensor nodes.
Run data gathering simulation: WSN-Maintain is run in parallel with the collect-view tool of Contiki, which was integrated into the Cooja simulator, to gather data from the WSN.
Export log file and calculate node remaining energy: Cooja communicates with WSN-Maintain through its log file. WSN-Maintain reads the log file to calculate the nodes’ remaining energy. In [
16], a linear model is used to estimate sensor node energy consumption. The total energy consumption
E is defined as:
where
V is the supply voltage,
the current draw of the microprocessor when running,
the time in which the microprocessor has been running,
and
the current draw and the time of the microprocessor in low power mode,
and
the current draw and the time of the communication device in transmit mode,
and
the current draw and time of the communication device in receive mode and
and
the current draw and time of other components, such as sensors and LEDs.
Table 4 shows the energy consumption parameters used. The current draw of the communication device in transmit mode (
) for different power level has been shown in
Table 1. Time measurement is implemented using the on-chip timers of the MSP430. The 32,768-Hz clock divided by eight is used, producing 4096 clock ticks per second.
If a node fails or runs out of energy: When a node dies, the coverage percentage decreases or the network disconnects. If the coverage percentage is below a threshold or the connectivity is insufficient, WSN-Maintain will either automatically find and turn on non-overlapping redundant nodes to maintain the coverage and connectivity requirement or report failures that require physical maintenance. Users can interactively use WSN-Maintain to simulate node failures by killing nodes or just wait until a node runs out of energy to see the results of WSN restoration.
5. Simulation Set-Up
In the WSN-Maintain simulation with Cooja, we use datasets from five sensor network deployments: a data centre room at the Informatics Institute at Federal Fluminense University in 2013 (TMON) [
20], the ground floor and first floor of the Nimbus building at the Cork Institute of Technology in 2013 (CIT-1 and CIT-G) and the second floor and third floor of the Strata Conference building in New York that was held in 2012 (NY-2 and NY-3) [
21]. We chose these deployments as we require dense networks for our simulation, where some rooms must have multiple sensor nodes, as to be expected in large buildings. Unless otherwise specified, the five datasets that are used in our simulation consist of temperature sensor reading for 24-hour periods. The floor plan of the buildings and the sensor node locations that are used in the simulation are depicted in
Figure 4,
Figure 5,
Figure 6,
Figure 7 and
Figure 8.
The information for the five WSN deployments is summarised in
Table 5. These deployments have different numbers of sensor nodes. Note that some rooms do not have sensor nodes, and so, they are not considered in the performance calculation. The simulation parameters are given in
Table 6. We assume all sensor nodes communicate using the highest power level. For Tmote Sky’s CC2420 radio, the output power is 0 dBm (
Table 1). To have sufficient sensing coverage, we use 7.5 m as the sensing range for all sensor nodes in the CIT-1, CIT-G, NY-2 and NY-3 deployments. However, for the one-room TMON deployment, a 2.5-metre sensing range is sufficient to have the room covered. TMON needs higher accuracy because of the nature of the application,
i.e., data centre monitoring. We also assume that all sensor nodes have the same initial energy. We choose a small amount of energy,
i.e., one Joule for TMON, five Joules for CIT-1 and CIT-G and four Joules for NY-2 and NY-3. This is a pragmatic choice that allows us to run experiments that can produce results within practical time periods, since in reality, sensor networks are expected to have sufficient power for operation over several months.
For the network connectivity, we use directed graph radio medium because for an in-building scenario, we take into account the effects of obstacles (walls and doors) between the transmitter and the receiver. For the sake of simplicity, we use the binary detection model, and all rooms have the same coverage requirements,
i.e.,
. To have sufficient coverage redundancies, we use 75% local coverage threshold, as the deployments are not dense enough, except the TMON deployment, where we use 95%. For the reading correlation, a node is redundant if the difference between the predicted and its actual temperature readings is below 0.1 °C. This value is in the range of Tmote Sky’s temperature sensor accuracy [
22]. For two dimensions, we use the correlation’s power parameter
. Our simulation utilises the collection tree protocol (CTP) [
23] implemented in Contiki and the duty-cycling Contiki MAC protocol [
24].
7. Related Work
Currently in the literature, there does not exist a tool to manage and maintain coverage in a deployed sensor network. However, in this section, we try to review publications that relate to maintenance efficiency in wireless sensor networks.
Wireless sensor networks are prone to node failures, for instance caused by battery depletion, damaged hardware and buggy software. To be able to maintain efficient operations and to prolong the lifetime of the network, a sensor network should be resilient to these dynamics and able to automatically reconfigure itself. In some applications, physical node access costs are assumed to be dominant over
in situ costs during WSN maintenance. This means the maintenance cost for replacing one sensor (or its batteries) will be approximately the same as the maintenance cost for replacing all sensors in a region. In this case, one may try to balance the energy consumption of the whole network, so as to extend the time intervals between replacement of one or more nodes/batteries in the field. Barroso
et al. [
27] modify the Greedy Perimeter Stateless Routing (GPSR) protocol for these purposes. In the modification of GPSR, a message is not necessarily forwarded to a neighbour that is the closest one to the destination. Instead, the message is randomly delivered to any node closer to the destination. This scheme proves to achieve better maintenance efficiency, which depends on the number of messages sent. However, using this scheme, messages travel longer paths, which result in increased latency.
A failed node can create coverage and connectivity holes in a sensor network. In order to maintain network effectiveness, failed nodes should be replaced. There are three policies for failed node replacement by repairing network holes created by failed nodes [
28]. The first policy is the directed furthest node first (DFNF), where an active node repairs the hole using one of its deactivated neighbours that has the longest distance, but in the same direction to the hole. In the second policy, weighted directed furthest node first (WDFNF) selects replacements by considering both the distance and direction of a node. The third one is best fit node (BFN), where all active nodes adjacent to a coverage hole participate in the replacement procedure. These three policies need strong assumptions regarding the network properties: for the unit disk graph model, the transmission range is twice the sensing range, and nodes can measure distances and angles to other nodes. It has been shown that DFNF and WDFNF can achieve similar lifetime to BFN when the network is extremely dense. Extremely dense here means an active node has around 20 inactive neighbours, which is not realistic in a real deployment.
Under the condition that the communication range ≥ 2 × the sensing range, a sensor network only needs to be configured to guarantee coverage in order to satisfy both
k-covered and
k-connected network, where
[
29]. A decentralised algorithm called the Coverage Configuration Protocol (CCP) has been proposed to evaluate a node’s eligibility to become active if one of the intersection points of its neighbours’ sensing circles are not
k-covered. This algorithm requires the information about locations of all sensing neighbours, which are gathered using beacons (
i.e., HELLO messages) received from the neighbours. When the ratio of the communication range to the sensing range
, CCP guarantees
k-coverage, but nodes might not communicate with each other. In this case, Span [
18] can be utilised. Span is a decentralised algorithm to activate extra nodes for one-connectivity. With Span, a node decides to become active if two of its neighbours cannot reach each other either directly or via one or two active nodes.
An in-field maintenance framework for VigilNet has been proposed [
30]. VigilNet is a surveillance application. In this framework, users are allowed to define the coherency requirements of the states of protocols, specify the maintenance/repair policy (
i.e., when to self-heal the system and who invokes the maintenance service) and define which set of protocols need maintenance services in order to satisfy a system performance requirement and the dependency constraints among the services, according to the system specification and constraints. For example, time synchronisation repair is performed once per day; sensing coverage repair is performed locally if the coverage
; while communication repair is performed at the base station if the connectivity
. During the communication repair, the base station computes the connectivity graph based on the connectivity information reported from the nodes. Different from the original VigilNet system [
31], where all of the protocols are reinitialised once per day without considering if a protocol needs the reinitialisation, the proposed framework allows different maintenance periods for different maintenance services and, thus, saves up to 5% of a node’s battery capacity.
Li
et al. [
32] propose a dependency constraint-directed self-healing framework to allow users to compose self-healing services. The framework includes three components: health monitoring, self-healing policy and self-healing engine. The health monitor is implemented to collect the health state information at system execution time, such as battery level, link quality and end-to-end delay. The self-healing policy, which is usually specified by the application designer, is not discussed in this paper. The self-healing engine includes a set of run-time invocation routines embedded in the main loop of the application.
When an automated reconfiguration cannot heal the network, physical maintenance is required. In [
33], Parikh
et al. propose node-replacement policies to maintain a minimum threshold coverage and maximise the network lifetime using a fixed amount of replacement nodes. The policies determine if a failed node in the network is important enough to be replaced by calculating the weight of the failed node based on a specific parameter. If the weight of a failed node is greater than the policy threshold, the failed node is replaced. Otherwise, it is ignored. The parameters are the cumulative reduction in area of sensing coverage, the energy increase per node, the local reduction in area of the sensing coverage and the hybrid of the three parameters with different weights. With up to 10% coverage degradation, the results show that the hybrid policy improves the network lifetime by up to 90% compared to the no-replacement policy and up to 23% compared to the simple first-fail-first-replace policy.
The betweenness centrality of a node is the sum of the probability that the node falls on a randomly-selected shortest path between all pairs of nodes in a network. According to Kas
et al. in [
34], when nodes with high betweenness centrality die, the number of hops between any two nodes in a network becomes greater. This happens because the high betweenness nodes are on a high fraction of shortest paths among other nodes in the network. The concept of betweenness centrality can be used for routing purposes, where routing paths can bypass nodes with high centrality to preserve their energy. For the maintenance point of view, the locations of nodes with high centrality can be used to deploy redundant nodes as backups. Therefore, when nodes with high centrality die, the redundant nodes can be activated to replace the dead nodes. The use of centrality to analyse network robustness and deploy relay nodes has been proposed in [
25].