## 7 Classification of Mobile Sink based Data Collection Schemes
### Path Unconstrained Sink Mobility-Based Schemes
However, using the first broadcast if the source node fails to receive a response, itwaits for a while in the hope to find any nearest sink. At the expiry of that waiting time, it increases the zone's size for broadcasting the route discovery request. This procedure is repeated for some maximum number of retries, failure to which results into a network wide broadcast for route discovery. This scheme restricts the propagation of sink presence to a confined zone for achieving energy conservation, thereby avoiding network wide propagation. However nodes outside the confined zone have to find a route to the sink via the broadcast mechanism. Thus, during the sink discovery process, several broadcasts might need to be required depending on the position of the requesting node within the network. This will result into high energy consumption and collisions. Furthermore; using this approach, data delivery latency would also be more as a major part of the network has to establish routea to the sink first via the broadcast mechanism. [PERSON] _et al._ proposed an energy efficient data gathering algorithm for cluster-based mWSNs [36]. Initially, it partitions the whole network into partially overlapped clusters and classifies the nodes as Cluster-Heads (CHs) and Cluster-Members (CMs). CHs collect data from their CMs according to some MAC schedule. For uploading the collected data to the mobile sink, first the CH checks whether the mobile sink is accessible within its default radio coverage range. However, if the sink is not reachable with the default radio configuration, the CH increases its transmission power in the hope to get to the sink as shown in Figure 8. This process continues until the CH finds the mobile sink in its new coverage area. At that point, the mobile sink comes to a stationary state until it receives all the transmitted data from that CH. This scheme simply replaces the multi-hop communication with a single long range communication irrespective of the constrained resources (limited energy reserve, short range radio) of the sensor nodes. The long range radio communication may also disrupt communication in other clusters thereby causing collisions followed by retransmissions which gives rise to more energy consumption and delays for the disrupted nodes. Moreover, it also does not incorporate sink mobility patterns and leaves this to the application's designer. Integrated Location Service and Routing (ILSR) scheme is proposed in [37] that is based on geographic routing protocol and aims to ensure guaranteed packet delivery to a mobile sink. It assumes  
Figure 8: **(a)** Network Topology with default radio settings; **(b)** Network Topology after radio adjustment. that all the nodes, including the sink, are aware of their location information. Furthermore, neighbor nodes also exchange their location information via _hello_ messages. The mobile sink initially floods the network (once) with its location information and throughout the process remains connected via at least one node from that network. The sink moves slowly such that neighborhood change is detectable. To incorporate sink mobility, ILSR enhances the popular Geographical Forwarding Graph (GFG) routing protocol proposed in [38] which provides guaranteed delivery in static networks. ILSR enhances GFG with two types of location updates, namely _flooding-type_ and _routing-type_. _Flooding-type_ location updates target only the area near the sink in which the nodes detect some change in the next-hop node route towards the sink. Similarly, the _routing-type_ location update targets the lost neighbors of the mobile sink to prevent routing failures in the network. Both these location update messages are time-stamped via a monotonically increasing sequence number for maintaining freshness. Furthermore, two versions of ILSR are proposed to deal with both unpredictable and predictable sink mobility. ILSR achieves guaranteed data delivery to the mobile sink via the two types of location update messages.