# Enabling Multi-Mission Interoperable UAS Using Data-Centric Communications
## 4 Data-Centric Communications in UAS Scenarios
### Location of Data  
Information location is the process of, given the identifier of a particular content, obtaining locators for the required information. As an example, consider the case in which the operator of a ground mobile station (e.g., a firefighter with a tablet) wants to watch the video transmitted by UAVs flying over a certain geographical area. To this end, the firefighter checks a map on the tablet, where a set of UAVs are deployed on the shown area. Only a subset of those UAVs have the \"camera\" icon, so the user selects one of those. A small frame over the map shows the video transmitted by such UAV. In this example, the application must obtain the identifiers of all UAVs available in the system. By using these identifiers, the application could retrieve other identifiers for the specific services provided by the UAVs. With these identifiers, the objective is to search for the corresponding list of locators. By using these locators, it is possible to retrieve information like position of the UAV, equipment on the UAV, remaining autonomy, etc. In our example, applications will use locators to retrieve the geographical position of all UAVs, filtering out those that are outside the requested area, and contacting the proper ones to check if they are equipped with a video camera.  
There are different mechanisms to obtain the list of locators in the IP world (when using the IP protocol, locators and identifiers are represented by the same IP address). For example, one option is to assume that all devices are configured (via the Dynamic Host Configuration Protocol (DHCP), for example) with the IP address of a bootstrap server. This way, all devices should register themselves with the bootstrap server to annotate their IP addresses. In this case, applications should contact the bootstrap server to retrieve the list of identifiers (IP addresses) of all deployed devices. At this step, there are two choices: either devices register service locators with the bootstrap server or applications should contact devices to retrieve that list of locators. In a different approach, all services could be identified by Uniform Resource Identifiers (URIs), using the Domain Name System (DNS) as the name resolver to return IP addresses (used as locators). A third option is to use a signaling protocol, such as the Session Initiation Protocol (SIP) [22], where devices register the contact addresses corresponding to their local services in a specific SIP server, acting as a rendezvous point, called Registrar. When applications request to access those services, the infrastructure of DNS servers and a set of SIP proxies work together to contact the latter.  
Instead, if considering DDS, applications should subscribe to topics such as location, video streaming, etc. Subscriptions may specify the topic with extra requirements (data-related and/or quality-related): for example, Consumer A subscribes to the \"location\" topic, but only to the contents related to UAVs. It is the DDS middleware that seamlessly implements the broker coordination actions to return the content to subscribers. The main advantage of a data-centric approach, compared to IP, is that a data-centric application does not need to implement the mechanisms to obtain service locators. Instead, the DDS middleware can dynamically discover publishers and subscribers, forwarding subscriptions towards producers as required, thus improving flexibility and reducing the complexity of application development.