EXPLORATORY RESEARCH

U-space Concept of
Operations
D6.3 CO
CORUS
Grant: 763551
2016 SESAR 2020 RPAS Exploratory Research Call
Call:
(H2020 – SESAR -2016-1)
Topic: Topic 01: SESAR UTM Concept Definition
Consortium coordinator: EUROCONTROL
Edition date: 25th October 2019
Edition: 03.00.02
 EDITION 03.00.02

Authoring & Approval

Authors of the document

Name/Beneficiary Position/Title Date
Andrew Hately / EUROCONTROL WP6 lead / Editor of the document
Andres Van Swalm / Unifly CORUS team
Andreas Volkert / DLR WP3 lead
Anthony Rushton / NATS WP2 lead
Arnau Garcia / HEMAV CORUS team
Catherine Ronfle-Nadaud / DSNA CORUS team
Cristina Barrado / UPC WP4 lead
Daniel Bajiou / HEMAV CORUS team
David Martin / EUROCONTROL CORUS team
Davide Del Vecchio / ENAV CORUS team
Dominic Colin / EUROCONTROL CORUS team
Ellen Malfleit / Unifly WP7 lead
Enric Pastor / UPC CORUS team
Giancarlo Ferrara / EUROCONTROL CORUS team
Koen Williame / Unifly CORUS team
Luca Bellesia / EUROCONTROL WP1 lead
Luigi Brucculeri / ENAV (Technosky) WP5 lead
Mario Boyero Pérez / EUROCONTROL CORUS team
Peter Hullah / EUROCONTROL CORUS team
Ralf Heidger / DFS CORUS team
Yannick Seprey / DSNA CORUS team
Other CORUS team members

Reviewers internal to the project

Name/Beneficiary Position/Title Date
Philippe Rapp DGAC 05/08/2019
Steve Bancroft EUROCONTROL Airport team 16/07/2019

2 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

Reviewers external to the project

Name Position/Title Date
N Hasvoets et al Drone team at EDA 20/06/2019
A Sobchenko & P Alty EUROCONTROL & PODIUM consortium 19/07/2019
M Sanchez et al CRIDA & CORUS advisory board 26/07/2019
K Engelstad et al Drone team at EASA 31/07/2019

Approved for submission to the SJU By - Representatives of beneficiaries involved in the project
Name/Beneficiary Position/Title Date
Ralf Heidger / DFS DFS point of contact 30/08/2019
Robert Geister / DLR DLR point of contact 03/09/2019
Catherine Ronfle-Nadaud / DSNA DSNA point of contact 05/09/2019
Luigi Brucculeri / ENAV (Technosky) ENAV point of contact 02/09/2019
Luca Bellesia / EUROCONTROL CORUS Project coordinator 03/09/2019
Carlos Farraz / HEMAV HEMAV point of contact 03/09/2019
Anthony Rushton / NATS NATS point of contact 30/08/2019
Andres Van Swalm / Unifly Unifly point of contact 02/09/2019
Enric Pastor / UPC UPC point of contact 02/09/2019

Document History
Edition Date Status Author Justification
rd
03.00.00 3 September Approved by AH / all Approval info added. This version delivered to
2019 consortium SJU.
03.00.01 25th Sept 2019 Release AH / CB Added reference [32], updated 4.7 and Annex I.
candidate This version is marked DRAFT as it has not yet
been approved by SESAR Joint Undertaking.
03.00.02 22rd October Approved by SJU Incorporation of SJU comments.
2019

CORUS
CONCEPT OF OPERATIONS FOR EUROPEAN UTM SYSTEMS, FINAL VERSION

© – 2019 – CORUS consortium except as noted. 3

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

This document is part of a project that has received funding from the SESAR Joint Undertaking under
grant agreement No 763551 under European Union’s Horizon 2020 research and innovation
programme.

Abstract

This Concept of Operations (ConOps) for U-space is the final version produced by the EU Horizon2020-
funded CORUS R&D project, published on 30th September 2019.

This volume is a reference manual and is the second of three parts of the ConOps; the first part being
the extended overview and the third being a collection of annexes that give further explanation of the
ConOps and how it can be applied.

The ConOps describes from a users’ perspective how operations should occur in Very Low Level (VLL)
airspace, supported by U-space. The first part of this reference manual introduces the ConOps,
describes the scope of the work, the foundations on which it is built, the assumptions of the authors,
the approach taken and the guiding principles. The following section (3) describes operations and the
operating environment, explaining the airspace structure. This is followed by a discussion of safety and
social acceptability. Section (5) describes the U-space services, explaining how they are used in the
environment described earlier.

The key elements of the ConOps are the definition of three different types of airspace volume, named
X, Y and Z. The number and nature of the U-space services differ in the three volumes and as a result
the density and complexity of the operations that can occur differs in each. The intention is that the
airspace will be divided into X, Y and Z in function of the air risk, ground risk, the traffic demand and
other factors, and thus the cost and complexity of providing and using U-space services will be
proportionate to the need that they be used.

The ConOps elaborates the U-space services and proposes how they be used in combination to achieve
safety, public acceptance and efficient operation.

4 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

1 Table of Contents

1 Summary ................................................................................................................. 8
1.1 Context, Aim of this work ............................................................................................... 8
1.2 Structure of this document ............................................................................................. 8
2 Background Framework, Assumptions ...................................................................... 9
2.1 Relation with the framing regulation ............................................................................. 9
2.2 Safety, the risk approach, SORA ................................................................................... 10
2.2.1 What is SORA .............................................................................................................................10
2.2.2 Discussion of the integration of the SORA into the CORUS ConOps..........................................10
2.2.3 Safety Assessment methodology within U-space ...................................................................... 11
2.3 U-space......................................................................................................................... 12
2.4 Area of interest of VLL U-space .................................................................................... 13
2.5 Assumptions & definitions ........................................................................................... 14
2.5.1 Definition of Very Low Level, VLL...............................................................................................14
2.5.2 Altitude, North ...........................................................................................................................15
2.5.3 Types of Operation ....................................................................................................................17
2.5.4 Detect and Avoid .......................................................................................................................18
2.5.5 EASA Categories of operation .................................................................................................... 19
2.5.6 Drone use in VLL ........................................................................................................................20
2.5.7 The scale of the problem ...........................................................................................................20
2.6 Overall Approach.......................................................................................................... 21
2.6.1 Risk based .................................................................................................................................. 21
2.6.2 Performance based ....................................................................................................................21
2.6.3 Stepwise ..................................................................................................................................... 21
2.6.4 Validation based ........................................................................................................................21
2.7 High level principles ..................................................................................................... 22
2.7.1 Safety first ..................................................................................................................................22
2.7.2 Open market .............................................................................................................................. 22
2.7.3 Social Acceptance ......................................................................................................................22
2.7.4 Equitable access .........................................................................................................................22
2.7.5 ECAC wide ..................................................................................................................................22

3 Airspace rules and procedures ............................................................................... 23

3.1 Volumes ....................................................................................................................... 23
3.1.1 The three types of airspace volume and the services provided in each .................................... 23
3.1.2 The services available in the different Volumes ........................................................................ 25
3.1.3 Drone operations in the different volumes ............................................................................... 27
3.1.4 Drone capabilities required in different volumes ......................................................................28
3.1.5 Access & Entry conditions ..........................................................................................................29
3.1.6 Airspace Assessment..................................................................................................................32
3.1.7 Summary of volumes, uses and operations ............................................................................... 33
3.1.8 Comparison of X, Y & Z Volumes and other models of the airspace .........................................34
3.2 Operational Practice including Rules of the Air and Flight Rules .................................. 34
3.2.1 Rules of the Air...........................................................................................................................34
3.2.2 Specific and General Flight rules in VLL .....................................................................................35
3.2.3 Avoidance of collisions ...............................................................................................................35

© – 2019 – CORUS consortium except as noted. 5

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

3.3 Spacing & Conflict Resolution ....................................................................................... 35

3.3.1 The impact of Weather on Drone Spacing ................................................................................. 36
3.3.2 Required U-space Navigation Performance - RUNP ..................................................................36
3.3.3 Conflict management.................................................................................................................37
3.3.4 Examples of separation in Use Cases .........................................................................................38
3.3.5 U-space usage model - summary ............................................................................................... 39
3.3.6 Prioritisation ..............................................................................................................................41
3.3.7 Reasonable time to act ..............................................................................................................42

4 Safety & Social aspects ........................................................................................... 43

4.1 Ground risk terms ......................................................................................................... 43
4.1.1 Ground risk ................................................................................................................................ 43
4.1.2 Airport related risk .....................................................................................................................43
4.2 Privacy, Confidentiality and Electronic conspicuity ...................................................... 44
4.2.1 Privacy of citizens and confidentiality of DRONE OPERATIONS ................................................. 44
4.2.2 Electronic conspicuity in U-space ..............................................................................................45
4.3 Contingency.................................................................................................................. 46
4.3.1 Mitigation: .................................................................................................................................46
4.3.2 Contingency plan: ......................................................................................................................46
4.3.3 Emergency: ................................................................................................................................47
4.3.4 Contingency plans for drones ....................................................................................................47
4.3.5 Contingency plans for U-space services ..................................................................................... 48
4.4 Accident and Incident Investigation ............................................................................. 49
4.4.1 Additional events to be reported............................................................................................... 49
4.4.2 Proposed changes for reporting to responsibilities ...................................................................51
4.4.3 Proposed changes for practices and reporting repository ........................................................51
4.5 Uncooperative Drones .................................................................................................. 52
4.6 Cyber security of U-space ............................................................................................. 53
4.7 Best practices ............................................................................................................... 54
5 Services and High Level Architecture ...................................................................... 56
5.1 U-space services ........................................................................................................... 56
5.1.1 Identification and tracking ......................................................................................................... 56
5.1.2 Airspace management / Geo-Awareness .................................................................................. 62
5.1.3 Mission management ................................................................................................................65
5.1.4 Conflict management.................................................................................................................71
5.1.5 Incidents and Emergencies ........................................................................................................72
5.1.6 Monitoring .................................................................................................................................73
5.1.7 Environment .............................................................................................................................. 75
5.1.8 Interface with ATC .....................................................................................................................76
5.2 Architecture (high level) ............................................................................................... 76
5.2.1 Architecture principles ...............................................................................................................76
5.2.2 Architecture Framework ............................................................................................................ 77
5.2.3 Stakeholders and Roles ..............................................................................................................78
5.2.4 Operational processes and Information Exchanges ..................................................................81
5.2.5 A generic system breakdown ..................................................................................................... 82
5.2.6 U-space Portal ............................................................................................................................84

6 Terms and acronyms, References ........................................................................... 85

6 © – 2019 – CORUS consortium, except as noted
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

6.1 Terms and acronyms .................................................................................................... 85

6.2 References .................................................................................................................... 88

List of Tables
Table 1 Traffic projections 21
Table 2 U-space services offered in different airspace types 27
Table 3 Possible prioritisation 41
Table 4 Ground risk terms 43
Table 5 Airport related area terms 43
Table 6 Contingency plans for U-space services 49
Table 7 Summary of e-Registration 57
Table 8 Geo-awareness service Roles and Actions 64
Table 9 Mission management specific terms 65
Table 10 Drone Operation Plan Processing service Roles and Actions 68
Table 11 Terms and Acronyms 88

List of Figures
Figure 1 U-space levels, from the U-space Blueprint 13
Figure 2. An overview of the various vertical datums and vertical measurements 16
Figure 3 X, Y and Z volumes 33
Figure 4 The relationship between Mitigation, Contingency and Emergency 46
Figure 5 U-space services 56
Figure 6 Example trajectories 69
Figure 7 Stakeholders 78
Figure 8 information exchanges, informal presentation 82
Figure 9 Generic U-space system breakdown 83

© – 2019 – CORUS consortium except as noted. 7

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

1 Summary
1.1 Context, Aim of this work
The CORUS project exists to write a Concept of Operation (ConOps) for U-space (UTM in Europe). The
project is undertaken for the SESAR Joint Undertaking in the context of the SESAR2020 exploratory
research programme, and is partly funded by Horizon2020 grant 763551.

The project is developing this ConOps iteratively. The first version was released in June 2018.
Comments on the first version have been received and these have led to this second version, released
in March 2019. Comments on this version will lead to the third and final version in the lifetime of the
CORUS project, which will be released in September 2019.

It is stressed that CORUS is an exploratory research project. While this CONOPS has been produced
by experts in many fields of aviation operations and safety, it has not yet been validated (see section
2.6.4) and must not be considered an operational document.

1.2 Structure of this document

The ConOps version 2 is composed of three parts. It is structured in this way for ease of use both at
the management and expert level.

Part 1 – U-space Extended Overview providing an extended summary of the U-space ConOps.

Part 2 – U-space Operational Concept Description providing a reference manual of U-space

operations and environment.

Part 3 – U-space ConOps Annexes

The present document is Part 2. As this is a reference manual, it is concise but is not particularly easy
to read. To get a better understanding of how the different parts of what are described here fit
together, please consult Part 1, the extended overview, and then Part 3, the Annexes, in particular the
use cases. These use cases refer back to specific sections of the reference manual.

8 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

2 Background Framework, Assumptions

From Wikipedia [49] it is clear there are a number of broadly similar descriptions of a ConOps which
may differ in their precise details. This document is in line with the opening paragraph which states:
A concept of operations (abbreviated CONOPS, CONOPs, or ConOps) is a document describing the
characteristics of a proposed system from the viewpoint of an individual who will use that system such
as a business requirements specification or stakeholder requirements specification. It is used to
communicate the quantitative and qualitative system characteristics to all stakeholders.

This document is a Concept of Operation for U-space, which is defined in the U-Space Blueprint [6] as
“…a set of new services and specific procedures designed to support safe, efficient and secure access
to airspace for large numbers of drones” which we equate to UAS Traffic Management in Europe.

2.1 Relation with the framing regulation

This is a ConOps for U-space, the UTM system in Europe. This ConOps has been built taking into
consideration conceptual elements introduced by the European Union’s (EU) regulations, such as
classification of drone operations and the requirements for those operations.

The CORUS ConOps can be taken as input for defining the evolution of the framing regulation for the
management of UAS traffic.

In June 2019, two regulations were published on drone use in Europe [1] and [2]. During the
development of these regulations CORUS has been following European Aviation Safety Agency’s (EASA)
work. This ConOps is in line with these regulations..

A set of Acceptable Means of Compliance (AMC) and Guidance Material (GM) has been developed for
these regulations [57]

Several decisions are embedded in the regulations. Briefly these are

 A drone operation is categorised as Open, Specific or Certified. Each category combines a risk
level for the operation, and an appropriate risk assessment and mitigation approach.
 Drones that are to be sold as suitable for Open operations fall into one of five classes, C0, C1,
C2, C3 or C4, depending on various technical parameters.
 The Open category is divided into three sub-categories, A1, A2 and A3, that refer to the
different drone classes C0 to C4 referred to above.
 Preparation of a Specific operation should usually include a risk assessment using the JARUS
“SORA” [4] method, or any other assessment method, compliant with the Acceptable Means of
Compliance (AMC) [57].1 However, it is expected that many current operations in the lower end
of the Specific category will be covered by standard scenarios, which already include the
minimum set of requirements (in addition to those in the regulation) to be complied with, and
will not therefore require the operator to perform the SORA process.
 EASA will publish a "pre-defined risk assessment" as an AMC. This will contain requirements
based on a pre-application of SORA, to guide operators in their operational authorisation
process.

1
The Acceptable Means of Compliance [57] states in Article 11 that the acceptable means of risk assessment is
SORA although methods other than SORA may be proposed.

© – 2019 – CORUS consortium except as noted. 9

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

Regulations [1] and [2] do not cover Certified operations.

2.2 Safety, the risk approach, SORA

2.2.1 What is SORA
The Specific Operational Risk Assessment (SORA) is a prominent methodology for the classification of
the risk posed by a drone flight mission lying into the specific category of operations as defined in
Regulations [1] and [2]. It is based on the evaluation of ground risk and air risk. The ground risk is
related to the risk of a person, property or critical infrastructure being struck by a UA and therefore
considers the operating environment with respect to the population density, the type of operation
(VLOS or BVLOS) and the UA size. The determination of the air risk considers the probability of
encountering manned aircraft in the airspace, which is chiefly derived from the density and
composition of manned air traffic in the airspace. After obtaining the Ground Risk Class (GRC) and Air
Risk Class (ARC) respective values, the combination of both leads to the final rating of the mission, the
so-called SAIL (Specific Assurance and Integrity Level), with a high value representing a high potential
risk. Mitigations, which can be either additional equipment or changes to the operation including
subscription to a U-space service, can be used to reduce the ground and air risks and thereby the SAIL.
An example of a safety assessment can be found in the annex C.

2.2.2 Discussion of the integration of the SORA into the CORUS ConOps
SORA is intended to be easier to apply than developing a full safety case. SORA was conceived as a
suitable way to exchange information between drone operators wanting to apply for a mission in the
specific category of operations and the competent authority. Consequently, enhances the awareness
and conscientiousness of drone operators as the mission and the accompanying risk are examined
thoroughly before take-off. In combination with the derived safety objectives, that leads to a safer
deployment of drones, which in return could foster the general public acceptance [48]. Therefore,
SORA is considered an important element of the operation (or flight) planning process. It should be
noted, that the SORA process is still under development/validation and its reliability and usability by
non-professional users is still to be demonstrated. Operation planning and SORA show a strong
interdependency which might lead to an iterative process, as operators will try to find risk-minimised
flight paths to avoid overly stringent requirements for their intended missions.

However SORA does not currently address the risk imposed by multiple drone operations being
conducted simultaneously. Responsibility for conducting SORA rests with the drone operator and the
assumption seems to be that the drone operator cannot manage and/or will never have the complete
set of information required to take other drone operations into account, for many reasons.

SORA has been investigated thoroughly in the course of CORUS and has been deployed on various
drone use cases. The derived considerations for improvement are mentioned briefly to support the
further development of the methodology.

a. The determination of GRC (Ground Risk Class) does not include the flight over temporary high risk
areas such as scenes of accidents, or localised high risk features such as critical infrastructure,
properties, highways and railway facilities within sparsely populated (or unpopulated) areas which are
generalised as having low GRC. This ConOps describes how U-space services can address both short-
comings.

10 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

b. The current ARC is determined only with respect to manned aviation, while drone operations in the
vicinity would increase the probability of an incident. This is because the majority of drone operations
take place in VLL; the vertical separation is therefore less between drone and drone compared to
drone and manned aviation – as manned aviation is expected to operate mostly above VLL (apart from
take-off and landing). An adaption of the SAIL due to nearby drone operations should be considered.
CORUS proposes a way of dividing the airspace in response to the drone traffic demand in which U-
space services reduce the air risk appropriately for each traffic level.

c. In the current definition of SORA, the SAIL is dominated by the ARC. Therefore, drone operations in
ARC-c or ARC-d2 offer little motivation for an operator to reduce the GRC, as the SAIL stays almost
unaffected. GRC can be reduced easily using the information provided by certain U-space services.

d. The determination of the final ARC should be regulated or able to be reduced through the
availability of U-Space/UTM services. For instance, a certain set of services could be required to reduce
the ARC from d to c.

During the SORA consultation process the European Cockpit Association (ECA) produced a paper [54]
with points about the required expertise and resilience. In relation to U-space they propose that SORA,
instead of solely looking at potential fatalities, could account the intrinsic risk of a mid-air collision
(MAC) by statistical analysis. The deployment of U-space will help in this.

2.2.3 Safety Assessment methodology within U-space

Preserving the principle of the risk based approach, CORUS proposes a safety assessment strategy
called MEDUSA. The MEthoDology for the U-Space Safety Assessment (MEDUSA) is a strategy to
identify and manage the hazards posed by drone traffic in the context of U-space. The main principle
of this methodology is based in the EUROCONTROL Safety Reference Material (SRM) where a broader
approach to assess safety is adopted. The broader safety approach addresses both the positive
contribution of U-space to aviation safety (success approach), as well as U-space’s negative effect on
the risk of an accident (failure approach). The success approach is required to show whether operation
under U-space is intrinsically safe, in the absence of failure.

The MEDUSA process provides a holistic approach to the U-Space safety assessment incorporating
different viewpoints, not only the operator perspective (which comes with SORA), but also the airspace
perspective of the U-Space service provision and the interoperability of these services with the
ATS/ATM. The operators perspective remains within MEDUSA with the reception of different SORA
assessments, and the U-space perspective with the integration of those results in a single safety
assessment. This safety assessment shall be conducted considering normal, abnormal and faulted
conditions in order to derive a complete and correct set of safety requirements/mitigations to be
implemented at U-Space service level, at drone operators’ level and/or at non U-space service
providers’ level, such as ATS providers.

The ultimate objective of MEDUSA is to derive a complete set of Safety Requirements for the U-Space
service implementation and associating these requirements with mitigation means that are able to
maintain the level of safety that stands today for manned aviation in both air and ground. An extended
overview of MEDUSA appears in the annex D.

2
The different ARC levels are explained in the JARUS SORA documentation [4] and is therefore not further
described in this document.

© – 2019 – CORUS consortium except as noted. 11

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

2.3 U-space
The CORUS project has been initiated by the SESAR Joint Undertaking (SJU). The following text is
extracted from the call [5]:
This project addresses those drones that are expected to operate in the VLL [Very Low-Level]
environment, covering many types of aerial activity, including leisure, remote infrastructure inspection,
rural operations, flights in densely-populated and urban areas, and flights near protected sites, such as
airports or nuclear power stations. Although manned aviation operating in this airspace is typically
uncontrolled, it will be necessary to address how drones might operate within controlled airspace near,
for example, airfields. In addition, VLL airspace is also used by other classes of airspace users, such as
military aircraft, rotorcraft, balloons, hang-gliders, micro-lights, parachutists and so on. The Concept
must enable safe interaction with all these users. Operational considerations must include
contingencies and emergencies, and societal issues must also be addressed.

As well as the references mentioned in section 2.1, CORUS takes as its input the existing SESAR work:
 U-space Blueprint [6]
 SESAR roadmap for the safe integration of drones into all classes of airspace. [7]
 European Drones Outlook Study [8]

CORUS is following the work being done in the eight other SESAR research projects in the same call [5].
Final reports are not yet available but information has already been exchanged. CORUS is also following
the activities of and exchanging information with the ten ongoing SESAR U-space demonstration
projects, the first of which to start was PODIUM; see [Link]

CORUS also considers as relevant inputs at least (but not limited to) the following list:
 Unmanned Aircraft Systems (UAS) ATM Integration Operational Concept from EUROCONTROL
and EASA [9]
 The EASA Concept of Operation for Drones [23]
 ICAO Annex 2 to the convention on Civil Aviation, Rules of the Air. [10]
 ICAO Annex 11 to the convention on Civil Aviation, Air Traffic Control Service, Flight
Information Service, Alerting Service [11]
 ‘SERA’ = EU regulation 923/2012 “…laying down common rules of the air… “ [12]
 ICAO Manual on remotely piloted aircraft systems (RPAS) – ICAO doc 10019 [13]
 ICAO Procedures For Air Navigation Services, Air Traffic Management, ICAO doc 4444 [14]
 The three consultation studies of EUROCONTROL & EASA ongoing as this ConOps is written:
UAS ATM Flight Rules [15], UAS ATM Airspace Assessment [16] and UAS ATM Common
Altitude Reference System [17]
 The FAA / NASA Unmanned Aircraft Systems (UAS) Traffic Management (UTM) Concept of
