U-Space Concept of Operations: A Key Enabler for Opening Airspace to Emerging Low-Altitude Operations

Abstract

Opening the sky to new classes of airspace user is a political and economic imperative for the European Union. Drone industries have a significant potential for economical growth according to the latest estimations. To enable this growth safely and efficiently, the CORUS project has developed a concept of operations for drones flying in Europe in very low-level airspace, which they have to share that space with manned aviation, and quite soon with urban air mobility aircraft as well. U-space services and the development of smart, automated, interoperable, and sustainable traffic management solutions are presented as the key enabler for achieving this high level of integration. In this paper, we present the U-space concept of operations (ConOps), produced around three new types of airspace volume, called X, Y, and Z, and the relevant U-space services that will need to be supplied in each of these. The paper also describes the reference high-level U-space architecture using the European air traffic management architecture methodology. Finally, the paper proposes the basis for the aircraft separation standards applicable by each volume, to be used by the conflict detection and resolution services of U-space.

1. Introduction

Over the last century, the development of aviation has fundamentally changed the way we live, work, and travel. During this time, aviation has never ceased to innovate, and while traditional manned air traffic continues to grow, aviation is once again taking a significant step forward with the advent of new technologies and new types of airspace user, such as unmanned aircraft systems (UASs), also known as drones.

This emerging ecosystem, based on a new class of aircraft and new types of operation, will soon allow us to benefit from several new services and integrated air-ground transport solutions. The UAS industry has a significant potential for growth, and it has been estimated that by 2050 the European drone sector will create more than 135,000 jobs and have an economic impact exceeding € 15bn per annum [1].

Opening the sky to these new classes of airspace user is thus a political and economic imperative for the European Union, which has defined the U-space Blueprint [2] to both enable the development of the drone industry in Europe and to ensure its safe and efficient operation [3].

Nowadays, the number of drone flights across a wide range of applications is rising under an initial regulatory framework where small drone operators only have regulated access to very low-level (VLL) airspace. This airspace already has several classes of user—military/police, helicopters, balloons, ultralights, hang-gliders, micro-lights, parachutists, and general aviation—operating in it today, and most future drone operations are also envisaged there. Therefore, a safe and equitable integration of current and future operations is essential, especially in the urban airspace and close to airports where the density and ground risks are expected to be higher [4].

U-space is a service-orientated concept to provide air traffic management (ATM) to drones and is described in detail in the SESAR roadmap for the safe integration of drones into all classes of airspace [5]. U-space services aim to promote the development of smart, automated, interoperable, and sustainable traffic management solutions, and they will be a key enabler for achieving this high level of integration. The most critical success factor for U-space operations will be the ability to identify solutions that allow UASs and all other airspace users (unmanned and manned) to operate safely, securely, sustainably, and efficiently in a managed and fully integrated airspace, preventing an undue impact on operations currently managed by ATM.

U-space must also address a variety of constraints to meet the requirements of “prioritised aviation”, such as security or emergency service helicopters. These challenging objectives can only be achieved through an evolutionary development process. This process will ensure the definition and timely deployment of appropriate, advanced, and interoperable U-space infrastructure. The deployment of the traffic management capabilities, including a new set of advanced services capable of fitting with planned/expected types of operation and levels of demand, is also important. Current standards, such as aircraft separation minima, will need to be revised. The automated nature of the U-space services brings new opportunities for managing a very high traffic demand, expected from the growth on the number of drone operations.

The main contribution of this paper is the development of a U-space concept of operations for drones flying in very low-level airspace, as produced by CORUS in consensus with the main stakeholders, with the aim of enabling the growth of the drone traffic safely and efficiently. In the safety area, other contributions are a new safety methodology and the revision of current separation standards. In the efficiency area, the main contribution is the detailed description of the U-space architecture using the European air traffic management architecture (EATMA) framework. These contributions are organized as follows: Section 2 describes the U-space concept of operations (ConOps) and the relevant airspace classification, the associated services, and how safety assessment is addressed. Section 3 presents the reference U-space architecture description, and Section 4 describes the foundations for the new separation standards to be used in conflict management and separation provision. The paper ends with conclusions and necessary future R&D work.

2. U-Space Concept of Operations for VLL

2.1. Background

The European Union has developed a vision called U-Space to facilitate the phased introduction of procedures and “a set of services designed to support safe, efficient and secure access to airspace for large numbers of drones,” to encourage the growth of the UAS industry, and the use of these aircraft in Europe. These services and procedures rely on a high level of digitization and automation of functions, whether they are onboard the drone itself, or are part of the ground-based U-space ecosystem.

