# Study of Data Transfer in a Heterogeneous LoRa-Satellite Network for the Internet of Remote Things
## 5 Experimental Results  
To verify the obtained results, an experimental stand consisting of the Laird DVK-RM186 kit, the LinkLab LoRaWAN Gateway shield, a Raspberry Pi3-based IoT MQTT station, the Iridium 9602 SBD modem and DirectIP (SBD) and MQTT servers was built (Figure 4). The latter two components were installed on a virtual cloud server. For message packing, algorithm 1 was used. During the experiment the stand components interacted as follows:  
1. An end device from the Laird DVK-RM186 kit generated LoRa messages with a variable inter-arrival time from 1 to 20 s and a payload from 18 to 20 bytes. The messages themselves consisted of a pseudo-random sequence of characters emulating sensor data. 2. Messages were transferred through the LoRaWAN gateway and persisted at a local MQTT server installed on the Raspberry PI based IoT station [58]. 3. Messages were then retrieved from the MQTT server into a First-In First-Out (FIFO) queue with the format converted from JSON to Protobuf. 4. In the first scenario, each new message from the queue was placed in a new SBD container and immediately passed to the Iridium satellite modem. In the second scenario, a packaging algorithm was additionally applied. Figure 4: Scheme of the experimental stand. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Criteria** & **Algorithm 1** & **Algorithm 2** & **Algorithm 3** \\ \hline Number of sent messages & 1000 & 1000 & 1000 \\ Number of used containers & 334 & 333 & 330 \\ Average number of messages per container & 2.99 & 3 & 3.03 \\ Average container size in bytes & 280.99 & 281.83 & 284.4 \\ Container utilization, \% & 87.8 & 88 & 88.8 \\ Number of iterations for packing messages into containers & 1000 & 167,347 & 667,518 \\ The delay associated with the process of packing messages & \(3\times\mathrm{T}\) & \(1000\times\mathrm{T}\) & \(1000\times\mathrm{T}\) \\ into containers in seconds & \(3\times\mathrm{T}\) & \(1000\times\mathrm{T}\) & \(1000\times\mathrm{T}\) \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Comparison of packaging algorithms. 5. The Iridium 9602 modem normally responded with a confirmation within 5 s, indicating either successful transmission or failure. If the message transmission failed, an attempt was repeated up to 10 times. After 10 transmission failures, the message was deleted from the queue. 6. After sending the message, the main characteristics related to the data transfer process--send status, size of the initial JSON message, size of the encoded Protobuf message, total transfer time--were recorded on the IoT station side, as well as on the server side. 7. Steps 4-6 were repeated for subsequent messages from the queue. The experiment was carried out in an open area in the Moscow region. The data transfer process within each experimental setup lasted for about 12 min, then the LoRa message generation frequency was increased and the experiment was repeated. Within the 12-minute interval, about 40 SBD containers were sent, with 95% of them successfully arriving at the server side. The message transmission time related to passing data onto the Iridium network varied from 6 to 27 s (see Figure 5a), averaging at 10.7 s.  
These data can be interpreted from a different perspective, as shown in Figure 5b. As mentioned in the introduction, significant delays in the data transmission process are one of the main limitations of satellite technologies. With most real-life applications having certain Quality of Service (QoS) requirements to the maximal possible delay of information transmitted through the underlying network, the feasibility of the satellite channel can be determined by figuring the transmission success rate. Transmission success is determined by a message received at the server endpoint within a given interval. Figure 6 shows the distribution of delivery time with and without the packaging algorithm applied.