Operations [22]
 The many reports on the NASA UTM portal [51]
 Blueprint for the Sky, The roadmap for the safe integration of autonomous aircraft by Airbus /
Altiscope [18]
 Airbus / Altiscope’s Technical Report series [19]
 The Global UTM Association (GUTMA) UAS Traffic Management Architecture [50]
 The Swiss U-space ConOps. [24]
 JARUS publications in general [52] and SORA [4] in particular

12 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

Further CORUS members have had sight of a number of draft documents that are not yet published,
but whose ideas have influenced the thinking behind this ConOps, for example in the work of EUROCAE
working group 105, ICAO and a SESAR Joint Undertaking study of U-space Architecture.

U-space should enable business activity related to drone use as well as leisure use of drones while
maintaining an acceptable level of safety and public acceptance. This ConOps has been developed
considering the use-cases of U-space starting with the most frequent.

The U-space Blueprint [6] describes U-space has having four “levels”.

Figure 1 U-space levels, from the U-space Blueprint

The Blueprint describes U-space by means of a list of services that are offered. Each level is a set of
services. The expectation is that these levels will be deployed progressively.

The particular set of services that are available leads to the way of working that is possible, safe and/or
optimal. Hence, in essence, this document has to describe four concepts of operation, one for each
level. This document does not describe combinations of “mostly one level plus a few features from the
next” as each such combination requires a specific way of working, hence a different concept of
operation. There are many services and hence very many different possible combinations of services.
The CORUS project had neither the time nor the effort to explore them all and hence only describes
U1, U2 and U3 operations assuming a complete set of services in each. The descriptions of the services
are in section 5.1.

U4 is not covered to any extent in this ConOps. U4 heralds interoperation between U-space and
manned aviation. CORUS concluded that exploring U4 services required considerable interaction with
the manned aviation stakeholders who may use these services or depend on their correct functioning.

2.4 Area of interest of VLL U-space

Having defined the element characterising the context and scope of U-space, the following are
considered in scope:
 All size of drones, including those carrying passengers
 VLL Operations in vicinity of airports
 UAS with different kind of automation (including fully autonomous)
 UAS with different level of supervision (multiple UA supervision by a pool of RP)
 Obstacles such as stationary infrastructure, either permanent (e.g. buildings, wind turbines) or
temporary (e.g. cranes)

© – 2019 – CORUS consortium except as noted. 13

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

 Mobile obstructions (vehicles, trains and vessels)

 Significant turbulence, very low visibility conditions or other weather phenomena impeding safe
drone operation as well as other environmental hazards to drone operation such as
electromagnetic interference
 Day and night operations
 Flocks of birds, both airborne and on ground3

Considered out of the scope of this Conops are:

 Operations directly managed by ATC using current procedures, e.g. landing in an airport in the
same way as a manned aircraft.
 IFR RPAS.

A scenario illustrating the role of U-space might start with a business need, such as inspecting a tower.
The client might approach a drone operator whose first action would be to use the U-space Geo-
awareness service (see [Link]) and/or Drone Aeronautical Information service (see [Link]) to
estimate whether the work could be made as an Open category operation. If not, then the operator
would make a rough plan for the operation as a Specific category, and consider whether a standard
scenario applies or specific operational risk assessment (SORA) is needed. Both the evaluation of
applicability of a Standard Scenario and any SORA would take input from the U-space Drone
Aeronautical Information service, as well as U-space Risk Analysis Assistance service (see [Link]).
SORA may indicate the need for risk mitigations and some of these mitigations may be that the
operation makes used of U-space services. If the SORA shows that the residual risk is too high further
mitigation measures such as the creation of a temporary geo-fenced zone, will need to be applied.

This ConOps is concerned with airspace organisation, U-space services and how these services support
risk assessment, provide risk mitigations and further meet the traffic management needs of society.

2.5 Assumptions & definitions

2.5.1 Definition of Very Low Level, VLL
VLL is the airspace below that used by VFR. In ICAO Annex 2 [10] and SERA [12] there are statements
about the minimum height for VFR. For example in SERA section 5005 is written:
(f) Except when necessary for take-off or landing, or except by permission from the competent
authority, a VFR flight shall not be flown:
(1) over the congested areas of cities, towns or settlements or over an open-air assembly of
persons at a height less than 300 m (1 000 ft) above the highest obstacle within a radius of 600 m from
the aircraft;
(2) elsewhere than as specified in (1), at a height less than 150 m (500 ft) above the ground or
water, or 150 m (500 ft) above the highest obstacle within a radius of 150 m (500 ft) from the aircraft.

The SERA text above and similar text in ICAO Annex 2 section 4.6 essentially define the lower limit for
VFR operation above urban (1) and rural (2) areas. Below that limit is VLL. There are many reasons why
manned aircraft might fly in VLL, but these do not in themselves impact the definition of VLL. Much
more is said about VLL in section 3. In this document VLL is considered to extend laterally into airports.

3
Assuming such flocks are detectable and can be made known to U-space

14 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

The European drone regulations [1] and [2] mention a height limit for some activities which confirms
the focus of CORUS on VLL. Commission Implementing Regulation (EU) 2019/947 [1] mentions that for
Open operations, “during flight, the unmanned aircraft is maintained within 120 metres from the
closest point of the surface of the earth, except when overflying an obstacle”. Commission Delegated
Regulation (EU) 2019/945 [2] mentions limitations of vehicles to 120m above the take-off point for C0,
C1, C2 and C3 – your attention is directed to the exact wording of the regulation as it has been
simplified here.

2.5.2 Altitude, North

Aircraft altitude is used for different purposes during flight, including:
1. Navigation avoiding terrain or structures, Landing
2. Remaining below or above a legal height limit

As an input into the process of avoiding conflicts with other aircraft, including for use by ATC

Figure 2 shows different ways altitude is measured:

© – 2019 – CORUS consortium except as noted. 15

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
Figure 2. An overview of the various vertical datums4 and vertical measurements

4
For the classically trained, the plural of datum is data. In current English the word data has taken on a distinct meaning from datum. The reader is advised to consider the word written here
to mean the plural of datum and pronounce it as they feel is appropriate, but not to contact the authors to complain.
For practical and cost reasons, small drones commonly use altitudes based on GNSS. Existing aviation
makes use of barometric altitudes. As this ConOps is written, work is ongoing on the UAS ATM Common
Altitude Reference System discussion document [17]. That document proposes that U-space offer
services to convert between different altitude systems. These services are not described in this
ConOps.

In the first two uses for altitude mentioned above need to be referenced to the ground immediately
below the aircraft. GNSS heights are determined relative to a reference ellipsoid. Calculation of the
height above ground requires a look-up table (or map) to give the height of the ground at the current
location relative to the same ellipsoid. Such look-up tables trade-off accuracy against size, and
potentially cost. It is assumed that this ground-level calculation is done inside the UAS (UAS = vehicle
+ remote piloting station) but the accuracy may vary.

A similar issue is the meaning of North. For small drones whose navigation is based on GNSS, true north
is available. Aviation uses magnetic north in many situations. Calculation of one from the other is
relatively simple but requires a datum that should be updated periodically. The issue is already
troubling in aviation and may be addressed by an eventual switch to general use of true north. The
most important conclusion is that all should be clear about what is being used at any moment.

It is assumed that U-space will generally use GNSS altitude and true north while accommodating other
systems.

2.5.3 Types of Operation

[Link] Remotely Piloted flight

In this ConOps, a remotely piloted flight is any operation under the active control of a remote human
pilot. Active control means that the remote pilot is in tactical control of the aircraft and is responsible
for their own aircraft “Remaining Well Clear” of other aircraft, if the airspace class requires that. Any
mode of control not meeting this criterion is not Remotely Piloted - see section [Link].

There are two types of remotely piloted flight: those in Visual Line of Sight (VLOS) and those Beyond
VLOS (BVLOS).

VLOS requires that the remote pilot maintain visual contact the aircraft at all times during flight. VLOS
operation is described in the Implementing Regulation [1] and also defined in the ICAO Manual on
Remotely Piloted Aircraft Systems (RPAS) [13]

BVLOS is a mode of operation in which the pilot is not in visual contact with the aircraft. BVLOS
operation is described in the Implementing Regulation [1] and in the ICAO Manual on Remotely Piloted
Aircraft Systems (RPAS) [13]

“First Person View” (FPV) operation is considered to be a variant of either VLOS or BVLOS. FPV
operation involves the remote pilot viewing images sent from a video camera in the aircraft. According
to the Implementing Regulation [1], FPV is VLOS if and only if an assistant positioned next to the remote
pilot maintains visual contact with the drone, as the remote pilot usually wears goggles during FPV and
thus cannot do so. FPV is considered a variant of BVLOS in the absence of such an assistant.

[Link] Automated Flight (AF)

In this ConOps, a remotely piloted flight includes a remote human pilot responsible for their own
aircraft “Remaining Well Clear” of other aircraft if the airspace class requires RwC. Any mode of control
not meeting this criterion is considered by CORUS as Automated Flight. This ConOps draws attention
 EDITION 03.00.02

to Automated Flight in which the piloting function is implemented by a machine (usually software)
rather than by a human actor, as there may be implications for the design, implementation and legal
status of U-space services provided to such a flight, such as different requirements for robustness or
different liability. There may be a human supervisor for an automated flight but if his/her duties and/or
capabilities do not include remaining well clear then the flight is automated. (The implications of
automated flight are not explored further in this ConOps but should not be overlooked when
implementing U-space.)

A remotely piloted flight with a collision avoidance system which can automatically intervene to
change the course of the aircraft in the final seconds before a crash is considered remotely piloted and
not an automated flight.

[Link] Formation flights and Swarms

U-space considers formation flights and swarms as being collections of aircraft that do not need to be
separated by U-space.

This ConOps views a formation flight as several flights5 that have a special relationship. The special
relationship means that U-space will not attempt to separate the flights from each other and will never
consider them to have lost separation between each other. Establishing the relationship is explained
in section [Link]

A swarm is considered by U-space to be a single, solid object. U-space will not attempt to pass another
flight through a swarm. When flown in Y or Z volume, a swarm will have a single operation plan and
this plan will include dimensions for the swarm. Swarms may be prohibited in some volumes. Swarming
is not mentioned in the Regulations [1] and [2] as being part of Open operations and hence any swarm
is assumed to be a Specific or Certified operation.

2.5.4 Detect and Avoid

Detect and Avoid (DAA) is defined by ICAO as “the capability to see, sense or detect conflicting traffic
or other hazards and take the appropriate action.” DAA can provide a remote pilot with traffic
information, different levels of alert and decision aid, assisting them in flying the UA ‘well clear’ of, and
avoiding collisions with, other traffic, terrain, fixed and mobile obstacles, hazardous weather, people,
etc.

The remote pilot, or in the case of automated flight (see section [Link]) the UA itself, will use the DAA-
provided traffic information, alerts and decision aids to manoeuvre to avoid operating in such
proximity to other traffic as to create a collision hazard.

This ConOps defines U3 as that time when collaborative detect and avoid is standardised and widely
deployed. In collaborative detect and avoid, all participating hazards (aircraft) make themselves

5
The flights in a drone formation are considered to be distinct flights. This is different from how the ICAO doc
4444 flight plan currently considers formation flight. Formation flights in U-space may be parts of longer
operations; with distinct flights coming together for formation and then separating again. As the swarm flight
also exists in this ConOps as a collection with a single operation plan, the operator can choose which is most
appropriate.

18 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

detectable in some agreed way. (See Electronic conspicuity in U-space, section 4.2.2). This does not
meet the full description of DAA as the aircraft can only detect collaborative hazards.

Non-cooperative detect and avoid (sometimes called sense and avoid) in which the aircraft can detect
hazards independently is not expected to be standardised and widely deployed before U4, if at all.
However it may come into isolated use much earlier.

2.5.5 EASA Categories of operation

EASA defined Open, Specific and Certified categories of operation in their Concept of Operations for
Drones [23]. The definitions of Open and Specific appear in the Regulations [1] and [2]. This ConOps
does not seek to revise these definitions although it clarifies that in some situations an Open category
flight might require an operation plan; see sections 3.1.1 and 5.1.3.

[Link] Open
The reader’s attention is drawn to the Implementing regulation [1], sections [Link].020,
[Link].030 and [Link].040 which define sub-categories A1 to A3 respectively of Open
operations. Note that
 Some Open category operations may be performed by relatively untrained and inexperienced
pilots
 Some Open category operations may be performed with UAs incapable of submitting position
reports
 Open category operations include “follow-me” mode, with limitations – see [Link].020

Open operations have certain restrictions on where they be undertaken. Identifying that an area is
amenable to Open operation will be supported by U-space services. (see U-space Geo-awareness
service, section [Link])

[Link] Specific
The Implementing regulation [1] indicates that Specific operations are conducted
 Following a Standard Scenario published by EASA
 After a Specific Operational Risk Assessment (SORA) has been made for the operation
 By an operator holding a Light UAS operators Certificate (LUC).
 In the framework of a flying club which has received an appropriate authorisation

The specific operational risk assessment (SORA), involves identifying and assessing risks and then
finding mitigations for them. The assessment must be described in an Operational Declaration which
has to be lodged with the authorities. U-space services exist to help identify risks and to provide
mitigations to risks; see [Link]. It is assumed that more tools and services will appear to support SORA,
reducing the time and effort of completing the SORA process. The Operational Declaration of SORA is
much more general than a flight plan, and may cover many flights. It is completely different from an
Operation Plan as described in section 5.1.3.

Many operations in the lower end of the Specific category will be covered by standard scenarios and
will not require the operator to perform the SORA process. These standard scenarios will include the
minimum set of requirements (in addition to those in the regulation) to be complied with. Some
national governments (i.e. Spain, Poland) as well as international initiatives by JARUS - the body
responsible for the creation of the SORA methodology - have already implemented their own Standard
Scenarios for Specific operations.
© – 2019 – CORUS consortium except as noted. 19
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

[Link] Certified
Certified operations have not been described in the recent UAS Regulations [1] and [2] as they are
already covered by existing aviation regulation.

It is assumed that in traffic management terms, Certified and Specific flights are be indistinguishable.
U-space services provide information for aiding risk identification and assessment, and mitigation for
risks, in both of these operational categories.

2.5.6 Drone use in VLL

It is assumed that most private and leisure use of drones will be Open category VLOS operations. A few
private users will probably undertake Specific category operations or even make Certified category
operations.

Open operations do not require the operator to complete a SORA. This effort and time saving is of
interest for professional uses6. Hence it is assumed that while many professional uses of drones in VLL
will be achieved in the Specific category (see [Link]) and others will be, by necessity, in the Certified
category, a significant number of professional drone operations will be in the Open category.

Independent of the operation category or the objective of the flight (leisure or business), the same U-
space services will be available to all flights.

2.5.7 The scale of the problem

This ConOps refers to the European Drones Outlook Study, [8] as the current SESAR view of the
expected drone traffic. During the CORUS stakeholder consultations various widely differing numbers
of operations per day have been proposed, and these numbers will have a significant impact on
deployment choices; the technology to use, the amount to be invested and so on. In terms of traffic
safety, the ConOps tries to cover a range of situations; see section 2.6. The area where the numbers
impact the CORUS project’s work more significantly is social acceptance. Table 1 lists two rather
different projections of traffic and indicates the implications of each, assuming a totally homogeneous
distribution of population and drone activity both in space and time. As this is written, the European
Union has 28 member states and a total population just over 510 million people. Dividing the
population by the number of states indicates an average EU member state as a population of 18 million.
This is rounded here to 20 million. The average population density in the EU is currently around 115
people per square kilometre. This 20 million person ‘average EU state’ would have an area of about
175,000 sq km. An average drone flight is assumed to last 15 minutes.

6
CORUS learned this during stakeholder consultation

20 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

Parameter High Low

Number of UAS operations per day
1 million 1 thousand
for a 1 million inhabitant city
Average number of flights per minute in that city ~700 <1
Average number of drones airborne in that city at any
~10 thousand ~10
moment
20 million 20 thousand
Projection for a country with 20 million inhabitants
ops/day ops/day
Average number of flights per minute in that country ~ 14 thousand ~14
Average number of drones airborne in that country at
~210 thousand ~210
any moment
Average number of drones airborne per square kilometre ~1.2 ~0.0012
Table 1 Traffic projections

Very unscientifically, the high projection has a drone operating within the same square kilometre, or
“nearby,” every member of the population on average all of the time. The low projection has a
probability of a drone “nearby” around one in eight hundred. Clearly these numbers are crude
estimates but they show that the impact of the high projection in terms of social acceptance obviously
requires serious consideration.

2.6 Overall Approach

2.6.1 Risk based
This ConOps, in line with the EASA regulation, follows a risk based approach. Broadly this means that
the level of ‘effort’ devoted to maintaining safety is proportional to the risk associated with not doing
so. Examples of this risk based approach in the ConOps are the different modes of operation in the
different volumes

2.6.2 Performance based

The ConOps adopts a performance based approach; airspaces may have minimum performance
criteria for drones to fly in them – see section 3.3.2 – that will be set in response to the anticipated
traffic demand, meaning the number of flights expected in the airspace and security consideration.

2.6.3 Stepwise
The ConOps describes the stepwise evolution of U-space through U1, U2, U3 and U4. Each progressive
step allows more efficient use of the airspace while maintaining or improving safety.

2.6.4 Validation based

The ConOps takes the view that, since CORUS is an exploratory research project, the various concept
elements in the operational concept should be validated before deployment. This approach is visible
in the resemblance of some of what is proposed to existing aviation practice. The over-riding concern
of the authors for safety drives this ‘fondness for the conventional’ which some may view as a
weakness but the authors believe is a strength of this ConOps.

© – 2019 – CORUS consortium except as noted. 21

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

2.7 High level principles

2.7.1 Safety first
This ConOps is about the safe operation of drones and other aircraft. The U-space services described
are all concerned with safety. It is likely that many more U-space services will come to exist, to serve
business needs or for other reasons. They are not described here.

2.7.2 Open market

The aim of U-space is to create a business environment. The European Union champions the European
consumer and promotes business competition as a way of delivering the best service, innovation and
value, while allowing business the space to flourish. U-space will allow many businesses to operate, to
innovate, to compete, and to deliver cost-efficient services. The lightest possible involvement of the
regulator would be to oversee a purely commercial deployment of U-space so as to ensure its safe
operation. The fact that ATM already exists and may offer closely related services, or the lack of
commercial viability of such an approach (at least at first) may lead to a hybrid approach with the state
taking a larger role.

This ConOps tries to describe the services being delivered in a manner that allows any deployment but
aims to keep the door firmly open to an open market.

2.7.3 Social Acceptance

Further to the two first principles on safety and economic growth, drone operators and other U-space
stakeholders should consider that the flight of drones at low altitudes can disturb the people and
nature on the ground nearby. The aim of the ConOps is to balance the commercial pressure for growth
of drone use with the preservation of nature, people's health, personal privacy and European security.
Consideration of social acceptance from the start of drone operations is likely to produce a better
result in the long term than a brief boom in drone use followed by a public backlash.

2.7.4 Equitable access

Another aim of U-space is to enable drone flight. Not just the flight of some people’s drones, but all
drones. The U-space services should be open to all – within reason; there will be general obligations
like insurance, there will be operational and performance requirements for some airspaces and there
may be costs – which will be regulated as any other aspect of service provision – but any drone that is
fit to fly should be treated equally, as far as safe operation allows.

At the same time as there being a principle of Equitable access, some flights may have priority,
particularly life-saving or other emergency-response. Instances where non-equitable treatment are
forced by circumstance should be as dealt with fairly. Prioritisation is discussed in section 3.3.6.

2.7.5 ECAC wide

This ConOps is guided by EASA regulation and aims to be applicable throughout the European Union.
Further, the authors hope that the ConOps can be applied throughout the member states of ECAC (the
European Civil Aviation Conference) and with minor adaptations, beyond.

22 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

3 Airspace rules and procedures

3.1 Volumes
Very Low Level Airspace or VLL is defined in section 2.5.1. U-space divides the whole of VLL airspace
into three different types of volume as is explained in this section. These volumes include the “UAS
geographical zones” mentioned in the regulations [1] and [2]. As is mentioned in the regulations, the
motivations for creating these different volumes include differences in:
 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 drone
 Nuisance, security or other public acceptance factors
 The U-space services that are needed to enable safe operation

These volumes differ in two ways; the services being offered and hence the types of operation which
are possible, and their access and entry requirements. Three airspace volume types are identified and
referred to as X, Y and Z. All of the VLL airspace is either X, Y or Z. The services and operations are
described in 3.1.1 and the access conditions in 3.1.5; the latter mentions that access to Y and Z is
controlled and that in some cases volumes of type Y or Z may exist in order that access be controlled.

3.1.1 The three types of airspace volume and the services provided in each
The most significant difference is in the provision of conflict resolution services:

X: No conflict resolution service is offered

Y: Pre-flight (“strategic”) conflict resolution is offered only

Z: Pre-flight (“strategic”) conflict resolution and in-flight (“tactical”) conflict resolution are offered

This difference has a large impact on how drones should fly in that airspace.

[Link] X Volumes

There are few basic requirements on the operator, the pilot, or 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 flight are easily possible. 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, either due to there being few flights, or there being particular
focus on Open category operations.
 low ground and air risk. The Regulations [1] and [2] describe the ground and air risk
requirements for Open category operations and these conditions are expected to be commonly
found in X volumes.

In SORA terms X volumes are most likely to be “ARC-b” and “Rural” however X is defined in terms of
services offered so this is only a probability rather than a general rule.

© – 2019 – CORUS consortium except as noted. 23

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

[Link] Y Volumes
Access to Y requires an approved operation plan (see section 5.1.3 for more information on the
operation plan approval process). Y airspaces may have specific technical requirements attached to
them – demonstrating that these are met is part of the operation plan approval process. These
technical requirements will usually include
 A remote piloting station connected to U-space
 A UAS capable of position report submission

Y volumes facilitate VLOS and BVLOS flight. In Y volumes there are risk mitigations provided by U-space
which 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. As there is no tactical (in
flight) separation service offered in the airspace, the pre-flight conflict resolutions will reduce the
residual risk of collision to a very low level, which will result in widely spaced aircraft. In Y airspace
there is Traffic Information (see [Link]), the provision of which requires that all aircraft in Y airspace
be 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) are 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 at a national park. In such
cases Y volumes may enforce the approved operation plan requirement but might, due to
unavailability of mobile internet, not require a remote piloting station connected to U-space.

[Link] 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 there is particular risk.

Just as for Y, access to Z requires an approved operation plan, and additionally:

 The pilot continuously connected to U-space
 Position report submission for the aircraft with enough performance to enable tracking

Z airspaces may have specific technical requirements attached to them – demonstrating that these are
met is part of the operation plan approval process.

Z volumes have a tactical conflict resolution service. This may be supplied by U-space (see section
[Link]) in which case the volume is known as Zu, or the volume may be controlled or by ATS when it
is known as Za.

This ConOps assumes that for all VLL regions controlled by ATS, for example inside a Controlled Traffic
Region (CTR), U-space classes the volumes as Za.

ICAO Annex 2 [10] and SERA [12] both define Controlled Airspace as: An airspace of defined dimensions
within which air traffic control service is provided in accordance with the airspace classification.

24 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

