# Enabling Multi-Mission Interoperable UAS Using Data-Centric Communications
## 4 Data-Centric Communications in UAS Scenarios
### Summary of the Analysis  
The previous analysis shows the advantages of utilizing DDS to support data-communications in the motivating scenarios considered in this section (the result of our comparative analysis is summarized in Table 1). On the one hand, DDS offers a standard API that eases the development of UAS applications, independently of the software and hardware resources over which that applications operate (e.g., the hardware platforms and the operating system of client machines and UAVs, and the specificities of the data-links that support network communications). On the other hand, the DDS middleware handles the interaction with the underlying computer and network platforms, providing a common interface to UAS applications that offers, transparently to those applications, the following relevant functionalities: (1) the automated discovery of publishers and subscribers, enabling effective data-sharing with the utilization of application-meaningful _topics_ (this avoids the pre-configuration or discovery of IP addresses by applications, which do not handle network-specific information or implement procedures to support data location); and (2) the possibility to flexibly specify application-level QoS policies at runtime (e.g., in terms of latency or reliability), matching subscriber and publisher requirements and guaranteeing the timely distribution of data between them.  
The aforementioned features enable the utilization of general-purpose UAV platforms and heterogenous end-user equipment to build fully interoperable UAS deployments, which may deploy different DDS-based applications and hence be adapted to different mission objectives, such as those corresponding to the use cases presented in this section.  
On the other hand, as we previously commented, the efficiency of the multicast-based data-sharing approach of DDS may be affected in scenarios with a limited number of subscribers. This is due to the maintenance costs associated with multicast delivery trees, and the need to execute a multicast routing protocol over the resource-limited hardware platform that can be provided by a small-size UAV. A solution to address these limitations is to use layer-2 virtual networks to integrate the client entities of the UAS deployment (e.g., the mobile ground stations, as well as the equipment available at the UAVs, in our motivating scenarios) into a single broadcast domain. This enables the utilization of network-level multicast over the broadcast domain, without incurring in the maintenance costsimposed by a multicast routing protocol, as publishers and subscribers would be effectively located in the same Local Area Network (LAN).  
As a consequence of this solution, mobility management procedures are simplified from the perspective of the user equipment (e.g., mobile ground stations), as they can be statically or dynamically provisioned with a fixed IP address that will not change despite the movement of the equipment across the wireless access points provided by the small-sized UAVs (these access points would offer access connectivity to the same LAN segment). Mobility management procedures will still be necessary to update the access point serving the user equipment.  
In the next section, we present a practical experience that explores this approach, consisting in the utilization of layer-2 virtual networks to support the delivery of multicast traffic in a UAS deployment, demonstrating its feasibility and showcasing its advantages and limitations.