These coordinates are similar to the ones in VCap [6], JUMPS [7] or VCost [9]. Several nodes, L₁, . . . , L_k with k ≥ 3, in the network are distinguished as landmarks. Each landmark broadcasts a beacon in the network incremented at each hop. From it, an arbitrary node x knows its virtual coordinate vector V(x) = (h₁, . . . , h_k) where h_i is the hop-distance between x and L_i. Figure 1(a) shows an example of how nodes are assigned virtual coordinates. We suppose 3 landmarks: nodes 10, 9 and 14. Every node thus has a 3-dimensional vector as coordinates constituted by the number of hops between itself and every landmark. For instance, node 0 can reach Landmark 1 (node 10) in 2 hops, Landmarks 2 (node 9) in 4 hops and Landmark 3 (node 14) in 3 hops. Its virtual coordinate is thus V(0) = (2, 4, 3). The distance used on these virtual coordinates is d_V where d_V (u, u′) is the Hamming distance from node u to node u′ on V coordinates ( d V ( u , u ′ ) = ∑ i = 1 M | h i ( u ) − h i ( u ′ ) | ). For example, on Figure 1(a), the distance d_V (0, 8) between node 0 (V (0) = (2, 4, 3)) and node 8 (V (8) = (4, 1, 3)) is d_V (0, 8) = |4 − 2| + |1 − 4| + |3 − 3| = 2 + 3 + 0 = 5.

Obviously, using only these coordinates does not guarantee delivery since the node coordinates are not unique (i.e., several nodes may have the same virtual coordinates) and thus do not identify a single node. This is for example the case for nodes 6 and 15 on Figure 1(a) which are both labeled with (4, 2, 4).

We build T labels in the same fashion as in LTP [10]. This labeling is performed through a tree construction. The tree is built iteratively from the root to the leaves. At bootstrap, a node is designed as root. This node may be a special node such as a fixed landmark. At each step, every freshly labeled node queries its unlabeled neighbors and then gives a label to each answering node. If l(u) is the label of node u, the k^th neighbor of node u is labeled l(u)k. Figure 1(b) gives an example of how the nodes are labeled. The tree root is node 4 and has the label R. Node 13 is labeled R211 since is it the first child of node 0 which has label R21. The tree gives the shortest path in number of hops from the root to any other node. The distance used in the tree is based on label size and common prefix which can give the hop distance between any two nodes of the network. Thus the distance between node a and node b is d_T (a, b) = |l(a) − l(c)| + |l(c) − l(b)| where c is the lowest common ancestor of a and b and l(a) is the label size of node a. From Figure 1(b) the distance between node 9 and node 5 is thus d_T (9, 5) = |l(9) − l(4)| + |l(4) − l(5)| = |3 − 1| + |1 − 2| = 3.

As described in [10], the path is encoded in the labels. There exists a path encoded in node labels between any two nodes of the network. This path is the path in the tree, which, by definition, always exists and is unique (for t = 1).

Let N(u) be the set of physical neighbors of node u, i.e., the set of nodes in communication range of node u. Let δ(u) be the cardinality of this set, also called the degree of node u: δ(u) = |N(u)|. We define N_V (u, u′) as the set of neighbors of node u that reduce the distance to node u′, regarding the V coordinates: N_V (u, u′) = {v|v ∈ N(u), and d_V (v, u′) < d_V (u, u′)}. Similarly, N_T (u, u′) is the set of neighbors of node u that reduce the distance to node u′, in T coordinates: N_T (u, u′) = {v|v ∈ N(u), d_T (v, u′) < d_T (u, u′)}.

Although HECTOR is cost model-independent, for the sake of proof of concept, we use the most common energy model [23], which is as follows: cost(r) = r^α + c if r ≠ 0, 0 otherwise, where r is the distance separating two neighboring nodes, c is the overhead due to signal processing, and α is a real constant (>1) that represents the signal attenuation. Note that, in reality, this needs to be multiplied with a constant that includes, for example, the message length.

The optimal transmission radius, r*, that minimizes the total power consumption for a routing task is equal to: r * = c α − 1 α assuming that nodes can be placed on a line toward the destination [17].

Let us introduce the functions COP_T and COP_V as functions defining selection criteria of s’s next hop toward d in a cost-over-progress fashion [1] over coordinates T and V respectively. s selects node b, which minimizes COP_T or COP_V as defined later in Algorithm 1. These functions are as follows: (1) COP T ( u , v , d ) = cost ( | uv | ) d T ( u , d ) − d T ( v , d ) (2) COP V ( u , v , d ) = cost ( | uv | ) d V ( u , d ) − d V ( v , d )where |uv| is the Euclidean distance between nodes u and v.

