# Optimal Data Collection Time in LoRa Networks--A Time-Slotted Approach
## 7 Proof of Concept and Experimental Results
### Transmission of the Schedule  
Here, we present experimental results related to the transmission of the schedule. This includes an evaluation of the capability of the gateway to efficiently compute and encode the schedule. No physical presence of the nodes themselves is required. As a consequence, we can experiment with more than 10 nodes. In _Light_, the schedule consists of a set of tuples indicating the node id, the SF, and the slot number (i.e., [id, sf, slot]). For example, in our 10-node deployment this results in a 70 byte schedule. Some extra bytes are added to indicate the gateway id, the guard time, and the sync packet rate. In total, 78 bytes are sent. In terms of transmission time this translates to 35 ms with SF7 or 698 ms with SF12. _Global_ uses a more sophisticated data encoding to represent the repetition of the frames in the schedule. Recall that in _Global_ all the packets are scheduled, thus, a collection of frames is generated. A straightforward solution would be to include the node ids, their SFs, and their slots for all the computed frames in the schedule. However, this solution does not scale because the number of bytes increases linearly with the number of transmissions. On the contrary, since a big range of successive transmissions is scheduled on the same SF and slot, one way to reduce the total number of bytes is to use a run-length encoding data compression algorithm. For example, in our testbed, only the last transmission of one node is relocated to SF8. Thus, all the previous transmissions can be indicated using a single tuple. The general encoding pattern of a node's transmissions is the following: [id first_frame_sf last_frame_sf sfl slot, start_frame_sf' end_frame_sf' sf'slot',...]. In our experiments, the total schedule length with _Global_ is 154 bytes. In terms of transmission time this translates to 6.3 ms and 1.23 s with SF7 and SF12, respectively. Every node that receives the schedule, decodes the data and calculates the frame length for its assigned SF. In _Global_, this must be done for all the assigned SFs which incurs additional coding effort. The schedule transmission is followed by a very short init packet which actually initiates the data collection process. In the Aloha-based approach, the schedule transmission is omitted, thus, only the init packet is used. Table 4 illustrates the total theoretical schedule transmission time for different node populations using SF7. We examine the scenario where the schedule is sent based on an ideal setup where no duty cycle restrictions are imposed as well as when the duty cycle rules are followed. We should note that the first case occurs when transmissions are sent in non-restricted bands (e.g., 2.4 GHz LoRa). We can observe that, in the first case, the transmission of the schedule is quite fast for up to 100 nodes. _Light_ scales very well with less than 4 s transmission time for 1000 nodes. On the contrary, as the number of nodes increases, _Global_'s schedule becomes very long and, thus, difficult to be transmitted in a reasonable period of time, especially when the duty cycle rules have to be followed. This is because each node's transmissions may jump from one SF to another causing many non-periodic slot allocations in successive frames. Letting the nodes know these SF jumps, requires extra bytes and, thus, more time. To overcome the scalability issue of _Global_, we follow an alternative approach [11]. We disengage the computation of the schedule from the gateway (network server) and we move this process to the nodes. In this way, we transmit only the list of nodes and their minimum SFs, and we let the nodes compute the schedule. Since this list is usually multiple times shorter in size than the schedule, it can be transmitted in a shorter amount of time. It should be noted that this action leads to a trade-off between processing and communication time. In order to evaluate this trade-off, we implement _Global_ on our testbed devices.