Optimization of the AODV-Based Packet Forwarding Mechanism for BLE Mesh Networks

The standard Bluetooth Low-Energy mesh networks assume the use of flooding for multihop communications. The flooding approach causes network overheads and delays due to continuous message broadcasting in the absence of a routing mechanism. Among the routing protocols, AODV is one of the most popular and robust routing protocol for wireless ad hoc networks. In this paper, we optimized the AODV protocol for Bluetooth Low-Energy communication to make it more efficient in comparison to the mesh protocol. With the proposed protocol (Optimized AODV (O-AODV)), we were able to achieve lower overheads, end-to-end delay, and average per-hop one-way delay in comparison to the BLE mesh (flooding) protocol and AODV protocol for all three scenarios (linear topology with ten nodes, multipath topology with six and ten nodes). In addition, the proposed protocol exhibited practically constant route requests and route reply setup times. Furthermore, the proposed protocol demonstrated a better Packet Delivery Ratio (PDR) for O-AODV (84%) in comparison to AODV (71%), but lower than the PDR of the mesh (flooding) protocol with 93%.


Introduction
Bluetooth Low-Energy (BLE) is a Wireless Ad Hoc Network (WAHN) technology that is becoming increasingly popular among IoT devices that run on batteries. The Bluetooth Special Interest Group (SIG) introduced the BLE standard in Bluetooth Version 4.0, which was further improved in Bluetooth Versions 4.2 and 5 [1]. For multihop communications and network connections, BLE 4.x initially used the traditional Bluetooth-based Personal Area Network (PAN) paradigm. BLE 5 aims to address these flaws by implementing a flooding-based mesh architecture, which will enable better coverage of the network, standardized intercluster communications, and improved security [2]. The model, foundation model, and access, upper/lower transport, network, and bearer layers make up the BLE mesh system architecture, which sits on top of the BLE network stack [3].
Despite its many features, the BLE mesh protocol assumes the use of flooding for multihop communications. The flooding approach results in network overheads and delays due to continuous message broadcasting in the absence of a proper routing mechanism.
Aside from the flooding-based protocol, numerous common routing protocols for wireless ad hoc networks exist, such as AODV [4], DSR [5], and others. AODV has been used in a wide range of applications and scenarios, demonstrating its dependability and robustness.
For this paper, we considered a multihop mesh with a flat/nonhierarchical topology as a usage scenario and proposed a O-AODV protocol for BLE by replacing the network layer protocol in the BLE mesh architecture to improve communication efficiency and reliability over the current AODV and mesh protocols. The objectives of this research were

BLE Mesh Architecture and Message Routing Protocols
To improve the readability of the paper, it is necessary to discuss the background material in the following sections, such as the BLE mesh architecture and the available mesh routing protocols, before delving into the details of the proposed protocol.

BLE Mesh Architecture
To describe various words and concepts used throughout the paper, a quick introduction to the BLE mesh layers is presented and shown in Figure 1: • Model layer: Models define operations based on use cases in the model layer. The Bluetooth mesh model specification or vendors specify these models. The models are identifiable by Bluetooth SIG and vendor-defined unique identifiers of 16 and 32 bit; • Foundation layer: The states, messages, and models are defined in this layer that are needed to setup and maintain mesh networks in different contexts. The configuration client and server model and the health client and server model are the two types of models specified in the Bluetooth SIG specification; • Access layer: The access layer specifies how the upper transport layer can be used by the upper layers. It is also responsible for defining the app's data structure and implementing encryption/decryption operations. Finally, before passing data to the upper layers, it ensures that the network and application keys in the incoming data are correct; • Upper transport layer: This layer is in charge of application data encryption, decryption, and authentication, as well as keeping the secrecy of access messages. It also specifies the control messages that are used to coordinate the transport layer functions between nodes; • Lower transport layer: This layer specifies how messages in the top layers are segmented and reassembled in the lower-layer protocol into units of data. It is also in charge of controlling segmentation and reassembly; • Network layer: Data transfer addressing, formatting, encryption, and authentication are all handled by the network layer. This layer is also in charge of handling message forwarding and dropping decisions. The BLE mesh network layer, on the other hand, lacks a routing mechanism and relies on a flooding-based approach; • Bearer layer: The message transmission mechanism is defined by the bearer layer. In the newest BLE 5 mesh requirements, there are two types of bearers available: advertising bearer and GATT bearer; • Bluetooth core specifications: The Bluetooth core specifications' network stack supports the physical data transfer between the nodes/devices with the help of a layering architecture. The host, controller, and physical/radio layers are the three fundamental layers of the BLE network stack. The host layer, which sits just beneath the application layer, has many nonreal-time network and transport protocols that allow apps on different devices to communicate with one another.

