# Communication Manager for Hyper-Connected RPAS Environments
## 4 Validation: From the Lab to the Air
### Laboratory Ground Truth
#### 4.1.2 Load Balancing  
The main goal of this second experiment is to use the CIM to distribute the traffic coming from each one of the RPAs (applications related to flight control and telemetry reporting as well as local applications on the RPA) over different interfaces to perform a load-balancing strategy that preserves the required throughput and minimizes packet losses (complementing the previous experiment based on traffic delay with this one based on traffic load).  
Figure 5: Choosing the minimum RTT path traffic.  
In an earlier analysis, we identified that the maximum bandwidth available on the Wi-Fi ad hoc interface (emulated channel using VENUE) is roughly 7 Mb/s. The number itself is nonessential and depends on local computer conditions in the measurement moment. What is important is that it stays reasonably stable during the tests because it is used as a reference. Therefore, if the sum of the traffic received from RPA1 and RPA2 over the RPS Wi-Fi interface is higher than 7 Mb/s, it is reasonable to expect data loss.  
For this second experiment, the RPAs remain static (hovering), so the topology/grid of the system remains stable (initial position in Figure 3). We performed two different tests to evaluate the potential of the CIM. The first one uses the logic of a traditional system, only communicating over Wi-Fi. In contrast, the second one uses the CIM in combination with the proposed system and uses the other available interfaces (Wi-Fi and 4G/LTE).  
The experiment runs as follows: the RPA1 sends a constant stream of 6 Mb/s to the RPS; starting at the 20 s mark, the RPA2 sends 1 Mb/s flow that will be increased by 1 Mb/s every 10 s, i.e., at 30 s, RPA2 will send 2 Mb/s, and so on, until reaching the 6 Mb/s sent by the RPA1 by the 70 th second.  
As shown in Figure 6a (traffic captured at the RPS), with a traditional system, losses start to appear from 30 s onwards because the aggregation of incoming traffic at the RPS exceeds 7 Mb/s at its Wi-Fi interface. Therefore, even though RPA2 periodically increases the data flow rate, the total traffic received at the RPS remains stable and always close to the maximum available bandwidth (and below the real traffic sent).  
However, as shown in Figure 6b with CIM, from 30 s, the SDN controller using the information available from the _network monitoring application_ installed in the RPS discovers that the traffic received at the RPS Wi-Fi interface is close to the maximum available. At that moment, the SDN controller installs a rule in the RPA2 switch so that traffic with the RPS destination is forwarded through the 4G/LTE interface. That way, throughput automatically increases, and no packet loss is appreciated.  
It should be noted that the maximum bandwidth capabilities of both the Wi-Fi interface and the 4G/LTE interface may vary due to different environmental factors. However, although performed under controlled conditions (laboratory experience), this experiment serves as a Proof of Concept (PoC) to demonstrate that some QoS (both in RTT and packet loss) can be guaranteed by configuring the CIM and the SDN controller to honour the selected metrics.