Multi-Hop Zone Sharing (MHZS)

The main idea of the MHZS scheme is to relax the strict single hop sharing assumption adopted in the SHZS scheme. Based on this relaxation, we introduce another ZS version

where a zone can be shared more than once. This implies that a given zone can encounter a tree depth change, as well as a tree path change, of any size. To see how this can occur, consider a network with two main subtrees, 0x and 1y, where x and y are zone bit-codes of different lengths. In this topology, a hotspot may arise in node N0 with address 0110, i.e., falling in the 0x subtree. To decompose this hotspot, MHZS applies the zone sharing process for 3 hops. Thus, at the end of the zone sharing process, the hotspot zone will be in a node which is 3 hops away from its original location. Among these hops, the first one is applied with node 0111 from the 0x subtree. However, the following hops are applied with nodes 100 and 101, respectively. Thus, the final location of the hotspot zone is node 101, which belongs has a different path and different path length in the k-d tree than the original node 0110.

4.1.5.1 GPSR Modifications This above description of the MHZS scheme introduces an important question, which is: how would the routing work in the resulting k-d tree? In the original k-d tree of the DIM scheme, routing worked in a systematic hop-by-hop purely localized manner without any need for keeping immediate information of the node actually responsible for storing each zone as the convergence to that node at the end of the routing process was guaranteed. However, due to the changes introduced by MHZS to the k-d tree structure, this is not the case anymore. As a zone can be moved several hops away from its original node, using the basic GPSR routing algorithm without modifying it will involve the original donor, as well as subsequent donors, in all insertions and queries concerning the shared zone. This would be an extreme overhead as it would involve the original hotspot nodes in all these operations. All insertions and queries will first go to the original hotspot node. Then, they would be forwarded to the subsequent donors, one after the other, until reaching the final node actually storing the zone. This overhead would be proportional to the number of times the zone sharing process is applied. Furthermore, this would defeat one of the purposes of applying the zone sharing process, which is reducing the energy consumption burden imposed on the hotspot nodes. Hence, GPSR must be augmented by some means to determine that a zone has been shared and moved away from its original location. We discuss the modifications that we introduce to GPSR in the following paragraphs.

Figure 6: Modified GPSR Algorithm for ZS

To implement the MHZS scheme, we assume that each node maintains a Shared Zones List (SZL) containing three entries: zone address, original donor, and final migrator. Upon zone sharing, the donor sends the shared zone address, its name, and the migrator’s name, to all its neighbors. Thus, each node will be aware of zones traded by its neighbors.

In case of multiple sharing of the same zone, the old migrator becomes the new donor.

It sends the zone address, the original donor, and the new migrator, to all of its neighbors.

Thus, it has to check its SZL first and send the entry corresponding to the zone under concern after updating the final migrator entry with the new migrator. In case a node receives a shared zone entry that is already present in its SZL, it updates its list with the new entry.

This means that a given zone has been re-shared. This update guarantees that a shared zone will have similar entries in all shared lists containing information about this shared zone.

The node then forwards the shared zone entry to its neighbors.

When routing an event (an insertion or a query), GPSR first searches the SZL with the zone address. In case an entry for such zone is found, this means that the original destination of the zone has been changed to a new one. Therefore, the destination node found in the SZL entry of the zone is used to explicitly update the destination field of the message to be routed to its new value. GPSR then uses the new destination address to forward the message using the best path to the final migrator. A flag is updated in the message to indicate that its original destination has been already changed to its current one to avoid further lookups

in subsequent nodes. Figure 6 shows the modified version of the GPSR algorithm run by each node in the network.

As all the neighbors of each donor and migrator are forwarded with the new SZL entry of the shared zone, this results in a cloud of nodes with the same SZL entry. This cloud includes the original hotspot area as well as the sensor nodes surrounding it. Applying the SZL search at each of the routing steps results in changing the routing direction of any event as soon as an SZL entry for the event zone is encountered. This usually happens when the event starts entering the cloud. Thus, the cloud deviates the direction of any event to direct it to the new destination of the required zone. This has the effect of considerably reducing the energy consumption overhead imposed on the nodes falling in the hotspot area.

It is important to mention that queries are routed exactly as they used to be routed in the original DIM scheme. Any query initiating at any of the sensor nodes, and asking for a given range over the attributes stored in the network, is processed in a hop-by-hop manner.

At each step, the query is forwarded to the next node towards its final destination in case the query can be completely answered by one node, i.e., in case the attribute range of the query is falling under responsibility of one sensor node. Otherwise, the query is split at one point into two or more queries each targeting a different node. Applying our GPSR modification results in the possibility of splitting the query at any time in case a subset of the queried zone has already been shared. On the other hand, the query is fully deviated in case the whole queried zone has been shared. Otherwise, the query processing proceeds exactly as dictated by the original DIM scheme.

4.1.5.2 Hotspot Decomposition Mechanism After describing the routing process of any insertion or query in MHZS, we now illustrate the high-level hotspot decomposition technique that applying the above MHZS would result in. Let us consider a storage hotspot arising in a group of sensor nodes. Applying MHZS results in multiple-rounds of hotspot decomposition (with each round similar to the one we described for SHZS in Section 4.1.4).

The hotspot decomposition starts from the hotspot borders and goes on towards the center of the hotspot area. However, the main difference between MHZS and SHZS is that the former will be able to scale more than the latter. In both schemes, applying the zone sharing

for the first time would result in increasing the number of nodes responsible for storing the hotspot load by involving the immediate neighbors of the border nodes in this responsibility.

However, for the next round, MHZS tends to further send the zones shared in the first round away from their original locations. This results in more room in the border nodes and their surrounding nodes. This room would be use in further dissipations of the hotspot load away from the hotspot area. This has the effect of increasing the MHZS ability in decomposing large hotspots, unlike the case with SHZS.