Algorithm 1 formally describes this routing process.

In this paper, we assume every node is able to control its transmitting power (and thus its range) and to estimate the Euclidean distance between itself and every of its neighbor, based on the received signal strength (RSSI).

HECTOR uses RSSI rather than the angle of arrivals or triangulation that require additional communication overhead. In addition, even if some obstacles or external environment impact could mislead the computing of the distance based on RSSI, this computed distance reflects the state of the link. If a short link is seen as long by the node because of low RSSI, the link will be less likely to be used, which is a positive point. Virtual distances are not suitable in the cost calculation since they do not reflect the real cost of the transmission.

Each node u has two sets of coordinates (V, T) as defined in Section 3.

The routing algorithm combines advantages of both kinds of coordinates : (i) virtual coordinates as in VCost [9] allow the reduction of the path length and (ii) labels as in LTP [10] avoiding reaching a dead end and to guarantee delivery.

The basic idea is the following. A source node s holding a packet for a destination node d performs an energy-efficient greedy routing scheme in a VCost fashion. In order to avoid to be trapped in a local minima, the routing algorithm selects the next hop with regard to not only the virtual coordinates but also the labels. The routing process runs as follows. When node u receives a message for node d, it first considers its neighbors in the forward direction, based on both their labels and virtual coordinates. It only considers nodes v for which d_T distance toward d is equal or smaller than the tree distance between u and d (d_T (v, d) ≤ d_T (u, d)). Such neighbors always exist (whenever source and destination nodes are connected) because of convergence of label-based routing. The algorithm first checks whether any one of these nodes also provides a progress with respect to landmark coordinates. Let H = N_T (u) ∩ {N_V (u) ∪ v |d_T (v, d) = d_T (u, d)} be the set of such nodes.

If H ≠ ∅, then u selects its next hop among the nodes in H (thus reducing the distance toward the destination regarding coordinates V and not increasing distance regarding T labels) as the node v that provides the best ratio cost over progress to the destination regarding the virtual coordinates (v such that COP_V (u, v, d) = min_w∈NV (u) COP_V (w)).

Otherwise (that is, if H = ∅), the node selects its neighbor v that provides the best ratio cost over progress (as in [1]) to the destination regarding the labels (v such that COP_T (u, v, d) = min_w∈NT (u) COP_T (u, w, d)). Such a node always exists since there always exists exactly one path in the tree between any two nodes. In case of ties, the next hop is chosen at random between candidates.

Lemma 1 A packet cannot transit from a node u to another node v if V (u) = V (v) (or if d_V (u, d) < d_V (v, d)) unless there is an absolute progress regarding T labels (if d_T (u, d) > d_T (d, v)).

Proof Let us assume that node u holds a packet for a destination d. Suppose that nodes u and v have the same V coordinates (V (u) = V (v)) or that v is farther than node u regarding V coordinates (d_V (u, d) < d_V (v, d)). Then v ∉ N_V (u, d), which means that v ∉ H. The selected next hop thus belongs to H′ = {v|COP_T (u, v, d) = min_i∈NT (u) COP_T (u, i, d)}, which contains every neighbor of u closer to d than u regarding T labels. Thus, if node v is chosen as the next hop, that means that v ∈ H′ and thus provides a progress regarding T labels. Note that in the worst case (i.e., when the progress on T labels is minimal), the next hop is either the parent or a child of node u.

Lemma 2 The routing protocol described in Algorithm 1 is loop free.

Proof We introduce an order among all nodes with respect to combined distance to destination d. Consider d_T (u, d) as the primary key, and d_V (u, d) as the secondary one. Two nodes are sorted by their primary key. In case of ties, the secondary key is used. Thus u < v if and only if d_T (u, d) ≤ d_T (v, d) and (d_V (u, d) < d_V (v, d) or H = ∅). Let us assume that node u₀ is the source of a packet, d its destination and node u₁ the next hop chosen by node u₀. If H ≠ ∅ then d_T (u₁, d) ≤ d_T (u₀, d) as per restriction. Also similarly d_V (u₁, d) < d_V (u₀, d). Therefore u₁ < u₀ in our order. Let H = ∅. Then d_T (u₁, d) < d_T (u₀, d) and therefore again u₁ < u₀. Our routing process therefore strictly reduces distances to destination regarding T coordinates at every step in the order defined by given primary and secondary keys. This means that loops cannot be created.

