Skip to the content

Altitude Angel's "Vision for U-Space"

As part of our commitment to the global drone ecosystem and as a solution provider within that ecosystem, today we are pleased to share with you further details on the work we have been undertaking with the European Commission as part of its 'U-Space' programme, particularly in respect of helping to make U-Space a reality, sooner, within the EU. This post is the first in a planned series and sets the scene for our vision of U-Space in the context of current, evolving discussions.

As always, we welcome dialog from a variety of stakeholders and regularly provide forums for and participate in intelligent debate on matters concerning the evolution of the drone industry.

U-Space (and, on the global stage, 'UTM') is an evolving concept - rather than a product - and as such this is a vision we feel is appropriate to accelerate its deployment and adoption within Europe.


Altitude Angel has a broad view of 'U-Space' and how it should be designed to support an evolving set of missions, capabilities and technologies. This document is provided as a narrative; to give an overview of our vision. It is not intended to serve as a detailed specification or a complete list of the component parts of U-Space, instead providing a conceptual overview with some detail removed for brevity.

A core tenet of our vision is that U-Space is designed to evolve from relatively 'humble' beginnings (supporting low volume VLoS and lower risk BVLoS operations) to a far more capable system that supports greater numbers of higher risk BVLoS flights and fully automated drones. To this end, we envisage a U-space that goes beyond the comparatively simple automation of manual processes to one that will continue to evolve beyond ‘version 1’, becoming the backbone for sophisticated and automated drone operations that Europe deserves.


There are several core concepts to our vision of U-Space:

  • U-Space needs to ensure that drone operations can be performed safely with different parts/services delivered/offered by it capable of undergoing appropriate levels of certification, regulation etc.
  • To unlock the full potential that drones offer, U-Space needs to be almost completely digital to allow the system to scale to very high-demand usage, at high efficiency, while being cost-effective. This is possible today using modern technology and service provision principles.
  • To ensure fair user choice, reduce cost and help ensure continued innovation, U-Space needs to provide a competitive marketplace for its services, as well as cater for ground and drone-based equipment.
  • A common concept of identity across the whole of U-Space is required to ensure different systems, built and operated by different organisations, can understand that they are talking about the same pilot or drone.
  • All parts of the U-Space implementation need to use standard interfaces and to ensure that those standards are built on widely-adopted technologies; this ensures it is easy to hire people to develop these services across all key stakeholders and that these technologies have a future (e.g. considering the use of GeoJSON rather than AIXM for aviation geospatial data as a simple example).
  • A standard way of indicating a service’s or system’s level of capability, including defined performance criteria for each level.
  • That U-Space components have further requirements to be resilient to cyber security threats, be highly available and work in accordance to rules specified in the General Data Protection Regulation (GDPR).


To fulfill this vision, we envisage a U-Space foundation system should offer the following services (as a minimum) for both ground-based and airborne systems:

  • A common, inter-operable registration system storing information on drone operators/pilots, owners and drones.
  • An identification system to allow Law Enforcement and concerned citizens to identify a drone, what it is doing and to interact with authorities to, for example, raise a complaint.
  • A guaranteed accurate, up-to-date restriction and hazard database. These restrictions should not just consist of 'no-fly zones', but zones where complex criteria can be accounted for (e.g. only drones with certain capabilities are permitted to fly, or drones flown by certain authorised persons for certain purposes).
  • A permissions system where operators can file flight plans and request to fly in restricted zones. This system should de-conflict filed flight plans and handle permissions management.
  • A communication service that is responsible for data connectivity between the drone or ground station and UTM Provider.
  • A tracking service that allows a drone or ground station to provide telemetry information including its location.
  • A monitoring service that will check the telemetry information and warn the operator about conflicting traffic, penetration of restricted zones and changes in airspace (e.g. temporary no fly zones). For Automated drones, this service will issue commands rather than information (e.g. follow this route, change altitude, etc.).
  • Surveillance systems to allow sensitive sites to deploy drone detection sensors to identify drones that are not cooperating with U-Space (it is considered an essential service that the basic U-Space services are capable of dealing with both cooperative and non-cooperative drones).
  • Sense and Avoid on the drone to allow the drone to avoid hazards the UTM system is not aware of, and to provide pre-registered safe 'escape trajectories'.
  • Accurate weather information evolving to hyper-localised forecasts.