Any Za volume is Controlled Airspace. ATS are in control and provide services in this volume, making
use of U-space services if necessary, i.e. to enable communication, surveillance and so on.

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.

The aeronautical information (including drone aeronautical information) for each Zu volume shall
make clear if it is Controlled Airspace or Uncontrolled.

Z volumes facilitate BVLOS and automatic drone flight and also allow VLOS. In Z there are more risk
mitigations provided than in Y or X. Z also allows higher density operations than Y; residual risks from
strategic (pre-flight) 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.

3.1.2 The services available in the different Volumes

The U-space services are listed and described in section 5.1. The following table lists which U-space
services are used in the three volumes. These services have different states:
 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
 When-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
 No: Not available.

Note that services only become mandatory when available and planned to be available by phases U1,
U2, U3, U4. A volume is fully operative only when all the mandatory services are deployed in the area.
The U-space services mentioned here are described in section 5.1. Links are given in the table below.

Service Section X Y Z
Registration [Link] Mandated Mandated Mandated
e-Identification
[Link] Mandated Mandated Mandated
– see note 12
Position report
Optional – When-available
submission sub- [Link] Mandated
See note 1 See note 3
service
Tracking [Link] Optional When available Mandated
Drone
Aeronautical [Link] Mandated Mandated Mandated
Information
Geo-awareness
[Link] Mandated Mandated Mandated
- See note 13
© – 2019 – CORUS consortium except as noted. 25
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

Service Section X Y Z
Geo-Fencing
[Link] Mandated When-available Mandated
provision
Drone
operation plan [Link] Optional Mandated Mandated
processing
Dynamic
When-available -
Capacity [Link] No Mandated
see note 4
Management
Strategic
Conflict [Link] No Mandated Mandated
Resolution
Tactical Conflict Mandated – see
[Link] No No
Resolution note 5
Emergency When-available –
[Link] When-available Mandated
Management see note 14
Incident /
Accident [Link] Mandated Mandated Mandated
Reporting
Monitoring [Link] Optional – see note 2 When-available Mandated
Traffic When-available Offered
[Link] Optional– see note 2
Information See note 3 See note 6
When-available – see
Legal recording [Link] When-available Mandated
note 7
When-available – see
Digital logbook [Link] When-available Mandated
note 8
Weather
[Link] Mandated Mandated Mandated
Information
Geospatial
information [Link]
service
Electromagnetic
interference [Link]
information
Population
[Link] Optional Optional When-Available
Density Map
Navigation
Coverage [Link]
information
Communication
Coverage [Link]
information
Procedural
Interface with
[Link] When-available When-available Mandated
ATC – see note
10

26 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

Service Section X Y Z
Collaborative
Interface with
[Link] When-available When-available Mandated
ATC – see note
11
Table 2 U-space services offered in different airspace types

Notes:
1. Position report submission may be offered. When it is, flights in X volumes are encouraged to
make use of the service in order to warn other airspace users of the presence of drones.
2. Both Monitoring and Traffic Information will be of limited use in X volumes as not all aircraft are
tracked.
3. Tracking is required in Y to allow Traffic Information to be provided. Y volumes may have a
minimum standard of position reporting. Y volumes may be defined in remote areas for access
control in which case there may be no position reporting service offered.
4. Provision of dynamic capacity management is at the choice of the airspace authority concerned
5. Tactical conflict resolution is offered by the U-space service of that name in Zu from U3 and by
ATS in Za from U1
6. The provision of Tactical Conflict resolution effectively makes Traffic Information unnecessary.
7. Legal recording will contain traces only of operational declarations and position reports, hence
not all flights in X
8. Digital logbook features are limited to flights with position report submission
9. Like Weather Information, the Terrain Map, Building & Obstruction Map and Population Density
Map become standardised data services in U2. The same information may be available in some
places earlier than U2. The quality of the information available may vary, but shall be indicated
to the consumer of the service.
10. Procedural Interface with ATC only offered to flights which submit operation plans which enter
airspace controlled by ATS.
11. Collaborative Interface with ATC only offered to flights which enter airspace controlled by ATS.
12. E-identification is a U-space service. Remote Identification as described in the regulations [1]
and [2] is a drone capability, mandatory for Open operations, and is related to this service. See
section [Link]
13. Geo-awareness as described in the regulations [1] and [2] is a UAS capability, as discussed in
section [Link]. The U-space Geo-Awareness service provides data that allows this capability
to operate. See section 5.1.2. A service equivalent to the UAS Geo-awareness capability may
be provided by the U-space Monitoring Service (see [Link]) but only for drones which are
being tracked by U-space.
14. Emergency Management is an important service for the delivery of information to the remote
pilot. This ConOps assumes Emergency Management will be made available from U2 onward
in all Y volumes apart from those defined in areas in which there is known to be an absence of
mobile internet or similar which prevents communications from U-space to the UAS.
Operations in such a Y airspace should take this lack of communications into account.

Access to both Y and Z volumes requires an operation plan. The U-space operation planning service is
only available in U2.

3.1.3 Drone operations in the different volumes

All of the volumes X, Y and Z support Open, Specific and Certified category operations, with a few
qualifications. Access to Y or Z always requires an approved operation plan, even if the operation is
“Open” category. Any Y or Z volume can have entry criteria associated such as minimum technical
© – 2019 – CORUS consortium except as noted. 27
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

standards or a requirement for special permission, and meeting these entry criteria is part of the
process of operation plan approval.

BVLOS operation is possible in X-type airspace volumes, but very careful attention must be paid to risk
mitigation.

While the ‘Follow-me’ mode, as described in the Implementing regulation[1], is part of Open
operation, its use in Y or Z type airspace volumes should probably be preceded by an assessment of
the risk involved.

3.1.4 Drone capabilities required in different volumes

The following UAS technical features are required to fly in these airspaces:

[Link] Remote Identification

Remote Identification is described in the regulations [1] and [2]. Remote identification is mandated for
most drones intended to be operated in the Open category, no matter where they fly. Remote
identification may also be mandated for all vehicles in any volume – see Article 15 of [1]. This ConOps
does not link remote identification to any of X, Y or Z but leaves that option to the implementation.

Remote identification is expected to have two implementations;

 DRID, direct remote identification, where the drone emits a signal that can be received on a
handheld device directly giving identification, or using the data carried by that signal to request
further information from the U-space e-Identification service, see section [Link].
 NRID, network remote identification where the drone is being tracked by U-space and can be
identified by using the current position of the drone to select the most likely track. See tracking,
section [Link]

DRID is mandated in the regulations [1] and [2] for most Open category operations. NRID is only
possible for vehicles which are being tracked.

[Link] Geo-awareness

The Implementing Regulation [1] defines Geo-awareness as a system that alerts the pilot to a potential
breach of airspace limitations. The same regulation requires this feature on drones used in some open
operations. Open operations can occur in volumes where this ConOps does not foresee tracking. Hence
Geo-awareness is considered to be a UAS feature as U-space is unable to provide it generally. The U-
space service Geo-awareness described in section [Link] provides the data used by this UAS capability.

Geo-awareness is expected in all X, Y and Z volumes on capable drones.

[Link] Dynamic Geo-fencing

Dynamic Geo-fencing is the capability of the UAS to make use of the Geo-fencing Provision service of
U-space, described in section [Link]. The service and the capability will keep the drone up-to-date
with geo-fencing information, even during flight. The capability is recommended for all but not
mandated. It may be that local implementations lead to this capability being mandated in some
volumes.

28 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

[Link] Position Report Submission

As described in section 5.1.1, the drone operator shall enable tracking by ensuring that reports of the
position of the aircraft reach U-space. These reports could result from different technological means.
Position report submission is mandatory in Z and mandatory when available in Y. Position reporting is
optional in X.

In any Z volume, or in a Y volume where it is mandatory, there may be a minimum technical standard
for position reporting, specifying (for example) the minimum rate or maximum uncertainty.

Although not required, position report submission is recommended in X for the following reasons:
 Future airspace assessment, for example revision of the categorisation, will benefit from
evidence of operations in the volume.
 Other operations benefit from knowing that a flight is present, even if there is not a full air-
situation available.

Similarly operation planning is encouraged but not required in X volumes.

[Link] Pilot connected to U-space

In Y and Z it is mandatory that the remote pilot be able to receive messages sent from or via U-space.
Various U-space services rely on this ability.

In X, this connection is optional and it is expected that many UAs in X volumes will not have this ability.

[Link] Collaborative Detect and Avoid

U3 is defined as starting when Collaborative Detect and Avoid is widely deployed. At that time,
Collaborative Detect and Avoid will be mandatory in some Y and Z volumes as the airspace assessment
decides.

[Link] Detect and avoid compatible with manned aviation

How Detect-and-avoid, compatible with manned aviation will function, or can be implemented, has
yet to be agreed within the aviation industry – including manufacturers and operators of drones. This
feature will be a key enabler for U4. Depending on decisions made in the implementation of U4, detect
and avoid compatible with manned aviation may become mandatory in some or all types of airspace.

3.1.5 Access & Entry conditions

As explained in section 3.1.1, access to Y and Z volumes requires an approved operation plan, while
access to X does not. The Implementing Regulation [1] mentions in article 15 that ‘geographical zones’
may be prohibited to some or all operations. Y and Z volumes implement these geographical zones.

Such a geographical zone may be created to protect areas from drones for reasons of:
 Safety, for example over an oil refinery
 Security, for example over a prison
 Noise abatement or visual nuisance, for example over a national park

In each of the cases mentioned, a situation can be imagined when a drone flight may be permitted, for
example if the oil refinery operator might use a drone to inspect a tower on the site. Hence the

© – 2019 – CORUS consortium except as noted. 29

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

prohibited geographical zone is really an “only by special permission” zone and for each zone there is
a specific authority able to give this special permission.

Geographical zones may be used to present to drone users Restricted Areas and other special use
zones which are defined for manned aviation. Geographical zones may also implement drone specific
restrictions, for example relating to gatherings of people.

Geographical zones will be implemented by classifying the airspace as type Y or Z. In U1, getting
“special permission” is outside the scope of U-space. From U2 onward, the process may be facilitated
by the Operation plan processing service of U-space. However despite being marked as Y or Z volumes,
some geographical zones may be inaccessible to all, in which case all operation plans crossing the
volume will be rejected or amended.

Having permission to enter a prohibited geographical zone shall be managed in a standard way – see
[Link].2

[Link] Short Term Restrictions

Restrictions may be placed on drone operations at short notice and with short duration, for example
to protect an emergency manned flight in VLL, for example a Helicopter Emergency Medical Service
(HEMS) flight evacuating an injured person from an accident, or for other sudden needs. These short
term restrictions over-ride the XYZ volumes. The creation of a short term restriction will generally be
announced through the Emergency Management service, see [Link]. The existence of a short term
restriction shall be shown on electronic maps via the Drone Aeronautical Information service, see
[Link]. The Geo-awareness information shall also be updated, see [Link] and Geo-Fencing provision
similarly shall be updated, see [Link].

However, if a drone operator in an X volume is not connected to U-space, they will not be aware of
this restriction. This is a risk that still has not been, but that needs to be, resolved.

[Link] Manned flights entering X, Y & Z volumes

Manned operations may enter type X, Y or Z unintentionally or intentionally. Manned operations in X,

Y and Z are at risk of colliding with drones, but this risk can be mitigated to an extent if the manned
flight is conducted making use of U-space services. A VFR flight might be in VLL because of a planned
entry, an unplanned, but conscious, entry, or an inadvertent entry. There are many reasons for these
types of entry.

Some examples of planned entry into VLL of a manned flight could be:
 HEMS or police flight
 Military training
 (in a few places) low altitude routes exist for helicopters
 VFR training for emergency landings and similar
 Balloon or microlight take-off or planned landing using ad-hoc location
 (in some countries) microlights may fly in VLL
 (in many countries) there are geographic areas where VFR may fly in what this ConOps defines
as VLL under the provisions of ICAO Annex 2 or SERA

Examples of Unplanned, conscious entry into VLL include:

30 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

 Emergency landing, other emergency

 Gliding loss of altitude
 Ballooning loss of altitude or ad-hoc landing

Inadvertent entry into VLL may be associated with hilly terrain or obstacles that raise the top of VLL.
The VFR pilot ought to know his/her height above ground from his/her map but might make an error.

If not segregated into a specific volume of airspace, parachuting, base-jumping, hang-gliding and
paragliding might also be considered to be potential planned or unplanned (or even inadvertent) entry
into VLL.

Permanent structures in VLL that are used by manned aircraft such as low level helicopter routes,
frequently used hospital helicopter landing pads and similar should be protected from drone
operations by means of Y or Z volumes.

Priority operations such as HEMS or Police flights or military training shall be systematically protected
by short term restrictions, and hence geo-awareness.

Predictable non-priority activities like parachuting or hot-air-balloon festivals, glider airports or similar
may also be protected by either Y or Z volumes or short term restrictions.

Planned, non-priority entry into VLL may be handled in different ways depending on the type of
airspace.
 In U1, there is no mitigation for the risk of entering a type X volume apart from a short term
restriction. The manned flight should assess the likely risk very carefully before flight.
 From U2, planned entry into type VLL can be made known to U-space by the manned flight
submitting a U-space operation plan, and then following it. See section [Link]. (Note that drone
operation plans can indicate “volume and period”) In Y and Z volumes, the results of the
Strategic Conflict Resolution service shall be followed. If the conflict resolution cannot be
followed, the manned flight might request being protected by a short term restriction on drone
traffic. The operational declaration brings less risk reduction in X volumes.
 From U2, the risk associated with planned entry VLL may be reduced by use of the U-space
Position report submission service on the manned aircraft – see section [Link], which is
mandatory in types Y and Z. The use of ADS-B might be sufficient if there is coverage at the
location and altitude.
 From U2 the risk associated with planned or unplanned entry into VLL can be reduced by the
crew making use of the U-space Traffic Information service – see section [Link], which might
require some training for the crew.
 From U3, when collaborative detect and avoid is in widespread use, a manned aircraft intending
to enter, or at risk of entering X, Y or Z volumes should be fitted with a drone compatible
collaborative detect and avoid system, and the pilot trained to use it.
 In U4, when means of allowing safe interoperation of manned and drone flights are
standardised, these should include a detect and avoid system that is compatible with both, in
general use, and which should reduce the risk in all types of airspace

Unplanned, conscious entry in VLL should be considered as risky. The following can reduce the risk:
 From U2, the crew of the aircraft may wish to use the U-space Emergency management service
– see section [Link] to report their incursion. This may involve some training and the availability
of a device on the aircraft which is connected to the internet (e.g. smartphone)

© – 2019 – CORUS consortium except as noted. 31

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

 From U2, the use of the U-space Position report submission service on the manned aircraft. This
might be done in some way that the pilot can turn on when the need arises. Use of ADS-B may
be sufficient as the ATM and U-space trackers shall be interconnected.
 From U2, the use of the U-space Traffic Information service, if the crew have sufficient
connectivity and time to do so.
 In U4, a detect and avoid system compatible for use on drones and manned aircraft

The risk associated with inadvertent entry into VLL may be mitigated by
 From U2, some types of inadvertent entry into VLL can be detected by the manned flight
submitting a U-space operational declaration. Submitting an operational declaration may also
reduce the risk in the case of an unpredicted entry into VLL when in combination with position
report submission and the U-space monitoring service which could warn the manned aircraft of
inadvertent entry into VLL
 From U2, the crew of the aircraft may wish to monitor information sent out by the U-space
Emergency management Service – see section [Link]. This may involve some training and the
availability of a mobile device connected to the internet (e.g. smartphone)
 From U3 the fitting of the manned aircraft with a collaborative detect and avoid system as used
by drones.
 In U4, a detect and avoid system compatible for use on drones and manned aircraft

Nevertheless, since some drone operator in X volumes are not connected to U-space, they will not be
aware of this restriction. This is a risk that still has not been, but that needs to be, resolved.

Further work is needed on safe integration of manned and drone traffic; the success of that work
depends on the active involvement of both communities.

It should be noted that mitigation of risks using ADS-B may be affected by the contents of a state letter
being drafted by ICAO recommending limiting the use of 1090 MHz for drones in VLL airspace.

3.1.6 Airspace Assessment

[Link] Process

The airspace authority, typically the Civil Aviation Authority of the state, is responsible for deciding, or
revising, which volumes of their airspace have which classification. A full description of the process of
airspace assessment is out of the scope of this ConOps, but it can be stated that the process should
consider:
 Ground risk – the safety of what is below
 Air risk – what is likely to be flying
 Social acceptability factors such as noise and privacy
 Security criteria to ensure trusted and correct functioning of U-Space
 The need to provide opportunities for legal drone flying to reduce the risk of illegal drone flying
 The interests and needs of specific authorities
 Requests from current and potential future operators of drones
 The cost of providing the services needed to operate Y or Z volumes compared to the additional
safety or capacity that they provide
 European norms – the airspace subdivision into volumes should be broadly harmonised across
member states in order to produce a Single European Sky

32 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

The categorization of the airspace into volumes of different types or access conditions may be by place
(lat-long) and/or by height.

[Link] Result

It is the opinion of the ConOps consortium that the X, Y and Z volumes can be created using the existing
tools of the current ICAO airspace classes plus restricted areas and similar. A definitive conclusion
would depend on there being an accepted mapping from drone modes of operation (VLOS and BVLOS)
to flight rules and then the inclusion of those flight rules in the airspace class descriptions. See section
3.2.2 where the flight rules are discussed.

3.1.7 Summary of volumes, uses and operations

Figure 3 X, Y and Z volumes

 There are three types of airspace volume in the VLL: X, Y, and Z

 X offers no separation services, all responsibility for safe operation is with the remote pilot
 Y offers strategic (= pre-flight) conflict resolution and usually traffic information during flight
 Z offers strategic conflict resolution and tactical (= in flight) conflict resolution
 Short term restrictions may be imposed in any volume. Their creation is announced via the
Emergency Management Service. They are visible in the Drone Aeronautical Information and
the Geo-awareness data.
 Access to Y and Z requires an approved operation plan. Y & Z volumes may exclude some or all
drone flights.
 Open, Specific and Certified operations are all possible in X, Y, or Z – with some limitations.

© – 2019 – CORUS consortium except as noted. 33

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

 As well as an approved operation plan, flying in Y or Z involves appropriate training, technical

equipment and a connected remote piloting station.

3.1.8 Comparison of X, Y & Z Volumes and other models of the airspace

[Link] EUROCONTROL/EASA

The EUROCONTROL/EASA UAS ATM Integration Operational Concept [9] mentions No-drone-zone
(NDZ), Limited-drone-zone (LDZ), and Exclusive drone zones (EDZ), the latter subdivided into EDZu for
unplanned, EDZp for planned and EDZm for passenger carrying operations.

Each is possible using X, Y and Z volumes. NDZ and LDZ can be implemented by either Y or Z volumes.
EDZu is a Restricted Area for manned aviation which is dedicated to drones as an X volume. Both EDZp
and EDZm may be implemented as being Y or Z volumes (either) within restricted areas for manned
flight.

The same document gives an example in which classes of traffic are separated in height. Such a scheme
could be achieved by layering Z or Y volumes above X.

[Link] Airbus

The Airbus Blueprint for the Sky [18] describes corridors and zones being used for safe and expeditious
flight. Airbus (Altiscope) have done further work considering traffic organisation in their “Technical
Report 004: Metrics to Characterise Dense Airspace Traffic” [20].

Considering the application of these airspace features using volumes, corridors could be constructed
from type Y or Z in regions otherwise filled with type X, or Z corridors could join Y volumes.

The systems described in the Technical Report 004 can, with some effort, be constructed using the
tools described in sections 3.1.1 and 3.1.5 of this ConOps. However, traffic organisation for efficiency
is a big subject worthy of detailed study and is not described in this ConOps.

3.2 Operational Practice including Rules of the Air and Flight Rules
3.2.1 Rules of the Air
Current sources of the rules of the air in Europe are the Standardised European Rules of the Air
(SERA) [12], ICAO Annex 2 “Rules of the Air” [10], and national regulation. For drones, further
operational practice appears in the Implementing Regulation [1] Article 7 and the Annex. The drone
pilot is a pilot as defined in the SERA, and this applies unless stated in the Implementing regulation.
When there is no identifiable pilot, the drone operator takes that role and all associated
responsibilities.

In order for manned and unmanned operations to be adaptable, there need to be clearly defined flight
rules at low level. At present there are no specific rules for drones in the SERA, other than those that
regulate all aircraft. The UAS ATM Integration Operational Concept [9] proposes that two new sets of
rules are required – low-level (LFR) and high-level (HFR) flight rules - which would accompany the
current visual and instrumental flight rules.

34 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

It is clear that drones flying in the VLL will not be able to operate in accordance with the full set of
requirements in section 3 of the SERA, given their size and performances. It is vital to review the
general rules and collision avoidance with the LFR.

3.2.2 Specific and General Flight rules in VLL

The reader’s attention is drawn to the difference between operations and flight rules; VLOS and BVLOS
are not alternatives to VFR and IFR. That said, VLOS and BVLOS drone operations are not compatible
with VFR. This ConOps does not offer a definition of LFR.

Existing right of way rules are applicable not only to VFR traffic but also for VLL flights with drones. It
is challenging to apply right of way procedures knowing that a pilot flying its drone in visual line of sight
will have to determine the relative level, heading and distance of an incoming flight. Similarly a pilot in
the cockpit would have trouble visually identifying a small drone even if it is only 50 m away.

Automated flight (see [Link]) must also be able to apply the flight rules.

3.2.3 Avoidance of collisions

The first step into ensuring a safe self-separation and avoiding a collision between a drone and a
manned aircraft is to conduct separate analysis between several densities of traffic, with high-density
demanding flow control, as provided by the Dynamic Capacity Management service.

The logic for drones and manned aircraft to avoid collisions must be compatible, whatever the
combination of conflicting aircraft.

In any situation where the drone pilot is uncertain as to the trajectory, level, speed or status of another
aircraft approaching the pilot’s aircraft, the pilot should assume a head-on approach and follow
SERA.3210 (or section [Link] of ICAO Annex 2 above the high seas) and change heading to the right
for interoperability with VFR flights.

This topic requires more study.

3.3 Spacing & Conflict Resolution

In aviation, separation is a concept in controlled airspace for keeping aircraft outside of a minimum
distance from each other to reduce the risk of a Mid-Air Collision (MAC). Today different separation
minima apply in different surveillance conditions; for example during procedural control over the
Atlantic Ocean, where there is no radar coverage, separations of 60 nautical miles are used, while in
continental Europe where there is radar coverage, in class A airspace separations of 5 nautical miles
are used. VFR pilots in class G using “see and avoid” do not have a minimum distance specified but
must remain ‘well clear’ of each other. In all cases, a minimum separation takes into account how well
the relative positions of the aircraft are known. Historically, the parameters that define each
Separation Standard were based on the capabilities of the service offering (e.g. the radar resolution,
altimeter accuracy) or the generalised set of abilities that all aircraft can procedurally conform,
considering factors such as the time taken to respond to a control input, the ability to maintain a
vertical “flight level” accuracy of at least 100ft, and so on.

With the emergence of small high-accuracy positional location and tracking systems, the minimum
distances that aircraft can be safety separated can now depend on the performance of overall

© – 2019 – CORUS consortium except as noted. 35

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

navigation and surveillance system. ICAO defines Performance-based navigation (PBN) in terms of a
requirement set [43]
 Accuracy - The volume of space the drones will be confined.
 Integrity - A measure of correctness of the navigation data provided.
 Availability - The proportion of time which reliable navigation information is available.
 Continuity - The capability to provide uninterrupted navigation information.
 Functionality - Functional requirements.

