# An Optimized Load Balancing Using Firefly Algorithm in Flying Ad-Hoc Network
## 4 Results and Discussion  
Simulations have been run to evaluate the performance of the proposed scheme. Because standard FANET simulator tools have limitations, realistic mobility models are very useful in designing and implementing routing protocol performance. To reflect the effects of a routing protocol based on environmental variables, a flying mobility model should be proactively easily adjustable. The results are validated using the NS2 simulator as a network simulator and the chrgen utility to generate traffic files. Seldest is a program in the NS2 simulator that has an average pause of 2 s between node movements. The simulation is terminated after 200 s, and the topology perimeter is defined as 500 \(\times\) 500. In this paper, we use the NS2 simulator to pretend the network scenario. NS-2 packages are made up of the following components:  
* geo utility.h contains geometrical utility functions such as the projection of a 3D graph to a 2D graph and the communications network between two flying nodes;
* geo pkt.h contains the new geo packet header definition;
* geo node.h and geo node.cc files define and implement the geographic node;
* geo.h and geo.cc files contain the definition and implementation of the geographic agent prototype;
* the proposed algorithms are defined and implemented in geo next node.h and geo next node.cc. In the beginning phase, flying nodes are dispersed arbitrarily, the altitude of UAVs is 40 m, and the directional gain is 10 dBi with a frequency range of 2.4 GHz. The value of the transmission power is 0.005 W for each session is set to the speed of the UAVs, which varies up to 60 m/s. In addition, we use the queue type as the priority queue to simulate a wireless physical medium channel and further to estimate the link quality of the nodes. The detailed definitions of simulation parameters can be found in Table 3. The goal of this study is to regulate the congestion level of the entire network by satisfying various characteristics of flying nodes. The network is initialized with the help of multiple flying nodes with the altitude of UAVs at 70 m. The transmission power is constrained by the connectivity between terrestrial base stations and UAVs. To prevent these, UAVs can communicate with one another using purely ad hoc architecture. In Figure 1, the initialization of the flying nodes is defined. The syntax for defining a node is set as n0 ($ns node). We created a node that is \begin{table}
\begin{tabular}{l l} \hline \hline
**Parameter Type** & **Value** \\ \hline Number of UAVs & 100 \\ \hline Queue Type & Priority queue \\ \hline Altitude of UAVs & 70 m \\ \hline Traffic Type & CBR \\ \hline Directional Gain & 10 dBi \\ \hline Frequency & 2.4 GHz \\ \hline Wireless Medium & Wireless physical medium \\ \hline Data Rates & 54 Mbps \\ \hline Packet Interval (s) & Exponential (1) \\ \hline Routing Protocol & GPMOR \\ \hline Packet Size (byte) & 1024 \\ \hline Fuel (kg) & 80 \\ \hline Simulation Time & 200 s \\ \hline Pause Time & Variable \\ \hline Antenna Type & Omni-Directional \\ \hline Transmission Power & 0.005 W \\ \hline Speed of UAVs & Can vary up to 60 m/s \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Dimensions of UAVs in the network. represented as node 0 by the variable n0. When we refer to that node in the code, we will use $n0. After we have defined a few nodes, we can define the links that connect them, and so on. In ns2, a node's output queue is implemented as a component of each link whose input is that node. The definition of the link then includes a method for dealing with queue overflow. Figure 2 depicts the specific source and destination nodes as defined by RoadSide Units (RSU). Furthermore, we need to connect the traffic source to the traffic sink. This maintains the RSU's proper infrastructure for sending route packets to flying nodes. It manages traffic signals; the RSU is intended for use at road intersections and serves as a resource for information.