# Implementing and Testing a U-Space System: Lessons Learnt
## 3 The U-Space Services
### Identification and Tracking  
* **e-identification Service**. The system must maintain updated information on the flights and, if requested, provide the different user types--authorities, citizens and operators--with different details depending on their data access privileges. During the project, the focus was put only on the pilot's view. In this regard, since it is important to provide an uncluttered screen, to minimize the quantity of information, pilots were asked for the values they wanted to see in the drone tags, and finally only the drone's unique identifier and some telemetry chosen by the pilots were displayed (Figure 7). A useful value on it is the timestamp, which indicates the moment when the telemetry was measured. Since position reports were expected once per second, a timestamp older than that could mean a loss link event. While in this case users would receive a lost link warning, a look at the timestamp of a drone that remains still in the screen--or that the current zoom level makes it seem still--can rapidly reveal if it is in position hold or if there is some lag or issue in the reporting.  
Figure 6: Detail of the location of the services and connections of the users.  
Figure 7: Drone tag with the information chosen by the pilots, namely: altitude relative to the ground, mean sea level altitude, speed and timestamp.  
* **Tracking Service.** In our case, the Tracking Service was only dependent on the Position Report Submission sub-service. Since no other close traffic was expected during the tests, no more position reporting (e.g., ADS-B) or tracking sources were integrated into the service. The Position Report Submission sub-service receives and processes the reports with the drone telemetry received from the UAV or the GCS. This processing includes several tasks like verifying the required periodicity of the reporting, forwarding the report to other services, comparing the coherence between GCS and UAV reporting when both are reported or identifying unexpected values. These verifications could trigger warnings and contingency procedures. In the reports, some fields were mandatory (drone and flight IDs, origin such as UAV/GCS, three-dimensional (3D) coordinates, speed, timestamp, security token) and others were optional (e.g., uncertainty of the values or source, like altitude from a Global Positioning System (GPS) receiver, barometry or infrared). The optional ones were not due to their minor importance, but because they were not being used by any service. Some flexibility in the fields will be necessary, since different platforms can provide different data or in different units and formats. In this sense, we could require a conversion in the GCS or the UAV or allow for different versions of the same data and make the conversion in the service. Regarding the reporting frequency, while it was requested a minimum of one report per second, it could be considered to increase/decrease the frequency based on the speed or the traffic nearby. That would help to reduce the workload in the server, of special interest with high densities. Each of the reports triggers a good quantity of checks in different services, and the updates are broadcast to all connected users. As mentioned, reports could be sent by the UAV, the GCS or by both redundantly. In this last case, the coherence between both sources was verified, which can help to detect spoofing.