For IFR aviation, PBN has been implemented by examples such as required navigation performance
(RNP) specification of on-board monitoring and alerting, or the area navigation (RNAV) specification
that relies on navigation beacons. Both specification methods define a separation distance based on
the criteria above.

Safe deployment of a PBN separation specification can be defined as

Examples include: RNP-2 implemented for US en-route arrival/departure and requires a monitored
accuracy of +/- 2nm available, 95% of the time. – see [55]

3.3.1 The impact of Weather on Drone Spacing

Weather impacts small drones in a variety of ways and drones can be used to measure this effect.
Newton’s second law states that every force has an equal and opposite reaction, meaning that an
aircraft that can measure a weather system is also affected by the meteorological conditions. Increased
weather severity can cause loss of control of a drone and ultimately an increase in LoS events. An
RUNP-20m (see section 3.3.2) operating zone would have to validate, by some means, that
(cooperative) drones can safely fly in a wind speed of up to:

Wind speed = speed(aircraft type)

New fan arrays, with numerous small fans, can generate variable wind profiles that allow better control
in higher wind speeds. In winds of 30 kts, a light UAS of less than 900 grams will naturally be less stable
than a large 100 kg UAS in the same winds, and will also be much more susceptible to gusts. However,
in still air, the light UAS can naturally hold their position much more accurately. Therefore, navigational
accuracy depends on the drone’s capabilities for a given weather condition and cannot be considered
to have the same response function across different drones models.

3.3.2 Required U-space Navigation Performance - RUNP

A U-Space validated RUNP would use the same ICAO principles of validation that are used in RNP and
RNAV. The specification would use the same requirements set, although the parameters of what
produced a safe operation will have to be validated for a given geospatial implementation (e.g. at a
particular airport). RUNP is written with a distance suffix, as is done for RNP. In the case of RUNP the
distance unit is given by SI abbreviation, and is usually metres.

36 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

Examples high-level RUNP parameters:

RUNP-5m
 Accuracy - +/- 5 metres
 Integrity - Greater than 1-1x10-7/h with a Time-To-Alert of less than 1 second
 Availability - Better than 99% link-time (in nominal conditions)
 Continuity - At least 1-1x10-4/h continuous link-time
 Functionality - Managed: “ATZ”

RUNP-50m
 Accuracy - +/- 50 metres
 Integrity - Greater than 1-1x10-7/h with a Time-To-Alert of less than 5 second
 Availability - Better than 99% link-time (in nominal conditions)
 Continuity - At least 1-1x10-4/h continuous link-time
 Functionality - Declared: “Sub-urban region”

The safety impacts of RUNP will require certified aircraft fitted with certified dependent surveillance
of high technical performance.

3.3.3 Conflict management

There are three layers of conflict management which also apply to U-space:

- Strategic (pre-tactical) de-confliction; the ability to plan before flight operations of a strategy that
does not conflict with other users. Typically this involves operators sharing drone operation plans to
relevant parties and reducing any potential loss of separation by planning routes that are unlikely to
cause interactions with other airspace users. U-space’ Strategic Conflict Resolution service is described
in section [Link]

- Tactical separation provision; the ability to maintain a situational awareness through either visual
or instrumental aid that monitors for potential loss of separation. Typically, in non-segregated
controlled airspace, ATC uses radar to track aircraft to predict their trajectory and issue clearances that
resolves potential conflicts. Likewise, VFR defines the tactical actions required to manage the potential
loss of separation between two aircraft: “An aircraft shall not be operated in such proximity to other
aircraft as to create a collision hazard (ICAO Annex 2)”. U-space’ Tactical Conflict Resolution service is
described in section [Link]

- Collision avoidance; the ability to prevent a MAC as part of a last course of action, if the above
separation plans and provisions fail. In U-space the collision avoidance layer is implemented with
“Detect and Avoid (DAA)” systems.

In U-Space, the three layers of conflict management will remain valid, although the service provisions
of each layer will become increasingly merged. With increased connectivity between (semi-
autonomous) aircraft, 4D trajectory can be updated and shared in mid-flight, allowing tactical provision
services to take reaction.

DAA systems are defined by ICAO Annex 2 [10] as – “the capability to see, sense or detect conflicting
traffic or other hazards and take the appropriate action”. It defines a capability aim to ensure the safe
execution of flight with all airspace users. The principles are to mitigate hazards such as
 conflicting traffic,
 terrain and obstacles,
© – 2019 – CORUS consortium except as noted. 37
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

 hazardous meteorological conditions,

 ground operations,
 other airborne hazards,

In this ConOps DAA systems are the back up in case the Tactical Conflict Resolution service fails (see
section 2.5.4 for more details). Drone DAA is expected to include Collision Avoidance and Remain Well
Clear functions, but applying different separation distances. Ultimately, the goal of DAA on board
drones is to give the UAS equivalent capabilities as currently used by manned aircraft.

3.3.4 Examples of separation in Use Cases

[Link] Spacing between drones

[Link].1 Between VLOS and VLOS

In the rules of the air, we stated that

 the remote pilot flying the drone in VLOS is responsible for the avoidance of collisions,
 there is no value in setting any minimum separation as distance cannot be accurately judged by
eye from the ground.

Where the strategic and tactical de-confliction services are provided, there is no particular reason to
set any separation minima between VLOS, just as today there is no minimum separation set between
two VFR in class G. A criterion to be taken into account could be a limited volume capacity, in order to
not overcharge VLOS pilot’s attention. This would require drone flight plan management to implement
demand and capacity balancing.

[Link].2 Between VLOS and BVLOS

Where a drone operation plan is submitted, the U-space system is able to consider separation minima
between the planned 4D trajectories before validating the plan. Collision avoidance can be effected by
the VLOS pilot, and this is more certain if the VLOS pilot is warned. Hence proximity closer than some
minimum distance should trigger a warning to the VLOS operator / pilot that a BVLOS flight is expected.

[Link].3 Between BVLOS and BVLOS

Strategic confliction resolution will guarantee the separation between the planned 4D trajectories. In
addition, in Z volumes, where traffic density could be higher, tactical de-confliction could be applied
by ATC or USP.

[Link] Separation between drones and manned aircraft

EASA regulations, and most European countries’ national regulations, highlight the necessity to fly
under 120m (~400ft), or to fly far from manned aviation activity. Despite this an encounter with a
manned aircraft is already relatively common.

In airspace volumes of type X, the VLOS pilot is responsible for the avoidance of collision with all the
aircraft. BVLOS drones can enter these volumes only if the air risk is mitigated.

38 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

Planned manned aircraft activities (e.g. aerial work, HEMS landing and take-off) can be protected by a
Short Term Restriction (see [Link]) which will be reflected in the Geo-awareness data.

In Y and Z volumes, every operation will be known to U-Space and can therefore be brought to a
manned aircraft pilot’s attention.

3.3.5 U-space usage model - summary

This section is an abridged version the usage model of a UTM system, presented in more detail in
Annex L.

In the context of the U-space ConOps it is important to understand, how the U-space system could be
used. To elaborate on this, we introduce a model of a typical drone operation sequence, referring in
the workflow to Roles, Environment and Services identified elsewhere in the ConOps. It is assumed
that the U-space services are delivered via the internet to computers or mobile devices. The model
considers three phases or any drone operation;
 Pre flight
 In flight
 Post flight

The model considers that during flight conditions can be nominal or anomalous. An anomalous flight
results in a different post-flight workflow.

The basic starting conditions are set up in the “strategic” part of pre-flight. These steps, following the
procurement of a drone include:
 Registration of the drone if required – see [Link] and [Link]
 Registration of the drone operator – see [Link] and [Link]
 Pilot training (if applicable)
 Registration of any pilot training – see [Link] and [Link]
 Procuring relevant insurance if not per-flight
 Signing up with a U-space service provider

Once a decision has been made to fly, the “tactical” part of pre-flight starts to prepare a specific
mission. This includes:
 Becoming familiar with the location where the mission will occur – see [Link] and [Link] as
well as all Environment services – see 5.1.7
 (if appropriate) Selecting the appropriate drone and pilot to meet any airspace requirements –
see [Link]
 (if appropriate) Deciding on the type of operation; open, specific, certified
 Planning the operation – see [Link] and if appropriate [Link] (validation mode) which includes

o checking and planning appropriately for the airspace structure

o checking whether any geo-fence crossing permission is required

 (if appropriate) Performing SORA – see [Link]

 (if appropriate) Submitting the Operation Plan – see [Link] and [Link], which results in:

o Granting of any geo-fence crossing permit requested (in the form of a ‘token’ or
electronic key, see section [Link].2)
o Flagging any geo-fences that cannot be crossed
o Strategic conflict resolution
o (if appropriate) dynamic capacity management
© – 2019 – CORUS consortium except as noted. 39
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

o Acceptance or refusal of the operational plan

 Downloading the plan into the drone and/or remote piloting station (as appropriate)

Once the pre-flight phase is done, the drone can be prepared for take-off.

Flying has a normal routine and particular actions to be taken if something goes wrong. The normal
sequence of events would be:
 Prepare the flight area (if appropriate) including take-off and landing points
 Verify the conditions for flight are within the limits planned: Weather – see [Link], Airspace
(geo-fences) – see [Link], Other air traffic – see [Link]
 Check the flight area for unexpected risks (such as the presence of people)
 Check the Operation plan (if any) is still OK – see [Link]
 If not done previously, download the plan into the drone and/or remote piloting station (as
appropriate)
 Prepare the drone for flight, check it is airworthy and ready to operate, follow pre-flight checklist
 Prepare the payload
 Log on to U-space and configure the Emergency Management Service for the current operation
– see [Link]
 Log on to the Position report submission sub-service send Start of Flight, enable position report
submission (if used) – see [Link]
 Take-off
 Fly, during which continuously monitor

o The Drone’s flight

o The Mission goal
o Conformance with the plan
o Geo-awareness – see [Link] or [Link] as appropriate
o Other traffic – maintaining separation at all times
o Ground risk (people in particular)
o Warnings from the Emergency Management Service [Link]
o Traffic information [Link] if available
o Tactical conflict resolution [Link] if available
o Collaborative interface with ATC [Link] if available
o Comms and Navigation infrastructure failure warnings if available – see [Link] and
[Link]

 Land
 Switch off position report submission, Send End-of-flight (as appropriate) – see [Link]
 Go through end-of-flight checklist, e.g. power-off…
 Log-off U-space

If the flight should experience any irregularities an ad-hoc analysis made. The corrective action or
mission modification to be taken immediately should be decided upon and taken. The pilot should
make use of the Emergency management service as appropriate – see [Link]

Normal post flight workflow makes little use of U-space services. Typical steps include:
 Fill in a log or flight report as the operator’s processes require
 Check the mission has been successful

40 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

 Check the drone

 Either prepare for another flight or pack up

A flight which has experienced some sort of problem may lead to the use of the Accident and incident
reporting service, [Link]. Any such irregularities should be fully analysed and reported as part of the
process for ensuring that they do not re-occur. Any remedial action necessary should be planned and
undertaken before similar flights proceed.

A much more exhaustive exploration of the usage model can be found in Volume 3, annexes.

3.3.6 Prioritisation
U-space gives priority to emergency services and similar operations as discussed in [Link]

U-space occasionally needs to make choices between seemingly equal priority flights that
disadvantage one or some and advantage others. This typically happens during Dynamic Capacity
Management [Link] and Strategic Conflict Resolution [Link].

[Link] Priority
There is a general principle that priority should be given to life-saving operations, to emergency
services and to police. A second consideration is the relative agility of the aircraft; more manoeuvrable
aircraft should make way for less. A proposal taking these principles into consideration is as follows.

Priority Type of operation

1 (max) Emergency – Air ambulance, Search and rescue, catastrophe…
2 Hospital (Hospital transport)
3 Authorities (Police, other)
Military
4 Urgent Transport
Passenger transport
5 Agriculture
Inspection
Infrastructure
Science
Weather
6 Transport
7 Video, Filming, TV
Empty flight (ferry flight)
8 (min) Leisure, Sports
Table 3 Possible prioritisation

Table 3 should be considered as a proposal and has not been validated.

[Link] Demonstrably random choices

There are many alternatives for prioritisation, but most seem to penalise particular groups of users,
for example allowing airspace to be reserved by the first operator to file a plan will systematically
negatively impact delivery operations which occur at short notice. In the interests of general
acceptance, U-space implementations should make demonstrably random choices in these situations.
© – 2019 – CORUS consortium except as noted. 41
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

3.3.7 Reasonable time to act

This section has not achieved general acceptance yet but is part of the ConOps as it raises the topic of
equity on the airspace access for different type of drone business.

For any drone operation, there is a time period far enough before flight that a disturbance to the
operation has minor repercussions. After that time the effect of change becomes harder to accept. (It
could be argued that the time depends on the nature and size of the disturbance as well as the type of
flight – but this process needs to be simple.)

This time is known as the “reasonable time to act” (RTTA) and can be different for different operation
types. No value is specified in this version of the ConOps - determining it is left for future research.

RTTA impacts how the flight is treated in processes like strategic conflict resolution and dynamic
capacity management. Both of these processes need to act as close as reasonably possible to the take-
off time of the flight in order to work with the most precise picture of the traffic. At the same time the
two services need to avoid an implicit prioritisation based in the order in which operations are planned
because this is disadvantageous to operations which cannot be planned long in advance.

If an operation plan has been submitted before its RTTA, then from RTTA until take-off U-space will
protect that flight from any further change in all but the most extreme situations.

If an operation plan is submitted later than its RTTA then that flight will be processed at a disadvantage
in strategic conflict resolution and dynamic capacity management.

42 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

4 Safety & Social aspects

4.1 Ground risk terms
4.1.1 Ground risk
The ground risk is a very rough classification of the harm that is likely to result from a drone falling to
earth. Numerous terms are used in the reference material; rural, urban, sparsely populated, crowds of
people, etc. The classifications usually consider the density of human life and the density of buildings
or property.

This ConOps uses the following terms as found in the draft AMC7 [3]:
Term Meaning Examples
Densely populated area Area where people are Urban area, Residential area,
always present, frequently Industrial zone, Highway, Harbour
present or have gathered Recreational park
temporarily Tourist beach (when crowded)
Open-air music festival or agricultural
show
Sparsely populated area Area where people and Farm land, Rural area
buildings are few but not
absent
Desert area Area where few people are Remote forest, moor or mountain
present, infrequently Open sea, Open desert
Table 4 Ground risk terms

4.1.2 Airport related risk

The ConOps has specific terms for the zones in and around Airports (as in airports for manned
operations). These zones present a “low altitude” risk combining ground and air risks. Three terms
are defined:
Term Meaning
Near Airport Outside the fence of the airport but close enough to penetrate the
airport in a short time, should something go wrong.
Movement area The runways, taxiways, apron.
Any place where the presence of a drone – flying or crashed – could
endanger manned aviation
Airport, outside Inside the fence of the airport but not in the movement area.
movement area
Table 5 Airport related area terms

7
In the days between versions 03.00.01 and 03.00.02 of this document the AMC has been published [57]. These
terms come from the Draft AMC [3].

© – 2019 – CORUS consortium except as noted. 43

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

4.2 Privacy, Confidentiality and Electronic conspicuity

4.2.1 Privacy of citizens and confidentiality of DRONE OPERATIONS
The right-to-privacy is a critical concept for U-Space and is considered fundamental when the safety of
a flight does not impose an immediate danger to life. The right to privacy applies to individuals, such
as the pilot, the client contracting a drone service and especially to the citizen being recorded by the
camera of a drone. Moreover, companies doing business with drones, may need to keep secret their
business model, which may include their flights. For this reason the ConOps proposes the use of
identifiers for the flights to be agnostics keys, with no information about the type of drone, the drone
operators or the origin-destination of the flight. Only authorised U-space roles will be able to retrieve
such information from the system and any of these consultations will be recorded..

Drone operators collected data and data shared between U-Space Service providers must not violate
the GDPR that protect the individuals’ right-to-privacy. These include the unnecessary monitoring and
tracking of people or objects, widespread broadcast of a person’s identity and the excessive collection
and processing of personal data. The purpose of U-Space must not be to use drones to track patterns-
of-life and the identity of a drone operator must only be shared where appropriate.

The default U-Space assumption should always be to protect privacy and identity sharing should be
based on the local geographical requirements, such as being near a school, an airport or some other
managed airspace. In such instances there are many reasonable reasons to exchange identity and
location data with the local stakeholders.

[Link] Identifying a drone

Reasons for identifying a drone include:

 Safety – to ensure both the air and ground risk is not compromised by an unidentified drone
 Security reasons – suspicion that the aircraft is violating the law e.g. infringement of an airport
control zone.
 Privacy reasons – suspicion that the aircraft is illegally photographing the observer or an
otherwise private location.
 Environmental reasons – a drone is making excessive noise.
 Social reasons – a citizen sees a drone and wants to know more, even if they don’t suspect there
is anything wrong.

Some of these reasons are more important than others and different actors will naturally have
different priorities e.g. bird watchers and security guards have different justifications for wanting more
information. The solution to drone identification needs to be proportionate to solving the problem
above. For example, a hobbyist “drone watcher” does not have a safety reason to know where a drone
took-off or its plan operation (e.g. the previous or future path); however, at a minimum, they are
justified to ask U-Space “Are you aware of the drone I’ve just seen?”

The means for a member of the public to ask such a question is described in section [Link]. The result
will be that U-space confirms that it is aware or logs the report as unknown. If safety or security
considerations justify, an unknown report may trigger an immediate action. In the general such reports
will be logged for a period in case they can be of use to investigate accidents or criminal activity.

44 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

Users with appropriate credential will be able to see more information as a result of identifying the
drone.

As Open operations will generally not be known to U-space, the identification process will rely on the
reception of the “Remote Identification” signal sent by the drone (if any – see [Link]) and subsequent
use of the E-identification service of U-space – see [Link].

For Open operations made with C0 drones (see the delegated act [2]) or non-Open operations that do
not necessarily send Remote Identification, while flying in X there should be a relatively short distance
between the remote pilot and the drone. In Y and Z volumes, identification may be possible without
Remote Identification by means of track information.

The operators of Police or other state drones may not want their flight to be identified, for example if
the drone is being used to observe criminal activity. If a query by the public returns any information in
the general case, it may have to return false information in these cases.

[Link] The Public Portal

A Public Portal enables the general public to request information about a drone sighting. This ConOps
does not define the technical specification for this portal, rather but defines the high-level principles.
Fundamentally, if someone can “see” a drone flying near them, then the Public Portal should allow
them to easily interact with U-Space to request more information.

In principle, the portal should be able to automatically establish the reason(s) why a citizen is
requesting to about know details about a private operation. This could be as simple as the drone is in
local proximity and they want to know if the drone is known to U-Space. The citizen should be able to
report back to U-Space if they believe a drone is non-compliant or possibly infringing into a UAS flight
restriction zone. They may also request information about the operator or U-Space service provider.
Depending on the local legislation or industrial (self) regulation a level of detailed information will be
responded; however, for security issues, the response might be more like “this is a [government] non-
commercial UAS vehicle” with little further information.

In order for the public portal to be effective, the majority of drone sighting should be discoverable
through the portal. If a solution which uses a mobile phone camera can discover only a small
proportion of visible drones then the general public will not have an effect portal into U-Space. Any
solution must therefore be widely deployable.

The Public Portal may be implemented as the application for public use of remote identifictaion. See
sections [Link], [Link] and [Link].

4.2.2 Electronic conspicuity in U-space

Electronic conspicuity is a term used for a collection of technologies that enables the broadcast or relay
of an ownership’s location or position to other airspace users and ground operators. There are three
applications of electronic conspicuity in U-space:
 Direct Remote Identification, described in section [Link], primarily intended to allow an
authorised observer to identify a drone and its operator.
 Signals sent with the primary aim of enabling Surveillance such as ADS-B8

8
ADS-B is given as an example. This ConOps does not assume any particular technology choices.

© – 2019 – CORUS consortium except as noted. 45

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

 Signals sent for the purpose of collaborative Detect and Avoid, discussed in section 2.5.4, such
as FLARM

Detect and Avoid is discussed in this ConOps in terms of drone-drone interactions (section 2.5.4) and
to a lesser degree interactions between drones and manned aircraft (section [Link]). Crucial to further
exploration of detect and avoid will be the choice of whether detect and avoid involves ground systems
– and hence may take advantage of U-space track data – or is a function purely inside the aircraft based
only on information the aircraft can receive. The latter option might be simpler hence possibly more
robust, but it would imply that electronic conspicuity broadcast more often and more strongly.

4.3 Contingency
In this chapter some proposed Contingency Plans for drones and U-space Services are presented. To
understand when a Contingency Plan comes into force, it is important to clearly differentiate between
a Mitigation, Contingency or Emergency. The (non-exhaustive) definitions below explain when they
come into force. Note: A full definition of these three terms is presented in Volume 3

Figure 4 The relationship between Mitigation, Contingency and Emergency

4.3.1 Mitigation:
Mitigation is a precautionary measure to avoid that an unwanted threat/event is happening.

Example: Redundant radio link. In case the primary radio link fails, the secondary radio link engages
and mitigates a failure of the whole radio system.

4.3.2 Contingency plan:

[Link] U-space service

A contingency plan of a U-space service enters into force if misbehaviour of the service is detected or
the plausibility check of the service detects input data from external sources that are missing, wrong
or arrive with high latencies. It is a precondition that the service itself be stable, be under control and
be able to detect those occasions.

Example: Monitoring service detects erroneous data from tracking service, so it gives a warning to
affected drone users/operators.

46 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

[Link] Drone user/operator

A contingency plan for a drone user/operator is a backup plan (Plan B) for the pilot, describing
procedures to follow in a possible incident. It aims to maintain the level of operation.

Example: The navigation GPS system fails, but the drone is still controllable, so the pilot switches to
manual/stabilised flight mode.

For drone operators that have developed an Operations Manual, the contingency plan for such an
abnormal situation should be part of the Standard Operating Procedures.

4.3.3 Emergency:

[Link] U-space service

An emergency of a U-space service enters into force if the service is out of control or lost completely.

[Link] Drone user/operator

An emergency for a drone user/operator is an incident/accident which causes the drone to be out of
control.

Example: The navigation GPS system fails which causes the drone to be out of control, so the pilot
deploys the parachute.

For drone operators that have developed an Operations Manual, an emergency procedure for such an
abnormal situation should be part of the Standard Operating Procedures. The Operations Manual may
include Emergency Response Plan (ERP) to minimise the escalating effects of an operation out of
control)

4.3.4 Contingency plans for drones

Some examples are given here. More appear in Volume 3. Contingency plans may be expected to
appear as standard operating procedures listed in the drone operator’s Operations Manual, if the
operator has one.

CP1: If the drone experiences a loss of datalink, position emitter/receiver failure, directional loss, or
flies through an area of electromagnetic interferences, it must either return to home/launch or land
at a dedicated landing area, automatically.

CP2: If a drone experiences a flight controller failure, unintentionally loses altitude, flies through
severe weather, collides with an obstacle or other air traffic, or is totally lost, it must activate the
emergency landing protocol immediately. Emergency equipment (e.g. parachute, lights to be seen at
night, and a signal to be heard on ground) must be activated. Furthermore, either the pilot or the drone
must immediately send an emergency signal via the emergency management service - [Link].

