# Optimal Data Collection Time in LoRa Networks--A Time-Slotted Approach
## 7 Proof of Concept and Experimental Results  
### System Setup and Procedure  
In order to verify our approach also in experiments with real node deployments, we created a proof-of-concept implementation consisting of 10 nodes located across two adjacent, multi-floor buildings. Independent, co-located LoRaWAN networks also existed in the area. The top view with indicative node positions is illustrated in Figure 7. The gateway is located at the first floor on the edge of the upper-hand building. The maximum (reliable) indoor range that was achieved with SF7 was approximately 60 m using typical 2 dBi antennas for both the nodes and the gateway. This low range is justified by the presence of multiple concrete and stone walls which cause a very strong signal attenuation. The purpose of the experiments is not to show the superiority of the scheduling approaches over the rest of the methods since this would require a network of at least 100 nodes along with very high financial and time resources. Thus, we limit the purpose of the experiments to assess the following practical issues:  
1. to assess the feasibility of using time-slotted scheduling algorithms under real conditions,
2. to assess the downlink transmission time of the schedule,
3. to assess the feasibility of computing the schedule on the nodes instead of computing it centrally on the gateway and then disseminating it to the nodes, and
4. to assess confirmed transmissions. Figure 6: Data collection time and energy consumption for variable data sizes. LoRa-enabled devices from Pycom in the Netherlands where used for the purpose of the experiments. For experimental efficiency, an amount of data was already generated and loaded onto the nodes' storage module. Each node position was initially evaluated for its connectivity requirements in terms of transmit power and SF. We did this test manually, however LoRaWAN's ADR mechanism can be used to automatically calculate and adjust the SF according to the latest conditions (the embedded code of the gateway and the nodes is available at [[https://github.com/deltazita/offline-lora](https://github.com/deltazita/offline-lora)]([https://github.com/deltazita/offline-lora](https://github.com/deltazita/offline-lora)) (accessed on 3 February 2021) and at [[https://github.com/deltazita/ts-lora](https://github.com/deltazita/ts-lora)]([https://github.com/deltazita/ts-lora](https://github.com/deltazita/ts-lora)) (accessed on 3 February 2021)). Table 3 summarises the experimental parameters and their corresponding values. The entire process of computing the schedule, communicating it to the nodes, and receiving the data is illustrated in Figure 8. Moreover, an overview of the network architecture is presented in Figure 9. We used a Raspberry Pi (here representing the network server) to compute the schedule. The Raspberry Pi can also optionally send additional information related to the experimental process, such as the guard time, the synchronisation rate, and the channel bandwidth. A gateway is responsible for registering nodes to the network, while another gateway is used for data collection. A third gateway can optionally be used for statistic collection in case of confirmed transmissions (i.e., the nodes can send out data about the ack rate). All the gateways communicate with the Raspberry Pi via secure WiFi links. The data gateway receives the schedule and forwards it to the nodes. To do so, the nodes must have their radio on and listen to a specific channel, BW, and SF. These settings are fixed and do not change throughout the process, thus, they can be flashed into the nodes during their setup by a system administrator. In the experiments, we used the highest SF in the network so that all nodes regardless of their SF can receive the schedule. Figure 7: Positions of the nodes and the gateway in the 4-floor building. An alternative approach would be to send the schedule multiple times based on the available SFs in the network.