Lemma 3 In the routing protocol described in Algorithm 1, there always exists a next hop that is closer to the destination regarding both sets of virtual coordinates.

Proof Let us consider a source u and a destination d. By construction, if a node in N_V (u, d) is chosen as the next hop, this ensures a progress on the V coordinates. If the next hop is chosen in N_T (u, d) this ensures a progress in the tree toward the destination. The progress will occur since N_T (u, d) is a nonempty set.

It is worth noting that the progress made on V is more important than the progress made on T labels in the geographical space. Indeed, the next hop in the T labels can have the same V coordinates and thus more or less the same Euclidean distance to the destination. These lemmas show that the routing protocol HECTOR described in Algorithm 1 always works in a greedy way. The greedy aspect provided by this algorithm makes it simple, memoryless and scalable.

Theorem 4 The routing algorithm described in Algorithm 1 guarantees delivery.

Proof Each node has a unique label due to the labeling process described in Section 3. This ensures that the destination of a packet is unique and that at each step of the routing protocol, a next hop closer to the destination can be found. Based on Lemmas 1, 2 and 3, if a path exists (if the network is connected), the routing protocol will find it in a greedy way.

For using multiple trees, some additional notations are introduced.

Let Ω be the set of trees. We note d_mT (u, v) the distance in the forest or set of trees between nodes u and v: d mT ( u , v ) = min t ∈ Ω d T ( u , v , t )where d_Ti (u, v) if the d_T distance in tree i between nodes u and v. We note N_mT (u, u′) the set of neighbors of node u that provides a positive progress to u′ in the forest: N_mT (u, u′) = {v|v ∈ N(u), d_mT (v, u′) < d_mT (u, u′)}.

Based on this, we can now define the COP_mT function as the cost over the progress realized over the forest and not a single tree as follows: COP T ( u , v , d ) = cost ( | u v | ) d mT ( u , d ) − d mT ( v , d ).

By replacing 1-tree notations by these new notation, the same algorithm as Algorithm 1 applies. Algorithm 2 details the new routing algorithm. The current node u holding the packet first considers the set of its neighbors that provide both a positive progress on V coordinates and a positive or null progress over T coordinate whatever the tree considered (u considers nodes v such that v ∈ {{N_mT (u, d)} ∪ {v|d_mT (v, d) = d_mT (u, d)}} ∩ {N_V (u, d)}) and chooses the one among them that provides the best cost-over-progress over V coordinates. If no such node exists, u chooses the next hop as the one that provides the best progress over T coordinates over every tree. To break ties, it applies the minimizing label and label balancing rules that we describe below.

Indeed, some cases may appear in which, from the local point of view of the current node, every tree provides the same progress to the destination. For instance, let us consider node 13 on Figure 2 aiming to send a message to node 6. Here, paths in both trees A and B have the same length, regarding T coordinates (7 hops). Nevertheless, the message may follow the path through nodes 13−0−3−4−5−6, which is the shortest one but only if node 13 chooses Tree A. To help node 13 make the right decision, two selection rules are introduced: the minimizing labels rule and the label balancing rule.

Minimizing labels rule: When paths are equivalent, the next hop in route selection is the node with the lowest label size. The idea here is that by selecting the next hop in such a way, the message goes at least 1 hop toward the tree roots and, as further stated by Theorem 6, the path in the tree from the root to any other node is the shortest path. This is easily done by counting and summing the number of digits of every label of a node. For instance, node 13 has to choose between node 0 (which label global size is |A00| + |B0110| = 3 + 5 = 8) and node 12 (which global label size is |A0010| + |B0200| = 5 + 5 = 10). Thus here, Tree A is selected since the number of digits of node 0 is the smallest one. When node 0 is reached, it reiterates the same process and so on.

Minimizing label rule: This rule allows the selection of a node with a high position in every tree. This is interesting when the routes from the source to the destination have to pass through a parent in both trees.

Nevertheless, these two rules do not prevent from having nodes choosing at random, as it is the case if node 0 handles a packet for node 6. It has the choice between Tree A through node 1 and Tree B through node 3 which both offer a path of length 6 hops and which both have a global label size equal to 7. So, to break that final tie, we apply the Label balancing rule. This rule will favor the node which label sizes are load balanced. Indeed if label sizes are load balanced, that means that the root of the trees are more likely to be bypassed, which may prevent from contention. In this case, node 0 will choose node 3.