U-space provides an enabling framework to support routine drone operations, as well as a clear and effective interface to manned aviation, air navigation service providers (ANSPs), and authorities. U-space should not, therefore, be considered a defined volume of airspace, segregated and designated for the sole use of drones, but an environment capable of ensuring the smooth operation of drones in all operating environments and all types of airspace—in particular but not limited to VLL airspace. It addresses the need to support all types of mission and concerns all drone users and categories of drone.

VLL airspace is that below the airspace normally used by air traffic flying with visual flight rules [6]. Although this airspace is usually empty, it is occasionally used for emergencies, take-off and landing, some high-precision aerial work, and training. In the near future, micro/small drones, such as those typically used for inspection, photography, or delivery tasks, will make major use of it.

The ConOps gives qualitative and quantitative details of how the U-space system should be used from a user’s perspective, and how it should behave. It describes how VLL airspace should be organized, what rules and regulations should be put in place to enable the safe integration of drones with other users of this airspace, and what U-space services should be available to help the drone user achieve this. In parallel with CORUS, a number of technological (DREAMS, IMPETUS, CLASS, TERRA, etc.) and demonstration (PODIUM, GOF, SAFEDRONE, etc.) projects were also lunched to test and develop new technologies and services for U-space. Most of them have been participating in the discussion that lead to the consensus of the U-space ConOps presented in this paper.

We see U-space as an environment that enables business activity related to drone use, while maintaining an adequate level of safety and public acceptance, and has developed the ConOps for VLL by considering the most promising use-cases of U-space.

Most drones fly today in visual line of sight (VLOS) operations where the remote pilot can see the aircraft. Beyond visual line of sight (BVLOS) operations, where the pilot cannot directly see the drone, are relatively rare, if not forbidden. However, BVLOS flights are expected to be the normal way of operating for many future commercial drone activities, such as delivery. According to the European ATM master plan [7], by 2035 the airspace will be about ten times busier than today, with a majority of aircraft being drones operating BVLOS. For this reason, the proposed ConOps is capable of working in both the short and long-term, focusing on current VLOS operations and the integration of BVLOS operations. It assumes a high demand for VLL airspace.

The ConOps development has been guided by the same set of five high-level principles that inspired U-space:

• Safety first: The safety assessment is fully addressed with a new proposed methodology.
• Open market: To create an environment where many businesses can operate, innovate, compete, and deliver cost-efficient services.
• Socially acceptable: To balance the commercial pressure for growth of drone use with the preservation of nature, people’s health, personal privacy, and European security. Social acceptance has been considered from the beginning of the ConOps design [8].
• Equitable access: All airspace users must be treated equitably, provided safety requirements are met. Exceptions will only apply to life-saving or other emergency-response flights.
• European-wide: The ConOps is designed to be applied throughout the member states of the European Civil Aviation Conference (ECAC), with minor adaptations.

The ConOps covers three main issues: a VLL airspace classification, a first refinement of U-space services, and an architecture definition.

2.2. Airspace Volumes and U-space Services

In accordance with the European Union drone regulations [9,10] that classify drone operations as open, specific, and certified according to their risk, the ConOps divides the whole VLL airspace into three different volumes, called X, Y, and Z. Motivations for creating these three different volumes include:

• The numbers of drone flights that are expected;
• The ground risk—whether the area is populated;
• The air risk—the number of other flights in the volume, either manned or unmanned;
• Nuisance, security, or other public acceptance factors;
• The U-space services that are needed to enable safe operation.

These X, Y, and Z volumes differ in two ways: the services being offered, and their access/entry requirements. The services offered limit the types of operation that are possible. In particular, the provision of conflict resolution services is the most significant difference between volumes. Conflict resolution, expanded in more detail below, is perhaps the primary purpose of U-space. Its aim is to reduce to an acceptable level the probability of a collision between drones or between a drones and manned aircraft. In X volumes, no conflict resolution service is offered and the remote pilot has full responsibility for ensuring safe operation. In Y volumes, only preflight (“strategic”) conflict resolution is offered, which means, in essence, that the operation plans are coordinated to avoid collision. In Z volumes, in-flight (“tactical”) conflict resolution is offered in addition to strategic, meaning information about the positions and motions of other aircraft is used to guide the drones so as to avoid conflict. This difference has a large impact on how drones should fly in these airspaces. The national aviation authorities, or delegated entities, will be in charge of defining the volumes and their limits. Figure 1 shows a possible design of the airspace using the three volumes.