Discussions involving aspects of unmanned aircraft traffic management systems often skip to the far-right of the diagram, i.e. "the future", leaving those tasked with attempting to regulate or even deliver key components in the situation that the path between 'here and now' and 'the future' is completely unknown. Our deployment model enables and provides for phased national roll-out, following a capabilitiy model, that also takes into account the sensitivities and requirements of different classes of drone operator, mission and geographic sensitivities within a Member State.

This deployment model also provides for a very high level of integrity in the safety-critical parts of the system which enables a flourishing open and competitive marketplace to develop. To facilitate these seemingly conflicting requirements, some services will need to be run centrally and operated by, or on behalf of, a Member State - perhaps by a regulated entity. The 'monopolistic' nature of some of these services can be offset by the expectation that interaction by the end-user (or drone itself) is not directly with the services operated by the Member State's base layer, but instead through the use of a UTM service provider, selected by the drone operator or manufacturer.

It therefore makes sense for the State to retain control over the service that actually gives a drone permission to take off and fly a route (or, at least, to have access to a real-time centralised picture).

This ensures fair access to the airspace while providing for a single source to understand what activity is taking place, where and by whom.

We have proposed a model that supports the Member State's desire to remain in control of its airspace while allowing flight planning service providers to innovate and to differentiate themselves from their competition (e.g. investment in hyper-localised weather forecasting would allow a flight planning provider to increase the range of their customers’ drones by allowing for wind direction and speed).


To ensure that the U-Space is not artificially delayed, the system needs a mechanism to encourage companies to commit R&D budgets to develop and innovate more advanced capabilities. This mechanism must be capable of clearly defining what a digital service or item of hardware is a capable of providing and what are the commitments in service and availability levels. This can be achieved through the concept of ‘Capability Levels’ and defining the performance characteristics to be met for each level.

Capability Levels can be though of, therefore, as a set of technical, procedural and/or legislative requirements that one must adhere to in order to fly or operate a drone in an area that has an assigned Capability Level. In this way, both the chosen level and the location to which it applies provide mechanisms for gradually rolling-out additional capabilities in a predictable, scalable manner while ensuring there is - at the same time - a matched mechanism for policy.


Let's take an example of a system on the drone responsible for determining its current location. We could imagine foundation requirements here broadly similar to standard GPS, such that ‘Capability Level 1’ could be defined as ‘needing to be accurate to 20 m laterally and 50 m vertically’. Continuing this imaginary example, ‘Capability Level 2’ could require a more accurate or perhaps certified device, while ‘Capability Level 3’ adds the requirement to have a backup system that allows the drone to operate safely for a period of time in the event the primary location system fails (e.g. GPS is jammed) - allowing the drone time to land safely.

Capability Levels should specify mitigation processes and not just define the required behaviours of hardware. In context, for example, a communication service could have a higher Capability Level if it had a process to compensate for an area of poor communications coverage. Hypothetically, this could include increasing the separation distance between drones or all the drones given pre-deconflicted landing points to use in the event of a network failure.

This model allows industry to look to build and certify devices to meet these Capability Levels with no constraints on the technology that they are allowed to innovate with; a key and fundamental concept in the rapid adoption and rollout of new technology but one which, crucially, can be paired with a geographic restriction and a set of regulatory patterns to match.

Capability Levels, therefore, could apply to both hardware and software services; they allow us to define a region where a drone will only be given permission to fly if it meets a certain Capability Level, and is using services that are built to an appropriate standard. Through the standardisation of these levels across U-Space, as an example, it allows the drone (or drone operator) to request to fly in a zone and for that answer to be given digitally.

As a conceptual example, to fly under VLoS in a rural environment you may only need to meet Capability Level 1, but to fly BVLoS without a human in the loop in a dense urban environment may require Capability Level 4.


To create an interoperable system that is both robust and capable of encouraging competition in a safe environment, standardisation is fundamental. Each service will need to have its interface standardised to allow any party to develop either the service or a client to connect to that service. Both SESAR and the EU are looking to EUROCAE to do this work.

