7.5 Sleep Scheduling Protocol for Partial Coverage
7.5.1 Description of the scheduling protocol
We assume that the sink or base station which is a powered node computes the expected redundancy degree for a type i sensor, given the number of neighbours of each type, and their ranges for sensing and communication. The expected redundancy degree corresponding to a given number of neighbours of different types is stored in
0.5 0.6 0.7 0.8 0.9 1
(0,1) (0,2) (0,3) (0,4) (0,5) (0,6)
Expectedredundancydegree
No. of neighbours of (type 1, type 2) Numerical results for type 1 Simulation results for type 1 Numerical results for type 2 Simulation results for type 2
0.5 0.6 0.7 0.8 0.9 1
(1,0) (2,0) (3,0) (4,0) (5,0) (6,0)
Expectedredundancydegree
No. of neighbours of (type 1, type 2) Numerical results for type 1 Simulation results for type 1 Numerical results for type 2 Simulation results for type 2
(a) (b)
0.5 0.6 0.7 0.8 0.9 1
(1,1) (1,2) (1,3) (1,4) (1,5) (1,6)
Expectedredundancydegree
No. of neighbours of (type 1, type 2) Numerical results for type 1 Simulation results for type 1 Numerical results for type 2 Simulation results for type 2
0.5 0.6 0.7 0.8 0.9 1
(1,1) (2,1) (3,1) (4,1) (5,1) (6,1)
Expectedredundancydegree
No. of neighbours of (type 1, type 2) Numerical results for type 1 Simulation results for type 1 Numerical results for type 2 Simulation results for type 2
(c) (d)
Figure 7.3 Variation in the expected redundancy degree of a sensor for different number of neighbours.
a table called Redundancy Table (format shown in Table 7.1(b)). Computation of this table is facilitated by Eq. 7.8. The Redundancy Table is either stored in each sensor off-line or can be sent by the base station initially at the time of deployment.
Once a sensor knows the information about its neighbours, it can lookup the expected redundancy degree from this table, compare it with the desired coverage ratio and determine if it is redundant. We explain the protocol used to gather information about the neighbours and sleep scheduling in detail below.
In the sleep scheduling protocol, the operation time of the WSN is divided into successive rounds. Each round consists of two phases: the decision phase and the sensing phase. In the decision phase, all sensors decide on their activity for the current round. During the sensing phase, all active sensors are responsible for sensing until the beginning of the next round. After each round, all sensors become active to participate in the decision phase of the next round. The duration of each round is chosen such that it is much longer than the decision phase but much shorter than the average lifetime of the WSN.
At any given point of time, a sensor can be in one of these states: ACTIVE, WAIT, and SLEEP. In ACTIVE state, a sensor is responsible to cover its sensing region and communicate with its neighbours. At the beginning of each round, all sensors are in ACTIVE state and independently execute the scheduling protocol. In SLEEP state, the sensor is put to sleep in order to conserve energy. Sensors in this state are not required to maintain the desired QoC during the round. A sensor goes into WAIT state if it determines itself to be redundant but is in the process of asserting its transition to SLEEP state with its neighbours. The state transition diagram of this protocol is similar to that in previous proposals like [77, 78].
The scheduling protocol uses two messages HELLO and SLEEP to disseminate information among all the neighbours. Each sensor turns active at the beginning of a round (i.e., during the decision phase) and broadcasts a HELLO message with its
ID, type, and current state to all its neighbours. A sensor that receives the HELLO message stores information about its neighbours in a Neighbour Table in the format shown in Table 7.1(a). The table stores the unique ID of each neighbour, its type, and the current state of the neighbour. This information is updated with periodic HELLO messages between the sensors.
From the information in the Neighbour Table, each sensor knows the number of neighbours of each type and their state. It then looks up the expected redundancy degree corresponding to the number of different types of neighbours from theRedun- dancy Table. Table 7.1(b) shows the format of the Redundancy Table for a type 1 sensor. The first two columns in the table show the number of neighbours of each type while the third column shows the expected redundancy degree. For example, if this sensor has two type 2 sensors in the neighbourhood (in ACTIVE or WAIT state), the expected redundancy degree is 0.91. Since the Redundancy Table can be computed offline and stored at the time of deployment, determining the expected redundancy degree of a sensor is simplified to only periodically refreshing the information in the Neighbour Tableand looking up the Redundancy Table.
Table 7.1 Data stored at a type 1 sensor.
ID Type State 1 type 1 ACTIVE 2 type 2 WAIT 3 type 2 WAIT 4 type 1 ACTIVE 5 type 1 ACTIVE (a) Neighbour Table.
nnn111111 nnn121212 E[ξE[ξE[ξ111]]]
0 0 0
0 1 0.73
0 2 0.91
... ... ...
6 6 1
(b) Redundancy Table.
Each sensor compares the expected redundancy degree with the desired coverage ratio of the field (a constant QoC requirement) to determine if it is redundant. If the
track of its SAC neighbours with HELLO messages. The motive behind back-off time is to avoid a black-hole when several sensors try to go to SLEEP state simultaneously.
If the sensor has sufficient number of active neighbours at the end of back-off time, it sends SLEEP messages to a selected number of neighbours (greater than or equal to the number of neighbours required for its redundancy), and switches to the SLEEP state until the next round. To send the SLEEP messages, a neighbour already in the ACTIVE state is given higher priority either because it does not have sufficient neighbours for redundancy, or it just switched from WAIT state to the ACTIVE state.
A SLEEP message consists of the IDs of the sender and all the selected neighbours.
When a sensor receives the SLEEP message, it switches to ACTIVE state or stays in the same state until the next round. This is because the receiving sensor is made responsible for the area covered by the sender of the SLEEP message. If SLEEP message is received by a sensor whose ID is not listed in the message the receiving sensor uses it to update its Neighbour Table.