# Optimization of the AODV-Based Packet Forwarding Mechanism for BLE Mesh Networks
## 4 Optimized-AODV Protocol Topologies and Testbed Design
### Experimental Result Findings  
In the light of the above-mentioned protocol optimizations, we were able to obtain lower end-to-end delay and much lower overheads in comparison to mesh and the existing AODV protocol, as depicted in Figures 8, 10, 17, 18, 24 and 25 respectively. In addition, the proposed protocol exhibited practically lower route requests and route reply setup time in comparison with AODV, as shown in Figures 11, 16 and 23. In addition, the proposed protocol performed well in terms of efficiency by giving a better PDR than the AODV protocol for all three topology formats, as illustrated in Figures 12, 19 and 26. Furthermore, it demonstrated that the traffic load for routing-based protocols was less than that for the mesh-based protocols, as shown in Figures 13-15 and 20-22.  
ison with AODV and flooding-based mesh. In addition, O-AODV also showed a much better RREQ-RREP setup time in comparison with AODV. From the overhead data shown in all three scenarios, directed forwarding used by the routing protocols such as AODV and O-AODV was preferred over the flooding-based forwarding used in the BLE mesh standard since the high transmission overheads of up to 83% for flooding-based mesh would significantly reduce the operating lifetimes of battery-equipped sensor nodes. The scalability of the O-AODV protocol with respect to the number of hops was evident from Scenario 1. Since average end-to-end delay increases with the number of hops, the average per-hop delay metric is useful for comparing the performance of all three protocols. In general, O-AODV achieved from 8% to over 20% lower average per-hop delay compared to the other protocols. In addition, O-AODV exhibited almost negligible overheads for up to seven hops, whereas AODV incurred up to a 25% overhead in comparison. Moreover, there was a slight increase in the overheads of eight and nine hops where traffic from multiple sources competed for the bottleneck link towards the sink, resulting in retransmissions, which allowing us to conclude that the optimum size of the multihop topology was seven hops or less. Furthermore, O-AODV incurred a lower RREP-RREQ setup time in comparison to AODV. The lower average one-way delays and lower overheads for O-AODV contributed more significantly to the mesh topologies used in Scenarios 2 and 3. Since there were multiple possible paths between the source and sink, the number of duplicated forwarded packets in the flooding-based mesh protocol contributed significantly to the average end-to-end delay, requiring 6500 ms for the two-hop full mesh in Scenario 2 and 7500 ms for the four-hop partial mesh in Scenario 3. The increase was not linear with the number of hops due to the random nature of the flooding process in the mesh topology. In contrast, O-AODV achieved 4000 ms for the two-hop Scenario 2 and 5500 ms for the four-hop Scenario 3, which was lower than AODV with 4500 ms and 6000 ms in Scenario 2 and 3, respectively. Subsequently, the average one-way delay for the mesh topology scenarios increased significantly as the number of hops through the network increased. The values in Figures 8, 17 and 24 clearly illustrate that the trend of end-to-end latency increased with the increasing number of nodes in the network. According to the mesh topology architecture, an increase in the number of full function nodes offering multihop routes led to significant network delay. Furthermore, with mesh, a greater number of full function nodes were involved in the mesh architecture, resulting in higher overall energy consumption. The lower RREQ-RREP setup time for O-AODV in comparison to AODV was also significant. As the number of hops between the source and sink and the number of alternate paths within the mesh topology increased, the difference in the RREQ-RREP setup time of up to 1000 ms between O-AODV and AODV, as shown in Scenarios 2 and 3, would lead to much better responsiveness in terms of the networking joining time needed by new sensor nodes before they can start sending data to the sink.