To ensure a vibrant, competitive marketplace, these standards must be as open and accessible in as wide a variety of scenarios as possible. Most U-Space services are going to be running in the public cloud and over the public internet and, probably the mobile phone networks (at least in the shorter term or for lower Capability Level operations) in the short- and medium term. It is important that these standards are developed with this environment and its associated characteristics in mind while still recognising that, over time, the underlying communications transport technologies will change.

Additionally, it needs to be easy for companies wishing to develop U-Space services to hire enough technical resources to complete integration work and thus, more traditional aviation standards (such as AIXM, as an example) are likely not appropriate for U-Space service providers. This does not mean that the lessons learnt from these existing standards should be discarded and new standards developed from scratch; it merely means that we look to, where possible, leverage the knowledge and technical definitions from the existing standards but ensure they are more accessible to and usable by software engineers creating services running on more modern infrastructure for modern devices.



The registration system is a key enabler for U-Space; both from the safety and enforcement aspects, and also allowing a vibrant ecosystem of services and hardware to access key identity information. The registration system should be operated by or under license of the Member State, but should be designed to ensure interoperability between States, while ensuring that the subject of registration (the operator) remains in control of their data.

The registry will store details on Drones, Operators and Owners. Information such as operator-specific permissions and exemptions will be stored along with information on the capabilities of the drone. This information will be made available, with the user’s consent, to any U-Space service provider they choose to utilise. This gives the U-Space service providers high quality and up-to-date information, which could, where required, be validated by the NAA in either an automatic or manual (but digital) process, with automated checks expected to comprise the bulk of such validations. This quality of information allows much better decision-making and reduces the risk to service providers dependent upon it. Additionally, when an operator is requesting permission to fly at a sensitive site (an ATZ, for example), the authority for that site will be in a very good place to understand who this person is.

An essential component in supporting a vibrant, competitive U-Space (while, crucially, delivering one that is verifiably ‘safe’) is to allow all the systems to have a common view on identity of a Pilot, Drone and Operator, etc. This is provided by making the registration system an identity provider. This means that when a user comes to log into any U-Space service, they are redirected to the registration system. Once they log in and give consent for their data to be used by the service provider, the registration system gives the service provider a cryptographically verifiable set of information on that Pilot, Drone, Operator, etc.

There are several very widely used technical standards that support exactly this model - SAML and OAuth2 are ubiquitous, industry-standard solutions. The trusted Identity Provider model has obvious benefits: from the end-user’s point of view, it means they won’t need separate logins for each service they use (e.g. to submit a flight plan, check the airspace, report an accident) and that their data isn’t locked away by a single vendor (vendor lock-in). It also saves users from having multiple accounts that have stale information in them.

Additionally, a common e-Registration system will enable a drone manufacturer to develop control applications that access the in-situ registration system in a Member State; without having or requiring each drone operator to register again and again in each State he or she wishes to fly while enabling the manufacturer to make only one drone that works in multiple locations. If an end-user uses their registry login to submit a flight plan, it allows a marketplace for a marketplace of flight planning tools, fleet management, etc. The end-user is not tied to the first flight planning tool that they used that now ‘owns’ all their data.

In summary, e-Registration should enable end-users to control with which UTM Service Providers they share certain data, or which 3rd parties they authorise to provide updates to data held in the Registry.


U-Space will require a system to allow law enforcement / security personnel as well as concerned citizens to identify and/or potentially file a complaint about a drone, regardless of which UTM Service Provider is handling the flight. This system is likely to consist of a radio broadcast identifier as well as using telemetry information sent to the State operated orchestration service, cooperatively. It is recommended that upon registration, each drone is allocated a URL to act as it’s unique identifier. This URL would also be the address in the registration system for this drone.

For example: [protocol]://

An implementation following this pattern has several advantages:

  • It does not impose any artificial limit on the number of drones that can be registered
  • It allows a State to have numerous registration systems and imposes no limit on their number, if this was ever desired (it is conceived this may occur when one registration provider supersedes another, or the State wishes to retire any particular system while still maintaining compatibility). This would allow a state the option of decentralising a registry to U-space service providers, model flying clubs, training organisations, etc.
  • If an end-user has the correct privileges, accessing the URL in a browser or app will display the details in the registration system; removing the need for a service to locate the registry that an ID number is registered in. If the user does not have permission to see this information, this URL could allow them to raise a complain about this drone, report that they have found it or allow an organisation who doesn’t have access to that information to initiate a data sharing request.
  • With a standardised data format being returned from this URL, interoperability is ensured across all of U-space. E.g. a police officer could have a standardised app to look up the URL even if the drone is not from their country. *By moving away from a traditional ID system that increments an ID number for every new system, we make the registration system much more resilient and scalable. i.e. if there is a single entity storing the last ID allocated, this becomes a single point of failure (and a bottleneck) and as well as scalability concerns, introduces brittleness to the registration system.


