# DTN and Non-DTN Routing Protocols for Inter-CubeSat Communications: A comprehensive survey
## 4 DTN Routing Protocols in Disjointed Satellite Networks
### DTN Flooding-Based Techniques
\begin{table}
\begin{tabular}{l c c c c c c c c c} \hline \hline
**Methods** & **Category** & **Decision Criteria** & **Advantages** & **Limitations** & **Delivery Ratio** & **Average Delay** & **Overhead** & **Complexity*** \\ \hline MC [\(\%\)] & & Space-time graph & - & Recourse friendly & - & High-computational complexity & High-if resources unlimited & Low if resources unlimited & Medium & (O(m\({}^{\pm}\) m)) \\ \hline EBR [\(\%\)] & & History & - & Recourse friendly & - & High-deep-ratio & High-if resources unlimited & Low if resources unlimited & Low & O(t) \\ \hline DBRP [\(\%\)] & & History & - & Recourse friendly & - & High-deep-ratio & High-if resources unlimited & Low if resources unlimited & Low & O(t) \\ \hline DBRP [\(\%\)] & & History & - & Recourse friendly & - & High-deep-ratio & High-if resources unlimited & Low if resources unlimited & Low & O(t) \\ \hline ADRT [\(\%\)] & & History & - & Recourse friendly & - & High-deep-ratio & High-if resources unlimited & Low if resources unlimited & Low & O(t) \\ \hline MMBF [\(\%\)] & & Space-time graph & - & Recourse friendly & - & High-computational complexity & High-if resources unlimited & Low if resources unlimited & Low & O(m\({}^{\pm}\) m)) \\ \hline RCML [\(\%\)] & & Space-time graph & - & Recourse friendly & - & High-computational complexity & Low & 16 gb & Low & O(m\({}^{\pm}\) m)) \\ \hline Hampag et.al. [\(\%\)] & & Space-time graph & - & Recourse friendly & - & High-computational complexity & Low & 16 gb & Low & O(m\({}^{\pm}\) m)) \\ \hline Mmerge et.al. [\(\%\)] & & Space-time graph & - & Recourse friendly & - & High-computational complexity & Low & 16 gb & Low & O(m\({}^{\pm}\) m)) \\ \hline Mmerge et.al. [\(\%\)] & & Space-time graph & - & Recourse friendly & - & High-computational complexity & Low & 16 gb & Low & O(m\({}^{\pm}\) m)) \\ \hline CAR [\(\%\)] & & History & - & Recourse friendly & - & High-deep-ratio-High & & Low & O(t) \\ \hline \hline \end{tabular}  
* Where m, n and r represent the number of nodes, number of nodes without the given bundle, and number of bundle replicas respectively in the computational complexity column.  
\end{table} 
Table 4: Cont. A PROPHET routing protocol that employs probabilistic routing utilizing the history of contacts and the mobility of nodes is proposed [49]. This approach considers using the benefits of non-random mobility, which may include typical real-world scenarios, such as the periodic satellite movement. A global unique bundle ID should be assigned to all of the bundles to identify the bundles that have already been seen as well as any unnecessary re-transmissions. In the same manner as the TTL field in the IP packets, there is also a hop count field that is associated with each bundle to specify a bundle detouring threshold. The hop count is considered to be one of the most important metrics affecting protocol resources utilisation. In contrast, for networks with random probability patterns, [PERSON] and [PERSON] proposed a NECTAR protocol [53], which is a history-based routing technique that uses the previous contacts with neighbouring nodes and stores this information as a neighbourhood index. The neighbourhood index is determined based on a distance measure, which is the number of hops and the ageing measure that specifies the number of time slots where two nodes are out of the communication range. In the encounter time, the nodes will exchange the neighbouring information and choose the node that had the previous contact with the destination, as it may have a quicker likelihood of future contact. While NECTAR does not require any prior global knowledge regarding the topology, all of the nodes cache current neighbouring contacts to minimize resources harvesting, where a discarding policy is introduced due to the assumption of limited storage availability. Each node has two counters: one to count the number of received bundles and another to count the elapsed time for each bundle since its arrival.