CP3: In the case of a critical human error or medical issue with the remote pilot, a backup pilot must
take over the flight immediately, if available. If no control input is received by the drone for longer
than a determined time period, CP1 must be activated.

© – 2019 – CORUS consortium except as noted. 47

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

4.3.5 Contingency plans for U-space services

Service Contingency Plan

E-Registration: To be developed
E-Identification: To be developed
Pre-tactical Geofencing: If the service detects that received data is faulty, it has to correct the
missing data and send a message to the affected users/operators.
Tracking: If the service detects that data from drone(s) is missing or faulty, it
has to send a message to the affected users/operators. In U3 a
dynamic geofence must be put around the predicted position
(triggers Emergency Management notification).
If a received track cannot be correlated to a flight plan, the service
has to send a message to the drone user/operator. If necessary it can
command the pilot/drone either to hold position/circle until
correlated/situation awareness is restored or land at dedicated
landing area.
Drone AIM: If the service detects that received data is faulty, it has to correct the
missing data and send a message to the affected users/operators.
Tactical Geofencing: If a drone flies through prohibited area, because the upload of the
geo-fence was unsuccessful/delayed, the service has to send a
message to the drone user/operator and, if necessary, warn other
drones/aircraft in the affected geo-fence.
Drone operation plan To be developed
processing:
Strategic Conflict To be developed
Resolution:
Emergency Management: In case of an emergency, the service has no working datalink to a
drone operator; the drone user/operator must be contacted by
phone. (This demands a requirement for all drone users/operators to
be on call)
In case of an emergency, a drone user/operator has no working
datalink to the emergency management service; the drone
user/operator has to contact the service provider via
hotline/emergency phone.
Monitoring: If the service is not fully operative due incoming faulty data or high
latencies, it has to give a warning to all affected drone
users/operators. If necessary, a different (higher) separation
between drones can be demanded from the dynamic capacity
management and/or tactical deconfliction service.
Traffic Information: Same as Monitoring
Weather Information: If the service limited due to insufficient data or other reasons, it has
to give a warning to all affected drones and drone users/operators.
Furthermore it has to provide the calculated forecast.
Procedural Interface with If the datalink between the U-Space System and ATS fails, the
ATS: permission of a take-off can be denied if the drone is not airborne
yet. (If the drone is already airborne it is not a contingency but an
emergency and therefore out of scope of the Contingency Plans)
48 © – 2019 – CORUS consortium, except as noted
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

Service Contingency Plan

Dynamic Geofencing: Same as Tactical Geofencing
Collaborative Interface Same as Procedural Interface with ATS
with ATS:
Tactical Deconfliction: To be developed
Note: If the service fails to detect or solve a conflict, it is backed-up
by DAA (Detect and Avoid) in U3, Monitoring Service and Traffic
Information
Dynamic Capacity If the service is out of order, the latest capacities shall be restored
Management: from a back-up system. Access to the airspace shall only be granted,
if the capacitiy was under a certain threshold. Otherwise access shall
be denied, and a report to the Tactical Deconfliction Service shall be
sent to vector (reroute) the affected drones.
Table 6 Contingency plans for U-space services

4.4 Accident and Incident Investigation

4.4.1 Additional events to be reported
The following are the proposed modifications to the existing EU 2015/1018 implementing regulation
concerning the occurrences that must be reported. The need of reporting a drone incident shall follow
the proportional principle, when safety of life can be potentially affected. It is an addition to what is
already written and is subdivided per different Annexes sections:

Annex I: AIR OPERATIONS

 1.1 Flight Preparation

o incorrect data inputs in the drone navigation software (4D trajectory, geo-awareness
update)

 1.2 Aircraft preparation:

o Drone improperly assembled (including software)

 1.3 Take-off and landing:

o Non-respect of safety distance from obstacle, or persons, during take-off or landing

 1.4 Any phase of flight:

o Lack of activation of the flight envelope protection, including stall warning, stick
shaker, stick pusher, automatic protections and geo-awareness manoeuvres.
o Misinterpretation of automation mode or of any flight deck information provided to
the remote pilot, which has or could have endangered the aircraft, its occupants or
any other person.
o Unintentional deviation from intended or assigned track

 1.5. Other types of occurrences:

o loss of communication with the observer in case of extended visual line of sight (E-
VLOS) operation.
o loss of visual contact in case of visual line of sight (VLOS) operation.
© – 2019 – CORUS consortium except as noted. 49
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

o Drone flying in airspace type not corresponding to his assigned category (X, Y, Z)

 3. INTERACTION WITH U-SPACE SERVICES AND U-SPACE TRAFFIC MANAGEMENT (UTM)

o Unsafe clearance.
o Prolonged loss of communication with UTM Unit.
o Conflicting instructions from different UTM Units potentially leading to a loss of
separation.
o Intentional deviation from UTM services instruction which has or could have
endangered the RPAS, its occupants (if any) or any other RPAS or Aircraft

 4. EMERGENCIES AND OTHER CRITICAL SITUATIONS

o Failure to apply the correct non-normal or emergency procedure by the remote pilot
to deal with an emergency
o Remote pilot fatigue impacting, or potentially impacting, the ability to perform safely
their flight duties.

 6. SECURITY

o Difficulty in controlling, intoxicated, violent or unruly payload 9 endanger the flight

o Discovery of a stowaway
o Hack of the communication C2 channel

Annex II: OCCURRENCES RELATED TO TECHNICAL CONDITIONS, MAINTENANCE AND REPAIR OF THE AIRCRAFT
 2. DESIGN

o Any failure, malfunction, defect or other occurrence related to a product, part, or

appliance which has resulted in or may result in an unsafe condition.

 3. MAINTENANCE AND CONTINUING AIRWORTHINESS MANAGEMENT

o Wrong assessment of a serious defect, or serious non-compliance with MEL (Minimum

Equipment List) and Technical logbook procedures.
o Significant malfunction, reliability issue, or recurrent recording quality issue affecting
a flight recorder system (such as a flight data recorder system, a data link recording
system or a cockpit voice recorder system) or lack of information needed to ensure
the serviceability of a flight recorder system.

Annex III: OCCURRENCES RELATED TO AIR NAVIGATION SERVICES AND FACILITIES

 1. AIRCRAFT-RELATED OCCURRENCES

o Detect and avoid Resolution Advisory

o Aircraft deviation from applicable air traffic management (ATM) or U-space regulation:
 aircraft deviation from applicable published ATM or U-space procedures;
 airspace infringement including unauthorised penetration of airspace;
 deviation from aircraft ATM or U-space-related equipment carriage and
operations, as mandated by applicable regulations.

9
Payload maybe constituted by passenger on taxi service

50 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

 2. DEGRADATION OR TOTAL LOSS OF SERVICES OR FUNCTIONS

o Inability to provide ATM or U-space services or to execute ATM or U-space functions:

o Failure of ATM or U-space system security which had or could have a direct negative
impact on the safe provision of service.
o Prolonged loss of communication with a remote pilot or with other ATS unit.

Annex IV : OCCURRENCES RELATED TO AERODROMES AND GROUND SERVICES

 [Link] MANAGEMENT OF AN AERODROME

o 1.1. Aircraft and obstacle-related occurrences

 Foreign object on the aerodrome manoeuvring area which has or could have
endangered the aircraft, its occupants or any other person

4.4.2 Proposed changes for reporting to responsibilities

Concerning the witnesses of occurrence the following recommendations are identified:
 Verifying training needs about reporting practices for witness (who is obliged to report
occurrences). Are all witnesses aware of how to do that?
 Maintaining the level of safety culture from manned aviation to RPAS users and operators, so
that to build awareness on the importance of an efficient reporting system.
 Availability of a user-friendly tool to ease the process of events reporting

4.4.3 Proposed changes for practices and reporting repository

The overall objective of aviation safety improvement cannot be sufficiently achieved by the Member
States, because reporting systems operating in isolation are less efficient than a coordinated network,
where exchange of information and identification of possible safety problems with associated key risk
areas take place. Therefore, it is highly recommended that analysis at national level should be
complemented by analysis and follow-up at Union level, to ensure better prevention of aviation
accidents and incidents.

Furthermore current EU Regulation 996/2010 invites single states in doing investigations networking
through the setting up of -ENCASIA (European Network of Civil Aviation Safety Investigation
Authorities) and through invitation of EASA and its representatives to national investigations. It is
recommended that further inputs to users will be provided by clarifying the role and associated
responsibilities of a trans-national investigation authority, which would have the possibility to build
the European wide picture.

On the other side, no changes are expected in terms of central repository to be used (i.e. ECCAIRS), as
well as for timing of the expected notification to the competent authorities and timing for
investigations. However, adaptation of current taxonomy to take RPAS operations into account should
be performed. Particularly, a gap analysis on what is existing today and what is missing should be
performed by EASA, which has a dedicated sub-group working on taxonomy updates for the relevant
regulations (Safety Recommendations Taxonomy working group) The outcome of this analysis will
identify the terms missing and may trigger connected updates.

Finally, experience has shown that accidents are often preceded by safety-related incidents and
deficiencies revealing the existence of safety hazards. Safety information is therefore an important
resource for the detection of potential safety hazards. In addition, whilst the ability to learn from an
accident is crucial, purely reactive systems have been found to be of limited use in continuing to bring
forward improvements. Therefore, reactive systems should be complemented by proactive systems.
© – 2019 – CORUS consortium except as noted. 51
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

4.5 Uncooperative Drones

U-space and UTM-systems fundamentally deal with cooperative UAS, which are UAS that, at
appropriate times, submit an operational plan, emit remote identification signals, submit reports of
their position to U-Space, and so on. However, there will also be uncooperative UAS, rogue UAS, hostile
UAS, or “lost” UAS, which might expose a threat to critical infrastructure like airports, test sites, or
gatherings of people (e.g. for sporting events). Drone Detection Systems (DDS) are an upcoming
technology that is dedicated to identify uncooperative UAS at a range of 500m to 5000m today. Their
scope is local, different from UTM where the scope is at least regional, if not national. UTM systems
cannot embody DDS functionalities due to cost and complexity, but it is useful to consider system
collaboration.

DDS typically consist of

 Surveillance sensors
 Multi-sensor data fusion servers
 Database servers
 Map-based situation displays

Some variants also include C² (Command and Control) servers that allocate effectors or weapons to
detected objects, plus the effectors for drone intercept. Such effectors today are: Jammers, HPEM
(High Power Electro-Magnetic) emitters, nets, anti-drone drones, water guns, or – in military context
– missiles and cannons. The use of effectors may be a critical issue in airport contexts. The surveillance
sensors of DDS have to detect comparatively small objects down to half a meter in diameter, therefore
the range of detectability is limited. Usual sensor settings are combinations of
 Phased-array/holographic type of primary radar
 Multi-static primary radar for passive coherent location
 Electro-optical/infrared sensors and cameras
 Acoustic arrays
 HF, VHF, UHF, SHF scanners
 laser sensors and scanners (e.g. LIDAR)

Due to surveillance range, complexity and cost, DDS are local systems, based on client-server
architectures with local area networks. Cost grows proportional to detection range. Some variants
using cloud technologies and web-based clients also exist, but have to take additional measures for
cyber-security and vulnerability resilience. Because of its multi-sensor nature, effective multi-sensor
fusion and tracking is an utmost requirement in DDS. The result is primary tracks of detected drones
with associated properties gathered by the various sensors. Besides track number, 4D position, speed,
and heading this might include UAS type/brand, subtype, power type, number of rotors, shape, size,
link version, the involved RPS type. If DDS communicates this track information to UTM, the UTM track
fusion may determine whether there is a kinematic fit with existing tracks of cooperative UAS, and
report this information back to the DDS. The remaining tracks are then to be considered as
uncooperative, and eventually hostile. At the end of this system communication both systems – the
DDS and the UTM – agree which uncooperative UAS and which cooperative UAS are in the given range
of surveillance. While the DDS remains local in scope, the cloud-based trans-regional or even national
UTM system may have several attached DDS-systems, and may serve this way as a trans-regional
information exchange platform for classification purposes. However, there will always be a limitation
in completeness of the surveillance of uncooperative UAS, the full coverage of a whole country with
DDS capacity will be too costly.

52 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

It might be expected that DDS will be installed at major airports to protect airport operations against
uncooperative UAS as seen in the Gatwick case of December 201810. A national UTM might collaborate
with the related DDS for drone information exchange and intelligence data collection for police forces.
Other hotspots of critical infrastructure may be added stepwise, and thus contribute to better
surveillance and intelligence. Defence against rogue drones everywhere, however, must be considered
as unrealistic for the current state of technology.

As the Gatwick case has shown for the attacked airports it is very relevant
 to detect such threats as early and as reliably as possible with the help of such DDS
 to have an existing communication infrastructure between the necessary stakeholders
 to have defined workflows and procedures between the necessary stakeholders
 to have an established and proven decision structure for situation assessment and planning of
measures
 to have a legal basis for taking action

Once such collaboration between UTM and DDS is emerging, it might be useful to extend the ConOps
aspects of UTM for these issues, covering
 Operational workflows between UTM and DDS users, including

o data flow (information, warning, alerts)

o data contents (track, features, imagery, acoustic patterns, context)
o intelligence collection

 Workflows between operational users, authorities, and law enforcement

o Situation assessment
o Monitoring
o Reporting
o Alarming
o Countermeasures
o Return to normal operations
o Postprocessing (lesson learning)

4.6 Cyber security of U-space

Security, besides safety, is essential for the public acceptance of drone operations. Security risks in U-
space need to be assessed and mitigated to an acceptable level. Secure drone operations need to be
supported by a combination of different security functions at different levels in the drone end-to-end
system, managed by a dedicated set of procedures and supported by clear regulations.

Given the highly automated nature of U-Space, cyber security is particularly important. A preliminary
cyber security risk assessment was performed to determine the risks concerning confidentiality,
integrity and availability (CIA) of the U-Space information flows. The task of security is to assure that
these risks are on an acceptable level by means of mitigating actions where needed.

The preliminary assessment of the U-Space information flows revealed the following high-level
findings:

10
[Link]

© – 2019 – CORUS consortium except as noted. 53

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

Integrity – Integrity was identified as the most critical property to ensure secure U-Space operations.
Mitigating actions required are authentication and authorisation of information flows between U-
space services, but also continuous integrity verification of data(bases) such as registration and
geofencing data. This is also applicable for information flows not coming directly from a U-space
service, but used by U-space, such as the GNSS signal to determine the GPS positions. Furthermore
mitigating actions are also required to ensure the integrity of software/firmware updates of the U-
space services/systems and drones.

Availability – Availability of the U-space services is essential for secure operations. Mitigating actions
include duplication of the essential services/systems to ensure redundancy and measures to prevent
disruptions, to prepare for and adapt to changing conditions and to respond and recover rapidly from
disruptions to ensure the continuity of services at an acceptable performance level (resilience).

Confidentiality – Confidentiality was identified as less critical for secure operations. Mitigating actions
shall be taken to ensure that confidential information, including privacy sensitive information, is stored
securely and is made available only to authorised services and stakeholders.

Security awareness – Security awareness is seen as an important security measurement to reduce the
security risks in general. This can be in the form of security training of the essential operators, but also
information campaign for drone operators and pilots.

Enforcement – Enforcement is needed to assure that the stakeholders are following the law, but also
to respond when they do not or to counter a drone when it becomes a risk for critical infrastructures
or people. Besides the event handling and incident reporting services, an independent monitoring
service is required for certain areas, to identify (rogue) drones. Also measures are needed to counter
these drones, supported by the appropriate regulations.

4.7 Best practices

The emergence of unmanned aerial systems (UAS) as a resource for a wide variety of public and private
applications quite possibly represents one of the most significant advancements to aviation, the
scientific community, and public service since the beginning of flight. Rapid advancements in the
technology have presented unique challenges and opportunities to the growing UAS industry and to
those who support it. The future of UAS will be linked to the responsible and safe use of these systems.
Operations should be conducted in a safe manner that minimises risk and instils confidence.

The CORUS project finds that the ‘UAS Pilots Code’ [32] captures this need well and the following is
adapted from their work with the permission of Aviators Code Initiative

Best practice should offer recommendations to advance flight and ground safety, airmanship, and
professionalism. It should present a set of recommended practices—a vision of excellence—to help UAS
pilots interpret and apply standards and regulations, and to confront the real-world challenges to avoid
mishaps. It should be designed to help UAS stakeholders to develop standard operating procedures,
effective risk management, safety management systems, and to encourage the industry to consider
themselves aviators and participants in the broader aviation community.
Best practices should be built on three specific themes: Flight and ground safety, professionalism,
privacy and respect. Each theme and its associated recommendations should represent a “common
sense” approach to UAS operations and address many of the concerns expressed by the public and
54 © – 2019 – CORUS consortium, except as noted
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

regulators. The best practice should provide UAS manufacturers and users a convenient checklist for
operations and a means to demonstrate their obligation to supporting the growth of our industry in a
safe and responsible manner.

[32] is copyright Aviators Code Initiative - [Link]

A much more detailed study of best practice can be found in Volume 3, Annex I

© – 2019 – CORUS consortium except as noted. 55

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

5 Services and High Level Architecture

5.1 U-space services
The Blueprint [6] listed some U-space services. These services were described in more detail in the
Roadmap [7]. CORUS has reworked the set of services slightly, as described in the Appendix section on
Architecture. The following diagram, Figure 5, presents the services together, indicating which can be
traced back to the Roadmap [7] and which have been added

Airspace
Identification and Mission Conflict Emergency Interface with
Management / Monitoring Environment
Tracking Management Management Management ATC
Geo-Fencing

Operation plan Strategic Procedural

Emergency Weather
Registration Geo-awareness preparation / Conflict Monitoring interface with
Management Information
optimisation Resolution ATC

Drone
Incident / Geospatial Collaborative
Registration Aeronautical Operation Plan Tactical Conflict Traffic
Accident information interface with
Assistance Information processing Resolution Information
reporting service ATC
Management

Geo-Fence Citizen Navigation

Risk Analysis Population
e-identification provision Reporting Infrastructure
Assistance density map
(includes service Monitoring
Dynamic Geo-
Fencing)
Tracking Dynamic Communication Electromagnetic
(Position report Capacity Infrastructure interference
submission) Management Monitoring information

Surveillance
Data Exchange
U1 U2 Legal Recording
Navigation
Coverage
information

U3 Added
U2
Communcation
Digital Logbook Coverage
information

Figure 5 U-space services

The services listed in Figure 5 are all related to safety and or security. There will be other U-space
services which are business related. CORUS views such business related services as being outside the
scope of this document.

The services are now described in detail, grouped in the clusters given in Figure 5.

5.1.1 Identification and tracking

Remote Identification, as described in section [Link] involves the emission of the current position of
the drone. CORUS assumes that in some cases this signal will be the basis of position report submission
of the drone to U-space and hence makes a link with Position report submission and Tracking.

[Link] Registration service

The U1 service Registration is a basis that enables many other functions of U-space. The U-space e-
registration service answers the requirement for registration that appears in the Implementing
legislation [1] Article 14, “Registration of UAS operators and certified UAS,” which lists fairly precisely
what information is expected. The U-space e-registration service is the digital implementation of the
requirement. To achieve Registration, there should be some secure and high availability registry (data
store), with appropriate means available for different classes of user to input/update their own data
or (when permitted) query the contents of the registry. There will need to be agreed processes to
determine who is permitted to query or even change the contents of the registry and in what
56 © – 2019 – CORUS consortium, except as noted
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

circumstances, for example to remove a record following a death or winding up of a company, or after
a court order. The Registry will also need to be connected to other systems so as to confirm that
people, businesses, addresses and other information mentioned in inputs really exist.

As is explained in section [Link], the registry must give rapid responses to queries.

The following table lists (most of) the roles and actions that are supported by the e-registration service.
Role / Node Action Notes
Drone operator Register operator: Registering of drone
representative - Create new registration of self operators is required in
- Review own registration many but not all cases.
- Update own registration Update might be
- Delete own registration provoked by change of
address.
Drone owner Register operator: Only in cases where
representative - Create new registration of self drown owner
- Review own registration registration is required.
- Update own registration
- Delete own registration
Accredited registry View some information in the registry, as Police or security agent
reader appropriate for that person’s permissions. are examples of
stakeholders that would
also have Accredited
registry reader status
Accredited registry Register pilot and/or pilot training: Drone pilot schools hold
updater - Create new registration of pilot or training this role.
- Review pilot registration or training Pilot schools deletion of
- Update pilot registration or training pilot registration would
- Delete pilot training or registration be in exceptional
circumstances
Drone pilot Register pilot: Update might be
- Create new registration of self provoked by change of
- Review own registration address, for example.
- View / Print own training records
- Update own registration
- Delete own registration
Registrar Create / Review / Update / Delete Impacts:
accreditaion of persons / organisations Accredited registry
allowed to access the registry to write or read updater
information. Accredited registry
reader
Registrar Create / Review / Update / Delete registration …generally when the
entries in exceptional conditions usual actor is unable,
unwilling or untrusted.
Table 7 Summary of e-Registration

Note in the actions above, deleting will probably not remove the record but mark it as no longer active.
How this is presented would depend on who is looking.

There shall be standard protocols for querying and describing pilot training. When answering such
queries, the registry itself should be able to recognise any elements that are too old to still be valid.
© – 2019 – CORUS consortium except as noted. 57
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

The registry needs to be connected to other registries to allow cross border operations. Any drone
operator or pilot from anywhere in Europe should be able to operate in any European country, as long
as national laws and local rules are followed. Hence any registry should be able to respond to queries
about an operator or pilot by consulting the relevant registry in which the operator or pilot is known.

[Link] Registration assistance service

It may be that some specific registrations occur routinely, for example that a shop owner register a
drone (if required) or drone operator each time a drone is sold, or that a training school register pilot
training. Services may be offered to assist such routine registrations, presenting a user interface that
is simplified and/or partly filled in with standard information.

[Link] e-Identification service

Remote Identification is described in the regulations [1] and [2]. As is explained in section [Link],
Remote Identification is expected to have two implementations, Direct and Network. Direct Remote
Identification is a drone capability relating to the broadcast of an identifying signal with the intention
that it is received on some (portable) device nearby. Network Remote Identification is a process
allowing someone using a (portable) device which is able to detect the current position of the drone
to consult the tracking data of U-space, identify the relevant track and obtain equivalent identification
information - see [Link].

The U-space e-Identification service allows the identification information obtained by such a (portable)
device to be used – by any authorised person – to access information held “on the ground” to:
 Consult the Registry (see section [Link]) and find details of the operator
 View, on suitable equipment, the current position of the drone, the take off point and probably
also recent position reports (if available in U-space), images of the drone type, and any other
relevant information in a manner that aids visual identification.

As one aim of Remote Identification is law enforcement, all of these are to be accomplished quickly,
before the drone is out of sight of the law officer or out of range of the detection equipment.

Hence the e-identification service consists of

 lookup of the Registry
 association of the vehicle with any existing track or mission in U-space and if successful fetching
of relevant information (referring to the Tracking service and the Drone Operation Plan
Processing service)
 lookup of the type and hence provision of visual recognition information
 fetching of contextual information; nearby tracks or landmarks
 presentation of the above information in an accessible way
 (possibly) integration of the above information in real time with images from a camera to
produce an ‘augmented reality’ view

[Link] Position report submission sub-service