We now prove that Algorithm 2 finds the shortest path in the forest.

Definition 1 (shortcut) We call shortcut a link between two distinct branches of the tree on the routing path.

Definition 2 (t-shortcut) A t-shortcut is a link on a routing path that allows the switching from a tree to another one.

Lemma 5 We assume that the network is stable at least during a minimum time that ensures that a packet can be routed from its source to its final destination. If the MAC layer and the Physical layer are ideal (no packet loss or interferences), there is no t-shortcut between a parent and a child.

Proof Let us assume 3 nodes with labels A, A1 and A11. Let us assume that a t-shortcut exists between nodes A and A11 from another tree. This means that node A11 did not receive the Discovery request from node A, which is impossible since we assume that there is no message loss.

Lemma 5 can easily be extended to t-shortcuts between nodes with labels of size X and labels of size X + 2 resp.

We now give two definitions for a subtree. Definitions 3 and 4 are equivalent.

Definition 3 (Subtree) Node u belongs to the subtree of node v iff l(u) ⊂ l(v).

Definition 4 (Subtree) Node u belongs to the subtree of node v iff node v is on the path in the tree from node u to the tree root.

Theorem 6 If the MAC layer and the Physical layer are ideal, which means that there is no message loss, a shortest path to a destination node in the subtree of the source is the path which follows the tree.

Proof This is true based on Lemma 5, because there is no possible t-shortcut in the same subtree.

This theorem means that, if a path from a node to another node in the same subtree exists, this path (by using this tree) is the shortest path. The two previous theorems mean that the t-shortcut and the minimizing labels rules are interesting when the destination is not in the subtree of the source. The minimizing labels rule is thus important when the destination is not in the subtree of the source (for all trees) because when the labels are minimized, it means that in at least 1 tree the message is forwarded toward the root of this tree.

As we focus our performance evaluation study on network layer mechanisms, for our performance results to be independent of the lower layers, we chose to use our home-made simulator that assumes ideal MAC (no packet collision, no delay) and Physical layers (no interference, BER = 0, isotropic radiation pattern). The network can be described as follows. Nodes are deployed in a 1,000 × 1,000 square following a two dimensional Poisson Point Process with different intensities λ. In such a Poisson Point Process, the total number of nodes is probabilistic and is obtained from a Poisson Law of intensity λ, which is correlated to the mean node degree δ : λ = δ π R 2. Nodes are uniformly distributed over the area. Nodes can adapt their range between 0 and R = 200. We only consider connected networks.

We compare HECTOR, LTP [10] and VCost [9] for the same samples of node distribution, same source and destination pairs, both randomly chosen. Landmarks and the tree root are randomly chosen among the nodes. Finally, to show the impact of the use of the two sets of coordinates over the guaranteed delivery, we evaluate the performances of the routing schemes over a homogeneous network and over a topology with a crescent hole (see Figure 3).

All results are the average of statistics retrieved from more than 100 simulation runs and meet a 98% interval. Note that the bootstrap cost induced by the coordinates setting is not integrated in these results. We keep for future work the evaluation of this cost and the maintenance of the virtual coordinates.

We evaluate the energy consumption overhead (ECO) of each algorithm based on the energy model described in Section 3. As in [23], we use c = 10⁷ and α = 4, which leads to an optimal range of r^* = 100 [24]. To further evaluate the routing protocols, we computed their energy overhead using as reference the optimal centralized energy weighted shortest path (SP) (Dijkstra algorithm [25]). We let e_i and e^* be the energy consumed using any described protocol and the centralized SP protocol, respectively. We define the energy overhead as the ratio e i − e * e * × 100. Note that 0% overhead means that the algorithm consumes the same energy than the optimal algorithm.

We also evaluate the mean path length and mean hop length obtained for each protocol and give visual results of routing process.

Energy consumption overhead when VCost succeeds. Figure 4 shows the ECO for paths provided by the different algorithms when VCost succeeds for a given source-destination pair. The energy overhead is drawn depending on the mean node degree and on the number of landmarks used to build V coordinates. We can see from this figure that HECTOR provides the lowest overhead within the protocols that guarantee delivery. We can see that the node degree and the number of landmarks have a limited impact on the performances of each protocol since the figure shows the energy overhead once a path has been found. Since the environment is homogeneous, the impact of these parameters is thus negligible on the path features. Figure 5 shows the same results in a topology with a hole, still when VCost succeeds. Here we can also see that the performances of HECTOR are the best within the protocols that guarantee delivery.