2.2.1. X Volumes

There are few prior requirements on the operator, the pilot, and the drone for accessing airspace type X, but as a result few services are offered. In X volumes, the pilot remains responsible for separation at all times. VLOS flights are easily possible, as shown in Figure 2. Other types of operation in X require significant attention to air risk mitigation.

X volumes are expected in regions with both low demand for U-space services due to there being few flights and low ground and air risk. For instance, applicable regulations [9,10] describe the ground and air risk requirements for open category operations, and these conditions are expected to be commonly found in X volumes. In specific category operations, X volumes are most likely to be “ARC-b” and “rural” according to the specific operational risk assessment (SORA) [11] terms. However X is defined in terms of services offered, so this is only a probability rather than a general rule.

2.2.2. Y Volumes

Access to Y requires an approved operation plan. Y airspaces may have specific technical requirements attached to them—demonstrating that these being met is part of the operation plan approval process. These technical requirements will usually include a remote piloting station connected to U-space and a UAS capable of propagating its position report.

Y volumes facilitate VLOS and BVLOS flight. In Y volumes there are risk mitigation means provided by U-space that are not available in X. Effective use of these services will require the pilot to be appropriately trained. In Y airspace, conflicts between flights are resolved before take-off (see Figure 3). As there is no tactical (in-flight) separation service offered in this airspace, the preflight conflict resolutions will reduce the residual risk of collision to a very low level, which will result in widely spaced aircraft, in space and/or in time. In Y airspace there is traffic information, the provision of which requires that all aircraft in Y airspace are tracked. The Y airspace may have a minimum performance requirement for position reporting: in some areas the reporting of start-of-flight and end-of-flight may be sufficient.

Y volumes are expected in areas where the ground or air risk determined by a SORA or otherwise (including regulation) is too great for an X volume; for example, where there is significant air (drone) traffic or over a densely populated area. Y volumes may be created in response to significant demand to fly BVLOS operations.

Y volumes may also be created as a means of limiting access; for example, over a national park. In such cases, Y volumes may enforce the approved operation plan requirement, but due to unavailability of mobile internet, might not require a remote piloting station connected to U-space.

2.2.3. Z Volumes

Z volumes allow higher density operations than Y, and hence are expected in areas where traffic demand exceeds the capacity of Y, or where there is particular risk, such as urban areas, as shown in Figure 4.

As is the case for Y, access to Z requires an approved operation plan, and additionally:

• The continuous connection of the pilot to U-space;
• Additionally, to enable tracking, the submission of the position reports of the aircraft.

Z volumes facilitate BVLOS and automatic drone flight, and also allow VLOS. In Z there are more risk mitigation means provided than in Y or X. In Y volumes, the lack of tactical conflict resolution requires that strategic conflict resolution takes account of the residual risk due to wind, or other sources of perturbation to the flight. Hence, the traffic in Y is kept far apart. Z allows higher density operations than Y; residual risks remaining after strategic (preflight) separation can be reduced by tactical (in-flight) conflict resolution; hence, the residual risk after strategic conflict resolution need not be as low as in Y. Access to Z may have specific technical requirements attached to it. Demonstrating that these are met is part of the operation plan approval process.

Z volumes have a tactical conflict resolution service. The provision of this service is unique for a given volume; that is, only one entity is responsible for aircraft separation. When the separation is provisioned by U-space, the Z volume is named Zu. On the other hand, if air traffic controllers are in charge of providing the separation, then the volume is named as Za. Thus, a Za volume is controlled airspace [9,11] and use of U-space services will be limited to a subset of services; for instance, to enable communication and surveillance, but not for conflict resolution.

At the decision of the regulator:

• Zu may be created in uncontrolled airspace, in which case the tactical conflict resolution service provides advice.
• A Zu volume may be designated controlled airspace, in which case the U-space tactical conflict resolution service is considered to be an air traffic control service. Hence, in that volume, the U-space tactical conflict resolution service provides instructions which must be followed by all manned and unmanned aircraft.

The aeronautical information (including drone aeronautical information) for each Zu volume will make clear if it is controlled or uncontrolled airspace.

2.3. Refinement of U-Space Services

The ConOps has reworked the set of services slightly compared to U-space official documentation [2,5]. These services are all related to safety and/or security. There will be other U-space services which are business related. Such business related services are considered out of the scope of this paper.