Message Routing Protocols
The BLE mesh protocol relies on the flooding approach that causes network overheads and delays because of continuous broadcasting. Therefore, this section gives a brief overview of three popular routing-based messaging paradigms adopted by different multihop transmission protocols to enable readers to better understand the implementation of the proposed O-AODV protocol: • Reactive (on-demand) protocols Messages received by the reactive forwarding protocol provide information about the destination nodes. Every transmission table entry is only active for a limited amount of time. The item will be erased if no traffic is encountered for a certain destination within the specified time frame. A process for new route discovery will be launched upon receiving the request from the sender node. Examples of such protocols include ad hoc AODV [4] and Dynamic Source control Routing (DSR) [5]; • Proactive (table driven) protocols  For all nodes, whether active or not, explicit forwarding table entries are maintained by proactive forwarding protocols. The Bellman-Ford algorithm is used to keep feasible pathways to important nodes, allowing data to be delivered to the destination as soon as possible. The examples of this kind of protocol include: Babel, Optimized Link State Routing (OLSR) [10], Destination Sequenced Distance Vector (DSDV) [11], and others; • Cluster-based protocols Scatternet is a kind of cluster-based transmission protocol in BLE 4.1 to support multihop communications. The network nodes are divided into multiple overlapping disjoint clusters [12]. Each cluster is led by the cluster head, who maintains memberships in a cluster and is then utilized to find the path that connects the clusters. The clustering of nodes decreases the flood during the path discovery procedure. In addition, the protocol monitors any single directional links for transmission between clusters and intracluster. Protocols of this type include the Two-Tier Data Dissemination Protocol (TTDD) [13], ring routing [14], Energy-Efficient Secured Ring Routing (E2SR2) [15], and others.
In a BLE mesh network with identical battery-operated nodes, a flat topology would provide the most flexibility to support multihop communications among the nodes. Reactive protocols such as AODV compute routes on-demand, eliminating the need for periodic updates [4] and reducing message flooding. Furthermore, because BLE nodes are typically resource constrained, the reactive protocol is best suited because it requires less storage than proactive and cluster-based protocols.

Related Works
In order to identify the research gap, we reviewed the latest BLE-based mesh communication protocols.
The early BLE mesh solution proposed by [16] is called MultiHop Transfer Service (MHTS). The proposed solution also works well for the two-hop and three-hop transmission of data. Reference [17] used the available mesh protocol to construct the mesh topology on office doorbells. According to [18], it is possible to support long-range communication due to the incorporation of the scatternet topology in Bluetooth 4.1. The author introduced the concept of service mediation based on Name Data Networking (NDN). In addition, BLE multihop routing was developed by [19], based on a scatternet topology feature of the BLE 4.1 protocol. To increase production, Reference [20] developed a BLE-based data collection approach for the agriculture area. Moreover, Reference [21] proposed the design for a multihop tree-based wireless network implementation, Furthermore, Reference [22] proposed a dynamic node organization approach for data routing, through an on-demand routing technique. In order to allow mesh functionality in an existing BLE beacon network, Reference [23] presented a novel BLE-based overlay mesh that addresses issues related to the best-effort scheduling and RSSI-based bounded flooding. Likewise, References [9,24] gave performance measures using the existing protocols, i.e., trickle and FruityMesh. Subsequently, a directional ad hoc on-demand multipath distance vector technique was proposed by [25]. By providing a directional link quality indicator for the routing schemes, the protocol overcame the problem of moving nodes' transmission instability. Furthermore, Reference [26] developed a BLE protocol to unravel the weaknesses in the BLE specifications on industrial wireless sensors networks. The main idea behind the article was to divide a network into different subnetworks that were each controlled by a master. To tackle the problem of overlapping events and enable real-time communication, Reference [27] suggested a BLE-based real-time multihop communication network with bounded message delays. Moreover, Reference [28] introduced BLE's multihop on-demand routing protocol, proposing topology configuration and recovery procedures. Reference [29] talked about using BLE technology to automate parking systems. Reference [30] also worked on a specific relay distribution in a flooding-based BLE mesh network with collision mitigation to increase the overall PDR. Moreover, an AODV-routing-based BLE mesh protocol was proposed by [6]. According to the author, less traffic was generated by the protocol than the mesh.
The aforementioned works attempted to improve the BLE mesh protocol features, as well as experimented on the available BLE mesh protocol, but did not focus on improving the underlying protocol. Only [6] has worked on a routing-based protocol to improve the performance of the packet-forwarding mechanism. As a result of the preceding, in this paper, we focused on improving the protocol proposed by [6] by reducing overheads, retransmissions, and delays. Moreover, the selected protocols mentioned in this section are summarized in Table 1.

