## 7 Simulations and Discussion  
This paper aims to improve the OLSR protocol control plane by building a secure topology database. Indeed, the topology database is the main pillar of each routing process.  
Thus, in order to test the performance of the proposed solution, simulations were conducted using the network simulator NS2 with a modified version of the UM-OLSR implementation. For simulation purposes, we kept all the default values for the OLSR parameters as presented in the Table 1.  
As illustrated in Figure 13, this set of simulations involves a network comprising 10 nodes with a transmission range of 250 m in an area of 1500 \(\times\) 1500 mm\({}^{2}\). For perfor  
\begin{table}
\begin{tabular}{c c} \hline
**Parameter** & **Description** \\ \hline Simulator & NS2 \\ \hline TC interval & 5 \\ \hline HELLO interval & 2 \\ \hline Refresh Timeout Interval & 2 \\ \hline Neighbor hold time & 6 \\ \hline Topology hold time & 15 \\ \hline Duplicate hold time & 30 \\ \hline Traffic type & UDP \\ \hline \end{tabular}
\end{table}
Table 1: Simulation Parameters.  
Figure 12: Topology changes after round 2.  
mance evaluation, UDP traffic is sent by nodes located at the extreme boundaries of the network.  
NS2 allows consultation of the routing table of each network node. Indeed, this table contains the fields \"dest,\" \"next,\" \"Iface,\" and \"dist.\" The meaning of each field can be presented as follows:  
* dest: Determines the destination node of the packet.
* next: Identifies the next hop to which the packet will be forwarded.
* Iface: Identifies the local interface leading to the next hop.
* dist: Determines the cost associated with the transfer via \"Iface\".
* Two scenarios were considered. Scenario 1 simulates a standard protocol without malicious nodes. Using the OLSR protocol, each node builds its own routing table. Node_(1) has a UDP traffic session with node_(9) that has a distance of 2, as shown in Figure 14. Thus, it needs an MPR node in order to forward its data.  
To verify the result of the MPR selection algorithm's execution, we can refer to the MPR table of Node_(1) and check the content of the MPR Set column. Indeed, this column displays the list of MPR nodes selected by a node to serve as its MPRs. In our case, Node_(1) selected Nodes_(3) and Node_(6) as its MPRs (see Figure 15).  
Figure 14: Scenario 1: Node_(1) routing table.  
Figure 13: Simulation topology.  
The second scenario simulates our proposed approach based on the Byzantine fault in the OLSR Protocol and evaluates its performance in the case of the presence of malicious nodes. It consists of introducing node_(5) as a malicious node. This node will promote an irregular number of neighbors or will increase its willingness to be elected as an MPR by node_(1).  
As a result of node_(5) behavior, the traffic will be routed through node_(5) instead of node_(6) as confirmed by the verification of the node_(1) routing and MPR tables presented in Figures 15-17. This constitutes a serious vulnerability whose impact is undoubtedly major on the security of the OLSR protocol and, consequently, of the entire MANET infrastructure.  
In order to evaluate the impact of the default MPR selection algorithm on the data plane, we have conducted a series of performance evaluation simulations. These simulations aim to assess the initial OLSR version and our proposed one. This assessment is based on the measurement of the average Packet Delivery Ratio (PDR) and the packet drop percentage.