The Tracking service of U-space (section [Link]) cannot work unless U-space receives position reports
concerning drones. The Position report submission sub-service has been added in this ConOps to allow
that. It is not a service on its own but rather an important part of the Tracking service.

58 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

Position report submission will be an obligation in some airspaces and optional in all others. As stated
at the start of section 5.1.1, position reports could originate as e-Identification signals, received at the
remote piloting station and forwarded to U-space; but many other technical means exist for position
report submission. The service must be flexible in which technologies it supports as long as
performance based requirements can be met.

Where position report submission is an obligation, the drone operator or pilot will also be required to
monitor that position reports are being received by U-space. Hence the Position report submission
sub-service should not just allow reports to be sent, it should also give feedback that they are being
received. There should be alerts when some agreed time passes without a report; that time will relate
to the previous rate of pre-mission report submission and the precise navigational performance needs
of the airspace concerned. (See section 3.3.2)

Position report submission will need to be secure, reliable and low latency. The information in Position
Reports is safety critical11. The Position report submission sub-service must be deployed in a robust
and reliable manner because of its safety criticality.

Position report submission will involve the drone or the remote piloting station or some specific ground
equipment being connected to U-space, possibly by mobile internet. Implementations of the sub-
service shall include an appropriate level of cyber security to assure that the transmissions are coming
from the declared source and are being reliably received at intended end-point. To enable the secure
identification of the source, there will probably be a specific logon protocol, probably linked to start-
of-flight.

To distinguish between a flow of position reports stopping because the flight has ended and because
of a failure, there will be specific logoff protocol, probably linked to end-of-flight. The failure of position
reports in an airspace in which they are mandatory (for long enough to be considered real) will
constitute an emergency.

Drone position report submission will be an automatic process (the pilot will not type lat-longs) hence
the technical implementation will probably be fed by some software that is running at the drone or
remote-piloting station. The feedback that is given is intended for the pilot and may be delivered the
same way or through a web or similar interface that the pilot can conveniently consume.

All drone position reports should be recorded to allow the provision of the Accident and Incident
investigation (section [Link]). Hence the Position report submission service will feed the Legal
Recording service (section [Link]).

The Position Reports sent to U-space should include

 The current 3D position of the drone, expressed in the agreed measurement system and frame
of reference, to the precision expected in the airspace concerned.
 The uncertainty in the reported position (perhaps in the manner of ADS-B)
 The precise time at which the position has been measured, if available
 The means by which the position has been determined, and/or some identifier of the origin of
the report – so as to help the tracking service combine multiple sources of reports for the same
flight.
 If available the current speed vector of the vehicle, together with its uncertainty

11
Not all position reports for all flights are always safety critical, but that fact that some are, some of the time,
for some flights requires that all be handled as if they were.

© – 2019 – CORUS consortium except as noted. 59

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

 The identity of the vehicle, if available, preferably in the form used by Remote Identification see
[Link]
 The identity of the operator of the vehicle, if available
 The identity of the mission plan being executed – if any and if available
 In the absence of the vehicle’s identifier, if possible, a temporary identifier for the flight to ease
the job of the tracker12.

A Start of Flight report is a special report and will always originate from the remote piloting station or
by delegation the drone operator’s flight operations centre. It unambiguously identifies the operator
and identity of the vehicle. If there is a mission plan for the flight then that mission plan is identified in
the start of flight report. The time at which the flight will start is stated accurately (e.g. 1 minute or
closer). Start of Flight will include an indication of the expected rate of position report submissions.
Other than these conditions start of flight will resemble position reports described above. The start of
flight report may be part of a sign-on process to allow position report submission to commence. The
start of flight must not be sent too far in advance (e.g. more than 5 minutes) before the flight begins
in order that the flight start time can be believable. If the situation changes after Start of Flight has
been sent, then a new Start of Flight message will be sent giving the revised start time, or an End of
Flight sent to cancel the active status of the flight. The time given in the Start of Flight is the time that
the position report submissions begin.

An End of Flight report is a special report and always originates from the remote pilot station or by
delegation the drone operator’s flight operations centre. It unambiguously identifies the operator and
identity of the vehicle. If there is a mission plan for the flight then that mission plan is identified in the
end of flight report. The end of flight report must only be sent once the drone has landed and the
position report submissions end. It accurately indicates (e.g. to an accuracy of 1 minute or better) the
time at which the flight ended. The End of Flight report is sent as soon as possible after the landing
and the end of the position report submissions (e.g. within 2 minutes) to avoid an emergency alert
being triggered.

Pilots and operators of drones that cannot or will not send position reports during flight are still
encouraged whenever possible to send Start of Flight and End of Flight.

[Link] Tracking service

Because of the role of tracking in the processes of conflict resolution and traffic information, this
ConOps assumes that there will only be one safety-critical instance of tracking in any location, and that
is described here.

The U-space Tracking service incorporates the Position report submission sub-service described in
[Link]. Any instance of the Tracking service receives all position reports in its area of interest. Tracks
are built using a statistical process that can be assisted by having access to the operation plans of the
flights, hence the Tracking service is also a client of the Drone operation plan processing service [Link].

The Tracking service should be able to deal with multiple sources of reports for the same flight, as well
as (‘uncorrelated’) reports that do not contain the identifier of the aircraft or flight such as would come

12
Position reports being generated by multilateration may not include the official vehicle identifier but will be
able to associate a stream of reports to a single vehicle.

60 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

from primary radar, or that contain another (perhaps previously unknown) identifier for the flight or
vehicle, such as would come from cellular telephone triangulation, or from ADS-B.

The Tracking service should contain some sanity checks on the data being received and should be able
to flag suspicious position reports.

The Tracking service should produce track updates at a rate that is appropriate for the airspaces that
are in its area of interest. A track is a series of reports, each of the form:
 The identity of the vehicle and operator - if available (see section [Link])
 The identity of the mission plan being executed – if any and if available - or an automatically
generated identifier for the flight. (see section [Link])
 The identifier of the system that has calculated the track
 The time for which the track position has been calculated
 The 3D position of the vehicle at the time calculated, expressed in the agreed measurement
system and frame of reference
 The speed vector of the vehicle at the time calculated, expressed in the agreed measurement
system and frame of reference
 The (estimated) uncertainties in the calculated position and speed vector (or confidence if this
is more appropriate)

In the same channel as track reports as described above, the Tracking system should be able to signal
start of flight, end of flight – both derived from the corresponding signals in the position report
submission sub-service – as well as unexpected start of position reports and unexpected end of
position reports. The service should be able to signal significant changes of state, such as when a track
suddenly becomes correlated, when two tracks are reclassified as being the same, or when one track
is reclassified as two, and so on. Further anomalous conditions should be handled gracefully by the
tracking service but signalled such as when a series of position reports suddenly changes Identifier but
appears to be the same track, or when improper calibration causes a drone to report a heading or
speed that is inconsistent with the track - beyond what can be expected from the reported accuracy.

The Tracking service will need to be secure, reliable and low latency. The information in Tracks is safety
critical.

The Tracks generated in the Tracking service are consumed by the Monitoring service (section [Link]),
the Traffic Information service (section [Link]), the Tactical Conflict Resolution service (section
[Link]), the Legal Recording service (section [Link]) and the Drone operation plan processing service
(section [Link]). Tracks will also be sent to ATM when appropriate and sent in a format acceptable to
ATM. Tracks should be sent to (and received from) neighbouring U-space trackers as needed by cross-
boundary flights. The Tracking service shall also collaborate with drone detection systems (DDS) see
section 4.5

The presentation of Tracks is the job of Traffic Information service. The human-interface of the
Tracking service concerns alerting in case of problematic position reports or other anomalies.

[Link] Network remote identification sub-service

As described in sections [Link] and [Link] there needs to be a way to identify a tracked drone by
means of giving its current position and identifying the likely track or tracks that match this position.
The Network remote identification sub-service is a part of the U-space Tracking service and will be
available for authorised users. The returned information will be a list of zero, one or more matching
tracks. For each track the information returned will either be the equivalent of the (Direct) Remote ID

© – 2019 – CORUS consortium except as noted. 61

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

signal described in [1] and [2] or if this is not known to U-space, another identifier compatible with the
e-Identification service described in [Link].

[Link] Surveillance data service

The Surveillance Data service exchanges information between the Tracking service and other sources
or consumers of tracks (rather than individual position reports) such as
 Primary radar and drone detection similar systems, for example used at airports
 Drone tracking services based on cellular telephony information and similar
 Motion capture systems and similar that use their own tracking process
 ATM aircraft surveillance systems
 Neighbouring drone trackers

5.1.2 Airspace management / Geo-Awareness

This section draws together the Geo-fencing and Geo-awareness services expected in U1, U2 and U3,
together with the Drone AIM service, expected in U2.

[Link] Presentation of Drone Environment Data

The community of drone users contains very varied levels of familiarity with aeronautical practices and
terminology. It is important that displays of volume boundaries, geo-fences and drone airspace
information be comprehensible by their intended users. For example Open drone operations in
category A1 are available to a pilot of a class C0 drone “familiarised with the user manual provided by
the manufacturer of the UAS.” All UAS intended for use in the Open category will include an
information notice that includes the dos & don'ts that all Open category UAS operators shall be aware
of. Displays intended for such drone pilots should directly address questions like “where can I fly
today?”

This document has described a lot of types of airspace in section 3.1 but these need not always be
distinguished in a display; they might be generalised to fewer groups depending in the intent of the
display. Likewise as few drone users would be ready to read NOTAMS, it is expected that the
information in NOTAMS is extracted and relevant parts are shown when needed to the drone pilot.
This document leaves the choices of how to display geo-fence and drone aeronautical information to
the ingenuity and imagination of the businesses building software tools for drone operators.

[Link] The terminology of Geo-fences and Geo-awareness

Geo-fences are geographic boundaries which should be respected during drone flight. The term may
be can be used for any of
 Features described in the AIP such as the perimeter of a CTR or a restricted area.
 Drone aeronautical information features such as the perimeter of an area where people have
gathered temporarily
 Restrictions specific to the current drone flight, sometimes called a Geo-cage

Geo-fencing is the action of preventing a drone crossing a geo-fence. This is inherently a UAS feature
as it involves influencing the flight of the drone. Some drone manufacturers supply maps of geo-fences
which are then used for geo-fencing during flight. This ConOps expects that for many drones an
operations relevant geo-fence map will be generated before any operation and loaded into the UAS.
62 © – 2019 – CORUS consortium, except as noted
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

The not-flight-specific data to build this map will come from the U-space Drone Aeronautical
Information management service, described in section [Link]

A Geo-awareness service is a service to keep the pilot informed of geo-fences. This can be general
information for example a map of a country or region showing geo-fences, or flight relevant
information which indicates at each moment how close the drone is to any geo-fence and issues
warnings when appropriate. The Geo-awareness service described in section [Link] offers general
information.

Flight relevant geo-awareness requires the position of the drone to be known. For volumes where no
U-space tracking service is offered or for drones that are not submitting position reports to a U-space
tracking service, there is no way U-space can offer such warnings. Hence flight-relevant geo-awareness
is expected to be either a UAS feature whose operation depends on geo-fence data, or for drones that
are being tracked by U-space, flight-relevant geo-awareness is a part of the U-space Monitoring service
described in section [Link].

[Link] U-space Geo-awareness service

The Geo-awareness service provides geo-fence and other flight restriction information to drone pilots
and operators. For a U-space service giving warnings of imminent geo-fence crossing see the U-space
Monitoring service in section [Link].

This service is available from U1. In U1, the Geo-awareness service takes in information from existing
aeronautical information, such as restricted areas, danger areas, CTRs and so on. It also adds
information extracted from NOTAMS. Further it adds information coming from national and local
drone legislation. From the national airspace authority (CAA) or when available the Drone Aeronautical
Information Management service, temporary and drone specific restrictions are added, to produce an
overall picture of where drones may operate. All restrictions on airspace access are included in this
service – see section 3.1.5.

In (or by) U2 the service adds inputs from the Drone aeronautical information management service,
described in [Link], including Short Term Restrictions (see [Link]) which can produce geo-fences with
immediate effect. Short Term Restrictions exist to protect HEMS and similar unexpected manned
operations in VLL and they may also be used for other purposes. Short Term Restrictions must be
communicated very quickly and may impact operation plans already known to the Drone operational
plan processing service – some of which may be for drones already in the air.

The data delivered by this service will most likely be presented to the operator or pilot on a map, either
generated by the service or integrated in an operation planning management tool or service. The
information delivered by this service shall be available in an electronic form suitable for uses such as
configuring a UAS to perform geo-fencing.

In U1, the data delivered by this service may be used in operation planning, the operator may have a
tool to check plans are compliant, or loaded into the flight management system of the drone. In U2
and after the pre-tactical geo-fences will be checked by the Drone operation plan processing service.

The following table lists the roles involved in this service

© – 2019 – CORUS consortium except as noted. 63

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

Role Action Notes

Aeronautical Supply aeronautical publications This service and these
Information Service Supply NOTAMs publications already
exist for the benefit of
existing aviation.
National airspace Supply drone specific restrictions The duty should pass to
authority (CAA) - E.g. where Open is not allowed the Drone Aeronautical
Or - Where are types X Y Z Information
Drone Aeronautical - Where Geo-fences exist Management service by
Information U2. From U2 the
Management service amount of data and its
rate of change increase
Pre-Tactical Geo- Synthesise all data into a single image and
fencing service supply the service (to an adequate level of
provider performance)
Drone operator Consume the service in the process of
respresentitive operation planning and optimisation
Drone pilot Consume the service in the process of pre-
flight check and upload into drone.
Drone operation plan Consume the service in the process of Drone
processing service operation plan processing
provider
Table 8 Geo-awareness service Roles and Actions

[Link] Drone aeronautical information management service

The Drone aeronautical information management service is the drone equivalent of the Aeronautical
information management service. It is concerned with collecting together temporary and permanent
changes to the drone “flying map” which are not of interest to other aviation. An example of such
information might be that due to a music festival over a weekend an area changes from sparsely
populated to densely populated. This results in a change to ground-risk. Operating the service will
probably involve:
 Collecting inputs from occasional suppliers of information who have little knowledge of aviation
 Operating a service for more frequent suppliers of information who have been trained and
authorised to upload changes
 Vetting and training of organisations to establish that they are trusted to make updates directly
in the system.
 The provider of the service will probably have to negotiate at times with those providing inputs
which are unduly cautious (restricting drone flight unnecessarily) or incautious, …
 Synthesising, updating and making available the overall situation for each moment in time.

This service may be embedded in the Aeronautical information management service of a country or
may be kept separate for any number of reasons, for example cost transparency or ease of
implementation.

This service is expected to be fully deployed in U2 but may appear earlier. In U2 this service will
maintain the map of where X, Y and Z airspaces are defined. The Drone aeronautical information

64 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

management service provides information to the Geo-fencing services as well as Mission management
services in section 5.1.3.

Related to the drone aeronautical information management service is the publication of

environmental data, described in section 5.1.7

[Link] Geo-fencing provision

This service, referred to in the Blueprint [9] and Roadmap [10] as dynamic geo-fencing, will be available
in U3. This service provides UAS directly with 4-D coordinates of, and information about, geo-fences,
even during flight. This service depends on the technical geo-awareness capability of the UAS to
request, receive and use the geo-fencing data. The only human actor involved is the drone operator
who must configure and maintain the UAS appropriately to allow the service to work. The Geo-fencing
provision service is an extension of the U-space Geo-awareness service described in [Link].

5.1.3 Mission management

The following specific terms are used in this section:
Term Meaning & source
Operational European regulation [1], [2] mentions Operational declaration the declaration of
declaration compliance that an operator intending to operate a Specific category flight
under a standard scenario (STS) requirements must submit.
Operations not under a STS either:
- require an authorisation by the competent authority (i.e. NAA), or
- are authorised by the UAS operator under the privileges of its Light UAS
operator certificate (LUC)
ICAO flight plan The flight plan of manned aviation described in ICAO doc 4444
Drone mission Many small drones operated with batteries can only fly for a short time before
plan the battery needs to be changed. Many business objectives cannot be fit into
only one such flight but may require a series of flights.
A mission plan is a plan for a series of flights to achieve one business objective
that will be broken into separate flights ad-hoc as battery life dictates.
Drone flight A plan for one drone flight
plan
Drone Either a drone mission plan or a drone flight plan.
operation plan
Table 9 Mission management specific terms

An operation plan broadly contains

 Who is flying – the pilot, any significant pilot training, also the operator/owner
 What is flying – the identity and technical details of the drone, including any that are mandated
 Where the flight will be – as well as it is known in advance
 When the flight will occur – as well as it is known in advance – and for how long
 Supplementary information like documents giving access to airspaces, evidence of SORA,
certification of the flight, …

These details are expand in the following sections. These sections do not cover any ICAO flight plan
that may need to be submitted for a flight in unsegregated, controlled airspace (classes A-E).

© – 2019 – CORUS consortium except as noted. 65

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

[Link] Drone operational plan preparation assistance

There will probably be many different drone operational plan preparation assistance services offered.
These will vary in their target market, ease of use, cost, scope, level of integration with the operators
other tools, level of optimisation offered and so on. There will also be equivalent “tools” that are not
“services” but run at the drone operator’s site. Some operators will develop their own tools. (All of
these are referred to as drone operational plan preparation assistance services in this section.)

The common features of these services will be their interaction with the Drone operation plan
processing service:
 They allow the operator to prepare an operation plan and submit it to the Drone operation plan
processing service
 They allow the operator to display (and hopefully understand) the information coming back
when an operation plan is submitted
 They allow the operator to check on the status of an operation plan that has been submitted
 They allow the operator to cancel or submit an update to an operation plan that has been
submitted

Further many will support

 loading the operation plan into the drone,
 SORA processes, to some extent,
 integration with “Insurance as a Service” businesses
 integration with remote piloting stations to aid conformance monitoring and similar

[Link] Risk analysis assistance

Preparation of Specific operations involves SORA (see the Acceptable Means of Compliance (AMC) and
guidance material (GM) [57]) which involves analysing risks associated with the operation. It is
expected that a service is offered to support that analysis using the draft operation plan as well as
information coming from the Drone Aeronautical Information Management service (section [Link]),
various Environment services (section 5.1.7) and Traffic Information (section [Link])

The risk analysis assistance service may also provide access to “per flight insurance” services.

[Link] Drone operation plan processing service

The Drone operation plan processing service is deployed in U2. It receives operation plans and uses
these for a number of safety-related activities. The Drone operation plan processing service must be
deployed in a robust and reliable manner because of its safety criticality.

The Drone operation plan processing service maintains a pool of data containing the histories of all
submitted flights that have not yet been archived. Archiving occurs at some time after the flight lands
or is cancelled. The data in this pool is considered to be commercially sensitive and may additionally
be restricted for other reasons – such as for state operations. Hence access to this data is controlled.

The description of operation presented here is as if the system providing the Drone operation plan
processing service is a single integrated instance. This is the operational view. The implementation
may be made otherwise – that choice is out of the scope of this ConOps.

66 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

The role that submits an operation plan to the Drone operation plan processing service is the drone
operator representative. To do this they use an Operation plan preparation / optimisation service or
tool. The submission will be by some secure means.

The sum of all the operations known in the Drone operation plan processing service is “the traffic.”
The impact of an operation plan being submitted is to an extent felt by all other drone operators as a
change in the traffic.

The Drone operation plan processing service is the doorway through which a number of services are
reached. The following can be taken as an approximate list of the steps taken by the Drone operation
plan processing service when an operation plan is received.
 Syntax check. Does whatever has arrived resemble a flight plan enough to be processed?
 Semantic check. Are all the expected pieces of information present?
 If OK so far, generate a unique identifier for the operation plan13.
 Authorisation-check using the e-Registration service. Is there some reason this operator or this
pilot or this drone should not be flying?
 Construction of a probabilistic 4D model of the flight’s likely airspace occupancies, (a trajectory)
using the plan, the Weather information service, the flight/performance characteristics of the
drone, and any other relevant information. The trajectory will be subject to simple sanity checks.
 Weather warning, using the Weather information service. Is there a weather warning for the
time and place of the operation
 Geo-Fencing, height maxima and other boundary checks, using the Drone aeronautical
information service and the probabilistic trajectory. For any geo-fences that are penetrated, is
there a corresponding permission in the operation plan? For any conditional access, are the
conditions met?
 Procedural interface with ATC. If any controlled areas are penetrated by the probabilistic
trajectory then the procedural interface with ATC is triggered for each.
 The Strategic conflict-management service is invoked. See section [Link]
 If available, the Dynamic capacity management service is invoked. See section [Link]

The response from the processing should be a copy of the accepted plan including its unique identifier,
together with any conditions, for example from the procedural interface with ATC, or an explanation
of any problems that have prevented acceptance.

The Operation plan management service will also offer a validation mode in which the operation plan
is checked, but not submitted (i.e. not added to the set of operations.) This mode supports risk
assessment processes as well as optimisation. Some parts of the process – such as the procedural
interface with ATC – will not be fully executed in validation mode.

Once an operation plan has been accepted by the Drone operation plan processing service, the
operator may send further messages to
 Cancel the operation plan
 Change the operation plan
 Ask for the current status of the operation plan

Further an operator can query the service to get a list of all the operation plans known that have been
submitted by that operator.

13
The unique identifier should be unique EU-wide (preferably world wide) and unique over a minimum of two
years, preferably longer. The concept is inspired by the GUFI of FF-ICE. See ICAO doc 9965. [47]

© – 2019 – CORUS consortium except as noted. 67

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

The status of an operation plan can change after the operation plan is accepted if a tactical NDZ is
created that makes the operation plan unacceptable. Further the arrival of other operation plans may
make this plan subject to strategic conflict resolution or dynamic capacity management. The operator
should be notified directly by the Drone operation plan processing service if such an event occurs that
changes the status of the flight.

The status of an operation plan also changes when start-of-flight is received or position reports arrive
for the flight without start-of-flight. A further status change occurs on receipt of end-of-flight. Hence
the Drone operation plan processing service consumes information from the Tracking service
described in [Link].

The following table summarises the different interactions that involve the Drone operation plan
processing service
Role / Node Action notes
Drone operator Submit plans, changes, cancellations Uses an Operation plan
representative Receive positive or negative preparation /
acknowldgements optimisation service or
Query plans or status tool.
Receive status change warnings
Aeronautical Supply aeronautical publications This service and these
information service Supply NOTAMs publications already
exist for the benefit of
existing aviation.
Drone aeronautical Supply X, Y , Z volumes and other drone
information service sepcific information
e-Registration service Confirming the validity of the operator, any
pilot training, the type of drone mentioned in
any plan
Weather information Supplying weather forecasts and warnings
service
Procedural interface Triggering a coordination for a flight to
with ATC penetrate a controlled area.
Strategic conflict- Detecting and resolving conflicts before flight
management service
Dynamic capacity Detecting and resolving demand and capacity
management imbalances
Tracking Signalling start of flight.
Querying the existance of a plan.
Retrieving a plan for a track
Creating an ad-hoc plan for a track
Updating the current position of a plan
Signalling end of flight.
e-identification Query plans
Table 10 Drone Operation Plan Processing service Roles and Actions

The Tracking service works closely with the Drone operation plan processing service. The existence of
an operation plan helps the tracking service work. The operation plan provides a unique ID for a flight
and hence a track. If the tracking system has a track for which there is no plan, it will trigger the Drone

68 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