As expected, for each case, HECTOR provides a greater overhead than VCost. This is due to the routing process in HECTOR that tries to provide a progress in the tree at any step. Therefore, the tree root position is important for minimizing the energy consumption for a given source and destination, but it is not possible to have an optimal tree root position for all possible source-destination pairs.

Nevertheless, as Figure 6(a) shows, the success rate of VCost is far from 100% and is not the same following the different scenarios. We can note that the more VCost succeeds, the more HECTOR is energy-efficient and sticks to VCost performances. This is because, in Algorithm 1, the V coordinates are chosen uppermost. On the other hand, the less VCost succeeds, the more HECTOR sticks to LTP performance. If VCost fails, that means that there is no path following V coordinates and thus HECTOR algorithm follows T labels to ensure packet delivery, as in LTP. This is also confirmed by results displayed by Figure 6(b) which are the percentage of times HECTOR progresses over V coordinates rather than only on T labels. This is correlated with the success rate of VCost which only follows V coordinates.

Note that an exception occurs for low densities of HECTOR with 3 landmarks. This is due to, by construction and because of the low densities, the path followed by VCost can be far from the label root, which forces HECTOR not to follow the VCost coordinates but the LTP labels. This is less the case in topologies with holes because VCost coordinates also bypass the hole, which make the path followed by VCost closer to the root. This explains this phenomenon. We integrated this explanation in the revised version.

Energy consumption overhead when VCost fails. When VCost fails, HECTOR has to follow T labels to reach the destination. This feature is one of the main contributions of HECTOR and cannot be observed in Figures 4 and 5 since the latter ones show results for simulation runs where VCost succeeds. Therefore, Figures 7 and 8 draw the results of HECTOR, HECTOR’ and LTP for every simulation run, about paths on which VCost fails.

In Figures 7 and 8, HECTOR is the algorithm that provides the best performances regarding energy consumption, followed by HECTOR’. LTP, once again, is the least performing algorithm. Moreover, as expected, we can note that the global behavior of HECTOR and HECTOR’ is the same as LTP’s. As already mentioned, this is because, when there is no progress over V coordinates, HECTOR and HECTOR’ follow the T labels, as LTP, and so on till reaching a node which can provide a progress regarding V coordinates.

Hop length. Figure 9 shows the mean hop length along the routing path for every algorithm. The optimal hop length (based on energy consumption) is plotted as a reference. Results are similar for other choices of the number of landmarks and the topology. We can notice that VCost and HECTOR follow edges whose lengths are close to the optimal one [17] in every case. The mean hop length is greater than the optimal one with HECTOR because the choice of the next hop is conditioned by the progress made over T labels, which leads to greater hop length because of tree construction. Indeed, because of the labeling process, close nodes are mainly at the same level in the tree and thus the progress they provide is null. Therefore, since nodes try to minimize the cost over progress ratio, they generally try to maximize the progress, thus reaching farther nodes.

Path Length. Figure 10 draws the path length in number of hops when VCost succeeds. We can notice that VCost is the algorithm that provides the shortest paths. This is because it is the only algorithm to select the next hop in the forwarding direction at each hop. LTP is the one achieving the longest paths since it follows the path in the tree, sometimes with shortcuts between branches but which is rarely the shortest path. The tree construction affects the mean hop length of LTP. The impact of having an energy efficient tree or a tree with optimized range is left to future works. As already mentioned, HECTOR tries to stick to VCost when it is possible. HECTOR’ acts as VCost but since it is not energy-aware, HECTOR’ takes long edges and thus gets shorter paths than HECTOR. Note that in the worst cases when HECTOR can never provide a progress over V coordinates and that there is only one candidate that provides a progress over T labels, it also follows the tree. In this latter case, the path length provided by HECTOR is longer than the one achieved by LTP since they both follow more or less the same route, but LTP takes longer edges and HECTOR tries to fit the optimal range.

When VCost fails, HECTOR and HECTOR’ make decision based on T labels only, and thus HECTOR and HECTOR’ stick to LTP. Thereby, HECTOR provides longer paths than LTP and HECTOR’, which are not energy aware and take long links while HECTOR favors edges less energy-costly. This behavior is highlighted in Figure 11, which shows the path length in number of hops when VCost fails.