It is imperative that drone operators are given an authoritative view of where flight is normally permitted and where there are known restrictions and hazards that are either permanent or temporary. Putting the onus to accurately define all this data for a country onto each and every private company while expecting them to take liability for it will make becoming a U-Space service provider very expensive and increase the overall system risk. This, in turn, will stifle innovation, reduce choice and increase costs.

A key underpinning to a thriving U-Space must be an authoritative data set of restrictions and hazards that is approved and maintained by the State. Other UTM System Providers may supplement this with additional data specific to their USP and product capabilities, but the basic fundamental data governing the legality of an operation must be single-source. This data would be served from a centralised service that is isolated from the end-user by a marketplace of authorised U-Space service providers that have been proven to have the right integration and have met specific safety bars.

Additional considerations for this service include the need to process NOTAMs and issue temporary drone flight restrictions, for example in the case of a car accident or maybe around a building or wildfire.


To ensure that operators and drones are aware of restrictions and hazards, a Geo-Awareness service will be needed in order to ‘push’ this data. This can provide for a competitive marketplace where service providers are able to differentiate themselves by adding data to the authoritative dataset – e.g. a greater range of hazards, terrain model, 3D City maps, etc.


The Orchestrator – a central service operated by the State - will provide the essential safety services and real-time decision making that U-Space will rely on. As a result, it will be the most heavily certified part of the ecosystem. It will provide the State with a mechanism to update rules or regulations, and enforce any temporary restrictions digitally, authoritatively and in a manner that can be backed-up by enforcement.

The Orchestrator also takes responsibility for providing data exchange of critical safety information (such as actual or detected conflicts) and sharing this information with the UTM service providers responsible for then taking action. By centralising this service, the State can be assured of safety while enabling an open, flourishing ecosystem of UTM service providers.

In this example, The Orchestrator performs the following critical functions:

  • Declaration of intent to fly: Declaration of where and when a drone operator is planning to be in the air. It may not be mandatory in a State to declare a flight (especially if it is VLoS), but sharing this information derisks other drone flights and helps the information services (described below) improve safety. The Orchestrator will also de-conflict these flight plans, warning operators if another drone flight overlaps in time and geography with theirs.
  • Access to the sky: When we get to the point where a drone has to request permission to take off, a central entity needs to perform this. This decision will be made based on a number of factors including traffic density, airspace restrictions, drone mission, pilot and operator qualifications, service capacity, predicted or pre-declared flight volumes, etc. This decision will need to be made by a centralised, independent service with a complete airspace picture and, by one that is not influenced by commercial priorities. It cannot be made by an organisation that may have a vested interest to always ensuring its customer’s drones take off at the most favourable times or locations, or if the entity also operates its own drones, giving priority to its own drones over other airspace users. Finally, only the State will know what to do with a request when it arrives – which stakeholders are important to involve (such as security services, or the ATCO at an airport), and can implement the necessary ‘back-end’ systems to connect the UTM and ATM ecosystems together.
  • Collision Avoidance Information Service: If drones are human-controlled, this information service can warn drone pilots about potentially conflicting manned and unmanned aviation as well as changes to airspace (TFRs) and poor weather.
  • Collision Avoidance Instruction/Resolution Service: To support automated drones with no human pilot, we believe that a tactical real-time de-confliction service is essential to provide efficient and safe use of our airspace. While it may be possible to allow drones to fly with a rigid set of the ‘rules of the air’ and an on-board sense and avoid capability, we feel that V2V and/or simple reactionary measures executed by the drone should be a last resort in avoiding a collision. By implementing a Plan to Avoid system, where drones are routed around hazards dynamically via a connection to the Orchestration service while they fly, the airspace will be used much more efficiently. Sense and Avoid on the drone is essential, but it should not be the only means of avoiding a collision.
  • Accurate airspace picture: This Orchestrator provides a 'single view of the truth'; a central view of airspace usage for authorities and law enforcement to be able to understand what is happening in the skies, including potential ATM integration feeds.

