# A Platform of Unmanned Surface Vehicle Swarms for Real Time Monitoring in Aquaculture Environments
## 7 Case Study
### Experiment  
This section presents a case study used to assess the performance of the platform with respect to the energy autonomy, connectivity, processing delay and mission delegation. The routing protocol and mechanisms required to assure the USV-USV communication by the means of a Delay Tolerant Network were already evaluated in ReReference [32] and they are out of scope of this work. Moreover, the navigation algorithm was evaluated in Reference [30]. The goal of the evaluation in this paper is to analyze the battery capacity, the connectivity between the gateway and the USVs,and among USVs, as well as the time spent in the information processing task by the USV. For that, the scenario illustrated in Figure 15 was considered, comprising two USVs, labeled as 51 and 52, both equipped with the same sensors, three targets, one DTS with Wi-Fi and LoRa, labeled as 31 and one MC. As stated before, each USV has two batteries, one for the Raspberry Pi and another for the motors. The life of the motor's battery was found to last for 75 min, when the motors were running continuously at maximum speed, being this the worst case scenario. In this experiment, every USV starts with no information about any mission. Due to the location of the USVs, the team is in contact with a DTS in the beginning of the experiment. Automatically, the DTS starts sending a missions' data message to each USV directly connected. When an USV receives this  
Figure 15: Case study scenario. packet, the database is populated with the newest information of the existing missions. All results comprise the mean and 95% confidence interval of 5 experiments in the same conditions. Figure 16 presents the delay and processing time in each USV of a _Collect missions' data_ Message and a _Start Mission_ Message. These messages take between 1 and 2 s to arrive in the USV and be processed. This shows that, for this scenario, a Start Mission message shall be sent with a starting time higher than the message timestamp plus 3 s (the delay and processing time of a _Collect missions' data_ Message plus the time of a _Start Mission_ Message). The task, in this experiment, consists in visiting three targets, taking the most advantage use of resources. When the mission starts, the team's navigation mechanism assigns target A to USV 51 and target B to USV 52. When USV 51 reaches target A, it sends a message containing the values measured in A through Wi-Fi. Then, target C is assigned to USV 51. When USV 52 reaches target B, it also sends a message to the DTS and because there are no more targets, this USV waits for the mission to end, while maintaining connectivity to USV 51. This mission takes on average 564 s to be completed (with a 95% confidence interval of 180.211 s), since the start of the mission advertised in the _Start Mission message_. In this experiment, we wait until receiving all Sensor Data Packets, so as a result, we see a 100% delivery ratio. However, in _mOVE_, if the Acknowledgement message is not received within a specified limit, that packet is re-sent. In this experiment we have observed 5 re-sends in total out of 25 packets. On the target C, LoRa packets of 104 bytes were sent to the DTS. The total time spent sending LoRa packets in a LoRa session from a monitoring node to a DTS was approximately 4 s, pausing for 7 min before sending another packet. As a result, it is expected an USV to be able to send approximately 24 LoRa packets per hour with the mentioned sensor data payload. To study the efficiency of the server when receiving data from several USVs, we flooded the gateway with packets to be transmitted to the server. Due to the DTS characteristics, that only sends a packet to the server every 100 milliseconds, we concluded that the server has 100% ratio of packets processed by packets received over time, being able to handle and process each packet under 100 milliseconds, having no packets left in the queue waiting at any time. On average, it takes the server 0.19151 s (with 95% confidence interval of 0.0302 s) to process and save the packet.