## 3 Routing for Data Centric Storage
### Rendezvous Regions  
This work [20] uses geographic regions as rendezvous areas for producers and consumers. The authors claim that sending messages towards geographic regions instead of geographic points, relax the requirements for location accuracy. In this case an event type is mapped into a region identifier.  
The network is divided in rectangular regions where each region could be responsible of one or more event types. The size of a region is several hops, although the exact value is not specified. Each region is assigned with an identifier. Then, each event type is mapped to a region. Finally, each region chooses locally the home node as well as the local replicas.  
The authors define 3 different forwarding mechanisms:  
* _Unicast_: Direct messages to a given node. This could be used when the location of a rendezvous node is well-known.
* _Geocast_: Sending the message to all nodes in a geographical region. It is useful to send a message to several nodes inside a region (in this case the local replication nodes within that region), however it incurs in an important overhead. The authors propose to use it just for production events.
* _Anycast_: It is enough with reaching one of a set of nodes (one of the local replication nodes). The authors propose to use this forwarding mechanisms for consumption queries.  
It is assumed that the nodes are able to detect in which region they are located. In addition, they know how the regions are distributed within the sensornet, that is the region location and its identifier.  
Local replicas are elected on-demand. When a production event message reaches the first node in the targeted rendezvous region, this node (known as flooder) geocasts the message inside the region. Each local replica receiving the message sends back an ACK to the flooder. If the ACKs number is not enough (_i.e._, the number of local replicas is lower than the minimum number established) the flooder geocasts again the message including a self-election probability p. Then, each node that receives the geocast message elects itself as replication node with a probability \(p\). This process keeps working until the minimum number of replicas is reached or \(p\) becomes 1.  
When a producer generates an event, it computes the target region and includes its ID within the message. The nodes in the path forward the message towards that region. Once the message reaches the flooder, it geocasts it and receives one (or more) ACKs, that are notified to the producer. If after a given time the producer did not receive any ACK it sends the message again.  
This mechanism works similarly for the consumer queries. However, when the query reaches the flooder it uses anycast since it has previously cached all the replication nodes' location. The selected replica replies to the flooder and the flooder to the consumer.  
The authors claim that this work performs better in mobile scenarios than the original GHT. Moreover, the main advantage of this protocol compared to GPSR is that nodes need to know in which region they are located but not its exact position, thus avoiding the necessity of using GPS or any other location device or costly protocol in order to provide each node with its coordinates within the sensor field. On the other hand, the paper neither discuss the size of the area nor how the identifiers should be assigned to each area or how a particular sensor knows which its area identifier is. All these assumptions are key issues in order to practically deploy this routing proposal.