The remit of the Orchestrator role starts off very simply, for the VLoS and BVLoS world; with just the flight declaration.

It has been suggested that de-confliction could be carried out by multiple U-space providers in real time. This would involve building a system to ensure that two drones that are using different providers. This would involve having both providers create compatible avoidance manoeuvres. While this sounds good (in theory), a deeper investigation shows several flaws with this approach as well as introducing significant inertia to the development of U-space.

“Split brain” decision making between different commercial entities in real-time and on safety related matters would introduce a massive complexity into the heart of the most critical service. To facilitate a rapid adoption of U-Space and ensure this system is a safe and fair as possible it will therefore need to be centralised service operated by, or on behalf of, a State.

As with all the centralised roles that have been proposed for U-Space (perhaps with the exception of Registration, which could be a user-accessed centrally-run service by the State), we believe that end users (drone operators etc.) should not interface directly with this service. Instead, users should communicate though one of the approved marketplace UTM service providers. This provider can then relay information / instructions from the orchestrator while also being able to add their own functionality to the standard service to differentiate them from others. E.g. if a service provider specialised in accurate hyper-localised weather forecasting, they could add their own weather warnings into the information service or instruction service data streams.

This two-tier architecture allows for a central service with guaranteed performance characteristics, capable of certification, while providing a competitive marketplace for the end user to choose their service provider from.

It has also been suggested that drones will ‘just be able to fly around avoiding each other autonomously’; each knowing the new set of Rules of the Air and potentially using Vehicle to Vehicle communication technology to gain awareness of conflicts and potentially agree separation manoeuvres. While this may be possible in the very long term, it will be a long time before this level of autonomy will be accepted by the security services and certified by the safety agencies. Implementing the Orchestrator may well be a stop gap until this utopia becomes real, but will have the following advantages:

  • The Orchestrator can choose an avoidance manoeuvre that takes into account other drone destinations and missions – we do not need to ‘just turn right’ each time and hence can make much more efficient manoeuvres, extending the range of the drones.
  • It is imperative that we are able to ‘update’ the Rules of the Air after the system has gone into use - e.g. as we gain more operational experience with the system we may want to change some of the parameters – e.g. start with a very conservative minimum safety distance and reduce it over time. As changes to the rules only take place in the Orchestrator, we do not have the problem of simultaneously updating every drone in the system even while in flight. Having different drones flying under different versions of the rules is an accident waiting to happen.
  • The orchestrator is an accelerator to certification of any large-scale deployment of highly automated drones. By moving the core logic into the Orchestrator, this is where the bulk of the certification effort lies. Drone manufactures only need to show that their drone does what the orchestrator says.


To allow the drone or ground station to send telemetry information, there is a requirement for a data connection. This connection should be defined as a service against specific Capability Levels. Conceptually, an designed to evolve over time, Level 1 might be limited to sharing the location of a VLoS operator, Level 2 a telemetry stream including position data. However, Level 3 might require that the service verifies the declared position that are being transmitted.

By providing performance criteria for this level, we allow a range of solutions including 3G, 4G and 5G mobile technologies using triangulation from the cell towers, from a SatComms network or maybe with a custom radio system using ADSB and multilateration for verification.

The standard would also include criteria around data loss, coverage and redundancy. However, industry must innovate to provide different technologies that meet the performance levels without restricting the technologies used.

The user would be free to pick the service, that best suits their needs, service from the open marketplace and through a standardized interface connect their drone to the marketplace service; this in turn will connect to the Orchestrator providing the Orchestrator with details of the services’ Capability Level.


The drone will require a mechanism to identify its location and altitude. There will be a range of capability levels for this service. Some may require only self-reported location, others may require sensor correlation and that the drone be visible to one or more stated surveillance technologies.

Aligning these requirements on the system to Capability Levels enables a regulatory environment that can require more stringent criteria be met for riskier operations (i.e. larger drones, or in more congested controlled airspace as simple examples).