operation plan processing service to create an ad-hoc plan based on the data the tracking service has
in order to generate a unique id for the track.

[Link] Some aspects of operation plan contents

[Link].1 Trajectory uncertainty

To operate effectively, the Strategic Conflict Resolution service requires precise operation plans giving
the 4D trajectory to be flown. Further, to use the airspace efficiently requires the amount of “buffer
space” around flights to be minimised.

Unfortunately some drone operations are not very precisely plannable – for different reasons. Hence
the general requirement is that the 4D trajectory should be described as precisely as is possible for
that operation. Further the operation plan should include uncertainties as far as they are known, for
example “take off time between 14:00 and 14:30.” Some of this uncertainty will decrease as the flight
time approaches. Updating the plan to reduce uncertainty is considered necessary behaviour.
Messages coming via the position report submission sub-service will further reduce uncertainty as the
flight starts.

Figure 6 Example trajectories

The examples show a blue flight trajectory in an orange probable operation zone. The examples are
two dimensional for illustration reasons, but the process will be four dimensional including height and
time uncertainties.

The first two examples, A and B, are possibly plans for VLOS operations; as can be seen, they are
volumes of operation rather than linear trajectories. C is a typical scan pattern as might be flown as a
pre-programmed operation. D might be a delivery or a linear survey, perhaps BVLOS.

[Link].2 Geo-fence crossing tokens

A technical means, referred to hereafter as a token, is needed to show that a particular drone
operation has permission to cross a geo-fence. This token is needed in the Operation planning phase
and during flight where it may need to overcome geo-fencing implemented inside the drone itself, or
in the remote piloting station, or in U-space.

The token should be trustworthy and secure. Ideally it should be linked to a specific operation by a
specific drone, perhaps being associated with the unique identifier of that drone operation.

[Link].3 Contingency plans

The drone operation plan may include contingency plans, or emergency response plans, to be followed
in case of emergency. These may be alternate landing sites or more complex procedures. The drone
operator’s manual, if it exists, may also give general procedures for contingency and emergency.

© – 2019 – CORUS consortium except as noted. 69

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

[Link].4 Formation flights

A mentioned in section [Link], in contrast with the established practice of the ICAO doc 4444 flight
plan, drone formation flights are individual operation plans that are linked, rather than single plans for
multiple aircraft. It is expected that formation flights will be indicated in the respective operation plans
by mentioning an association with another plan or plans. To describe an operation in which drones A
and B fly in formation, the sequence would be something like:
 Submit an operation plan for A
 Get an acknowledgement back including a unique identifier for A’s operation plan
 Submit an operation plan for B that mentions formation flight with the unique identifier for A’s
operation

This approach can be extended to as many flights as needed. The system providing the Drone operation
plan processing service will make the associations bidirectional and associative. A formation flight is
then simply a pair (or set) of drone operations for which U-space will not give any warning or protection
against loss of separation within the formation, though these services are maintained between the
formation and other flights.

Swarm flights, in contrast, are single operations of multiple aircraft, with one operation plan for all.

[Link] Dynamic capacity management service

Dynamic Capacity Management aims to match demand with capacity and has two threads. Demand
may be regulated to match capacity, or capacity may be changed to match demand. The process
described in sections [Link].1, [Link].2 and [Link].3 is the regulation of demand. A discussion of
matching capacity to demand follows in [Link].4

U3 brings Tactical Conflict Resolution, in type Z airspace. The level of confidence in how well this service
will work can be matched to the difficulty of the task the service faces by limiting the number of flights
in a particular volume of air, which is the job of the Dynamic Capacity Management Service.

[Link].1 Inner working

There will be a process to predict times in the future when an airspace will be “full”. The details of this
process are out of the scope of this document but it will be related to the probability that flights lose
safe separation. The parameters for this decision may be set as a function of other characteristics of
the airspace.

When this process determines that the airspace is full, what follows is based on a parameter known as
the “reasonable time to act” (RTTA) – see section 3.3.7. The process also considers priority – see
section 3.3.6

The solution is generally to propose delay for flights or to propose rerouting away from the full
airspace. If this has to happen, then:
 All high-priority operations occur unhindered, as far as possible.
 Apart from high priority operations, all operations for which an operation plan was submitted
after RTTA for the flight are the first candidates to be proposed a plan change due to the airspace
being full at the time they are planned to cross.

70 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

 If the above will not solve the problem, the not-high-priority operations are examined to find
those causing the most risks of conflicts, hence whose removal would cause the largest overall
reduction in risk of the airspace.
 If the above will not solve the problem, all operation plans take part in a process that proposes
changes to those with the lowest priority, working upward until the problem is solved.

[Link].2 Other applications

The machinery of the Dynamic capacity management service can be employed for any measure of
“fullness,” not only collision risk. The same machinery might be used in some airspaces to manage
noise.

The same machinery of rerouting and delay may be invoked if an airspace is closed for any reason.

[Link].3 Invocation

The Dynamic capacity management service is expected to appear generally in U3. It is invoked by the
Drone operation plan processing service. It has no independent use. It is invoked if and only if the
airspace requires it.

The Dynamic capacity management service uses the probabilistic 4D models calculated by the Drone
operation plan processing service.

[Link].4 Modulating capacity in response to demand

A number of approaches can be followed that will change capacity in response to demand.
 There may be a traffic organisation scheme in which traffic is collected into certain regions while
others are generally not used, for example for noise abatement reasons. There could be traffic
level triggers that allow the not-used regions to come into use.
 Similarly prediction of or experience of ‘hotspots’ may trigger a revision of any traffic
organisation scheme, for example measures that produce more homogenous traffic; like one
way systems or speed controlled zones.
 Longer term trends might lead to changes in the technical requirements for the volumes
concerned. For example higher precision tracking and navigation may allow closer spacing
between aircraft and may be mandated for a volume that is frequently subject to demand
regulation measures.

This ConOps does not include any study of traffic organisation. The exploration of methods to increase
capacity in response to demand is left for future research.

5.1.4 Conflict management

As discussed in section 3.3.3, Conflict Management is more than these two U-space services.

[Link] Strategic conflict resolution service

The Strategic conflict resolution service is invoked by the Drone operation plan processing service. It
can be invoked because a new operation plan has been submitted or because an already submitted
operation plan has changed. Strategic conflict resolution is before flight.

The service has two phases. First it detects conflicts, then it proposes solutions.

© – 2019 – CORUS consortium except as noted. 71

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

Detection broadly involves examining the probabilistic 4D trajectories predicted by the Drone
operation plan processing service and looking for pairs which have a reasonable probability of coming
closer than is allowed in any given airspace. The precise meaning of the previous sentence – what is a
reasonable probability and so on – is outside the scope of this ConOps.

Resolution is by changing either of the pair – following similar rules about RTTA (section 3.3.7) and
Prioritisation (section3.3.6) as were followed in section [Link], Dynamic capacity management
service. The changes will come from a standard set of “recipes” which are tested and those that resolve
the problem (and do not cause another problem) retained. The possible solutions are proposed to the
operator who will refine the plan further before resubmitting or changing it.

[Link] Tactical conflict resolution

Tactical conflict resolution is the process of resolving conflicts that occur during the flight by changing
the flight while it happens. The service can be implemented as an advisory service or a system giving
instructions, as discussed in section [Link]. The description given here assumes the service is
implemented on the ground and not as a distributed function within the aircraft.

The Tactical conflict resolution service requires that the positions of all aircraft are known and
frequently updated in the airspace volume being served, and further that the precision with which
these positions are known can be reliably determined. Based on these tracks the service predicts
conflicts and then issues advice or instructions to aircraft to change their speed, level or heading as
needed to resolve these conflicts. These instructions should reach the pilot rapidly and reliably.

The Tactical conflict resolution service can work more effectively if it makes use of a model of the flight
envelope and characteristics of each aircraft concerned. Further efficiency gains may be made if the
service is aware of the intention (that is the operation plan) of each flight.

The Tactical conflict resolution service is a client of the Tracking service, the Drone operation plan
processing service and the Drone aeronautical information management service.

5.1.5 Incidents and Emergencies

Emergency management combines U-space services and technical capabilities of the drone and
remote piloting station to detect and recover from emergencies, additionally the remote pilot /
operator may have an Emergency Response Plan that can be triggered. This section also covers the
reporting of accidents, incidents and potential incidents as well as the recording of data used in
investigations.

[Link] Emergency management service

The Emergency management service of U-space has two aspects

 assistance to a drone pilot experiencing an emergency with his/her drone
 communication of emergent information to those who may be interested

o pilots whose drones may be impacted

o manned aviation, air traffic services
o police

The assistance given to a pilot may include:

72 © – 2019 – CORUS consortium, except as noted
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

 enabling the reporting of an emergency

 detection and alert of an emergency (when possible)
 proposals for action to be taken to minimise risk
 reminders of contingency plans or emergency response plans

The Emergency management service needs to be configured for the “current operation.” The pilot will
need to identify his drone and/or drone operation plan if any. If the drone is not using the position
report submission service then the pilot will need to give the location of the flight during the ‘log-on’.
Emergencies that are communicated to the drone pilot are those likely to come near his/her operation
and hence pose a risk to it.

The communication channel of the Emergency management should be monitored at all times by the
drone pilot. Human factors should be considered during the deployment of this service; the channel
may be inactive much of the time and the pilot may be under stress during any emergency. The U-
space service will add value by filtering the information sent on the communication channel in order
to maintain relevance for the pilot.

The Emergency management service consumes information from the Tracking, Monitoring and
Operation plan processing services – if active for the operation concerned. In case the flight has an
operation plan, the Emergency management service shall warn the pilot when a geo-fence-with-
immediate-effect has been created which impacts the current flight.

[Link] Accident and incident reporting

The process of Accident and Incident reporting is described in detail in section 4.4. The U-space
Accident / Incident reporting service supports that process. The service allows drone operators and
others to report incidents and accidents. The service allows these reports to mention drone identifiers
and operation plan identifiers in order to help later investigation.

The service shall maintain the reports for their whole life-cycle. The system shall be secure and give
access only to authorised persons.

The Accident and Incident reporting service is a client of the Legal Recording service (see [Link]) and
hence indirectly all parts of U-space. There may be some linkage between the Emergency Management
service and the Accident and Incident reporting service; some Emergency events may trigger automatic
creation of an Accident/incident report.

[Link] Citizen reporting service

Similar to the Accident and Incident reporting service, U-space should allow citizens to report what
they have observed when they believe incidents or accidents involving drones have occurred. The user-
interface should be designed to encourage the reporting of sufficient information to identify the flights
concerned.

The details of the Citizen reporting service are rather similar to the Accident and Incident reporting
service.

5.1.6 Monitoring
The Monitoring family of services groups functions derived mostly from Tracking that are of value in
flight.

© – 2019 – CORUS consortium except as noted. 73

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

[Link] Monitoring service

Subject to appropriate data-quality requirements, this service retrieves data from the tracking service
and combines it with information related to non-cooperative obstacles and vehicles to provide an air
situation status report for authorities, service providers, and operators, including pilots. This service
may include operation plan conformance monitoring, geo-fence compliance monitoring and warnings
(see [Link]), weather limit compliance monitoring, ground risk compliance monitoring,
electromagnetic risk monitoring. The geo-fence compliance monitoring and warnings constitute U-
space providing Geo-Awareness.

Alerts from the Monitoring service should be emitted in a manner compatible with all drone
operations, hence audio alerts are preferred.

Monitoring is a client of Tracking, Drone aeronautical information management and the different
environmental services.

[Link] Traffic information

This service provides the drone pilot or operator with traffic information and warnings about other
flights – manned or unmanned - that may be of interest to the drone pilot. Such flights generally have
some risk of collision with the pilot’s own aircraft.

Traffic information is also the presentation of “air situation.” As mentioned in section [Link], there is
some commercial sensitivity to drone flight information. Air situation display may be restricted. Note
that Air situation display is the presentation of an image to the user; it is foreseen that tracks are
shared between U-space and ATM by means of the Surveillance data service – see [Link]

The Traffic information service also gives access to the traffic densities expected in the near future at
any location, as calculated from operation plans that have been submitted.

[Link] Legal recording

The aim of the legal recording service is to support accident and incident investigation. The service
should record all inputs to U-space and allow the full state of the system at any moment to be
determined. A second use of legal recording is as a source of information for research and training.
Finally, post-processing of legal recording data by dedicated (e.g. AI-based) algorithms can identify
high risk situations and adapt parameters for risk assessment of future operations.

In view of the commercial sensitivities of drone operators, it is likely that access to the recordings will
be restricted.

[Link] Digital logbook

The digital logbook service extracts information from the legal recordings to produce reports relevant
for whoever is using the service. It shall give users access to their own information only.

Drone operators and pilots will be able to see summaries of information for flights they have been
involved in; start and end times, places, aircraft id, and so on.

Drone pilots will be able to see histories of and statistics about their flight experience.
74 © – 2019 – CORUS consortium, except as noted
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

Drone operators will be able to see histories / statistics for their aircraft.

The digital log book service needs to be securely implemented. Various query functions should be
available.

Authorise users, such as accident investigators or police may have general access to all data.

[Link] Navigation Infrastructure Monitoring

The service to provide status information about navigation infrastructure. This service is used during
operations. The service should give warnings of loss of Navigation accuracy.

[Link] Communication Infrastructure Monitoring

The service to provide status information about communication infrastructure. This service is used
during operations. The service should give warnings of degradation of communications infrastructure.

5.1.7 Environment
The environment group of services cluster many similar services offering data. These services each
provide information that has a cost to collect and maintain.

[Link] Weather information

The service to collect and present relevant weather information for the drone operation. This include
hyperlocal weather information when available/required.

[Link] Geospatial information service

The Geospatial information service collects and provides relevant Terrain map, buildings and obstacles
for the drone operation. The information may be available at different precisions from different
sources.

[Link] Population density map

The Population density Information service to collects and present relevant density map for the drone
operation. This map is used to assess ground risk.

Proxies for instantaneous population density information might be found to be reliable; such as mobile
telephone density – to be confirmed.

[Link] Electromagnetic interference information

The service to collect and present relevant electromagnetic interference information for the drone
operation.

[Link] Navigation coverage information

The service to provide information about the navigation coverage. It can be specialised depending on
the navigation infrastructure available (e.g. ground or satellite based). This service is used to plan
relying on required coverage.

© – 2019 – CORUS consortium except as noted. 75

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

[Link] Communication Coverage information

The service to provide information about the communication coverage. It can be specialised depending
on the communication infrastructure available (e.g. ground or satellite based). This service is used to
plan relying on required coverage.

5.1.8 Interface with ATC

Two interfaces with ATC are proposed. Procedural, available first, and Collaborative.

[Link] Procedural interface with ATC

The procedural interface with ATC is a mechanism to coordinate an entry of a flight into controlled
airspace. The interface works before flight. The Operation plan processing service will invoke the
service and through it:
 ATC can accept or refuse the flight
 ATC can describe the requirements and process to be followed for the flight

[Link] Collaborative interface with ATC

The collaborative interface with ATC is introduced in U3 and is a service offering communication
between the Remote Pilot (or the drone itself in case of automatic flight) with ATC while a drone is in
a controlled area. The communication may be verbal or textual. The Collaborative interface allows
flights to receive instructions and clearances in a standard and efficient manner, replacing ad-hoc
solutions used prior to this service being used.

The Procedural Interface with ATC is the normal method to get approval to enter a controlled area.
ATC may refuse to accept flights as they choose. The collaborative interface is not a means to avoid
such approval.

The Collaborative Interface with ATC provides a means of communication between ATC and Remote
Pilots. In addition to communications, safe operation is enabled by ATC having access to U-space
surveillance data, see [Link]

5.2 Architecture (high level)

This section is used to give to the reader visibility of the overview of U-space architecture. It is not
aiming to provide details but the high-level elements and views which are supporting the concept
development and understanding.

5.2.1 Architecture principles

The architecture principles taken into consideration when defining the U-space architecture are:

Service-oriented architecture: A service-oriented approach will be applied to ensure that the solutions
are built based on a set of services with common characteristics.

76 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

Modular: the architecture will be decomposed into self-contained elements (Functional Blocks) which
contain a meaningful set of functionalities with the required inputs/outputs, that can be re-used or
replaced.

Safety-focused: The architecture shall always consider the safety of its stakeholders or of other people
and places that may be affected by U-space operations.

Open: a system architecture shall be developed which is component-based and relies on published or
standardised interfaces based on SWIM principles 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 re-use, to increase flexibility, to reduce costs and time to market, to foster competition, to
improve Interoperability and to reduce risks.

Standard-based: whenever there are exchanges between roles, the interfaces must be defined and
based on open standards.

Interoperable: the main purpose of the interoperability is to facilitate homogeneous and non-
discriminatory global and regional drone operations.

Technology agnostic: to allow platform independent design, the architecture shall be described
independently of the later implementation specifics, e.g. platforms, programming languages and
specific products which shall 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: the architecture will be developed to facilitate the delivery of safe and secure U-space
services with a high degree of automation of the processes as manual operations will be too labour
intensive.

Allowing variants: the architecture work will allow variants and alternative solutions to be described.
The principles listed in this document and later in the CONOPS aim for ensuring interoperability
between different implementations.

Deployment agnostic: architecture work will not constrain different deployment choices according to
the business and regulatory framework established.

Securely designed: architecture work will address security issues such as cyber-security, encryption
needs and consequences, and stakeholder authentication. It is needed to follow the SWIM principles
that is to use a central or federated Public Key Infrastructure (PKI) for identity management.

5.2.2 Architecture Framework

Architecting has become a decisive process for the successful development of projects at aiming to
capture all the relevant information from different facets to end-up with a complete, consistent and
coherent content. CORUS team has worked to provide U-space stakeholders with a reference
architecture from which build up a realizable U-space and that will support the future decision making.
Every architecting approach needs an architecture framework, which has a common set of principles
and practices for structuring and describing the enterprise/concept, in this case the U-space. Having
the Principles for the U-space architecture issued by the SJU, the framework chosen by CORUS must
follow the same principles as the ones stated in this reference document. Therefore, the European Air
Traffic Management Architecture (EATMA) was selected to drive the CORUS architecture. This choice
© – 2019 – CORUS consortium except as noted. 77
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

will facilitate the integration of the ATM and U-space architecture since EATMA is also the framework
used for the research and development activities of ATM. The Annex K provides the necessary
information about the structure and guidance of EATMA.

5.2.3 Stakeholders and Roles

The U-space undertaking can be defined as a collection of organisations that share a set of common
goals and collaborate to provide specific products or services to customers. In that sense, this
undertaking covers various types of organisations, regardless of their size, ownership model,
operational model, or geographical distribution. It includes people, information, processes, and
technologies.

A U-space stakeholder is an individual, team, or organisation with interest in, or concerns relative to,
the U-space undertaking. Concerns are those interests, which pertain to the undertaking’s
development, its operation or any other aspect that is critical or otherwise important to one or more
stakeholders.

Stakeholder Role (aka role) is representing an aspect of a person or organisation that enables them to
fulfil a particular function.

The U-space stakeholders have been classified as:

 Operational stakeholder, who are actively consuming and/or providing services of U-space.
For this class of stakeholders, roles have been identified.
 Other stakeholders, which are not operational stakeholders. No specific role in using the
system has been identified for them. It is not excluding these stakeholders to access to some
information (e.g. statistics) to accomplish their businesses (out of scope).

Figure 7 Stakeholders

78 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

The Drone operator is the legal entity, which can be a natural person, accountable for all the drone
operations it performs. The equivalent of the airline for the pilot in manned aviation. Could be civil,
military, an authority (special) or a flight club. Key roles: Drone pilot, Drone crew, Drone operator
representative

The Drone owner is the legal entity, which can be a natural person, owning the drone. May be
different from the Drone Operator legal entity (e.g. leasing rental mechanisms). Key role: Drone owner
representative

The Drone manufacturer produces drones and ensures their compatibility with U-space (technical
feasibility, interoperability). Key role: Drone manufacturer representative

The U-space service provider (USSP) is the Generic stakeholder who provides at least one of the U-
space services. The entity that provides U-space service access to drone operators, to pilots and/or to
drones, to other operators visiting non-controlled very-low-level airspace. Depending on the
architecture deployment options and the services, multiple services could be provided by different U-
space service providers. It is possible to distinguish between the providers of centralised services (i.e.
Principal USSP) and concurrent service providers aiming to interface with the drone and drone
operator (Operator USSP). Key roles: Registrar, Accredited registry updater, Accredited registry reader,
USSP Supervisor, Authorization Workflow Representative, Capacity Authority, Drone Aeronautical
Information Manager

The Supplemental Data Service Provider (SDSP) is an entity that provides access to supplemental data
to support U-space services. Multiple services could be provided by different Supplemental Data
Service Providers. Specific providers of this category are:
 Weather Data Service Provider, which provides weather information data (hyper local
weather data, solar flare information and TAFs and METARs) and ensures that these are
reliable, accurate, correct, up-to-date and available.
 Ground risk observation service provider Provides supplemental data which contribute to
the knowledge/observation of the ground. It encompasses: ground and terrain data
modelling (building heights, digital elevation model) and population density, ensuring that
these are reliable, accurate, correct, up-to-date and available.

CNS infrastructures are constituting important U-space supporting systems. CNS Infrastructure Service
Providers in general provide the technological infrastructure with which the CNS service providers
provide the actual CNS services. Where applicable, they also provide relevant monitoring and coverage
services. Satellites, for example, are infrastructure, provided by one or more infrastructure providers,
that are used by the different providers of all three CNS services. Then:
 Communication service provider, responsible for the provision of a reliable and safe
communication link between systems. For the C2 Link, also known as a C2-Link service
provider.
 Navigation service provider, responsible for the provision of a reliable navigation infrastructure
to allow safe drone operations. E.g. Satellite Navigation Service Providers.
 Surveillance service provider, responsible for the provision of surveillance services with
different technologies/methodologies and SLA. This encompasses anti-drone surveillance for
non cooperative traffic. Provides services to check coverage and monitor the status of the
surveillance service offered.

The Air navigation service provider (ANSP) provides services to airspace users that may be operating
in airspace where U-space services are also being provided. Existing ATM (Aeronautical information
management provider (AIMP)) provides sources of some data consumed by U-space service providers
© – 2019 – CORUS consortium except as noted. 79
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

and users. Key roles: ATS Operator, Authorization Workflow Representative, Authorised viewer of air
situation

(Airfield/Airport) Aerodrome operator (civil, Military) supports the definition of operating

procedures and interoperability requirements and expects that U-space ensures safe integration of
drones in airspace, especially in airport vicinity. Key role: Airport Operator Representative

Civil Aviation Authority encompasses national or local aviation authority. It expects that U-space
ensures aviation law is followed, ensures safe and secure operation of all aircraft, promotes the
minimisation of environmental impact and anticipates deployment challenges. Key roles: Registrar,
Accredited registry updater, Authorization Workflow Representative, Authorised viewer of air situation

Authority for safety and security (police, fire brigade, search and rescue orgs) publishes danger areas
in real time – relating to medical evacuation, police helicopter or similar. (Police only) Develops law
enforcement methods related to illegal drone use. Key roles: Police or security agent, Authorised
viewer of air situation, Accredited registry reader

Local authorities (government/city/prefecture) Supports the definition of operating procedures

and rules. Explores applications of U-space to urban needs – for example active measures limit noise
“dose” in any one place. Expects U-space develops methods to support among the others: privacy
assurance, enforcement of drone regulations and publishing VLL hazards as they arise – cranes,
building work, … Key roles: Authorised viewer of air situation, Accredited registry reader, Authorization
Workflow Representative

