# Enabling Multi-Mission Interoperable UAS Using Data-Centric Communications
## 5 Functional Validation
The GCS contains a barebone computer (Advanced Micro Devices, Santa Clara, CA, USA Athlon II X2 3 GHz processor, 8 GB memory, 500 GB hard disk) with 3 GbE ports, as the GCS router, operating under the same Linux distribution as the UAV router. The GCS router provides network connectivity to a workstation that receives and processes the telemetry information from the UAV (UAV operator in Figure 2), and provides a Wi-Fi interface that supports the attachment of external devices (e.g., external remote video terminals, that may receive the UAV telemetry, or even a set of small-sized UAVs). The detailed description of our UAS testbed can be found in [8]. To support experimentation activities with DDS and networks of UAVs, we extended this testbed with a number of hardware and software components. First, we incorporated three small-sized UAVs (Parrot AR.Drone 2.0), interconnected through a Wi-Fi ad-hoc network. Each of them transports a single board computer as payload, in particular a Raspberry Pi 3 Model B (RPi) and, in a real deployment, would be capable of flying and landing on a desired area to provide a regular Wi-Fi access point to mobile users over the operation field (or perform a stationary flight with the same purposes). The Wi-Fi access points and the Wi-Fi ad-hoc network are supported through wireless interfaces available at the RPIs. Secondly, we installed RTI Connex(r) DDS Professional software in the different components of the UAS, so that the tactical UAV can share its telemetry information (sensor data and video) using DDS with specific QoS constraints. Small-sized UAVs can also publish data to be accessible over the deployment area, such as the GPS coordinates corresponding to their current location. All the information made available through DDS will promptly be accessible to the users of the infrastructure, following the dynamic discovery mechanisms of DDS, and will be shared according to matching QoS requirements expressed by publishers and subscribers. In our experiments,  
Figure 2: Validation testbed including tactical UAV, GCS and small UAVs. we consider three users: (1) a UAV operator, who works at the GCS and is in charge of monitoring and managing the operation of the tactical UAV; (2) a user coordinating the mission that requires the UAS deployment (shown as the mission planner in Figure 2), who gets network access connectivity using a Wi-Fi access point provided by a small-sized UAV; and (3) a user that is carrying out some field operation at a distant area, and gets network access connectivity through a second small-sized UAV. The communications among small-sized UAVs, as well as between each of these UAVs and the GCS, is provided via the Wi-Fi ad-hoc network (in particular, one of the small-sized UAVs acts as a network relay between the GCS and the other two small-sized UAVs). To support the utilization of network-level multicast in our testbed, and this way take advantage of this technology to support the fast delivery of DDS messages to multiple receivers, we configured all the client devices of our infrastructure to be in the same Local Area Network (LAN) domain, using Virtual eXtensible Local Area Network (VXLAN) technologies [31] and linux bridges.