# Implementing and Testing a U-Space System: Lessons Learnt
## 3 The U-Space Services  
The ConOps defines different types of airspace volumes and these require a different number of services. Considering the use cases of the project, some of them are expected inside or close to the city. The developed environment was addressed to the most restrictive Zu volumes, which requires continuous position reporting from the drone, a remote pilot station connected to U-space and an approved flight plan, and in which tactical separation instructions are sent to the traffic when needed. U-space also determines four deployment phases, which gradually add services, some of them mandatory, to allow for each step more complex operations. Being a research prototype oriented to test only some specific services in controlled scenarios, not all of the services required for each phase were implemented before developing a service of the following phase (the Tactical Conflict Resolution service belongs to the U3 level), and only those necessary for the projected validation were implemented. But among those implemented were e-identification, Tracking, Geoawareness, Drone Aeronautical Information Management, Geo-fence Provision, Operation Plan Preparation/Optimization, Operation Plan Processing, Strategic Conflict Resolution, Tactical Conflict Resolution, Emergency Management, Monitoring, Traffic Information and Legal Recording.  
The description of the implementation of these services has been ordered following the categories for these specified in the ConOps. Figure 6 shows the location of the services implemented. The GCS communicated with the Bridge Server; the task of this server was to work as a link between the users connecting via API/Web app and the UTM, and at the same time allow the update of the information in the Web app. Note that this Web app interface could be not only used by the pilots, but also by other users like the operators, authorities, air traffic controllers or citizens, and all of them should receive the update of the events and airspace situation. However, the UAV reported directly to the UTM to avoid the forwarding between the Bridge and UTM; in the case of having only the UAV reporting its position (or in the case of loss link between GCS and UAV), the reports are sent by the UTM to the Bridge which forwards them to the GCS and the Web app. All servers were hosted in the Amazon Web Services cloud, located in Frankfurt, except for the path planner used by the deconfiction services, which was running in a server of UC3M in Madrid. Inside the UTM server can be seen services that are dependent on other services or an extension of it. However, most of the services are interconnected between them, to  
Figure 5: Example of flight plan with three waypoints. On the left, the original set of components in the waypoints, which will be populated with the 4D constraints after the deconfiction of the path planner.  
access the data or receive updates or requests from other services. The Message Delivery Service (in yellow) is not part of the U-space ConOps, but a need identified during the implementation. Many information is generated before and during the execution of the flights and we need to be sure that every user receives the information they need or are allowed to access it. This service takes care of the delivery of the messages so that the GCSs and the Web apps can be correctly updated. Some messages are stored if the user is offline and sent to the user when logging in the system, like the information that a scheduled flight has been canceled or modified due to some change in the airspace environment.