Another interesting feature to point out is that globally, HECTOR provides longer paths than HECTOR’ and VCost while it spends less energy. This also shows that HECTOR distributes the energy spending over the nodes on the paths.

Path shapes. Figure 12 shows example of the paths followed by each protocol in a network with a crescent hole. Five landmarks are randomly chosen and the tree root is the red/black node in the middle of the network. Source and destination are also randomly chosen. These schemes clearly show the behavior of each algorithm.

We can see in Figure 12 that VCost and HECTOR follow exactly the same path. This means that every hop provides a progress on both V and T coordinates. It is nevertheless worth noting that this would not appear in the general case. Indeed, for HECTOR to follow exactly the same path that VCost, a progress has to be made at each step on both sets of coordinates. Even if a progress is made on V coordinates by a node u, to be chosen, this node u has to also provide a progress on T labels, which is strongly related to the tree root, the source and the destination position. In the contrary, HECTOR’ does not try to minimize the COP and thus the first hop is different from that in VCost and directs it toward the hole. From it, in order to provide a progress regarding T labels and avoiding the dead end, HECTOR’ has to follow the path in the tree, as in LTP. The path followed by LTP goes trough the tree root which, in this particular case, increases the path length.

In Figure 13, the same simulation is run with different source and destination pairs. The tree root is also modified. We can see from this figure that the path followed by VCost falls into a dead end after the second hop. One may think that when VCost fails, HECTOR follows the path of LTP. We can see in Figure 13(d) that HECTOR first follows the V coordinates and then avoids the dead end encountered by VCost by using both T and V coordinates. This example shows how the combination of both T and V coordinates can guarantee delivery and optimize the path length. Once again, LTP follows the complete path in the tree and provides a very long path.

It is worth noting that the landmarks and the tree root positions have a great impact on the routing process. In VCost, landmarks position may affect the success rate. In LTP, the tree root position may increase the path length, and in HECTOR, the path may be different depending on these positions.

Till now, we have evaluated HECTOR by comparing it to other existing algorithms by running them in a restricted area and by making the node density grow. In this section, we fix the node density to δ = 15 and the maximum node range radius to R_max = 200 and expand the network area size.

Indeed, in such a scenario, the energy consumption will necessary grow since nodes may be further one from the others and more hops are needed to connect them than in previous scenarios. This section allows us to check the scalability of HECTOR (in terms of growing area rather than increasing node density) in very large networks by being sure that we still ensure a low ECO.

Figure 14 draws the ECO of the routes taken by each algorithm when the network size grows, for 5 landmarks. The results are similar for 3 landmarks. The abscissa axis plots the factor by which the network size has been multiplied. We only plot results where VCost fails since these runs represent the most energy costly results and the longest paths, as seen in previous sections.

One can notice that for homogeneous networks, even if the network grows as well as the route length, the energy overhead compared with the optimal shortest path consumed by HECTOR grows slowly with the network size. This is because HECTOR can follow V coordinates, and thus can have an energy consumption close to the optimal. Therefore, the energy consumed by paths followed by each algorithm is within a constant factor of the optimum. Also note that for distributions with a hole, the energy overhead tends to increase with the network size. This is due to the fact that the bigger the network (and longer the routes), the more likely greedy routing encounters a dead end and thus HECTOR has to follow the T labels and the tree, which gives longer paths and thus consumes more energy.

We now measure the benefit of using multiple trees for HECTOR as described in Section 5. Indeed, paths is tress should be shortened but in return, this means that there are several trees to maintain and there is a cost. To do so, we compare the energy consumption of paths found by HECTOR with different numbers of trees, both when VCost succeeds and when it fails. Tree roots are spread randomly in the network. Results are displayed in Figure 15.

We can notice that globally, the energy consumption is lower when VCost succeeds. This is still because HECTOR is more likely to follow the VCost coordinates. What is interesting to notice is that in both cases, using two trees instead of one allows the great enhancement of the energy consumption while using more than two trees does not bring a lot, since energy consumed by HECTOR is globally the same whatever the number of trees. When the network is sparse, it can be worth using a third tree but this is only for some low density scenarios.

This means that two trees are enough to find appropriate paths by switching from one tree to another one. This is confirmed by results shown in Figure 16 that displays the path length of each variant. Path length is similar for every variant that has two trees or more. These figures show that there is no need to build more than 4 trees since the energy saved is negligible. This is due to the fact that 4 trees are enough to find a direct way in the graph.