# Reliability-Aware Cooperative Node Sleeping and Clustering in Duty-Cycled Sensors Networks
## 6 Performance Evaluation
### Performance Comparison among RCR, REER, BLR and GPSR  
On top of the data delivery schemes, we transferred a video sequence from the source node to the sink. Since the compressed video bit stream is sensitive to transmission errors because of the frame dependency, error control techniques such as forward error correction (FEC) were necessary to obtain the high reliability required by video services. We implemented the FEC coding scheme proposed in [29], and \(n-m\) redundant packets were generated to protect \(m\) data packets of a video frame. The size of each FEC packet was equal to the maximal size of data packets. If any \(m\) of \(n\) packets in the coding block were received by the sink, the corresponding video frame was successfully restored. In our simulation, three (\(n-m=3\)) FEC packets were used to protect six original video packets (\(m=3\)). We compared RCR with the other three algorithms in terms of reliability and energy consumption per pack, as shown in Figure 9. In the simulation, we changed \(f\) from zero to 0.95 with  
Figure 8: The impact of \(f\) and \(\mu\) on reliability and ETE delay in RCR. Figure 7: The impact of \(f\) and \(k\) on reliability and ETE delay in RCR. the step of 0.05. We set \(k\) in RCR to nine and \(r\_value\) of REER to 65 m (i.e., the reference node at every hop had nine cooperative nodes on average). In Figure 9a, the performances of four schemes, i.e., REER, BLR, GPSR and RCR, are compared in terms of reliability. With the increase of \(f\), the reliability of GPSR decreases with the fastest speed among all schemes due to the lack of a mechanism for tackling packet loss. The BLR periodically re-selects the relay node using two forwarding mechanisms, namely the relay node-based forwarding and normal forwarding. During the selection of the relay node, broadcasting was utilized to achieve high reliability. However, once the relay node was selected, in the stage of normal forwarding, the same relay node was used for a certain period without the ability to antagonize fluctuations in channel quality. Thus, with the increase of \(f\), the reliability of BLR decreases quickly. As indicated in BLR, a timer was set, and the time value was inversely proportional to the distance progress. However, in the simulation, the data collision among multiple nodes was hard to avoid because of the timer parameter, i.e., 0.04 s [16]. Thus, we implemented three hand-shakes including DATA, REpand SELin the protocol, which was adopted by REER [17]. Compared to the BLR, both REER and RCR select multiple relay nodes for every hop to achieve high reliability. In order to compare the RCR with the REER, we considered a scenario where \(k\) is set to nine. In the RCR, nine CNs were selected for each hop. However, the number of CNs is unstable in REER because \(r\_value\) was first calculated according to \(k\). Due to the uneven node distribution, the practical number of CNs based on a fixed \(r\_value\) can be much smaller than nine. We varied \(r\_value\) from 40 m to 75 m with a step of 5 m and found that the average number of CNs was nine when \(r\_value\) was 65 m and the average hop count was 10.7. In comparison, the selection of the forwarding area in RCR was stricter than REER. For the same \(k\) (\(k=9\)), the average hop count reached 14.4 in RCR. Though RCR requires a higher hop count, the number of CNs was stable at each hop. Thus, the reliability was high and predictable. In the case when the average \(k\) was nine, the REER would have poor performance with lower reliability; because the bottleneck hop with an unpredictable small number of CNs reduced the whole ETE reliability. Figure 10 shows the snapshots of OPNET simulations for the same network scenario for the REER and RCR protocols. The number of cooperative nodes (packet forwarders) in hops in REER was unstable, as shown in Figure 10a.