Using the possible states given in

Table 1. Possible states of the U-space services.

Mandated	The service must be provided in the volume and must be used by any drone operator flying in that volume.
Offered	The service must be provided in the volume and may be used by any drone operator flying in that volume.
Optional	The service may be provided in the volume and may be used by any drone operator flying in that volume.
Where-available	The service may be provided in the volume and when it is provided then it must be used by any drone operator flying in that volume. Where-available should be understood as where-or-when-available.
No	Not available. Typically the reason of the non-availability of a service is the cost of its deployment.

, we provide the list of all the U-space services available in the each of the three proposed volumes. This list has been divided in two tables:

Table 2. U-space services and volumes (not in-flight).

SERVICE	X	Y	Z
Registration	Mandated	Mandated	Mandated
Geo-awareness	Mandated	Mandated	Mandated
Weather information	Mandated	Mandated	Mandated
Other information services 1	Optional	Optional	Where-available
Drone operation plan processing	Optional	Mandated	Mandated
Strategic conflict resolution 2	No	Mandated	Mandated
Dynamic capacity management 2	No	Where-available	Mandated
Procedural interface with ATC 2	Where-available	Where-available	Mandated
Incident/accident reporting	Mandated	Mandated	Mandated
Digital logbook	Where-available	Where-available	Mandated

¹Other information services include the services providing information and real-time data on geospatial, electromagnetic interference, population density pap, navigation coverage, and communication coverage. ² These services may not be offered at first. They are expected by the time Z volumes exist.

and

Table 3. U-space services and volumes (in-flight).

SERVICE	X	Y	Z	Remarks
e-Identification	Mandated	Mandated	Mandated	Used by law enforcement
Geo-fencing provision	Mandated	Where-available	Mandated
Position report submission	Optional	Where-available	Mandated	See note 3
Tracking	Optional	Where-available	Mandated	See note 4
Traffic information	Optional	Mandated	Offered	See note 4
Monitoring	Optional	Where-available	Mandated	See note 4
Other information services1	Optional	Optional	Where-available
Emergency management1	Where-available	Where-available	Mandated
Legal recording1	Where-available	Where-available	Mandated
Collaborative interface with ATC2	Where-available	Where-available	Mandated
Tactical conflict resolution	No	No	Mandated

¹ These services may not be offered at first. They are expected by the time Z volumes exist. ² Other information services include the services providing information and real-time data on geospatial, electromagnetic interference, population density map, navigation coverage, and communication coverage. ³ In X volumes position report submission is not required but may occur. In Y volumes it is expected when feasible. ⁴ Traffic information depends on monitoring and tracking of other flights. Monitoring depends on tracking, and tracking depends on position report submission.

.

Table 2 lists the services that are generally used before or after flight and thus are not considered to depend on mobile internet connectivity. A brief description of the listed services and of their provision follows:

• Registration is the initial service, from which the U-space is receiving the information about drones, pilots and operators.
• Geo-awareness, as described in regulations [9,10], is a drone capability. The U-space geo-awareness service provides data that allows this capability to operate. A service equivalent to the geo-awareness capability of drones may be provided by the U-space monitoring service, but only for drones that are being tracked by U-space.
• Drone aeronautical information and weather information services are mandated in all volumes, while other information services, such as the terrain mapping, building and obstruction mapping, and population density mapping, are optional. All require standards for data exchange in digital format. The quality and type of the information available may vary, especially in the non-mandatory services, but it must be indicated to the consumer of the service, in order to evaluate the suitability for final use.
• Drone operation plan processing requires the submission of the flight intention in anticipation of the flight. The processing of all the requested flight intentions detects potential conflicts that the strategic conflict resolution service must address and solve. Both are mandated in volumes Y and Z. In X volumes, the submission of the drone operation plan is highly recommended, but since it is not mandatory, no conflict resolution will be provided here.
• Dynamic capacity management is a potential solution for strategical conflict resolution, especially in areas where traffic density is expected to be high, and for this reason it is mandated in volume Z. The provision of the dynamic capacity management service is at the discretion of the airspace authority concerned for Y. On the other hand, the tactical conflict resolution service is offered by the U-space in Zu and by air traffic services (ATS) in Za, although the deployment calendar of both is quite different.
• Procedural interface with ATC is a preflight service providing the rules for interfacing drones with air traffic control (ATC). This service is mandated in Z volumes; for instance, when submitting operation plans that enter airspace controlled by ATC (Za). But procedural interface with ATC shall also be used for X and Y volumes where it is available. This will be the case of volumes in proximity to controlled areas, where ATC may request a drone’s flight information to increase situational awareness.
• Incident/accident reporting is the service that receives reports describing dangerous situations collected by drone operators and stores them for further analysis, and the digital logbook service stores all the essential data of each flight. Both services are always mandated, with the exception that the digital logbook service may not be available in volumes X and Y due to the high cost of its provision.