Optimized-AODV Protocol Topologies and Testbed Design
This section describes the topologies and testbed architecture, the hardware and software used, and the discussion related to the proposed optimized-AODV for BLE mesh.

O-AODV Topologies and Testbed Design
To evaluate the proposed O-AODV protocol in this research, we developed a testbed as depicted in Figure 2 and the topology diagrams in three formats: linear topology with ten nodes as shown in Figure 3, multipath topology with six nodes, and partial mesh multipath topology with ten nodes, as depicted in Figures 4 and 5.
Furthermore, it is important to note that we increased the complexity of the Scenario 3 topology from the six-node topology in order to evaluate the O-AODV protocol's efficiency and robustness. Therefore, we included traffic results for the same four paths for O-AODV and AODV in the Experimental Results Section to demonstrate clearly the protocols' efficiency.
For simulation, Renode software was the only option for simulating the Zephyr RTOS application; it has support for a variety of boards [34]. Although the nRF52840 board is supported by Renode, it currently lacks a radio connectivity feature. Consequently, this paper focused on the experimental evaluation of the proposed protocol, which has the additional advantage of providing insights into various implementation constraints of the protocol in actual devices.

Initial Findings and Proposed Optimizations for O-AODV
In comparison to the mesh (flooding) protocol, the original AODV protocol was not performing on par in terms of the packet delivery ratio, overheads, end-to-end one-way delay, and average per-hop delay. With 2-3 nodes, the AODV protocol performed similarly to the mesh protocol, but as the number of nodes increased, the packet delivery ratio declined and the overheads rose, causing real effects on protocol reliability based on initial experiments not reported in this paper. As AODV is a more dependable protocol for ad hoc networks than mesh since it forwards packets based on the route, consequently, we improved the protocol by changing the host (software) part of the BLE stack (which contains the BLE mesh architecture) to improve its performance in terms of packet delivery ratio, overheads, end-to-end one-way delay, and average per-hop delay and to bring it as close to the mesh protocol as possible. We also changed the configuration in the controller component of the stack to enhance the protocol's performance. With the aforementioned improvements, the proposed protocol produced consistent results when compared to the existing AODV protocol, as well as comparable PDR with lower overheads and average per-hop delay and end-to-end one-way delay when compared to the mesh protocol, as discussed in Section 5.7.  The Nordic Semiconductor nRF52840 development boards are the BLE nodes selected for the testbed. The boards are embedded with four LEDs and four user-programmable buttons, as well as various input and output interfaces; Segger J-Link OB support; an integrated printed circuit board antenna; a battery (coin-cell) and micro-USB connectivity support used for programming, as well as for powering, and a UART serial port communication. A 32 bit ARM Cortex M4F processor is embedded with 512 kB of flash memory storage, and the board is equipped with 64 kB of RAM.
The only element in the mesh network are the BLE nodes. They were programmed with a BLE stack and the proposed mesh-based protocol that was designed and developed mainly in the application and network layer of the Zephyr RTOS (real-time operating system). All 10 nRF52840 DKs were connected via a USB connection to a laptop for data collection purposes by utilizing the PuTTY software.
The proposed protocol was embedded with the device-provisioning feature for the mesh network security, which means that every device wishing to join the network must first go through the provisioning process. Thus, the built-in provisioning APIs of Zephyr RTOS were utilized to enable the provisioning feature in the proposed protocol's application layer. Furthermore, for physical provisioning, a BLE mesh Android application was required on a smartphone to grant permission to the mesh-enabled nodes to enter the mesh network.
Moreover, the developed protocol was hardcoded with the network, application, and device keys for testing purposes. However, to enhance the security of the protocol, developers could dynamically give the security keys and utilize the available BLE security features as discussed in Appendix B.2.
Moreover, the operating system used to develop the protocol was Zephyr RTOS [35]. Zephyr OS is based on a very small footprint kernel for embedded devices that are resource constrained, which includes anything from simple embedded environmental sensors and LED wristbands to smart IoT apps and comprehensive integrated controllers. More explanation is given in Appendix B.

Experimental Topologies
In this section, we describe the topologies that we used in our experiments. For preliminary testing, we used a simple 10-node linear topology (as shown in Figure 3 by transmitting 100 packets from the source and reduced Tx power up to −40 dB (to make the testbed manageable) to compare the proposed protocol's efficiency to the AODV and mesh (flooding) protocols. Furthermore, to test the proposed protocol's efficacy, we experimented with a multipath simple topology with 6 nodes and with more complex/partial mesh scenario with 10 nodes, as depicted in Figures 4 and 5, with the same configuration as discussed for the linear topology.

Proposed Optimized-AODV Protocol Optimizations Achieved with the Experimental Results
In this section, we go over the O-AODV optimizations achieved and the experimental results obtained with those improvements.
Moreover, before delving into the details of the protocol optimizations, it is required to provide an overview of the message transmission flow following the incorporation of the AODV layer. Figure 6 depicts the BLE mesh communication with the inclusion of the AODV layer, and also shows the layers where the optimizations were performed. In the figure, the message is transmitted from the application layer, which then passes it to the AODV layer for routing. The AODV layer then sends the message to the BLE mesh layers, and the BLE mesh network layer finally hands over the message to the BLE stack, which then sends it to the other device. Furthermore, on the receiving end, the BLE stack sends data to the BLE mesh layers, which ultimately send it to the AODV and application layer.

How the Optimizations Were Achieved
This section discusses how we improved the proposed O-AODV protocol's efficiency in comparison to its predecessor version.

Route Request and Route Reply Optimization
We increased the hello message interval to reduce the control packet overheads on the channel since nodes are less likely to be transmitting when a route request is initiated. The route waiting list for route replies was expanded to accommodate a greater number of entries, as for the hello message list. Furthermore, the route request and route reply SDU sizes were slightly increased, which also had a good impact on the PDR, as well as the throughput, as observed in preliminary experiments that are not reported in this study. As a result, we used the same value in all of the tests reported.

Route Request Search and TTL Optimization
To improve the protocol's efficiency in terms of delays, we reduced the ring buffer delay, the route request search TTL, and the route request interval timings while improving the routing table's entries to accommodate more routes.

BLE Mesh Network and AODV Layer Optimization
Furthermore, in order to reduce the likelihood of unwanted retransmissions, we reduced the channel utilization and probability of collision due to retransmissions, as well as the packet loss by lowering the packet's time-to-live in both the application and network layers after making the necessary changes in the mesh protocol's network layer's bt_ mesh_net_send and bt_ mesh_ net _recv functions. In addition, we improved the AODV protocol's rreq_send, rreq_ recv, and rrep_ send functions to reduce packet retransmission.

Application Layer Optimization
Because the application layer is critical for the compilation of the results, we improved the periodic updates function for printing status messages. Furthermore, we optimized the bt_ mesh_ cfg_ srv function used in the Zephyr RTOS to modify various parameters required for our experimentation, such as enabling the relay, TTL value, GATT proxy, and so on, to improve application performance in accordance with our experimental requirements. Subsequently, Figure 7 depicts the summary of the acquired optimizations (obtained with the help of the aforementioned hardware and software) that resulted in better and more efficient results. To begin, this research concentrated on optimizing the application layer to achieve the desired output, as well as printing the messages to the PuTTY terminal. In addition, we enabled some of the capabilities of the configuration server model function and streamlined the periodic update function to obtain the desired results. In addition, as indicated in Figure 7, changes were made to the AODV layer functions. Following that, to address the issue of message retransmission, the mesh network layer functions such as bt_ mesh_ net_ send and bt_mesh_net_recv were enhanced. In addition, the controller configuration was altered, as shown in Figure 7, to ensure that the protocol ran smoothly as per the requirement.

Impact of Optimizations
In the light of above-mentioned optimizations, the proposed protocol exhibited practically constant route request and route reply to setup time and less overhead when compared to the old AODV and mesh protocols. The BLE mesh had very high overheads due to packet retransmissions, which the proposed protocol eliminated. We used the network's relay feature to control the number of packet retransmissions to support directed multihop transmission. In addition, for improved protocol efficiency, we increased the buffer size in the controller for the queuing of a few extra Tx and Rx PDUs that showed better results in terms of packet loss and PDR.

Performance Measurement Metrics Used for the Experiments
To understand the experimental results in detail, it is necessary to first explain the metrics that we used to assess the overall performance of our protocol.

Average End-to-End Delay
The term "average end-to-end delay" or "average one-way delay" refers to the amount of time it takes a packet to travel across a network from its source to its destination. It was calculated as: When data are sent from a source to a destination, the delay caused by each hop is referred to as the hop delay. It was calculated as: (2) PDR This ratio is defined as the proportion of packets that arrive at their destination in relation to the number of packets that were originally sent to the destination (source to destination). The overall performance improved when the packet delivery ratios were high. It was calculated as: PDR = ∑ Packets Received by All Destination Nodes/ ∑ Packets Sent by All Source Nodes (3)

RREQ-RREP Setup Time
This is the total time taken by the protocol from the time the route request is initiated until it reaches the destination and the destination sends the route reply message to the source and is received by the source. It was calculated as:

RREQ-RREP Setup Time = t_rreq_received -t_rrep_sent
Overhead We calculated the overhead by counting the number of packets retransmitted on the mesh network layer level, by adjusting the prompt message and the counter.

Common Experiment Setup and Configurations
We managed to run the experiments with three different topologies: linear, multipath, and partial mesh multipath. Furthermore, for each of the three scenarios, we experimented seven times to obtain precise results with 100 packets transmitted from the source with the lowest transmit power set to make the testbed manageable. We had nine sources and a sink in Scenario 1 and a single source and a sink in Scenarios 2 and 3. Furthermore, Table 2 shows the general experiment setup and configurations for the experiments.

Experimental Results: O-AODV Linear Topology with 10 Nodes
These studies were carried out using the linear topology of ten nodes. There are nine sources transmitting simultaneously towards the sink. Hence, the links closer to the sink carried the packets generated by previous nodes from the previous hops, resulting in the link closest to the sink being the bottleneck link with the highest amount of traffic.
This section summarizes the experimental findings in terms of the end-to-end delays, average per-hop delays, route request to route reply setup time, overhead, and PDR.
According to the results shown in Figure 8, the end-to-end delay increased linearly as the number of hops increased, and O-AODV was proven efficient in comparison with the other two protocols. According to the results shown in Figure 9, the average per-hop delay for all three protocols was almost linear, with better O-AODV results than the other two protocols. We achieved an average per-hop delay of 840 ms compared to 1100 ms for AODV and 1000 ms for mesh (flooding) protocols.
As shown in the graph depicted in Figure 10, mesh (flooding) had a very high overhead of more than 80% compared to the O-AODV and AODV protocols. Furthermore, O-AODV incurred a much lower overhead by reducing message retransmissions and TTL values.  As illustrated in Figure 11, both O-AODV and AODV showed a slight linear increase in the route request to route reply to setup time with an increase in the number of hops, with the O-AODV protocol taking approximately 16% less time. In Figure 12, O-AODV outperformed AODV in terms of the packet delivery ratio with 85% compared to 70%, but it was lower than the PDR for Mesh (Flooding), which was 95%.

Experimental Results: O-AODV Multipath Topology with Six Nodes
In this section, we show the results of the experiments with the six-node AODV topology proposed by [6].
The single source transmits data to the sink via two hops through the mesh, which has four different possible routes.
The routing protocols in Figures 13 and 14 had less traffic load than the mesh (flooding) protocol, which had very heavy traffic loads due to uncontrolled traffic flow, as depicted in Figure 15. Furthermore, the routing protocols created less overhead traffic with route selection mechanisms, resulting in better results with O-AODV in light of the optimizations discussed in the preceding sections.   Furthermore, as shown in Figure 16, O-AODV had a better route request to route reply setup time of 5100 ms compared to 6100 ms for AODV.
Furthermore, the proposed optimized protocol had a lower average end-to-end delay of 4000 ms compared to 4500 ms for AODV and 6500 ms for the mesh (flooding) protocols, as shown in Figure 17. In addition, O-AODV achieved lower overheads of 20% compared to 40% for the AODV and 79% for mesh (flooding) protocols, as depicted in Figure 18. However, in terms of the PDR, O-AODV (84%) outperformed AODV (72%), but not at the mesh level (flooding) of 95%, as shown in Figure 19.

Experimental Results: O-AODV Multipath Topology with 10 Nodes
These experiments were conducted using the 10-node AODV partial mesh topology for further protocol testing. The findings are presented in this section.
The single source transmits data to the sink via four hops through the partial mesh, which has numerous possible routes.
Since there are various combinations of paths through the partial mesh, Figures 20 and 21 only present the results for the selected paths to illustrate the directed forwarding behavior of the O-AODV and AODV protocols.
The O-AODV and AODV routing protocols depicted in Figures 20 and 21 resulted in lower traffic loads with the ten-node complex/partial mesh scenario than the mesh (flooding) protocol, which resulted in extremely high traffic loads due to uncontrolled traffic flow, as depicted in Figure 22. Furthermore, due to the improvements discussed in the preceding sections, the proposed routing protocol caused less traffic with the routing mechanism, resulting in better results with O-AODV due to lesser packet retransmission overhead.   In the partial mesh scenario with 10 nodes, O-AODV showed a lower average route request to route reply time of 5900 ms compared to 6800 ms for AODV, as illustrated in Figure 23, in comparison with its predecessor version due to the optimizations made to the mesh network and AODV protocol layers.  Figure 24 shows that the O-AODV had a lower average end-to-end delay of 5300 ms compared to 6200 ms and 7200 ms for AODV and mesh (flooding), respectively, due to the controlled traffic load. Furthermore, O-AODV had lower overheads of 22% compared to 42% for the AODV and 80% for mesh (flooding) protocols due to less retransmission than AODV and mesh due to an improved routing mechanism, as shown in Figure 25. O-AODV also demonstrated its efficiency in terms of the PDR with 81% compared to AODV with 69%, but it was lower than mesh flooding, as shown in Figure 26, because mesh uses a flooding mechanism that favors the packet delivery ratio at the cost of much higher overheads.

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.

Experiment Results, Discussion, and Research Contributions
The proposed O-AODV protocol performed better for various performance metrics, as shown in the improvements in the average end-to-end delay and overheads in compar-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 endto-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.
Nonetheless, the improved efficiency of O-AODV in terms of the average one-way delay and overheads compared to the flooding-based mesh protocol had a tradeoff, in terms of the achieved Packet Delivery Ratio (PDR). For example, in Scenario 3, although O-AODV showed a higher PDR (82%) than AODV (69%), it was lower than the 92% achieved by the flooding-based mesh protocol. Nonetheless, that tradeoff may well be worthwhile given that the higher PDR of the flooding-based mesh was achieved only with much higher average one-way delays, whereas message delivery reliability can be improved via selective message retransmission in the application layer, which was expected to incur lower overheads and a lower increase in the end-to-end delays compared to the floodingbased mesh protocol.
In addition, for this research, we optimized the proposed protocol for use in scenarios involving static nodes since AODV was originally designed for mobile nodes.

Conclusions
This article presents the proposed O-AODV protocol for BLE mesh networks and its implementation on a testbed in comparison with the AODV and mesh protocols.
There were various challenges with the experimental approach that are worth noting. One of the issues we faced was the lack of a simulation environment, which prevented us from testing for a high number of nodes because with physical devices, it was difficult to scale the experiments to a large number of nodes. The transmission power of the nodes was also lowered to limit the testbed to a more manageable size of 20 m × 20 m. Finally, radio interference is an environmental factor that is difficult to eliminate in a physical testbed. This was reduced as much as possible by locating the tested in an area with minimal cochannel interference from WiFi access points and other wireless devices.
Coming to the result outcome of this research, in terms of the PDR, the proposed protocol (84%) performed better than AODV, but not to the level of the mesh protocol. Moreover, the developed protocol outperformed AODV and mesh in terms of overheads, end-to-end one-way delays, and average per-hop delays. Furthermore, the proposed protocol had a lower RREQ-RREP setup time than the previous protocol version.
The proposed optimization in O-AODV managed to reduce the delay to 5300 ms, which was less than the delays for AODV (6200 ms) and flooding mesh (7200 ms); while the overheads were also reduced to 22%, compared to the overheads for the AODV (42%) and flooding mesh (80%) protocols. Nonetheless, the PDR performance needs to be improved. In order to reduce the 10% difference in the PDR to be on par with the mesh protocol performance, enhancements such as multipath support for AODV to increase redundancy and ensure faster route recovery need to be investigated as the next step.
Furthermore, the reduced delays and overheads will undoubtedly benefit the hospital scenario, as hospitals deal with emergencies all of the time, and delays can have a significant impact on response time during emergencies. Furthermore, lowering the overheads will benefit the network by putting less load on it, as shown in the Figure 20. In addition, there is room for improvement in PDR to bring it on par with the mesh protocols for improved reliability, since applications requiring high reliability will need to retransmit data due to packet loss, decreasing the available traffic capacity and limiting the ability to scale the network to a larger number of nodes.
Author Contributions: M.R.G. and T.-C.W. developed and implemented the proposed protocol, as well as compiled the paper. M.R.G., T.-C.W., G.C.S., and A.R. all contributed to the selection of the paper, its organization, critical assessment, and manuscript drafting. The published version of the manuscript has been read and approved by all authors. All authors have read and agreed to the published version of the manuscript.
Funding: This research received no external funding.

Conflicts of Interest:
The authors declare no conflict of interest.

Abbreviations
The following abbreviations are used in this manuscript: The Generic Access Profile (GAP) offers a standard structure for how Bluetooth Low-Energy (BLE) devices link. A BLE device can function as a broadcaster (advertises, but does not allow connections), an observer (sees advertisements, but does not initiate connections), a peripheral (advertises and accepts connections), or a central (sees advertisements and starts connections). BLE enables connectionless communications between broadcasters and observers through the use of advertisements (called beacons), as well as connectionoriented communications between peripheral and central devices. A BLE peripheral device, for example, broadcasts its presence at first, while the receiving device, a mobile phone acting as the central, establishes a connection with the peripheral to enable two-way communication. Following the formation of the connection, the central will operate as the master and the peripheral as the slave. To allow more complicated topologies, devices may also implement multiple roles. two methods for pairing can be used for low-energy versions: Low-energy Legacy Pairing (LLP) or Low-Energy Secure Connection (LESC) (introduced in Version 4.2) [35].
Furthermore, the 4.2 and 5 specifications added a secure connection device pairing capability, as well as a new approach called numeric comparison, which has proven to be the best for BLE-based device authentication when compared to other methods.
Provisioning: Unprovisioned devices are those that are not connected to a BLE mesh network. If a device wants to join a mesh network, it should first go through the provisioning process [35]. The device will obtain the provision to enter the mesh network after provisioning and will be able to communicate with rest of the nodes in the network. In Zephyr, there are several API's to program a provisioning feature in the mesh-based applications [35].