In this context, Capability Level 1 could be defined a needing to be accurate to 20 m laterally and 50 m vertically. Capability level 2 could be a more accurate device, while level 3 is additionally required to have a backup system that allows the drone to operate safely for a period of time in the event the primary location system fails (e.g. GPS is jammed) - allowing the drone time to land safely. Level 4 might be dual redundant systems that allow the flight to continue uninterrupted in the event of the failure of one of these systems.

This then allows industry to look to build and certify devices to meet these Capability Levels.

For example, a Level 3 device could use a calibrated GPS receiver augmented with accelerometers to provide a short term fall back. Alternatively, the GPS could be backed up by triangulation from a mobile phone network or even optical recognition back to a high res mapping or image database. The important point is that, by defining the Capability Level and performance criteria, and not favouring one technology in particular, we allow industry to innovate and create a competitive marketplace.


To create a layered approach to separation assurance, de-confliction will be performed on pre-filed flight plans, on real time telemetry and to cater for unplanned events, through using Sense and Avoid capabilities on-board an automated drone in combination with the Orchestrator (which has a critical responsibility to ensure drones taking evasive action don’t all try to occupy an ever riskier location), or another separation method including a human pilot.

Any onboard sense and avoid capability will need to be covered by the defined Capability Levels which, among other things, will set the required performance characteristics; allowing a variety of technical solutions to be developed to perform this function e.g. onboard radar, lidar, optical etc.

The development of this technology will be critical for the success of BVLoS operations in non-segregated airspace.

Example Scenarios

Because U-Space is an evolving concept (and system), it can be challenging to 'picture' the full system without specific examples of its application.

Below are some example flows of how a U-Space foundation system could perform in different scenarios, intended to promote conversation rather than to provide a complete end-to-end definition.


It will be very useful for the UTM system to know about the location of VLoS drone operations, but it will be a political decision as to whether it becomes mandatory to declare where you are flying (which will also be based upon a function of how simple and accessible the tools are in order to file such a declaration).

There are also commercial drivers affecting whether VLoS flights are captured and the insurance market is key in defining a lot of these requirements, too. For instance, while it may not be the law to declare your VLoS flight, it might be written into an insurance policy from an insurer that you do so.

In the future, VLoS drones may well connect to U-Space and send a telemetry stream, but this will not be the case for a pre-U-Space VLoS drone.

For people flying recreationally, the following is an example of the pilot’s view of their interactions with U-Space:

  1. The pilot, having previously registered themselves and their drone, uses their registry logon details to identify themselves to their U-Space service provider’s app on their phone. This is the app or service of their choosing.
  2. They use the app to check whether they can fly at their current location; at this location they are seeing no restrictions, so they tell the app that they want to fly now.
  3. Their U-Space service provider submits a request to the Orchestrator, containing the location and details of the pilot and drone from the registration system.
  4. The Orchestrator checks a number of factors including airspace restrictions, the pilot’s qualifications and whether any manual input from an external stakeholder is required to grant the permission, and upon finding no restrictions or conflicting flights; grants the operator permission to fly.
  5. The app displays to the pilot their permission to fly and securely stores and logs it.
  6. During the flight if there is any conflicting traffic or airspace changes, the app notifies the pilot.
  7. At the end of the flight, the pilot lets the app know that the drone has landed, and in turn, the Orchestrator is notified that the flight is complete.


A drone operator has been tasked with conducting an inspection flight over a piece of linear infrastructure. The operator is using a drone whose manufacturer provides U-Space integration by acting as a U-Space service provider.

  1. Several days in advance, the operator uses the flight planning software that has been provided by the drone manufacturer, to plan the route.
  2. This route requires it to fly through several restricted areas, so on submission of the flight plan to the flight planning service, permission to fly in these areas is requested from the Orchestrator.
  3. One of these areas requires certain services on board the drone to be at a minimum Capability Level. This is easily checked by looking at the drone’s registry details as well as the payload submitted with the flight plan.
  4. Another of these restricted areas requires permission from the authority for that airspace – for example if the drone needs to transit through an ATZ, the aerodrome’s ATC unit may need to give their permission.
  5. The pilot’s and operator’s permission to fly BVLoS operations are also checked.
  6. Sometime later the ATC unit approve the transit request.
  7. On the day of the flight, at the point of take-off, the ground station requests permission to fly the approved flight plan. The Orchestrator checks a number of factors including whether any permissions have been withdrawn, the current traffic density, etc. In this case all is ok, and the Orchestrator gives permission to fly.
  8. During the flight, the ground station relays the drone’s current position to the tracking service - if there is any conflicting traffic or airspace changes, the ground station notifies the pilot. The pilot can also be warned if the drone is deviating too far from the flight plan or heading towards zones they don’t have permission to fly in.
  9. During the flight, a member of the public sees the drone and wants to know what it is doing. Using their phone, they are able to query the identification service to see that it is working on behalf of the rail company and is doing a track survey. This information relieves their concerns.
  10. After completion of the flight, the ground station sends notification that the drone is no longer airborne.