Table 3 lists services that are generally used in flight and whose availability may be dependent on mobile internet connectivity of the remote piloting station or drone. Such services cannot be mandated in remote areas. A brief description of the listed services and of their provision follows:

• e-Identification is the service that accesses the information from the drone remote identification, which is described in regulations [9,10] as the drone capability to broadcast its identification, and is mandatory for Open operations (with the exception of toy drones) [12]. This service, as with registration, is always mandatory.
• Geo-fencing provision is a service that can be provided to the drone operator, remote piloting station, or directly to the drone. This service is considered very relevant for safety in X volume, and is mandatory in Z volume. In Y volumes, the service is less important, as an operation plan is required and this plan can be checked against known geo-fences during operation plan processing. But still it must be used by the drone when it is available.
• Position report submission may be offered in X volume, and when it is available, flights are encouraged to make use of it in order to warn other airspace users of their presence. Y volumes may exist in remote areas with poor mobile internet coverage. In such cases services during flight cannot be mandated—hence, they are optional or where-available. Y volumes in which a position reporting service is available may have a minimum standard of position reporting, specifying rate and precision.
• Tracking is required in Y when available to improve traffic information. Both monitoring and traffic information will be of limited use in X volumes, as not all aircraft are tracked. Other information services, as before, are mainly optional.
• Emergency management is an important service for the delivery of urgent information to the remote pilot. Emergency management must be made available as soon as possible in all volumes, and operators must connect to it when it is available. Without emergency management, the Z volume is not possible. In X or Y, where there is a known absence of mobile internet or other communication infrastructure, operations should take this lack of communications into account.
• Legal recording will only contain traces of operational declarations and position reports, and hence, not all flights in X. The same limitations hold in X for the digital logbook service.
• Collaborative interface with ATC is offered to flights that enter airspace controlled by ATS, submitting operation plans.
• Finally, tactical conflict resolution is only available and mandated in volume Z. It is described in more detail in Section 4 together with strategic conflict resolution and the separation standards in each volume.

2.4. Methodology for U-Space Safety Assessment

The ConOps includes a methodology for U-space safety assessment (MEDUSA), to identify and mitigate relevant risks of drone operations supported by U-Space services. The MEDUSA methodology aims to integrate the principles of the SESAR safety reference material [8,13], which looks at the overall airspace system, with those of the SORA approach that are focused on single-mission risk assessment. MEDUSA follows a holistic approach by not only considering the operators’ viewpoint (as proposed in SORA) but by extending the scope to airspace safety. The airspace safety assessment takes into account, among other sources of information, the airspace design, the ATS service provision, and the available U-space services. In brief, the MEDUSA methodology’s identification and evaluation of risks involves two different approaches adopted from the SESAR safety reference material, called the “success” and “failure” approaches. The “success” approach evaluates what requirements or mitigation means are necessary to reach the required level of safety in the volume of airspace considered. In this case, the positive contribution of U-space to aviation is addressed by assessing how effective these U-space services would be when everything is working as intended. Hence, existing risks or those implicit to aviation will determine the attainable target safety level. Additionally, the “failure” approach assesses system-generated risks of the U-Space services, including systems and procedures. This could be seen as the negative effect of U-Space on the risk of an accident. For instance, Nguyen et al. [14] measure the degradation of the link performance at a $10\%$ capacity reduction for high-density VLL using cellular connectivity. Together with any possible malfunctioning of the drone, this could provide valuable input to the “failure” approach, considering that the SORA assessment focuses on the drone operator/pilot viewpoint. MEDUSA includes a process for integrating individual SORA assessments, to help obtain an insight from multiple SORA assessments sharing the same volume of airspace.

3. U-Space Architecture

Digitization is a cornerstone to deliver a fully scalable traffic management system, capable of handling growing air traffic, both manned and unmanned. The U-space architecture aims to defining the parts of such a system and their relationships. The ConOps includes a description of the U-space architecture for very low-level operations developed from a business and operational viewpoint. As a secondary objective, the U-space architecture provides an overview of the services and systems for supporting a bottom–up coherence of the ConOps.

