## 2 Background and Related Work
### Black-Hole Solutions in DT-IoV
Table 1 summarizes the main characteristics of the described mechanisms. More comprehensive surveys of solutions to black-hole or other attacks in similar situations may be found in [19; 20]. For VANETs, a survey is available in [21]. Most solutions for VANETs assume a centralized authority or cloud server that is always available, generally unconstrained in terms of communication, computation, and storage, which cannot be compromised [22], and thus does not apply to a delay-tolerant scenario that requires a completely distributed solution. The main motivation to try to solve the problem of black-hole nodes was the fact that most effective protocols use a reputation value as a base for judgment, the dependency of other nodes for information, and the fact that to classify a node in most reputation schemes, there must be an encounter, not allowing for a good network awareness. A wrong reputation value is problematic in the case you want to punish nodes for malicious behavior. Nodes, good or bad, might be in a limbo of classification before reaching a certain threshold. Furthermore, the possibility that good nodes might have to be continually proving they are good may slow down message exchanges. The dependency on other nodes' information is a clear drawback when analyzing scenarios with black-holes, having to meet a node before being able to classify it is a drawback. In that way, a node will never be able to identify all the existing malicious nodes in a large scenario. Having these primary three factors in mind, an attempt was made to try to create a reputation system \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Scheme** & **Information Used** & **Detection** & **Action** & **Limitations** \\ \hline FBIDM [10] & past meetings, past delivery probability & suspicious multiple times & exclude black-holes & requires ferry nodes \\ \hline MUTON [13] & past meetings, past delivery probability, transitivity & suspicious multiple times & exclude black-holes & requires ferry nodes \\ \hline MDS [14] & encounter records & forwards less than a threshold & exclude black-holes & no exchange of trust information \\ \hline MDS extension [15] & encounter records, cluster analysis & forwards less than a threshold & exclude black-holes & no exchange of trust information \\ \hline Packet Exchange Recordings [16] & delivery records & forwards less than a threshold multiple times & none described & no exchange of trust information \\ \hline RCAR [17] & messages carry forwarders, ACK messages & aging decreases reputation & prefer nodes with a higher reputation & no exchange of trust information, requires ACK \\ \hline CWS [18] & messages delivered, delayed, dropped & exchange of reputation, thresholds & few resources used for nodes with low reputation & does not assess classification performance \\ \hline BiRep & messages carry forwarders & exchange of reputation, node has no forwarding record & warmup, disconnect from black-holes, delete messages from black-holes & \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Delay-tolerant networking (DTN) black-hole (BH) detection and mitigation schemes-related work. that corrects these drawbacks and also achieves a high black-hole node detection ratio and a 0% false-positive ratio.