This scenario involves a retail organisation that manages and operates their own drone delivery fleet. This organisation acts as a U-Space service provider, implementing several U-Space services for their own use, to provide U-Space integration for their fully automated fleet.

In this scenario, we are describing a use for an automated drone but not straying or detailing the practicality or the implications of such a drone delivery service. This is a fully automated system and the entire scenario happens with no human intervention.

  1. A customer on a retail’s eCommerce website identifies an item they would like, chooses drone delivery and clicks the ‘buy’ button.
  2. The purchasing system checks that there are no restrictions at the delivery address and automatically plans the most efficient route, routing the drone round any restrictions or bad weather. The retailer’s U-Space service files the flight plan with the Orchestrator and receives approval.
  3. The customer is given confirmation of their order and the time the drone will arrive.
  4. The retailer’s warehouse system identifies the location of the chosen item and dispatches a robot to load it onto a drone.
  5. When the drone is loaded, the retailer’s system electronically requests permission for the drone to take off.
  6. During the flight, live telemetry is sent to the Orchestrator which occasionally sends deconfliction instructions to the drone resulting in minor course and altitude alterations.
  7. Due to a car accident, a temporary no fly zone has been created that covers part of the return leg.
  8. The retailer’s system is notified of this change and files a new flight plan with the Orchestrator which will navigate the drone around the restriction. Upon receiving the new flight plan, the Orchestrator can send the new course to the drone. In this case the retailer’s system has requested to be allowed to re-plan disrupted flight plans. Alternatively, it could allow the Orchestrator to calculate the best course to avoid the restriction (e.g. hover, route round or over, divert to alternate landing site …).
  9. Upon safe return to the distribution centre, the retailer’s system selects the landing pad for the drone.

For further information about our U-Space vision, downloadable materials, whitepapers and more, please contact us. 

Altitude Angel

Altitude Angel

Altitude Angel is an award-winning provider of UTM (Unified Traffic Management) software, enabling those planning to operate, or develop UTM/U-Space solutions, to quickly integrate robust data and services with minimum effort.

From a consistent, well-documented and standards-based platform, drone manufacturers such as DJI and cutting-edge software developers around the world use our Developer Platform to obtain rich, relevant and local geofencing data, exchange and share flight plans, de-conflict their own flights in real-time and interface with national flight authorisation systems. A growing portfolio of enhanced capabilities help our customers to comply with current and future regulations and interface with changing national systems with only minimal effort.

Altitude Angel’s first party solutions also power some of the world’s leading ANSPs, aviation authorities and Enterprises, including LVNL (Netherlands) and Avinor (Norway), empowering them with new capabilities to safely manage and integrate drone traffic into national operations.

Today, Altitude Angel’s market-defining technology is providing a critical, enabling service on which the future of UTM, especially in controlled airspace, will be built across the globe.

By unlocking the potential of drones and helping national aviation authorities, ANSPs, developers and enterprise organisations, Altitude Angel is establishing new services to support the growth in the drone industry.

In 2021 Altitude Angel won a prestigious Air Traffic Management (ATM) Magazine Award in the ‘UTM Service Suppliers’ category, which recognises pioneering technologies and procedures developed by UTM service suppliers to advance safety and complex operations, for its Pop-Up UTM platform.  Read more about the awards here.

Altitude Angel was founded by Richard Parker in 2014 and is headquartered in Reading, UK.

Altitude Angel’s developer platform is open and available to all at


For further information please contact:

Stephen Farmer, Altitude Angel, Head of Corporate Communications & PR

+44 (0)118 391 3503

[email protected]