The main achievements of the architecture proposed are:

• The consolidation, in close cooperation with the SESAR joint undertaking of principles that underpin the U-space architecture definition and then drive the implementation of U-space services.
• The selection of a suitable architecture framework to support concurrent and multinational architecture development and publishing. This is based on the European air traffic management architecture (EATMA) framework, already adopted for ATM in SESAR projects.
• The development of architecture artefacts to describe the U-space capability model, the operational process model, service catalogues, and any possible system breakdown unambiguously.

Figure 5 shows the main principles used in designing the U-space architecture. The following set of principles, agreed with the U-space community, were selected to guide the design of the architecture.

• Service oriented architecture: To ensure that the solutions built are based on a set of services with common characteristics.
• Safety focused: The architecture must always consider the safety of its stakeholders and of other people and places that may be affected by U-space operations.
• Standard-based: The interfaces should be defined and based on open standards.
• Open: The system architecture should be component-based and rely on published or standardized interfaces to make adding, upgrading or swapping components easier during the lifetime of the system. Some other expected benefits of an open architecture are to facilitate reuse, to increase flexibility, to reduce costs and time to market, to foster competition, to improve interoperability, and to reduce risks.
• Modular: The architecture should be composed of self-contained elements that contain a meaningful set of functionalities with their required inputs/outputs, and that can be reused or replaced.
• Interoperable: To facilitate homogeneous and non-discriminatory global and regional drone operations.
• Technology agnostic: To allow platform independent design, the architecture should be described independently of later implementation specifics, e.g., platforms, programming languages, and specific products, which must be consistent with the operational architecture.
• Based on evolutionary development (incremental approach): Architecture work is an incremental and iterative process, building upon the previously consolidated baseline.
• Automated: To facilitate the delivery of safe and secure U-space services with a high degree of automation of the processes.
• Allowing variants: The architecture work should allow variants and alternative solutions to be described. The principles listed in this document aim to ensure interoperability between different implementations.
• Deployment agnostic: Architecture work must not impose constraints and must allow different deployment choices according to the established business and regulatory frameworks.
• Securely designed: Architecture work should address security issues such as cyber-security, encryption needs, and consequences, and stakeholder authentication. The principles of the system wide information management (SWIM) must be followed; i.e., use of a central or federated public key infrastructure for identity management.

Figure 6 shows the U-space operational stakeholders that are expected to be part of the core business of U-space. Some on this list are direct stakeholders, such as the drone operators, the U-space service providers, and the authorities. Others are ATM-related stakeholders, such as aerodrome operators and ANSPs. Additionally, in Figure 6, the notion of U-SWIM (SWIM for U-space) appears. For the moment, this is simply the idea of providing quality information to the right people with the right systems at the right time. This could be achieved through common infrastructure, shared data, and selected stacks of protocols that will help to easily integrate and interoperate for the different stakeholders and with SWIM in the ATM context.

As mentioned above, EATMA has been used as the architectural framework for the ConOps. The selection of EATMA was supported by its already following the same principles required for designing the U-space architecture (Figure 5) and its being the architectural framework already used in ATM R&D programmes in Europe. The integration of the U-space architecture with the ATM architecture will be effortless if both architecture are based on the same “language.” EATMA consists of six architecture layers whose purpose is to provide a natural division of the architecture in different views that together provide a complete view of the U-space enterprise:

• Program layer: provides a project management point of view with the description of solutions and their development roadmap.
• Capability layer: describes U-space’s abilities. It can be understood as the strategic layer.
• Operational layer: helps to better describe the concepts and shows how the different actors collaborate.
• Service layer: contains the services, which act as link between the operational needs and the technical solutions.
• System layer: describes all human and technical resources and how they work together.
• Standard layer: contains the standards, protocols, and regulation needs.

Since EATMA, in its working repository web portal, shows all the architecture designed in collaboration with other U-space projects, a brief description of the EATMA layers used in the context of the ConOps and some examples of their elements are given here.

• Capability Layer

The capability layer can be seen as the strategic level in which the abilities are described. The capability model of U-space is aligned with the ICAO operating modules and the ATM capability model. The U-space capability model aims to describe the whole of U-space considering its abilities.

• Operational Layer

The operational layer contains the elements needed to describe the operational concepts and is independent from any physical implementation. It includes descriptions of how actors collaborate. An example of how some of the U-space actors collaborate can be seen in Figure 7 (high level view). This diagram does not aim to describe how all U-space actors exchange information, but just a limited set of them.

