# A Platform of Unmanned Surface Vehicle Swarms for Real Time Monitoring in Aquaculture Environments
## 4 Network Communication System
For a node to be able to send data packets through LoRa, it must wait for a DTS to initiate a session, according to the mentioned protocol, so it can receive the LoRa packets. An USV or Buoy listens for the two types of packets mentioned, sent through LoRa to either start a mission (with Start Mission payload) or to one of the nodes reaching the DTS and update the missions, which corresponds to the packet with the Request Update Mission Payload. Sensory data payload is structured in a sequential way, where it is specified the ID of the sensor following the values sampled by the respective sensor (Figure 9). Some of the sensor devices used by a node acquire more than one type of value (for example, the GPS, where latitude, longitude and speed are measured), thus having more than one sensor value field on the structure of the packet's payload. This packet structure is variable according to the available sensors composed by the USVs. USVs will transmit their sensory data packets through LoRa in case that the same packet cannot reach its endpoint through _mOVE_, i.e using Wi-Fi and the DTN instead of LoRa. When this happens, the LoRa software module is notified, a LoRa packet is created and sent to the DTS once a session is established. The DTS also works according to the MAC protocol for Media Access Control for Multi-Gateway in LoRa. This means that it establishes a LoRa session with a LoRa node when it is requested, as long as the DTS is free to do so. The received LoRa sensory data packets are parsed and sent to the server. **Wi-Fi:** All nodes in the platform comprising Wi-Fi modules, meaning all USVs and Wi-Fi DTSs, have a DTN implemented. DTNs were designed for heterogeneous networks that may have connection  
Figure 8: LoRa packet structure and two types of payload: Start mission payload and request update mission payload. Figure 9: LoRa sensory data payload structure. disruption. This platform implements the \(mOVE\) architecture supporting IEEE 802.11a/b/g (Wi-Fi technology) and others, with a link quality-based routing strategy proposed in Reference [32]. This routing strategy has a replication avoidance mechanism and it has been proven to be better among other routing strategies for these types of scenarios. **Bluetooth:** Each USV or Buoy is able to communicate through Bluetooth Low Energy (BLE) to a mobile phone with a mobile application, if this mobile phone is in reach of the USV and Buoy. For this purpose, each USV or Buoy has a dedicated module to manage a Bluetooth session. Once the session is established with an endpoint device (the mobile app in the mobile phone), the module will gather the last sampled sensory values stored at a database and will share it with the client. If the session is still established, i.e the client is still in reach through Bluetooth and new sensory values are sampled, the USV or Buoy transmits this information to the client and stores it at the database in the case a new client comes up and starts a new session. Each packet is built in a JSON format, where sensory values are mapped with the correspondent sensor identification. This application is an android mobile app dashboard dedicated to establish a session, such as the mentioned above with an USV or Buoy, capable of parsing and processing the received values, displaying them through graphs.