What should the value of P be?

In Triva, as mentioned in Section 5.2.5, sending HELP packets depends on the probability P. And this value affects the message overhead of Triva. IfP is set to 1, all nodes in the neighbourhood that are ready to send theHELP packet will send it. However, this may cause not only a lot of message overhead, but also collisions which wastes resources such as energy [70]. Conversely, if P is set to a very small value, then nodes might not sendHELP packets and the asymmetric link problem may not be solved for a time until one of the nodes sends a HELP packet. Thus, there is a tradeoff between the message overhead and latency.

For simplistic assumptions, like a circular communication range and uniformly distributed networks, the value of P could be approximated as following. Let k be the number of neighbours of a node. Let n1 and n2 be neighbours of each other.

Then, if the coverage area of a node is Πr2, then the intersection of coverage areas of n1andn2 is 2Πr2/3−r2

√

3/2 (see Figure 5.16 for illustration). As there areknodes in Πr2, there are aroundk/3 nodes in 2Πr2/3−r2√3/2. Therefore, if there exists an asymmetric link between n1 and n2, the neighbours of both should set their P

to a number between 1 and 3/q, i.e., 1 ≥P ≥3/k. For example, if the number of neighbours of a node isk≤3, then P should be set to 1; if k= 30, then P ≥0.1.

One way to relax the above assumptions is to have nodes to broadcast their neighbours’ IDs so that each node could identify the number of common nodes (the intersection area) for each pair of its neighbours. And according to that number, nodes could define theirP. However, it needs extra number of packet transmissions and memory to store the number of common nodes for each pair of neighbours. Moreover, this way will not work well for time-varying topologies where nodes may crash, join or disjoin the network.

To find P for time-varying topologies, nodes should exchange messages periodi- cally or when there is a change in their neighbourhood. In WSNs, such a technique

n1 n2 r r r

120o

Figure 5.16: Computing an approximate value ofP. The area of the shaded region is equal to 2Πr2/3−r2√3/2

is usually used for different objectives. For example, in [70], this technique is used to select a single sender in a neighbourhood at a time. So, to find the value ofP for time-varying topologies, like the above method, first, nodes should broadcast their neighbours’ IDs to find the initial value of P, and then whenever a node detects any change in its neighbourhood, the node informs its neighbours about the change so that its neighbours could update their P accordingly. However, as mentioned above, this is costly and may not be practical, especially for resource constrained wireless sensor nodes. Also, while trying to reduce message overhead, this method, conversely, may increase it.

A simpler and more practical solution could be, instead of computing the value of P according to topology changes, to set P to a constant value and apply a basic suppression method, as in Trickle [79], to reduce the number of redundant HELP

packet transmissions. That is, if noden1hears noden2 transmitting aHELPpacket

to noden3, then there is no need forn1to transmit aHELPpacket ton3. Otherwise,

if n1 does not hear any HELP packet, then n1 sends a HELP packet to n3 with

probability P. This solution will greatly reduce the message overhead, even when the network is dense and P = 1, as most of the neighbours will suppress their

transmissions. But then the question is how many redundant HELP packets will be sent if P = 1? The answer is only few. According to the simulation results reported in [79], if we apply the above suppression method, in a 1-hop network of sizes 8, 64 and 256, then the number of transmissions is 2, 3 and 4 with 0% packet loss rate, and 4, 7 and 10 with 60% packet loss rate, respectively. This is because, based on the simple geometric observation, there could be at most 5 nodes that may not be connected with each other if the communication radius of nodes is same [121]. Therefore, the network topology will not affect much. To reduce the message overhead further, we can set P to a smaller constant value such as 0.5, which might slightly increase the time to solve the asymmetric problem.

In general, for any network topology, setting P to a small value bigger than 0, P > 0, will still lead to a better performance as it overcomes the problem of asymmetric links. However, it may take more time to solve the problem. Setting P = 1 may generate lots of additional traffic as long as there exist asymmetric links; however, when all nodes solve the asymmetric link problem, Triva does not send HELP/ADV packets anymore. We think that this is reasonable if the number of asymmetric links is large and they are permanent, though more transmission energy may be used (see Figure 5.17).

We use the casino lab noise trace to make the network more realistic. However, the casino lab file has a high SiNR (Signal-to-Noise Ratio). The impact of a low SiNR, such as heavy-meyer trace file has to be determined. Figure 5.18 shows the impact of a signal with high SiNR 5.18(a) and low SiNR 5.18(b). As can be observed, the number of transmitted packets with low SiNR is more than that of with high SiNR.

0 5000 10000 15000 20000 25000 30000 0 50 100 150 200 250 300 350 400 Numbe r of p ack ets Time(minutes) P=0 P=1

Figure 5.17: The number of transmitted ADV and HELP packets when P=0 and P=1 0 1000 2000 3000 4000 5000 6000 7000 8000 0 50 100 150 200 250 300 350 400 Numbe r of p ack ets Time(minutes) P=0.2 P=0.5 P=0.8 P=1

(a) The number of packets with varyingP and high a SiNR 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 0 50 100 150 200 250 300 350 400 Numb er of p ack ets Time(minutes) P=0.2 P=0.5 P=0.8 P=1

(b) The number of packets with varyingP and low a SiNR

Figure 5.18: The impact of P and SiNR

5.5

Conclusion

In this chapter, we have proposed an algorithm that can be used to maintain code updates in a wireless sensor networks. Code update maintenance algorithms are necessary as not all nodes may update to a new code during code dissemination phase due to reasons such as transient link failures. The existing algorithms of this kind are efficient in terms of different metrics such as latency and energy. However, they have drawbacks as well.

The algorithms, namely Trickle and Varuna, have drawbacks in terms of energy and latency, respectively. In the presence of asymmetric links the latter does not consume constant energy as expected. The proposed code maintenance algorithm in this chapter, called Triva, tries to address the drawbacks of the algorithms by leveraging the properties of both. It adapts both Trickle and Varuna to achieve energy efficiency and low dissemination latency in event-based sensor networks and in the presence of asymmetric links. The results of performed simulation and real- world testbed experiments show that Triva outperforms both Trickle and Varuna (i) in periodic traffic, (ii) event-based traffic, (iii) bursty traffic, and (iv) in networks with asymmetric links.

To address the asymmetric link problem, which Varuna does not solve, Triva uses additional packets called HELP. However, HELP packets are sent only when there exist asymmetric links in the network, thereby reducing the message overhead. The experiment results showed that by solving the asymmetric link problem Triva stops sending ADV packets when there is no new code in the network, which is desirable especially when updates occur rarely.

All in all, although Triva, like Trickle and Varuna, may not work with dissem- ination protocols that have protocol specific mechanisms such as sender selector in MNP, the mentioned algorithms are orthogonal to many code dissemination algo- rithms and thus can be integrated to any of them to maintain code updates. There- fore, Triva is an algorithm that could be integrated to any compatible dissemination protocols to save more energy.

Data Aggregation Scheduling with Two Sinks