• Service and System Layers

The system layer describes all the human and technical resources of a system, including its internal functional breakdown and its interactions with surrounding systems. These interactions can be called services. Figure 8 shows a possible service provision between U-space technical assets.

In addition to the interaction between assets, the system layer also describes how the systems are composed.

4. Conflict Management in U-space

In ATM conflict management is the process reducing the possibilities of an encounter between aircraft in controlled airspace. This section focuses on two important components of conflict management: the conflict detection and the conflict resolution. Conflict detection is the process occurring in controlled airspace of alerting when two aircraft are too close; that is, near to a loss of separation (aircraft separation distance is lower than a defined separation standard). Conflict resolution is the process to recover the safe separation and is also known as deconfliction. Both components are present in the two U-space services listed in Section 2: strategical conflict resolution and tactical conflict resolution.

Strategic deconfliction is the ability to plan operations before flight to avoid conflict with other users’ operations. U-space provides this capability with the strategic conflict resolution service in volumes Y and Z.

Tactical deconfliction is the ability to provide live alerts when boundaries/protection areas between tracked drones intersect. It also offer alternative flight paths in real-time, enabling pilots to avoid in-air collisions. U-space provides this capability with the tactical conflict resolution service in volume Z. Tactical conflict resolution service will also help to deconflict drones against manned cooperative aircraft with transponders, as well as non-cooperative drones flying in the vicinity of the specific drone surveillance network of the volume Z.

The inability of current drone technology to be able to properly manage “the unexpected”, such as manned aircraft, drones, and obstacles, or airspace closures which were not foreseeable before the flight happened, should be widely considered as an important showstopper for automated drones flying BVLOS. In practice, the tactical conflict resolution service should provide information to drone pilots or the drone itself to ensure that a proper separation is maintained during the in-flight phase. The drone surveillance system will continuously monitor the airspace around a drone looking for the “unexpected”, such as other aerial vehicles or changes to airspace (e.g., a temporary flight restriction or a dynamic geo-fence around in a certain area). After identifying a potential conflict, tactical conflict resolution service will make the necessary routing adjustments via instructions or alerts which are communicated to the pilot in command or to the drone’s control software, allowing the drone to maintain an appropriate distance between other airspace users or fly around restricted airspace so it can continue safely to its destination. Tactical deconfliction is intended to supplement any on-board sense-and-avoid technologies, which usually only operate in close proximity to other air traffic.

Typically, in non-segregated controlled airspace, radar systems are used to track aircraft trajectories, while air traffic controllers provide separation services. This is also applicable to U-space Za volumes, but not to Zu. In a U-space Zu volume, this service is implemented on the ground and not as a distributed function within the aircraft, which is considered to detect and avoid. The tactical conflict resolution service has no human in the loop.

In uncontrolled airspace, tactical deconfliction follows the remain well clear ICAO statement [11]: “An aircraft shall not be operated in such proximity to other aircraft as to create a collision hazard”. Pilots are responsible for remaining well clear. Similarly, in X and Y U-space volumes, where no tactical conflict resolution service is provided, pilots are responsible for remaining well clear.

Collision avoidance is the ability to prevent a mid-air collision as part of a last course of action. It applies only if the previous layers of conflict management fail in the provision of separation. In U-space, the collision avoidance layer is implemented with detect and avoid systems. Novel approaches, such as Hear&Avoid [15], are being tested for drones flying at the VLL based on other sensors. Detect and avoid is out of the scope of this paper.

4.1. Separation Standards in Za Volumes

Unmanned aircraft are typically much lighter and slower than traditional manned aviation, with wielding kinetic energies many orders of magnitude less than a typical airliner; as such, the separation standards could be quite different from those currently in existence for manned aircraft. Nevertheless, since separation services are provided by air traffic controllers, and they, as humans, have a limited capacity to simultaneously manage a high number of aircraft, we propose to the keep current manned aviation separation standards in Za volumes. Previous research [16] demonstrated that air traffic controllers could manage the separation of one remotely piloted aircraft from manned traffic with no significant increase of their workload. Still, more research is needed to check whether the increasing mix of aircraft types with different performances keeps the workload in the safety limits. The growing diversification of aircraft types (very light jets and super heavy aircraft) is also one of the reasons which led ICAO, FAA, and EUROCONTROL starting the initiative for the recategorization of the wake vortex categories and their related aircraft separation distances, with supporting studies such as the work by Holzapfel et al. [17]. Further studies on wake vortex separation shall also include drones, because their small size and weight may be badly affected by the wake vortex of landing aircraft in a Za volume inside an airport.

