## 5 Performance Evaluations
### Evaluation of Frequency of Global Updates  
To estimate the most efficient global update frequency, we test different frequency values (_i.e._, \(f\)) varying from 3 to 25 \(s\). In this set of simulations, sinks perform periodically global updates to update the routing tree and local convex hulls. There is no local update during the simulations, _i.e._, mobile nodes do not sent local update messages to their neighbors. Higher frequency of global updates means that the routing trees of sinks will be updated more frequently resulting in new geocast structure most of the time. The queries are sent just before the next global update starts to see the worst case behavior of different update frequency values. In Figure 11(a), we evaluate execution ratios (ERs) of different \(f\) values when we increase the number of nodes and the number of mobile nodes in the network. We observe that increase in number of nodes and number of mobile nodes in the network results in decreases of ERs for different global update frequencies. The best ER is obtained when \(f~{}=~{}5\). Although global updating every 3 seconds refreshes the tree structure more frequently, the drop in the ER of \(f~{}=~{}3\) is very large when we increase the number of nodes. This is mainly due to the overlapping of global updates. Overlapping means that before finishing one global updating, the next one starts. The overlapping time gets longer when we have more nodes in the network. Therefore, for bigger network sizes \(3\) seconds is not enough to finish one global update. For instance, for a network having 360 nodes, it takes around 3.75 seconds to finish  
Figure 11: Execution Ratio for different frequencies of global updates. one global update. For other \(f\) values bigger than \(5\), ER is worse than ER of \(f=5\) for the given network sizes. It is important to point out that for networks bigger that 360 nodes, 5 seconds may also not be enough to finish one global update. However, it is the best frequency for the range of network sizes we consider here. In Figure 11(b), which reflects the results of _Scenario 2_, we plot the dependency between ER and the number of mobile nodes. While in _Scenario 1_ (Figure 11(a)), the ratio of mobile nodes to the number of nodes in the network is kept constant, here we vary the number of mobile nodes in the network and keep the total number of nodes fixed. ER of \(f=5\) is also the best in this scenario. In general, when we have higher mobility (_i.e._, more mobile nodes) in the network, the ER decreases for all values of \(f\). Finally, in Figure 11(c), we explore the influence of speed of mobile nodes on ERs of different update frequencies. The frequency \(f~{}=~{}5\) again achieves the best performance. However, different than the other scenarios, ERs first slightly decrease when we increase the speed of mobile node up to \(9~{}m/s\), then ERs stay more or less stable or slightly increase for the speeds higher than \(9~{}m/s\) in this scenario. This behavior is due to the adaptation of timeout mechanism according to speed of mobile nodes. For higher speeds, timeout interval is shorter; hence, up-to-date convex hull descriptions can be obtained quicker. Since the geocast structure is updated more frequently for higher speeds by the timeout mechanism, ER results are the same or better for higher speeds. Figure 12: Communication Overhead for different frequencies of global updates. Maintaining up-to-date convex hull information by exchanging control packets incurs control overhead. Possessing the most up-to-date tree structure provides better chance to build a more efficient query dissemination solution. However, there is a trade-off with the update interval: if trees routed at sinks are updated too often, the benefit of having current state information diminishes and most of the energy will be consumed exchanging control packets (_i.e._, hello, convex hull update messages). In what follows, we investigate the communication overhead of different update frequencies in the three scenarios.