## 3 The Proposed Protocol
### MA Path Planning  
MAs go on data collection journeys from the sink to LDSs residing on the tree. MA migration is similar to ZMA, in which MAs move through each data zone to visit sensory data stations [4]. However, MINDS is a top-bottom MA route planning as compared to ZMA, which is bottom-up. Moreover, MINDS utilises a hop-count-aware DFS algorithm to select the paths, whereas ZMA works according to a particular weight function of connectivity degree and residual energy level to reactively establish the routes.  
MINDS forms a data-centric tree path which forwards MAs to only LDSs whose data records match the query. That way, MAs avoid random walking that consequently results in reduced MA power consumption. Hence, this offers great benefits to hardware MA applications that usually are equipped with restricted power resources. Each MA is allocated to stack memory, called _re_visiting_, which works according to last-in-first-out data retrieval. This is used to keep the address of _joint_points_ to visit tree branches as next move, yet MAs record their own itinerary to avoid loops and visiting overlapping areas.  
Algorithm 4 illustrates MINDS which forwards MAs to collect sensory data samples. According to this, each sub-tree is allocated to an MA to move from the sink. An MA visits LDSs residing on the allocated tree one-by-one until a _joint_point_ is visited. Then, this updates its own _re_visiting_ by the region address of the _joint_point_. This address is used to change the direction and collect data records from the non-visiting LDSs which are interconnected to the _joint_point_. Indeed, an MA returns to _joint_point_ and visits other non-visiting branches when an LDS with no next-hop link is visited. A hop-count-aware DFS algorithm is used to select the next direction at each _joint_point_. According to this, a LDS with minimum _hop_count_ is selected as the next visiting LDS and other ones are left as non-visiting until next move. An MA removes a _joint_point_ from _re_visiting_ when all the tree branches are visited. This is repeated until _re_visiting_ becomes empty with no next-hop link to visit. The MA eventually reruns to the sink to deliver the results. Figure 2 depicts the MA route planning approach. However, a UAV might return to the sink in the middle of a journey if the power resources are running out. For this, the address of the last visited LDS is recorded for a return later. The MA resumes its journey from the last visited LDS when it is fully re-charged.  
Figure 2: MA route planning diagram.  
```
Data: Routing Tables (RT);  MA(ID, Data, Code, Itinerary);  Next LDS(NLDS); Last visited (LV); /*MA starts to move.*/  Move \(\leftarrow\) true; while(Move == true)do /*Run-out power.*/ ifMA,power \(\leq\) thresholdthen  Move \(\leftarrow\) false;  LV \(\leftarrow\) LDSID;  MA.itinerary(sink);  end if /*Resume a move.*/ else ifLV \(\
eq\) Nullthen  MA.itinerary(LV);  LV \(\leftarrow\) Null;  Move \(\leftarrow\) true;  end if else /*Multiple branches.*/ ifjoint,flag == truethen ifLDSID == sinkthen /*MA allocation at sink.*/ whileRTLDS \(\
eq\) Nulldo  NLDS \(\leftarrow\) RTLDS.top();  RTLDS.remove();  MA.ID().itinerary(NLDS);  i++;  end if  end if else /*Hop-count DFS.*/  MA.re-visiting() \(\leftarrow\) LDSID;  sort.RT.min(HC);  NLDS \(\leftarrow\) RT.top0;  NLDS.MA \(\leftarrow\) MA.ID;  MA.itinerary(NLDS);  end if  end if /*single route is available.*/ else ifRTLDS.count() == 1 then  NLDS \(\leftarrow\) RT.top();  MA.itinerary(NLDS);  end if /*Preparing the return path.*/ else  NLDS \(\leftarrow\) MA.re-visiting(); /*To re.visiting is left.*/ ifNLDS == Nullthen  MA.itinerary(sink);  Move \(\leftarrow\) false;  end if /*A re.visiting is found.*/ else  re-visiting.remove(NLDS);  MA.itinerary(NLDS);  end if  end if  end while  end while
```  
**Algorithm 4** UAV migration algorithm.