To enter a Za volume, unmanned aircraft must comply with requirements of equipment, such as the barometric altimeter, transponder, or radio, and performance.

4.2. Separation Standards in Zu Volumes

The proposal for separation provision in a U-space controlled volume Zu is based on the bubble concept, a concept originally named Aircraft Safety Bounds [18], as shown in Figure 9. In the absence of a human controller, a new separation model, with different minima for any pair of aircraft, is possible, thanks to the capabilities of the unmanned aircraft and U-space automation and communication.

New separation minima adapt to each aircraft and its individual performance model [19]. The separation between any two aircraft is determined by creating a virtual bubble around each aircraft and ensuring that these bubbles never overlap. The shape and size of the bubble is dynamic and not necessarily isotropic. At any moment, for any aircraft, the bubble is a function of factors, such as the frame characteristics, external factors, or communication delays. The detailed list of them follows:

• The size and weight of the aircraft;
• The instantaneous velocity of the aircraft;
• The performance of the aircraft navigation system;
• The performance of communication with U-space;
• The performance of the U-space surveillance function;
• The risk of aggravating the hazard of any collision coming from features of the aircraft (e.g., high mass, flammable fuel), its cargo or the presence of passengers;
• The risk of aggravating the hazard of any collision associated with the ground being overflown or other airspace users flying below;
• The weather conditions.

The greater the risk (speed, mass, passengers on board, etc.), the larger the safety bubble. The same applies to uncertainties and latencies, which directly affect the bubble size. Some of these factors are fixed for the whole flight (i.e., the size of the aircraft), but most of them, e.g., speed, weather, or the quality of the navigation signal, can change during the flight. The idea of the bubble is intrinsically dynamic and considers all of these aspects in real time. Fast communications and rapid calculations, provided by U-space computers, will detect probabilities of bubble overlapping and return automated advisories to the aircraft pilots involved (remote or not).

The bubble concept results in a non-fixed separation distance, calculated by a formula proposed by the regulators, using inputs from different sources. For instance, aircraft manufacturers will provide the aircraft performance parameters. Further extensive research is needed to propose a formulation for bubble separation and to tune the appropriate time to advisory and time to resolution. For instance, work in [20] derives a set of separation rules that can be applied by the tactical conflict resolution service in real-time.

4.3. Deconfliction in Y Volumes

In uncontrolled areas, separation is not fixed, and the poor visibility of small UAS makes visual separation (remain well clear) a very difficult task for pilots [21]. For this reason, we propose the same bubble-based separation concept for Y volume, but in this case as part of the strategic conflict resolution service. The uncertainties involved before flight will be solved by applying larger and longer (time) bubbles. For this, preflight trajectory sharing will be mandatory in the low traffic densities of Y volumes. Preflight trajectory sharing will be also mandatory for Z volumes, so manned aircraft aiming to enter volumes Y and Z will be able to check the expected unmanned traffic in the volumes in advance.

4.4. Deconfliction in X Volumes

Bubble separation will not apply in X volumes, where the few unmanned aircraft will remain well clear of each other. In any X volume, it is assumed that there are no other manned aircraft nearby. In an emergency, the emergency management service will notify it and give the emergency the right of way.

5. Conclusions

This paper presents an initial concept of operations for drone flight in very low-level airspace. It provides a definition of U-space as a set of services required for safely and efficiently integrating drones into the airspace that they share with manned aviation. It defines three different types of airspace volume, primarily defined by the conflict resolution available in them. The paper briefly presents MEDUSA, which has combined the SORA risk analysis method with the SESAR Safety Reference Material. An additional important output is the description of the U-space architecture using the EATMA framework, looking at which services need to be supplied by an ANSP, which by a local authority, and which by a U-space service provider. Finally, the ConOps view of separation provision has been described.

But this is not the final definition of a U-space ConOps. The concepts proposed need to be validated, and although produced in collaboration with a wide scope of concerned stakeholders, require much more work to ensure the safety of all airspace users, and people and infrastructure on the ground. In addition, the growing concept of urban air mobility and the ConOps of drones flying above VLL, in a challenging airspace type such as class G, have not been treated in the presented U-space ConOps. We have a long way to go before a fully validated concept of operations allows drones to fly safely in an integrated airspace.