Insurance companies Collect statistics about drone accident rates in U-space. They propose more
affordable insurance for drones that use enabling factors that lowers the risk of incident. They offer
per operation insurance based on the specific operational plan. They can be providers of supplemental
data related to the insurance. In that case it is an Insurance data service provider. Key roles: Accredited
registry reader, Accredited registry updater

Training organisation such as Remote pilot schools & Training centres are responsible for pilot and
operator training. Key roles: Accredited registry reader, Accredited registry updater

Aviation user are users of the airspace other than drone operators / pilots. It includes those concerned
with manned aircraft, parachuting and similar. Key roles: Pilot, Authorised viewer of air situation

The General Public are representing those who may hear, see or otherwise be concerned by a drone.
Key roles: Citizen, Authorised viewer of air situation.

Operation customer, The final stakeholder of the drone operation who may have some roles in the
authorisation of the mission itself.

U-space service industry develops sw products to realise U-space services. They expect that standards
are issued for ensuring U-space interoperability. They provide a range of services implementation from
basic to advanced solutions.

Equipment Manufacturer develops hw solutions needed or effected by U-space services. They expect
that standards are issued for ensuring interoperability (if required). (Scope is equipment for drones,
manned aircraft and U-space infrastructure).

80 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

Manned Aircraft Manufacturer produces manned aircraft which can operate in an U-space
environment and ensures their compatibility with U-space, integrating equipment needed for
operation.

National supervisory authority Ensures that aviation law is followed, ensure safe and secure operation
of all aircraft, promote the minimisation of environmental impact and anticipate deployment
challenges.

EASA/JARUS Contribute to
 Implementation of an operation-centric, proportionate, risk- and performance-based regulatory
framework for all UAS operations conducted in the ‘open’ and ‘specific’ categories;
 ensuring a high and uniform level of safety for UAS;
 fostering the development of the UAS market; and
 addressing citizens’ concerns regarding security, privacy, data protection, and environmental
protection

see [Link] for EASA and see [Link]

we-are for JARUS

European institutions (European Commission, SJU, Directorate General for Mobility & Transport (DG
MOVE), Directorate General for Internal Market, Industry, Entrepreneurship & SMEs (DG GROW),
EUROCONTROL, European Defence Agency (EDA) Promotion of economic activity related to drone
use. They expect that U-space ensures protection of privacy, EU consumer rules conformance and
safety with regards to protected sites (geofencing). Further EDA mention: Maintaining the level of
Safety for Military (low-level) operations, preserving operational effectiveness and protecting Search
and Rescue operations. Guaranteeing the Security of (Military) infrastructures, assets and operations.
Quantifying the financial impacts of U-Space implementation on the Military in order to secure the
necessary funding to maintain safety, guarantee security and ensure interoperability.

Universities and academic institutions and research projects provide Feedback, outcomes, results on
current research issues, recommendations for additional industrial / research needs.

Drone association (manufacturers & operators) represents drone pilots/operators/manufacturers and

provide them assistance. Expect that U-space services realise an important enabling factor for the safe
growth of the drone marker.

Model club represents modellers which needs to be distinguished from drone operators in the U-
space access considering peculiarity of their activities.

Specialised press Responsible for communicating and disseminating information/news about this
drone market.

5.2.4 Operational processes and Information Exchanges

From an operational point of view, following diagram shows, independently of any physical realisation,
high level operational processes (the blocks which represent the stakeholder and relevant activities)
and information exchanges among these processes (the arrows between blocks). The diagram is
mainly focusing on U-space traffic management operations.

© – 2019 – CORUS consortium except as noted. 81

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

Figure 8 information exchanges, informal presentation

Information exchanges will be focused in order to provide the right information at right people and
time, in order to comply with safety, security and privacy requirements. These interactions, named
Information Exchanges, describe then the operational needs that require to be covered in
implementation with technical systems.

5.2.5 A generic system breakdown

Being service oriented and having recognised different business models possible, a range of
deployment architectures can be imagined for U-space.
The main arguments are around the deployment of U-space services and the possibility to have
distributed responsibility among several USSPs and then interoperability among Drone Traffic
Management system. The trivial solution is the monolithic deployment of all system functions in a
unique solution managed by a unique provider in a certain volume of airspace (e.g. Member State,
City). Alternative deployment solutions envisage the possibility of delivering more instances of DTM
systems to provide a subset of services and interoperate each other to ensure consistency; the
resulting federated architecture foresees the orchestration of services provided by more than one
supplier in the same portion of airspace.

Before addressing at high level the two deployment architecture options it is important:
 to address the principles that may drive the selection of an implementable solution.
 to analyse service-by-service what it is important to be performed centrally or possible
federated, in terms of final responsibility of service providers.
82 © – 2019 – CORUS consortium, except as noted
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

 It is recommended to balance the complexity of having more Drone Traffic Management

providers in same geographical airspace volumes with the impact to safety, security, privacy and
access and equity. E.g. In many case Member state responsibility or complexity in ensuring a
distributed model of the service realisation may lead with the centralised approach for the
service deployment.
 It is recommended to have a deployment architecture economically sustainable. E.g. In some
countries the decision to compensate the costs of realisation of U-space supporting
infrastructure may lead in the decision of a mixed solution with centralisation of some services
and federation in the provision of others promoting the competition of the market.
 It is important not to confuse Drone Traffic Management system with Drone Operating Systems
which may realise service to the operator consuming DTM services. Then it is not necessary to
compete on the services related to provision of traffic management when it is provided the
possibility to build added value services upon them (e.g. assistance services).

There are likely to be two types of services, those that, for a specific volume of airspace, can run in
parallel and those that are likely to work best if unique, or requiring close synchronisation across
instances if not unique. Further there are likely to be services that are of interest to the user that they
are willing to fund and services that are mandated by the state (typically for safety or law enforcement)
that shall be funded by some state means – e.g. a levy, the taxpayer.

The basic idea is that it is not possible to approach the discussion of federated vs monolithic
architecture with U-space as a whole, but considering service by service.

This document does not push any position on what shall be centralised and what can be executed.

Figure 9 Generic U-space system breakdown

Figure 9 aims providing an overview of possible interfaces among systems for both monolithic and
federated options.
© – 2019 – CORUS consortium except as noted. 83
All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

Validation and demonstration activities will provide evidences of these architecture options.

5.2.6 U-space Portal

In order to have a common understanding of the U-space architecture, it becomes essential to have
only one single point of truth accessible for the U-space architects. This assures completeness,
consistency and coherency of the content developed by the different projects in the most efficient
way. So having access to the architecture designed by CORUS becomes a critical milestone for the
future work to be performed on U-space.

Therefore, CORUS team has decided to show the architecture in a web based portal
([Link] This portal will expose the CORUS U-space architecture.
Therefore, it will allow the future U-space architects to easily access the reference material to
continuously enhance and develop in a consistent way the future U-space.

The portal will include content from the different EATMA layers and the relationships between the
elements, easing the verification of the traceability between the different levels of the architecture
(business, operational, service and system).

84 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

6 Terms and acronyms, References

6.1 Terms and acronyms
Term or Meaning / Expansion Remarks
Acronym
Aircraft Any machine that can derive Definition from ICAO.
support in the atmosphere from Aircraft either manned or unmanned.
the reactions of the air other Size is irrelevant.
than the reactions of the air
against the earth’s surface.
Air-crew The on-board pilot(s) of a As opposed to remote-pilot for a drone
manned aircraft
AF Automatic Flight Local defnition – see section [Link]
AMC Acceptable Means of Compliance See [57]
ASM AirSpace Management
ATFCM Air Traffic Flow and Capacity
Management
ATM Air Traffic Management ATM consists of Air Traffic Services (ATS),
Airspace Management (ASM), and Air Traffic Flow
and Capacity Management (ATFCM).
ATS Air Traffic Service(s)
BVLOS Beyond Visual Line of Sight A manner of operating a drone; contrasts with
Defined in the Implementing VLOS. In BVLOS the drone flies out of sight of the
regulation [1] remote pilot or any assistant.
CA Collision avoidance Defined in ICAO doc 9854 [54].
Controlled An airspace of defined Defined identically in ICAO Annex 2 [10] and SERA
Airspace dimensions within which air [12]
traffic control service is provided
in accordance
with the airspace classification.
C2 Command and Control Usually C2 refers to the communication link from
a remote piloting station to a drone. The link may
be bi-directional in which case the information
coming from the drone is often referred to as
Telemetry
DAA Detect and Avoid. Defined in ICAO Annex 2 [10] - See section 3.3.3
Cooperative implementations involve potential
targets emitting special signals to facilitate
detection.
DDS Drone Detection System Generally refers to a system to detect non-
cooperative drones.
DRID Direct Remote Identification Contrasts with NRID. DRID is remote
identification by means of the drone emitting a
signal.
DTM Drone Traffic Management Variant of UTM

© – 2019 – CORUS consortium except as noted. 85

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

Term or Meaning / Expansion Remarks

Acronym
Drone A type of aircraft that is not being Contrasts with manned aircraft
piloted from on board by a
human.
EASA European Aviation Safety Agency [Link]
EATMA European ATM Architecture … ATM being Air Traffic Management
EC European Comission [Link]
ECAC European Civil Aviation [Link]
Conference
EDZ Exclusive Drone Zone See UAS/ATM integration Operational Concept
[12] section 3.3.1
EGNOS European Geostationary A satellite based augmentation system for
Navigation Overlay Service satellite navigation providing a service for Europe,
augmenting Galileo, GLONASS and GPS
ERP Emergency Response Plan
EU European Union [Link]
EVLOS Extended Visual Line of Sight A manner of operating a drone. In EVLOS, the
drone remains in the sight of the remote pilot or
an assistant at all times. EVLOS is a mix of VLOS
and BVLOS and hence is not considered in this
ConOps to be a distinct mode.
Galileo A European GNSS
GCS Ground Control Station A synonym for Remote Piloting Station.
GLONASS A Russian GNSS
GNSS Global Navigation Satellite General term for satellite navigation.
System
GPS ‘Global Positioning System’ The term GPS is sometimes used to mean satellite
A GNSS operated by the USA. navigation in general.
HEMS Helicopter Emergency Medical HEMS flights often penetrate VLL.
Service
HF High Frequency ITU: Refers to a specific radio frequency band
from 3MHz to 30 MHz. See also VHF, UHF, SHF
HPEM High Power Electro-Magnetic
IFPS Integrated Initial Flight Plan Europe’s flight planning system for manned
Processing System aircraft.
ITU International Telecommunication
Union
LDZ Limited Drone Zone See UAS/ATM integration Operational Concept
[9]
LFR Flight rules for low level see UAS/ATM integration Operational Concept [9]
where the term is introduced as a place holder
LIDAR “Light Detection and Ranging” Laser equivalent of RADAR
LoS Loss of Separation See section 3.3
LUC Light UAS operator’s Certifiate See the Implementing regulation [1]
MAC Mid Air Collision

86 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

Term or Meaning / Expansion Remarks

Acronym
Manned Of an aircraft; being controlled by Note that a drone carrying a passenger is not
an on-board pilot manned in the sense meant here.
NAF NATO Architecture Framework
NDZ No Drone Zone See UAS/ATM integration Operational Concept
[9]
NOTAM Notice to Airmen A means of publication of warnings in aviation.
See ICAO Annex 11 [11] and many other
references. NOTAM (and related SNOWTAM,
ASHTAM, Digital-NOTAM, etc) are considered to
be inputs to this ConOps as they are already in
widespread use.
NRID Network Remote Idenification Contrasts with DRID.
NRID is remote identification of a drone by means
of U-space tracking.
OM Operations Manual
RNP Required Navigation See ref [43]
Performance
RP Remote Pilot
RPS Remote Piloting Station A synoym for Ground Control Station. Part of a
UAS.
RTTA Reasonable Time To Act See section 3.3.7
RUNP Required U-space Navigational See section 3.3.2
Performance
RwC Remain well Clear
SHF Super High Frequency ITU: Refers to a specific radio frequency band
from 3GHz to 30 GHz. See also HF, VHF, UHF
STS Standard Scenario From Commission Implementing Regulation (EU)
2019/947 [1], as aspect of the Specific category of
operations.
Traffic The collective term for flights. Current Traffic is airborne
Predicted Traffic is derived from plans
Forecast Traffic is estimated
U1, U2, U3, U-space levels See the Blueprint [6] and Roadmap [7] documents
U4
UA Unmanned Aircraft
UAS Unmanned Air System, UAS includes the UA and everything else needed
Unmanned Aircraft System to make it work, including the RPS
UAV Unmanned Air Vehicle, Equivalent to UA.
Unmanned Aerial Vehicle
Uncontrolled Airspace which is not Controlled The term is implicitly defined in ICAO Annex 2
Airspace Airspace [10] and SERA [12] as all airspace which is not
Controlled Airspace
UHF Ultra High Frequency ITU: Refers to a specific radio frequency band
from 300 MHz to 3 GHz. See also HF, VHF, SHF

© – 2019 – CORUS consortium except as noted. 87

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

Term or Meaning / Expansion Remarks

Acronym
UTM UAS Traffic Management UAS Traffic Management by analogy with Air
Or Traffic Management. (see also DTM)
Unified Traffic Management “Unified” from the aim to have one system
combinging both UAS and [manned] air traffic
management.
U-Space Europe’s drone traffic See [Link] -> “WHAT”
management system
VHF Very High Frequency ITU: Refers to a specific radio frequency band
from 30 MHz to 300 MHz. See also HF, UHF, SHF
VHL High level An airspace above that normally used by
manned operations. See UAS/ATM integration
Operational Concept [9]
VLL Very Low Level airspace Very Low Level (VLL) refers to the portion of
airspace below that normally used by VFR. See
sections 2.5.1 and 3.1
VLOS Visual Line of Sight A manner of operating a drone; contrasts with
Defined in the Implementing BVLOS. In VLOS, the drone remains in the sight of
regulation [1] the remote pilot at all times.
Za Z volume controlled by ATS See Z Volumes, [Link]
Zu Z volume in which Tactical See Z Volumes, [Link]
Collision Resolution is provided
by U-space
Table 11 Terms and Acronyms

6.2 References
[1] Commission Implementing Regulation (EU) 2019/947 of 24 May 2019 on the rules and
procedures for the operation of unmanned aircraft (Text with EEA relevance.) [Link]
[Link]/legal-content/EN/TXT/?qid=1560259925294&uri=CELEX:32019R0947
[2] Commission Delegated Regulation (EU) 2019/945 of 12 March 2019 on unmanned aircraft
systems and on third-country operators of unmanned aircraft systems [Link]
[Link]/legal-content/EN/TXT/?qid=1560259925294&uri=CELEX:32019R0945
[3] Draft Acceptable Means of Compliance (AMC) and guidance material (GM) to Regulation …/…
[IR] laying down rules and procedures for the operation of unmanned aircraft and to the
Annex (Part-UAS — UAS operations in the ‘open’ and ‘specific’
categories)[Link]
0to%20draft%20Regulation%20...-...%20and%20to%20the%20draft%20Annex%20%28Part-
U....pdf replaced by [57]
[4] JARUS guidelines on Specific Operations Risk Assessment (SORA) [Link]
[Link]/content/jar-doc-06-sora-package
[5] SESAR ER RPAS Call Technical Specification for H2020-SESAR-2016-1
[Link]
doc-er-sesar-ju-2016_en.pdf

88 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

[6] SESAR Joint Undertaking: U-space Blueprint

[Link]
space%20Blueprint%20brochure%[Link]
[7] SESAR Joint Undertaking: Roadmap for the safe integration of drones into all classes of
airspace. 1st March 2018
[Link]
%20Plan%20Drone%[Link]?
[8] SESAR Joint Undertaking: European Drones Outlook Study
[Link]
tudy_2016.pdf
[9] EUROCONTROL & EASA: Unmanned Aircraft Systems (UAS) ATM Integration Operational
Concept, [Link]
integration-operational-concept
[10] ICAO: Annex 2 to the convention on Civil Aviation, Rules of the Air, available from
[Link]
[11] ICAO: Annex 11 to the convention on Civil Aviation, Air Traffic Control Service, Flight
Information Service, Alerting Service, available from [Link]
[12] EU / EASA: Regulation (EC) No 923/2012 of the European Parliament and of the Council of
26 September 2012 laying down common rules of the air… Including amendment by
Regulation (EC) No 1185/2016 of 20 July 2016. [Link]
content/EN/TXT/?uri=CELEX:02012R0923-20171012
Also available at
[Link]
ndardised%20European%20Rules%20of%20the%20Air%20%28SERA%[Link]
[13] ICAO: Manual on remotely piloted aircraft systems (RPAS) – ICAO doc 10019, available from
[Link]
[14] ICAO: Procedures For Air Navigation Services, Air Traffic Management, ICAO doc 4444,
available from [Link]
[15] EUROCONTROL & EASA: UAS ATM Flight Rules
[Link]
[16] EUROCONTROL & EASA: UAS ATM Airspace Assessment
[Link]
[17] EUROCONTROL & EASA: UAS ATM Common Altitude Reference System
[Link]
[18] Airbus (Altiscope): Blueprint for the Sky, The roadmap for the safe integration of
autonomous aircraft, 5/9/18. [Link]
[19] Altiscope (Airbus): Technical Report Library, currently available at
[Link]
[20] Altiscope (Airbus): Technical Report 004: Metrics to Characterize Dense Airspace Traffic
[Link]
[21] Altiscope (Airbus): Technical Report 008 A Quantitative Framework for UAV Risk
Assessment: Version 1.0 [Link]

© – 2019 – CORUS consortium except as noted. 89

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

[22] FAA / NASA: Unmanned Aircraft Systems (UAS) Traffic Management (UTM) Concept of
Operations, Version 1, 18/5/18. [Link]
[23] EASA: Concept of Operations for Drones
[Link]
_web.pdf
[24] Swiss Federal Office of Civil Aviation: Swiss U-Space ConOps,
[Link]
delle/U-space_ConOps.[Link]/Swiss%20U-Space%[Link]
[25] EATMA, the European Air Traffic Management Enterprise Architecture - is not described
online but its current contents are presented as part of the EUROPEAN ATM Master Plan.
[Link]
[26] The EUROCONTROL ATM Lexicon [Link]
[27] EATMA Guidance material, version 9.
[Link]
66e5b2deab5c&appId=PPGMS (ignore web page – the correct file is downloaded)
[28] [NTIA 2016] The US National Telecommunications and Information Administration
“Voluntary Best Practices for UAS Privacy, Transparency, and Accountability” Convened
Multistakeholder Process. May 2016. Available at
[Link] uas_privacy_best_practices_6-[Link]
[29] [AEDRON 2016] Asociacion Española de drones y afines. “Codigo etico de conducta de
profesionales de RPAS, tanto pilotos, como empresas operadoras”. Jun 2016. Available at
[Link]
[30] [Guidelines 2012] International Association of Chiefs of Police Aviation Committee.
Recommended Guidelines for the use of Unmanned Aircraft, August 2012.
[31] [Guidelines 2015] Best Practices for Protecting Privacy, Civil Rights & Civil Liberties in
Unmanned Aircraft Systems Programs. U.S. Department of Homeland Security, Dec 2015.
[32] [ACI 2018] Michael S. Baum et al. "UAS PILOTS CODE. Tools to advance UAS safety and
professionalism", Version 1, Jan 2018. UAS Pilots CODE © Aviators Code Initiative (ACI) and
University Aviation Association. Available on-line at [Link]
[Link]
[33] [AESAa 2018] Agencia Española de Seguridad aérea, “APÉNDICE H: MEDIOS ACEPTABLES DE
CUMPLIMIENTO RELATIVOS AL PROGRAMA DE MANTENIMIENTO “, Version 2, Real Decreto
1036/2017, Jul 2018.
[34] [AESAb 2018] Agencia Española de Seguridad aérea, “Apéndice E: GUÍA SOBRE EL
CONTENIDO DEL MANUAL DE OPERACIONES“, Mar 2018.
[35] [Drones 2014], Rachel L. Finn et al. “Study on privacy, data protection and ethical risks in
civil Remotely Piloted Aircraft Systems operations. Summary for industry”, European
Commission Nov 2014.
[36] [Grids 2014] Workshop "The Future of Social Acceptance". Available at
[Link]
[Link]
[37] [HEMAV 2018] HEMAV SL. “Configuración de Plataformas (P-05-4.1-05)”. 2017

90 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
U-SPACE CONCEPT OF OPERATIONS

[38] [JARUS 2016] JARUS, “CS-LUAS Recommendations for Certification Specification for Light
Unmanned Aeroplane Systems”. 2016 [Link]
[Link]/files/jar_05_doc_cs-luas_v0_3.pdf
[39] [DR1 2018] Dronerules, “Recommendations for a pilot performing a professional mission”
2018.
[40] [DR3 2018] Dronerules, “Recommendations for recreational pilots” 2018
[41] [TP 2016] Department of Transport of Canada, “Flying for fun? Rules for recreational drones
users”. 2016.
[42] [GNL 2017] The Google News Lab, “Drone Journalism Code of Ethics”. 2017
[43] ICAO Performance-Based Navigation Manual, ICAO doc 9613,
[Link]
%20Doc%209613%20Final%205%2010%2008%20with%[Link]
[44] Regulation (EC) No 785/2004 of the European Parliament and of the Council of 21 April
2004 on insurance requirements for air carriers and aircraft operators [Link]
[Link]/legal-content/EN/TXT/?uri=celex:32004R0785
[45] ICAO Global Air Traffic Management Operational Concept, Doc 9854, first edition, 2005.
Available at
[Link]
f and [Link]
[Link]
[46] UAS ATM common altitude reference system (CARS) discussion document
[Link]
discussion-document
[47] ICAO Doc 9965 Manual on Flight and Flow — Information for a Collaborative Environment
(FF-ICE) [Link]
[48] Office of Inspector General (United States Postal Service), 2016, “Public Perception of Drone
Delivery in the United States”, RARC-WP-17-001
[Link]
[Link]
[49] Wikipedia definition of ConOps in English:
[Link]
[50] The Global UTM Association UAS Traffic Management Architecture,
[Link]
[51] NASA UTM portal [Link]
[52] JARUS publications [Link]
[53] EASA Notice of Proposed Amendment 2015-10
[Link]
[54] ICAO Global Air Traffic Management Operational Concept. ICAO doc 9854
[Link]
f
[55] ICAO Performance-based Navigation (PBN) Manual, doc 9613
[Link]
%20Doc%209613%20Final%205%2010%2008%20with%[Link]

© – 2019 – CORUS consortium except as noted. 91

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.
 EDITION 03.00.02

[56] ECA Position Paper on Specific Operations Risk Assessment (SORA), available at
[Link]
01/SORA_ECA_Position_Paper_19_0128_F.pdf
[57] Acceptable Means of Compliance (AMC) and Guidance Material (GM) to Commission
Implementing Regulation (EU) 2019/947
[Link]
ion%20Implementing%20Regulation%20%28EU%29%202019-
947%20%E2%80%94%20Issue%[Link]
also Acceptable Means of Compliance (AMC) and Guidance Material (GM) to Part-UAS UAS
operations in the ‘open’ and ‘specific’ categories
[Link]
UAS%20—%20Issue%[Link]

92 © – 2019 – CORUS consortium, except as noted

All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions.