## 4 Experiment Design  
In this section, the experimental testbed and the evaluation scenarios for the proposed hybrid topology procedure for LoRaWAN are defined. After the implementation of the proposed solution for network coexistence in LoRaWAN, a set of experimental tests were performed on the campus of Santiago de Cali University (Colombia). As the devices would be susceptible to tampering if placed unattended in different parts of the campus, the most viable option for the feasibility tests was to locate all the end devices inside the laboratory. The antenna was located on the roof of one of the university buildings at a distance of 90 m in a straight line from the location of the end devices. The testbed consists of 6 end devices initially connected point-to-point, that is, in one-hop to one gateway, as presented in Figure 6. This initial state of the implementation resembles the conventional LoRaWAN star topology. The correct operation of the evaluation testbed was assessed before making topology changes. These end devices transmit data at different times. The LoRaWAN messages carrying these data include the link quality metrics from end device to gateway, specifically, the SNR and RSSI values. This information is extracted from the LoRaWAN message and stored in the database for later analysis and visualization. Another metric that is stored at the database is latency. This metric is obtained by subtracting the time of message transmission from the time of message arrival at the specific topic for the end device in the MQTT broker as automatically configured by the Chirpstack LoRaWAN server. Lastly, the information on the topology of the end device is obtained from the topology manager through the control UI, where the historical data from all the end devices can be accessed. Figure 6: Graphical representation of the initial evaluation scenario. To assess the coexistence between star and mesh topologies, three scenarios were considered for evaluation in which the communication of different end devices is changed to follow a mesh topology as represented in Figure 7. The aim of these scenarios is to demonstrate the feasibility of different topology combinations and the performance of the network according to the metrics previously described. Therefore, the topology changes in these tests were performed manually to force the desired scenario. Scenario 1 begins with the initial state of the testbed. In this scenario, two end devices send their data through a different hybrid device. This results in two devices operating in mesh topology mode and two devices operating in a hybrid state. This scenario was designed to assess the feasibility and performance of the solution with multiple hybrid nodes. Scenario 2 also starts in the initial state with all the end devices operating as star topology. Then, two of the six end devices change to mesh topology and send data through the same end device that has changed to operate as a hybrid node. That is, it receives the data from mesh devices and forwards them to the gateway. This scenario aims to verify that hybrid end devices are able to manage several mesh devices. Lastly, scenario 3 initiates with the testbed configured in star topology. Then, a device changes into mesh node and begins transmitting through one hybrid node. After some time, the device transmits through a different hybrid node. This scenario was developed to gauge the possibility of servicing moving devices or reconfiguring the network dynamically if necessary. In this way, a mesh end device can transmit data through the hybrid device accessible at the moment. To change the network topology from star to mesh/hybrid, the topology manager sends a message to the devices that need to change their topology. To do so, the message is added to the downlink queue for the intended device.