U-Space CONOPS 4th Edition

U-SPACE CONCEPT OF
OPERATIONS (CONOPS)
FOURTH EDITION
VERY LARGE-SCALE DEMONSTRATION
U-space ConOps and

architecture (edition 4)
Deliverable ID: D4.2
Dissemination Level: PU
Project Acronym: CORUS-XUAM
Grant: 101017682
Call: SESAR-VLD2-03-2020
U-space capabilities and services to enable Urban
Topic:
Air Mobility
Consortium Coordinator: EUROCONTROL
Edition Date: 20 July 2023
Edition: 01.00.02
Template Edition: 02.00.05
U-SPACE CONOPS AND ARCHITECTURE
(EDITION 4)
Authoring & Approval
Authors of the document

Beneficiary Date
EUROCONTROL 20-7-2023
Reviewers internal to the project

Beneficiary Date
Reviewers external to the project

Beneficiary Date
Approved for submission to the S3JU By - Representatives of all beneficiaries involved in the
project
Beneficiary Date
EUROCONTROL 20-7-2023
Rejected By - Representatives of beneficiaries involved in the project

Beneficiary Date
Document History
Edition Date Status Beneficiary Justification
D4.1 26/8/2022 Delivered EUROCONTROL Baseline for this version
00.00.01 8/2/2023 Draft EUROCONTROL Incorporating WP3 inputs
00.00.02 23/2/2023 Draft EUROCONTROL Incorporating WP4 inputs
00.00.03 12/3/2023 Draft EUROCONTROL Incorporating CCC inputs
00.00.04 11/4/2023 Draft EUROCONTROL Incorporating comments
from consortium
01.00.00 17/4/2023 Delivered EUROCONTROL Approved by Consortium
01.00.01 26/6/2023 Delivered EUROCONTROL Reacting to SJU feedback
01.00.02 20/7/2023 Delivered EUROCONTROL Reacting to SJU feedback
A more detailed explanation of the evolution of the content of this document appears in section 1.2.
Page 2
(EDITION 4)
Copyright Statement © 2023 – CORUS-XUAM consortium. All rights reserved. Licensed to SESAR3
Joint Undertaking under conditions.
CORUS-XUAM
CORUS-XUAM
This Concept of Operations is part of a project that has received funding from the SESAR3 Joint
Undertaking under grant agreement No 101017682 under European Union’s Horizon 2020 research
and innovation programme.
The SESAR3 Joint Undertaking was co-founded by EUROCONTROL who provide in kind contribution to
its operations and projects. This project has benefited from that support.
Abstract
U-space is Europe’s traffic management system for Uncrewed Aerial Systems, also called drones. The
CORUS project, 2017 to 2019, produced three editions of the U-space Concept of Operations or
ConOps. The third edition [1] was produced in October 2019. The ConOps explains how U-space works
from a user’s point of view. A preliminary version of the fourth edition of the ConOps, labelled 3.10,
was released in July 2022 for comment. This is now the consolidated fourth edition. It differs from the
third edition for three reasons: Improved consideration of UAM needs; adjustments according to the
regulatory evolution; incorporation of inputs stemming from other R&D projects.
Meeting the needs of UAM focuses on processes at the vertiport, airspace structure and flight rules,
particularly as passenger carrying operations with electric vertical take-off and landing (EVTOL or
eVTOL) aircraft are expected within U-space; initially with a pilot on board, later remotely piloted. The
key feature of the eVTOL, currently, is short flight duration and U-space has to be able to provide safe
operation with this constraint.
The European Union regulations, primarily 2021/664, 665 and 666 known as the U-space regulatory
framework, sets the minimum requirements for the U-space in terms of seven services, six functional
plus “common information.” This ConOps includes these services.
Some research projects bring more precise descriptions of services or processes already mentioned,
for example dynamic capacity balancing (DACUS), and some projects bring new services like altitude
conversion services (ICARUS).
This fourth edition of the U-space ConOps aims to serve as a reference manual for U-space.
Page 3
(EDITION 4)
Table of Contents
Abstract ................................................................................................................................... 3
1 Introduction ............................................................................................................... 8
1.1 What is a ConOps .......................................................................................................... 8
1.2 U-space Concept of Operations edition 4 compared to ed 3 ............................................ 8
1.3 What is in the scope of this ConOps ............................................................................. 11
1.4 Expected evolution of U-space ..................................................................................... 13
1.5 The structure of this ConOps and how to read it ........................................................... 16
2 Operating environment ............................................................................................ 19
2.1 Urban Air Mobility ....................................................................................................... 19
2.2 The phases in the life of a flight.................................................................................... 20
2.3 Airspace ...................................................................................................................... 30
2.4 Ground Infrastructure for UAM .................................................................................... 38
2.5 U-space infrastructure and the role of a mandated actor .............................................. 43
3 U-space services ....................................................................................................... 47
3.1 Introduction ................................................................................................................ 47
3.2 Registration ................................................................................................................. 48
3.3 Surveillance in U-space ................................................................................................ 49
3.4 Airspace Management ................................................................................................. 52
3.5 Mission management .................................................................................................. 54
3.6 Tactical conflicts .......................................................................................................... 65
3.7 Vertiport availability service ........................................................................................ 67
3.8 Weather Information ................................................................................................... 67
3.9 Geographical Information Service ................................................................................ 67
3.10 Monitoring .................................................................................................................. 67
3.11 Legal Recording ........................................................................................................... 68
3.12 Emergency Management ............................................................................................. 68
3.13 Incident / Accident reporting ....................................................................................... 69
3.14 Traffic Information ...................................................................................................... 69
3.15 Infrastructure monitoring ............................................................................................ 70
3.16 Digital Logbook............................................................................................................ 70
3.17 Procedural interface with ATC ...................................................................................... 70
3.18 Collaborative interface with ATC .................................................................................. 72
Page 4
(EDITION 4)
3.19 Vertical Conversion Service .......................................................................................... 73

3.20 Vertical Alert and Information Service.......................................................................... 73
3.21 Service names in comparison with EU regulation and the previous ConOps ................... 74
4 Flight rules ............................................................................................................... 79
4.1 Rules of the Air ............................................................................................................ 79
4.2 UFR ............................................................................................................................. 79
5 Examples of using U-space services .......................................................................... 81
5.1 Architectural photography ........................................................................................... 81
5.2 Aerial mapping ............................................................................................................ 83
5.3 Power line inspection .................................................................................................. 84
5.4 Pharmaceutical delivery............................................................................................... 85
5.5 Passenger carrying, remotely piloted, scheduled. ......................................................... 86
5.6 Passenger carrying, remotely piloted, on demand. ....................................................... 88
6 Social acceptability .................................................................................................. 90
6.1 Operating Environment ............................................................................................... 90
6.2 Phases of flight ............................................................................................................ 92
6.3 Airspace ...................................................................................................................... 93
6.4 Ground infrastructure .................................................................................................. 93
6.5 U-space infrastructure and services .............................................................................. 94
7 Architecture ............................................................................................................. 95
7.1 Architecture principles................................................................................................. 95
7.2 Architecture Framework .............................................................................................. 96
7.3 Stakeholders and Roles ................................................................................................ 96
7.4 Operational processes and Information Exchanges ....................................................... 99
7.5 A generic system breakdown ...................................................................................... 101
7.6 U-space Portal ............................................................................................................102
8 Regulatory context.................................................................................................. 104
9 References, Terms, Acronyms ..................................................................................106
List of Tables
Table 1: Lifecycle of the U-plan ............................................................................................................. 20
Table 2 ICARUS services ........................................................................................................................ 32
Table 3 X Y Z Volumes ........................................................................................................................... 32
Page 5
(EDITION 4)
Table 4: Equating subdivisions of the airspace: Volumes, Geographic Zones and Airspace classes..... 37
Table 5 Geo-awareness services in EU regulation ................................................................................ 54
Table 6 Relative scopes of the Flight Authorisation Service of 2021/664 and this ConOps ................. 55
Table 7: U-space Services cross reference ............................................................................................ 76
Table 8: U-space stakeholders .............................................................................................................. 98
Table 9 Acronyms ................................................................................................................................ 114
Table 10 Terminology .......................................................................................................................... 114
List of Figures
Figure 1: U-space levels, from U-space Blueprint ................................................................................. 14
Figure 2 Urban Air Mobility Venn diagram ........................................................................................... 19
Figure 3: Timeline schema of the lifecycle of a U-plan ......................................................................... 20
Figure 4 Verification of the design of a UAS (diagram from EASA) ....................................................... 21
Figure 5: Air taxiing and Ground movement vertiport configuration ................................................... 40
Figure 6: Vertiport Classification from Operations Perspective [23] .................................................... 41
Figure 7 U-space services ...................................................................................................................... 47
Figure 8 Flight authorisation in EU IR 2021/664 ................................................................................... 58
Figure 9 Flight Authorisation flow chart including RTTA ....................................................................... 59
Figure 10 Area-based and Linear 4D trajectories, in green................................................................... 61
Figure 11 Deviation thresholds for two non-conflicting U-plans .......................................................... 62
Figure 12 Near Mid-air-collision volume and other thresholds - from BUBBLES .................................. 66
Figure 13 AURA scenario with airspace predominantly controlled by ATC .......................................... 72
Figure 14 AURA scenario with airspace predominantly U-space .......................................................... 72
Figure 15 EU IR 2019/947 and U1 U-space services.............................................................................. 77
Figure 16 EU IR 2021/664 (default), 2021/665 and U2/U3 services (1)................................................ 77
Figure 17 EU IR 2021/664 (default), 2021/665, 2021/666 and U2/U3 services (2) .............................. 78
Figure 18 U2/U3 services not linked to European regulations 2019/947 or 2021/66[456]. ................ 78
Figure 19: U-space Stakeholders, shown in aggregation. ..................................................................... 99
Page 6
(EDITION 4)
Figure 20: information exchanges, informal presentation ................................................................. 100
Figure 21: Operational use case for the departure from a vertiport .................................................. 101
Figure 22: Generic U-space system breakdown .................................................................................. 102
Page 7
(EDITION 4)
1 Introduction
The opinions expressed herein reflect the authors’ views only. Under no circumstances shall the SESAR
Joint Undertaking be responsible for any use that may be made of the information contained herein.
1.1 What is a ConOps

A concept of operations (abbreviated CONOPS, or ConOps) is a document describing the characteristics
of a proposed system from the viewpoint of an individual who will use that system. It is used to
communicate the quantitative and qualitative system characteristics to all stakeholders1.
This ConOps tries to answer the basic question “how does U-space work” and in doing so provides a
common basis for discussion of details. The ConOps provides terminology and a general model of the
overall system of U-space. Ideally the ConOps expresses a set of ideas and assumptions that the reader
absorbs, applies and is not conscious of. Until that is achieved this document aims to be a reference
manual for, or an encyclopaedia of U-space.
1.2 U-space Concept of Operations edition 4 compared to ed 3

The CORUS project ran from September 2017 to November 2019 and produced three editions of the
U-space ConOps in an iterative process involving collaboration with a large number of stakeholders
including other research projects. (The CORUS project received funding from the SESAR Joint
Undertaking under grant agreement No 763551 under European Union’s Horizon 2020 research and
innovation programme.) Edition 3 of the U-space ConOps [1] was published in October 2019 and since
then has been downloaded more than 4000 times.
This document is the fourth edition of the U-space ConOps. Due to the rapid development of the U-
space knowledge domain, the need for an updated version of the ConOps became evident. Specifically,
this edition aims to address the following.
 The presentation should be concise and easy to read. The 3rd edition [1] is very long and
contains a great deal of discussion. The original CORUS project put a lot of effort into
explaining as the audience being addressed was generally new to the topic. The audience
for edition 4 is better informed.
 Several European regulations have been published that diverge from the U-space ConOps in
detail if not in spirit. They need to be fully embraced in the ConOps.
 The specific aim of CORUS-XUAM (The CORUS Extension for Urban Air Mobility), which is to
study how the needs of Urban Air Mobility impact U-space.
 Many developments, research & demonstration projects have occurred, standards and
legislation have been written that have moved the state of the art.
The latter three bullets are expanded below.
1
Wikipedia, https://en.wikipedia.org/wiki/Concept_of_operations accessed January 2023
Page 8
(EDITION 4)
1.2.1 The scope and impact of EU regulations

One of the motivations for producing the fourth edition of the U-space ConOps was to reconcile the
impact of the EU (European Union) regulations. The Edition 3 ConOps [1] was produced in 2019. Since
then the U-space regulatory framework has been published: EU Implementing Regulation (IR)
2021/664 [8], 2021/665 [9] and 2021/666 [10] and the relevant Acceptable Means of Compliance and
Guidance Material (AMC-GM) [11]. The scope of the U-space regulatory framework is a U-space
airspace. The U-space regulatory framework addresses the competent authority, the common
information service provider, the U-space service provider, the UAS operator and in 2021/666, other
aviators.
These U-space regulatory framework does not address other airspaces, notably controlled airspace or
UAS geographic zones which are not U-space airspaces. Y and Z airspaces are volumes in which U-space
services are used, which include but might not be limited to the U-space airspaces of the regulations.
The U-space regulatory framework provides a minimal set of functions to enable low density beyond-
visual-line-of-sight (BVLOS) flight. The scope is approximately U2 in terms of Figure 1.
The terms and scope of the U-space regulatory framework, [8] [9] [10], with [11] are reconciled in this
version.
1.2.2 Impactful research projects

The SESAR Joint Undertaking has organised a forum called the ConOps Coordination Cell (CCC) which
has promoted the U-space Conops edition 3 as a foundation of SESAR U-space projects and encouraged
the feeding back of ideas into this, the U-space ConOps edition 4. Of the sixteen projects that took part
in the CCC, several whose impacts are most visible are bulleted below. The others all contributed
providing refinements of the ConOps and validating its contents in experiments, those listed below are
examples whose impacts can be summarised briefly.
 ICARUS [28] examined the Common Altitude Reference System, proposing two new services
and modifying two others.
 BUBBLES [54] studied the processes of separation and proposed a new service. The BUBBLES
project refined the definition of the Tactical Conflict Detection and Tactical Conflict Resolution
services.
 DACUS [55] provided a detailed method for demand capacity balancing in U-space and refined
the definition of the dynamic capacity management service.
 The Gulf of Finland 2 project [46] (GOF2) developed and validated a set of data exchange
models to enable U-space. The same models were validated in the AURA project [47]. GOF2
deliverable D4.2 detailing these models is an annex to this ConOps.
 AMU-LED [45] examined, among other things, a division of the airspace in function of risk &
performance.
1.2.3 The key differences between edition 3 and edition 4

This comparison is between edition 3 of October 2019 [1] and this document. This comparison assumes
a good knowledge of edition 3. The comparison in this section is not required reading to understand
edition 4 and the reader may wish to skip to section 1.3.
Page 9
(EDITION 4)
1.2.3.1 Terminology
The term U-plan is used in edition 4 to mean a plan for a flight managed by U-space. Edition 3 used the
term “operation plan.” Throughout the period of the CORUS project and in subsequent interactions
with stakeholders there was often confusion about what was being referred to be operation plan,
which led to other terms being used like “drone flight plan” leading to more confusion, typically about
whether an Uncrewed2 Aerial System (UAS) could fly under a flight plan as described in ICAO document
4444 [57] . By putting the emphasis on U-space the term U-plan seeks to clarify. EU IR 2021/664 [8]
uses the term “flight authorisation request,” a term that can lead to confusion with the requirements
in EU IR 2019/947 [4].
The names used for airspace volumes have been revised slightly in edition 4. In edition 3, the airspace
volume Zu could be a region in which U-space gave tactical separation instructions or offered tactical
conflict resolution advice. This ambiguity has prevented clear discussion. Now the two modes of
operation are now given distinct names. In a Zu volume U-space will give tactical separation
instructions. In a Zz volume U-space will offer tactical conflict resolution advice.
The definition of the Y volume has been revised allow it to be the U-space airspace of EU implementing
regulation 2021/664 [8]. The mapping is not two way, all U-space airspace is Y, not all Y is U-space
airspace. See 2.3.5.3.
1.2.3.2 How the services differ between editions 3 and 4

The list of services has been changed between editions 3 and 4.
Some service names have been changed in edition 4 to bring them in line with the EU IR 2021/664 [8].
This difference is explored in Table 7.
Some services have been split into parts. For both strategic and tactical conflicts, the detection and
resolution functions have been separated. This is done to better match the likely implementations.
ASTM standard F3548 [18] describes a strategic conflict detection mechanism. The standard mentions
that conflict resolution would be by negotiation between the concerned service providers but does
not describe the negotiation process in detail. EU IR 2021/664 [8] can be implemented with ASTM
F3548 for strategic conflict detection, but in EU IR 2021/664 the process for resolution of strategic
conflicts is not negotiation between U-space Service Providers (USSP).
Edition 3 described the “operation plan processing service” as doing many things. Edition 4 splits the
activities between the Flight Authorisation service whose focus is pre-flight and the U-plan processing
service which is concerned with active flights, following work in the Gulf of Finland 2 (GOF2) project
[46].
The AURA project [47] explored the interactions between Air Traffic Control (ATC) and U-space. They
proposed a finer grain of services than Edition 3. Following proposals of the AURA project, the
Collaborative interface with ATC now includes the Tactical Operational Message Info Exchange and the
Procedural interface with ATC now includes the Dynamic Airspace Reconfiguration (DAR) Service. See
sections 3.18 and 3.17 respectively.
2
UAS may also be expanded as Unmanned Aerial Systems.
Page 10
(EDITION 4)
Some services have been removed. Edition 3 mentioned a “registration assistance” service.
Interactions with stakeholders since the publication of Edition 3 show the service and its name causes
confusion. The authors of edition 3 considered the “registration assistance” service to be an example
of a value-added services which might be offered. The description of the service in edition 3 was vague.
It is not mentioned in edition 4.
Some services have been added. CORUS-XUAM has added the Vertiport availability service in section
3.7. The ICARUS project [28] added two new services to edition 4 and refined the definitions of several
others. The new services are the Vertical Conversion Service, section 3.19, and the Vertical Alert and
Information Service in section 3.20. See Table 2 for the services revised by ICARUS.
A number of other services have revised definitions following the work of CORUS-XUAM as well as
other research projects such as DACUS, ICARUS, BUBBLES, AURA and others.
Accommodating EU IR 2021/664 also extended the scope of the services of the ConOps between
editions 3 and 4. EU IR 2021/664 describes a Common Information Service – see 2.5.1 – which among
other things, lists which U-space Service Providers are certified to provide services in any U-space
Airspace.
1.3 What is in the scope of this ConOps

1.3.1 U-space
U-space is based on a set of services, see the U-space Blueprint [2] and Commission Implementing
Regulation (EU) 2021/664 [8]. These services are provided from the ground (generally) and concern
safety, security and efficient flight. This ConOps describes these services, how they are used and the
environment in which they are used.
There are many other closely related services that may be supplied to U-space stakeholders, for
business or other reasons, which are not considered to be in the scope of this ConOps. They may be
mentioned in passing.
1.3.2 Urban Air Mobility

Urban Air Mobility (UAM) in this document is defined as air operations which are:
 above urban areas, at least for part of the flight,

 in ‘U-space airspace,’ – see Section 2
 performed by a mix of traffic which includes aircraft:
o incapable of flying Instrument Flight Rules (IFR) or Visual Flight Rules (VFR),
o with very limited range,
UAM is expected to involve some situations in which the combined effect of a high level of traffic and
uncertainties in the navigation necessitate tactical separation to ensure safe operations.
The operations include passenger carrying operations with highly automated remotely piloted
electrically powered aircraft, as well as cargo and other flights with no human on board.
Page 11
(EDITION 4)
The European Union Aviation Safety Agency, EASA, has announced that the steps to 1) passenger
carrying operations with 2) remote pilot and a high degree of automation in 3) an electrically powered
aircraft in 4) lower airspace with novel traffic management will be made separately. Hence initial
operations may have pilot on board, but this should be viewed as a transition measure towards remote
piloting. Urban Air Mobility includes any flights meeting the conditions above.
That the operations are above urban areas implies that there are limited opportunities for safe
emergency landing which impacts the planning of operations.
The increased risk of Urban Air Mobility compared to other U-space operations, both in terms of
ground risk and in the air risk, especially when passengers are being carried, will influence the
performance requirements on the operations and procedures, but may not impact the procedures
themselves.
1.3.3 In scope
 Management of remotely piloted aviation of any level of autonomy
 Management of Pilot-on-board aviation
 Use of U-space in flight scenarios by different stakeholders
 Ground infrastructure such as Vertiports
 Contingency scenarios
 Safety
 Security including cyber-security
 Risk assessment and mitigation
 Social acceptability
 Flight rules
 Traffic management
 Optimisation of flight or traffic or airspace use according to key performance areas
1.3.4 Not in scope

 Whether or not there should be UAS flight and UAS applications3
 Business viability of drone uses, or of U-space service provision
 The environmental impact of UAS flight.
 Aircraft design, aircraft performance, aircraft certification
 Avionics, on board systems, detect and avoid, remote piloting stations
 Batteries, recharging, fuel cells, hydrogen production and storage
 Specific technologies (as far as possible)
 Command and Control (C2) links, navigation systems, surveillance technologies
 Human performance, Human-Machine Interface (HMI) design
 Licencing and certification of U-space service providers or their suppliers
 Pre-flight processes to determine whether a flight is possible, such as executing a Specific
operations risk assessment (SORA) when required to obtain an operational authorisation.
3
This document should be read as “if there is to be UAS flight then it should be as described here.”
Page 12
(EDITION 4)
How both the mandatory and optional U-space services can be used as mitigation measures
starting from the pre-defined residual airspace risk class (ARC) associated to each U-space
airspace, is considered to be outside the scope of this ConOps.
1.4 Expected evolution of U-space

At the time of writing, the number of UAS flights on an average day in Europe is small. The need for
what is described in this document may not be apparent. It is anticipated that the number of UAS
flights will rise and that urban air mobility will become more common. To help simplify discussion of
the problems this rise in traffic will cause and the solutions that U-space should bring, the CORUS-
XUAM project groups the expected traffic evolution into five eras, considering the following
assumptions.
1.4.1 Assumptions:
 While passenger carrying operations have higher risk than non-passenger carrying
operations, the procedures they use will be the same. Hence the concept of operations for
U-space can and should be extended to cover “Urban Air Mobility.” It may be that some
service providers are certified to provide services to passenger carrying operations and
others not, but the operational processes they are involved in will be the same for both.
 The services won’t all be available at the same time, and the most complicated will arrive
last (e.g., tactical conflict resolution).
 Technologies improvements and evolutions will allow UAS to fly more and more
autonomously.
 Required equipment costs will decrease with the time so that the cost for a crewed aircraft
shall be increasingly acceptable. Hence it is not a question of whether there will be
passenger operations, it is a question of when.
 As time progresses the proportion of operations that are uncrewed grows to exceed crewed
operations.
 U-space airspace will become more common with the different volume types eventually
being recognized as ICAO airspace classes.
 UAM infrastructure will be built incrementally to support operational needs.
 Airspace design will change to accommodate all operations.
 There is a balance between commercial secrecy and providing a common picture of
operations. As this ConOps is written that balance is that small UAS operators would prefer
that their operations are not generally known. The balance may shift.
 U-space service provision will be a competitive commercial activity. There will be multiple
simultaneous service providers and they will have to cooperate. That said, this ConOps
should be applicable to situations with one or more service providers.
Page 13
(EDITION 4)
The “U levels” or “U blocks” as defined in the U-space Blueprint [2] are assumed, as shown in Figure 1.
Figure 1: U-space levels, from U-space Blueprint
Airbus UTM Blueprint [20] proposes a timeframe of the automation level. CORUS XUAM would like to
propose a vision with a kind of calendar for U-space implementation. The topics that need to be
considered are the following.
 Availability of the U-space services

 Availability of the required technologies for Communication, Navigation and Surveillance,
(CNS) and ground infrastructure for drone operations
 Availability of the “drones effective enough” to perform specific operations (e.g., carry
heavy payload, long haul trip)
 Evolution of the airspace design and structure
 Interactions with crewed aviation in controlled and uncontrolled airspace
 Rules of the air
In the following five subsections, the different considered implementation phases are outlined.
1.4.2 Before 2023: the foundations of U-space

States are setting up registries and defining geographic areas in accordance with the UAS regulatory
framework, EU IR 2019/947 [4] & EU DR 2019/945 [5] and subsequent amendments such as 2020/639,
2020/746, 2020/1058, 2021/1166, 2022/425, etc, together with the corresponding AMC-GM [6] & [7].
Drones fly without U-space services. Manual coordination with and authorizations from the involved
authorities are usually required. ATC procedures make Visual Line of Sight (VLOS) flights possible,
though sometimes requiring some effort. Beyond Visual Line of Sight (BVLOS) flights are limited, time
consuming and expensive to set up.
1.4.3 Initial U-space implementation (2023-2030)

The U-space regulatory framework [8], [9], [10] and corresponding AMC-GM [11] came into force on
the 26th of January 2023. In line with these, a limited number of services are available, providing a
digital assistance to the authorities in charge of authorising the operations, and a digital assistance to
Page 14
(EDITION 4)
the operators to plan and declare their operations. When required, airspace structures are defined,
temporarily or permanently, to allow drone operations (e.g., corridors for point-to-point goods or
passenger carriage).
 U-space airspaces are defined:
o In controlled airspace, crewed aviation is not allowed to enter U-space airspace hence
ensuring separation from all UAS operations. Using the concept of Dynamic Airspace
Reconfiguration (DAR), Air Traffic Control can temporarily change the boundaries of
U-space by deactivating parts of the U-space airspace to allow for exceptional passage
of crewed aircraft. The U-space Service Providers (USSPs) are informed by ATC if and
when DAR is being used so they can adapt their flight authorisations in order for the
drone operators to no longer use these temporarily deactivated parts of the U-space
airspace.
o In uncontrolled airspace, crewed aviation is allowed to freely enter U-space airspace
provided that it is electronically conspicuous.
 In U-space airspace conflict resolution is strategic, that is, the plans are free of conflicts.
 Within U-space airspace, BVLOS operations are significantly easier to organise than has been
possible before.
 Traffic densities are expected to be relatively low. In the initial period flights are expected to
be widely spaced.
U-space is made aware of the current position and motion of the aircraft (surveillance)4 mostly by the
UAS reporting the position of the aircraft through the Network Identification Service. Initial operations
are expected to occur before the performance of U-space surveillance is well understood5. Plans will
initially be subject to wide separations in time and/or distance to allow for this uncertainty about the
performance of this surveillance.
The U-space regulatory framework [8], [9], [10] resolves strategic conflicts by prioritising “first to file.”
The authors of this ConOps expect when the U-space regulatory framework is revised, another
resolution scheme will be adopted in the interest of fairness to flights that cannot be planned long in
advance. This topic is explored in the paper Market Design for Drone Traffic Management, [27], but at
the time of writing no mature proposal for a fairer resolution scheme exists.
As experience grows, U-space and UAS evolve rapidly. Standards and best practice will emerge in a
number of fields. It is expected that during this period the level of performance achievable in
4
A traffic management system being made aware of the positions and motions of the vehicles being managed is
referred to as surveillance. When the observations of the traffic are made by an independent system, for example
a radar, then this is independent surveillance. When traffic management relies on the vehicles to report their
own positions, the surveillance is referred to as dependent surveillance. Network Id is (usually) dependent
surveillance.
5
U-space operations begin with the question of how precisely the positions and motions of UAS can be observed
under all conditions. Once the performance is understood, requirements can be specified. These two phases can
be inferred from EU IR 2021/664 having conformance monitoring optional. Conformance monitoring compares
observed position and expected position and is valuable if the accuracy of the observed positions is known.
Page 15
(EDITION 4)
communications, navigation and surveillance will improve. Confidence in the Communication,

Navigation and Surveillance (CNS) performance will lead to the safe provision of U-space tactical
services.
1.4.4 General U-space (2030-…)

In view of rising UAS traffic and as experience grows, many U-space airspace volumes have been
defined, in what was previously controlled or uncontrolled airspace. In uncontrolled airspace, as most
drone operations are performed in the VLL, U-space airspace is declared below 500 feet AGL. For some
UAS operations which require to fly higher, such as inter-cities passengers or cargo transportation,
corridors are in place and published in the AIP.
In more densely occupied U-space airspaces tactical conflict resolution is routinely offered. UAS traffic
in ATC controlled areas is routinely controlled by ATC through U-space; that is using U-space means of
CNS. In order to avoid exceeding the capabilities of the tactical conflict resolution service, a dynamic
capacity management service will be needed to match the capacity and traffic demand.
Some U-space airspaces with tactical services will accommodate remotely piloted flight according to a
new flight rule, UFR (see Section 4)
1.4.5 Advanced U-space

UAS operations are now very common, as are U-space volumes. U-space services and volumes are
increasingly used by crewed aircraft. U-space volumes are commonly defined above 500 feet AGL, up
to a few thousand feet as traffic necessitates. Tactical U-space services are in common use as is UFR.
1.4.6 Full U-space Integration

U4 is deployed. Most professional aerial operations are uncrewed. Uncrewed and crewed operations
use U-space services and fly UFR. U-space airspace is defined widely. Uncrewed aircraft are capable to
autonomously detect and avoid collision with any other aircraft.
The timing of Full U-space Integration is hard to gauge. While U-space may have followed the trajectory
mentioned above, full integration requires that most aircraft used for professional purposes are
uncrewed. If that requires new aircraft then the time taken may be a function of the useful life of the
final generation of crewed aircraft. Currently aircraft are expected to have a working life of 25 to 30
years on average, see [41] and [42].
1.5 The structure of this ConOps and how to read it

Sections 2, 3 and 4 are a reference manual for the elements of U-space. There is no correct order to
read them as understanding any section requires some knowledge of the others. Note that Sections 2,
3 and 4 are highly ‘compartmentalised’ and contain many levels of sub-heading to aid navigation.
Section 5 contains examples of how the elements in Sections 2, 3 and 4 are combined in operations.
The needs of different users are addressed in different subsections. If you are new to U-space start
with section 5 then refer to sections 2, 3 and 4
Sections 6, 7 and 8 provide the usage guides for what is presented in Sections 2, 3 and 4.
Page 16
(EDITION 4)
Section 9 gives references, explains terms and expands acronyms and abbreviations.
Five documents are provided in annex to this ConOps.
 U-space ConOps Architecture Annex 1.0, “U-space ConOps - Architecture Annex_1.0.docx”.

This document describes the architecture of U-space in five major chapters:
o Drivers addresses main inputs and architecture principles taken into consideration for
developing the U-space architecture in CORUS-XUAM.
o Strategic Architecture presents architecture elements and views to describe the U-
space architecture from a strategic point of view. It provides the description of the U-
space Capability Model.
o Business Architecture presents architecture elements and views to describe the U-
space architecture from a conceptual point of view. It provides the description of the
business process diagrams.
o Service Architecture presents architecture elements and views to describe the U-
space architecture from a service-oriented point of view. It provides the list of the
identified services and their links that present how the services realise the business
and supports the strategy.
o System Architecture presents architecture elements and views to describe the U-
space from a system point of view. It provides the description of possible breakdown
of the U-space in systems (in some cases with a further possible breakdown in
functional blocks) and their relationships.
 U-space ConOps Regulatory and Legal Impact Study, “SESAR CORUS X UAM D4.4 edition
01.00.00.docx”. The study aims to identify discrepancies between ConOps content and current
European regulations, and at making suggestions to adapt or improve, if required, the
regulatory framework.
 The Advanced U-space definition, “CORUS XUAM - D3.1 - Advanced U-space
Definition2.1.docx”. The section titles of this document are:
o Definition of the Operational Framework

o Operational Performance of UAM
o Safety and Contingency in UAM Operations
o Social Acceptance of Urban Air Mobility
The reader’s attention is particularly drawn to the Safety and Contingency section of the
Advanced U-space Definition, as the topic is not covered in this ConOps. In addition, the Social
Acceptance section is much more detailed than section 6 of this ConOps.
 The GOF2.0 project deliverable 2.4: GOF2.0 VLD Updated Service Specifications, “D2.4 GOF2.0
VLD Updated Service Specifications.docx”. This Word document contains embedded Word
documents. It proposes a number of data exchange models to support U-space. These models
have been developed and validated in the GOF2.0 project.
 U-space ConOps: Interface U-space/ATM (AURA sol.2), “U-space ConOps - Interface U-space-
ATM (AURA sol.2).docx”. This document provides the AURA team’s view of the architecture
needed to support the services they add to the ConOps. The document has been developed
by the AURA project in collaboration with CORUS-XUAM.
Page 17
(EDITION 4)
Page 18
(EDITION 4)
2 Operating environment
This chapter aims to give the context(s) in which the U-space services are used. Highlighting a
significant difference with the previous version of the ConOps, [1], Urban Air Mobility is explained. The
section then explains the lifecycle of a flight, the nature of the airspace and the ground infrastructure
of relevance to U-space.
2.1 Urban Air Mobility

“Urban Air Mobility” or UAM can be parsed thus:
 Mobility: someone or something is made able to move

 Air: above the ground
 Urban: over/near a town or city
Urban mobility refers to commonly used transport means such as train, bus, car/taxi, bicycle, walking
or boat. “Air” in UAM distinguishes mobility involving aircraft. The aircraft may have a crew on board
or might not. The following diagram shows this relationship.
As so much urban mobility involves people going to/from

work, the OECD definition of “functional urban area” is
used, see [22], “A functional urban area consists of a city
and its commuting zone. Functional urban areas
therefore consist of a densely inhabited city and a less
densely populated commuting zone whose labour
market is highly integrated with the city.“
The European Commission (EC) Sustainable and Smart

Mobility Strategy [58] lays out a vision for sustainable
mobility that mentions drone and air transport as being
part of multi-modal logistics and also smart mobility. The
European Commission fully supports the deployment of
drones and unmanned aircraft as part of this vision.
Figure 2 Urban Air Mobility Venn diagram
Urban air mobility flights by crewed aircraft are likely to involve current Air Traffic Control providing
services via radio. The expectation is that U-Space services will increasingly be used.
Page 19
(EDITION 4)
2.2 The phases in the life of a flight

The plan for an operation in U-space is referred to as a U-plan. Table 1 lists the activities in the different
phases of U-plan. Figure 3 shows the phases in a timeline. The sections that follow focus on the U-
space services used in each phase.
Phase Typical activities

Strategic – long term  Capacity planning: provision of services, airspace design
 Acquisition of aircraft, recruitment & training of crew
 Obtaining an operator’s licence / certificate (if appropriate)
Strategic – pre-flight  Developing a plan for a flight, selecting & configuring aircraft & crew
 Specific Operations Risk Assessment (SORA), Pre-defined Risk
Assessment (PDRA), etc, if needed
 Seeking permission to enter airspace / overfly (if needed)
 Contingency planning.
Pre-tactical  Demand capacity balancing

 Pre-flight de-confliction
Tactical  Activation
 Aviation (contingencies)
 Termination
Post-flight  Logging
 Reporting (as required),
 Maintenance,
 Performance assessment.
Table 1: Lifecycle of the U-plan
Figure 3: Timeline schema of the lifecycle of a U-plan
Page 20
(EDITION 4)
2.2.1 Strategic – long term

Many activities must take place to prepare for flight. These relate to the operator of an aircraft, the
aircraft and to the operating environment.
2.2.1.1 Airspace design & redesign

The competent authority, see 7.3, establishes the airspace structure including U-space airspaces
services and any technical constraints associated with them, in view of the expected risks, in line with
EU regulation 2021/664, and the airspace risk assessment mentioned in article 3 – see [8][11]. These
technical constraints will include factors that set the capacity of the airspace. The competent authority
is also required to review these requirements periodically in function of the expected UAS traffic.
2.2.1.2 UAS operator registration

The UAS operator shall be registered according to EU regulation 2019/947 – see [4][6]. In some
situations the aircraft may also need to be registered.
2.2.1.3 UAS type approval

Depending on the flight category or risk level a UAS may need a Type Certificate or a Design Verification
Report (DVR).
Figure 4 Verification of the design of a UAS (diagram from EASA)
Figure 4 is from https://www.easa.europa.eu/en/domains/civil-drones-rpas/specific-category-civil-

drones/design-verification-report. The processes to obtain either a DVR or a type certificate are out of
the scope of this document.
2.2.2 Strategic – pre-flight

During the strategic pre-flight phase, the flight goes from being an idea to a concrete plan for one or
more specific instances of flight. The process is likely to be iterative and balance business needs (or the
equivalent for a leisure flight) with risk, regulations and cost.
Page 21
(EDITION 4)
2.2.2.1 Operational category

The operational category of the flight may lead to approval being needed. The regulations embody
requirements of safety and public acceptability.
EU regulation 2019/947 – see [4] and [6] – describes different circumstances in which a flight may
occur, summarised below. Operations are categorised according to risk by combining aspects of the
aircraft such as mass with how, where & when it is flown.
 Open category operations must meet various criteria that all limit risk to people and
property. A flight not compatible with Open might be possible as Specific or Certified.
 There are different ways a Specific category flight can be permitted; by following an
approved specific operations risk assessment (SORA) or Pre-defined Risk Assessment
(PDRA), by conforming to a Standard Scenario (STS), as result of the operator holding a Light
UAS operator Certificate (LUC), or by following a process defined in an accepted alternate
means of compliance.
 Flights that do not meet the Open or Specific category conditions may be possible as
Certified category.
The determination of the operation category and then obtaining any necessary approval is a pre-flight
process that has some support from U-space. During this process the UAS operator may refine the U-
plan iteratively supported by U-space services, for example by routing the flight through areas of lower
“ground risk” and so on. The relevant services are:
 Geo-awareness, see Section 3.4.2

 Risk Analysis Assistance, see Section 3.5.1.5
Specific operations risk assessment is described in the SORA package of documents published by JARUS
[21]. The process aids the identification of risks associated with the flight and their mitigation,
including by use of U-space services. SORA approval may be for one flight or for a set of flights that
meet the same criteria. It is expected that U-space service providers will supply services and tools that
help the UAS operator optimise U-plans, including with the aim of conducting and optimising SORA.
Edition 3 of the ConOps mentioned the “U-plan preparation / optimisation” service, with a vague
description. While such services are assumed to exist, they are not described in this edition of the
ConOps.
2.2.2.2 Flight priority

EU regulation 2021/664 [8] article 10, paragraph 8 defines two levels of priority for flights which we
refer to as Normal and Priority. It states:
When processing UAS flight authorisation requests, the U-space service providers
shall give priority to UAS conducting special operations as referred to in Article 4
of Implementing Regulation (EU) No 923/2012.
EU regulation 2012/923 is SERA [12], the Standard European Rules of the Air. SERA Article 4 lists special
operations that may be granted exemptions:
a) police and customs missions;

b) traffic surveillance and pursuit missions;
c) environmental control missions conducted by, or on behalf of public authorities;
d) search and rescue;
Page 22
(EDITION 4)
e) medical flights;
f) evacuations;
g) fire fighting;
h) exemptions required to ensure the security of flights by heads of State, Ministers and
comparable State functionaries.
How priority impacts U-plan processing is discussed in sections 2.2.2.4 and subsequent.
2.2.2.3 Vertiport constraints

An U-plan for a flight may include taking off from or landing at a vertiport. That ground movement may
be constrained by a number of factors that must be taken into account in the U-plan.
 The flight must have permission to use the vertiport. This has different aspects. The aircraft
should be compatible with the vertiport, which could include flight characteristics, size,
noise, charging or refuelling requirements, ground handling needs, etc. As there are likely
to be fees for using the vertiport, the vertiport operator may require some contractual
arrangements to be set up before the aircraft operator can plan operations. (Or not, a
vertiport may be open to all.) The net result is that the flight planning may be limited to a
subset of the total number of vertiports.
 A vertiport is likely to have a limited number of FATO (Final Approach and Take-Off areas.)
The vertiport operator is likely to be optimising the use of the vertiport and may constrain
the time slot available for take-off or landing for any flight. Hence the U-planning will have
to fit into these time slots.
There are (at least) three possible approaches to including the vertiport in the strategic phase of U-
planning.
1. The vertiport is “mostly available” and in terms of deconfliction it can be treated like
airspace; it is a resource at which there may be a conflict between operations. The
allocation of the vertiport as a resource can be achieved in the same way as flights are
strategically deconflicted.
2. The vertiport is “busy” and has its own planning process which imposes time-slot
constraints on the take-off and landing. These time slots balance the need for vertiport
efficiency while allowing enough margin that strategic uncertainties can be
accommodated. Strategic U-planning can usually respect these time slots, hence vertiport
planning and U-planning are loosely coupled.
3. The vertiport is “extremely busy” and is the most constraining resource of the entire
network. Hence time slots are as brief as operations allow and all aspects of U-planning
are in function of these slots. U-planning cannot be decoupled from vertiport planning in
case the needs of in-flight strategic deconfliction trigger a change to vertiport planning.
This model can be dealt with in two ways: as a static construction or by dynamically
updating the planning continuously.
The three approaches are touched on below.
2.2.2.4 U-plan optimisation & approval

It is assumed that during the strategic phase the U-plan is created including any necessary permissions
being obtained.
Page 23
(EDITION 4)
The last activity of the strategic phase is when the U-plan is filed. EU IR 2021/664 [8] calls the U-plan
the “flight authorisation request.” Unfortunately, the term “authorisation” is used in both EU IR
2019/947 [4] and EU IR 2021/664 with different meanings. The authorisation of 2019/947 is part of
the general permission to fly and may cover more than one instance of the flight, while the
authorisation of 2021/664 refers to a single instance of flight at a specified date and time. The U-plan
is the latter.
“Filing” or submitting the U-plan makes use of the Flight Authorisation service , see 3.5.2. The filed U-
plan might be authorised or rejected. In case the U-plan is rejected, an explanation will be given as to
why the U-plan has been rejected and there may be a suggestion for how to construct a valid U-plan
which is similar to that which was rejected. Following rejection, the UAS operator might refile a
modified U-plan which addresses the reason for rejection. Successive filings may form part of the
iterative process of planning.
Many UAS operators are expected to use tools to prepare and file their U-plans. These tools will build
the U-plan based on the business need of the operator. These tools will optimise the U-plan given the
various preferences of the operator and the constraints coming from U-space, and should manage the
process of successively modifying and re-filing to find a U-plan that is free of conflicts.
The strategic phase ends when the U-plan is authorised.
Authorisation logic depends on the era. In the Initial U-space implementation (2023-2030) era, the U-
plan is only authorised if it is free of conflict with other U-plans of the same or higher priority. In the
later eras, it is likely that strategic conflict resolution cannot be completed at the time of filing, hence
authorisation might not indicate an absence of conflicts. Such conflicts would be resolved in the pre-
tactical phase, as is explained below.
2.2.3 Pre-tactical
Once the U-plan has been authorised the pre-tactical phase begins. The pre-tactical phase ends with
activation of the U-plan, which triggers the start of the tactical phase.
During the pre-tactical phase the U-plan may have its authorisation withdrawn or a warning may be
issued, for any of three reasons:
1 Due to a conflict with another U-plan

2 Due to traffic demand exceeding airspace capacity
3 Due to a change in the airspace structure
Each is explained below. Each can occur at any moment. The logic depends on the operating
environment and the prioritisation scheme in conflict resolution.
2.2.3.1 The pre-tactical phase during the Initial U-space implementation (2023-
2030)
The U-space regulations [8], [9], [10], [11] refer to a flight authorisation request which is considered to
be equivalent to a U-plan. The regulations require that a U-plan can only be authorised if it is free of
conflicts and that U-plans are prioritised by filing time. Hence the filing of a new U-plan in conflict with
an already approved U-plan of the same priority leads to that new U-plan being rejected and the
already authorised U-plan not being impacted. However, if a new U-plan of higher priority is filed and
is in conflict with any authorised U-plan(s), that/those U-plans have their authorisation withdrawn. As
Page 24
(EDITION 4)
the U-space regulations do not describe a change process, the lower priority U-plan is in effect
rejected.
The U-space regulations; 2021/664 [8], 2021/665 [9], 2021/666 [10] & Acceptable Means of
Compliance and Guidance Material (AMCGM) [11], describe an environment without demand-capacity
balancing, hence the second reason for pre-tactical permission removal, above, does not apply.
U-space regulation 2021/664 Annex iv [8] proposes a “flight authorisation request” format which lacks
any means to indicate that a flight has permission to enter any airspace. The Acceptable Means of
Compliance and Guidance material to Article 10(7) of 2021/664 [11] explains that in cases where
permission is needed, processing on the basis of Annex iv will result in a warning. The USSP may be
able to test technical compliance in some cases, or directly request permission, where possible.
2.2.3.2 Conflict resolution & dynamic capacity management

In eras after that described in 2.2.3.1, there is expected to be dynamic capacity management and the
following model is expected to apply. The details are currently the subject of research [29] and may
change.
2.2.3.2.1 Reasonable Time To Act

It is assumed that U-plans will be filed at different times in advance of activation, depending on the
business process of the UAS operator. Some UAS operators would like to file their U-plans very shortly
before activation.
It is also expected that U-plans will be subject to revision to meet the needs of the UAS operator. These
changes can also appear at any time before activation.
Hence any process that is going to impact plans in order to balance demand and capacity will only have
a “complete” picture of the demand very close to activation. Whatever the balancing process is, the
impact it has (for example changing the route or delaying activation, hence take-off) needs to be
absorbed by the UAS operator. There may be operators whose businesses cannot accommodate
impacts on their U-plans very shortly before activation.
Hence a compromise is reached. An agreed time is used as the moment to determine what is the
demand and which if any U-plans are impacted if the demand exceeds the capacity. This agreed time
is the “reasonable time to act,” (RTTA.) It is an agreed amount of time before the activation.
RTTA might be 5 minutes, or perhaps 1 minute, or even more or less. It may be that in different
airspaces different RTTA are used. The principle remains the same.
2.2.3.2.2 Demand Capacity Balancing and RTTA

As explained above at RTTA there should be an acceptably complete picture of the traffic, hence the
balance can be made between demand and capacity. The description that follows may be subject to
refinement as it is tested experimentally.
The process of DCB with RTTA proceeds continuously but is best understood in terms of four cohorts
of U-plans. Those which have passed RTTA, those at RTTA, those not yet at RTTA and “late filers”, U-
plans that are either filed or changed after RTTA.
U-plans that have passed RTTA are “frozen” and no longer subject to change. They form part of the
demand picture but cannot be impacted in order to match that demand to the capacity.
Page 25
(EDITION 4)
U-plans that are “at RTTA”, whatever that means, form part of the demand picture. They are fitted
into the available capacity and impacted if necessary. In this process they “freeze” and the impacts are
revealed to the operators. The DCB process acts on the “pool” of U-plans at RTTA and will optimise for
some metric, for example fewest flights impacted, minimum total impact (minutes of delay) or
whatever is agreed.
U-plans that are not yet at RTTA form part of the demand picture. They are tentatively fitted into the
available capacity but may be subject to revised impacts later.
Late filers are added to the frozen set as well as can be achieved after the “at RTTA” cohort has been
optimally served.
There may be sudden changes in capacity, for example the closure of an airspace or vertiport, that
impact U-plans that are past RTTA. It is expected that this situation is infrequent.
2.2.3.2.3 Applying RTTA to Strategic Conflict Resolution

In the absence of schemes like auctions, applying RTTA to strategic conflict resolution can avoid the
systematic disadvantage imposed by “first to file” prioritisation on businesses that cannot file far in
advance such as on-demand delivery or air-taxis. The scheme is similar to that for DCB
 Until the RTTA a U-plan is not deconflicted. It is counted as part of the expected traffic but
not acted upon.
 During the period a flight is considered to be at RTTA, the flight is subject to a conflict
resolution process and subject to measures to balance demand and capacity. These
processes do not change flights which have passed RTTA, and for those flights at RTTA, seek
to find an optimal deconfliction. It is at this time that the flight authorisation may be
withdrawn and the operator may have to file a modified plan.
 After the required time to act, the flight is left alone unless:
o It is in conflict with a higher priority flight

o There are other circumstances that prevent flight, such as a closed vertiport
2.2.3.2.4 On the management of uncertainty

In the execution of any plan there is some uncertainty of the outcome. The sources of the uncertainty
may be considered at the level of an individual operation to be exceptional (the head-wind was strong
and the flight took longer than planned) while at the macro level these may be normal events (a few
days a year there are very strong winds). In a mature operating environment, uncertainty can be
characterised by previous experience.
Control theory shows that precision can be improved by the application of negative feedback, for
example by varying the speed of the flight to achieve a precise arrival time, but doing so sacrifices
another optimisation, for example fly so as to maximise battery life. Negative feedback also sets the
“normal” performance much worse than the “best” – the flight always takes as long to arrive as it
would on the most windy day. (Analogous to the difference between open-loop and closed-loop gain.)
These uncertainties limit the precision of the plans and hence the optimisations of the system. There
will need to be trade-offs in U-space between different optimisations, including at least three: the
optimisation of each flight, optimisation of vertiport utilisation and optimisation of airspace capacity.
This ConOps cannot quantify these imprecisions nor propose how to trade-off between these
Page 26
(EDITION 4)
optimisations but highlights that planning precision should be considered and quantified at all phases
of the operation. The RTTA value and precise process are likely to impact this trade-off.
2.2.3.3 Pre-tactical overall, in the later eras

At the beginning of the pre-tactical phase, the flight is authorised.
During the pre-tactical phase this authorisation may be withdrawn at any time due to a change in the
airspace structure, due to an unresolvable change in capacity (e.g. vertiport closure) or due to a conflict
with a higher priority flight. The 2.2.3.3 authorisation might be withdrawn at RTTA due to an excess
of demand or a conflict with one or more flights of the same priority.
Any withdrawal might be resolved by a change in the U-plan.
The pre-tactical phase ends when the flight is activated.
2.2.4 Aviation: the tactical phase

The tactical phase starts when the U-plan is successfully activated. The tactical phase continues until
the aircraft operator, which could be the pilot, indicates that the U-plan has ended.
2.2.4.1 Activation Request & Activation.

There is not a distinct activation service. Activation is a function of the U-plan processing service. The
UAS operator, which could be the pilot, requests the activation of an existing authorised U-plan. The
U-plan processing service makes a final check of the flight conditions and responds (promptly) either
that the U-plan is activated or that the U-plan authorisation is withdrawn.
The activation request must be made during the period specified in the U-plan. Once the planned
activation period is over, if the operation has not been activated its authorisation is withdrawn.
2.2.4.2 Commencement of tactical U-space services

U-space tactical services only operate for an active U-plan. These could include:
 Network identification, hence Tracking and Surveillance Data Exchange

 Conformance Monitoring service
 Traffic Information service
 Tactical Conflict Prediction and Tactical Conflict Resolution, if relevant
 Emergency Management
 Other monitoring services
These services all require connections to U-space. The activation will include a “logging on” process
that “creates an active flight session” which links the sources/sinks of the services (computer network)
and data with a planned operation and the aircraft operator / pilot.
2.2.4.3 Flight phases, conformance with the U-plan.

From the activation of the U-plan, the U-plan should be followed. Non-conformance with the U-plan
can occur at any time. The flight phases depend on the operation type, for example an air taxi or a
delivery with a small UAS and could include:
Page 27
(EDITION 4)
 Pre-flight operations that follow activation, for example confirmation that network
identification is operating
 Taxi-out phase:
o Pushback / towing if appropriate, involving ground handling processes and equipment.

o Taxiing, if needed.
 Departure phase:
o (probably) a check that everyone / everything is clear

o Take-off.
o Initial climb. The initial part of the flight may have the aim of “getting clear of the take-
off site.” There may be restrictions on the procedure due to obstacles, noise
abatement or ground risk.
 En-route. Once the aircraft is clear of the departure region, it can achieve the purpose of the
flight, for example go to the destination.
 Approach. Safety / noise / environmental concerns may dictate that there is a particular way
this type of aircraft needs to descend into the landing site in the current weather conditions.
The approach phase involves getting the aircraft into position to start such a descent and
then descending as required.
 Landing including final descent, flaring, touch down. These are likely to follow a check that
everyone / everything is clear.
 Taxi in, if needed, meaning ground movement under aircraft power, possibly followed by
towing in, if needed, meaning ground movement by means of ground handling equipment.
Then parking.
Other events may occur depending on the nature of the operation. The operation should follow its
plan.
The en-route section of the flight may be planned in such a way as to optimise a number of factors
such as cost, ground risk, noise abatement and/or airspace limits – for example the flight may be
constrained to remain within some height band relative to the ground immediately below. As a result
of these optimisations, the flight path of an urban air mobility may not resemble the “straight and
level” flight familiar in stratospheric flight.
The tactical phase can be viewed as a continuous sequence of challenges that the aircraft must
overcome in order to follow the plan, for example completing checks in the planned time, or correcting
course deviations due to gusts of wind. The plan represents a best guess as to what the prevailing
conditions will be and how well the aircraft can meet these challenges. The aircraft follows the plan
within agreed limits, or in control-system terms, acceptable error.
As shown in Figure 10 and Figure 11, the U-plan is a series of volumes around which there may be
deviation thresholds. If the flight does not follow the U-plan then it is initially “non-conforming” and is
expected to make every effort to return to the U-plan. If the non-conformance persists beyond 5% of
the time in the volume or exceeds the deviation thresholds then the aircraft is in a contingency
situation and should invoke a/the previously filed contingency plan.
2.2.4.4 Non-conformance with the U-plan

There are many reasons that an aircraft might not follow the U-plan.
Page 28
(EDITION 4)
 Failure:
o The plan is unachievable. This aircraft just can’t fly that fast, that far, that high, that
precisely.
o The conditions have changed. For example, the wind is stronger than was allowed for
in the plan.
o Something has happened to or gone wrong with the aircraft. For example, a rotor is
out of balance.
o Something has gone wrong with the communications, navigation or surveillance. The
aircraft is unable to communicate its position, does not know its position, does not
know where it is supposed to go, …
 ‘External’ event:
o A manoeuvre associated with Tactical conflict resolution is unusually large and

requires the aircraft to fly outside the planned volume(s), for example a crewed or
other aircraft is in an emergency close to the aircraft and avoiding action must be
taken.
o The airspace has been “reconfigured dynamically.” The aircraft has to evacuate the
region where it is currently.
In each case a previously announced contingency plan should be followed. These plans may be
preprogramed, for example fly directly to a predetermined location, or manually flown by the remote
pilot.
2.2.4.5 Contingencies
Contingencies are dealt with in more detail in the Annex “CORUS XUAM - D3.1 - Advanced U-space
Definition”, this is an overview.
The UAS operator should be cognisant of the contingency plans the aircraft will follow autonomously
and their probable triggers. Possible triggers for contingency plans may include lost C2 link, low
battery, loss of GNSS, mechanical or electrical failure. Many autonomous contingency plans are
possible. Examples of contingency plans might include “fly straight back to take-off point,” or “fly to
and land at an alternative landing site,” or “continue to follow the plan to the destination,” or “switch
off motors and deploy parachute” or many others.
The UAS operator should also prepare contingency plans for hazards that risk assessment indicates are
worthy of anticipating. Examples might include planning alternate landings or fitting a parachute.
When an aircraft is following a contingency plan, it may no longer be “strategically deconflicted.” In

that case all conflicts must be dealt with tactically. An example of when this is likely to occur is dynamic
airspace reconfiguration which requires the aircraft to exit an airspace.
Contingency plan activation in some cases lead to a state that can be deconflicted by updating the U-
plan during the active phase.
2.2.4.6 Updates to the U-plan during the active phase.

If the USSP’s agreement with the UAS operator allows it, then the UAS operator may update the U-
plan during flight. The following guidelines seem likely:
Page 29
(EDITION 4)
 A flight which is following contingency plan, particularly in the case of a change, above, may
be given priority over non-active flights in the strategic deconfliction, including those that
have passed RTTA
 A flight which is active but not currently in contingency may not considered a priority, but
rather a “late filer.” Rejection of the change would imply that the current U-plan remains
authorised.
2.2.4.7 Termination of the flight & Ending of tactical U-space services

There is not a distinct flight termination service. The aircraft operator, which could be the pilot, signals
to the U-plan processing service that the operation has ended. This triggers the ending of tactical U-
space services that are running.
2.2.5 Post flight

The U-plan and records of how it was flown should be archived by the “legal recording service” but
remain available for authorised use for as long as necessary. Uses include:
 Accident and incident investigation

 Criminal investigation other than aviation accident/incident
 Assessment of performance by or for the competent authority of UAS, UAS operators, U-
space design, U-space services, social impact and so on
 Research.
2.3 Airspace
This section describes different aspects of the airspace of interest to U-space.
2.3.1 Urban airspace

“Urban Airspace” is not currently much used by aviation for reasons of risk and nuisance, especially
noise. The general expectation is that urban air mobility will make use of airspace which is currently
mostly unused.
2.3.2 ICAO airspace classes

ICAO Annex 11 [14] Section 2.6 defines seven airspace classes, A to G, in terms of VFR and IFR flight
rules, and the services offered. Only subsets of flight rules {VFR, Special VFR, IFR} are permitted in
classes A to G. ICAO Annex 2 [13] defines Prohibited and Restricted areas as being something other
than classes A to G. Restricted areas can enable air use which is neither IFR nor VFR.
2.3.3 Geographic Zones and U-space Airspace

EU regulation 2019/947 [4] Article 15 allows for the creation of Geographical Zones (Geo-Zones) for
the management of UAS traffic. EU regulations 2021/664 [8] and 2021/665 [9] allow for a Geographic
Zone to be designated as a U-space airspace. U-space airspaces are, in effect, Restricted Areas in ICAO
terms. ICAO Annex 2 defines a Restricted area as “An airspace of defined dimensions, above the land
areas or territorial waters of a State, within which the flight of aircraft is restricted in accordance with
certain specified conditions.” For U-space airspaces the specified conditions are:
Page 30
(EDITION 4)
 UAS operations must consume U-space services, following EU regulation 2021/664 [8]
 Crewed aircraft must be electronically conspicuous, as EU regulation 2021/666 [10]
 U-space airspaces have associated with them technical and operational requirements in
terms of equipment fit, performance and operating methods.
These technical and operational requirements are determined for the airspace in function of the
permitted level of traffic and the risks expected. 2021/664,5,6 [8] are the initial U-space regulations
corresponding to the Initial era of U-space, section 1.4.3. These regulations do not include a Tactical
conflict resolution service.
As already noted, U-space airspace is not any of the ICAO airspace classes A to G. Flight need not follow
IFR or VFR.
EU regulation 2019/947 [4] requires that information on the Geographical Zones be made publicly
available, in an electronic format. That requirement is the basis of two services in this ConOps, Drone
Aeronautical Information Management, section 3.4.1, in which the Geographical Zone definitions are
collected from the different authorities that are permitted to create Geographical Zones, and Geo-
awareness, in section 3.4.2 in which the combined Geographical Zone information is published.
The acceptable means of compliance and guidance material for EU regulation 2019/947 [6] further
requires that, “The Member States should publish information on UAS geographical zones that are
relevant to crewed aircraft operations in Section ENR 5.1 ‘Prohibited, restricted and danger areas’ of
the AIP.” Hence the U-space airspaces will be published for crewed aviation as restricted areas.
2.3.4 Geodetic Altitude Mandatory Zones

The ICARUS project [28] proposes a common altitude reference system. Within zones where there is a
risk of altitude confusion, the competent authority may declare a “Geodetic Altitude Mandatory Zone.”
In a GAMZ, when aircraft exchange altitude information, it shall be exchanged in the form of geodetic
height, that is referenced to the WGS84 ellipsoid. To support this expression, a vertical conversion
series is foreseen, see 3.19 GAMZ-ness is independent of other properties of the airspace.
It is expected that GAMZ-ness is likely to be one of the technical and operational requirements
associated with a U-space Airspace, as mentioned in section 2.3.3
In total, ICARUS proposes four services, some of which map onto services identified in Edition 3 of the
ConOps [1].
ICARUS ConOps Edition 4 remarks

Vertical conversion Vertical Conversion Service, 3.19 Converts between GNSS and
service Barometric altitudes.
GNSS service Navigation Infrastructure Monitoring, 3.15.1 Navigation Infrastructure
Monitoring Service has more
general scope.
Real-time geographic Vertical Alert and Information Service, 3.20 Scope of Icarus service is split
information service Geographical Information Service, 3.9 between three services in this
ConOps.
Geo-awareness, 3.4.2
Page 31
(EDITION 4)
Vertical Alert Service Monitoring, 3.10 The provision of height warnings

Vertical Alert and Information Service, 3.20 to pilots of crewed and uncrewed
aircraft in the ICARUS service is
distinct from Monitoring
Table 2 ICARUS services
2.3.5 X, Y, Z volumes
UAS pilots range in their experience and training. The least training requirements in EU IR 2019/974
[4] are for pilots to fly A1 operations with a class C0 aircraft, as per EU DR 2019/945 [5]. The pilot shall
be “familiarised with the user's manual provided by the manufacturer of the UAS.” Addressing UAS
pilot needs, especially those with little training, the lower airspace can be described as one three types
of volume: X, Y or Z. These volumes describe the conflict resolution services offered in the volume.
Volume Conflict resolution service

X None. Avoiding conflict is the responsibility of Pilot / Operator, unassisted by U-space
Y Pre-flight (“strategic”) conflict resolution
Z Pre-flight (“strategic”) conflict resolution, and
In-flight (“tactical”) conflict resolution
Table 3 X Y Z Volumes
In X volumes, the operation requires no U-plan. The pilot / operator / UAS should be up to date with
the Geo-awareness data to be confident that the flight is completely within X. Permission may be
needed to fly and there may be requirements for equipment fit.
For Y and Z an approved U-plan is required. In both Y and Z the pilot / UAS should be connected to U-
space during flight to allow sending of position information and receipt of warnings, traffic information
and so on.
In terms of the U-space regulatory framework [8], [9], [10] , as introduced in section 2.3.3:
 An X Volume is not a U-space airspace.

 A Y Volume is either a U-space Airspace or a Geo-Zone.
 A Z Volume is beyond the current EU regulation but extends the idea of U-space Airspace to
allow higher traffic density.
The descriptions below are for a flight wholly in that airspace. For flights penetrating multiple
airspaces, the conditions for each must be applied for that portion of the flight.
2.3.5.1 Airspace access conditions are not expressed in XYZ

Before describing XYZ, it is important to stress that these airspaces differ in the services being offered.
XYZ is not a complete description of the access conditions for the respective airspace.
 Access to an airspace may require permission from some authority.

 There may be technical or operational restrictions, for example a requirement that aircraft
must conform to or be fitted with equipment that conforms to some standard.
Page 32
(EDITION 4)
This information, if applicable, should be included in the publicly available descriptions of Geo-Zones,
including U-space airspaces. See section 3.4.
2.3.5.2 X volume
In X volumes flights need no U-plan and receive no separation service.
X is suited to VLOS flight. BVLOS requires appropriate risk assessment with no mitigations from U-
space.
2.3.5.2.1 X, Pre-flight
Before flight the UAS operator should make use of a Geo-awareness service, see 3.4.2 to
 Confirm the flight is in X

 Be informed of any restrictions that may apply such as heigh limits or required equipment
 Ensure any necessary permissions have been obtained or are obtained.
 Load geo-zones into the UAS, if appropriate
The UAS operator should in some circumstances be registered, see 3.2. The operator may make use of
other services as appropriate (or as mentioned in the SORA for the flight, if there is one), for example:
weather, see 3.8.
2.3.5.2.2 X, In flight
No “tactical” separation service is available. The UAS operator remains responsible at all times for
ensuring safe operation.
In many cases the UAS needs to be identifiable and will either have to direct remote identification, see
EU regulations 2019/947 [4] and 2019/945 [5], or make use of a network identification service, see
3.3.1.
The operator may make use of services as they are available and needed by the circumstances, for
example vertical conversion service (3.19), vertical alert and information service (3.20), emergency
management (3.12). As aircraft can fly in X without network identification or electronic conspicuity,
any traffic information service (3.14) cannot guarantee to include all other aircraft and hence may not
be offered.
2.3.5.2.3 X, Post flight

An accident and incident reporting service is available, see Section 3.13.
2.3.5.3 Y volume
The Y volume offers strategic (that is, pre-flight) deconfliction. In order to do this flight in Y volume
requires a U-plan. EU regulation 2021/664 [8] describes the “U-space airspace” which offers this.
However, the Y volumes fulfils two roles. In the edition 3 ConOps [1] these were mentioned. Because
UAS flight in a Y volume requires an approved U-plan:
 The Y volume can exist to enable flight with strategic deconfliction.

 The Y volume can exist primarily to limit access.
Hence all U-space airspace are Y volumes but not all Y volumes are U-space airspace.
Page 33
(EDITION 4)
Strategic deconfliction is the process of reducing the probability of there being a conflict to an
acceptable level by acting on the plans for the flights. One factor in this process is the level of
confidence about how precisely the plan will be followed. In the early stages of “Initial U-space
implementation” see 1.4.3, this lack of confidence is expected to result in “wide” spacing of flights.
The strategic conflict detection and resolution processes are described in sections 3.5.2.2 and 3.5.2.3
respectively.
2.3.5.3.1 Technical and Operational Characteristics of the Volume

Each U-space airspace has technical and operational requirements. These are published by the
competent authority as part of the Common Information. The authorisation of a U-plan is accompanied
by a reminder of these technical and operational requirements.
In EU regulation 2021/664 [8] and its Acceptable Means of Compliance and Guidance Material [11]
there is mention of the “terms and conditions.” The operational and technical characteristics are part
of the terms and conditions.
2.3.5.3.2 Y, Pre-flight
The UAS operator should in some circumstances be registered, see 3.1. The UAS operator should make
use of the geo-awareness service before flight, to load relevant data into the UAS, if appropriate and
to confirm that the volume is Y, see 3.4. The airspace may have particular access conditions, which will
be published, in which case permission to fly in the airspace may need to be obtained.
Every flight must have an approved U-plan, see 3.5.2. Approved U-plans do not conflict due to the
strategic conflict prediction, see 3.5.2.2, and resolution services, see 3.5.2.3.
2.3.5.3.3 Y, In flight
The U-plan shall be activated to commence flight, see 3.5.2.6
The flight shall make use of the following services unless their use is waived for the specific airspace:
 Network identification service, see 3.3.1

 Traffic Information service, see 3.14
 Emergency Management service, see 3.12
 Monitoring service, see 3.10, including Conformance Monitoring service, see 3.10.1
 Infrastructure monitoring services, see 3.15
 Vertical Alert and Information Service, see 3.20
2.3.5.3.4 Y, Post flight

The U-plan shall be ended by the operator, see 3.5.2.5. An accident and incident reporting service, see
3.13, is available. The operator may consult the digital logbook, see 3.16
2.3.5.4 Z volume
A Z volume is a volume in which there is a tactical conflict resolution service. Three versions of Z are
defined:
 Za in which Air Traffic Control manage all the traffic. Such airspaces may exist at an airport.
The expectation is that ATC will take benefit of U-space services in managing UAS.
 Zu in which U-space will provide a tactical conflict resolution service
Page 34
(EDITION 4)
 Zz in which U-space will provide a tactical conflict advisory service
Za is an existing controlled airspace. This ‘Za’ label is for the UAS community only. Za is not a U-space
airspace as described in EU regulation 2021/664. Flight of UAS in airports is increasingly common.
Zu and Zz have not been described in EU legislation at the time this is written. They are the logical
extension of Y allowing higher densities of operations.
Edition 3 of the ConOps [1] did not mention Zz and defined Zu ambiguously. In this, Edition 4 of the
ConOps, Zu has a more precise definition and Zz is new.
2.3.5.4.1 Za, Pre-flight

to confirm that the volume is Za, see 3.4.
Every flight must have an approved U-plan 3.5.2. The plan will need to be approved by ATC by means
of the procedural interface with ATC, see 3.17. That procedural interface may result in various
conditions being specified.
2.3.5.4.2 Zu & Zz, Pre-flight

to confirm that the volume is Zu or Zz, see 3.4.
Every flight must have an approved U-plan, see 3.5.2. Approved U-plans do not conflict due to the
strategic conflict prediction, see 3.5.2.2, and resolution services, see 3.5.2.3. The U-plan will be subject
to dynamic capacity management, see 3.5.2.5
Strategic conflict resolution in Zu and Zz may operate with a higher residual risk of conflict than in Y,
as there is a tactical process afterwards.
2.3.5.4.3 Za, In flight

The flight shall be activated to commence flight, see 3.5.2.6
 network identification service, see 3.2.1. Other surveillance may be mandated.

 collaborative interface with ATC, see 3.18
2.3.5.4.4 Zu, Zz, In flight

The U-plan shall be activated to commence flight, see 3.5.2.6
 Network identification service, see 3.3.1

 Tactical Conflict Prediction, see 3.6.1, and Tactical Conflict Resolution, see 3.6.2
 Traffic Information service, see 3.14
 Emergency Management service, see 3.12
 Monitoring service, see 3.10, including Conformance Monitoring service, see 3.10.1
Page 35
(EDITION 4)
 Infrastructure monitoring services, see 3.15

 Vertical Alert and Information Service, see 3.20
In Zu, the Tactical Conflict Resolution service issues instructions that the UAS must follow. In Zz the
Tactical Conflict Resolution service issues advice. Because of the different likelihood of resulting action,
the tactical conflict resolution advice in Zz may be issued earlier than would be the case for the tactical
conflict resolution instructions in Zu.
2.3.5.4.5 Za, Zu, Zz, Post flight

2.3.6 Permanent and Temporary structures

In “conventional” air traffic control, airspace structures are changed on the basis of four week periods
known as AIRAC cycles. The reader is directed to ICAO Annex 15 [56] for more information. Planned
changes are normally announced one AIRAC ahead, meaning that changes require up to 8 weeks
notice. Short term changes are announced in NOTAMs, see ICAO Annex 15. Pilots should review
NOTAMS before flight.
In EU IR 2021/664 [8], Dynamic Airspace Reconfiguration and Dynamic Airspace Restriction are
introduced. These allow reductions/restrictions of the U-space airspace with minutes of notice. The
Geo-awareness services facilitate the rapid dissemination of the information electronically.
Dynamic Airspace Reconfiguration is further examined in section 3.17.1.
2.3.7 Synthesis
The following table explains the relationship of the different U-space volumes to EU regulations and
ICAO airspace classes. Note below SVFR is a form of VFR and is usually not mentioned as a separate
flight rule.
ICAO 2019/947 2021/664 U-space Flight Remarks

class UAS U-space ConOps rules
Geographical airspace
Zone
G above No No Not U- IFR (4,5) & For U-space users such airspace
VLL, space VFR would probably be marked a Y
ABCDEF volume and any U-space U-plan
penetrating this airspace will either
not be approved or will be subject
to conditions or warnings.
ABCDE No No Za IFR (4) Za if and only if the flight’s entry
& VFR into the airspace is enabled by a U-
space planning process that
includes ATC approval.
Page 36
(EDITION 4)
ICAO 2019/947 2021/664 U-space Flight Remarks

class UAS U-space ConOps rules
Zone
G VLL No No X VFR & IFR Conditions apply
(5) UAS fly below VFR limits. UAS fly in
a way that limits the risk to VFR and
IFR traffic
Restricted Yes (1) No X VFR Special conditions may apply:
Area Geo-zones can exist to manage
which UAS flights are allowed
and/or how they operate. See (2)
Restricted Yes (1) No Y Dependent Potentially a no fly zone for UAS
Area on the
restriction
Restricted Yes (1) Yes Y See 6 & 7, No tactical separation service
Area below supplied by U-space
Restricted Yes (1) Yes (3) Zu UFR Tactical separation service supplied
Area See 6, by U-space.
below
Restricted Yes (1) Yes (3) Zz See 6 & 8, Tactical separation advice supplied
Area below by U-space
Table 4: Equating subdivisions of the airspace: Volumes, Geographic Zones and Airspace classes
Notes:
1) 2019/947 [4] article 15 does not state that geographic zones are restricted areas. U-space airspaces
created as a result of 2021/664, 665, 666 are expected to be restricted areas due to the obligation on
crewed traffic to be conspicuous.
2) 2019/947 [4] article 15 allows Geographical Zones to exist for different reasons. Restrictions may be
placed on flights, or exemptions made.
3) 2021/664 [8] & [11] describes something approximating Y. Zu and Zz are considered as extending Y
4) IFR only in A.
5) IFR unlikely in G in many countries
6) UFR, a possible new flight rule, is defined here as “how to fly in Zu”. In Zu there is U-space tactical
conflict resolution, hence UFR will include obeying U-space tactical conflict resolution. It is expected
that Zu only supports UFR and all aircraft in Zu must follow UFR. UFR is discussed in section 4.2.
7) An airspace which is a U-space airspace according to EU 2021/664 [8] & [11], most closely matching
the U-space ConOps volume Y, is one aimed at supporting BVLOS operations by means of strategic
conflict resolution. Hence flights in the airspace do not follow UFR as flown in Zu, as tactical support is
limited to traffic information. EU 2021/664 foresees entry of VFR or IFR traffic into U-space airspace as
Page 37
(EDITION 4)
being an emergency procedure in which U-space traffic “take appropriate measures.” Hence it should
be noted IFR and VFR traffic are not catered for in Y volumes.
8) The flight rule in Zz is not UFR as flown in Zu.
2.3.8 Structure
Y and Z volumes, sometimes known as U-space airspaces, can have attached to them different
requirements (equipment fit, procedures, performance) for flight. EU regulation 2021/664 [8] also
mentions that U-space service providers may be authorised for some U-space airspaces but not others.
The AMU-LED project [45] proposed a structure with two layers with different levels of performance
above and below. The arrangement would allow (higher risk) passenger carrying operations in the
upper region to be provided services by suitably qualified service providers without requiring all traffic
to operate at this higher level of performance and resulting cost.
A similar proposal is to create corridors for higher performance traffic.
2.4 Ground Infrastructure for UAM

The term vertiport is used here to mean an aerodrome of Urban Air Mobility. Two forms are presented,
first the vertiport for passenger operations and then the vertiport for cargo operations by small UAS.
The term vertiport is used in a general sense in this document. The content of this section builds on
the state of the art in 2022. R&D, commercial proposals, standards and regulations for vertiports are
evolving rapidly.
Some sources propose a terminology that distinguishes between larger, well equipped vertiports and
smaller less equipped. The term Vertistop has occasionally been used in this context. Vertistop is a
registered trademark of Difass International SPA.
2.4.1 The Vertiport predominantly for passenger operations

2.4.1.1 Overview
Vertiports are landing and take-off sites for passenger carrying VTOLs and will be equipped with a
number of facilities, including charging facilities for electrically operated vertical take-off and landing
(eVTOL) aircraft as well as passenger boarding, disembarkation, and waiting areas. Non passenger
carrying drones, for example for cargo operations, are expected to operate from other sites since
decentral locations are preferable for such operations and infrastructure and safety requirements
differ, though they may occasionally visit “passenger” vertiports.
A number of companies are presently developing vertiport concepts and infrastructure and these are
largely inspired by heliports, including the touchdown and lift-off (TLOF) area, the final approach and
take-off (FATO) area, the safety area around the FATO and stands as applicable. Additionally, while the
aircraft is moved between TLOF and stand without depending on its power and wheels, ground
movement equipment (GME) needs to be accommodated in the vertiports. GME serves as towing
equipment in the form of a wheeled vehicle to move the aircraft horizontally on the vertiport surface,
which can be either manually operated or remotely controlled or supervised by a member of the
technical ground crew.
Page 38
(EDITION 4)
Vertiports may be located in any area, but realistically predominantly in urban areas and close to
airports, permitting air taxi operations within cities and between cities and airports. An important
consideration and requirement is the integration into the existing airspace; this concerns the airspace
category in and around the area the vertiport is located and the safety of drone operations to and from
the vertiport which may need to be separated or segregated from piloted aircraft. Operations at
vertiports will be managed through U-space. The management; sequence building, landing clearances,
hold instructions, taxi clearances, etc, will be mostly without human intervention.
2.4.1.2 Aircraft
Whilst a number of aircraft types will undoubtedly be used in urban air mobility, we make the
assumption that vertiports will be used by and designed for eVTOL and hybrid VTOL aircraft. Noise and
local air quality considerations as well as the non-availability of landing sites for aircraft taking off in
any other way than vertically have informed this assumption. Since eVTOL aircraft require charging
facilities and have very limited endurance (so that holdings are not a desirable feature) this has a
number of repercussions for the vertiport layout.
2.4.1.3 Vertiport facilities

The present design concept of vertiports, which is based on the EASA Guidance Material for Design of
VFR vertiports [39] and largely inspired by current standards and recommendations for heliport design
(e.g., ICAO Annex 14, Volume 2), provides the following facilities:
 Touchdown and Lift-off (TLOF) area(s);

 Final Approach and Take-off (FATO) area(s);
 Safety Area(s) around the FATO(s);
 Stands
 Facilities for re-energizing of aircraft batteries;
 Areas for taxiing (under own power) and ground movement (not under own power) of VTOL
aircraft between the FATO and TLOF; and
 Passenger embarking, disembarking, and waiting areas.
For capacity and contingency reasons, it is desirable to provide more than one TLOF/FATO since the
TLOF/FATO will be occupied by the incoming or outgoing flight for a specified period of time. FATO and
safety area are always placed together within vertiport environment, but TLOF and stand can be placed
elsewhere. Different options are expressed in Figure 5 for:
 Air taxiing, with TLOF being at the same place as the stand, where aircraft moves hovering over
the vertiport surface on its own power, i.e. the aircraft does not lift-off or touch down at the
FATO.
 Ground movement, where TLOF and FATO being at the same place with a stand in a different
location and where ground movement of the aircraft is needed e.g., for longer distances. A
VTOL aircraft can be moved under own power or by a vertiport movement system.
Page 39
(EDITION 4)
Figure 5: Air taxiing and Ground movement vertiport configuration
2.4.1.4 Vertiport access and operations

Operations are performed under the authority of the vertiport operator. Whilst detailed
responsibilities are yet to be defined and agreed, the vertiport operator can be expected to
 specify the minimum operational and equipage requirements for aircraft using the vertiport
and ensuring compliance,
 indicate the operational status of the vertiport and the availability of landing / departure /
parking capacity,
 provide information and services, e.g. provide ground obstacle maps and/or
landing/departure routes, potentially also local meteorological information.
Vertiports will probably have defined procedures including arrival, departure, holding, diversion,
ground operations (charging, ground movement).
Aircraft in the U-space surrounding the vertiport will be under responsibility of one or various U-space
service providers. The presently favoured view is that the USSP(s) also authorize landing and take-off
operations at the vertiport, based on the availability of slots and infrastructure indicated by the
vertiport operator. Note that different concepts are imaginable, for example a vertiport authority
which clears aircraft for take-off and landing similarly to tower control. Yet the interface with USSP(s)
in the surrounding airspace in terms of control authority would become complex to manage. (Due to
a number of possible setups and solutions as presented above, the concept of traffic management at
the vertiport should be further investigated and could be subject to following research projects.)
When considering vertiports for passenger VTOL aircraft operations, EASA is distinguishing different
kinds of vertiports (see Figure 6: Vertiport Classification from Operations Perspective [23]).
As per EASA SC VTOL, VTOL aircraft certified in the category enhanced, need to satisfy the requirement
of and hence be able to continue to the original intended destination or a suitable alternate vertiport
after a critical failure for performance [24]. This enhanced category of VTOLs covers those aircraft
which will carry passenger on-board.
Page 40
(EDITION 4)
Figure 6: Vertiport Classification from Operations Perspective [23]
The grey circles are normal aerodromes, heliports or vertiports, with the full range of facilities and
services required for the operation, so that the VTOL aircraft can take-off from. The blue circles are
aerodromes for continued safe flight and landing (CSFL) which may be heliports or vertiports, that only
have a minimum set of facilities and services (to be specified), from which the VTOLs may not be able
to take off.
 Take off and destination vertiport: Each flight originates from a take-off vertiport and is
planned and conducted to the destination vertiport.
 Alternate vertiport: This can be either an alternate take-off vertiport, where the VTOL
aircraft would be able to land should this become necessary shortly after take-off, or an
alternate en-route vertiport, where the VTOL aircraft would be able to land in the event that
a diversion becomes necessary with normal aircraft performance while en-route, or an
alternate destination vertiport, where the VTOL aircraft would be able to land should it
become either impossible or inadvisable to land at the intended destination vertiport.
 Alternate en-route vertiports for CSFL: The alternate en-route vertiport for CSFL complies with
the same minimum design requirements as the alternate en-route vertiport. But it only has to
fulfil a minimum set of services with respect to the aircraft and CSFL operations.
 Emergency landing site is excluded from these considerations as emergency landing may be
carried out at any possible location, not necessarily at an aerodrome/operating site.
The procedures to manage the availability of alternate vertiports are yet to be defined and will be
informed by the, presently unknown, occurrence rates of technical failures and other causes lead to
the need for alternate vertiports. The presently favoured view is that vertiports will not nominally
operate at maximum capacity and thus leave some availability to accommodate unforeseen operations
on an ad-hoc basis.
Page 41
(EDITION 4)
2.4.1.5 Vertiport location, airspace

Whilst vertiports with lower traffic demand may not have a designated area of airspace
assigned/attached, we assume that the majority of vertiports is surrounded by a Vertiport Traffic Zone
(V-TZ).
Flight planning and authorisation are performed by the USSP providing service to the UAS operator
wishing to land at the vertiports. This includes booking of vertiport access. Details have yet to be
defined but it may well be that InterUSS [19] will be used not only for booking access to the airspace
but also to the vertiport resources (see ASTM standard F3548-21 [18]).
Vertiport access booking is part of the U-Plan but does not authorise the aircraft to take-off or land.
For this, the take-off/landing clearance is required which will be obtained shortly prior to the actual
operations. The details of clearance provision in U-space have yet to be defined. Experimental work
shows that stepwise clearances, with clearance limits similar to traditional aviation, seem to have a
number of advantages when compared to clearing the whole mission at take-off. These advantages
include better accommodation of uncertainty, capacity aspects, lost-link procedures, and other
contingencies. EASA’s Prototype Technical Design Specifications for Vertiports [53] echoes this view.
For the initial concept and use cases, we assume vertiports to be located in airspace surrounded by
class G (uncontrolled) airspace. This would cover some vertiports located in urban areas but exclude
vertiports in the vicinity of airports which are surrounded by class D airspace. In an evolution vertiports
could be imagined in the premises or the vicinity of an airport (i.e., airspace class C or D). In this case,
air taxi operations will require some form of interaction with ATM, which may be through the U-space
service Collaborative interface with ATC, see 3.18. VTOL aircraft need then to be clearly displayed for
ATC on the HMI for ATCOs situational awareness. This integration with ATM needs to be further
researched.
2.4.2 Vertiports predominantly for cargo operations

Much of the description of the passenger vertiport applies to vertiports for cargo flights, but there are
some simplifications other than the absence of passengers.
2.4.2.1 Optimisation
There may be cases where a vertiport is used by only one aircraft operator or by a small number of
aircraft operators working in close cooperation with the vertiport operator. Examples might include
“business to customer delivery” or if a number of hospitals/medical facilities have set up an air delivery
service between themselves. The close linkage between the vertiport operator and the aircraft
operator(s) may influence the way flights are scheduled at the vertiport, allowing emphasis of
“network” optimisation.
‘General’ use of vertiport by aircraft operators without shared business interests diminishes the
opportunities for such over-arching optimisations. We can expect each aircraft operator to optimise
their own flights with the vertiport operator optimising vertiport operations.
2.4.2.2 Location
Two modes of cargo flight can be identified linked to the type of operation which impact vertiport
location.
Page 42
(EDITION 4)
 The flight takes off and lands with the cargo on board. The cargo vertiport is at a source/sink
of cargo, such as a warehouse, logistics centre, “fulfilment centre” or “dark store.” The
location of the vertiport is determined by the location of the source/sink of cargo.
 The cargo is collected and then delivered during the flight. Aircraft leave and return to the
vertiport without cargo. The vertiport is only concerned with flight operations. The vertiport
position can be optimised for flight efficiency, safety and social acceptance
2.4.3 The impacts of vertiport in U-space

Vertiports are often going to be a limited resource and hence will constrain flight planning, both for
normal operations and in contingency planning. A service will be needed to share the current and
planned availability. Other services will need to take this availability into account.
Processes at the vertiport may inject uncertainty into operations. For example, a flight may take off
when the FATO is clear, but any number of improbable events can result in the FATO not being clear
at the planned take-off time and hence the take-off is delayed.
2.5 U-space infrastructure and the role of a mandated actor

Edition 3 of the U-space ConOps [1] identified the motivations for including a state mandated actor in
U-space. These were to provide services that are considered unlikely to be provided through market
means, and to meet the unique needs of other state mandated actors such as the security services.
This section argues that a state mandated actor may also fill a role providing U-space infrastructure.
2.5.1 The Common Information Service of EU regulation 2021/664

The reader is directed to the European “Drone regulations” EU IR 2019/947 [4] and EU Delegated
Regulation (DR) 2019/945 [5] and their associated Acceptable Means of Compliance and Guidance
Material [6],[7] as well as the “U-space regulations” EU IR 2021/664 [8], 2021/665 [9] and 2021/666
[10] as well as the associated Acceptable Means of Compliance and Guidance Material [11]
EU IR 2019/947 article 15 allows for the designation of UAS Geographical Zones and requires that
information on them be made available, electronically.
EU IR 2021/664 defines a kind of UAS Geographical Zone called a U-space Airspace and among other
things, the regulation lists those services that must be provided with in it. One of these is the Common
Information Service and it consists of (paraphrasing)
 The geographic boundaries of the U-space airspace, horizontally and vertically.

 The technical capabilities and performance required for aircraft allowed to fly there as well
as any required flight procedures.
 The list of U-space Service Providers certified to provide services in that U-space airspace
and any limitations. The terms and conditions of those service providers
 Associated geography: any adjacent U-space airspaces. Any UAS geographical zones
“relevant” to this U-space airspace.
 Any restrictions limiting the volume available for UAS flight.
 The result of any Dynamic Airspace Restriction
 EU IR 2021/665 [9] adds traffic information regarding crewed aircraft known to ATC to the
definition of the Common Information Service.
Page 43
(EDITION 4)
Common Information includes the information distributed by the Geo-awareness service, see section
3.4.2. Common Information should be supplied to anyone that asks for it while Geo-awareness is
supplied only as part of the relationship between a U-space Service Provider and a UAS operator.
According to EU IR 2021/664 article 5 (6) “Member States may designate a single common information
service provider to supply the common information services on an exclusive basis in all or some of the
U-space airspaces under their responsibility.”
The situation in U-space airspaces where there is no single CISP is outlined in the acceptable means of
compliance [11] in GM-1 to Article 5, part d, which says “In the absence of a single CIS provider,
common information is directly exchanged between the relevant operational stakeholders in a
distributed communication architecture, whereby each data provider communicates directly with
another USSP for sharing information. Each USSP needs to communicate with other data providers. A
clear allocation of common information elements between Member States, ATS providers and USSPs
would allow data users to find target data quickly and efficiently. In the absence of a single CIS provider,
there is no need for additional certification; the provision of common information elements by ATS
providers and USSPs will be covered by their respective certificate and the provisions of Regulation
(EU) 2021/664 and Regulation (EU) 2021/665 amending Regulation (EU) 2017/373.”
Hence the options are one CISP or none. Which is in effect may differ per U-space airspace in a given
state.
2.5.2 The Infrastructure of U-space

The U-space regulations 2021/664 [8], 2021/665 [9] and 2021/666 [10] indicate and imply that there
will be a number of data flows between different participants in U-space. Notably:
1. The Common Information includes the geographic zones and U-space airspaces. The
geographic zones are created, updated and removed by authorised actors including Air
Traffic Control organisations, including through the Aeronautical Information or by means
of NOTAMS. U-space airspaces can be subject to change following operational decisions
by Air Traffic Control in the “dynamic airspace reconfiguration” process.
2. The Traffic Information service requires a service provider to provide information about
all traffic in the vicinity of any UAS to which it is providing traffic information. Hence the
USSP needs access to the tracks of flights known to other USSP. Traffic information can
include tracks of aircraft derived from Air Traffic Control surveillance. Hence there needs
to be a flow of relevant ATC surveillance data to USSP.
3. The Conformance Monitoring Service requires that other airspace users may be warned in
some conditions. That may include warning Air Traffic Control.
4. The Flight Authorisation Request service should take into account crewed aircraft in a state
of emergency, information that may come from ATC.
5. The Flight Authorisation Request service needs to be able to safely deconflict flight
authorisation requests with those of other USSPs.
These data exchanges should meet a number of criteria. They should be timely as they are generally
used during flight operations. They should be safe and secure; there should be no doubt as to the
source of the information and the consumer, each should be known to and trusted by the other. The
data exchange mechanisms should not expose any participants to significant risk of cyber attack. The
data exchange mechanisms should be reliable.
Page 44
(EDITION 4)
The U-space regulations [8],[9],[10] enable normal operations. Nothing is said about the data exchange
requirements stemming from the needs of the competent authority in monitoring and auditing the
correct functioning of U-space, or when investigating accidents and incidents. Similarly the needs of
security services may imply additional actors with their own data exchange needs.
2.5.2.1 Discovery and Synchronisation Service

From the list above, items 2 and 3 are covered by ASTM standard F3411 [44] and items 4 and 5 by
ASTM standard F3548 [18]. Neither standard is currently mandated in Europe but both are acceptable
means of compliance. Both rely on the same mechanism, the Discovery and Synchronisation Service,
or DSS.
The basic mechanism of the DSS can be explained thus
 At least one trusted actor runs an instance of the DSS. It is foreseen that more than one will
run and that the different instances will synchronise between themselves. In the reference
implementation, the InterUSS [43], this is done using the Cockroach database which
implements the “Raft Consensus Algorithm” 6
 The DSS stores a four dimensional map of the airspace in the form of a grid of 4D boxes.
 Participants in U-space access the DSS and express an interest in collections (one or more)
of these 4D boxes. Their interest is noted within the DSS.
 When another participant expresses an interest in a 4D box, it learns how to contact the
other(s) interested in the same box.
 Direct bilateral negotiation is then expected between the participants.
For traffic information the relationship between participants is expected to be a publish-subscribe

idiom. For flight deconfliction in U-space according to 2021/664 first to file has priority hence there is
in effect a system of reservation. The standard F3548 foresees a bilateral negotiation.
The key question is who implements the DSS. It may occur that at least one instance should be created
at the mandate of the competent authority, because with no DSS, the conflict detection of F3548 will
not function. Other DSS may be operated by USSP or other participants in the system, however a USSP
is only really interested in a particular U-space airspace if a flight concerning that USSP is planned or is
operating in that U-space airspace. A competent authority mandated DSS instance may be considered
to be part of the duties of the Common Information Service Provider.
2.5.2.2 Other “backbone” functions of U-space

There are other services needed to enable the correct functioning of U-space. Many can be
implemented as replicated synchronised services. Any state could rely on these services being
provided by one or more participants in U-space or they could mandate an instance exists. Such a
mandated instance might be considered part of the duties of the Common Information Service
Provider if it exists.
6
see https://thesecretlivesofdata.com/raft/
Page 45
(EDITION 4)
2.5.2.2.1 Trust
Since 2019 ICAO has been working on the Trust Framework7 and this will make use of “Public Key
Infrastructure” to identify participants. This requires a trusted, reliable, secure “certificate directory. ”
2.5.2.2.2 Swim Registry

There needs to be a registry of SWIM services. This is closely linked to the Common Information
described in the U-space Regulation which requires publication of the certified USSP. Currently a
European registry exists8 but we may see competent authorities wanting to operate a national registry
for service providers that are certified to operate in their country.
2.5.2.3 Accident and incident investigation, auditing

The Legal recording service 3.11 is absent from the U-space regulations [8]. Instead, there is an
obligation for service providers to log inputs, outputs and other significant information. The regulation
doesn’t mention how this data is subsequently obtained by the competent authority. One very likely
mechanism is that the information is requested and delivered electronically. The competent authority
may operate its own system to collect this data or may delegate the activity to a trusted actor.
2.5.2.4 Exceptional conditions, status and state messaging, contingencies

EU regulation 2021/664 article 10(6) [8] requires that USSP make “proper arrangements” to resolve
conflicts. The Guidance Material [11] to the regulation mentions ASTM F5348.
These arrangements should be robust. Due to scheduled or unscheduled events, service providers
involved in U-space may at times go off-line or be suffering from degraded performance. Such changes
to the network will probably need to be signalled to the other relevant participants in U-space, for
example through the SWIM registry. There will likely be contingency procedures associate with some
of these state changes, some of which may require “special permission” for example, if a USSP A has
an arrangement that USSP B will takeover active flights when A fails, there would be a need to revise
every entry in the DSS relating to A, changing it to B. Such a change might not “normally” be authorised
and may require an escalation process to a trusted actor.
As different contingency scenarios are identified, a central trusted actor may be selected to have a
definitive role in some situations where safety would otherwise be difficult to demonstrate.
7
see https://www.icao.int/Meetings/DRONEENABLE2/Documents/Presentations/1-5-1%20Voss.pdf
8
https://eur-registry.swim.aero/home
Page 46
(EDITION 4)
3 U-space services
Identification and Airspace Mission Conflict Emergency Environmental Interface with
Monitoring
Tracking Management Management Management Management data ATC
Drone Strategic Procedural

Aeronautical Flight Emergency Conformance Weather
Registration Conflict interface with
Information Authorisation Management Monitoring Information
Detection ATC
Management
Strategic Incident / Geospatial Collaborative

Network Common U-plan Traffic
Conflict Accident information interface with
Identification Information processing Information
Resolution reporting service ATC
Tactical
Dynamic Citizen
Surveillance Tactical Conflict Vertical Alert & Population Operational
Geo-awareness Capacity Reporting
Data Exchange Detection Info density map Message Info
Management service
Exch
Geofence `Navigation Electromagneti

Vertiport Tactical Conflict
Tracking Information Infrastructure c interference
Availability Resolution
Exchange Monitoring information
Communication Navigation
Vertical
Infrastructure Coverage
Conversion
Monitoring information
Communication
Legal Recording Coverage
information
Risk Analysis
Digital Logbook
Assistance
Figure 7 U-space services
Geo-awareness is a U1 service whose functions are increased in U2.
3.1 Introduction
3.1.1 Definition of “U-space service”
In everyday English a service is something done by somebody (or some thing) for someone else. The
term has many more specific meanings in particular fields. This ConOps, like the previous editions, is
intended to describe how U-space works; in this document the term “service” is used quite broadly
and includes many functions, of varying importance.
The services in this ConOps, Edition 4, are very consistent with those in Edition 3 [1]. The range and
granularity of the services is intentional, as in Edition 3, to explain how U-space works. In contrast, EU
IR 2021/664 [8] describes the minimal set of services that it regulates. These EU IR 2021/664 services
are examined in section 3.21.
In computing the term “service” often refers to an information (or state) exchange; some of the
services described here are much more complex than one data exchange; and some services described
here may be considered by some readers as being parts of other services, or as merely data used in
various processes. That view can be seen in the work done by the GOF2 [46] and AURA [47] projects.
Table 7 proposes a mapping from the regulation to the list of services here and to those referred to in
previous editions of the ConOps as well as an indication of hierarchy, if any.
While using the term service in quite a general way, this document follows the conventions of “use
cases” in that services are initiated by the person (or system) to which they deliver a result. For
Page 47
(EDITION 4)
example this document would describe a user might subscribing to a warning service, rather than a
describing a service which (spontaneously) warns people.
3.1.2 Structure of this section

The headings in Figure 7 are merely for grouping and are not indicative of a hierarchy. The services of
Figure 7 are described in this section in the order they are shown in Figure 7. Section 3.21 concludes
with a comparison of Edition 3 and Edition 4 terminology as well as a comparison with the EU
regulations.
3.2 Registration
EU regulation 2019/947 [4] article 14 obliges the state to register operators of most classes of UAS and
that some UAS. Hence there needs to be a state appointed registrar who maintains a registry.
EU 2019/947 [4] article 14 lists what information is expected in the registry. The registry should
generate unique registration numbers associated with registry entries. The registry should form part
of a multi-national network which is coordinated to ensure registration numbers are unique.
Registry entries will need to be able to be created, read, updated and deleted. There will need to be
search functions. Some data consistency rules will need to be enforced, such as avoiding multiple
registrations of the same information. There will need to be agreed processes to determine who is
permitted to query and change the contents of the registry. Registration information may also change
with time (e.g. lapse) in some cases. There will need to be means to carry out less frequent processes
such as the registrar removing or changing a record following a court order.
The U-space Blueprint [2] and Roadmap [3] mention an ‘e-registration’ service to emphasise the digital
implementation of the registry.
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/check/remove their own
data or (when permitted) query the contents of the registry. The Registry will also need to be
connected to other systems so as to validate names of people, businesses, addresses and other
information given as inputs. The registry will probably need to be able to take part in multi factor
authentication and support processes for “forgotten password” and similar to an appropriate degree
of security, both of which may require that messages or emails can be sent.
The registrations (the contents of the registry) will be queried by authorised officials (for example law
enforcement) in combination with the Network Identification service in order to find the details of an
aircraft which may be currently airborne. Hence the registry implementation must be capable of rapid
response. The multi-national network of registries should be interconnected to allow network
identification queries to function in any collaborating state for any registration known in any
collaborating state.
Registration Assistance was identified as a U-space service in the U-space ConOps edition 3 [1]. This
was foreseen as a service that might support something like a legal requirement for businesses selling
UAS to ensure that the owners are registered. Services may be offered to assist routine registrations,
presenting a user interface that is simplified and/or partly filled in with standard information.
Descriptions of this kind of “helper” are no longer included in the ConOps but are left to the
imagination and ingenuity of the reader.
Page 48
(EDITION 4)
3.3 Surveillance in U-space

Surveillance is the term commonly used in Air Traffic Control for the process by which the positions of
aircraft are known on the ground. The term is used in the same sense here. Surveillance is the S in CNS.
EU regulation 2021/664 [8] and [11] article 8 describes the Network Identification service as a way of
U-space being informed of where UAS are. This service is complemented by the requirement for
Electronic Conspicuity in EU2021/666 [10]. These two provisions require that all aircraft flying in U-
space airspace shall regularly communicate their current position to U-space. This is done in three
ways:
 UAS communicate with their contracted U-space Service Supplier via the Network
Identification service – 2021/664 article 8
 Aircraft in receipt of an ATC service have their surveillance communicated from ATC to U-
space, following 2021/666
 Crewed aircraft not in receipt of an ATC service must make themselves conspicuous to U-
space, following 2021/666
Hence the Network identification service is the basis of drone surveillance in the U-space airspace.
Surveillance in U-space is the basis for the following services:
 The Network Identification service

 Monitoring
 Traffic Information
 Tactical Conflict Prediction
 Surveillance data exchange
The performance of the system and the services consuming surveillance data, especially separation
can be quantified if position reports contain an indication of the uncertainties in the reported figures
and tracks have known quality. U-space airspaces will have associated with them minimum
performance for surveillance.
3.3.1 Network identification

EU 2021/664 [8] and [11] article 8 describes the Network Identification service as having two distinct
aspects.
 A service is described whose function requires the position of all UAS to be known.
 Based on that there is a requirement for the position of all UAS to be supplied to U-space.
These two aspects are explained separately below.
3.3.1.1 The Network Identification service as an Identification service

EU 2021/664 [8] and [11] article 8 describes a service by which authorised users and systems can obtain
information about a currently active UAS. The amount of information depends on the user or system
but the list of what should be output includes – quoting from paragraph 2 of article 8:
a) the UAS operator registration number,
Page 49
(EDITION 4)
b) the unique serial number of the uncrewed aircraft or, if the uncrewed aircraft is privately
built, the unique serial number of the add-on,
c) the geographical position of the UAS, its altitude above mean sea level and its height above
the surface or take-off point,
d) the route course measured clockwise from true north and the ground speed of the UAS
e) the geographical position of the remote pilot or, if not available, the take-off point,
f) the emergency status of the UAS.
The rate of update is determined by the competent authority, as may be other performance criteria
for surveillance.
The term “route course” should be interpreted as current heading. Intent is not shared.
In addition to the Surveillance uses mentioned in Section 3.3 and that the data is to be shared with
other U-space service providers (see [11],) the use of this service to substitute for the “Direct Remote
Identification” provision of UAS in Open operations – see EU 2019/947 [4]. That is, it allows a person
to identify a UAS that he/she is aware of, for example a policeman to identify a UAS that he/she can
see.
3.3.1.2 Dependent surveillance as part of Network Identification

EU 2021/664 [8] and [11] article 8 requires UAS in U-space to regularly inform U-space of enough
information to supply the Network Identification service. The rate is determined by the competent
authority.
Examining the list of elements that must be supplied in Section 3.3.1.1:
 Some elements might not be known to the aircraft, such as the geographical position of the
remote pilot. Hence the position report information sent form the UAS to U-space may
combine elements with different sources: the aircraft, the remote piloting station.
 Some elements are not likely to change during flight, such as the UAS operator registration
number and the take-off point.
 The messages sent from the UAS to U-space may vary over time. In particular there is Item
d), ‘the route course measured clockwise from true north and the ground speed of the UAS,’
can come from three different means:
o The U-space service receiving reported positions from the UAS could perform Tracking
and infer the motion vector,
o The UAS can send its own measurements of heading and velocity. The velocity is likely
to come from examination of previous positions,
o The UAS can sent its intended (planned) heading and ground speed.
Neither the regulation [8] nor the acceptable means of compliance [11] indicate how the information
is to be sent to U-space. It is assumed that “within the UAS” the aircraft will be in almost continuous
contact with the remote piloting station and that the pilot will be informed of (at least) the position of
the aircraft. Hence the position reports could be sent to U-space from either the aircraft, the remote
piloting station or a combination of elements from each.
The position report submission aspect of Network Identification will require processes to start and end
the submission. The submission process should be secure. Start of submission will involve secure
identification of the operator and aircraft. Start of submission and should follow very shortly after
Page 50
(EDITION 4)
activation of the flight – see 2.2.4.2. The ending of submission precedes the Termination of the flight
– see 2.2.4.7.
3.3.2 Tracking
EU 2021/664 [8] and [11] does not mention Tracking, though it might be inferred.
Tracking is a statistical process that uses the observations of where the object has been (the position
reports) and builds a model of where the object is most likely to be now, and how it is most likely to
be moving, hence where it is most likely to be in the near future. Tracking can be made to work with
multiple sources of observations for the same object, known as Multi Sensor Fusion Tracking.
Tracking is a standard activity in surveillance, especially in air traffic control. Tracking enhances the
value of radar, for example. In the U-space context we expect Network Identification to be the basis
of surveillance. The expected performance of the system will be that the observations are provided
every “few” seconds with a latency of less than a second. Tracking should allow the current position
to be inferred and presented as a smooth motion in any application.
Tracking implies a computing cost. Experience in current air traffic control is that Tracking aids human
cognition. Some services such as Tactical Conflict Prediction require tracks to work correctly. Any
source of uncorrelated reports, such as a drone detection system, will require tracking in order to
correlate the tracks with the other surveillance and/or flight plans.
There appear to be at four (or more) ways tracking can feature in U-space.
 As a service performed by the U-space Service Provider receiving the reported positions and
motions of the UAS. (by the producer)
 As a ‘shared’ service at some point within the interconnected U-space service providers as
they exchange surveillance data. (centrally)
 As a service performed by the U-space Service Provider making use of the reported positions
and motions of the UAS. (by the consumer)
 As a process applied in the Remote Piloting Station, if at all (downstream of U-space).
It is assumed that the Monitoring (3.10) and Tactical Conflict Prediction (3.6.1) services require tracks
rather than observations. Traffic Information (3.14) benefits from being supplied tracks rather than
observations. Tracking is also needed to allow cooperation between U-space and drone detection
systems.
3.3.3 Surveillance Data Exchange

EU 2021/664 [8] and [11] article 8(4) requires U-space service providers to share surveillance data
[Network Identification] with
 other U-space service providers, in order to ensure the safety of operations in the U-space
airspace
 the air traffic services providers concerned
 when designated, the single common information service provider
EU 2021/664 article 11(2) requires U-space to be able to display
Page 51
(EDITION 4)
 information about crewed aircraft and UAS traffic shared by other U-space service providers
and relevant air traffic service units, including that mentioned in EU IR 2021/665 as coming
from ATC
Hence U-space service providers must share surveillance data and accept surveillance data shared with
them.
3.4 Airspace Management

EU regulation 2019/947 [4] allows for the creation of UAS Geographical Zones (Geo-zones) for the
facilitation, restriction or exclusion of UAS operations.
EU regulations 2021/664,5,6 describe a kind of UAS Geographical Zone in which U-space services are
used, called a U-space airspace.
3.4.1 Drone Aeronautical Information Management

The Drone aeronautical information management service is concerned with bringing together
temporary and permanent changes to the drone “flying map.” It is the drone equivalent of the
Aeronautical information management service.
The slowly changing elements are the UAS Geographic Zones which may result from different sources.
A (fictitious) example might be a prohibition of drones flying over schools. If such a prohibition exists,
the education ministry, or the local (e.g., city) authority may use the drone aeronautical information
service to publish the geographic bounds of schools.
Rapid changes in the information are expect from:
 Dynamic Airspace Reconfiguration. This process is described in EU regulation 2021/664

Article 4 [8] and EU regulation 2021/665 [9]. U-space airspaces that are adjacent to
controlled airspace can have their boundaries changed by ATC under some conditions.
 The police in some countries (and perhaps others) are empowered to temporarily forbid
UAS flight in a region.
The Drone Aeronautical Information Management service may be part of a state’s Aeronautical
information management service or may be kept separate for any number of reasons, for example cost
transparency or ease of implementation.
Operating the Drone Aeronautical Information Management service will involve:
 Operating a service for authorised (presumably trained, perhaps certified) creators of Geo-
Zones.
 Collecting and possibly assisting or checking the inputs from occasional or less experienced
creators of Geo-zones.
 Vetting and training (and certification) of organisations to establish that they are trusted to
make updates directly in the system.
 The provider of the service may have to negotiate at times with those providing inputs which
are unduly cautious (restricting drone flight unnecessarily) or incautious, etc.
 Updating and synthesising the overall situation and making it continuously available.
Page 52
(EDITION 4)
3.4.2 Geo-awareness
Geo-awareness makes the UAS operator, and other interested parties, aware of what has been
gathered by the Drone Aeronautical Information Service.
3.4.2.1 U1
EU 2019/947 article 18(f) says that competent authorities are responsible for “making available in a
common unique digital format information on UAS geographical zones…” Regulation 2019/947 does
not describe this as a U-space service, but it is taken in this document as being the definition of U1
Geo-awareness.
3.4.2.2 U2
EU 2021/664 article 9 is within chapter IV and is addressed to the U-space service provider. Article 9
requires a geo-awareness service that provides the following information to UAS operators concerning
the U-space airspace:
 applicable operational conditions and airspace constraints,

 UAS geographical zones,
 temporary restrictions applicable to airspace use.
Article 9 further states that U-space service providers must provide this information in a timely manner
so that contingencies and emergencies can be addressed by UAS operators. The information must
include the time at which it was updated through a version number and/or a valid timestamp.
3.4.2.3 Common Information Service

Chapter II of EU IR 2021/664 is addressed to the state. Article 5 is within chapter II and describes the
Common Information Service. The full text of the article is not reproduced here – see [8]. The text of
article 5 mentions the content, the quality, the scope of the provision and the means of the provision
of the common information as well as related obligations.
The content mentioned in 2021/664 article 5(1) is, essentially:
 The geographic bounds of the U-space airspaces and Geographic zones,

 Technical and operational constraints associated with those U-space airspaces,
 The providers of services within those U-space airspaces.
The AMC/GM to the regulation [11] illuminates this further.
EU IR 2021/665 adds to the definition of Common Information by saying that it includes traffic
information coming from ATC.
The differences between Common Information service of EU regulation 2021/664 Article 5 and the
Geo-awareness service of Article 9 of the same regulation are that
 Common Information is available to all while Geo-awareness is provided by a U-space

Service Provider to its customers.
 While Geo-awareness gives the geographic bounds of the U-space airspaces and Geographic
zones, the Common Information is more than this, as it includes the Technical and
operational constraints associated with those U-space airspaces.
Page 53
(EDITION 4)
 The U2 Geo-awareness service has a greater emphasis on timeliness and performance than
the Common Information service.
 The Common Information includes some Traffic Information – that coming from ATC.
One use case for Common Information is as part of a planning process. Once a UAS operator has
determined the path for a proposed flight, then the UAS operator can use the Common Information
Service to determine if any part of the flight is in U-space airspace, and if it is, what requirements there
are to fly in that U-space airspace and which USSPs are certified to provide services in that U-space
airspace. EU IR 2021/664 states that a competent authority may nominate a single provider of common
information, which would provide a single point of reference for such a process. Section 2.5.1 considers
the Common Information Service as part of the infrastructure of U-space.
3.4.2.4 Summary
Service Provider Consumer Scope
Geo-awareness (U1) State appointed Anyone Nationwide
Common Information Either: State appointed Anyone U-space airspace (1)
Service Or: All U-space service providers
Geo-awareness (U2) U-space service provider Client of USSP U-space airspace
Table 5 Geo-awareness services in EU regulation
Note (1): The Common Information Service is mentioned in 2021/664 as being available in U-space
airspaces. If it were available nationwide it might be the same as U1 Geo-awareness.
3.4.3 Geo-Fence Information Exchange service

The Geo-Fence Information Exchange service has been identified in the AURA project [47] as the means
to communicate the result of Dynamic Airspace Reconfiguration from ATC to U-space. It can be
considered to be a part of the Collaborative Interface with ATC.
3.5 Mission management

This section describes the Flight Authorisation service and the U-plan Processing service. As elements
of these the following are also discussed:
 strategic conflict detection service

 strategic conflict resolution service
 dynamic capacity management service
 vertiport availability service
 u-plan preparation and optimisation service
 environmental data services
 risk analysis service
The UAS flight authorisation service is mandated under EU Regulation 2021/664 Article 10 [8] [11].
Flight authorisation in 2021/664 only has very limited scope. The Flight Authorisation service described
here was referred to as the Operation Plan Processing service in Edition 3 [1] and has a larger scope.
Page 54
(EDITION 4)
Action EU Regulation Edition 4

2021/664
Specific operations risk assessment No Some support
Obtaining permission to fly No No
Checking the operator is registered Yes Yes
Listing geo-zones penetrated by the flight Yes Yes
Obtaining permission to enter a geo-zone No In some cases
Confirming the flight has permission to enter a geo-zone / No In some cases
confirming the flight conforms to geographic bounds
Uniquely identifying each flight Yes Yes
Storing and making available the flight intent for use by other Yes Yes
services before, during and after the active phase
Strategic Conflict Resolution Yes Yes
Dynamic Capacity Management No Yes, when
appropriate
If the flight penetrates a region controlled by ATC, coordinating No Yes
the flight with the ATC for that region
Table 6 Relative scopes of the Flight Authorisation Service of 2021/664 and this ConOps
3.5.1 U-plan Preparation / Optimisation service

It is assumed that many UAS operators will have a tool to develop plans for flights and send those plans
for authorisation. This tool may be a service provided by a USSP and is referred to as the U-plan
Preparation / Optimisation Service. Different versions of this service could be imagined for different
business sectors. These tools are expected to be very valuable to UAS operators, however the details
of how they work is out of the scope of this ConOps.
Supporting the U-plan Preparation / Optimisation service, various services providing geographic data
used in planning may be offered:
3.5.1.1 Population density map

The Population density Information service collects and presents the relevant density map for the
drone operation. This map is used to assess ground risk.
Proxies for instantaneous population density information such as mobile telephone density (to be
confirmed) might be found to be reliable.
3.5.1.2 Electromagnetic interference information

The service collects and presents relevant electromagnetic interference information for the drone
operation. The service shows where there may be a risk to the C2 link or other aspects of drone
function due to radio frequency emissions.
Page 55
(EDITION 4)
3.5.1.3 Navigation Coverage information

The service to provide information about navigation coverage. This can be specialised depending on
the navigation infrastructure available (e.g. ground or satellite based). This service is used to plan
operations that rely on such coverage. It may show regions with known issues or regions in which
augmentation is available.
3.5.1.4 Communication Coverage information

This service provides 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 operations that rely on such coverage. For example, this might be a map of the calculated or
measured signal strength of mobile internet based on mobile telephony standards such as 3G, LTE 4G,
5G and so on.
3.5.1.5 Risk Analysis Assistance

Preparation of Specific operations involves SORA (see Annex I to EASA ED Decision 2019/021/R -
Acceptable Means of Compliance (AMC) and guidance material (GM) to Commission Implementing
Regulation 2019/947 [3]) which requires analysing risks associated with the operation. It is expected
that a service will be offered to support this analysis using the draft U-plan as well as information
coming from the Drone Aeronautical Information Management service (Section 3.4), various
Environment services and the Traffic Information service (Section 3.14)
The risk analysis assistance service may also provide access to “per flight insurance” services.
3.5.2 Flight Authorisation service

Edition 3 of the ConOps [1] referred to this as part of the Operation Plan Processing. To follow EU
regulation 2021/664 [8], the name Flight Authorisation service is used.
The Flight Authorisation service is deployed in U2. It receives U-plans and uses these for a number of
safety-related activities. The Flight Authorisation service must be deployed in a robust and reliable
manner because of its safety criticality.
The description of operations presented here is as if the system providing the flight authorisation
service is a single integrated instance. This is the operational view. The implementation may be
otherwise – that choice is out of the scope of this ConOps.
The Flight Authorisation service maintains a pool of data containing the histories of all submitted U-
plans that have not yet been archived. Archiving occurs at some time after the U-plan is ended (after
flight) or is cancelled (without ever flying). The U-plans in this pool are considered to be commercially
sensitive and may additionally be restricted for other reasons – such as for state operations. Hence
access to this pool is controlled.
The role that submits a U-plan to the Flight authorisation service is the drone operator representative.
To do this they probably use an U-plan preparation / optimisation service or tool. The submission will
be by some secure means.
The sum of all the U-plans known in the Flight authorisation service is “the traffic.” The impact of a U-
plan being submitted is to an extent felt by all other drone operators as a change in the traffic. To
maintain commercial secrecy while multiple instances of the flight authorisation service collectively
Page 56
(EDITION 4)
build a pool, the pool might only contain the minimum information, as proposed in ASTM F3548-21
Standard Specification for UAS Traffic Management (UTM) UAS Service Supplier (USS) Interoperability
[18].
The Flight authorisation 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 Flight authorisation service
when a U-plan is received.
 Syntax check. Does whatever has arrived resemble a U-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 U-plan.
 Authorisation-check using the Registration service, see 3.2. Is there some reason this operator
or this pilot or this drone should not be flying?
 Check the 4D trajectory supplied in the U-plan is credible. (e.g. no gaps)
 Weather warning, using the Weather information service. Is there a weather warning for the
time and place of the operation?
 Geo-Fencing, height limits and other boundary checks, using the Drone aeronautical information
service and the 4D trajectory. For any geo-fences that are penetrated, is there a corresponding
permission in the U-plan? For any conditional access, are the conditions met?
 Procedural interface with ATC. If any controlled areas are penetrated by the 4D trajectory then
the procedural interface with ATC is triggered for each.
 The Strategic conflict-management service is invoked. See Sections 3.5.2.2 and 3.5.2.3
 If appropriate, the Dynamic capacity management service is invoked. See Section 3.5.2.5
Figure 9 shows the process outlined above as a flow chart. Figure 8 shows the simpler process of the
EU regulation 2021/664, expected in the Initial U-space implementation (2023-2030) described in
section 1.4.3.
Page 57
(EDITION 4)
Receive U-plan Geo awareness
Geofence Check
Syntax check
Reject
Semantic
Reject
Check
Warning
Conflict
Generate
Unique ID
set of flights
Reject
Authorised
UAS operator Higher priority Conflict with

Registry
check flight higher priority
Withdrawn
Trajectory
complete
Weather
minima
Weather minima
Reject
check
Weather
forecast
Figure 8 Flight authorisation in EU IR 2021/664
Page 58
(EDITION 4)
Receive U-plan Geo awareness
Geofence Check
Syntax check
Reject
Semantic
Reject
Check
Warning
Generate ATC
Unique ID involvement
Procedural
Interface
With ATC
Reject
UAS operator Add to set of

Registry
check flights
RTTA Valid
Trajectory Dynamic Capacity

complete management
Weather
minima
Weather minima Strategic conflict
Reject Withdrawn
check resolution
Weather
forecast
Authorised
Figure 9 Flight Authorisation flow chart including RTTA
The response from the processing should be a copy of the accepted U-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 flight authorisation service will also offer a validation mode in which the U-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 a U-plan has been accepted by the Flight authorisation service, the operator may send further
messages to:
 Cancel the U-plan,

 Change the U-plan,
 Ask for the current status of the U-plan.
Further an operator can query the service to get a list of all the U-plans known that have been
submitted by that operator and their status.
The status of a U-plan can change after the U-plan is accepted, see Section 2.2.3.3, due to
 A change in the airspace structure,

 A conflict with another U-plan,
 Capacity being exceeded and this plan being subject to a measure to reduce demand.
Page 59
(EDITION 4)
The operator should be notified directly by the Flight authorisation service if such an event occurs, and
it changes the status of the U-plan.
The status of a U-plan also changes when it is activated. A further status change occurs on receipt of
end-of-flight.
The following table summarises the different interactions that involve the Flight authorisation service.
Role / Node Action notes

Drone operator Submits U-plans, changes, cancellations May use an U-plan
representative Activates and terminates U-plans preparation / optimisation
service or tool.
Receives positive or negative acknowledgements
Queries U-plans or status
Receives status change warnings
Aeronautical Supplies aeronautical publications This service and these
Information Service Supplies NOTAMs publications already exist
(may be supplied via for the benefit of existing
Common Information aviation.
Service)
Drone Aeronautical Supplies X, Y , Z volumes and other drone specific
Information Service information
(Common Information
Service)
Registration service Confirms the validity of the operator, any pilot
training, the type of drone mentioned in any plan
Weather Information Supplies weather forecasts and warnings
service
Procedural interface Triggers a coordination for a flight to penetrate a
with ATC controlled area.
Strategic Conflict Detects and resolves conflicts before flight
Prediction service May trigger a state change
Strategic Conflict
Resolution service
Dynamic Capacity Detects and resolves demand and capacity
Management service imbalances
May trigger a state change
Network identification Queries U-plans, U-plan identifiers and U-plan
service states
Creates / feeds / destroys flight surveillance
session(s) associated with a U-plan
Monitoring service Retrieves a plan
Including Updates the current position of a plan
Conformance Signals non-conformance, which may change the
Monitoring service state of a plan
Table 9: Flight Authorisation service Roles and Actions
Page 60
(EDITION 4)
3.5.2.1 U-plan processing service

Once a U-plan is activated, the U-plan processing service links the U-plan with the stream of
surveillance data, see section 3.3. The combination is a version of the plan with reduced uncertainties.
It may be used in Conformance Monitoring, Tactical Conflict Prediction and exchanged with Drone
surveillance systems.
3.5.2.2 Strategic Conflict Prediction

The Strategic conflict prediction service may be invoked by the Flight authorisation service, before the
flight takes place, because a new U-plan has been submitted or because a previously submitted U-plan
has changed.
3.5.2.2.1 The 4D trajectory

The 4D trajectory of the U-plan is made of a series of one or more four dimensional volumes. Each
volume has three dimensions in space as well as an entry time and an exit time. The trajectories of
UAS flights are considered as having two basic modes of flight. The UAS could be active in an area, for
example photographing crops in a field, or it could be travelling somewhere. These are expressed as
volumes which are occupied for an extended period or volumes which are visited briefly.
Figure 10 Area-based and Linear 4D trajectories, in green.
The 4D trajectory submitted in the U-plan by the UAS operator consists only of the 4D volumes, shown
in green in Figure 10. The blue lines shown in Figure 10 are only to help the reader understand their
purpose.
A U-plan may contain either or both linear and area-based volumes.
Each 4D volumes expresses the uncertainties of that segment of the flight. These uncertainties come
from various sources:
 The capabilities of the aircraft, for example turning radius and the expected effect of the
forecast weather.
 The imprecision of the navigation technology, for example GNSS receivers are typically limited
by the precision of their internal clocks, while GNSS suffers from effects such as “dilution of
precision” and multipath error.
 The range of take-off times. Each volume expresses the earliest possible entry time in the
volume and the latest possible exit time from the volume. Because of this the volumes may
overlap in time – the flight might be in more than one volume.
The uncertainty expressed in the volumes is bounded at 95%. It is assumed that the probable position
of the aircraft in any dimension will follow some distribution. The region of interest is limited to 95%
which for a Gaussian distribution would be two standard deviations. This figure comes from the Reich
collision risk model which has long been used in aviation. See “Aircraft Collision Models” by Shinsuke
Endoh, MIT Flight Transport Lab Report R82-2 [48].
Page 61
(EDITION 4)
In its deliverable “Algorithm for analysing the collision risk,” [25] the BUBBLES project described the
trajectory of UAS as being a box or a corridor. The box corresponds to the area based trajectory in
Figure 10, the corridor to the linear trajectory. The expectation in this ConOps is that the linear
trajectory will consist of a series of volumes rather than a single corridor as this will allow more efficient
use of the airspace. At any moment, volumes that the flight has exited, or has not yet entered can be
considered as not currently occupied. This liberates airspace compared to a corridor model in which
the whole length of the flight is considered occupied as long as the aircraft is airborne. Hence the series
of volumes described here. Obviously, the series of 4D volumes must be contiguous or overlap in order
to allow the flight to progress. There can be no gaps.
It is expected that for any airspace the competent authority may publish minimum and/or maximum
dimensions for the volumes in a 4D trajectory. It is particularly expected that the range of earliest
possible entry time and latest possible exit time will be limited in the interests of efficient use of the
airspace. For a drone flying at 20ms-1, a take-off time ±30 seconds represents an uncertainty on the
current position of the aircraft 1.2km in length. Allowing ±1 minute doubles this to 2.4km.
3.5.2.2.2 Detecting conflict between trajectories

EU IR 2021/664 [8] and its Acceptable Means of Compliance and Guidance material [11] require that
the 4D trajectory submitted by the UAS operator is enlarged by in each dimension by an amount
referred to as a Deviation Threshold. The size of this deviation threshold is determined by the
competent authority and is particular to each U-space airspace. Deconfliction then considers the 4D
trajectories plus the deviation thresholds while conformance monitoring considers only the 4D
trajectories. Figure 11 shows the idea of deviation thresholds in a two-dimensional diagram.
Ideal path
U-plan 4D
volumes
Deviation
threshold
s
Figure 11 Deviation thresholds for two non-conflicting U-plans
Page 62
(EDITION 4)
The U-space regulation 2021/664 [8] specifies that deconfliction means that every trajectory “is free
of intersection in space and time with any other.”
Currently UAS operators consider flight details commercially sensitive. ASTM F3548-21 [18] is a
“Standard Specification for UAS Traffic Management (UTM) UAS Service Supplier (USS)
Interoperability” and describes how different USSP can discover conflicts between flights while
revealing the minimum information. The standard describes the use of a “discovery and
synchronisation service” DSS, for which there is a reference implantation, the Inter-USS [19], published
by the Linux foundation and available on Github. In very simple term the DSS maintains a four-
dimensional grid of cells and USSP express an interest in cells. When a USSP expresses an interest in a
cell they are informed the contact details of any other party having an interest in that cell. The DSS can
be replicated across multiple instances.
3.5.2.3 Strategic Conflict Resolution

Strategic conflict resolution is undertaken by changing one of the pair of conflicting trajectories so that
there is no longer “intersection.” It is expected that the strategic conflict resolution service will search
for non-conflicting alternatives by applying automatically generated changes from a standard set of
“recipes” to the filed plan(s) and testing the result, e.g. take-off delay. Those that resolve the problem
and do not cause another problem will be proposed to the operator who will refine the plan further
before resubmitting or changing it.
ASTM F3548-21 [18] proposes that when it is found that two USSP have an interest in the same 4D cell,
they contact each other and negotiate.
EU IR 2021/664 article 10 proposes a simple approach: the first authorised plan reserves the airspace
in which it flies. This is qualified by there being two priorities of flight and a higher priority will take
precedence over the lower, but within the same priority, the earliest to be authorised is accepted and
others are rejected. This rejection can be understood as signalling to the UAS operator that their plan
needs to be changed.
3.5.2.4 Fairness in strategic conflict resolution

In case of a conflict between two flight plans, the conflict is usually resolved by changing one of the
plans. This change may be viewed as a penalty. UAS operators are expected to file plans that are in
their best interest, that best optimise their business. Any change will move the plan away from that
optimisation - to some degree.
The “first to file” prioritisation of EU regulation 2021/664 systematically penalises types of operations
that cannot file long in advance, such as “on demand” services like food delivery.
There is a desire to achieve fairness in strategic conflict resolution. What exactly fairness means is
currently the subject of research, as is how it might be achieved, such as RTTA: see 2.2.3.2.3. Many
other approaches could also be imagined, see “Market Design for Drone Traffic Management” [27] for
an overview.
3.5.2.5 Dynamic Capacity Management

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.
Page 63
(EDITION 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.
3.5.2.5.1 Inner working

This section condenses the work done by the DACUS project. See the Drone DCB concept and process
[29].
There will be a process to predict times in the future when an airspace will be “full” or “saturated”.
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, or that some social acceptability metric (e.g. noise) has reached its
limit. 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), and considerations of priority – see Section 2.2.3.2.
The solution is generally to propose a delay for flights or to propose rerouting them away from the full
airspace. If this has to happen:
 All high-priority operations continue unhindered, as far as possible.

 Apart from high priority operations, all operations for which an U-plan was submitted after
the 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. If the above will not solve the
problem, lower-priority operations are examined to find those causing the greatest risk of
conflict, hence whose removal would cause the largest overall reduction in risk to the
airspace.
 If the above will not solve the problem, all U-plans take part in a process that proposes
changes to those with the lowest priority, working upward until the problem is solved.
3.5.2.5.2 Invocation
The Dynamic capacity management service is expected to appear in U3. It is invoked by the Flight
authorisation 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 Flight
authorisation service.
3.5.2.5.3 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 unused 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 such as
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.
Page 64
(EDITION 4)
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.
3.5.2.6 Flight authorisation states

The U-plan has a number of distinct phases in its life. Different observers may identify different states
of the U-plan depending on their particular interests.
1 Draft. There is a business need and a U-plan is being developed.

2 Approved. The U-plan has been filed, strategically deconflicted and so on. Resources (e.g.,
airspace, vertiport) are now committed to this flight.
3 Active. The services used in flight are operating. Tracking, emergency management, etc.
4 Ended. The flight is over.
There are a few other states that can usefully be added to that set. Flights may have been approved
but then due to changes in circumstances, for example a higher priority flight is in conflict with the U-
plan, this approval might be withdrawn. Flights might be already activated and then the same change
in circumstances make them activated but not safe. Flights may invoke contingency procedures which
means that they are flying but not following the original plan.
3.6 Tactical conflicts

Tactical conflict prediction and resolution avoid conflict by changing the flight while it happens. These
can be implemented as advisory services or as systems giving instructions. The descriptions here
assume that the services are implemented on the ground and not as a function distributed among the
aircraft.
It is expected that an aircraft to aircraft system for avoiding conflicts during flight, known as “detect
and avoid” or “sense and avoid”, will either be used when there is no Tactical Conflict Resolution
service or act as a safety net in addition to (i.e. after) Tactical Conflict Resolution.
3.6.1 Tactical Conflict Prediction

The Tactical conflict prediction service requires that the positions of all aircraft be 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. The Tactical conflict prediction service is highly
linked with the Tracking service (see 3.3.2) and the Vertical Alert and Information Service (see 3.20) to
provide common-reference altitudes of all aircraft. The service may also take intent into account, as
obtained from the U-plans in the U-plan processing services (see 3.5.2.1) Based on current motion and
(where available) intents, the service predicts conflicts and provides alerts to the operators/pilots and
to the USSP.
A Tactical Conflict is a prediction that two aircraft “come too close together” or “lose separation.” The
predicted positions/motions of the aircraft are uncertain as each is based on previous observations of
position and motion that have limited accuracy, which are then used in approximate models of the
behaviour of the aircraft to predict the current and future positions/motions. In function of the
uncertainties of the positions of the aircraft, the loss of separation considers a volume around the
calculated position of the aircraft with the view that the aircraft is probably somewhere within the
volume. The BUBBLES project [54] follows conventional logic by naming this the “Near Mid-Air-
Collision” (NMAC) Volume. In Figure 12, from the BUBBLES project, the NMAC volume is surrounded
Page 65
(EDITION 4)
by three larger volumes; the Collision Avoidance threshold - at which any on-board collision avoidance
system should trigger, the separation threshold, which the strategic and tactical conflict detection and
resolution services should protect, and the tactical conflict threshold which is the distance at which
the tactical conflict detection should trigger a resolution. These distances are not shown to scale.
Figure 12 Near Mid-air-collision volume and other thresholds - from BUBBLES
3.6.2 Tactical Conflict Resolution

On receiving a conflict alert from the Tactical conflict prediction service, the Tactical conflict resolution
service issues advice (Zz volume) or instructions (Zu volume) to aircraft to change their speed, level or
heading as needed to resolve these conflicts. The advice / these instructions should reach the pilot (or
piloting system) rapidly and reliably.
The Tactical conflict prediction and resolution services can work more effectively if they make use of
models of the flight envelope and characteristics of each aircraft concerned. Further efficiency gains
may be made if the service is aware of the intent (that is the U-plan) of each flight.
The Tactical conflict resolution service is a client of the Tracking service (see 3.3.2), the Flight
authorisation service (see 3.5.2) and the Drone aeronautical information management service (see
3.4).
A much more detailed examination of Tactical Conflict Resolution appears in deliverables of the
BUBBLES project, notably “Algorithm for analysing the collision risk,” D4.1 [25] and “Guidelines to
implement separation minima and methods,” D4.2 [26]. The BUBBLES project provides describes a
method to derive the separation minima from such factors as the CNS performance and target level of
safety.
Page 66
(EDITION 4)
3.7 Vertiport availability service

As described in section 2.4.1, whether a vertiport is available to be landed at will be information to be
considered in the planning for contingencies for UAS which consider that Vertiport as an alternative
landing site. Due to the possibility that the vertiport might be used as an emergency landing site, the
vertiport availability is not guaranteed for flights that have planned its use.
The vertiport availability service provides information to a UAS operator on whether a vertiport FATO
is occupied or available during a requested period.
The vertiport availability service is a planning service.
Use of the vertiport will imply contractual arrangements and the agreement of permission to land
including any relevant arrival procedures, contingency processes, technical constraints and so on.
Ideally the vertiport availability service will support these exchanges.
3.8 Weather Information

Article 12 of Reg. 2021/664 mandates the provision of a weather information service. This service will
collect and present relevant weather information for the drone operation. This includes hyperlocal
weather information when available/required.
Weather Information may be used for air worthiness decisions – for example are the capabilities of an
individual aircraft likely to be exceeded by the forecast wind, and/or for traffic management – for
example does the visibility exceed mandated minima.
3.9 Geographical Information Service

The Geographical Information Service (GIS) provides a 3D model of terrain and obstacles for use during
planning, updated continuously for use during flight. GIS extends the Geospatial Information (GI)
service referred to in Edition 3 [1].
Sources of data could include digital surface models combined with a ground obstacle database, or
from direct mapping of the obstacles. The map data quality will be announced and assured by the
service provider.
3.10Monitoring
Subject to appropriate data-quality requirements, this broad service retrieves data from the tracking
service and combines it with information related to:
 the flight plan, from the U-plan processing service, in order to achieve the Conformance
Monitoring service (see 3.10.1),
 obstacles, from the Geographical Information Service, in order to provide the Vertical Alert
and Information Service (see 3.20),
 other aircraft from the Traffic Information service to provide an air situation status report
for authorities, service providers, and operators, including pilots,
 geo-fences from the Geo-awareness service in order to provide geo-awareness compliance
monitoring and warnings (see 3.4.3),
Page 67
(EDITION 4)
 weather information from the Weather Information service to provide weather limit
compliance monitoring.
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 the Tracking and Drone aeronautical information management services and
of the different environmental services.
3.10.1Conformance Monitoring service

Article 13 of EU IR 2021/664 requires that a Conformance monitoring service be in place to “enable
UAS operators to verify whether they comply with the requirements set out in article 6(1) of the same
regulation [referring to the obligations of UAS operators] and the terms of the UAS flight
authorisation.” Furthermore, article 15(g) of EU IR 2021/664 mandates legal recording of flights and
article 15(d) requires incident and accident reporting. All of these requirements are discussed in this
section.
The monitoring service supplies conformance monitoring.
3.11Legal 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.
3.12Emergency Management
The Emergency management service of U-space has two aspects:
 assistance to a drone pilot experiencing an emergency with their drone,
 communication of emergency information to those who may be interested:
o pilots whose drones may be affected,
o crewed aviation, air traffic services,
o police, military and similar
The assistance given to a pilot may include:

 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 their drone and/or drone U-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 ‘log-on’. Emergencies
Page 68
(EDITION 4)
communicated to the drone pilot are those likely to come near their operation and hence pose a risk
to it.
The Emergency-management communication channel 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 to maintain relevance
for the pilot.
The Emergency management service consumes information from the Tracking, Monitoring and U-plan
processing services – if active for the operation concerned. If the flight has an U-plan, the Emergency
management service will warn the pilot when a geo-fence-with-immediate-effect has been created
which affects the current flight.
3.13Incident / Accident reporting

An Incident/accident reporting service is a requirement of Article 15(d) of Reg. 2021/664. This service
allows drone operators and others to report incidents and accidents. It allows these reports to mention
drone identifiers and U-plan identifiers to help later investigation.
The service maintains the reports for their whole life-cycle. The system is secure and only gives access
to authorised persons.
The Accident and Incident reporting service is a client of the Legal Recording service (see 3.11) 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.
U-space should also 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.
3.14Traffic Information
A traffic information service is mandated in EU IR 2021/664, article 11. This service provides the drone
pilot or operator with traffic information and warnings about other flights – crewed or uncrewed - 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.” There is some commercial sensitivity to
drone flight information and an air situation display may be restricted. Note that an air situation display
presents an image to the user; it is foreseen that tracks will be shared between U-space and ATM
through the Surveillance data service – see 3.3.3. The traffic information should be subject to Vertical
Conversion Service (see 3.19) when it is available in order to present information that is meaningful to
the recipient.
The Traffic information service also gives access to the traffic densities expected in the near future at
any location, as calculated from U-plans that have been submitted.
Page 69
(EDITION 4)
3.15Infrastructure monitoring
Services exist to report the current state of critical infrastructure.
3.15.1Navigation Infrastructure Monitoring

The service to provide up to date status information about navigation infrastructure. This service is
used before and during operations. The service should give warnings of loss of navigation accuracy.
Specifically, the GNSS service retrieves data from EDAS (the EGNOS Data Access Service), from the
Reference Stations database and, through the USSP API, from the U-Space Tracking and Monitoring
service (see Section 3.3.2) provided by the USSP. Once all the necessary data have been obtained, the
service can provide GNSS signal monitoring, Position Velocity and Time (PVT) and Integrity calculation.
This service may also distribute correction information coming from augmentation services, and even
RTK (real time kinematic) augmentation as appropriate.
3.15.2Communication Infrastructure Monitoring

The service to provide up to date status information about communication infrastructure. This service
is used before and during operations. The service should give warnings of degradation of
communications infrastructure.
3.16Digital 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.
Drone operators will be able to see histories / statistics for their aircraft.
The digital logbook service needs to be securely implemented. Various query functions should be
available.
Authorised users, such as accident investigators or police may have general access to all data.
3.17Procedural interface with ATC

The procedural interface with ATC is a mechanism for coordinating the entry of a flight into controlled
airspace. The interface works before the flight takes place. The U-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.
Page 70
(EDITION 4)
3.17.1Dynamic Airspace Reconfiguration (DAR) Service

Project PJ34/AURA [47] has studied the interaction between ATC and U-space and proposes the
Dynamic Airspace Reconfiguration (DAR) Service.
In the medium to long-term, there is an assumption that the number of UAS operating in controlled
airspace will be much higher than the number of crewed aircraft (e.g., ratio of 10:1). This service aims
at managing such a UA dense operating environment in shared ATM/U-Space airspace (Y volume).
The service is eligible in a known traffic environment of cooperative operations in lower-level

controlled airspace. A portion of the overall operational environment where the majority of crewed
and uncrewed interactions are likely to occur and where the demands on the interface and utilisation
of its services are likely to be greatest. This corresponds to airspace classes A – D and also to class E
when all the air traffic is electronically conspicuous.
The service enables operational integration through the delegation of portions of airspace for either
crewed or uncrewed operations through a process called Dynamic Airspace Reconfiguration (DAR).
While partially resembling a form of traditional airspace segregation, there are several aspects which
diverge from this conventional concept and align closer to a form of separation.
 Enables wide-scale, high volume access for UA to certain parts of controlled airspace,
increasing the available airspace for UAS to operate in, rather than conventional segregation
which typically curtails or restricts the movement of airspace users to specific set
regions/corridors.
 High granularity and fidelity DAR, which, unlike large, pre-defined blocks of segregated
airspace, enables better utilisation of the controlled airspace for a mix of crewed and
uncrewed airspace users.
 Highly dynamic and responsive to demand, reconfiguring the airspace both tactically and
strategically. In contrast to conventional segregated areas, this concept is able to respond in
almost real-time to changes in demands on the airspace.
ATC manages DAR, delegating portions of the controlled airspace for U-space services to manage
according to crewed and uncrewed traffic demands.
 Portions of controlled airspace where ATC have control are termed ‘blue’ volumes. For
example, there could be pre-defined blue volumes within controlled airspace whose airspace
matches crewed Standard Instrument Departure Routes (SIDs) and Standard Terminal Arrival
routes (STARs).
 Portions of controlled airspace where ATC have delegated management of the airspace to U-
space are termed ‘orange’ volumes. For example, areas within the controlled airspace not in
proximity to the airport or crewed flight paths which are clear of other hazardous objects.
Orange volumes are geo-caged to prevent uncrewed operations straying outside their flight paths and
infringing on blue volumes of ATC controlled airspace. There are safety buffers between blue and
orange volumes.
In the event that crewed operations seek to operate in airspace which is currently a U-space airspace
delegated volume and uncrewed operations seek to operate in airspace which is currently an ATC
controlled volume, these requests are considered by ATC who will implement DAR and alter the
airspace structure to allow these operations if possible. This can be done pre-tactically or tactically.
Page 71
(EDITION 4)
The result being that crewed operations always occur in blue volumes and uncrewed operations always
occur in orange volumes within CTA.
ATC will not perform active monitoring over all UA operations within the CTA, as it can be assumed
that USSPs will take over this responsibility in orange areas. ATC will only monitor a UA flight which
has direct implications on the operations of crewed aircraft.
Figure 13 AURA scenario with airspace predominantly controlled by ATC
Figure 14 AURA scenario with airspace predominantly U-space
The subject is further discussed in the AURA project deliverables [47].
3.18Collaborative interface with ATC

The collaborative interface with ATC is introduced in U3 and is a service offering communication
between ATC and U-space or the appropriate representative of a drone flight, which could be the
remote pilot, the drone itself in case of automated flight or in some cases the USSP. The collaborative
interface with ATC is expected to used while a drone is close to or in a controlled area. The
Page 72
(EDITION 4)
communication to a pilot may be verbal or textual / graphical and to U-space will be by means of a
data exchange model. The Collaborative interface allows flights to receive instructions and clearances
in a standard and efficient manner, replacing the ad-hoc solutions used prior to this service’s being
used.
The Procedural Interface with ATC is the normal method for obtaining approval to enter a controlled
area. ATC may refuse to accept flights as they choose. The collaborative interface is not a means for
avoiding such approval.
In addition to communications, the Collaborative Interface with ATC provides for safe operation by
giving ATC access to U-space surveillance data.
3.18.1Tactical Operational Message Info Exchange

The project GOF2 [46] has proposed several information exchange models, which are in annex to this
ConOps. Project PJ34/AURA [47] has studied the interaction between ATC and U-space and has
adopted the information exchange models of GOF2. AURA has highlighted the need for an information
exchange to exchange operational messages. This service is considered here to be a sub-part of the
Collaborative interface with ATC.
3.19Vertical Conversion Service

The Vertical Conversion Service (VCS) and the Vertical Alert and Information Service (see Section 3.20)
are both elements of the proposed ICARUS suite of services not mentioned in Edition 3 [1]. The VCS
ensures the conversion of altitudes between barometric and geodetic reference systems to both
crewed and uncrewed aircraft in Geodetic Altitude Mandatory Zones (GAMZ). It uses other services
and ICARUS sub-services to calculate the geometric height a crewed plane is flying at, and the
barometric height of a drone and shares these with other aircraft in the vicinity.
The Vertical Conversion Service retrieves weather data from weather service providers, from the USSP
(Weather information service) and from the Weather Reference Station database. It also obtains GNSS
data and barometric data etc. about crewed aviation through interfaces with ATM.
3.20Vertical Alert and Information Service

The ICARUS project [28] has defined the Vertical Alert and Information service (VALS) which alerts
pilots of crewed and uncrewed aircraft in any Geodetic Altitude Mandatory Zones (GAMZ) to any risk
of collision with ground obstacles, using APIs (Application Programming Interfaces) from the Air
Navigation Service Provider (ANSP) and the USSP respectively. This is done through using the GIS
(Section 3.9), Navigation Infrastructure Monitoring (Section 3.15.1), and VCS (Section 3.19) services
that provide it with the position of the crewed aircraft and the drone, and their barometric and
geometric heights. For UAS the service is part of the monitoring service. For crewed aircraft is requires
separate provision – or monitoring of crewed aircraft.
Page 73
(EDITION 4)
3.21Service names in comparison with EU regulation and the

previous ConOps
This section draws on the ConOps edition 3 [1] and seeks to align the material with EU regulation. The
following table lists the U-space services which are then described each in its own section. In each row
is the relationship with EU regulation. Note that EU IR 2019/947 [4] & [6] does not refer to U-space
services but does make obligations that are answered by what this document refers to as U-space
services. EU IR 2021/664 [8] does refer to U-space services, but only describes a small number used by
the operator. ConOps edition 3 broke the services down into their different functions.
Edition 4 section Edition 3 Service U-level 2019/947 & 2021/664, 665

service 945 & 666
Registration
U1 947 Article 14
Registration 3.2 ( e-registration )
Registration Assistance U1
Partial match 664 Article 8

e-identification U1 with remote Network
Network identification Identification
identification 3.3.1
(see note below) 664 Article 8
Position report
U2 Network
submission subservice
Identification
Not mentioned but
might be inferred in
the description of
Tracking 3.3.2 Tracking U2
the Traffic
Information Service
in 664
664 Article 8
Network
Identification
Surveillance Data Surveillance Data Reception of ATM
3.3.3 U2
Exchange Exchange surveillance data by
U-space is part of
the Traffic
Information Service
664 Article 5
Drone Common
Drone Aeronautical
Aeronautical Information Service
3.4 Information U1 947 Article 15
Information
Management (CIS has larger
Management
scope than DAIM)
Partially: 947
Geo-awareness U1
Article 15
664 Article 9 Geo-
Geo-awareness 3.4.2 Geo-Fence provision awareness service
(includes Dynamic U2
Geo-Fencing)
Page 74
(EDITION 4)

service 945 & 666
U-plan
Preparation / U-plan preparation /
U2
Optimisation optimisation
service
Risk Analysis Risk Analysis
U2
Assistance Assistance
Partly covered in
Flight
Article 10 UAS
Authorisation 3.5.2 U-plan processing U2
flight authorisation
service
service
Article 10 UAS
Strategic Conflict
3.5.2.2 flight authorisation
Prediction
Strategic Conflict service
U2
Resolution Article 10 UAS
Strategic Conflict
3.5.2.3 flight authorisation
Resolution
service
Dynamic Capacity Dynamic Capacity
3.5.2.5 U3
Management Management
Tactical Conflict
3.6.1
Prediction Tactical Conflict
U3
Tactical Conflict Resolution
3.6.2
Resolution
Partially covered by
Monitoring 3.10 Monitoring U2 Article 13
Conformance
monitoring service
Legal Recording 3.11 Legal Recording U2 Article 15(g)
Article 13
Emergency Emergency
3.12 U2 Conformance
Management Management
monitoring service
Incident / Accident Partially covered by
Incident / U2
reporting Article 15(d)
Accident 3.13
reporting Citizen Reporting
U2
service
Traffic Article 11 Traffic
3.14 Traffic Information U2
Information information service
Navigation Navigation
Infrastructure 3.15.1 Infrastructure U2
Monitoring Monitoring
Communication Communication
Infrastructure 3.15.2 Infrastructure U2
Monitoring Monitoring
Page 75
(EDITION 4)

service 945 & 666
Digital Logbook 3.16 Digital Logbook U2
Weather Article 12 Weather
3.8 Weather Information U2
Information information service
Geographical
Geospatial information
Information 3.9 U2
service
Service
Population Population density
3.5.1.1 U2
density map map
Electromagnetic Electromagnetic
interference 3.5.1.2 interference U2
information information
Navigation
Navigation Coverage
Coverage 3.5.1.3 U2
information
information
Communication
Communication
Coverage 3.5.1.4 U2
Coverage information
information
Procedural
Procedural interface
interface with 3.17 U2
with ATC
ATC
Collaborative
Collaborative interface
interface with 3.18 U3
with ATC
ATC
Vertical
Conversion 3.19 U3
Service
Vertical Alert and
Information 3.20 U3
Service
Table 7: U-space Services cross reference
Notes:
Network Identification is a U2 service described in EU IR 2021/664 [8] . It partially matches the Remote
ID requirement of EU IR 2019/947 [4]
EU IR 2021/664 [8] lists seven services. They are:
1. Common Information Service

2. Network Identification service
3. Geo-awareness service
4. UAS flight authorisation service
5. Traffic information service
6. Weather information service
Page 76
(EDITION 4)
7. Conformance monitoring service
Numbers 2 to 7 are to be provided by U-space service providers (USSP). Number 1 may be provided by
a designated Common information service provider (CISP), or if none is designated, then it is also
provided by USSPs. Numbers 1, 2, 3, 4 and 5 are mandatory in all U-space airspaces. The competent
authority may mandate number 6 and or number 7 in any U-space airspace.
The definitions of the EU IR 2021/664 services are extremely brief. More detail is provided in the
associated Acceptable Means of Compliance and Guidance Material [11].
The following diagrams put the U-space services of this ConOps into the perspective of the obligations
of EU IR 2019/947 and the services in 2021/664. Pink  Regulation, Green  U-space ConOps Edition
4, Blue  other.
Article 15 Article 14 Annexes:

Geographic Zones Registration Identification
Drone Aeronautical
Direct Identification Network Remote
Information Geo-awareness Registration
UAS capability Identification
Management
User interaction: On-line queries / position reporting

“CRUD” interoperability subservice
Figure 15 EU IR 2019/947 and U1 U-space services
Article 5 Common Article 4 DAR Article 8 Network Article 9 Geo-

Information Service 665 Article 1(3) Identification awareness
Geo-awareness
USSP catalogue U-space airspace (Surveillance) Identification Geo-awareness
bounds
Drone Aeronautical
Dynamic Airspace Surveillance data
Information Tracking
Reconfiguration exchange
Management
Figure 16 EU IR 2021/664 (default), 2021/665 and U2/U3 services (1)
Page 77
(EDITION 4)
665 Common
Article 13
Article 10 Flight Information Service Article 11 Traffic Article 12 Weather
Conformance
Authorisation 666 Electronic Information information service
Monitoring
Conspicuity
Strategic conflict Dynamic capacity Emergency Emergency

U-plan processing Traffic Information Monitoring
detection management Management Management
Strategic conflict Tracking Surveillance data

resolution Position reporting exchange
Figure 17 EU IR 2021/664 (default), 2021/665, 2021/666 and U2/U3 services (2)
Accident / Procedural
Service
Incident Interface with Geographic
monitoring
Reporting ATC
Navigation Communication
Geospatial Communication
Legal recording Infrastructure infrastructure
Information coverage info
monitoring monitoring
Population Electromagnetic
Digital log book
density map interference map
Navigation
coverage info
Figure 18 U2/U3 services not linked to European regulations 2019/947 or 2021/66[456].
Figure 15 to Figure 18 show the complex relationship between EU regulations and the ConOps services.
Some ConOps services appear more than once. This complexity results from the different purposes
and needs of a concept of operations and a regulation, and also the obligation on Edition 4 of the
ConOps to evolve from Edition 3 which has been widely used in the research community.
Page 78
(EDITION 4)
4 Flight rules
This section briefly introduces the topic of the rules of the air for flights receiving U-space services. This
topic is the subject of ongoing work as this edition of the ConOps is being prepared and this section
will be enlarged in the next edition.
4.1 Rules of the Air

ICAO Rules of the Air date back to October 1945 when the first international recommendations for
Standards, Practices and Procedures for the Rules of the Air were established and ultimately amended
into Annex 2 [13]. The Standardised European Rules of the Air (SERA) [12] includes the transposition
of Annex 2 into European law. The legislative framework for SERA includes Regulations (EU) 923/2012
[12], amendment Regulations (EU) 2016/1185 [52] and the Aviation Safety (Amendment) Regulations
2021 [51] applies to all European Union states and the United Kingdom (as per the EU Withdrawal Act
2018 [50]). Additional flight rules are also applied at the state-level (for example the UK’s Air Navigation
Order [49]), which are designed to align with SERA and ICAO standardisation.
There are two distinct flight rule categories defined in Annex 2 [13] and SERA [12] :
 Visual Flight Rules (VFR); flown in Visual Meteorological Conditions (VMC),

 Instrument Flight Rules (IFR); flown in either Visual or Instrument Meteorological Conditions
(IMC).
Special VFR is more of an exception-based rule set, for VFR flights that do not meet the requirements
for VFR (typically VFR minima) when operating in controlled airspace.
4.1.1 Avoidance of collisions

Annex 2 [13] Section 3.2 explains the rules of the air related to avoiding collisions.
 Section 3.2.1 requires that aircraft not come too close to other aircraft
 Section 3.2.2 on right of way describes decisions and actions based on assessments of the
relative positions and motions of other aircraft
In Visual flight rules, there is the expectation that the pilot of each aircraft is aware of what is around
their aircraft by means of sight.
Annex 2 [13] chapter 5 describes instrument flight rules. In essence the flight either benefits from a
separation service or traffic information.
4.2 UFR
This section contains a proposal which is currently of low maturity.
U-Space Flight Rules (UFR) are intended to apply uniquely to airspace users in receipt of U-Space
services within U-Space airspace. Aircraft and pilots that adhere to standardised U-Space equipment
interfaces, and operate within U-Space Airspace Volumes, are expected to operate under UFR.
Page 79
(EDITION 4)
The aim of UFR is to be a flight rule that works for remotely piloted aircraft, without the pilot being
able to look out of the window. Instead, the pilot should be informed about the relative positions of
aircraft by other means.
The principle behind UFR is to enable aircraft operations that cannot conform to VFR, SVFR or IFR in
all operational conditions. Whilst in some operating cases it is possible for UAM to operate under VFR
if piloted as visual line of sight (VLOS), however, more advanced UAM use cases may not be capable of
“see and avoid” procedures if the aircraft are uncrewed. Likewise, UAM may be accommodated by IFR
in some instances, however, their separation minima may not be suitable for effective operations in
more congested airspace, such as the CTR. The aircraft participating under UFR are therefore required
to be supported by a set of U-Space services for a particular airspace volume. The required U-Space
services and their interface with other ATS depends on the airspace classification.
UFR is for operations in U-space volumes for airspace users that are consuming U-space services. UFR
is based on deconfliction service(s) for separation provision (safety layer 1). These would be strategic
deconfliction or both strategic and tactical deconfliction. On-board technologies (DAA/SAA) for
collision avoidance would provide a further safety net (safety layer 2).
It shall be expected that aircraft conforming to UFR are required to:
 be Electronically Conspicuous to the ground system(s) and to other aircraft within the U-
Space Airspace,
 be in receipt of a traffic information service(s), as required, with respect to other aircraft,
 adhere to any [Digital] ATS clearance/instruction deemed necessary by the controlling
authority,
 have any air traffic separation service managed by a U-Space service.
Aircraft operating under UFR are not expected to receive voice communications from ATS units.
U-Space Mandatory Zone: aircraft operating in a U-Space Mandatory Zone (UMZ) shall be required to
make their position known to U-Space through a defined procedure. States shall be responsible for
defining the required process for making aircraft Electronically Conspicuous to U-Space.
Page 80
(EDITION 4)
5 Examples of using U-space services

Five flights are expanded here to show how the Operating Environment, Services and Flight Rules
apply. The DACUS project’s deliverable on the Drone DCB Concept and Process [29] has identified three
general types of operations with different characteristics:
Surveillance operations are distinguished by mostly larger trajectory patterns and

possibly repeating schemes to effectively monitor larger areas or points of
interest. It is expected that most of these operations will not be performed in close
range of any structures and therefore will be deployed in higher altitudes within
very low-level airspace. Typical examples for this type are aerial mapping, traffic
monitoring or applications in public safety and security;
Inspection operations. They refer to all business models that practically require a
close approach to the point of interest and for the whole execution of the mission
task, e.g., the automated recognition of structural damage to a surface with
optical methods. Contrary to surveillance operations, this type of mission can be
expected to stay inside a defined and foreseeable containment area that is
comparably small and near the observed structure. Further examples for this case
are the inspections of solar power, cell towers or target-oriented photography;
Transport operations. They are characterized by a point-to-point flight scheme

and the actual transport of goods or persons. The cruise flight in this type is
mostly distant to structures but straight forward and optimised on efficiency to
reach a certain destination. It is likely that loading and unloading requires an
approach to the ground and/or solid structures. Besides the industrial and private
transportation of goods, this operation type also covers medical transport (e.g.,
medication or first responder equipment) or the carriage of persons in personal air
vehicles.
Five examples will consist of:
 Architectural photography, an example of Inspection, VLOS

 Aerial mapping, an example of Surveillance
 Power line inspection, an example of Inspection, BVLOS
 Pharmaceutical delivery, an example of Transport
 Air taxi, remotely piloted, an example of Transport
These five examples build in complexity.
5.1 Architectural photography

The photography mission is VLOS. The building to be photographed stands in an area that is enclosed
by a fence, hence people can be excluded. The ground around the building is approximately the same
altitude all over with respect to mean sea level. The missions are flown “by hand” by a pilot /
photographer wearing first-person-view goggles. An observer stands beside the pilot and scans the sky
visually. The flight is planned because it takes place in a Y volume (see 2.3.5.3) an airspace for which
planning is mandatory.
Page 81
(EDITION 4)
The plan consists of a single 4D volume, from ground level to 50m above ground, covering a square on
the ground of side 200m with the building at the centre, lasting from 7pm to 8pm local time. The
operation will involve what appears to be unpredictable flight within the volume including periods
when the aircraft is on the ground for battery changes.
5.1.1 Pre-flight
The drone-photographer is asked if she can take pictures of a hotel which stands in its own gardens.
The photographer studies the location using the Geo-awareness service 3.4.2, considers the
customer’s wishes and decides the work can be done as an “open” category mission.
The photographer uses a relatively simple U-plan Preparation / Optimisation service 3.5.1 to prepare
and submit the plan mentioned above; an hour long period in a “box” around the hotel during the
‘golden hour.’ The plan is sent the day before flight.
The plan is received by the Flight Authorisation service, 3.5.2. An acknowledgement comes back
confirming the conditions applicable to the flight, notably which services should be used (see
2.3.5.3.3), what the technical requirements are. These same conditions are published per airspace but
the acknowledgement serves as a reminder and makes the conditions contractual.
On the day of flight, the photographer and her assistant drive to the hotel. They check the status of
the plan and if it has passed RTTA with no conflicts see 2.2.3.2.3.
5.1.2 In flight
Using the Flight Authorisation service, 3.5.2, the photographer activates her flight and commences the
tactical services required for the airspace, in this case
 network identification service, 3.3.1

 traffic information service, 3.14
 emergency management, 3.12
 monitoring, 3.10
With the assistant, the pilot flies the drone and takes pictures.
In this example flight there are no unexpected events.
5.1.3 Post flight

Using the Flight Authorisation service, 3.5.2, the photographer ends her flight. The tactical services
end.
The photographer and her assistant pack up and leave.
Later the photographer checks the details of the flight from the digital logbook.
Page 82
(EDITION 4)
5.2 Aerial mapping

The drone operator has received an order from a regular customer to collect the data to enable the
production of an aerial map of a region of about 1km x 1km. The work consists of taking a large number
of photographs of the specified region from different angles ensuring that every point on surface has
been photographed from three angles9. The precise location at which each photograph is taken must
be recorded. The work involves a drone carrying quite a lot of equipment for positioning and image
recording.
The flight is flown following a pre-programmed trajectory that scans over the region of interest. It is
flown as a BVLOS flight, within an area, even though the aircraft may be visible to the operator much
of the time. The interventions available to the operator are to deviate following a tactical separation
instruction, to return to base and to restart the mission from the last ‘good’ point.
The airspace in which the flight occurs is Zu.
5.2.1 Pre-flight
The operator uses a relatively sophisticated U-plan Preparation / Optimisation service, 3.5.1, to
develop a U-plan (or series of U-plans) that meet the needs of the mapping task. That tool makes use
of the Geo-awareness service, 3.4.2, a Population density map service, 3.5.1.1, and a Risk Analysis
Assistance service, 3.5.1.5, to minimise the risks associated with the operation. The Operator has a
Light UAS operator Certificate (LUC), see EU regulation 2019/947 [4]. The U-plan Preparation /
Optimisation service also checks for risks to the flight by making use of services providing
Electromagnetic interference information, 3.5.1.2, Navigation Coverage information, 3.5.1.3 and
Communication Coverage information, 3.5.1.4.
Once the U-plan seems optimal from a business and risk consideration, the U-plan Preparation /
Optimisation service submits the U-plan to the Flight Authorisation service, 3.5.2. The U-plan describes
large blocks of airspace being occupied in sequence. The operator is informed that the U-plan is
accepted.
At RTTA the operator is informed that the flight is involved in a demand-capacity imbalance at one
point and has been suspended. The system proposes several solutions. The operator prefers to change
the sequence of scanning the area of interest and submits a revised plan which is accepted.
5.2.2 In flight
Using the Flight Authorisation service, 3.5.2, the operator activates the U-plan and commences the
tactical services required for the airspace, in this case

 monitoring, 3.10, including conformance monitoring service, 3.10.1
 tactical conflict prediction service, 3.6.1
9
Detail invented for the sake of the story.
Page 83
(EDITION 4)
 tactical conflict resolution service, 3.6.2

 weather information, 3.8
 navigation infrastructure monitoring, 3.15.1
 communication infrastructure monitoring, 3.15.2
 vertical alert and information service, 3.20
The pilot prepares the UAS and starts the flight.
During the flight the pilot monitors the flight operations and the achievement of business objectives
while U-space information is overlaid on the flight display. The pilot receives tactical separation
instructions form U-space in a form that can be directly uploaded to the aircraft.
The pilot’s flight management system records which business objectives have been met and collects
any which have not been met due to tactical interventions to allow the generation of a new U-plan to
“fill the gaps.”
5.2.3 Post flight

Using the Flight Authorisation service, 3.5.2, the pilot ends the flight. The tactical services (listed above)
end.
After the aircraft has been powered off and made secure the pilot checks the digital logbook, 3.16, to
confirm the details.
5.3 Power line inspection

The operator has a contract to inspect a number of power lines periodically. Following the schedule in
the contract as well as the weather and any reports of exceptional situations, the operator plans a line
inspection flight. The flight is BVLOS consisting of three parts. The aircraft flies to the start point of the
inspection. The flight then follows the powerline while cameras and other sensors relay information
back to the operator. When the operator’s attention is drawn, the flight may linger at a point on the
line. Finally, the aircraft flies to a landing site. The airspace is all Y volume. The operation is specific
category. The operator has an existing SORA approved for this flight.
5.3.1 Pre-flight
The operator has flown this inspection before. The operator uses an U-plan Preparation / Optimisation
service, 3.5.1, to recheck and if necessary, update the U-plan for the inspection. That tool makes use
of the Geo-awareness service, 3.4.2, the Weather Information service, 3.8, and a Risk Analysis
Assistance service, 3.5.1.5, which helps the operator check that the SORA is still applicable.
The U-plan Preparation / Optimisation service submits the U-plan to the Flight Authorisation service,
3.5.2. The U-plan describes a sequence of tubes of airspace being occupied in sequence, with growing
uncertainty in the entry and exit time as the flight continues. The operator is informed that the U-plan
is accepted.
Page 84
(EDITION 4)
At RTTA the operator is informed that the flight conflicts with more than one other flight and has been
suspended. The system proposes several solutions including a delayed start. The operator updates the
U-plan to match the proposed delayed start and it is accepted.
5.3.2 In flight
tactical services required for the airspace, in this case:

The pilot prepares the UAS and starts the flight.
During the flight the pilot monitors the flight operations and inspects the power line while U-space
information is overlaid on the flight display. At times the operator pauses to record additional details.
5.3.3 Post flight

end.
After the aircraft has been powered off and made secure the pilot checks the digital logbook, 3.16, to
confirm the details.
5.4 Pharmaceutical delivery

The drone operator has a contract with a number of hospitals, medical laboratories, clinics and a few
pharmacies in a city. Each location has a vertiport suitable for the small UAS used by the operator. The
operator has developed a network of routes between these vertiports. In some cases there are
multiple routes between the vertiports. These routes follow regions of lower ground risk.
The operations are a mix of planned in advance and on demand services, always over known routes
between known end points. The flights are certified category operations. The airspace is a mix of Zu
and Y.
5.4.1 Pre-flight
The operator receives a request for an urgent delivery of pharmaceuticals from a pharmacy to a clinic.
There happens to be a suitable UAS sitting waiting at the pharmacy. A pharmacist is collecting the
pharmaceuticals as the operator prepares the U-plan. The expected activation time of the flight is in
three minutes. The operator uses an U-plan Preparation / Optimisation service, 3.5.1, which is
programmed with the vertiport and route-network. That tool makes checks the possible routes using
Page 85
(EDITION 4)
the Geo-awareness service, 3.4.2 and the Weather Information service, 3.8. To choose the fastest
route, the U-plan Preparation / Optimisation service calls the Flight Authorisation service in “test”
mode for each route with different start times to find the fastest. A suitable combination of start time
and route is identified and submitted to the Flight Authorisation service, 3.5.2. At RTTA the operator
is informed that the flight is conflict free. The pharmaceuticals are loaded on board and the UAS
checked. The destination is advised of the arrival time.
5.4.2 In flight

The pilot starts the flight. During the flight the pilot monitors the flight operations while U-space
information is overlaid on the flight display. In the Y volumes the pilot monitors traffic information, in
Zu, the pilot receives tactical separation instructions form U-space in a form that can be directly
uploaded to the aircraft.
As the UAS approaches the clinic, the flight management system warns the clinic of the imminent
arrival. A member of staff is standing by as the UAS lands.
5.4.3 Post flight

end.
The aircraft has been powered off and made secure and then the pharmaceuticals are unloaded.
5.5 Passenger carrying, remotely piloted, scheduled.

In the first of two passenger carrying operations, a scheduled services is considered.
A UAS operator focusing operations on making the best use of the vertiport may adopt the approach
of operating flights according to a schedule. (See 2.2.2.3, third case.) Flights follow a predetermined
route network visiting known vertiports. The air operations are carefully planned to turn around
quickly so as to maximise the utility of the vertiport. Passengers buy tickets to occupy seats on
scheduled flights.
Page 86
(EDITION 4)
The planning is made long in advance. The operations are certified. The airspace is a Zu volume.
Vertiports will have associated arrival and departure routes which will be determined by the needs of
safety and social acceptability.
5.5.1 Pre-flight
The operator plans an entire day at a time, fitting together all the flights so as to optimise vertiport
use. Each flight is planned with some margin for tactical changes, but that margin is limited in the
interest of maximising the optimisation. The operator uses an U-plan Preparation / Optimisation
service, 3.5.1, of great sophistication which models the vertiport operations and multiple flights by the
whole fleet of aircraft.
So as to minimise the risk of conflict, flights are planned using four dimensional volumes of the
minimum size.
The U-plan Preparation / Optimisation service submits plans to the Flight Authorisation service, 3.5.2.
At RTTA for each flight the operator is usually informed that the flight is conflict free. In cases where
there is a conflict, strategic conflicts are generally solved by speed and route changes, attempting to
keep take-off and landing times undisturbed. When this is not possible, the U-plan Preparation /
Optimisation service, 3.5.1, may update many flights to coordinate the overall schedule.
The pre-flight phase will include the boarding of passengers. Systems or an agent at the vertiport will
signal to the remote pilot that the passengers are on board, the doors are closed.
5.5.2 In flight

information is overlaid on the flight display. The pilot may communicate with the passengers, either
directly or via a staff member dedicated to passenger relations.
In Zu, the pilot receives tactical separation instructions form U-space in a form that can be directly
uploaded to the aircraft. The pilot strives to maintain the planned arrival time. When the planned
arrival time is in jeopardy, the operator may update the plan to operate at higher speed. When tactical
manoeuvres delay the flight beyond the planned margin, the operator will replan the operations at the
arrival vertiport and perhaps beyond.
Page 87
(EDITION 4)
The pilot constantly monitors the state of the aircraft and the status of both the nearest vertiport and
the destination vertiport. The pilot maintains contingency plans throughout the journey to allow safe
landing with different degrees of urgency.
As the UAS approaches the arrival vertiport, the pilot checks the availability of the destination. The
aircraft follows a standard arrival path and touches down.
5.5.3 Post flight

end. The aircraft is made secure. A member of the ground staff opens the doors of the aircraft and
those passengers who have reached their destination exit the aircraft.
5.6 Passenger carrying, remotely piloted, on demand.

In the second of two passenger carrying operations, an on-demand services is considered.
It may be that passengers might use a phone app or web page to investigate and then order air-taxi
journeys. The process would probably resemble current ride-hailing apps where the customer requests
a start point and a destination and in return is offered a price, an estimated departure time and an
estimated arrival time. In this example the start and end points are vertiports of which we assume
there are many.
The operations are certified. The airspace is a Zu volume. Vertiports will have associated arrival and
departure routes which will be determined by the needs of safety and social acceptability.
5.6.1 Pre-flight
On receiving a request, the ride hailing app will investigate availability of the vertiports and the
candidate aircraft. Optimisations involving multiple passengers may be possible but are out of the
scope of this simple example. The ride-hailing app is likely to interface with the UAS operator’s U-plan
Preparation / Optimisation service, 3.5.1, which is programmed with the vertiport and route-network
and is likely to call the Flight Authorisation service in “test” mode for possible each route to find the
best trade-off between speed, cost and so on.
Once the passenger has converted the enquiry into an order, the U-plan can be submitted to the Flight
Authorisation service, 3.5.1. If the flight is in conflict, then the business logic of the app / operator will
determine what solution to follow – one involving more time or more cost.
The plan is simultaneously submitted to the departure and arrival vertiports.
At RTTA, which is presumably very soon after the U-plan is submitted, the operator is usually informed
that the flight is conflict free. In cases where there is a conflict, strategic conflicts are solved as
previously described using the business logic of the operator to balance cost vs time while meeting the
constraints agreed with the vertiports. On occasions this whole process will fail to meet the
expectations of the customer and a process of apology may be needed.
The customer arrives at the departure vertiport and is guided on to the aircraft. Systems or an agent
at the vertiport will signal to the remote pilot that the customer is on board, the doors are closed.
Page 88
(EDITION 4)
5.6.2 In flight

information is overlaid on the flight display. The pilot may communicate with the passenger(s), either
directly or via a staff member dedicated to passenger relations.
In Zu, the pilot receives tactical separation instructions form U-space in a form that can be directly
uploaded to the aircraft. The pilot strives to maintain the planned arrival time. When the planned
arrival time is in jeopardy, the operator may update the plan to operate at higher speed. When tactical
manoeuvres delay the flight beyond the planned margin, the operator will replan the operations at the
arrival vertiport and perhaps beyond.
The pilot constantly monitors the state of the aircraft and the status of both the nearest vertiport and
the destination vertiport. The pilot maintains contingency plans throughout the journey to allow safe
landing with different degrees of urgency.
As the UAS approaches the arrival vertiport, the pilot checks the availability of the destination. The
aircraft follows a standard arrival path and touches down.
5.6.3 Post flight

end. The aircraft is made secure. A member of the ground staff opens the doors of the aircraft and
those passengers who have reached their destination exit the aircraft.
Page 89
(EDITION 4)
6 Social acceptability
This section provides some suggestions on how to improve the societal acceptance of the UAM
operations. Societal acceptance of Urban Air Mobility is a key requirement for the economic growth
foreseen in the European Drones outlook study to happen [30].
As defined in section 1.1 a ConOps is the description of the characteristics of a proposed system from
the viewpoint of an individual who will use that system. The system is the U-space supporting the UAM
operations and the individuals that will use the system are all the involved stakeholders, specially
including the citizens.
The section follows a similar structure to the ConOps. First a description of the (urban) operating
environment is given, including most relevant knowledge extracted from public surveys. Then the
Phases of the flight is used to propose actions to improve societal acceptance. Airspace and ground
infrastructure contain some hints about their design. Finally, a subsection on U-space and its services
proposes requirements coming from the public.
6.1 Operating Environment

The operating of UAM operations includes, by definition, urban areas. The limitations in altitude
imposed to UAM operations, to avoid interaction with crewed aviation, sets these operations to occur
very close to the ground. And the ground in urban areas is mostly populated. In summary, UAM will
operate very close to people and buildings.
An increasing number of surveys have been collecting the citizens opinions about uncrewed aircraft
since 2015 [31], with special focus in UAM since 2018 [32]. For the European case it is especially
relevant the EASA survey [33] and posteriori surveys conducted by other SESAR and EU projects
(AiRMOUR, ASSURED-UAM, U-space4UAM, AMU-LED) to European citizens and experts.
According to the surveys the acceptance rate of UAM terms, such as drones, air-taxis, UAM, aerial
delivery, etc., is between 45% to 85%. In the EASA survey the term urban air mobility reached was
labelled as positive by 83% of the responders.
In all surveys the rate of acceptance is higher for medical urgent services and for public services, such
as search and rescue, critical infrastructure maintenance and emergency response. In fact, most police
departments are already including drones as a new tool on their services.
The public observes as main benefits:
 Fast services,
 Environmentally friendly, and
 Providing extended connectivity to the busy urban transport systems.
Some surveys taken from 2021 move the focus of the questions from the citizens as passive observers
to potential customers of the UAM services. The willingness to use drone delivery services is in 58%
while the passenger experience is only attractive to 27% of the citizens of the EASA survey.
Demographics tests of surveys demonstrate the influence that age, gender, education, economical
wellness and knowledge have in the level of acceptance. Elders are less positive than young people.
Page 90
(EDITION 4)
Men show more enthusiasm in adopting UAM than women. Economic wealthiness and educational
degree have a direct relation with UAM acceptance. Same applies for the level of knowledge about the
UAM technologies, the more knowledge, the higher acceptance. As an example, the rate of willingness
to use drone delivery services for the 66 experts participating in the first CORUS XUAM workshop was
% while the passenger experience is only attractive to 27% of the citizens of the EASA survey.
Although most than 90% of the people declared to have heard about drones, only a 2% declared to
have personal experience in 2017. The sources of information are generally mass media (news, movies,
social media, etc.)
Changes on public’s opinion have occur when they are involved in UAM operations. In Dublin, the
Manna experience in delivery using drones, resulted in one of the highest acceptance rate (84%) of
drone delivery [34]. Drones for public services obtain acceptance of 92-97%. The AMU-LED project
detected 75% changes in opinion when comparing the answers before and after the participation in
UAM air-taxis demonstration [35]. An increase of the acceptance is also reported by U-space4UAM
after conducting 215 demonstration flights.
Surveys show also the public’s concerns. With slight differences on the percent, all point to the same
concerns:
 Malfunction / safety
 Nuisance / environment
 Misuse / security and privacy
Safety concerns are raised in higher degree by airspace users and experts. Safety is the main focus of
AESA regulation and U-space provision. Citizens show also concerns about malfunctioning aircraft
falling. In general, after the participation in a flight demonstration the level of concern decreases.
Nuisance includes a number of negative effects for the environment, wildlife and people’s health.
Airspace users and experts have long experience in this area. With UAM the noise, affecting today only
populated areas close to airports, can expand all across the cities. The electric power of most UAM
aircraft improves the gas emissions and noise footprint. But the shorter distances from UAM aircraft
to citizens has the contrary effect. UAM aircraft are also more silent and slower than commercial
aviation, reducing the negative effects to wildlife and people, but many unknowns are still to be
investigated.
Misuse of drones, especially of small ones with cameras, are seen as a security breach. Citizens image
them in the hands of thieves, terrorists or spies, compromising their home, life or privacy. In the era
of Internet, the effect of potential cyber-attacks on good-intentioned aerial vehicles are also part of
this concern. While safety and nuisance concerns are well-known concerns in aviation, misuse is in
generally new to air space, with the exception of some well-known episodes of kidnapping of aircraft.
As happened with the degree of acceptance, the exposition and knowledge of UAM has proved to have
also an effect on the concerns. In the Dublin experience the concern on privacy raised to 75%. After
demonstrations of air-taxis in ASSURED-UAM the noise concern was also higher than before.
Other concerns are informed in special situations:
 In surveys focusing on drone delivery another concern that appears is the damage produced
to (or from) the cargo.
 Liability is also a concern in case of incident/accident.
Page 91
(EDITION 4)
 The limitations introduced by regulation is a major concern for stakeholders after having
participated in a demonstration.
 Finally, a full level of automation is an issue generally raised by the lack of confidence in
artificial intelligence.
6.2 Phases of flight

While social acceptability benefits and the concerns are raised during the tactical phase of flight, it is
the strategic phase that is key to increasing these benefits and to mitigating these concerns.
Long-term decisions that affect the societal acceptance are taken by the UAM operator at the moment
of aircraft design or acquisition. Currently electric powered aircraft are the best option to reduce gas
emissions and the noise footprint, but still decisions about materials use in the design, such as the
reuse of components and recycling, can produce much eco-friendly UAM. Aircraft colour and blades
protection have also a role in visual impact and wildlife protection.
More decisions of strategical long-term phase are related to airspace design and are given in the next
subsections.
Strategic pre-flight phase is responsible of creating the U-plan. Below the list of operational decisions
that can help in performing a more societal-friendly mission [36]:
1. Limit the minimum altitude,

2. Respecting no-fly zones for drones/times,
3. Flight most direct routes to minimise energy and annoyance,
4. Alternate routes to spread noise,
5. Avoid/limit hovering drone flights,
6. Set speed limits according to the area being crossed,
7. Review the urban land use below the flight trajectory.
Decisions such as the flight altitude and flight waiting points (hovering) are very relevant for noise
impact and also for avoiding privacy concerns. Aircraft shall avoid flying by any home window, and to
stop for no evident reason above a private property. Experimental UAM operations in the city were
obtained by virtual and augmented reality and used to evaluate annoyance to humans. Visual, auditive
and safety perception improved always with higher altitudes [37].
To better preserve the environment, direct routes at high altitude are preferred. Meaning high altitude
overflying all urban buildings in the line of site of the drone. High altitude avoids annoyance and privacy
concerns, allow direct routes and consumes less energy. The only exception is but for short-length
flights, to which a high altitude may be less convenient for energy consumption.
Some of the actions, such as the studying ground land usage, are mandatory during the safety
assessment, but unless a no-fly zone, using convenient safety mitigations may allow that the mission
can finally proceed in top of populated areas. Different speeds and altitudes can be defined to preserve
the wellness of all crossed areas.
When a route becomes too much used by sequences of flights, the operator shall study alternative
routes, that even not so energy safe, can help to distribute better the noise. It is well known that
permanent noise disturbances may affect the health of humans and natural life. Searching for alternate
paths for instance for a 2-way trip is a good planning measure.
Page 92
(EDITION 4)
Finally, the post flight phase is very relevant also for environment. A good maintenance execution of
the batteries of the aircraft will lead to longer life and less residuals generation. In the same way, the
correct maintenance and when necessary, replacement of blades will reduce the noise of the future
flights.
6.3 Airspace
The legal requirements of the airspace structure and how these affect the capacity are presented in
section 2.2.1.1. But no further comments are given with respect to societal acceptance.
Other SESAR projects, such as Metropolis and Metropolis 2, have propose and study several airspace
organizations and evaluate them in terms of efficiency. From corridors to free routing, and radial to
perpendicular routes. Segregating by altitudes the different traffic according to their performance
(speed and also noise) is the most convenient way for reducing the noise annoyance. For instance, U-
space4UAM proposed altitude limits of 20 m height for hobbyist while commercial UAM shall fly from
20 m to the U-space airspace upper limit.
Airspace design shall be coherent with city organization to which UAM is serving. Flying over existing
urban transportation vials (rails, highways, rivers and streets) is proposed as safety measure, but it has
several benefits for societal acceptance:
 Perceived noise increment is minimised since the existing urban transportation vials are
already accepted noisy areas and the added noise is less perceived.
 UAM can contribute to the multimode transport system and alleviate the busy urban traffic.
 Avoids the problem of overflying private properties addresses. Private properties can raise
private concerns. Also, some countries grant the owner with full rights up to a give height over
their terrains. In those cases, an aerial flight may require of owner’s permission, including tolls
to use such right [38].
6.4 Ground infrastructure

Section 2.4.1.3 presents the EASA design concept for vertiports [39]. Section 2.4.1.5 present the
concept of Vertiport Traffic Zone. This concept embeds the need of protecting all approach areas and
the set of rules to be defined to ensure safety. Section 2.2.2.3 presents the limitations to the U-plan
(on access, capacity and operation) imposed by vertiports. But none of them addresses the problem
about societal impact of these infrastructures.
Vertiports will concentrate a high number of operations. Moreover, vertiports are the areas at which
flight altitude of UAM operations will be lowest, eventually including stationary phases. In
consequence annoyance of traffic to near neighbours is, after safety, probably the most urgent
element to address and solve to make UAM become a reality.
A number of works have proposed the best location of vertiport [40]. In general, they consider the
potential demand sources, the efficiency for the UAM integration into the multimode transportation
system and the capacity offered by U-space.
Page 93
(EDITION 4)
Focusing on air-taxis, ASSURED-UAM studied the best conditions for urban ground infrastructure.
Major agreements of the experts participating was achieved in the necessity of converting existing
urban infrastructure to cost-effective UAM infrastructure (62%). The involvement of cities to issue
specific regulation for the use of land were also considered important by 59% of the responses.
In summary, vertiports shall be located close to current ground transportation hubs to maximise their
efficiency, utility and acceptability. Areas such as train and bus stations are large wide areas with
potentially few obstacles. They have close by parking areas and are already busy and noisy. The city
knowledge from urban planners is key to propose vertiport facilities on the roof or close to existing
transportation hubs
6.5 U-space infrastructure and services

Section 8.3 shows “General public” as a stakeholder of U-space. General public represents those who
may hear, see or otherwise be concerned by a UAM flight. For them the U-space is expected to provide
traffic information (see Figure 20). Surveys show that it is essential that any citizen can get access to
UAM traffic to mitigate the privacy concern.
In addition, citizens are also the ultimate beneficiary of UAM flights, as drone delivery client or as UAM
passenger. The roles “UAS delivery client” and “UAM passenger” are also direct stakeholders of U-
space, and their acceptability are economical.
The general public are an indirect user of the UAM for HEMS flights. These flights are performed by
law enforcement or emergency responders, but the final goal is always the society.
Page 94
(EDITION 4)
7 Architecture
This section is used to give to the reader an overview of U-space architecture and required evolutions
for UAM. It is not aiming to provide details but the high-level elements and views which are supporting
the concept development and understanding with a focus on UAM.
This section contains the following:
 Architecture principles
 Architecture Framework
 Stakeholders and Roles
 Operational processes and Information Exchanges
 A generic system breakdown
 An explanation of the U-space Portal
7.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.
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 of information, 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 UAS 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.
Page 95
(EDITION 4)
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 implementation options.
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.
7.2 Architecture Framework

Architecting has become a decisive process for the successful development of projects aiming to
capture all the relevant information from different facets to end-up with a complete, consistent and
coherent content. Starting from CORUS project achievements, CORUS-XUAM team has worked to
provide U-space stakeholders with a reference architecture from which to build up a realizable U-space
for UAM 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 for UAM.
As for CORUS project, the European Air Traffic Management Architecture (EATMA10) was selected to
drive the CORUS-XUAM architecture development work. This choice consolidates previous projects
achievements and 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 and other U-space related
projects.
7.3 Stakeholders and Roles

The architecture of a complex system such as that of U-space, brings together different elements and
requires operating procedures that involve numerous "players". For this reason, the U-space 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 mainly looking at safety and performance. For this reason,
this commitment covers various types of organisations, regardless of their size, ownership model,
operational model, or geographical distribution. It includes people, information, processes, and
different technologies.
10
EATMA Guidance Material
https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5b2deab5c&a
ppId=PPGMS
Page 96
(EDITION 4)
In these paragraph two terms are distinguished which help the reader to easily understand the U-space
system. These terms are Stakeholders and Roles. In particular:
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. Therefore, the role element is the means in EATMA to represent the human
being.
The mapping from stakeholder to role can be many depending on the scenario to which it refers. In
the following table the stakeholders identified in the overall architecture are mapped with the
correspondence of roles as indicated in the Operational Framework document:
Stakeholder
UAS operator: is the legal entity, performing one or more UAS operations and is accountable for
them.
UAM operator: is the legal entity, performing one or more UAM operations and is accountable for
them. A UAM operation is an air transportation operation that carries passenger and/or goods. UAM
is a safe, secure and sustainable air transportation system for passengers and cargo in urban
environments, enabled by new technologies and integrated into multimodal transportation
systems. The transportation is performed by electric aircraft taking off and landing vertically,
remotely piloted (in such a case it is a specialisation of UAS operator) or with a pilot on board.
One of the responsibilities is the booking and potentially it can be considered a new stakeholder to
highlight business choices for UAM Booking, in that case it supplies the booking services.
Specialisations are envisaged for the urban air transport such as Air taxi booking service provider
(allowing the general public to book a journey in an air taxi. It offers mobility as a service (MaaS) and
Air delivery booking service provider (allowing anyone who wants to, to book a delivery by air).
UAS manufacturer: has an interest in aircraft and equipment certification processes. The UAS
manufacturer or representative may have a role in U-space registration, for example as the provider
of UAS characteristics and serial numbers.
U-space Service Provider (USSP): This stakeholder provides one or more of the U-space services as
listed in the U-space regulation [8] chapter iv.
A USSP may have suppliers, for example a software supplier. At the level of granularity presented in
the document, such suppliers are considered as subcontractors to the USSP and are not identified
as having a distinct role.
Common Information Service Provider: where applicable, provides the services mentioned in the
the U-space regulation [8] article 5.
The CIS is concerned with the provision of the necessary information for the well-functioning of the
ecosystem. Its objective is to ensure that the information comes from trusted sources and that it is
of sufficient quality, integrity and accuracy as well as security so that the USSPs and other users such
as ASNPs can use this information with full reliability when providing their services.
Supplemental Data Service Provider (SDSP): provides access to supplemental data to support U-
space services. E.g., Weather Data Service Provider, Ground risk observation service provider.
Page 97
(EDITION 4)
Stakeholder
CNS Service Providers (CNS): a provider of Communication, Navigation or Surveillance services.
Air Traffic Service provider: is a provider of air traffic services to airspace users. It can be ATS
Aerodrome or ATS Approach service provider.
Aeronautical Information Service Provider (AISP): The provider of a service established within the
defined area of coverage responsible for the provision of aeronautical information/data necessary
for the safety, regularity and efficiency of air navigation. It has the task of producing the Aeronautical
Information Publication, a collection of data describing the geography and procedures of for flying
in a given country.
(Airfield/Airport) Aerodrome operator (civil, Military): The aerodrome operator is distinct from the
ANSP and has business concerns and legal responsibilities which make them interested in /
concerned by UAS flight and U-space procedures.
Vertiport operator: will provide services at a vertiport. Service provision might vary between
vertiport for private use and public use. It encompasses passenger and Cargo transport
This one operates the facility in a safe and efficient manner including the scheduling of arrivals and
departures as well as supplying U-space with information about the aerodrome’s status and capacity
to accommodate incoming aircraft.
Competent Authority: Generic term to encompass national or local civil aviation authority, or some
entity delegated by them.
 Roles: Registrar, Authorised viewer of air situation, Airspace access authorization Workflow
Representative, Capacity Authority
Authority for safety and security (police, fire brigade, search and rescue orgs): Authorities involved
in preparation and supervision of the operations of law enforcement such as police, security,
military, homeland security that are responsible for law enforcement methods.
Roles: Police or security agent, UAS specific aeronautical information originator
Emergency Responders: Organisations involved in preparation and execution of emergency
operations such as fire brigade, emergency, first aid, Search and Rescue (SAR).
Local and specific authorities: city / region / prefecture / county / canton / state - support the
definition of operating procedures and rules.
U-space Coordinator: (Defined in the Guidance Material to EU IR 2021/664) The U-space
coordinator coordinates the Local and Specific Authorities.
UAS delivery client: The clients of the delivery service
UAM passenger: Generic beneficiary of safe, secure and sustainable air transportation system for
living being e.g. the air-taxi passenger rides in an air taxi UAM operation.
Airspace User (other than UAS/UAM): include scheduled airlines, charter companies, cargo and air
freight service providers, the business and leisure aviation sectors and all forms of non-military air
travel, from hot air balloons through police helicopters to general aviation pilots.
Roles: Pilot, Authorised viewer of air situation
General Public: representing those who may hear, see or otherwise be concerned by a UAS
 Roles: Citizen, Authorised viewer of air situation
Table 8: U-space stakeholders
Page 98
(EDITION 4)
Figure 19 shows as a whole the stakeholders identified in the previous table, aggregating those with
"similar" characteristics together with those who are involved in the U-space, but in an "indirect" way,
such as UAS delivery clients and air taxi passengers.
Figure 19: U-space Stakeholders, shown in aggregation.
7.4 Operational processes and Information Exchanges

From an operational point of view, Figure 20, below 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). Figure 20 mainly
focuses on U-space traffic management operations.
Page 99
(EDITION 4)
Figure 20: 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 are required to be covered in
implementation with the provision and consumption of data by technical systems through U-space
services.
7.4.1 An example of an operational process

In addition to the static information diagram shown in Figure 20, it is crucial to understand the
sequence of activities that have to be performed by the stakeholders in a specific scenario. Like this,
the responsibilities of each stakeholder would be defined.
So far 12 business process models or operational processes have been developed in the context of
CORUS-XUAM. Several of them continue the work presented in the U-space ConOps Ed.3, but others
have been newly defined due to the entrance of the UAM, whose vertiports would play an important
role in the U-space. All these business process models can be consulted in the Section 7.6 U-space
Portal.
Figure 21 illustrates an example of the process defined for the departure from a vertiport is shown.
Page 100
(EDITION 4)
Figure 21: Operational use case for the departure from a vertiport
7.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 or centralised responsibilities for Common Information services and the
interoperability among several USSPs. Deployment solutions envisage the possibility of centralised or
distributed alternatives. This document does not push any position on what shall be centralised and
what can be executed in distributed way.
Page 101
(EDITION 4)
Figure 22: Generic U-space system breakdown
Figure 22 provides an overview of possible interfaces among systems for both monolithic and
federated options.
Supplemental data system is encompassing the MET, Terrain and Obstacles ones. CNS Infrastructure
represents the physical systems for Communication, Navigation and Surveillance including the services
providing information about status and coverage. ATM System includes mainly the AIM system and
Air Traffic service unit systems. More details on the EATMA portal.
Validation and demonstration activities will provide evidence of these architecture options.
7.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-XUAM becomes a critical milestone for
the future work to be performed on U-space.
Therefore, in continuation with CORUS work, CORUS-XUAM team has decided to show the architecture
in a web based portal (https://www.eatmportal.eu/working/signin). This portal shows the CORUS-
Page 102
(EDITION 4)
XUAM SU-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).
Page 103
(EDITION 4)
8 Regulatory context
A detailed examination of the regulatory context of this ConOps can be found in annex to this
document in the “CORUS-XUAM ConOps Annex: regulatory and legal impact study.” This section
summarises that document.
The European regulatory context for “Uncrewed” aviation at the time this document is written is
described here as it influences the contents of this document.
Aviation is subject to national law. National law for aviation is greatly shaped by international treaties.
All European states except Liechtenstein have ratified the Chicago Convention on International Civil
Aviation, the founding document of ICAO. Some national exemptions exist to specific ICAO regulations.
All European Union member states, as well as some other European countries, follow the regulations
developed by EASA, the European Aviation Safety Agency.
“Crewed” aviation is well described in the regulations issued by the two (see references [12], [13], [14],
[15], for example) and corresponding national law. “Uncrewed” aviation is partly covered by these
aviation regulations. Specific regulations for “uncrewed” aviation have been developed by EASA. These
are:
 2019/94711 [4] on the rules and procedures for the operation of unmanned aircraft and its
corresponding acceptable means of compliance and guidance material (AMC-GM) [6]
 2019/945 [5] on unmanned aircraft systems and on third-country operators of unmanned
aircraft systems and its corresponding AMC-GM [7]
 2021/664 [8] on a regulatory framework for the U-space.
 2021/665 [9] amending Implementing Regulation (EU) 2017/373 as regards requirements
for providers of air traffic management/air navigation services and other air traffic
management network functions in the U-space airspace designated in controlled airspace
 2021/666 [10] amending Regulation (EU) No 923/2012 as regards requirements for manned
aviation operating in U-space airspace
 The Acceptable Means of Compliance and Guidance Material (AMC-GM) for 2021/664, 5, 6
[11].
Key points of these European regulations are:
Flights are categorised by risk. The lowest risk are known as Open category, then Specific, then
Certified. There are requirements on the aircraft in order for a flight to be in a given category. See
section 2.2.2.1
Geographic zones may be created to manage (limit or enable) drone flight. These resemble Restricted
Areas. Some geographic zones will require the use of U-space services by UAS operators. These zones
11
European regulations are named for the year they are issued and a sequence number. Either the year or
sequence number may be written first. 2019/947 may be referred to as 947/2019
Page 104
(EDITION 4)
are referred to as U-space airspaces, see 2.3.3. Four U-space services are always mandated: Network
Identification, Geo-awareness, Flight authorisation and Traffic information. The competent authority
may also mandate either of two others; Weather information and Conformance monitoring. A
mapping of the services described in EU regulation 2021/664 to those described in this ConOps can be
found in Table 7.
Current EU regulation seems to cover initial U-space operations with “low” traffic. The expected
evolution of U-space is described in Section 1.4.
Page 105
(EDITION 4)
9 References, Terms, Acronyms

[1] U-space ConOps, 3rd Edition, CORUS Consortium
https://www.eurocontrol.int/project/concept-operations-european-utm-systems
[2] SESAR Joint Undertaking: U-space Blueprint

https://www.sesarju.eu/sites/default/files/documents/reports/U-
space%20Blueprint%20brochure%20final.PDF
[3] SESAR Joint Undertaking: Roadmap for the safe integration of drones into all classes of
airspace. 1st March 2018
https://www.sesarju.eu/sites/default/files/documents/reports/European%20ATM%20Maste
r%20Plan%20Drone%20roadmap.pdf
[4] 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.) https://eur-
lex.europa.eu/legal-content/EN/TXT/?qid=1560259925294&uri=CELEX:32019R0947
[5] Commission Delegated Regulation (EU) 2019/945 of 12 March 2019 on unmanned aircraft
systems and on third-country operators of unmanned aircraft systems https://eur-
lex.europa.eu/legal-content/EN/TXT/?qid=1560259925294&uri=CELEX:32019R0945
[6] Acceptable Means of Compliance (AMC) and Guidance Material (GM) to Commission
Implementing Regulation (EU) 2019/947
https://www.easa.europa.eu/sites/default/files/dfu/AMC%20%26%20GM%20to%20Commis
sion%20Implementing%20Regulation%20%28EU%29%202019-
947%20%E2%80%94%20Issue%201.pdf
[7] Acceptable Means of Compliance (AMC) and Guidance Material (GM) to Part-UAS UAS
operations in the ‘open’ and ‘specific’ categories
https://www.easa.europa.eu/sites/default/files/dfu/AMC%20%26%20GM%20to%20Part-
UAS%20—%20Issue%201.pdf
[8] Commission Implementing Regulation (EU) 2021/664 - https://eur-lex.europa.eu/legal-

content/EN/TXT/?uri=CELEX%3A32021R0664

[10]Commission Implementing Regulation (EU) 2021/666 - https://eur-lex.europa.eu/legal-

[11]Acceptable means of compliance and guidance material for EU regulations 2021/664,

2021/665 and 2021/666 https://www.easa.europa.eu/en/document-library/acceptable-
means-of-compliance-and-guidance-materials/amc-and-gm-implementing
[12]EU Regulation 2012/923, SERA, Standard European Rules of the Air - https://eur-
lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32012R0923
[13]ICAO Annex 2 - Rules Of The Air Annex 2 - Rules Of The Air | ICAO Store
Page 106
(EDITION 4)
[14]ICAO Annex 11 - Air Traffic Services https://store.icao.int/en/annex-11-air-traffic-services
[15]ICAO Annex 14, Aerodromes. https://store.icao.int/en/annex-14-aerodromes
[16]ICAO Heliport Manual – Doc 9261 https://store.icao.int/en/heliport-manual-doc-9261
[17]ICAO Global Air Traffic Management Operational Concept – Doc 9854

https://store.icao.int/en/global-air-traffic-management-operational-concept-doc-9854
[18]ASTM F3548-21 Standard Specification for UAS Traffic Management (UTM) UAS Service
Supplier (USS) Interoperability – see https://www.astm.org/f3548-21.html
[19]Inter-USS: https://github.com/interuss
[20]Airbus (Altiscope): Blueprint for the Sky, The roadmap for the safe integration of
autonomous aircraft, 5/9/18. https://www.utmblueprint.com
[21]JARUS SORA package. http://jarus-rpas.org/content/jar-doc-06-sora-package
[22]OECD Definition of Functional Urban Areas (FUA) for the OECD metropolitan database
September 2013 https://www.oecd.org/cfe/regionaldevelopment/Definition-of-Functional-
Urban-Areas-for-the-OECD-metropolitan-database.pdf
[23]Volocopter’s internal presentation prepared based on discussions in EASA RMT.0230

Working group on Vertiports design
[24]European Union Aviation Safety Agency, ‘Special Condition Vertical Take-Off and Landing
(VTOL) Aircraft’. Jul. 02, 2019. Accessed: Oct. 22, 2020. [Online]. Available:
https://www.easa.europa.eu/sites/default/files/dfu/SC-VTOL-01.pdf
[25]BUBBLES project deliverable 4.1, “Algorithm for analysing the collision risk”.
https://www.bubbles-project.eu/wp-
content/themes/bubbles/Deliverables/BUBBLES_D4.1_Algorithms%20for%20analysing%20th
e%20collision%20risk_Ed_01.01.00.pdf
[26]BUBBLES project deliverable 4.2, “Guidelines to implement separation minima & methods”,
content/themes/bubbles/Deliverables/BUBBLES_D4.2_Guidelines%20to%20implement%20s
eparation%20minima%20and%20methods_Ed_01.00.00.pdf
[27] “Market Design for Drone Traffic Management”, Seuken, Friedrich, Dierks,
https://www.aaai.org/AAAI22Papers/SMT-00225-SeukenS.pdf
[28] ICARUS project https://www.u-spaceicarus.eu/
[29]DACUS deliverable D1.1, Drone DCB concept and process https://dacus-research.eu/wp-

content/uploads/2021/03/DACUS-D1.1-Drone-DCB-concept-and-process_01.00.00.pdf
[30] SESAR JU, “European Drones Outlook Study. Unlocking the value for Europe”, Nov 2016.
[31]Clothier, Reece A and Greer, Dominique A and Greer, Duncan G and Mehta, Amisha M. 2015.
Risk perception and the public acceptance of drones. Risk analysis, 35(6), p 1167-1183, Wiley
Online Library.
Page 107
(EDITION 4)
[32] Hamilton, Booze A, 2018. Final Report Urban Air Mobility (UAM) Market Study, National
Aeronautics and Space Administration (NASA).
[33] EASA, “Study on the societal acceptance of Urban Air Mobility in Europe”, May 2021.
[34]Philip Butterworth-Hayes and Tim McCarthy. Accelerating the potential of drones for local
government - International Best and Emerging Practice Report. Dublin City Council and
Smarts Dublin. May 2022. Available at https://bit.ly/3QbSiB5
[35] Gonzalez P et al. AMU-LED – Air Mobility Urban – Large Experimental Demonstrations SESAR
project. https://amuledproject.eu. Paper to appear at MPDI Aerospace 2023.
[36] Çetin E. et al, “Implementing Mitigations for Improving Societal Acceptance of Urban Air
Mobility”, MDPI Drones 2021.
[37]Maria Stolz and Tim Laudien. Assessing Social Acceptance of Urban Air Mobility using Virtual
Reality. IEEE/AIAA 41st Digital Avionics Systems Conference. 2022.
[38] Famula, J., Pittman D.E., Haring K.S. Building Trust with a Mobile Application for Last-Mile
Commercial Drone Delivery. 2022 Int Conf on Unmanned Aircraft Systems (ICUAS). Croatia
June 2022.
[39]EASA Guidance Material for Design of VFR Vertiports -

https://www.easa.europa.eu/document-library/general-publications/prototype-technical-
design-specifications-vertiports
[40]Schweiger, Karolin, and Lukas Preis. "Urban Air Mobility: Systematic Review of Scientific
Publications and Regulations for Vertiport Design and Operations." Drones 6, no. 7 (2022):
179.
[41]https://www.airbus.com/en/products-services/commercial-aircraft/the-life-cycle-of-an-
aircraft/operating-life
[42]https://www.boeing.com/assets/pdf/commercial/aircraft_economic_life_whitepaper.pdf
[43]InterUSS see https://interussplatform.org/
[44]ASTM F3411 Standard Specification for Remote ID and Tracking

https://www.astm.org/f3411-22.html
[45]AMU-LED project https://cordis.europa.eu/project/id/101017702 also

https://amuledproject.eu/
[46]Gulf of Finland 2 project, D2.4 GOF2.0 VLD Updated Service Specifications, see
https://gof2.eu/deliverables/
[47]AURA project, PJ34, “ATM U-SPACE INTERFACE”. See https://www.pj34aura.com/
[48] MIT Flight Transport Lab Report R82-2 “Aircraft Collision Models” Shinsuke Endoh, May 1982
https://dspace.mit.edu/bitstream/handle/1721.1/68072/FTL_R_1982_02.pdf
[49]Air Navigation Order 2016, UK Statutory Instrument 2016 number 765.

https://www.legislation.gov.uk/uksi/2016/765/contents/made
Page 108
(EDITION 4)
[50]EU Withdrawl Act, UK Public General Acts 2018 c 16

https://www.legislation.gov.uk/ukpga/2018/16/contents/enacted
[51]The Aviation Safety (Amendment) Regulations 2021, UK Statutory Instrument 2021 number
10 https://www.legislation.gov.uk/uksi/2021/10/contents/made
[52]Commission Implementing Regulation (EU) 2016/1185 of 20 July 2016 amending

Implementing Regulation (EU) No 923/2012 as regards the update and completion of the
common rules of the air and operational provisions regarding services and procedures in air
navigation (SERA Part C) and repealing Regulation (EC) No 730/2006 (Text with EEA
relevance) https://www.easa.europa.eu/en/document-library/regulations/commission-
implementing-regulation-eu-20161185
[53]EASA Prototype Technical Design Specifications for Vertiports

https://www.easa.europa.eu/en/document-library/general-publications/prototype-
technical-design-specifications-vertiports
[54]BUBBLES project https://www.bubbles-project.eu
[55]DACUS project https://dacus-research.eu
[56]ICAO Annex 15, Aeronautical Information Services, https://store.icao.int/en/annexes/annex-

15
[57]ICAO Document 4444, Procedures for Air Navigation Services (PANS) - Air Traffic
Management https://store.icao.int/en/procedures-for-air-navigation-services-air-traffic-
management-doc-4444
[58] EC Sustainable and Smart Mobility Strategy https://eur-lex.europa.eu/legal-

content/EN/TXT/?uri=CELEX%3A52020DC0789
The following acronyms appear in the text
Acronym Expansion remarks

AGL Above Ground Level Height measured relative to the ground directly below.
AIP Aeronautical Information A publication issued by or with the authority of a State and
Publication containing aeronautical information of a lasting character
essential to air navigation (ICAO Annex 15 [56]).
AIRAC Aeronautical Information See ICAO Annex 15 [56]
Regulation And Control
AMC-GM Acceptable Means of AMCs are non-binding standards adopted by EASA to
Compliance – Guidance illustrate means to establish compliance with the Basic
Material Regulation and its Implementing Rules.
Guidance Material provides solutions to reach that goal.
API Application Programming Software solution which allows two applications to
Interface communicate.
Page 109
(EDITION 4)

ASTM American Society for
Testing and Materials
ATC Air Traffic Control Used to inform that the control service is provided by an
ATC unit.
ATS Air Traffic Services Three services are provided by Air Traffic Controller,
depending on the airspace class and knowledge of the
traffic: control, information and alert.
BVLOS Beyond Visual Line Of Sight UAS operation where the aircraft is beyond visual line of
remote pilot’s sight.
C2 link Command and Control Link Radio or satellite link between the remote pilot station and
the aircraft.
CCC ConOps Coordination Cell A forum for research and demonstration projects that gave
input to this document.
CIS Common Information Common information service is a service consisting in the
Service dissemination of static and dynamic data to enable the
provision of U-space services for the management of traffic
of uncrewed aircraft.
CNS Communication Navigation Are the foundation of the aviation operational
Surveillance performance, enabling airspace capacity.
CSFL Continued Safe Flight and Continued safe flight and landing means an airplane is
Landing capable of continued controlled flight and landing, possibly
using emergency procedures, without requiring
exceptional pilot skill or strength.
CTR Controlled Traffic Region Volume of controlled airspace set for protecting
departures and arrivals to or from an aerodrome.
DCB Demand and Capacity Process used to minimise disruption and optimises
Balancing operations using powerful, accurate forecasting that
balances demand with capacity allowing to anticipate and
mitigate disruption.
DFR Digital flight rule A term used in what is currently research at NASA
See https://ntrs.nasa.gov/citations/20205008308
EASA European Union Aviation The European Union Aviation Safety Agency (EASA) is an
Safety Agency agency of the European Union (EU) with responsibility for
civil aviation safety.
EATMA European ATM EATMA is the European ATM architecture reference.
Architecture
Page 110
(EDITION 4)

EC European Commission The European Commission (EC) is part of the executive of
the European Union (EU), together with the European
Council. It operates as a cabinet government, with 27
members of the Commission (directorial system, informally
known as "Commissioners") headed by a President. It
includes an administrative body of about 32,000 European
civil servants. The Commission is divided into departments
known as Directorates-General (DGs) that can be likened to
departments or ministries each headed by a Director-
General who is responsible to a Commissioner.
EDAS EGNOS Data Access Service The EGNOS Data Access Service (EDAS) offers ground-
based access to EGNOS data through the Internet on a
controlled access basis. EDAS is the single point of access
for the data collected and generated by the EGNOS ground
infrastructure - mainly Ranging and Integrity Monitoring
Stations (RIMS) and Navigation Land Earth Stations (NLES) -
distributed over Europe and North Africa. See
https://egnos-user-support.essp-
sas.eu/new_egnos_ops/services/about-edas
EGNOS European Geostationary Europe's regional satellite-based augmentation system
Navigation Overlay Service (SBAS). It is used to improve the performance of global
navigation satellite systems (GNSSs), such as GPS and
Galileo in the future. EGNOS was deployed to provide
safety of life navigation services to aviation, maritime and
land-based users. See https://egnos-user-support.essp-
sas.eu/new_egnos_ops/egnos-system/about-egnos
EU European Union The European Union (EU) is a political and economic union
of member states that are located on the European
Continent.
EVTOL Electric Vertical Take Off Electric powered aircraft capable of vertical take-off and
and Landing landing.
FATO Final Approach and Take- Area designed to allow take-off and landing of VTOL
off aircraft.
GAMZ Geodetic Altitude A region of airspace in which Geodetic Altitudes should be
Mandatory Zones used. See 2.3.4
GCS Ground Control Station Part of a UAS. Synonymous with Remote Piloting Station
GME Ground Movement
Equipment
GNSS Global Navigation Satellite With a global coverage, the system allows satellite
System navigation everywhere on earth.
HEMS Helicopter Emergency Helicopter in charge of moving patients from an area to
Medical Service another. It could be from an accident scene to a healthcare
facility such as hospital or between two hospitals for
instance.
Page 111
(EDITION 4)

HMI Human Machine Interface The Human Machine Interface allows interactions between
a machine and a human in charge of using it.
ICAO International Civil Aviation A United Nations agency in charge of proposing and
Organization recommending principles and techniques in order to foster
and harmonize aeronautical practices in the world.
IFR Instrument Flight Rules Defined in ICAO Annex 2 [13]
JARUS Joint Authorities for Group of experts from the National Aviation Authorities
Rulemaking on Unmanned (NAAs) and regional aviation safety organizations. Its
Systems purpose is to recommend a single set of technical, safety
and operational requirements for the certification and safe
integration of Unmanned Aircraft Systems (UAS) into
airspace and at aerodromes (source JARUS LinkedIn page).
LUC Light UAS operator Certificate issued to a UAS operator by a competent
Certificate authority (see COMMISSION IMPLEMENTING REGULATION
(EU) 2019/947 of 24 May 2019 on the rules and procedures
for the operation of unmanned aircraft, part C).
Maas Mobility as a service A shift from personally owned transport to mobility
consumed as a service
MET METeorology What is related to meteorological data and information.
MSL Mean Sea Level Heights above Mean Sea Level have equal gravitational
potential.
NOTAM Notice to Airmen See ICAO Annex 15 [56]
OECD Organisation for Economic Intergovernmental organization which goal is to stimulate
Co-operation and economic progress and world trade.
Development
POB Pilot On Board A (hopefully) unambiguous term to indicate an aircraft
which has its pilot on board. May appear as POBA; Pilot On
Board Aircraft. Contrasts with UAS
PVT Position Velocity Time Third mode of motion, position-velocity-time (PVT) mode,
allows the same ease of coordination as contour mode, but
removes velocity discontinuities.
RPS Remote Pilot Station Part of the UAS or RPAS, such as the RP (remote pilot) or
the RPA (remotely piloted aircraft). RPS encompasses, at
least, the functionalities allowing the remote pilot to steer
and navigate the remotely piloted aircraft.
RPS Remote Piloting Station Part of a UAS. Sometimes also called Ground Control
Station
RTTA Reasonable Time To Act RTTA is an agreed amount of time before the activation of
the U-plan.
SAR Search And Rescue Organisation and operations of localisation and rescue of
people in distress.
Page 112
(EDITION 4)

SDSP Supplemental Data Service Provides access to supplemental data to support U-space
Provider services. E.g., Weather Data Service Provider, Ground risk
observation service provider.
SERA Standardised European SERA is the transposition into law of ICAO Annex 2 (Rules
Rules of the Air of the Air) and parts of ICAO Annex 3 (Meteorology), Annex
10 (Communication Procedures), Annex 11 (Air Traffic
Services) and Doc 4444 (PANS-ATM). (Source
https://www.caa.co.uk/).
SESAR (JU) Single European Sky ATM The SESAR Joint Undertaking is an institutionalised
Research (Join European partnership between private and public sector
Undertaking) partners set up to accelerate through research and
innovation the delivery of the Digital European Sky (source
sesarju.eu).
SORA Specific Operation Risk Methodology to assess the safety risk of a UAS operation in
Assessment the specific category.
SVFR Special Visual Flight Rules Special VFR flight’ means a VFR flight cleared by air traffic
control to operate within a control zone in meteorological
conditions below VMC (Source SERA).
TLOF Touchdown and Lift-Off A load bearing area on which a helicopter may touch down
or lift off (Annex 6 Part III).
UAS Uncrewed Aerial System Also expanded as ‘Unmanned Aerial System.’
A UAS may carry passengers but in normal operations is
being piloted remotely or autonomously.
The term “system” denotes a combination of the vehicle
and other parts needed to make it work such as the
remote piloting station
UAV Uncrewed Aerial Vehicle See UAS
UFR U-space flight rule Defined in this document. See section 4
May be the same as DFR.
UMZ U-space Mandatory Zone Zone in which aircraft shall be required to make their
position known to U-Space through a defined procedure.
USSP U-space Service Provider This stakeholder provides one or more of the U-space
services as listed in the U-space regulation[8]
UTM UAS Traffic Management UTM is a traffic management ecosystem for UAS operation.
VALS Vertical ALert and Alerts pilots of crewed or uncrewed aircraft in any
information Service Geodetic Altitude Mandatory Zones (GAMZ) to any risk of
collision with ground obstacles.
VCS Vertical Conversion Service Ensures the conversion of altitudes between barometric
and geodetic reference systems to both crewed and
uncrewed aircraft in Geodetic Altitude Mandatory Zones.
VFR Visual Flight Rules Defined in ICAO Annex 2 [13]
VLL Very Low level Part of airspace from ground to 500 feet above the ground.
Page 113
(EDITION 4)

VLOS Visual Line Of Sight UAS operation where the aircraft is in sight the remote
pilot.
VTOL Vertical Take-Off and Aircraft capable of vertical take-off and landing (e.g.,
Landing helicopter).
V-TZ Vertiport Traffic Zone Is a zone around a vertiport designed for protecting
vertiport arrivals and departures. This zone is a U-space
airspace.
Table 9 Acronyms
The following terms appear in the text
Term Meaning Source / remarks

Aircraft Vehicle that derives lift from the May have the pilot / aircrew on board or not.
air
Below In the direction towards the
gravitational centre of the earth
Conflict Loss of adequate separation For clarity, when this term is used in this document
between two (or more) aircraft in a general sense, then it refers to a conflict
between two aircraft. When an object is identified
then it will mean a loss of separation between an
aircraft and that object. E.g. “conflict with giraffe”
Conspicuous Visible to or able to be detected The VFR pilot is expected to see other aircraft and
by some implied or identified remain well clear of them. Such aircraft are
observer, typically a pilot. conspicuous to the pilot. U-space makes use of non-
visual means to achieve conspicuousness or as it is
also written, conspicuity.
Crewed aircraft Aircraft with a human pilot (air May also be written as ‘manned aircraft,’ but the
crew) on board term manned is ambiguous about whether the
human on board is able to pilot the aircraft. No
gender is implied.
Drone Aircraft without a human pilot May be any size. Synonym of Uncrewed aircraft and
(air crew) on board UAV
U-plan A plan for a flight in U-space = U-Plan.
Operations in U-space may include recharging /
refuelling / battery-changing stops which may be
inserted into the operation unpredictably. An U-
plan may include more than one take-off / landing.
Uncrewed Aircraft without a human pilot Synonym of Drone. Sometimes shortened to UA. See
aircraft (air crew) on board UAS.
U-plan A plan for a flight in U-space = U-plan.
The term “flight plan” is avoided to stress that the
format of the U-Plan is not that described in ICAO
Doc 4444.
Table 10 Terminology
Page 114
(EDITION 4)
Page 115
(EDITION 4)
Page 116
(EDITION 4)
Page 117
U-space ConOps:
Architecture Annex
Dissemination Level: CO
Grant: 101017682
Topic:
Air Mobility
Edition Date: 14 Apr 2023
Edition: 01.00.00
1
CORUS-XUAM
CORUS-XUAM
This Concept of Operations is part of a project that has received funding from the SESAR Joint
Abstract
U-space is Europe’s traffic management system for Uncrewed Aerial Systems (UAS), also called drones.
The ConOps explains how U-space works from a user’s point of view. This is the fourth edition of the
ConOps and differs for three reasons. This edition attempts to meet the needs of Urban Air Mobility,
including both goods and passenger air transport in urban areas. The European Union has passed
various regulations relating to U-space which have to be considered. Research projects have
completed details missing in the previous editions which are incorporated.
Meeting the needs of UAM focuses on processes at the vertiport, airspace structure and flight rules,
particularly as initial passenger carrying operations with “electric vertical take-off and landing” (EVTOL)
vehicles are expected to have a pilot on board.
The European Union regulations, primarily 2021/664, 665 and 666 define U-space in terms of seven
services, six functional plus “common information.” This ConOps supports that view.
Some research projects bring more precise descriptions of services or processes already mentioned,
for example dynamic capacity balancing (DACUS), and some projects bring new services like altitude
conversion services (ICARUS).
This fourth edition of the U-space ConOps aims to be more succinct than previous editions.
© – 2023 – CORUS-XUAM consortium, except as noted

All rights reserved. 2
Licensed to the SESAR Joint Undertaking under conditions.
Table of Contents
Abstract ................................................................................................................................... 2
1 Introduction ............................................................................................................... 6
1.1 Purpose ......................................................................................................................... 6
1.2 Scope ............................................................................................................................ 6
1.3 Document Structure ...................................................................................................... 6
1.4 Intended readership ...................................................................................................... 7
1.5 Terms, acronyms and abbreviations ............................................................................... 7
2 Drivers ..................................................................................................................... 10
2.1 U-space Blueprint, European ATM Master Plan and U-space ConOps ed.3 Architecture
document ............................................................................................................................... 10
2.2 CORUS-XUAM-XUAM Internal Drivers .......................................................................... 11
2.3 Other U-space projects ................................................................................................ 11
3 Strategic Architecture .............................................................................................. 12
3.1 U-space Capability Model ............................................................................................ 12
3.2 U-space Capabilities..................................................................................................... 14
4 Business Architecture ............................................................................................... 17
4.1 Nodes and Information exchanges ............................................................................... 18
4.2 Business Processes for U-space .................................................................................... 23
5 Service Architecture ................................................................................................. 39
5.1 U-space services .......................................................................................................... 40
5.2 Services aim to achieve Capabilities ............................................................................. 42
5.3 From the conceptual needs to services ......................................................................... 43
6 System Architecture ................................................................................................. 44
6.1 Stakeholders and Roles ................................................................................................ 44
6.2 Evolution of service provisioning in U-space ................................................................. 47
6.3 Some of the fundamental U-space systems .................................................................. 51
7 Data exchange models ............................................................................................. 54
8 References ............................................................................................................... 55

List of Tables
Table 1: Acronyms ................................................................................................................................... 8
Table 2: Terminology ............................................................................................................................... 9
Table 3: U-space Blueprint service levels .............................................................................................. 10
Table 4: Capability descriptions ............................................................................................................ 16
Table 5: Nodes ....................................................................................................................................... 19
Table 6: U1 U-space Services ................................................................................................................ 40
Table 7: U2 U-space Services................................................................................................................. 40
Table 8: U3 U-space Services................................................................................................................. 41
Table 9: Mapping of Services to Capabilities......................................................................................... 42
Table 10: Mapping of Information Exchanges to Services .................................................................... 43
Table 11: Roles ...................................................................................................................................... 47
Table 12: Some U-space systems. ......................................................................................................... 53
List of Figures
Figure 1: U-space levels ......................................................................................................................... 10
Figure 2: Services in each of the U-space levels .................................................................................... 11
Figure 3: U-space Capability Model....................................................................................................... 13
Figure 4: U-space CNS Capabilities ........................................................................................................ 14
Figure 5: U-space information exchanges needs in U1 ......................................................................... 20
Figure 6: U-space information exchanges needed at U2 ...................................................................... 21
Figure 7: U-space information exchanges needed at U3 ...................................................................... 22
Figure 8: Registration of the Professional Pilot ..................................................................................... 24
Figure 9: Registration of the UAS Operator .......................................................................................... 25
Figure 10: Flight Route with ATS clearance ........................................................................................... 26
Figure 11: The Flight Plan with Strategic Deconfliction ........................................................................ 27
Figure 12: Start Up, Taxi and Take Off................................................................................................... 28
Figure 13: Post-flight Operations .......................................................................................................... 29
Figure 14: Landing on a controlled airfield/airport/aerodrome ........................................................... 30

Figure 15: Flight Planning with no CISP involved (e.g., weather, terrain, traffic density, regulations)
............................................................................................................................................................... 31
Figure 16: Tactical de-confliction .......................................................................................................... 32
Figure 17: Network identification, tracking monitoring and traffic information .................................. 33
Figure 18: Strategic DCB Planning Measures Management (U3).......................................................... 34
Figure 19: Passenger ticketing and boarding (U3) ................................................................................ 35
Figure 20: Departure from and arrival to uncontrolled vertiports (no interaction with ATC) .............. 36
Figure 21: Departure from a controlled vertiport towards an uncontrolled vertiport (with ATC
interaction) and vice-versa .................................................................................................................... 37
Figure 22: Nominal arrival to a vertiport (U3) ....................................................................................... 38
Figure 23: Service portfolio classification.............................................................................................. 39
Figure 24: Possible Service Provision in U-space (U1)........................................................................... 48

1 Introduction
1.1 Purpose
This document is used to give to the reader visibility of the final work of architecture development in
CORUS-XUAM which required for ConOps document.
This document is providing indeed high-level views which are supporting the concept development
mainly and proving examples and initial contents for a future reference architecture, not in the scope
of CORUS-XUAM.
Main purpose of this document is to baseline high level architecture views based on comments
received on the intermediate version and outcomes of the validation with the U-space Community.
Not all the different views composing the CORUS-XUAM architecture are shown in this document. It is
intended to show all of them in the eATM Portal (U-space R&D).
1.2 Scope
The scope of this annex is the same as the one of the U-space ConOps.
It presents the description of the U-space architecture for Very Low-level operations from a business
and operational viewpoint, supporting the incremental versions of the business process diagrams. In
addition, it provides an overview of the service and system viewpoints to support bottom–up
coherencies of the concept of operations.
The objective of developing CORUS-XUAM architecture is to support the definition of a Concept of
Operation (the CORUS-XUAM ConOps) and thus provides the foundation for U-space. The architecture
addresses VLL and all U-space service levels. It addresses VLL operations in both uncontrolled (Class G)
and controlled (Classes A, B, C, D, E and F) airspace, such as in and around airports for building
inspections, aircraft maintenance, ILS and or VOR/DME calibration, calibration of runway lighting etc.
1.3 Document Structure

Chapter 1 – Introduction; it is the synopsis of this document.
Chapter 2 – Drivers; it addresses main inputs and architecture principles taken into consideration for
developing the U-space architecture in CORUS-XUAM.
Chapter 3 –Strategic Architecture; it presents architecture elements and views to describe the U-space
architecture from a strategic point of view. It provides the description of the U-space Capability Model.
Chapter 4 –Business Architecture; it presents architecture elements and views to describe the U-space
architecture from a conceptual point of view. It provides the description of the business process
diagrams.
Chapter 5 –Service Architecture; it presents architecture elements and views to describe the U-space
architecture from a service-oriented point of view. It provides the list of the identified services and
their links that present how the services realise the business and supports the strategy.
Chapter 6 –System Architecture; it presents architecture elements and views to describe the U-space
from a system point of view. It provides the description of possible breakdown of the U-space in
systems (in some cases with a further possible breakdown in functional blocks) and their relationships.
Chapter 7 – References; it lists relevant documentation.
1.4 Intended readership

The primary readership for this document is those who have a responsibility for the management and
maintenance of the U-space Architecture and its content. These readers can be divided into the
following groups:
 CORUS-XUAM Members – Those who are responsible for the development of the Architectural
content and those who are involved in other CORUS-XUAM activities which may
review/complement and take as input the architecture developed.
 U-space Project Managers – The managers of other relevant SJU projects which may be
interested in the content that is collected within the CORUS-XUAM architecture and in
providing feedback for ensuring the overall quality and consistency of the U-space
Architectural content.
 S3JU - who wants to have the visibility of the CORUS-XUAM work and contribute to the
architecture definition.
 U-space Community – Those who are stakeholders of the U-space which are interested in the
ConOps and architecture principles and descriptions.
1.5 Terms, acronyms and abbreviations

The following acronyms appear in the text:
Acronym Expansion Remarks

ATC Air Traffic Control Used to inform that the control service is provided by an
ATC unit.
ATS Air Traffic Services Three services are provided by Air Traffic Controller,
depending on the airspace class and his knowledge of the
traffic: control, information and alert.
CIS Common Information Common information service is a service consisting in the
Service dissemination of static and dynamic data to enable the
provision of U-space services for the management of traffic
of unmanned aircraft.
CNS Communication Navigation Are the foundation of the aviation operational
Surveillance performance, enabling airspace capacity.
DCB Demand and Capacity Process used to minimise disruption and optimises
Balancing operations using powerful, accurate forecasting that
balances demand with capacity allowing to anticipate and
mitigate disruption.
EATMA European ATM EATMA is the European ATM architecture reference.
Architecture
EU European Union The European Union (EU) is a political and economic union
of member states that are located on the European
Continent.
EVTOL Electric Vertical Take Off Electric powered aircraft capable of vertical take-off and
and Landing landing.

Acronym Expansion Remarks
FATO Final Approach and Take- Area designed to allow take-off and landing of VTOL
off aircraft.
ICAO International Civil Aviation A United Nations agency in charge of proposing and
Organization recommending principles and techniques in order to foster
and harmonize aeronautical practices in the world.
MET METeorology What is related to meteorological data and information.
NAF NATO Architecture Architecture framework developed by NATO, which is used
Framework as the main reference of EATMA.
RPS Remote Pilot Station Part of the UAS or RPAS, such as the RP (remote pilot) or
the RPA (remotely piloted aircraft). RPS encompasses, at
least, the functionalities allowing the remote pilot to steer
and navigate the remotely piloted aircraft.
RPS Remote Piloting Station Part of a UAS. Sometimes also called Ground Control
Station
R&D Research and First stages of the development of a concept before its
Development industrialisation.
SDSP Supplemental Data Service Provides access to supplemental data to support U-space
Provider services. E.g., Weather Data Service Provider, Ground risk
observation service provider.
SESAR (JU) Single European Sky ATM The SESAR Joint Undertaking is an institutionalised
Research (Join European partnership between private and public sector
Undertaking) partners set up to accelerate through research and
innovation the delivery of the Digital European Sky (source
sesarju.eu).
UAS Uncrewed Aerial System Also expanded as ‘Unmanned Aerial System.’
A UAS may carry passengers but in normal operations is
being piloted remotely or autonomously.
The term “system” denotes a combination of the vehicle
and other parts needed to make it work such as the
remote piloting station
USSP U-space Service Provider This stakeholder provides one or more of the U-space
services as listed in the U-space regulation [10]
UTM UAS Traffic Management UTM is a traffic management ecosystem for UAS operation.
VALS Vertical ALert and Alerts GA pilots, UASs and their pilots in any Geodetic
information Service Altitude Mandatory Zones (GAMZ) to any risk of collision
with ground obstacles.
VCS Vertical Conversion Service Ensures the conversion of altitudes between barometric
and geodetic reference systems to both manned and
unmanned aircraft in Geodetic Altitude Mandatory Zones.
VFR Visual Flight Rules Defined in ICAO Annex 2 [11]
VLL Very Low level Part of airspace from ground to 500 feet above the ground.
Table 1: Acronyms
The following terms appear in the text

Term Meaning Source / remarks
Aircraft Vehicle that derives lift from the May have the pilot / aircrew on board or not.
air
Below In the direction towards the
gravitational centre of the earth
Crewed aircraft Aircraft with a human pilot (air May also be written as ‘manned aircraft’
crew) on board
UAS Aircraft without a human pilot May be any size. Synonym of Un-crewed aircraft and
(air crew) on board UA
Uncrewed Aircraft without a human pilot Synonym of UAS. Sometimes shortened to UA.
aircraft (air crew) on board
U-plan A plan for a flight in U-space
Table 2: Terminology

2 Drivers
2.1 U-space Blueprint, European ATM Master Plan and U-space
ConOps ed.3 Architecture document
As the U-space blueprint [1] makes clear, a U-space Concept of Operations (ConOps) is required,
especially for Very Low-Level UAS operations1 and should describe the services and interfaces that are
necessary to enable full development of the economic potential of UASs while ensuring adequate
levels of safety.
The U-space blueprint [1] defines four levels of services, as shown below. Each level is a package of
related services. CORUS-XUAM will make use of this terminology.
Figure 1: U-space levels
The U-space blueprint [1] lists several services, clustering them into “levels” that differ in terms of their
deployment timeline. The following table summarises the document.
Level Name Target
U1 U-space foundation services 2019
U2 U-space initial services 2022..25
U3 U-space advanced services 2025..30
U4 U-space full services 2030+
Table 3: U-space Blueprint service levels
1
Including operations beyond visual line of sight (B-VLOS), as well as in visual flight rules (VFR) environments. In
accordance with the call, instrument flight rules (IFR) integration will not be addressed.

The U-space Blueprint is a brief document. The European ATM Master Plan UAS roadmap document
provides more detailed description of services and UAS capabilities which constituted one of the main
top-down input taken into consideration in the CORUS ConOps ed.3 architecture [4] development,
which has served as the baseline for the CORUS-XUAM architecture presented in this document and
in the eATM Portal (U-space R&D) [3].
Figure 2: Services in each of the U-space levels
CORUS-XUAM takes these inputs and seeks to:
 Explain how these services are used to ensure safe, efficient operations.
 Provide, where appropriate, more precise descriptions of the services
 Refine the lists of services - as far as is possible today.
 Maintain the lists of services during the life of CORUS-XUAM, interacting with other projects
or actors who have contributions to make to those definitions.
2.2 CORUS-XUAM-XUAM Internal Drivers

CORUS-XUAM splits the work in several work packages. CORUS-XUAM internally developed among the
others the definition of business process diagrams, environment, requirements, services, constraints
to operation in relation with failure and emergency. All these are important inputs that fed the
development of the U-space architecture.
2.3 Other U-space projects

The CORUS-XUAM project has no hard dependencies on other U-space projects in the sense of waiting
for deliverables from those projects. However, as CORUS-XUAM aims to describe the U-space ConOps,
it is transversal for these other U-space projects. Therefore, there have been coordination sessions to
understand the outcome of the projects, the feedback on the progress of the U-space ConOps and to
include in the U-space architecture their most promising findings.

3 Strategic Architecture
This section provides high-level description of the U-space Strategic Architecture.
The strategic layer describes the U-space’s abilities and performance measures such as validation
targets and validation results; it describes the business capabilities.
The main element of the Strategic Layer in the U-space architecture is the Capability, whose definition
is the following:
 Capability:
Capability is the ability of one or more of the enterprise’s resources to deliver a

specified type of effect or a specified course of action to the enterprise
stakeholders.
A Capability represents a high-level specification of the enterprise’s ability. As

such, the whole enterprise can be described via the set of Capabilities that it has.
A Capability is a statement of "what" is to be carried out and does not refer to

"how" or "by whom" they are carried out. Consequently, capabilities are free from
considerations of physical organisation or specific choices of technology.
'Capabilities' is an important business concept that describes the abilities or

competencies of an organization. They are typically quite stable, and while
business processes, functions and roles change quite frequently, capabilities
change less frequently. When they do change, it is typically in response to a
strategic driver or change. Capabilities can be mapped back to strategic goals and
objectives.
They provide a useful starting point to derive lower-level elements such as

processes and functions, applications and technology assets.
3.1 U-space Capability Model

The Capability Model is the view that describes the entire U-space enterprise in the form of a set of
decomposed capabilities. A capability is the perceived outcome realised by the undertaking of
activities by stakeholders.
Building from the U-space Capability model defined in the U-space ConOps v3 [4] , this latest iteration
is produced with the inputs from the CORUS-XUAM consortium, other U-space projects and the
alignment with the evolution of the EATMA Capability Model.
The model has 3 levels of granularity; the main one (level 1) is composed by the ICAO building blocks,
the level 2 decomposes the ICAO building blocks into different domains, while the level 3 addresses
the most detailed capabilities, which trace to other architectural elements (e.g., services).
The white level 3 capabilities are the ones identified either as pure U-space capabilities or shared
between ATM and U-space; while the grey ones are, so far, only considered ATM capabilities.

Figure 3: U-space Capability Model.
13
Figure 4: U-space CNS Capabilities
3.2 U-space Capabilities

Capability Level 3 Description
Air Traffic Demand Provision The ability to determine the air traffic demand (present, future) in airspace.
(Airspace)
Airspace Capacity The ability to determine the capacity (present, future) of airspace, including
Information Provision (incl. ad hoc changes due to circumstances (e.g. weather)
Capacity Changes)
Air Traffic Flow Management The ability to detect / monitor demand capacity imbalances (present,
future) in the airspace and solve the imbalance issues acting on
load/demand.
Airspace Separation Minima The ability to define and manage the separation minima and separation
Management methods for a specific airspace (U-space)
14
Area Proximity Avoidance The avoidance of infringement into airspace by airborne vehicles not
authorised or expected to enter the airspace
CNS Infrastructure The ability to monitor the status of the CNS infrastructure
Monitoring
Controller Situational The ability to visualise the air traffic situation through the position and
Awareness (airspace) identification of aircraft.
Controller Situational The ability to visualise the traffic situation on the ground through the
Awareness (surface) position and identification of aircraft and vehicles.
Digitalised Aeronautical The ability to provide and exchange aeronautical information as digital data
Information Provision sets, in an interoperable manner and mutually understood manner.
Drone Aeronautical The ability to provide aeronautical and coherent information for manned
Information Provision and unmanned operators relevant to U-space. This includes predefined
restricted areas or available aeronautical information.
Emergency Management The ability to manage solutions for emergencies in U-space. It includes the
exchange of information among the relevant actors and drone auto-
diagnosis.
Ground Collision Avoidance Prevention of aircraft collision during taxi or push-back (including collisions
with parked aircraft) or on the runway/landing spot or while one is on the
ground and the other in the air close to the ground.
Ground Proximity / Terrain Prevention of aircraft collision with the terrain and obstacles while is in the
Avoidance air close to the ground.
The avoidance of collision with the terrain by an airborne vehicle.
Ground Risk Observation The ability to provide static and dynamic information about ground risks for
UAS operations (e.g. terrain and obstacle elevation, population density,
other ground traffic such as trains, vessels, cars) at the scale of interest of
small UASs.
Meteorological Observation The ability to provide meteorological observations, forecast and warning
and Forecasting information in support of ATM and U-space decision making.
Mid-Air Collision Avoidance The avoidance of collision between mobile airborne vehicles.
Pilot Situational Awareness The ability to visualise own aircraft position and surrounding traffic
(airspace) information in context (e.g. airspace status).
Pilot Situational Awareness The ability to visualise own aircraft position and surrounding traffic
(surface) information in context (e.g. airport layout).
Recording and Analysis The ability to record U-space such as relevant event and traffic scenes and
to provide reports, statistics, playback. It encompasses e.g. logbooks, legal
recordings, playback for incident and accident investigations.
Registration The ability to provide the registration of the operator, drone and pilot with
the appropriate information according to Regulation.
Self-separation The ability to separate own aircraft from surrounding traffic.
Separation Service Provision The ability to separate aircraft when airborne in line with the separation
(airspace) minima defined in the airspace design (incl. aircraft separation from
incompatible airspace activity, weather hazard zones, terrain-based
obstacles).
Situational Awareness The ability to provide traffic information for user situational awareness
coming from any kind of monitoring.
Traffic Information Provision The ability to provide traffic information for user situational awareness
in support of U-space coming from any kind of monitoring.
Operations
UAS Operational Planning The ability to plan UAS missions considering all relevant information, such
as meteorological information, aeronautical information, applicable rules
and traffic information.
UAS Procedure Design The ability to interface with ATC to define a set of procedures for some
mission types where there may be an impact on ATC; the procedures
ensure clear and unambiguous UAS operation and provide an appropriate
flow of information between the UAS operators and ATC. Such procedures

will allow UAS to fly in controlled airspace and near airports with more
flexibility and procedural approval/rejection based on agreed rules.
U-space Communication The ability to facilitate (providing the link, coverage provided and
Coverage Provision monitoring) the air-air, air-ground and ground-ground communication.
U-space Interface with ATS The ability to interoperate with ATC with mechanisms which ensure proper
effective coordination when UAS operations using U-space services impact
ATS.
U-space Navigation Coverage The ability to facilitate (providing the link, coverage provided and
Provision monitoring) the planning, recording and controlling the movement of an
aircraft from one place to another.
U-space Surveillance The ability to facilitate the provision of ground and air surveillance data
Provision from different sources to track and fuse for determining the position of the
aircraft.
Vertical Conversion The ability to convert barometric to geodesic heights and vice-versa.
Vertiport Capacity The ability to determine and provide the capacity (present, future) of the
Information Provision (incl. vertiport, including ad hoc changes due to circumstances (e.g. weather)
Capacity Changes)
Vertiport Resource Allocation The ability to allocate resources of vertiports to accommodate UAS
Management requests.
Visual Separation The ability to maintain own separation during visual approach/departure.
Table 4: Capability descriptions

4 Business Architecture
The operational layer contains the elements needed to describe the business concepts and is
independent from any physical implementation. It includes descriptions of business actors and
processes.
Even if six different architectural elements compose this layer in the EATMA framework [6], only five
are used for the CORUS-XUAM architecture so far.
 Node:
A logical entity that performs Activities. Note: nodes are specified independently
of any physical realisation. They represent the actors in the operational layer.
Nodes interact through Information Exchanges in which they exchange
Information Elements.
 Information Exchange:
The collection of information elements that are exchanged between two nodes.
An Information Exchange defines the types of Information Elements exchanged
and which Nodes are involved in the Information Exchanges.
It is important to note that Information Exchanges are realised by Services. This

means that the Services are identified from the Information Exchanges, which also
represent the operational need for exchanging information.
 Activity:
A logical process, specified independently of how the process is carried out.
Activities represent WHAT has to be done to complete a Capability.
Activities are logically grouped within Nodes (and hence, associated to the
Stakeholder that implements that node) Activities may be realized by people, or
aspects may be automated and performed by functionality (Functions and
Services) provided by Technical Systems.
 Information Flow:
A flow of information from one Activity to another.
An Information Flow defines the types of Information Elements sent from one
Activity to another. It is always modelled as a one-way flow.
Information Flows may be aggregated into one or more Information Exchanges

between Nodes, thus enabling the description of more complex two-way
interactions
 Information Element:
A formalised representation of information. An Information Element is carried by

one or more Information Exchanges (between Nodes).

4.1 Nodes and Information exchanges
Node Description
USSP Operations Performs all the operational activities related to management of UAS traffic.
This includes the activities required at strategic level, in execution and post flight to
ensure a safe execution of UAS flights.
It is as well encompassing activities to maintain/monitor physical condition of the

supporting infrastructures, creating and maintaining a good relationship with local /
national authorities, ATM and communities.
It also includes assurance that the scale of equipment and facilities provided are
adequate for the activities which are expected to take place, as well as provision of
staff, where necessary, that are competent and, suitably qualified.
UAS Operations Represents all the activities undertaken by those organisations and individuals who
have access to and operate in the airspace which is available for UAS operations in
accordance with international and national procedures.
The main types of UAS Operations are:
· Civil UAS Operations /Organisation. The most extensive organization for UAS
Operations is run by Legal Entities which uses UASs for their business activities. The
daily operations of these companies require a lot of flexibility.
· Recreational UAS Operations. Another important segment of UAS

Operations which are constituted by single individuals which are aimed to use UASs
for recreational purposes.
· Special UAS Operations /Organisation. Organizations for UAS Operations

which require special conditions to operate, such as military/law enforcement. The
daily operations of these companies require special condition of privacy in respect to
the other organisations.
Pilot Operations It performs all the activities related to the preparation, execution and post-
flight where pilot and the flying system are involved.
Registration Performs all the operational activities related to the registration of UAS ownership,
Operations UAS pilot and UAS operators licensing according to the law.
It is as well encompassing activities to maintain registrations, to share them with

interested parties, as well as provision of staff, where necessary, that are competent
and, suitably qualified.
Law Enforcement Performs all the operational activities related to the law enforcement. Most of the
Operations activities relies on U-space services to provide required law enforcement actions (e.g.
e-identification).
CISP Operations It performs all the activities related to the provision of Common Information
for U-space. It is also responsible, if applicable, of the exchange of
information of ATM and U-space.
Public Users Performs all the operational activities related to public when wants to be informed
Operations about UAS traffic. These activities are mainly derived from privacy and safety issues
of an individual/community.

Insurance Performs all the operational activities related to insurance management. Even if the
Management process can be considered outside the scope, for registration purposes it is important
to mention these activities especially for the required exchanges in the e-registration
process.
Meteorological Service Performs all the operational activities related to the weather information provision.
Provision
Provides at least the weather data and where necessary hyper local weather data to
ensure safe UAS operations.
In most instances a weather provider will provide a wider scope of weather data
relevant to the ATM stakeholders/ATM community.
Ground Info Provider Performs all the operational activities related to the provision of ground
Operations related information, e.g. Terrain and Obstacles information.
Surveillance Performs all the operational activities related to the provision of Surveillance
Operations information
Navigation Operations Performs all the operational activities related to the provision of Navigation
information
Communication Performs all the operational activities related to the provision of Communication
Operations information
ER/APP ATS (U-space) Performs all the en-route and approach ATS operations.
Aerodrome ATS (U- Performs all the aerodrome ATS operations.

space)
Flight Deck Performs all the on-board AU operations including flight execution/monitoring
according to agreed trajectory, compliance with ATC clearances/instructions, etc.
AIM Performs all the operational activities related to the provision of Aeronautical
Information
Training School Performs all the operational activities related to the training schools. Provides
information required for the registration process.
Regulator Operations Performs all the operational activities related to the regulator.
Vertiport Operations Responsible for providing permission for departing and arriving in the
vertiport as well as for providing relevant information to other USSPs.
Table 5: Nodes

Figure 5: U-space information exchanges needs in U1

Figure 6: U-space information exchanges needed at U2

Figure 7: U-space information exchanges needed at U3
At this level of abstraction and from a conceptual point of view the USSP Operations is described just
as a single node, without entering in the technical possible variants of deployment, which may include
more than one.
4.2 Business Processes for U-space

The business processes of the U-space ConOps are depicted via the business process diagrams as
represented in the Operational Layer as NAF Operational Views – 5 (NOV-5) [5].
They represent the dynamic behaviour of the Nodes (swim lines) showing in a sequenced way what
Activities (yellow boxes) they perform and so which and when the Information Elements are sent
between the participants.
As a result of the consortium, fifteen different business processes have been designed representing
the use cases explained in the CORUS-XUAM ConOps. They represent one possible way of proceeding,
but not constraining the process to these procedures.

Figure 8: Registration of the Professional Pilot
Figure 9: Registration of the UAS Operator
Figure 10: Flight Route with ATS clearance
Figure 11: The Flight Plan with Strategic Deconfliction
27
Figure 12: Start Up, Taxi and Take Off
28
Figure 13: Post-flight Operations
29
Figure 14: Landing on a controlled airfield/airport/aerodrome
30
Figure 15: Flight Planning with no CISP involved (e.g., weather, terrain, traffic density, regulations)
31
Figure 16: Tactical de-confliction
32
Figure 17: Network identification, tracking monitoring and traffic information
33
Figure 18: Strategic DCB Planning Measures Management (U3)
34
4.2.1 U-space when the Vertiport is involved
Figure 19: Passenger ticketing and boarding (U3)

35
Figure 20: Departure from and arrival to uncontrolled vertiports (no interaction with ATC)
36
Figure 21: Departure from a controlled vertiport towards an uncontrolled vertiport (with ATC interaction) and vice-versa
37
Figure 22: Nominal arrival to a vertiport (U3)
38
5 Service Architecture
The service layer provides a link between the operational need and technical solution by describing
services.
Only one element from this layer is used in this iteration of the architecture document.
 Service:
The contractual provision of something (a non-physical object), by one, for the use
of one or more others. Services involve interactions between providers and
consumers, which may be performed in a digital form (data exchanges) or through
voice communication or written processes and procedures.
Services are key to describe the relationships between the different aspects
(business, operational and solution) of the Architecture.
The section 5.1 reports the list of 30 services for U-space for the different U-phases.
The services have been grouped in:
 Core U-space services, which can be further classified in Principal and Operator U-space
services according to the split of responsibilities in the deployment architecture. They are
services strongly linked to U-space domain among USSPs and for the end-users.
 U-space Supporting services, which encompass Infrastructure and Supplemental Data

services. They are services providing additional data to stakeholders that can use it to offer
more valuable services to their service consumers, which would be normally the end-users.
They are typical services that are not necessarily specific to U-space and can be consumed in
another domain as well. On
Supplem U-space
ental Services
Data
Services
Infrastructur
e Services
Figure 23: Service portfolio classification
It should be noted that the activity performed in CORUS-XUAM is not providing details about the
signature of the services (out of scope) and that specification activity may result in optimisation to
merge/split services or introduce other services (e.g., related to technical infrastructure such as Service
Registration, Service Discovery or related to market evolution).
39
5.1 U-space services
U1 services Core Supplemental Infrastructure
U-space
Geoawareness X
NetworkIdentification X
Registration X
UASAeronauticalInformationManagement X
Table 6: U1 U-space Services

U-space
CommonInformationService X
CommunicationCoverageInformation X
CommunicationInfrastructureMonitoring X
ElectromagneticInterferenceInformation X
EmergencyManagement X
FlightAuthorisation X
GeographicalInformation X
IncidentAccidentReporting X
LegalRecording X
Monitoring X
NavigationCoverageInformation X
NavigationInfrastructureMonitoring X
PopulationDensityInformation X
ProceduralInterfaceWithATC X
RiskAnalysisAssistance X
SurveillanceDataExchange X
TrafficInformation X
WeatherInformation X
40
U-space
CollaborativeInterfaceWithATC X
DynamicCapacityManagement X
TacticalConflictPrediction X
TacticalConflictResolution X
VerticalAlert X
VerticalConversion X
VertiportDynamicInformationService X
VertiportResourceAllocationManagement X
At a first glance, infrastructure and most of the supplemental services are expected to be deployed at
U2, while the core U-space services are spread in all three phases. Furthermore, a first interface with
ATS with limited features is expected at U2, while a more dynamic is expected at U3.
It should be noted as well that the list is not an exhaustive list of possible services, and that further
research and innovation will probably help identifying and developing more services.
In addition, the descriptions of the different services can be found in both the main body of the U-
space ConOps and the eATM Portal (U-space R&D) [3].
A possible allocation of services to the different stakeholders for the different U-phases is presented
in the section 6.2 Evolution of service provisioning in U-space and in the main part of the U-space
ConOps.
41
Monitoring
Registration
VerticalAlert
Geoawareness
LegalRecording
TrafficInformation
VerticalConversion
FlightAuthorisation
WeatherInformation
NetworkIdentification
RiskAnalysisAssistance
EmergencyManagement
GeographicalInformation
TacticalConflictPrediction
TacticalConflictResolution
SurveillanceDataExchange
IncidentAccidentReporting
CommonInformationService
ProceduralInterfaceWithATC
PopulationDensityInformation
DynamicCapacityManagement
CollaborativeInterfaceWithATC
NavigationCoverageInformation
NavigationInfrastructureMonitoring
VertiportDynamicInformationService
CommunicationCoverageInformation
All rights reserved.

ElectromagneticInterferenceInformation
CommunicationInfrastructureMonitoring
VertiportResourceAllocationManagement
UASAeronauticalInformationManagement
Air Traffic Demand Provision (Airspace)
Airspace Capacity Information Provision (incl. Capacity

Changes)
5.2 Services aim to achieve Capabilities
Air Traffic Flow Management
Airspace Separation Minima Management

Area Proximity Avoidance

CNS Infrastructure Monitoring
Controller Situational Awareness (airspace)
Controller Situational Awareness (surface)
Digitalised Aeronautical Information Provision
42
Drone Aeronautical Information Provision
Emergency Management
Ground Collision Avoidance
Ground Proximity / Terrain Avoidance
Ground Risk Observation
Meteorological Observation and Forecasting
Mid-Air Collision Avoidance
Pilot Situational Awareness (airspace)
Table 9: Mapping of Services to Capabilities

Pilot Situational Awareness (surface)
Recording and Analysis
Registration
A Service is a mean to achieve or to access a Capability. Therefore, there is a need to trace the identified Services to the Capabilities composing the Capability Model.
Self-separation
Separation Service Provision (airspace)
Situational Awareness
Traffic Information Provision in support of U-space

Operations
UAS Operational Planning
UAS Procedure Design
U-space Communication Coverage Provision
U-space Interface with ATS
U-space Navigation Coverage Provision
U-space Surveillance Provision
Vertical Conversion
Vertiport Capacity Information Provision (incl. Capacity

Changes)
Vertiport Resource Allocation Management
Visual Separation
42
5.3 From the conceptual needs to services
As stated previously, the operational layer describes at a conceptual level (independent from any
physical implementation) how the Nodes interact between them. These interactions, named
Information Exchanges, describe then the operational needs that must be covered at the System layer
(implementation) with the technical systems. The service layer provides this link between the
operational and technical layer. Once the operational/conceptual needs are described, the services
shall be identified. Consequently, there is a direct relationship between the Information Exchanges
and the Services. Examples of these links, for CORUS-XUAM, are shown in the following table.
Information Exchange Service

Registration Info Provision
Insurance Information Provision
License Info Provision Registration
Registration Information Provision
Operator Registration Provision
Network Identification Provision NetworkIdentification
Flight Plan Information Provision FlightAuthorisation
Conflict Alert Provision
Monitoring
Monitoring Provision
Logbook Information DigitalLogbook
Geo-awareness Information Provision GeoAwareness
Emergency Info Provision Emergency Management
Airspace Structure Provision UASAeronauticalInformationManagement
TacticalConflictResolution
Tactical Clearance Provision
TacticalConflictPrediction
MET Info Provision Weather information
ProcedureInterfaceWithATC
Information Exchanged with ATS
CollaborativeInterfaceWithATC
Incident and Accident Report
Flight Report Provision IncidentAccidentReporting
Citizen Report Provision
Traffic Information Provision TrafficInformation
Surveillance Info Provision
SurveillanceDataExchange
Tracking Information Provision
Dynamic Capacity Management Info DynamicCapacityManagement
CommunicationCoverageInformation
Communication Info Provision
CommunicationInfrastructureMonitoring
NavigationCoverageInformation
Navigation Info Provision
NavigationInfrastructureMonitoring
Risk Analysis Assistance Info RiskAnalysisAssistance
Terrain and Obstacles Provision GeographicalInformation
Common Information for U-space CommonInformationService
VerticalAlert
Vertical Measures and Alert Information
VerticalConversion
Vertiport Dynamic Information VertiportDynamicInformationService
Vertiport Allocation Information VertiportResourceAllocationManagement
Table 10: Mapping of Information Exchanges to Services

6 System Architecture
The system layer describes all human and technical resources of a system including its internal
functional breakdown and its interactions with the surrounding systems.
 Stakeholder:
A stakeholder is an individual, team, or organisation (or classes thereof) with

interest in, or concerns relative to, an enterprise [e.g. the European ATM].
Concerns are those interests, which pertain to the enterprise’s development, its
operation or any other aspect that is critical or otherwise important to one or
more stakeholders
 Capability Configuration:
A Capability Configuration is a combination of Roles and Technical Systems

configured to provide a Capability derived from operational and/or business
need(s) of a stakeholder type.
 Role:
An aspect of a person or organisation that enables them to fulfil a particular

function.
They represent the use of a human resource (person) in a Capability

Configuration.
 Technical System:
Technical Systems are artefacts that represent the technical part of Capability
Configurations. Interaction between Technical Systems can be described via
Services.
6.1 Stakeholders and Roles

First, a clarification of the difference between stakeholder and role is needed in order to set the
appropriate understanding of both elements. Many times, roles are considered only as the facet that
a stakeholder could have at a certain moment. Often the sentence “a stakeholder is playing the role
of…” is listen when talking about these two elements.
As a brief differentiation, in the EATMA framework [6], the stakeholder is considering the individual
or organisation that is interested in an enterprise, while the role usually represents the human being
performing functions.
The U-space stakeholders and the possible U-space roles allocated to them are presented in the
section 8.3 of the U-space ConOps. Therefore, the complementing list of U-space roles and their
descriptions are defined hereafter for completeness purposes.
The following table provides a brief description of main roles and their relevant responsibilities.

Role Explanation
Accredited This category groups the police, accident investigators, other agents of the
registry reader authorities or anyone else who might need – and be given permission - to
investigate the registry. (or registries).
How he/she interacts: Who may query registration information.
Accredited This category groups together pilot training schools, LUC issuers, nominated
registry agents of the courts and any others who have the power to create, read, update
updater or delete registry entries in any way – which may be very restricted for some.
How he/she interacts: User of (operator/school/pilot) registrations.
Airport It is responsible for interacting with the system to protect airport perimeter
Operator (anti UAS) to contribute to the safe integration of UASs in airspace, especially in
Representative airport vicinity. It will be responsible to establish proper coordination with other
relevant stakeholders.
ATS Operator ATS should have access to the air-situation generated from NetworkIdentification
reports, with the usual controller-working-position tools to filter out those of no
interest, give conflict alerts and so on. Main roles: Air Traffic Controller, Tower
Supervisor, Tower Runway controller, Tower Ground controller, (A)FIS and RIS
Operator.
How he/she interacts: User involved to achieve the interface with ATS.
Authorised This groups actors like U-space operators, city authorities and some others such
viewer of air as researchers who can be trusted with the commercially sensitivities of the
situation overall air-situation.
How he/she interacts: Who may be allowed to have a situational awareness

according to privileges and privacy.
Authorization A person having the rights to participate in the authorization workflow (e.g.,
Workflow when local authority/USSP/NAA must express the approval or does not object).
Representative
Capacity A person receiving warning and alerts from the monitoring service
Authority
Responsible for setting the minimum safe operating conditions that determine
the capacity of an airspace or an aerodrome due to safety
Responsible for setting noise level limits that limit capacity due to noise footprint
and “dose”
Citizen Generic person who wants to be aware of UAS operations impacting its privacy.
How he/she interacts: a kind of authorised viewer of air situation and able to
report about events.
Pilot It is the pilot of glider, parachutist, paraglider, balloon, GA, military flight which
share the airspace (even if occasionally) in VLL operations.

How he/she interacts: In some environments, user of situational awareness and
monitoring alerts.
Police or Security actors would be interested in the air situation, to identify operators and
security agent to apply relevant procedures.
Law enforcement Unit, responsible to develop law enforcement methods related

to illegal UAS use.
How he/she interacts: User of registration, e-identification and interested in the

situational awareness and monitoring alerts.
Registrar A registrar has a legal duty to operate a registry securely, reliably and adequately.
The registrar will be a legal person, probably with staff.
UAS A body that is independent of the Aeronautical Information Office and allows UAS
Aeronautical specific aeronautical information to be registered, combines the information,
Information assesses it and then published the result.
Manager
UAS crew The UAS pilot or any person following the UAS’s progress during flight. This term
generalises the pilot, any kind of dispatcher, any mission specialist. Additional
recipient of messages about flights.
UAS Pilot Assistant. It is assisting the piloting in its duty.
Observer. It is assisting the piloting in its duty, e.g., during EVLOS operations.
UAS It is responsible for UAS registration and using the system for all other
Manufacturer obligations the UAS manufacturer must comply (e.g., UAS
Representative model/characteristics/performance publication).
UAS operator Aka UAS Operator, the operator being registered in operator registry. An
representative operator representative is a legal entity, meaning a natural person or a business.
An operator representative has contact details.
How he/she interacts: User of geo-fence definitions during flight planning, User
of situation awareness computed from the dynamic online traffic situation based
on relevant maintained tracks, Generalised actor that submits a flight plan, the
person receiving warning and alerts from the monitoring service
UAS owner When any UAS is registered, it will have a registered owner. An owner is a legal
representative entity, meaning a natural or a business. An owner representative has contact
details.
How he/she interacts: User of UAS registration.
UAS pilot aka UAS Pilot, Pilot in Command (PIC) or Remote Pilot, it is responsible for the
safe execution of the flight according to the U-space rules, whatever it is
recreational or professional with one of the different license levels, according to
the typology of the UAS used. (Recreational UAS Pilot, Professional UAS Pilot)
It expects:

 more efficient flight preparation, including getting permission (easier,
quicker and more efficient);
 safer and more efficient flight execution due to improved situational
awareness in all operations – VLOS and BVLOS
The person being registered in the pilot registry. A pilot is a human being
performing the piloting function. The registry should be able to record some
information about the pilot’s qualification; mentions different levels of
qualification.
The UAS pilot should be able to update some parts of his/her registry entry, such
as changing his/her address and he/she may be allowed to create the record
initially.
How he/she interacts: User of geo-fence definitions during flight; User of

situation awareness computed from the dynamic online traffic situation based on
relevant maintained tracks; User of weather nowcast to assist him in the in-flight
phase; the person receiving warning and alerts from the monitoring service.
UAS specific The person or representative of the organisation that creates UAS specific
aeronautical aeronautical information. This actor is accredited and trained in the processes of
information creating, updating or deleting UAS specific aeronautical information.
originator
This is reflecting the possibility to have a different originator of “constraints” for
UASs.
USSP Being the level of automation high, it is not envisaged the role of “Controller”.
Supervisor Nevertheless, it has been envisaged a person who will arbitrate or impose a
solution in some cases (in case of escalation required) who may intervene
manually imposing ad-hoc solutions or taking over other USSP roles.
Vertiport Responsible of the vertiport terminal zone.

Manager
Table 11: Roles
6.2 Evolution of service provisioning in U-space

Once the operational layer, which specifies the responsibilities and the needs for information
exchanges, is stable, the work in the system layer starts. In this layer a possible realization of the needs
through a combination of systems services and humans is defined.
Nonetheless, it is important to remark that:
 The Capability Configurations realize the Nodes that were presented in the section 4.1.
 The Services are realizations of the Information Exchanges depicted in the section 4.1.
In the following diagram, the “red boxes” represent the Capability Configurations, while the lines
represent the services. Please note that the rounded part of the interaction represents the provision
of the service, while the semi-circular part represents the consumption of the service.

Figure 24: Possible Service Provision in U-space (U1)



This is just an example of which services could be potentially provided and consumed by the capability
configurations in each of the different U-phases.
The reader probably has noticed the different colours used in the 3 views. They represent what is
expected to be in place at each of the U-phases being:
 Orange: stakeholders and services expected at U1.
 Blue: stakeholders and services expected at U2.
 Green: stakeholders and services expected at U3.
6.3 Some of the fundamental U-space systems

The previously presented Capability Configurations are composed by roles and systems. In this section
a possible list of Technical Systems is presented. Being an architecture service-oriented other
breakdowns are feasible, and the following is not aiming to prevent others.
System Description
Aerodrome ATC Supports the ATC controllers at an aerodrome and provides the following
main functionalities:
· surface routing and guidance,
· infrastructure (weather, lighting, datalink) management,
· safety nets,
· aerodrome surveillance,
· flight data processing,
· departure management.
Centralised The system that manages, consumes and provides the information in the
Information Service Common Information Service Provider (CISP).
Provider
Communication U-space support infrastructure for Communication. It encompasses

Infrastructure technologies and services that will provide communication among U-
space actors. It includes:
- ground-ground communications among systems and any other

stakeholder: UAS Operator/Pilot, ATM, Law Enforcement, Aviation
Authority
- air-ground communications with the UAS itself.
Continuous Operating The system that provides GNSS data consisting of carrier phase and code
Reference System range measurements in support of 3D positioning, meteorology, space
(CORS) weather, and geophysical applications.
For further information, please check ICARUS documentation [7].
Navigation U-space support infrastructure for Navigation. It encompasses

Infrastructure technologies that could provide signals in space to allow UAS positioning
and navigation (e.g., satellite-based or ground-based).

Registration system Aka USSP system which supports with automation the Registration
process.
Supplemental Data It is a system which can elaborate/provide supplemental data for U-space
system services such as a weather system or terrain data model system.
Surveillance U-space support infrastructure for Surveillance. It encompasses

Infrastructure technologies and sensors to support cooperative and non-cooperative
surveillance of UASs
Terrain Data Model U-space support infrastructure for terrain and obstacles data. It
system encompasses the technologies and the models for data acquisition,
elaborations and provisioning.
UAS Operating Where available it supports the UAS operations in their activities assisting
System the human actor in the fleet management, UAS preparation, the
assistance to interface with UAS Traffic Management.
UAS system The Unmanned Aerial System (UAS) represents the UAS operating from
the end to end, on the airport surface, from a field and in the air. The main
groupings of functionalities are the ones dealing with traffic management:
 Communication (air ground data link, information domain);
 Navigation (Flight management, flight control, position

determination);
 Surveillance (traffic, weather, terrain);
 Other functions (remote displays and controls, alerts, recording,

databases, sensors and antennas, information domain display).
UAS Traffic Aka USSP system which supports the UAS operators in their activities
Management system related to traffic management. It provides the following main
functionalities: e-identification, UAS aeronautical information and
geofencing, flight planning management, de-confliction, demand capacity
balancing, weather data presentation.
This system may provide graphical interfaces to the public, the law
enforcement units (e.g., police, security agent) and UAS operators/pilots,
other airspace users.
In some deployment options several instances of UAS Traffic Management

systems may exists. Each of them realises completely or partially (a subset
of service provision) a UAS Traffic Management system.
USSP system Is a generic system which provides U-space services. It can be unique per
volume of airspace or possibly broken down in several instances sharing
responsibilities and interoperable. One of the possible breakdowns is
between Registration and UAS Traffic Management services (i.e.,
Registration system and DTM system) according to the services provided.
A further breakdown is considering the deployment options where the

boundary between Principal and Operator USSPs is determined; then it

results in a Principal USSP system and several Operator USSP systems in
case of federated deployments.
Vertical Conversion The system calculates the conversion between geometric and barometric
and Alerting altitudes, and issues alerts for vertical risks during the execution phase of
a flight.
For further information, please check ICARUS documentation [7].
Weather system U-space support infrastructure for (hyper local) weather data. It
encompasses the technologies and sensors and the evolution of the
models for data elaborations.
Table 12: Some U-space systems.

7 Data exchange models
This ConOps has been developed by the CORUS-XUAM project in collaboration with 16 other research
and demonstration projects. Two of these projects have studied the data exchange models that are
needed to make U-space work. Their work is appended here.
The project GOF2 (Gulf of Finland 2) [8] has developed ten data exchange models. Their project has
demonstrated the value of these models in the integration of different U-space Service Providers,
although they were only able to validate nine of the ten. These models can be found in the document
“D2.4 GOF2.0 VLD Updated Service Specifications” which is provided as an annex to this annex.
Beware that the Word document contains embedded Word documents. The work is entirely by GOF2
and is reproduced with their kind permission. More information can be found on the project website,
https://gof2.eu
The project PJ34 AURA [9] adopted five of the GOF2 data exchange models and had developed an
architectural description of their use. Their work can be found in the annex “U-space ConOps:
Interface U-space/ATM (AURA sol.2)” which is also provided here as an annex with the kind permission
of the PJ34/AURA project. For more information see the project web site https://www.pj34aura.com/

8 References
[1] U-space Blueprint https://www.sesarju.eu/sites/default/files/documents/reports/U-
space%20Blueprint.pdf
[2] European ATM Master Plan Drone roadmap,

https://www.sesarju.eu/sites/default/files/documents/reports/European%20ATM%20Master
%20Plan%20Drone%20roadmap.pdf
[3] U-space eATM Portal https://www.eatmportal.eu/working/rnd/rd-dashboard
[4] U-space ConOps ed. 3 https://www.sesarju.eu/node/3411
[5] NATO Architecture Framework V3 AC/322-D (2007)
[6] EATMA Guidance Material, SESAR Extranet Programme Library
[7] ICARUS https://www.u-spaceicarus.eu
[8] Gulf of Finland 2 project, https://gof2.eu
[9] AURA project, PJ34, “ATM U-SPACE INTERFACE”. See https://www.pj34aura.com/

[11] ICAO Annex 2 - Rules Of The Air https://store.icao.int/en/annex-2-rules-of-the-air

EXPLORATORY RESEARCH
CORUS-XUAM ConOps
Annex: regulatory and
legal impact study
Grant: 101017682
Topic:
Air Mobility
Edition Date: 11 Apr 2023
Edition: 01.00.00
CORUS-XUAM CONOPS ANNEX: REGULATORY AND LEGAL IMPACT STUDY

Name / Beneficiary Position / Title Date
DSNA Task co-leader 18/11/2022
UPC Task co-leader 18/11/2022
AOPA Task member 18/11/2022
ENAIRE Task member 18/11/2022
EUROCONTROL Task member 18/11/2022
LFV Task member 18/11/2022


project
Page 2
Name and/or Beneficiary Position / Title Date
Document History
Edition Date Status Name / Beneficiary Justification
00.00.01 18/11/2022 Draft Task 4.4 members First draft for review
00.00.02 5/12/2022 Draft Task 4.4 members First comments received
led to some adjustments
in the document.
00.00.03 9/12/2022 Final draft Task 4.4 members Final draft for review
01.00.00 06/01/2023 Final version Task 4.4 members and No comments received.
CONOPS writer Final draft ready for
release.
Copyright Statement © 2023 – CORUS-XUAM Consortium. All rights reserved. Licensed to SESAR3
Page 3
CORUS-XUAM
CORUS-XUAM
This study is part of a project that has received funding from the SESAR3 Joint Undertaking under grant
agreement No 101017682 101017682 under European Union’s Horizon 2020 research and innovation
programme.
Abstract
In 2019, a first proposal for a European concept of operations for unmanned aircraft systems traffic
management system was shared. This concept was based on a global view of UAS operations without
focusing on specific operations such as urban air mobility operations. CORUS-XUAM ConOps addresses
this domain by improving the initial ConOps with a UAM flavour.
What was yet only stammering in 2019 has been enriched so far with regulations from EASA and ICAO
on UTM and UAS topics.
On one hand, it is paramount that the next version of the ConOps be compatible with existing
regulatory framework and in other hand, that the regulation embeds what is necessary to allow and
foster future UAS operations, in particular in urban environment.
This study aims at identifying discrepancies between Conops content and regulations, and at making
suggestions to adapt or improve, if required, the regulatory framework.
Page 4
Table of Contents
Abstract ................................................................................................................................... 4
1 Executive Summary .................................................................................................... 8
2 Introduction ............................................................................................................... 9
2.1 Purpose of the document............................................................................................... 9
2.2 Scope ............................................................................................................................ 9
2.4 Background ................................................................................................................... 9
2.5 Structure of the document ............................................................................................. 9
2.6 Glossary of terms......................................................................................................... 10
2.7 List of Acronyms .......................................................................................................... 10
3 ConOps and regulatory environment: observations and adjustment opportunities .... 13
3.1 CORUS X UAM ConOps ................................................................................................ 14
3.1.1 Contribution 1: Operational Environment ...................................................................................... 15
3.1.2 Contribution 2: U-space services..................................................................................................... 18
3.1.3 Contribution 3: U-space Flight Rules (UFR) ..................................................................................... 19
3.2 Existing regulatory Environment .................................................................................. 20
3.2.1 Current regulations ......................................................................................................................... 20
3.2.1.1 (EU) 2019/945 on unmanned aircraft systems and on third country operators of unmanned
aircraft systems ........................................................................................................................................ 20
3.2.1.2 (EU) 2020/1058 amending delegated regulation (EU) 2019/945 as regards the introduction
of two new unmanned aircraft systems classes ...................................................................................... 21
3.2.1.3 (EU) 2019/947 on the rules and procedures for the operation of unmanned aircraft .......... 21
3.2.1.4 (EU) 2020/639 Amending Implementing Regulation (EU) 2019947 as regards standard
scenarios for operations executed in or beyond the visual line of sight ................................................. 22
3.2.1.5 Commission implementing regulations 2021/664, 665 and 666 ........................................... 23
3.2.1.6 NPA 2021-14 ........................................................................................................................... 25
3.2.1.7 Easy Access Rules for Standardized European Rules of the Air (SERA) .................................. 26
3.2.1.8 EASA “Prototype Technical Specifications for the Design of VFR Vertiports for Operation with
Manned VTOL-Capable Aircraft “certified in the enhanced category ..................................................... 27
3.2.1.9 EUROCAE MOPS ED-269 and ED-270 on Geofencing and Geo-caging ................................... 27
3.2.1.10 RPAS Panel documentation .................................................................................................... 28
3.2.1.11 SSDR: single seat microlight ................................................................................................... 29
3.2.1.12 “” NPA2022-06” “Introduction of a regulatory framework for the operation of drones
Enabling innovative air mobility with manned VTOL-capable aircraft, the initial airworthiness of
unmanned aircraft systems subject to certification, and the continuing airworthiness of those
unmanned aircraft systems operated in the ‘specific’ category” ............................................................ 29
3.2.1.13 (EASA) public consultation on Guidelines on noise measurement of unmanned aircraft
systems lighter than 600kg operating in the specific category (low and medium risk) released on 13
October 2022. .......................................................................................................................................... 30
3.2.1.14 (EASA) ED Decision 2022/002/R on AMC & GM to Regulation (EU) 2019/947 that amends
AMC-GM for (EU) 2019/947 .................................................................................................................... 30
3.2.2 Domains impacted by the regulations and gaps ............................................................................. 30
Page 5
3.2.2.1 Domains identified ................................................................................................................. 30

3.2.2.2 Gaps ........................................................................................................................................ 31
3.3 Comparison between ConOps and regulation ............................................................... 32
3.3.1 Differences and possible impacts on ConOps ................................................................................. 32
3.3.1.4 (EU) 2020/639 Amending Implementing Regulation (EU) 2019/947 as regards standard
3.3.1.5 (EU) 2021/664, 665 and 666 on a regulatory framework for the U-space (amending (EU)
2017/373 & (EU) 2012/923)..................................................................................................................... 33
3.3.1.6 NPA 2021-14 ........................................................................................................................... 33
3.3.1.12 NPA 2022-06 on innovative air mobility with manned VTOL-capable aircraft ....................... 35
AMC-GM for (EU) 2019/947 .................................................................................................................... 36
3.3.2 Differences and possible impacts on regulations............................................................................ 36
3.3.2.4 (EU) 2020/639 Amending Implementing Regulation (EU) 2019/947 as regards standard
3.3.2.5 (EU) 2021/664, 665 and 666 on a regulatory framework for the U-space (amending (EU)
2017/373 & (EU) 2012/923)..................................................................................................................... 37
3.3.2.6 NPA 2021-14 ........................................................................................................................... 37
3.3.2.12 NPA 2022-06 on innovative air mobility with manned VTOL-capable aircraft ....................... 40
AMC-GM for (EU) 2019/947 .................................................................................................................... 41
4 Conclusions and recommendations........................................................................... 42

4.1 conclusion ................................................................................................................... 42
4.2 Recommendations....................................................................................................... 42
5 References and Applicable Documents ..................................................................... 43
5.1 Reference Documents.................................................................................................. 43
Page 6
List of Tables
Table 1: Glossary of terms ..................................................................................................................... 10
Table 2: List of acronyms ....................................................................................................................... 12
Table 3 Links between flight phases and existing regulations or proposals ......................................... 16
Table 4 U-space volumes and possible implementation in ICAO/SERA airspace classes ..................... 17
Table 5 New U-space services names ................................................................................................... 18
List of Figures
Figure 1 U-space services of ConOps 3.10 19
Figure 2 U-space services and (EU) 2019/947 articles 22
Figure 3 Common Information service, Dynamic Airspace Reconfiguration and U-space services
referenced by (EU) 2021/664 articles 4-5, 8-9 24
Figure 4 U-space services referenced by (EU) 2021/664 articles 10-13 25
Page 7
1 Executive Summary
UAS traffic, mainly with professional purposes, keeps on growing despite the national regulations
which tend to limit regular exploitation of UAS, even if lot has been done since first commercial UAS
operations showed up.
European UTM regulations will come into force in January 2023, and a new concept of operations
encompassing urban air mobility operations will be published few months later.
Despite all participants to the definitions of the ConOps and of the different regulations, both European
or international, try to coordinate and stay up to date, differences and gaps remain.
This study has identified these differences between the ConOps and the regulations, and the gaps that
shall be fulfilled for an efficient integration and acceptability of UAS traffic.
On the ConOps side, it appears that some definitions are missing (IAM) or could be identical to those
found in the regulation (e.g., VTOL aircraft, UAs operator).
The ConOps also does not take over certain topics addressed in the regulation (e.g., remote pilot
responsibilities, cross border operations).
Considering the regulations, and it is probably due to the time required to create them all, we identified
several gaps (e.g., noise limitations, VTOL unmanned capable aircraft) but also little consideration in
the existing ones given to some of the structuring ideas proposed in the CORUS ConOps (e.g., many U-
space services including very important ones (emergency service, drone aeronautical information
management service), U-space volumes).
Page 8
2 Introduction
2.1 Purpose of the document
This document is a study which purpose is to identify any gaps in the existing European and
international regulations that provide the frame to UAS operations, and to verify that the CORUS-
XUAM ConOps[1] in line with what has already been defined.
This will lead to make recommendations for the ConOps adaption when necessary and to suggest
improvements and/or complements to the regulatory framework for filling in the gaps.
2.2 Scope
The scope of the document is the CORUS-XUAM ConOps and the existing regulatory framework of UAS
operations and U-space.
Has also been included in that scope what regulates how aircraft shall fly in European skies.

CORUS-XUAM Conops writers and contributors is the main intended readership of this study.
The European Union Aviation Safety Agency (EASA) and International Civil Aviation Authority (ICAO)
may also have an interest in the document.
2.4 Background
The production of the first three editions of the concept of operations for UAS took into account the
existing and limited regulatory framework for UAS, and the procedures, rules and environments
already in place for manned/crewed aircraft operations.
The provision of a U-space regulatory framework, complementary regulations on unmanned aircraft

systems, on the rules and procedures for the operation of unmanned aircraft, on command-and-
control link loss, for instance, requires a review of the ConOps.
2.5 Structure of the document

Three main sections composed the document which core is developed in section 3:
Section 3.1 provides a high-level description of the topics addressed in the CORUS-XUAM Conops[1].
Section 3.2 lists the different existing regulations reviewed and the describes what domains are
impacted.
Section 3.3 depicts the differences found between the ConOps and the regulations and make some
proposals for improvements
Page 9
2.6 Glossary of terms

Term Definition Source of the
definition
IAM The safe, secure and sustainable air mobility of NPA 2022-06[19]
passengers and cargo enabled by new-generation
technologies integrated into a multimodal
transportation system.
Manufacturer Manufacturer” means any natural or legal person (EU)2019/945[2]

who manufactures a product or has a product
designed or manufactured and markets that
product under their name or trademark
Operating site "Operating site” means a site, other than an NPA 2022-06[19]
aerodrome, selected by the operator or pilot-in-
command or commander for landing, take-off
and/or external load operations.
UAM The subset of IAM operations conducted in to, NPA 2022-06[19]

within or out of urban environments.
UAS operator Unmanned aircraft system operator’ (‘UAS (EU) 2019/945[2]

operator’) means any legal or natural person
operating or intending to operate one or more
UAS.
VTOL capable aircraft A power-driven, heavier-than-air aircraft, other NPA 2022 06[19]
than aeroplane or rotorcraft, capable of
performing vertical take-off and landing by means
of lift or thrust units used to provide lift during
take-off and landing
Table 1: Glossary of terms
2.7 List of Acronyms

Acronym Definition
ACAS Airborne Collision Avoidance System

ATC Air Traffic Control
ATM Air Traffic Management
AMC-GM Acceptable Means of Compliance – Guidance Material
BVLOS Beyond Visual Line Of Sight
CIS Common Information Service
Page 10
Acronym Definition
C2 Command and Control

CNS Communication Navigation and Surveillance
CONOPS Concept of Operations
CR Change Request
DAA Detect And Avoid
EASA European Aviation Safety Agency
EATMA European ATM Architecture
E-ATMS European Air Traffic Management System
EU European Union
EUROCAE European Organisation for Civil Aviation Equipment
FATO Final Approach and Take-Off area
GAMZ Geodetic Altitude Mandatory Zone
HPAR Human Performance Assessment Report
ICAO International Civil Aviation Organisation
ICARUS Integrated Common Altitude Reference system for U-space (SESAR H2020
project)
IFR Instrument Flight Rules
INTEROP Interoperability Requirements
KPA Key Performance Area
LUC Light UAS operator Certificate
MOPS Minimum Operational Performance Standards
MS Member State
NPA Notice of Proposed Amendment
OI Operational Improvement
OPAR Operational Performance Assessment Report
OSED Operational Service and Environment Definition
PAR Performance Assessment Report
PIRM Programme Information Reference Model
PTS Prototype Technical Specifications
RPAS Remotely Piloted Aircraft Systems
QoS Quality of Service
RTTA Required Time To Act
Page 11
Acronym Definition
RWC Remain Well Clear

SAC Safety Criteria
SAR Safety Assessment Report
SecAR Security Assessment Report
SESAR Single European Sky ATM Research Programme
SERA Standardised European Rules of the Air
S3JU SESAR3 Joint Undertaking (Agency of the European Commission)
SORA Specific Operations Risk Assessment
SPR Safety and Performance Requirements
SSDR Single Seat DeRegulated
STS Standard Scenario
SWIM System Wide Information Model
TS Technical Specification
TLOF Touch-down and Lift Off
UA Unmanned Aircraft
UAM Urban Air Mobility
UAS Unmanned Aircraft System
UAV Unmanned Aircraft Vehicle
UFR U-space Flight Rules
USSP U-Space Service Provider
UTS U-space Traffic Services
VFR Visual Flight Rules
VLL Very Low Level
VLOS Visual Line Of Sight
VMC Visual Meteorological Conditions
VTOL Vertical Take-Off and Landing
Table 2: List of acronyms
Page 12
3 ConOps and regulatory environment:

observations and adjustment
opportunities
The former CORUS ConOps and now the current CORUS-XUAM ConOps (Edition 3.10) [1]has been
developed in a very active and mobile environment. ICAO panels, SJU, EUROCAE, other SESAR projects,
and especially EASA, are proposing a non-stop list of new documents and proposals for Urban Air
Mobility that the CORUS-XUAM team aims at considering and homogenizing.
The complexity of the task is huge, but at the same time very challenging. The contrast of the current
regulation with the proposed ConOps shows potential conflicts or mismatch. The objective of this task
is to find those potential conflicts and convert them into opportunities to improve the ConOps. But
also, this task aims at proposing changes in the current and in particular, in the forthcoming regulations
under development.
The list of documents that we have reviewed is given below. The order of the documents is given
according to their maturity level, and to the time they were produced.
- Regulation for manned aircraft
● (EU) No 923/2012 [10] on easy access rules for Standardized European Rules of the Air
(SERA) – and its source ICAO Annex 11 [21].
- Working groups proposing specific amendments to ICAO/State documents
● (ICAO) RPAS Panel documentation for the integration of UAS into airspace (for RPAS flying
IFR)
● SSDR: single seat microlight ‘de-regulation’ [18]
- Regulation on unmanned operations and their classification according to their risk:
● (EU) 2019/945 [2] on unmanned aircraft systems and on third country operators of
unmanned aircraft systems
● (EU) 2019/947 [4]on the rules and procedures for the operation of unmanned aircraft
● (EASA) ED Decision 2022/002/R on AMC & GM to Regulation (EU) 2019/947[22]
● (EU) 2020/1058 [3]amending delegated regulation (EU) 2019/945 as regards the
introduction of two new unmanned aircraft systems classes
● (EU) 2020/639 [5] Amending Implementing Regulation (EU) 2019/947 as regards standard
scenarios for operations executed in or beyond the visual line of sight
- Regulation on U-space:
Page 13
● (EU) 2021/664 [6], 2021/665 [7] and 2021/666 [8]on the regulatory framework for the U-
space
● (EASA) NPA 2021-14 [9]on AMC&GM to the U-space regulatory package
- Regulatory work in UAM
●
(EASA) NPA2022-06 [19] on a regulatory framework for new operational and mobility
concepts that are based on innovative technologies, like unmanned aircraft systems (UAS)
and aircraft with vertical take-off and landing (VTOL) capability-
● (EASA) work in progress for the Prototype Technical Specifications for the Design of VFR
Vertiports for Operation with Manned VTOL-Capable Aircraft certified in the enhanced
category [11]
● (EASA) public consultation on Guidelines on noise measurement of unmanned aircraft
systems lighter than 600kg operating in the specific category (low and medium risk) released
on 13 October 2022. [20]
More detailed contents of these documents are provided in section 3.2.
In the current ConOps there are already many references to the current regulation (see e.g., section
2.2.2.2 – Flight priority). In the following section we will detail how the ConOps has made efforts to
comply with the current regulation (section 3.1), a brief explanation of the content of the current
regulations, highlighting the domains of them that have much impact with the entrance of new aerial
mobility asset (section 3.2), and the comparison of both (3.3).
3.1 CORUS X UAM ConOps

The ConOps edition 3.10[1] has three major chapters as main contributions:
-Contribution 1 (Chapter 2 – Operational Environment) defines the UA flight phases, proposes

a new volume Zz, provides a way to inform UAM operations to other airspace users, and
presents basic definitions for vertiports and other ground infrastructure.
- Contribution 2 (Chapter 3 – U-space services) details the list of services offered by U-space.
- Contribution 3 (Chapter 4 – Flight Rules) motivates the need of a new set of flight rules for
UAM, proposed to be named as UFR.
Other chapters are either introductory (Chapter 1), descriptive examples (Chapter 5), basic description
of some architectural implementation details (Chapter 8) or initial proposals for improving the social
acceptance of the CORUS XUAM very large demonstration flights (Chapter 7). There is also pending
work that will be proposed in the next edition: One of the pending works is Chapter 9 – Regulatory
context, which will be fed from this deliverable. Chapter 6 – Contingency and Safety, is being developed
in a parallel task.
Through the document several definitions are presented, some are taken from the regulation, from
ICAO or from other projects. CORUS-XUAM also proposes the definitions of some concepts that we
found do not always accommodate with current regulation definitions. This document contains
proposals on revising some definitions in line with harmonisation.
Page 14
3.1.1 Contribution 1: Operational Environment

The aviation world has a long tradition of safety. The “Swiss cheese model” illustrates the safety
process very well, where each slice of cheese represents a safety barrier relevant to a
particular hazard. The application of all these barriers, each at a different time, brings as result
the high levels of safety of current aviation.
With the operational environment the ConOps translates the current safety barriers from conventional
aviation to the UAM operations. It proposes the needed activities for each different time, situating
them at different phases of the flight: Long-term strategic/design, pre-flight/strategic, pre-flight,
during flight/tactical, and post-flight. Making parallelism with the life timeline of a conventional flight,
the ConOps proposes the activities that are necessary to be taken by each stakeholder, and a new
nomenclature to avoid confusion with the original. In this way, the plan for the UAM operation is
named as U-plan, the initiation of the tactical phase is done with the U-plan activation and is finished
with the U-plan termination.
Important links with current regulation are given in the operational environment chapter: the
regulation on U-space and its on-going AMC&GM are very related with the long-term strategic phase.
The planification, definition and design of the areas to be defined as U-space airspace is defined in the
ConOps as in the hands of member states competent authorities. Also, safety works in this phase are
required for drone operators, to register as required by (EU) 2019/947[4], and to have approved
vehicles.
The following table provides the links of the flight phases and the regulatory documents that provide
some requirements in relation with the flight phase. Notice that some aspects are already raised in the
ConOps that are not mentioned by any regulation.
Flight Phase Related regulation Comment / Requirement
Strategic Long-Term (EU) 2021/664[6] U-space airspace design
(EASA) NPA 2021-14[9]
(EU) 2019/947[4] UAS operator registration
(EU) 2019/947[4] UAS type classification
(EASA) VTOL vertiport Vertiport and infrastructures

prototype[11]
Strategic Pre-Flight (EU) 2019/947[4] Operation Category
Risk Assessment
Page 15
(EU) 2021/664[6] Authorisation of U-plan
(EU) 2021/664[6] Priority of U-plans conducting

special operations
Inspired in (EU) No 923/2012[10]
none Plan for vertiport usage
Pre-tactical (EU) 2021/664[6] U-space strategic services
(EU) 2021/664[6] U-plan permission removal if

higher priority U-plan
none U-plan that crosses airspace

boundaries
none U-plan permission removal by

dynamic capacity management
and the concept of Reasonable
Time to Act
none U-plan uncertainty

quantification
Tactical none U-plan includes the time window

for the activation request
(EU) 2021/664[6] U-space tactical services
Post flight (EU) 2021/664[6] U-space Legal recording service
Table 3 Links between flight phases and existing regulations or proposals
The long-term strategic phase of the operational environment has an enormous role in the safety of
the operations. In addition to the operational plan, two aspects are introduced in the ConOps: the
airspace and the ground.
For the airspace, the ConOps proposes the harmonization of the airspace classes (from ICAO Annex 11
and SERA (EU) No 923/2012)[10] with the U-space regulatory pack and the CORUS ConOps Volumes.
Table 2 of the ConOps is a summary of the harmonization work. Below an inverse table shows how the
Volumes may be integrated in the current legislation, including the new Zz volume proposed in the
new ConOps. Zz is similar to Zu, except that the tactical separation service provides only advice to
Page 16
pilots. U-space airspace volumes are highlighted in green. Current U-space regulation is mainly
addressing volume Y for the moment.
Volume ICAO/SERA Airspace class Remark
X G In G only UAS flying in VLOS (VFR) and

limited to VLL
X or Y Restricted Area No other aircraft expected
(Declared UAS Geographical Zone)
Y Restricted Area Manned aircraft not expected or require

electronic conspicuity according to U-
(Declared UAS Geographical Zone) space regulation.
Zu / Zz Restricted Area Manned aircraft not expected or require

electronic conspicuity according to U-
(Declared UAS Geographical Zone) space regulation. Managed by Tactical
services.
Y/Za ABCDE UAS needs ATC approval
Table 4 U-space volumes and possible implementation in ICAO/SERA airspace classes
In addition, the common altitude reference proposal is based on the proposals from the ICARUS SESAR
project. The proposal is that U-space will use geodetic altitude with reference to WGS84. Four U-space
services will support any on-the-fly translation from barometric altitude. For this the ConOps proposes
to add U-space as Geodetic Altitude Mandatory Zone (GAMZ), a new concept to add in regulation,
similar to Transponder Mandatory Zone.
Neither the ConOps nor the regulation said anything about the flow management and network
structure inside the volumes.
On the ground UAM will only be possible if cities are able to allocate space and infrastructure for
vertiports (passengers and/or cargo). While the cargo vertiports are simpler than the passenger
vertiports, both need to provide capacity information to the U-space, so this could correctly manage
the flight authorizations and the emergencies.
For passenger transport in urban areas, the VTOL vertiport prototype is used in this ConOps. General
definitions of the areas for touchdown and lift-off, approach, and take-off, stands, embarking and
waiting are given. The ConOps proposes the vertiport operators as authorities and responsible of the
definition of the procedures and the provision of services to operators and information to U-space. For
VTOLs certified in the enhanced category, the U-plan will contain emergency procedures supported by
Page 17
a ground infrastructure consisting in several vertiports (nominal and alternates) and emergency
landing sites. The concept of Continued Safe Flight and Landing applies for passenger UAM.
3.1.2 Contribution 2: U-space services

The ConOps V3.10 provides an update of the list of services proposed, with some renaming and
regrouping to match with the U-space regulation pack. Below a summary list of the renamed services
and the reference to the regulation article that justifies the change.
Previous name Updated name Article
ConOps Edition 3.10
e-registration Registration 2019/947 art 14[4]
e-identification Network identification 2021/664 art 8[6]
Position report submission
[Dynamic] Geo-fencing Geo-awareness 2021/664 art 9[6]
Operational plan processing Flight Authorization Service 2021/664 art 10[6]
- Strategic Conflict Prediction 2021/664 art 10[6]
Table 5 New U-space services names
In addition, two U1 services (Registration Assistance and Operational Plan Preparation/Optimization)

have been eliminated.
All services above are U1 and U2, thus most services of U3, not yet considered in the regulation, are
kept without changes. The only exception is the split of the Tactical Conflict Resolution into two
services: one for Prediction and another for Resolution, mimicking the sibling services for strategical
phase.
The description of other services has been updated according to the regulation when they were
described. The list of these services is:
 Surveillance data exchange

 Drone aeronautical information management
 Legal recording
 Traffic information
 Weather information
New services are defined in relation to vertiports and to a common altitude reference:
 Vertical Conversion (U2)
Page 18
 Vertical Alert & information (U2)

 Vertiport Availability (U3)
Finally, what the regulation refers as Conformance Monitoring, in the ConOps still appears as two
separated services: Monitoring, and Emergency Management.
As a summary, figure X shows the new proposed services and their organization by functionalities and
phases:
Identification and Airspace Mission Conflict Emergency Environmental Interface with

Monitoring
Tracking Management Management Management Management data ATC
Drone Strategic Procedural

Registration Aeronautical Flight Emergency Conformance Weather
Conflict interface with
(includes query) Information Authorisation Management Monitoring Information
Detection ATC
Management
Strategic Incident / Geospatial Collaborative

Network Common U-plan Traffic
Conflict Accident information interface with
Identification Information processing Information
Resolution reporting service ATC
Geo-awareness Tactical
Dynamic Citizen
Surveillance (includes Tactical Conflict Vertical Alert & Population Operational
Capacity Reporting
Data Exchange Dynamic Geo- Detection Info density map Message Info
Management service
Fencing) Exch
Geofence `Navigation Electromagneti

Vertiport Tactical Conflict
Tracking Information Infrastructure c interference
Availability Resolution
Exchange Monitoring information
Communication Navigation
Vertical
Infrastructure Coverage
Conversion
Monitoring information
Communication
Legal Recording Coverage
information
Risk Analysis
Digital Logbook
Assistance
Figure 1 U-space services of ConOps 4
3.1.3 Contribution 3: U-space Flight Rules (UFR)

Although some unmanned aircraft, equipped with required avionics, are classified as IFR and able to
fly in controlled airspace, the high increase of the number of UAM aircraft and their characteristics
make them not suitable for either VFR or IFR. Current regulation allows the mix of VFR and IFR traffic
in some airspace classes, making the integration of unmanned traffic even more complicated. In both
flight rules the pilot remains the last responsible of the safety of the aircraft, but IFR provides additional
services to help pilots in their duty.
The ConOps proposes that the rules of the air in the U-space airspace needs a different approach, in
which all participants (manned and unmanned) will share the same rules. These new rules basically
follow the information and separation services given uniquely by U-space. Even any clearance or
information originated from ATC will be communicated to an UFR aircraft by means of the U-space.
To be able to enter U-space and follow the UFR all aircraft are requested to:
 Be electronically conspicuous
 Receive the traffic information about other aircraft in the volume
 Adhere to ATS instructions received via U-space
 Use the separation services provided by U-space
Page 19
3.2 Existing regulatory Environment

The following two sections aim at setting the scene of the current international and European
regulatory frameworks, and at identifying the relationships with the ConOps. If any gaps appear, they
will be raised.
Hence, the text below will:
 List the set of documents that have been reviewed, with a description of the main theme for
each. The documents reviewed are those available, adopted or on NPA format, in October and
November 2022, which could have links on one way or another with U-space and/or urban air
mobility.
 Identify the domains of the ConOps that are impacted.
 Identify the domains where information and regulation are missing.
3.2.1 Current regulations

3.2.1.1 (EU) 2019/945 on unmanned aircraft systems and on third country
operators of unmanned aircraft systems
COMMISSION DELEGATED REGULATION (EU) 2019/945 of 12 March 2019[2] on unmanned aircraft
systems and on third-country operators of unmanned aircraft systems is a European regulation.
 This Regulation lays down the requirements for the design and manufacture of unmanned
aircraft systems (‘UAS’) intended to be operated under the rules and conditions defined in
Implementing Regulation (EU) 2019/947[4] and of remote identification add-ons. It also
defines the type of UAS whose design, production and maintenance shall be subject to
certification.
 It also establishes rules on making UAS intended for use in the ‘open’ category and remote
identification add-ons available on the market and on their free movement in the Union.
 This Regulation also lays down rules for third country UAS operators, when they conduct a UAS
operation pursuant to Implementing Regulation (EU) 2019/947 [4]within the single European
sky airspace.
It applies to all UAS categories of operations as described in (EU) 2019/947[4].
This regulation provides many definitions such as the ones of UA, UAS or UAS operator.
The annex provides an exhaustive description of the requirements for UAS of class C0, C1, C2,
C3 and C4.
Part 13 of the annex lays down the methods of measurement of airborne noise, Part 14 details
the labelling that UA must show (measures shall be used for the determination of the A-
weighted sound power levels and given in dB). Part 15 provides the limits of noise of UA classes
C1 and C2 (Class C3 is missing in the table where maximum sound power level is defined).
Maximum noise limits are from 85 dB(A) to 81 dB(A), decreasing on forthcoming years, plus
some extra noise allowed for vehicles with higher mass.
Page 20
3.2.1.2 (EU) 2020/1058 amending delegated regulation (EU) 2019/945 as regards

the introduction of two new unmanned aircraft systems classes
COMMISSION DELEGATED REGULATION (EU) 2020/1058 of 27 April 2020[3] amends Delegated
Regulation (EU) 2019/945 as regards the introduction of two new unmanned aircraft systems classes
is a European regulation.
(EU)2019/945 articles are updated to reflect adoption of two additional UAS classes, C5 and C6. It also
adds to (EU)2019/945[2] definitions of:
 Command unit (‘CU’).

 C2 link service.
 Night.
The annex content is the same to the one of (EU)2019/945 [2]with class C5 and C6 add-ons.
3.2.1.3 (EU) 2019/947 on the rules and procedures for the operation of unmanned
aircraft
This Regulation lays down detailed provisions for the operation of unmanned aircraft systems as well
as for personnel, including remote pilots and organisations involved in those operations.
The document provides:
More information about the categories of UAS operations (articles 3 to 6), in particular which
operations are in the certified category. Lots of UAM UAS operations will be conducted in that
category. The annex details the operations in the open and specific categories and provides the
requirements for a Light UAS operator Certificate (LUC).
Requirements for remote pilots operating in the open and specific categories (article 8 and 9).
Requirements for conducting an operational risk assessment (article 11, SORA is not mentioned!).
Requirements for conducting a UAS operation (e.g., UAS operator registration (article 14), definition
of geographical zone services (article 15), tasks of the competent designated authority (article 17 and
18), as shown in figure 2.
Page 21
Article 15 Article 14 Annexes:

Geographic Zones Registration Identification
Drone
Direct
Aeronautical Network Remote
Geo-awareness Registration Identification
Information Identification
capability
Management
User interaction: On-line queries / position reporting

“CRUD” interoperability subservice
Figure 2 U-space services and (EU) 2019/947 articles
3.2.1.4 (EU) 2020/639 Amending Implementing Regulation (EU) 2019947 as regards

standard scenarios for operations executed in or beyond the visual line of
sight
COMMISSION IMPLEMENTING REGULATION (EU) 2020/639 of 12 May 2020 amends[5] (EU) 2019/947
[4]by integrating two standard scenarios for operations executed in or beyond the visual line of sight.
They are detailed in the appendix 1.
STS-01:
 Describes an operation in VLOS over controlled ground area in a populated environment.
This scenario could typically occur in an urban environment but would not be part of what is
called UAM. However, operation that would take benefit of STS-01(e.g., building inspection,
photography) would probably interfere with UAM operations.
 Shows responsibilities of UAS operator and remote pilot and remote pilot training and skills
requirements.
STS-02:
 Describes an operation in BVLOS with or without airspace observers over a controlled ground
area in a sparsely populated environment. This scenario could also occur in an urban
environment, possibly when most people are sheltered (e.g., at night). As for STS-01, it is likely
that that kind of operation is not part of UAM (except for carriage a specific goods for instance)
but would probably interfere with UAM operations.
Page 22
 Shows responsibilities of UAS operator, remote pilot, and airspace observer as well as remote
pilot training and skills.
Appendix 3 provides requirements for entities conducting practical skill training and assessment of
remote pilots for operations covered by a standard scenario.
Appendix 5 lists the minimum content of the operation manual for a standard scenario.
This amendment also defines for instance the observer, the contingency volume and the ground risk
buffer.
(EU)2019/945[2] and 2019/947[4] were already published when CORUS ConOps edition 3 was
shared in October 2019. These parts of the regulation had been considered for that version of the
ConOps. Amendments of 2019/945 by (EU) 2020/1058[3] and of 2019/947[4] by (EU)2020/639[5]
were published later, hence both UAS classes 5 and 6 and standard scenarios STS-01 and STS-02 are
not addressed in that version of the ConOps.
Reviewing those amendments may bring additional possibilities for UAM operations, and there also
is a need to check that UAM operations are in line with the content of 2019/945[2] and 947[4].
3.2.1.5 Commission implementing regulations 2021/664, 665 and 666

Commission implementing regulations (EU) 2021/664[6], 665[7] and 666[8] pave the way of a U-space
regulatory framework.
2021/664:
 Lays down rules and procedures for the safe operations of UAS in the U-space airspace, for the
safe integration of UAS into the aviation system and for the provision of U-space services.
 Introduces the definitions, descriptions and/or role of a U-space airspace, U-space service,
airspace risk assessment, common information service and dynamic airspace reconfiguration.
 Provides the general requirements for UAS operator and U-space service providers.
 Provides the list of minimum U-space services that shall be provided in a U-space airspace/UAS
geographical zone. See figure X and figure Y.
 Shows conditions for obtaining a USSP or CIS certificate.
Page 23
Article 5
Article 4 DAR Article 8 Network Article 9 Geo-
Common 2021/665 Identification awareness
Information Service
Geo-awareness (1)
USSP catalogue U-space airspace (Surveillance) Identification Geo-awareness (2)
bounds
Drone Aeronautical
Dynamic Airspace Surveillance data
Information Tracking (1)
Reconfiguration exchange (1)
Management
Figure 3 Common Information service, Dynamic Airspace Reconfiguration and U-space services referenced by
(EU) 2021/664 articles 4-5, 8-9
2021/665:
 Amends Implementing Regulation (EU) 2017/373[24] as regards requirements for providers of

air traffic management/air navigation services and other air traffic management network
functions in the U-space airspace designated in controlled airspace.
 Introduces the dynamic reconfiguration of the U-space airspace allowing temporary manned
traffic transit through a U-space airspace and proper coordination (article 1 (3)).
2021/666:
 Amends Regulation (EU) No 923/2012[10] as regards requirements for manned aviation

operating in U-space airspace.
 Introduces electronic conspicuity of manned aircraft operating in airspace designated as U-

space airspace and not provided by an air traffic control service (article 2 c)).
Page 24
Article 13
Article 10 Flight Article 11 Traffic Article 12 Weather
Conformance
Authorisation Information information service
Monitoring
Operation plan
processing Strategic conflict Dynamic capacity Emergency Emergency
Traffic Information Monitoring
detection management Management Management (2)
Full flight lifecycle
Tracking (2)
Strategic conflict Surveillance data
Position reporting
resolution exchange (2)
(2)
Figure 4 U-space services referenced by (EU) 2021/664 articles 10-13
2021/664[6], 665[7] and 666[8] are setting the basement of the regulatory framework for U-space.
In particular, three important requirements are raised:
 At least four mandatory services shall be provided in a U-space airspace (UAS flight
authorisation service, traffic information service, network identification service and geo-
awareness service).
 Two are proposed as optional if deemed useful by the member state (weather information
service and conformance monitoring service).
 Manned and unmanned operations shall be segregated in controlled airspace.
 Manned aircraft shall be conspicuous in U-space airspace.
The ConOps addressing UAM operations already describes several U-space services, including the
compulsory four. Nevertheless, there may be differences in the way the services are named and
their roles.
In addition, The ConOps has a long-term vision which could go beyond EASA’s.
That review aims at identifying the differences.
3.2.1.6 NPA 2021-14
This Notice of Proposed Amendment 2021-14[9] proposes acceptable means of compliance and
guidance material to support the U-space regulation, meaning it deals with Regulations (EU)
2021/664[6], (EU) 2021/665[7], (EU)2021/666[8].
The document provides explanation(why) and a lot of details on the regulation contents and gives
guidance on how these regulations could be implemented.
Topics addressed in the document are the following:
 U-space airspace
Page 25
 Dynamic airspace reconfiguration
 U-space stakeholders such as USSP, CIS or UAS operators’ roles, responsibilities, and
certification
 U-space services
 Competent authorities
AMC-GM bring additional information and details to 2021/664[6], 665[7] and 666[8]. Reviewing this
document complements the review of these regulations.
3.2.1.7 Easy Access Rules for Standardized European Rules of the Air (SERA)
The Standardised European Rules of the Air are transposing, adapting, and complementing the ICAO
annex 2 for Europe.
It aims at establishing the common rules of the air and operational provisions regarding services and
procedures in air navigation that shall be applicable to general air traffic within the scope of Regulation
(EC) No 551/2004[25].
This Regulation:
 Shall apply in particular to airspace users and aircraft engaged in general air traffic:
 Operating into, within or out of the Union.
 Bearing the nationality and registration marks of a Member State of the Union and
operating in any airspace to the extent that they do not conflict with the rules
published by the country having jurisdiction over the territory overflown.
 Shall also apply to the competent authorities of the Member States, air navigation service
providers, aerodrome operators and ground personnel engaged in aircraft operations.
 Shall not apply to model aircraft and toy aircraft. However, Member States shall ensure that
national rules are established to ensure that model aircraft and toy aircraft are operated in
such a manner as to minimise hazards related to civil aviation safety, to persons, property or
other aircraft.
The topics addressed in SERA with which the ConOps could have links somehow are the following:
 Instrument and visual flight rules

 VMC minima
 Collision avoidance
 Flight plan
 Airspace classification
 Air traffic services (control, information, alert)
 Interference, emergency, contingencies, and interception
 Voice communication procedures
Appendix 1 deals with the “signals” and is likely to have no application in the “unmanned” world, at
least not in this form.
Page 26
Appendix 2 addresses the unmanned free balloons.
Rules of the air are one of the biggest challenges for UAS provided their specificities and obvious non
full compliance to existing ones for manned aviation. All existing rules that could be applied to UAS
operations would help to mix operations. On the contrary, those that are inconsistent shall be
identified and new rules of the air for UAS operations proposed.
3.2.1.8 EASA “Prototype Technical Specifications for the Design of VFR Vertiports
for Operation with Manned VTOL-Capable Aircraft “certified in the
enhanced category
This PTS[11] focuses on the design of VFR vertiports for operation with manned VTOL -capable aircraft
certified in the enhanced category. As a reminder, SC VTOL category ‘Enhanced’ are used for the
commercial air transport of passengers, including VEMS operations, or for the commercial and non-
commercial air transport of cargo taking place outside congested areas. Thus, only the first part, with
the transport of passengers, concerns the urban air mobility.
It provides a lot of details and requirements about the geometry of vertiports (e.g., FATO, TLOF, stands,
visual aids and markings).
Also are described the shapes of approach, transitional and take-off climb surfaces, with obstacle
limitations.
General information on vertiports is of utmost importance in the frame of urban air transportation,
as points of departures, arrivals, and as contingency and emergency landing facilities.
3.2.1.9 EUROCAE MOPS ED-269 and ED-270 on Geofencing and Geo-caging

These two standards, very related one to the other, detail the UAS on-board function that, based on
the data provided by the State (or entitled trusted sources) on UAS geographical zones, detects a
potential breach of airspace limitations and assists the remote pilot in preventing that breach.
Differences between the two functions are (Sect. 1.3):
 The Geofencing function prevents the UA to penetrate in a forbidden zone.

 While the Geo-caging function prevents the UA to exit out of a zone pre-defined by the
operator
Both define two levels of automation in case of breach detection:
 When the function is limited to alerting the pilot is called Geo-awareness.

 When the function prevents the breach by engaging an adequate manoeuvre without any pilot
action is called Geo-caging / Geofencing.
The function can be implemented as a set of hardware and/or software components inside the UAS,
this is, in the remote pilot station and/or on board the UA itself. The function shall be fed by data (e.g.,
data about the applicable airspace restrictions) provided by a ground service. The expected
characteristics of the output and interface of the ground service are also defined by these MOPS.
Section 3.1 provides the list of functions that include alarms, reactions, and safety buffers for the fence
volumes.
Page 27
Appendix 1 details the margin distances on the volume limits that shall be defined and implemented
by the manufacturer, considering the accuracy of the UAS position/altitude measurement in
comparison with the geographical zone limits.
The topics addressed in ED-269[12] and ED-270[13] with which the ConOps could have links somehow
are the following:
 Flight Authorisation
 Geo-awareness and geo-fence services, but not mention of Geo-caging
 Monitoring service
 Flight Information Service
The goal by reviewing these MOPS is to refine in the ConOps the description of the Geo-XXX services
that could be relevant for UAM operating in U-space (standards for defining the geographical shape
of the geofence, informative/automatic reactions, safety buffer, distance to alarm, etc.)
3.2.1.10 RPAS Panel documentation
All documents of the RPAS Panel are relative to IFR unmanned aircraft with one remote pilot in control
(IFR-RPAS).
 RPASP/16-WP/15(24/09/2020)[14]
The document reviewed is the working paper RPASP/16-WP/15 dated on 24/09/2020, from the
Remotely Piloted Aircraft Systems Panel (RPASP), sixteenth meeting. It addresses lost C2 link and
detect and avoid procedures.
Only the part on C2 link loss seems to be relevant. The information provided on the DAA procedures
embed the Remain Well Clear function (RWC) and suppose the presence of a remote pilot, which would
not often be the case with a long-term perspective.
Back to the C2 link loss procedures, the working paper describes the procedures to be followed by an
RPAS in case of command-and-control link loss during en-route, departure and arrival phase. The
unmanned vehicle would fly with instrument flight rules mainly in controlled airspace.
The goal by reviewing this document is to capture information that could be relevant for UAS
operating in U-space and which would be affected by the same failure.
 RPAS/19-WP/5(17/02/2022)[15]
This document presents the results of simulation of loss of C2-link, including human-in-the loop, and
proposes how to add the loss of C2 procedures in the aeronautical chart. The working group also
proposes the Special loss of C2 procedures in some specific airports.
No new relevant information to add to the previous document
 RPAS/19-WP/6(22/02/2022)[16]
The document lists the regulated procedures that need to be reviewed for IFR-RPAS, such as visual
self-separation, separation minima, ability to flight instrumental procedures, ACAS (DAA & RWC).
Page 28
Not mature enough proposals to be able to consider them for the ConOps
 RPAS/19-WP/7(22/02/2022)[17]
This working group document proposes amendments to ICAO Annex 10 Vol II on Aeronautical
telecommunications by introducing prefix REMOTE in RPA call sign
The goal by reviewing this document can be useful in the description of the Interface with ATM
service and on the requirements for UAM flying in Za volume.
3.2.1.11 SSDR: single seat microlight

The British Microlight Aircraft Association Technical Information Leaflet[18] introduces the
characteristics and general usage requirements of that kind of aircraft which weight is limited to a
maximum of 330kg in its maritime version, with only one person on-board.
This document has been taken on-board the regulatory framework reviewing process as we initially
thought it could be of interest if we consider microlight aircraft as possibly close to unmanned taxi
drone.
Unfortunately, we did not find any useful information, for our task, in this document.
3.2.1.12 “” NPA2022-06” “Introduction of a regulatory framework for the

operation of drones Enabling innovative air mobility with manned VTOL-
capable aircraft, the initial airworthiness of unmanned aircraft systems
subject to certification, and the continuing airworthiness of those
unmanned aircraft systems operated in the ‘specific’ category”
EASA developed NPA 2022-06[19] to encompass in existing regulations usage of a new category of
aircraft, VTOL capable aircraft, in a manned or unmanned configuration. These aircraft are expected
to operate for urban air mobility. It is explained that these VTOL capable aircraft are different to
helicopter, hence operating them requires an update of several document such as (EU) No
748/2012[26], (EU) 2019/945[2] or (EU) 923/2012[10].
The operational objective of the proposal is to establish a coherent regulatory framework to enable
the airworthiness for UAS subject to certification which are operated in the ‘specific’ category and of
operations with manned VTOL-capable aircraft.
The scope of the proposed amendments to Commission Regulation (EU) No 748/2012[26] includes
UAS subject to certification independently of the category in which they are operated (‘specific’
category or ‘certified’ category).
Despite many parts dedicated to the unmanned configuration (text is “reserved”) are still missing,
airworthiness, maintenance and certification of personnel and components processes, and
requirements (ML-UAS and CAO-UAS) are provided.
Expectations in reviewing NPA2022-06 are to find information on vehicles and possibly procedures
applicable to what would be used for urban air mobility operations.
Page 29
3.2.1.13 (EASA) public consultation on Guidelines on noise measurement of

unmanned aircraft systems lighter than 600kg operating in the specific
category (low and medium risk) released on 13 October 2022.
This document extends the noise requirements of UAS flying, provided in EU 2019/947[4] and EU
2018/1139[27] for the Open category operations, to the Specific category. The procedures to measure
the noise consider level flight (with tests at 50 m of altitude from the recording equipment) and
stationary flight (tests at 25 m above measurement point). Environmental conditions, AUS mass and
speed and recording equipment are detailed and corrections to apply when these cannot be met are
also given. SUBPART D shall contain the limits of the noise, but this section is still not published.
3.2.1.14 (EASA) ED Decision 2022/002/R on AMC & GM to Regulation (EU)

2019/947 that amends AMC-GM for (EU) 2019/947
In the AMC-GM for (EU) 2019/947[22], the following domains could be of particular interest for the
ConOps.
 Definitions for the following terms:
o Dangerous goods (AMC1 article 2 and GM1 article 2 (11))

o Privately built (GM1 article 2 (16))
o Uninvolved persons (GM1 article 2 (18))
o Controlled ground area (GM1 article 2(21))
o Flight geography, Flight geography area, Contingency volume, Operational volume,
Ground risk buffer, Contingency area (GM1 article 2 (28 to 33))
o Responsibilities of the airspace observer (GM1 article 2 (25))
 Description in detail of the rules for conducting an operational risk assessment with many
applications examples on operations in the specific category, including examples of scenarios
STS-01 and STS-02.
 Full description of SORA methodology.
 Operational conditions for UAS geographical zones (article 15):
o Means to inform manned aviation of UAS geographical zones

o Cross-border UAS geographical zone(s)
o Data integrity and quality
o General aspects
o Exemption(s) for the open category
o Common unique digital format
o Publication of information on UAS geographical zones in the aeronautical information
products and services
o Publication of maps of UAS geographical zones
3.2.2 Domains impacted by the regulations and gaps

3.2.2.1 Domains identified
The different reviews of the ConOps and above selected documentation show that several domains
are already addressed:
Page 30
 Airspace (manned and U-space) and related ATM or U-space services content.
 Roles and responsibilities of ATM and U-space stakeholders.
 Rules of the air, including weather consideration.
 Operation infrastructures (for VFR manned VTOL capable aircraft operation; unmanned VTOL
should come later).
 UAS contingency procedures: UAS Command and control link failure procedure for IFR-RPAS,
which is a sub-category of UAS.
 Detect and avoid equipment.
 Requirements for VTOL capable aircraft operations (mainly manned, unmanned parts should
come later) and airworthiness.
 Definitions (e.g., Geo-awareness, geo-fencing, geo-caging).
3.2.2.2 Gaps
Despite detailed differences are introduced in sections 3.3.1 and 3.3.2, the paragraph below proposes
to list the main thematic that are still missing, both in current regulations and/or in the Conops:
In the ConOps:
 Cross border operations (AMC1 article 13 of Easy Access Rules for UAS)
 Remote pilot (UAS.OPEN.060 and UAS.SPEC.060) (and other stakeholders) responsibilities
(only roles are depicted).
 UAS equipment failure procedures and U-space equipment and services failure procedures (is
MEDUSA adapted to UAM environment?).
 Rules of the air for UAS (UFR are, for the moment, more rules of “ATS” services (control,
information, and alert provision).
 Better description of manned aircraft operations in U-space (e.g., connection to U-space,
requirements).
In the regulation:
 EASA regulation does not mention U-space volumes as defined in the ConOps; most U-space
projects refer to these volumes.
 VTOL capable aircraft operations in IFR, VTOL capable aircraft unmanned operations and
Vertiport operations for unmanned VTOL.
 Rules of the air for UAS.
 Social acceptability: (EU) 2019/945[2] and (EU) 2020/1058[3] provide information on UAS
noise limitations for UAS of classes C1, C2, C3, C5 and C6. Guidelines on noise measurement
of unmanned aircraft systems lighter than 600kg operating in the specific category provides
noise measurement and flight test procedures for UAS lighter than 600kg in the specific
category. These may cover operations of UAS transporting goods without flying over assembly
(ies) of people.
Missing issues:
o Noise limitation level(s) for UAS operating in the specific and the certified categories.
o Any consideration of UAS flights (whatever the size or the category of operation)
impact on privacy.
Page 31
o Lowest altitude limitation and characteristics of the landing areas to preserve privacy
and reduce noise impact.
3.3 Comparison between ConOps and regulation

This section describes the differences identified between the CORUS X UAM ConOps and the regulatory
documents listed in the section 3.2.1. For each item, this section suggests changes to apply on the
existing regulation framework (if required) or on the CORUS X UAM Conops in order to adapt or
improve their compatibility.
3.3.1 Differences and possible impacts on ConOps

This section lists all the differences grouped by document and suggests the possible associated impacts
on the CORUS X UAM ConOps.

(EU) 2019/945[2] provides the following definitions:
Article 3(4) of the UAS operator: “unmanned aircraft system operator’ (‘UAS operator’) means any
legal or natural person operating or intending to operate one or more UAS”.
Should we use, in the architecture section, the exact definition provided in the regulation?
(Article 3(13)) “manufacturer” means any natural or legal person who manufactures a product or has
a product designed or manufactured and markets that product under their name or trademark”.
Should we try to combine both definitions and adapt it to “UAS manufacturer” in the
architecture section?
It also set in (Article 40) requirements for UAS operated in the “certified” and “specific” categories.
This explains why UAS used for UAM shall be certified. Article 40 has been updated by regulation
2020/1058[3].
Should we mention these conditions in section 2.2.2.1?

See above remark for article 40.
aircraft
Article 6/(b) lists the type of UAS operations that require to be classified in the “certified category”.
The ConOps should precise the conditions met for certified category of UAS operation in section
2.2.2.1.
Page 32
3.3.1.4 (EU) 2020/639 Amending Implementing Regulation (EU) 2019/947 as

regards standard scenarios for operations executed in or beyond the visual
line of sight
The Appendix 1/Chapter 2/ UAS.STS-02.050 sets the “Responsibilities of the airspace observer”.
If The ConOps intends to introduce remote pilot responsibilities, it should also consider the role of
airspace observers in the U-space ecosystem and their interaction with the system.
3.3.1.5 (EU) 2021/664, 665 and 666 on a regulatory framework for the U-space
(amending (EU) 2017/373 & (EU) 2012/923)
We noted discrepancies with U-space volumes requirements:
 The U-space ConOps edition 3 describes some U-space “Volumes” in which different services
should be used. For Y and Z an approved plan is required, but not for X volume. In X volumes
flights need no plan and receive no separation service, which implies that X volume cannot be
considered as U-space airspace volume if we consider the EU regulation 2021/664[6].
 EU regulation 2021/664[6] defines U-space volumes as volumes where 4 mandatory services
and two optional services are provided, being one of the mandatory services the UAS flight
authorisation service. As stated in Article 10 “The U-space service providers shall provide UAS
operators with the UAS flight authorisation for each individual flight, setting the terms and
conditions of that flight, through a UAS flight authorisation service” and as no flight
authorization is required in Volume X, this is in direct conflict with the EU regulation
2021/664[6].
In addition, the ConOps[1] introduced the idea of RTTA whereas the regulation uses the notion of first
filed – first served. There is a difference in the way fairness could be managed: is it fair to penalize
businesses that cannot accommodate impacts on their U-plans very shortly before activation or to
penalize businesses that have no other choice but to fill U-plans close to the operation start?
3.3.1.6 NPA 2021-14

NPA 2021-14[9], through article 3, 2.3.4, includes a guideline for MSs to define U-space airspace,
considering in the risk assessment aviation and non-aviation issues (i.e., environment). They are
combined to set the TLS.
The ConOps focuses only on operation risks and could also add airspace design consideration.
In Article 4, 2.3.5, it states clearly that ATC is responsible for Dynamic U-space Airspace reconfiguration.
The ConOps[1] only mentions two dynamic services (capacity and geo-awareness) and as source of
contingencies. ConOps could mention the “Dynamic U-space Airspace reconfiguration” as
functionality of the “Collaborative Interface with ATC” service of U-space.
In Article 5, a more extensive definition of the CIS is provided, compared to the one in the ConOps.
The ConOps[1] could incorporate a summary of the CIS characteristics or refers to the AMC and GM
articles.
Article 6(5) mentions to limit the time window (max-min) for the request of activation of the approved
operation.
Page 33
The ConOps[1] proposes the RTTA (only minimum) but not for the activation, only for the
submission. ConOps could harmonize time window concepts in CONOPS: strategic (RTTA), pre-
tactical (activation), + for departure (tactical window).
The ConOps[1] is globally missing a lot of information developed in SERA such as alerting service
(unless it is part of U-space emergency service) or emergency contingencies and interception
services. UFR would need further development.
Wake turbulences are mentioned nowhere in the ConOps.
enhanced category
PTS VPT-DSN.B.110 “Vertiport reference point” mentions Operations from uncertified vertiport.
We did not address the required certification, or not, of the vertiport, in the ConOps[1]. Should we?
In addition, it is likely that vertiports for operation with unmanned VTOL, whatever the category,
would have more or less the same requirements. Although this regulation has no direct effect on the
concept of operations, it may considerably affect the development of UAM.

Sect.3.1 provides details on UAS systems for geo-caging and geofencing that include alarms, react,
volumes (buffer, exclusion, etc.).
The ConOps[1] explicitly mentions in Section 1.3.4-Not in scope- the onboard systems are not
considered, but the ConOps description of the Geo-XXX services could add a reference to the EUROCAE
standards and make clear the difference between the standards (on-board function) and the U-space
(services).
Should we add that the Geo-XXX services description, in addition to provide the geographical shape
of the geofence, shall/should include additional information, such as, type of alarms
(informative/reactive), safety buffers, distance to alarm, etc.

 (RPASP/16-WP/15[14] details a loss of C2-link procedure
Should ConOps include a similar contingency procedure for loss of C2, either planned in the U-plan
approval or as part of the Contingency Management service. Currently drone execute a return to
home (RTH), which is not safe if more traffic is around.
 (RPAS/19-WP/7[17]) introduces the prefix ‘remote’ in the call sign of an IFR-RPAS as part of
the phraseology with ATC.
Page 34
ConOps could include mention the necessity of a call sign for Za volumes and Interface with ATC
services.

No relevant information found.
3.3.1.12 NPA 2022-06 on innovative air mobility with manned VTOL-capable

aircraft
The document introduces in paragraph §2 the definition of the Innovative air mobility (IAM) as “the
safe, secure and sustainable air mobility of passengers and cargo enabled by new-generation
technologies integrated into a multimodal transportation system”".
ConOps could mention this notion of Innovative air mobility.
In paragraph §2 again, definition of Urban air Mobility (UAM) as” the subset of IAM operations
conducted in to, within or out of urban environments” is shared.
ConOps could adjust our definition of UAM.
§2 and 2.3.4.1, definition of VTOL capable aircraft: “a power-driven, heavier-than-air aircraft, other
than aeroplane or rotorcraft, capable of performing vertical take-off and landing by means of lift or
thrust units used to provide lift during take-off and landing.”
… “It is proposed to limit the definition of ‘helicopter’ to “heavier than-air aircraft supported in flight
chiefly by the reaction of the air on up to two power-driven rotors on substantially vertical axes”. This
would imply that aircraft configurations with more than two power-driven rotors should be initially
classified as ‘VTOL-capable aircraft’ for the purposes of the above-mentioned Regulations.”
The ConOps[1] addresses “VTOL capable aircraft” and provide the definition of VTOL. Suggest
changing.
UAM.OP.VCA.105 Use of aerodromes or operating sites states that “for the purpose of VTOL-capable-
aircraft operations, aerodromes (including heliports and vertiports) and operating sites are considered.
Vertiports are aerodromes predominantly used by and designed to accommodate VTOL-capable
aircraft. Vertiports shall have adequate infrastructure and provide necessary services regarding
operations with VTOL-capable aircraft. Operating sites may only have a suitable surface for take-
off/landing. Operations with passengers will only be possible to aerodromes. Cargo operations may
use operating sites as well. ‘Operating site’ is defined in Regulation (EU) No 965/2012 as follows:
‘“operating site” means a site, other than an aerodrome, selected by the operator or pilot-in-command
or commander for landing, take-off and/or external load operations.’”
ConOps to consider operating site as a new facility.
A general remark on the content of whole document: VTOL capable aircraft is seen as possibly being
manned or unmanned. It may engender confusion to manned aircraft pilot when having these aircraft
in sight; manned or unmanned and all what it implies?
ConOps could address that if the same type of aircraft could be manned or unmanned, there could
be confusion for manned aircraft pilots. This is valid also for any manned aircraft transformed into
unmanned (e.g., cargo). If pilots on-board aircraft flying in U-space airspace are connected to U-
space, there could be indication on the HMI that an aircraft is unmanned.
Page 35

3.3.2 Differences and possible impacts on regulations

This section lists all the differences grouped by document and suggests the possible associated impacts
on the existing regulation framework.

The ConOps[1] is in line with (EU) 2019/945[2], hence does not contain information in contradiction
with this regulation.

The ConOps[1] is in line with (EU) 2020/1058[3], hence does not contain information in contradiction
with this regulation.
aircraft
The two following updates of the document are seen of interest:
 Definition and description of UAM.

 Consideration of rules and procedures for the safe operations of UAS in the U-space airspace,
for the safe integration of UAS into the aviation system and for the provision of U-space
services as it is described in (EU) 2021/664.
3.3.2.4 (EU) 2020/639 Amending Implementing Regulation (EU) 2019/947 as

regards standard scenarios for operations executed in or beyond the visual
line of sight
Regulation (EU) 2020/639 should be updated or adapted with the following ideas:
 Annex Part B/UAS.SPEC.020 Operational declaration/1. b) should refer to U-space volumes

instead of airspace classes.
 Annex Part B/UAS.SPEC.060 Responsibilities of the remote pilot/2 & 3) should ensure that
UAS is connected to U-space system if a part of the flight is included in a U-space volume and
this prior to the start of the operation.
 Appendix 1/Chapter 1/UAS.STS-01.030 Responsibilities of the UAS operator/5 & Appendix

1/Chapter 2/UAS.STS-02.030 Responsibilities of the UAS operator/5) should be adapted so
U-space shall ensure the level of performance for any externally provided service necessary
for the safety of the flight is adequate for the intended operation in case of a flight in a U-
space volume.
 Appendix 1/Chapter 1/UAS.STS-01.030 Responsibilities of the UAS operator/7 & Appendix

1/Chapter 2/UAS.STS-02.030 Responsibilities of the UAS operator/7) should be adapted to
Page 36
take account U-space high level of automation specifically on data with frequent update
(e.g., data related to geo awareness).
 Appendix 1/Chapter 1/UAS.STS-01.040 Responsibilities of the remote pilot/2. d & Appendix

1/Chapter 2/UAS.STS-02.040 Responsibilities of the remote pilot/2. d) should define the role
of UAS flight supervisor as it cannot be assimilated as remote pilot (e.g., the limit of one UAS
per remote pilot).
3.3.2.5 (EU) 2021/664, 665 and 666 on a regulatory framework for the U-space
(amending (EU) 2017/373 & (EU) 2012/923)
The three modules on the regulatory framework for the U-space are missing the two volumes Y and Z
proposed in the ConOps, such as the Emergency Management service, Infrastructure Monitoring
service, Vertical Alert and Information Service, Accident and Incident Reporting service, Tactical
Conflict resolution service, Collaborative Interface with ATC and more.
In addition, another notable discrepancy is the fact that (EU) 2021/664[6], 2021/665[7] and
2021/666[8] and (EASA) NPA 2021-14 on AMC&GM[9] define a means of operating in U-space airspace
which does not include a Tactical conflict resolution service, but this ConOps develops this service and
the way it works.
Hence, there is a clear lack of U-space services in the regulation, some being probably more than useful
(e.g., emergency management, Dynamic Capacity Management).
Regulation does not develop all the services that will be required for an efficient and safe UAS traffic
management. Conops has a long-term approach whereas regulations’ have a short one.
3.3.2.6 NPA 2021-14

The regulation is referring to operational environments that are described in the ConOps with volume
identifications (X, Y, Za, Zu, Zz).
Could EASA adopt CORUS volumes descriptions?
One of the general comments is that SERA[10] will have to embed the level of autonomy of UAS.
This impacts many acceptable means of compliance, guidance material and rules of the air.
Below is shared our more detailed analysis of what we considered the more relevant articles:
 GM1 article 2(45): Area navigation
UAS will need to be able to comply with the RNP requirements. It is likely that new RNP requirements
are set, more constraining for UAS.
 SERA 2005: Applicability and compliance.
Rules of the air for aircraft flying in U-space airspace to be defined (Named UFR in the ConOps).
 SERA 2010: responsibilities.
Page 37
 a): Pilot in command, how do we intend to deal with this in regard of an

operator controlling one or more UAV’s. PIC is remote, see and avoid doesn’t
work unless VLOS is used.
 b): Is not compatible with ConOps. Parts are adequate, i.e., check “fuel”,
respect flight rules. A part (c) for UAV is needed.
 SERA 2015: About PIC.
Needs to be updated with remote pilot or UAS supervisor consideration.
 SERA 3105: Sections on minimum heights.
Need to be updated and adapted for UAS.
 SERA 3110: Deals with cruising levels.
This will have to be updated with the common altitude reference systems information.
 SERA 3115, 3120: Dropping, spraying.
This is what many UAV will do: dropping, spraying, delivering by winching down goods, Specific UAV
part needed.
 SERA 3201: Deals with collision avoidance.
This is true in U-space as well, but the part regarding PIC (see above) is different for UAV. DAA will
be the ACAS. Update needed.
 SERA 3210: Deals with right of way.
Is mainly for manned aviation, this whole section needs to be re-written and added with UAV parts
in general and specific.
 SERA 3215: Deals with lights to be displayed by aircraft.
This must address UAS specificities (e.g., size, shape) be described here.
 SERA 3225: Deals with Operation on and in the vicinity of an aerodrome.
ConOps’ parts regarding Vertiport should be included or have a specific point in SERA.
 SERA 3301: Deals with signals described in appendix 1.
SERA will need to be updated with UAS operation peculiarities, in particular for autonomous
operation.
 SERA 4001-4005-4010-4015-4020: Deals with flight plan.
SERA needs to describe U-plan in the same manner.
 Whole section 5: Visual meteorological conditions, Visual Flight Rules, Special VFR and
Instrument Flight Rules.
Page 38
SERA would be required to propose one set of rules for U-space (only UAS) and one set when
interacting with manned aircraft in shared airspace.
Helicopter’s speeds and weather minima for instance are not necessarily adapted for flying in
airspace where smaller aircraft such as UAS are flying too.
Also, helicopters have rules in relation operating heights and speeds and therefore it may be the
case that UAMs will need to comply more with Helicopter rules, but the larger UAS fixed wing aircraft
will need to adapt to some of the rules whereas they may not be able to comply with rules that apply
to manned flights.
 SERA 6001: Deals with airspace classification.
SERA should be updated with U-space volumes description.
 SERA 6005: Deals with communications.
U-space rules for communication and e-conspicuity needs to be described in a separate bullet. Ref.
mandatory services in U-space. Rules have to be implemented where use of MODE-C and –S
transponders for UAS (UAM) is clearly described.
 Section 7: Deals with air traffic services.
Needs to be updated with the:
 Objectives of U-space services, USSP, also need to be described here,
 The cooperation between ATS and UTS.
 Interaction between a USSP and the users of U-space.
All this to be implemented as described in the CORUS ConOps Ed.4.
 Section 8: Air traffic control service.
 Needs a part where ATC obligations handling UAV is clearly described. Also, what is
expected for UAV from the ATC.
 U-space service/objectives as described in Chapter three of the CORUS XUAM

ConOps Ed.4 shall be, part of SERA section 8. All relevant parts from EU Regulation
2021/664 most be visible accordingly here.
 Section 9: Flight information service.
Traffic (Flight-) information services provided by USSP in U-space as described in the CORUS XUAM
ConOps Ed.4 3.14 shall be, part of SERA section 9. All relevant parts from EU Regulation 2021/664
[6]most be visible accordingly here.
 Section 10: Alerting service.
Maybe requires having a UAS-U-space flavour.
 Section 11: Interference, emergency contingencies and interception.
This section shall also be enriched with UAS – U-space specificities.
Page 39
 Section 12: Services related to meteorology – aircraft observations and reports by voice
communication.
SERA will need to take into consideration the absence of pilot on-board the aircraft. Many local
weather information can be shared by aircraft equipped on purpose but probably not all items
referred in section 12, or also different.
 Appendix 1: Signals.
This appendix needs to include to information exchanges between machines.
 Appendix 3: Cruising levels.
It is likely that each urban airspace has its own traffic management rules by layers.
 Appendix 4: ATS Airspace classes – Services provided and flight requirements.
Corresponding table for U-space airspace classes as found in CORUS ConOps Ed.4 2.3.6. shall be
added in this annex. Might lead to a major updated of appendix 4
enhanced category
The ConOps tackles the necessity to have alternate landing site, which are not necessarily vertiport, in
case of emergency.
Despite this PTS[11] is dedicated to manned VTOL operations, shouldn’t this be addressed? This is
especially the case for VFR operations.

Nothing to add.

The ConOps section 3.2 presents the surveillance in U-space. All aircraft must either have a Network
Identification, Transponder or Electronic Conspicuity. Network Identification is mandatory for UAS
using U-space services. Manned aircraft can be either under ATC service or not. If they enter U-space
the controlled manned aircraft location is communicated from ATC services to U-space, otherwise the
Electronic Conspicuity is necessary.
In case of an IFR-RPAS entering U-space the RPAS panel should make clear which surveillance
technology is expected.

No relevant information found.
3.3.2.12 NPA 2022-06 on innovative air mobility with manned VTOL-capable

aircraft
Page 40
The ConOps[1] has no obvious effect on the content of this NPA.

Page 41
4 Conclusions and recommendations

4.1 conclusion
Reviews of current regulations either on UAS, UAS operations, UAS or UAM infrastructures or on U-
space and of the CORUS XUAM ConOps show that the concept of operation is ahead the regulation in
several domains, although the regulation grows rapidly providing more and more documentation
encompassing considerations for urban air mobility.
On the other hand, the ConOps makes the choice to not address some topics such as the
responsibilities of each stakeholder, including some of the most important, the remote pilot and the
USSP. Regulation tackles this point for instance.
What we can conclude from the review is the obvious need to update the existing regulations with
what has been developed the last three years in the domains of the UAS and U-space. This process is
the rationale consequence of this new world of UAS and U-space which is evolving fast and will keep
integrating technologies, concepts, and ideas in the coming years.
Hence, the ConOps may or should embed additional information on what is deemed useful to the good
understanding and acceptance of the concept of operations, existing regulations should be updated
with the past and current contributions of the Conops and regulations to come fill in the gaps, one on
them addressing rules of the air for UAS, between UAS and with manned aviation.
4.2 Recommendations
Section 3 lists all the discrepancies that have been found both in the ConOps and in the different
regulation documentations that have been reviewed.
Recommendations below gather what is considered as the most urgent and/or easy to deal with.
In the Conops:
 Update the definitions according to those proposed in the regulations, add definitions
considered as relevant for the ConOps and urban air mobility.
 Address the topics that could seem of interest for a concept of operations (e.g., cross border
operations, stakeholders responsibilities.
 Maybe better explain how manned aviation would fly in a U-space airspace.
 Try to detail rules of the air for UAS.
For the regulations:
 Embed CORUS Conops and CORUS X UAM Conops proposals or at list equivalent (e.g., U-space
volumes and core U-space services).
 Update current regulation documentation with the latest developments.
 Invest in the development of rules of the air for UAS and update accordingly SERA.
 Tackle social acceptance (noise and visual impacts, privacy) in any circumstances.
Page 42
5 References and Applicable Documents
5.1 Reference Documents

[1] CORUS X UAM ConOps D4.1 edition 3.10
[2] (EU) 2019/945 on unmanned aircraft systems and on third country operators of unmanned
aircraft systems
[3] (EU) 2020/1058 amending delegated regulation (EU) 2019/945 as regards the introduction of
two new unmanned aircraft systems classes
[4] (EU) 2019/947 on the rules and procedures for the operation of unmanned aircraft
[5] (EU) 2020/639 Amending Implementing Regulation (EU) 2019947 as regards standard
scenarios for operations executed in or beyond the visual line of sight
[6] COMMISSION IMPLEMENTING REGULATION (EU) 2021/664 of 22 April 2021 on a regulatory

framework for the U-space
[7] COMMISSION IMPLEMENTING REGULATION (EU) 2021/665 of 22 April 2021 amending

Implementing Regulation (EU) 2017/373 as regards requirements for providers of air traffic
management/air navigation services and other air traffic management network functions in
the U-space airspace designated in controlled airspace
[8] COMMISSION IMPLEMENTING REGULATION (EU) 2021/666 of 22 April 2021 amending

Regulation (EU) No 923/2012 as regards requirements for manned aviation operating in U-
space airspace
[9] Notice of Proposed Amendment 2021-14 Development of acceptable means of compliance

and guidance material to support the U-space regulation
[10]Easy Access Rules for Standardised European Rules of the Air (SERA) or (EU) 923/2012
[11]EASA “Prototype Technical Specifications for the Design of VFR Vertiports for Operation with
Manned VTOL-Capable Aircraft “certified in the enhanced category
[12]EUROCAE MOPS ED-269
[13]EUROCAE MOPS ED-270
[14]RPAS Panel documentation RPASP/16-WP/15(24/09/2020)
[15] RPAS Panel documentation RPAS/19-WP/5(17/02/2022)
Page 43
[18] SSDR : single seat microlight
[19]NPA2022-06 "Introduction of a regulatory framework for the operation of drones Enabling

innovative air mobility with manned VTOL-capable aircraft, the initial airworthiness of
unmanned aircraft systems subject to certification, and the continuing airworthiness of those
unmanned aircraft systems operated in the ‘specific’ category”
[20](EASA) public consultation on Guidelines on noise measurement of unmanned aircraft systems

lighter than 600kg operating in the specific category (low and medium risk) released on 13
October 2022
[21]ICAO Annex 2
[22](EASA) ED Decision 2022/002/R on AMC & GM to Regulation (EU) 2019/947 that amends AMC-
GM for (EU) 2019/947
[23]ICAO Annex 11 Air Traffic Services
[24] COMMISSION IMPLEMENTING REGULATION (EU) 2017/373 of 1 March 2017 laying down
common requirements for providers of air traffic management/air navigation services and
other air traffic management network functions and their oversight, repealing Regulation (EC)
No 482/2008, Implementing Regulations (EU) No 1034/2011, (EU) No 1035/2011 and (EU)
2016/1377 and amending Regulation (EU) No 677/2011
[25] Regulation (EC) No 551/2004 of the European Parliament and of the Council of 10 March 2004
on the organisation and use of the airspace in the single European sky (the airspace Regulation)
[26] COMMISSION REGULATION (EU) No 748/2012 of 3 August 2012 laying down implementing
rules for the airworthiness and environmental certification of aircraft and related products,
parts and appliances, as well as for the certification of design and production organisations
[27] REGULATION (EU) 2018/1139 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 4 July
2018 on common rules in the field of civil aviation and establishing a European Union Aviation
Safety Agency, and amending Regulations (EC) No 2111/2005, (EC) No 1008/2008, (EU) No
996/2010, (EU) No 376/2014 and Directives 2014/30/EU and 2014/53/EU of the European
Parliament and of the Council, and repealing Regulations (EC) No 552/2004 and (EC) No
216/2008 of the European Parliament and of the Council and Council Regulation (EEC) No
3922/91
Page 44
Page 45
U-SPACE CONOPS (EDITION4) ANNEX: ADVANCED U-SPACE DEFINITION
U-space ConOps
(edition4) Annex:
Advanced U-space
definition
Deliverable ID: D4.2 (Annex)
Grant: 101017682
Call: H2020-SESAR-2019-1
CONCEPT OF OPERATIONS FOR EUROPEAN U-SPACE
Topic:
SERVICES - EXTENSION FOR URBAN AIR MOBILITY
Edition Date: 23 December 2022
Edition: 1.00.00
11

Beneficiary Date
Douwe Lambers / DFS, Deputy WP 3 Lead 2022
Ralf Heidger / DFS, WP 3 Lead 2022
Yannick Seprey / DSNA, Task 3.1 Lead 2022
Javier García Moreno / CRIDA, Task 3.2 Lead 2022
David Martin-Marrero / EUROCONTROL, Task 3.3. Lead 2022
Cristina Barrado / UPC, Task 3.4 Lead 2022
Andrew Hately / EUROCONTROL, WP 4 lead 2022
Martin Robinson / AOPA 2022
Gonzalo Torres Ortín / CRIDA 2022
Luigi Brucculeri / D-FLIGHT 2022
Michael Borkowski / DLR 2022
Karolin Schweiger / DLR 2022
Robert Geister / DLR 2022
Marc-Antoine Laclautre / DSNA 2022
Marta Sanches Cidoncha / ENAIRE 2022
Daniel Bajiou Mroczkowska / ENAIRE 2022
Giovanni Riccardi / ENAV 2022
Aris Anagnostou / EUROCONTROL 2022
Peter Hullah / EUROCONTROL 2022
Elina Millere / EUROCONTROL 2022
Dirk Schaefer / EUROCONTROL 2022
Norberto VERA VELEZ / EUROCONTOL 2022
Alicia Cano / HEMAV 2022
Sergi Tres / HEMAV 2022
Xavi Baluguer / HEMAV 2022
Billy Josefsson / LFV 2022
Mats Nilsson / LFV 2022
Åsa Taraldsson / LFV 2022
Valentin Polishchuk / LIU 2022
Anthony Rushton / NATS 2022
Guillermo Ledo Lopez / NATS 2022
2
Colin Hampson / NATS 2022
Zakariya Laftit / Unifly 2022
Enric Pastor / UPC 2022
Sebastian Bomart / VOLOCOPTER 2022
Joern Jaeger / VOLOCOPTER 2022
Arife Aycan Multu / VOLOCOPTER 2022
Barbara Zygula / VOLOCOPTER 2022

Beneficiary Date

Beneficiary Date
project
Beneficiary Date

Beneficiary Date
Document History
Edition Date Status Beneficiary Justification
1.0.0 23 December 2022 PU DFS Final Draft
3
Copyright Statement © 2022 – CORUS XUAM Consortium. All rights reserved. Licensed to SESAR3
This report is part of a project that has received funding from the SESAR3 Joint Undertaking under
grant agreement No 101017682 under European Union’s Horizon 2020 research and innovation
programme.
Abstract
The Advanced U-space Definition document presents a comprehensive overview of the operational,
performance, and safety considerations for the successful integration of Urban Air Mobility (UAM) into
urban airspace. UAM operations, involving the transportation of people and goods by unmanned aerial
systems (UAS), present unique challenges due to the higher traffic densities and ground risks
associated with urban areas. The document describes UAM operations and Traffic Integration, focusing
on the specific needs of UAM.
This document aims to extend the U-space ConOps, produced by the CORUS project, with Urban Air
Mobility aspects, ultimately delivering an "Operational Services & Environment Definition" for U-space
in the UAM environment. It is divided into four main chapters: Definition of the Operational
Framework, Operational Performance of UAM, Safety and Contingency in UAM Operations, and Social
Acceptance of Urban Air Mobility.
The Definition of the Operational Framework covers regulatory matters, system performance
characterisation, stakeholders and use cases, ground environments, airspace characterisation in urban
environments, systems in support of UAM, operational procedures, CNS characteristics in urban
environments, and risk assessment classes.
The Operational Performance section focuses on environment descriptions, assumptions, scenarios,

use cases, and performance and operational requirements for UAM operations. The Safety and
Contingency chapter include sections on air risk impact assessment, continued safe flight and landing
in alternate vertiports, pre-flight de-confliction, and flight rules and airspace classification. It covers
strategies for safely redirecting and landing in alternative vertiports in the event of an emergency, as
well as how to plan and coordinate flights to minimize conflicts and ensure safe operation.
The social acceptability of UAM is also examined, with recommendations made based on a review of
past public surveys and a Societal Acceptance Study conducted during the trials. It makes
recommendations for addressing societal concerns related to safety, economics, and politics. Overall,
the Advanced U-space Definition document covers the key considerations and serves as a valuable
resource for stakeholders looking to effectively integrate Urban Air Mobility (UAM) into urban
airspace.
Keywords: Urban Air Mobility (UAM), Unmanned aerial systems (UAS), Traffic integration, Operational
Framework, Use cases, Performance requirements, Safety and contingency, Ground risks, Airspace
design, Rules of the air, Interoperability, ATM systems, Continued safe flight and Landing, Alternate
vertiports, Flight planning, De-confliction, Airspace assessment, Social acceptability, Public surveys,
Societal acceptance study, Air risk impact assessment.
4
Table of Contents
Abstract ................................................................................................................................... 4
1 Introduction ............................................................................................................. 14
1.1 Purpose of the document............................................................................................. 14
1.2 Intended readership .................................................................................................... 15
1.3 Structure of the document ........................................................................................... 15
1.4 Scope .......................................................................................................................... 15
1.5 U-space evolution ........................................................................................................ 19
1.6 U-space services definitions ......................................................................................... 24
2 Executive Summary .................................................................................................. 29
3 Definition of the Operational Framework ................................................................. 30
3.1 Introduction ................................................................................................................ 30
3.2 Regulatory framework ................................................................................................. 30
3.3 System Performance .................................................................................................... 47
3.4 Stakeholders and use cases .......................................................................................... 67
3.5 Ground environment ................................................................................................... 88
3.6 Airspace characterization in urban environment.......................................................... 103
3.7 Systems in support of UAM ......................................................................................... 111
3.8 Operational procedures .............................................................................................. 141
3.9 CNS characteristics in urban environment ................................................................... 145
3.10 Risk assessment classes .............................................................................................. 156
4 Operational Performance of UAM ...........................................................................159
4.1 Introduction ............................................................................................................... 159
4.2 Environment Description ............................................................................................159
4.3 Assumptions...............................................................................................................195
4.4 Scenarios .................................................................................................................... 196
4.5 Use Cases ...................................................................................................................200
4.6 Performance and Operational Requirements ............................................................... 268
5 Safety and Contingency in UAM Operations ............................................................289
5.1 Introduction ............................................................................................................... 289
5.2 Air Risk Impact Assessment.........................................................................................289
5.3 Continued Safe Flight and Landing ..............................................................................303
5.4 Pre-flight de-confliction ..............................................................................................319
5
5.5 Flight rules and Airspace Classification ........................................................................ 328
6 Social Acceptance of Urban Air Mobility ..................................................................339
6.1 Public surveys............................................................................................................. 339
6.2 Societal concerns mitigations proposed to the VLDs .................................................... 349
6.3 Societal Acceptance Questionnaires in CORUS-XUAM .................................................. 360
6.4 Noise study ................................................................................................................ 367
7 References, Glossary, Acronyms .............................................................................. 374
7.1 Reference Documents.................................................................................................374
7.2 Glossary of terms........................................................................................................ 383
7.3 List of Acronyms and abbreviations ............................................................................. 395
Appendix A Use Cases for U-Space services ............................................................... 406
Appendix B T3.2 Integrated Requirements ................................................................415
List of Tables
Table 1 WP3 & WP4 task purposes ....................................................................................................... 14
Table 2 U-space characteristics today ................................................................................................... 20
Table 3 U-space characteristics 2023-2030........................................................................................... 21
Table 4 U-space characteristics 2030 - 2040 ......................................................................................... 22
Table 5 U-space characteristics 2035 - 2045 ......................................................................................... 23
Table 6 U-space characteristics 2040+ .................................................................................................. 24
Table 7 Administrative U-space services ............................................................................................... 24
Table 8 Mandatory U-space services .................................................................................................... 26
Table 9 Optional U-space services ........................................................................................................ 27
Table 10 Other U-space services identified in several U-space projects .............................................. 28
Table 11 Open category of operations restrictions and requirements – from

https://www.easa.europa.eu/faq/116452 ........................................................................................... 37
Table 12: Meteorological conditions minima and distance from cloud for VFR flight – ICAO Annex 2 and
SERA 5001.............................................................................................................................................. 46
Table 13: Definitions of KPAs applicable to ATM and U-space ............................................................. 55
Table 14: Stakeholders Expectations in terms of KPAs for Service Providers ....................................... 63
Table 15: Stakeholders Expectations in terms of KPAs for Service Providers ....................................... 63
Table 16: Stakeholders Expectations in terms of KPAs for Airport and UAS Operators ....................... 66
6
Table 17 Different U-space Service Providers ....................................................................................... 70
Table 18 U-space Service Providers ...................................................................................................... 71
Table 19 ANSP roles............................................................................................................................... 72
Table 20 Types of aircraft involved in UAM operations ........................................................................ 80
Table 21 List of operation types in urban environment ........................................................................ 84
Table 22 airspace structure summary ................................................................................................. 106
Table 23 Tactical Separation methods in uncontrolled airspace ........................................................ 110
Table 24 Separation methods in controlled airspace.......................................................................... 111
Table 25 U-space related systems ....................................................................................................... 115
Table 26 Neighbour systems for UAM ................................................................................................ 117
Table 27 Registration database functions in more detail ................................................................... 118
Table 28 Registration database communicating partner systems and data exchange....................... 119
Table 29 ATM Multi-Sensor-Data-Fusion Tracker functions ............................................................... 120
Table 30 ATM Multi-Sensor-Data-Fusion Tracker partner systems and data exchanges ................... 121
Table 31 ATM situation display functions ........................................................................................... 122
Table 32 ATM situation display partner systems and data exchanges ............................................... 123
Table 33 ATM FDPS and flight plan display functions ......................................................................... 124
Table 34 ATM FDPS and flight plan display communicating systems and data exchanges ................ 125
Table 35 ATM Safety net server functions .......................................................................................... 126
Table 36 ATM Safety net server communicating partner systems and data exchange ...................... 126
Table 37 CIS traffic information data provision system functions ...................................................... 127
Table 38 CIS traffic information data provision system communicating partner systems and data
exchanges ............................................................................................................................................ 128
Table 39 CIS geodata information provision system functions........................................................... 129
Table 40 CIS geodata information provision system communicating partner systems and data
exchanges ............................................................................................................................................ 129
Table 41 UTM functions ...................................................................................................................... 131
Table 42: Functions today’s status and needed extensions in the future .......................................... 132
Table 43 UTM client systems for authorities communicating partner systems and data exchanges 133
7
Table 44 functions of UTM client system for cities ............................................................................. 133
Table 45 communications of UTM client system for cities ................................................................. 134
Table 46 UTM client system for UAS operators .................................................................................. 135
Table 47 functions of UTM client system for pilots in the field .......................................................... 135
Table 48 functions of UTM client system for VFR pilots ..................................................................... 136
Table 49 functions of operator fleet management system ................................................................ 136
Table 50 Communicating partner systems and data exchanges of operator fleet management system
............................................................................................................................................................. 137
Table 51 functions of UAM/UAS ground control system or RPS ......................................................... 137
Table 52 functions of UAM/UAS onboard flight management system ............................................... 138
Table 53 communications of UAM/UAS onboard flight management system ................................... 138
Table 54 functions of vertiport management system ......................................................................... 139
Table 55 communications of vertiport management system ............................................................. 139
Table 56 functions of U-Space surveillance means ............................................................................. 141
Table 57 Goods classification by risk consequences ........................................................................... 158
Table 58: ICAO Airspace Classification ................................................................................................ 175
Table 59: Type of vehicles ................................................................................................................... 179
Table 60: Common transportation modes characteristics compared with air taxi [105]. .................. 180
Table 61 Passenger ticketing and boarding process. .......................................................................... 204
Table 62 Validation of U-plan generation use case steps - initial version .......................................... 206
Table 63 U-plan filing use case steps - initial version .......................................................................... 207
Table 64 U-plan submission Use Case. ................................................................................................ 209
Table 65 U-plan Submission & Authorisation ..................................................................................... 212
Table 66 U-plan conflict detection Use Case....................................................................................... 216
Table 67 Deconfliction of U-planning: Pathfinding Computation. ...................................................... 220
Table 68 Table presenting the steps for the Strategic Dynamic Capacity Balancing measures.......... 223
Table 69 U-plan Update/ Modification Use Case. ............................................................................... 224
Table 70 U-plan Update/ Modification for Conflict resolution and DCB processes............................ 226
Table 71 Table presenting the steps for the Strategic Dynamic Capacity Balancing measures.......... 230
8
Table 72 Departure and Taxi Out UC................................................................................................... 232
Table 73 En-route UC .......................................................................................................................... 236
Table 74: Air taxi Flight: Landing on an uncontrolled vertiport .......................................................... 240
Table 75 Submit position reports: login to U-space systems based approach .................................. 244
Table 76 Receive position reports: nominal sub-use case .................................................................. 246
Table 77 Receive position reports sub- use case, non-nominal form - initial version ........................ 247
Table 78 Tactical conflict resolution sub-use case .............................................................................. 249
Table 79a Tactical conflict resolution sub- use case, non-nominal form - inital version .................... 250
Table 80 Emergency Management sub- use case - inital version ....................................................... 253
Table 81 Monitoring service sub- use case - initial version ................................................................ 255
Table 82 Traffic Information service sub- use case - initial version .................................................... 257
Table 83 Ground Holding Process UC.................................................................................................. 259
Table 84: Alternate Vertiport Process UC ........................................................................................... 261
Table 85 Holding/Hovering Process .................................................................................................... 263
Table 86 Post flight UC ........................................................................................................................ 266
Table 87 Requirements ....................................................................................................................... 288
Table 88: Pros and Cons of Free and Predefined Routes .................................................................... 291
Table 89. Simulation input parameters ............................................................................................... 325
Table 90. Results for FFFS method ...................................................................................................... 327
Table 91. Results for RTTA method ..................................................................................................... 327
Table 92: Volumes ............................................................................................................................... 333
Table 93. Please check the option(s) that apply/applies to you. ........................................................ 347
Table 94- Please select which of the three main concerns is most important for you. ...................... 349
Table 95: CORUS-XUAM Workshop responses about the list of mitigations ...................................... 350
Table 96. Categorisation of the mitigations ........................................................................................ 351
Table 97. Concerns about Urban Air Mobility ..................................................................................... 353
Table 98. Top-10 mitigations ............................................................................................................... 355
Table 99. List of mitigation actions on the flight plan design ............................................................. 357
Table 100. List of dissemination actions ............................................................................................. 358
9
Table 101. List of mitigation actions applicable to drones ................................................................. 358
Table 102. List of other mitigation actions.......................................................................................... 359
Table 103. List of questions of the social acceptance study ............................................................... 367
Table 104 (EU) 2019/945 current noise limits .................................................................................... 368
Table 105. Decibels of drone by distance ........................................................................................... 370
Table 106. Decibels (dBA) in context................................................................................................... 372
Table 107: Glossary of terms ............................................................................................................... 395
Table 108: List of acronyms and abbreviations ................................................................................... 405
List of Figures
Figure 1 Categories of operations ......................................................................................................... 35
Figure 2 Subcategory A1 – https://www.easa.europa.eu/faq/116452europa.eu/faq/116452 ........... 36
Figure 3 Subcategory A2 – from https://www.easa.europa.eu/faq/116452 ....................................... 36
Figure 4 Subcategory A3 – from https://www.easa.europa.eu/faq/116452 ....................................... 36
Figure 5 Specific category of operations procedure ............................................................................. 39
Figure 6 UAS classes requirements and characteristics ........................................................................ 42
Figure 7 City of Grenade on VFR map ................................................................................................... 42
Figure 8 Flight phases representation [38] ........................................................................................... 86
Figure 9: Overview of the UAS Operation lifecycle phases and associated activities ........................... 87
Figure 10 Neither AGL nor MSL alone will work everywhere [48] ........................................................ 89
Figure 11 Height and altitude references (figures 2 of CORUS ConOps [4]) ......................................... 91
Figure 12 3D view of the VTOL take-off and landing volume based on reference volume [83] ........... 94
Figure 13 (Fig.2 in [62]: CTL value computed from the findings of six surveys of communities exposed
to aircraft noise. Note that CTL values for the different communities shown vary over a range of 30 dB
............................................................................................................................................................... 95
Figure 14 Drone Station by DHL in collaboration with E-Hang [68] ...................................................... 97
Figure 15 Drone Delivery hub for hospitals [69] ................................................................................... 98
Figure 16 Drone Delivery Station for Parcels [70] ................................................................................. 98
Figure 17 Roof Terrace for drone deliveries [71] .................................................................................. 99
Figure 18 Roof Delivery [72] .................................................................................................................. 99
10
Figure 19Urban Drone port [73].......................................................................................................... 100
Figure 20 multi-level fulfilment centre [78] ........................................................................................ 100
Figure 21 Vertiport classification from operations perspective [76] .................................................. 101
Figure 22 VoloPort a top urban building with VoloCity and VoloConnect © Volocopter GmbH [74] 102
Figure 23 VoloPort Singapore outside © Volocopter GmbH, Raphael Oliver [75] ............................. 103
Figure 24 UAM systems landscape...................................................................................................... 116
Figure 25 Current Mobile Network Coverage ..................................................................................... 148
Figure 26 Roadmap to implement Mobile Network Communication Architecture............................ 149
Figure 27 CNS Required System Performance Proposal ..................................................................... 156
Figure 28 CNS Required System Performance Achievements ............................................................ 156
Figure 29: CORUS-XUAM Operational Environments ......................................................................... 163
Figure 30: Air taxiing and Ground movement vertiport configuration ............................................... 166
Figure 31: Vertiport Classification from Operations Perspective........................................................ 166
Figure 32: Hierarchical requirements for U-space airspace to mitigate hazards and airspace
congestions.......................................................................................................................................... 175
Figure 33: Air taxi service point to point segments............................................................................. 180
Figure 34: DACUS D5.2. Rules for separation management schema. ................................................. 181
Figure 35: 4D trajectories (blue) abiding a set of moving obstacles (red) .......................................... 182
Figure 36: RNP Accuracy and Containments limits, BUBBLES Project ................................................ 183
Figure 37: ATM Seminar [96], Conformance rate as a function of the volume horizontal buffer across a
variety of volume time buffers. ........................................................................................................... 183
Figure 38: BUBBLES D4.1. [95] Collision probability versus separation distance................................ 184
Figure 39: ATM Seminar 2021, The absolute unmitigated risk as a function of nominal separation. 185
Figure 40: Probability of safety breach as the function of r and traffic intensity (left 3D graph, right:
view from the top)............................................................................................................................... 185
Figure 41: CORUS-XUAM Process and Flight phases timeline scheme. .............................................. 186
Figure 42: Operational Framework flight phase representation from EmbraerX and Airservices Australia
ConOps for UAM [106]. ....................................................................................................................... 189
Figure 43: Timeline schema of the lifecycle of a U-plan within the process and flight phases related.
............................................................................................................................................................. 190
Figure 44: Visualisation of RTTA in U-plan and process phases timeline relation. ............................. 193
11
Figure 45: Diagram sketch of Scenario Scn-A-ST-Env1........................................................................ 198
Figure 46: Diagram sketch of Scenario Scn-A-ST-Env2........................................................................ 199
Figure 47: Summary of Uses Cases Flow through different flight phases........................................... 201
Figure 48: U-plan action/role diagram resume ................................................................................... 213
Figure 49: Departure and Taxi Out Use Case ...................................................................................... 233
Figure 50: Arrival and Taxi-In Nominal Use Case flow diagram. ......................................................... 241
Figure 51: Example of UAM trajectory ................................................................................................ 290
Figure 52: Finding the middle ground between Free Routes and Predefined .................................... 291
Figure 53: corridor cross-section from Demonstration Exercise #2.2, showing minimum dimensions
............................................................................................................................................................. 298
Figure 54: Safety Objectives from EASA SC-VTOL ............................................................................... 305
Figure 55: Classification of failure conditions ..................................................................................... 308
Figure 56: Interactive Voronoi diagrams cells determination............................................................. 311
Figure 57: Example of a Voronoi Diagram with 12 sites ..................................................................... 312
Figure 58: Example of 75 flights and 12 Vertiports in a given area..................................................... 313
Figure 59: Example of closure of a vertiport ....................................................................................... 315
Figure 60. Closed loop for pre-flight de-confliction ............................................................................ 321
Figure 61. 2D grid simulated by the tool ............................................................................................. 322
Figure 62. Distribution of activation time ........................................................................................... 325
Figure 63. Distribution of filing time ................................................................................................... 326
Figure 64. Distribution of time between filing and activation ............................................................ 326
Figure 65. Simulation of 2D flights with different pre-flight de-confliction strategies: no de-confliction
(left), FFFS (centre), RTTA (right) ......................................................................................................... 327
Figure 66 - Key results from the EASA survey. Source [EASA2019] .................................................... 341
Figure 67 - Summary of the surveys per year, aim and proposed vehicles ........................................ 344
Figure 68 - Acceptance levels of drones and/or UAM per survey (in %) ............................................ 345
Figure 69 - Evolution of acceptance over years .................................................................................. 346
Figure 70 - Words clouds highlighting the public concerns on the different surveys ......................... 348
Figure 71 - Evolution of main concerns over the years ....................................................................... 348
12
Figure 72 - Examples of mitigations by category ................................................................................ 351
Figure 73 - Example of mitigations by ease of implementation ......................................................... 352
Figure 74- Category and Easy of Implementation classifications of the list of mitigations ................ 353
Figure 75 - Top-10 mitigations scores and classification..................................................................... 356
Figure 76 U-space ConOps 3.10 stakeholders ..................................................................................... 360
Figure 77 - Sound pressure level per frequency of ambient noise and drone noise at different AGL [133]
............................................................................................................................................................. 371
13
1 Introduction
The CORUS-XUAM project aims to expand the earlier ConOps for U-space [1], produced in the CORUS
project, with Urban Air Mobility aspects. The project consists broadly of two parts:
- development of an extension to the ConOps (WP 3 / 4), and
- several very large demonstrators (VLDs) that are addressed in WP 5 – 11.
CORUS-XUAM Work Package 3 and 4 collectively aim to deliver what is in effect an “Operational
Services & Environment Description” for U-space although no one document has this title.
Approximately the work breaks down as follows
Task Aim
What is the scope of the work of WP3 & WP4?
T3.1 What U-space operations need to be supported, in what environment, in what level of detail, with
what considerations?
What, in detail, do these U-space operations mentioned by T3.1 consist of?
T3.2 When the project has something to say about performance, why and what performance is
expected?
What is the approach to safety?
T3.3 How do safety considerations impact the U-space operations considered in T3.2
What non-nominal situations should be considered?
What is the approach to social acceptance?
T3.4 How does social acceptance impact the U-space operations considered in T3.2?
What are the main concerns of social acceptance and how should they be handled
Synthesising the work in WP3 and T4.2, T4.3, T4.4, what is the overall concept of operations for U-
T4.1
space.
What are the business processes of U-space that support the operations and environment
T4.2 described by WP3.
How in detail do the U-space services form part of these business processes
T4.3 Validation of the work of T4.2 by its formalisation in the EATMA architecture
What of the ConOps is outside current regulation, what changes to law or regulation would be
T4.4
needed to make it work.
Table 1 WP3 & WP4 task purposes
Hence this document provides a framework to allow WP3 to discuss the various aspects of Urban Air
Mobility operations and defines scope of what will be described. A framework here means the
identification of the goals of UAM operations in a working system, its typical use cases, and eventually
also contingency and potential emergency cases, the identification of the stakeholders and actors, the
identification of the airspaces, the identification of the involved aircraft, the identification of potential
and suitable related tools and systems, a description of the required infrastructure, and last but not
least a look at the legislative background, both with a perspective on the status quo, and with a
14
perspective on the desired target situation. This overall framework then drives all the rest of WP3 and
WP4.

The intended readers of this document are in no particular order
CORUS-XUAM WP2 who will disseminate and prepare the exploitation of all of the work done in
the project
Researchers working in U-space in contemporary and subsequent projects
While the main deliverable of CORUS-XUAM will be the ConOps whose production this document
exists to enable, this work will potentially be of continuing interest to:
Operators and potential operators of air vehicles that will make use of U-space
Potential or current suppliers of air vehicles that will make use of U-space, or suppliers of systems
fitted to such vehicles
Potential and current U-space service providers as well as suppliers of software to such providers
Potential and current air traffic service providers as well as suppliers of software to such providers
whose services will have to interact with U-space
Regulators and standardisation bodies concerned by U-space or UTM
Airport operators and potential vertiport operators that will interact with U-space as a U-space
servicer user and/or provider"
City authorities who need to provide the basis for a functioning U-space system and are in need of
detailed understanding of UAM/U-space

This document aggregates the output of the four subtasks of Work Package 3. Each work package
produced one chapter in this document.
Chapter 1, this chapter, is a general introduction to the document.
Chapter 2 is the result of Task 3.1: Definition of the Operational Framework for Urban Air Mobility in
U-space
Chapter 3 is the result of Task 3.2: Analysis of Operational & Performance Requirements for Urban Air
Mobility in U-space
Chapter 4 is the result of Task 3.3: Analysis of Safety & Contingency Requirement for Urban Air Mobility
in U-space
Chapter 5 is the result of Task 3.4: Social Impact analysis.
1.4 Scope
This document does not define UAM operations, processes, or responsibilities in detail.
15
It describes the known starting points, existing constraints, system boundary and assumptions on
UAM. In addition, it provides a description of the objectives of UAM, the stakeholders and actors within
UAM, as well as their goals.
It lists the areas that need to be addressed by the ConOps and puts emphasis on the areas that are
considered important, especially in relation to the CORUS XUAM VLDs. It provides structure and focus
for the ConOps.
1.4.1 Societal context

Various EU declarations [Riga 2015, Warsaw 2016, Helsinki 2017, Amsterdam 2018] have underlined
in the last 5 years the political will of the European Commission to enable the commercial use of UAS
to the advantage of European air traffic evolution1, given that the societal acceptance is considered
and kept in focus. As a recent study (EASA: study on the societal acceptance of Urban air mobility in
Europe, May 19, 2021) [2] has shown the societal interest seems to be focused on a safe usage of UAS
and UAM for all kinds of operations, with a priority on use cases in the public interest, in medical
supply, transport of injured persons and medical emergency personnel, in disaster management with
drones, and long-distance forwarding of heavy cargo.
Throughout Europe, a positive initial attitude to UAM can be found. The top 3 benefits that are
expected, are a faster, cleaner, and extended connectivity. In terms of safety, it can be observed that
existing aviation safety levels are understood as the benchmark for that kind of new operations. The 3
most important concerns found by the study are safety, environment (e.g., noise), and security. UAM
operations may gain more acceptance if they are in line with environmental sustainability, e.g.,
contribute to carbon-reduced traffic, make use of clean and energy-efficient vehicles, and support
environmental and wildlife protection. The noise emission of UAM is expected to be acceptable only if
it is at the level of familiar city sounds, which indeed is a challenge. Security and cybersecurity of UAM
vehicles are trusted only by about the half of the respondents of the study, so obviously from the
societal perspective there is a lot of work to do yet to ensure security and cybersecurity and thus
increase the trust of citizens.
Ground infrastructure must be well integrated to fulfil the expectations of European societies. A
smooth integration into ground infrastructure has many specific aspects: efficient use of space and
resources shall be made, a smooth integration with other transport means must be achieved, cultural
heritage shall be preserved, noise levels of vertiports shall be kept at acceptable levels, and
environmental impact must be minimized.
European citizens observe the complex evolution of the European and national legislative frameworks.
Its partially contradictory and partially incomplete evolution is critically considered and evaluated.
Regulatory authorities must work together at all levels to build a comprehensive and clear regulatory
framework that allows operations for the public interest and commercial usage of UAM.
The conclusions of the study therefore mention:
Safety should be addressed primarily, with a safety level equivalent to that of current aviation
operations
1
https://ec.europa.eu/defence-industry-space/eu-aeronautics-industry/unmanned-aircraft_en
16
Environmental impacts should be mitigated, including impact on animals and environmental
footprint from production and operation of UAM vehicles
Emission of CO2 or other greenhouse gasses should be avoided, and energy consumption should
be kept low
Noise should be limited to a level equivalent to that of current familiar noises in a city
Security risks should be prevented, mostly for drones in a first stage
European, national and local authorities should work together
Local authorities need detailed information and guidance, as well as involvement in the decision-
making
Use cases with highest benefit for general public to be introduced first (transport of medical goods
with manned eVTOLs (with a pilot on-board)), use cases by cargo like last mile delivery could
follow
Aviation safety needs to be taken care by competent authorities through appropriate regulations
and design assessment of vehicles, systems and infrastructure. The UAM traffic should be
safely integrated in the airspace with conventional aircraft.
Public acceptance should be secured by different levers, e.g., by:
ensuring UAM is affordable to all and used in the public interest
well integrated in the local transportation network/system
Supported by timely, sufficient and transparent information to citizens and local stakeholder
groups
1.4.2 Political context

The European Commission (EC) is supporting the development of Urban Air Mobility and U-Space in
general. The political support for UAM should be seen in the context of improving mobility in cities,
as well as in support of European climate objectives. The EC has identified a number of political
objectives that have a relation to the development of UAM:
to enhance mobility while at the same time reducing congestion, accidents and pollution [85][86]
[85]
achieve shorter journey times, while meeting the goal of decarbonising cities [83][84]
to advance transport services that are safe, quiet, convenient and even more efficient and
ecologically sustainable than what we have in our present ground-based options [83][86]
enable safe & secure transport in general and specifically safe and secure integration of UAS and
other autonomous aircraft into our airspace, also respecting privacy.
create opportunities for new services and business models, particularly in cities [84]
improve the cost-efficiency of ATM [84]
1.4.3 Economic context

While technological progress towards UAM operations/services are starting to receive quite a high
attention in the R&D, regulatory and standardisation areas, relevant business cases/models for the
deployment of a sustainable ecosystem that enables on-demand, highly automated, passenger or
cargo-carrying air transport services is apparently getting less attention. On the contrary, it should be
recognised that, especially in early market stages with high risks of investment and in respect to an
often-envisioned implementation of transport services in the proximity of urban settlements, it is
important that the proposed services and technologies offer the opportunity to provide measurable
benefits and add value to society.
17
The European Commission [82] predicts that by 2035 the European overall UAS sector will have an
economic impact exceeding €10 billion per year, mainly in services and by 2050 employ over 100 000
people.
As the use of UAM spreads, the need to balance the advantages and challenges they bring will also
increase. For instance, unmanned aircraft can add value when used in gathering and interpreting data
in different sectors of the economy. But UAS and UAM can also pose liabilities in terms of data
protection, privacy, noise and CO2 emissions.
In this document relevant perspectives to comprehend the current UAM business environment will be
briefly addressed focusing on some possible operator models and customer segments, making
reference to some concrete business model approaches for UAM.
Scrutinising for example UAM Airport Shuttle Services we should carefully consider that even concepts
with sufficient demand might still not be adequate for a robust business case due to potentially
incomplete and/or insufficient analysis made on the overall operational environment.
Also, an often-unconsidered business model for a Company Shuttle Service could be analysed,
addressing the problem of scaling up UAM services with a dynamically expandable Business-to-
Business (B2B) concept.
Last but not least, UAM should also be analysed as an enabler for on-demand cargo-carrying air
transport services that is introducing a business model that should be inclusive and integrated with
other type of transport services.
These rather different types of implementation concepts could help to develop new financially
sustainable business models around UAM. The realisation of commercial UAM services makes also
necessary to properly consider economically viable application scenarios which, at the same time,
address actual and forecasted air-transport demand along with their sustainability and value-led
development.
Current key drivers for the civil market are commercial UAS applications in sensor technology and
communication, however, the market size for VTOL vehicles carrying passengers and related services
is considered to exceed its value in the long term [6]. In future, the biggest share of profits is considered
by brokering Mobility as a Service (MaaS) solutions [7].
Of course, an economically crucial point is seen at the technology’s maturation from the level of
demonstration into a mass market, allowing for economies of scale and for significantly lower
production cost. Mass air transit is expected to become affordable for larger parts of society in the
long term only owing to further computation advancements, leading to autonomous operations.
Further hesitations may evolve if “the market is not mature enough to identify a clear demand within
the civil sector” [8]. More in general it could be assumed that the economic success of UAM is
dependent on “the ability of varied stakeholders to reconsider how this emerging technology platform
can be best harnessed to serve the broad interests of society” [9] urging for a value-led development
of UAM services.
A consolidation of how commercial UAM services will evolve has not yet begun. Consultancies, like
Roland Berger see airport shuttle, inner-city air taxi and inter-city connections as its most promising
use cases. Looking at the different studies on the modal share of UAM in overall traffic, so far none
seems to exceed a maximum share of 4%. Others researches name daily or weekly commute scenarios
and discuss non-commute point-to-point as well as non-transportation missions (e.g., sightseeing)
further reflecting on possible operational models such as private air transport, personal scheduled
18
transportation, personal unscheduled transportation (on-demand mobility) and commercial scheduled
transportation.
In any case, it should be recognised that, at this stage, integrating UAM into the public transport system
poses both advantages and disadvantages. UAM services operated by a public transport provider
promise to be at costs that make the mobility offer accessible for the broad public. This in return could
significantly increase public acceptance as UAM will not be perceived as a transport service only for
high income households.
Additionally, an efficient integration with public transport can decrease negative environmental
externalities and support sustainable mobility planning.
Vertiports could bring an economic impulse to neighbourhoods and offer new business models. Like
at airports, shops, restaurants etc. can be co-located with the vertiport and generate jobs, cashflow
and can indeed "uplift" city districts/ areas.
The application scenarios for UAM have to be studied carefully to make sure that UAM is the most
beneficial mode for the specific use-case. In general, UAM operation through the public transport
provider could be a promising approach especially in the beginning when the related risks could be too
high to be eligible for public spending and subvention.
During later stages of development this business model could especially be promising in areas with
geographical characteristics that make ground-based transport less attractive.
In any case, we should be aware that this is a complex exercise and that not all influencing factors
could be easily considered in the assessment of the respective business models and that several
business model approaches could be not properly considered. Business model development for UAM
should be considered a sort of iterative process, aiming to increasingly replace hypotheses with
empirical facts gathered over time.
In this context, it is clear that so far, the discussion on quantitative economically viable analysis and
socially meaningful UAM business models is far from a proper level of maturity. Only a critical analysis
of UAM business models can eventually lead to a growing acceptance of the economic use of UAM in
public airspace and to further investments necessary for its implementation.
1.5 U-space evolution

This section describes how U-space may evolve from early deployments to an environment with fully
operational U-space service that caters to all airspace users.
1.5.1 Assumptions:
 All services won’t be available at the same time, and the most complicated will arrive last
(e.g., tactical conflict resolution).
 Technological improvements and evolutions will allow UAS to fly more and more
autonomously.
 U-space services will serve as much unmanned as manned aircraft.
 Required equipment costs will decrease with the time so that the cost for a manned aircraft
shall be increasingly acceptable.
19
 As time progresses the proportion of operations that are unmanned grow to exceed manned
operations.
 U-space airspace will become more common with the different volume types eventually
being recognized as ICAO airspace classes.
 UAM infrastructure will be built incrementally to support operational needs.
 Airspace design will change to accommodate all operations.
Airbus UTM Blueprint [24] proposes a timeframe of the automation level.
CORUS X UAM would like to propose a vision with a kind of calendar for U-space implementation.
The topics that need to be considered are the following:
- Availability of the U-space services.

- Availability of the required technologies (CNS) and ground infrastructures for drone
operations.
- Availability of the “drones effective enough” to perform specific operations (e.g., carry heavy
payload, long haul trip).
- Evolution of the airspace design and structure.
- Interactions with manned aviation in controlled and uncontrolled airspace.
- Rules of the air.
What are the different steps considered?
1.5.2 Pre U-space era:

States are setting up registries and defining geographic areas [17] but drones fly without any U-space
services. Manual coordination with and authorizations from the involved authorities are usually
required. The current procedures make VLOS flights possible with some effort. BVLOS flights are
limited, time consuming and expensive to set up.
Availability of the U-space services Mainly:

 UAM/UAS operation plan preparation
 Strategic conflict detection and resolution
 Procedural interface with ATC
 e-identification
 Drone Aeronautical information (current AIP)
Evolution of the airspace design and None
structure
Rules of the air As main operations are VLOS, see and avoid.
For BVLOS, segregation is in place.
Table 2 U-space characteristics today
1.5.3 Initial U-space implementation (2023-2030):

A limited number of services are available. They provide a digital assistance to the authorities in charge
of authorizing the operations, and a digital assistance to the operators to plan and declare their
operations.
20
When required, airspace structures are defined, temporarily or permanently, to allow drone
operations (e.g., corridors for point-to-point goods or passenger carriage).
In controlled airspace, these airspace structures are temporarily activated on request, by the USP
to the ATC.
In uncontrolled airspace, permanent structures boundaries are published in the AIP to manned
aviation.
Temporarily structures boundaries and activation slots are also published in the AIP to manned
aviation.
U-space airspaces are progressively defined.
 Drone operation plan preparation
 Drone aeronautical information including AIP
and information specifically dedicated to drone
operators
 Operation plan processing
 Geo-fence provision
 If needed, first “Vertiport Service
Evolution of the airspace design and No U-space airspaces still defined, but specific structures for
structure. drone operations are defined in current airspace classes.
Rules of the air As main operations are VLOS, see and avoid.
For BVLOS, segregation is in place. Flow of drone operations
does not yet require dedicated rules of the air.
Table 3 U-space characteristics 2023-2030
1.5.4 Intermediate U-space (2030-2050):

U-space airspace volumes have been defined, whether it is in controlled or uncontrolled airspace.
In uncontrolled airspace, as most drone operations are performed in the VLL, U-space airspace is
defined from ground to 500 feet AGL. The volume is “X” or “Y”, depending on the required level of
services.
For specific drone operations which require to fly higher, such as inter-cities passengers or cargo
transportation, corridors are in place and published in the AIP.
Remote pilot for VLOS operations is responsible for collisions avoidance with any other aircraft.
Remote pilot for BVLOS operations is responsible for collisions avoidance with any other aircraft thank
to adapted mitigations (e.g., DAA).
In controlled airspace, a “red” zone is defined to protect manned operations around an airport. This
area is exclusively under the responsibility of the ATC and all drone operations in that area are
21
controlled by ATC. These operations can be declared to a USP and coordinated through the
collaborative interface. The remote pilot is directly in contact with an air traffic controller.
This zone can be extended beyond the “airport influence” in the controlled airspace as much as
manned operations remain the majority. A system such as the US LAANC can be implemented for
unmanned operations below a certain height. The responsibility of the services provision in these
volumes (Za) are delegated to a USSP. ATC remains informed of all operations.
The USSP can authorize drone operations by just informing ATC as long as they remain below a certain
height.
The other part of the controlled airspace is Za. The airspace remains class A, B, C or D by default, and
U-space volume Za is activated on demand by a USP. Segregation of activities is in place.
Za goes from the ground to 1000 feet AGL.
In the “ATM classes”, rules of the air are those described in SERA [13].
In the U-space volume, UFR are to be applied.

 drone operation plan preparation
 Drone aeronautical information including AIP and
information specifically dedicated to drone
operators
 ATC collaborative interface
 Monitoring
 Emergency management
 Traffic information
 Tracking
Evolution of the airspace design and U-space airspaces are defined

structure.
Rules of the air For VLOS, rule is “see and avoid”.
For BVLOS, segregation is still in place. Flow of drone
operations does not yet require dedicated rules of the air.
Table 4 U-space characteristics 2030 - 2040
1.5.5 U-space advanced (2050+):

Unmanned operations are now the majority, but manned operations are still numerous for societal
considerations, and for leisure.
22
For that reason, U-space volumes have been increased but the majority of the airspace remains
“manned available”.
In controlled airspace, the structures of the airspace around an airport remain the same. The “red”
zone is still there.
But the airspace by default is now the U-space volume (Za). Any manned aircraft wishing to fly in that
airspace shall be capable to use U-space services and UFR will be applied.
If not, required airspace reservation and the adapted structure must be requested to the ATC through
the USSP. In the segregated volume, SERA rules of the air are applicable.
Za is now up to 2000 feet or more. Manned leisure operations are possible. If the manned aircraft is
UFR capable, it can proceed. If not and if the unmanned traffic allows it, the manned aircraft can transit
across Za thanks to ATC traffic information and clearance.
In uncontrolled airspace, U-space is now up to 2000 feet or higher. Manned aircraft can fly inside “X”,
“Y” or “Zu” if UFR compliant. If not, they shall not fly in a U-space airspace.

 Drone operation plan preparation
 Drone aeronautical information including AIP and
information specifically dedicated to drone
operators
 ATC collaborative interface
 Monitoring
 Emergency management
 Tactical conflict detection and resolution
 Full services for environment monitoring
 tracking
Evolution of the airspace design and U-space airspaces are defined
structure.
Rules of the air In U-space airspace, UFR.
In ATM airspace, SERA.
Table 5 U-space characteristics 2035 - 2045
1.5.6 U-space 2070+:

U4 is there. The vast majority professional aerial operations are unmanned. Only very specific
operations and leisure operations could be manned.
ATM classes of airspace disappeared for the benefit of U-space volumes.
Unmanned and manned operations use U-space services, as manned aircraft are equipped to do so.
23
Unmanned are capable to autonomously avoid any other aircraft, even if remote pilot of VLOS
operations remains capable to avoid collision manually. Rules of the air are UFR.
Availability of the U-space services All services highly automated

Evolution of the airspace design and The sky is a U-space airspace
structure.
Rules of the air UFR is applicable everywhere
Table 6 U-space characteristics 2040+
1.6 U-space services definitions

The following section proposes to list, not exhaustively, some of the U-space services already identified
by EASA and many SESAR U-space projects.
They are introduced divided into three different parts:
Administrative services which have no operational purpose, in the sense that they do not impact
directly an operation during the flight.
U-space services, identified as being essential for the good execution of an operation performed
in a near future, including those that could be imposed by member state if required
The other U-space services which will be essential for UAS operations when they become
numerous.
1.6.1 Administrative services

These services have no impact on the flight as they are triggered before or after the operation occurs.
U-space service U-space service description

identification
Interaction with the registrar to enable the registrations of the drone, its
owner, its operator, and its pilot. Different classes of user may query
Registration
data, or maintain or cancel their own data, according to defined
permissions.
Registration assistance Provides assistance to people undertaking the registration process
Digital Logbook Produces reports for a user based on their legal recording information.
A secure and access-restricted system that allows drone operators and
Accident / Incident Reporting others to report incidents and accidents, maintaining reports for their
entire life cycle. A similar citizen-access service is possible.
Table 7 Administrative U-space services
1.6.2 U-space services

The services described in this section are those defined in the COMMISSION IMPLEMENTING
REGULATION (EU) 2021/664 of 22 April 2021 on a regulatory framework for the U-space.
The regulation defines four mandatory services and two optional services, which are listed in the tables
below.
24
U-space Service identification and Enhanced U-space Service description at solution
description level
e-identification
Network identification
e-identification enables information about the drone and
Should provide the identity of UAS
other relevant information to be verified without physical
operators, and the location and flight vector
access to the unmanned aircraft.
of UAS during normal operations and in
contingency situations and share relevant Tracking and position reporting
information with other U-space airspace Receives location reports, fuses multiple sources and
users. provides tracking information about all flight movements
Strategic conflict resolution

Checks for possible conflicts in a specific operation plan, and
proposes solutions, during operational plan processing.
Operation plan preparation/optimisation
Provides assistance to the operator in filing of a operation
plan. This service functions as the interface between the
drone operator and the operation plan processing service
UAS flight authorisation
Should ensure that authorised UAS Operation plan processing service
operations are free of intersection in space A safety-critical, access-controlled service that manages live
and time with any other notified UAS flight operation plans sub-mitted via the operation plan
authorisation within the same portion of U- preparation service (OPPS) and checks them against other
space airspace. services. The service manages authorisation workflows with
relevant authorities, and dynamically takes airspace changes
into account.
Risk analysis assistance
Provides a risk analysis, mainly for Specific operations,
combining information from other services – drone AIM,
environment, traffic information, etc. This can also be used
by insurance services.
Geo-fence provision (incl. dynamic geo-fencing)
Geo-awareness
Should provide UAS operators with the An enhancement of geo-awareness that allows geo-fence
changes to be sent to UAS immediately. The UAS must have
information about the latest airspace
the ability to request (or subscribe to), receive and use geo-
constraints and defined UAS geographical
zones information made available as part of fencing data.
the common information services. Navigation Infrastructure Monitoring
"This provides geo-fence and other flight Provides status information about navigation infrastructure
restriction information to drone pilots and during operations. This service should give warnings about
operators for their consultation up to the loss of navigation accuracy.
moment of take-off. It includes existing
aeronautical information, such as: Communication Infrastructure Monitoring
restricted areas, danger areas, CTRs etc... Provides status information about communication
infrastructure during operations. The service should give
- information extracted from NOTAMS, and
warnings about degradation of communication
legislation.
infrastructure.
25
description level
- temporary restrictions from the national Geospatial information service
airspace authority.
Collects and provides relevant terrain map, buildings, and
to produce an overall picture of where obstacles - with different levels of precision - for the drone
drones may operate. operation.
Population density map
Collects and presents a population density map for the drone
operator to assess ground risk. This could be proxy data e.g.,
mobile telephone density.
Electromagnetic interference information
Collects and presents relevant electromagnetic interference
information for the drone operation.
Navigation means coverage information
Provides information about navigation coverage for missions
that will rely on it. This information can be specialised
depending on the navigation infrastructure available (e.g.,
ground or satellite based).
Communication means coverage information
Provides information about communication coverage for
missions that will rely on it. This information can be
specialised depending on the communication infrastructure
available (e.g., ground or satellite based).
Traffic Information Provides the drone pilot or operator with information about
Should alert UAS operators about other air other flights that may be of interest to the drone pilot;
traffic that may be present in proximity to generally, where there could be some risk of collision with
their UAS. the pilot’s own aircraft
Table 8 Mandatory U-space services

description level
Weather Observation service
Responsible to provide real-time weather information for the
Weather Information drone operations and ensures that these are reliable,
Collects and presents relevant weather accurate, correct, up-to-date and available.
information for the drone operation
including hyperlocal weather information Weather Forecast service
when available/required. Responsible to provide forecast weather information for the
drone operations and ensures that these are reliable,
accurate, correct, up-to-date and available.
26
description level
Monitoring
Provides monitoring alerts (preferably audible) about the
Conformance monitoring progress of a flight (e.g., conformance monitoring, weather
Should provide real-time alerting of non- compliance monitoring, ground risk compliance monitoring,
conformance with the granted flight electromagnetic monitoring)
authorisation and inform the UAS operators Emergency management
when deviating from it. Provides assistance to a remote pilot experiencing an
emergency with their drone and communicates emerging
information to interested parties.
Table 9 Optional U-space services
1.6.3 Other U-space services identified

These services are seen as essential when UAS traffic will become dense, generating conflicts which
will require additional services such as tactical conflict resolution.
U-space service identification U-space service description

"The drone equivalent of the Aeronautical Information Management
Drone Aeronautical Information service. This service maintains the map of X, Y and Z airspaces, and
Management permanent and temporary changes to it. (e.g., a weekend festival
will change an area from sparsely to densely populated).
A mechanism invoked by the operation plan processing service
(OPPS) for coordinating the entry of a flight into an airspace which
Procedural Interface (with ATC or
require an authorization before flight (e.g., controlled airspace,
any other authority responsible for a
airspace above natural reserve). Through this, the authority can
volume of airspace)
either accept or refuse the flight and can describe the requirements
and process to be followed by the flight.
Exchanges data between the tracking service and other sources or
Surveillance data exchange
consumers of tracks – radar, other drone trackers, etc.
A restricted-access service to support accident and incident
investigation by recording all input to U-space and giving the full
Legal Recording
state of the system at any moment. A source of information for
research and training.
Similar to the Accident and Incident reporting service, this U-space
service is to be used by the citizen to inform the law enforcement
Citizen Reporting Service about not cooperative drone traffic or other suspicious event to be
reported. The user interface should be designed to encourage the
reporting of sufficient information to identify the flights concerned.
Checks for possible conflicts in real time and issues instructions to
Tactical Conflict Resolution
aircraft to change their speed, level or heading as needed.
27
U-space service identification U-space service description
Offers verbal or textual communication between the remote pilot
and ATC when a drone is in a controlled area. This service replaces
previous ad-hoc solutions and enables flights to receive instructions
Collaborative Interface with ATC and clearances in a standard and efficient manner.
CORUS has foreseen that this service would include, with time, the
procedural interface.
Responsible for balancing traffic demand and capacity constraints
Dynamic Capacity Management
during operational plan processing.
Responsible for managing status, resources
Vertiport dynamic information
(open/closed/availability, capacity) information about the vertiport
service
in real time
Table 10 Other U-space services identified in several U-space projects
28
2 Executive Summary
Urban Air Mobility (UAM) operations, which involve the transportation of people and goods by
unmanned aerial systems (UAS), are expected to occur in many locations for many purposes. These
operations are characterized by higher risk due to the higher traffic densities and ground risk
associated with urban areas, particularly when it comes to passenger transport. UAM operations in
urban areas also need to be socially acceptable, with limitations on noise and nuisance. UAS traffic
management as part of U-space is expected to be a key element in meeting the safety, security, and
social acceptability goals of UAM.
There is considerable interest in the integration of UAM into existing transport networks for both
goods and passengers, as it is anticipated that UAM operations will offer social benefits. This
document, the Advanced U-space Definition, describes UAM operations and Traffic Integration and
elaborates on the requirements for the U-space Concept of Operations. It is divided into four parts and
explains the operations of UAS, with a focus on the specific needs of UAM, including passenger
transport by electric, vertical take-off and landing (EVTOL) aircraft. The performance limitations of
current batteries for EVTOL aircraft require certain methods of operation to limit risk.
The performance requirements associated with UAM operations are defined, as is the safety
framework in which these operations and their associated risks can be considered. The document also
explores the need for new airspace design and procedures, particularly in the vicinity of airports and
vertiports, and the development of new rules of the air for manually or autonomously operated UAM.
Stakeholders involved in UAM as direct contributors or impacted users of the same airspace will use
diverse services to build or contribute to safe, secure, and efficient air traffic management for all types
of aircraft. Performance areas, both traditional and innovative, will be monitored to increase the
quality of services and improve social acceptability. The integration of different systems, with a focus
on interoperability with ATM systems, is also taken into consideration for the successful
implementation of Urban Air Mobility.
The Safety and Contingency Requirements for Integrated Operations section focuses on ensuring the
safe and efficient operations of Urban Air Mobility (UAM). This chapter is divided into four topics: Air
Risk Impact Assessment, Continued Safe Flight and Landing in Alternate Vertiports, Flight Planning and
De-Confliction, and Airspace Assessment.
The Air Risk Impact Assessment examines the potential risks and impacts of different flight trajectories,
corridors, and vertiport locations while also protecting other airspace users. The Continued Safe Flight
and Landing in Alternate Vertiports section outlines strategies for safely redirecting and landing in
alternative vertiports in the event of an emergency. The Flight Planning and De-Confliction section
discusses how to plan and coordinate flights to minimize conflicts and ensure safe operation. The
Airspace Assessment covers the regulations and rules governing unmanned flight, as well as the
classification of airspace for integrated operations.
Finally, the social acceptability of Urban Air Mobility (UAM) is examined, and some recommendations
made. A review of past public surveys highlights concerns related to safety, economics, and politics,
and proposes mitigation actions to address these concerns in UAM trial locations. Results from a
Societal Acceptance Study conducted during CORUS-XUAM trial locations indicate an overall positive
response to UAM. Conclusions are presented and a list of appendices includes a full list of mitigation
actions to address societal concerns.
29
3 Definition of the Operational Framework
3.1 Introduction
The chapter is written as part of T3.1 (Definition of the Operational Framework) and acts as a starting
point to derive high level operational requirements, safety requirements and for the social impact
analysis.
3.1.1 Structure of this Chapter

The Operational Framework description encompasses a set of topics which goal is to provide the
reader with an extended view of the operational environments as they will impact UAS operations.
Section 2 introduces the document, explaining its context, scope and aims. The scope description goes
into some detail on the of social, political and economic contexts are provided as well as a vision of U-
space evolution within the next 40 years. Note the glossary and acronyms appear in section 13.
Section 3 introduces the regulatory framework with the current U-space European regulation and
some local regulations which may impact drone operations. A description of the rules of the air is
provided as well as how they could affect drone operations.
Section 4 tackles system performances with key performance areas and indicators that could be
applied in U-space context.
Section 5 proposes an exhaustive list of stakeholders and UAS operations applicable in U-space.
Section 6 describes the ground environment, including infrastructures and constraints to drones
operations.
Section 7 deals the airspace characterization in urban environment. Constraints of current structures
of the airspace, U-space volume implementation and urban operations are discussed.
Section 8 provides a general view of systems in support of urban air mobility, from Air Traffic
Management systems to U-space systems.
Section 9 presents the procedures in the three phases which characterise a UAS operation: pre-
operational, pre-flight and flight phases.
Section 10 gives a description of the communication, navigation and surveillance characteristics in

urban environment by focusing on how CNS may “drive” UAS operations.
Section 11 proposes ground and air risk classifications.
Section 12 concludes
Section 13 lists the references, glossary and list of acronyms.
Appendices follow containing use cases.
3.2 Regulatory framework
30
This section identifies the regulatory framework that influences Urban Air Mobility and U-space and
serves as an input to further elaboration of recommendation for regulatory enhancements in WP4.
Please refer to the CONOPS and D4.4 for further assessment of the regulations.
3.2.1 EASA regulatory framework of U-space regulation

In 2016, the Warsaw Conference on UAS developed the concept of U-space, a set of digital services
enabling the safe growth of UAS routine operations. As a complement of the regulation of 2019 giving
a set of detailed rules for the operation of UAS [17] and [28] in April 2021 the Commission has
published the regulatory framework for U-space prepared by EASA, fulfilling in this way the objectives
set in the 2016 Warsaw declaration.
The U-space creates and harmonises the conditions needed for manned and unmanned aircraft to
operate safely, to prevent collisions between UA and other aircraft, and to mitigate the risks of UAS
traffic on the ground. The regulatory package that consists of 3 documents ([23], [ [29] and [30]) which
will enter into force on 22 April 2021 and will become applicable as of 26 January 2023.
In the following subsections a more detail summary of the main document [23] will be given. The other
two are briefly described below.
Implementing Regulation (EU) 2021/665 [29] is a short amendment to IR 2017/373 [11]. This
implementing rule is addressed to ATM. It adds 4 new definitions for U-space airspace, U-space service,
common information service and dynamic airspace reconfiguration. It also lays down requirements for
coordination with Air traffic services providers within U-space airspace and dynamic reconfiguration
of the U-space airspace for air traffic control units.
Air traffic services providers shall:
1. Provide relevant traffic information regarding manned aircraft within U-space airspace
2. Establish coordination procedures and communication between air traffic service units
and U-space service providers
Air traffic control units shall:
1. Ensure temporary limitations in U-space airspace depending on manned traffic demand

2. Ensure communication between U-space service providers and CIS providers about
activation/de-activation of the designated U-space airspace
Implementing Regulation (EU) 2021/666 [30] is a short regulatory document addressed to manned
aviation. It adds two new points to the current regulation EU2012/923 [32] to inform pilots about a
new area of airspace named as 'U-space airspace', its definition and the relation with a new type of
available services. In addition to this, it modifies the communication requirements established in
SERA.6006 [13] which will include different means for Radio Mandatory Zones (RMZ), Transponder
Mandatory Zones (TMZ) and 'U-space airspace'. Manned aircraft will be allowed to enter in a 'U-space
airspace' if the two following conditions met:
1. No traffic control service is provisioned

2. Aircraft equipment includes a system to make the aircraft electronically conspicuous to
the U-space service providers.
31
3.2.1.1 Mandatory services
The commission implementing regulation 2021/664 [23] lists four mandatory services that must be
provided in a U-space airspace and at least two other services that may be required by member state(s)
for safety purpose:
Article (18) the network identification service:
A network identification service should provide the identity of UAS operators, and the location and
flight vector of UAS during normal operations and in contingency situations and share relevant
information with other U-space airspace users.
Article (19) the geo-awareness service:
A geo-awareness service should provide UAS operators with the information about the latest airspace
constraints and defined UAS geographical zones information made available as part of the common
information services. In accordance with Implementing Regulation (EU) 2019/947, the establishment
of UAS geographical zones should take into account safety, security, privacy and environmental
requirements.
Article (20) the UAS flight authorisation service:
A UAS flight authorisation service authorises UAS operations are free of intersection in space and time
with any other authorised UAS flight within the same U-space airspace.
Article (21) the traffic information service:
A traffic information service should alert UAS operators about other air traffic that may be present in
proximity to their UAS.
3.2.1.2 Services that may be mandatory

Two other services in implementing regulation 2021/664 [23] may be deemed necessary by a member
state in order to ensure safe operation in a given U-space airspace:
Article (24) Weather information service:
A weather information service should support UAS operators during the flight planning and execution
phases, as well as improve the performances of other U-space services provided in the U-space
airspace.
Article (25) Conformance monitoring:
A conformance monitoring service should provide real-time alerting of non-conformance with the
granted flight authorisation and inform the UAS operators when deviating from it.
3.2.1.3 Requirements
Implementing Regulation (EU) 2021/664 [23] provides a regulatory framework for the U-space.
Chapter I of EU2021/664 [23] provides principles, general requirements and definitions.
Chapter II of EU2021/664 [23] provides requirements on U-space airspace and common information
services. Before a Member State designates a U-space airspace, an Airspace risk assessment has to be
32
conducted. There will be an AMC/GM published for further guidance [31]. There are four mandatory
U-space services:
the network identification service

the geo-awareness service
the UAS flight authorisation service
the traffic information service
An important part of U-space airspace is determination of UAS capabilities and performance
requirements, U-space services performance requirements, applicable operational conditions and
airspace constraints. All the above mentioned will be based on the performed airspace risk assessment.
For cross-border U-space airspace, states shall jointly decide on the designation, provision of U-space
services as well as provision of the cross-border common information services. As for U-space airspace
in a controlled airspace, the main objective is to keep UAS segregated and dynamic reconfiguration of
the airspace ensures a link between the USSP and the ATC in the case of manned aircraft flights taking
place in U-space airspace.
Chapter III of EU2021/664 [23] provides general requirements for UAS operators and U-space service
providers.
UAS Operators have a list of requirements that they shall comply with such as the capabilities and
performance requirements, applicable operational conditions and airspace constraints. U-space
service providers themselves shall always be compliant to regulation 2019/947 [17] as well as comply
with geographical zones limitations. UAS operator is expected to submit a UAS authorization request
before each individual flight through the flight authorization service.
U-space service providers shall be certified and are responsible for providing the UAS operators with
the U-space services. USSPs have to establish link with the air traffic services providers to ensure an
adequate coordination and information exchange relevant for the safe provision of U-space services.
Chapter IV of EU2021/664 [23] provides the detailed description about data interchange of the four
mandatory U-space services (network identification, geo-awareness, flight authorization and traffic
information) plus the weather information and the conformance monitoring services.
Such service description includes a number of requirements. For instance, the data items that a flying
UAS must make available to the network identification service shall include the altitude of the UAS and
this shall be given twice: once as altitude above mean sea level and a second datum which can be
either the height above the surface or above the take-off point. As a UAS is composed by the aerial
vehicle and the ground station, both positions shall be reported. In case there is not a ground station,
then the take-off point is used as such.
All transmission of data must always include a time stamp, and dynamic data shall be updated at the
established (by national authorities) frequency.
Only conflict free UAS operations can be authorised, and, in case of conflict, the existing aeronautical
prioritisation rules shall apply, including manned and unmanned, ATC and U-space controlled, and
across different USSP. Alternative routes for a flight can be given as solution to non-authorised flights.
A flight authorisation will include some flexibility limits such as time delay or position deviations
allowed. In case of traffic information, this shall include also manned aircraft.
33
Once on the air, the conformance monitoring service, not considered mandatory, shall provide alerts
that help to keep safety levels high. These alerts must be communicated by informing to the originator
flight of the non-conformance conditions, but also to the other close-by UAS.
Chapter V is about how USSP/CIS shall be certified.
Who certifies: the National CAA or EASA
How: see annex VI and VII
Conditions: service quality, economic viability (at least for 12 months), administrative and
management processes according to UE 2017/373 [11], insurance and contingency plans for them and
for end users.
USSP can apply in conjunction with others under an agreement contract.

Cease of activity when conditions are not met or after 6/12 months of non- activity.
Chapter VI - About the conditions for the CAA and EASA
CAA/EASA shall: have qualified personnel, resources to audit USSP/CIS and online services for
USSP/CIS,
CAA/EASA will define traffic data exchange conditions (see annexes II and V), design of U-space
airspace and its services, and assess safety.
Application of the regulation starts on 2023 (Jan 26th).
Content of the ANNEXES:
ANNEX I - Criteria elements

ANNEX II - Data access: online, fair, secure
ANNEX III - Performance of data exchange
ANNEX IV - Fields required for a flight permission: i.e., 4DT, emergency procedure, used technology
for eID/COMM...
ANNEX V - Data exchange between USSP, CIS and ATM
ANNEX VI - Format of the USSP Certificate
ANNEX VII - Format of the CIS Certificate
Content of the Appendix - Summary table for U-space services per Airspace class and Airspace user.
Conclusions from this summary table is proposed below:
U-space is for UAS not flying under either IFR or VFR.

Any A/C under ATC (i.e., all A/C in classes A-B-C-D, or IFR in class E) will never enter U-space. In
case on necessity, the dynamic airspace configuration will first reduce the U-space area
extension.
Manned AC allowed to enter U-space are only those not under ATC control (i.e., VFR in class E or
any A/C in class F/G).
The conditions are that they will communicate position to U-space but will not get any information
back. The USSP and the UAS shall give way to any entering manned aircraft.
3.2.1.4 Roles and responsibilities

While for most of the detailed services in EU2021/664 [23] the U-space service providers are
responsible to provide data to the UAS operators (geo-awareness, flight authorisation, traffic
information, weather information and conformance monitoring), in the case of the network
identification service the responsibility of the data flow starts in the UAS and goes to the U-space. Still,
34
this service is responsible to forward the relevant U-space data to the final users of the service, which
can range from competent authorities to general public, including other U-space services and also
other U-space service providers (USSP) or the ATC/CIS.
3.2.2 EASA implementing regulation on the rules and procedures for the
operation of unmanned aircraft
EU Regulations 2019/947 [17] and 2019/945 [28] set the framework for the safe operation of UAS in
European skies (EU and EASA Member States). They adopt a risk-based approach, and as such, do not
distinguish between leisure or commercial activities. They take into account the weight and
specifications of the UAS and the operation it is intended to undertake.
Implementing Regulation (EU) 2019/947 [17] sets the rules and procedures for the operation of
unmanned aircraft by introducing three categories of UAS operations (open, specific and certified).
Delegated Regulation (EU) 2019/945 [28]on unmanned aircraft systems and on third-country
operators of unmanned aircraft system. It provides requirements for the design and manufacture of
unmanned aircraft systems.
Apart from the two UAS Regulations, EASA has also developed Acceptable Means of Compliance (AMC)
and Guidance Material (GM) to the Regulation (EU) 2019/947 [18] in order to improve the
harmonisation of operations with unmanned aircraft within the EU.
3.2.2.1 Categories of operations and limitations

The Implementing Regulation (EU) 2019/947[17] establishes the rules and procedures applicable to
the use of unmanned aircraft. Based on the risk level of the operations, three operational categories
are established: ‘open category, ‘specific category’ and ‘certified category’.
Figure 1 Categories of operations
The 'open' category is divided, in turn, into three subcategories: A1, A2 and A3.
 Operational limitations: presence of people not involved in the operation.
 Requirements for the pilots: theoretical and/or practical training.
35
 Technical requirements for UAS: classes, private construction and UAS prior to the entry into
force of the standard.
Open Category – Subcategory A1
 No fly over assembly people

 Reasonably expect that no uninvolved
person is overflown. In case of unexpected
overfly over uninvolved persons, the RPIC
shall reduce as much as possible the time
during which the UAS overflies those
persons.
Figure 2 Subcategory A1 – https://www.easa.europa.eu/faq/116452europa.eu/faq/116452
 No fly over uninvolved people

 UAS at a horizontal distance of at least 30
metres from uninvolved persons, or up to 5
metres when low speed mode functions are
activated
Figure 3 Subcategory A2 – from https://www.easa.europa.eu/faq/116452
 No fly over uninvolved people

 Conducted in an area where the remote pilot
reasonably expects that no uninvolved
persons will be endangered within the range
where the unmanned aircraft is flown during
the entire time of the UAS operation
Figure 4 Subcategory A3 – from https://www.easa.europa.eu/faq/116452
The following table shows a full vision of requirements and limitations for the different open category
and UAS label indicators after January 1, 2023.
36
Table 11 Open category of operations restrictions and requirements – from
https://www.easa.europa.eu/faq/116452
UAS Operation Drone Operator/Pilot

Remote
Drone
Operational Remote pilot pilot
Class MTOM Subcategory Operator
restrictions competence minimum
registration
age
• May fly over No
Privately • No training
uninvolved minimum
built needed
people No, unless age
(should be camera/sensor
< 250 16*, no
avoided when on board and
g minimum
possible) a drone is not • Reader user
C0 age if
• No flying over a toy manual
drone is a
A1 assemblies of
toy
(Can also fly people
in • No flying
subcategory expected over • Reader user
A3) uninvolved manual
people (if it • Complete
< 900 happens, online
C1 Yes 16*
g should be training
minimised) • Pass online
• No flying over theoretical
assemblies of exam
people
• Read user
manual
• Complete
• No fly over
online
uninvolved
training
people
• Pass online
• Keep
theoretical
horizontal
A2 exam
distance of 30
(Can also • Conduct and
m from
C2 < 4 Kg fly in Yes declare a 16*
uninvolved
subcategory self-
people (this
A3) practical
can be
training
reduced to 5
• Pass a
m if low speed
written
function is
exam at the
activated)
NAA (or
recognized
entity
C3 • Do not fly
C4 < 25 near people • Read user
A3 Yes 16*
Privately Kg • Fly outside of manual
built urban areas
37
(150 m • Complete
distance) online
training
• Pass online
theoretical
exam
The 'specific' category comprises those UAS operations with a medium risk. Operations in the 'specific'
category requires authorization from the competent authority before carrying out the intended
operation, applying the mitigation measures identified in an operational risk assessment, except when
the operation is performed under a standard scenario.
A Standard Scenario (STS) is a predefined operation, described in an appendix to EU regulation

2019/947. Two STSs have been published. STS 1 and STS 2 and they require use of a UAS with class
identification label C5 or C6 respectively. In this case a declaration (responsible) on the part of the UAS
operator will be sufficient.
However, if the operation is not covered by an STS and doesn’t fall in the open category, then the UAS
operator will need to have an operational authorisation before starting the operation. Two alternative
approaches are provided for:
• An operational authorisation by conducting a risk assessment using a methodology for the

risk assessment; One method is:
o SORA (specific operation risk assessment), as proposed in EASA Acceptable Means of

Compliance and Guidance Material [15]
Another method, proposed in CORUS ConOps:
o MEDUSA (MEthoDology for the U-Space Safety Assessment)
• An operation authorisation through a predefined risk assessment’ (PDRA) as a simplification

of the UAS operator conducting a risk assessment.
Finally, a third option provided for the UAS operator is apply for a light UAS operator certificate (LUC)
to the respective competent authority. A LUC which is an organisational approval certificate. This
certificate grants powers and privileges to the UAS operator based on his degree of maturity, his
knowledge of the sector and his good practices when operating. The privileges may be one or more of
the following:
Conduct operations covered by standard scenarios without submitting the declaration.

Self-authorise operations conducted by themselves and covered by a PDRA without applying for
an authorisation.
Self-authorise all operations conducted by themselves without applying for an authorisation.
To sum up, the following diagram, shows the three proposed options for a UAS operator to operate in
‘specific’ category.
38
Figure 5 Specific category of operations procedure
The 'certified' category encompasses those UAS operations with a high risk, carried out with UAS with
which used on concentrations of people; designed and used to transport people; for the transport of
dangerous goods that may put third parties at risk in the event of an accident or UAS operations in
which the competent authority, based on the risk assessment, considers that the risk of the operation
cannot be adequately mitigated without the certification of the UAS and the also the UAS operator
and, where appropriate, without obtaining a license from the remote pilot.
Nowadays, but not yet in the regulation, three types of operation are proposed by EASA [19]:
 Operations type #1: International flight of certified cargo UAS conducted in instrumental flight
rule (IFR) in airspace classes A-C and taking-off and landing at aerodromes under EASA’s scope.
 Operations type #2: UAS operations in urban or rural environments using pre-defined routes
in airspaces where U-space services are provided. This includes operations of unmanned UAS
carrying passengers or cargo.
 Operations type #3: Operations as in type #2 but conducted with an aircraft with a pilot on
board. Actually, this is expected to cover the first type of air taxi operations, where the pilot
will be on board. In a second phase the aircraft will become remotely piloted (operations type
2).
3.2.2.2 UAS equipment and characteristics requirements

This subsection aims to explain the European regulations on UAS to be sold to the general public;
2019/945 [28], it must be understood that there is a new classification of unmanned aircraft. Using a
"class identification label" is intended to define the class of the UAS. Until now, the UAS had an
identification plate with the operator and aircraft data. From now on they must carry a sticker
indicating which class, or classes, they belong to, as well as the identification number that will be given
to them once registered.
The aircraft class identification label shall be affixed in a visible, legible and indelible manner. In
addition, all manufacturers must incorporate these labels on their UAS, with the commitment that the
UAS meet the corresponding characteristics.
39
To belong to one class or another, unmanned aircraft must meet a series of technical requirements
that are detailed below for each class of UAS.
UAS requirements described below belong to UAS which weight is less than 25kg; hence, they cannot
carry huge payload such as passengers or heavy goods, but they could be used to carry light payload.
To belong to class 0, the aircraft must incorporate the image label and meet the following
characteristics:
 Have an MTOW of less than 250 g

 Maximum speed in flight of 19 m/s
 Limit the maximum height from the take-off point to 120 m
 Be powered by electricity
characteristics:
 MTOW less than 900 g

 Have a maximum speed in horizontal flight of 19 m/s.
 Have a unique serial number
 Have a system for direct remote identification and network remote identification
 Be equipped with a geo-consciousness system
 Have equipped a low battery warning system for the drone and the control station (CS)
characteristics:
 Have an MTOW of less than 4 kg

 Be equipped with a data link protected against unauthorized access to command and
control functions (C2)
 Except if it is a fixed wing aircraft, be equipped with a selectable low speed mode that
limits the speed to 3 m/s maximum
 Contain a system of direct distance identification and network remote identification
 Be equipped with a geo-consciousness system
 Have equipped a low battery warning system for the drone and the control station (CS)
 Equip lights for attitude control and night flight
characteristics:
 MTOW less than 25 kg and a wingspan of less than 3 m

 Have a system of direct distance identification and network remote identification.
 Have a geo-consciousness system equipped.
 Be equipped with a low battery warning system for the drone and the control station (CS)
 Equip lights for attitude control and night flight
40
characteristics:
 Have an MTOW of less than 25 kg, including payload.

 Not having automatic control modes, except for assistance with flight stabilization and
for assistance in case of loss of link.
 Be safely controllable and manoeuvrable by a remote pilot following the manufacturer’s
instructions
characteristics:
 MTOW less than 25 kg.

 Not be a fixed wing aircraft, except if it is a captive UA.
 Have a system that provides the remote pilot clear and concise information about the
height of the drone.
 Be equipped with a selectable slow speed mode that limits the speed to 5 m/s maximum.
 In the event of a loss of data link (C2), or in the event of a failure, have a method of
recovering it or terminating the flight safely.
control functions (C2).
 Powered by electricity.
 Have a unique serial number.
 Contain a direct distance identification system.
 Have a geo-consciousness system equipped.
 Have equipped a low battery warning system for the drone and the control station (CS).
 Equip lights for attitude control and night flight.
 If the drone has a function to limit access to certain areas or volumes of airspace, it must
be interoperable with the flight control system, and must inform the remote pilot when
it prevents the UA from entering these areas or volumes of airspace.
 A C5-class drone may consist of a C3-class unmanned aircraft fitted with an accessory kit
that converts it to C5-class.
 The accessory kit will not include changes to the C3-class drone software.
characteristics:
 Have an MTOW of less than 25 kg.

 Have a system that provides the remote pilot with clear and concise information about
the height of the drone, providing means that prevent the aircraft from exceeding the
horizontal and vertical limits of a programmable operational volume.
 Maximum ground speed in horizontal flight of 50 m/s.
 In the event of a loss of data link (C2), or in the event of a failure, have a method of
recovering it or terminating the flight safely.
control functions (C2).
 Powered by electricity.
 Have a unique serial number.
 Have a direct remote identification system. 41
 Be equipped with a geo-consciousness system.
 Have equipped a low battery warning system for the drone and the control station (CS).
Figure 6 UAS classes requirements and characteristics
3.2.3 Examples of local regulations which may impact UAS operations in

urban environment
In some countries, local authorities have the power to implement specific local regulations valid only
in their areas of responsibilities. These regulations are usually adding constraints to the national one
or may deal with an issue they are the only to face (e.g., protection of a natural area).
3.2.3.1 France
For France, the city of Grenade, around 10 000 inhabitants, is taken as an example of local regulation
which could impact UAS operations in urban environment.
This city has set rules restricting usage of machines

during certain periods of the week and day to fight noise
nuisance.
It is forbidden to use professional machines:

 between 20h and 7h
 on Sunday and bank holiday
And leisure machines (e.g., lawn mower, handiwork
machine):
 On business day from 12h to 14h30 and after 19h30
 On Saturday from 12h to 15h and after 19h
 On Sunday and bank holiday from 12h to 16h and
after 18h.
Figure 7 City of Grenade on VFR map
According to French rules of the air, this city cannot to overflown by a VFR flight below 3300 feet AGL.
These restrictions do not apply for urgent professional interventions (e.g., electricity, gas or water
companies) or with the required authorization.
It is likely that these restrictions would apply also to UAS operations.
42
3.2.3.2 Spain, city of Barcelona
The Barcelona metropolitan area current local regulation are named Pla General Metropolità (PGM)
[33] and Text Refós d'Ordenació Urbana [34]. Gathering a total of 27 municipalities the PGM regulates
many of the day-to-day life in the metropolitan area, ranging from the Airport area (Articles 186-190),
industrial areas (Art.124) or the future uses of land for communal equipment (Art.215). In some
aspects, such as the environmental protection (Art.74) the PGM delegates to the municipalities the
limits to approve new usage licenses.
Activities and edification to hold industrial activities rely in several elements to be declared. The power
consumption is a key element to classify the activity, but also noise, emissions, water usage, residuals
or safety aspects are used for the classification (Art.287-289). All articles related with noise give limits
in decibels of type A (dBA). As an overall measure for environmental and human protection there is an
absolute limit of 80 dBA, but further regulations, such as the added noise of an individual activity on
the outside, stablished a maximum of 3 dBA over the background noise. This limit applies to external
noise generated by industries. Regulation also sets a time schedule for external activity and noise that
can be only from 8am to 9pm.
Nothing is reflected about privacy, vehicle emissions or power emissions of radio-frequency signals.
These three aspects are found in the national regulations, which are mainly transposed from European
regulations. For instance, the ground vehicle environmental categories. Nevertheless, the cities use
this classification to declare areas of low emission, where vehicles within categories Euro3-Euro5 are
not allowed to enter during week working daytime.
Both examples above show that it is likely that the regulatory framework in place in an area would be
different to the one in place in others, even in the same country. Local authorities will implement
additional (to the national/ European) regulations in accordance with local policy and in order to satisfy
local electorate. This would have to be considered by UAS operators.
3.2.4 What in the Standard European Rules of the Air could affect urban UAS
operations?
Aim of this section is to identify what in the SERA could affect urban air mobility UAS operations. From
“Easy access Rules for SERA, December 2018” [13].
3.2.4.1 Regular minimum height

The minimum heights provided in the following sections are those published in the European
Standardized European Rules of the Air. Some countries have increased or decreased some minimums
in certain conditions.
Heights selected are those provided for flights over urban areas and outside, in order to take into
account UAS operations linking two or several urban areas separated by non-urbanized zones.
Minimum heights are of utmost importance as they indicate where, in the vertical plan, a UAS is likely
to encounter a manned aircraft.
3.2.4.2 The aircraft flies with Instrument Flight Rules

SERA 5015,(b),(2): except when necessary for take-off or landing, or except when specifically
authorized by the competent authority, an IFR flight shall be flown at a level which is not below the
43
minimum flight altitude established by the State whose territory is overflown, or, where no such
minimum flight altitude has been established at a level which is at least 300 m (1 000 ft) above the
highest obstacle located within 8 km of the estimated position of the aircraft.
Note: large unmanned aircraft (RPAS) flying in controlled airspace are considered as flying in IFR. These
aircraft are usually (for the moment) state aircraft (mainly military) and their flight in civil controlled
airspace requires early coordination between the operator (usually the military) and the air traffic
control. Hence, as considered flying in IFR, IFR apply to these RPAS.
3.2.4.3 The aircraft flies with Visual Flight Rules
3.2.4.3.1 At night-time
SERA 5005 (5) ii: except when necessary for take-off or landing, or except when specifically authorized
by the competent authority, a VFR flight at night shall be flown at a level which is not below the
minimum flight altitude established by the State whose territory is overflown, or, where no such
minimum flight altitude has been established, at a level which is at least 300 m above the highest
obstacle located within 8 km of the estimated position of the aircraft.
3.2.4.3.2 At daytime
SERA 5005(f), (1): except when necessary for take-off or landing, or except by permission from the
appropriate authority, a VFR flight shall not be flown 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.
For inter-urban UAS operations, SERA 5005 (f) (2) will have to be considered, including AMC1 SERA
5005 (f) which states that “The competent authority should specify the conditions under which the
permission is or may be granted, including the minimum heights above the terrain, water or the highest
obstacle within a radius of 150 m (500 ft) from an aircraft practising forced landings, a balloon or an
aircraft executing ridge or hill soaring.
SERA 5005, (f), (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.
3.2.4.4 Flight plan

CORUS Concept of operations proposes to make mandatory the provision of UAS operation plan in U-
space volume Y, Zu and Za. This UAS operation plan will probably not look like ICAO flight plan but
contain some similar information. Common ideas are that the plan needs to convey who flies what
where and when. Specific to the UAS operation plan are the quantification of all uncertainties in the
planning and description of the trajectory as a series of one or more four dimensional volumes. The
plan in essence indicates that the aircraft will be in each 3d volume during the specified time duration.
EU regulation 2021/664 [23] uses the term “flight authorisation request” in regard to the mandatory
“flight authorisation request service,” see 3.2.1.1, and describes the format in Annex IV. Some further
light is shone on the annex in the AMC/GM for 2021/664 [31]. Annex IV does not match the
expectations of the plan described in the CORUS ConOps. This “flight authorisation request service”
addresses only the authorisation of flight within the U-space airspace. There is no mention of
coordination with ATC and absent from Annex IV is any way to indicate that a flight has permission to
enter any airspace. Hence the “flight authorisation service” of 2021/664 cannot currently be used to
authorise flights based in consideration of where they fly, nor to plan flights that exit U-space airspace.
44
The authorisation aspect of the “flight authorisation request service” of 2021/664 is limited to
detecting conflicts between any new U-space flight request and any previously authorised U-space
flight.
2021/664, 665 and 666 indicate that U-space airspace as described in the regulations, equivalent to Y
volume, may be visited by manned aircraft which are electronically conspicuous, but which have not
submitted a plan to U-space, which a will ineluctably prevent any strategic conflict resolution with
unmanned traffic.
Nevertheless, as UAS operations shall be declared before flight in volume Y, Zu and Za, manned aircraft
pilot may have access to a good situational awareness, provided they have access to information
coming from the U-space Service Providers.
3.2.4.5 Collision avoidance

SERA 3201 General: “Nothing shall relieve the pilot-in-command of an aircraft from the responsibility
of taking such action including collision avoidance manoeuvres based on resolution advisories
provided by ACAS equipment, as will best avert collision”.
As mentioned, several times in the different literatures, this is quite hard for a pilot of a manned
aircraft to see UAS in the sky due specifically to the small size of the UAS first, and to the fact that the
pilot has to concentrate on its own operation while being close to the ground. These constraints in
urban areas are exacerbated with the multiplicity of obstacles and contrasts coming from the ground.
Moreover, the number of UAS in urban environment may make impossible the detection by the pilot
of all the UAS in its vicinity and likely to be dangerous.
Therefore, avoidance of collision between a manned aircraft and a UAS shall be the responsibility of
the remote pilot when the UAS is flown VLOS. Nevertheless, the remote pilot flying a UAS in VLOS in
dense traffic conditions may take advantage of services such as a traffic information to help avoid
collision.
If the UAS is flown BVLOS, avoidance of collision will be provided by U-space services first, then by
systems such as detect and avoid acting as safety nets.
3.2.4.6 Right of way

Right of way is generally based on the capacity to see the other aircraft, their type and behaviour.
Details are provided in SERA 3210. This capacity does not exist for the remote pilot who is not on board
the aircraft, and even for VLOS flight the view makes it very hard to know which UAS or aircraft is
below, above, in front or behind the other.
This information may be provided by systems, to the UAS (and the remote pilot) directly if flying in
autonomous mode, or to the remote pilot if the UAS is steered manually.
SERA describes right of way for the flight rules VFR, IFR and special VFR. There is no information in
SERA on the right of way between manned and unmanned aircraft that are not following one of these
flight rules. Implicit in the description of the traffic information service of EU regulation 2021/664 is a
requirement that unmanned aircraft give priority to manned aircraft.
45
3.2.4.7 VMC visibility and distance from cloud minima
In urban area and below 1000 feet, visual meteorological condition visibility and distance from cloud
minima concern manned aircraft flying in VFR with special authorization or flying in the vicinity of an
aerodrome for take-off, landing and aerodrome circuit.
Outside urban areas, these minima impact all the VFR flights.
Visibility and distance from cloud are clearly compatible with VLOS operations. They could be useful
for a UAS pilot to see an aircraft, manned or unmanned (depending on the size) long in advance and
early enough to take appropriate actions.
BVLOS operations should not be impacted by these parameters. The remote pilot would not take
benefit of a good visibility for instance.
This is valid as long as the UAS does not carry sensors which performance do not depend at least on
one of these parameters.
*** The VMC minima in Class A airspace are included for guidance to pilots and do not imply
acceptance of VFR flights in Class A airspace.
Altitude band Airspace class Flight visibility Distance from cloud
At and below 900 m 1 500 m horizontally

A***B C D E 5 km
(3 000 ft) AMSL, or 300 m 300 m (1 000 ft) vertically
(1 000 ft) above terrain, Clear of cloud and with the surface
FG 5 km
whichever is the higher in sight
Below 3 050 m (10 000 ft)

AMSL and above
900 m (3 000 ft) AMSL, or A***B C D E F 1 500 m horizontally

5 km
above 300 m (1 000 ft) G 300 m (1 000 ft) vertically
above terrain, whichever
is the higher
Table 12: Meteorological conditions minima and distance from cloud for VFR flight – ICAO Annex 2 and SERA
5001
3.2.5 Identified gaps in the current regulation

Despite European regulation for UAS operations is quite advanced and still on-going, we can notice
some gaps; below some elements missing in the regulation:
 The first gap identified is the lack of regulation for operations in the specific and certified
categories related to the minimum distance between the UAS and the people or an assembly
of people, and obstacle, whereas it is defined in the open category. Even if the operator, the
UAS and the remote pilot are certified when operating above urban or populated
environment, there should be minimum distances, vertical and horizontal, set between the
UAS and obstacle, people and assembly of people.
46
 Regarding certified categories, for instance air taxis, current information (e.g., Doc. No: SC-
VTOL-01, article 6 of EU 2019/947) we have in the regulation is not detailed enough whereas
it is probably the kind of operations that will be performed soon.
 There is a need to establish prioritization rules considering type of vehicle and operations
(manned aircraft, passengers-carrying UAS, cargo-carrying UAS) beyond the existing priority
for safety-relevant flights.
 There is no clear definition of populated area. EU regulations, acceptable means of compliance

and guidance material mention "populated area" but do not refer to a precise definition of
the term:
EASA is pursuing to launch a study for a better measurement of population density in Europe, which
include development of static and dynamic maps (EASA presentation of the 1st of October 2020 -
"Operations in the medium risk of the Specific category").
 The SORA does not consider air risk due to other UAS flight, only with manned aircraft.
Nevertheless, JARUS WG 6 is already working to expand the scope of SORA to address the risk of
collision when more UAS are flying in the same airspace (e.g., urban).
 No Standard scenario for operations specifically in urban environment in the Specific category
has been proposed so far, especially for flight over uninvolved people. Provided the number
of use cases of operations in urban environment which could not be performed in the open
category (e.g., building inspection, photography, filming) nor in the certified category without
dramatically increasing the cost, this would be relevant.
 No values for the separations (unmanned – unmanned and unmanned- manned) is provided.
These could be an absolute distance or a function of performances (CNS and aircraft).
 It is also likely that the Standardised European Rules of the Air would have to be updated in
order to describe the rules for operating in a U-space airspace.
The scope of EU regulations today is “Early U2”. Regulation 2019/947 [17] described minimal U1
implementation – registration, collection and dissemination of drone aeronautical information.
Regulations 2021/664, 665 and 666 ( [23],[29],[30] & [31] ) describe some U2 services in a way that
will only support low density operations. A number of situations are foreseeable in 2021/664 such as
the arrival of a conspicuous manned aircraft in U-space airspace, or the dynamic redefinition (removal)
of U-space that raise the question “and then what happens?”
To move forward, the EU regulations need to tackle higher density U2 by looking at traffic with
frequent strategic conflicts and consider how to make efficient use of the available airspace, and then
address U3; that is tactical separation and flight rules that would allow integration of manned an
unmanned traffic.
3.3 System Performance

Performance characterisation is the structured way to describe the target outcome of a system and to
monitor how close the outcome is to that target. In the specific case of Air Traffic Management, the
ICAO Global Air Traffic Operational Concept, Doc 9854, [35] associates performance to the diverse
47
demands of the system from diverse members of the ATM community. This ICAO ATM ConOps
establishes the concept of Required ATM System Performance (RASP)2:
“RASP is the set of criteria, expressed in the form of performance parameters and values of
those parameters, that the ATM system needs to meet, with a given probability, in order to
support the approved quality of service specified for a particular environment.”
In line with this conceptual framework, the role of performance characterisation for the U-space
system in support of Urban Air Mobility is twofold:
- Set expectations about the system outcome.
- Monitor the external outcome of the system in a way that can be linked to the performance
of internal functionalities, allowing for steering actions towards expectations.
3.3.1 Key Performance Areas

The first level of performance structuring is setting Key Performance Areas: those areas of
performance considered critical for the system success in terms of outcomes, in line with the
expectations of the relevant stakeholders. In the ICAO 9854 document [35], Appendix D, there is
indeed a description of the ICAO 11 Key Performance Areas for ATM in terms of the expectations of
the ATM community.
The other main source in European ATM providing additional definitions for the same KPAs and also
proposing some amendments and additions is the SESAR Performance Framework and the European
ATM Master Plan [36].SESAR PF is conceived for setting expectations and measuring benefits linked
to solutions for manned air transport from a research and development point of view. To this aim,
there are some ICAO KPAs left outside the list. Since the focus of the present document is the
unmanned air traffic research and development, all ICAO areas are considered and analysed. In
particular, three areas not included in SESAR PF were considered relevant additions to the CORUS-
XUAM performance scheme by the attendees to the first CORUS-XUAM workshop (27th September to
1st October 2021, virtual event. 93% agreement through online poll): Access and equity, Participation
and collaboration and Flexibility.
In the context of European drone traffic management, there has not been yet an attempt to define
KPAs relevant for U-space. There are however a couple of references that add some light to the U-
space performance scene:
 U-space ConOps from CORUS [4] addresses Social Acceptance as one key area to be considered
linked to the expectations and perceived impact of various sectors of society.
 SESAR JU guidance for U-space demonstrations [37] puts the focus of the performance
assessment for drone traffic management research and demonstration projects on certain
KPAs (such as environment, safety, security, cost-efficiency and human performance). Besides,
2
It must be noted that RASP accounts for the external performance (outcome of the system) to which
corresponds the expectations. A different concept is the Required Total System Performance (RTSP), which is the
internal performance related to the functionality of the ATM components as they contribute to deliver the
external performance.
48
the document introduces specific questions for cost-efficiency and human performance, which
can be read as further details of the scope of the related KPAs.
Outside the European scene, there are two main references to be observed, because of their advanced
and structured contribution to setting a drone performance framework:
 The Australian Urban ATM ConOps [38], which builds on the same 11 KPAs of ICAO to set
performance expectations/ benefits associated the effective functioning of main Urban ATM
services:
o Airspace and procedure design.
o Information exchange.
o Flight planning and authorisation.
o Flow management.
o Dynamic airspace management.
o Conformance monitoring.
 The UK Connected Places Catapult – Open Access UTM programme [39] goes a step forward
and introduces key principles (assailable to KPAs) tailored to the UTM, including the traditional
safety, security or flexibility and also other innovative drone-specific areas such as
transparency and scalability.
The following table summarises the definitions of each KPA in the mentioned references.
49
SESAR JU
KPA ICAO SESAR PF guidance for U- Open Access UTM - UK Catapult
space
Access and A global ATM system should provide an
Equity operating environment that ensures that
all airspace users have right of access to
the ATM resources needed to meet their
specific operational requirements and
that the shared use of airspace by
different users can be achieved safely.
The global ATM system should ensure
equity for all users that have access to a
given airspace or service. Generally, the
first aircraft ready to use the ATM
resources will receive priority, except
where significant overall safety or
system operational efficiency would
accrue or national defence
considerations or interests dictate that
priority be determined on a different
basis.
Participation & The ATM community should have a
Collaboration continuous involvement in the planning,
implementation and operation of the
system to ensure that the evolution of
the global ATM system meets its
expectations.
Capacity The global ATM system should exploit The ambition is to tackle capacity
the inherent capacity to meet airspace crunch, address the risk of
user demands at peak times and unaccommodated traffic and
locations while minimizing restrictions increase the network traffic
on traffic flow. The ATM system must be throughput in order to
resilient to service disruption and the accommodate predicted demand
resulting temporary loss of capacity. with a sufficient margin. It also
intends to provide sufficient
50
SESAR JU
space
scalability at key bottlenecks in the
network to enable reductions in
ATFCM delays and increase the
potential for fuel-efficient
trajectories.
Cost The ATM system should be cost- The ambition is to provide necessary Cost Benefit
Effectiveness/ effective, while balancing the varied technical system changes, at Analysis (CBA) of
Cost Efficiency3 interests of the ATM community. The reduced life cycle costs, while deploying the U-
cost of service to airspace users should continuing to develop operational space services
always be considered when evaluating concepts to enhance the overall (and required
any proposal to improve ATM service productivity of ANS provision. The capabilities).
quality or performance. performance ambitions are a
reduction of costs per flight and
gate-to-gate direct ANS cost per
flight.
Efficiency Efficiency addresses the operational and Efficiency and predictability together
economic cost-effectiveness of gate-to- form "Operational Efficiency".
gate flight operations from a single-flight Indirect economic benefits for flight
perspective. In all phases of flight, operations, mainly through the
airspace users want to depart and arrive reduction and better management
at the times they select and fly the of departure delays and more
trajectory they determine to be efficient flight paths, reducing both
optimum. the additional fuel consumption
3
This KPA is conceptually the same for the two main references observed in this Operational Framework (ICAO and SESAR PF), although the exact term used in each
one is different. ICAO uses “Cost Effectiveness” while SESAR PF talks about “Cost Efficiency”.
51
SESAR JU
space
Predictability Predictability refers to the ability of attributable to ATM and gate-to-
airspace users and ATM service gate flight time, and increasing
providers to provide consistent and predictability. For the military,
dependable levels of performance. operational efficiency is an enabler
Predictability is essential to airspace of mission effectiveness. This means
users as they develop and operate their the best possible adherence
schedules. between the planning and the
execution phase of the mission (e.g.,
in relation to fine-tuning of the
transit time from/to the home base,
real occupancy of the reserved
airspace).
In addition to reducing departure
delays, the aim is to increase the
predictability of flight arrivals in
accordance with commonly agreed
reference business trajectories, prior
to push-back.
Environment The ATM system should contribute to The reduction in gate-to-gate CO2 Considered but
the protection of the environment by emissions is directly proportional to no definition
considering noise, gaseous emissions the average reduction in fuel burn provided.
and other environmental issues in the per flight, and thus captured by the
implementation and operation of the efficiency KPI.
global ATM system. In addition to its global impact due
to CO2 emissions, aviation has local
impacts, in terms of noise and local
emissions, that are specific to each
airport and affected by airspace
constraints, the traffic mix, local land
use and local geography.
Global The ATM system should be based on Interoperability and global
Interoperability global standards and uniform principles harmonisation rely on the
52
SESAR JU
space
to ensure the technical and operational synchronised application of
interoperability of ATM systems and standards and common principles,
facilitate homogeneous and non- together with common technical and
discriminatory global and regional traffic operational solutions for relevant
flows. aircraft and ATM systems. This
includes civil-military
interoperability.
Safety Safety is the highest priority in aviation, Irrespective of traffic growth and Considered but Cornerstone to enable increasingly
and ATM plays an important part in taking into account that the no definition complex drone operations –
ensuring overall aviation safety. Uniform ATM/ANS system must ensure gate- provided. particularly in controlled airspace or
safety standards and risk and safety to-gate traffic safety (in flight as well urban settings, where mitigating
management practices should be applied as during surface movement, that is, risk to people, vehicles, property
systematically to the ATM system. In during taxi and on the runway), the and other airspace users will remain
implementing elements of the global safety ambition is zero accidents as a challenging.
aviation system, safety needs to be consequence of ATM/ANS. Meeting
assessed against appropriate criteria and this ambition will require a
in accordance with appropriate and significant reduction in risk per
globally standardized safety individual flight.
management processes and practices.
Security Security refers to the protection against The overall objective is to ensure Considered but Security refers to the protection of
threats that stem from intentional acts that the airspace and the ATM no definition a person, item, service, etc. against
(e.g., terrorism) or unintentional acts system, including ATC and CNS provided. threats i.e. the need to protect the
(e.g., human error, natural disaster) infrastructure and airports, as well UTM participants, drone
affecting aircraft, people or installations as ATM-related information, are operations, the public and the
on the ground. Security risk adequately protected against environment. Threats can be caused
management should balance the needs security threats, meeting the by external intentional acts (e.g.,
of the members of the ATM community expectations of European citizens terrorism, spoofing attacks,
that require access to the system, with and policymakers. cyberattacks), internal intentional
the need to protect the ATM system. In acts (e.g., threats from disgruntled
the event of threats to aircraft or threats employees), and unintentional acts
using aircraft, ATM shall provide the (e.g., human error, technical
hardware or software error/failure).
53
SESAR JU
space
authorities responsible with appropriate
assistance and information.
Flexibility Flexibility addresses the ability of all Flexibility refers to the ability of the
airspace users to modify flight UTM architecture to evolve or
trajectories dynamically and adjust adapt with respect to
departure and arrival times, thereby considerations relating to
permitting them to exploit operational technological progress, risk and
opportunities as they occur. performance measures, policy and
regulatory changes, and new
business models.
Transparency Information sharing attribute of this
UTM framework which will enable
all stakeholders access to a
common understanding of the
airspace in terms of operations and
services. As a result, UTM users will
have the right of access to the
airspace when they fulfil the
operating requirements, but also a
right to understand why access
maybe denied. Considerations
around transparency are important
due to the potential impact on
trust, security and safety in the
system. There are other key
considerations around
transparency, particularly around
the compromise between user
privacy and security.
Scalability Scalability refers to the capacity for
growth in the number of
54
SESAR JU
space
manageable drone operations, as
well as the number (or density) of
vehicles, or the number of actors, or
services and messages that can
reliably operate within the same
UTM environment.
Human Human Performance (HP) is used to Potential impact
Performance denote the human capability to on ATCO in case
successfully accomplish tasks and of interface
meet job requirements. The ATM/U-space,
capability of a human to successfully pilot, flight
accomplish tasks depends on a planning
number of variables that are usually operators, etc.
investigated within the discipline of
“Human Factors (HF)”. These are
procedure and task design, design of
technical systems and tools, the
physical work environment,
individual competences and training
background as well as recruitment
and staffing. HP also depends on the
way in which Social Factors and
issues related to Change &
Transition are managed.
Table 13: Definitions of KPAs applicable to ATM and U-space
55
To complete the summary provided in the table above, the U-space ConOps [4] provides the following
description of Social Acceptance:
Drones bring high social and economic expectations. But social acceptance of drones is key for
the full development of the economical expectations. To consider all aspect of social impact the
acceptance is evaluated from three points of view: safety (perception), economic
(accomplishment of economical expectations of the new emerging drone market) and political
(any other social issue, which includes aspects such as the citizens’ affectations from the
drones’ noise, the privacy potential compromise, the visual impact etc.)
3.3.2 Performance Ambitions

As introduced at the beginning of this section 3.3, a main objective of the performance characterisation
of a system is to drive outcomes in line with expectations. These are logically different for each
stakeholder, depending on its business, technical and operational objectives. Besides, there can be
regional and local differences in the specific objectives that each stakeholder has. The expectations
analysed in this section does not account for these local specificities. They have been produced using
expert judgement internal to the project and will be used as a framework to set the Performance
Indicators to be measured in CORUS-XUAM demonstration.
The stakeholder list used is tailored to UAM:
- Service Provider:
o U-space Service Provider (USSP)
o One-service USSP4;
o Common Information Service Provider (CISP)
o ANSP
o Infrastructure SP
o Supplemental Data Service Provider (SDSP).
- Safety Authority:
o SA concerned with Drone Operators (Dos)
o SA concerned with airspace and rules of the air
o SA concerned with service providers.
- Regulator
4
A USSP that provides one specialised service, which may or may not be regulated. The weather and data service
providers are examples of these, but there could be others:
- Providing specific monitoring services: GNSS performance, Sunspot activity, Airborne dust…
- Using some proprietary algorithm to generate some “added value” service – input traffic demand,
output perceived noise at ground level.
56
- Vertiport Operator
- Airport Operator
- UAS Operator
- Other airspace users:
o Recreational & sport aviation
o Aerial works
o Private flights
o Commercial air transport
o Military, including state police.
- Society (in the sense of interests not already represented by other stakeholders)
- Local authorities with geographical scope:
o Specific authorities (e.g., harbour authorities)
o City/ Region/ State.
- Surface transport modes
- Value-added business.
The progress so far has been the production of expectations of service providers, airport operators
and UAS operators.
57
Service Provider
KPA USSP One-service USSP CISP ANSP Infrastructure SP SDSP
Fair access to No restrictions on

Access and
airspace for its ATM linked to
Equity5
Drone Operators UAM activity
Accommodation
of all operations Capacity can meet
Capacity
managed by the the demand
USSP
Accomplishment
Global costs and
Cost of economical
investment are
Effectiveness/ expectations of
covered by
Efficiency the new drone
income
market
Minimum delays
and extra- Smooth
Efficiency distance flown for management of
the operations resources
managed
5
Services in U-space are expected to be offered by commercially. All service providers expect equal business conditions and access to the market.
58
Service Provider

Possibility to
change
trajectories of the
operations
Flexibility managed to adapt
to operational
needs and/ or
business
opportunities
Updated
Possibility to take
Possibility to take Possibility to take Possibility to take information on
part on
part on part on Competence to part on discussions on the
discussions on the
discussions on the discussions on the take part on discussions on the technical,
Participation technical,
technical, technical, collaborative standards and regulatory and
& regulatory and
regulatory and regulatory and decisions regulations standardisation
Collaboration operational
operational operational impacting ATM impacting the aspects impacting
evolution of the
evolution of the evolution of the operations provided the provision of
U-space
U-space U-space infrastructure the SDSP specific
concerned service
data
59
Service Provider

Maximum
adherence to
Minimum changes Minimum changes Maximum approved
Predictable drone
due to network due to network adherence to operation plans so
operations so
constraints in filed constraints in approved that level of
Predictability UTM-ATM knock-
trajectories of the operations linked operation plans of performance
on delays are
operations to the U-space flights in the provided can be
minimised
managed concerned service managed airspace better planned
and adjusted to
demand
Safety level of
Minimise risk of UAM operations
Minimise risk of
collision with close to or within
collision with
other drones, controlled Minimise risk of
other drones,
infrastructure or airspace is high collision of drones
Safety infrastructure or
manned aircraft enough so there is with the managed
manned aircraft
of drones within not a subsequent infrastructure
of the operations
the managed decrease in safety
managed
airspace level of ATM
operations
60
Service Provider

Minimum security
Security level of Minimum security
occurrences, and
UAM operations occurrences, and
especially
Minimum security Minimum security close to or within especially Minimum security
intentional rogue
occurrences occurrences, and controlled intentional rogue occurrences
drones, in the
impacting the especially airspace is high drones, in the impacting the
Security airspace in which
provision of the intentional rogue enough so there is vicinity of the provision of the
the USSP is
U-space drones, in the not a subsequent managed concerned data
operating or
concerned service managed airspace decrease in infrastructure or service
impacting the
security level of impacting the CNS
operations
ATM operations service provided
managed
Visibility of Visibility of
operations and Visibility of operations and
services in the Visibility of manned Visibility of services in the Visibility of
area of service operations and operations from operations inside vicinity of the operations and
Transparency provision, as well other services in the ANSP (e.g., and close to managed services impacted
as access to the area of service about TSAs, controlled infrastructure by the data
rationale for provision airspace closure, airspace and/ or impacted service provided
denied access or AIM, etc.) by the CNS service
reduced priority provided
61
Service Provider

Possibility to Possibility to Possibility to
growth in number growth in number growth in number
of operations of operations of operations
Scalability managed, served, managed,
unconstrained by unconstrained by unconstrained by
technical technical technical
limitations limitations limitations
Concurrence of Concurrence of
number and number and Acceptance by
typology of typology of society of new
Social operations operations drone
Acceptance accepted by accepted by infrastructures
society with society with and their service
target operations target operations levels
managed managed
62
Service Provider

Clear and
Clear and Clear and Clear and effective
effective effective effective procedures and
procedures and procedures and procedures and tasks design, and
tasks design, and tasks design, and tasks design, and standards for
standards for standards for standards for Clear procedures design of
Human design of design of design of that allow smooth technical systems
Performance technical systems technical systems technical systems coordination and tools that
and tools that and tools that and tools that ATM-UTM support
support support support effectively human
effectively human effectively human effectively human tasks for the
tasks within the tasks within the tasks within the related
USSP one-service USSP CISP infrastructure
management
Table 14: Stakeholders Expectations in terms of KPAs for Service Providers
Table 15: Stakeholders Expectations in terms of KPAs for Service Providers
63
KPA Airport Operator UAS Operator Vertiport Operator
Access and Equity No restrictions on airport Free market Assurance of equitable

management linked to UAM access to a variety of UAS
activity and assurance of Fair and flexible operators and USSPs from an
access to drone performing accommodation of flights operational perspective
airport-relevant operations which cannot file
authorization requests with
great lead time, e.g., air
taxis, ad-hoc delivery
missions
Capacity Minimum delays and Concept of operations that

Minimum re-routing maximizes or at least not
unduly restricts capacity for
departing and arriving
aircraft and VTOLs (e.g.,
through capacity-prohibitive
contingency procedures)
Cost Business case of each

Effectiveness/ vertiport (may differ) need
Cost Efficiency to be satisfied; overall ticket
prize is partly shaped by the
efficiency of the vertiport
operation
Efficiency Optimal routes Intermodality asks for an

efficient UAS operation in
order to meet transition
times and affordable ticket
prizes and social acceptance
Flexibility - Minimum time from Adequate handling of

request to acceptance variation of demand patterns
- Negotiation capabilities and densities is required.
with other operators Tightly connected to capacity
and operational resilience of
a vertiport
Global Standards for USSP API Unified definition about a

Interoperability vertiport operator's role and
responsibilities within U-
space.
Standard procedures and

communication protocols
which describe the operation
on a vertiport and are
64
distributed to all U-spacer

users
Participation & Competence to take part on Consultation on U-Space Competence to take part on
Collaboration collaborative decisions design collaborative decisions
impacting airport operations impacting vertiport
operations
Active member of U-space

and provider of U-space
services (capacity, weather,
workload/utilization, etc.)
Predictability Predictable drone operations Transparency of acceptance Predictable drone operations

so airport operations and ratio and maximum response so vertiport processes can be
especially turn-around of time efficiently planned and
other aircraft are not executed in support of a
negatively impacted successful business case
Safety Safety level of UAM No drone's lose Primary concern which

operations close to or within Not high endurance needs to be addressed on
the airport is high enough so the airside air, airside ground
there is not a subsequent Minimize risk to third parties and on the landside of a
decrease in safety level of (since UAS operator may be vertiport
airport operations liable for damage)
Safety level of UAM
operations close to or within
the vertiport is high enough
so there is not a subsequent
decrease in safety level of
vertiport operations
Security Security level of UAM Impossibility of hacking my Security level of UAM

operations close to within drone operations close to or within
airports is high enough so vertiport is high enough so
there is not a subsequent there is not a subsequent
decrease in security level of decrease in security level of
airport operations. Rogue vertiport operations. Rogue
drones are avoided drones are avoided.
On-demand behaviour and

short travel times asks for a
modern and probably
interoperable security check
of passengers. Security of
autonomous operations and
65
the provision of U-space

services by the vertiport
operator need to be ensured
Transparency Visibility of operations in the Clear rules for accessing the Visibility of operations and
vicinity of the airport airspace and clear services in the vicinity of the
requirements for the vertiport
approval of operations
Scalability Growth of business Growth of business
Social Acceptance High rate of clients Acceptance of operations

and integration of vertiport
services in the surrounding
environment.
Main issue which will be

faced by a vertiport operator
and its facility. Integration
into existing transportation
networks and an active
participation in U-space
Human Minimal interaction Minimal interaction (high

Performance degree of automation) is
anticipated but
responsibilities need to be
clarified and the interaction
with "modern" systems
(propulsion, charging,
passenger screening,
operational procedures,
monitoring etc.) need to be
trained
Table 16: Stakeholders Expectations in terms of KPAs for Airport and UAS Operators
RASP concept [27][35] has been also introduced as the set of performance requirements to be met by
the system. It must be highlighted that “RASP does not mean that the system performance can be
expressed by a single figure or that performance figures have to be unique globally”. The implication
of this is twofold:
- The required performance will be expressed in the form of a set of values for the
correspondent set of indicators.
- The required performance can vary depending on the environment. The notion of environment
impacts on the analysis of relevance of each KPA for each stakeholder. In plus of considerations
66
of rural, suburban and urban areas, aspects such as type of airspace (possible examples – not
yet discussed – are high performance layers, approach areas to vertiports, logistic hub
surrounding airspace, environmentally sensitive areas) or level of complexity/ risk might
influence in the level of relevance of each KPA.
3.3.3 Performance Indicators

The required level of performance in each KPA is measurable within a framework of performance
indicators.
At the level of individual VLDs it is a way of covering the demonstration of success in reaching the VLD
objectives (see Deliverable D35.). All in all, the global set of indicators shall be able to demonstrate
achievement of global CORUS-XUAM objectives and also to mirror relevant results in a way compatible
with dissemination of VLDs and global success to local boards/AB.
3.3.4 Key Performance Indicators

KPIs - “Target” is understood to be the minimum that is required at a given point in time or at a given
period and may also address the present.
There are already some expectations included in the reference documents defining the KPAs in the
Excel with KPAs-KPIs. ATM Master Plan 2020 establishes objectives for the deployment of full U-space
services and UAM. A valuable output from the project, based on experiments, will be feedback on the
need for updating the Master Plan proposals in terms of dates.
3.4 Stakeholders and use cases

System architects often need to describe how some ‘system’ is used. The system is some man-made
thing that usually brings together different elements and requires particular operating procedures. Our
system is U-space, the European implementation of UAS Traffic Management. Descriptions of uses of
a system are often formulated as “use cases.” Use cases are little stories explaining how some goal is
achieved in terms of a sequence of system functions. They come as “nominal” and “non-nominal.” Use
cases are generally named for some tasks being achieved (e.g., “deliver pizza”) and the nominal form
is a story in which the goal is achieved. The non-nominal forms (and there are always many) are
versions in which the goal is not achieved (the customer does not receive the pizza) or not achieved
completely (the pizza arrives late and is cold) or not achieved in the intended way (the pizza is delivered
by a guy on a motorbike, not by a UAS).
Use cases can be presented in different ways. As they are generally functioning as a means to get a
group of people to agree or at least share a common understanding of how the system is being used,
67
the presentation should be adapted to the audience as far as is possible - audience members often
have particular concerns and interests.
System architects use different terms to describe the people in terms of the system. In the past a term
that has been used is “actor” meaning a person who takes some action. (e.g., “press the green button”)
But this idea of an actor is limiting in terms of explaining the person’s motivation. The approach used
here is to use two terms.
Stakeholder
Role
The stakeholder is a group, corporate, organization, member, or system that affects or can be affected
by an organization's actions. Stakeholders are typically identified by their properties or functions in
society. (e.g., pizzeria manager, hungry person)
The role is a way to describe the function or position that someone has or is expected to have in an
organization, in society, or in a relationship. Roles should not be defined in terms of the system.
“Presser of the green button” is not a useful role name.
The mapping from stakeholder to role can be many to many as the situation determines.
3.4.1 General stakeholders

The stakeholders listed here are an expanded group building on the CORUS U-space ConOps volume
3, annex K. Following this list each is described in a subsection.
3.4.1.1 UAM stakeholders in detail
3.4.1.1.1 Air taxi booking service provider

An air taxi booking service is a service allowing the general public to book a journey in an air taxi. It
offers mobility as a service (MaaS). This stakeholder may (or may not) be independent of any air taxi
operator or any vertiport operator. An example of this stakeholder was Voom6 which operated until
the pandemic offering helicopter transport provided by multiple aircraft operators.
3.4.1.1.2 Air delivery booking service provider

An air delivery booking service is a service allowing anyone who wants to, to book a delivery by air.
This stakeholder may (or may not) be independent of any air delivery vehicle operator or any vertiport
operator.
6
https://acubed.airbus.com/projects/voom/
68
The nature of this stakeholder may not be immediately apparent if the business is focused on delivery
of goods and does not draw attention to the means of delivery, for example Aha in Iceland7.
3.4.1.1.3 UAS operator

A UAM operator is the legal entity, performing one or more UAM operations and is accountable for
those UAM operations. A UAM operation is an air transportation operation that carries passenger
and/or goods. UAM is taken to include the terms delivery drone and Air Taxi, including what EASA
describe as operations type 38. The UAM operator may be a business or an individual or a non-
commercial organization. The UAM operator can have several roles that involve it in different U-space
use case, including but not limited to the planning of flights and their execution.
A UAM operation includes an operation conducted with an unmanned aircraft or with an aircraft with
a pilot on board – the latter is expected to cover the first type of air taxi operations (Operations type
#3 according to EASA terminology9).
3.4.1.1.4 UAS command unit operator

As applicable, the organisation holding a Command Unit Operator Certificate (CUOC) and is responsible
for ensuring that, at any time in its operating life, the Command Unit, including any installed
component, conforms to approved design, specifications and performance, and is in a condition for
safe operation of the certified Unmanned Aircraft. The UAS command unit operator can have several
roles that involve it in different U-space use case.
3.4.1.1.5 UAS manufacturer / type certificate holder

The UAS manufacturer / type certificate holder has an interest in vehicle and equipment certification
processes. The UAS manufacturer or representative may have a role in U-space registration, for
example as the provider of serial numbers.
3.4.1.1.6 U-space Service Provider (USSP)

This stakeholder provides one or more of the U-space services.
Under EU regulation 2021/664 [23] U-space service providers providing services to UAS operators must
offer a minimum set of services but may “resell” services provided by others. Hence USSP can supply
services to each other as well as UAS operators and other aviators.
The CORUS ConOps provided a distinction of USSP into different classes based on a number of criteria.
The EU regulation 2021/664 [23] is not really aligned with these so it is interesting to go over the
scheme in the ConOps to understand what it contained.
7
https://www.aha.is/
8
https://www.easa.europa.eu/domains/civil-drones-rpas/certified-category-civil-drones
9
https://www.easa.europa.eu/domains/civil-drones-rpas/certified-category-civil-drones
69
Name Description Key feature
Principal USSP Service provider mandated by the Provides services that (any of)
state or a delegated authority to [1] are not provided commercially
provide some specific services in
a given geographic area. [2] require some delegated authority
[3] may need to be monopolistic
Operator USSP Traffic management service Provides traffic management services which are
provider whose customers are derived from and/or act on flight data and flights.
UAS operators. A commercial organisation which competes in the
Typically, Operator USSP provide market.
a suite of services.
USSP Traffic management service Provides one or more services to UAS/UAM
provider. A USSP may specialise operators and/or to other USSP. Specialised services
in providing particular service(s), may satisfy a niche market.
either for resale or as an added
value.
Supplemental Provider of data used in UAS Provides data that does not derive from flights, for
data service flight example weather, terrain maps, population density
provider (SDSP)
Infrastructure Provider of infrastructure such as
service provider communications, navigation or
surveillance
Table 17 Different U-space Service Providers
The U-space regulation 2021/664 [23] takes a slightly different approach
The Principle USSP of CORUS combined unique services like provision of Aeronautical Information
coming, together with activities that were inherently unprofitable like recording data to allow accident
investigation. The regulation describes a Common Information Service which provides Aeronautical
Information while recording data becomes an obligation on the commercial USSP as a cost of
operating.
The EU regulation has the same distinction between Operator USSP and USSP but is not explicitly using
these names. Within CORUS the distinction was made explicit. The revised CORUS XUAM ConOps
should consider how the nomenclature can be harmonised and clarify the distinction between the
USSPs providing services to end users (i.e., UAS/UAM operators) and those Service Providers that
provide (partial) U-space services to USSP’s for resale. A mechanism is required that allows certification
of U-space Service Providers that only offer a subset of the services for the sole purpose resale.
The following table maps EU regulation 2021/664 terms to the CORUS ConOps
70
CORUS name 2021/664 name Remarks
Common 2021/664 specifies which services are provided.
Principle USSP Information Service Both foresee that each service has a unique provider and that
Provider this/these provider(s) are appointed by the competent authority.
Operator USSP
USSP No distinction is made
USSP
Supplemental
data service Not mentioned
provider
Infrastructure
Not mentioned
service provider
Table 18 U-space Service Providers
3.4.1.1.7 Common Information Service Provider

In U-space, the CISP is concerned with the provision of the necessary information for the well-
functioning of the ecosystem. Its objective is to ensure that the information comes from trusted
sources and that it is of sufficient quality, integrity and accuracy as well as security so that the USSPs
and other users such as ASNPs can use this information with full reliability when providing their
services.
CISP are responsible for providing horizontal and vertical limits of the U-space airspace, the
requirements for accessing such airspace, a list of available certified USSPs, any adjacent U-space
airspaces, UAS geographical zones and static and dynamic airspace restrictions.
As the CISP is responsible for providing any U-space airspace restriction and requirements of such
airspace, it makes sense to assume that CISP will also provide those airspace restrictions specific from
UAM tailored U-space volumes, such as the activation and de-activation of vertiport corridors or
protecting areas and gather any common information to be provided by USSPs managing UAM traffic,
making it available to all UAM involved actors. Likewise, in the mid-term the provision of tactical
conflict resolution service might be centralised by the CISP, enabling an early implementation of this
service.
3.4.1.1.8 Air Navigation Service Provider (ANSP)

An ANSP is a provider of services to manned aviation. ANSP operate today and the main point of
interest is that U-space will change the way they work introducing new tasks and new tools.
ANSP in this work is a broad term to include all air traffic services and air traffic management. Notably
ANSP includes the airport tower.
In the short term, ANSP’s main responsibility will be to ensure segregation of manned traffic in
controlled U-space airspace from UAS. ANSPs will provide situational awareness information about
surrounding traffic to the users operating in a specific airspace. The ANSP shall coordinate the
interaction between UTM and ATM through the Collaborative Interface with ATC service providing
instructions and clearances when needed.
71
ANSPs are responsible for triggering dynamic airspace restrictions and coordinating through the CIS
with USSPs on potential contingencies and emergencies.
In the case of UAM, ANSPs might need to provide tailored traffic information services and set specific
contingency and emergency protocols with HPVs given their different CNS and flight performance than
those of SPV. Also, as described in Section 4, these vehicles are expected to fly higher, closer to
controlled airspace below VLL, and also at airports.
Likewise, ANSPs will have to coordinate with the Competent Authority the establishment of the new
U-space airspace volumes tailored for UAM, when such volumes are within the airspace under their
responsibility.
Flight Information Flight information service officers or FISO, provide a flight information
Service Officer service (FIS) to any air traffic that requests it, or requires it. FIS is
provided together with ATC service in controlled airspace, but more and
more ANSP’s have dedicated units (FISO) that provide Flight
Information to aircraft in uncontrolled airspace.
The Tower Runway Controller is responsible for the provision of Air

Traffic Services to aircraft within the control zone, or otherwise operating
in the vicinity of controlled aerodromes (unless transferred to Approach
Control/ACC, or to the Tower Ground Controller), by issuing clearances,
instructions and permission to aircraft, vehicles and persons as required
for the safe and efficient flow of traffic. The Tower Runway Controller will
TWR runway/Ground be assisted by arrival, departure and surface management systems,
Control where available.
The Tower Ground Controller is part of the controller team responsible

for providing an Air Traffic Service at controlled aerodromes. His main
task is the provision of ATS to aircraft and vehicles on the maneuvering
area. He must also ensure that airport maintenance vehicles carrying out
necessary improvements on an active maneuvering area do not interfere
with the movement of aircraft.
Table 19 ANSP roles
3.4.1.1.9 Aeronautical Information Management Provider (AIMP)

The AIMP is likewise an existing actor in manned aviation whose tasks and tools will change slightly as
U-space is introduced. Aeronautical Information Management is the task of producing the
Aeronautical Information Publication, a collection of data describing the geography and procedures of
for flying in a given country. UAS Aeronautical Information Management is the equivalent for U-space
and overlaps with AIP with some features in common, though DAIM adds UAS specific information
concerning very low level
3.4.1.1.10 (Airfield/Airport) Aerodrome operator (civil, Military)
72
Aerodrome generalises any size of airfield or airport. The aerodrome operator is distinct from the ANSP
and has business concerns and legal responsibilities which make them interested in / concerned by
UAS flight and U-space procedures.
3.4.1.1.11 Vertiport operator

A vertiport operator will provide services at a vertiport. Service provision might vary between
vertiport for private use and public use. The vertiport operator will contribute to the development of
rules regarding vertiport availability and priority given to specific fleet operators or mission type
(e.g., scheduled operations).
Vertiport operators will be responsible for overseeing ground safety, security and boarding
procedures and charging or refuelling, although this responsibility could sit with fleet operators or
other third parties.
The vertiport operator will provide information regarding the operating status of their vertiport to
various stakeholders through the CIS, including the availability of FATOs, stands (where applicable),
personnel and charging (e.g., electricity).
3.4.1.1.12 Cargo-hub operator

If Vertiports are considered to be passenger airports, then “cargo-hub” is an equivalent term for an
aerodrome providing services to UAS flights carrying cargo. The operator of a cargo hub has the same
responsibilities as a vertiport operator; operating the facility in a safe and efficient manner including
the scheduling of arrivals and departures as well as supplying U-space with information about the
aerodrome’s status and capacity to accommodate incoming aircraft. Generic term to encompass
national or local aviation authority.
3.4.1.1.13 Competent authority

Generic term to encompass national or local civil aviation authority, or some entity delegated by them.
The competent authority 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. The competent authority has a role in regulating U-space.
The Competent Authority will be responsible for certification of all elements that are considered to be
safety related. They certify and oversee the USSPs and the CIS provider(s) with principal place of
business in one of EASA Member States. The Competent Authority will have to certify UAM Operators
and UAS operators (if requested)
Competent Authorities will be responsible for their certification and oversight, as well as, carrying out
the necessary audits, assessments, investigations and inspections as established in their oversight
programme.
3.4.1.1.14 Authority for safety and security (police, fire brigade, search and rescue orgs)
Authorities involved in preparation and supervision of the operations of law enforcement such as
police, security, military, homeland security that are responsible for law enforcement methods.
Publish danger areas in real time – relating to medical evacuation, police helicopter or similar
73
(Police only) Develop law enforcement methods related to illegal UAS use.
3.4.1.1.15 Emergency Responders

Organisations involved in preparation and execution of emergency operations such as fire brigade,
emergency, first aid, Search and Rescue (SAR).
May publish danger areas in real time – relating to medical evacuation, police helicopter or similar
3.4.1.1.16 Local and specific authorities

Local authorities - city / region / prefecture / county / canton / state - support the definition of
operating procedures and rules. They influence applications of U-space to urban needs – for example
active measures limit noise “dose” in any one place, or coordination of transport by ground and air.
Responsibilities:
• Supports the definition of operating procedures and operational rules and limitation
• Explores applications of U-space to urban needs – for example active measures limit noise
“dose” in any one place
• publishing VLL hazards as they arise – cranes, building work, etc.

Specific authorities – harbour / river or waterway / national park / prison / military / … have a similar
role of ensuring U-space and UAS operations are in accordance with the particular activities and
conditions in the region for which they are responsible.
Any authority expects U-space develops methods to support among the others:
Safety assurance
Security and privacy assurance
Enforcement of UAS regulations
publishing VLL hazards as they arise – cranes, building work, …
appropriate and optimal use of UAS in their domain
derive added value from data generated by routine UAS operations
3.4.1.1.17 UAS delivery Clients

The clients of the delivery service have the goods that need to be delivered. They have a business
arrangement with the UAS operator. They may host a UAM Aerodrome, and either be its operator or
have a business arrangement with the operator of the landing site.
3.4.1.1.18 UAS delivery Customers

The customers of UAS delivery receive goods. They benefit from the speed and efficiency of UAS
delivery. They may host a Landing Site, and either be its operator or have a business arrangement with
the operator of the landing site.
Their interaction with U-space will focus on landing-site setup and operation.
3.4.1.1.19 Air-taxi passengers

74
The air-taxi passenger rides in an air taxi. Their interaction with U-space is generally indirect.
3.4.1.2 Roles
3.4.1.2.1 remote pilot

Stakeholder: UAS Operator
The remote pilot is a natural person responsible for safely conducting the flight of one or several UAs
in accordance with applicable rules and regulations and established procedures by operating the
flight controls, either manually or, when the UA flies automatically, by monitoring its course and
remaining able to intervene and change its course at any time.
The remote pilot is licensed and registered in the pilot registry, according to the typology of UAS
used and the type of operation performed.
Remote Pilots make use of services provided immediately prior to and during flight:
Traffic information service

In addition, additional services may be consumed:
Tactical conflict resolution

Emergency management
warnings of other flights in the vicinity which are out of conformance
warnings of changes of airspace availability – for example changes to accommodate
manned aircraft in emergencies
assistance during emergencies
Collaborative interface with ATC
Weather information
Monitoring of infrastructure
Conformance monitoring
The remote pilot uses their own surveillance data and these tactical services to ensure safe and
expeditious operation of the flight.
The state may require the remote pilot to be registered with U-space registration services. This
registration may encompass their training level(s), experience, certification, insurance, and other
personal data. Similarly, depending on the state and the details of the flight, the pilot’s identity may
be recorded in the operation plan. U-space may provide such pilots access to records of previous flight
hours by means of the electronic logbook service.
The remote pilot is always a person working with a machine. The exact division of tasks between the
person and the machine may vary. The whole is referred to as the “UAS pilot function” although
responsibility remains with the human pilot - in general. In the most extreme case, all in flight
information is processed directly by the machine and the human has an oversight function.
UAM vehicles are expected initially to be controlled by a pilot on board. In a next phase, some UAM
vehicles will include a remote, ground-based pilot who is in command of a single or multiple UAM
vehicles once the appropriate standards and certification criteria are defined. At some point, the term
75
pilot may no longer be applicable and other terms such as monitoring pilot or supervisor may be used.
Some UAM vehicles are expected to achieve full autonomy at a point in the future. The UAM
environment will include a mix of piloting mechanism that include onboard pilot and autonomous
operations.
Responsibilities:
Responsible for the safe execution of the flight according to the U-space rules, whatever it is
recreational or professional with one of the different license levels, according to the typology
of the drone used.
In charge to execute the drone flight through the Ground Control Station (GCS)
3.4.1.2.2 UAS Crew

Under the term UAS Crew, the following roles are identified:
Remote pilot is the person manipulating the controls of the UA and is in control of the flight path
either directly or through controlling the on-board automation.
A Visual Observer or UA Observer is a trained and competent person designated by the operator
who, by visual observation of the unmanned aircraft, assists the remote pilot in the safe
conduct of the flight
3.4.1.2.3 UAS operator representative

A person representing a UAS Operator, the operator being registered in operator registry.
The UAS pilot (see above) works for the UAS operator and may be the same person as the UAS operator
representative, but the two are described separately to aid understanding.
Interaction with U-space:
Mission planning. The UAS operator representative is responsible for mission planning, which can
be done manually or supported by automation, whereas the UAS pilot or crew executes it. This
mission planning task includes all pre-flight activities such as SORA if required as well as
obtaining any permits to enter zones or similar.
Receiving tactical warnings that impact the flight and making tactical changes to the operation plan
if needed
Ensuring the flight complies with rules and regulations.
Post flight activities – audits, inquests, etc
The UAS operator representative uses many U-space services in the pre-flight phase including but not
limited to geo-awareness, operation plan preparation, the environmental services: weather,
geospatial information, maps of population density, electromagnetic interference, communication
coverage and navigation coverage.
3.4.1.2.4 ATS Operator

Stakeholder: ANSP
76
ATS should have access to the air-situation generated from e-identification reports, with the usual
controller-working-position tools to filter out those of no interest, give conflict alerts and so on. Main
roles: Air Traffic Controller, Tower Supervisor, Tower Runway controller, Tower Ground controller,
(A)FIS and RIS Operator.
How he/she interacts: User involved to achieve the interface with ATS.
3.4.1.2.5 Police or security agent

Stakeholder: Authority for safety and security
Security actors would be interested in the air situation, to identify operators and to apply relevant
procedures.
Law enforcement Unit, responsible to develop law enforcement methods related to illegal UAS use.
How he/she interacts: User of registration, e-identification and interested in the situational awareness
and monitoring alerts.
3.4.1.2.6 Pilot
Stakeholder: Airspace User
There are two type of pilot roles with regards to U-space:
This is about the pilot on board an aircraft, for a remote pilot, see 5.1.2.1 UAS remote Pilot.
The Pilot on-board is a natural person responsible for safely conducting the flight in accordance with
applicable rules and regulation and established procedures by operating the flight controls, either
manually or, when the aircraft flies automatically, by monitoring its course and remaining able to
intervene and change its course at any time.
The pilot is licensed and registered in the pilot registry, according to the typology of aircraft used and
the type of operation performed.
The rules and procedures under which pilots-on-board can operate in U-space and the way they will
interact with U-space will need to be established.
3.4.1.2.7 Citizen
Stakeholder: The general public
Generic person who wants to be aware of UAS operation for any reason, for example because they
believe UAS are impinging on their privacy.
How he/she interacts: a kind of authorised viewer of air situation and able to report about events.
3.4.1.2.8 Registrar
Stakeholder: Civil Aviation Authority, USSP, agent there-of
77
A registrar has a legal duty to operate a registry securely, reliably and adequately. The registrar will be
a legal person, probably with staff.
How he/she interacts: they maintain the registry and may intervene in case of problems in the
registration.
The registry is accessed by accredited registry updater and Accredited registry reader who respectively
change or read the data.
3.4.1.2.9 UAS Aeronautical Information Manager

Stakeholder: ANSP, AIMP
A body that may be independent of the Aeronautical Information Office and allows UAS specific
aeronautical information to be registered, combines the information, assesses it, and then publishes
the result.
3.4.1.2.10 UAS specific aeronautical information originator

Stakeholder: Authority
The person or representative of the organisation that creates UAS specific aeronautical information.
This actor is accredited and trained in the processes of creating, updating or deleting UAS specific
aeronautical information.
This is reflecting the possibility to have a different originator of “constraints” for UAS.
3.4.1.2.11 Authorised viewer of air situation

Stakeholder: The general public, Aviation User, Civil aviation Authority, UAS Operator, …
This groups actors like U-space operators, city authorities and some others such as researchers who
can be trusted with the commercially sensitivities of the overall air-situation.
How he/she interacts: Who may be allowed to have a situational awareness according to privileges
and privacy.
3.4.1.2.12 USSP Supervisor

Stakeholder: USSP
Being the level of automation high, it is not envisaged the role of “Controller”. Nevertheless, it has
been envisaged a person who will arbitrate or impose a solution in some cases (in case of escalation
required) who may intervene manually imposing ad-hoc solutions or taking over other USSP roles.
3.4.1.2.13 Airspace access authorization Workflow Representative

Stakeholder: Civil Aviation Authority, Local Authority, ANSP, …
A person having the rights to participate in the authorization workflow (e.g., when local
authority/USSP/NAA must express the approval or does not object).
78
3.4.1.2.14 Capacity Authority
Stakeholder: ANSP, USSP, Civil Aviation Authority
A person receiving warning and alerts from the monitoring service
Responsible for setting the minimum safe operating conditions that determine the capacity of an
airspace or an aerodrome due to safety
Responsible for setting noise level limits that limit capacity due to noise footprint and “dose”
3.4.1.2.15 UAS Manufacturer Representative

Stakeholder: UAS Manufacturer / type certificate holder
It is responsible for UAS certification (if appropriate) and supplying registration information and using
the system for all other obligations the UAS manufacturer must comply (e.g., UAS
model/characteristics/performance publication).
3.4.1.2.16 Airport Operator Representative

Stakeholder: Aerodrome Operator
The Airport Operator Representative is responsible for interacting with the system to protect airport
perimeter (counter-UAS) and to contribute to the safe integration of UAS in the airport operations,
including optimisation the use of resources, such as arrival and departure management.
The airport operator will be responsible to establish proper coordination with other relevant
stakeholders.
3.4.1.2.17 Vertiport operator representative

Stakeholder: Vertiport Operator
This role has many of the same high-level interests as the aerodrome operator representative. However,
the details of how these are achieved and the level to which they include U-space will vary.
The vertiport Operator Representative is responsible for operating the vertiport in accordance with
established rules and regulations and optimising those operations including arrival and departure
management to make best use of limited resources like airspace, charging capacity and parking stands.
The vertiport operator will be responsible to establish proper coordination with other relevant
stakeholders.
3.4.1.3 Airport shuttle, Type of aircraft involved

The following classes of aircraft are involved in UAM or operating in nearby airspace:
79
Aircraft EASA UAS ops Pilot on board Use of U- Level of Notes
type Space automation
Classification Services
Manned VFR Yes No None GA, HEMS etc
Manned VFR Yes Yes None - low Integrating manned

aviation in U-space,
advanced U-space
operations
Piloted Type #3 Yes Yes None Initial phase, like

UAM10 helicopter
operations
Piloted UAM Type #3 Yes Yes Yes Initial U-space

operations for UAM
Remote Type #2 No Yes Remotely Advances U-space

piloted UAM piloted, operations for UAM
supported
by
automation
Some flight
phases fully
automated
Remote Type #2 No Yes Remotely

piloted UAS piloted,
supported
by
automation
Table 20 Types of aircraft involved in UAM operations
For the definition of the EASA operation types, see section 3.2.2.1
3.4.2 Airspace stakeholders
10
“Piloted UAM” shall be understood in the table below as “Piloted UAS performing a UAM operation”.
80
This section lists and defines stakeholders which have links with manned operations (e.g., airport,
hospital, police) in the lower airspace that will be impacted by UAM operations. This should be limited
to those operating at low altitude above urban areas, other than in those in the terminal areas of
existing airports.
 Helicopter Emergency Medical Services (possibly assisted by drone(s) in disaster recovery

operation)
 Police
 Journalism, sports coverage
 Photography & filming
 Tourism, sight-seeing (depends on the definition of low altitude)
 Paragliding, hang-gliding, ultralight in some urban areas (e.g., Hármashatárhegyi repülőtér
and Újlaki-hegy in Budapest).
 Special events, public spectacles military parades – ‘Red Bull’ air races, aerobatics, flypasts,
displays
 VFR pilot
3.4.3 UAM Use cases
3.4.3.1 Introduction
This section aims to propose an exhaustive list of the different use cases of operations in U-space which
would potentially be conducted in urban environment. This is introduced over a generic description of
the use case with the type of operation and short description, and a brief description of the U-space
services usage through each phase of one operation, from the organization set up phase to the post-
flight.
3.4.3.2 Operation types overview

Category Description Type Description
Providing point-to-point passenger

Air Taxi transportation, possibly without fixed routes
and/or schedule
Optionally A shuttle service to transport passengers

manned Scheduled between vertiports over fixed routes.
drones with Shuttle
Passengers the Shuttle services to/from/between airports
transportation transportation may involve interactions with other aviation.
of people as Travel to/from the hospital for emergencies
primary Air Ambulance
and potentially hospital visits
purpose
Sight seeing Providing passengers with an aerial view.
Firefighter Quick response firefighting emergencies

Vehicle enabled by air mobility travel
81
Law enforcement individuals enabled by air

Police Vehicle support for daily routine tasks and
emergencies management
UAM aircraft and drones to deliver mail,

Goods delivery
food, and general goods in relatively low
to the public
volumes to a range of destinations.
Goods delivery Delivery of cargo between fixed points.

Unmanned between These deliveries may take-off and land from
drones with business and to UAS aerodrome facilities.
the collection
Movements of
and delivery of Medical/Urgent Delivery of urgently needed medical items
goods
physical delivery and organs between hospitals
objects as only
purpose Aerial Using aerial craft to facilitate warehousing
Warehousing and logistics management
Deliver legal/business documents, replacing

Intra-company
inter office mail and traditional courier
goods delivery
services
Mapping based on photogrammetry and

Mapping
classification of the imagery.
Photogrammetry to assess stocks of building

Survey
materials stocked in heaps: sand, gravel, etc.
Detection of & Diagnosis of the status of

Archeology &
historical sites through acquisition of
Unmanned Heritage
information via drones the aim is to create a
drones with mapping
Visual and digital map.
the collection
data Inspection and 3D mapping of
or streaming Infrastructure
acquisition infrastructures (e.g., railway lines, oil & gas
of data as only mapping and
purpose etc.) including detection of potential
inspection
hazards.
Weather Monitoring of atmospheric pressure and

monitoring climate conditions to help weather forecasts
Periodical/recurrent monitoring of
Inspections of
structures, for example bridges, towers,
structures
wind turbines, cranes.
82
Inspections of Inspection of remote and dangerous areas

dangerous areas reducing people involvement and costs
Search and Use drones to help in searching activities for

rescue of missing people or fugitives
missing people
Land, sea and Monitor and control traffic situation on land,

air traffic in harbors, on waterways, at sea and in the
control air
Substituting land patrolling activities with

Security
drones capable of patrolling wider areas
Patrolling
with lower risks
Crowd events Crowd monitoring during large events to

surveillance detect or monitor emergency situations
Photos & Videos Aerial filming and photography
Data collection to support advertising

Advertising tech activities (e.g., shopping windows, queue
analysis)
Exploration of touristic areas from home

Virtual Tourism
thanks to virtual reality
use of drones for newsgathering purposes.

Drone photos and videos allow journalists to
Journalism
make their reports more insightful and
innovative.
Support emergency situations with medical

First emergency and other professional tools (e.g.,
Unmanned support defibrillator) outside of the hospital
drones perimeter
performing
physical Anti-drone Use drones to monitor and intervene in case
Aerial Work solutions of unauthorized UAS activities
interactions
with the world Remote medical Reach remote areas to visit patients who
around them visits can’t move from their location
while in-flight
Reaching less accessible farmland for
Harvesting
planting, harvesting, potable water
83
Crime fighting Intervene in case of criminal activities with

law-enforcement tools
Active support of firefighting activities using
Firefighting
dedicated pumps (e.g., water spraying)
Landscaping/gar Assist gardening activities with drones to

dening reach higher areas reducing risks for people
Replacement of trash trucks, hazardous

Trash collection
waste disposal11
Cable Installation of cables in difficult to reach

installation areas
Anti-icing Replacing winter snowplow and salt trucks

measures
Use drones for decontamination of areas

Pest control
from parasites and insects
Use of drones as flying billboards for

Flying billboards
advertising
Table 21 List of operation types in urban environment
3.4.3.3 UAM Operation Lifecycle

Pre-operational phase: any general pre-operational activities related to the management of UAM and
independently to the single flight: there are encompassing registration, publication of UAM corridor,
operational of UAM.
Generic steps for the phase:
Registering / obtaining approval as operator (UAM Operator, CAA)

Registering aircraft
Establish UAM Corridor if necessary (USSP, ANSP, UAM Operator, Cities, Vertiport operator, Civil
Aviation Authority)
Including validation / approval by CAA
Publication of new airspace structure in AIP
Publication of Arrival/Departure/Holding procedures for each vertiport in AIP
Establish contractual agreements between involved parties:
Including agreeing between USSP, ANSP, Vertiports.
11
This use case requires carriage capability which is clearly not expected in short or mid terms
84
Establishing agreements with the city, (public) transportation systems, citizens, etc.
Establishing/offering booking access (App, Ticket store, etc.)

Pre-flight: Any activity related to the preparation of the individual flight prior to departure, including
vehicle pre-flight checks, vehicle charging, flight planning, boarding passengers and/or cargo.
Flight planning
Obtain weather information
Submission of request
Conflict free check
Authorisation provision (if required)
Pre-Flight info (e.g., weather info, NOTAM)
Pre-flight briefing
Flight acceptance
Availability of the vertiports
Preparing vehicle for flight (no U-Space services involved, unless flight is cancelled)
Vehicle Pre-flight check
Vehicle charging and / or fuelling
Boarding passengers and/or cargo (no U-space services involved)
Perform final Pre-flight checklist --> ready to fly
Take-off: the period in which the UAM vehicle physically departs from the location A (Vertiport, stand,
runway, airfield, etc.) up to the point at which it reaches cruise altitude. Departure includes taxi, take-
off and initial climb.
Obtain clearance to moving to take-off area (if needed)

Obtain take-off clearance, when applicable
Take-off from vertiport / operating site / airfield
Enter the UAM corridor if one has been set or enter U-space airspace
En-route: The point at which the vehicle reaches cruise altitude up to the point at which it begins the
approach to the destination location/point (Vertiport, stand, runway, airfield, etc.).
Fly according to the flight plan

Execute conflict resolution instructions
Obtain real time weather information
Informing passengers about journey (e.g., weather, ETA, changes, delays) or customer waiting for
a cargo delivery.
Approach: the period between the UAM vehicle aligning with the optimal track to the assigned
destination and reaching the decision point (or decision altitude/flight). Descent is expected to occur
within this phase. The UAM pilot will elect to either continue or land or climb to a safe manoeuvring
altitude (executing a missed approach).
85
Confirm landing area is free from conflicts

Execute approach procedures in case of uncontrolled airfield
Request clearance in case of controlled airfield
Execute conflict resolution instructions
Landing: the point at which the decision is made to continue to the destination from the decision point
(or decision altitude/height) until the UAM vehicle lands.
Execute landing procedures,

Execute conflict resolution instructions.
Post flight: the period after the UAM vehicle stops moving, the flight closes and securing the vehicle
commence. Post flight activities typically includes de-boarding passengers and/or cargo and vehicle
servicing activities.
Confirm landing
Perform post-flight check list
Disembarking passengers and/or cargo
Figure 8 Flight phases representation [38]
86
Figure 9: Overview of the UAS Operation lifecycle phases and associated activities
87
3.4.3.4 Use cases in nominal situation and linked U-space services
The table attached shows the use of the U-space services throughout the operation.
CORUS XUAM
U-space services.xlsx
For graphical use case diagrams of the U-space services, see Appendix B.
3.5 Ground environment

The development and implementation of urban air mobility operations requires a holistic
understanding of the ground environment. Introducing new mobility solutions into cities, offer many
opportunities and benefits to citizens, but also brings challenges that need to be faced and addressed.
This chapter will first look into the aspects to be considered when entering the urban environment,
and how UAM can not only be introduced, but also well integrated into the existing transport network
and city landscape. Subsequently, the challenges – weather conditions, noise and privacy constraints
- stemming from operations in urban zones will be elaborated upon. Later on, the ground
infrastructure will be addressed; this is a critical element/enabler of UAM operations to be scaled-up.
This chapter concentrates on take-off and landing segments, as the ‘en-route’ infrastructure is
presented in chapter 3.9
3.5.1 General considerations and challenges

Urban Air Mobility imposes challenging conditions on the planning and the actual execution of the
UAM operation itself when operated in an urban environment. A non-exhaustive overview of general
considerations and challenges is provided in this chapter, including but not limited to the discussions
about the lack of a definition of the term “urban” that distinctly describes the system boundary of
UAM, urban obstacle scenery and weather peculiarities, as well as the overall integration of UAM into
the city landscape, the existing public transport network, and into society in general considering noise
and privacy issues.
3.5.1.1 Definition of “urban”

Since the word "urban" (from the latin “urbs/urbis” – city) is part of the initialisation "UAM",
understanding what a city is, which areas are urban and which are rural, what a commuting zone for
a city is, etc. is crucial for the development of UAM operations. The French National Institute of
Statistics and Economic Studies (INSEE) provides the following definition for urban areas [40]:
A "[large] urban area" is a group of touching municipalities, without pockets of clear land,
encompassing an urban centre (urban unit) providing at least 10,000 jobs, and by rural districts or an
urban unit (urban periphery) among which at least 40% of [the] employed resident population works
in the centre or in the municipalities [drawn to] this centre.
The 2010 zoning of urban areas distinguishes between:
88
 "Average[-sized] areas", a group of municipalities, without pockets of clear land, constituted
by a centre [with] from 5,000 to 10,000 jobs, and by rural districts or urban units among
which at least 40% of the [the] employed resident population works in the centre or in the
municipalities which are [drawn to] this centre.
 "Small areas" [are] a group of municipalities, without pockets of clear land, constituted by a
centre [with] from 1,500 to 5,000 jobs, and by rural districts or urban units among which at
least 40% of the [the] employed resident population works in the centre or in the
municipalities [drawn to] this centre.
The Directorate-General for Regional and Urban Policy of the European Commission, together with
the Organisation for Economic Co-operation and Development (OECD) gave definitions of “urban” and
“rural” in a short 2012 paper [41]. A 2019 working paper [42] defined detailed algorithms for
identifying many more typologies of functional urban areas, encompassing their economic and
functional extent based on daily population movement patterns; a crucial input to UAM.
In 2014, the EU and the OECD issued a working paper [43], which went into force in March 2020 [44]
et [45], defining new degrees of urbanisation. On a finer scale, cadastral maps record categories of all
real estate, such as warehouse, trade, cultural, hospitality, industrial, sports, no-use, offices, historical,
religious, shows, residential, and health. Similar to the functional urban areas, these categories help
understand where people are located as a function of the time of the day. This is important in UAM
for at least two reasons:
(1) defining transport demand and
(2) estimating the ground risk of urban flights (see below).
Cadastral maps are generally publicly available. However, they are usually only available in the
national language and have different interfaces.
A consolidated definition needs to be defined within the U-space community.
3.5.2 Obstacle scenery
Terrain is a natural obstacle that any aircraft operation must consider. Planning a flight following a
constant height above ground level (AGL) is a difficult task if there is a complicated terrain profile (see
blue profile on the left of Figure 10). On the contrary, maintaining the same altitude above mean sea
level (AMSL) may be impossible for the entire duration of the mission because of terrain relief (see
red profile on the right of Figure 10). In the case of urban areas, a complex obstacle scenery will make
the flight- planning task even more complex.
Figure 10 Neither AGL nor MSL alone will work everywhere [48]
89
Moreover, according to Commission Implementing Regulation (EU) 2019/947 [17] section
UAS.OPEN.010, any unmanned aircraft operating within the open category “shall be maintained
within 120 metres of the closest point on the surface of the earth”, except when flying within 50m
from an artificial obstacle more than 105m tall, where it may fly up to 15m above the obstacle (if
requested by the person/organisation responsible for the obstacle). The same maximum height of
120m is specified also for both STS’s and 2 out of 4 PDRA’s (see Tables 1 and 2 of GM1 to AMC1 Article
11 Rules for conducting an operational risk assessment). The Part A of the annex adds that “the
measurement of distances shall be adapted accordingly to the geographical characteristics of the
terrain, such as plains, hills, mountains.” The obstacle scenery of UAM flights can change significantly
if we compare different cities in different countries.
As presented in sections 5.1.3 and 5.3, the typical use cases (passenger transport, delivery and
inspection work) flying under such height restrictions will need to face natural obstacles and terrain,
especially in the case of UAM, with many artificial obstacles, as can be seen in any European city
skyline. To reduce risk, the Commission Delegated Regulation (EU) 2019/945 [28] also mandates that
the vehicles shall be “equipped with a geo-awareness system that provides an interface to load and
update data containing information on airspace limitations related to UA position and altitude
imposed by the geographical zones”.
In consequence, the terrain profile is a vital piece of information for U-space. Care must be taken,
however, to ensure coherent altitude measurement in different parts of the urban area, in which other
airspace users may also be present. Below 5,000ft, manned aircraft traditionally use barometric height
that provides an altitude based on the difference between the air pressure where the aircraft is
compared with that measured at a reference point of known altitude on the ground, using a standard
atmospheric model. UAS generally use a value provided by a satellite navigation related to the WGS84
ellipsoid, often translated so that the take-off point is considered to be zero height.
Digital terrain models (DTM) that provide altitudes for the bare ground, and digital surface models
(DSM) that provide altitudes for the surface including buildings, vegetation etc., can be based on
ETRS89, WGS84, using different geoid corrections or not, etc. Height itself can be defined by
orthometric or ellipsoidal means. The difference between these comes from the reference system,
which can be a geoid (which is based on the Earth’s gravity) or an ellipsoid (a mathematical
simplification of the geoid). Figure 11 shows an example of this and also includes the terrain, which can
be above - this is the general case- or below the reference. Conventional aviation estimates their
altitude from the orthometric height using atmospheric pressure, while UAs navigate using the WGS84
ellipsoid as the reference for their altitude.
90
Figure 11 Height and altitude references (figures 2 of CORUS ConOps [4])
There is obviously a need for a common frame of reference for height, and this issue was identified as
early as the 1st CORUS Exploratory Workshop [46] . The EASA/EUROCONTROL discussion document
[47] on defining a common altitude reference system (CARS) explored the different ways of measuring
height and concluded that no on-board altimetry system was sufficiently accurate, therefore, U-space
must step in to help define the altitude/height of flights. The preferred solution among the potential
ones studied was that each airspace user should use the approved altimetry system best suited to the
aircraft, airspace, or certification requirements, and that U-space functionalities should be used to
translate these to a common reference. This is currently the subject of the ICARUS SESAR ER4 project.
While some initial work on using U-space for CARS has been undertaken[48], the issue is far from
being resolved and is also discussed in the "Airspace” section (see chapter 7).
In summary, since UAM ground infrastructure will mostly be placed within city boundaries with
densely populated and built-up areas, the UAM operating environment will be small in space and great
in complexity. UAM faces more complicated obstacle geometries more frequently than conventional
fixed-wing aviation does due to proximity to the ground and smaller spatial scales. Firstly, the UAM
operating environment is filled with various types of constraints: terrain and buildings, special flight
rules areas and temporary flight restrictions, airport procedures, etc.[49] . Secondly, the impact on,
and the rights of, inhabitants must be considered.
3.5.2.1 Urban weather

Low altitudes over densely populated and built-up areas are complex operating environments for
aircraft in terms of obstacles and corresponding regulations, but also face different weather
phenomena compared with those usually experienced by aviation. The World Meteorological
Organization (WMO) defines an urban climate as a "local climate that differs from its surrounding
climate due to effect of buildings and emissions". […] The urban heat island is a typical feature of the
urban climate. It is characterised by a difference in temperature between the hotter city and its cooler
surrounding countryside and reaches its maximum in very sunny and low wind weather conditions.
This difference can be as much as 10 Kelvin in large cities” [50].
According to[50], additional variations can be seen in air humidity, radiation, wind, noise emissions
and air. The overall structure of the city including but not limited to the characteristics of the buildings
(geometry, substance, facing), domestic heating, public/individual traffic and industry are main
contributors to urban climate. Comparing an eVTOL e.g., a Volocopter 2X with a maximum take-off
mass of 450 kg [52] with a helicopter e.g., an Airbus H160 with a maximum take-off mass of 6,050 kg
[53], UAM eVTOL vehicles are not only much lighter, but are also at higher risk of being affected by
the weather specifics caused by the urban environment. Rapidly changing weather conditions,
potentially (hazardous) wind flow around buildings/vertiports and the appearance of micro-weather
can challenge the feasibility of UAM operations at anytime. Furthermore, [VTOL_steiner] highlights
regional and seasonal wind variations, gusts, and turbulences within and above cities as challenges for
ground and air operations.
The extent to which specific and rapidly changing weather conditions degrade operating hours needs
to be evaluated for every operating environment and the European UAM market in general The report
‘An Assessment of the Potential Weather Barriers of Urban Air Mobility (UAM)’ by [54] investigated
the average number of weather-impacted hours for target American urban areasconsidering amongst
others New York, Miami, Dallas, Denver and San Francisco. It concluded that an average of 6.1
hours/day during the winter, 7.3 hours/day in the spring, 2.9 hours/day in summer and 2.2 hours/day
in the fall wereaffected by unsuitable weather conditions. Thus, the greatest number of hours per day
affected by weather come during the winter and spring seasons [54].
91
To define operational limits and procedures on how to react to specific weather conditions, we first
need to know in detail what we are going to face which requires comprehensive weather data
collection in urban areas and at low altitudes. “It is recognised that the weather information for UAS
operations may be different from the one provided by today’s meteorological service providers; in
particular, as regards support of operations under the ‘open’ and ‘specific’ categories. UAS can fly near
buildings and in areas where current aeronautical meteorological information is not always provided.”
[55]
More information is needed regarding winds at ground level and above ground level (turbulent eddies,
extreme and rapid changes in wind speed/ direction, micro-burst translation), temperature (heat
island effect, effects on density altitudes), icing, turbulences and thermals [56].
The vertiport, an independent infrastructure component but an active part of U-space, can be one of
the weather data collectors providing essential and continuous weather surveys of the vertiport and
its vicinity to the U-space community. Additionally, each UAS (e.g., air taxi) can contribute to the data
collection during its operation, which enhances the baseline for complex studies of urban weather
phenomena. It is necessary to understand the operating environment of a UAS better, to always
ensure safe operations and to improve the overall planning process by reducing uncertainties.
3.5.2.2 UAM integration

UAM being introduced into metropolitan areas can either compete with or complement existing
public transport modes and networks. The way of integrating a new mode of transport will influence
and shape their future acceptance by the public. There is a difference between new transport modes
connected to and harmonised with public transport modes such as metros, trams and busses,
completing the existing network, extending the network’s range and offering greater public access,
and an additional transport option that only serves selected customers at specific locations during
specific and maybe personalised operating times.
EASA’s study on social acceptance of UAM [57] showed that an “insufficient integration into the
existing transport ecosystem of the city (i.e., UAM just adding another layer of transport congestion)”,
is one additional concern of the stakeholders interviewed. The survey concludes with the statement
that “UAM services need to be integrated into the existing local mobility system. Visual impact of
aircraft and infrastructure should be limited, and city landscapes preserved” [57].
Following the insights of EASA’s study [57] and the trend towards multi/intermodal city transport
behaviour (e-scooters, bike, bus, tram, subway, underground, taxi, car-sharing, etc.) UAM operations
and infrastructure need to support the European transport policy which aims for “a form of mobility
that is sustainable, energy-efficient and respectful of the environment. These goals can be achieved
by using multimodal transport that combines optimally the various modes of transport, exploiting
each one’s strength and minimising the weaknesses. The European Commission hence pursues a
policy of multimodality by ensuring better integration of the transport modes and establishing
interoperability at all levels of the transport system.”[58]
Therefore, UAM operations need to be integrated rather than isolated and cover transport segments
in need by decreasing travel time, offering additional transport capacity, etc.
UAM’s innovation potential may be easiest to exploit in cases where urban air travel provides
significant time savings compared to the current ground-based journeys. One exemplary metric which
could evaluate the adequacy of a mode of transport is the stretch factor which is introduced by [59].
According to [59], the stretch factor of a network is defined as:
92
�㕑�㕖�㕠�㕡�㕎�㕛�㕐�㕒(�㕠, �㕡)
�㕠�㕡�㕟�㕒�㕡�㕐ℎ = �㕓(�㕠, �㕡) =
|�㕠�㕡|
�㕠 = �㕝�㕜�㕖�㕛�㕡 �㕜�㕓 �㕜�㕟�㕖�㕔�㕖�㕛

�㕡 = �㕝�㕜�㕖�㕛�㕡 �㕜�㕓 �㕑�㕒�㕠�㕡�㕖�㕛�㕎�㕡�㕖�㕜�㕛
�㕑�㕖�㕠�㕡�㕎�㕛�㕐�㕒(�㕠, �㕡) = �㕠ℎ�㕜�㕟�㕡�㕒�㕠 �㕑�㕖�㕠�㕡�㕎�㕛�㕐�㕒 �㕏�㕒�㕡�㕤�㕒�㕒�㕛 �㕠 �㕎�㕛�㕑 �㕡 �㕎�㕙�㕜�㕛�㕔 �㕡ℎ�㕒 �㕛�㕒�㕡�㕤�㕜�㕟�㕘
|�㕠�㕡| = �㔸�㕢�㕐�㕙�㕖�㕑�㕒�㕎�㕛 �㕑�㕖�㕠�㕡�㕎�㕛�㕐�㕒 �㕏�㕒�㕡�㕤�㕒�㕒�㕛 �㕠 �㕎�㕛�㕑 �㕡
(�㕑�㕢�㕒 �㕡�㕜 �㕠�㕐�㕎�㕙�㕒 �㕜�㕓 �㕜�㕢�㕟 �㕐�㕖�㕡�㕖�㕒�㕠, �㕒�㕎�㕟�㕡ℎ �㕠 �㕐�㕢�㕟�㕣�㕎�㕡�㕢�㕟�㕒 �㕐�㕎�㕛 �㕏�㕒 �㕛�㕒�㕔�㕙�㕒�㕐�㕡�㕒�㕑)
As an alternative to distance, travel time, fuel/energy cost, environmental impact etc. may be
considered for both ground and air transport to define the stretch factor, e.g., the UAM path may be
confined to the airspace available for UAM operations (see [59] and the “Airspace” chapter 7). UAM
trips would be most competitive on origin-destination journeys having a high stretch factor by other
means of transport.
Even though UAM describes a mode of transport that operates in the air, it needs supporting
infrastructure on the ground to offer future customers access to UAM services in general. Therefore,
ground infrastructure needs to be sized, designed, developed and placed with respect to the urban
environment, the projected demand characteristic and the needs and expectations of the city and
local residents.
The right design and placing of future UAM ground infrastructure is necessary on the one hand to
provide convenient access and to blend into the urban scenery respecting public requirements, and
on the other hand to live up to the requirements defined by the UAM operating procedures in the air
and on the ground to provide an operation that is as safe but also as cost-efficient as possible.
A vertiport place on top of or next to existing transport network junctions (bus stations, train stations,
etc.) would offer a secure and continuous demand stream, but often, these locations suffer already
from noise, lack of parking spots, large numbers of busy people nearby, and in general increased traffic
densities on the ground. The extent to which an additional UAM operation is going to add value to or
instead amplifies the congestion of such a traffic junction needs to be analysed precisely for every
vertiport use- case.
To “preserve city landscapes” [57], vertiports can make use of existing infrastructure (parking garages,
train station buildings, rooftops, etc.) but can also function as a new attraction/ and highlight in the
city landscape by developing a modern and sustainable design including e.g. entertainment
opportunities, restaurants, stores, public meeting and relaxation areas etc. Both ways need for a
vertiport design in harmony with the characteristics of the city that considers all the requirements of
the surrounding neighbourhood.
From an operational point of view, the siting of the vertiport not only needs to offer a free operating
environment to maintain safe operations on the ground and in air , but it does also needs to offer
sufficient access to one or several energy sources (electricity, liquid natural gas, hydrogen, fuel, etc.)
depending on the vehicle fleet operating and being charged/fuelled at the vertiport. Upgrading
existing infrastructure with a vertiport, e.g., placing it on top, requires a detailed assessment of the
refuelling/recharging capacity offered by the existing connection and the extent to which the city grid
is capable of dealing with additional “UAM consumers”. Furthermore, this needs to be compared to
the projected demand for the given vertiport to assess the actual value of UAM at this location. If the
building of new infrastructure is considered, the construction of new vertiport-site power plants, or
an extension of the energy grid needs to be discussed as part of the vertiport planning process. How
different energy sources will influence the cost/size of a vertiport and how refuelling/recharging of a
93
UAM vehicle can be guaranteed at a vertiport, was, for example, part of the research conducted in
[60] .
A vertiport may feature several final approach and take-off areas (FATOs), gates, parking positions,
taxiway systems, may be elevated and may even offer entertainment and shopping areas for
passengers. Developing future vertiport designs and procedures also involve the evaluation of the
surrounding area and its 3-D characteristic to make sure a vertiport respects take-off and landing
slopes with acceptable safety margins;[61]
By providing the second publication of the MOC-SC-VTOL [83], EASA elaborated an approach in order
to define the airspace volume required for take-off and landing operations of VTOL aircrafts at
vertiports:
Figure 12 3D view of the VTOL take-off and landing volume based on reference volume [83]
Knowing the geometry and composition of rooves is also important to understanding which rooftops
may support emergency landings. On the ground next to alternate vertiports, open water and
unpopulated areas should also be identified for possible rerouting of dysfunctional unmanned aircraft.
Information about the extent of these areas, as well as the vegetation present (grass, trees, flammable
or not), is also essential.
In conclusion, the goal of the European Commission [58] which emphasises the importance of future
transport modes to meet the concept of multimodality, should be the key driver during the planning
and implementation phase for UAM operations in metropolitan areas and cities. Following this
approach, UAM needs to be harmonised with existing public transport modes and networks, must be
made interoperable (e.g., single ticketing) and UAM operations need to achieve a high degree of
punctuality to offer a smooth transition to other modes. The coordination with exiting transport
modes requires wise vertiport siting, including but not limited to the requirements of the city and its
residents’, a free and safe operating environment on the ground and in the air, sufficient access to
energy, that offers convenient access for customers and is either retrofitted or a new public area that
blends into the city landscape.
Details on various sizes of vertiports (ranging from 1-2 landing pads to >10 pads) are for instance
discussed in the UAM ground infrastructure section in the recent EASA survey on public acceptance
of UAM [57], where ease of access and connection to the electricity infrastructure are identified as
94
important factors for vertiport location (see CURAM research at Georgia Tech for recharging schedule
and electricity costs). EASA’s RMT.0230 working group on vertiports is working on technical
specifications for VFR vertiports.
3.5.2.3 Noise
The decibel (dB) is the unit of measurement for sound levels. It is used in the fields of communication,
electronics and signals, but is mostly relevant for industries that have equipment that generate noise.
Noise is very subjective, its perception changes from individual to individual, and also annoyance is
also affected by the environment and the person’s age. Since it covers the entire audible spectrum
from around 20Hz to up to 20kHz, we apply filters to it when measuring it so that we only measure
those parts of the spectrum that concern us. Typically, mid-range filter (measured in dBA) is used to
provide objective values of noise.
In addition to the noise level, the exposure time and the area/population affected by noise are also
important in an urban environment. Noise is therefore measured using different indicators: long-term
average noise level (Leq), the percentage of time noise exceeded the background noise level n or any
other specified n (Ln), the area affected by noise above ndB (An), the population affected by noise
above ndB (Pn), etc.
Similarly, visual pollution from UAM may also be assessed, in particular due to security and privacy
concerns that UAM may raise. The effect of both acoustic and non-acoustic factors may be
represented using Community Tolerance Level (CTL) [62] (Fig. 14) which is in turn based on the seminal
study of dose-response by Schultz [63]. For recent results see “Initial Investigation into the
Psychoacoustic Properties of Small Unmanned Aerial System Noise” [64] by Andrew Christian and
Randolph Cabel from NASA Langley Research Center which used NASA tools to show linear
dependence between sound pressure and annoyance from drones, as well as that drones noise is
perceived as systematically slightly more annoying than that of cars (the study was performed in
NASA's room, where the subjects did not see where the sound came from).
Figure 13 (Fig.2 in [62]: CTL value computed from the findings of six surveys of communities exposed to aircraft
noise. Note that CTL values for the different communities shown vary over a range of 30 dB
3.5.2.4 Privacy
A person’s privacy is a fundamental right according to European Union regulation (2000/C 364/01).
Although privacy can have different interpretations and regulations in different countries, European
Regulation 2016/679, known as GDPR, has helped to homogenize the understanding and treatment
of private data across Europe. Personal data handling must carefully follow strict rules that define
what personal data is, how to collect it, what to do with incidental data collection and how to use,
store and disclose personal data.
95
Privacy was the major public concern in earlier surveys on social perception of unmanned aircraft. At
that time most of the missions proposed were attached to surveillance, such as search, rescue or
firefighting, agriculture aerial work, etc. The new urban applications for unmanned aircraft (UAM) are
basically passenger transport and last-mile delivery. Although the ground environment of these
applications is, of course, urban or suburban areas, characterised by the density of people and
habitations, recent public surveys do not show privacy as being the main public concern anymore[57].
In addition to the new European regulation, the reasons for this evolution can be diverse. Firstly, the
flight profiles for UAM (point-to-point direct routes) are very different from (non -UAM) surveillance
flights, where long periods of hovering, or surveys that stayed in the same area for a long time, made
the nearby inhabitants wary of the intrusion.
Secondly, in UAM the on-board payload are passengers and/or cargo, instead of the required camera
of most aerial work. Of course, a camera can still be on board UAM vehicles for obstacle avoidance or
for landing purposes. But most survey work is carried out by recording the ground, while UAM will use
cameras only for live monitoring. This difference is well stated in the current privacy regulation that
applies to video and images in which people appear. When recorded, the images must be stored in
such a way that unauthorised access is prevented, explicit consent for data storage and usage is
required from the persons being recorded and misuse apart from the announced primary function is
subject to liability.
Finally, today’s cities are full of cameras: at bank offices, in private buildings, in public transport, in
many stores, on the street to observe road traffic, to fine cars not observing the rules, even in
elevators. These cameras are mainly there for security reasons and citizens in high-density populations
have learned to live surrounded by them, sometimes even requesting more coverage of some “dark
areas”. As said, the strong European GDPR legislation seems to be part of people’s relaxation about
privacy.
Along the same lines, the authorities point out that UAM and U-space must develop methods to
ensure the privacy of citizens. U-space design, and services, such as geo-awareness, must, take into
account safety, security, privacy and environmental requirements in accordance with Implementing
Regulation (EU) 2019/947.
Of course, liability applies to any drone operator who violates privacy (e.g., a drone flying over houses
with a camera, taking pictures or filming private gardens and buildings where people can be
identifiable). The European “Drone Rules” project has published good practices for drones operations
[65]. The recommendations are based on the belief that it is the drones industry that must be
proactive and act to minimise these risks, while the institutions must make them aware of their
responsibilities.
Not all information collected by a drone will qualify as personal information. Personal information is
any information about a person who is or can be reasonably identified. Actions must be taken in
advance (privacy by design, contacting and informing neighbours about the purpose of any filming,
etc), during the flight (making the pilot visible and identifiable, filming in the contrary direction of
habitations, etc...) and after flight (eliminating or blurring images with recognisable individuals [66] ).
3.5.3 UAM ground infrastructure

UAM ground infrastructure provides accessibility to UAM services and is the key supporting element
of UAM for accommodating airside and landside operations and plays a mandatory part in the U-space
framework. It defines what kinds of operations can be conducted (passenger transport, small/cargo
96
UAS), how many and what kinds of passenger/cargo can be processed and what kinds of vehicle are
able to operate.
In this operational framework, a difference is understood between the following terms:
Vertiport - take-off and landing site used by passenger carrying VTOLs or other VTOLs certified in
accordance with Special Condition (SC) VTOL
Following the definition provided by EASA SC VTOL, vertiport means an area of land,
water, or structure used or intended to be used for the landing and take-off of VTOL
aircraft.
Take-off and landing sites used by delivery UAS.
The reason behind distinguishing between take-off and landing sites for passenger carrying VTOLs and
for delivery UAS, is that for the latter there are not yet any defined requirements on the landing sites
to be used, and we can assume more flexible usage of pre-defined or ad-hoc Final Approach and Take-
off areas (FATOs) for that purpose (e.g., in a garden, on a balcony, etc.). At the same time, as per SC
VTOL, passenger carrying aircraft are required to use vertiports, on which EASA is currently working
on defining design specifications.
3.5.3.1 Ground infrastructure for Cargo UAS (operating sites)

If we are considering a significant number of drone activities in metropolitan areas and cities including
but not limited to parcel delivery, food delivery, transplant/ blood sample transport, “HEMS” and
police surveillance etc., for most of the operations we need a suitable take-off and landing area which
can probably vary between a high-traffic drone hub and a single landing area in someone’s garden.
Most European city centres include high- rise buildings with several living quarters, where multiple
households share a mutual entrance. In addition, not every household has a garden, private balcony,
driveway or direct access to a private rooftop which makes it challenging to forecast how delivery
drones will actually operate within an urban environment. One reasonable approach could be to
implement take-off and landing sites for delivery UAS at points of interest within a neighbourhood, a
district, or a city centre, which can be made accessible to everybody after registration. For postal
services, DHL already provides this option with their “DHL Packstation”. Something similar could be
possible for UAS deliveries, where it is no longer the postman , but UAS that safely delivers each parcel
to the station (examples provided in Figure 146, Figure 157 and Figure 168.
Figure 14 Drone Station by DHL in collaboration with E-Hang [68]
97
Figure 15 Drone Delivery hub for hospitals [69]
Figure 16 Drone Delivery Station for Parcels [70]
Another approach to allow drones to deliver parcels in the city is to retrofit rooftops which then allows
the tenant to directly receive the package in their apartment. Only tenants of the apartment unit right
under the roof would qualify for this kind of parcel delivery. Changing weather conditions (rain, snow,
etc.) need to be considered for this kind of operations. Examples are provided in Figure 17 and Figure
18.
98
Figure 17 Roof Terrace for drone deliveries [71]
Figure 18 Roof Delivery [72]
If drone deliveries are scaled up and high-throughput operations are considered, the starting site,
where delivery drones are equipped with the parcel and then take-off to the destination
address/landing site may be pictured as delivery hubs.
99
Figure 19Urban Drone port [73]
Figure 20 multi-level fulfilment centre [78]
3.5.3.2 Ground infrastructure for passenger- carrying VTOLs

For passenger carrying VTOLs, either existing or new infrastructure could be used:
1) Existing infrastructure
100
Heliports - VTOL capable aircraft dimensions and performances meet the design characteristics of
the heliport intended to be used.
Airports - where runways, ramps of hangars, or manoeuvring areas, terminal rooftops could be
used.
2) New infrastructure:
Vertiports are specially designed to be used for the landing and take-off of passenger and cargo
VTOL aircraft.
Before the distinction between different vertiports is presented, two categories of VTOLs are defined
[76]:
1) Enhanced category: VTOL aircraft certified in this category would have to meet
requirements for continued safe flight and landing and be able to continue to the original
intended destination or a suitable alternate vertiport after a failure.
2) Basic category: For VTOL aircraft certified in this category, only controlled emergency
landing requirements would have to be met, in a similar manner to a controlled glide or
autorotation.
When considering vertiports for passenger VTOL aircraft operations, EASA distinguishes between
different kinds of vertiports Figure 21[77].
As per EASA SC VTOL [76], VTOL aircraft certified in the enhanced category, need to satisfy the
requirement of continued safe flight and landing (CSFL) and hence be able to continue to the original
intended destination or a suitable alternate vertiport after a failure [76] This enhanced category of
VTOLs covers those aircraft that carry passengers on board.
Figure 21 Vertiport classification from operations perspective [76]
services required for the operation, that the VTOL vehicle can take-off from. The blue circles are
vertiports for CSFL, that only have a minimum set of facilities and services (to be specified), from which
the VTOLs may not be able to take off. For cargo UAS and small UAS operations all operating sites can
be used.
101
 Alternative vertiport: An alternative vertiport is pre-planned and chosen in case it becomes
either impossible or inadvisable to proceed to or to land at the intended destination vertiport.
This can be either an alternative take-off vertiport, where the VTOL aircraft would be able to
land should this become necessary shortly after take-off, or an alternative en-route vertiport,
where the VTOL aircraft would be able to land if a diversion becomes necessary with normal
aircraft performance while en-route, or an alternative destination vertiport, where the VTOL
aircraft would be able to land should it become either impossible or inadvisable to land at the
intended destination vertiport.
 Alternative en-route vertiports for CSFL: The alternative en-route vertiport for CSFL complies
with the same minimum design requirements as the alternative en route vertiport. But it only
has to fulfil a minimum set of services with respect to the aircraft and CSFL operations.
Take-off and destination vertiports could look like the one shown in figure 25 and figure 26:
Figure 22 VoloPort a top urban building with VoloCity and VoloConnect © Volocopter GmbH [74]
102
Figure 23 VoloPort Singapore outside © Volocopter GmbH, Raphael Oliver [75]
3.6 Airspace characterization in urban environment

3.6.1 Flight rules
ICAO Annex 2 [80] and SERA list VFR, IFR and SVFR (Special VFR). Flight rules standardise how aircraft
behave, interact with each other during flight and how aircraft interact with air traffic control.
Remote flights, either operated as VLOS and BVLOS do not fit well into any the existing flight rule sets.
We expect that at least one, perhaps several, new flight rules must be developed to integrate remote
flights into the airspace.
A new set of flight rules for U-space, the so call U-space flight rules or UFR should be developed. UFR
allows for but is not limited to BVLOS operation. It should also cater to the other types of operation,
including VLOS and the operations currently performed under existing flight rules. The objective is to
stay close to the existing rules, so that training requirements for pilots that want to fly in U-space are
limited. The details of UFR are yet to be developed.
3.6.2 Pilot
Three general conditions are foreseen.
1. Human pilot on board the aircraft

2. Human pilot remote from the aircraft
3. Autonomous piloting software on board the aircraft, supervised remotely by a
human.
These three are identified for the following reasons:
There is a significant distinction in terms of liability between involving (1,2) or not involving (3) a
human pilot. There is a significant distinction in terms of latency, robustness and capabilities between
an on-board (1,3) and off-board (2) pilot. U-space provides communications and other facilities that
are optimised towards remote pilots or software piloting functions (2,3) and may be less optimal for
human pilots on board (1)
Hybrid solutions between 2 and 3 where, for example, the UA will be piloted by software, augmented
by piloting software on the ground and potentially supervised by a human operator are not explicitly
103
discussed here. We note that the architecture of control systems should take the latency, achievable
data rates and continuity of the remote-control link carefully into account.
In the early days some UAM operations will fly with a pilot on board. The project should anticipate all
three options and also flights that transition from one to another.
UFR is expected to support 2 and 3 well.
3.6.3 On “controlled airspace" and U-space volumes

This section describes the structure of the airspace and links different terminologies.
3.6.3.1 ICAO Airspace classes

ICAO Annex 11 [81] section 2.6 defines airspace classes A, B, C, D, E, F and G. Each is defined in terms
of IFR and VFR flight and the services offered. From the current descriptions, UFR or any other ‘new’
flight rule is not permitted in any of the airspace classes defined by ICAO.
ICAO Annex 2 [80] section 3.1.10 defines restricted areas, and below that section is reproduced from
Annex 2, Tenth Edition, July 2005:
3.1.10 Prohibited areas and restricted areas
Aircraft shall not be flown in a prohibited area, or in a restricted area, the particulars of which have
been duly published, except in accordance with the conditions of the restrictions or by permission of
the State over whose territory the areas are established.
Hence with today’s definitions:
Any airspace classed from A to G can only accommodate UAS flights if they fly as IFR or VFR,
including special VFR.
Any airspace which accommodates aerial activity which is neither IFR nor VFR must be a prohibited
or restricted area. Such activities are many and include UFR flight as well as rocket launches,
skydiving, etc
3.6.3.2 Controlled airspace

ICAO Annex 2 — Air Traffic Services [80] defines Controlled Airspace thus:
Controlled airspace. An airspace of defined dimensions within which air traffic control service is
provided in accordance with the airspace classification.
Note. — Controlled airspace is a generic term which covers ATS airspace Classes A, B, C, D and E as
described in Annex 11, 2.6.
The list does not include F. Hence an advisory service is not sufficient for an airspace to be considered
controlled.
Today many refer to “controlled airspace” meaning “airspace controlled by an air traffic controller.”
This document stresses the precise meaning “airspace in which a tactical separation service is
provided,” without stating by what means this service is provided.
104
3.6.3.3 Geographic zones & U-space airspace
EU implementing regulation 2019/947, in Article 15 allows for the creation of Geographic Zones - see
[17] and [18]. Geographic zones are created for the management of UAS traffic. Geographic zones
may be restricted areas in the aeronautical information.
EU implementing regulations 2021/664, 665 and 666 [23], [29], [30] and [31] describe ‘U-space
airspace’ which is a kind of Geographic Zone in which U-space services are provided. This may be is a
restricted area in the sense that any aircraft not engaged in U-space network identification, nor visible
to ATC (equipped with a transponder, etc) must be electronic conspicuous to U-space. [30]
3.6.3.4 U-space volume types

Note: The proposal in the sections below is still under discussion within the CORUS X UAM project and
will refined in the CORUS X UAM ConOps.
The U-space ConOps of CORUS [4] describes three Volumes distinguished primarily by the conflict
resolution service offered by U-space. X has none, Y has strategic (i.e., plans do not conflict) and Z has
tactical conflict resolution. Z has been identified as coming in two types: Za and Zu. In Za the tactical
conflict resolution is by ATC, with the support of U-space tools for surveillance, communications, etc.
In Zu, the conflict resolution is by U-space service alone. The CORUS ConOps identifies a question. Is Z
controlled airspace or uncontrolled. The current ConOps [4] allows either.
When Z is controlled airspace the conflict resolution service gives instructions. The conflict
resolution service is responsible for maintaining separation.
A form of Z in which the conflict resolution service gives advice. The pilot is responsible for
maintaining separation. Like ICAO Class F, this is not considered to be controlled airspace. See
3.6.3.2
Each option has implications in terms of performance, capacity, cost, …
The CORUS project and the U-space ConOps grappled with the difficulty of classifying Z as controlled
and allowed for it to be either controlled or uncontrolled. This compromise is problematic and
confusing. Hence this document introduces two distinct names and uses them from now on.
Z volumes are airspace in which separation instructions are sent by a U-space service provider: Zu
(Z U-space control)
Z volumes are airspace in which separation advice is sent by a U-space service provider: Zz (Z, zero
control)
Z volumes are airspace in which separation instructions are sent by ATC: Za (Z, ATC control)
Z volumes are airspace in which separation advice is sent by a FIS (Zf, zero control)
Hence Zu and Za are both controlled airspaces. Zz is not.
3.6.3.5 Relationship between ICAO classes and U-space volume types

As mentioned in 3.6.3.1, under current definitions volumes XYZ could only be parts of existing ICAO
classes of airspace if (and only if) all traffic within them followed VFR or IFR. The difficulty for UAS to
follow IFR is not the navigation or deconfliction aspects so much as the equipage requirements.
105
# ICAO 2019/947 2021/664 CORUS- Flight Remarks
Geo Zone U-space XUAM rules
airspace
α G above No No Not U- IFR ** & For U-space users such airspace
VLL, space VFR *** would probably be marked a Y
ABCDEF volume and any U-space operation
plan penetrating this airspace will
either not be approved or will be
subject to conditions or warnings.
β ABCDE No No Za IFR ** Za if and only if the flight’s entry
space planning process that
includes ATC approval.
γ G VLL No No X VFR & IFR UAS fly below VFR limits but in
*** effect conform to VFR flight rules
δ G VLL Yes No X VFR & IFR Conditions apply
*** UAS fly below VFR limits but in
effect conform to VFR flight rules
ε Restricted Yes No X VFR Restrictions may apply:
ζ Restricted Yes No Y Dependent Potentially a no fly zone for UAS
Area on the
restriction
η Restricted Yes Yes Y See 1 & 2, No tactical separation service
θ Restricted Yes Yes * Zu UFR Tactical separation service supplied
below
λ Restricted Yes Yes * Zz See 1 & 3, Tactical separation advice supplied
Table 22 airspace structure summary
* 2021/664 describes something approximating Y. Zu and Zz are considered as extending Y
** IFR only in A.
*** IFR unlikely in G
1) UFR is defined as how to fly in Zu. In Zu there is U-space tactical conflict resolution, hence UFR
includes obeying U-space tactical conflict resolution. As mentioned in section 3.6.1, UFR is not
fully defined in this document. It is expected that Zu only supports UFR and all aircraft in Zu
must follow UFR.
2) An airspace which is a U-space airspace according to 2021/664 [23] & [31], most closely
matching the CORUS volume Y, is one aimed at supporting BVLOS operations by means of
strategic conflict resolution. Hence flights in the airspace do not follow UFR as flown in Zu, as
tactical support is limited to traffic information. 2021/664 foresees entry of VFR or IFR traffic
into U-space airspace as being an emergency procedure in which U-space traffic “take
106
appropriate measures.” Hence it should be noted IFR and VFR traffic are not catered for in Y
volumes.
3.6.3.6 Around airports

The other problem we need to tackle is that today around airports, the airspace (the CTR) is often
classified as controlled down to ground level for significant distances – several km. This results in many
urban areas being in controlled airspace. As urban UAS operations begin, it is likely that these regions
will not be offered separation services to small UAS by ATC at the airport who that lack the
surveillance, procedures and manpower to provide them. Instead of being Za, such regions may be
reclassified as Y or Zu or Zz, and notably neither Y nor Zz are controlled airspace.
3.6.3.7 Summary
In summary, the following are all controlled airspace:
Airspace classes A, B, C, D, E
U-space Zu volumes inside restricted areas,
U-space Za volumes inside ICAO classes A, B, C, D, E
ICAO controlled airspace is described to the UAS community as Za for two reasons: 1) to aid UAS
community comprehension and 2) to allow the U-space ConOps to describe how UAS flights and
operators should act to fly within such airspaces. Not all controlled airspaces are Za volumes – only
those for which the U-space Za procedures can be used.
All flights in Zu fly UFR.
The following are all uncontrolled:
Airspace classes F, G
U-space volumes X, Y and Zz created inside restricted areas.
UAS Flights in X in uncontrolled airspace must fly in accordance with VFR or IFR.
Y volumes may exist simply to exclude UAS traffic. Such Y volumes may be created in any airspace.
3.6.4 Operations
The following operations flight phases are foreseen:
Taxi
Take off from (from airport, vertiport or any facilities or areas where take-off is possible and
allowed)
Climb / departure
Exit terminal area and join en-route phase
Cruise in low, medium or high-density environment
Descent approach
Join the arrival sequence
Final approach
Land at Airport
Land at Vertiport
Land at TOLA
Missed approach
107
3.6.5 Discussion of flight rules for different operations
In general, four modes are foreseen as appropriate to the conditions:
1. As manned operations – IFR or VFR

2. In Za volume. ATC control the flight, either using U-space ATC tools (UFR) or as now IFR or
VFR
3. In Y or Zz volumes the flight is uncontrolled but receives traffic information (Y) and
advisory service (Zz) from U-space. This is close to VFR or SVFR.
4. In a Zu volume. The flight is under U-space – UFR.
A quick examination of UFR follows. The key features of aircraft operating under UFR are:
High density BVLOS UAS remote flight operations are supported by means of U-space.
All operations are planned and known to U-space.
Tactical separation instructions are sent from U-space by means of data communications, not
voice.
Vehicles use a detect and avoid feature as a safety net, it is not the primary means of achieving
tactical separation.
Separation minima depend on the prevailing conditions for each pair of aircraft.
Each airspace has a set of operational performance minima with corresponding separations and
capacity.
Messages sent by means of U-space community may be received by and acted on by the vehicle
without human consideration and judgement. The pilot would have a monitoring role. The
rapid reactions this would allow would be considered in any pairwise separation minima
calculation. The number (frequency) and types of instructions will probably change
significantly from current operations. It may be that this way of working becomes mandatory
in some airspaces to ensure consistently rapid reactions and subtlety of control that enable
high capacities.
Significant difficulties of integrating manned aircraft into this environment would be
Translating communications to and from U-space into a form convenient for a human pilot.
Allowing for the reaction time and unpredictability of a human pilot.
Training the pilot to new rules, even if the maximum is done so that UFR are close to IFR.
3.6.6 Operations in Airport & CTR, class A, B, C, D

3.6.6.1 Areas of active control:
It is expected that operations of UAM would resemble existing helicopter operations with dedicated
arrival & departure routes, taxiing areas and similar.
This is not a requirement however and on-board piloted UAM vehicles may operate as U-space flights,
as will vehicles without a human pilot on board. Such U-space flights are expected to operate in
airports in either in Za with ATS in control the flight through U-space, or in U-space volumes Y, Zz, Zu
as defined. Za volumes are of most interest if the flight has to be “routed” or managed tactically with
manned traffic.
Hence the Airport would be Za with aircraft operating as manned (IFR/VFR) or unmanned (UFR) on a
case-by-case basis. Achieving efficient and safe operations in these mixed modes will be challenging.
Effects on controller workload and airport capacity need to be carefully considered.
108
3.6.6.2 Areas further from the airport:
Establishment of Zu or Zz in classes A, B,C, and D has not been discussed in the CORUS ConOps but
seems to be valuable. CTR may be defined down to ground level at a distance from the airport at which
ATC are neither interested nor willing to offer a control service to a new and numerous collections of
traffic. Hence such volumes may be defined as Zu (or Zz or Y). The choice of whether such a Z airspace
is operating as Zu (U-space controlled) or Zz (uncontrolled) should be made on the basis of traffic
safety rather than an automatic inheritance of this status. Conversion of such CTR areas to in effect
class G, combined with a “U-Space Avionics Mandatory Zone”, may be achieved by creation of
restricted areas in the short term.
3.6.7 Class G above an urban, suburban or other area

The expectation of the team is that Zu is the normal designation of the airspace, with Zz and Y in areas
of low to very low demand. UAM would operate as “UFR” whether or not there was a pilot on board.
Work should be done to define what UFR is and once that is established how IFR and/or VFR flights
differ. Once that is done study is needed to establish how non-UFR traffic can safely enter Zu, Zz and
Y.
3.6.8 Other considerations

Airspace volumes will have minimum navigational or technical performance criteria attached to them.
These will be set as needed by the target level of safety, the expected traffic demand and so on.
Transition from current operations to the intended goal will be a slow process in which a lot is learned
on the way. The goal should be defined to an appropriate level of detail.
3.6.9 Intermediate Conclusion:

Most UAM operations are predicted to occur in Zu airspace where separation services are
provided.
Where interaction with ATC is needed, U-Space shall be considered Za. shall be used.
Where Y and or Zz should work are not able to provide sufficient airspace capacity, hence Zu is
preferred in areas with high capacity demand and safety requirements.
We may create Zu, Zz and Y in airspaces on any current ATM airspace.
3.6.10 Acceptable Means of Separation

This section compares different means of separation in different airspace. Each case considers two
aircraft, proposes a means of separation and comments on this. Note that the table below mixes flight
rules and UAS modes of operation. Note that the tables below consider VLOS and BVLOS as distinct
from IFR - it is possible to operate UAS as IFR but in this case they appear in the table as IFR.
3.6.10.1 U-space Uncontrolled Airspace, Y, Zz:

volume Flight Tactical Separation Remarks
Y VLOS VLOS See & Avoid If both take action, then the risk neither does is reduced.
assisted by U- That reaction also helps the VLOS/BVLOS case.
space
Traffic Information
when available
109
volume Flight Tactical Separation Remarks
Y VLOS BVLOS VLOS: See & Avoid BVLOS must be slow moving and visible.
assisted by U- VLOS pilot must be aware that he/she is responsible to
space avoid the other aircraft, either operating BVLOS or VLOS.
Traffic Information The BVLOS has priority.
when available
Y BVLOS BVLOS U-space
or Traffic Information
when available
VLOS
Detect and Avoid12
when available
Zz Any Any U-space tactical Safety net is Detect and Avoid, when available or see and
conflict resolution avoid, when available
advice
Y VLOS VFR U-space VLOS limited to an altitude of 500ft AGL (or lower, 400ft),
or IFR Traffic Information to reduce risk of encounter.
when available Additional rules when operating near airfields (e.g.,
VLOS: See & Avoid requirement to inform airport)
Manned aircraft has priority.
Y BVLOS VFR U-space Detect & Avoid should work to high level of reliability.
or IFR Traffic Information
when available
BVLOS: Detect and
Avoid
Table 23 Tactical Separation methods in uncontrolled airspace
At the level of airspace class definition, no decision needs to be made regarding the technical solution
for detect and avoid or conspicuity; the airspace class describes the responsibilities for aircraft
operating under various Flight Rules.
A cooperative D&A solution could be based on e-conspicuity. This would require all air traffic to be
suitably equipped with a transponding and/or broadcasting device13.
Non-cooperative D&A (aka S&A) may also be used, based on vision, sound14, radar, lidar, etc.
The technical solution needs to be addressed at airspace management level. Like Transponder
Mandatory Zones that exist today, an e-Conspicuity Mandatory Zone would be required for the e-
Conspicuity based D&A type, limiting access to that airspace to aircraft that are equipped with e-
Conspicuity. Similarly, an “Non-cooperative D&A Mandatory Zone” would require UA to be suitably
12
Detect and Avoid is sometimes used to mean a cooperative scheme where aircraft take measures to be
detectable by other aircraft, in which case Sense and avoid is used to mean as scheme that can sense any other
aircraft, cooperative or not. Here Detect & Avoid covers both.
13
Research has shown that this may be feasible at low cost. The PERCEVITE project proposed a scheme based
on WiFi. ASTM F3411-19 proposes WiFi and Bluetooth.
14
Percevite project – hear and avoid. Manned aircraft are often quite noisy.
110
equipped with non-cooperative D&A means, but it would not put additional equipment requirements
on manned aviation.
The performance requirements for D&A equipment would need to be addressed in a Standardisation
process. The performance level of the D&A will directly affect the residual risk and therefore impact
the maximum airspace capacity.
See & Avoid and Detect & Avoid are safety barriers that lower the probability of mid-air collisions, but
they are not infallible:
 Not seeing / detecting in time, or at all (studies have shown failure to see is common)
 Not properly executing avoidance manoeuvres
The introduction of UAS corridors, well-known to GA traffic, could help to organise smooth traffic
flows as well as reducing the risk associated to S&A/D&A because GA will tend to avoid those corridors.
At increasing traffic levels, S&A/D&A errors will increasingly lead to near misses and mid-air collisions.
To enhance the effectiveness of S&A, a Traffic Information Service can be introduced, which is an
Information Service that advises pilots about other traffic in the vicinity.
3.6.10.2 U-space Controlled Airspace, Zu/Za:

Flight Separation Remarks
BVLOS BVLOS U-space D&A – if present – is a safety-net15.
or or Tactical conflict resolution
VLOS VLOS
BVLOS VFR UAS:
or or Tactical conflict resolution
VLOS IFR Replanning due to airspace restriction
& Emergency Management (alerts)
Table 24 Separation methods in controlled airspace
Controlled airspace is about predictability.
3.7 Systems in support of UAM

3.7.1 Collaborative systems for UAM
When considering tools for solutions, we will always find the combination of systems, procedures, and
qualified people with specific roles at the core of solutions.
Procedures and airspaces structures are already addressed in their specific chapter, as well as
legislative aspects.
Also, people or stakeholders and their specific roles are addressed in specific chapters.
15
When UAS and GA traffic are segregated, under what circumstances is Sense & Avoid (or Detect & Avoid)
needed as a safety net? What would the decision depend on? Ground risk – meaning the effect of a collision?
Or only air risk – meaning the probability of a collision?
111
So, in this chapter we have to deal with the systems that will be involved in providing the necessary
services for UAM. The paradigm here is that the cooperation of various systems is the way forward,
since the complexity of the total task can probably not be solved by just one system.
Several the envisaged and involved systems are already existing today, but eventually they must be
modified or extended, and another number of systems will have to be developed yet.
We furthermore assume that for these systems interconnectivity exists (VPN over internet), including
mobile communication via the telecommunication network. With this assumption we may add mobile
devices to the whole network. Mobile telecommunication today is yet limited in altitude.
Investigations have shown that usually there is a coverage up to 150 meters, at some spots even up
to 1000 m, but the latter cannot be assumed everywhere. The mobile telecom service providers,
however, are beginning to elaborate this market, and for simplification we may presume that a mobile
coverage up to 10 km altitude will exist soon.
All actors/stakeholders in UAM will make use of specific systems providing specific functions and
services. As a starting point we list the relevant systems, their role and functionality today, seen at a
national scope:
System Actor/ Function Role in UAM Status

Stakeholder
UAS/UAM CAA DB of all UAS Central registry with Under construction
registration Proxy to foreign unique operator
database registration DBs and vehicle ids, and
related data
ATM Multi Sensor ANSP Tracking and fusion Computation of the Many variants
Data Fusion (MSDF) of all kinds of overall situational existing, a few only
Tracker surveillance data traffic (=sum of all with the capability
tracks, manned and to fuse manned
unmanned) and unmanned
traffic
ATM Situation ANSP Air traffic situation Situational Many variants
Display / Controller display and working awareness means existing
Working Position position for air incl. traffic and
(CWP) traffic controllers geodata on ATC
side
ATM Flight Data ANSP Display of flight Flight Planning Many variants
Processing System plans, management coordination means existing, some of
(FDPS) and flight of flight plan on ATC side them integrated
plan displays workflow with the CWP
ATM Safety net ANSP Conflict Detection Conflict detection Many variants
Functions on Area intrusion, for manned aviation existing, but no
minimum altitudes, consideration of
and Short Term UAS
Conflict Alerting
(STCA)
112
Stakeholder
CIS Traffic CISP Traffic service (e.g., Provision of In development,
information data tracks) provision to situational prototypes existing
provision U-Space, either awareness to (all?)
ATM tracks only, or U-Space
a fused situation stakeholders
with integrated
UAS tracks
CIS geodata CISP Compilation, Foundation of In development,
information quality assurance, geodata services to prototypes existing
provision and data service (all?) U-Space
provision of stakeholders
geodata both from
ATC and for U-
Space purposes
UTM USSP UAS Traffic Coordination In development,
Management platform for the prototypes existing
provision by one or interaction of all
many USSPs stakeholders in a U-
Uses track data and Space, exchange of
geodata to provide traffic information,
comprehensive air geodata, flight
situation picture plans, permissions
Computes conflicts Clients of UTM:
for UAS and UAM, At the USSP to grant
also with manned standard
aviation permissions and
Computes conflict provide situational
resolutions for UAS awareness might
and UAM exist
Processes flight at authorities to
requests and grant special
permissions, permissions,
validates against at cities to allow the
geo-zones and definition of
regulations temporary NFZs
Coordinates flight- at police to support
plan status with law enforcement
ATM at UAS/UAM
operators to
provide situational
awareness
at UAS pilots in the
field to provide
situational
awareness
at VFR pilots to
provide situational
awareness
113
Stakeholder
UTM clients for USSP USSP Situation Situation awareness In development,
awareness in AoR Geo-awareness and prototypes existing
Permission granting geodata
modifications in
AoR
Permissions in
scope of USSP
UTM clients for authorities Situation Situation awareness In development,
authorities awareness in AoR Permissions beyond prototypes existing
Permission granting scope of USSP
Geo-awareness and
geodata
modifications in
AoR
UTM clients for cities City Situation Situation awareness In development,
awareness in AoR Geo-awareness and prototypes existing
geodata
modifications in
AoR (temp. NFZ)
UTM clients for Police Situation Situation awareness In development,

police awareness in AoR Law enforcement prototypes existing
Search and activities
identification Geo-awareness and
geodata
modifications in
AoR (temp. NFZ)
UTM clients for UAS or UAM Situation Situation awareness In development,

operators operator awareness in AoR prototypes existing
Flight planning and
validation
UTM clients for UAS pilots Situation Situation In development,
pilots in the field awareness in AoR awareness, prototypes existing
Flight planning and including mobile
validation versions
UTM clients for VFR VFR pilots Situation Situation In development,

pilots awareness in AoR awareness, prototypes existing
Flight planning and including mobile
validation versions
114
Stakeholder
Operator fleet UAM operator Fleet asset Source of UAM In development
management system management, fleet flight plans,
workflow Interacts with UTM
management, fleet
monitoring, UAS
resource planning,
central DB for
bookings
UAM booking UAM operator Booking app for Tool for passengers In early concept
system resp. passenger calling an air-taxi, or customers to call phase
interfaces with the an UAS or UAM
central operator service
fleet management
UAS ground control UAM operator Controls the UAS or Tool for the Many variants for
system or RPS and/or pilot in UAM (manually, execution and UAS exist, for UAM
the field semi-manually, per control of the UAS systems are in
uploaded/activated or UAM flight, development
flight path) May integrate with
UTM client
UAS on board flight UAS or UAM Flies the UAS or The flight system of Many variants exist
management system itself UAM, evtl. receives the UAS or UAM, in various stages
commands (flight position data
path, controls), provision
provides UAS or
UAM position via
LTE
Might use extra
devices for that
purpose (HOD,
ADS-B, FLARM, R-
Id)
Vertiport Vertiport Monitors and Provides vertiport In early concept
management system manager manages a data and status to phase
vertiport or many UTM
vertiports and its
resources
U-space surveillance USSPs and/or Surveillance of UAS UAS identification Solutions for ADS-
means ANSP with: ADS-B, and surveillance B, FLARM, LTE,
FLARM, HOD, LTE, infrastructure to HOD exist.
RID, DDS/C-UAS observe UAS or Solutions for RID
UAM flights are upcoming.
DDS/C-UAS are
evolving, some
solutions for
smaller AoRs exist,
a few for larger
AoRs and airports
Table 25 U-space related systems
115
A diagram of these systems connected to the internet & mobile communication infrastructure is
added below. This diagram may consecutively be used to illustrate the various communications
between the systems.
Figure 24 UAM systems landscape
Platforms here do not imply a specific technology, they could be LANs, Cloud based environments, or
simply a set of coexisting systems in the same organisation.
We assume that there will be at least 4 types of such platforms for UAM, resp. in the aviation area of
the future:
 ATM/ANSP platforms
 CIS platforms
 UTM platforms
 UAM operator platforms
 Furthermore, at least 4 additional instances of specific systems will be required for UAM:
 The national UAS registry database, also acting as a proxy to foreign registries
 The national set of geodata sources (evtl. unified in one QS-controlled database)
 The METEO data sources (by METEO service)
 A series of local vertiport management systems
116
Neighbour systems for UAM
Neighbour systems Explanation Owner Remark
METEO data sources Provision of aviation METEO service Could be provided

weather through CIS
Provision of UAS
operations weather
Geo data sources Cataster mapping service, Will probably be

provided through CIS
DLM geodata service
Geodatabases of the aeronautical geodata

authorities service (usually with
ANSPs)
UAS manufacturer Permission-relevant, manufacturers Parameters have to be

data performance-relevant, considered in
and safety-relevant permissions, airspace
UAS data usage, mission
permissions
Table 26 Neighbour systems for UAM
3.7.2 Registration database

Actor/stakeholder and its variants:
The registration database belongs to the tasks delegated to the member state, and it is up to the
member state to decide about its implementation. Foreseeable implementation variants are:
Registration database at the CAA
Registration database at the combined CAA/ANSP
Registration database at a mandated suborganisation
The ministry of transport in a member state will probably be the instance, where the allocation is
decided. The decision will be influenced by the already existing structure of aviation-related
authorities, depending on its either centralised or federated structure. In countries like Austria, it
seems to be more centralised and thus will more probably be allocated to the combined instance of
CAA and ANSP at AUSTROCONTROL, in other countries with a split between CAA and ANSP this task
might be allocated to either the CAA or the ANSP (see e.g., Italy), or – in an even more federated
context – it might be delegated to a specific authority below the CAA level, like to the
Luftfahrtbundesamt (LBA) in Germany.
117
Function in more detail, differentiating also the status today and the needed extensions in future:
Functions, Explanation Status today Needs in

in more future
detail
Central Descriptive data for operators Registry is under Accessibility
registry with (name address, id, email, etc) construction; for UTM
unique Descriptive data for UAS (id, provision of systems,
operator and brand, type, serial nr., unique ids is including for
vehicle ids, equipage, etc.) granted the tracking
and related and MSDF
Data for Light UAS certificate
data storage: fusion
management
Registry of component in
Functions to search manually by UTM to use the
operators,
an operator or remotely by a unique ids for
registry of
system to retrieve data on an UAS track
UAS,
operator and/or an UAS identification
Registry of
Data from the past may not go
LUC?
lost by modification but need to
Data search be stored as valid for a certain
functionality timeslot in the past. A
Data versioning therefore is
maintenance required. When searching, the
functions time dimension has to be
Data considered as well.
versioning
and history
Transnational Data from registries abroad Data exchange Transnational
data shall be accessible to allow not yet existing; interoperability
provision and identification and flight work is max. in with foreign
exchange planning in a foreign country conceptual phase UAS registry
Retrieval of inside Europe. databases to
foreign data By default, data access for exchange ids
on operators modifications is assumed to be and related
and UAS with the assigned authority, but operator and
there might be emergency or vehicle data for
Evtl. remote
contingency cases, where UAS operations
update of
severe events need a remote abroad
certain data
for UAS and access for modifications.
operators (in
case of
accidents,
termination
of operations
etc.)
Table 27 Registration database functions in more detail
118
Communicating partner systems and data exchange
Partner system Exchange purpose Data in/out Remarks

A UTM system (one at Retrieval of UAS track properties for Data privacy issues
an USSP or the national identification data for an search in, full identification yet to be
one) operator or an UAS data out considered
Either from within the Operator properties for
member state, or from search in, full operator
a foreign state in identification data out
Europe
A foreign UAS/UAM Retrieval of UAS track properties for Data privacy issues
registration database identification data for an search in, full identification yet to be
operator or an UAS data out considered
Operator properties for
search in, full operator
identification data out
Data update provision

due to specific events or UAS or operator matching
knowledge criteria in,
Updated of related data in
Confirmation or rejection of
update out
Table 28 Registration database communicating partner systems and data exchange
Role today and in future in UAM
The registry provides the authorised identification of an UAS and an operator, with all relevant
attached data that are necessary to be participant in U-Space. Some UTM implementations today
already have included database functions for UAS and operator registry. It needs to be decided,
whether registry and UTM shall remain separate systems und functionalities, or whether they will be
rejoined again. In any case, bilateral – or even multilateral - data access is required. If there will be
several UTM systems – as USSPs – per country, it is more likely that registry and UTM remains
separated.
3.7.3 ATM MSDF Tracker

Actor/stakeholder and its variants
ATM MSDF trackers use radar and other certified surveillance data in ATM to collect position data of
moving aircraft and compute a statistically optimal track update for all detected aircraft. The track of
an aircraft contains a 4D position, identification, and kinematic parameters of the aircraft such as
ground speed, heading, manoeuvre state, rate of climb or descend, and other current status
parameters. Trackers perform also some monitoring of surveillance sensor status and use that
assessment information in the computation of the statistical estimation. Track updates are computed
permanently on a cyclic or event-basis and distributed to a series of consumer systems, such as ATC
controller working positions (CWPs), flight plan data processing systems (FDPS), conflict detection
systems like STCA, MTCD, Aera intrusion alert or terrain proximity warning systems, and other traffic
management assistance systems in ATM. ATM MSDF trackers are the primary source of up-to-data
manned aircraft position data, also for U-Space systems as additional future consumer systems. ATM
MSDF tracking systems are allocated to stakeholders within the ANSP organisation at various levels:
ATM MSDF tracker per control zone around an airport (tower context)
119
ATM MSDF tracker per area control center (ACC or UAC context)
ATM MSDF tracker per ACC and its associated towers (combined context)
ATM MSDF tracker per country
UTM systems might consume track data of the neighbouring ATM MSDF trackers or use the services
of a CIS provider. A CIS provider will need to use ATM MSDF capabilities in the scope of its area of
responsibility. If a nationwide ATM MSDF tracker is available, it will reduce complexity of
communication a lot and also minimise the risks of ambiguities, however, a national ATM MSDF
tracking capability is demanding, and only available in a subset of the European countries (at least in
Austria, Belgium, Denmark, Germany, Luxembourg, Netherlands, Portugal, Switzerland).
Function in more detail, also differentiating the status today and the needed extensions in future.
Functions in Status today Needs in future

more detail
Integration of Existing in all Might need an integration at national level to reduce
position data European countries, communication complexity
from radars with various levels of Might need the integration of position data sources of
(Primary, SSR, integration (see unmanned traffic, like ADS-B, FLARM, 5G mobile comm. to
Mode S), above) compute a common air situation picture
Multilateration
systems
(MLAT), evtl.
ADS-B
Statistically Existing in all More complex motion models in statistical filters to integrate
optimal European countries, also UAS manoeuvres
estimation of with various levels of
current track integration (see
states of above)
aircraft
Track Existing in all Track distribution also to new consumer systems like CIS
distribution to European countries, platforms, UTM-systems
consumer with various levels of
systems integration (see
above)
Assessment of Existing in all Extensions for new types of sensors and position data sources
sensor data, European countries, like FLARM, and 5G.
status, quality, with various levels of
and control integration (see
feed back into above)
the estimation
process
Table 29 ATM Multi-Sensor-Data-Fusion Tracker functions
Partner system Exchange purpose Data Remarks

in/out
ATM situation Track provision for air Tracks out
displays situation picture
ATM FDPS and Track provision for flight Tracks out
flight plan displays plan correlation
120
Partner system Exchange purpose Data Remarks
in/out
ATM safety net Track provision for conflict Tracks out
functions detection: short term
conflict alert (STCA),
medium term conflict
alert (MTCD), Area
intrusion alert (AIA),
Terrain proximity warning
and minimum altitude
(MRVA)
CIS traffic Track provision for (a) ATM May be designed in two ways:
information data servicing UTM consumer Tracks out (a) ATM tracks out to U-Space only
provision systems at USSPs (b) UAS plots (b) UAS position data are fed from UTM
in, combined resp. U-Space sensors at USSPs to the
ATM and central MSDF tracking as well, combined
UAS tracks manned and unmanned track situation
out is computed and redistributed to USSPs
Table 30 ATM Multi-Sensor-Data-Fusion Tracker partner systems and data exchanges
ATM MSDF trackers are the functional core of ATM systems and the computation of the current air
situation picture, where controllers act on and ensure the safety of the ATM system.
Manned aviation and UAS will get together. The less segregation, the higher capacity of given airspace
is available for all participants. Non-segregated airspace needs a commonly sensored, computed, and
distributed air situation picture. Even in segregated airspace structures, common awareness helps for
the coordination close to the borders of both airspaces or in emergency and contingency cases
(“reconfiguration of airspace”).
At a first level of collaboration ATM MSDF tracker data will need to be provided to U-Space via the CIS
function. A second integration step might allow a two-way communication to use the existing MSDF
tracking capabilities for feeding UAS data in and getting a combined manned and unmanned traffic
situation out. Expensive investments in own tracking technologies at USSPs could be avoided this way.
3.7.4 ATM situation display (CWP)

Basically, CWPs are available for 4 stakeholder groups inside an ANSP, for the work of the controllers:
 SMGCS/A-SMGCS CWP for apron and taxi controllers at airports, with regionally varying
models of workshare between ANSPs and airport
 Tower CWP for tower controllers managing approaching/landing and starting/departing

aircraft at airports
 Centre CWPs for area control centres, evtl. with variants for dedicated approach controllers
(approach sequencing), departure controllers, area controllers, and upper airspace controllers
 FIS CWPs for controllers supporting general aviation with flight information services and
navigation support
121
Function in more detail, differentiating also the status today and the needed extensions in future.
Functions in Explanation Status today Needs in future

more detail
Air traffic Display of ATM tracks over Existing in all Might include UAS tracks in
situation configurable map background European controlled airspace in the future
display countries, with (unmanned cargo systems)
various levels of Might include relevant subpart of
integration UAS traffic in VLL (FIS CWPs,
SMGCS CWPs, TWR CWPs)
Combined Tracks and flight plans are Existing in all Might include UAS tracks in
display of correlated. Flight plan European controlled airspace in the future
tracks and flight information is available for countries, with (unmanned cargo systems)
plan correlated tracks various levels of Might include relevant subpart of
information integration UAS traffic in VLL
Weather Aviation weather data today Existing in all UAS will need specific weather in
information only European VLL with a refined grid resolution
display countries, with and additional other elements, but
various levels of possibly not relevant to the ATM
integration controller
Conflict alarm Display of conflict detection Existing in all UAS in controlled airspace
display between aircraft or between European probably will be treated like
aircraft and environment: short countries, with aircraft with limited features,
term conflict alert (STCA), various levels of conflict detection will work like for
medium term conflict alert integration aircraft, possibly conformance
(MTCA), Area intrusion alert monitoring will have differences in
(AIA), Terrain proximity detail
warning and minimum altitude UAS in uncontrolled airspace will
(MRVA), conformance not be relevant for ATM
monitoring with flight plan controllers, but possibly for FIS,
SMGCS, and Tower CWPs
Conflict Assignment of new flight levels Existing in all FIS might support VFR with UAS-
resolution Assignment of new route European related traffic information and
support elements countries, with warnings
various levels of
Provision of situational
integration
awareness and navigational
information
Sector Handover between sectors in Existing in all
transition ACCs and UACs European
coordination Handover between Tower and countries, with
support ACC various levels of
integration
Handover between Tower and
SMGCS
Contingency Display of aircraft specific Existing in all
and emergency alarms and conditions European
support Provision of support countries, with
information to pilots various levels of
integration
Table 31 ATM situation display functions
122
Partner system Exchange purpose Data in/out

ATM MSDF tracker Situation picture Tracks in
ATM FDPS Flight plan information Flight plans and correlated flight plan in
conformance monitoring status in
ATM SNF Safety net functions results Warnings and alerts in
shown in CWP
Table 32 ATM situation display partner systems and data exchanges
CWPs are dedicated to manned air traffic solely today. UAS in controlled airspace will join in in the
future, with specific attributes and display elements, and possibly slightly modified parameters in
monitoring and warning (different dynamics, flight envelope, degrees of freedom, etc.).
FIS CWPs might get a specific role in providing UAS activity awareness to VFR traffic.
SMGCS and tower CWPs will be interested in the future in UAS traffic, in case there are regular or
irregular UAS activities at an airport.
3.7.5 ATM FDPS and flight plan displays

FDPS variants are used by 2 stakeholders inside ANSPs:
Tower Control uses Tower FDPS, or short TFDPS to define new (individual) flight plans, or modify
flight plans that are received from ACCs or the European ATM Network Manager (former
CFMU), where European repetitive flight plans are collected for a season or a year
ACCs or UACs use and modify flight plans that are received from ACCs or the European ATM
Network Manager (former CFMU), where European repetitive flight plans are collected for a
season or a year
FDPS are in essence flight plan workflow management systems, where flight plan data are forwarded
along the path of the flight execution from start through all sectors (in ACCs and UACs) to the landing
destination at an airport. So, all flight plan workflows start and end at an airport (tower control).
There is a server functionality that performs the computations, and there are display clients that
interact with the server. Display clients are part of the CWP setup, either in an integrated manner with
the traffic situation displays, or in a separate setup, with its own application.
123
more detail
Display of flight Display in strip-like tables in Static and dynamic May have to include UAS
plans extra display applications or displays, differentiated for flight plans in controlled
integrated in the CWP ATC tower and ATC centre airspace
display applications May have to include UAS
flight plans from adjacent
May include sequenced Operational at all tower airspaces (U-Space, VLL)
displays of flight plans control and ACC/UAC for situation awareness
based on time, priority, units in Europe and ease of coordination
optimisation
Management of Managements of requests Operational at all tower Flight plan coordination
flight plan and clearances, change of control and ACC/UAC with UAS and UTM might
workflow status of flights, modified units in Europe be handled in TFDPS, if
routings, pre-information controlled airspace is
and coordination along the affected.
flight plan path
Modification of Modification of routings, Operational at all tower Flight plan coordination
flight plans timings (ETD, ATD, ETA, control and ACC/UAC with UAS and UTM might
ATA, etc.), and coordinated units in Europe be handled in TFDPS, if
flight levels for hand-over controlled airspace is
affected.
Coordination on Flight plan conflicts, either Operational at all tower MTCA in controlled
flight plan basis detected by MTCA functions control and ACC/UAC airspace will possibly have
or considerations of ATC units in Europe to handle also UAS flight
controllers, might lead to MTCD operational at envelopes in the future
modifications for conflict some ACC/UAC units in (limited performance of
resolution Europe, currently rollout manoeuvrability)
and update in progress
Table 33 ATM FDPS and flight plan display functions
Partner Exchange purpose Data in/out Remarks

system
ATM CWP Integrated or extra display Flight plan
Display Tower version of CWP modifications, new flight
plans, flight plan
ACC/UAC version
deletions in
Eventually also, FIS version
Flight plan data out
ATM MSDF Correlation, Flight plans out
tracker Flight plan update for Tracks in
actual positions and time
computation
ATM Safety net Usage of flight plan data Flight plans out
functions for conflict detection and Warnings and alerts in
conformance monitoring
124
system
UTM UAS flight plan UAS flight plans in Might be an additional direct
preannouncement Clearances out connection to coordinate UAS
UAS preannouncement flight plans that affect
Flight plan modifications
clearance controlled airspace
out
UAS flight coordination (Modification in the platform
diagram)
Table 34 ATM FDPS and flight plan display communicating systems and data exchanges
Today there is no function or communication with respect to UAS and UTM. Military drone operations
might have a regular flight plan (or be completely invisible), such operations are treated like usual
controlled flights, with (manual) consideration of the limited degree of freedom in manoeuvring.
There might be in future an additional direct connection to coordinate UAS flight plans that affect
controlled airspace
3.7.6 ATM Safety net server

ATM safety net servers are usually allocated to ACCs and UACs, and to a much lesser degree to tower
applications.
Safety net servers compute:
Short-term conflict alert between aircraft

Area intrusion alert
Minimum radar vectoring altitude violations and ground approximations
Some of them also medium-term conflict alerts (MTCA) between aircraft, with a longer horizon of
look-ahead time (10 min +), and therefore taking flight plan data into consideration
Conformance monitoring (to flight plan, including monitoring of coordinated altitudes)
In the tower context safety net functions might be more easily found in the context of SMGCS with
runway incursion monitoring, and conflicts between taxiing aircraft, and also vehicles.

more detail
Short-term conflict Operational in Systems as such are not expected to interface with UAS and
alert most ACCs and UAM, but algorithmic knowhow may be an important source to
UACs in Europe UTM
Area intrusion alert Operational in Systems as such are not expected to interface with UAS and
most ACCs and UAM, but algorithmic knowhow may be an important source to
UACs in Europe UTM
125
more detail
Minimum radar Operational in Systems as such are not expected to interface with UAS and
vectoring altitude most ACCs and UAM, but algorithmic knowhow may be an important source to
violations and UACs in Europe UTM
ground
approximations
Medium-term Operational in Systems as such are not expected to interface with UAS and
conflict alerts most ACCs and UAM, but algorithmic knowhow may be an important source to
(MTCA) between UACs in Europe UTM
aircraft
Conformance Operational in Systems as such are not expected to interface with UAS and
monitoring most ACCs and UAM, but algorithmic knowhow may be an important source to
UACs in Europe UTM
Table 35 ATM Safety net server functions

system
ATM MSDF Track provision for conflict Tracks in
tracker detection: short term conflict alert
(STCA), medium term conflict alert
(MTCA), Area intrusion alert (AIA),
Terrain proximity warning and
minimum altitude (MRVA)
ATM FDPS Usage of flight plan data for Flight plans in Might evolve to conflict resolution
conflict detection and Alerts and and assistance tools (already
conformance monitoring warnings out ongoing research work, and also
part of advanced controller
support functions
ATM CWP Safety net functions results shown Warnings and
in CWP alerts out
Table 36 ATM Safety net server communicating partner systems and data exchange
Safety net systems in ATM as such are not expected to interface with UAS and UAM, but algorithmic
knowhow may be an important source to UTM.
3.7.7 CIS traffic information data provision system

Common information services provide information on U-spaces, adjacent U-Spaces, geodata, traffic
information data, and similar “foundation data” of airspace management. The provision of ATM traffic
data and ATM geodata is considered as part of the CIS in many national ConOps drafts in Europe.
The CIS platform is discussed in 2 variants:
126
 A central, single CIS platform and provider (S-CISP)
 A federated approach with multiple CIS platforms and providers, possibly one per USSP (N-
CISP)
S-CISP would reduce the complexity of data versions and communications, but as such it would not be
a competitive task. A N-CISP approach seems to fit to a competitive market-oriented approach. The
question is whether CISP really needs market competition, or whether it is better to have single
sources of truth for traffic data and geodata as a foundation for the competitive USSP services that
build upon these data. Multiple sources of foundation data – e.g., map data and traffic positions -
inherit the risks of ambiguities, which might be critical in emergency or contingency situations.
Ambiguities were also involved in most of the aviation accidents in history, therefore it might be
considered as a serious risk.
On the other hand, a competitive approach offers the chance to find best services and market prices
for the CIS services (if there is really competition instead of a hidden monopoly), however, there will
then be no guarantee.
Most ANSPs seem to be in favour of a S-CISP solution, while some USSP candidates seem to prefer a
N-CISP approach. Either approach will affect the architecture of the U-Space system landscape and
the structure of communication fundamentally.

more detail
Provision of traffic ATM tracks Prototypic systems existing in
data some countries, development
ongoing
Provision of traffic Also manned Largely not covered in ATM VLL traffic like VFR, HEMS, SAR
data aviation tracks systems, since no coverage need to become visible as well
in VLL Possibly plot data feed via CISP
into central MSDF, to get back a
complete fused air situation
Provision of traffic Possibly also, Not covered in ATM systems, UTM systems with attached U-
data UAS tracks and very expensive for UTM Space surveillance means might
systems collect UAS plot data and
forward it to central MSDF, and
get back a fused situation of
manned and unmanned aviation
Table 37 CIS traffic information data provision system functions

system
ATM Track service U-Space plots out
MSDF Tracks in
tracker
UTM Track Service Tracks out
systems U-Space plots in
127
system
Optional: Tbd. Tbd. Might need an update of the
pass thru diagram, interface to FDPS?
of UAS
mission
data and
clearances
Table 38 CIS traffic information data provision system communicating partner systems and data exchanges
There is no existing role today, as such systems really are not yet existing. CISP will be fundamental
for the system design of U-Space.
3.7.8 CIS geodata information provision system

Similar consideration as in chapter 7.7.

more detail
Provision of Provision of aeronautical geodata Prototypic systems Operational
geodata Provision of NFZ geodata existing in some system(s) needed
countries, development
Provision of land use data
ongoing
Consolidation of Merge and QS of geodata from

geodata variety of sources, if no central
agency is available
Provision of U- U-Space limits Prototypic systems Operational
space geometry Adjacent airspaces existing in some system(s) needed
data and adjacent countries, development
U-Spaces ongoing
List of certified Database of certified USSPs with Prototypic systems Operational
USSPs central repository, and shared existing in some system(s) needed
viewing and modification countries, development
capabilities ongoing
USSPs terms and Database of terms and conditions Prototypic systems Operational
conditions with central repository, and existing in some system(s) needed
database shared viewing and modification countries, development
UAS capabilities Database of requirements with Prototypic systems Operational
and performance central repository, and shared existing in some system(s) needed
requirements viewing and modification countries, development
128
more detail
UAS geo-zones and Database of zones and Prototypic systems Operational
static restrictions restrictions with central existing in some system(s) needed
repository, and shared viewing countries, development
and modification capabilities ongoing
Repository of Database of dynamic restrictions Prototypic systems Operational
dynamic with central repository, and existing in some system(s) needed
restrictions shared viewing and modification countries, development
Dynamic airspace Highly dynamic database and Prototypic systems Operational
reconfigurations messaging system of dynamic existing in some system(s) needed
reconfigurations with central countries, development
repository, and shared viewing ongoing
and modification capabilities
Table 39 CIS geodata information provision system functions

Geodata source Geodata compilation, merging, quality Geodata in
assurance, versioning, distribution
UTM servers Geodata provision as a common reference Merged geodata out

Table 40 CIS geodata information provision system communicating partner systems and data exchanges
Today there is no such function existing yet, will fundamentally form the structure of systems and
communications in U-Space.
3.7.9 UTM
USSPs will use UTM systems for USSP service provision such as:
Traffic information service

Geo-awareness service
UAS flight authorisation service
Network remote identification service
Conformance monitoring
Weather service
Provision and reception of dynamic restrictions
Sharing of USSPs terms and conditions
UTM systems and services are at the core of U-Space and serve as building blocks for it in a market
that is expected to be competitive.
In some countries CIS and UTM are merged into a single system (PANSA Poland?), in most others CIS
and UTM are seen as separate systems. While CIS are considered in majority to be central and single
instance, UTMs are regarded as systems with several USSPs in competition, and therefore with a
number of instances in U-Space.
129

more detail
Traffic Provision of track Prototypes existing, very few Needs to provide full and
information information for systems operational complete situation
service manned and Provided situation awareness is awareness
unmanned traffic limited
Provision of flight
plan information for
UAS
Provision of conflict
warnings and alarms
Geo-awareness Provision of geodata, Prototypes existing, very few Needs to provide full and
service maps, systems operational complete geodata
and geodata related
alarms
UAS flight Flight authorisation Prototypes existing, but very few Needs to provide full
authorisation within the scope of systems are operational. An open service for all UAS classes
service the USSP standards software development of UAS, and all types of
Flight authorisation initiative is going under the name missions
in coordination with “interUSS project” (Home-InterUSS
other authorities (interussplatform.org))
Network Provision of a unique Prototypes existing, very few Needs to provide full
remote identifier for a flight systems operational service for all UAS classes
identification object in U-space of UAS, and all types of
service missions
Conformance Monitoring of track Prototypes existing, very few Needs to provide full
monitoring accordance with systems operational service for all UAS classes
flight plan limits, of UAS, and all types of
generation of missions
warnings and alerts
Weather Provision of aviation Prototypes existing, very few Needs to provide full
service weather plus U- systems operational service for all UAS classes
Space weather of UAS, and all types of
Provision of missions
weather-related
restrictions,
warnings and alarms
Provision and Exchange of dynamic Prototypes existing, very few Needs to provide full
reception of restrictions with systems operational service for all UAS classes
dynamic other UTM and with of UAS, and all types of
restrictions ATM missions
130
more detail
Sharing of Communication of Prototypes existing, very few To be completed
USSPs terms T&C with other systems operational
and conditions USSPs
Future services To be defined To be defined The set of U-Space
services is expanding as
U-Space evolves over
time. Special attention is
needed for scalability,
security and
interoperability between
USSPs
Table 41 UTM functions
Partner Exchange Data in/out

system purpose
UAS registry Registry data UAS/operator search criteria in
database retrieval Registry data out
CIS traffic Traffic Track data in
information information Flight plan data out?
service retrieval
CIS Geodata Geodata in
geoinformation information
service retrieval
Meteo data Meteo data Meteo-data in
sources retrieval
All types of Client service Specific client service data exchange
UTM clients provision
Operator fleet UTM to Traffic information out
management operator’s UAS flight plans in
systems fleet
management.
coordination
Table 41 UTM communicating partner systems and data exchanges
UTM systems will be the building blocks of the U-Space system landscape, together with UAS, UAS
surveillance means, and possibly operators’ fleet management systems.
3.7.9.1 UTM client system for authorities

The UTM client system for authorities provides the authorities with the means of accessing data in the
UTM servers as well as the CIS data. The functionality used by various authorities can be roughly
divided into three categories:
1) Providing geographic information

2) Approving (special) operation plans
131
3) Planning and executing UAS operations on behalf of the authorities

more detail
Providing Authorities need access to Under

access to geographics data in support development, first
geographic of, for example, U-Space systems are
information operation authorisation operational.
processes
Workflow The appropriate authorities Initial systems are As traffic increases, there
support for need means to assess the operational, is a need for extensive
assessing acceptability requests for however further automation of the
flight operation authorisation. automation is approval process in order
operation This typically requires data desirable. to keep the response
authorisation from various sources and times to requests
request natures (geographic reasonable.
information, legal, technical
information about
equipment etc)
Flight The flight planning in Initial systems have

planning in support of emergency and been developed for
support of law-enforcement is similar demonstrator
emergency to that of regular UAS projects; further
and law- operations but has a development is
enforcement different set of operational needed.
flights limitations. The UTM Client
System for Authorities
should provide the
capability to plan flights
with higher priorities and
other restriction than those
that apply to regular users.
Functionality may include
management of temporary
restricted airspace to e.g.,
to protect SAR operations
from conflicting traffic.
Table 42: Functions today’s status and needed extensions in the future
132
Partner Exchange Data in/out Remarks

system purpose
UTM The client Geo-zones in / out
system obtains its Flight plan in / out
main data
Flight plan approval out
from the
UTM system Registration / Operator
information in
Authority- Synchronise
specific authority-
systems specific data
with the
UTM system
(e.g.,
geographic
information)
Table 43 UTM client systems for authorities communicating partner systems and data exchanges
3.7.9.2 UTM client system for cities

The UTM client system for cities allows local authorities to interact with the UTM system. It should
provide the city authorities with means of establishing and distributing rules on UAM operations (e.g.,
noise limitations) and local obstacle data (e.g., tower cranes) Function in more detail, differentiating
also the status today and the needed extensions in future
Functions Explanation Status today Needs in future

in more
detail
Manage The city Management of The functionality needs
local authorities airspace and obstacle further expansion,
airspace have the best database is under especially the delegation
restrictions, knowledge of development stage in of management
obstacles local current UTM systems. functionality to lower
etc. (temporary) authorities.
obstacles.
Generate The local
statistics authorities
for airspace will need
usage, information
social from the UTM
impact system in
reporting support of
etc. mobility
policy
development.
Table 44 functions of UTM client system for cities
133

system
UTM The UTM Server system is the
Server interface to the CIS, which holds the
system airspace and obstacle information.
Table 45 communications of UTM client system for cities
3.7.9.3 UTM client system for police

The UTM client system for police shall combine function of the client system for authorities (e.g., in
support of creation of pop-up no fly zones) as well as function of operators (e.g., in planning flights for
policing purposes). Flights managed through the police client shall have the option of being marked
as priority flight, giving it the priority over other flights when it comes to deconfliction.
3.7.9.4 UTM client system for operators

The UTM Client system for operators gives access to those services in the UTM systems that are of
importance to UAS operators.

in more
detail
Provide This is the general Prototypes existing, very few systems
access the interface that operational
U-Space provides the
services in operation access to
support of functions offered by
flight the USSP
operations
Traffic Provides real time Functionality is available as an Needs to be expanded
information information to the evolution from ATM systems with U-Space relevant
traffic situation. information on the traffic
(e.g., in support of priority
rules, right of way, etc)
Operation Allowing for the Prototypes existing, very few systems
planning submission and operational
modification of
operation plans.
Visualisation in support of flight Prototypes existing, very few systems
of Geo- planning operational
information
Obtaining in support of flight Prototypes existing, very few systems

weather planning operational
information
134
in more
detail
Access to For obtaining To be developed
UTM-ATM clearance from ATC
interface when exiting U-
Space, or for
coordination in
mixed traffic
environments
Table 46 UTM client system for UAS operators
3.7.9.5 UTM client system for pilots in the field

The UTM client system for pilots in the fields provides the pilot with accurate up-to-date information
in support of the execution of the flight. This includes traffic information, weather information, non-
conformance monitoring alerts of own flight and nearby aircraft as well as access to the UTM – ATM
interface in support of obtaining clearances from ATC.

more detail
Traffic Provides real time information to Functionality is Needs to be expanded with
information the traffic situation. available as an U-Space relevant
evolution from information on the traffic
ATM systems (e.g., in support of priority
rules, right of way, etc)
Provision of geo- Provides real time information Prototypes existing,
zone information about the position of the aircraft very few systems
with respect to geo-zones. operational
Obtaining in support of flight execution To be developed

weather
information
Conformance This function is to warn about To be developed
monitoring deviations from the deconflicted
flight plan of either own aircraft
or other (nearby) traffic
Access to UTM- For obtaining clearance from ATC To be developed
ATM interface when exiting U-Space, or for
coordination in mixed traffic
environments
Table 47 functions of UTM client system for pilots in the field
3.7.9.6 UTM client system for VFR pilots

The UTM client system for VFR pilots brings the U-space functions to the cockpit of manned aviation.
135

in more
detail
Traffic Provides real time The data link to manned Needs to be expanded with U-
information information to the aircraft is not yet available, Space relevant information on
traffic situation. This nor the avionics or handheld the traffic (e.g., in support of
could be augmented applications to display the priority rules, right of way, etc)
with traffic alerting traffic. Similar functionality
function that warn for exists in the form of FLARM
nearby traffic. and ADSB based traffic
information
Provision of See section above
geo-zone
information
Obtaining See section above
weather
information
Conformance See section above
monitoring
Access to See section above
UTM-ATM
interface
Table 48 functions of UTM client system for VFR pilots
3.7.10 Operator fleet management system

The operator fleet management system is at heart of the UAM operator’s operation. It is responsible
for planning the utilisation of the fleet, assigning transport requests to individual aircraft, planning
and monitoring flights for those aircraft as well as planning battery usage and charging. Whilst the
implementation details of fleet management systems is out of scope of CORUS-XUAM, the
development of U-Space solutions needs to recognise the need for interoperability with such systems.
Functions in more detail Explanation Status today Needs in future

Receive and process transport requests Prototypes are under
from customer development
Assign aircraft to fulfil transport request Prototypes are under
development
Prepare and submit flight plans Prototypes are under
development
Table 49 functions of operator fleet management system
136

UTM Flight planning Out: Flight plan submission
Traffic information In: flight plan approval/denial
In: Flight plan modification request
UAM booking Customer transport request In: transport request
system Out: Booking confirmation/denial
UAM GCS Flight plan exchange Out: Flight plan
Vehicle status information In: vehicles status information
Table 50 Communicating partner systems and data exchanges of operator fleet management system
3.7.11 UAM/UAS ground control system or RPS

Whilst the implementation details of ground control systems are out of scope of CORUS-XUAM, the
development of U-Space solutions needs to recognise the need for integration of UTM functionality
within such systems. The UTM system will have to provide appropriate interfaces to enable tight
integration of UTM functions in, and provision of data to ground control systems.
Functions Explanation Status Needs in future

in more today
detail
Pilot (see section
functions on UTM client
for pilots in
the field)
Receive Prototypes
orders and are under
communicate development
status with
Fleet
management
system
Table 51 functions of UAM/UAS ground control system or RPS
3.7.12UAM/UAV onboard flight management system

The flight management system is an onboard system of a UAV that is responsible for providing a
reference path which will be followed by the flight control system. As such, the FMS is holds and
updates in the intended flight path of the UAV for both nominal and abnormal situations. The intended
flight path may be updated based on inputs the Ground Control System or autonomously based on
inputs from on-board sensors.
In case the connection to the GCS is lost, the FMS shall keep the UAV on a safe path, potentially all the
way to the landing, which may be at an alternative landing site.
The intended flight path may be shared with the UTM system for purposes of conflict detection and
avoidance. In that case, the accuracy of the definition of the flight path combined with the ability of
137
the flight control computer and the navigation system to accurately fly that path will be one of the
factors driving the required size of safety buffer between passing aircraft.
When separation between aircraft is based on shared flight path intent data, the FMS may also
function as a route conformance monitoring subsystem to detect path deviations by approaching
aircraft. This can enable early detection of collision risk which can then be reduce by the FMS by
altering its own intended flight path.
The more autonomous the UAV is, the more critical the role of the FMS in keeping the flight safe.
Functions in more detail Explanation Status Needs in future

today
Managing the flight path in agreement with the
deconflicted flight plan.
Providing a reference path to Flight control
system
Managing contingencies flight paths in case of
failures in links or on-board systems
Table 52 functions of UAM/UAS onboard flight management system

UAS Ground Control System All control
information will
come through the
UAS Ground Control
System
Table 53 communications of UAM/UAS onboard flight management system
3.7.13Vertiport management system

A Vertiport management systems is responsible for coordinating local traffic movement on surface of
the vertiport as well as maintaining vertiport planning and status information up-to-date and
distributing this information to various stakeholders.
Maintaining a plan of FATO utilisation in support of Demand / Capacity balancing

Assigning FATO’s to approaching / departing vehicles
Orchestrating surface movement at the vertiport (if applicable)

Maintaining a plan of FATO utilisation Not developed yet,
in support of Demand / Capacity baseline may get
balancing and air taxi operations inspiration from airport
planning operation planning
systems / SWIM
Assigning FATO’s to approaching / Not developed yet
departing vehicles.
138
Orchestrating surface movement at Not developed yet,
the vertiport (if applicable) baseline may get
inspiration from
ASMGCS
Table 54 functions of vertiport management system

UTM flight Demand / Capacity balancing FATO availability.
planning system Slot reservation &
confirmation.
Fleet management Exchanging passenger information to
system guide passengers to the right stand.
Assigning stands to air taxis.
UAS Surface movement guidance Taxi route (if
applicable)
Table 55 communications of vertiport management system
3.7.14U-Space surveillance means

A wide variety of surveillance technologies will be used in U-Space. Especially in the near term,
traditional surveillance means used in manned aviation such as secondary radar, 1090 Mhz
multilateration, ADS-B and potentially FLARM will be used to locate manned aviation, as is done
currently. Some of these technologies may also be applicable to a number of unmanned aircraft,
however it is foreseen that aircraft will be connected to the UTM system (either directly or via the
GCS) over an IP-based communication link. This link will be used to provide the UTM system with
position and velocity data, either from the aircraft’s navigation system, or from a dedicated GNNS
receiver (e.g., Hook-on-Device). At the same time this link can be used to provide real time trajectory
forecast from the UAV to the UTM system. This enables better conflict prediction and resolution.
In addition to a UTM System based centralised surveillance, air-to-air surveillance may play a role in
collision avoidance. The benefit of air-to-air surveillance is that it does not rely on connectivity to the
UTM system, which may face continuity issues in areas of poor communication system coverage. Air-
to-air surveillance is also likely to have a lower latency than a centralised surveillance solution. A
downside of air-to-air surveillance is the difficulty to innovate whilst maintaining interoperability
between aircraft. Where a UTM system could act as a translation layer between various technologies,
air-to-air surveillance systems must be interoperable with each other. Introduction of new air-to-air
surveillance technologies can only be successful if backwards compatibility with existing technologies
is guaranteed, or the whole fleet is upgrading to the new technology at the same time.
Therefore, a U-Space air-to-air surveillance system should be focussed on enabling robust last resort
collision avoidance a strong safety barrier, whilst the centralised surveillance should be focussed on
enabling efficient tactical routing in order to achieve high operational performance within U-Space
while avoiding conflict situations.
139
more detail
Mode S SSR Mode- S Secondary Surveillance Used by most ANSPs Due to the limited Mode-S
Radar. for the surveillance address range (16 million
of aircraft in unique addresses
controlled airspace worldwide) and 1090 Mhz
frequency overload, Mode-S
cannot facilitate many
additional users. Use in U-
Space is mostly limited to
existing (manned aviation)
users.
ADS-B Automatic Dependent Implemented on Due to the limited Mode-S
Surveillance -Broadcast. A aircraft with a MTOM address range (16 million
technology that uses Mode-S exceeding 5700kg unique addresses
transponders to broadcast e.g., and/or maximum worldwide) and 1090 Mhz
position, velocity and identity cruising airspeed frequency overload in a
information. greater than KTAS number of geographic
:250kts areas, ADS-B cannot
facilitate many additional
users. Use in U-Space is
mostly limited to existing
(manned aviation) users.
Since ADS-B uses an
unencrypted link without
means to authenticate the
transmitter (like all Mode-S
based communication),
there are security concerns
mainly related to spoofing.
A secured form of ADS-B
that address this issue
would be welcomed.
Wide Area Wide area multilateration is a Used by various WAM works with signals
Multilateration technology that determines the ANSPs for the from the Mode-S
(WAM) position of aircraft by measuring surveillance of transponder on aircraft.
the difference in time of arrival aircraft in controlled Due to the limited Mode-S
of a signal transmitted from the airspace address range (16 million
aircraft’s transponder. unique addresses
worldwide) and 1090 Mhz
frequency overload in a
number of geographic
areas, Mode-S cannot
facilitate many additional
users. Use in U-Space is
mostly limited to existing
(manned aviation) users.
FLARM FLARM is a traffic awareness and Mature, proprietary,
warning system for General technology Used
Aviation. It provides increased mainly in gliders,
situation awareness by actively light single engine
warning the pilots of potential propeller aircraft and
traffic conflicts. HEMS.
140
more detail
IP based This technology uses an IP based In development, Standardised interfaces
Dependent communication system to various have to emerge from the
Surveillance transmit position, velocity and implementations are current implementations so
identity information to a central emerging (e.g., that the systems work in all
traffic tracking system. Droniq Hook-on- U-Space implementations.
Conceptually, additional Device)
information such as intended
flight path can be added to the
submitted dataset.
Air-to-Air In development (e.g.,
surveillance ACAS Xu, ACAS sXu)
Table 56 functions of U-Space surveillance means
3.8 Operational procedures

The safety and performance of the system enabling UAM is the result of the interaction of the three
constituents of the UAM system: people, procedures and equipment.
Procedures prescribe the interactions between people, between people and equipment and between
equipment. They consist of a predictable sequence of events, ensuring consistent outcomes, enabling
the UAM system to perform according to expectations in a safe manner.
Therefore, procedures in UAM should cater for nominal as well as non-nominal situations.
This chapter breaks down the need for operational procedures for UAM in various phases of the flight.
It focusses on procedures that are relevant of the U-Space implementation, and specifically on those
procedures that are specific to UAM.
3.8.1 Procedures in the pre-operational phase

The organisation phase, which addresses the pre-operational activities see the following procedures:
3.8.1.1 Procedures for establishing the UAM operator:

Registering as operator with the CAA and obtaining permission to operate
This establishes the conditions under which the operation is permitted
Registering the aircraft used for the UAM operation
3.8.1.2 Procedures for establishing the U-Space

This is an Airspace change process, involving ANSPs, USSPs, local authorities, CAA, vertiport
operators, UAM operator and other airspace users.
Including validation / approval by CAA
Publication in AIP etc.
3.8.1.3 Contractual agreement processes

Including agreements between the UAM operator, USSP, ANSP and Vertiports.
141
3.8.2 Procedures in the pre-flight phase
The pre-flight phase is addressing all activities associated to a flight, before the flight takes place.
3.8.2.1 Procedures for planning a flight

The flight planning procedures are to ensure that the planned flight is not conflicting with other
planned flights and does not exceed vertiport or airspace capacity so that, with a high level of
confidence, the flight can be executed as planned. The planning process will be initiated by the UAM
operator. Additionally, the vertiports, USSP and optionally ANSP and other UAM operators are
involved.
3.8.2.2 Procedures for changing of flight plan prior to flight

It is to be expected that not every flight will be executed as planned. In some cases, prior to
departure a change of the plan is needed. Procedures for changing a flight plan prior to flight will
need to be established. These procedures must at least address the following cases
- Change of timing (early / late departure and/or arrival)
- Change of routing
- Change of destination
- Change of vehicle
- Change of uncertainty – refinement of a plan to reduce the uncertainty, particularly take off
time uncertainty.
They should describe the actions taken by the operator as well as by the USSP and vertiport operators
to ensure the flight plan is not conflicting with other plans.
3.8.2.3 Procedures for deconfliction of flight plans

In case a flight plan is filed, or a change is to a plan is requested that is conflicting with pre-existing
flight plans, there is a need for a procedure to deconflict these plans. In the simplest case, the new
plan or the requested change which creates a new conflict is denied, however it seems that for
operational efficiency a more sophisticated procedure is desirable. Such a procedure could involve
proposing a similar, deconflicted plan optionally optimising the use of airspace by proposing
modifications to other plans as well. This procedure should not be limited to the pre-flight phase, it
should also cater for changes of flight plans of flights that are already active. Priorities might be
introduced to consider repetitive flights plans allowing planning certainty as well as classification of
goods, such as passenger flights. The deconfliction procedure needs to take in to account the priority
status of flights, for example for law-enforcement, medical or search and rescue operations.
CORUS’ ConOps [4] described a concept “Required time to act” which in essence carries over some
lessons from manned aviation. In manned aviation, strategic conflict resolution is usually considered
infeasible, but demand capacity balancing is analogous. Specifically in manned IFR flight in Europe
today:
changes to plans are extremely common

the uncertainties in those plans are large
plans are filed at a range of different times before flight
problems that need rectification are typically only visible when almost all plans are filed.
Drawing on this experience, Required Time to Act was put forward as a mechanism to resolve what
would otherwise be a systematic unfairness between different business models if “first to file” was
taken as the prioritisation scheme. RTTA proposes that strategic conflict resolution consider the plans
in three groups. Required time to act is a time offset from the start time of the flight; in manned
aviation terms the estimated “off block” time.
142
Plans which have not yet reached RTTA are ignored
Plans which have passed RTTA are considered as immutable
Plans which are at RTTA are deconflicted with the immutable flights and then each other
Yet to be worked out are what is RTTA, suggestions include 5 minutes, and how broad a time window
is considered as being “at RTTA”, for example 1 minute. Both of these choices and even the utility of
RTTA are highly dependent on the exact nature of UAS operation plans, in particular the extent to
which they are likely to conflict and likely change.
European regulation 2021/664 [23] views strategic conflict resolution as being the task of the U-space
service providers and that there may be multiple USSP active in any airspace. The acceptable means
of compliance and guidance material [31] for 2021/664 [23] proposes that the conflict detection
across multiple USSP can occur following ASTM standard F3548-21 [88], that is making use of the Inter-
USS [89]. 2021/664 [23] requires that strategic conflict resolution prioritise earlier filing time, as noted
CORUS [4] explained that this was inherently unfair.
3.8.3 Procedures during the flight
3.8.3.1 Movement on the surface of a vertiport

Especially on busier vertiports, ground movements need to be carefully orchestrated to optimise the
utilisation of FATOs/ stands and avoid deadlocks on taxiways. For efficient vertiport operations, it is
crucial that aircraft do not occupy the FATO’s longer than necessary. It should be avoided that aircraft
on the FATO are waiting for permission to move onwards while they are preventing other flights from
landing. For departing flights, this mean that they should not move onto the FATO area if they have
no clearance (explicit or implicit) to take-off. Landing aircraft should vacate FATOs as soon as practical.
Procedures for ground traffic management will need to be developed.
On less busy vertiports, the ground movement does not require much orchestration. It such cases the
traffic could be self-organised. Procedures for self-organising ground traffic need to be developed.
3.8.3.2 Procedures for departing a vertiport

To depart from a vertiport procedures are needed to verify
1) The aircraft is fit to fly (final checks) (it is better to be on the ground and wish to be up in
the air, than to be up in the air wishing to be back on the ground)
2) The flight plan is conflict free and the destination vertiport is available (as well as the
alternates)
3) The weather is permitting the flight
In case the vertiport is in controlled airspace, a clearance from ATC may be required as well unless
agreed otherwise in a Letter of Agreement (LoA).
Two flavours of the departure procedure will exist:
Departing from vertiports in controlled airspace/U-space airspace

Departing from vertiports outside controlled airspace / U-space airspace
3.8.3.3 Procedures for approaching and landing at vertiports.

Procedures are needed for approaching and landing at vertiport. At busy vertiport, orchestration of
airborne and surface traffic may be required to achieve safe operations at high throughput. At quieter
vertiports, self-organising procedures can be used to achieve safe and efficient operations.
143
Approaching and landing at vertiports inside controlled airspace / U-space airspace
Approaching and landing at vertiports outside controlled airspace / U-space airspace
3.8.3.4 Procedures to transit from one airspace to another

Procedures for leaving and entering areas of responsibility of ANSP / USSP must be agreed. The
following cases have been identified
Leaving U-Space airspace and entering controlled airspace

Leaving controlled airspace and entering U-Space airspace
Leaving uncontrolled airspace and entering U-Space airspace
Leaving uncontrolled airspace and entering controlled airspace
Leaving controlled airspace and entering uncontrolled airspace
Leaving U-Space airspace and entering uncontrolled airspace
3.8.3.5 Procedure for changing of flight plan during flight

In some use cases, the flight plan may need to be changed during flight on initiative of the operator
or commander of the aircraft.
These procedures to change the flight plan during the flight can be initiated by the commander
/operator of the aircraft.
Change of timing (early / late)
Change of routing
Change of destination
In all cases the UTM system will have to revalidate the plan which involves checking it against geo-
zones, conflicts with other traffic and capacity at the vertiport of destination. Upon agreement by
the UTM system, the proposed change becomes accepted in the active flight plan.
In other cases, the initiative to change the flight plan comes from the UTM system, e.g., when a
conflicting flight plan is submitted with higher priority, or when airspace is dynamically reconfigured.
The change is proposed to the commander and after accepting the change, the proposed change is
incorporated in the active flight plan.
3.8.3.6 Procedures for dynamic reconfiguration of airspace

Procedures applied by ATC
Procedures applied by actors involved in UAM operations
3.8.4 Emergency and Contingency procedures
3.8.4.1 Emergency procedures

Procedures will need to be developed for the following emergency cases: (initial list)
Aircraft low energy state (land as soon as possible)

Aircraft degraded technical state (land as soon as possible)
Aircraft degraded technical state (land at nearest suitable)
Medical situation of a passenger (land at nearest suitable)
3.8.4.2 Contingency procedures

Procedures will need to be developed for the following contingency cases: (initial list)
Intermittent loss of communication (single aircraft)
144
Loss of communication (single aircraft)
Loss of communication (multiple aircraft in same area)
Loss of communication (all aircraft in an area)
Mass deviation due to blocked vertiport
Mass deviation due to unexpected deteriorating weather
Diversion due to insufficient energy to reach destination (but not yet in low energy state)
3.9 CNS characteristics in urban environment

This section has three main objectives:
Identify the current CNS technologies (What is used?).

Identify the associated architecture required to support VLL and above VLL operations and answer
how to fit/integrate CNS in U-space.
(Most importantly) Bring to the industry and all the stakeholders a high-level performance-based
environment guide referring to CNS in U-space.
The used and followed concepts and methodology to develop this high-level performance-based
urban environment guide is focus on the concept of required total system performance (RTSP). When
looking at the ATM industry, we find the required ATM services and performance (RASP) which is the
criteria expressed as performance parameters and the values of these parameters to be met by the
ATM system, with a determined probability, to provide support to the approved service quality
specified for a particular environment. So, why don’t extrapolate these criteria but expressed as
operational and technology performance parameters to be met by the U-space industry in order to
provide approved safety and quality CNS performance for the particular urban environment.
This guide aim is to pave the path and propose a user’s guide to specify performance requirements
and make them achievable and measurable along all the flight phases of an operation as well as frame
this concept under the umbrella of service level agreement’s point of view supporting this operational
framework.
A small example to contextualize the latter. While pretending to perform an operation, the UAS
operator might have very good communications performances indicators in the area. However, the
area where operating has poor navigation and surveillance coverage or not even that. Having high
performance over a single CNS system it doesn’t bring anything. If the UAS has a very high accuracy
but very high latency there’s nothing to do with that high accuracy. So, a balance between all the
performance requirements across all CNS systems have to be managed and determined along all the
flight plan phases and the UAS operator must be aware of them.
The performance requirements and key indicators which will be analysed in order to be the spine of
this performance-based guide are:
 Integrity
 Continuity
 Functionality
 Availability
 Accuracy
 Latency
145
In order to achieve those objectives, 3 main tasks have been addressed:
Describe how a service and its performance model works in U-space in CNS environment.
Look at technologies and its limitations in U-space.
Describe the relations, interoperability, and performance between CNS systems.
To sum up, at the end of this sections, this operational framework CNS guide in urban environment
operations for UAS wants to let the UAS operators, USSPs and other stakeholders to derive and their
practical experience in operations, operational needs analysis and technical or technological needs.
State of the art
When we talk about operating in an urban environment, we find limitations due to the very low level
where the UAS have to operate. Houses, skyscrapers, various infrastructures attenuate, block and
reduce the signal-to-noise-ratio of radio signals that must interact with the UAS. These infrastructures
block the Global Navigation Satellite System (GNSS) signals that must be used by the UAS to navigate.
In addition, the Automatic Dependent Surveillance Broadcast that operate in the 1090 MHz band are
already beginning to be or almost reach saturation due to the large number of aircrafts.
By definition, “communications, navigation and surveillance are essential technological systems,

procedures and programs for pilots in the air and air traffic controllers on the ground. They facilitate
the process of establishing where the aircraft is and when and how it plans to arrive at its destination”.
So, with the coming increasing of commercial and non-commercial operations in urban environment
(EASA and NO EASA) CNS systems will play a fundamental and determining role to host the forecasts
of operations in a medium-long term time horizon.
3.9.1 Communication
This section discusses data communications. We cannot be technologically agnostic because the
objective of this chapter dedicated to CNS in urban environments is not to analyse all the available
technologies and choose which are the most appropriate or the best. The objective is to design a
performance-based guide that provides an analysis methodology so that the operator himself can
choose the technological solution that best suits the operational environment where he is going to
develop his operations.
Communications in an urban environment will be used by all kinds of vehicles and its function is to
provide the flight status of the operator's aircraft, their positions, speeds, directions, etc. and any
other relevant and useful information to share with the competent authorities such as weather
information for example.
As previously mentioned, due to the shielding, weakness and loss of the signals in these environments,
the first assumption is made. Since it will operate in physically unfriendly environments and the trend
of the electromagnetic spectrum is to become congested over time, communications will have to be
digital.
In the short term, communications will still be carried out through legacy systems such as voice
communications. But these have great drawbacks and disadvantages which have been aggravated
with the increase in air traffic. This happens because the aircraft that are in charge under the same
controller are tuned to the same frequency. With increasing operations, the likelihood of a pilot
accidentally accepting orders sent to another pilot is considerable.
To mitigate such an error, communications protocols have been implemented, but these slowed down
communications by having to repeat and duplicate the information sent. In addition, it requires a large
amount of time since first it is necessary to have the attention of the pilot or the controller and
146
secondly to give the order or send the request. And finally, thirdly, you will wait to receive the required
confirmation or information.
Traditionally, this problem has been mitigated by partitioning the radioelectric spectrum of saturated
air traffic control into smaller sectors. And each of these chunks is given to its own controller and so
each uses a different voice communication channel. However, this solution has two problems. The
first one is due to the increasing the number of frequencies we are increasing the amount of traffic
transfer operations between controllers. That increases the workload. This overload occurs when the
flights are transferred from one controller to another, which requires coordination between the
controllers themselves and a voice communication between the pilot. The second problem is that the
number of voice channels available is finite. And if we look at high-density airspaces such as large cities
and airport hubs in Europe, there may not be channels available within a certain period of time to
accommodate all drone operations in those environments.
In short, in some cases it will not be possible or feasible to increase the cuts and sectorization of the
radioelectric spectrum for voice communications. A new strategy is needed to cope with increased
demand. The solution is to base communications on data links adapted on the aviation and the UAM
need. These offer a better strategy and furnish the effective capacity of digital communications.
It is well known that the number of drones in our airspace is increasing and also that BVLOS operations
are very attractive for their business opportunities and use cases.
This requires a reliable command and control link (C2 Link). This link must have a wide coverage that
covers a large region and also be highly reliable to guarantee the safety of operations, the integrity of
the aircraft and the infrastructures and people on the ground. The technology chosen and previously
introduced, capable of meeting this need, is mobile networks. Mobile networks already offer
practically total coverage. They also offer excellent security levels.
Despite the fact that the solution in betting on digital communications using the current
telecommunications networks of mobile telephony has certain limitations due to its current layout
and design architecture.
Mobile phone antennas are designed to provide coverage to users with a mobile phone. And these, it
is at ground level. With which the antennas are oriented towards the ground. Here we detect the first
problem. There is a vast network coverage at ground level, however, UAS fly at a certain height.
Although we call the environment operations VLL, for reasons of performance and type of operation,
the UAS fly to certain levels of the ground where the coverage and quality of the signal is not good
enough to reach the levels of integrity, continuity, functionality, and availability.
Mobile phone companies and operators should make an investment in doubling the infrastructure to
reorient the antennas towards the sky. But it is evident that such investment, with the current
standards of the number of operations that are being carried out, cannot cover the costs of this type
of deployment.
147
Figure 25 Current Mobile Network Coverage
The urban environment has insufficient users to cover the current cost. During the coming years when
increasing the urban environment operations, mobile company operators will be more interesting and
more affordable talking in a cost-effective way.
The proposal presented below is an iteration of the current connectivity between an aircraft and the
ground control station through the conventional command and control link (C2 Link) that we already
know is limited by signal obstructions in the urban environment. To increase said connectivity and
number of operations while maintaining and ensuring the key indicators that are working on in this
section of the operational framework (integrity, continuity, functionality and availability). To do this,
focus should be on the next evolutionary leap in communications and have connectivity from the GCS
to mobile phone stations that provide access to U-space services and feed the aircraft with important
information.
Finally, and more interesting and relevant is to deploy a real and effective coverage of mobile
communications both, GCS and UAS.
148
Figure 26 Roadmap to implement Mobile Network Communication Architecture
3.9.2 Navigation
Next, we are going to address the aspect of air navigation. Generally, navigating through the air is
almost the same as navigating on land or sea. This includes planning the route, controlling the
movement and the movement of the vehicle from a starting point to an end point. But navigating
through the air has certain differences to be aware of. That make it more difficult to successfully
navigate. And it is even more complicated if these flights take place in urban environments densely
occupied by tall buildings and complex infrastructures. The Global Navigation Satellite System (GNSS)
is prone to data degradation or complete signal loss due to multipath effects, interference, or antenna
dimming. Added to this, there are other problems and risks that must be taken into account and be
mitigated. An example of this is illegal interference such as jamming and spoofing. Low-cost
technology solutions and systems for a civilian public and commercial sector are even more vulnerable
to these attacks.
The first important aspect is speed. Aircraft flies at relatively higher speeds than vehicles that travel
on the earth's surface. This first consideration reduces the time you have to calculate your position
during the flight. Also, depending on the type of aircraft (fixed wings, rotary wings, VTOLs) they cannot
be stopped in the air. Another related consideration is the issue of fuel and / or its power sources.
When planning a mission or flight plan, among the dozens or hundreds of parameters to study and
define one of the most important is fuel / energy. How much energy will we need to go from point A
to point B at a certain speed, height, direction, turns, the different changes that we will have to make
to maintain correct navigation and as accurate as possible.
Finally, navigation accuracy is a central point in the collision prevention. An event, incident or accident
in air terms usually has fatal consequences and outcomes, either accounting for material damage or
human damage. Well, constant knowledge of the position is extremely fundamental.
The navigation techniques and flight procedures for the air navigation are subject to whether the
aircraft is operating under visual or instrument flight rules.
Once we have introduced and defined the art of navigating through the air, we are going to land
navigation in the context that concerns us. What is to analyse what technologies are currently assisting
UAS and their limitations in urban environments and how to provide a better navigation technology
to assist operations in urban environments, thus being able to reduce safety distances, further
149
strengthening safety of the aircraft, their payloads, the people and infrastructures that are on the
ground. And finally, in operational terms, to be able to host more operations in the same airspace
structure thanks to reducing said separation distances between aircraft. Increased capacity, and
consequently the demand of the industry.
State of the art of navigation
The conventional navigation that we are used to with Ground-based radio-navigation systems (NDB,
VOR, DME, ILS…) does not apply in the environment we are working in or with the type of aircraft that
operate in it. For reasons such as that the receivers have not and never will be miniaturized to be on-
boarded in UAS. And the most relevant reason is that the accuracy is too low for the intended
purposes.
So, we have to look at other technologies and solutions and mix some of them to enhance the
operational and technical performance requirements. Some technologies are still in an early stage of
development and testing and have not been implemented in large environments to validate them.
However, what is intended to be enhanced and promoted is that the operator must seek and
implement the best solution for navigation and positioning of their aircrafts. As it has been doing in
recent years, it will be a mix and match of these technologies. This leads to better performance in
addition to the fact that when different solutions are combined and implemented, greater redundancy
is achieved. Something vital and basic in the aeronautical sector.
The main used and tested current technologies for positioning and navigation for UAS that we can find
and work with are based on GNSS:
 GNSS: The Global Navigation Satellite System involves a constellation of satellites orbiting at
about twenty thousand kilometres altitude over the earth surface, continuously transmitting
signals that enable users to determine their position with global coverage. This solution is the
most basic and cheapest. There are 6 constellations available (2 of them are in their final phase
of deployment). It has drawbacks such as the need for a minimum of satellites arranged in line
of sight. The waves cannot pass through obstacles such as buildings and mountains.
o Galileo: Galileo is Europe’s own global navigation satellite system, providing a highly accurate,
guaranteed global positioning service under civilian control. It is inter-operable with GPS and
GLONASS. Galileo receivers compute their position in the Galileo Reference System using
satellite technology and based on triangulation principles.
o GPS: The GPS is a space-based global navigation satellite system (GNSS) that provides reliable
positioning, navigation, and timing services to civilian and military users on a continuous
worldwide basis freely available to all. It is maintained by the United States government and
is freely accessible by anyone with a GPS receiver.
o GLONASS: Is a radio-based satellite navigation system operated for the Russian government
by the Russian Space Forces. It is an alternative and complementary to the United States' GPS,
the Chinese Compass navigation system, and the planned Galileo positioning system of the
European Union.
o Beidou: The BeiDou Navigation Satellite System (BDS), also known as Beidou-2, is a project by
China to develop an independent global satellite navigation system. BeiDou System is not an
extension to the previously deployed Beidou-1, but a new GNSS similar in principle to GPS and
Galileo.
150
o QZSS: QZSS is a Radio Navigation Satellite System. It will enable a better reception in urban
areas, in particular in Japan, by increasing accuracy and continuity, essentially for position-
based application.
o IRNSS: Indian Regional Navigation Satellite System. This constellation is clearly focused to be
useful for Indian users and those operating at a range of 1500 to 2000 km of India boundaries.
However, using stand-alone GNSS is inadequately precise for UAS navigation in urban environment,
due to the performance it delivers. Let’s have a look on how it works. A GPS receiver listens to satellites
to measure its distance to each sat, at a given time, and thus its location by simple geometry
calculation. The distance to a sat is measure by the time it takes for this sat’s GPS signal to travel to
the GPS receiver. To do that, each sat emits a unique Pseudo Random Noise signal (PRN), or C/A code,
repeated at a frequency of 1,023 MHz. The PRN period length is 1 ms or, due to the speed of light of
300.000.000 m/sec, about 290 meters. The distance measurement precision is about 1% of the
measured signal wavelength. This result in a standard GPS precision is about more or less 3 meters.
3 meters uncertainty is not good enough for urban UAS navigation. To improve this precision, we can
do two main things:
Measure a higher frequency signal (smaller wavelength than the PRN)

Correct measurements errors by subtracting them with differential trick or model errors, when
possible, to supress them.
Along the first option, the use of a higher frequency signal, luckily, GNSS standards use two high
frequency carrier signals. (L1: 1575 MHz, L2: 1227 MHz) on which the PRN is transmitted.
By measuring the L1 carrier signal phase, at 1575 MHz, instead of the PRN at 1 MHz, we can measure
a signal with a wavelength of 19 cm. And thus, a theoretical distance precision of more or less 2mm.
However, such 2mm precision is not reached because of signal/time measurements errors due to:
Satellites internal clocks errors

Satellites orbit errors
Ionospheric/tropospheric signal propagation delays
Receiver noise
Signal travel distance errors due to multipath reflections.
In order to correct or even supress these errors we can feed the GPS receiver with correction data. On
this statement, there are different approaches. Some of them with the more interest for UAS
operations in urban environment are
Satellite Based Augmentation System (SBAS)

Differential GPS approach (DGNSS)
Real Time Kinematics (RTK)
Precise Point Positioning (PPP)
Augmentation of GNSS means improving the navigation system's attributes, such as accuracy,
reliability, and availability, through the integration of external information into the calculation
process. There are many such systems in place, and they are generally named or described based on
how the GNSS sensor receives the external information.
A Satellite-based Augmentation System (SBAS) is a civil aviation safety-critical system that supports
wide-area or regional augmentation – even continental scale - through the use of geostationary
satellites which broadcast the augmentation information. A SBAS augments primary GNSS
constellations by providing geostationary ranging, integrity and correction information. While the
main goal of SBAS is to provide integrity assurance, it also increases the accuracy with position errors
below 1 meter. With SBAS we can achieve better accuracy when compared to using only GNSS.
151
SBAS but has certain limitations such as that it is necessary to be in line of sight. We can automatically
determine that for applications in the environments we are dealing with, where there are obstacles,
this is an impediment.
Next, we will highlight the SBAS systems currently available operationally. Each of them covers a
different region of the planet. In the United States we find the WAAS. In Japan there is MSAS, GAGAN
for India and SDCM in Russia. And finally, but not least, indeed is the one that with more relevancy in
this discussion is EGNOS.
The European Geostationary Navigation Overlay Service (EGNOS) is Europe's regional satellite-based
augmentation system (SBAS) that is used to improve the performance of global navigation satellite
systems (GNSSs), such as GPS and Galileo. EGNOS uses GNSS measurements taken by accurately
located reference stations deployed across Europe.
All measured GNSS errors are transferred to a central computing centre, where differential corrections
and integrity messages are calculated. These calculations are then broadcast over the covered area
using geostationary satellites that serve as an augmentation, or overlay, to the original GNSS message.
As a result, EGNOS improves the accuracy and reliability of GNSS positioning information, while also
providing a crucial integrity message regarding the continuity and availability of a signal. In addition,
EGNOS also transmits an extremely accurate universal time signal.
Differential GNSS (DGNSS) is a kind of GNSS augmentation system based on an enhancement to

primary GNSS constellations information by the use of a network of ground-based reference stations
which enable the broadcasting of differential information to the user to improve the accuracy of his
position, but the integrity is not assured.
PPP is a positioning technique that removes or models GNSS system errors to provide a high level of
position accuracy from a single receiver. A PPP solution depends on GNSS satellite clock and orbit
corrections, generated from a network of global reference stations. Once the corrections are
calculated, they are delivered to the end user via satellite or over the Internet. These corrections are
used by the receiver, resulting in decimetre-level or better positioning with no base station required.
PPP delivers accuracy up to 3 centimetres. A typical PPP solution requires a period of time to converge
to decimetre accuracy in order to resolve any local biases such as the atmospheric conditions,
multipath environment and satellite geometry. The actual accuracy achieved, and the convergence
time required is dependent on the quality of the corrections and how they are applied in the receiver.
Similar in structure to an SBAS system, a PPP system provides corrections to a receiver to increase
position accuracy. However, PPP systems typically provide a greater level of accuracy and charge a fee
to access the corrections. PPP systems also allow a single correction stream to be used worldwide,
while SBAS systems are regional.
RTK stands for Real-Time Kinematic and is a technique that uses carrier-based ranging and provides
ranges and therefore positions that are orders of magnitude more precise than those available
through code-based positioning. RTK techniques are complicated. The basic concept is to reduce and
remove errors common to a base station and rover pair.
RTK is used for applications that require higher accuracies, such as centimetre-level positioning, up to
1 cm + 1 ppm accuracy.
The UAS determine their position using algorithms that incorporate ambiguity resolution and
differential correction. Corrections are as accurate as the known location of the base station and the
quality of the base station’s satellite observations. The location of the base antenna selection is
152
important for minimizing environmental effects such as interference and multipath, as is the quality
of the base station and UAS receivers and antennas.
System comparison
DGNSS & RTK
 Both require a precisely known position of the base station.

 Both require a transmission link between the base and UAS.
 The maximum distance between the base and the UAS can be much greater for DGNSS.
 RTK (carrier phase use), is a way more accurate than DGNSS (PRN use)
SBAS & PPP
 Both have the same working architecture.

 PPP use carrier phase while SBAS using PRN
 PPP gets more accurate corrections and is overall more accurate.
 SBAS is free where PPP isn’t.
 SBAS works instantly whereas long convergence time of PPP (EKF).
 SBAS is regional and PPP is global.
DGNSS & SBAS
 Same range of accuracy (i.e., lower than other methods).

 DGNSS require a base station, SBAS doesn’t.
 DGNSS requires a link with UAS, SBAS doesn’t.
 DGNSS HW and setup is more complex than SBAS.
RTK & PPP
 Same range of accuracy (i.e., best of all methods)

 RTK requires a base station, PPP doesn’t.
 RTK requires a link with UAS, PPP doesn’t.
 RTK WH and setup is more complex than PPP.
 RTK is free, PPP isn’t.
 RTK works at a maximum 10 Km from base, PPP works globally (no base needed).
3.9.3 Surveillance
When we approach the aspect of surveillance of the air traffic that circulates daily in our skies, it’s one
of the most basic and main functions of air traffic management (ATM). In the current operational
framework, such surveillance is mainly achieved through what we call Secondary Surveillance Radars
(SSR) and Automatic Dependence Surveillance (ADS).
This data is displayed on the screens that air traffic controllers use to solve potential conflicts that may
arise in both strategic and tactical phases. To avoid work overload, the airspace is divided into sectors
and each sector is assigned to a team of controllers.
But when we try to apply these solutions in the urban environment, these technologies are not valid
for reasons that we have repeated several times. In the first place, normally the UAS that operate in
these environments tend to be of reduced dimensions, and the speeds to operate safely between
buildings, on people cannot be very fast. That is, compared to manned aviation, the speed is very low.
153
Therefore, due to their size and speed, they are easy to confuse with birds. Second, there are no easy
methods for ordering the screen when the radar is aimed at urban environments with many moving
objects that need to be filtered, such as cars, pedestrians, etc.
There are specialized systems for UAS detection, such as electrooptically coupled X-band radars that
can detect typical UAS within a range of 1 km.
The use of the X-band, the high bandwidth and the low power consumption are some of its most
outstanding characteristics compared to other technologies. Signal and data processing is fully
programmable using the latest high-resolution auto-tracking and target detection techniques to meet
surveillance requirements
However, we again run into the problem of line of sight. These types of solutions are not compatible
in urban environments due to line-of-sight requirements. These systems can be used to protect
airports, power plants, or other critical infrastructure. So, we have to go for other approaches based
on the detection of radio frequency (RF) emissions. Those systems shall detect UAS based on
commonly used frequencies such as 35MHz, 430MHz, 460MHz, 2.4GHz, or 5.8GHz, all commonly used
for communication with UAS.
The way to tackle this surveillance architecture and accomplish and accommodate those
performance-based requirements lays on a surveillance architecture based on a mix of ground and air
surveillance technologies.
In order to detect, identify and monitor UAS the industry has to deploy this mix of ground and air
systems with some of the following crucial capabilities
 Capacity to monitor and detect any drone at any frequency in real-time.

 Cover a wide range of surface.
 Capacity to cover full dome (360º & 90º) with tracking accuracy.
 Scalability for huge sites.
 Compatible to detect and track 3G, 4G and 5G in mobile network connectivity environment.
 Locate UAS and its operators and identify the UAS model and brand.
 Wide frequency range of detection (9KHz to 20 GHz).
Finally, and as the main objective of CORUS-XUAM and the development of U-space and its services,
we have to talk about the services that should be part of the solution architecture to provide
surveillance in operations with UAS in urban environments. Since cities will be the first hubs and points
of interest where U-space services will be tested through service providers.
Services such as Network Identification, Traffic Information and Tracking will be essential to provide
these levels of surveillance thanks to the technologies of mobile phone providers among others.
Through the network identification service within U-space airspace operationally supports traffic
safety and the traceability of the unmanned aircraft during its flight. Indeed, based on this
information, the USSPs can share UAS traffic information between themselves and therefore provide
traffic information to UAS operations. In order to obtain this information on other traffic there are
ground station systems with the capabilities described before. Other sources that make this
information available is through the network identification system or through other technical means
(e.g., from manned aircraft ADS-B, transponders, FLARM…etc).
3.9.4 Conclusions
After the previous analysis of communication, navigation and surveillance technologies and
methodologies, we reached the point of discussing and proposing a way to insert operations in the
154
urban environment and leaving the framework open for the industry itself, service providers and
operators to take base this proposal, mature, expand and work with the advancement, development,
and own maturation of existing technologies as well as those to come. In the same way as the approval
of regulations.
But first of all, it is important to address some questions to consider that will help guide the strategy
of defining operations, as well as their performance in the urban environment. These questions to
consider are those that an operator must consider when defining, designing, and choosing the
technologies and methodologies that are not only the most appropriate to achieve their objectives
but also to achieve the performance parameters and the values of these parameters to be met and
agreed by all the stakeholders.
What level of position is required for my operation to be successful?

What level of communication is required for my operation to be successful?
What level of surveillance I have to face-off and be electronically conspicuous and collaborative?
Is it practical to set up the newest and expensive equipment?
Do I have a reliable communication link?
Where do I need my operations and core business to work?
What is the geographical environment like?
How congested is the environment?
So, the general description of the approach is a trade-off between the U-space service providers
(USSPs) and the UAS operators that requests to operate in an urban environment. On the one hand,
regulation, standards, agencies and various administrations, service providers must define minimum
requirements to be able to operate in an urban environment such as a city, near an airport, on top of
crowds of people at mass events. …etc. They must propose the minimum requirements of required
communication, required navigation, and required surveillance performances to accomplish.
On the other hand, the UAS operators shall analyse those minimum performance CNS requirements
to reach and manage to combine whatever technologies needed to be able to fit in a high demand
and capacity environment such as the urban where the operational stress and workload is
considerable.
The minimum performance CNS requirements that suit a specific urban area are not necessarily the
same as those of another urban area that may have different traffic density, traffic patterns,
geographical characteristics, better CNS technologies coverage…etc. However, the process to guide
and approve the safe and secure development of those operations will be the same.
The UAS operators requests to their respective member state authority, U-space service provider or
the current authority responsible to accommodate and authorize to operate in an urban environment.
The UAS operator will be replied with the minimum performance-based requirements of CNS for this
particular area that has to reach and demonstrates the operational and technological capabilities to
achieve.
Note: The numeric values for the parameters (Integrity, Continuity, Functionality, Availability,
Accuracy and Latency) are randomly assigned. It’s just for graphical purposes.
155
Figure 27 CNS Required System Performance Proposal
The UAS operator has the due and responsibility to make sure their operation will achieve this
minimum performance levels. While better and greater are the levels of assurance the better, faster,
and easier will be served and accommodated in the urban environment to start its operations.
Figure 28 CNS Required System Performance Achievements
After the analysis of the environment, the density will be operating, the mobile network coverage, the
weather conditions, the geographical distribution of the terrain, the access to GNSS…among many
topics, the UAS operator will be able to detect the performance gaps and apply the corrective
measures as better equip the aircrafts, the ground control station…etc
What is essential and fundamental is the performance-based approach. That is, let it to the industry
to set goals and measure in an objective way. In this way, we can establish and determine that the
metrics that will later qualify the requirements for access to the urban environment should have a
SMART (Specific – Measurable – Accurate – Relevant – Timely) focus.
3.10 Risk assessment classes

This section aims at proposing a framework to classify the risks of Urban Air Mobility operations, by
unmanned aircraft but also encompassing Urban Air Mobility by manned operations.
Air and ground risks are taken into account for operations inside the city (inner-city operations) and
operations linking two or several urbanized areas (inter-cities operations).
3.10.1 Air risk classification
156
The air risk must be assessed considering different combinations of aircraft encounters, whether the
aircraft is manned or unmanned, or having people on-board or not.
The likelihood to have encounters between any type of UAV and manned aircraft differs whether the
operations occur in an environment close to airport, aerodrome or heliport, or above the countryside.
The possibility to mitigate this risk will depend on the type of U-space and ATM services provided and
aircraft equipage. Some dedicated airspace structures may also play a role by clearly segregating
operations of any kind: manned- unmanned, unmanned parcel transportation – unmanned passenger
transportation, etc…
Then the following pairs are to be taken into account:
Separation between UAVs without people on-board (neither passengers nor human flight
supervisor
Separation between UAVs and manned aircraft
Separation between UAVs and UAVs with people on-board.
Separation between UAV carrying people and manned aircraft.
Separation between two UAV carrying people.
Inside UAV without people on-board, a distinction between those carrying nothing or non-critical
goods and the other could be introduced. For the latter, the air risk is limited but would dramatically
increase the ground risk, by directly impacting a person’s life (e.g., if the UAV carries blood or an
organ), or by polluting water for instance (e.g., UAV carries dangerous goods).
3.10.2 Ground risk classification

The ground risk classification is divided into two specific operational environments. On one hand,
there are the inner-city UAV operations, whereas on the other hand the inter-cities UAV operations.
In the first case, the whole flight will mainly cover urbanized areas with infrastructures dedicated to
citizens way of life, including facilities for UAV operations such as vertiports or parcels hubs. Density
of people in these areas may be very high.
In the second case the flight will be performed above urbanized areas and the other part will be mostly
above sparsely or non-populated areas. Density of population should be low.
In that case the same ground risks as in the first case have to be encompassed but an extended
(compared to the inner-city one) ground environmental risk may be added. Probably the specificities
of the mapping around and between the cities will also impact the ground risk negatively.
3.10.3Transportation of people in U-Space

Transportation of people in U-space, whether they are by unmanned aircraft or by manned aircraft is
one of the main drivers of the risk assessment classes in U-space.
At the early stage of U-space implementation, manned and unmanned operations will be segregated,
and this will require a minimum coordination between ATCO and USSP in airspace class A to E.
In class G, the aeronautical information will be the key.
The question is whether UAV carrying passengers could be consider as “manned aircraft «when having
a pilot on-board, or not. Will the pilot have a role to steer the aircraft or just supervise the flight?
157
Once segregation concept will be removed and UAV operations well integrated, the risk will be
mitigated by services and aircraft equipage. At this stage of U-space, UAV carrying passengers will no
longer have a pilot on-board, and we can suppose that services and equipage will provide a sufficient
level of safety.
3.10.4 Transportation of goods in U-space

The transportation of goods in U-space, whether it is considered inner-city or inter-city, mainly
impacts the ground risk.
On a ground risk point of view, we could divide the risk into two different classes:
- The risk impacts people, animals and nature.
- The risk impacts only structures such as buildings.
Goods collision with the ground may directly or indirectly impacts people, animals or nature.
By falling directly onto one of those, by spreading dangerous substances on the ground or in the water
or if the goods transported are medicals (e.g., bloods, organs), by indirectly impacting people or
animals to whom the goods were intended.
In case of collision only with structures, without reaching people, animals or nature, the risk is only
material.
To introduce distinction in the goods, we can propose a goods classification by risk consequences:
Impacted
elements
People Animals Nature Structures
Type
of goods
Dangerous
goods High risk High risk High risk Medium risk
Medicals High Risk High risk None None

Big and/or
heavy parcel High risk High risk High risk High risk
Small parcel
with dangerous Medium to high Medium to high
Low risk Low risk
risk risk
shape
Small and/or Low to medium Low to medium
light parcel Low risk Low risk
risk risk
Table 57 Goods classification by risk consequences
158
4 Operational Performance of UAM
4.1 Introduction
The operational performance of Urban Air Mobility (UAM) systems is critical for the safe and effective
integration of these systems into urban airspace. In this chapter, we will explore the various factors
that impact the operational performance of UAM, including the environment in which they will
operate, the assumptions made about their capabilities and limitations, and the performance and
operational requirements that must be met. The section on Performance and Operational
Requirements is particularly important as it presents the results of the analysis and demonstrates how
UAM systems meet the necessary performance and operational requirements.
The chapter is the output of CORUS-XUAM Task 3.2, which is part of CORUS-XUAM work package 3. It
builds upon the use cases stated in the Definition of the Operational Framework section analysing the
nominal use cases regarding performance and operational perspective incorporating the input from
various Very Large Demonstrations (VLDs) through WP5 coordination.
The later chapters, addressing Tasks 3.3 and 3.4, will further modify and extend these use cases, and
WP4 will analyse how U-space services meet the needs of these use cases, describing in detail the
sequences and information flows of the services.
4.2 Environment Description

This section describes the context on which Urban Air Mobility (UAM) Operations are expected to
happen, and under which conditions the project CORUS-XUAM foresee the nominal Use Cases (UCs)
to occur.
According to EASA [107], UAM is a new safe, secure and more sustainable air transportation system
for passengers and cargo intended for, but not exclusively bound to, urban environments, enabled by
new technologies and integrated into multimodal transportation systems. The transportation is
performed by electric aircraft taking off and landing vertically, remotely piloted or with a pilot on
board
These conditions include different elements, including the capabilities horizons, the traffic prognosis
of this operations and other concepts surrounding these operations, like the vertiport environment,
the airspace type and structure, new flight rules to accommodate this operations, different type of
vehicles, the rules of separation, and the different phases that comprises a single operation.
The selection of specific condition within the environment section describes the different scenarios, a
list of the different scenarios used to describe the UCs are described in section 4.4
4.2.1 Maturity Levels

This section describes the progression of UAM implementation in a sequence of maturity levels.
Rather than describing a timeline, we describe the progression in terms of capabilities of the U-space
system and its constituents.
The levels presented in this section are inspired by NASA’s Urban Air Maturity Level scale. Whilst the
levels presented are similar, they are not the same due to a slightly different approach in Europe’s U-
space regulation. For a description of the NASA UML see Kenneth H. Goodrich & Colin R. Theodore
(2021): Description of the NASA Urban Air Mobility Maturity Level (UML) Scale.
159
Although this work is mainly focussed on the development of Urban Air Mobility, interoperability with
other types of operations occurring within the same airspace need to be considered as well. UAM
operations will be typically flying in the lower airspace but are not restricted to Very Low Level (VLL).
The type of operations in U-space:
 Urban Air Mobility
o Passenger transport operations
o Transportation of goods
 Aerial work, such as operations for
o agriculture, construction, photography, surveying, observation and patrol, aerial

advertisement
 Government / State operations
o Law Enforcement
o Search and Rescue
o Helicopter Emergency Medical Services
4.2.1.1 Maturity Level 1: Pre-operational trials and validation

The first phase, which is the phase we are entering now, covers qualification, certification, and
operational demonstrations in temporary reserved environments.
In this phase, most vehicles involved will be pre-operational prototypes that are nearing the
completion of the type certification process. Initially, Aircraft Certification regulation will likely require
that UAM passenger transport operations will be conducted with a pilot on board, as certification
baselines for remote-controlled or autonomous flying aircraft with passengers on board are not yet
established. Early good transport operations, aerial work and government / state operations may be
flying without a pilot on-board.
For trials with unmanned passenger carrying aircraft, as well as larger scale transport drones, the
airspace in this phase is characterised as a restricted sandbox environment, limited to traffic involved
in the trials. Temporary Reserved Airspaces are likely often used in this phase, to ensure that other,
non-involved aircraft will not intervene and pose risk to the trials.
When the trials focus on UAM aircraft operating with a pilot on-board, standard flight rules may be
applied and direct VHF voice communications with ATC can be facilitate the integration of the trial
existing airspace structure be without restricting other operations in the vicinity.
Other trials and validations may focus on assessing the viability of supporting U-space / UTM
implementations. This includes testing of communication, navigation and surveillance technologies as
well as higher level functions of the UTM system.
Early BVLOS operations outside U-Space trial areas can be accommodates if they are segregated from
other air traffic. BLVOS operations pose a challenge to existing airspace users, especially since the UA
will be difficult to see by VFR pilot and the UA will not have Detect (and Avoid) technology that can
warn the remote pilot or otherwise prevent collision hazard with all types of possibly conflicting traffic.
160
To avoid airspace conflicts and related collision hazards, the BVLOS flights can be accommodated in a
restricted area, danger area, (temporarily) reserved airspace or by other means.
Whilst such approach enables safe operation of BVLOS alongside manned traffic in segregated
airspace volumes, it leads to inefficient use of airspace. Since existing airspace users, especially those
in uncontrolled airspace, cannot be notified on short notice about activation of temporarily reserved
airspace, BVLOS flights requiring segregation need to be planned well in advance. The conventional
mechanism of notifying other airspace users by NOTAMs limits the flexibility and efficiency of
reconfiguring airspace to accommodate BVLOS operations.
4.2.1.2 Maturity Level 2: Early commercial operations

Early commercial UAM operations will take place in a Maturity Level 2 environment.
The environment is characterised by low traffic levels, as there are only a few vertiports and UAM
routes in the urban environment, and operations will not occur on large scales.
Initial Aircraft Certification rules will require that UAM passenger transport operations are be
conducted with a pilot on board. This allows for UAM to be conducted under current air traffic
management practices, especially with respect to flight rules. However, in parallel, early U-space
implementations will emerge where the Traffic Services are provided by U-space Service Providers.
Within these early U-spaces, the unmanned traffic will have to be segregated from pilot-on-board
operations that fly under IFR/VFR flight rules as there are no regulations existing that support mixed
manned / unmanned traffic. Pilot-on-board UAM operations in U-space may fly under alternative
flight rules that allow the integration of manned & unmanned U-space traffic in the same airspace.
Initial U-space services are provided (2021/664, network identification service, geo-awareness service,
UAS flight authorisation service and traffic information service), by a singular or multiple USSPs and a
single CISP.
4.2.1.3 Maturity Level 3: Increasing automation level

Maturity level 3 is a transitional phase, still seeing low density of operations, but with increasing
capability of both the aircraft as well as the U-space systems.
In UML 3 the integration between U-space operations and the ground infrastructure is increased.
Vertiports will connect to the UTM system in support of DCB and contingency planning and conflict
resolution services are expanded, covering both the pre-flight as the in-flight phase.
Services to support both VFR and IFR flights in U-space are introduced, allowing integration of existing
manned aviation in U-space. This requires technologies to augment or replace the See and Avoid
procedures used for VFR.
The CNS infrastructure to support these U-space service will be gradually rolled out. The surveillance
becomes sufficiently good that U-space can provide tactical separation. The communication becomes
reliable enough to reduce separation distances. This will enable the increase of traffic density and
complexity for the next UML step.
The integration between ATM and UTM will allow transfer of aircraft between U-space and other
airspace and facilitate dynamic reconfiguration of airspace to facilitate traffic that is not compatible
to U-space.
U-space service providers are demonstrating operational maturity in support of certification for
denser traffic operations that include remote controlled passenger carrying flights.
161
4.2.1.4 Maturity Level 4: Large scale operations
UAM Maturity level 4 will see increasing levels of traffic density. In the U-spaces with medium traffic
densities, the operations are relying on the UTM system including for both pre-flight and in-flight
(tactical) separation. This level sees a high level of automation and the possibility of autonomous
operations in specific phases of flight, e.g., to deal with loss-of-link situation.
UML 4 is the first level with remotely piloted operations of passenger flights (single pilot per vehicle).
UAM Maturity level 4 is assumed for larger scale vertiports operations.
4.2.1.5 Further evolution

Long term evolution of the U-space environment will see increasing traffic densities and complexities.
Reliance on the supporting UTM systems for operational performance and operational safety will
increase.
- Integration of GA, need for retraining of users
- Hight density & complexity
- Medium/High risk level
- More Autonomous operations
- Services more focused on tactical capabilities (Tactical De-confliction)
4.2.2 Traffic Prognosis

- Low density traffic with segregation from manned aviation, where this traffic is assumed to be low
enough to be manageable by strategic conflict resolution alone.
- High density urban operations with no segregation.
4.2.3 Types of environments

The SESAR JU defines U-space16 as “an enabling framework designed to facilitate any kind of routine
mission, in all classes of airspace and all types of environments - even the most congested -...” This
encompasses Urban Air Mobility, which is indeed the target of CORUS-XUAM. The notion of
environment, as a subset of urban scope, is relevant for the deployment of U-space in support of UAM,
influencing aspects such as functionalities of the services, level of required performance, types of
operations supported or airspace structuring. Requirements resulting from the execution of
demonstrations in each (sub) environment might be different.
In this sense, and with a view of better addressing the diverse use cases, CORUS-XUAM VLD addresses
the following UAM environments which are defined in the CORUS-XUAM Demonstration Plan (D5.1)
[91], also depicted in Figure 29 below:
 Urban environment, defined as an area either within the urban centre or a dense urban
cluster of a city [92];
16
https://www.sesarju.eu/U-space
162
 Sub-urban (residential) environment, defined as an area within a semi-dense urban cluster
or a peri-urban cell [92] used mainly for residential purposes;
 Sub-urban (industrial) environment, defined as an area within a semi-dense urban cluster or
a peri-urban cell [92] used mainly for industrial activities;
 Sub-urban (intercity) environment, defined as a succession of semi-dense urban clusters and
peri-urban cells linking two close cities.
Figure 29: CORUS-XUAM Operational Environments
In addition to the defined environments, controlled airspace within urban and sub-urban areas
corresponds to areas belonging to any of the above environments within airspace managed by ATC.
From the point of view of operational environments, the scope of CORUS-XUAM is:
 Mixed operations/missions in urban and suburban environments and in an airport

environment, including at least:
o Seamless door-to-door transport of people, including UAM flight between different
cities (inter-city scenario);
o Seamless door-to-door transport of goods (logistics services);
o Depot-to-depot transport of goods (logistics services);
o Visual and data acquisition and aerial works, and in particular:
 UAM for emergency operations;
 Surveillance of people traffics flows and infrastructure.
 Involvement of a dedicated vertiport placed in a city.
Moreover, CORUS-XUAM VLD targets the following operational and technical aspects:
 Seamless transition between different UTM systems;

 Seamless coexistence of different USSP;
 Automated flight and flight planning management;
 Ad-hoc weather information provision;
163
 Mission planning management;
 Collaboration and interface between ATM/ATC and USSP/U-space;
 Use of eVTOL and fixed-wing UAM solutions;
 Use of UAM of different performances and power supplies (electric/fuel);
 Involvement of small drones for specific missions in a mixed environment.
4.2.4 Vertiport Environment

As part of future Urban Air Mobility (UAM) ‘vertiports’ will serve as landing and take-off sites for air
taxis, i.e., passenger carrying VTOLs. Vertiports will be equipped with a number of facilities, including
charging facilities for electrically operated vertical take-off and landing (eVTOL) vehicles as well as
passenger boarding, de-boarding, and waiting areas. Vertiports with different scales changing to the
demand and environment constraints serve for public usage and each one has the role of vertiport
operator.
Their locations need to be depicted in the VFR map and all vertiports will be compliant with local and
regional rules. In the absence of clear standards, the concept of vertiports is largely inspired by
heliports, including the Touchdown and Lift-off (TLOF) area, the Final Approach and Take-off (FATO)
area, the Safety Area around the FATO and stands as applicable. Vertiports may be located in any area,
but realistically predominantly in urban areas and close to airports, permitting air taxi operations
within cities and between cities and airports.
Additionally, while the aircraft is moved between TLOF and stand without depending on its power
and wheels, Ground Movement Equipment (GME) or alternative means need to be accommodated in
the vertiports. GME serves as towing equipment in the form of a wheeled vehicle to move the aircraft
horizontally on the vertiport surface, which can be either manually operated or remotely controlled
or supervised by a member of the technical ground crew. Other possibilities are also envisaged
without the use of GME for moving between TLOF and stand, e.g., landing gear. In U-space airspace
landing and departure operations at Vertiports will be managed through U-space, a largely automatic
system that will perform the necessary control tasks (sequence building, landing clearances, hold
instructions, taxi clearances, etc.).
The following sections detail assumptions for initial operations of a vertiport as considered in CORUS-
XUAM which means that some simplifications are made, and some constraints are introduced. Future
iterations may introduce additional features and hence complexity.
4.2.4.1 Vehicles
Whilst a number of vehicle types will undoubtedly be used in urban air mobility, we make the
assumption that urban vertiports will be used mainly by eVTOL and hybrid VTOL aircraft. The main
reasons for this are
 We assume that in urban areas not enough space for landing and take-off strips for short-
Take-Off and Landing (STOL) vehicles will be available; VTOLs require significantly less space
for take-off and landing.
 Electrically powered vehicles have clear advantages in terms of noise and pollutant emissions
which is a relevant criterion in urban areas.
 In terms of endurance, hybrid propulsion systems used by VTOL aircraft are still less noisy than
commercial helicopter operations but provide higher endurances compared to purely electric
ones. When noise is not a relevant operational constraint, VTOL aircraft with combustion
164
engines, e.g., small helicopters, can be served since they require the same facilities as eVTOL
aircraft minus the charging facilities.
The vehicles must be compliant with the vertiport’s operating licence, which may specify maximum
weight, noise, fire risk, technical equipment, times of operation, etc.
We assume passenger-carrying flight (air taxi operations) either with a pilot on board (ML2, ML3) or
with a remote pilot operating beyond BVLOS – Beyond Visual Line Of Sight (ML4).
4.2.4.2 Vertiport facilities

The present design concept of vertiports, which is based on the EASA Guidance Material for Design of
VFR vertiports [108] and largely inspired by current standards and recommendations for heliport
design (e.g., ICAO Annex 14, Volume 2), provides the following facilities:
 Touchdown and Lift-off (TLOF) area(s);
 Final Approach and Take-off (FATO) area(s);
 Safety Area(s) around the FATO(s);
 Stands
 Facilities for re-energizing of aircraft batteries;
 Areas for taxiing (under own power) and ground movement (not under own power) of VTOL
aircraft between the FATO and TLOF; and
 Passenger embarking, disembarking, and waiting areas.
Figure 1: Example on TLOF, FATO and Safety Area
FATO and safety area are always placed together within vertiport environment, but TLOF and Stand
can be placed elsewhere. Different options are expressed in Figure 30 for:
 Air taxiing, with TLOF being at the same place as the stand, where vehicle moves hovering
over the vertiport surface on its own power. Vehicle does not lift-off or touch down at the
FATO.
165
 Ground movement, where TLOF and FATO being at the same point and the stand in a different
place, where ground movement of the vehicle is needed (e.g., for longer distances), vehicle
can be moved under own power or vertiport movement system.
Figure 30: Air taxiing and Ground movement vertiport configuration
For capacity and contingency reasons, it is desirable to provide more than one TLOF/FATO since the
TLOF/FATO may need to be ‘reserved’ for the outgoing flight for a specified period after take-off to
account for contingency. Providing one ‘spare’ FATO/TLOF at the vertiports for all flights may satisfy
this requirement.
When considering vertiports for passenger VTOL aircraft operations, EASA is distinguishing different
kinds of vertiports (see Figure 31: Vertiport Classification from Operations Perspective [102]).
As per EASA SC VTOL, VTOL aircrafts certified in the category enhanced, need to satisfy the
requirement of continued safe flight and landing (CSFL) and hence be able to continue to the original
intended destination or a suitable alternate vertiport after a failure [103]. This enhanced category of
VTOLs covers those aircraft which carry passenger on board.
Figure 31: Vertiport Classification from Operations Perspective
services required for the operation, that the VTOL vehicle can take-off from. The blue circles are
aerodromes for CSFL (heliport or vertiport), that only have a minimum set of facilities and services (to
be specified), from which the VTOLs may not be able to take off. For cargo UAS and small UAS
operations all operating sites can be used.
166
 Alternate vertiport: An alternate vertiport is pre-planned and chosen in case it becomes
either impossible or inadvisable to proceed to or to land at the intended destination vertiport.
This can be either an alternate take-off vertiport, where the VTOL aircraft would be able to
land should this become necessary shortly after take-off, or an alternate en-route vertiport,
where the VTOL aircraft would be able to land in the event that a diversion becomes necessary
with normal aircraft performance while en-route, or an alternate destination vertiport, where
the VTOL aircraft would be able to land should it become either impossible or inadvisable to
land at the intended destination vertiport.
 Alternate en-route vertiports for CSFL: The alternate en-route vertiport for CSFL complies
with the same minimum design requirements as the alternate en-route vertiport. But it only
has to fulfil a minimum set of services with respect to the aircraft and CSFL operations.
Procedures that need to be defined at vertiports include holding, diversion, arrival sequence,
departure sequence, ground operations (charging, ground movement). Due to battery limitations of
the incoming eVTOL holding procedures are not an element of nominal operations.
We don’t necessarily assume that a human is physically present at the vertiports.
4.2.4.3 Actors
Vertiport Operator: owing to the high levels of automation as well as the quick response times
required to accommodate air taxi operations, the vertiports authority will most likely be quite
different from traditional airport authorities with manned control towers and be highly autonomous
instead. An important building block of vertiports operations is the Vertiport Management system
which contains the status of all components and facilities at the vertiports as well as the allocation of
resources to individual air taxi operations; it will be used by different entities to book resources,
including FATOs.
Vertiport Management System: The Vertiport Management system needs to fulfil a number of
requirements, including real-time data provision, verification of the authority booking resources,
verification that the vehicle is technically suitable and authorized to operate at the vertiports, low
latency, and secure access. The Vertiport Management System should have an undoubtedly
transparent and fair process to fulfil all requirements. This includes a new Vertiport Management
System service, providing static information and dynamic on (e.g., facilities availability).
USSPs: Following guidance from the European Commission and unlike ‘traditional’ aviation, present
U-space and UAM concepts assume the existence of more than one U-space Service Provider (USSP)
in each airspace. The USSP supports the drone operator in the planning and execution of a mission
and this includes the authorization of the mission. The fact that more than one USSP can authorize
access to limited resources, including the airspace, makes the flight authorization process a non-trivial
aspect of U-space.
UAM operator: the commercial entity operating UAS in UAM airspace and offering air taxi services to
passengers, either scheduled or ad-hoc. The UAM/UAS Operator and the vertiport operator shall have
established an agreement to allow the operator to use the vertiports; this framework agreement
concerns aspects such as charges, services, billing, etc. The UAM/UAS Operator is supported by the
USSP in the flight planning and flight authorization process, and this includes obtaining access to the
vertiports.
167
Passenger (PAX): the passenger requests, via an application, price and scheduling information for a
trip between two vertiports. The UAM/UAS Operator provides the necessary information and once
the passenger has consented and paid the agreed services are provided at the vertiport.
The vertiport is assumed to be not exclusive, which means that various UAM/UAS Operators may use
it once they have established a framework agreement with the vertiports authority. Each UAM/UAS
Operator may choose one of the various USSP offering services in the airspace surrounding the
vertiport.
4.2.4.4 Vertiport location, airspace, and flight rules

For the initial concept and use cases we assume Zu airspace located inside class G (uncontrolled)
airspace. This would cover most vertiports located in urban areas but exclude vertiports in the vicinity
of airports which are surrounded by class D airspace.
VFR traffic will not be allowed to operate in class Zu airspace and hence in the airspace surrounding
the vertiport. This is a necessary restriction because ‘remain well clear of’ principles used in VFR have
no defined separation or safety distance and are hence difficult to deal with in operations involving
remotely piloted vehicles. Traffic inside Zu airspace surrounding the vertiports is assumed to be fully
cooperative with UFR flight rules. Maturity Levels (MLs) 2 and 3 operations with a pilot on-board will
also adhere to UFR, not VFR. Although technically and operationally there is no difference for ML 4
operations, we initially assume day flights based on safety considerations.
In an evolution of the above, we will consider vertiports based in the premises or the vicinity of an
airport (i.e., airspace class C or D). In this case, air taxi operations will require some form of interaction
(through U-space) with ATM and will be clearly shown for ATC on the HMI for ATCOs situational
awareness. This integration with ATM needs to be further defined/clarified.
In class G the vertiport shall be published on the AIP with the commonly used arrival and departure
routes in order to create awareness with VFR community.
During CORUS-XUAM WP3-WP4 workshop held on March 2022, there was a clear answer from that
participants that instead of defining procedures (e.g., STARs 0or SIDs), this should be a defined
geometry/volumetry that will depend on the operation.
4.2.4.5 Vertiport access and authorization of the U-plan

Whilst vertiports with lower traffic demand may not have such an area, we assume that the majority
of vertiports is surrounded by a Vertiport Traffic Zone (V-TZ); the vertiports is under the responsibility
of the vertiport operator and its actual state and operations plans are subject of the vertiport
management system which is accessible to the vertiports operator and the USSPs. Vertiport Traffic
Zone is U-space airspace, having an adequate approach area which is a protected one and in
possession of the set of rules defined. V-TZ is part of the U-space airspace where specific procedures
and rules are applied and that each flight (with whatever USSP is used) needs to follow them. The
stress lies here on a probable interaction with the Vertiport operator/management system.
Flight planning and authorisation are performed by the USSP providing service to the UAM operator
wishing to land at the vertiports. This includes booking of vertiports access. Details have yet to be
defined but it may well be that InterUSS will be used not only for booking access to the airspace
resources but also to the vertiports (ASTM standard F3548-21). The exact role of the vertiports
authority has yet to be defined if the booking of vertiports access is done by the USSP based on the
vertiports information management system.
Vertiport access booking is the booking of a, potentially limited, resource. It does not authorize the
vehicle to take-off or land. For this, the take-off/landing clearance is required which will be obtained
168
shortly prior to the actual operations. The exact concept of clearance of UAM vehicles exceeds this
section and has yet to be defined, however, suffice it to say that stepwise clearances, with clearance
limits similar to traditional aviation, seem to have a number of advantages when compared to clearing
the whole mission at take-off; these advantages concern the ability to better accommodate
uncertainty, capacity aspects, lost-link procedures, and other contingencies.
Vertiport Operator should define the requirements (in the agreement, e.g., noise, environment,
dimension) to operate in that vertiport. Vertiport should ensure the vehicle can comply those
requirements.
Vertiport communicates dynamically the status of their facilities but is not its responsibility. The Drone
Operator should decide if the vertiport can be used or not.
Equally out of scope of this section is the question of prioritization; rules defining prioritization need
to be (a) compliant with regulation and (b) treat different operators equally and reproducibly. Once
prioritization principles beyond present regulations (which prioritize emergency operations) have
been defined, it is likely that they relate to airspace access and vertiports alike.
4.2.5 Airspace Type

4.2.5.1 Background (may be deleted or moved to the framework)
4.2.5.2 Current ICAO airspace classification

ICAO Annex 11 presents the classification of airspaces in Section 2.6. The definitions refer to flight
rules which are described in Annex 2. Annex 11, 13th Edition, March 2001, Section 2.6 is reproduced
here in its entirety:
2.6 Classification of airspaces
2.6.1 ATS airspaces shall be classified and designated in accordance with the following:
Class A. IFR flights only are permitted, all flights are provided with air traffic control service and are
separated from each other.
Class B. IFR and VFR flights are permitted, all flights are provided with air traffic control service and
are separated from each other.
Class C. IFR and VFR flights are permitted, all flights are provided with air traffic control service and
IFR flights are separated from other IFR flights and from VFR flights. VFR flights are separated from IFR
flights and receive traffic information in respect of other VFR flights.
Class D. IFR and VFR flights are permitted and all flights are provided with air traffic control service,
IFR flights are separated from other IFR flights and receive traffic information in respect of VFR flights,
VFR flights receive traffic information in respect of all other flights.
Class E. IFR and VFR flights are permitted, IFR flights are provided with air traffic control service and
are separated from other IFR flights. All flights receive traffic information as far as is practical. Class E
shall not be used for control zones.
Class F. IFR and VFR flights are permitted, all participating IFR flights receive an air traffic advisory
service and all flights receive flight information service if requested.
169
Note.— Where air traffic advisory service is implemented, this is considered normally as a temporary
measure only until such time as it can be replaced by air traffic control. (See also PANS-ATM, Chapter
9.)
Class G. IFR and VFR flights are permitted and receive flight information service if requested.
2.6.2 States shall select those airspace classes appropriate to their needs.
In addition, ICAO Annex 2, Section 3.1.10 defines restricted areas, and below that section is
reproduced from Annex 2, Tenth Edition, July 2005:
3.1.10 Prohibited areas and restricted areas
Aircraft shall not be flown in a prohibited area, or in a restricted area, the particulars of which have
been duly published, except in accordance with the conditions of the restrictions or by permission of
the State over whose territory the areas are established.
4.2.5.3 Observations on the current ICAO airspace classification

The ICAO classes A to G are only defined in terms of IFR and VFR. This means anything which is not
either IFR or VFR cannot fly in these airspaces. Stated another way, if a new flight rule is created (e.g.
our UFR) then it cannot fly in the above as defined. Either we need to propose a redefinition of the
airspace classes or define new ones.
Restricted areas are a means to overcome that constraint by creating volumes that have and airspace
class definition of their own, distinct from the ICAO defined classes A to G.
4.2.5.4 EU regulations
EU regulation 2019/947 Article 15 describes geographic zones defined for the purposes of regulating
the operation of UAS. It states:
Article 15 - Operational conditions for UAS geographical zones Regulation (EU) 2020/639
1. When defining UAS geographical zones for safety, security, privacy or environmental reasons,
Member States may:
(a) prohibit certain or all UAS operations, request particular conditions for certain or all UAS operations
or require a prior flight authorisation for certain or all UAS operations;
(b) subject UAS operations to specified environmental standards;
(c) allow access to certain UAS classes only;
(d) allow access only to UAS equipped with certain technical features, in particular remote
identification systems or geo awareness systems.
2. On the basis of a risk assessment carried out by the competent authority, Member States may
designate certain geographical zones in which UAS operations are exempt from one or more of the
‘open’ category requirements.
Paragraph 3 is about data format. EASA NPA 2021-09 proposes acceptable means of compliance and
guidance material for this article. EU regulation 2021/664 Article 2 defines U-space Airspace as a
special geographical zone.
‘U-space airspace’ means a UAS geographical zone designated by Member States, where UAS
operations are only allowed to take place with the support of U-space services;
170
4.2.5.5 CORUS ConOps
The CORUS ConOps [93], defines X, Y, Za and Zu volumes, and states that to enter { Y, Zu, Za } requires
an approved operation plan, delivered by means of a U-space service. This requirement can be used
to limit access to volumes.
4.2.5.6 U-space airspace

The Airspace relevant in this work is one of the U-space airspace volumes: Y, Zu and Zz. This U-space
airspace has been created as a Geo-zone (2109/947 Art 15) within an existing ICAO airspace. Its
creation erases the previous quality of the ICAO airspace. These are Restricted Areas in ICAO terms.
The previous airspace class is recovered if the U-space airspace is dynamically de-allocated.
As in the case of ICAO airspace classes, the volume type impacts all aircraft in the volume.
Briefly the following minimum set of services are supplied:
 Y: Strategic conflict resolution, conformance monitoring, traffic information, emergency

management (As 2021/664)
 Zz: as Y + DCB, tactical conflict resolution advisory service
 Zu: As Y + DCB, tactical conflict resolution instructions
In any of these, access is contingent on an operation plan having been accepted. In each, dependent
surveillance is required. (In 2021/664 terms, Network Identification)
Technical & performance requirements may apply in the volume, for example compatibility with some
means of communication, or navigation performance within some bound. Other constraints or
requirements may also be attached to the volume such as speed limits or limits on the uncertainty
expressed in the U-plan.
4.2.5.7 Summary table

ICAO 2019/947 2021/664 CORUS- Remarks
Geo Zone U-space XUAM
airspace
Restricted Yes Yes Y No tactical separation service supplied by U-
Area space
Restricted Yes Yes * Zu Tactical separation service supplied by U-space.
Area Only UFR flights permitted.
Restricted Yes Yes * Zz Tactical separation advice supplied by U-space
Area
Restricted Yes No X Conditions might apply
Area
G VLL Yes No X Conditions apply
UAS fly below VFR limits but in effect conform
to VFR flight rule
G VLL No No X UAS fly below VFR limits but in effect conform
to VFR flight rule
171
ICAO 2019/947 2021/664 CORUS- Remarks
Geo Zone U-space XUAM
airspace
G above No No Not U- For U-space users such airspace would probably
VLL, space be marked a Y volume and any U-space
ABCDEF operation plan penetrating this airspace will
either not be approved or will be subject to
conditions or warnings.
ABCDEF No No Za Za if and only if the flight’s entry into the
airspace is enabled by a U-space planning
process that includes ATC approval.
* 2021/664 describes something approximating Y. Zu and Zz are considered as extending Y
4.2.6 Flight rules

into Annex 2. The Standardised European Rules of the Air (SERA) includes the transposition of Annex
2 into European law. The legislative framework for SERA includes Regulations (EU) 923/2012,
amendment Regulations (EU) 2016/1185 and the Aviation Safety (Amendment) Regulations 2021
applies to all European Union states and the United Kingdom (as per the EU Withdrawal Act 2018).
Additional flight rules are also applied at the state-level (for example the UK’s Air Navigation Order),
which are designed to align with SERA and ICAO standardisation.
The common European ‘Rules of the Air’ are detailed into 14 sections:
1. Flight over the high seas

2. Applicability and compliance
3. General rules and collision avoidance
4. Flight plans
5. Visual Meteorological Conditions, Visual Flight Rules, Special VFR and Instrument
Flight Rules
6. Airspace Classification
7. Air Traffic Services
8. Air Traffic Control Services
9. Flight Information Service
10. Alerting Service
11. Interference, Emergency Contingencies, and Interception
12. Services related to Meteorology – Aircraft observations and reports by voice
communications
13. SSR transponder
14. Voice communication procedures
There are two distinct Flight rule categories:
1. Visual Flight Rules (VFR); flown in Visual Meteorological Conditions (VMC)

2. Instrument Flight Rules (IFR); flown in either Visual or Instrument Meteorological Conditions
(IMC)
172
Classification of airspace are based on the permitted flights rules and the Air Traffic Services required
to be provided by a state appointed authority, such as an ANSP, in accordance with ICAO airspace
classification (class A-G). Classifications for different volumes of airspace take into consideration a
range of factors such as density of air traffic, types of operations and requirements for aircraft
equipage.
Currently, there are no specific flight rules for new airspace entrants such as UAM, UAS or RPAS in the
SERA or ICAO Annex 2. Moreover, Rules of the Air, which specifically include flight rules, right-of-way,
altitude above people and obstructions, distance from obstacles and types of flight rules, all of which,
as written, are incompatible with the intended operations within some UTM/U-space systems.
4.2.6.1 U-space Flight Rules

A new set of flight rules, recognising the specificities of unmanned, remotely piloted and/or
autonomous aircraft is required. The new rule set should address the needs and requirements unique
to users of U-space, incl. addressing specific challenges from the adoption/application of existing flight
rules. U-space Flight Rules (UFR) shall apply uniquely to airspace users in receipt of U-space services
within U-space airspace. Aircraft and pilots that adhere to standardised U-space equipment interfaces,
and operate within U-space Airspace Volumes, shall operate under UFR.
The principle behind UFR is to enable aircraft operations that cannot conform to either VFR, SVFR or
IFR in all operational conditions. Whilst in some operating cases it might be possible for UAM to
operate under VFR if piloted, however, more advanced UAM use cases are not capable of “see and
avoid” procedures if the aircraft are uncrewed. Likewise, UAM may be accommodated by IFR in some
instances, however, again the reliance on “see and avoid” with VFR traffic in class D and E airspace
will limit the usability of such approach since many urban environments are within a class D control
zone of a nearby airport. In addition, current IFR separation minima may not be suitable for effective
UAM operations in more congested airspace. The aircraft participating in U-space are therefore
required to be supported by a set of U-space services for that airspace volume. The required U-space
services and their interface with other ATS depends on the airspace classification.
UFR is for operations in U-space volumes for airspace users that are consuming U-space services. UFR
is based on deconfliction service(s) for separation provision (safety layer 1) and on-board technologies
(DAA/SAA) for collision avoidance (safety layer 2).
 Be Electronically Conspicuous to the ground system(s) and to other aircraft within the U-space
Airspace.
 In receipt of a traffic information service(s) (either by directly consuming the EC signal, or via
USSP) as required, with respect to other aircraft
 Adhere to any [Digital] ATS clearance/instruction deemed necessary by the controlling
authorities
 Have any air traffic separation service managed by a U-space service
Aircraft operating under UFR are not expected to received voice communications from ATS units.
U-space Mandatory Zone aircraft operating in a U-space Mandatory Zone (UMZ) shall be required to
make their position known to U-space through a defined procedure. States shall be responsible for
defining the required process for making aircraft Electronically Conspicuous to U-space.
173
4.2.6.2 ATS Airspace classification for UFR
Interoperability between existing ATS units and U-space services will be essential for the integration
of UFR flights with VFR, SVFR and IFR flights. There will be a need to share operational information
between existing ATS units and U-space systems to ensure safe and efficient operations depending on
the ATS airspace classification. Transfer of responsibility for control of an aircraft across boundary will
also consider the U-space airspace requirements as this may not involve direct separation control of
a UFR flight, but rather the exchange of flight information for the purpose of traffic information.
(a) Class AU. UFR flights are permitted.

(b) Class BU. UFR flights are permitted and provided with a U-space control service. UFR flight are
separated from IFR and VFR. UFR flights can receive digital ground to air or ground to ground
communications through an authorised ATM/UTM interface. UFR flight shall be subject to ATC
clearance.
(c) Class CU. UFR flights are permitted and provided with a U-space control service. UFR flight are
separated from IFR flights and receive digital U-space traffic information about VFR flights.
UFR flights can receive digital ground to air or ground to ground communications through an
authorised ATM/UTM interface. UFR flight shall be subject to ATC clearance, provided
through the UTM system.
(d) Class DU. UFR flights are permitted and provided with a U-space control service. UFR flights
are provided with digital U-space traffic information about all other flights. UFR flights can
receive digital ground to air or ground to ground communications through an authorised
ATM/UTM interface. UFR flight shall be subject to ATC clearance.
(e) Class EU. UFR flights are permitted and provided with a U-space control service. UFR flights are
provided with digital U-space traffic information about all other flights. UFR flights can receive
digital ground to air or ground to ground communications through an authorised ATM/UTM
interface. UFR flight shall be not subject to ATC clearance.
(f) Class F is not considered since it is no longer applied in Europe
(g) Class GU. UFR flights are permitted. UFR flights are provided with digital U-space traffic
information if requested and available. UFR flights receive digital ground to air or ground to
ground communications through an authorised ATM/UTM interface. UFR flight shall be not
subject to ATC clearance.
ICAO B C D E G Restricted area

Airspace
Classification
U-space Y Zu Zz
classification
Tactical UFR <-> UFR UFR No No No Yes No
Separation IFR, <-> <-> Separation Separation (Advice
Provided U(S)VFR IFR, IFR, only)
SVFR SVFR
U-space UFR UFR UFR UFR <-> UFR <-> yes yes yes
Traffic <-> <-> <-> IFR, SVFR, IFR*,
Service VFR, VFR, VFR UFR SVFR*,
UFR UFR UFR
Speed limit TBD TBD TBD TBD N/A probably probably probably
174
Radio None None None None None No No No
ATS Yes Yes Yes No No No No No

Clearance
required?
Table 58: ICAO Airspace Classification
* Only in UMZs
4.2.6.3 U-space Tactical Conflict Management

CORUS-X discriminates between strategic and tactical conflict resolution. Strategic conflict
management is explored more in detail within the lifecycle of the U-plan in Section 3.11. while this
section focuses on the provision of tactical conflict management within U-space.
Aircraft operating under UFR may expect to receive conflict management provided by U-space. It is
the role of U-space to assign responsibility for conflict management and separation provision to the
appropriate entity to ensure UFR flights are safely separated from other aircraft, as regulated by the
State. This may include a combination of mandated U-space services, co-operative self-separation,
defined UFR routes and UMZ concepts to achieve separation from other flights.
Where it is the responsibility of the remote pilot or aircraft operator to maintain (self) separation from
other aircraft, a Detect and Avoid (DAA) system may be used. ICAO Annex 2 defines DAA as “the
capability to see, sense or detect conflicting traffic or other hazards and take the appropriate action”.
This capability primarily aims to ensure the safe execution of an RPAS flight and fully integrate with
other airspace users that would otherwise be “seen and avoided”.
In U-space airspace where a conflict management system is required to ensure effective separation
provision, DAA systems can also be used for the purpose of maintaining safe separation minima.
Separation minima will be performance-based depending on the airspace procedures and structures,
such as the use of dedicated U-space corridors and the assurance of Position, Navigation and Timing.
The precise method of conflict management, be that a combination of strategic, pre-tactical and/or
tactical, will be overlayed on the ATS airspace classification as a U-space layer: X, Y or Z.
U-space layers are hierarchical requirements that are used appropriately to mitigate hazards and
airspace congestion:
• Known traffic enviroment

U-space X
• Known flight
intents
U-space Y
• Known
trajectories
U-space Z
Figure 32: Hierarchical requirements for U-space airspace to mitigate hazards and airspace congestions.
175
4.2.6.4 U-space X Layer Volume – Low traffic density flight rules
In airspace where capacity is not constrained, and aircraft can safely self-separate, the U-space layer
will be designated “X”. In this U-space airspace, there is no requirement to share flight intent for the
purpose of strategic or (pre-)tactical conflict resolution. All potential conflicts will be resolved
tactically, and separation will remain the sole responsibility of the pilots or operators. To enable BVLOS
operations within U-space Airspace X Layer, it is the responsibility of the state to approve DAA systems
that will independently provide flight separation for BVLOS flights operating under UFR.
UFR flights shall be expected to make themselves known through an electronic conspicuity (also
referred as e-conspicuity) device to the U-space system. The requirement for discovering and tracking
UFR flights will be defined by the U-space layer requirements for the specific airspace volume.
Examples of a U-space X Layer requirements may include a mandatory use of either: ADS-B, FLARM,
Pilot Aware Sky Echo and/or Remote ID.
In airspace classes that do not have a known traffic environment, such as class-G without a TMZ, states
have to include the following:
 Manage the layer as a temporary danger area, notified as a NOTAM
 Declare a U-space Mandatory Zone that requires all airspace to conform to the U-space X layer
requirements
 Require the DAA function of UFR flights to be certified to independently avoid all co-operative
and non-co-operative crewed aircraft.
4.2.6.5 U-space Y Layer Volume – Medium traffic density flight rules

In airspace where the UFR flights have a reasonable chance of coming into conflict with other aircraft
and the aircraft cannot guarantee safe efficient self-separation, the U-space layer will be designated
“Y”. In this U-space airspace, UFR flights will have the same requirement for defined for discovering
and tracking as a U-space X layer and in-addition are required to declare a flight intention to the U-
space system before entering the U-space airspace. If the intended flight becomes intersected with
another UFR flight (in both space and time), then the U-space system must attempt to separate the
planned flights. In the first instance, the system shall exchange detailed flight intension details for the
intersecting region, including a precise flight plan to collaboratively re-plan so that the respective UFR
flight may become “Strategically Deconflicted”.
Where the UFR flights cannot be strategically deconflicted from other UFR flights before entering the
U-space Airspace, the aircraft pilot or operator is still required to maintain separation using an
authorised DAA system. It is the responsibility of the state to appoint an authority to manage the
number of in-flight conflicts occurring and provide sufficient flight information to support the DAA
systems.
U-space Y layer requires a known traffic environment of all crewed aircraft and is only possible
controlled airspace or a TMZ. UFR flights shall receive the digital ground to air or ground to ground
communications through an authorised U-space ATM/UTM interface. Flight authorisation for UFR
flights in the U-space Y layer volumes is normally delegated by the ATS unit to a U-space service
provider.
To separate the UFR flights from VFR, SVFR or IFR traffic, the U-space system may restrict flights within
the U-space airspace. Flight restrictions are passed to U-space about VFR, SVFR and IFR flights entering
U-space Y layers that will restrict the operations of UFR flights that do not meet the DAA system
requirements for conflict management. Where a restriction is issued on the U-space airspace, the DAA
176
systems are primarily considered a collision avoidance function and must yield to the air traffic under
ATS unit control.
4.2.6.6 U-space Z Layer Volume – High traffic density flight rules

In airspace where the UFR flights require a tactical conflict management system is required for safe
and efficient control of an airspace, the U-space layer will be designated “Z”. In this U-space airspace,
UFR flights will be required to declare a flight intention to the U-space system before entering the U-
space airspace. In this U-space airspace, UFR flights will have the same requirement defined for
discovering, tracking and flight intent sharing as a U-space Y layer and in-addition are required to
cooperate with tactical U-space conflict management instructions.
Separation minima shall be provided for UFR flights by U-space depending on the airspace
classification and separation procedures. U-space shall be responsible for maintaining safe separation
between UFR and IFR in all U-space Z layers; collision avoidance remains the responsibility of the pilot
or operator. U-space can make use of DAA systems that directly cooperate with the U-space tactical
conflict service providing they meet the performance requirements.
The use of dedicated U-space corridors, performance navigation and visual tracking can be used by U-
space to maintain UFR flight separation. UFR flights shall require clearance by U-space to enter a U-
space corridor. U-space conflict management shall be responsible for re-planning UFR flight intentions
that are restricted.
4.2.7 Airspace structure

There are different airspace structures which are interesting from the point of view of UAM, the use
of Layers and Corridors and the use of the Dynamic Airspace Configuration (DAC).
4.2.7.1 Layers
4.2.7.2 Layers for traffic organisation

The “semi-circular rule” is an oft used term in aviation and refers to layering traffic according to
direction in order to reduce the probability of collision. Variations on this have been often proposed,
such as Irvine & Shaw 200417 proposed a scheme with traffic restricted to fly only certain headings in
dedicated layers, Metropolis18 propose “geo vectoring” grouping arcs of traffic heading into layers,
and the BUBBLES project applies the semi-circular rule in the VLL.
17
https://www.researchgate.net/publication/256503816_Layers_of_parallel_tracks_a_speculative_approach_to
_the_prevention_of_crossing_conflicts_between_cruising_aircraft
18
https://homepage.tudelft.nl/7p97s/Metropolis/
177
4.2.7.3 Layers relating to performance
AMU-LED have proposed a higher performance layer above a lower performance layer. Higher
performance may be obtained at higher altitude due to better radio propagation19.
A simple way to manage this in CORUS terms may be the vertical composition of two volumes with
different performance requirements.
4.2.7.4 Open questions about layers

How does a flight to move from one layer / volume to the other or through other layers to the ground,
for example if the layers are dedicated to directions or flight performance?
If layers are defined in terms of constant gravitational potential, that is relative to mean sea level (the
geoid) then they will interfere with terrain and obstacles. There will be occasions when aircraft must
climb or descend to the next corresponding layer in the stack, passing through all the others. The
benefits of layers in terms of reduced horizontal collision risk may be countered by increased vertical
collision risk
If layers are defined relative to ground level, they may require additional climbing and descending.
A CARS is indispensable when layers are used. These layers should be referenced to the same datum
used by CARS (e.g.: WGS84). This shall ensure proper vertical separation and conformance of aircraft
using the layers.
Dedicated vertical corridors linking the layers can solve the problem of needing to change. For
example, in the case of a high performance layer above, corridors can be defined near the vertiports
so that UAM traffic directly ascends to the high performance layer after take-off, an vice-versa for
landing.
Another question regarding layers and vertiports is how are vertiports (including the approach and
departure paths) integrated into the layers? These operations basically require changing vertical
levels, increasing the vertical collision risk as well. The U-space airspace surrounding some vertiports
will be V-TZ. Transition areas , in vicinity of V-TZ, or part of V-TZ can be a way of handle this problem.
4.2.7.5 Corridors
In an environment with a limited number of vertiports it may be interesting to try to connect them
with corridors, implemented as relatively narrow U-space airspaces. The advantages include:
 Limiting the regions subject to UAS noise or the risk of falling debris in case of an accident
 Constraining the flights to regions with sufficiently good CNS
 Limiting the amount of airspace ‘taken away’ from existing aviation. (The advantage may be
small as the corridors render much of the rest of the airspace useless.)
Disadvantages include:
19
Comment from Prof JV Balbastre of UPV & BUBBLES
178
 Flights which cannot follow the plan – for whatever reason – fall out of U-space. This may
require the flights switch to either IFR or VFR as appropriate. That requirement may be a
disincentive for contingency plans to be followed.
 Traffic may be concentrated increasing collision risk.
4.2.7.6 Dynamic Airspace Configuration

Dynamic Airspace reConfiguration is a contingency procedure described in 2021/664 in which
controlled airspace, which has been converted into U-space airspace, is converted back into controlled
airspace.
The expected result of this is chaotic unless a) contingency plans already exist for each flight in the
airspace and b) a notice period sufficient to execute those plans is given. In effect this is an emergency
procedure that needs to be rehearsed (like a fire drill).
4.2.8 Type of vehicles

Vehicle classification based on EASA Concept paper on usage of U-space (TBD):
Aircraft EASA Pilot on Use of U-space Level of Notes

Classification Board Services Automation
Manned N/A Yes No usage of U- None GA, HEMS, etc.

Aviation space services
Manned Type #3 Yes No usage of U- None Initial Phase, POBA

UAS space services
Manned Type #3 Yes Possible Usage Some flight Later Phase

UAS of U-space phases may be
services automated
Unmanned Type #2 No Yes Remote Different level of

UAS piloted/ autonomy is
automated/ possible; for more
Autonomous automated flights
there is no remote
pilot but a ‘fleet
manager’
Table 59: Type of vehicles
An Air taxi Service shall have the characteristics of common transportation modes, such as regular
taxis and subways.
CHARACTERISTICS REGULAR TAXI SUBWAY and BUSES AIR TAXI

On-Demand Availability Yes No Yes
Vehicle Routing Real-Time Pre-defined Real-time
Number of segments per trip Single Single/Multiple Single/Multiple
Vehicle Capacity Low High Low
Trip Distance Short, Medium or Long Short, Medium or Long Long or Very Long
Ride Fare Medium Low High
Vehicle Travel Speed Low Moderate High
Trip Duration Uncertainty High Low Low
179
Ridesharing Shared and non-shared Shared Shared and non-shared
Table 60: Common transportation modes characteristics compared with air taxi [105].
The experience of requesting an Air taxi Service should be similar to the process of booking a standard
on-demand and regular mobility services. Typically, a registered customer will enter the pickup and
drop-off locations using an ad-hoc web-service application (e.g., Uber Taxi Service). Depending on the
trip information, the platform will estimate the travel time for all relevant/applicable transportation
modes, such as air and regular taxis. If an Air taxi Service is feasible, then a customer may avail of the
service depending on his relevant attributes like willingness-to-fly, trip cost, and transit-time
sensitivity.
An Air taxi Service could also be constituted by multiple segments as follows:
Figure 33: Air taxi service point to point segments.
The first segment (commute from the pickup location to a vertiport) could be facilitated via on-road
car/taxi/other means of public transport trips or just walking from an airport gate to the relevant
vertiport located close to the terminal. Subsequently, the longest segment of the trip could be covered
by an air taxi, where the passenger is transported from the origin vertiport to the destination station.
Finally, the last mile of the trip (i.e., travel from destination vertiport to the drop-off location) could
be complemented by a regular taxi service. However, if the first or last segment of the trip is in close
proximity to the designated vertiport, then the customer may be directed to walk.
The majority of UAM/AAM use cases are scoped around the ‘air taxi’ size aircraft. Aircraft capacity can
vary from 1 – 5 passengers for local or regional flights.
Routes under use cases are focussed on short or local journeys. Significant numbers of use cases
describe “short hop” or “last mile” transportation models of distances of under 100 miles.
As anticipated, many use cases are considering piloted Air taxi aircraft, although longer-term
ambitions include autonomous or AI-driven flight control systems. Many of the aircraft systems do
however introduce advanced technology-driven systems, beyond conventional aircraft design.
180
Within this context, to it is strategically important to:
 Define an efficient network that is relying on optimal vertiports location;

 Integrate Air taxi Services with other existing Ground Mobility options.
4.2.9 Rules of Separation

Among the different projects exploring the rules of separation between UAS, is relevant the SESAR ER
project, DACUS, where in the Separation Management deliverable D5.2. [94] they define the different
alternatives and rules for the provision of the separation management process.
In this context, separation can be either provided by:
 A U-space service provided by a service provider from a ground station.

 Self-separation, provided by the vehicles itself.
Figure 34: DACUS D5.2. Rules for separation management schema.
181
Figure 35: 4D trajectories (blue) abiding a set of moving obstacles (red)
4.2.9.1 Self-separation
Self-separation is expected in “uncontrolled airspace”, such as U-space classes X and Y as defined in
the CORUS CONOPS [93]. This part of U-space is expected to be fairly large and have a low traffic
density. Types of self-separation, as found above in DACUS D5.2, Figure 34, are separation provided
by a Ground Drone Operator Systems, self-separation provided by the Autonomous vehicle itself and
finally VLOS (Visual Line of Sight) flights with PIC (Pilot in Command) on ground, responsible for visual
separation. This is in some ways equal to today's Class G airspace with mainly manned VFR traffic.
4.2.9.2 Ground U-space service centralized with one or more actors.

Ground-based separation is expected in Zu airspace by USSP throughout the use of separation service
in U-space.
Firstly, an initial strategic deconfliction is made when the operator is applying for authorization of a
flight, before its RTTA (i.e., xx minutes before ETD), when the U-plan is received. This is similar to what
we see in manned aviation today with NM, Network Manager to avoid congestion in the airspace. The
initial strategic deconflictions takes this a step further though, since this also aims to de-conflict the
4D flight path within reason depending on the timeframe to ETD.
For the strategic and pre-tactical phase, deconfliction data gathering is necessary to get a baseline. As
the operations grow, more data will come and we'll learn from it and will manage the uncertainties,
decrease the margins etc. Based on this approach, the vision of the project is that separation
management will be more conservative in the beginning and more efficient later on. Data needs to be
gathered locally, carefully checking whether data from one place is usable or not in another place.
The adherence to the flight route is vital; allowing deviations up to 5-10% of the route will create
unnecessary conflicts in the analysis of the strategic and pre-strategic deconfliction. RNP 95%
containment… should it be better, under 1%? Decrease of the containment violation probability,
during the initial implementations, may be achieved with larger safety margins (see below a schematic
figure from BUBBLES D4.1. [95] and the simulation results on containment from an ATM Seminar 2021
182
paper [96], by Airbus and Johns Hopkins University on evaluation of UTM strategic deconfliction
through end-to-end simulation).
Figure 36: RNP Accuracy and Containments limits, BUBBLES Project
Figure 37: ATM Seminar [96], Conformance rate as a function of the volume horizontal buffer across a
variety of volume time buffers.
Next, for the pre-tactical deconfliction phase, when the flight activation is requested, for example
within 3-5 minutes to ETD, the deconfliction service will take into account the actual airspace situation.
Airspace situation received from USSP with an MTCD-like algorithm to identify risks and---most
183
importantly---conflicts that can be solved before T/O, e.g., in the form of rerouting or change of en-
route flight altitude will provide an update on the U-plan.
Finally, when the flight is activated, all separation provided is tactical, no matter what the source of
issue is: weather (wind), delay, non-conformance, performance degradation, etc.
This is expected to be a common procedure, that will enable to increase traffic density and to allow a
free route concept in U-space. A remark must be done on not to confuse free route airspace (FRA)
with free flight: free route airspace will work just fine e.g., from vertiport to a waypoint, then directly
to another waypoint, then to vertiport; free flight is totally unpredictable since no rules apply, you fly
as you wish and want).
All UTM systems need to have the same parameters, to be able to detect all conflicts, to have the
same picture and use the same resolution for all conflicts that need to be resolved. Prediction is
necessary in systems used by USSPs as the predictability is an important part of all deconfliction in the
U-space, including sequencing at (vertiports, hubs, etc.)
Communication is vital too; in particular, information about off-nominal events must be transmitted
immediately to involved drone(s) and presented with a solution that will take them to an alternate
Vertiport or apply rerouting. This means a seamless connection for a flight during the whole flight.
A crucial parameter is the separation radius r, below which the loss of separation is declared. SESAR
ER4 project BUBBLES [95] looks at the interplay between r and resolution efficiency: for larger r, the
separation loss is more frequent, but the vehicles have "more room to manoeuvre"; on the contrary,
with smaller r, loss of separation is rare, but conflict avoidance schemes are less likely to work.
BUBBLES balances the probability of loss of separation and the probability of collision, given the loss
of separation, to determine the level of safety for various values of r (see figure from BUBBLES D4.1
[95] below).
Figure 38: BUBBLES D4.1. [95] Collision probability versus separation distance.
In addition, the ATM Seminar 2021 paper from Airbus and Johns Hopkins University [96], reports on
simulations results evaluating risk for various r (as well as time uncertainty buffers); see the figure
below (see the paper and the presentation for more results plots):
184
Figure 39: ATM Seminar 2021, The absolute unmitigated risk as a function of nominal separation.
DASC 2017 paper from Linköping University and UC Berkeley [97], produced similar graphs also for
varying traffic intensity (see the figure below). The main conclusion from the work are sharp
thresholds for the risk: for a fixed r, as the traffic increases, at some point the risk abruptly goes from
essentially 0 to almost sure. This "tipping point" defines the airspace capacity for the given CNS
performance: to avoid the risk, the CNS performance must be decreased before the threshold traffic
intensity is reached. For vehicles with hover capabilities, such CNS performance may potentially be
improved simply by decreasing the speed, which increases the time-to-act buffer.
Figure 40: Probability of safety breach as the function of r and traffic intensity (left 3D graph, right: view
from the top)
185
4.2.10 Processes and flight phases
The lifecycle of a single operation is divided into different flight phases, that categorizes the operational phase during an operation happens and refers to a
period within a flight, these includes, the pre-flight, the flight and the post-flight phase.
Also, to consider the different processes and flows of information, it is required to have processes phases, the strategic, pre-tactical, tactical, and post-flight
processes phases.
These phases are related in a timeline where the different events are depicted, as represented in Error! Reference source not found..
Figure 41: CORUS-XUAM Process and Flight phases timeline scheme.
186
These process phases are used to describe the lifecycle of the processes of an individual UAM
operation, and match with the actual names of ATFM and DCB processes phases as defined by ICAO
on Doc 4444 PANS-ATM [99], they are used to ensure the optimal traffic flow and to balance the
demand with the current capacity of the system, they are divided into:
 Strategic phase:
This process phase is the start point in the lifecycle of an operation, as this phase begins at the
point at which the UAM Operator plan its flight intentions into a U-plan. This could occur once
the UAM Operator has its intentions clear (e.g., 30 minutes before ETD) or even days before
the actual operation, but it is not limited in time.
In this phase, strategic processes occur, for example to check for imbalances (Demand and
Capacity Balancing, DCB processes) and proposes to apply DCB measures to ensure the flight
takes place in a safe and an efficient way if they needed. These DCB measures can encompass
from long term actions (as e.g., planning on CNS infrastructure update or modification,
redesign of the airspace structure, etc.), to medium and short-term measures (as for example
to change the route or altitude in the U-plan, or to change/adapt the current airspace
configuration, etc.).
This process phase ends when the flight activation request is sent by the UAM/UAS Operator.
 Pre-tactical phase:
This process phase starts then, once the U-plan is approved, and the drone operator has sent
the request for flight activation.
The flight is then freeze and has its RTTA (Reasonable Time to Act) on-going. At that moment,
the uncertainty of the estimated time of departure is very low, and so, the probability of
anything to change in the flight are very low.
A final U-plan conflict detection is performed, if any potential conflict is detected (for example
with a prioritised flight e.g., an emergency flight), then a modification on the U-plan can be
proposed. These modifications are based on a prioritisation schema as defined in Section
4.2.11.3. If no conflicts are detected, the Drone Operator is provided with the final time of
departure, slot, runway, and time of arrival.
This phase ends when the flight receives the flight activation authorisation. This RTTA needs
to finish at the same time or before this flight activation authorisation.
 Tactical phase:
This process phase start when the flight is finally activated. The flight phases comprised within
the tactical phase are Taxi Out, Departure, Take-Off, Climb/Ascend, En-Route,
Descend/Approach, Landing and Taxi In.
This phase ends after the Landing (or Taxi-In, depending on the vehicle capabilities), when the
flight sends the terminated message to the USSP, indicating that the flight is ended.
187
 Post-flight phase:
This process phase start when the flight is in the status terminated and the UAM vehicle stops
moving, the flight closes and securing the vehicle commence. Post flight activities typically
includes de-boarding passengers and/or cargo and vehicle servicing activities.
In addition to the process phases, as described in the CORUS-XUAM Operational Framework D3.1.
[98], the flight phases of an individual operations are divided into:
 Pre-flight phase:
Any general pre-operational activities related to the management of UAM and independently
to the single flight: there are encompassing registration, publication of UAM corridor,
operational of UAM and any activity related to the preparation of the individual flight prior to
departure, including vehicle pre-flight checks, vehicle charging, flight planning, boarding
passengers and/or cargo. This flight phase comprises the process phases of Strategic and Pre-
tactical phase.
 Flight phase:
This flight phase comprises the different evolution of the movement of a flight in a single
operation including:
o Departure: the period in which the UAM vehicle physically departs from the location
A (Vertiport, stand, runway, airfield, etc.) up to the point at which it reaches cruise
altitude. Departure includes taxi, take-off, and initial climb
o En-Route: The point at which the vehicle reaches cruise altitude up to the point at
which it begins the approach to the destination location/point (Vertiport, stand,
runway, airfield, etc.).
o Descend/approach: the period between the UAM vehicle aligning with the optimal
track to the assigned destination and reaching the decision point (or decision
altitude/flight). Descent is expected to occur within this phase. The UAM pilot will
elect to either continue or land or climb to a safe manoeuvring altitude (executing a
missed approach).
o Landing: the point at which the decision is made to continue to the destination from
the decision point (or decision altitude/height) until the UAM vehicle lands Landing
includes taxi-in if needed depending on the UAM vehicle.
 Post-flight phase:
this phase is described in exactly the same way as the Post-flight phase from the process
phases described above.
188
Figure 42: Operational Framework flight phase representation from EmbraerX and Airservices Australia
ConOps for UAM [106].
4.2.11 U-plan - Operational Planning

To process the different operations, it is envisaged the use of a U-plan (previously named Operational
Plan), that contains the minimum information required to perform an UAM operation.
4.2.11.1 Lifecycle of a U-plan.

The operation plan has a number of distinct phases in its life. This topic is quite large and needs proper
discussion. This is just an introduction.
1) Draft. There is a business need, and a plan is being developed.

2) Approved. The plan has been filed, strategically deconflicted and so on. Resources (e.g.,
airspace, vertiport) are now committed to this flight.
3) Active. The services used in flight are operating. Tracking, emergency management, etc.
4) Ended. The flight is over.
There are a few other states that can usefully be added to that set. Flights may have been approved
but then due to changes in circumstances might not be able to be activated. Flights might be already
activated and then the same change in circumstances make them activated but not safe. Flights may
invoke contingency procedures which means that they are not following the original plan.
189
Figure 43: Timeline schema of the lifecycle of a U-plan within the process and flight phases related.
4.2.11.2 RTTA (Reasonable Time to Act)

EU Regulation 2021/664 states that first filed U-plan is the first to be served in a basic FIFO
methodology (First In, First Out), with the exception of priority flights. This method has some
advantages and some disadvantages.
On one hand, the pro of this method is that the certainty of the operations comes early, except for
those priority flights which are not common, and secondly its easy implementation.
On the other hand, this methodology discriminates and penalise against businesses that cannot file a
U-plan that early (e.g., food delivery, air taxis, etc.). Also, this could lead to an inefficient use of the
available capacity, as the network will probably not have time to optimise or to use priority
preferences, as UAM/UAS Operators are “rewarded” for filing the U-plan early, increasing the level of
uncertainty of the plan filed.
In order to try to solve those issues, RTTA (“Reasonable Time to Act”) was explored.
 Definition from CORUS:
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 was specified in the version of the CORUS ConOps.
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.
190
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, the result of those flights might be
not being finally able to fly at the desired time and being accommodated when the operation in safe.
 Definition from DACUS:
Other projects have used this term as DACUS, an ER4 project based on DCB concept for U-space:
Operation plans submitted after RTTA for that flight are the first candidates to be proposed a plan
change. Although there is no advantage to early operation plan submission, there is a limit in the
interests of giving other operators some stability. At RTTA a flight becomes “protected” and may be
considered as being in its Tactical phase.
Identified "research challenges" with respect RTTA y and its use in U-space DCB:
1. Fair access to airspace versus “Reasonable Time to Act”
The U-space ConOps follows the principle that being first to submit an operation plan brings no
advantage regarding flight priority. Conflict resolution and Dynamic Capacity Management actions are
implemented a short time before take-off, referred to as “Reasonable Time to Act” or RTTA. At that
instant these processes occur on all flights concerned and treat them as equally as possible.
The impact of this “Reasonable Time to Act” on the diverse business models coexisting in the urban
areas is subject to further investigation. It is necessary to assess the DCB processes in place to ensure
the fair access to the airspace to those business models that can be constrained by the need of
providing the Operation Plans before the RTTA.
2. “Reasonable Time to Act” as starting time of the pre-tactical phase
“Reasonable Time to Act” means in practice that areas with high traffic uncertainty will have a pre-
tactical phase which is much closer to the departure time of the vehicle than those areas in which the
traffic uncertainty is very low. Subsequently, the time given to Drone Operators to react to (and
negotiate) DCB measures is greatly reduced in high-uncertainty areas. This strategy aims to incentivize
proactive participation of Drone Operators to provide DCB-relevant information early on in the
process in order to reduce overall traffic uncertainty, which benefits all Drone Operators aiming to fly
in a specific area. Additional incentives include the introduction of virtue points to further promote
collaborative behaviour among users.
Further research is needed to set the starting time of the pre-tactical phase, identifying if it will start
at a pre-defined time (e.g., 10 minutes prior to the execution), or it will start as soon as a demand
certainly value from which the traffic picture can be considered to be “consolidated”. The 1st option
could allow Drone Operators to know when they will be requested to adapt their Operation Plans if
necessary. The 2nd option could allow Drone Operators to have more time to adapt their Operation
Plans. A systematic analysis of the diverse business models in urban environments should be
performed to address this question.
The idea that underlies here is explained with an example: Two drone flights with the same departure
time but in two areas: Area 1 with high traffic demand uncertainty, and Area 2 will low traffic demand
uncertainty. Area 1 will take much longer to get a consolidated traffic picture than Area 2. Therefore,
the pre-tactical phase will begin earlier in Area 2 than in Area 1, giving drone operators in Area 2 much
more time to adapt to DCB measures than those in Area 1.
191
 CORUS-XUAM perspective:
From CORUS-XUAM perspective, U-plan could be submitted any time before the activation of the
flight. This will affect the performance of the U-space system in order to be efficient in the way
strategic measures like DCB and strategic conflict resolution works.
RTTA is related with equity KPA, as the RTTA impacts directly in how the flight is treated in processes
like strategic conflict resolution or dynamic and capacity balancing management.
RTTA is then defined as a line drawn in the time, with the capability of balance the flexibility of the
user and the efficiency of the strategic services used by the network.
In order to define this line, it takes two perspectives, from
 the point of view of the network, in order to ensure safety levels and to reach a certain level
of efficiency, the USSP/CISP would need the information of this U-plan as soon as possible, as
it needs to process the information regarding the different activities that are going to occur in
a certain airspace. This requires a minimum time where decisions and measures are applied
(DCB or Conflict management services). On the other side, having the U-plan sooner could
imply that the uncertainty for that operation is higher.
 the perspective of the passenger and the UAM/UAS Operator, once the USSP/CISP needs to
perform a modification in a U-plan due to the strategic services like DCB or conflict resolution,
the UAM/UAS Operator will require a minimum time to apply modifications in its intentions.
The Operator then would need to balance the uncertainty
The RTTA is a line drawn in the timeline, flight filings not yet at RTTA are stored and ordered, when a
flight is after the RTTA then is fixed/frozen, thus no disturbance of its plan is allowed (unless rare
priority cases, e.g., emergencies), the flight is then frozen and is protected until the flight is activated.
If a U-plan is filed before its RTTA, the system will consider their rules for prioritisation, these aspects
to be considered are further detailed in Section 4.2.11.3.
DCB Measures and Strategic conflict resolution then applies their measures based on this priority rules
for all flight that filed before RTTA. If a flight is filed before the RTTA, this flight is put on the queue,
and will need to be accommodated according to the availability of the network.
The duration of RTTA is not determined yet and may vary based on the operation and the maturity
level. An initial estimation based on Volocopter’s Voloport system and eVTOL aircraft characteristics
showed that an RTTA of 15 min could be envisaged for Volocopter’s operation (based on the
estimation times of 2.5 min for landing, 2.5 minutes for departure and 10 min for charging, making
the 15 minutes for the estimated turnaround). This RTTA can be different for different operation types.
A further study on the RTTA concept is needed, to characterise the value for each type of operation.
192
Figure 44: Visualisation of RTTA in U-plan and process phases timeline relation.
4.2.11.3 Rules for prioritisation

For flights filing a U-plan before RTTA, they have low uncertainty of this plan until RTTA is reached.
Also, their interests and preferences are not really taken into account when applying strategic services
like strategic conflict resolution or DCB measures.
To solve this, a set of rules are proposed, which enables a queue prioritisation, improving the
uncertainty of the plan for both parties (the network and the users), and improving the equity levels,
as the users can express their prioritisations aspects, which increases the fairness in the process.
To make sure that RTTA is a fair element, considering the different points of views of both (network
and user), several factors are taken into account like:
- Lead Time (LT):
The Lead Time indicator will specify how long in advance was the U-plan filed. The sooner the plan
is filed, the better the prioritisation.
- Accuracy of the plan (Acc):
This indicator will measure the uncertainty of the plan filed. This could be expressed by the
UAM/UAS Operator in the filed plan as well as the historic of the UAM/UAS Operator. The more
accurate the plan is, the better will be the prioritisation.
- Flexibility (Flex):
For some operations, the time of departure will not be a problem within a time window (E.g., no
high limitation on a fixed time of departure), the more flexibility to accommodate changes, the
higher the prioritisation will be.
- Start Time (ST):
193
A key factor in the prioritisation of the queue of traffic will be their start time (e.g., activation time
or estimated time of departure). The sooner the Start Time of a flight is, the higher the
prioritisation will be.
- Type of mission (ToM):
Finally, the type of mission will be considered, in case a special type of mission is considered, for
example for emergencies.
- Precision (P):
The precision of the information sent (e.g., set by the CNS equipment precision on board).
Then, when the flight is filed before RTTA, these flights enter in the pool and they are ordered based
on a prioritisation function P which is based on the factors previously mentioned.
�㕃(�㔿�㕇, �㔴�㕐�㕐, �㔹�㕙�㕒�㕥, �㕆�㕇, �㕇�㕜�㕀, �㕃)
This function requires more study and no conclusions was reach on specific values for these functions.
4.2.11.4 What is Provided in the U-plan / Operational Plan

Most flights flying within U-space will be requested to fulfill a U-plan / Operational Plan, this contains
a set of information needed for the lifecycle of an operation.
• 4D Volumes as specified under InterUSS [104] (3D airspace volume within a time window with
of the vehicle inside the 4D volume);
• Departure & Destination location;
• Departure time;
• Arrival/Landing time;
• Vehicle operator information, Vehicle registration/Serial Number;
• UAS information: Aircraft CNS Performance equipage;
• Mission Type;
• Flight Identification;
• Contingency Plan;
• Flight Prioritisation;
• Continuous safe flight and landing (CSFL) alternate vertiport.
4.2.11.5 Clearances
Clearances are linked to flight execution, a way of tactical deconfliction. They are needed to increase
capacity in more complex areas.
It is agreed to start describing the case where only strategic deconfliction is in place and explore
feasibility. The points limiting performance efficiency or capacity will be leading to the need of some
tactical deconfliction (i.e., clearances).
A detailed analysis of this will be performed on T3.3. Safety requirements.
194
4.2.11.6 Approval process of the U-plan:
At least should include these checks process:
- Procedural ATC Check
- Geo-Fencing Check
- Authorisation Check using Aircraft Registry
- Strategic Demand Prediction + Strategic Demand & Capacity Balancing
- Strategic U-plan Conflict Detections
4.3 Assumptions
This is a list of assumptions taken into account when describing the environment:
Vertiport Assumptions:
- For initial operations, the capacity of a vertiport is significantly greater than the demand
currently. Anything which should happen will happen promptly.
- At landing, there will always be stand allocation. The aircraft approaches a FATO then lands at
a TLOF and then moves (on the ground) to the stand. The distance from the FATO to the stand
is of concern to the Vertiport operator. There will be a negotiation regarding the requirements
regarding stand allocation or standing agreements.
- By the time of take-off, the plan must be complete as far as the arrival stand in order for the
operator to manage the energy on board.
- The vertiport is not exclusive – flights any operator may use it.
- Each Vertiport operator may have any USSP.
- The vehicle should be compliant with the vertiport’s operating licence. (Weight, noise, fire
risk, technical equipment, times of operation, …)
- The vertiport operator (most probably) has to have an agreement to allow the operator to use
the vertiport, covering the conditions above and in terms of a framework agreement, charges,
services, billing, etc.
- Vertiport include an area of storage and battery shift/charging area.
- Early Air taxi vehicles will have a pilot on board to ensure safety, but they will be largely
automated type of aircraft. Industry’s ultimate vision, after an initial transition period, is to
operate them without an on-board pilot.
U-plan activities assumptions:
- Flights covered under scenarios 1 to 4 covers only point-to-point flights (e.g., from vertiport
to vertiport.
- The authorisation to fly is a multi-stage process.
- There needs to be a “hypothetical plan mode” to estimate the cost, departure time, arrival
time, access to slots, before doing actual flight activation. Once the passenger agrees, the plan
needs to be made concrete (low uncertainty).
- The flight planning process is specific for a single flight. The plan is a 4D trajectory right to the
arrival stand and is also implicitly a take-off clearance.
- The U-plan contains 4D volumes as defined in the InterUSS platform documentation [104].
195
- All UTM systems need to have the same parameters, to be able to detect all conflicts, to have
the same picture and use the same resolution for all conflicts that need to be
resolved. Prediction is necessary in systems used by USSPs as the predictability is an
important part of all deconfliction in the U-space, including sequencing at TOLAs (vertiports,
hubs, etc.)
- U-plan activities within the short term are focused on Low density Traffic, to solve problems
at origin using strategic services (e.g., Strategic Conflict Resolution and Strategic Demand and
Capacity Balancing management services)
- U-plan activities within the medium/long term are focused on Medium and high-density
traffic, to solve some of the possible problems at origin and some others during real time
operations using strategic and tactical services (Strategic and tactical conflict resolution,
Strategic and Tactical DCB Management services).
Airspace assumptions:
- The use of the airspace should be fair.

- Airspace is segregated (either under U-space or ATM).
- For the fully automated operations phase, we should support the creation of UAM-specific
routes and corridors not interfering with manned aircraft/ATC operations. These corridors will
help to standardize and separate UAM operations while helping to simplify/reduce
interactions with other existing airspace users and air traffic control.
Traffic Assumptions:
- Low density traffic is the traffic set to be manageable by strategic conflict resolution alone
without the need of tactical conflict resolution services.
- Medium and high-density traffic is the traffic level set that is not only manageable by strategic
services but needs of tactical conflict resolution services.
- In the short term, UAM operations for Air taxis will be POBA (Pilot on Board Aircraft).
- There is a need on defining a new flight rule for UAS, UFR is proposed.
- Some initial low-volume UAM operations with a pilot on board could be managed much as
helicopter traffic is managed today. However, another set of rules will be needed for the
higher-volume and more automated operations that will follow.
4.4 Scenarios
For the description of the scenarios, we have focused on two mission types:
- A – Point-to-Point operations (e.g., Passenger transportation. (Air taxi) & Movement of

goods (Large cargo depot to depot)).
- B –Area Operations (e.g., Drone inspections, firefighting, etc.)
Also, the scenario will consider one of the timeframes defined in section Time Horizon:
- ST – Short Term (comprising Maturity Level 1 and 2 as from Section 3.1)

- LT – Long Term (comprising Maturity Level 3 and 4 as from Section 3.1)
For each time horizon and mission type there will be two environments, dealing with airspace topics:
- Env1 – Vertiports outside controlled airspace (e.g., airspace X, Y, airspace class G on VLL).
196
- Env2 – Vertiports are inside controlled airspace (e.g., airport CTR, airspace class D).
List of scenarios:
Scenario ID Mission Type Time Horizon Vertiport

Environment
Scenario 1 Scn-A-ST-Env1 Env1

Short Term
Scenario 2 Scn-A-ST-Env2 Env2
A
Scenario 3 Scn-A-LT-Env1 Env1
Long Term
Scenario 4 Scn-A-LT-Env2 Env2
Scenario 5 Scn-B-ST-Env1 Env1

Short Term
Scenario 6 Scn-B-ST-Env2 Env2
B
Scenario 7 Scn-B-LT-Env1 Env1
Long Term
Scenario 8 Scn-B-LT-Env2 Env2
4.4.1 Scenario 1: Scn-A-ST-Env1

At Scenario 1 (Scn-A-ST-Env1), vertiports exist at various places and air taxi operations are routine
between these vertiports.
A vertiport is surrounded by a mini-Approach area (busier vertiports, like this one, will have a V-TZ,
Vertiport Traffic Zone), in which the sequences of departing UAM vehicle will be managed and
eventually ground holding operations will be requested.
The flight is from vertiport A to vertiport B, where all vertiports are outside controlled airspace, and
so, there is no need to coordinate with ATC the operations.
Landing and departure operations at vertiports will be managed through U-space, a largely automatic
A passenger called Pax is inside an air taxi and is ready to depart from a vertiport called Dep to its
destination, another vertiport called Arr.
Dep is an urban vertiport and Arr is a Sub-Urban vertiport.
The air taxi vehicle is in a fit state to fly. It has sufficient range to reach the expected destination plus
the required contingency margin. The UAM/UAS Operator behind that air taxi vehicle has successfully
fulfilled its intentions in the U-plan.
The vertiports are operating normally. The traffic and weather conditions are compatible with the
operation and there is nothing exceptional happening.
197
Figure 45: Diagram sketch of Scenario Scn-A-ST-Env1
4.4.2 Scenario 2: Scn-A-ST-Env2

At Scenario 2 (Scn-A-ST-Env2), vertiports exist at various places and air taxi operations are routine
between these vertiports.
A Vertiport is surrounded by a mini-Approach area (busier vertiports, like this one, will have a V-TZ,
Vertiport Traffic Zone), in which the sequences of departing UAM vehicle will be managed and
eventually ground holding operations will be requested.
Landing and departure operations at Vertiports will be managed through U-space, a largely automatic
A passenger called Pax is inside an air taxi and is ready to depart from a vertiport called Dep to its
destination, another vertiport called Arr.
Dep is an urban vertiport, the airspace for the surrounding the vertiport is class Zu. VFR traffic is not
allowed. This is G but restricted.
The arrival vertiport Arr is an Urban vertiport based in the premises or the vicinity of an airport (i.e.,
airspace class D), an Air taxi departure operation will require some form of interaction (through U-
space) with ATM and will be indirectly submitted to air traffic control monitoring, the corridor
established will be U-space type Za.
The air taxi vehicle is in a fit state to fly.
It has sufficient range to reach the expected destination plus the required contingency margin.
The vertiports are operating normally. The traffic and weather conditions are compatible with the
operation.
There is nothing exceptional happening.
198
Figure 46: Diagram sketch of Scenario Scn-A-ST-Env2
Initial assumptions:
Early Air taxi vehicles will have a pilot on board to ensure safety, but they will be largely automated
type of aircraft. Industry’s ultimate vision, after an initial transition period, is to operate them without
an on-board pilot.
Some initial low-volume UAM operations with a pilot on board could be managed much as helicopter
traffic is managed today. However, another set of rules will be needed for the higher-volume and
more automated operations that will follow.
199
4.5 Use Cases
4.5.1 Scn-A-ST-Env1
Figure 47 contains a summary of the flow of events and processes for a single operation point-to-point
for Scenarios 1 and 2 (Scn-A-ST-Env1 Use Cases and Scn-A-ST-Env2 Use Cases).
Each of the blocks in the figure is represented as a use case (or sub-use case), which are analysed in
detail in the following subsections. This analysis includes the list of steps in a table that contains the
information regarding the roles and responsibilities, the services used, the flow of information, and
additional comments.
If required, this use cases can contain information regarding specific assumptions, roles and
responsibilities and additional notes to the reader.
These Use Cases are grouped following the U-plan and processes phases:
- Strategic Phase
- Pre-Tactical Phase
- Tactical Phase
- Post-Operations
200
Figure 47: Summary of Uses Cases Flow through different flight phases.
201
4.5.1.1 Strategic Phase
In this process phase, the vehicle is stopped on ground, the process is initiated by a passenger buying/reserving a ticket to fly.
4.5.1.2 Passenger ticketing and boarding

Step Action Trigger Information Role From Role To Services involved Remarks
transfer
1 Pax asks ticket Pax Ticket Pax Ticket salesclerk Ticket salesclerk might be a machine
sales for a journey enquiry (an app)
to Arr arriving at a
desired time in the
future or as soon as
possible.
2 Generation of a Ticket enquiry Estimated Ticket Pax Operation plan Two cases to be distinguished:
possible operation departure salesclerk preparation &
plan time, arrival optimisation a) ad hoc flights (no pre planned
time and routes or times): estimate of
cost (Geo-spatial data, hypothetical traffic interactions –
Geo-awareness, deconfliction, DCB. A possible 4D
Operation plan route is found and hence the
processing - departure and arrival times, as
validate mode) well as cost. Availability of
landing slot at Arr is checked.
b) Scheduled flights: the request is
matched with a repetitive flight
plan, which is pre-coordinated
and deconflicted in terms of time
and flight path. The flight
time/slot that is closest and
available to the Pax request is
identified and blocked.
202
3 Filing operation Confirmation of Confirmation Ticket Operation plan Triggers “airspace reservation”
plan purchase by of flight salesclerk processing aspects of U-space.
Pax (confirmed
reservation (Strategic conflict Triggers air taxi operations internal
or purchase) resolution, processes to allocate aircraft & pilot.
by Pax Demand Capacity (Pilot may be software and/or remote
balancing) from vehicle)
Triggers reservation of landing slot at

Arr.
4 Passenger arrival at Message(s) From mobile passenger, Vertiport security, processes, etc.
the vertiport is sent device or vertiport
confirmed equipment staff or There may be some delay between
- during used during automatic buying a ticket and the earliest
passenger’s the process when possible departure due to
trip to the passing deconfliction, DCB, vehicle
vertiport, certain preparation, etc.
- when gates
entering
the
vertiport,
- when
checking-in
or other events
5 Activation of RTTA is reached UAS air Position report

operation plan. (e.g. assigned operator submission &
aircraft is Tracking,
landed at origin
vertiport) Monitoring,
203
Traffic
information,
Tactical conflict
resolution
Table 61 Passenger ticketing and boarding process.
Roles identified:
 Ticket salesman
Interface between the Pax and the Air taxi business systems. Uses the Operation Plan Preparation & Optimisation service and may act as an “interpreter”
between it and Pax, for example explaining different options – for example that the lowest cost option arrives later than a more expensive option. The Ticket
Sales might be an app or a human and might be separate or integral part of the UAS air operator.
 Vertiport staff
The vertiport staff role (arbitrarily) combines all interactions with Pax after Pax buys ticket from the Ticket Sales. Pax will go through security and eventually
go to the vehicle and board it. Vertiport staff take care of this.
 UAM operator
The party setting up, maintaining and distributing the operation plan considering Pax, aircraft and crew needs based on repetitive flight plans or ad hoc flight
requests.
204
4.5.1.3 U-plan Creation
In order to create a U-plan, the UAM/UAS Operator will be assisted by services in order to check the status of the network when introducing its flight
intentions.
This will be like a “validation” method in order to check the availability of the route and the actual status and foreseen evolution of it. This would allow the
UAM/UAS Operator to know with more certainty which is going to be the status at the moment the flight is performed.
Step Action Trigger Information Roles from Role To Services involved Remarks
transfer
1 Identify Departure (Dep) and Arrival UAM/UAS Departure and UAM/UAS UAM/UAS U-plan preparation
(Arr) Operator want to Arrival Operator Operator and optimisation
perform a flight information /USSP service
point to point.
2 Extract list of available slots to land List of available UAM/UAS Vertiport U-plan preparation
at Arr slots at Arr Operator Operator and optimisation
/USSP service
Vertiport slot
service
N Use proprietary or open-source UAM/UAS Operation plan Open-source

route-finding methods to calculate Operator preparation and route finding
candidate trajectories that arrive at optimisation methods like
Arr at an available time at service InterUSS.
reasonable cost and risk
N+1 Use operation plan processing UAM/UAS USSP / Operation plan

service in “validate” mode to detect Operator Vertiport preparation and
actual conflicts or DCB overloads on Operator optimisation
candidates, eliminate or modify service
unusable candidates
205
Step Action Trigger Information Roles from Role To Services involved Remarks
transfer
(iterative with previous step) Operation Plan

Processing
final Present candidates to customer Details of route UAM/UAS Passenger Operation plan Each has an
and estimated Operator preparation and estimated cost,
times. optimisation departure time,
service arrival time.
Table 62 Validation of U-plan generation use case steps - initial version
Once the UAM/UAS Operator has validated its intentions, proceeds with the U-plan filing in detail:
Step Action Trigger Information Roles Role To Services involved Remarks

transfer From
1 Air taxi operator Validation UAM/UAS N/A Operation plan

allocates vehicle to U-plan is Operator preparation and
flight OK for optimisation
UAM/UAS service
Operator
2 Air taxi operator UAM/UAS Vertiport Operator Operation plan In order to avoid that U-plan may fail if
reserves arrival slot Operator preparation and slot is no longer available, validation
at Arr optimisation mode indicates in real time the status
service of the slot, as well as the possibility of
reservation by another actor.
Vertiport slot
service
3 Air taxi operator U-plan UAM/UAS USSP Operation plan Operation plan includes a trajectory
submits plan Operator preparation and described as a series of 4D volumes.
206
Step Action Trigger Information Roles Role To Services involved Remarks
transfer From
optimisation The dimensions of these volumes

service incorporate the allowable
uncertainties of the flight.
Operation Plan
Processing
Table 63 U-plan filing use case steps - initial version
Roles Identified:
 USSP:
- Provides support information for the creation and validation of the U-plan
- Receives the submission of the U-plan once is fulfilled for authorisation purpose.
 Vertiport Operator
- Provides support information for the creation and validation of the U-plan, regarding the slot management for departure and arrival
 Passenger
- Is the initial input to the UAM/UAS Operator to create the U-plan
- If the result of the validation activities is positive to the passenger, it is the trigger for the submission of the U-plan for authorisation through
the UAM/UAS Operator
 UAM/UAS Operator:
- Is the link between the passenger transportation demands and the USSP through the filing of a U-plan
- Is assisted by the USSP and Vertiport Operator U-space services in order to validate and fulfil a U-plan
207
- Decides to submit the U-plan once is fulfilled to the USSP for authorisation purposes.
208
4.5.1.4 U-plan Submission
- No limit on time in advance and before the flights takes-off. Taking into account the RTTA
(Reasonable Time To Act)
- The U-plan Submission is intended for all UFR flying within U-space in the selected
environment (Controlled Airspace, e.g., Airspace Class D)
- What is provided? A U-plan Contains:
o 4D Volumes
o Departure vertiport and Time of departure
o Arrival vertiport and Time of arrival
o Alternative destination
o Identification (Vehicle registration/Serial number)
o Aircraft equipage/performance based
o Contingency Plan
o Type of operation
Step Action Trigger Information Roles Role Services involved Remarks

transfer From To
1 Air taxi U-plan UAM/UAS USSP Operation plan Operation plan includes a
operator Operator preparation and trajectory described as a
submits optimisation series of 4D volumes. The
plan service / dimensions of these
Operation Plan volumes incorporate the
Processing allowable uncertainties
of the flight.
Table 64 U-plan submission Use Case.
4.5.1.5 U-plan Authorisation

The USSP receives the information from the U-plan submitted by the UAM/UAS Operator, then there
are a series of steps and checks for that U-plan for review:
Checking broadly consists of the following steps:
- Syntax check. Does whatever have arrived resemble a flight plan enough that it can be read?
- Semantic check. Are all the expected pieces of information present?
- 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. (Equally to

a Trajectory) using the plan and the Weather Information service.
209
- Geo-Fencing check. The probabilistic 4D model is compared with drone aeronautical
information to discover if it is flying where it should in terms of geo-fences.
- Strategic conflict-management check. The probabilistic 4D model is compared with the

models for other flights. Those where the probability of loss of separation exceeds some
minima are dealt with, as described in 6.1.4
- Demand prediction (in U3). The models of all flights are combined to generate a traffic
demand prediction.
- DCB (in U3). The demand prediction is examined to discover when the conditions are met to
say that capacity is exceeded, as described in the Section 4.5.1.8
If all the above checks are correct, then the U-plan is approved and the UAM/UAS Operator/UAS FMS
receives the approval, otherwise is rejected, the UAM/UAS Operator/UAS FMS receives a rejection
and is requested to modify the U-plan to be resubmitted.
210
Step Action Trigger Information Roles Roles Services involved Remarks
transfer involved: involved:
From To
1 Submit U-plan U-plan Has U-plan UAM USSP Operational Plan Service
been created Operator
2 Check U-plan USSP receives USSP USSP Operational Plan Service The USSP receives the
the U-plan information from the U-plan
submitted by the UAM/UAS
Operator, then there are a series
of steps and checks for that U-
plan for review as described
before.
2.1 Expand plan into Operation Plan

probabilistic Processing
occupancy
2.2 Compare Operation Plan

occupancies with Processing
airspace
availability
2.3 Detect conflicts Strategic conflict Conflicts result in negotiation

resolution service with the U-plan preparation and
optimisation service to achieve
resolution
2.4 Detect DCB Capacity management Overloads result in negotiation

overloads service with the U-plan preparation and
optimisation service to achieve
resolution
211
2.5 Check airspace, Operation Plan
noise and other Processing
constraints
3 a. Send U-plan All processes in U-plan USSP UAM Operational Plan Service
Approval the check are Approval Operator
satisfied
3 b. Send U-plan Something is U-plan USSP UAM Operational Plan Service

Rejection not complying Rejection Operator
with the U-plan
check.
3 c. Sends U-plan
modification
request
Table 65 U-plan Submission & Authorisation
212
Figure 48: U-plan action/role diagram resume
Assumptions:
- Flight Plans and U-plans are accurate
- Flight intents can be described without a flight plan, but flight intents need to be known.
- U-plan can be submitted any time (before and after RTTA).
- The use of fulfilment of U-plans are fair.
- The contractual part of the U-plan once is approved is relevant for the payment of the service.
- The U-plan is needed to execute the flight safely with strategic deconfliction to cope with the
limited resources dealing with a Demand and Capacity balancing system, where the demand
is below the capacity and to execute the flight efficiently
4.5.1.6 U-plan conflict detection

The U-plan conflict detection consists of the following steps:
 The USSP receives the U-plan submitted by the UAM Operator and expands the plan into
probabilistic occupancy (Weather Information service and performance model derived from
the Digital logbook service)
 Using information on airspace availability and probabilistic occupancy, the USSP evaluates the
probability of intersection of the submitted U-plan’s 4D volume with already reserved 4D
Volumes in space-time (InterUSS), with geofenced areas (GeoAwareness service) and with
congested airspace (DCB). DSS of InterUSS helps with the discovery of the conflicting plans
and facilitates data transfer using the S2geometry framework (in which 2D cells along a space-
filling curve are turned into a sequence of 4D volumes by specifying the floor and the ceiling
of each occupied cell, as well as the min and max times during which the cell is occupied).
 If the probability is too high, then the U-plan is returned rejected to the UAM Operator to be
possibly revised to ensure the proper separation criteria (the revision process is described in
6.1.1.6).
 A new U-plan is then proposed to the USSP for authorisation and the conflict detection routine
is repeated.
213
Assumptions:
 The available airspace is identified and is known to USSP (hopefully in InterUSS soon): the
USSP has information about all relevant constraints in the whole region of the requested
operation (such as 4D volumes reserved by other airspace users, geofences, restricted areas,
airspace structure and others)
 The Flight/U-plans are accurate
 Uncertainties are correctly accounted for during computation of the required 4D Volume.
 The UAM Operator has the relevant information about the uncertainties.
Delimitations
 Noise and visual pollution is not taken into account at this stage
 Fairness (including economic mechanisms for ensuring and evaluating it) are to be worked out
in further research
214
Step Action Trigger Information transfer Roles Roles Services Remarks
involved: involved: involved
From To
1 USSP Receives flight UAM/UAS Flight Activation UAM/UAS USSP

activation Operator is request Operator
requesting
flight
activation.
2 USSP Analyses all U- USSP is USSP USSP Strategic Using information on airspace
plan received 4D analysing the conflict availability and probabilistic
Volumes flight resolution occupancy, the USSP evaluates the
activation services, probability of intersection of the
request submitted U-plan’s 4D volume with
GeoAwareness already reserved 4D Volumes in
service space-time (InterUSS), with
geofenced areas (GeoAwareness
Weather
service) and with congested
service.
airspace (DCB). DSS of InterUSS
helps with the discovery of the
conflicting plans and facilitates data
transfer using the S2geometry
framework (in which 2D cells along a
space-filling curve are turned into a
sequence of 4D volumes by
specifying the floor and the ceiling
of each occupied cell, as well as the
min and max times during which the
cell is occupied).
215
involved: involved: involved
From To
3a USSP activates flight No problems USSP UAM/UAS If there is no problem, then the U-
found in the Operator plan is returned approved/activated
analysis to the Operator.
performed.
3b USSP ask for U-plan Intersection U-plan USSP UAM/UAS If the probability is too high, then
updated/modification probability modification/update Operator the U-plan is returned rejected to
high found. request the Operator to be possibly revised
to ensure the proper separation
criteria (the revision process is
described in 6.1.1.6).
Table 66 U-plan conflict detection Use Case.
216
4.5.1.7 Deconfliction of U-Plan: Pathfinding computation
The deconfliction protocol consists of the following steps, implementing Reg 664's requirement 10(6)
"U-space service providers shall establish proper arrangements to resolve conflicting UAS flight
authorisation requests received from UAM/UAS Operators by different U-space services providers."...
:
 When USSP rejects a proposed U-plan, the USSP informs the Operator about the rejection.
 If the Operator is willing to use an updated U-plan, the USSP sends the Operator several
conflict-free candidate plans, taking into account the risks and efficiency of the operation (the
paths may be computed, e.g., by tools as in [9]).
 If the Operator accepts one of the candidate plans, the Operator informs the USSP about it,
and the steps below are not followed.
 If the Operator is willing to try a plan outside of the candidate plans suggested by the USSP,
the Operator requests from the USSP the details on which grounds the Operator's Plan was
rejected.
 The USSP informs the Operator on occupied airspace time volume with which the proposed
Operation Plan was in conflict.
 The Operator then revises the Operation Plan taking into account the new constraints and
actively facilitating DSS to avoid conflicting with any other constraints not involved previously.
 The UAM/UAS Operator submits the new Operation Plan back to the USSP for new approval
and the U-plan Authorisation routine is repeated.
Assumptions:
 The USSP has information about all relevant constraints in the whole region of the requested
operation (hopefully in InterUSS soon).
 The Operator has necessary technical means to revise the U-plan.
Delimitations:
 The timings (RTTA, how long in advance before the departure should the U-plan be sent by
the Operator, how fast should the USSP reply Yes/No to the Plan, how soon should the
Operator accept/reject a candidate, how often and how many times may the Operator retry
Plan submission, etc)
 The acknowledgements that may need to be sent between the Operator and the USSP
(authorisation request received, authorised plan receipt ack, etc.) are not described
Notes:
217
 As InterUSS develops, deconfliction may be supported by the corresponding Entities types (or
similar)
218
Step Action Trigger Information Roles Roles Services Remarks
transfer involved: involved: involved
From To
1 USSP Receives flight UAM/UAS Flight Activation UAM/UAS USSP

activation Operator is request Operator
requesting
flight
activation.
2 USSP Analyses all U- USSP is USSP USSP Strategic Using information on airspace
plan received 4D analysing the conflict availability and probabilistic
Volumes flight resolution occupancy, the USSP evaluates the
activation services, probability of intersection of the
request submitted U-plan’s 4D volume
GeoAwareness with already reserved 4D Volumes
service in space-time (InterUSS), with
geofenced areas (GeoAwareness
Weather
service) and with congested
service.
airspace (DCB). DSS of InterUSS
helps with the discovery of the
conflicting plans and facilitates
data transfer using the
S2geometry framework (in which
2D cells along a space-filling curve
are turned into a sequence of 4D
volumes by specifying the floor
and the ceiling of each occupied
cell, as well as the min and max
times during which the cell is
occupied).
219
transfer involved: involved: involved
From To
3a USSP activates flight No problems USSP UAM/UAS If the there is no problem, then the
found in the Operator U-plan is returned
analysis approved/activated to the
performed. Operator.
3b USSP request for U- Intersection U-plan USSP UAM/UAS If the probability is too high, then
plan probability modification/update Operator the U-plan is returned rejected to
updated/modification high found. request the Operator to be possibly
revised to ensure the proper
separation criteria.
4b UAM/UAS Operator UAM/UAS Pilot On

implement a change Operator Board /
of its 4D route FMS
Table 67 Deconfliction of U-planning: Pathfinding Computation.
220
4.5.1.8 Strategic DCB Planning Measures Management
The ambition should always be able to deliver fair and optimal system capacity meaning reducing the
impact on requested operations. Primarily this is done by elaborating with available capacity tools as
described further down.
It is noted that local environmental constraints need to be considered in the application of strategic
DCB measures. The environmental parameters will aim to on a general level set the boundaries for
the distribution of the services based on the characteristics of the area / landscape, expected noise
and visual noise and density of population.
One U-space service is relevant in this case Dynamic Capacity Management. (Source CORUS CONOPS
Vol 1, 2019)
The table below suggest affected actors, identify services and allocation of roles. An assumption is
that the USSP contains functionality to integrate data like U-plans/Operation Plan, weather,
environmental constraints, airspace availability etc. and based on these data calculate the actual
enablers needed i.e. Airspace, Vertiport etc. to serve the demand from the U space users.
To demand and capacity balancing a number of measures can be taken, a few examples are shown
below. This shall be evaluated further to find all possible actions that could have a positive impact on
the capacity.
a) Act on capacity
a. Airspace reconfiguration, as additional airspace, routes, areas and altitude layers.
b. Vertiport availability, the assumption is that Vertiports will be scalable, an increase
of Vertiport availability could be changing the opening hours (i.e., open for some
more hours or open earlier than planned).
c. Improve CNS infrastructure, optimising separation based on PBN, adaption of speed
ETA
d. Optimize separation criteria’s incorporating weather parameters, as reduced
separation minima in good weather conditions and vice versa.
b) Act on demand:
a. Re-routing
b. Level changes depending on performance.
c. Adaption of speed
d. Apply time adjustments, including advance/delay departure/arrival times to a U-
PLAN/Operational Plan. (Like a CTOT)
e. Cancellation of flights as a final step in adverse situations.
221
Step Action Trigger Information Roles involved: From Roles Services involved Remarks
transfer involved: To
1 Establishing Information from Message Vertiports, USSP Dynamic Capacity *environmental

predicted system actors* regarding Municipality, Management constraints,
capacity capacity change Regulator, Police, regulations
MET-office, national and
information from local
ATC etc.
2 Identification of U-plan/Operation U-plan/Operation UAM/UAS Operators USSP Dynamic Capacity

critical parts for Plan received Plan Management
successful mission
3 Validation of U-plan/Operation USSP, with the help USSP Dynamic Capacity

Operation Plans and Plan of a technical system Management
generation of 4d
trajectories
4 Identification of Conflict analysis U-plan/Operation USSP, with the help USSP Dynamic Capacity
conflicts in Plan of a technical system Management
Operation Plans
5 Analysis of Demand and USSP, with the help USSP Dynamic Capacity
estimated demand capacity data of a technical system Management service
vs available capacity and the consolidated
including safety and constraints from
social aspects ATC, society etc.
6 Take action with Analysis result Decision USSP, with the help USSP Dynamic Capacity
regard to identified regarding of a technical system Management
imbalances capacity changes
preference is to
add capacity
222
rather than
restrict
availability
7 Analysis and follow Previous USSP in first case. USSP Dynamic Capacity Trigger possible
up operations Depending on the Management adjustment of
magnitude of the parameter for
results municipality, the airspace
regulator, operator and possible
may be involved. directions for
ATC may be involved the operators.
depending on. Feedback to
society actors.
Table 68 Table presenting the steps for the Strategic Dynamic Capacity Balancing measures
Sources; DACUS project 2021 and CORUS ConOps Vol 1 2019.
Once the measure is computed, if affects different U-plans, these measures are sent to UAM/UAS Operators to start a negotiation where the UAM/UAS
Operator can:
1) Accept the measure and update/modify its U-plan.
2) Reject the measure and cancel its U-plan
3) Send a counter proposal to the previously sent proposed modification from the USSP. The cycle starts again until a solution is accepted or
rejected and so no approving the U-plan.
These measures finally end in a U-plan update or modification.
223
4.5.1.9 U-plan Update/Modification
During the draft status of a U-plan or even when the U-plan is approved, the UAM/UAS Operator and the USSP can request to update or modify any element
of the U-plan content as in section 4.2.11.4 in an iterative process until the flight request its flight activation.
This can also occur either the UAM/UAS Operator has the need to update or modify its flight intentions (e.g., change of the route, its 4D volumes, etc.) or
the USSP/CISP needs to apply any correction within the U-plan due to any of the checks involving the U-plan authorisation process (4.5.1.5).
UAM/UAS Operator U-plan Update request:

From To
1 Modify/update of U- UAM/UAS Operator Update its U- UAM/UAS UAM/UAS Flight Planning UAM/UAS Operator has the
plan needs to update or plan Operator Operator Management /U- need to update or modify its
modify its U-plan plan Management U-plan.
2 Send /Re-submit the U-plan is sent to U-plan UAM/UAS USSP Flight Planning U-plan is sent, and its status is
updated or modified USSP updated Operator Management /U- changed to drafted if it was
U-plan (4.5.1.4) plan Management previously approved, the is re-
submitted accordingly to
(4.5.1.4).
3 U-plan Authorisation The new U-plan has U-plan USSP USSP Flight Planning As in section (4.5.1.5).
(4.5.1.5) been resubmitted updated Management /U-
plan Management
Table 69 U-plan Update/ Modification Use Case.
In the case of the USSP/CISP requesting the modification or update, it should take into account the RTTA and its priority as indicated in section 4.2.11.2 and
4.2.11.3.
224
From To
1 Need of U-plan Any of the Authorisation USSP USSP Flight Planning Any of the Authorisation
modification or checks performed by the Management /U- checks performed in 4.5.1.5 is
update. USSP in 4.5.1.5 is not plan Management not fulfilled in the submitted
fulfilled in the submitted U-plan. U-plan needs to be
U-plan. modified and its status is
changed to drafted.
1a U-plan Conflict USSP sent UAM/UAS U-plan USSP UAM/UAS Flight Planning Accordingly, to 4.5.1.7.
Detection: Operator a proposal for modified Operator Management /U- Continue on step 3.
Deconfliction modification on the route proposal plan Management &
using pathfinding and its 4D volumes. Strategic Conflict
Resolution
1b U-plan affected by USSP sent UAM/UAS U-plan USSP UAM/UAS Flight Planning As in section (4.5.1.8)
DCB Strategic Operator a proposal for modified Operator Management /U-
Measure modification on the U- proposal plan Management &
plan to accommodate a Strategic DCB
DCB Strategic Measure Management
2b Negotiation of Drones Operator receives U-plan UAM/UAS USSP Flight Planning A negotiation is opened to
change a modification proposal modified Operator Management /U- allocate the Strategic DCB
and can negotiate to proposal plan Management & Measure, this can be 1)
accept or propose new Strategic DCB Accepted, 2) Rejected or 3)
modification. Management Counter proposed
2b-1 Measure accepted The measure is accepted Measure UAM/UAS USSP Flight Planning Continue on step 3
by UAM/UAS Operator. message Operator Management /U-
plan Management &
225
From To
Strategic DCB
Management
2b-2 Measure rejected The measure is rejected Measure UAM/UAS USSP Flight Planning U-plan is rejected and is not
by UAM/UAS Operator. message Operator Management /U- approved. End of the process.
plan Management &
Strategic DCB
Management
2b-3 Counter proposal There is a counter Measure UAM/UAS USSP Flight Planning After sending a counter
proposal measure sent to message Operator Management /U- proposal, it iterates the cycle
USSP. plan Management & starting in step 1, USSP
Strategic DCB evaluating the need of
Management update or not.
3 Send /Re-submit U-plan is sent to USSP U-plan UAM/UAS USSP Flight Planning The U-plan is re-submitted
the updated or updated Operator Management /U- accordingly to (4.5.1.4).
modified U-plan plan Management
(4.5.1.4)
4 U-plan The new U-plan has been U-plan USSP USSP Flight Planning As in section (4.5.1.5).
Authorisation resubmitted updated Management /U-
(4.5.1.5) plan Management
Table 70 U-plan Update/ Modification for Conflict resolution and DCB processes.
226
4.5.1.10 Pre-tactical Phase
The pre-tactical phase is design for those last moment measures where flight disturbance is minimum,
as the UAM/UAS Operator has already requested for U-plan activation, the certainty of the flight is
really high, and it is ready to start moving. Also, in this phase it is considered the allocation of high
priority flights (e.g., emergency flights). At that moment, the U-plan should be in the status of
approved, after requesting the activation of the U-plan, the RTTA of that flight is close to be reached,
and so the flight is in the status of freeze, where not many changes can be accommodated either by
the UAM/UAS Operator or by the network (USSP or CISP in case of multiple USSP).
During the U-plan activation process, pre-tactical DCB and pre-tactical conflict resolution processes
are checked and applied if needed as follows:
4.5.1.11 Pre-tactical U-plan conflict detection

During the pre-tactical phase, the process followed for the U-plan conflict detection is the same as
applied during the Strategic phase as described in section 4.5.1.6.
The flight is in this moment close to RTTA, and has requested for the flight activation, the uncertainty
of the flight is now very low and the flight is frozen.
Only small adjustments in its U-plan or changes due to high priority flight are considered here (e.g.,
emergency operations). The second has a low probability to occur.
Assumption:
- Emergencies operations has low probability to occur, and so, the disturbances in the pre-
tactical phase due to this are rare.
- Small adjustments are considered as the ones that the Drone Operator and the network (i.e.,
the USSP or the CISP) are able to accept or pre-accept without negotiation after RTTA without
major consequences of the operation and business. No specific values are set in this part of
the project.
4.5.1.12 Pre-tactical DCB Measures

The ambition should always be able to deliver fair and optimal system capacity meaning reducing the
impact on requested operations. Primarily this is done by elaborating with available capacity tools as
described further down.
It is noted that local environmental constraints need to be considered in the application of strategic
DCB measures. The environmental parameters will aim to on a general level set the boundaries for
the distribution of the services based on the characteristics of the area / landscape, expected noise
and visual noise and density of population.
One U-space service is relevant in this case Dynamic Capacity Management. (Source CORUS CONOPS
Vol 1, 2019).
The table below suggest affected actors, identify services and allocation of roles. An assumption is
that the USSP contains functionality to integrate data like U-plans/Operation Plan, weather,
environmental constraints, airspace availability etc. and based on these data calculate the actual
enablers needed i.e., Airspace, Vertiport etc. to serve the demand from the U space users.
To demand and capacity balancing a number of measures can be taken, a few examples are shown
below. This shall be evaluated further to find all possible actions that could have a positive impact on
the capacity.
227
c) Act on capacity
a. Airspace reconfiguration, as additional airspace, routes, areas and altitude layers.
b. Vertiport availability, as increased Vertiport availability as opening hours, the
assumption is that Vertiport will be scalable.
c. Improve CNS infrastructure, optimising separation based on PBN, adaption of speed
ETA
d. Optimize separation criteria’s incorporating weather parameters, as reduced
separation minima in good weather conditions and vice versa.
d) Act on demand:
a. Re-routing
b. Level changes depending on performance.
c. Adaption of speed
d. Apply time adjustments, including advance/delay departure/arrival times to a U-
PLAN/Operational Plan. (like a CTOT)
e. Cancellation of flights as a final step in adverse situations.
 Bubbles proposed to reduce the vertical band allowed for the flight.
228
1 Establishing Information from Message Vertiports, USSP Dynamic Capacity *environmental

predicted system actors* regarding Municipality, Management constraints,
capacity capacity change Regulator, Police, regulations
MET-office, national and
information from local
ATC etc.
2 Identification of U-plan/Operation U-plan/Operation UAM/UAS Operators USSP Dynamic Capacity

critical parts for Plan received Plan Management
successful mission
3 Validation of U-plan/Operation USSP, with the help USSP Dynamic Capacity

Operation Plans and Plan of a technical system Management
generation of 4d
trajectories
4 Identification of Conflict analysis U-plan/Operation USSP, with the help USSP Dynamic Capacity
conflicts in Plan of a technical system Management
Operation Plans
5 Analysis of Demand and USSP, with the help USSP Dynamic Capacity
estimated demand capacity data of a technical system Management service
vs available capacity and the consolidated
including safety and constraints from
social aspects ATC, society etc.
6 Take action with Analysis result Decision USSP, with the help USSP Dynamic Capacity
regard to identified regarding of a technical system Management
imbalances capacity changes
preference is too
add capacity
229
rather than
restrict
availability
7 Analysis and follow Previous USSP in first case. USSP Dynamic Capacity Trigger ev.
up operations Depending on the Management adjustement of
magnitude of the parameter for
results municipality, the airspace
regulator, operator and possible
may be involved. directions for
ATC may be involved the operators.
depending on. Feedback to
society actors.
Table 71 Table presenting the steps for the Strategic Dynamic Capacity Balancing measures
Sources; DACUS project 2021 and CORUS ConOps Vol 1 2019
230
4.5.1.13 Tactical Phase
4.5.1.14 Departure and Taxi Out

Step Action Trigger Information Roles Roles involved To Services involved Remarks
transfer involved
From
1 Calculate/select Taxiing path UAM/UAS UAM/UAS Operator A new service Pilots receives the bay number
taxiing path calculated Operator needed to provide and the taxiing path.
(optional) and sent to taxiing path (for
pilot drone operator,
vertiport operator)
2 Send taxi Taxiing path UAM/UAS USSP Optional. Depending on the need
clearance and calculated Operator of the vehicle of taxiing.
departure and sent to
request pilot Pilot
3 Send taxi and Taxi and USSP / UAM/UAS Operator A new service Vertiport operator or U-space
departure departure needed? system receives the calculate
clearance clearance Vertiport taxiing path and proceed to
information Operator To deal with DCB approve or reject the taxi
capabilities for clearance.
vertiport? Or
Automatic taxiing
clearances issuing?
4 Calculate Passenger is N/A UAM/UAS UAM/UAS A new service Pilot inform about his/her
departure inside Air Operator. Operator. needed? position in the departure
sequence and taxi, and sequence and the ascent path to
path wants to U-space Weather Service be followed.
departs from systems
231
Step Action Trigger Information Roles Roles involved To Services involved Remarks
transfer involved
From
vertiport A
(departure)
5 Implement Pilot on N/A

departure Board
procedure
6 Send UAS take off Send UAS Pilot on UAM/UAS Operator Pilot or automated system
“departure” take off Board informs U-space system that the
information message to UAS is finally taken off.
U-space
Table 72 Departure and Taxi Out UC
232
Figure 49: Departure and Taxi Out Use Case
233
4.5.1.15 En-Route
This “use case” is a poor fit for the usual form. Use cases often describe a sequence of steps. In the en-route phase there are very few steps but there
are many simultaneous processes, each waiting for a triggering event. To explain this each will appear as a separate use case which will be shown
being triggered.

transfer involved involved involved
From To
1 Climb to cruise End of departure Confirmation & U-space Pilot Surveillance Used by U-space
altitude, Accelerate to phase (ATZ cleared) acknowledgment system Data to inform an
cruise speed of departure Exchange aircraft that it is
radar contact identified using
an approved
surveillance
source. Pilot to
respond with
acknowledgment
2 Follow planned route Aircraft has achieved Clearances,

to point where cruise altitude and advice and
See “continuous” steps below
approach process cruise speed requests
starts
3 Decelerate to speed as End of cruise phase Confirmation & U-space Pilot Surveillance See step 1
applicable for UAS acknowledgment system Data
approach procedure of arrival radar Exchange
contact
Descend to arrival
point.
4 Enter arrival use case Aircraft cleared for Approach U-space Pilot Traffic Control of
approach clearance system Information aircraft handed
234
From To
over to arrival
vertiport
Continuous Submit position SSR (Secondary Position Aircraft Ground Surveillance

reports to the tracking Surveillance Radar) system Data
service Exchange
Continuous Follow and act on the Potential loss of Tactical U-space Pilot Tactical
information coming separation clearance and system Deconfliction
from the Tactical instructions Service
conflict resolution according to
service deconfliction
strategy
Continuous Use the Emergency Non- Declaration of Pilot U-space Emergency Pilot informs U-
Management service nominal/contingency emergency system Management space system of
to inform of an event Service an emergency
emergency
Continuous Follow and act on the Declaration of Tactical U-space Pilot Emergency System issues
information coming emergency received instructions system Management tactical
from the Emergency Service instructions to
Management service assist in
emergency
Continuous Follow and act on the Airspace volume Warning of non- U-space Pilot Conformance Takes place
information coming proximity conformance system Monitoring when aircraft
from the Monitoring Service diverges from
service planned
trajectory or U-
space corridor,
235
From To
or is nearing a
geofence with a
forbidden zone
Continuous Follow and act on the Traffic proximity Warning on U-space Pilot Traffic Takes place
information coming presence of Information when other
from the Traffic traffic Service aircraft become
Information service close
Table 73 En-route UC
236
4.5.1.16 Landing and Taxi In
Initial assumptions:
Early Air taxi vehicles will have a pilot on board to ensure safety, but they will be largely automated
type of aircraft. Industry’s ultimate vision, after an initial transition period, is to operate them without
an on-board pilot.
Some initial low-volume UAM operations with a pilot on board could be managed much as helicopter
traffic is managed today. However, another set of rules will be needed for the higher-volume and more
automated operations that will follow.
A Vertiport may be surrounded in the beginning by a mini-Approach area (a V-TZ, Vertiport Traffic
Zone), in which the sequences of arriving UAM vehicle will be managed and abnormal procedures such
as holding operations will be conducted.
Landing operations at Vertiports (both departure and arrival) will be managed through U-space
specialised functions, a fully automatic system that will perform the necessary control tasks (sequence
building, landing clearances, hold instructions, taxi clearances, etc.). When operating in Vertiport(s)
based in the premises or the vicinity of an Airport, an Air taxi landing operation will require some form
of interaction (through U-space) with ATM and will be indirectly submitted to air traffic control
monitoring.
237
Step Action Trigger Information Roles involved Roles involved Services involved Remarks
transfer From To
0 Calculate path to At the Landing UAM/UAS USSP A new
Pilot/Flight
the vertiport beginning of sequence info Operator service/specialised
Management system
the flight. and descent path U-space functionis informed about
calculated and needed? his/her position in the
sent to pilot landing sequence and
Weather Service? the approach path to
be followed.
1 Send landing eVTOL Landing UAM/UAS USSP / Vertiport A new service Slot was pre-planned
clearance request following clearance request Operator Operator needed? and confirmed before
planned take-off.
route to The clearance to
entry point initiate landing
where arrival procedure is sent to
process check if the approach
starts/ sequence and path is
entering V- still correct.
TZ
2 Issue Transfer of the USSP / Vertiport USSP A new service Vertiport Operator
approach/landing approach/landing Operator needed? receives the
clearance clearance. To deal with DCB calculated approach
capabilities for sequence and path
vertiport? Or provided by the Pilot
Automatic landing through the USSP and
clearances process the clearance
issuing? request to issue the
clearance. Any
inconvenience
regarding the
availability/occupancy
of the Vertiport
landing pad shall be
238
transfer From To
promptly
communicated by the
Vertiport Operator to
the relevant USSP.
3 Implement Pilot/Flight N/A
landing Management
procedure till system
touchdown
4 Send “landed” eVTOL Send eVTOL UAM/UAS USSP Pilot/Flight
information landed landed message Operator Management system
to U-space inform U-space
system that the UAS is
finally landed.
5 Calculate take- Take- UAM/UAS Pilot on Board A new service Pilots/Flight
off/departing off/departing Operator needed to provide Management system
path/Send take- path calculated take-off/dep path receives the take-
off clearance and sent to pilot (for drone off/dep path bay.
request operator, vertiport
operator?)
6 Send taxi USSP UAM/UAS A new service Optional - Vertiport
clearance Operator needed? operator or U-space
To deal with DCB system receives the
capabilities for calculate taxiing path
vertiport? Or and proceed to
Automatic taxiing approve or reject the
clearances taxi clearance.
issuing?
7 Taxi till Taxi UAS Operator Pilot On Board Optional – Depending
bay/engine off clearance if the vehicle needs
received taxiing. Hovering or
using GME.
239
transfer From To
8 Termination of U- Pilot/Flight Send eVTOL UAS Operator USSP U-plan USSP Change the
plan. Management operation ended deletion/store. status of the U-plan to
Passengers system message to U- terminated. Post-
disembark confirm space flight phase starts.
ready to Vertiport Operator
disembark provides passenger
assistance to the
passenger to
disembark.
Table 74: Air taxi Flight: Landing on an uncontrolled vertiport
240
Figure 50: Arrival and Taxi-In Nominal Use Case flow diagram.
Roles identified:
- UAS Operator:
241
Legal entity performing one or more drone operations and accountable for those drone operations.
The UAM/UAS Operator can have several roles that involve it in different U-space use cases, including
the planning of flights and their execution.
- Vertiport Operator:
A vertiport is an example of an aerodrome for UAS. Each vertiport has an operator, that will be
concerned by the provisions and optimal use of the services to UAS (such as recharging) and to
passengers and/or cargo.
- Pilot on Board/Flight Management System:
Pilot may be a human or software or some combination (Flight Management System). Pilot may be on
the aircraft or remote or some combination. Pilot has responsibility for the safe execution of the flight.
Pilot response times, reliability and other performance criteria meet the operational minima for the
airspace.
242
4.5.1.17 Routine Sub-Use Cases
4.5.1.18 Position report submission

There are different versions of the position report submission service use case. The full table form is probably not very useful to describe them. The
overall use case is in the time frame of the flight.

From To
1 Establish a Activation of Flight id, session id Pilot U-space Tracking There needs to be some
connection to the the flight system service authentication of the source (e.g.
position report (stated by the digital signature).
service. pilot AND Operation
engine swich plan Tracking service will associate this
ON) processing stream of position reports
service (identified by the session id) with
the previously planned flight.
Something should let the tracking
service recognise that this stream is
allowed to do this.
The state machine of the flight is

maintained in the operation plan
processing service. The flight has an
activated state and only in this state
are position reports accepted.
243
many Transmit position Connection ID, position, Aircraft U-space Tracking Information transferred as defined
reports established altitude, heading, system service in Remote ID scheme
with position speed, ground
report service station location &
elevation, time
mark, emergency
status
final End connection to Ending of the Report on end of Pilot U-space Tracking There is an ended state for the
the position report flight (stated by flight system service flight
service the pilot AND
engine swich Operation
OFF) plan
processing
service
Table 75 Submit position reports: login to U-space systems based approach
244
Position reports may be sent by the UAS to U-space. If sent by the aircraft directly this may be via the mobile internet (LTE etc). Alternatively, position
reports may be sent by another entity to U-space: for example, there might be a surveillance service offered by a mobile telephone service provider
based on data extracted from “cell towers.”
Under this alternative methodology, the report submission process for each “open” session may be based on the following steps (from the
perspective of the U-space systems) in a nominal situation:
Step Action Trigger Information Roles involved from Roles involved to Services Remarks
transfer involved
1 Wait for A logon U-space system / Position

position report action has Surveillance service report
been provider (not submission
realized necessarily a U-space sub-service
actor, e.g. telephone
service provider)
2 Receive Position Position report UAS U-space system / Position Position report is
position report report Surveillance service report sent for processing
arrives provider (not submission by the tracking
necessarily a U-space sub-service service
actor, e.g. telephone
service provider)
3 Acknowledge Position Acknowledgement U-space system / UAS Position Adds a layer of

position report report of position report Surveillance service report safety in ensuring
received provider (not submission the pilot is aware
necessarily a U-space sub-service there is a
245
actor, e.g. telephone transmission
service provider) problem
Table 76 Receive position reports: nominal sub-use case
The following table describes a non-nominal case in which no report is received in time, triggering the intervention of the Emergency Management
Service.
Step Action Trigger Information Roles involved from Roles Services involved Remarks
transfer involved
to
1 Wait for A logon action U-space system / Position report

position has been Surveillance service provider submission sub-
report realized (not necessarily a U-space service
actor, e.g. telephone service
provider)
2 No report Time limit for U-space system / Position report

received in next report Surveillance service provider submission sub-
time passes with no (not necessarily a U-space service
report received actor, e.g. telephone service
provider)
3 Warn pilot No report Warning of U-space system / Pilot Emergency Adds a layer of safety in
directly received in time missing report Surveillance service provider Management ensuring the pilot is
(not necessarily a U-space Service aware there is a
actor, e.g. telephone service transmission problem.
provider)
246
Emergency Management
Service described in
further detail in 4.5.1.21
Table 77 Receive position reports sub- use case, non-nominal form - initial version
Further escalation should be triggered by the monitoring service. If the flight has more than one session ID, then the other may still be available. The
tracking service should fuse these. If the tracking service has only an old position for the flight it is the monitoring service that will trigger a non-
conformance.
247
4.5.1.19 Tactical Conflict Detection and Warning Provision

transfer involved involved
from To
1 Predict Track update U-space  Tracking At each track update, or some

imminent loss Service Service similar interval, the tactical
of separation Provider  Tactical conflict detection service tests
Conflict for loss of separation.
Detection
Service What imminent means will
depend on the specific aircraft
involved.
2 Warn of Imminent loss Warning of U-space Pilot(s) Emergency Pilots involved in the conflict
detection of of separation imminent loss of Service Management Service are made aware of the issue
conflict detected separation Provider
248
4.5.1.20 Tactical Conflict Resolution Provision
The tactical conflict resolution service is described here as issuing instructions. This description combines the actions of the pilot and the service:

from To
1 Identify manoeuvre Tactical Conflict Detection service has U-space Tactical Conflict
that will preserve identified an imminent loss of Service Resolution
separation separation and has warned the pilots Provider Service
involved
2 Transmit instruction Necessary manoeuvres identified Deconfliction U-space Pilot(s) Tactical

to pilot instructions Service Conflict
Provider Resolution
Service
3 Change course of Instructions received Pilot(s)

plane
Table 78 Tactical conflict resolution sub-use case
Non-nominal:
Step Action Trigger Information Roles Roles involved Services Remarks

transfer involved to involved
from
1 Warn pilot Separation- USSP/Pilot(s) Pilot(s) Conformance

directly preserving monitroing
manoeuvre
249
instruction
not received
(not found,
delayed,
deemed
infeasible,etc)
2 Follow RA from Pilot(s)

ACAS (Xu)
3 Change course of Pilot(s)

plane
Table 79a Tactical conflict resolution sub- use case, non-nominal form - inital version
250
4.5.1.21 Emergency Management Service
The U-space Emergency management service combines several functions.
1. It allows a pilot to report an emergency with their aircraft

2. It provides some assistance to a pilot whose aircraft is in an emergency condition
3. It warns a pilot of any nearby aircraft which is in an emergency and may pose a danger
4. It warns a pilot of dynamic changes to the airspace, which are typically made to ensure safety or security
5. It warns a pilot of irregularities in connection with U-space system; e.g. periodic reports are not being sent or received
The 1st, 2nd and 3rd cases are combined here. The Air taxi we are discussing is a “nearby aircraft” to that having an emergency.

transfer involved involved to involved
from
1 Pilot A reacts to a warning on the remote Warning ID, latest Pilot USSP GNSS jammers are
piloting station that indicates that the GNSS on RPS position openly sold on far
receiver on the aircraft is unable to determine eastern websites.
the position. The aircraft guidance is now
reliant on inertial navigation which has There should be a
significant drift. Pilot A alerts the emergency set of proposed
management service of the problem and that messages that can
the conformance limits may be breached. be sent to the
emergency
management
service.
251
from
2 Emergency management system acknowledges USSP Emergency

the report. management
system
3 Emergency management system advises Pilot A USSP Pilot Emergency

that the nearest recommended ditching place management
is the river and that flying east to get there will system
not cross the path of any flight expected in the
next ten minutes. (Operation
plan
processing
system)
4 Emergency management system advises Pilot B USSP Pilot Emergency

that A’s aircraft is to the north of their Air taxi management
and has lost GNSS. system
5 Pilot A maintains course, despite the Pilot

uncertainty of the reported position increasing
dramatically
6 Pilot A UAS regains GNSS, the warning UAS Pilot USSP

disappears. The reported position is sent position
252
from
7 Pilot A signals to the emergency management Pilot USSP Emergency

system that the emergency is over. management
system
8 The emergency management advises pilot B USSP Pilot Emergency

that the danger has passed. management
system
Table 80 Emergency Management sub- use case - inital version
253
4.5.1.22 Monitoring Service
Each instance of the monitoring service provides conformance monitoring for one aircraft. As well as warning the pilot of non-conformance, it reacts
to the loss of tracking, for example after an aircraft has crashed. The Monitoring service operates from the moment the flight is activated until the
moment the operator signals that the flight has ended.
Step Action Trigger Information Roles Roles involved to Services involved Remarks
transfer involved
from
1 Initiate monitoring Flight Pilot Operation plan The operation plan processing
activation processing service service has a database of operation
plans. The Monitoring service
reads the appropriate operation
plan from the database.
The operation plan processing

service can allow some updates to
plans which should be transferred
to the monitoring service
I Monitor Track Tracking There are two levels of non-

conformance update, conformance. Recoverable and
Operation plan unrecoverable. SORA and ASTM
Plan processing service WK63418 both cover these
update
I+1 Warn of Pilot USSP

recoverable non
conformance
254
Step Action Trigger Information Roles Roles involved to Services involved Remarks
transfer involved
from
N Monitor Track Tracking

conformance update,
Operation plan
Plan processing service
update
N+1 Warn of Pilot

unrecoverable non
conformance
N+2 Change flight state Operation plan After an unrecoverable non

to “contingency” processing service conformance the flight shall follow
a contingency plan.
Final End monitoring
Table 81 Monitoring service sub- use case - initial version
255
4.5.1.23 Traffic Information service
The traffic information service has two distinct functions.
 It provides a view of the air situation.

 If operating for a pilot, it can warn of the approach of aircraft towards the pilot’s own ship.

from to
1 Initiate traffic info Flight Traffic

activation Information
I Identify tracks in area of Track Traffic

interest update Information,
Tracking
I+1 Forward extract of tracks in USSP Pilot, Traffic Authentication of viewer and
area of interest appropriate USSPs Information what they can be shown is
for viewer required
N Check for traffic “in Track Traffic

proximity” to the flight update Information,
Tracking
N+1 Detect traffic “in proximity” Traffic

to the flight Information
256
from to
N+2 Advise pilot USSP Pilot Traffic

Information
Final Stop traffic information Flight end
Table 82 Traffic Information service sub- use case - initial version
257
4.5.1.24 Contingency Sub-Use Cases
4.5.1.25 Ground Holding Procedure

Several unexpected events could happen that could interfere with the implementation of the planned departure/take off phase (e.g., departure
platform occupied, taxi bays busy, temporary U-space system outage…). This could require the implementation of holding procedures; point 2 of the
normal procedure will become:

from to
2.0 Alert the U-space Unforeseen Alert on potential Vertiport U-space New service The vertiport detects an issue
System there is an event delay to departure Operator systems needed, that will prevent this flight from
unforeseen event temporarily internal to departing at the scheduled time
temporarily blocking blocking the the Vertiport
the departure departure Operator
procedure procedure (“manual”
input of the
issue) (See
section 3.4.3
on Vertiport
Management
System
service)
2.1 Alert UAS pilot of Alert received Alert on potential U-space Pilot Flight Pilot to be alerted of a non-
potential delay to of an delay to departure systems Activation & nominal event taking place
departure unforeseen Deactivation
event Service
temporarily
258
blocking the
departure
procedure
2.2 Calculate & send Requirement Holding time U-space Pilot U-Plan Pilot receives a hold instruction
holding time for a new calculated and sent systems Processing and the holding times to be
instructions departure to pilot Service followed
schedule
2.3 Confirmation of Reception of Acknowledgement Pilot U-space Pilot confirms reception of

reception of hold hold of hold instructions systems instructions
instructions instructions
2.4 Implement hold Confirmation of Pilot Possible constraints are checked

reception sent against, and the pilot decides to
implement the hold.
2.5 Hold End of blocking Termination of U-space Pilot Pilot receives hold exit
terminated/resume event hold/ resume take systems instructions and an updated
departure/ implement off sent to pilot sequence information and
take off procedure landing path.
Table 83 Ground Holding Process UC
259
4.5.1.26 Take-Off Alternate Vertiport Procedure
In case there is an unforeseen problem on-board the vehicle or at the destination vertiport during the flight that prevents the vehicle from landing
at the intended vertiport, there is need to identify an alternate vertiport that can service the non-scheduled landing on the flight.

involved involved involved
from to
2.0 Issue detected on- Pilot / Vertiport

board OR at the Vertiport Management
destination Operator Service
vertiport, requiring
landing at planned
alternate vertiport
2.1 Request alternate Issue detected  Landing Pilot Vertiport Common The pilot identifies their
vertiport for on-board OR at request Operator Information preferred alternate vertiport and
landing clearance the destination  Reasons for Service issues a request for landing
due to non- vertiport non-
nominal event scheduled
landing
request
2.3 Evaluation of Request for Vertiport Vertiport Alternate vertiports are

alternate vertiport alternate Operator Management evaluated for providing a landing
vertiport Service slot for the aircraft
received
260
2.4.a Request for Evaluation of Confirmation of Vertiport Pilot If the vertiport can accept the
alternate vertiport alternative landing slot Operator request, confirmation of slot is
accepted vertiports sent to the pilot
complete
2.4.b Request for Evaluation of  Rejection of Vertiport Pilot If the vertiport cannot accept the
alternate vertiport alternative landing Operator request, rejection of request is
rejected vertiports request sent to the pilot along with a
complete  Proposal for proposal for another option at a
2nd option different vertiport
vertiport
2.5 Confirmation of Reception of Acknowledgement Pilot Vertiport Pilot confirms reception of
reception of alternate of alternate vertiport Operator instructions
instructions vertiport instructions
instructions
2.6 Implement Confirmation of Pilot Pilot executes instructions

alternate vertiport reception sent
instructions
Table 84: Alternate Vertiport Process UC
261
4.5.1.27 Holding/Hovering Procedure
Several unexpected events could happen that could prevent the normal execution of the plan (e.g., landing platform occupied, taxi bays busy,
temporary U-space system outage, temporary local weather – wind gusts, priority flights present…). This could require the implementation of holding
procedures; point 2 of the en-route procedure will become:

2.1 Alert pilot on Unforeseen Alert on Vertiport Pilot Emergency Pilot to be alerted
need for event preventing unforeseen Operator/ U- Management
holding/hovering normal execution event taking space Service
procedure of the plan place systems
2.2 Calculate holding Pilot has been Vertiport Operator evaluates what
path/holding alerted Operator/Air holding procedures are
instruction taxi required and whether the
Operator vehicle can perform them. If it
cannot, it becomes an
Alternate Vertiport Procedure
2.3 Provision of Holding path  Holding Vertiport Pilot Pilot/FMS are sent instructions
holding calculated path/hover Operator/Air to carry out the procedure
instructions to spot taxi
pilot  Estimated Operator
time of hold
262
2.4 Pilot confirms Reception of Acknowledgment Pilot Vertiport Pilot confirms reception of
reception of holding of instructions Operator / holding instructions
holding instructions Air taxi
instructions Operator
2.5 Implement hold Acknowledgment Pilot Pilot/FMS evaluate battery

of instructions status in relation to estimated
time of hold
Table 85 Holding/Hovering Process
263
4.5.1.28 Post-flight Phase
from to
1 Vehicle Check- Passenger Report Pilot, Internal (Semi)automatic process in

up has operator communication nominal cases, more manual
disembarked between pilot if something non-nominal
and operator happened during the flight
Pilot reporting information
not just on flight but also
vehicle performance
(battery, mechanics, etc)
2 Archiving operational Flight has Ops data USSP Digital Logbook Flight is considered
info ended completed once landing
procedure is over
3 Feedback to Something Feedback on Operator to Technical This feedback might be

manufacturer unusual vehicle manufacturer support / actually requested by the
detected OR performance warranty manufacturers periodically
periodic
feedback
request
4 Maintenance Vehicle Maintenance Operator, Operator Responsibility is on the

needs Report maintenance carrying out operator even if activity is
maintenance team, maintenance, outsourced to manufacturer
as per pilot authority perhaps Maintenance report needs
report OR per
264
from to
periodic outsourced to to be sent to authority for

maintenance manufacturer certification
5 Validation/certification Receipt of Confirmation of Authority to Certification of Operator had sent

of maintenance maintenance airworthiness operator vehicle after maintenance report to
activities report maintenance authority.
Authority confirms vehicle is
ready to re-join the fleet
6 Charging Vehicle is Amount Vertiport Charging Should this be done at pre-

active in the charged/batteries operator to flight to avoid battery decay?
fleet (not in swapped operator Vehicles might be designed
maintenance) for either direct charging or
and fit for its battery swapping (not in
next flight, scope of vehicle operations;
except more relevant to vertiport
charge logistics/operations)
Vehicle remains at gate
during charging procedures
7 Crew swapping End of pilot Pilot(s) swapped Operator, Working shifts Should this be done at pre-
shift pilot flight?
Vehicle is Crew will most likely be of 1
charged pilot
Done at control room if
remotely piloted
265
Table 86 Post flight UC
266
4.5.2 Scn-A-ST-Env2
This contains the Use cases modified/adapted to Scn-A-ST-Env2, which adds the complexity of UAM
operations flying within ATC Airspace. Main changes with respect Scenario 1 happen in the Strategic
Phase, in order to coordinate with ATC to stablish UAM corridors within ATC airspace.
4.5.2.1 Strategic Phase
4.5.2.2 Passenger ticketing and boarding

There is no change with respect section 6.1.1.1
4.5.2.3 U-plan Creation

4.5.2.4 U-plan Submission

4.5.2.5 U-plan Authorisation

Additional checks are performed in order to check with ATC the procedures needed to fly in controlled
airspace:
- Procedural ATC check. The probabilistic 4D model is compared with drone aeronautical
information to discover if ATC permission is needed for any parts of the flight.
4.5.2.6 Pre-tactical Phase

There is no change with respect section 6.1.2
4.5.2.7 Tactical Phase

4.5.2.8 Post-flight Phase

267
4.6 Performance and Operational Requirements
On the table of UCs, the requirements are identified, just the identifier linked to a certain step of the UC. This section develops the requirements
identified, providing description, type, and all relevant fields.
Identifier Title U-space Description Environment Additional Type of Rationale

consolidated Information requirement
report area
Unique This attribute Baseline area This text is the core part of This field Information (free Operational or Information
number provides a considered in the the requirement. Ideally, indicates the text) provided by Performance (free text)
identifying short "Consolidated the description should environment the project to provided by the
the description of report on SESAR ensure the requirement is where the complement the project to justify
the U-space research Necessary, Justifiable, requirement description of the the
requireme
requirement. and innovation Feasible, Measurable, applies in terms environment. requirements.
nt. results" Clear and concise and of Urban, Sub-
document. Complete. urban, Rural,
Maritime
and/or Forestry.
CORUS- Temporary 2. Airspace The tactical geofencing All The segregation Operational Provides
XUAM-001 segregation management service shall enable environments must be done flexibility to
of area and geofencing authorised users to "safe" the system,
segregate areas especially with
dynamically and emergency
temporarily. operations.
268
report area
CORUS- Dynamic 2. Airspace The dynamic geofencing All Performance Enables drone
XUAM-002 geofencing management system shall provide environments operators and
and geofencing drone operators and users to
users with coordinates remain aware
of dynamic geofence of active area
polygons with a borders and
minimum accuracy level thus respect
of 1 metre. them.
CORUS- Safety 2. Airspace In accordance with All Operational / Ensures
XUAM-003 requirement management SORA Annex E, the environments Safety compliance
s for U-space and geofencing provision of external with U-space
service services (as the U-space regulations on
providers services) shall comply safety
deriving with safety requirements.
from specific requirements. The
operational higher the SAIL, the
risk most demanding are
assessment these requirements. For
(SORA) operations dealing with
SAIL IV, service
providers shall be
subject to oversight
mechanisms (a
competent third party
shall be involved).
269
report area
CORUS- Transaction 2. Airspace The pre-tactical All Performance Ensures timely
XUAM-004 time management geofencing service shall environments pre-tactical
requirement and geofencing deliver information with geofencing
for pre- a maximum transaction data
tactical time of 120 seconds. exchanges.
geofencing
CORUS- Continuity 2. Airspace The pre-tactical All Performance Ensures timely
XUAM-005 requirement management geofencing service shall environments pre-tactical
for pre- and geofencing deliver information with geofencing
tactical a continuity (max data
geofencing tolerable probability of exchanges.
interruption of service
per flight/hour) equal to
1E-02.
CORUS- Availability 2. Airspace The pre-tactical All Performance Ensures timely
for pre- and geofencing deliver information with geofencing
tactical an availability (max data
geofencing tolerable probability of exchanges.
non-availability of
service per flight/hour)
equal to 1E-02.
CORUS- Integrity 2. Airspace The pre-tactical All Performance Ensures viable
for pre- and geofencing deliver information geofencing
using a software with a
270
report area
tactical minimum design data
geofencing assurance level (DAL) exchanges.
equal to C.
CORUS- Transaction 2. Airspace The tactical geofencing All Performance Ensures timely
XUAM-008 time management service shall deliver environments tactical
requirement and geofencing information with a geofencing
for tactical maximum transaction data
geofencing time of 10 seconds. exchanges.
CORUS- Continuity 2. Airspace The tactical geofencing All Performance Ensures timely
XUAM-009 requirement management service shall deliver environments tactical
for Tactical and geofencing information with a geofencing
Geofencing continuity (max data
tolerable probability of exchanges.
interruption of service
per flight/hour) equal to
1E-05.
CORUS- Availability 2. Airspace The tactical geofencing All Performance Ensures timely
for tactical and geofencing information with an geofencing
geofencing availability (max data
tolerable probability of exchanges.
non-availability of
service per flight/hour)
equal to 1E-05.
271
report area
CORUS- Integrity 2. Airspace The tactical geofencing All Performance Ensures viable
for tactical and geofencing information using a geofencing
geofencing software with a data
minimum DAL equal to exchanges.
B.
CORUS- Human- 2. Airspace Geofencing information All To be further Performance Enables
XUAM-012 machine management should be received and environments understood and human
interface and geofencing displayed through by discussed. ATS oversight and
the ground control may tweak the automation of
station so as enhance rules of the geofencing
human performance airspace which services.
and to allow for may then be
automation. translated to the
operator and
impacting on the
mission.
CORUS- Strategic 4. Conflict The strategic Operational
XUAM-013 deconfliction management deconfliction service
capabilities shall be capable of
detecting conflicts
between flight plans
and of proposing
reasonable
modifications to the
flight plan to the flight
planning management
272
report area
service (alternative
flight plan, different
time slot…).
CORUS- Flight plans 4. Conflict The strategic

XUAM-014 information management deconfliction service
kept in shall have access to a
strategic cloud data base (or
deconfliction other distributed
service structures) where all
the known U-plans are
stored.
CORUS- Impact of 4. Conflict Flight planning Safety
XUAM-015 Flight management management, pre-
planning tactical geofencing,
management tactical geofencing and
, Pre-Tactical emergency
Geofencing, management services
Tactical shall be used as M3
geofencing mitigation to the
and ground risk in SORA.
Emergency
Management
services on
273
report area
SORA based-
risk
assessment.
CORUS- Safety 4. Conflict In accordance with Safety

XUAM-016 requirement management SORA Annex E,
s for U-space provision of external
service services (as the UTM
providers services) shall comply
deriving with safety
from SORA requirements. The
assessment. higher the SAIL, the
most demanding are
these requirements. For
operations dealing with
SAIL IV, service
providers shall be
mechanisms (a
shall be involved).
274
report area
CORUS- Integrity 4. Conflict The strategic Performance
XUAM-017 requirement management deconfliction service
for strategic shall deliver information
deconfliction using a software with a
minimum design
assurance level (DAL)
equal to B
CORUS- Vertical 4. Conflict The U-space shall Operational
XUAM-018 separation in management ensure a common
VLL airspace reference frame for
vertical separation of
drones in VLL airspace.
CORUS- Alternative/u 4. Conflict The flight planning Operational
XUAM-019 pdate of U- management management service
plan shall propose
alternative routes to
users in case of
conflicting plans due to
changes in the
environmental
conditions.
CORUS- Mission plan 4. Conflict The system shall inform Operational
XUAM-020 status management the operator of
accessibility modifications of the U-
plan to confirm that the
accepted route is still
275
report area
valid or if there has
been any modification.
CORUS- Trajectory 4. Conflict The operator shall Operational

XUAM-021 alerts management receive alerts to modify
processing drone trajectories in
for pre- order to avoid potential
tactical de- conflicts with other
confliction drone operators or
manned aviation.
CORUS- Mission 4. Conflict The system shall not Operational
XUAM-022 Request management show information about
privacy of other drone operators.
information
provided
CORUS- Area density 4. Conflict During the validation Operational
XUAM-023 management phase, the system
should take into
account the availability
of the area, considering
all the missions within
the same space/time
horizon.
276
report area
CORUS- Raise conflict 4. Conflict The conflict detection Operational
XUAM-024 alert management service shall raise
conflict alerts to drone
operator 1 and 2 based
on the deconfliction
functionality.
CORUS- Trajectory 5. Monitoring In case the flight is Operational
XUAM-025 alerts going to be conducted
reception in a volume that cannot
be geocaged for
the user, the operator
shall be alerted if a
minimum separation
distance with other
drones cannot be
maintained, to
guarantee that the risk
of collision is negligible
over
populated areas and
low enough in sparsely
populated areas.
277
report area
CORUS- Pilot 5. Monitoring Operators shall be able Operational
XUAM-026 accessibility to receive the location
to of nearby drones and
nearby other aircraft,
unmanned although not their
traffic private data (Traffic
information Information), to
improve situational
awareness.
CORUS- Geographical 5. Monitoring The traffic information Performance
XUAM-027 extension of service shall provide all
the the relevant
information information about
traffic
within a geographic
bounding volume
dimensioned large
enough to ensure the
safety of
all the operations
contained within.
CORUS- Bounding 5. Monitoring The traffic information Related to Performance
XUAM-028 volume for service shall extend the dynamic airspace
emergency information area for a reconfiguration,
procedures certain operation esp. 664
in case of emergency Art10.10.
procedures has been
278
report area
activated in the
surroundings of its
bounding volume.
CORUS- Mission 5. Monitoring The system shall not Operational.

XUAM-029 Request show information about
privacy of other drone operators
information
provided
CORUS- Traffic 5. Monitoring In urban or high drone Regulation 664 Performance
XUAM-030 information density areas, the traffic
to system should provide information
operators traffic information to related.
operators to allow
adequate situational
awareness.
CORUS- VFR 5. Monitoring The system should Complement 1.3 Performance
XUAM-031 information provide information of "Helicopters/VFR
geo-caged areas to VFR traffic position"
aviation. with info flow in
the opposite
direction
279
report area
CORUS- Monitoring 5. Monitoring The system shall allow Performance
XUAM-032 monitoring of the
functional status of
each capability
CORUS- Display of 5. Monitoring The UTM system shall Performance

XUAM-033 the flight display the tracks of the
track drones to:
of drones - other drone operators
- The authority
responsible for the area
CORUS- Front end 5. Monitoring The UTM system shall Performance

XUAM-034 track filtering filter the tracks to show:
- Non cooperative tracks
- Cooperative tracks
- Fused tracks
- A combination of the
upper
280
report area
CORUS- Maximum 5. Monitoring The UTM system shall AMCGM to 664 Performance
XUAM-035 allowed show all the data Ammex V will say
latency (positions, tracks, zones, differently: diff
in UTM alerts,…) with a latency for diff
system of 1 maximum latency of 1 info, percentage
second second. of time it's within
the limit
(demanding 100%
is harsh), etc. NB:
same applies to
"Transaction time
requirement for
pre-tactical
geofencing" and
"Transaction time
requirement for
tactical
geofencing" from
"2. Airspace
management and
geofencing". Note
how other
requirements in
2. do specify
availability
(=probability)
281
report area
CORUS- e- 5. Monitoring UFR flights shall be e- Performance
XUAM-036 Conspicuity conspicuity enabled to
fly within U-space
CORUS- Vertiport 5. Monitoring A Vertiport Operational
XUAM-037 Management Management service
Service will provide information
static and dynamic of
the vertiport facilities to
be used.
CORUS- Data 5. Monitoring The service shall record Operational
XUAM-038 recording all activity. All activity
and must be recorded for
auditing post analytical review,
this includes all inputs,
analysis, and rerouting
decisions and
commands.
CORUS- Provision of 5. Monitoring The system shall Operational
XUAM-039 location provide registered
information tracks to Law
to Enforcement or aviation
authorities authorities,
when required.
282
report area
CORUS- Provision of 5. Monitoring Law enforcement Performance
XUAM-040 mission agencies shall be able to
plan access mission plans
information when required.
to law
enforcement
agencies
CORUS- User 5. Monitoring The system shall allow Operational
XUAM-041 profiling user profiling: restricted
content and
functionality will be
accessible depending on
the profile of the
authenticated user. The
accessibility of each
content and function
must be configurable by
the supervisor.
CORUS- Mission plan 5. Monitoring The system shall Operational
XUAM-042 information provide access to
to Law Mission Plans to Law
Enforcement Enforcement agencies
agencies when
required.
283
report area
CORUS- Provision of 5. Monitoring The system shall Operational
XUAM-043 drone log provide access to drone
access to logs and registered
authorities tracks to law
enforcement
and aviation authorities
CORUS- Tracking 5. Monitoring The tracking service Regulation 664 Operational
XUAM-044 logging shall log all the data for Art 15.1(g)
at least one month
CORUS- Integrity 5. Monitoring The operator should Operational
XUAM-045 alerts receive alerts if the
navigation system is not
able to provide an
accurate position.
CORUS- Connectivity 5. Monitoring The selected Performance
XUAM-046 communication
infrastructure shall
provide connectivity
between the
central system and all
nodes.
284
report area
CORUS- Safety 5. Monitoring In accordance with Safety
XUAM-047 requirement SORA Annex E,
s for U-space provision of external
service services (as the UTM
providers services) shall comply
deriving with safety
from requirements. The
SORA higher the SAIL, the
assessment. most
demanding are these
requirements.
For operations dealing
with SAIL IV, service
providers shall be
mechanisms (a
shall be involved).
CORUS- Flight plan 7. Interface with A flight conformance Operational
XUAM-048 approval air traffic module built in the FPM
control service shall be the
instance responsible for
approving or rejecting
the individual flight
plans based on defined
rules and prioritization
criteria
285
report area
CORUS- Communicati 7. Interface with The system shall allow Performance
XUAM-049 on air traffic the communication
control between ATCO/manned
aviation pilots and
operator/pilot through:
R/T or
D/L or
general voice
communication means
CORUS- Datalink ATC 7. Interface with The C2 Link system may Performance
XUAM-050 voice air traffic offer, for the relay of
performance control ATC voice services, at
least the following
performance:
Voice latency: 400 ms
(maximum)
Availability: 99,998%
(minimum)
CORUS- Provision of 7. Interface with ATM systems shall Operational
XUAM-051 drone air traffic receive drone positions,
information control identification and
to ATM foreseen trajectories in
system in the proximity of
controlled airporsts or controlled
airspace airspace
286
report area
CORUS- Alarm to 7. Interface with The system shall Safety Operational
XUAM-052 supervisor air traffic provide alarms to ATM requirement for + Safety
control systems in case of drone non-nominal
deviations near scenarios.
controlled airspace
CORUS- Vertical 7. Interface with U-space shall ensure a Separation/Confli Performance
XUAM-053 separation in air traffic common reference ct management
VLL airspace control frame for vertical
separation of drones in
VLL airspace.
CORUS- Sensors for 7. Interface with A sensor or a set of Operational
XUAM-054 Collaborative air traffic sensors shall be
ATC control available to measure
Interfacing the altitude.
CORUS- Redundancy 7. Interface with Since U-space Safety Safety
XUAM-055 of air traffic information exchange is requirement for
communicati control expected to rely on non-nominal
on channel cellular networks (e.g. scenarios.
for U-space LTE or 5G), a redundant
information communication channel
exchange (e.g. satellite-based)
represents a safety
mitigation in areas
where coverage of such
networks is not
ensured.
287
report area
CORUS- Connectivity 7. Interface with The selected Operational
XUAM-056 air traffic communication
control infrastructure shall
provide connectivity
between the central
system and all nodes.
Table 87 Requirements
288
Insert project
logo here
5 Safety and Contingency in UAM Operations

5.1 Introduction
The Safety and Contingency Requirements in UAM Operations chapter focuses on ensuring the safe
and efficient operation of Urban Air Mobility (UAM). The section is divided into four main parts or sub-
sections: Air Risk Impact Assessment, Continued Safe Flight and Landing in Alternate Vertiports (CSFL),
Flight Planning and De-Confliction, and Airspace Assessment.
The Air Risk Impact Assessment section examines the potential risks and impacts of different flight
trajectories, corridors, and vertiport locations, while also protecting other airspace users. In this
section, the physical and logical structures of the corridors, trajectories, and vertiports have been
explored. This includes identifying potential risks and impacts associated with different flight paths and
proposing strategies to mitigate possible risks.
The Continued Safe Flight and Landing in Alternate Vertiports (CSFL) section outlines strategies for
safely redirecting and landing in alternative vertiports in the event of an emergency. A tool based on
the Voronoi tessellation algorithm has been developed and tested to assess the impact of different
distributions of vertiports on individual or collective contingencies in the U-space to UAM flights, by
placing vertiports in various locations.
The Flight Planning and De-Confliction section discusses how to plan and coordinate flights to minimize
conflicts and ensure safe operation. Simulations have been performed to study the advantages and
disadvantages of different pre-flight deconfliction methods, including First Filed First Served (FFFS) and
Reasonable Time to Act (RTTA).
The Airspace Assessment section covers the classification of airspace for integrated operations, taking
into account the CORUS volumes, X, Y, and Z considering pre-flight, in-flight, and post-flight phases. It
also includes the Unmanned Flight Rules (UFR), which apply uniquely to airspace users in receipt of U-
Space services within U-Space airspace. UFR is based on deconfliction service(s) for separation
provision and on-board technologies (DAA/SAA) for collision avoidance.
5.2 Air Risk Impact Assessment

5.2.1 Trajectories
The type of trajectories used in Urban Air Mobility (UAM) operations is a critical factor to consider in
terms of both safety and the capabilities and performances of the unmanned aerial vehicle (UAV). In
order to ensure the safety of other airspace users, a combination of U-space services and the type of
Page I 289
Insert project
logo here
trajectories may be utilized. When designing trajectories, potential social, noise, and visual impacts as
well as the presence of ground populations must be considered.
The urban environment presents unique challenges for UAM operations due to the presence of
obstacles and more dynamic changes in the environment. Aircraft may also operate close to obstacles,
as illustrated in Figure 51.
Figure 51: Example of UAM trajectory
This figure depicts an example of a UAM trajectory in the Paris area of France, created using the Google
Earth tool as part of a vertiport model. The horizontal and vertical profiles of the trajectory can be
observed, with three differentiated parts in the vertical trajectory: an ascent with two different angles,
a cruise phase, and a descent with again two additional angles. Therefore, the take-off, cruise flight,
descent, and landing phases, as well as the altitude changes during these flight conditions, can be
observed in the figure.
5.2.1.1 Comparing Free and Predefined Routes in UAM

In aviation, a free route is a route that is not predetermined or fixed, but rather is determined in real-
time based on the needs and conditions of the flight. Free routes allow pilots and air traffic controllers
to choose the most efficient and safe route for a flight, taking into account factors such as weather,
traffic, and airspace restrictions.
On the other hand, a predefined route is a route that is established in advance and is typically used for
flights that follow a regular or predictable schedule. Predefined routes can be used for a variety of
purposes, including optimizing airspace usage and reducing the workload of air traffic controllers.
Page I 290
Insert project
logo here
Predefined routes may be modified in real-time based on changing conditions, but they are generally
less flexible than free routes
Figure 52: Finding the middle ground between Free Routes and Predefined
Free and predefined routes are defined, and their advantages and disadvantages are discussed in Table
88:
Concepts Features Pros Cons

Free to plan a route
between a defined entry Unpredictability
Shortest path
point and a defined exit Complex ATC
Free Route Flexibility for the AU
point. (Not applicable to coordination
take-off and landing)
Better predictability
More restricted
A route is planned prior Organized traffic operations
Predefined Route to departure (Standardized
Not optimal flight paths
procedures)
Table 88: Pros and Cons of Free and Predefined Routes
In addition, the UAV routes and the concepts are presented in Sesar JU project, Metropolis 2 project
[19] to assess the most effective balance between strategic and tactical separation. It is proposed that
the fundamentals for concrete solutions for U-space U3/U4 services that are needed to enable high-
density urban aerial operations, with a unified approach to the following Uspace services: strategic
deconfliction, tactical deconfliction, and dynamic capacity management. Different concepts such as
the centralized concept, the hybrid concept and the distributed concept are described to address both
strategic and tactical deconfliction of the drone traffic over urban areas. For example, in centralized
concept, the main feature of the output is that the flight plans are conflict-free. A flight plan is assigned
as a polygonal path in a fixed layer without changing layers on route.
5.2.1.2 Flight Paths during take-off and landing

The present design concept of flight paths during take-off and landing, which is based on the EASA’
study [20] on Urban Air Mobility, has presented use cases such as air taxis and medical deliveries.
Page I 291
Insert project
logo here
VTOL aircraft can take-off and land vertically by definition. However, limitations can occur vertically
during initial part of take-off with an angle as due to obstacles throughout the trajectory of the flight,
while the rest of the flight path may be shallow.
For UAM flights, it is necessary to consider the use cases that are related to the type of trajectories
needed, as well as the safety implications of each flight path. In this context, EASA’s study proposed a
series of flight paths which can be used for their take-off and landing operations.
A roof-top vertiport is shown in Figure 2 on the left with a 'clear' green trajectory, which indicates
that a VTOL can take off from this vertiport without obstruction. A vertiport at ground level indicates
that the same VTOL would not be able to take off from there because its trajectory is too shallow, and
so there would be an obstruction. This means that this aircraft is not capable of taking off from this
vertiport since its performance is lower.
Figure: 2 A roof-top vertiport [20]
Additionally, EASA provides broad requirements that ensure Urban Air Mobility is adaptable to support
all urban settings and types of VTOLs.
 Vertical take-off
Figure 3 shows a profile designed for vertical take-offs in an obstacle-rich environment. A large portion
of the trajectory is vertical. Certain failures are also manageable under these conditions.
Page I 292
Insert project
logo here
Figure: 3 Vertical take-off [20]
 Conventional take-off
Figure 4 shows the VTOL taking off in an open area without obstacles. VTOL types and missions might
also benefit from a small runway for rolling starts, increasing their energy efficiency. It is important to
take into account that there may be a dip in the trajectory when certain failures occur.
Figure: 4 Conventional take-off [20]
 Elevated conventional take-off
Figure 5 illustrates how VTOLs launch from elevated places in a city (like rooftops of tall buildings),
even when certain failures such as mechanical and structural failures, issues related to flight
manoeuvres may cause the trajectory to dip.
Page I 293
Insert project
logo here
Figure: 5 Elevated conventional take-off [20]
In addition to take-off profiles presented above by EASA, two more sets of objectives are considered
when deciding on the location and kind of vertiports and VTOL trajectories. The aircraft can be certified
in two categories: Basic or Enhanced.
In Basic category, lower safety objectives are set depending on the number of passengers transported
by the VTOL, such as 0-1, 2-6 or 7-9. It can be used for non-commercial air transport of passengers,
outside congested areas such as in the countryside. In non-congested areas VTOLs can perform a
controlled emergency landing in many ways. Landing can be outside a vertiport but must be controlled
as it is shown in Figure 6, similarly to what a helicopter or aeroplane can achieve in case of power-loss.
Figure: 6 Landing in basic category aircraft [20]
In the Enhanced category, the highest safety objectives are set in accordance with the flights in busy
city / urban skies, or for Commercial Air Transport of passengers (Air Taxis). In congested areas such
as cities, a VTOL is expected to perform a “continued safe flight and landing”. Figure 7 shows an
example of a VTOL possible landing locations in an urban area. The immediate landing might not be
possible in a city outside of a vertiport.
Figure: 7 Landing in enhanced category aircraft [20]
5.2.2 Corridors
Corridors are three-dimensional (3D) volumes of airspace which are proposed to ensure the safety of
unmanned aerial vehicles (UAV). There are important safety concerns: when to establish corridors, the
reasons which can trigger the need for these kind of route structures and the parameters that need to
Page I 294
Insert project
logo here
be determined to make the corridors safe to operate in. In addition, presence of obstacles, CNS
performance and aircraft encounters are also discussed.
Corridors are conceived as tools to manage the traffic:
 Target traffic can use the corridors applying established limitations
 The rest of the traffic can only enter the corridor under certain conditions
FAA’s approach [21] to the relationship between UAM, UTM, and ATM operations within different
airspace classes are shown in Figure 8. According to FAA, ATC separation services are not involved in
UAM corridors. On the other hand, the corridors are the actual mechanism which establishes the
separation between UAM and other operations. Performance requirements such as Sense & Avoid
capabilities and manoeuvrability will be implemented in each corridor to increase efficiency of the
operations. Different corridors may have different requirements. As it is seen in Figure 8, UAM
aerodromes will be available, and they will be connected by corridors for point-to-point operations.
FAA considers more complex design to go beyond point-to-point operations. [22]
Figure: 8 Airspace by FAA [21]
Figures 9 and 10 represent “double-sided” corridors. In these figures UAVs move in two different
directions; these can be identified by using indications such as different colours located in each side of
the UAV. A minimum safety altitude should be set, under which the UAV cannot go lower. Figure 11
Page I 295
Insert project
logo here
illustrates the altitude changes in corridors. It is also identified the need to keep the distance between
the UAV and the highest obstacle in the area.
Figure: 9 Double-sided corridors top-view
Figure: 10 Double-sided corridors side-view
Page I 296
Insert project
logo here
Figure: 11 Double sense Corridors
Size of the corridors can also be used to ensure the safety of operations within them if there are
disturbances such as severe weather (wind, rain or visibility). BUBBLES project [23] can be used as a
source of information for designing air corridors’ sizes to ensure the safety and efficiency of UAM
operations. In addition, the DLR blueprint “Concept for urban airspace integration” [24] can be utilized
to integrate corridors in UAM. For example, a poorly equipped UAV such as a delivery drone may
require larger separation to other airspace users due to the limited manoeuvrability or Sense & Avoid
equipment with a smaller detection range.
An example of double-sided corridor dimensions is explored in Demonstration Exercise #2.2, where

the minimum dimensions of a corridor with vertical traffic separation were calculated to meet a
navigation performance (RNP) requirement of 0.02 NM for all U-space users. The resulting dimensions
are shown in Figure 53. In the same concept, the cross-section dimensions may be larger in certain
locations to incorporate existing airspace limitations, e.g. maximum & minimum allowed altitudes of
traffic.
Page I 297
Insert project
logo here
Figure 53: corridor cross-section from Demonstration Exercise #2.2, showing minimum dimensions
5.2.3 Vertiports
In this section the air risk impact assessment for the vertiport environment is discussed. UAM
operations in vertiports designed to minimize air risk are considered in detail. Different approaches to
vertiports are also discussed. Omnidirectional and directional types of approaches are shown in Figure
12.
Page I 298
Insert project
logo here
Prohibited sector e.g., to avoid an obstacle is illustrated in Figure 12a in the omnidirectional obstacle-
free volume. This is a perspective view in which a vertiport presented in an obstacle-free volume with
omnidirectional approach and take-off climb surface and prohibited sector.
a) Omnidirectional [25] b) Directional [25] c) Directional (with wider funnel) [25]
Figure: 12 Different approaches to vertiports [25]
The funnels of a vertiport with a directional approach are also illustrated in different locations in Figure
13. In this figure, the VTOL-capable aircraft can perform a vertical take-off and landing in these
potential vertiports.
Figure: 13 The funnels of a vertiport [25]
Page I 299
Insert project
logo here
Vertiports are also categorized as shown in Table 2. Category-1 defines vertiports as whether taxiing is
allowed or not. On the other hand, Category-2 considers vertiports depending on types of take-off.
[DETAIL EXPLANATION NEEDED]
Category-1 Category-2
Vertiport with taxiing Conventional take-off
Vertiport without taxiing Elevated conventional take-off
Vertical take-off
Mixed types of trajectories allowed
Table 2: Different kinds of vertiports
Physical requirements are set for vertiports to allow simultaneously take-off and landing, such as the
distances between final-approach and take-off areas (FATOs) in obstacle-free volume [25] shown in
Figure 14 . Generic vertical take-off and landing procedure parameters are also presented in Table 3.
Parameter Description
ℎ Low hover height
ℎ High hover height
�㕇�㕂 Width at ℎ
�㕇�㕂 Front distance at ℎ
�㕇�㕂 Front distance at ℎ
�㔹�㔴�㕇�㕂 Width of the FATO
�㔹�㔴�㕇�㕂 Front distance on FATO
�㔹�㔴�㕇�㕂 Back distance on FATO
�㔃 Slope of approach surface
�㔃 Slope of departure surface
Page I 300
Insert project
logo here
Table 3: Generic vertical take-off and landing procedure parameters [25]
Figure: 14 Generic vertical take-off and landing procedure parameters [25]
Operational Constraints
Operational constraints in vertiports are considered and the details are shown in Figure 15. In this
figure air taxiing, ground movement and the details of the vertiport operations are presented.
[REFERENCE] [DETAIL EXPLANATION NEEDED]
The list of constraints is described as follows:
 Whether landing on rooftops in city area or not
 Wind effects during landing and take-off
 Comfort of the passengers during vertiport operations

Page I 301
Insert project
logo here
 Emergency procedures such as escape routes and alternate A/C power
Figure: 15 Physical configuration of vertiports [REFERENCE] COMMENT!!!
The Paris sandbox scenario for vertiport to vertiport is presented in Figure 16. In this figure the
extension of the vertiport funnels and the trajectory between the vertiports are shown. The details of
the vertiport are shown in Figure 17. Different colours and shapes are illustrated to represent corridors
in blue colour, local altitude limit in Orly Airport in orange colour, and the vertiport volume in Orly is
in pink colour.
Page I 302
Insert project
logo here
Figure: 16 Paris sandbox scenario
Figure: 17 Vertiport in Paris sanbox scenario
5.3 Continued Safe Flight and Landing

A probabilistic approach
Page I 303
Insert project
logo here
5.3.1 Capacity planning for Continued Safe Flight and Landing sites and
alternative vertiports in Urban Air Mobility
Electrically powered aircraft envisaged for use in Urban Air Mobility have limited energy storage on
board. In order to avoid critical low energy situations during execution of flights, operations are
foreseen to be deconflicted prior to flight. This means that there is a high probability that the entire
flight will be flown as planned, and no additional time is spent airborne. However, not every flight may
be completed as planned; for example, technical difficulties with the aircraft, unforeseen capacity
problems at the destination vertiport or unexpected weather changes may cause the need for
deviating to an alternative landing site. Also in these cases, it is essential that the flight can be
completed before the energy on board is running critically low. It is therefore important that sufficient
capacity at alternative landing sites is available.
This article discusses the modelling of the probability of use of alternate landing sites and the relation
between the number of flights in an area and the required alternate landing site capacity. It also
investigates the benefits of a U-space service that coordinates the use of alternate landing sites.
5.3.2 Continued Safe Flight and Landing Concept (CSFL)

Aircraft certified in the SC-VTOL enhanced category must be operated such way that in case of a non-
catastrophic failure to a flight critical system, the aircraft can safely continue its flight and land at a
designated landing site. This Continuous Safe Flight and Landing (CSFL) landing site may not be the
original intended destination; it can be any site along the route that has been found suitable and
designated as a possible CSFL site.
In the flight planning phase, the operator must consider the locations of CSFL sites and the CSFL
characteristics of the aircraft when designing the route of the flight, to ensure that at any time during
the flight, in the case of a system degradation, the aircraft is within range of at least one available CSFL
site.
The CSFL sites may be regular vertiports used for normal UAM operations, or they may be sites
specifically created and designated only for CSFL purposes. Since, in urban environments the cost of
having landing areas is rather high, it is desirable to minimise CSFL sites due to economical reasons,
both in number and in occupied surface area.
To analyse the probability of use of an CSFL alternate it important to distinguish between two
categories of events that may lead to the use of a CSFL site.
Independent events:
In this category are those events that affect only a single flight.
Examples are:
Page I 304
Insert project
logo here
 Technical failures on the aircraft

 Passenger emergencies
 Unforeseen unavailability of landing slot, affecting a single flight.
If Vertiport Y serves as a CSFL site for flights to Vertiport X, each flight into X will have a low probability
of needing to divert to CSFL site Y for technical reasons. The probabilities are independent between
flights.
Dependent events:
In this category are those events that affect multiple flights.
Examples are:
 Vertiport closure (e.g. fire), affecting all incoming flights

 Unforeseen meteorological events
 U-space system degradation
If Vertiport Y serves as the only alternate of Vertiport X, each flight into X will have a low probability of
need to divert to Y in case X becomes unavailable. But these probabilities are not independent. If X
closes, each flight approaching to X will divert to Y.
Figure 54: Safety Objectives from EASA SC-VTOL
Failure conditions definition:
Page I 305
Insert project
logo here
Failure conditions are defined as effects on the aircraft and its occupants, both direct and
consequential, caused or contributed to by one or more failures, considering relevant adverse
operational or environmental conditions. Failure conditions may be classified according to their
severity as follows (AMJ 25.1309):
1. Minor. Failure conditions that would not significantly reduce aeroplane safety, and which
involve crew actions that are well within their capability.

2. Major. Failure conditions that would reduce the capability of the aeroplane or the ability of
the crew to cope with adverse operating conditions to the extent that there would be, for
example, a significant reduction in safety margins or functional capabilities, a significant
increase in crew workload or in conditions impairing crew efficiency, or discomfort to
occupants, possibly including injuries.

3. Hazardous. Failure conditions that would reduce the capability of the aeroplane or the ability
of the crew to cope with adverse operating conditions to the extent that there would be
(a) A large reduction in safety margins or functional capabilities
(b) Physical distress or higher workload such that the flight crew cannot be relied on to
perform their tasks accurately or completely, or
(c) Serious or fatal injury to a relatively small number of the occupants.

4. Catastrophic. Failure conditions that would prevent continued safe flight and landing.
An inverted relationship between the severity of the failure conditions and the probability of
occurrence is established. Hence,
Each of the above probabilities has a maximum value assigned, which depends on the type of aircraft
considered—for example, in the case considered above, extremely improbable is 10−9, as we have
already seen; extremely remote is 10−7; remote is 10−5, and so on.
Page I 306
Insert project
logo here
Page I 307
Insert project
logo here
Figure 55: Classification of failure conditions
The conservative assumption is that if an aircraft diverts to a CSFL site, it will not be able to move from
the FATO after it has completed its unscheduled landing due to technical difficulties with the aircraft.
And thus, the CSFL FATO will be unavailable to other aircraft after the event.
Page I 308
Insert project
logo here
Let Cap_Y be the available capacity (i.e. number of FATOs) of the alternate vertiport Y.
Let P_csfl,A be the probability per flight hour that a specific aircraft A encounters and independent
event causing a need to divert to a CSFL site.
For initial calculation, let’s assume that P_csfl,A is constant during the entire flight and that it is the
same for each aircraft.
A more advanced analysis could consider higher probability in the first segment of the fight, as
well as increasing probability towards the end of the flight.
The higher probability in the first segment will be driven by the transient mechanical and thermal
loads on the components of the aircraft during that segment. If there is a latent technical defect
on the aircraft, it is more likely to manifest itself during this transient phase.
The higher probability towards the end of the flight is mainly driven by operational choices. If
during the flight a probability emerges that the aircraft cannot land at the destination, the
operator will likely defer the decision to deviate to a later moment, when the outcome will be
clearer. For this reason, CSFL sites later along the flight route will likely see a higher probability of
being used.
Scenario 1: analysis of a technical degradation affecting single flight
Let’s assume a vertiport pair connected by flights of 30 minutes. Each flight is divided into 7 segments
for which a different CSFL port is designated. For the first and last 2.5 minutes there is the possibility
to return to vertiport of departure respectively continue to the original destination. The remaining 25
minutes are covered by 5 en-route CSFL sites covering a segment of 5 minutes each.
Each of the en-route CSFL sites has the capacity of accommodating a single vehicle. Thus, after a single
aircraft has deviated to the site, the site is no longer available.
In case a hazardous event happens to flight A, and no available CSFL site can be reached, the outcome
can conservatively be assumed to be catastrophic.
A less conservative assumption would take the possibility into account that an emergency
landing could be made at an unprepared and ad-hoc selected landing site.
Questions to be answered:
How many aircraft can use this route simultaneously without the probability of a catastrophic event
being too high? (need to define the acceptable probability of a catastrophic event)
Page I 309
Insert project
logo here
How many aircraft can simultaneously plan the same CSFL site as alternate for a portion of their flight?
If a CSFL site becomes unavailable during a flight, does the flight need to deviate/reroute or is it
acceptable to continue as planned even though a part of the route is not covered by an available CSFL
site?
If a CSFL site becomes unavailable just prior to flight, does the flight need to stay on the ground/reroute
or is it acceptable to continue as planned even though a part of the route is not covered by an available
CSFL site?
5.3.2.1 List of events that may cause multiple flight to deviate to alternate landing
site simultaneously.
 Vertiport closure
o Fire
o Technical
 U-space degraded / closed
o CNS
o USSP Service layer
 Single USSP
 All USSP
 CISP down
o Manned aircraft emergency crossing U-space
 Meteorological
o Unexpected weather degradation
Normal conditions
Contingencies
Abnormal conditions
e.g. Weather
Fault conditions
Failure in the aircraft
In the UTM system
Page I 310
Insert project
logo here
Reference ESRM (Extended / Safety Reference Material)
5.3.3 Voronoi Diagrams to determine the probability of occupancy of CSFL

vertiport
A Voronoi diagram is a partition of a plane into regions close to each of a given set of objects. In the
simplest case, these objects are just finitely many points in the plane (called sites). For each site there
is a corresponding region, called a Voronoi cell, consisting of all points of the plane closer to that site
than to any other.
Figure 56: Interactive Voronoi diagrams cells determination
Page I 311
Insert project
logo here
Figure 57: Example of a Voronoi Diagram with 12 sites
The sites of a Voronoi diagram can represent a set of vertiports in a given area.
Page I 312
Insert project
logo here
Figure 58: Example of 75 flights and 12 Vertiports in a given area
With 75 flights in average happening simultaneously and 12 vertiport in the area we have a ratio of
flight/vertiport of 6,25 flights. In average those are the flights that would correspond to each cell. What
we can see in practice is that we have one cell with one single flight at a certain moment in time while
there are another two cells with up to eleven flights at the same time instant. This gives a variability in
a range from [1,11] in number of flights handled in a single cell.
The number of flights per cell in this case seems to be driven by three main factors, the total amount
of traffic in the airspace, the number of direct connections from the vertiport in the cell with other
adjacent vertiports and the total distance between the vertiport in one cell and the rest of the
vertiports in the adjacent cell.
Page I 313
Insert project
logo here
5.3.3.1 Probability of the shadow occupancy of a vertiport
Uncertainty areas located in the border of two cells. These areas will assign an equal probability to the
two vertiports in opposite sides to be utilize as CSFL site.
What happen in the event of the closure of one of the vertiports?
The new Voronoi diagram it’s calculated and the UAS assigned to the cell that is closed it will be
assigned to adjacent cells depending on the new configuration.
Page I 314
Insert project
logo here
Figure 59: Example of closure of a vertiport
Questions to be answered (Part 2):
Q: What drives the limit to the number of drones that we can accept in an environment?
There are two limiting factors drive the number of drones that can be accepted in an airspace volume:
 The first one is a volumetric factor where certain number of drones and their respective
deconfliction volumes have to fit in a volume of airspace to guarantee a specific level of
safety in terms of mid-air collisions.
 The second is related to vertiport capacity in two different ways
o Number of parking pads the vertiport may have
o The number of UAS vertiports can manage (throughput)
Page I 315
Insert project
logo here
A further question would be, having certain number of vertiports in an area, what is the amount of
traffic that can be handled?
Defining the following parameters for a UAM environment:
�㕉 = �㕉�㕒�㕟�㕡�㕖�㕝�㕜�㕟�㕡 �㕖-�㕡ℎ �㕖�㕛 �㕡ℎ�㕒 �㕎�㕟�㕒a
�㕁 = �㕇�㕜�㕡�㕎�㕙 �㕛�㕢�㕚�㕏�㕒�㕟 �㕜�㕓 �㕣�㕒�㕟�㕡�㕖�㕝�㕜�㕟�㕡�㕠 �㕖�㕛 �㕡ℎ�㕒 �㕎�㕟�㕒�㕎
�㕃 = �㕁�㕢�㕚�㕏�㕒�㕟 �㕜�㕓 �㕝�㕎�㕟�㕘�㕖�㕛�㕔 �㕝�㕎�㕑�㕠 �㕎�㕣�㕎�㕖�㕙�㕎�㕏�㕙�㕒 �㕖�㕛 �㕣�㕒�㕟�㕡�㕖�㕝�㕜�㕟�㕡 �㕖
�㕇�㕝 = �㕇�㕜�㕡�㕎�㕙 �㕛�㕢�㕚�㕏�㕒�㕟 �㕜�㕓 �㕝�㕎�㕟�㕘�㕖�㕛�㕔 �㕝�㕎�㕑�㕠 �㕖�㕛 �㕡ℎ�㕒 �㕎�㕟�㕒�㕎
�㕃 = �㔴�㕣�㕒�㕟�㕎�㕔�㕒 �㕛�㕢�㕚�㕏�㕒�㕟 �㕜�㕓 �㕎�㕣�㕎�㕖�㕙�㕎�㕏�㕙�㕒 �㕝�㕎�㕑�㕠 �㕝�㕒�㕟 �㕣�㕒�㕟�㕡�㕖�㕝�㕜�㕟�㕡 �㕖�㕛 �㕡ℎ�㕒 �㕎�㕟�㕒�㕎
Page I 316
Insert project
logo here
Page I 317
Insert project
logo here
We can define the total number of pads in the area as:
�㕇�㕝 = �㕉 ∙ �㕃 + �㕉 ∙ �㕃 + ⋯ + �㕉 ∙ �㕃 = �㕁 ∙ �㕃
�㕇�㕝 is a limiting factor for the number of flights we will have in our UAM environment.
We could define…
Rough assumptions for the Vertiport Stands and FATOs:
 Assume x-number of movements per hour.

 Stands capacity
Two types of cites: Vertiports and CSFL sites
CSFL site will have one 1 stand capacity which will be zero once it’s occupied.
5.3.4 Further questions to be answered

Q: Probabilities for the failure of a vertiport have to be researched.
Q: If a vertiport closes how this does affect to aircraft that were not going to land there but had it as
CSFL vertiport during its route.
Q: We have the case when the vertiport closes. Who is affected by this.
 Whoever has this vertiport as a destination will be affected.

 Anybody who has this vertiport as a departure alternate will be potentially affected.
 Anybody who has this vertiport as a landing alternate will be affected.

Q: When do we start using emergency landing sites? What is the criteria for that? Assume that not
everything can be solved beforehand.
One proposal is not to use the vertiports at the highest capacity when they have CFSL purpose. There
will be always some available spots to accommodate flights with contingencies.
Page I 318
Insert project
logo here
Business case questions were also raised.
Q: Who is going to pay for the capacity that is claimed by alternate reservations?
Some system for route taxes might be proposed in this regards.
Q: For ETOPS, only one alternate airport is considered. They don't need to expect more. Can we accept
the same for UAS? What are the possibilities here? Discuss about this and give probabilities giving
assumptions.
List of factors that makes a vertiport not available:
 Technical failure of some system of the vertiport

 All landing spaces are occupied (It has been used as an alternative for some other flight
already)
 External factors (like a fire nearby)
 Weather
 Authorities closing the airspace corresponding to that vertiport (Local environment)
5.4 Pre-flight de-confliction

Simulation study
5.4.1 Introduction to Methods for volume-based pre-flight de-confliction

To achieve successful integration of Urban Air Mobility in densely populated airspaces, the risk of mid-
air collision with other aircraft is a critical concern. Pre-flight de-confliction processes enable operators
to fly safely separated from other aircraft, as long as all aircraft in a given airspace volume are flying as
planned. However, this may come at a high efficiency cost, as a portion of the airspace is ‘reserved’ for
each user when volume-based de-confliction is used. In addition, a residual risk is latent: in case any
aircraft exits its approved volume, there will be a collision risk that may require additional mitigation.
This study discusses different methods for volume-based pre-flight de-confliction and analyses their
performance in dedicated simulations. The analysis of residual risk and the use of tactical mitigations
will be addressed in a separate document.
5.4.2 Volume-based pre-flight de-confliction

The process for pre-flight de-confliction can be modelled via the closed loop illustrated in Figure 60.
This process is formed by the following elements:
Page I 319
Insert project
logo here
 The pool of U-plans. Is a list containing all active and planned flights. Each individual flight in
the pool corresponds to an operational intent or U-plan. This should include enough
information about the operation, such as the expected activation time, the planned 4D
trajectory, the time when the U-plan was filed, the flight priority, and the expected
uncertainties (both in temporal and spatial dimensions).
 The deconfliction scheme. Is the method upon which de-confliction is based. The deconfliction
scheme established the criteria that trigger the conflict search, and the selection of U-plans to
be considered for conflict search and update function. In the present document, two different
methods based on distinct principles will be addressed: first-filed first-served (FFFS) and
reasonable time to act (RTTA).
 The conflict search. The act of searching for possible predicted conflicts among a given set of
operational intents. In the present document, the method to conduct a conflict search is
volume-based, in which each operational intent is defined by one or multiple 4D volumes
which include the planned trajectory and a buffer that accounts for uncertainties. A conflict is
predicted if the 4D volumes of different U-plans intersect. Upon prediction of a conflict, the
update function is triggered.
 The update function. Modifies the U-plans to eliminate conflicts, according to the criteria set
by the deconfliction scheme. These changes can be of varied nature, such as issuing delays,
modifying trajectories, varying speeds, or outright rejecting a filed U-plan. When different
types of modifications can be issued to different U-plans, a set of optimisation criteria are
needed to get a safety acceptable result (e.g.: no conflict) with an efficient set of changes (e.g.:
minimize changes imposed to U-plans).
Page I 320
Insert project
logo here
Figure 60. Closed loop for pre-flight de-confliction
In the present document, three 3 different models that follow 2 distinct approaches have been
considered:
- FFFS (first-filed first-served): flights are deconflicted and locked (i.e., no more changes
expected) at the moment they are filled. This means that the conflict search is executed upon
submission of a U-plan, and the update function only considers modifications to that U-plan,
unless U-plans with a lesser priority are involved. This method provides early fillers with
advantage versus late fillers, as this method acts like a reservation of airspace. Nonetheless,
this method also has drawbacks: penalizes late fillers, which may lead to fairness concerns,
and is more affected by uncertainties and changes, due to de-confliction possibly being done
quite in advance.
- RTTA (reasonable time to act): this approach is based on the idea that, if deconfliction is
pushed closer to flight activation, the inherent reduction of related uncertainties may be
related to better results. Also, this does not discriminate U-plans regarding how early the
operational intents were submitted in advance, which can help achieve fairness in this sense.
Two different models for RTTA have been proposed:
o 1-parameter model: flights are deconflicted a given time in advance related to their
expected activation time, which is the only parameter in this model (e.g.: five minutes
before activation). Only one flight is deconflicted on each occasion, which is locked
after the deconfliction. This method is simple and quick but might have lower overall
Page I 321
Insert project
logo here
performance than the following 3-parameter model, as by considering only 1 aircraft

to be changed, it cannot find a solution other than a local minimum.
o 3-parameter model: flights with activation time within a certain time window are
deconflicted. This process is repeated with a given frequency. The three involved
parameters are: the period between two consecutive conflict searches, the width of
the time window, and the distance between the instant when conflict search is
executed and the start of the time window. These three parameters can be expressed
in units of time. This method tries to find better solutions than the 1-parameter model
by looking at a wider scope, effectively acting like a sliding window. However, the
computational cost is quite high, as multiple combinations of modifications of planned
flights can be executed to resolve conflicts. In addition, the three parameters of the
model are subject to mathematical constraints to ensure that the sliding window
effectively covers all operational intents. While the theory behind this method has
been discussed in the project, it has not been implemented in the simulation tool, due
to lack of resources, being marked as a future development.
5.4.3 Simulation tool description

To compare the performances of the FFFS and RTTA (1-parameter) models, a simulation tool has been
developed. The tool generates a 2D grid, with a traffic pattern corresponding to Figure 61.
Figure 61. 2D grid simulated by the tool
A traffic sample is generated based on certain input parameters, and then the volume-based pre-flight
deconfliction loop is run within the simulation. The simulation includes a primary loop, that represents
the passing of time from the beginning until the end, and a secondary loop, which executes the de-
Page I 322
Insert project
logo here
confliction functions when needed. The primary loop simulates the submission of new U-plans, calls
the secondary loop as required, and the simulates the execution of operations according to their de-
conflicted U-plans. On the other hand, the secondary loop predicts the future state of the simulation
executing a conflict search and modifying U-plans to solve any existing conflict, according to the
applicable rules. To modify U-plans, only delays have been considered as an option. When a conflict is
predicted, a U-plan is increasingly delayed until no more conflicts arise during the prediction.
The following parameters are inputs for the simulations:
 Grid size: the number of rows and columns of the grid (n x n square).
 Duration: the total duration of the simulation (primary loop) obtained as the multiplication of
the grid size and a duration coefficient.
 Uncertainty values: measures the temporal uncertainty of activation of a flight. Represents
the time window in which an operation is expected to be activated and start. The bigger the
uncertainty, the bigger the 4D volumes linked to the operation. Therefore, the 4D volume of
an operation with uncertainty 0 only occupies 1 cell at each instant. If uncertainty is increased
to 3, the 4D volume will have a size of 7 cell at each instant (the baseline one, plus three
forwards, and three backwards). Different values can be defined for different operations, and
also for planned vs active flights.
 Traffic: defines the speed of traffic in terms of cells advanced per unit of time. Also, determines
the total number of aircraft that will be simulated, each linked to a U-plan. To this purpose, a
density parameter is defined, ranging from 0 to 1. Density represents the average percentage
of the total available airspace that is occupied by 4D volumes of aircraft during a simulation.
This means that using a 10% occupation, 10% of the cells in the grid will be occupied in average.
The total number of flights is computed according to the density, uncertainty, grid size, and
simulation length. Hence, a higher density will increase the number of aircraft, while a higher
uncertainty will reduce this number, due to the greater 4D volumes resulting from the
increased uncertainty.
 RTTA: the values for the 3-parameter model (not used) and the 1-parameter model, in time
units.
 Uncertainty distribution: to create a representative traffic sample, three classes of U-plans
have been considered: early, medium, and late fillers. These are classified according to the
time between filing and expected activation time. Early fillers are expected to file long in
advance, and the contrary for late fillers. These inputs allow to define the proportion of early,
medium and late fillers, and which are the time between filing and activation for each class.
The thresholds represent the total number of flight lengths that the flights are filed in advance.
As an example, given the data from Table 89, early fillers always fill in less than 20 times the
Page I 323
Insert project
logo here
length of flight, normal fillers do in less than 5 times, and late fillers always fill in less time in
advance that what a flight takes to complete.
The simulation tool consists in the following modules:
 Traffic generator: generates a set of U-plans according to the inputs listed above.
 Main loop: executes the primary loop of the simulation. Three different versions:
o No-deconfliction: does not call any de-confliction method. Used as comparison.
o FFFS: calls the FFFS de-confliction whenever a U-plan is submitted.
o RTTA: calls the RTTA de-confliction whenever a U-plan is close to activation (when time
remaining to activation is equal to RTTA parameter)
 De-confliction: implemented as a function that performs the conflict search and update
functions when called by the main loop. Two versions:
o FFFS: for FFFS de-confliction
o RTTA: for RTTA de-confliction
 Post-analysis: reads results of the simulations and computes output by means of statistical
analysis.
 Visualisation: reads results of the simulations and generates 2D visualisation of the grid. Can
simultaneously show the 2D grid from the three cases (no deconfliction, FFFS, and RTTA) to
allow comparison.
5.4.4 Simulated scenarios

A total of 4 different scenarios have been simulated in this study. The criteria to define each simulation
is the following:
1) All flights are subject to the same level of uncertainty, both at planning and active phases.
2) Flights have different uncertainty according to the classification of the operation among early,
normal, or late fillers. Early fillers have the most uncertainty, while late fillers have the least.
This uncertainty is not modified upon activation. The lower level of overall uncertainty leads
to increased traffic compared to 1), with the same volume density.
3) Is similar to 2) but in addition to having different uncertainty values when planned, these
uncertainties are reduced to a minimum value upon activation of the flight.
4) Equal uncertainty levels as in simulation 1) but with increased density to match the number of
flights from simulations 2) and 3).
Page I 324
Insert project
logo here
Apart from the uncertainty values among 1), 2), and 3), and the density from simulation 4), the rest of
input parameters have not been modified among simulations. The following table collects all the input
data that define the simulations:
Simulation inputs
Uncertainty values RTTA Uncertainty distribution
General Traffic
Planned Active 3-model 1-model Proportion Thresholds
Grid Duration Flight
# Duration Early Normal Late Early Normal Late Speed Density UR LT UT RTTA Early Normal Late Early Normal Late
size coef number
1 50 100 5000 4 4 4 4 4 4 1 0,05 1389 1 5 6 5 25% 50% 25% 20 5 1
2 50 100 5000 4 3 2 4 3 2 1 0,05 1786 1 5 6 5 25% 50% 25% 20 5 1
3 50 100 5000 4 3 2 1 1 1 1 0,05 1786 1 5 6 5 25% 50% 25% 20 5 1
4 50 100 5000 4 4 4 4 4 4 1 0,064 1786 1 5 6 5 25% 50% 25% 20 5 1
Table 89. Simulation input parameters
In addition, the following graphics show the temporal distribution of flights regarding activation time
(Figure 62), filing time (Figure 63) and elapsed time between filing and activation (Figure 64).
It can be noted (Figure 62) that the number of simultaneous flights at the beginning of the simulation
is lower, but soon reaches a relatively constant value, considering the noise due to the randomized
distribution.
Figure 62. Distribution of activation time
Page I 325
Insert project
logo here
Figure 63. Distribution of filing time
In Figure 64, the peak in low FTA values shows the concentration of the 25% late fillers within [0, 50],
compared to the distribution of the 25% early fillers in [250, 1000].
Figure 64. Distribution of time between filing and activation
Page I 326
Insert project
logo here
5.4.5 Results
Figure 65 shows the 2D plot of the grid in a given instant during the simulations, drawing the 4D
volumes related to in-flight aircraft. The traffic sample corresponds to simulation 4). In the leftmost
graphic, the unmitigated case is shown, in which the traffic sample is simulated without adding any
delays. The centre plot shows the result of the delays proposed by the FFFS method to avoid conflicts,
while the rightmost plot shows the results of the delays proposed by the RTTA method to the same
traffic sample. The same instant is represented in the three pictures. Note how several conflicts are
shown in the leftmost grid, represented in green color.
Figure 65. Simulation of 2D flights with different pre-flight de-confliction strategies:

no de-confliction (left), FFFS (centre), RTTA (right)
Table 90 and Table 91 collect the results for the performed simulations for the FFFS and RTTA methods,
respectively.
Outputs FFFS
Early Normal Late Global
% delayed Avg delay Max delay Occupation % delayed Avg delay Max delay Occupation % delayed Avg delay Max delay Occupation Avg delay Occupation
1 25,91% 3,21 42 0,98% 73,31% 18,29 151 2,92% 83,05% 28,66 162 4,42% 16,99 2,79%
2 30,34% 4,60 63 1,22% 68,75% 14,69 121 3,10% 80,25% 18,73 121 4,56% 13,15 3,01%
3 33,10% 4,46 70 1,13% 71,52% 14,14 92 3,12% 75,96% 16,20 93 4,37% 12,30 2,95%
4 34,64% 5,14 71 1,18% 77,28% 20,77 147 3,65% 90,72% 39,20 213 5,50% 21,54 3,51%
Table 90. Results for FFFS method

Outputs RTTA_1
Early Normal Late Global
% delayed Avg delay Max delay Occupation % delayed Avg delay Max delay Occupation % delayed Avg delay Max delay Occupation Avg delay Occupation
1 80,78% 14,64 61 3,85% 77,86% 14,08 56 3,80% 77,30% 13,84 82 3,61% 14,16 3,76%
2 80,77% 13,86 57 3,67% 75,60% 10,74 48 3,51% 67,90% 8,06 38 3,41% 10,83 3,53%
3 75,86% 11,74 52 2,28% 67,99% 8,45 57 2,23% 59,33% 5,65 39 2,20% 8,56 2,24%
4 89,15% 18,59 66 5,25% 85,95% 18,71 74 4,99% 85,07% 17,93 82 4,83% 18,49 5,01%
Table 91. Results for RTTA method
The following can be appreciated:

Page I 327
Insert project
logo here
- In the FFFS method, early fillers are rewarded while late fillers are greatly penalized, being
subject to higher average and maximum delays. Normal fillers stay in between.
- In the RTTA method, we appreciate a similar treatment to all operators in simulations 1) and
4), while late fillers appear to be rewarded in simulations 2) and 3). The reason behind this is
that their volumes are smaller, which reduces their delay
- Comparing simulations 3) and 4), the impact of the uncertainty can be seen (same number of
flights, but much higher delays in 4))
5.4.6 Conclusions
- Uncertainty has a great impact on delay.
- The reduction in uncertainties is better leveraged in the RTTA method
- The RTTA method has overall less delays
- The RTTA method does not have fairness issues
- The FFFS method provides great advantage to early fillers
- Also, there are many future developments, such as refinement of planned operations reducing
their uncertainty (only reduction on activation tested in this study). In addition, the RTTA
method with 3 parameters could prove useful if successfully applied. There is interest in
machine learning approaches using reinforcement learning.
5.5 Flight rules and Airspace Classification

Open discussion
5.5.1 Introduction to flight rules discussion and airspace classification

The aim of this document is to set a common ground for discussion of the topics Airspace classification
and Flight rules within T3.3 of the project. The following two sections are taken from the latest version
of the ConOps, meant as the baseline to be considered. Then, some open questions are described.
5.5.2 From the ConOps, regarding AIRSPACE CLASSIFICATION
5.5.2.1 CORUS volumes

The U-space ConOps edition 3 [1] describes some U-space “Volumes” in which different services should
be used. The whole airspace is either X, Y or Z. The aim was a simple scheme for easy comprehension.
Page I 328
Insert project
logo here
 X: No conflict resolution service is offered.

 Y: Pre-flight (“strategic”) conflict resolution is mandatory
 Z: Pre-flight (“strategic”) conflict resolution and in-flight (“tactical”) conflict resolution are
mandatory
For Y and Z an approved plan is required. In both Y and Z the pilot / UAS should be connected to U-
space during flight to allow sending of position information and receipt of warnings, traffic information
and so on.
The descriptions below are for a flight wholly in that airspace. For flights penetrating multiple
airspaces, the conditions for each must be applied for that portion of the flight.
5.5.2.1.1 X volume
In X volumes flights need no plan and receive no separation service.
5.5.2.1.1.1 X, Pre-flight
to confirm that the volume is X, see 3.4. The operator may make use of other services as appropriate
(or as mentioned in the SORA for the flight, if there is one), for example: weather, see 3.8, geographic
information, see 3.9.
5.5.2.1.1.2 X, In flight
No “tactical” separation service is available. The UAS operator remains responsible at all times for
ensuring safe operation.
The UAS needs to be identifiable and will either have to direct remote identification, see EU regulations
2019/947 [4] and 2019/945 [5], or make use of a network identification service, see 3.2.1.
The operator may make use of services as they are available and needed by the circumstances, for
example vertical conversion service (3.19), vertical alert and information service (3.20), emergency
management (3.12)
5.5.2.1.1.3 X, Post flight

An accident and incident reporting service is available, see Section 3.13.
5.5.2.1.2 Y volume
Y volumes fulfil two roles. In the edition 3 ConOps [1] these were mentioned. UAS flight in a Y volume
requires an approved plan. In Y volumes the plans are deconflicted before flight. The two purposes of
Y are:
 The Y volume can exist primarily to limit access

Page I 329
Insert project
logo here
 The Y volume can exist to enable flight with strategic deconfliction
5.5.2.1.2.1 Y, Pre-flight
to confirm that the volume is Y, see 3.4.
Every flight must have an approved U-plan, see Error! Reference source not found.. Approved U-plans
do not conflict due to the strategic conflict prediction, see Error! Reference source not found., and
resolution services, see Error! Reference source not found..
5.5.2.1.2.2 Y, In flight
The U-plan shall be activated to commence flight, see Error! Reference source not found.
 Error! Reference source not found. service, see Error! Reference source not found.
 Error! Reference source not found. service, see Error! Reference source not found., including
Error! Reference source not found., see Error! Reference source not found.
 Error! Reference source not found. services, see Error! Reference source not found.
 Error! Reference source not found., SEE Error! Reference source not found.
5.5.2.1.2.3 Y, Post flight

Error! Reference source not found., is available. The operator may consult the digital logbook, see
Error! Reference source not found.
5.5.2.1.3 Z volume
A Z volume is a volume in which there is a tactical conflict resolution service. Three versions of Z exist:
 Za in which Air Traffic Control manage all the traffic. Such airspaces may exist at an airport.
The expectation is that ATC will communicate with UAS through U-space services.
 Zu in which U-space will provide a tactical conflict resolution service
 Zz in which U-space will provide a tactical conflict advisory service
Za is an existing controlled airspace. This ‘Za’ label is for the UAS community only.
5.5.2.1.3.1 Za, Pre-flight
Page I 330
Insert project
logo here
to confirm that the volume is Za, see 3.4.
Every flight must have an approved U-plan Error! Reference source not found.. The plan will need to
be approved by ATC by means of the procedural interface with ATC, see Error! Reference source not
found.. That procedural interface may result in various conditions being specified.
5.5.2.1.3.2 Zu & Zz, Pre-flight

to confirm that the volume is Zu or Zz, see 3.4.
Every flight must have an approved U-plan, see Error! Reference source not found.. Approved U-plans
do not conflict due to the strategic conflict prediction, see Error! Reference source not found., and
resolution services, see Error! Reference source not found.. The U-plan will be subject to dynamic
capacity management, see Error! Reference source not found.
Strategic conflict resolution in Zu and Zz may operate with a higher residual risk of conflict than in Y,
as there is a tactical process afterwards.
5.5.2.1.3.3 Za, In flight

The flight shall be activated to commence flight, see Error! Reference source not found.
 Network identification service, see 3.2.1. Other surveillance may be mandated.

 Collaborative interface with ATC, see Error! Reference source not found.
5.5.2.1.3.4 Zu, Zz, In flight

The U-plan shall be activated to commence flight, see Error! Reference source not found.
 Error! Reference source not found., see Error! Reference source not found., and Error!
Reference source not found., see Error! Reference source not found.
 Error! Reference source not found. service, see Error! Reference source not found., including
Error! Reference source not found., see Error! Reference source not found.
Page I 331
Insert project
logo here
 Error! Reference source not found. services, see Error! Reference source not found.
 Error! Reference source not found., SEE Error! Reference source not found.
In Zu, the Error! Reference source not found. service issues instructions that the UAS must follow. In
Zz the Error! Reference source not found. service issues advice. Because of the different likelihood of
resulting action, the tactical conflict resolution advice in Zz may be issued earlier than would be the
case for the tactical conflict resolution instructions in Zu.
5.5.2.1.3.5 Za, Zu, Zz, Post flight

5.5.2.2 Synthesis
The following table explains the relationship of the different U-space volumes to EU regulations and
ICAO airspaces. Note below SVFR is a form of VFR and is usually not mentioned as a separate flight
rule.
The U-space Volumes
ICAO 2019/947 2021/664 CORUS- Flight Remarks

UAS U-space XUAM rules
Zone
G above No No Not U- IFR (3,4) & For U-space users such airspace
VLL, space VFR would probably be marked a Y
ABCDEF volume and any U-space operation
plan penetrating this airspace will
either not be approved or will be
subject to conditions or warnings.
ABCDE No No Za IFR (3) Za if and only if the flight’s entry
space planning process that includes
ATC approval.
G VLL No No X VFR & IFR Conditions apply
(4) UAS fly below VFR limits but in
effect conform to VFR
Restricted Yes (1) No X VFR Restrictions may apply:
Page I 332
Insert project
logo here
ICAO 2019/947 2021/664 CORUS- Flight Remarks

UAS U-space XUAM rules
Zone
Restricted Yes (1) No Y Dependent Potentially a no fly zone for UAS
Area on the
restriction
Restricted Yes (1) Yes Y See 5 & 6, No tactical separation service
Restricted Yes (1) Yes (2) Zu UFR Tactical separation service supplied
below
Restricted Yes (1) Yes (2) Zz See 5 & 7, Tactical separation advice supplied
Table 92: Volumes
Notes:
1) ) 2019/947 [4] article 15 does not state that geographic zones are restricted areas. U-space airspaces
created as a result of 2021/664, 665, 666 are expected to be restricted areas due to the obligation on
manned traffic to be conspicuous.
2) 2021/664 describes something approximating Y. Zu and Zz are considered as extending Y
3) IFR only in A.
4) IFR unlikely in G in many countries
5) UFR is defined as how to fly in Zu. In Zu there is U-space tactical conflict resolution, hence UFR
includes obeying U-space tactical conflict resolution. It is expected that Zu only supports UFR and all
aircraft in Zu must follow UFR.
6) An airspace which is a U-space airspace according to EU 2021/664 [8] & [11], most closely matching
the CORUS volume Y, is one aimed at supporting BVLOS operations by means of strategic conflict
resolution. Hence flights in the airspace do not follow UFR as flown in Zu, as tactical support is limited
to traffic information. EU 2021/664 foresees entry of VFR or IFR traffic into U-space airspace as being
an emergency procedure in which U-space traffic “take appropriate measures.” Hence it should be
noted IFR and VFR traffic are not catered for in Y volumes.
Page I 333
Insert project
logo here
5.5.3 From the ConOps, regarding FLIGHT RULES

This section briefly introduces the topic of the rules of the air for flights receiving U-space services. This
topic is the subject of ongoing work as this edition of the ConOps is being prepared and this section
will be enlarged in the next edition.
5.5.3.1 Rules of the Air

into Annex 2 [13]. The Standardised European Rules of the Air (SERA) [12] includes the transposition
of Annex 2 into European law. The legislative framework for SERA includes Regulations (EU) 923/2012,
amendment Regulations (EU) 2016/1185 and the Aviation Safety (Amendment) Regulations 2021
applies to all European Union states and the United Kingdom (as per the EU Withdrawal Act 2018).
Additional flight rules are also applied at the state-level (for example the UK’s Air Navigation Order),
which are designed to align with SERA and ICAO standardisation.
There are two distinct flight rule categories defined in Annex 2 [13] and SERA [12] :
 Visual Flight Rules (VFR); flown in Visual Meteorological Conditions (VMC),

 Instrument Flight Rules (IFR); flown in either Visual or Instrument Meteorological Conditions
(IMC).
5.5.3.2 Avoidance of collisions

 Section 3.2.1 requires that aircraft not come too close to other aircraft
 Section 3.2.2 on right of way describes decisions and actions based on assessments of the
relative positions and motions of other aircraft
In Visual flight rules, there is the expectation that the pilot of each aircraft is aware of what is around
his/her aircraft by means of sight.
Annex 2 [13] chapter 5 describes instrument flight rules. In essence the flight either benefits from a
separation service or traffic information.
5.5.4 UFR
Page I 334
Insert project
logo here
U-Space Flight Rules (UFR) shall apply uniquely to airspace users in receipt of U-Space services within
U-Space airspace. Aircraft and pilots that adhere to standardised U-Space equipment interfaces, and
operate within U-Space Airspace Volumes, shall operate under UFR.
The aim of UFR is to be a flight rule that works for remotely piloted aircraft, without the pilot being
able to look out of the window. Instead, the pilot should be informed about the relative positions of
aircraft by other means.
The principle behind UFR is to enable aircraft operations that cannot conform to either VFR, SVFR or
IFR in all operational conditions. Whilst in some operating cases it is possible for UAM to operate under
VFR if piloted as visual line of sight (VLOS), however, more advanced UAM use cases may not be
capable of “see and avoid” procedures if the aircraft are uncrewed. Likewise, UAM may be
accommodated by IFR in some instances, however, their separation minima may not be suitable for
effective operations in more congested airspace, such as the CTR. The aircraft participating under UFR
are therefore required to be supported by a set of U-Space services for a particular airspace volume.
The required U-Space services and their interface with other ATS depends on the airspace
classification.
UFR is for operations in U-Space volumes for airspace users that are consuming U-Space services. UFR
is based on deconfliction service(s) for separation provision (safety layer 1) and on-board technologies
(DAA/SAA) for collision avoidance (safety layer 2).
 be Electronically Conspicuous to the ground system(s) and to other aircraft within the U-Space
Airspace,
 be in receipt of a traffic information service(s), as required, with respect to other aircraft,
 adhere to any [Digital] ATS clearance/instruction deemed necessary by the controlling
authority,
 have any air traffic separation service managed by a U-Space service.
Aircraft operating under UFR are not expected to receive voice communications from ATS units.
U-Space Mandatory Zone: aircraft operating in a U-Space Mandatory Zone (UMZ) shall be required to
make their position known to U-Space through a defined procedure. States shall be responsible for
defining the required process for making aircraft Electronically Conspicuous to U-Space.
5.5.5 Open questions

This section presents a series of open questions related to the ConOps, that might be tackled in T3.3.
Page I 335
Insert project
logo here
- What makes UFR UFR?

o Is it the fact that aircraft are unmanned?
o Is it the fact that operations are provided with new services?
o Is it the fact that these aircraft need specific RoW rules?
o Other?
- According to ConOps, UFR are to be applied to airspace users in receipt of U-space services.
o What about unmanned aircraft operating in CORUS X volumes, not considered U-
space by EU regulation? Can these users really accommodate to other existing flight
rules (VFR, IFR)? Is there a separate need of flight rules for unmanned aircraft which
operate outside U-space?
o Can (or even, should?) manned aircraft (e.g. initial UAM services) which operate in U-
space airspace operate in UFR? (i.e.: UFR not limited to unmanned but to U-space).
o Other?
- Existing flight rules are defined based on how the pilot gets information from its surroundings
o VFR according to VMC, based on visual feedback
o IFR according to IMC (or VMC), based on instrumental feedback
o How to use a similar approach for the definition of flight rules for U-space airspaces?
 Pilots are not located in the cockpit (possible exceptions?)
 Information is always received through technical means
 Is it reasonable to keep this division for UFR and consider two subsets, one
based on visual (e.g.: VLOS, or FPV cameras, onboard pilot?) and other on
instrumental (either onboard or U-space-based)?
 InterUSS defines two types of operational intents (U-plans): trajectory-based
and volume-based. Should this classification be captured in the UFR?
 for example, regarding RoW in Y airspaces, where a conflict appears
within a trajectory-based and an area-based operation. The area-
based operation would be able to change its trajectory to avoid the
collision without requiring changes to the U-plan. The same action
would be hard for the other operation. Should we then consider in
these scenarios that trajectory-based flight plans have the RoW?
 Area-based operations require more flexibility, are related to more
uncertainty, and are more likely to have a remote pilot.
 Trajectory-based operations favour the use of higher levels of
automation (including the lack of a remote pilot), and are more
efficient in terms of airspace use.
 How does automation affect UFR?
Page I 336
Insert project
logo here
 Having two sets of UFR (one VFR-like and other IFR-like) can be an interesting
approach, but it remains a task to draw a line that defines both. Does it depend
on the kind of information received by the (auto)pilot? Does it depend on the
automation level? Does it depend on trajectory or volume based plans?
 Should we also have subsets of the two UFR sets depending on the type of
airspace? (X,Y,Z,Zz,Zu). The above example is a case of Y. The ConOps already
acknowledges that Zz and Zu do not follow the same UFR
- Given that VLOS flight is defined by unaided continuous visual contact between pilot and
aircraft, is it possible to carry pure VLOS in U-space airspace, considering that there is a
requirement to receive the services? (for example, while the pilot looks at a screen to receive
traffic information service they lose visual contact with the aircraft). Should UFR carry any
consideration related to VLOS, BVLOS, EVLOS, FPV, etc?
o Based on the experience of project BUBBLES, the performance of a pilot in VLOS
conditions is unreliable, especially in cases in which there are several aircraft operating
in the vicinity, in which it is very easy to lose track of your aircraft and confuse it with
others. In addition, it is very hard to visually identify the relative position and distance
of other aircraft, from a VLOS point of view.
- For airspace classification: could a solution be a matrix-based scheme in which, in addition to
the existing ICAO airspace class (ABCDEFG), the airspace might also be designated a U-space
airspace class?
o An advantage is that it would require minimum modification to already existing flight
rules and airspace classes
o However, it requires the definition of the rules for unmanned aircraft in this airspace
classes
o And also, very important, to define the interfaces between the air traffic under U-
space and under ATM.
o Previous discussions in T3.3 included an example of classification of U-space airspaces
as UA, UB, UC, etc, mimicking how VFR and IFR are separated.
 UA would mean a U-space airspace in which aircraft only fly IFR-like rules and
are separated by a tactical service.
 UB would mean a U-space airspace in which VFR-like and IFR-like are possible,
and separation is provided to all users by tactical services
 UE would mean a U-space airspace in which VFR-like and IFR-like operations
can be conducted, but separation services are not provided by U-space.
 The above UA and UB are possible examples of Zu volumes, while UE
represents a Y volume and also similar to EU regulation U-space airspace.
Page I 337
Insert project
logo here
 However, this classification does not provide any clue regarding how VFR/IFR
interact with U-space operations.
- Section 3.5.2.1. Strategic conflict prediction of the ConOps considers two approaches.
o 1) Each point of the desired trajectory becomes a four-dimensional volume
o 2) Each point of the desired trajectory is surrounded by four dimensions by a field of
probability that the aircraft is present.
o The method proposed in EU regulation 2021/664 article 10(2)(b) requires flights
authorisations to be “free of intersection.”, and it is more alike the approach 1), by
defining 4D volumes that contain the aircraft 95% of the time.
o The use of this method also means that the occurrence of a tactical conflict implies a
contingency status in which at least 1 aircraft is not conforming to their U-plan. If there
are no unconformities, no tactical conflicts would be expected, as all flight paths are
deconflicted prior to flights.
o However, for approach 2), the consequences are different. Since it is understood that
there will be a certain overlap (an accepted flight plan has a risk below an acceptable
threshold of having tactical conflicts, even if the flight always complies with its plan)
o Approach 1) is easiest to implement, and seems aligned with EU regulation. However,
it might be ‘less efficient’ from an airspace usage point of view, as each operation is
reserving airspace for its own use. Approach 2), on the contrary, would allow more
efficient use of airspace, and tackle any residual risk with the use of tactical
deconfliction methods (either a service of remain well clear executed by pilots)
o During the RTTA discussions in T3.3, the two approaches were considered for the
theoretical discussion: Approach 1) named as deterministic, and 2) named as
probabilistic. Approach 1) was used to develop the model and simulations.
o Does any of the above have any impact in the topic of airspace classification or the use
or flight rules? Our main topics in this question are related to>
 the use of the airspace as a resource,
 the underlying conditions of use of a service (i.e.: tactical deconfliction as a
contingency or not),
 how operations should be conducted (i.e.: having a explicit 4D volume in
which operations need to be conductor or having a field of probability)
Page I 338
Insert project
logo here
6 Social Acceptance of Urban Air Mobility

This chapter is produced by T3.4 Social Acceptance of Urban Air Mobility. It is a study which purpose
is to identify aspects that have an impact on the societal acceptance of the UAM and propose solutions
to mitigate those aspects that have a negative impact.
This will lead to make recommendations for the ConOps adaption and to suggest improvements and/or
complements to the regulatory framework for filling in the gaps.
6.1 Public surveys

The CORUS-XUAM project has undertaken a review of surveys that cover public acceptance of drones
with the aim to address public concerns and have mitigation measures in place to facilitate a seamless
acceptance of drones in our urban skies. The surveys reviewed are from various organisations (air
traffic service providers, industry, research, universities, airspace security agencies) and countries
(Australia, Germany, Brazil, USA, China, Korea, etc.), and were conducted between 2015 and 2022,
being 2018 the inflection point in which drones were considered for the first time as new entrant
vehicles to share urban transport. Below, a summary is provided in chronological order divided in two
subsections: before the start of CORUS-XUAM and after it.
6.1.1 Till 2020

In 2015, Clothier et al. [113] studied the risk perception and the public acceptance of drones in
Australia. The objectives of this study were to investigate whether the public perceives the risks of
drones differently to that of conventionally piloted aircraft, to provide guidance for setting safety
requirements for drones, and to understand how the terminology used to describe the technology
influences how the public perceives the risk. In this research, it was found that that terminology had
a minimal effect on public perceptions. However, this may change as more information about the
drone technology and risks and benefits of their usage become available to the public.
In 2016, the Office of Inspector General of the United States Postal Service published a report [114]
on the public perception of drone delivery in the United States. This report refers to an online survey
that was administered, in June 2016, to a sample of 18 to 75 year-old residents in all 50 states and the
District of Columbia to understand the current state of public opinion on drone delivery for potential
customers. The survey showed, among other things, that most Americans like the concept of drone
delivery rather than dislike it, but that many have yet to make up their minds. Different groups have
different levels of interest in drone delivery. Drone malfunctions were the main concern of the public,
but other concerns included misuse, privacy, potential damage and nuisance.
Page I 339
Insert project
logo here
In 2017, Lidynia et al.[115] conducted a survey of 200 people (laypersons and active drone users)
living in Germany about their acceptance and perceived barriers for drones. The survey questions were
about the general evaluation of civil drone technology, barriers, demography and further user factors.
The survey results show that user diversity strongly influences the acceptance of drones and perceived
barriers. Active drone pilots were more concerned by a risk in possible accidents, while lay people were
more concerned about the violation of their privacy (the routes that drones should and should not be
allowed to use).
In 2018, an online survey from NATS [116] the UK airspace service provider, showed that drone
acceptance can range from 45%, when seen as a generic technology tool, to 80%, when they are used
in emergency situations.
A deep market study conducted by NASA [117] forecasts that, in the coming years, there will be
numerous markets in which drones will have a stake. As a novelty, additional operations, such as
passenger transport by unmanned aircraft or 'air taxis', are expected to grow exponentially. Air taxis
operations will reduce the travel times of part of the commuting traffic to city centres and contribute
to decongesting ground transport by up to 25% . Urban Air Mobility (UAM) is emerging as the new
concept for drones' future business. In the US, the concept will later be extended to include also
manned electrical vehicles with vertical take-off and landing capabilities, known as eVTOL, under the
new term Advanced Air Mobility (AAM). The paper shows the acceptance level goes up to 55% with
the development of new safety technologies, the improvement in air flow network and automation of
the flights.
In 2019, Airbus also conducted a survey [118] about the public perception of UAM. The Airbus survey
covered four cities/countries around the world, Los Angeles, Mexico City, New Zealand, and
Switzerland, and collected 1540 responses. Results revealed that 44.5% of respondents supported or
strongly supported UAM and that 41.4% of respondents thought UAM was safe to very safe. This
suggests that the initial perception of UAM is quite positive.
The same year, a meta-analysis from Legere of former US public surveys [119] and the DLR survey
to 832 German citizens [120], showed acceptance levels of 60% and 49% respectively. The meta-
analysis focused on the different acceptance levels per mission, with public missions having higher
acceptance than private/commercial uses. The German survey provides results about major public
concerns. The most important one was the misuse of drones for crime (91%) and the violation of
privacy (86%). Both surveys refer to generic (small) drones involved in missions such as police
surveillance or search and rescue. In 2020, Tan et al. [121], surveyed in 2020 the opinion of more than
$1,000$ citizens from Singapore. Delivery drones and passenger vehicles were considered to have an
average acceptance of 62%.
6.1.2 From 2021
Page I 340
Insert project
logo here
In 2021, an EASA survey [122] conducted a comprehensive “Study on the societal acceptance of Urban
Air Mobiltiy in Europe” and obtained the highest acceptance (83% of the respondents had a positive
initial attitude towards UAM, and 71% is ready to try out such service). The UAM proposed was
composed of passenger electrical vehicles (manned and unmanned), cargo drones and also
surveillance drones (unmanned). Special emphasis was given to the different types of passenger
vehicles (manned eVTOL, vectored thrust, lift & cruise and multicopters) and also to concerns related
to the environment. Four thousand people from seven different countries (cities of Barcelona,
Budapest, Hamburg, Milan, Paris and the cross-border region Öresund) were also requested to
respond about safety, security and cybersecurity, environment (including urban wildlife), noise,
privacy and infrastructure. Top ten key results are shown in Figure 66.
Figure 66 - Key results from the EASA survey. Source [EASA2019]
Also, from 2021 three new surveys [123][124][125] focused on analysing the demand for future UAM
services as main focus. The questions were addressed to the public as potential customers. Kloss and
Riedel [124] surveyed almost 5,000 people from Brazil, China, Germany, India, Poland and the US.
Acceptance was measured for different missions (6 using eVTOL and 4 using cargo-drones) and found
out that only 27.3% of the people declare willingness to try passenger drones, mostly for commuting,
business trips or travels to/from airport). On the contrary, the willingness to use cargo drones paying
twice or more as of today was 57.8%.
More positive were the responses from Lundqvist’s survey [125]. This survey was conducted among
almost 500 people from 5 EU regions (in the Netherlands, England, Spain, Croatia and Poland).
Respondents were mainly connected to drone operators or their business. The general positive
attitude towards drones was up to approximately 70%. Specific questions about concerns included
safety, environment and privacy issues. Finally, Park and Joo’s survey [123] was conducted in South
Korea to more than 1,000 citizens, plus 44 experts. The willingness to use UAM (both passenger and
cargo) was 47%, and decreasing when the automation of the vehicles increased.
Page I 341
Insert project
logo here
Near Dublin there is nowadays a drone company (Manna) performing home deliveries. In parallel to
this activity the Dublin City Council published a survey to 902 respondents across all demographics
[128]. The rate of positive feelings towards drone technology was very high (84%), with much higher
rates (92-97%) when drones are used for public services (emergencies, planning, environment, traffic).
Concerns about privacy are still high (75%), and safety and misuse has been declared by half of the
respondents. Interestingly 60% felt it would be essential for any member of the public to get
information about the purpose/ownership of the drone openly.
In 2022 a new survey polled more than 1,000 Americans statistically representative of the US society
[127]. With a different culture than European citizens in remote shopping (an 80% declares to receive
packages at home regularly) the survey revealed that 58% of the Americans are in favour of using
drones for delivery and are ready to pay more (1 dollar -41%- to more than 10 dollars -18%-). Still, the
rate of respondents that prefer drone delivery not to happen is 16%. Almost half of the people declared
to be open to purchase a permanent landing pad on their property. Declared concerns were about the
possibility to lose or ruin the package content (43%) and to lose the human interaction (19%).
New studies about social acceptance of UAM, but involving less participants are shown below. In [130]
47 persons, generally very interested in technology and having already used drones, participated in an
immersive experiment using virtual reality (with helmet-mounted display). The scenario showed a
square at the main station of a large city with a high volume of traffic. Five different vehicles were
included using virtual reality. Four drones were flying at constant altitude and speed over the city
roads. Sounds were realistic and adjusted according to the distance or went completely off. Three
different runs were performed with increasing density and flight altitudes (10-15-20-50-100 m).
Altitude has a significant effect on feeling comfortable. While at 10 m the comfortability was measured
as 5.8 (over 7), at 50 m it was 6.23. In all cases the responses were more positive to higher altitudes.
There are no significant differences in flight noise between the scenarios with and without drone
sounds. In all cases responses are more negative the more drones were flying.
A second scenario showed an air-taxi in a continuous descent from 200 m to a rooftop. The
comfortability of this scenario was (statistically significant) lower than for drones (4.87). Authors
suggest that landing zones should be placed not too close to people in order to ensure better
acceptance.
Interestingly, the former responses about UAM concerns pointed to the violation of privacy as the
major concern, but after the simulation this concern was reduced from 5.49 (over a Likert scale of 7)
to 4.89, being still the highest concern. Also, noise had a significant difference before and after (going
down from 4.34 to 3.79, the lowest of all the evaluated issues!) Most participants (25%) did not hear
drones in the different scenarios. In fact, all concerns were reduced except criminal actions and
accidents, pointing that the exposure to drones creates a better perception of UAM (42.6% more
positive attitude vs 25% more negative).
A research work evidenced the fact that a user-centred mobile application could increase trust in
commercial drone flights used for last-mile delivery and reduce the concerns in terms of safety and
Page I 342
Insert project
logo here
privacy [131]. The delivery service is paired with an application for customers and bystanders that
allow customers to control how the drones can collect their personal information when entering their
private property. An online survey was conducted to 41 users exposed to two different privacy-
protected versions of the application. For instance, the app shows a map of the current no-fly-zones,
which in one version (high privacy) all properties are automatically but, under user’s request can be
removed from the no-fly list. Reversely, the second version (more transparency) proposes an opt-out
request to add a property to the no-fly list. Responses were clearly in favour of the high privacy version.
In respect to the concerns, the most common concerns were the loss of packages due to delivery to
the wrong address, injury to bystanders from dropped packages, and damage to property.
In the contest of the ASSURED–UAM project, a technical online survey involving 34 experts with
heterogeneous expertise and affiliations (industry, research, citizens, infrastructures, operators) was
conducted to explore the expectations about UAM as a potential new element of sustainable urban
mobility [129]. An online survey was prepared collecting opinions about benefits, integration, costs,
propulsion, safety, security, regulatory and social concerns. Major agreements were achieved in the
necessity of: converting existing urban infrastructure to cost-effective UAM infrastructure (partially
agreement 62%), cities to issue specific regulation for the use of land (59%), standard methodologies
developed for security risk assessment (59%) and that U-Space services shall allow safe integration of
pilot UAM services within the cities (partially agreement 59%).
6.1.3 Surveys at a glance

In Figure 67, the surveys are shown according to their main focus, such as public acceptance (blue)
or market analysis (green). The number of surveys for each year from 2015 to 2021 can be seen on the
vertical axis. The different types of drones (surveillance, cargo and passenger) covered by each
questionnaire are also indicated by a picture.
Page I 343
Insert project
logo here
Figure 67 - Summary of the surveys per year, aim and proposed vehicles
A growing interest in passenger drones can be observed starting from 2018 to 2021. Conversely, the
interest in surveillance drones has been decreasing. This may be a reason why privacy concerns have
been decreasing over the years in these surveys, while noise and environmental concerns have
increased.
As an overall metric, the level of acceptances of drones and of urban air mobility are shown in Figure
68. Each bar represents one survey and they are sorted by years to try to show the trend across time.
Again, the colour indicates the focus of the survey, blue for public acceptance and green for market
analysis.
Page I 344
Insert project
logo here
Figure 68 - Acceptance levels of drones and/or UAM per survey (in %)
Although public opinions vary with time/country, numbers show that between half and three-fourths
of the public accepts the deployment of business -related drone operations. As can be seen in the
figure, there is not a clear trend over the years on the public acceptance levels. The maximum in six
years was 83 %, however, the other surveys of the same year had diverse results.
The way questions are proposed in these surveys partly explains these differences. In the EASA survey,
with the highest acceptance value, the question was the general attitude towards urban air mobility.
In the Park and Joo survey [123], also conducted in 2021, but from a market analysis perspective, the
question that obtained 47 % of positive responses were about the publics’ willingness to use UAM in
its initial phase. This diversity on the questions shows how difficult it is to compare survey results.
Surveys, in general, have a first set of questions to classify the public according to their age, gender,
and economic status, but also their knowledge about drones, so the answers can be further studied by
groups. Typically, females, elders and less educated people have a slightly lower acceptance of drones
than the other groups. On the contrary, experts in the field are generally more concerned about safety
than laypersons.
Page I 345
Insert project
logo here
Figure 69 - Evolution of acceptance over years
Most surveys are also usually accompanied by a scenario of drone usage, and in the surveys on
market studies the scenarios include a forecast about the cost of the services. Many unknowns are yet
to be unveiled: Will safety increase or decrease? Will the projected drone service costs/times be
achievable? Will drones generate the expected economic growth? For the moment, only predictions
can be provided when conducting surveys, whereas the survey results show clearly that the costs of
drone services, as well as the time saved, have a high impact on responses. Drone operations related
to health and welfare always have a high level of acceptance, while leisure or business related to leisure
are always the least accepted drone operations.
In most recent surveys, we found that quantitative data are obtained from the questionnaire
responses, while qualitative information is obtained from a set of persons who are interviewed
separately, and whose responses are analysed with more detail. Typically, this set of responses,
referred to as experts, is used to validate and interpret the responses of questionnaires. However,
experts' answers usually point towards a positive attitude to drones, as confirmed during the first
CORUS-XUAM stakeholder workshop.
This workshop analysed the most critical elements related to UAS/UAM operations along with possible
solutions that could enable a sustainable and accepted expansion of drone operations in and around
the European cities. In particular, the 5th day of the workshop was dedicated to the analysis of societal
impact of drone operations and possible mitigation measures. The responses to the questions in Table
93Table 1 showed a high acceptance rate among the 66 workshop participants, same as happened in
the surveys with the experts’ answers.
Page I 346
Insert project
logo here
Options (Multiple Choice)
I am a potential passenger of a taxi-drone 63 %
I am a potential client of a delivery-drone 89 %
Table 93. Please check the option(s) that apply/applies to you.
6.1.4 Public concerns

In addition to acceptance, most surveys include questions about public concerns, but they do not use
an equivalent set of concerns or the same terminology. To highlight this fact, we used word clouds to
process the surveys addressing "public concerns" (see Figure 70). In words clouds, the most frequently
used terms within a document are displayed in larger font size.
In these word clouds, public concerns related to drone operations are mostly focused on safety,
environment, privacy, and noise. Terms such as Animals, Visual, and Waste are classified as an
environmental concern, while others such as Risk and Danger are considered as safety concerns. In
addition, we see terms related to the economy (e.g., Cost and Liability) or to other topics such as
Regulation or Ethics.
Page I 347
Insert project
logo here
Figure 70 - Words clouds highlighting the public concerns on the different surveys
Looking at the evolution over the years the trends are not always clear (see Figure 71). While visual
pollution, noise and, to some extent, privacy seem to be becoming a less important issue when UAM
takes over other surveillance/country tasks, the perceived safety has not a clear trend.
Figure 71 - Evolution of main concerns over the years
Page I 348
Insert project
logo here
In the CORUS-XUAM, the workshop participants were asked to select the top three concerns for them,
and the results are shown in Table 94. As most of them came from the aviation sector, it is not surprising
to see that the safety concern was selected as the major concern.
Options (single choice)
Safety / (Cyber)Security 59%
Environmental impact (noise, emissions, visual,...) 33%
Privacy 9%
Table 94- Please select which of the three main concerns is most important for you.
It is worth mentioning some specific issues that yield ‘Not in my backyard’ responses. The location of
vertiports is a good example. People are open to the concept, but would not be happy to have one
near their home or office.
6.2 Societal concerns mitigations proposed to the VLDs

The full list of societal concerns identified by the CORUS-XUAM project is, organised in four main
areas, the following:
● Environment: Noise impact; Emissions impact, Impacts on animals and flora; Recycling;
Impact of Climate change; Visual pollution; Loss of Privacy / Intrusion; Nuisance;
● Safety: Safety concerns; Security concerns, Cybersecurity;
● Fairness: Lack of Transparency; Cost of services; Competency; Liability;
● Economy: Jobs; Economic Viability; Demand.
Since the environmental area has many items, and the noise and privacy are highly mentioned as
concerns, we treat noise and privacy separately from the environment. The purpose of this section is
analysing each societal concern, while we also hint at possible mitigation measures, especially those
applicable to CORUS-XUAM VLDs.
6.2.1 List of mitigation actions
Page I 349
Insert project
logo here
The procedure to define the mitigations was produced after several brainstorming sessions: The
societal concerns captured in the surveys were analysed. For each concern, we determined possible
actions that could help to minimise its negative perception. The result was a list of mitigation
measures, in which each item is an individual action. Further analysis showed that many mitigation
ideas were useful to more than one concern.
The list mitigations was presented and discussed in the CORUS-XUAM workshop. The majority of the
participants felt that it was a good start (details can be seen in Table 95) but it was still incomplete.
During the debate, new potential actions were proposed and added to the existing ones. The full list is
given in Appendix A.
Options (single choice) Split
The list is a good starting point 85%
The list has important omissions 11%
The list is exhaustive and complete 4%
Table 95: CORUS-XUAM Workshop responses about the list of mitigations
Once the list of mitigation actions was extended with the participants’ contributions, an analysis was
performed using the double classification process: first providing a category to each action and then
an effort level, as required to implement that action.
In more detail, the analysis started by categorising each mitigation measure according to the scope in
which it can be applied. We have established four different scopes or categories as follows:
Category Content
Regulation and policy This category contains the mitigations that should be part of a regulation
made by the authorities
Page I 350
Insert project
logo here
Operational and ConOps This category includes the mitigation measures related to rules and
regulations that enable the safe integration of drones with other
airspace users
Human Response and This category relates to mitigation measures that engage the public
Metrics
Tool and Technologies This category includes mitigation measures that can be built into or used
by drones
Table 96. Categorisation of the mitigations
Figure 72 shows some examples of mitigation for each category. Note that simply rewording slightly a
mitigation can move it from one category to another. For instance, "Setting up countermeasures to
criminal/illegal use of drones" was categorised under "tools and technologies", but rephrasing it to
"Make mandatory the use of countermeasures ..." would have categorised it under "regulation and
policy".
Figure 72 - Examples of mitigations by category
In addition to the category, we assigned each mitigation a second classification in three effort levels
"easy", "medium", and "difficult", according to its ease of implementation in terms of resources and
time. Figure 73 shows a mitigation example for each of the three levels of ease of implementation. For
example, the mitigation "Creating an independent authority to investigate accidents / incidents /
complaints related to drone operations'' is considered to be difficult to implement at the moment
because it requires a high level of agreement between stakeholders. In particular, this mitigation
Page I 351
Insert project
logo here
measure shall involve regulation bodies, which have to follow a lengthy period of legal procedures. In
contrast, the mitigation "Limit minimum altitude" is an operational action that is easy to implement.
Figure 73 - Example of mitigations by ease of implementation
Figure 73 gives the split of the proposed mitigations according to their category (a) and to the easiness
of implementation (b). While the ease/difficulty of the implementation are quasi-evenly divided, the
categories involving regulation are the most proposed actions, but the human response and conops
actions represent also more than half of the actions.
Page I 352
Insert project
logo here
Figure 74- Category and Easy of Implementation classifications of the list of mitigations
It can be observed that more than 60% of the mitigation measures are found to be achievable in a
short or medium time, either because the necessary applied science exists today or because the
required technologies are under development. However, 38% of the mitigation measures are still
considered complex to implement, which means that there is still a long way to go in the research and
development of new technologies and the regulations that make these mitigations possible.
6.2.2 Prioritisation of the mitigation actions

Given the long list of mitigation measures, we proposed a method to rank them from highest to lowest
priority. Mitigations were scored using a dynamic table: For each mitigation was scored with a count
equal to the number of concerns they were applicable to. The concerns used to score the mitigations
were the following 17:
Noise Climate change Safety Loss of Privacy / Cost of services

Intrusion
Emissions Visual pollution Security Lack of Competency

Transparency
Animals & flora Demand Cybersecurity Jobs Liability
Recycling Economic
Viability
Table 97. Concerns about Urban Air Mobility
Page I 353
Insert project
logo here
The effects of an action can have positive impact against one concern but negative to another, thus in
this process a +1 or -1 could be accounted for to each action. For instance, one mitigation that reduces
visual impact may have a negative effect on the safety of the surrounding traffic, but at the same time
may be neutral for natural life and for privacy.
The total score for a mitigation action is calculated by summing all its scores. For example, the
mitigation of "Limit minimum altitude" affects many concerns such as noise, animals & flora, visual
pollution, safety, security and loss of privacy at the same time, all in a positive way, thus its final score
is +6. This is similar to the process used in the safety operational risk assessment (SORA) methodology
[126]. The final sum of the values of a mitigation provides a numerical proxy of the impact of its
applicability. The higher the number, the more positive the impact to mitigate societal concerns.
6.2.3 Prioritisation of the mitigation actions

Using the process explained above and selecting the items with the highest score, we obtained the
top-10 mitigation actions proposed, which are listed in Table 98Table 98.
Top 10 mitigation measures Concerns mitigated with this measure
M1 - Limit minimum altitude Noise impact, Impacts on animals & flora, Visual
pollution, Safety Concerns, Security Concerns,
Loss of Privacy / Intrusion
M2 - Establish no-fly zones for drones Noise impact, Impacts on animals & flora, Visual
pollution, Safety Concerns, Security Concerns,
Loss of Privacy / Intrusion
M3 - Identify a strategic location for vertiports Noise impact,Emissions impact, Impacts on

animals & flora, Visual pollution, Safety
Concerns, Security Concerns
M4 - Public knowledge about drone technology Loss of Privacy / Intrusion, Lack of Transparency,
and operations Competency, Economic Viability, Demand
M5 - Avoid/limit hovering drone flights Noise impact, Impacts on animals & flora,
Visual pollution, Loss of Privacy / Intrusion
Page I 354
Insert project
logo here
M6 - Promote the use of renewable energy Emissions impact, Recycling, Impact of

sources to recharge batteries (Use of SAF20 for Climate change, Economic Viability, Demand
hybrid drones)
M7 - Ensure proper maintenance processes and Emissions impact, Recycling, Impact of

controls (for batteries to extend their life cycle) Climate change, Safety Concerns
M8 - Work with eco-friendly drones (re-cycling Emissions impact, Recycling, Impact of

parts) Climate change, Economic Viability
M9 - Ensure that the cost of drone services Cost of services, Competency, Jobs,
commensurate Economic Viability
M10 - Developing a risk and safety culture in the Competency, Jobs, Economic Viability,
drone industry Demand
Table 98. Top-10 mitigations
Figure 75 shows the score and the effort classification of each of these 10 mitigations measures. More
than half are easy to implement. The two that are considered the most difficult to achieve today are
those related with vehicle construction and maintenance (M7 - Ensure proper maintenance processes
and controls for batteries to extend their life cycle and M8 - Work with eco-friendly drones and re-
cycling parts). As the drone industry is not yet consolidated, other priorities more related to cost and
safety are under consideration now, but in the future, these environmental aspects shall prevail.
20
Sustainable Aviation Fuels
Page I 355
Insert project
logo here
Figure 75 - Top-10 mitigations scores and classification
6.2.4 Selected mitigation actions for the VLDs

As a final step, we have selected a new subset of mitigation measures that could be applicable to very
large (drone flight) demonstrations (VLDs) being prepared within the CORUS-XUAM project. They were
mainly from the Operational/ConOps category, but not exclusively.
VLDs are at the heart of CORUS-XUAM. They demonstratethe integrated operations of UAS/UAM and
manned aircraft with the advanced forms of interaction given by the U-space services. Scenarios in
urban, sub-urban, and inter-city, as well as in and near ATM-controlled airspace and airports are
demonstrated, with focus on different types of missions such as passenger transport, delivery,
emergency response, and surveillance. The VLDs use different U-space deployment architectures and
state-of-the-art technologies. They take into account the coordination between ATC and U-space,
including interaction with ATCOs and pilots. The VLDs will combine eVTOLs flights with other traffic,
and operations in the CTRs of major airports.
The mitigation measures proposed for the VLDs are mainly those that can be implemented by the U-
space service providers or by other partners involved in the VLD. The following tables are providing
Page I 356
Insert project
logo here
the mitigations that we believe are applicable to flight demonstrations of CORUS-XUAM. These
mitigations have been grouped according to the areas they influence: flight plan, dissemination and
communication actions, vehicle selection and others.
Meetings were held separately with each VLD to discuss the applicability of the proposed list of
mitigation measures in advance, during their planning phase.
Table 99. List of mitigation actions on the flight plan design
From this list most VLDs responded that hovering was not foreseen, and in those that planned
hovering, its duration was minimised. The flight routes were carefully selected to limit the ground risk
and avoid no-flight zones, so in this case the SORA/STS measures were inline with the improvement of
societal acceptance. In some VLDs, the no-flight zone was extended to avoid flying over natural areas.
Only the Spanish VLD could apply alternative return routes, although the software did not finally take
this into account.
The speed and altitude were selected using the vehicle performances and the SORA altitude limits.
There were few possibilities to set higher altitudes with current regulation, which is against the societal
preference of having higher altitudes for drones.
Page I 357
Insert project
logo here
Table 100. List of dissemination actions
Few VLDs had the capability to undertake dissemination actions in advance. Most dissemination
actions were done at the Open day, after or during the VLD. The main exception is the Swedish VLD
that had a great implication of the involved municipalities, with several meetings and attendance of
external bodies of the consortium. This was a step forward to UAM acceptance. A summary of the
discussion about the societal acceptance meeting held within the Open Day of the Swedish VLD can be
found at Appendix B.
With the exception of the consortium representative from AOPA, the general aviation pilots were
engaged only when they had to participate in the demonstration. More extensive communication with
this group is clearly needed.
Table 101. List of mitigation actions applicable to drones
Page I 358
Insert project
logo here
Privacy was not an issue in any of the VLDs. Most of the vehicles involved had no camera on board, or
were flying in non-highly-populated areas.
Audio recordings were captured and results will be given in section 3.4.
No significant interaction with birds was observed, other than some seagull observing the drones at
the beach for several seconds.
No one had reported the use of recycled parts on their vehicles.
Table 102. List of other mitigation actions
The vertiports selected for the VLDs using eVTOL and fixed-wing aircraft were necessarily taken from
existing aerodromes: Pontoise in France, Grottaglie in Italy, and Cochstedt in Germany. Also Swedish
VLD was selecting existing aerodromes for its inter-city flight.
When the involved aircraft were small multi-rotor UAS (Spain, Belgium, but also Italy and Paris) there
was more flexibility in selecting the vertiport. But as the flights were not to be repeated constantly in
a business process, the only reasons for the location was safety. The same applies to the designed
arrival and departure procedures.
Encryption was mainly present in the intra-uas communication (vehicle to ground station), but not in
the U-space communications. There was no time to add an additional layer of encryption in many of
the VLDs.
CHECK HOW MANY VLDs HAD ENCRIPTION
Page I 359
Insert project
logo here
All VLDs were able to monitor and recognise any drone with a deviant behaviour thanks to the tracking
service of the U-space.
6.3 Societal Acceptance Questionnaires in CORUS-XUAM

In order to capture the opinion of the people involved and attending to the VLDs a classification of the
roles and the major interest was done. According to CORUS-XUAM ConOps Version 3.10 (see chapter
8 on Architecture) the stakeholders that will interact with U-space are the ones shown in the Figure
76:
Figure 76 U-space ConOps 3.10 stakeholders
For the questionnaires these stakeholders have been aggregated according to their main interests
(keep safety standards, obtain economic benefits or improve the quality of citizens’ life) in the
following profiles:
Page I 360
Insert project
logo here
Comply with safety standards Obtain economic benefits Improve the quality of citizens’
life (political)
Airspace managers Citizens (as UAS delivery clients Citizens (as general public)
/ UAM passenger)
(Air Traffic service providers,
Aviation Safety Agencies,
Aeronautical Information
service providers,
Common Information service

provider,
Airport Operator)
Other Airspace Users (pilots) Drone operators HEMS (Emergency Responders,
(includes also UAM operators) Law enforcement,
Medical Urgent Transport)
Drone Industry (includes Local and regional

manufacturer) administrations (includes
competent authority)
U-space service providers

(includes Supplemental Data
service providers,
Vertiport operators,
Aerodrome operator,
CNS service providers)
Page I 361
Insert project
logo here
For each one of these profile groups a Questionnaire was proposed. Questionnaires were available
online using a unique point of access through the following link. A QR-code was disseminated to
facilitate people to access the questionnaire and respond to the questions.
Taking advantage of the fact that most of the profiles were filled with project partners, two time sets
were defined for them: before the VLD and after the VLD. The aim of this duplication is to check the
effect of the VLD experience in the opinions.
Ten questionnaires were prepared and distributed to the different profiles. Questions are shown in
the following table, organised by KAP and by profile. In the Results subsection the plots show a word
to represent the question. To easily make the link between the question and the plot, the selected
word is highlighted in boldface.
KPA Profile Question (only post-VLD questions are shown)
- all In which VLD have you participated?
Safety Airspace Managers, How do you see the contribution of U-space services in
Agencies, etc. providing safety during the VLD now?
Do you think that the demonstrated U-space services and

technologies will promote new aviation safety standards?
How did U-space manage the interaction of drones -

manned aircraft, if any?
Page I 362
Insert project
logo here
How did you find the situational awareness provided by U-

space about the drones traffic?
What do you think should be the maximum elapsed time

from request of a geo-fence till activation?
If any ATM - U-space interaction was proven in the VLD,

how did the high-level of automation of U-space affect this
interaction?
Safety Other Airspace Users Did U-space services demonstrate their ability to provide
safety to manned aircraft?
Can access to the U-space airspace be considered fair

during the VLD?
How was the good situational awareness provided by U-

Space to other airspace users ?
KPA Profile Question (only post-VLD questions are shown)
Economical Drone operator How useful did you find U-space? Do you think U-space will
help to increment your drone business?
UAM operators
How long in advance (anticipation) did you have to notify

U-space about your drone flights?
Page I 363
Insert project
logo here
How flexible did you find that U-space has been with last
minute changes, if any (do not respond if you did not have
any change)?
What has been your experience with the integration of the

system that connected your drone with the U-space? Was
it costly?
What has been your experience about the need for

personnel (or their training -cost-) caused by U-space?
What has your experience of the U-space services in

providing safety between drones? (do not respond if your
drone flight alone)
What has been your experience of the U-space services in

providing advice (awareness) to drones about the
environment (obstacles, weather)?
What has been your experience of the U-space in terms of

the level of confidentiality of your flight?
U-space Service Which has been your experience about the complexity of
Providers connecting drones to your USSP system?
Supplemental Data
service providers
Vertiport operators
Aerodrome operator
CNS service providers
What has been your experience about the complexity of

connecting your USSP system with other USSPs (do not
answer if there were no more USSPs)?
Page I 364
Insert project
logo here
Which has been your experience about the role of the CISP
(do not answer if there were no CISP)?
(Other) Drone Industry How useful did you find U-space for your business?
U-space solutions/systems were added to your products

for the VLD. Do you think these solutions/systems will
impact your business benefits?
KPA Profile Questions
Economical Citizens Do you think that in the near future you may hire a drone
service, such as the one being demonstrated today
(as UAS delivery clients / (client)?
UAM passenger)
How much are you ready to pay for a fast drone service,
such as the one being demonstrated today (service cost)?
How many companies offering drone services would you

like to have (competition)?
What are your expectations about the cost of flying

commercial aircraft? Will there be any change caused by
drones and U-space? (EffectACCost)
If you have a business: Would you use drones (or U-space)

to grow your local business?
Political Citizens How do you think drones will affect the natural life (birds
and plants) in urban environments?
Page I 365
Insert project
logo here
(as general public)
Being mostly electrical powered, will drones help to

reduce CO2 emissions?
How did you feel about the perceived noise level of the
drones during the VLD?
KPA Profile Questions
Political Emergency Responders How do you see drones in helping HEMS (emergencies)
and other civil services?
Law enforcement
Medical urgencies
How do you see U-space services in managing

(SafeExecution) interactions of HEMS and drones?
Do you think that U-space geofences are useful for the

safe execution of a priority operation?
Do you think that U-space provides a good situational

awareness of other traffic surrounding HEMS ?
Do you think that U-space improves the safety

perception of an emergency operation?
What do you think should be the maximum elapsed time

from your request of a geofence to its activation in U-
space? (Time2Geofence)
Page I 366
Insert project
logo here
Do you think that the high-level of automation of U-space

is convenient for emergency tasks?
Do you think that U-space is treating correctly the level of

confidentiality of your flight?
Local and Regional How does local/regional administration see the

Administrations deployment of drones in the urban environment?
(competent authority)
(UrbanDrones)
To what extent can drones (and U-space) contribute to

improving the provision of local services to citizens?
(useful)
How urban air mobility will affect the local administration

in terms of administrative workload?
How drones will affect the local administration in terms

of law enforcement?
How drones/U-space will affect the local administration

in terms of mobility surveillance?
Table 103. List of questions of the social acceptance study
6.4 Noise study

ICAO proposes five ways to approach the mitigation of noise annoyance:
1. Reduction of noise at source: new construction technologies, new standards/certification.
2. Operational procedures for noise reduction: limited hovering, optimised procedures,

alternating routes.
3. Land use: plan land compatibility, preserve noise sensitive areas.
4. Restrictions: curfews, limits, quotas, nature of flights.
Page I 367
Insert project
logo here
5. Manage community: build tolerance, community engagement, outreach strategy, manage

expectations.
Related to the first item above, the current European regulation (EU) 2019/945 [135], to enter into
force in January 2023, Part 13 of the annex states "This Part lays down the methods of measurement
of airborne noise that shall be used for the determination of the A-weighted sound power levels of UA
classes 1, 2 and 3." According to Part 14 these noise measures shall be detailed in the labelling of any
unmanned aircraft, given in A-weighted sound power levels in dB. Part 15 provides the limits of noise
of drones of classes C1 and C2. Maximum noise limits are set to 85 dB(A) plus some extra noise allowed
for vehicles with higher mass, but with maximum decreasing in forthcoming years to 81 dB(A).
Table 104 (EU) 2019/945 current noise limits
This tendency to reduce the noise is in accordance with the long-term vision (2050) of ACARE (the
Advisory Council for Aviation Research and innovation in Europe) for manned aviation. ACARE
proposed, on April 1st 2022, to limit the noise nuisance to the airport perimeter, reaching at 2035 no
persons exposed to noise levels (Lden) above 65 dBA. This reduction will be achieved by new
operational procedures (continuous descent and noise abatement departures) and by the new
technologies.
Noise pressure, in particular db A, is the main indicator used in several experiments such as [122] and
[134]. In the EASA study [122] a number of people was participating in an experiment in which several
noise sources (helicopter, aircraft, motorbike, bus, drone) at high pressure (LAmax,F = 80 dB) were
played during 30 seconds. People were requested to provide their level of annoyance, and surprisingly
drones were perceived (statistically significant) more annoying (8 over 10) than other vehicles, such as
bus (4), motorbike (5) or helicopter (7.2). Reasons reported in the study were related to the familiarity
or the noise. Anyway, when the decibels were decreased to 70 and 60, then the level of annoyance of
drones reported went down to 6 and 3.5. It is clear that the noise pressure is a very relevant indicator.
Page I 368
Insert project
logo here
A similar experiment is reported in [134] with a number of participants listening to recorded noises
during 30 seconds. The noise pressures exposed were 72-73 (low), 78-79 (medium), 86-87 (loud) and
(91-92 (very loud) and then requested to respond to a questionnaire about their status. Two new
elements were added: a visual imagery of the drone (two different) and the use of a Kansei brain wave
analyser. This is a sensor that reads the electromagnetic waves of a human brain and returns the
emotional state of the person, classified as stress, concentration, preference, calmness and interest.
While the responses were not statistically different between the visualisations, the authors find that
some respondents were reporting calm while the sensors said stress. This always happened once the
subject had been exposed to a loud sound, previously to the actual exposure under evaluation.
Ivoševic et al. [137] conducted noise measurements of two UAVs of different performance (2.8 Kg
quadrotor and 5.6 Kg hexarotor) in flying up and down, hovering, and overflight procedures at one
isolated meadow in a large campus of the University of Zagreb. At 50 m distance or less 31 persons,
with tested good hearing capabilities, from 21 to 61 years old, listen during 20 minutes each drone and
answer a set of questions. Participants declare a generally more negative experience with the
hexarotor, which produced higher noise pressure (in LA,max 75.3 dBA), than the quadrotor (70.2 dBA) in
outdoor noise measurements at 4.5 metres up-down procedures. These values are both reduced to
72.5 dBA and 65.4 dBA respectively when the flight procedure is cruise at 10 m AGL. The outcomes can
be useful for future pilots directly operating the drones during 8 working hours a day. In the case of
the hexacopter, in order to stay below the Recommended Exposure Limit (by regulation), the
maximum time of operation shall be fixed to 5h40’.
A new document by EASA, currently in public consultation [136] proposes the methodology for specific
category operations (low and medium risk, i.e. operations of UAS transporting goods without flying
over assemblies of people). The procedures to measure the noise consider level flight (with tests at 50
m of altitude from the recording equipment) and stationary flight (tests at 25 m above measurement
point). Environmental conditions, drone mass and speed and recording equipment are detailed and
corrections to apply when these can not be met are also given. SUBPART D shall contain the limits of
the noise, but this section is still not published. Currently there is no noise limitation level for UAS
operating in the specific and the certified categories.
But it is well known that noise propagates in waves that get attenuated with distance. While the
interest of the surveillance operation conducted with drones may be to fly as close to the ground as
possible if they want to capture more details, the noise impact is less if the flight altitude is high [132].
This same study provides a list of commercial drones and shows the decrease of noise by altitude:
DJI Model Mavic Spark Phantom 4 Mavic Air Mavic pro Phantom 4
Platinum Pro 2.0 Pro
Decibels 70 74 76.5 76 79 81
Page I 369
Insert project
logo here
Number of engines, propellers diameter, rotation speed, blade shape and materials used are the
causes for the different values. Also the differences on the exposure level depending on the distance
for a Matrice 600 Pro is given in Table 105. As a rule of thumb noise drop-off rate with altitude is -6 dB
for every double of distance [132].
Vertical distance (m) 20 70 350
Horizontal distance (m) 15 50 50
Decibels 74 55 43
Table 105. Decibels of drone by distance
The noise of the drone was previously analysed at different frequencies and different altitudes as seen
in the Figure 77:
Page I 370
Insert project
logo here
Figure 77 - Sound pressure level per frequency of ambient noise and drone noise at different AGL [133]
Observe the importance also of the frequencies of the noise. Ambient noise pressure is almost the
same that the drone noise for frequencies 0.02-0.125 KHz, while the lower and especially higher
frequencies have much difference with the ambient noise. It is also interesting to see how large the
deltas are.
As a general rule, 3dB difference should be audible, 6dB is a significant difference (very perceptible)
and 9dB and beyond almost suppresses the lower values entirely because the higher SPL becomes
dominant. The grey ambient SPLs are followed closely by the blue line (120m AGL) up to about 0.5 kHz
Page I 371
Insert project
logo here
beyond which they start to diverge. The 2kHz octave band (1.6-2.5 kHz values) carries a delta of circa
5-10dB. This would suggest high perceptibility of the UAS noise.
The proximity and even inversion of the SPLs of the UAS noise measurements (Red-Blue-Green lines)
between 0.025 kHz and 0.125 kHz is quite intriguing. Considering the fact that the grey area most likely
represents a quiet neighbourhood, it could be assumed that the drone noise in that frequency range
would be masked to a large extent by the ambient noise levels, regardless of the AGL level of the drone.
To be able to put these numbers in context, Table 106 shows a comprehensive description of the
decibel measures.
Table 106. Decibels (dBA) in context
In general, a rural area is exposed to 45 dB (35 dB at night), a suburban area to 55 dB (45 dB at night)
and a city centre to 65 dB (55 dB at night).
But in addition to the noise acoustic factors, Vascik and Hansman [Vascik2018] mention 4 other types
of noise annoyance sources, named as non-acoutics factors, that produce “virtual noise”. They justify
why a noise with a given acoustic factor can create different annoyance levels. An ease example is the
Page I 372
Insert project
logo here
day/night time of the noise. The four types are situational, community, privacy and secondary factors.
The example day/night, together with day of the week, weather, ambient noise and noise insulation
are situational factors. Within the community factors we have demographic aspects, such as income
or age, attitude factors, such as familiarity, fear or prognosis about the near future evolution, and
personal traits such as individual noise sensitivity or perception of fairness. The privacy factor occurs
when the individual’s discomfort, given by the aircraft proximity, accentuates the noise annoyance.
Examples of privacy factors are the number of times an aircraft flies close to the person, the duration
of the noise perception and the altitude of the aircraft. Finally the secondary factors refer to non-
auditory sensory events produced by noise. An example is the vibrations that the low-frequencies of
the noise of an aircraft can produce in the windows on a house. Dust, shadows or pollution are other
known secondary factors that affect civil aviation, although these factors are not probably relevant for
future UAM vehicles if they are electric powered.
The effects in quiet areas, such as natural parks and wildlife, are studied by [133]. Authors perform
several experiments exposing megafauna from a zoo to drone noise without direct vision between
both. Eighteen different species were analysed with a drone flying at 120 m AGL and descending, while
a hidden observer taking notes of the first animal behaviour change. The study compared not only the
decibels, but also the frequencies involved and the animals audiogram (the range of frequencies that
species can listen to), when known. The paper also refers to the visual acuity of these animals, being
in general 70%-80% below the humans. The study showed that no animal was reacting with 120 m ALG
and the range of reactions started from 100 m (Asian elephant and giraffe) to 40 m (felines). It
concludes that surveillance operations using drones should fly at heights from 100 m to 180 m to avoid
possible disturbances to natural life. In general disturbances were created by high frequencies
according to the audiogram of the animals.
In the urban areas a key element is the identification of the strategic locations for vertiports. Same
applies to the design of the airspace. As far as we know there is little work addressing these issues
from the societal acceptance perspective. For example, the Metropolis and Metropolis2 SESAR
projects have been proposing different airspace structures but the main indicators used where in
reference to air safety and flight efficiency.
Page I 373
Insert project
logo here
7 References, Glossary, Acronyms

7.1 Reference Documents
[4] CORUS Consortium, “U-space Concept of Operations,” H2020 – SESAR -2016-1, SESAR UTM
Concept Definition v03.00.02, 2019.
[5] EASA. Study on the societal acceptance of Urban Air Mobility in Europe. 2021
[6] Doole, M., Ellerbroek, J., Hoekstra, J.: Drone Delivery: Urban airspace traffic density
estimation. Eight SESAR Innovation Days Conference (2018).
[7] Horvath & Partners: Business between sky and earth - Assessing the Market Potential of
Mobility in the 3rd Dimension - https://www.horvath-partners.com/de/media-
center/studien/urban-air-mobilitystudy-report-2019/ (2019).
[8] Nentwich, M., Horváth, D.: Delivery UAS from a technology assessment perspective (2018)
[9] Rao, B., Gopi, A.G., Maione, R.: The societal impact of commercial drones. Technol. Soc.
(2016)
[10]Regulation (EU) 2018/1139 - https://www.easa.europa.eu/document-

library/regulations/regulation-eu-20181139
[11] Regulation (EU) 2017/373 - https://eur-lex.europa.eu/legal-

content/EN/TXT/PDF/?uri=CELEX:32017R0373&from=fr
[12]COMMISSION REGULATION (EU) 2015/340 - https://www.easa.europa.eu/document-

library/regulations/commission-regulation-eu-2015340
[13] SERA - https://www.easa.europa.eu/document-library/easy-access-rules/easy-access-rules-

standardised-european-rules-air-sera
[14]Regulation (EC) 2020/2034 - https://eur-lex.europa.eu/legal-

content/EN/TXT/PDF/?uri=CELEX:32020R2034&from=EN
[15] ICAO Annex 6 part 1 - https://www.icao.int/Security/COVID-

19/ReferenceMaterial/Annex%206.%20Part%201.%20Chapter%206.pdf
[16]REGULATION (EC) No 2004/549 - https://eur-lex.europa.eu/legal-

content/EN/TXT/PDF/?uri=CELEX:32004R0549&from=EN
Page I 374
Insert project
logo here
[17] Regulation (EU) 2019/947 - https://www.easa.europa.eu/document-

library/regulations/commission-implementing-regulation-eu-2019947
[18]AMC & GM Implementing Regulation (EU) 2019/947 -

https://www.easa.europa.eu/acceptable-means-compliance-and-guidance-material-
group/amc-gm-implementing-regulation-eu-2019947
[19] https://www.easa.europa.eu/domains/civil-drones/drones-regulatory-framework-
background/certified-category-civil-drones
[20] ICAO doc 10019 Edition 2015 - https://standart.aero/en/icao/book/doc-10019-manual-on-

remotely-piloted-aircraft-systems-rpas-en-cons
[21] Regulation (EU) 965/2012 - http://eur-

lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ%3AL%3A2012%3A296%3A0001%3A0148%
3AEN%3APDF
[22]https://www.eurocontrol.int/archive_download/all/node/10539 Page 19--> No fly Zone =

No Drone Zone?
[23] Regulation (EU) 2021/664 - https://eur-lex.europa.eu/legal-

[24]Airbus Blueprint for our sky, https://www.airbus.com/en/newsroom/stories/2018-09-

premiering-a-future-blueprint-for-our-sky
[25] MITRE, Urban Air Mobility Airspace Integration Concepts, 2019 -

https://www.mitre.org/sites/default/files/publications/pr-19-00667-9-urban-air-mobility-
airspace-integration.pdf
[26]FAA, NASA UAM Conops v.1, 2020 -

https://nari.arc.nasa.gov/sites/default/files/attachments/UAM_ConOps_v1.0.pdf
[27] EmbraerX ConOps - https://embraerx.embraer.com/global/en/uatm
[28]Commission delegated regulation EASA2019/945 - https://eur-lex.europa.eu/legal-

[29] EU2021/665 - https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32021R0665
[30]EU2021/666 - https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32021R0666
[31] Proposed acceptable means of compliance and guidance material for EU regulations
2021/664, 2021/665 and 2021/666 as Notice of Proposed Ammendment 2021-14
Page I 375
Insert project
logo here
https://www.easa.europa.eu/document-library/notices-of-proposed-amendment/npa-
2021-14
[32](EU) No 923/2012 http://eur-

lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ%3AL%3A2012%3A281%3A0001%3A0066%3
AEN%3APDF
[33] https://ajuntament.barcelona.cat/ecologiaurbana/ca/serveis/la-ciutat-
funciona/urbanisme-i-gestio-del-territori/informacio-urbanistica/normativa-del-pla-
general-metropolita
[34]https://www.roses.cat/la-vila/urbanisme/planejament/planejament-vigent/copy2_of_pla-
general-dordenacio-urbana-1985
[35] ICAO 9854 -

https://www.icao.int/Meetings/anconf12/Document%20Archive/9854_cons_en[1].pdf
[36]European ATM Master Plan - https://www.atmmasterplan.eu/downloads/285
[37] SESAR JU guidance for U-space demonstrations - Guidance for U-space conclusions &
recommendations, SESAR JU, Edition 01.00, edition date 04/07/2019
[38]Australian Urban ATM ConOps - Urban Air Traffic Management Concept of Operations,
Embraer X and Airservices Australia, Version 1, 2020
[39] Towards a UTM System for the UK, Connected Places Catapult | Open Access UTM
programme, October 2019. https://cp.catapult.org.uk/2019/09/30/new-report-points-way-
toshared-airspace-between-drones-and-traditional-aircraft/
[40]https://www.insee.fr/en/metadonnees/definition/c2070
[41] Dijkstra, Lewis, and Hugo Poelman. "Cities in Europe: the new OECD-EC definition." Regional
focus 1.2012 (2012): 1-13
[42]Dijkstra, Lewis, Hugo Poelman, and Paolo Veneri. "The EU-OECD definition of a functional
urban area." (2019).
[43] L Dijkstra, H Poelman. A harmonised definition of cities and rural areas: the new degree of
urbanisation. WP 1, 2014
[44]Dijkstra, L., Florczyk, A. J., Freire, S., Kemper, T., Melchiorri, M., Pesaresi, M., & Schiavina, M.
(2020). Applying the degree of urbanisation to the globe: A new harmonised definition
reveals a different picture of global urbanisation. Journal of Urban Economics, 103312.
Page I 376
Insert project
logo here
[45] [40] [UN20] UN Statistical Commission. "A recommendation on the method to delineate
cities, urban and rural areas for international statistical comparisons." European Commission
(2020).
[46]L. Bellesia, B. Clark, E. Malfliet, Y. Seprey, C. Ronfle-Nadaud, A. Wennerberg, C. Barrado, W.

Van Leare, L. Brucculeri, and A. Hately, “CORUS 1st workshop early findings,” 2018.
[47] EASA/EUROCONTROL, “UAS ATM CARS (Common Altitude Reference System),” 2018,
Discussion document.
[48]Sedov, L., Polishchuk, V., & Acuna, V. Altitude Zoning for UTM. SID20
[49] P. Vascik, J. Cho, V. Bulusu, V. Polishchuk A Geometric Approach Towards Airspace

Assessment for Emerging Operations Special issue of JAT on ATM Seminar'19
[50]Deutscher Wetterdienst, ‘Urban heat islands’.

https://www.dwd.de/EN/climate_environment/climateresearch/climate_impact/urbanism/u
rban_heat_island/urbanheatisland.html
[51] https://vtol.org/files/dmfile/20200422---matthias-steiner---ncar---weather-challenges---no-
animations2.pdf
[52]e-volo GmbH, ‘Design specification Volocopter 2X’. e-volo GmbH, Apr. 2017. Accessed: May
11, 2020. [Online]. Available:
https://www.volocopter.com/assets/pdf/2017_04_Design_specifications_2X.pdf
[53] ‘H160’, Airbus. https://www.airbus.com/helicopters/civil-helicopters/medium/h160.html

(accessed Sep. 09, 2021).
[54]C. Reiche, F. Brody, C. McGillen, and et al., ‘An Assessment of the Potential Weather Barriers
of Urban Air Mobility (UAM)’, Nov. 2018, doi: 10.7922/G2057D4F.
[55] European Aviation Safety Agency, ‘Draft acceptable means of compliance (AMC) and
Guidance Material (GM) to Opinion No 01/2020 on a high-level regulatory framework for the
U-space’. Accessed: Jan. 15, 2021. [Online]. Available:
https://www.easa.europa.eu/sites/default/files/dfu/Draft%20AMC%20%26%20GM%20to%
20the%20U-space%20Regulation%20%E2%80%94%20for%20info%20only.pdf
[56]D. Berchoff, ‘Weather-Resilient AAM Operations in Urban Environments’, presented at the

Virtual Workshop on eVTOL Infrastructure, Apr. 22, 2020. Accessed: Sep. 09, 2021. [Online].
Available: https://vtol.org/files/dmfile/20200422---don-berchoff---truweather---weather-
solutions.pdf
Page I 377
Insert project
logo here
[57] European Aviation Safety Agency and McKinsey & Company, ‘Study on the societal
acceptance of Urban Air Mobility in Europe’. European Aviation Safety Agency, May 19, 2021.
Accessed: Sep. 06, 2021. [Online]. Available:
https://www.easa.europa.eu/sites/default/files/dfu/uam-full-report.pdf
[58]The European Commission, ‘Logistics and multimodal transport’, Mobility and Transport -
European Commission. https://ec.europa.eu/transport/themes/logistics_multimodal_en
[59] P. D. Vascik, J. Cho, V. Bulusu, and V. Polishchuk, ‘Geometric Approach Towards Airspace
Assessment for Emerging Operations’, Journal of Air Transportation, vol. 28, no. 3, pp. 124–
133, May 2020, doi: 10.2514/1.D0183.
[60]L. W. Kohlman and M. D. Patterson, ‘System-Level Urban Air Mobility Transportation

Modeling and Determination of Energy-Related Constraints’, presented at the 2018 Aviation
Technology, Integration, and Operations Conference, Atlanta, Georgia, Jun. 2018. doi:
10.2514/6.2018-3677.
[61] Israeli CAA, ‘UTM - VLD in Israel’, presented at the U-space Lessons Learned Webinar #1.
Accessed: Sep. 14, 2021. [Online]. Available:
https://www.eurocontrol.int/sites/default/files/2021-06/eurocontrol-uspace-lessons-
learned-webinar-1-israeli-caa.pdf
[62]S. Fidell, V. Mestre, P. Schomer, B. Berry, T. Gjestland, M. Vallet, and T. Reid, “A first-
principles model for estimating the prevalence of annoyance with aircraft noise exposure,” J.
Acoust. Soc. Am., vol. 130, no. 2, pp. 791–806, 2011.
[63] Schultz, T. J. (1978). “Synthesis of social surveys on noise annoyance,” J. Acoust. Soc. Am.
[64]A. W. Christian and R. Cabell, ‘Initial Investigation into the Psychoacoustic Properties of Small
Unmanned Aerial System Noise’, presented at the 23rd AIAA/CEAS Aeroacoustics
Conference, Denver, Colorado, Jun. 2017. doi: 10.2514/6.2017-4051
[65] DroneRules Consortium, ‘DroneRules’. https://www.dronerules.eu/de/ (accessed Sep. 14,

2021).
[66]Office of the Information Commissioner Queensland, ‘Decision and Reasons for Decision’.
Jun. 17, 2011. Accessed: Sep. 14, 2021. [Online]. Available:
https://www.oic.qld.gov.au/__data/assets/pdf_file/0004/7195/310275-Dec-17-06-11.pdf
[67] K. Schweiger, ‘UAM Vertidrome Airside Operation: What needs to be considered?’,

presented at the Delft International Conference on Urban Air-Mobility (DICUAM), Virtual
Conference, Mar. 15, 2021.
Page I 378
Insert project
logo here
[68]DHL launches its first regular fully-automated and intelligent urban drone delivery service’,
Deutsche Post DHL Group. https://www.dpdhl.com/en/media-relations/press-
releases/2019/dhl-launches-its-first-regular-fully-automated-and-intelligent-urban-drone-
delivery-service.html (accessed Sep. 06, 2021).
[69] P. Ridden, ‘Matternet Station to serve as drone delivery hub for hospitals’, New Atlas, Mar.
11, 2020. https://newatlas.com/drones/matternet-station-drone-delivery-hub-medical/
[70]‘The Future of Airborne Delivery is Now’. https://www.valqari.com/ (accessed Sep. 06, 2021).
[71] C. Stonor, ‘Scotland: Future Edinburgh flats to have roof terrace for drone deliveries by end
of year’, Urban Air Mobility News, Apr. 19, 2021.
http://www.urbanairmobilitynews.com/express-delivery/scotland-future-edinburgh-flats-
to-have-roof-terrace-for-drone-deliveries-by-end-of-year/ (accessed Sep. 06, 2021).
[72]R. Curry, ‘Rooftop Skylight Hatches for Drone Deliveries’, UAS VISION, Sep. 22, 2020.
https://www.uasvision.com/2020/09/22/rooftop-skylight-hatches-for-drone-deliveries/
[73] L. Cooke, ‘Futuristic Urban Droneport could act as a hub for drone deliveries’, INHABITAT,
Dec. 05, 2016. https://inhabitat.com/futuristic-sustainable-urban-droneport-could-act-as-a-
hub-for-drone-deliveries/ (accessed Sep. 06, 2021).
[74]GmbH https://mediahub-volocopter.pixxio.media/start/detail/1701#downloadarea
[75] Oliver https://mediahub-volocopter.pixxio.media/collection/44/detail/765
[76]European Union Aviation Safety Agency, ‘Special Condition Vertical Take-Off and Landing
[77] Volocopter’s internal presentation prepared based on discussions in EASA RMT.0230

Working group on Vertiports design.
[78]J. C. Curlander, A. Gilboa-Amir, L. M. Kisser, R. A. Koch, and R. D. Welsh, ‘Multi-level

Fulfilment Center for Unmanned Aerial Vehicles’, US 020170175413A1 Accessed: Sep. 06,
2021. [Online]. Available:
https://pdfaiw.uspto.gov/.aiw?PageNum=0&docid=20170175413&IDKey=6B4D0DADFC1F&H
omeUrl=http%3A%2F%2Fappft.uspto.gov%2Fnetacgi%2Fnph-
Parser%3FSect1%3DPTO1%2526Sect2%3DHITOFF%2526d%3DPG01%2526p%3D1%2526u%3
D%2Fnetahtml%2FPTO%2Fsrchnum.html%2526r%3D1%2526f%3DG%2526l%3D50%2526s1%
3D20170175413.PGNR.%2526OS%3D%2526RS%3D
Page I 379
Insert project
logo here
[79] Barcelona Skyline, Barcelona Skyline, city, spain png | PNGEgg’, PNGEgg.
https://www.pngegg.com/en/png-cdqef (accessed Sep. 14, 2021).
[80]ICAO Annex 2 - Rules Of The Air

https://www.icao.int/Meetings/anconf12/Document%20Archive/an02_cons%5B1%5D.pdf
[81]ICAO Annex 11 - Air Traffic Services https://store.icao.int/en/annex-11-air-traffic-services
[82]SESAR European Drones Outlook Study -

https://www.sesarju.eu/sites/default/files/documents/reports/European_Drones_Outlook_
Study_2016.pdf
[83] Commission welcomes European cities joining the Urban Air Mobility initiative | Mobility and
Transport (europa.eu)
[84]SESAR Joint Undertaking | Europe-wide urban air mobility demonstrations get off the ground
in bid for greener future (sesarju.eu)
[85] Urban mobility | Mobility and Transport (europa.eu) (Urban mobility, not specific UAM)
[86]European Urban Mobility, Policy Context, European Commission, 2017 (europa.eu) 
[87] ICAO Annex 14, Aerodromes. https://store.icao.int/en/annex-14-aerodromes
[88]ASTM F3548-21 – not yet published.
[89] Inter-USS: https://github.com/interuss
[90]European Aviation Safety Agency, “Second Publication of Proposed Means of Compliance

with the Special Condition VTOL.” Jun. 23, 2021. Accessed: Dec. 08, 2021. [Online]. Available:
https://www.easa.europa.eu/downloads/128938/en
[91] CORUS-XUAM D5.1 DEMO Plan Ed- 00.01.02, 2022
[92]Applying the Degree of Urbanisation — A methodological manual to define cities, towns and
rural areas for international comparisons —, Eurostat, 2021 edition
[93]SESAR2020 CORUS CONOPS, Concept of Operations for U-space – 01.01.03 [September 2019]
[94]SESAR ER DACUS, Separation Management Process Definition D5.2. – 00.03.00 [July 2021]
[95]SESAR ER BUBBLES, Algorithm for analysing the collision risk D4.1 – 01.01.00 [February 2021]
content/themes/bubbles/Deliverables/BUBBLES_D4.1_Algorithms%20for%20analysing%20th
e%20collision%20risk_Ed_01.01.00.pdf
Page I 380
Insert project
logo here
[96]ATM SEMINAR 2021 Evaluation of UTM strategic deconfliction through end-to-end simulation,
Maxim Egorov, Antony Evans, Scot Campbell, Tyler Young.
[97]DASC 2017, Sampling-Based Capacity Estimation for Unmanned Traffic Management, Leonid
Sedov, Valentin Polishchuk and Vishwanath Bulusu.
[98]CORUS-XUAM D3.1. Definition of the Operational Framework Ed. 00.00.02 [December 2021]
[99]ICAO Doc 4444 PANS-ATM – Air Traffic Flow Management (ATFM) phases.
[100] L. Sedov, V. Polishchuk, V. Bulusu. Ground risk vs. Efficiency in Urban Drone
Operations. ATM Seminar'21 Slides GUI
[101] SESAR2020 CORUS U-space Concept of Operations D6.3 – 03.00.02 [October 2019]
[102] Volocopter’s internal presentation prepared based on discussions in EASA RMT.0230

Working group on Vertiports design
[103] REEuropean Union Aviation Safety Agency, ‘Special Condition Vertical Take-Off and Landing
[104] InterUSS – GitHub Repository https://github.com/interuss]
[105] Air taxi service for Urban Mobility:

https://www.researchgate.net/publication/349727737_Air_taxi_service_for_urban_mobility_A_critical_rev
iew_of_recent_developments_future_challenges_and_opportunities
[106] EmbraerX and Airservices Australia Concept of Operations for Urban Air Mobility, Version 1,
2020
[107] EASA – What is UAM https://www.easa.europa.eu/what-is-uam
[108] EASA Guidance Material for Design of VFR Vertiports -

https://www.easa.europa.eu/document-library/general-publications/prototype-technical-
design-specifications-vertiports
[113] Clothier, Reece A and Greer, Dominique A and Greer, Duncan G and Mehta, Amisha M. 2015.
Risk perception and the public acceptance of drones. Risk analysis, 35(6), p 1167-1183, Wiley
Online Library.
[114] Soffronoff, J and Piscioneri, P and Weaver, A. 2016. Public Perception of drone delivery in the
United States, RARC-WP-17-001.
Page I 381
Insert project
logo here
[115] Lidynia, Chantal and Philipsen, Ralf and Ziefle, Martina. 2017. Droning about drones —
Acceptance of and perceived barriers to drones in civil usage contexts, Advances in human
factors in robots and unmanned systems, p.317-329, Springer.
[116] NATS, 2018. New and Emerging Technologies: drones and digital towers, available at
https://www.nats.aero/static/aviation-index - Section New Technologies,
[117] Hamilton, Booze Allen, 2018. Final Report Urban Air Mobility (UAM) Market Study, National
Aeronautics and Space Administration (NASA).
[118] Yedavalli, Pavan and Mooberry, Jessie. 2019. An assessment of public perception of Urban
Air Mobility (UAM). Airbus UTM: Defining Future Skies
[119] Legere, Miles M. 2019. Meta-Analysis of Public Acceptance of Unmanned Aircraft Systems in
the United States, Embry-Riddle Aeronautical University.
[120] Eissfeldt, Hinnerk and Vogelpohl, Verena and Stolz, Maria and Papenfuss, Anne and Biella,
Marcus and Belz, Janina and Kügler, Dirk. 2020. The acceptance of civil drones in Germany,
CEAS Aeronautical Journal, 11(3), p.665-676, Springer.
[121] Tan, Lynn Kai Lin and Lim, Beng Chong and Park, Guihyun and Low, Kin Huat and Yeo, Victor
Chuan Seng, 2021. Public acceptance of drone applications in a highly urbanized environment,
Technology in Society, 64, p.101462,
[122] EASA, 2021. Study on the societal acceptance of Urban Air Mobility in Europe, available at
https://www.easa.europa.eu/downloads/127760/en.
[123] Park, Sun Wook and Joo, YM. 2021. Social acceptability of urban air mobility by aircraft
category and autonomous phases, KDI School.
[124] Benedikt Kloss and Robin Riedel, 2021. Up in the air: How do consumers view advanced air
mobility, available at https://www.mckinsey.com/industries/aerospace-and-defense/our-
insights/up-in-the-air-how-do-consumers-view-advanced-air-mobility.
[125] Lundqvist, Rasmus, 2021. Aerial Uptake Intereg Europe - Regional Analysis. Comparative
Summary of Regional Questionnaire Responses, RISE Research Institutes of Sweden, EU
Interreg Europe, p.1-109.
[126] AESA, 2017. JARUS guidelines on Specific Operations Risk Assessment (SORA). Final public
release v.1.0, Joint Authorities for Rulemaking of Unmanned Systems.
[127] Drone Delivery in the United States, American consumer attitudes on home drone delivery
of goods and food. July 2022.
Page I 382
Insert project
logo here
[128] Philip Butterworth-Hayes and Tim McCarthy. Accelerating the potential of drones for local
government - International Best and Emerging Practice Report. Dublin City Council and Smarts
Dublin. May 2022. Available at https://bit.ly/3QbSiB5.
[129] Gabriella Ducaa ,Barbara Trinconea, Bartosz Dziugielb, Adam Liberackib, Raffaella Russoa,
Vittorio Sangermanoa, Adriana Witkowska-Koniecznyc. Urban Air Mobility in the next future:
main findings from a technical survey. Elsevier Transport Research Procedia.2022.
[130] Maria Stolz and Tim Laudien. Assessing Social Acceptance of Urban Air Mobility using Virtual
Reality. IEEE/AIAA 41st Digital Avionics Systems Conference. 2022.
[131] Famula, J., Pittman D.E., Haring K.S. Building Trust with a Mobile Application for Last-Mile
Commercial Drone Delivery. 2022 Int Conf on Unmanned Aircraft Systems (ICUAS). Croatia
June 2022.
[132] Drone Noise Levels by Airborne drones, Jan 13, 2020 at

https://www.airbornedrones.co/drone-noise-levels
[133] Mesquita, G.P., Mulero-Pázmány, M., Wich, S.A. and Rodríguez-Teijeiro, J.D., 2022.
Terrestrial Megafauna Response to Drone Noise Levels in Ex Situ Areas. Drones, 6(11), p.333.
[134] Hara, S., Mitsukura, Y. and Kamide, H., 2022. Noise-Induced Stress Assessment─ On the
Difference between Questionnaire-Based and EEG Measurement-Based Evaluations─.
Technical Journal of Advanced Mobility, 3(6), pp.81-90.
[135] (EU) 2019/945. On unmanned aircraft systems and on third-country operators of unmanned
aircraft systems. COMMISSION DELEGATED REGULATION, 12 March 2019.
[136] EASA. Public consultation on Guidelines on noise measurement of unmanned aircraft

systems lighter than 600kg operating in the specific category (low and medium risk). 13
October 2022
[137] J. Ivoševic, E. Ganic, A. Petošic and T. Radišic. Comparative UAV Noise-Impact Assessments
through Survey and Noise Measurements. Int J. Environmental Research and Public Health, 18
(6202). MPDI 2021. Available at https://doi.org/10.3390/

Term Definition Source of the definition
UAM Operator
Page I 383
Insert project
logo here

Aerial work ''aerial work’ means an aircraft To be approved by CORUS X
operation in which an aircraft is used
for specialised services such as
agriculture, construction,
photography, surveying, observation
and patrol, search and rescue, aerial
advertisement, etc…
Aerodrome ‘aerodrome’ means a defined area, on Regulation (EU) 2018/1139 (Basic

land or on water, on a fixed, fixed Regulation) [10]
offshore or floating structure,
including any buildings, installations
and equipment thereon, intended to
be used either wholly or in part for the
arrival, departure and surface
movement of aircraft;
Aerodrome traffic circuit ‘Aerodrome traffic circuit’ means the SERA [13]
specified path to be flown by aircraft
operating in the vicinity of an
aerodrome;
Aeronautical information ’Aeronautical information’ means Regulation (EU) 2017/373 [11]
information resulting from the
assembly, analysis and formatting of
aeronautical data;
Air Traffic Control ‘Air traffic control (ATC) service’ COMMISSION REGULATION (EU)
means a service provided for the 2015/340 (air traffic controllers’
purpose of: (a) preventing collisions: licences) [12]
— between aircraft, and
— in the manoeuvring area between
aircraft and obstructions; and (b)
expediting and maintaining an orderly
flow of air traffic;
Airborne collision (Risk area) a collision between aircraft Regulation (EC) 2020/2034 [14]
while both aircraft are airborne; or
between aircraft and other airborne
objects (excluding birds and wildlife);
Page I 384
Insert project
logo here

Aircraft upset (Risk area) an undesired aircraft state Regulation (EC) 2020/2034 [14]
characterised by unintentional
divergences from parameters normally
experienced during operations, which
might ultimately lead to an
uncontrolled impact with terrain;
Taxiing “The aircraft is moving on or above EUROCAE ED-293
the vertiport surface under its own
power prior to take-off or after
landing. Taxiing is a phase of the
flight”
Ground taxiing “Movement of a wheeled VTOL EUROCAE ED-293
aircraft for taxiing on a surface of a
vertiport”
Ground movement “The movement of the aircraft on the EUROCAE ED-293
vertiport surface not under its own
power prior take-off or after landing
by hand or with the assistance of
ground movement equipment. Ground
movement is not part of the flight”
Alternate Aerodrome "An aerodrome to which an aircraft ICAO Annex 6 Part 1 [15]
may proceed when it becomes either
impossible or inadvisable to proceed
to or to land at the aerodrome of
intended landing where the necessary
services and facilities are available,
where aircraft performance
requirements can be met, and which is
operational at the expected time of
use"
Alternate vertiports Alternate Vertiport - in addition to I thought it was already part of the SC
'main vertiports', identified along the VTOL AMC/GM but I cannot find the
route by VTOL Operator (prior to doc on the internet anymore…
flight) for cases of diversion landings.
Two types of alternate vertiports: en
route and destination vertiport.
Emergency landing is not pre-planned,
could be anywhere.
Page I 385
Insert project
logo here

Alternate vs. emergency Alternate Vertiport - in addition to To be approved by CORUS X
'main vertiports', identified along the
route by VTOL Operator (prior to
flight) for cases of diversion landings.
Two types of alternate vertiports: en
route and destination vertiport.
Emergency landing is not pre-planned,
could be anywhere.
ATM services ‘Air traffic management’ means the REGULATION (EC) No 549/2004 [16]
aggregation of the airborne and
ground-based functions (air traffic
services, airspace management and air
traffic flow management) required to
ensure the safe and efficient
movement of aircraft during all phases
of operations;
ATM system ‘ATM/ANS system’ means the Regulation (EU) 2018/1139 (Basic
aggregation of airborne and ground- Regulation) [10]
based constituents, as well as space-
based equipment, that provides
support for air navigation services for
all phases of flight;
Page I 386
Insert project
logo here

ATM/ANS ‘ATM/ANS’ means air traffic Regulation (EU) 2018/1139 (Basic
management and air navigation Regulation) [10]
services and covers all of the
following: the air traffic management
functions and services as defined in
point (10) of Article 2 of Regulation
(EC) No 549/2004; the air navigation
services as defined in point (4) of
Article 2 of that Regulation, including
the network management functions
and services referred to in Article 6 of
Regulation (EC) No 551/2004, as well
as services which augment signals
emitted by satellites of core
constellations of GNSS for the purpose
of air navigation; flight procedures
design; and services consisting in the
origination and processing of data and
the formatting and delivering of data
to general air traffic for the purpose of
air navigation;
Autonomous operation ‘Autonomous operation’ means an Regulation (EU) 2019/947 [17] and its
operation during which an unmanned AMC&GM [18]
aircraft operates without the remote
pilot being able to intervene;
(source: Regulation (EU) 2019/947)
An autonomous operation should not

be confused with an automatic
operation, which refers to an
operation following pre-programmed
instructions that the UAS executes
while the remote pilot is able to
intervene at any time (source: GM1 to
Article 2(17) of Regulation (EU)
2019/947).
Page I 387
Insert project
logo here

BRLOS Beyond Radio Line Of Sight - refers to Doc 10019 Edition 2015 [20]
any configuration in which the
transmitters and receivers are not in
RLOS. BRLOS thus includes all satellite
systems and possibly any system
where an RPS communicates with one
or more ground stations via a
terrestrial network which cannot
complete transmissions in a timeframe
comparable to that of an RLOS system.
BVLOS Beyond Visual Line Of Sight - is an Doc 10019 [20]
operation in which the RPA is flown
beyond a range where a remote
pilot or RPA observer can maintain
direct unaided visual contact with the
remotely piloted aircraft and the
remote pilot in
command is using on-board sensors
and data to capture, transmit, and use
flight parameters throughout the flight
mission to ensure safety of flight.
C2 Command and Control Link: The data Doc 10019 [20]
link between the remotely piloted
aircraft and the remote pilot station
for the purposes of managing
the flight.
Collision on runway (Risk area) a collision between an Regulation (EC) 2020/2034 [14]
aircraft and another object (other
aircraft, vehicles, etc.) or person that
occurs on a runway of an aerodrome
or other predesignated landing area. It
does not include collisions with birds
or wildlife;
Concept of operation A Concept of Operations (ConOps) is a MITRE (Systems Engineering Guide)
user-oriented document that
"describes systems characteristics for
a proposed system from a user's
perspective.
Page I 388
Insert project
logo here

Congested area ‘‘congested area’ means in relation to Regulation (EU) 965/2012 [21]
a city, town or settlement, any area
which is substantially used for
residential, commercial or recreational
purposes’
Aerial operations in congested areas
for civil purposes, below certain
heights, are today not permitted (refer
to SERA.3105 and SERA.005(f)).
Contingency procedure The contingency procedure describes To be approved by CORUS X
action(s) that the (remote pilot) will
engage and the future behaviour of
the aircraft in case of one or several
system(s) failure(s) which do(es) not
put safety at risk at the moment it
occurs.
Controlled airspace ‘Controlled airspace’ means an SERA [13]
airspace of defined dimensions within
which air traffic control service is
provided in accordance with the
airspace classification;
Cooperative UAS U-space and UTM-systems Definition within the U-space
fundamentally deal with cooperative Document "U-space Concept of
UAS, which are UAS that, at Operations" from 25.10.2019 (Page
appropriate times, submit an 52)
operational plan, emit remote
identification signals, submit reports
of
their position to U-Space, and so on.
DAA Detect and avoid: The capability to Doc 10019 [20] - JARUS AMC RPAS
see, sense or detect conflicting traffic
or other hazards and take the
appropriate action.
Door2door Door-to-door is a shipping service To be approved by CORUS X
where the parcel is collected at the
designated address and delivered
directly to the destination selected.
For UAM, this could be extended to
passenger transportation
Page I 389
Insert project
logo here

Emergency procedure Emergency procedure is the procedure To be approved by CORUS X
put in place when safety is at risk. The
procedure describes immediate
action(s) that the (remote) pilot will
engage and future behaviour of the
aircraft. The emergency procedure
could follow a contingency procedure
if the latter was not sufficient.
eVTOL Electric Vertical Take Off and Landing -
said for an aircraft, powered
electrically, which is not a helicopter,
able to take-off and land vertically.
excursion (Risk area) an occurrence when an Regulation (EC) 2020/2034 [14]
aircraft leaves the runway or
movement area of an aerodrome or
landing surface of any other
predesignated landing area, without
getting airborne. It includes high-
impact vertical landings for rotorcraft
or vertical take-off and landing aircraft
and balloons or airships;
fire, smoke and pressure (Risk area) an occurrence involving Regulation (EC) 2020/2034 [14]
cases of fire, smoke, fumes or
pressurisation situations that may
become incompatible with human life.
This includes occurrences involving
fire, smoke or fumes affecting any part
of an aircraft, in flight or on the
ground, which is not the result of
impact or malicious acts.
ground damage (Risk area) damage to aircraft induced Regulation (EC) 2020/2034 [14]
by operation of aircraft on ground on
any other ground area than a runway
or predesignated landing area, as well
as damage during maintenance.
HEMS Helicopter Emergency Medical
Services
IFR ‘IFR’ means the symbol used to SERA [13]
designate the instrument flight rules;
Page I 390
Insert project
logo here

IMC ‘Instrument meteorological conditions SERA [13]
(IMC)’ mean meteorological conditions
expressed in terms of visibility,
distance from cloud, and ceiling, less
than the minima specified for visual
meteorological conditions.
No fly zones (NFZ) No Drone Zone: UAS are totally In U-space they are referring to a "No
prohibited in this volume unless Drone Zone"
granted special authorisation (e.g.,
government UAS)
Link to Geographical zone, article 15 of

UAS regulation
When defining UAS geographical
zones for safety, security, privacy or
environmental reasons, Member
States may:
(a) prohibit certain or all UAS
operations, request particular
conditions for certain or all UAS
Obstacle collision in flight (Risk area) collision between an Regulation (EC) 2020/2034 [14]
airborne aircraft and obstacles rising
from the surface of the earth.
Obstacles include tall buildings, trees,
power cables, telegraph wires and
antennae as well as tethered objects;
Operational framework The operational framework is the To be validated or improved by CORUS
description of the technical, X partners.
procedural, physical and regulatory
working environments.
Other injuries (Risk area) an occurrence where fatal Regulation (EC) 2020/2034 [14]
or non-fatal injuries have been
inflicted, which cannot be attributed
to any other key risk area;
Populated area ‘Populated area’ means an area with Regulation (EU) 2020/2034 [14]
clustered or scattered buildings and a
permanent human population, such as
city, settlement, town, or village;
Page I 391
Insert project
logo here

Remote pilot ‘Remote pilot’ means a natural person Regulation (EU) 2018/1139 (Basic
responsible for safely conducting the Regulation) [10]
flight of an unmanned aircraft by
operating its flight controls, either
manually or, when the unmanned
aircraft flies automatically, by
monitoring its course and remaining
able to intervene and change the
course at any time;
RLOS Radio Line Of Sight - refers to the Doc 10019 Edition 2015 [20]
situation in which the transmitter(s)
and receiver(s) are within mutual radio
link coverage and thus able to
communicate directly or through a
ground network provided that the
remote transmitter has RLOS to the
RPA and transmissions are completed
in a comparable timeframe.
RP Remote Pilot: A person charged by the Doc 10019 [20]
operator with duties essential to the
operation of a remotely piloted
aircraft and
who manipulates the flight controls, as
appropriate, during flight time.
RPA Remotely Piloted Aircraft: An Doc 10019 [20]
unmanned aircraft which is piloted
from a remote pilot station.
RPAS Remotely Piloted Aircraft System: A Doc 10019 [20]
remotely piloted aircraft, its
associated remote pilot station(s), the
required C2 Link and any other
components as specified in the type
design.
RPS Remote Pilot Station: The component Doc 10019 [20]
of the remotely piloted aircraft system
containing the equipment used to
pilot the remotely piloted aircraft.
Rural "An area with widely scattered American Highway Capacity Manual
development and low density of (HCM) / Alternative: NatGeo
housing and employment"
Page I 392
Insert project
logo here

Security (Risk area) an occurrence where fatal Regulation (EC) 2020/2034 [14]
or non-fatal injuries have been
inflicted, which cannot be attributed
to any other key risk area;
U-space services U-space service’ means a service Regulation (EU) 2021/664 [23]
relying on digital services and
automation of functions designed to
support safe, secure and efficient
access to U-space airspace for a large
number of UAS
Special VFR ‘Special VFR flight’ means a VFR flight SERA [13]
cleared by air traffic control to operate
within a control zone in
meteorological conditions below VMC;
Suburban "An area with mixture of densities for American Highway Capacity Manual
housing and employment, where high- (HCM) / Alternative: NatGeo
density non-residential development is
intended to serve the local
community".
Terrain collision (Risk area) an occurrence where an Regulation (EC) 2020/2034 [14]
airborne aircraft collides with terrain,
without indication that the flight crew
was unable to control the aircraft. It
includes instances when the flight
crew is affected by visual illusions or
degraded visual environment;
UAM UAM covers passenger and cargo Airbus Blueprint for the sky, 2018 [24]
flights operated in densely populated
areas, including air taxis, delivery
drones, remotely piloted and
autonomous operations.
Urban Air Mobility (UAM) is an MITRE, Urban Air Mobility Airspace
industry term used to describe a Integration Concepts, 2019 [25]
system that enables on-demand,
highly automated, passenger- or
cargo-carrying air transportation
services.
Page I 393
Insert project
logo here

The transport of people or goods from FAA, NASA UAM Conops v.1, 2020 [26]
one aerodrome to another using UAM
Corridors (UAM operation).
UAM vehicles - primarily eVTOLs. First EmbraerX ConOps [27]
with pilot on board, then remote pilot.
For carriage of passengers or cargo.
UAM Aerodrome UAM aerodrome – a location from Concept of Operations Urban Air
which UAM flight operations depart or Mobility (FAA)
arrive. The use of “UAM aerodrome”
and “aerodrome” in this ConOps are
synonymous. “UAM aerodrome” is
used explicitly when the context
indicates functionality to support UAM
operations that is not present
in current NAS operations.
UAM operation UAM Operations are operations with To be approved by CORUS X
unmanned aircraft in an urban
environment.
UAM vehicle An aircraft involved in a UAM To be approved by CORUS X
operation
UAS Unmanned Aircraft System: An aircraft Doc 10019
and its associated elements which are
operated with no pilot on board.
UAS unmanned aircraft system' (UAS) EU 2019/947
means an unmanned aircraft and the
equipment to control it remotely
UFR “U-space Flight Rules” are rules of the to be approved by CORUS X
air that would be applicable to any
aircraft wishing to fly in a U-space
volume.
Unmanned Aircraft ‘Unmanned aircraft’ means any Regulation (EU) 2018/1139 (Basic
aircraft operating or designed to Regulation)
operate autonomously or to be piloted
remotely without a pilot on board;
Urban "An area typified by high densities of American Highway Capacity Manual
development or concentrations of (HCM) / Alternative: NatGeo
population, drawing people from
several areas within a region"
Page I 394
Insert project
logo here

USSP U-Space Service Provider EASA
Vertiport ‘vertiport’ means an area of land, Special Conditions VTOL (EASA)
water, or structure used or intended
to be used for the landing
VFR ‘VFR’ means the symbol used to SERA
designate the visual flight rules;
VLOS Visual Line of Sight operation: An Doc 10019
operation in which the remote pilot or
RPA observer maintains direct unaided
visual contact with the remotely
piloted aircraft.
VMC ‘Visual meteorological conditions’ SERA
mean meteorological conditions
expressed in terms of visibility,
distance from cloud, and ceiling, equal
to or better than specified minima;
VTOL Vertical Take Off and Landing - said for To be approved by CORUS X
an aircraft, which is not a helicopter,
able to take-off and land vertically.
Air Traffic Services “Air traffic services’ means the various REGULATION (EC) No 549/2004
flight information services, alerting
services, air traffic advisory services
and ATC services (area, approach and
aerodrome control services).
7.3 List of Acronyms and abbreviations

Acronym Definition
ACAS Xu Airborne collision Avoidance System X – the successor to TCAS II Xu –

designed for UAV (specifically RPAS)
ADS-B Automatic Dependent Surveillance - Broadcast
AESA Agencia Estatal de Seguridad Aérea (Spanish NAA)
Page I 395
Insert project
logo here
AFIS Aerodrome Flight Information Service
AGL Above Ground Level
AMC Acceptable Means of Compliance
AMSL Above Medium Sea Level
AMULED Air Mobility Urban - Large Experimentation Demonstrations
ANSP Air Navigation Service Provider
ARC Air Risk Class
ATS Air Traffic Services
ATSP Air Traffic Service Provider
ATZ Air Traffic Zone
BRLOS Beyond Radio Line Of Sight
C2 link Command & Control link
CARS Common Altitude Reference System
CBD Central Business Districts
CFR Code of Federal Regulations
CISP Common Information Service Provider
ConOps Concept of Operations
Page I 396
Insert project
logo here
CORUS Concept of Operation for EuRopean UTM Systems
CSFL Continued Safe Flight and Landing
CTR Controlled Traffic Region
CWP Controller Working Position
DAC Dynamic Airspace Configuration
DACUS Demand And Capacity Optimisation in U-space
DCB Demand and Capacity Balancing
DFS Deutsche Flugsicherung GmbH
DSNA Direction des Services de la Navigation Aérienne (french ANSP)
EU European Union
ETRS89 European Terrestrial Reference System 1989
eVTOL Electric Vertical Take-off and Landing
FAA Federal Aviation Administration
FAR Federal Aviation Rules
FATO Final Approach and Take-off Area
FDPS Flight Data Processing System
FIS Flight Information Service
FLARM Flight AlARM
FPV First Person View
Page I 397
Insert project
logo here
Ft Feet
GM Guidance Material
GME Ground Movement Equipement
GNSS Global Navigation Satellite System
GPS Global Positioning System
GRC Ground Risk Class
GSM LTE 5G Global System for Mobile Long-Term Evolution 5G
HEMS Helicopter Emergency Medical Services
ICAO International Civil Aviation Organization
JARUS Joint Authorities for Rulemaking of Unmanned Systems
KJ Kilo Joules
KTAS Knots True AirSpeed
LAANC Low Altitude Authorization and Notification Capability
Lb Libra
LBA Luftfahrt-Bundesamt
Maas Mobility as a Service
MSDF Multi Sensor Data Fusion
MTCD Medium Term Conflict Detection
MTOM Maximum Take-Off Mass
NASA National Air and Space Administration
Page I 398
Insert project
logo here
NM Network Manager
NOTAM NOtice To AirMen
NPRM Notice of proposed rulemaking
OSO Operational Safety Objectives
PAV Personal Air Vehicles
POBA Pilot On-board Aircraft
RLOS Radio Line Of Sight
RP Remote Pilot
RPAS Remotely Piloted Aircraft System
RPS Remote Pilot Station
RTK Real-time kinematic
RTTA Reasonable Time to Act
SAIL Specific Assurance and Integrity Levels
SAR Search And Rescue
SDSP Supplemental Data Service Provider
SJU SESAR Joint Undertaking (Agency of the European Commission)
SMGCS / A-SMGCS Surface Movement Guidance and Control System / Advanced Surface
Movement Guidance and Control System
STCA Short Term Conflict Alerting
STOL Short Take-off and Landing
Page I 399
Insert project
logo here
STS STandard Scenario
SUMP - UAM Sustainable Urban Mobility Plan/Policy – Urban Air Mobility
SVFR Special Visual Flight Rules
TCAS II Traffic Collision Avoidance System version II, an ACAS implemention
TLOF Touch-Down and Lift-Off
TMPR Tactical Mitigation Performance Requirement
TOLA Touchdown and Lift off Area
U1, U2, U3, U4 U-space service level
UA Unmanned Aircraft
UAV Unmanned Aerial Vehicle
UC Use Case
UML UAM Maturity Level
UMZ U-space Mandatory Zone
USSP U-space Service Provider
UTM UAS Traffic Management
V2V Vehicle to Vehicle
VLD Very Large Demonstrator
VLL Very Low Level
Page I 400
Insert project
logo here
VO Visual Observer
VTOL Vertical Take-off and Landing
V-TZ Vertiport Traffic Zone
WG Working Group
WGS84 World Geodetic System, revision 84
Acronym Definition

ACAS Xu Airborne collision Avoidance System X – the successor to TCAS II Xu –
designed for UAV (specifically RPAS)
ADS-B Automatic Dependent Surveillance - Broadcast
AESA Agencia Estatal de Seguridad Aérea (Spanish NAA)
AFIS Aerodrome Flight Information Service
AGL Above Ground Level
AMC Acceptable Means of Compliance
AMSL Above Medium Sea Level
AMULED Air Mobility Urban - Large Experimentation Demonstrations
ARC Air Risk Class
ATS Air Traffic Services
ATSP Air Traffic Service Provider
ATZ Air Traffic Zone
Page I 401
Insert project
logo here
BRLOS Beyond Radio Line Of Sight

C2 link Command & Control link
CBD Central Business Districts
CFR Code of Federal Regulations
CISP Common Information Service Provider
ConOps Concept of Operations
CORUS Concept of Operation for EuRopean UTM Systems
CWP Controller Working Position
DACUS Demand And Capacity Optimisation in U-space
DCB Demand and Capacity Balancing
DFS Deutsche Flugsicherung GmbH
DSNA Direction des Services de la Navigation Aérienne (french ANSP)
EU European Union
ETRS89 European Terrestrial Reference System 1989
FAA Federal Aviation Administration
FAR Federal Aviation Rules
FDPS Flight Data Processing System
FIS Flight Information Service
FLARM Flight AlARM
FPV First Person View
Ft Feet
Page I 402
Insert project
logo here
GM Guidance Material
GNSS Global Navigation Satellite System
GPS Global Positioning System
GRC Ground Risk Class
GSM LTE 5G Global System for Mobile Long-Term Evolution 5G
HEMS Helicopter Emergency Medical Services
ICAO International Civil Aviation Organization
JARUS Joint Authorities for Rulemaking of Unmanned Systems
KJ Kilo Joules
KTAS Knots True AirSpeed
LAANC Low Altitude Authorization and Notification Capability
Lb Libra
LBA Luftfahrt-Bundesamt
Maas Mobility as a Service
MSDF Multi Sensor Data Fusion
MTCD Medium Term Conflict Detection
MTOM Maximum Take-Off Mass
NASA National Air and Space Administration
NM Network Manager
NOTAM NOtice To AirMen
NPRM Notice of proposed rulemaking
OSO Operational Safety Objectives
PAV Personal Air Vehicles
RLOS Radio Line Of Sight
RP Remote Pilot
RPAS Remotely Piloted Aircraft System
Page I 403
Insert project
logo here
RPS Remote Pilot Station

RTK Real-time kinematic
SAIL Specific Assurance and Integrity Levels
SAR Search And Rescue
SDSP Supplemental Data Service Provider
SJU SESAR Joint Undertaking (Agency of the European Commission)
SMGCS / A-SMGCS Surface Movement Guidance and Control System / Advanced Surface
Movement Guidance and Control System
STCA Short Term Conflict Alerting
STS STandard Scenario
SUMP - UAM Sustainable Urban Mobility Plan/Policy – Urban Air Mobility
TCAS II Traffic Collision Avoidance System version II, an ACAS implemention
TMPR Tactical Mitigation Performance Requirement
TOLA Take-off and Landing Areas
U1, U2, U3, U4 U-space service level
UTM UAS Traffic Management
V2V Vehicle to Vehicle
VLL Very Low Level
Page I 404
Insert project
logo here

VO Visual Observer
WG Working Group
WGS84 World Geodetic System, revision 84
Table 108: List of acronyms and abbreviations
Page I 405
Insert project
logo here
Appendix A Use Cases for U-Space services
The diagrams below show the following use cases for U-space services:
- Services as described in regulation (EU) 2021/664
- Weather information service
- Registration service
- Registration assistance service
- E-identification
- Geo-awareness
- Geo-fence provision
- Tracking and position reporting
- Traffic information service
- Operation plan processing
Page I 406
Insert project
logo here
Page I 407
Insert project
logo here
Page I 408
Insert project
logo here
Page I 409
Insert project
logo here
Page I 410
Insert project
logo here
Page I 411
Insert project
logo here
Page I 412
Insert project
logo here
Page I 413
Insert project
logo here
Page I 414
Insert project
logo here
Appendix B T3.2 Integrated Requirements

The excel file contains additional information, as per example the link with the services
CORUS-XUAM%20R
equirements%20Integrated%20version.xlsx
Page I 415
Insert project
logo here
Page I 416
Insert project
logo here
Page I 417
D2.4 GOF2.0 VLD Updated

Service Specifications
Project Acronym: GOF2.0
Grant: 101017689
Call: H2020-SESAR-2020-1 VLD Open 2
Topic:
Air Mobility
Consortium Coordinator: LENNULIIKLUSTEENINDUSE AS (EANS)
Edition Date: 4 November 2022
Edition: 01.00.00
D2.4 GOF2.0 VLD UPDATED SERVICE SPECIFICATIONS

Name/Beneficiary Position/Title Date
Gregor Mogeritsch / FRQ WP2 26.10.2022
Hubert Künig / FRQ WP2 26.10.2022
Peter Cornelius / FRQ WP2 26.10.2022
Thomas Lutz / FRQ WP2 Lead 26.10.2022

Jonas Stjernberg / Robots Expert WP3 Lead 1.11.2022
Maria Tamm / EANS Project coordinator 3.11.2022
Tanel Järvet / CAFA WP4 Lead 3.11.2022
Damian Soliwoda / PSNC WP2 member 2.11.2022
Lukasz Gorny-Zajac / DRR WP2 member 2.11.2022
Parmentier Remy / VAI WP2 member 2.11.2022
Pawel Korzec / DRR WP2 member 2.11.2022
Piotr Dybiec / DRR WP2 member 2.11.2022
Piotr Luboński / PSNC WP2 member 31.10.2022
Piotr Szymaniak / PSNC WP2 member 31.10.2022
Sven Jürgenson / Threod WP3 member 3.11.2022
Leopoldo Tejada/UML WP2 member 2.11.2022
Thomas Wana / DIME WP2 member 31.10.2022
Yuhang Yun / EHANG WP3 member 30.10.2022
Iris Roehrich / FRQ WP1 member 3.11.2022
Approved for submission to the SJU By - Representatives of beneficiaries involved in the project
Sami Alkula/FANS Project Management Group 3.11.2022
Thomas Neubauer/DIME Project Management Group 3.11.2022
Pawel Korzec/DRR Project Management Group 3.11.2022
Yuhang Yun/EHE Project Management Group 3.11.2022
Damini Gera/AIRB Project Management Group 3.11.2022
2
Piotr Szymaniak/PSNC Project Management Group 3.11.2022

Sven Jürgenson/THREOD Project Management Group 3.11.2022
Leopoldo Tejada/UML Project Management Group 3.11.2022
Tapio Haarlaa/VAI Project Management Group 3.11.2022
Iris Röhrich/FRQ Project Management Group 3.11.2022
Juha Lindstedt/AVIA Project Management Group 3.11.2022
Piotr Bratek/PANSA Project Management Group 3.11.2022
Tanel Järvet/CAFA Project Management Group 3.11.2022

Document History
Edition Date Status Author Justification
00.00.01 26.10.2022 draft WP2 Lead
01.00.00 4.11.2022 released WP2 Partners Revised and amendments
included
Copyright Statement
©2022 GOF2.0 Consortium. All rights reserved.
Licensed to the SESAR Joint Undertaking under conditions
3
GOF2.0
GOF2.0 INTEGRATED URBAN AIRSPACE VLD
This critical design document is part of a project that has received funding from the SESAR Joint
Abstract
This deliverable describes the GOF2.0 information exchange services documented at conceptual level,
following SWIM principles, which could be used to implement U-space airspace, following guidance
material to (EU 664/2021).
For each service specification there is a separate document. These documents are embedded in this
document, which acts as bucket. As a preview, the data model of each service specification is copied
into this document.
The service specifications are a baseline, built on experience from previous projects and the GOF2.0
project execution.
They have been updated based on D2.2, with better understanding gained in integration and trials.
Updates were performed in agreement between the GOF2.0 project partners, which could be
considered a governance body for the project execution time.
Currently, the following information exchange services are available:
 Traffic/Telemetry (Appendix A)
 Operation Plan (Appendix B)
 Geozones (Appendix C)
 Registration (Appendix D)
 Operational Message (Appendix E)
 Traffic Conformance Monitoring (Appendix F)
 Network Data (Appendix G)
 Ground Control Integration (Appendix H)
 Drone Flight (Appendix I)
 Weather (Appendix J)
4
Table of Contents
Abstract ................................................................................................................................... 4
1 Executive Summary .................................................................................................... 7
2 Introduction ............................................................................................................... 9
2.2 Scope ............................................................................................................................ 9
2.4 Structure of the document ........................................................................................... 11
2.5 Background ................................................................................................................. 11
2.7 List of Acronyms .......................................................................................................... 11
3 References ............................................................................................................... 12
Appendix A Traffic/Telemetry .................................................................................... 13
A.1 Data Model ................................................................................................................. 13
A.2 Embedded document................................................................................................... 13
Appendix B Operation Plan........................................................................................ 14
B.1 Data Model ................................................................................................................. 14
B.2 Embedded document................................................................................................... 14
Appendix C Geozones ................................................................................................ 15
C.1 Data Model ................................................................................................................. 15
C.2 Embedded document................................................................................................... 15
Appendix D Registration ............................................................................................ 16
D.1 Data Model ................................................................................................................. 16
D.2 Embedded document................................................................................................... 16
Appendix E Operational Message .............................................................................. 17
E.1 Data Model ................................................................................................................. 17
E.2 Embedded document................................................................................................... 17
Appendix F Traffic Conformance Monitoring (not validated) ...................................... 18
F.1 Data Model ................................................................................................................. 18
F.2 Embedded document................................................................................................... 18
Appendix G Network Data ......................................................................................... 19
G.1 Data Model ................................................................................................................. 19
5
G.2 Embedded document................................................................................................... 19

Appendix H Ground Control Integration ..................................................................... 20
H.1 Data Model ................................................................................................................. 20
H.2 .Embedded document.................................................................................................. 20
Appendix I Drone flight (proposed) .............................................................................. 21
I.1 Data Model ................................................................................................................. 21
I.2 Embedded document................................................................................................... 21
Appendix J Weather ..................................................................................................... 22
J.1 Embedded Document .................................................................................................. 22
List of Tables
List of Figures
Figure 1 - High level Architecture based on grant agreement ................................................................ 7
Figure 2: Traffic / Telemetry Exchange Data Model.............................................................................. 13
Figure 3: Operation Plan Exchange Model ............................................................................................ 14
Figure 4: Geozones Exchange Model .................................................................................................... 15
Figure 5: Registration Exchange Data Model ........................................................................................ 16
Figure 6: Operational Message Exchange Model .................................................................................. 17
Figure 7: Traffic Conformance Monitoring Exchange Model ................................................................ 18
Figure 8: Network Coverage Exchange Model ...................................................................................... 19
Figure 9: Drone flight exchange model ................................................................................................. 21
Figure 10: Weather exchange model .................................................................................................... 22
6
1 Executive Summary
The information exchange services described in this document could be used to implement
U-space airspace, following guidance material to (EU 664/2021).
This document is an update to D2.2 Service Specification. Changes were done mostly in the
areas of operation plan and network data. New service specifications were introduced for
weather service and drone flight. For convenience, service specifications of D2.2 were again
included in this document.
“The GOF2.0 Integrated Urban Airspace VLD (GOF2.0) very large demonstration
project will safely, securely, and sustainably demonstrate operational validity of
serving combined UAS, eVTOL and manned operations in a unified, dense urban
airspace using current ATM and U-space services and systems.
Both ATM and U-space communities depend extensively on the provision of

timely, relevant, accurate and quality-assured digital information to collaborate
and make informed decisions.” [12]
Figure 1 - High level Architecture based on grant agreement
Timely, relevant, accurate and quality-assured digital information is exchanged as shown in Figure 1,
indicated by the double arrows. They connect stakeholders in the demonstrated UTM / U-space
ecosystem. For each type of information exchanged (e.g. Traffic/Telemetry, Operation Plan,
Geodata…).
7
Information exchange services are introduced and described using formal templates, separating
logical, technical and runtime concerns. By defining the interfaces in the system, they enable a
modular, interoperable, open, and highly resilient system of systems, allowing for technical variants in
implementation and deployment.
This deliverable contains descriptions for the information exchange services identified in GOF2 –
harmonizing the information flow between respective services.
8
2 Introduction
This deliverable contains service specifications for information exchange services on conceptual level.
2.2 Scope
This document contributes to all objectives of the GOF2.0 project, especially those listed below. The
focus of this deliverable is indicated in bold letters.
 Objective O2: Integrated, lean, modular, resilient, and interoperable system architecture
supporting safe integration of all UAM vehicles on national and European level
o Demonstrate the exchange of trajectory, weather, connectivity, and aeronautical

information through information management, supported by SWIM interoperable
services, to enhance collaborative decision-making at network and global levels, and
specifically to allow safe and affordable integration of UAM into a shared airspace at
high vehicle densities and in mixed traffic scenarios. Demonstrate interoperability
through standardised interfaces for U-space, CIS and ATM information exchanges,
to allow seamless U-space/ATM operations for all operational stakeholders.
o Project Results: Documented service architecture, proposals for standardised

interface service descriptions, performance data from validation trials, tracking
performance, probability and reliability of identification and authentication,
availability of connectivity, availability of communication means for safety
notifications and ATC instruction
 Objective O4: Air-ground and ground-air connectivity and sharing of information digitally
o Showcase technical means to enable the exchange of digital information in support

of collaborative management of UAM operations and remote provision of U-
space/ATM services:
 Ground-Air Data link using mobile networks
 Air-ground Data link using mobile networks
 Information Exchanges using the SWIM Yellow Profile
o Project Results: Automated data exchange between the supplementary connectivity

data providers and the various stakeholders in the system architecture for pre-flight
and flight operations and services plus validation / audit via measurements
 Objective O7: Virtualisation - allowing more dynamic resource allocation
o Demonstrate modern-day cloud deployment, general-purpose communication, and

computer processing capabilities to allow for better performing and more cost-
efficient U-space/ATM service provision. A Centralized cloud deployment serving
9
ANSPs, USSPs and finally all airspace users lead to facilitate data sharing, new
synergies, and more cost-efficient management of the U-space/ATM resource
network. It facilitates effective interoperability between functional systems.
o Project Results:
 U-space service catalogue,
 Operational and technical performance assessment (Response times for

automated and manual flight authorisations.)
 Data models,
 ICDs
 Airspace assessment
 Objective O9: Definition of novel U-space service essential to enable UAM
o Introduce novel U-space services including concept, definition and validation to serve
a safe, orderly and efficient integration of UAM. Within the scope of GOF2.0 the
following - but not limited to - services will be defined:
 mobility data: population densities to calculate ground risks
 connectivity data to ensure reliable communication links between airborne

and ground segments
 hyperlocal weather information
o Project Results:
 U-space services catalogue,
 Data models,
 ICDs

• Authorities
• Air Navigation Service Providers (ANSPs)
• Civil Aviation Authorities (CAAs)
• U-Space / UTM Service Provides
• U-Space / UTM Infrastructure Providers
• Administrative Units
• Supplemental Data or Data Service Providers
10
• Drone Manufacturer
• Drone Operators
• General Aviation Operators

The document is a bucket for the Service Specifications embedded in the appendices.
As preview, a copy of the data model for each service specification was copied into the appendices.
Please refer to the respective chapter in the appendices for the specific structure of a Service
Specification.
2.5 Background
When producing this document and its appendices, several research and standardization activities, as
well as projects, initiatives and existing solutions have been considered.
Please refer to the respective chapter in the appendices for the specific background.

n/a

Acronym Definition
UTM Unmanned Traffic Management

SWIM System Wide Information Management
ICD Interface Control Document
11
3 References
[2] U-space
regulationhttps://ec.europa.eu/transparency/regexpert/index.cfm?do=groupDetail.groupMe
eting&meetingId=23814)SESAR 2020 GOF USPACE FIMS Design and Architecture – D4SESAR
principles for U-space architecture https://www.sesarju.eu/sites/default/files/documents/u-
space/SESAR%20principles%20for%20U-space%20architecture.pdf
12
Appendix A Traffic/Telemetry
A.1 Data Model
Figure 2: Traffic / Telemetry Exchange Data Model
A.2 Embedded document

D2.4-A GOF2.0 VLD
Service Specification TrafficTelemetry 00.00.04.docx
13
Appendix B Operation Plan

B.1 Data Model
Figure 3: Operation Plan Exchange Model
B.2 Embedded document

D2.4-B GOF2.0 VLD
Service Specification Operation Plan 00.00.04.docx
14
Appendix C Geozones
C.1 Data Model
Figure 4: Geozones Exchange Model
C.2 Embedded document

D2.4-C GOF2.0 VLD
Service Specification Geozones 00.00.06.docx
15
Appendix D Registration
D.1 Data Model
Figure 5: Registration Exchange Data Model
D.2 Embedded document

D2.4-D GOF2.0 VLD
Service Specification Registration 00.00.03.docx
16
Appendix E Operational Message

E.1 Data Model
Figure 6: Operational Message Exchange Model
E.2 Embedded document

D2.4-E GOF2.0 VLD
Service Specification Operational Message.00.00.01.docx
17
Appendix F Traffic Conformance Monitoring (not

validated)
F.1 Data Model
Figure 7: Traffic Conformance Monitoring Exchange Model
F.2 Embedded document

D2.4-F GOF2.0 VLD
Service Specification Traffic Conformance Monitoring.00.01.02.docx
18
Appendix G Network Data

G.1 Data Model
Figure 8: Network Coverage Exchange Model
G.2 Embedded document

D2.4-G GOF2.0 VLD
Service Specification Network coverage and population density 00.00.04.docx
19
Appendix H Ground Control Integration

H.1 Data Model
Where feasible, the information services described in the other appendices have been used in the
integration phase approaching the first GOF2.0 trials. GOF 2.0 consortium did not need a specific
ground control integration specification based on the operational scenarios run in the trials.
H.2 .Embedded document

Please refer to the other appendices.
20
Appendix I Drone flight (proposed)

I.1 Data Model
Figure 9: Drone flight exchange model
I.2 Embedded document

D2.4-I GOF2.0 VLD
Service Specification Drone Flight.docx
21
Appendix J Weather
Figure 10: Weather exchange model
J.1 Embedded Document

D2.4-J GOF2.0 VLD
Service Specification Weather 00.00.04.docx
22
D2.4 Appendix A
Traffic/Telemetry Service
Specification
Deliverable ID: D2.4-A
Project Acronym: GOF 2.0
Grant: 101017689
Topic:
Air Mobility
Consortium Coordinator: Lennuliiklusteeninduse Aktsiaselts (EANS)
Edition: 01.00.00
D2.4 APPENDIX A TRAFFIC/TELEMETRY SERVICE SPECIFICATION

Gregor Mogeritsch / Frequentis WP2 26.10.2022
Hubert Künig / Frequentis WP2 26.10.2022
Peter Cornelius / Frequentis WP2 26.10.2022
Thomas Lutz / Frequentis WP2 Lead 26.10.2022

2

Maria Tamm/EANS Project Management Group 3.11.2022

Document History
00.00.01 2019 GOF U-space Project Partners (Sebastian Babiarz /
Airmap, Teodor Todorov / Airmap, Rupert
Benbrook / Altitude Angel, Phil Binks / Altitude
Angel, Chris Forster / Altitude Angel, Simon Wynn-
Mackenzie/ Altitude, Angel Alkula Sami /
Ansfinland, Tanel Jarvet / Cafatech, Vello
Müürsepp / EANS, Heidi Himmanen / Ficora, Dan
Davies / Fleetonomy, Peter Cornelius / Frequentis,
Thomas Lutz / Frequentis, Harald Milchrahm /
Frequentis, Jonas Stjernberg / Robots Experts,
Charlotte Kegelaers / Unifly, Ronni Winkler
Østergaard / Unifly, Andres Van Swalm / Unifly
00.00.02 18.03.2021 draft WP2 Partners Update or GOF2.0 D2.2
00.00.03 30.04.2021 Release WP2 Partners As GOF2.0 D2.2
00.00.04 26.04.2022 draft WP2 Partners Revised and updated
draft
01.00.00 04.11.2022 Released Coordinator Submit deliverable
Copyright Statement
© 2022 – GOF2.0 Consortium. All rights reserved. Licensed to SESAR3 Joint Undertaking
under conditions.
3
GOF 2.0
This Updated Service Specification is part of a project that has received funding from the SESAR Joint
Abstract
This specification introduces a service of a Common Information Service (CIS) which ensures
interoperability and hence transparent and reliable information flow between the stakeholders in an
operational U-space environment. In accordance with ICAO SWIM, represents an Information
Exchange Service.
Specifically, this document describes, in a logical, technology-independent manner, the
Traffic/Telemetry service, a Position report Submission Sub-Service and Surveillance Data Service
which accepts and carries surveillance data from a number of data sources to a Tracking Service which,
in turn, provides a common situational picture to its consumers via this service.
Sources include, but are not limited to, primary and secondary radar and other drone detection
services, on-board position telemetry services, and tracking service,
Consumers include, but are not limited to monitoring and traffic information services, tracking
services, and display systems.
4
Table of Contents
Abstract ................................................................................................................................... 4
1 Abstract ..................................................................................................................... 9
2 Introduction ............................................................................................................. 10
2.2 Scope .......................................................................................................................... 10
2.4 Background ................................................................................................................. 10
2.4.1 EUROCONTROL Concept of Operations for U-space (CORUS) ........................................................ 10
2.4.2 Global UTM Association (GUTMA) and GUTMA-related ................................................................. 12
2.4.2.1 Flight Logging Protocol ........................................................................................................... 12
2.4.2.2 Air Traffic Protocol .................................................................................................................. 12
2.4.3 Federal Aviation Administration (FAA) Concepts of Operations ..................................................... 13
2.4.4 Swiss Federal Office of Civil Aviation (FOCA) .................................................................................. 13
2.4.5 International Civil Aviation Organization (ICAO) ............................................................................. 13
2.4.6 Open Drone ID................................................................................................................................. 13
2.4.7 SESAR-JU.......................................................................................................................................... 14
2.4.8 Efficient, safe and sustainable traffic at sea (EfficienSea2) ............................................................. 14
2.4.9 ASTM ............................................................................................................................................... 15
2.6 List of Acronyms .......................................................................................................... 17
3 Service Identification................................................................................................ 18
4 Operational Context................................................................................................. 19
4.1 Functional and Non-functional Requirements ............................................................... 19
4.2 Other Constraints ........................................................................................................ 20
4.2.1 Relevant Industrial Standards ......................................................................................................... 20
4.2.1.1 ICAO SWIM ............................................................................................................................. 20
4.2.1.2 EUROCONTROL ASTERIX ......................................................................................................... 21
4.2.1.3 EUROCONTROL ATM Automation System Environment Performance Requirements .......... 21
4.2.1.4 FAA ATM Automation System Environment Performance Requirements ............................. 22
4.2.2 Operational Nodes .......................................................................................................................... 22
4.2.3 Operational Activities ...................................................................................................................... 23
5 Service Overview...................................................................................................... 25
5.1 Service Interfaces ........................................................................................................ 25
6 Service Data Model .................................................................................................. 26
6.1 Overview..................................................................................................................... 26
6.2 The Pose Data Structure .............................................................................................. 26
6.3 The Velocity Data Structure ......................................................................................... 30
6.4 The VelocityChangeRate Data Structure ....................................................................... 30
6.5 The Orientation Data Structure .................................................................................... 31
5
6.6 The OrientationChangeRate Data Structure .................................................................. 31

6.7 The ObjectIdentification Data Structure ....................................................................... 32
6.8 The EnumObjectIdentificationType Enumeration.......................................................... 32
6.9 The ObjectPriority Data Structure ................................................................................ 34
6.10 The PositionReport Data Structure ............................................................................... 35
6.11 The Position Data Structure ......................................................................................... 35
6.12 The Altitude Data Structure ......................................................................................... 36
6.13 The EnumAltitudeType Enumeration ........................................................................... 40
6.14 The EnumCRSType Enumeration ................................................................................. 40
6.15 The AltitudeDeterminationMethod Enumeration ........................................................ 40
6.16 The FlightEventIndication Data Structure ..................................................................... 41
6.17 The FlightEventType Enumeration ............................................................................... 41
6.18 Common Data Structures Used in UTM Service Specifications ....................................... 41
6.18.1 NotificationEndpoint Data Structure .......................................................................................... 42
6.18.2 ServiceResponse Data Structure ................................................................................................. 42
6.18.3 OperationResult Enumeration .................................................................................................... 42
6.19 Common Geometry Data Structures Used in UTM Service Specifications ....................... 43
6.19.1 AreaOfInterest Data Structure .................................................................................................... 43
6.19.2 Geometry Data Structure............................................................................................................ 43
6.19.3 EnumAltitudeType Enumeration ................................................................................................ 44
6.19.4 EnumCRSType Enumeration ....................................................................................................... 44
6.19.5 EnumGeometryType Enumeration ............................................................................................. 46
7 Service Interface Specifications ................................................................................ 47

7.1 Service Interface TrafficTelemetrySubscriptionInterface ............................................... 47
7.1.1 Operation subscribeForTrafficTelemetry ........................................................................................ 47
7.1.1.1 Operation Functionality.......................................................................................................... 47
7.1.1.2 Operation Parameters ............................................................................................................ 47
7.1.2 Operation unSubscribeForTrafficTelemetry.................................................................................... 47
7.2 Service Interface TrafficTelemetryNotificationInterface ................................................ 47
7.2.1 Operation notifyPositionReport ...................................................................................................... 48
7.2.2 Operation notifyFlightEvent ............................................................................................................ 48
8 Service Dynamic Behaviour ...................................................................................... 49

8.1 Service Interfaces TrafficTelemetrySubscriptionInterface and
TrafficTelemetryNotificationInterface ..................................................................................... 49
9 References ............................................................................................................... 51
6
List of Tables
Table 3: Service Identification ............................................................................................................... 18
Table 4: Requirements for the Traffic/Telemetry Service ..................................................................... 20
Table 5: Excerpt from EUROCONTROL Specification for ATM Surveillance System Performance [16] 21
Table 6: Operational Nodes providing the Traffic/Telemetry service................................................... 23
Table 7: Operational Nodes consuming the Traffic/Telemetry service ................................................ 23
Table 8: Operational Activities supported by the Traffic/Telemetry service ........................................ 24
Table 9: Service Interfaces .................................................................................................................... 25
Table 10: The Pose data structure......................................................................................................... 30
Table 11: The Velocity data structure ................................................................................................... 30
Table 12: The VelocityChangeRate data structure ................................................................................ 31
Table 13: The Orientation data structure.............................................................................................. 31
Table 14: The OrientationChangeRate data structure .......................................................................... 32
Table 15: ObjectIdentification data structure ....................................................................................... 32
Table 16: EnumObjectIdentificationType enumeration ........................................................................ 34
Table 17: The ObjectPriority data structure.......................................................................................... 35
Table 18: The PositionReport data structure ........................................................................................ 35
Table 19: The Position data structure ................................................................................................... 36
Table 20: The Altitude data structure ................................................................................................... 40
Table 21: The AltitudeDeterminationMethod enumeration................................................................. 41
Table 22: The FlightEventIndication data structure .............................................................................. 41
Table 23: The FlightEventType enumeration ........................................................................................ 41
Table 24: NotificationEndpoint Data Structure ..................................................................................... 42
Table 25: ServiceResponse Data Structure ........................................................................................... 42
Table 26: OperationResult Enumeration............................................................................................... 42
Table 27: AreaOfInterest Data Structure .............................................................................................. 43
7
Table 28: Geometry Data Structure ...................................................................................................... 44
Table 29: EnumAltitudeType Enumeration ........................................................................................... 44
Table 30: EnumCRSType Enumeration .................................................................................................. 46
Table 31: EnumGeometryType Enumeration ........................................................................................ 46
Table 32: Payload description of subscribeForTrafficTelemetry operation .......................................... 47
Table 33: Payload description of unSubscribeForTrafficTelemetry operation ..................................... 47
Table 34: Payload description of notifyPositionReport operation........................................................ 48
Table 35: Payload description of notifyFlightEvent operation.............................................................. 48
Table 36: List of References .................................................................................................................. 52
List of Figures
Figure 1: U-space nodes related to the Traffic/Telemetry service........................................................ 22
Figure 2: Traffic/Telemetry Interface Definition diagram ..................................................................... 25
Figure 3: Data Model diagram of the Traffic/Telemetry Service .......................................................... 26
Figure 4: Common Data Types Used in UTM Service Specifications ..................................................... 42
Figure 5: Common Geometry Data Types Used in UTM Service Specifications .................................... 43
Figure 6: Traffic/Telemetry Service interface operation sequence diagram ........................................ 49
8
1 Abstract
Exchange Service.
Specifically, this document describes, in a logical, technology-independent manner, the

Traffic/Telemetry service, a Position report Submission Sub-Service and Surveillance Data Service
which accepts and carries surveillance data from a number of data sources to a Tracking Service
which, in turn, provides a common situational picture to its consumers via this service.
Sources include, but are not limited to, primary and secondary radar and other drone detection
services, on-board position telemetry services, and tracking service,
Consumers include, but are not limited to monitoring and traffic information services, tracking
services, and display systems.
9
2 Introduction
Based on the guidelines given in [3], this document describes the Traffic/Telemetry bridge service of
a Common Information Service (CIS) in a logical technology-independent manner, that is:
 the operational and business context of the service

o requirements for the service (e.g., information exchange requirements)
o involved nodes: which operational components provide/consume the service
o operational activities supported by the service
o relation of the service to other services
 the service description
o service interface definitions
o service interface operations
o service payload definition
o service dynamic behaviour description
 service provision and validation aspects
Furthermore, this document clearly defines the version of the service.
2.2 Scope
This document describes the Traffic/Telemetry service for a CIS.
The Traffic/Telemetry service provides a means for the operational nodes of the U-space to share
their position reports and make them available for further processing.
The Traffic/Telemetry service furthermore provides a means for the operational nodes of the U-
space to consume position reports from the U-space participants for further processing.

This service specification is intended to be read by service architects, system engineers and
developers in charge of designing and developing an instance of the Traffic/Telemetry service.
Furthermore, this service specification is intended to be read by enterprise architects, service

architects, information architects, system engineers and developers in pursuing architecting, design
and development activities of other related services.
2.4 Background
2.4.1 EUROCONTROL Concept of Operations for U-space (CORUS)
10
EUROCONTROL CORUS [4] Vol. 2 elaborates in 5.1.1.4 Position reporting submission sub-Service as
follows.
“The Tracking service of U-space (section 5.1.1.5) 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.
[…]
Position report submission will need to be secure, reliable and low latency. The information in
Position Reports is safety critical. The Position report submission sub-service must be deployed in a
robust and reliable manner because of its safety criticality.
[…]
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.
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 5.1.5.2). Hence the Position report submission service will feed the Legal
Recording service (section 5.1.6.3).
The Position Reports sent to U-space should include
All drone position reports should be recorded to allow the provision of the Accident and Incident
investigation (section 5.1.5.2). Hence the Position report submission service will feed the Legal
Recording service (section 5.1.6.3).
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
 The identity of the vehicle, if available, preferably in the form used by Remote
Identification see 3.1.4.1
 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 tracker. “
2.4.2 Global UTM Association (GUTMA) and GUTMA-related
2.4.2.1 Flight Logging Protocol
The Flight Logging Protocol [5], section flight_logging suggests some data items as follows.
“For the moment, mandatory fields are timestamp, gps_lon, gps_lat, gps_altitude. speed and
battery_voltage are also taken into account, but they are optional. Many types can be added, it
will simply not be analysed, just stored.
 Timestamp : number of the seconds elapsed since logging_start_dtg. It is a float, with max
3 decimals (so precision is milliseconds). By extension, the last timestamp will be equal to
the duration flight in seconds.
 gps_lon, gps_lat, gps_altitude: GPS coordinates
 speed: ground speed in m/s (float)
 battery_voltage: voltage in volt (float)
 logging_start_dtg: describes the beginning of the flight. It is mandatory.
 altitude_system: indicates the type of altitude reported: "AGL", "MSL" or "WGS84".
Event is used for notify events during the flight. It can be take off, gps lost, obstacle detection etc.”
2.4.2.2 Air Traffic Protocol
The Air Traffic Protocol has received several suggestions for extension [6]. From the Objective and
Data Sources sections:
“Therefore the core objective of this reporting standard is the following:
 Identify aircraft with high certainty

 Minimize Latency, reduce bandwidth
 Ensure quality and integrity of the data
 Ability to merge different data sources into a single feed.
(…)
The following data sources are considered in scope for the purposes of this data feed:
 Aircraft equipped with sensors that detect and produce data (e.g. ADS-B / Mode S /
Primary Radar / Mode AC / FLARM / UAT)
 Sensors from private companies / 1st level sensors detecting emitted data (e.g. OEM /
Radar manufacturers / Sensor manufacturers)
12
 UAS / Aircraft itself: In the future all drones will detect neighbouring aircraft and share it
(Traffic information service - broadcast (TIS-B) collects information and broadcasts it to any
aircraft in the region)”
2.4.3 Federal Aviation Administration (FAA) Concepts of Operations
The FAA defines a messaging service in its Concepts of Operations v1.0 - Appendix C - UTM Services
- Messaging Service [7] as follows.
“A service which provides on demand, periodic, or event driven information on UAS operations
(e.g. position reports, intent information, and status information) occurring within the subscribed
airspace volume and time. Additional filtering may be performed as part of the service.”
2.4.4 Swiss Federal Office of Civil Aviation (FOCA)
From the FOCA Concepts of Operations v1.0 [8], section 3.5.10 - Tracking Service:
“A service, which tracks position reports of the UAVs in order for other services to operate
(deconfliction,flight planning and so on). It fulfils following functions:
 To track UA positions in real-time

 To securely store tracked data
 To provide different access levels to users with different credentials for the tracking data
The services will gather positions of the UAS and ensure privacy of its users and their activity. It will
benefit the users by allowing the services and the competent authorities to access data while
ensuring privacy and data protection of the participants.”
2.4.5 International Civil Aviation Organization (ICAO)
In the Global Air Navigation Plan [9], ICAO defines three Aviation System Block Upgrade (ASBU)
blocks, B1-RPAS, B2-RPAS, and B3-RPAS, referring to scheduled implementation years of 2019, 2025,
2031, and beyond, and expects increased situational awareness from B1-RPAS onwards.
ICAO Doc 10039 [2] elaborates in section 3.4 INFORMATION EXCHANGE SERVICES on information
exchange services as follow (para. 3.4.2).
“Within the SWIM Global Interoperability Framework, the Information Exchange layer is
instantiated by ‘information services’ as is further explained. Information services ensure
interoperability between ATM applications which consume and provide interoperable information
services. Consequently, the concept of information service is a fundamental building block of SWIM
which enables interoperability through well-defined information exchanges.”
2.4.6 Open Drone ID
13
Open Drone ID is a project to provide a low cost and reliable “beacon” capability for drones so that
they can be identified when within range of a receiver. Open Drone ID receives support from large
companies such as Intel.
The Open Drone ID Message Specification [10] proposes a Location Message in both, a byte and a
JSON representation, which permits the transport of
 a position in three space dimensions,

 a velocity, and
 a data age.
The Open Drone ID Message Specification furthermore proposes messages to convey information
about
 the type of drone,

 its in-flight status, and
 the location of the drone operator.
2.4.7 SESAR-JU
The European Commission identifies an increasing demand for a non-segregated use of airspace
which is being driven by a rapidly growing market of Very-Low-Level (VLL) airspace users, most of
which are expected to be drones.
Via the Roadmap for the safe integration of drones into all classes of airspace [11], within the
European ATM Masterplan [12], the European Commission seeks to ensure that this rapid growth of
airspace use happens in a safe and controlled manner.
SESAR develops the required concepts and demonstrations for this process to happen. The roadmap
[1], in alignment with ICAO recommendations, identifies three phases for the integration, from which
SESAR derives the four U-space service blocks presented in the U-space blueprint [13],
U1 U-space foundation services,

U2 U-space initial services,
U3 U-space advanced services, and
U4 U-space full services.
These stages reflect the anticipated quick growth of demand for U-space services. The state of the
art is being validated throughout Europe via several Very Large Demonstrator (VLD) projects such as
the GOF USPACE project.
During the U1 phases, SESAR expects drones capable to supply their position via telemetry. The U1
and U2 is anticipated to provide tracking capabilities and services.
2.4.8 Efficient, safe and sustainable traffic at sea (EfficienSea2)
The design method and terminology builds on experience from the EfficienSea2 project [14], [15].
14
2.4.9 ASTM
F3411 - 22a, Standard Specification for Remote ID and Tracking provides a specification on performance
requirements for remote identification for unmanned systems. It defines message formats, transmission
methods and minimum performance standards for broadcast and network-based remote ID.
Especially, network-based remote ID, as described in F3411 - 22a can be considered a valid
implementation of this service specification.

Term Definition
A report from an aircraft in flight prepared in conformity with requirements for position,
AIR-REPORT
and operational and/or meteorological reporting.
Describes the semantics of the domain (or a significant part thereof) by defining data
External Data
structures and their relations. This could be at logical level (e.g., in UML) or at physical
Model
level (e.g., in XSD schema definitions), as for example standard data models.
Describes the principles how two different parts of a message passing system (in our
case: the service provider and the service consumer) interact and communicate with
each other. Examples:
In the Request/Response MEP, the service consumer sends a request to the service
Message Exchange provider in order to obtain certain information; the service provider provides the
Pattern requested information in a dedicated response.
In the Publish/Subscribe MEP, the service consumer establishes a subscription with the
service provider in order to obtain certain information; the service provider publishes
information (either in regular intervals or upon change) to all subscribed service
consumers.
Operational An activity performed by an operational node. Examples of operational activities are:

Activity Route Planning, Route Optimization, Logistics, Safety, Weather Forecast Provision, …
Operational A structure of operational nodes and associated operational activities and their inter-
Model relations in a process model.
A logical entity that performs activities. Note: nodes are specified independently of any
physical realisation.
Operational Node
Examples of operational nodes are: Control Center, Authority, Weather Information
Provider, …
The provision of something (a non-physical object), by one, for the use of one or more
others, regulated by formal definitions and mutual agreements. Services involve
Service interactions between providers and consumers, which may be performed in a digital
form (data exchanges) or through voice communication or written processes and
procedures.
15
Service Consumer A service consumer uses service instances provided by service providers.
Formal description of one dedicated service at logical level. The service data model is
part of the service specification. Is typically defined in UML and/or XSD. If an external
Service Data
data model exists (e.g., a standard data model), then the service data model shall refer
Model
to it: each data item of the service data model shall be mapped to a data item defined in
the external data model.
Documents the details of a service technical design (most likely documented by the
Service Design service implementer). The service design description includes (but is not limited to) a
Description service physical data model and describes the used technology, transport mechanism,
quality of service, etc.
Service The provider side implementation of a dedicated service technical design (i.e.,
Implementation implementation of a dedicated service in a dedicated technology).
Service Implementers of services from the service provider side and/or the service consumer
Implementer side.
One service implementation may be deployed at several places by same or different

Service Instance service providers; each such deployment represents a different service instance, being
accessible via different URLs.
Documents the details of a service implementation (most likely documented by the

service implementer) and deployment (most likely documented by the service provider).
Service Instance
The service instance description includes (but is not limited to) service technical design
Description
reference, service provider reference, service access information, service coverage
information, etc.
The communication mechanism of the service, i.e., interaction mechanism between

service provider and service consumer. A service interface is characterised by a message
Service Interface
exchange pattern and consists of service operations that are either allocated to the
provider or the consumer of the service.
Functions or procedure which enables programmatic communication with a service via

Service Operation
a service interface.
Describes the realisation of a dedicated service data model in a dedicated technology.

This includes a detailed description of the data payload to be exchanged using the
chosen technology. The actual format of the service physical data model depends on
the chosen technology. Examples may be WSDL and XSD files (e.g., for SOAP services) or
swagger (Open API) specifications (e.g., for REST services). If an external data model
exists (e.g., a standard data model), then the service physical data model shall refer to
it: each data item of the service physical data model shall be mapped to a data item
Service Physical
defined in the external data model.
Data Model
In order to prove correct implementation of the service specification, there shall exist a
mapping between the service physical data model and the service data model. This
means, each data item used in the service physical data model shall be mapped to a
corresponding data item of the service data model. (In case of existing mappings to a
common external (standard) data model from both the service data model and the
service physical data model, such a mapping is implicitly given.)
A service provider provides instances of services according to a service specification and

Service Provider service instance description. All users within the domain can be service providers, e.g.,
authorities, organizations (e.g., meteorological), commercial service providers, etc.
16
Describes one dedicated service at logical level. The Service Specification is technology-
Service agnostic. The Service Specification includes (but is not limited to) a description of the
Specification Service Interfaces and Service Operations with their data payload. The data payload
description may be formally defined by a Service Data Model.
Service
Producers of service specifications in accordance with the service documentation
Specification
guidelines.
Producer
The technical design of a dedicated service in a dedicated technology. One service

Service Technical
specification may result in several technical service designs, realising the service with
Design
different or same technologies.
List and specifications of allowed technologies for service implementations. Currently,

Service
SOAP and REST are envisaged to be allowed service technologies. The service
Technology
technology catalogue shall describe in detail the allowed service profiles, e.g., by listing
Catalogue
communication standards, security standards, stacks, bindings, etc.
A service specification is characterised as “spatially exclusive”, if in any geographical

region just one service instance of that specification is allowed to be registered per
Spatial technology.
Exclusiveness
The decision, which service instance (out of a number of available spatially exclusive
services) shall be registered for a certain geographical region, is a governance issue.

Acronym Definition
API Application Programming Interface
CIS Common Information Services
MEP Message Exchange Pattern
NAF NATO Architectural Framework
REST Representational State Transfer
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
SSD Service Specification Document
UML Unified Modelling Language
URL Uniform Resource Locator
WSDL Web Service Definition Language
XML Extendible Mark-up Language
XSD XML Schema Definition

17
3 Service Identification
The purpose of this chapter is to provide a unique identification of the service and describe
where the service is in terms of the engineering lifecycle.
Name Traffic Telemetry Service
ID urn:frequentis:services:TrafficTelemetryService
Version 2.0.2
Description A service which provides position reports of objects such as aircraft (manned and unmanned),
Position report Submission Sub-Service, Surveillance Data Service, U-space Tracking, UAV
Keywords
Orientation, Speed
2020-today The Frequentis Group

Architect(s)
2018-2020 The GOF U-Space Project Consortium
Status Provisional
Table 3: Service Identification
18
4 Operational Context
This section describes the context of the service from an operational perspective.
4.1 Functional and Non-functional Requirements

The table below lists applicable existing requirements for the Traffic/Telemetry service.
Requirement Requirement
Requirement Text References
Id Name
At all times, all U-space participants shall CORUS [4], 3.1.1.2 Z

Common
operate on the same common set of data, Volumes; B1-RPAS [9];CEF-
[R-1] Situational
during pre-flight planning stages as well as SESAR-2018-1 [1],
Awareness
during all stages of flight operations. Objective O5
SESAR Drone Roadmap

[11], Foreword, 4.1 and
The U-space concept shall be designed such as
4.2;U-space Blueprint [13],
Basis for Open to ensure a well-established line of authority
[R-2] Benefits to European
Market while at the same time ensuring that an open
society and economy; CEF-
market for VLL services may develop
SESAR-2018-1 [1], Table 8
– Key Challenges
ICAO Doc 10039 [2];[R-

2];CEF-SESAR-2018-1 [1],
There shall be an implementation of a Flight Objective O6; CEF-SESAR-
Information Management System (FIMS) 2018-1 [1], Table 8 – Key
which ensures that, at all times, emerging Challenges
unmanned traffic management systems and
existing technologies from manned operations Note: The term 'Flight
[R-3] Interoperability
can exchange any data required to support Information Management
such common situational awareness, be it for System (FIMS)' has been
drone operations in areas where established since replaced by
ATC procedures apply, or in zones outside 'Common Information
established ATC. Services (CIS)'. This text
hence refers to CIS, rather
than FIMS.
Standard communication protocols shall

[R-2];SESAR Drone
hence be used where available, and such
Roadmap [11], 3.5, section
Standard standard protocols be developed otherwise, in
[R-4] ‘Standards’;C EF-SESAR-
Protocols order to ensure the lowest level of
2018-1 [1], Table 8 – Key
obstruction for an open VLL airspace use
Challenges
market to develop.
Any interface and protocol hence must be

openly defined and its definition be freely [R-2];CEF-SESAR-2018-1
[R-5] Open Interfaces accessible in order to ensure the lowest level [1], Table 8 – Key
of obstruction for an open VLL airspace use Challenges
market to develop.
19
[R-3];CEF-SESAR-2018-1
[1], 5.3.4 Overall approach
and methodology
Note: The term 'Flight

The implementation of a Flight Information
Information Management
[R-6] SWIM Management System (FIMS) shall be based on
System (FIMS)' has been
an ICAO SWIM-compliant architecture.
since replaced by
'Common Information
Services (CIS)'. This text
hence refers to CIS, rather
than FIMS.
Under no operational circumstance, the

processing of position data may add
significant latency to the overall detection-to-
display latency of position data. In particular,
The processing latency added by the

processing of positional data shall never
exceed 10 per cent of the maximum value of
the corresponding value permitted for the
entire ATM automation system.
[17], tables in the
[R-7] Latency The processing latency and delay added by Executive Summary, [16],
the processing of positional data should not 3N_C-R8 and 5N_C-R8
exceed 1 per cent of the maximum value of
the corresponding value permitted for the
entire ATM automation system.
The maximum value for latency and delay is

the minimum of the values defined by the
ATM system performance requirements by
EUROCONTOL and the FAA; for a 3 NM
minimal separation, this is 2.2 s, for a 5 NM
separation, 2.5 s.
Table 4: Requirements for the Traffic/Telemetry Service
4.2 Other Constraints

4.2.1 Relevant Industrial Standards
4.2.1.1 ICAO SWIM
The System Wide Information Management (SWIM, [2]) complements human-to-human with
machine-to-machine communication, and improves data distribution and accessibility in terms of
quality of the data exchanged. The SWIM Concept addresses the challenge of creating an
“interoperability environment” which allows the SWIM IT systems to cope with the full complexity of
operational information exchanges. The SWIM environment shifts the ATM information architecture
paradigm from point-to-point data exchanges to system-wide interoperability.
20
4.2.1.2 EUROCONTROL ASTERIX
The All-purpose structured EUROCONTROL surveillance information exchange (ASTERIX) [18] is a set
of documents defining the low level (“down to the bit”) implementation of a data format used for
exchanging surveillance-related information and other ATM applications.
EUROCONTROL-SPEC-0149-9 - EUROCONTROL Specification for Surveillance Data Exchange ASTERIX

Part 9 Category 062 SDPS Track Messages

Part 12 Category 21 ADS-B Target Reports

Part 14 Category 20 Multilateration Target Reports

Part 17 Category 004 Safety Net Messages
EUROCONTROL-SPEC-0149-28 - EUROCONTROLSpecification for Surveillance Data Exchange –

ASTERIX Part 28 - Category 015: INCS System Target Reports
EUROCONTROL-SPEC-0149-29 - EUROCONTROL Specification for Surveillance Data Exchange –

ASTERIX Part 29 - Category 129: UAS Identification Reports

ASTERIX Part 30 - Category 016: Independent Non-Cooperative Surveillance System Configuration
Reports
EUROCONTROL-SPEC-0149-31 - EUROCONTROLSpecification for Surveillance Data Exchange –

ASTERIX Part 31 - Category 205: Radio Direction Finder Reports
4.2.1.3 EUROCONTROL ATM Automation System Environment Performance

Requirements
Eurocontrol defines clear operational requirements and an elaborated assessment methodology for
European surveillance in its Specification for ATM Surveillance System Performance [16]. For
instance, for a separation of 3 nautical miles:
Req. # Quality of service Mandatory performance
3N_C- Forwarded pressure altitude average data age (see Note 7 in § Less than or equal to 2.5
R8 3.4.5) seconds
Table 5: Excerpt from EUROCONTROL Specification for ATM Surveillance System Performance [16]
Further requirements for update rates and error margins apply.
21
4.2.1.4 FAA ATM Automation System Environment Performance Requirements
In a similar fashion, the Federal Aviation Administration concludes that the time from the
determination of a position (measurement) to display (latency of the ATM system) shall not exceed
similar values [17]:
Latency 2.2 seconds to display maximum
The FAA also applies further requirements for update rates and error margins.
4.2.2 Operational Nodes
A typical U-space flight goes through several stages, starting strategic-tactically, pre-flight, from
Strategic Planning, over to Pre-Tactical Planning, to Tactical Planning. Then, tactical-operationally it
enters into the actual in-flight stages from Departure, over to In-Flight, and, finally Arrival. Further
post-flight stages may evaluate the results from the data produced during the prior stages.
The Traffic/Telemetry service primarily is relevant during the actual operational in-flight stages of a
U-space flight during which the flying device and/or the corresponding ground stations produce the
position data which we convey via the Traffic/Telemetry service.
There are several nodes in U-space which could provide position information to the Traffic/Telemetry
service.
 An actual aircraft (manned or unmanned), that provides position data to a ground station
 A ground station, relaying or providing position data to a Central Information Service (CIS)
 A CIS to consolidate for consuming applications and services
Figure 1: U-space nodes related to the Traffic/Telemetry service
Though a simple view on data provided by a Traffic/Telemetry service already could be used for
some applications, typically consuming services and applications will utilize the service together with
other services like
 Flight Planning Services - to retrieve more information about a flight associated with the
position report
22
 Registration Services - for background on e.g. operator, pilot and flown device
 Geofencing Services – to draw a user’s attention to a potential area conflict and to act
accordingly, possibly even automatically
Consuming services and applications include the following services and applications.
 Tactical Deconfliction Service

 Tracking Service
 Traffic Alerting Service
 Displays for Situational Overview
 Accident and Incident Reporting Services
 Traffic Monitoring Services
 Traffic Information Services
 Legal Recording Service
Operational nodes which may provide data for the Traffic/Telemetry service include the following
ones.
Operational Node Remarks
Aircraft Manned, unmanned, and/or autonomous
Ground Station Professional or recreational alike
UTM Service Provider
Common Information Service

Table 6: Operational Nodes providing the Traffic/Telemetry service
Operational nodes which may consume the Traffic/Telemetry service include the following ones.
Information Display
Telemetry Converter
Legal Recorder
Table 7: Operational Nodes consuming the Traffic/Telemetry service
4.2.3 Operational Activities
Operational activities supported by the Traffic/Telemetry service include the following ones.
Phase Operational Activity Remarks
Pre-flight Set-up (Telemetry likely not operational yet at this stage)
Plan (Telemetry likely not operational yet at this stage)
23
Arm (Traffic/telemetry should start to run here)
In-Flight Depart Traffic/Telemetry data operational for the flight
Cruise Traffic/Telemetry data operational for the flight
Arrive Traffic/Telemetry data operational for the flight
Post-Flight Disarm (Traffic/telemetry likely stops here)
Report (Post/flight analysis only)

Table 8: Operational Activities supported by the Traffic/Telemetry service
24
5 Service Overview
5.1 Service Interfaces
Figure 2: Traffic/Telemetry Interface Definition diagram
Role (from service provider point of

ServiceInterface ServiceOperation
view)
subscribeTrafficTelemetry
TrafficTelemetrySubscriptionInterface Provided
unsubscribeTrafficTelemetry
notifyPositionReport
TrafficTelemetryNotificationInterface Required
notifyFlightEvent
Table 9: Service Interfaces
25
6 Service Data Model

This section describes the information model, i.e., the logical data structures to be exchanged
between providers and consumers of the service.
6.1 Overview
The Traffic/Telemetry service transfers positional data as PositionReports, aggregating Position and
Altitude data, derived from the aggregated Pose structure which may carry Velocity,
Orientation, ObjectIdentification, and an ObjectPriority. Optionally (if supported by the service
provider), also ObjectClassificationInfo may be included.
The provision of the Position and at least one Altitude data item is mandatory.
There should be at least one ObjectIdentifiation data item in each Pose. Data sources should report
as many ObjectIdentification and ObjectClassificationInfo data items as they have data available.
Figure 3: Data Model diagram of the Traffic/Telemetry Service
6.2 The Pose Data Structure
26
Pose is a composite of Velocity, Orientation, Object Identification, and Object Priority. This structure
builds the base for dedicated Report structures (e.g., the PositionReport). Depending on a service
provider's capabilities, only the core attributes of Pose and a (possibly empty) subset of its
composing elements may be available on the service interface.
Multiplicit
Property Type Description Note
y
The UUI should be

generated by as
A uuid, globally close as possible
reportId UUID 1 unique to identify the to the data
position record originator (e.g.
airborne, or by the
operator).
The id of the
operation, e. g. a
flight_id i. e. a gufi, More information
globally unique for an operation
identifier referencing may be retrieved
operationId UUID 0..1 the flight producing using a respective
this position report. Common
Information
If no operation plan is Service
known, this element is
missing.
UTC point in time

when the position was Expressed in UTC
acquisitionDatetime DateTime 1 measured by the using the ISO 8601
positioning unit of the date time format
device in operation
Accuracy of
acquisitionDatetimeAccura
Real 1 acquisition time
cy
measurement in ms
Two Pose records

could be sent from
the same aircraft –
they would be
Indicates the origin of
identified by a
this position
different origin.
record. Can be, e.g., a
origin string 1 Depending on
sensor identification,
bandwidth
or a tracker
considerations all
identification.
available sensors
should be utiziled
and transmit Pose
records.
27
If provided, carries the

Position and Altitude
of the Ground Control
Station being in
gcsPosition PositionReport 0..1
control of the drone
that is being reported
about by this Pose
data structure.

velocity of the object
There may be
being reported about
none or one
in this Pose.
Velocity data
structure provided
velocity Velocity 0..1 There may be none or
for every Pose,
one Velocity data
providing all, or a
structure provided for
subset, of the data
every Pose, providing
it may carry.
all, or a subset, of the
data it may carry.

orientation data of
the object being There may be
reported about in this none or one
Pose. Orientation data
structure provided
orientation Orientation 0..1
There may be none or for every Pose,
one Orientation data providing all, or a
structure provided for subset, of the data
every Pose, providing it may carry.
all, or a subset, of the
data it may carry.
28
If provided,
carries data to assist
in identifying the
object we report
about in this Pose. It
can be a vehicle
registration identifier
or any other
appropriate identifier.
There shall be none,

one or more complete
ObjectIdentification
data structure(s)
Data sources
provided for every
should report as
Pose, providing the
many
means of
ObjectIdentificati
identification of the
on data items as
target.
they have data
identifications ObjectIdentification 0..* available.
The first of
the ObjectIdentificati
There should be at
on data structures
least one
provided shall contain
ObjectIdentifiatio
the value which
n data item in
subsequent
each Pose.
processing stages may
rely on as accurate
and binding.
Per default, this first

ObjectIdentification
data structure should
contain the officially
registered unique ID
as assigned by the
registering authority
of the country of
registration of the
vehicle.
If provided, carries
data indicating the
priority level of the
object being reported
about in this Pose.
priority ObjectPriority 0..1
There shall be none,
or one, ObjectPriority
data structure
provided for every
Pose.
29
Optional information
about the
ObjectClassificationIn
classificationInfo 0..1 classification of the
fo
object being reported
about.
Table 10: The Pose data structure
6.3 The Velocity Data Structure

The Velocity data structure may carry the velocity of the object being reported about. Velocity is
represented as vector; it includes information on bearing and inclination.
Property Type Multiplicity Description Note
Velocity in latitudinal direction in unit of

measurement defined in unit of
latitude Real 0..1
measurement as defined by
Position.positionCrs.
Velocity in logitudinal direction in unit of

longitude Real 0..1
measurement as defined
by Position.positionCrs.
Velocity in vertical direction in unit of

altitude Real 0..1
Altitude.altitudeCrs.
Accuracy of horizontal velocity in unit of

horizontalAccuracy Real 0..1 measurement defined
by Position.positionCrs.
Accuracy of vertical velocity in unit of

verticalAccuracy Real 0..1
measurement defined in Altitude.altitudeCrs.
Optional information about the change rate

changeRate VelocityChangeRate 0..1
of the velocity (i.e., the acceleration).
Table 11: The Velocity data structure
6.4 The VelocityChangeRate Data Structure

The VelocityChangeRate data structure describes the speed change rate (acceleration) of the object
being reported about.
Change rate of the latitudinal velocity per time unit in unit of

latChangeRate Real 0..1
measurement as defined by Position.positionCrs.
Change rate of the longitudinal velocity per time unit in unit of

lonChangeRate Real 0..1
measurement as defined by Position.positionCrs.
30
Change rate of the vertical velocity per time unit in unit of

altChangeRate Real 0..1
measurement as defined by Altitude.altitudeCrs.
Table 12: The VelocityChangeRate data structure
6.5 The Orientation Data Structure

The Orientation data structure may carry the orientation data of the object being reported about.
Transverse axis in unit

of measurement as
pitch Real 0..1
defined by
orientationCrs
Longitudinal axis in unit

of measurement as
roll Real 0..1
defined by
orientationCrs
Vertical axis in unit of

measurement as
yaw Real 0..1
defined by
orientationCrs
Measured or
orientationType OrientationType 1
calculcated
Enum values: S-UTM

Coordinate reference
Services Common
orientationCrs EnumCRSType 1 system used (e. g., for
Data Model - Basic
WGS-84, EPSG:4979)
Geometry Data Types
Accuracy of orientation
in unit of measurement
orientationAccuracy Real 0..1
defined in
orientationCrs
Optional information
changeRate OrientationChangeRate 0..1 about the change rate
of the Orientation.
Table 13: The Orientation data structure
6.6 The OrientationChangeRate Data Structure

The OrientationChangeRate data structure describes the rate of change of the orientation of the
object being reported about.
Change rate of the movement around the transversal axis per time
pitchRate Real 0..1
unit in unit of measurement as defined by Orientation.orientationCrs.
31
Change rate of the movement around the longitudinal axis per time
rollRate Real 0..1
unit in unit of measurement as defined by Orientation.orientationCrs.
Change rate of the movement around the vertical axis per time unit in
yawRate Real 0..1
unit of measurement as defined by Orientation.orientationCrs.
Table 14: The OrientationChangeRate data structure
6.7 The ObjectIdentification Data Structure

The ObjectIdentification data structure may carry data to assist in identifying the object we report
about in this report. It can be a vehicle registration identifier or any other identifier as listed in the
IdentificationType property. Data sources should report all ObjectIdentification data items they have
data about.
The actual value of the identification of the

value String 1
object this report applies to, of type type.
Type of identification conveyed by this

type EnumObjectIdentificationType 1 ObjectIdentification item, as defined by
the EnumObjectIdentificationType.
Optional empty item for temporary use

until standardization is in place: Unless
type is set to “ID_OTHER”, do not set this
field at all; however, if type is set to
“ID_OTHER”, set this field to a descriptive
string for the type and set value to the
other String 0..1
corresponding value.
NOTE: Use of this field is discouraged at

any time and permitted for local bilateral
temporary deviation of standard only until
updated standardization is in place.
Optional item with a range from 0 to 100

representing the degree of confidence the
emitter of this information has that the
confidence Integer 0..1
object we report about in this report
actually can be identified by this particular
value.
Table 15: ObjectIdentification data structure
6.8 The EnumObjectIdentificationType Enumeration

The EnumObjectIdentificationType enumeration type specifies possible ways to identify an object.
32
Property Description Note
ID_ICAO indicating an ICAO 24 bit address
ID_CALLSIGN indicating a call sign as per [ICAO-DOC-4444]
ID_ETHER indicating an Ethernet address
ID_PRIMARY primary surveillance
ID_MODE_3A secondary surveillance, 2D only, squawk
ID_MODE_3AC secondary surveillance, 3D, squawk
ID_MODE_S secondary surveillance, ICAO 24 bit address
ID_COMBINED ombined primary/secondary surveillance
ID_MODE_SES dependent surveillance, ICAO 24 bit address
ID_VDL dependent surveillance, ICAO 24 bit address
ID_UAT dependent surveillance, ICAO 24 bit address
ID_MLAT secondary surveillance, ICAO 24 bit address
ID_TRACK combined surveillance, numeric track id
ID_TRACKID combined surveillance, track uuid
ID_ALERT surveillance, numeric alert id
ID_ALERTID surveillance, alert uuid
ID_ADSC dependent surveillance, ICAO 24 bit address
ID_FPL dependent surveillance, squawk or no id, FPL number
ID_GUFI operation-id, i. e. the uuid of the operation
ID_FLARM dependent surveillance, FLARM-ID
ID_IMEI dependent surveillance, IMEI number
ID_IMSI dependent surveillance, IMSI number
ID_MMSI dependent surveillance, MMSI number
dependent surveillance, serial number of the vehicle as assigned by its

ID_SERIAL
manufacturer
ID_MAKER dependent surveillance, three letters identifying the manufacturer of the vehicle
dependent surveillance, three letters identifying the model of the manufacturer of

ID_MODEL
the vehicle
dependent surveillance, ISO 3166-1 Alpha 2 code of the country of registration of

ID_COUNTRY
the vehicle
ID_REGMARK indicating a registration marking (e. g. [ICAO-ANN-10-IV], [ICAO-ANN-7])
ID_REGID indicating a registration (e. g. uuid) from the national (aircraft or drone) registry
33
ID_OTHER discouraged
Table 16: EnumObjectIdentificationType enumeration
6.9 The ObjectPriority Data Structure

The ObjectPriority data structure may carry information about the status of the object and the
priority it requires or requires/requests.
The status of the object this ObjectPriority item reports

about, one of:
NORMAL Generic normal state of operations
FOLLOWME Normal state of operations, specifically

operating as follow-me or marshal
RUNWAYCHECK Normal state of operations, specifically

checking runway or taxiway
TOWING Normal state of operations, specifically

towing vehicle, ship or aircraft
WIP Normal state of operations, work in

priority String 1
progress such as maintenance or sweeping
TROUBLE Generic state of out-of-order operation

such as technical failure
SAFETY Out-of-order state with safety impact to

others (securité)
URGENCY Out-of-order state with immediate

impact on the safety of the object or to human safety or
health, or foreseeable distress
DISTRESS Out-of-order state with immediate

danger to human life, on-board, or immediately related to
the object
34
The privilege the object which this ObjectPriority item

reports about requests or requires, one of:
NORMAL No privilege required nor requested
LAW Elevated privileges for law enforcement

privilege String 1
EMERGENCY Elevated privileges to avoid danger of
life
STATE Elevated privileges for matters of

national security or other public safety, including military
operations and diplomatic operations
priorityInformation String 0..1 Optional item which may hold additional information
Table 17: The ObjectPriority data structure
6.10The PositionReport Data Structure

The PositionReport data structure provides the actual position data, and one or more altitudes of the
object being reported about. Furthermore, it inherits all properties of the Pose data structure.
There shall be one

Carries the position data of the object
complete Position data
position Position 1 being reported about in this
structure provided for
PositionReport.
every PositionReport.
Carries the altitude data of the object

being reported about with this
PositionReport.
There shall be at least
There shall be one or more complete one complete Altitude
altitudes Altitude 1..*
Altitude data structure provided for every data structure provided
PositionReport. The first of the Altitude for every PositionReport.
data structures provided shall contain the
value which subsequent processing stages
may rely on as accurate and binding.
all attributes
inhertited See Pose Data Structure
from Pose
Table 18: The PositionReport data structure
6.11The Position Data Structure

The Position data structure carries the position data of the object being reported about.
35
Most commonly used CRSs

Latitude of position record in use degrees as the UoM
latitude Real 1 unit of measurement as for the latitude; however,
defined by positionCrs meters are used for
Mercator projections.
Most commonly used CRSs

Longitude of position record in use degrees as the UoM
longitude Real 1 unit of measurement as for the longitude;
defined by positionCrs however, meters are used
for Mercator projections.
The positionAccuracy
value is mandatory and
must be provided in any
circumstance. It is the
responsibility of the data
Accuracy of latitude and
provider to include an
longitude as the maximum
accuracy value into the
deviation in the unit of
position report.
positionCrs. This means, for
In cases, where the
positionAccuracy Real 1 example, a value of
accuracy value is not
positionAccuracy=x indicates
explicitly given by the data
that the real latitude reported
source, the accuracy has
in this position report is
to be included according
expected to be in the range of
to the best knowledge,
[latitude-x, latitude+x].
taking into account the
documented sensor
accuracy and the
methodology of obtaining
the value.
Enum values: S-UTM

Coordinate reference system
Services Common Data
positionCrs EnumCRSType 1 used (e. g., for WGS-84,
Model - Basic Geometry
EPSG:4979)
Data Types
This attribute shall be

provided, if the Position is
used in a reporting service
Elapsed time in s since last
(e.g., in a PositionReport);
positionDataAge Real 0..1 position data received by the
in other cases this
reporter of this Position
attribute may be omitted
(e.g., in conversion
operations).
Table 19: The Position data structure
6.12The Altitude Data Structure

The Altitude data structure carries the altitude data of the object being reported about.
36
All currently
supported
Altitude of position
Coordinate
record in unit of
Reference
altitude Real 1 measurement as
Systems use
defined by
meters as unit of
altitudeCrs.
measurement
for the altitude.
37
The
altitudeAccuracy
value is
mandatory and
must be
provided in any
circumstance. It
is the
responsibility of
the data
provider to
include an
accuracy value
into the position
report.
In cases, where
Spedifies the the accuracy
accuracy of altitude value is not
as the maximum explicitly given
deviation in the by the data
unit of source, the
measurement as accuracy has to
defined by be included
altitudeCrs. This according to the
means, for best knowledge,
altitudeAccuracy Real 1 example, a value of taking into
altitudeAccuracy=x account the
indicates that the documented
real altitude sensor accuracy
reported in this and the
position report is methodology of
expected to be in obtaining the
the range of value.
[altitude-x,
altitude+x]. For example, in
case of
barometric
altitude
determination,
the accuracy
heavily depends
on the current
air pressure at
the time of
measurement. If
the data
provider is in the
possession of up
to date pressure
data, the
resulting
accuracy will be
38
higher; if no up
to date pressure
data is available,
the data
provider shall
still add a worst
case
altitudeAccuracy
value taking the
worst case
pressure
deviations into
account.
indicates the
reference point for
altitude
measurement, e. g.:
altitude above
mean-sea-level
(MSL)
altitudeType EnumAltitudeType 1 altitude above take-

off location (ATO)
altitude above
ground (AGL/SFC)
altitude above
the WGS-
84 ellipsoid; value
delivered by GPS.
Method of
determination of
altitude, e. g.:
radio-altimeter
determinationMethod AltitudeDeterminationMethod 1 barometric
GNSS-based
calculated against
reference point and
mean-sea-level
39
Enum values: S-
Coordinate
UTM Services
reference system
Common Data
altitudeCrs EnumCRSType 1 used (e. g., for
Model - Basic
WGS-84,
Geometry Data
EPSG:4979)
Types
This attribute
shall be
provided, if the
Altitude is used
Elapsed time in s in a reporting
since last position service (e.g., in a
altitudeDataAge Real 0..1 data received by PositionReport);
the reporter of this in other cases
Altitude this attribute
may be omitted
(e.g., in
conversion
operations).
This information
If provided, shall be added to
contains Position the Altitude
and Altitude of the structure in case
startPosition PositionReport 0..1
starting point, that the
where this drone altitudeType is
flight has departed. set to
ABOVE_TO.
Table 20: The Altitude data structure
6.13The EnumAltitudeType Enumeration

The EnumAltitudeType enumeration type specifies the possible ways to express an altitude/height.
See Common Geometry Data types.
6.14The EnumCRSType Enumeration

The EnumCRSType enumeration type specifies the possible ways to express a coordinate reference
system.
6.15The AltitudeDeterminationMethod Enumeration

The AltitudeDeterminationMethod enumeration type specifies the possible ways to determine an
altitude.
40
RADIO_ALTIMETER Altitude measured via radio altimeter.
BAROMETRIC Altitude measured via air pressure.
GNSS_BASED Altitude obtained by satellite navigation system.
CALCULATED Altitude calculated against reference point.

Table 21: The AltitudeDeterminationMethod enumeration
6.16The FlightEventIndication Data Structure

The FlightEventIndication data structure carries information about a flight event, such as a "start of
flight" or "end of flight".
Indicates the type of the flight event being

flightEvent FlightEventType 1
reported about.
Reference to the related operation plan, if

operationPlanId UUID 0..1
available.
Indicates the (expected) start time of the

startTime DateTime 0..1 flight. To be provided with a
START_OF_FLIGHT event indication.
Indicates the end time of the flight. To be

endTime DateTime 0..1 provided with an END_OF_FLIGHT event
indication.
Expected number of position reports per

second for this flight.
positionReportFrequency Float 0..1
Optionally provided with
a START_OF_FLIGHT event indication.
Table 22: The FlightEventIndication data structure
6.17The FlightEventType Enumeration

The FlightEventType enumeration type specifies the types of flight events.
START_OF_FLIGHT denotes a start-of-flight event.
END_OF_FLIGHT denotes an end-of-flight event.

Table 23: The FlightEventType enumeration
6.18Common Data Structures Used in UTM Service Specifications
41
Figure 4: Common Data Types Used in UTM Service Specifications
6.18.1NotificationEndpoint Data Structure
NotificationEndpoint is used in subscription and un-subscription operations to show the receiver of

notifications as a result of the subscription.
URL String 1 Endpoint capable of receiving notifications

Table 24: NotificationEndpoint Data Structure
6.18.2ServiceResponse Data Structure

ServiceResponse is the generic response provided by each service operation. In some cases, this basic
data structure may be extended by inheritance.
result OperationResult 1 Indicates the result of the request to the service
Optional additional information to be provided in case

rejectReason String 0..1
of negative result
timeStamp DateTime 1
Table 25: ServiceResponse Data Structure
6.18.3OperationResult Enumeration
The OperationResult enumeration type specifies the possible outcomes of calling an operation.
SUCCESS Operation was successfully executed.
REJECTED Operation could not be executed.

Table 26: OperationResult Enumeration
42
6.19Common Geometry Data Structures Used in UTM Service

Specifications
Figure 5: Common Geometry Data Types Used in UTM Service Specifications
6.19.1AreaOfInterest Data Structure
AreaOfInterest is used in subscription operations to provide an indication of the geographic area for
which the subscriber is interested to receive notifications.
A geometric description of a Should be a 2-dimensional

area Geometry 1
geographic area. geometry in this case.
Coordinate reference system used

areaCRS EnumCRSType 1
(WGS-84, EPSG:4979)
Table 27: AreaOfInterest Data Structure
6.19.2Geometry Data Structure
Geometry describes a geometrical shape of one, two or three dimensions.
The Geometry data structure is not further detailed in this service specification. One example of how
a generic Geometry structure could be realized is sketched in the table below:
Collection of the coordinates,

coordinates Double 2..*
describing the geometry.
43
Type of geometry being Examples: Point, Polygon,

geometryType GeometryType 1
described by the coordinates. Polyhedron, etc.
Table 28: Geometry Data Structure
6.19.3EnumAltitudeType Enumeration
Altitude above mean-sea-level.

ABOVE_MSL
Same as orthometric height; same as height above the earth geoid.
ABOVE_TO Altitude above take-off location.
ABOVE_GND Height above ground surface.
ABOVE_ELLIPSOID Altitude above the WGS-84 ellipsoid; value delivered by GPS.

Table 29: EnumAltitudeType Enumeration
6.19.4EnumCRSType Enumeration
system. The most common values used are noted in bold letters.
World Mercator
Geodetic CRS: WGS 84;
Coordinate System: Cartesian

EPSG3395_WGS84 CS. Euro-centric view of world excluding polar areas.
Axes: easting, northing (E, N).

Orientations: east, north.
UoM: metre.
44
Pseudo-Mercator -- Spherical
Mercator, Google Maps,
OpenStreetMap, Bing, ArcGIS,
ESRI
Geodetic CRS: WGS 84; Uses spherical development of ellipsoidal coordinates.

Relative to WGS 84 / World Mercator (CRS code 3395)
EPSG3857_WGS84 errors of 0.7 percent in scale and differences in
northing of up to 43km in the map (equivalent to 21km
CS.
on the ground) may arise.
Axes: easting, northing (X, Y).

UoM: metre.
Coordinate System: Ellipsoidal

2D CS. Uses Historic World Geodetic System 1972.
EPSG4322_WGS72
Axes: latitude, longitude. Horizontal component of 3D system.
Orientations: north, east.
UoM: degree.
WGS84 - World Geodetic

System 1984, used in GPS
Horizontal component of 3D system. Used by the GPS

EPSG4326_WGS84 satellite navigation system and for NATO military
2D CS.
geodetic surveying.
Axes: latitude, longitude.

UoM: degree.

EPSG4760_WGS66
UoM: degree.
45

3D CS.
EPSG4979_WGS84 Used by the GPS satellite navigation system.
Axes: latitude, longitude,
ellipsoidal height. Orientations:
north, east, up.
UoM: degree, degree, metre.

Table 30: EnumCRSType Enumeration
6.19.5EnumGeometryType Enumeration
The EnumGeometryType enumeration type specifies possible geometrical shapes.
POINT Single point.
POLYGON Polygon.
...
Table 31: EnumGeometryType Enumeration
46
7 Service Interface Specifications

This chapter describes the details of each service interface. One sub-chapter is provided for each
Service Interface.
The Service Interface specification covers only the static design description while the dynamic design
(behaviour) is described later.
7.1 Service Interface TrafficTelemetrySubscriptionInterface

7.1.1 Operation subscribeForTrafficTelemetry
7.1.1.1 Operation Functionality
A consumer calls this operation to subscribe to position report data.
7.1.1.2 Operation Parameters

Parameter
Direction Data Type Description
Name
Which endpoint shall be notified in case of new

consumer Input NotificationEndpoint
PositionReports (and FlightEvents, if supported).
areaOfInterest Input AreaOfInterest Area of interest to the consumer
response Return ServiceResponse Provide status information on subscription

Table 32: Payload description of subscribeForTrafficTelemetry operation
7.1.2 Operation unSubscribeForTrafficTelemetry

A consumer calls this operation at the provider to unsubscribe from position report data.

Parameter
Name
Which endpoint shall be not be notified (anymore) in case

of new PositionReports.

Table 33: Payload description of unSubscribeForTrafficTelemetry operation
7.2 Service Interface TrafficTelemetryNotificationInterface
47
Consumer provides this interface, allowing the service provider to submit to the consumer position
report data (and flight event notifications, if supported).
7.2.1 Operation notifyPositionReport

Once and while subscribed, consumer receives position report data via this operation.

Parameter
Name
A position report matching the area criterium provided with

positionReport Input PositionReport
subscription.
Table 34: Payload description of notifyPositionReport operation
7.2.2 Operation notifyFlightEvent

Once and while subscribed, consumer receives flight event notifications via this operation.

Parameter
Name
Indication of a flight event taking place in the area

flightEvent Input FlightEventNotification
criterium provided with subscription.
Table 35: Payload description of notifyFlightEvent operation
48
8 Service Dynamic Behaviour

8.1 Service Interfaces TrafficTelemetrySubscriptionInterface and
TrafficTelemetryNotificationInterface
Figure 6: Traffic/Telemetry Service interface operation sequence diagram
The figure above provides an example scenario for the TrafficTelemetry service. The scenario
assumes a Tracker system providing the TrafficTelemetry service as well as the
PositionReportSubmission service. In this example, two different systems are assumed to submit
position reports to the tracker. Furthermore, the scenario includes a consumer of the
TrafficTelemetry service, subscribing to the Tracker at some point in time and unsubscribing some
time later. The consumer, as long as it is subscribed to the Tracker, receives all position reports and
flight event notifications matching the area of interest indicated in the subscription.
Note:
In order to illustrate the service operations in a realistic context, this Sequence Diagram contains
additional operations from the PositionReportSubmission service, not only TrafficTelemetry service
operations.
49
50
9 References
Nr. Version Reference
CFP Reference CEF-SESAR-2018-1, “Finnish-Estonian "Gulf of Finland" Very Large U-

[1] n/a
Space Demonstration”
Advanced
[2] Edition ICAO Doc 10039, Manual on System Wide Information Management (SWIM) Concept
(unedited)
SESAR 2020 GOF USPACE FIMS Design and Architecture, Appendix A Service Description
[3] 00.05.00
Templates, document SESAR 2020 GOF USPACE Service Documentation Guidelines
Vol. 1:
Ed.
01.01.03, EUROCONTROL Concept of Operations for U-space (CORUS), D6.2, grant agreement No.
04-SEP- 760550, Call Ref. 2016 SESAR 2020 RPAS Exploratory Research Call (H2020 – SESAR -
2019 2016-1), in two volumes:
[4]
Vol. 2: Vol. 1: Enhanced Overview
Ed.
03.00.02, Vol. 2: SESAR UTM Concept Definition
25-OCT-
2019
Global UTM Association (GUTMA) Flight Logging Protocol, https://github.com/gutma-

[5] n/a
org/flight-logging-protocol/blob/master/Flight_logging_protocol.md
Global UTM Association (GUTMA) Air Traffic

[6] n/a
Protocol, https://github.com/hrishiballal/airtraffic-data-protocol-development
Federal Aviation Administration NextGEN Concept of Operations, Foundational

[7] V1.0 Principles, Roles and Responsibilities, Use Cases and Operational Threads, Unmanned
Aircraft System (UAS), Traffic Management (UTM)
Federal Office of Civil Aviation (FOCA), Swiss U-Space ConOps, U-Space Program
[8] 1.0
Management, 31.10.2018, FOCA muo / 042.2-00002/00001/00005/00021/00003
5th Ed. -
[9] ICAO Doc. 9750-AN/963, Global Air Navigation Plan (GANP) 2016-2030
2016
Intel Corporation, Open Drone ID Message Specification, Draft Specification, November

[10] 0.61.1
13, 2018
SESAR, European ATM Master Plan: Roadmap for the safe integration of drones into all
[11] n/a
classes of airspace
[12] n/a SESAR, eATM PORTAL, European ATM Master Plan, https://www.atmmasterplan.eu/
[13] 2017 SESAR-JU, U-space Blueprint, https://www.sesarju.eu/u-space-blueprint
51
Efficient, safe and sustainable traffic at sea (EfficienSea2), a Horizon 2020 Project, Grant
Agreement No 636329
[14] n/a https://efficiensea2.org
https://efficiensea2.org/wp-content/uploads/2018/04/Deliverable-3.6.Standard-
proposal-for-Maritime-Cloud-service-specification.pdf
IALA specification for e-navigation technical services

[15] n/a
https://www.iala-aism.org/product/g1128-specification-e-navigation-technical-services
EUROCONTROL Specification for ATM Surveillance System Performance,

[16] Ed. 1.0 EUROCONTROL-SPEC-0147, https://www.eurocontrol.int/publications/eurocontrol-
specification-atm-surveillance-system-performance
Massachusets Institute of Technology Lincoln Laboratory for the Federal Aviation

1 Administration, Project Report ATC-323, Required Surveillance Performance Accuracy to
[17] November Support 3-Mile and 5-Mile Separation in the National Airspace
2006 System, https://www.ll.mit.edu/sites/default/files/publication/doc/2018-
12/Thompson_2006_ATC-323_WW-15318.pdf
ASTERIX Library: ASTERIX, All-purpose structured EUROCONTROL surveillance

information exchange, Defining the low level implementation of a data format used for
[18] n/a
exchanging surveillance-related information in ATM applications. Available at
https://www.eurocontrol.int/asterix.
Gesamtvorhabensbeschreibung zum Verbundprojekt "Fähigkeit des Abfangens von in

gesperrte Lufträume eindringenden Kleinfluggeräten durch zivile Einsatzmittel",
Akronym: FALKE, Aktenzeichen: DG20-837.4/4-1, eingereicht im Rahmen des Ideen- und
[19] 21.08.2019 Förderaufrufes zum Thema "Unbemannte Luftfahrtanwendungen und individuelle
Luftmobilitätslösungen (UAS, Flugtaxis)" beim Projektträger, dem Bundesministerium
für Verkehr und digitale Infrastruktur der Bundesrepublik Deutschland, Invalidenstr. 44,
11030 Berlin
Table 36: List of References
52
D2.4 Appendix B
Operation Plan Service
Specification
Deliverable ID: D2.4-B
Grant: 101017689
Topic:
Air Mobility
Edition: 01.00.00
D2.4 APPENDIX B OPERATION PLAN SERVICE SPECIFICATION


2


Document History
draft
01.00.00 04.11.2022 Release Coordinator Submit deliverable
Copyright Statement
© 2022 – GOF2.0 Consortium. All rights reserved. Licensed to SESAR3 Joint Undertaking under
conditions.
3
GOF 2.0
1.1 Abstract
Exchange Service.
This document describes one of these Bridge Services, the Operation Plan Exchange service in a logical,
technology-independent manner.
4
Table of Contents
Abstract ................................................................................................................................... 4
1 Introduction ............................................................................................................. 11
1.2 Scope .......................................................................................................................... 11
1.4 Background ................................................................................................................. 12
1.4.2 SESAR-JU.......................................................................................................................................... 13
1.4.3 1.1.8 Efficient, safe and sustainable traffic at sea (EfficienSea2) ................................................ 14
1.6 List of Acronyms .......................................................................................................... 17
3.2.1.1 ICAO SWIM ............................................................................................................................. 21
4.1 Overview..................................................................................................................... 25
4.2 The OperationPlan Data Structure................................................................................ 26
4.3 The OperationPlanResponse Data Structure ................................................................. 33
4.4 The OperationVolume Data Structure .......................................................................... 34
4.5 The ContingencyPlan Data Structure ............................................................................ 36
4.6 The UasRegistration Data Structure.............................................................................. 39
4.7 The FlightDetails Data Structure ................................................................................... 40
4.8 The Priority Data Structure .......................................................................................... 40
4.9 The OperationTrajectory Data Structure....................................................................... 41
4.10 The TrajectoryElement Data Structure.......................................................................... 41
4.11 The Mission Data Structure .......................................................................................... 42
4.12 The PublicInformation Data Structure .......................................................................... 42
4.13 The OperationPlanState Enumeration .......................................................................... 43
5
4.14 The EnumClosureReason Enumeration ......................................................................... 43

4.15 The ContingencyCauseType Enumeration ..................................................................... 44
4.16 The ContingencyLocationDescriptionType Enumeration ............................................... 44
4.17 The ContingencyResponseType Enumeration ............................................................... 45
4.18 The PriorityLevelSimple Enumeration........................................................................... 45
4.19 The PriorityLevelCorus Enumeration ............................................................................ 46
4.20 The OperationPlanProcessingResponse Data Structure ................................................. 47
4.21 The ProcessingResultInfo Data Structure ...................................................................... 48
4.22 The EnumOperationPlanResult Enumeration ................................................................ 48
4.23 The MissionResponse Data Structure ........................................................................... 49
4.24.3 OperationResult Enumeration .................................................................................................... 50
4.26 Common Address Data Structures Used in UTM Service Specifications .......................... 54
4.26.1 Address Data Structure ............................................................................................................... 55
4.26.2 ContactDetails Data Structure .................................................................................................... 55

5.1 Service Interface OperationPlanRetrievalInterface ....................................................... 57
5.1.1 Operation getOperationPlanForId .................................................................................................. 57
5.1.2 Operation getOperationPlanVersion............................................................................................... 57
5.1.3 Operation getOperationPlanForMission ......................................................................................... 58
5.1.4 Operation getOperationPlanForGeometry ..................................................................................... 58
5.1.5 Operation getOperationPlans ......................................................................................................... 58
5.2 Service Interface OperationPlanSubscriptionInterface .................................................. 59
5.2.1 Operation subscribeForOperationPlan ........................................................................................... 59
5.2.2 Operation unsubscribe .................................................................................................................... 59
6

5.3 Service Interface OperationPlanNotificationInterface ................................................... 60
5.3.1 Operation notifyOperationPlan....................................................................................................... 60
5.4 Service Interface OperationPlanManagementInterface................................................. 60
5.4.1 Operation evaluateOperationPlan .................................................................................................. 60
5.4.2 Operation proposeOperationPlan ................................................................................................... 61
5.4.3 Operation submitOperationPlan ..................................................................................................... 62
5.4.4 Operation updateOperationPlan .................................................................................................... 62
5.4.5 Operation cancelOperationPlan ...................................................................................................... 63
5.4.6 Operation requestOperationPlanAuthorisation.............................................................................. 63
5.4.7 Operation revokeOperationPlan ..................................................................................................... 64
5.4.8 Operation requestTakeOff .............................................................................................................. 64
5.4.9 Operation declareEndOfFlight......................................................................................................... 65
5.4.10 Operation createMission ............................................................................................................ 66
5.4.11 Operation updateMission ........................................................................................................... 66

6.1 Sequence of events, cooperation with other services ................................................... 67
6.2 Operation Plan State Machine ..................................................................................... 68
7 References ............................................................................................................... 69
List of Tables
Table 4: Requirements for the Traffic/Telementry Service................................................................... 21
7
Table 5: Operational Nodes providing the Operation Plan Exchange service ...................................... 22
Table 6: Operational Nodes consuming the Operation Plan Exchange service .................................... 22
Table 7: Operational Activities supported by the Operation Plan Exchange service ............................ 23
Table 9: The OperationPlan data structure ........................................................................................... 33
Table 10: The OperationPlanResponse data structure ......................................................................... 34
Table 11: The OperationVolume data structure ................................................................................... 36
Table 12: The ContingencyPlan data structure ..................................................................................... 39
Table 13: The UasRegistration data structure....................................................................................... 40
Table 14: The FlightDetails data structure ............................................................................................ 40
Table 15: The Priority data structure .................................................................................................... 41
Table 16: The OperationTrajectory data structure ............................................................................... 41
Table 17: The TrajectoryElement data structure .................................................................................. 42
Table 18: The Mission data structure .................................................................................................... 42
Table 19: The PublicInformation data structure ................................................................................... 42
Table 20: The OperationPlanState enumeration .................................................................................. 43
Table 21: The PriorityLevelSimple enumeration ................................................................................... 44
Table 22: The ContingencyCauseType enumeration............................................................................. 44
Table 23: The ContingencyLocationDescriptionType enumeration ...................................................... 45
Table 24: The ContingencyResponseType enumeration ....................................................................... 45
Table 25: The PriorityLevelSimple enumeration ................................................................................... 45
Table 26: The PriorityLevelCorus enumeration..................................................................................... 46
Table 27: The OperationPlanProcessingResponse data structure ........................................................ 48
Table 28: The ProcessingResultInfo data structure............................................................................... 48
Table 29: The EnumOperationPlanResult enumeration ....................................................................... 48
Table 30: The MissionResponse data structure .................................................................................... 49
8
Table 39: Address Data Structure.......................................................................................................... 55
Table 40: ContactDetails Data Structure ............................................................................................... 56
Table 41: Payload description of getOperationPlanForId operation .................................................... 57
Table 42: Payload description of getOperationPlanVersion operation ................................................ 57
Table 43: Payload description of getOperationPlanForMission operation ........................................... 58
Table 44: Payload description of getOperationPlanForGeometry operation ....................................... 58
Table 45: Payload description of getOperationPlans operation ........................................................... 59
Table 46: Payload description of subscribeForOperationPlans operation............................................ 59
Table 47: Payload description of unsubscribe operation ...................................................................... 60
Table 48: Payload description of notifyOperationPlan operation ........................................................ 60
Table 49: Payload description of evaluateOperationPlan operation .................................................... 61
Table 50: Payload description of proposeOperationPlan operation .................................................... 61
Table 51: Payload description of submitOperationPlan operation....................................................... 62
Table 52: Payload description of updateOperationPlan operation ...................................................... 63
Table 53: Payload description of cancelOperationPlan operation........................................................ 63
Table 54: Payload description of requestOperationPlanAuthorisation operation ............................... 64
Table 55: Payload description of revokeOperationPlan operation ....................................................... 64
Table 56: Payload description of requestTakeOff operation ................................................................ 65
Table 57: Payload description of declareEndOfFlight operation .......................................................... 65
List of Figures
9
Figure 1: OperationPlanExchangeService Interface Definition diagram ............................................... 23
Figure 2: Operation Plan Services - Base Data Model diagram ............................................................. 26
Figure 3: Operation Plan Services - Operation Plan Processing Response data structure diagram ..... 47
Figure 4: Operation Plan Services - Mission Response data structure diagram ................................... 49
Figure 7: Common Address Data Types Used in UTM Service Specifications ....................................... 55
Figure 8: OperationPlanExchange service operation sequence diagram ............................................. 67
Figure 9: Operation Plan states - state transition diagram ................................................................... 68
10
2 Introduction
In accordance with according to the guidelines given in [3], this document describes the Operation
Plan Exchange service for the GOF USPACE project on a logical technology-independent manner, that
is:

2.2 Scope
This document describes the Operation Plan Exchange service for the GOF USPACE project.
The Operation Plan Exchange service provides a means for the operational nodes of the GOF USPACE
project to share their UTM operation plans and make them available for further processing.
The Operation Plan Exchange service furthermore provides a means for the operational nodes of the
GOF USPACE project to consume UTM operation plans from the U-space participants for further
processing.
Finally, the Operation Plan Exchange service provides an interface allowing operational nodes to
manipulate drone operation plans by interacting with the service provider in order to request
authorization, activation, etc.

This service specification is intended to be read by service architects, system engineers and
developers in charge of designing and developing an instance of the Operation Plan Exchange
service.
11

2.4 Background
EUROCONTROL CORUS [4] elaborates in 5.1 Flight planning and derived services reporting as follows.
“U2 brings flight planning and many derived services. As mentioned in section 4, for
airspaces where flight plans are required, the aim is to have a flight plan from every aircraft,
drone or manned. This will allow a something like a complete picture to be built in advance.
“Something like” because flight plans for drones, like for manned aircraft, will contain some
elements of uncertainty, or “flexibility”. U2 brings flight planning and many derived services.
As mentioned in section 4, for airspaces where flight plans are required, the aim is to have a
flight plan from every aircraft, drone or manned. This will allow a something like a complete
picture to be built in advance. “Something like” because flight plans for drones, like for
manned aircraft, will contain some elements of uncertainty, or “flexibility”.
[…]
Drone flight plans will not be the same as the flight plan defined in ICAO doc 4444 used by
manned aviation today. Several factors push for this. There are rules associated with the
ICAO flight plan that simply cannot work for small drones, such as a requirement to fly via
published points. The ICAO flight plan does a poor job of describing a 4D trajectory and there
is no reason to inflict this problem on ourselves in the brave new world of drone flight
planning.
[…]
The basic contents of the drone flight plan will be the same as the ICAO flight plan: who flies
what, where and when. Like the ICAO flight plan, the drone flight plan is a legal commitment
to fly and stakes a claim on a limited public good – the airspace. Submitting a flight plan is
also a commitment by the drone operator to meet the obligations associated with flying,
which would include factors like having a safe aircraft and a competent pilot and committing
to operate the flight safely, but also committing to meet the costs (if any) associated with
flying, to have public liability insurance and so on.
There will need to be a nominated actor to whom drone flight plans are sent, probably with a
mandate from the civil aviation authority for the country. Flight plans will be sent
electronically, ideally from a tool used by a drone operator that makes flight plan creation
easy and integrates into the task of creating the plan to be loaded into the drone itself. The
basic process will consist in its simplest form as:
 Drone operator submits flight plan

 Flight plan is checked by U-space
 Drone operator gets a response
 If valid, the flight plan data is added to the set of current flight plans in the flight planning
12
 system and the operator can load it into the drone

 If invalid, the drone operator reads the remarks, changes the plan and resubmits.
The ‘check’ of the flight plan by the U-space includes:
 Some parts of Pre-tactical Geo-fencing

 Strategic Conflict Resolution
 In U3, Dynamic Capacity Management
The flight plan management service supports:
 Flight plan preparation / optimisation

 Pre-tactical Geo-fencing and Tactical Geo-fencing
 Strategic Conflict Resolution
 Collaborative interface with ATC
 Tracking
 Monitoring
 Traffic Information
 Emergency Management
 Legal Recording
 Incident / Accident reporting
 Operations Management
 Safety Management
 Dynamic Capacity Management
 Digital Logbook"
2.4.2 SESAR-JU
The European Commission identifies an increasing demand for a non-segregated use of airspace
which is being driven by a rapidly growing market of Very-Low-Level (VLL) airspace users, most of
which are expected to be drones.
Via the Roadmap for the safe integration of drones into all classes of airspace [11], within the
European ATM Masterplan [12], the European Commission seeks to ensure that this rapid growth of
airspace use happens in a safe and controlled manner.
13
These stages reflect the anticipated quick growth of demand for U-space services. The state of the
art is being validated throughout Europe via several Very Large Demonstrator (VLD) projects such as
the GOF USPACE project.
During the U1 phases, SESAR expects drones capable to supply their position via telemetry. The U1
and U2 is anticipated to provide tracking capabilities and services.
2.4.3 1.1.8 Efficient, safe and sustainable traffic at sea (EfficienSea2)

Term Definition
Describes the semantics of the domain (or a significant part thereof) by
External Data defining data structures and their relations. This could be at logical level (e.g.,
Model in UML) or at physical level (e.g., in XSD schema definitions), as for example
standard data models.
Describes the principles how two different parts of a message passing system
(in our case: the service provider and the service consumer) interact and
communicate with each other. Examples:
In the Request/Response MEP, the service consumer sends a request to the

Message service provider in order to obtain certain information; the service provider
Exchange Pattern provides the requested information in a dedicated response.
In the Publish/Subscribe MEP, the service consumer establishes a subscription

with the service provider in order to obtain certain information; the service
provider publishes information (either in regular intervals or upon change) to
all subscribed service consumers.
An activity performed by an operational node. Examples of operational
Operational
activities are: Route Planning, Route Optimization, Logistics, Safety, Weather
Activity
Forecast Provision, …
Operational A structure of operational nodes and associated operational activities and
Model their inter-relations in a process model.
A logical entity that performs activities. Note: nodes are specified
independently of any physical realisation.
Operational Node
Examples of operational nodes are: Control Center, Authority, Weather
Information Provider, …
14
The provision of something (a non-physical object), by one, for the use of one
or more others, regulated by formal definitions and mutual agreements.
Service Services involve interactions between providers and consumers, which may be
performed in a digital form (data exchanges) or through voice communication
or written processes and procedures.
Formal description of one dedicated service at logical level. The service data
model is part of the service specification. Is typically defined in UML and/or
Service Data
XSD. If an external data model exists (e.g., a standard data model), then the
Model
service data model shall refer to it: each data item of the service data model
shall be mapped to a data item defined in the external data model.
Documents the details of a service technical design (most likely documented
Service Design by the service implementer). The service design description includes (but is
Description not limited to) a service physical data model and describes the used
technology, transport mechanism, quality of service, etc.
Service Implementers of services from the service provider side and/or the service
Implementer consumer side.
One service implementation may be deployed at several places by same or
Service Instance different service providers; each such deployment represents a different
service instance, being accessible via different URLs.
Documents the details of a service implementation (most likely documented
by the service implementer) and deployment (most likely documented by the
Service Instance
service provider). The service instance description includes (but is not limited
Description
to) service technical design reference, service provider reference, service
access information, service coverage information, etc.
The communication mechanism of the service, i.e., interaction mechanism
between service provider and service consumer. A service interface is
Service Interface characterised by a message exchange pattern and consists of service
operations that are either allocated to the provider or the consumer of the
service.
Functions or procedure which enables programmatic communication with a
Service Operation
service via a service interface.
15
Describes the realisation of a dedicated service data model in a dedicated

technology. This includes a detailed description of the data payload to be
exchanged using the chosen technology. The actual format of the service
physical data model depends on the chosen technology. Examples may be
WSDL and XSD files (e.g., for SOAP services) or swagger (Open API)
specifications (e.g., for REST services). If an external data model exists (e.g., a
standard data model), then the service physical data model shall refer to it:
each data item of the service physical data model shall be mapped to a data
Service Physical
item defined in the external data model.
Data Model
In order to prove correct implementation of the service specification, there
shall exist a mapping between the service physical data model and the service
data model. This means, each data item used in the service physical data
model shall be mapped to a corresponding data item of the service data
model. (In case of existing mappings to a common external (standard) data
model from both the service data model and the service physical data model,
such a mapping is implicitly given.)
A service provider provides instances of services according to a service
specification and service instance description. All users within the domain can
Service Provider
be service providers, e.g., authorities, organizations (e.g., meteorological),
commercial service providers, etc.
Describes one dedicated service at logical level. The Service Specification is
technology-agnostic. The Service Specification includes (but is not limited to) a
Service
description of the Service Interfaces and Service Operations with their data
Specification
payload. The data payload description may be formally defined by a Service
Data Model.
Service
Producers of service specifications in accordance with the service
Specification
documentation guidelines.
Producer
The technical design of a dedicated service in a dedicated technology. One
Service Technical
service specification may result in several technical service designs, realising
Design
the service with different or same technologies.
List and specifications of allowed technologies for service implementations.
Service Currently, SOAP and REST are envisaged to be allowed service technologies.
Technology The service technology catalogue shall describe in detail the allowed service
Catalogue profiles, e.g., by listing communication standards, security standards, stacks,
bindings, etc.
A service specification is characterised as “spatially exclusive”, if in any
geographical region just one service instance of that specification is allowed to
be registered per technology.
Spatial
Exclusiveness
The decision, which service instance (out of a number of available spatially
exclusive services) shall be registered for a certain geographical region, is a
governance issue.
16

Acronym Definition

17
The purpose of this chapter is to provide a unique identification of the service and describe where
the service is in terms of the engineering lifecycle.
Name OperationPlanExchange Service

ID urn:gof:services:OperationPlanExchangeService
Version 2.0
Description An information exchange service which provides operation plan information
Operation Plan, Mission Planning, Contingency Plan, Operation Volume, Operation
Keywords
Trajectory
2021-today The GOF 2.0 Project Consortium
Architect(s) 2020-2021 The Frequentis Group

Status Provisional
18

The table below lists applicable existing requirements for the Operation Plan Exchange service.
Id Name
At all times, all U-space
CORUS [4], 4.1.1.2
participants shall operate on
Common Amber airspace;B1-
the same common set of data,
[R-1] Situational RPAS [9];CEF-SESAR-
during pre-flight planning stages
Awareness 2018-1 [1], Objective
as well as during all stages of
O5
flight operations.
SESAR Drone Roadmap
The U-space concept shall be
designed such as to ensure a
4.2;U-space Blueprint
well-established line of
Basis for Open [13], Benefits to
[R-2] authority while at the same
Market European society and
time ensuring that an open
economy;CEF-SESAR-
market for VLL services may
2018-1 [1], Table 8 –
develop
Key Challenges
There shall be an
implementation of a Flight
System (FIMS) which ensures
that, at all times, emerging
unmanned traffic management ICAO Doc 10039 [2];[R-
systems and existing 2];CEF-SESAR-2018-1
[R-3] Interoperability technologies from manned [1], Objective O6;CEF-
operations can exchange any SESAR-2018-1 [1], Table
data required to support such 8 – Key Challenges
common situational awareness,
be it for drone operations in
areas where established ATC
procedures apply, or in zones
outside established ATC.
19
Standard communication
protocols shall hence be used
[R-2];SESAR Drone
where available, and such
Roadmap [11], 3.5,
Standard standard protocols be
[R-4] section ‘Standards’;CEF-
Protocols developed otherwise, in order
SESAR-2018-1 [1], Table
to ensure the lowest level of
8 – Key Challenges
obstruction for an open VLL
airspace use market to develop.
Any interface and protocol
hence must be openly defined
and its definition be freely [R-2];CEF-SESAR-2018-1
[R-5] Open Interfaces accessible in order to ensure [1], Table 8 – Key
the lowest level of obstruction Challenges
for an open VLL airspace use
market to develop.
The implementation of a Flight
[R-3];CEF-SESAR-2018-1
[1], 5.3.4 Overall
[R-6] SWIM System (FIMS) shall be based on
approach and
an ICAO SWIM-compliant
methodology
architecture.
20
Under no operational
circumstance, the processing of
position data may add significant
latency to the overall detection-to-
display latency of position data. In
particular,
The processing latency added by

the processing of positional data
shall never exceed 10 per cent of
the maximum value of the
corresponding value permitted for
the entire ATM automation
system.
[17], tables in the
[R-7] Latency Executive Summary, [16],
The processing latency and delay
3N_C-R8 and 5N_C-R8
added by the processing of
positional data should not exceed
1 per cent of the maximum value
of the corresponding value
permitted for the entire ATM
automation system.
The maximum value for latency

and delay is the minimum of the
values defined by the ATM system
performance requirements by
EUROCONTOL and the FAA; for a 3
NM minimal separation, this is 2.2
s, for a 5 NM separation, 2.5 s.
Table 4: Requirements for the Traffic/Telementry Service

4.2.1.1 ICAO SWIM
21
The Operation Plan Exchange service primarily is relevant during the Pre-Tactical planning stages of a
U-space flight during which the relevant stakeholders generate flight planning information data as
well as requests for authorization and activation, which we convey via the Operation Plan Exchange
service.
Operational nodes which may provide data for the Operation Plan Exchange service include the
following ones.

USSP
CISP
Flight Information Management System
Table 5: Operational Nodes providing the Operation Plan Exchange service
Operational nodes which may consume the Operation Plan Exchange service include the following
ones.

Information Display
Drone Operator
ATM Service Provider
Legal Recorder
Table 6: Operational Nodes consuming the Operation Plan Exchange service
Operational activities supported by the Operation Plan Exchange service include the following ones.
Phase Operational
Remarks
Activity
22
Pre- This is the main phase where the Operation Plan Exchange service is
Plan
flight used.
In the in-flight phase the Operation Plan Exchange service is
In-Flight Cruise
enhanced by the Drone Flight Exchange service.
Post-
Report
Flight
Table 7: Operational Activities supported by the Operation Plan Exchange service
Figure 1: OperationPlanExchangeService Interface Definition diagram
Role (from service

ServiceInterface provider point of ServiceOperation
view)
getOperationPlanForId
getOperationPlanVersion
OperationPlanRetrievalInterface Provided getOperationPlansForMission
getOperationPlansForGeometry
getOperationPlans
OperationPlanSubscriptionInterface Provided subscribeForOperationPlans

unSubscribeForOperationPlans
23
OperationPlanNotificationInterface Required notifyOperationPlan

evaluateOperationPlan
proposeOperationPlan
submitOperationPlan
updateOperationPlan
cancelOperationPlan
OperationPlanManagementInterface Provided requestOperationPlanAuthorisation
revokeOperationPlan
requestTakeOff
declareEndoOfFlight
createMission
updateMission
24

This section describes the information model, i.e., the logical data structures to be exchanged
5.1 Overview
The OperationPlan exchange service transfers information about Operation Plans and associated
data. The central part of the data model for this service is the OperationPlan structure, which collects
various data items of various categories:
 identification;
 information about geographical and timely dimension of the operation plan:
o rough trajectory by a sequence of operation volumes including timely validity of
these volumes;
o optionally a more finegrained 4D trajectory, defined by a list of waypoints (trajectory
elements).
 information about contingency plans for the case of unplanned events:
o alternative actions;
o alternative landing or loitering areas;
o alternative volumes for emergency landings;
o expected endurance
 information about the current state of the operation plan:
o current state;
 history of the operation plan:
o history of past updates to the operation plans;
o history of state transitions.
 priority declarations;
 information about used devices: drone identification and registration information;
 flight related information;
 administrative information, such as contact details, public name and description, comments,
etc.;
 additional information about the operation mission.
25
The picture can't be display ed.
Figure 2: Operation Plan Services - Base Data Model diagram
5.2 The OperationPlan Data Structure

OperationPlan is the central part of the OperationPlanExchange service data model. As such, it acts
as a composite of plenty other structures.
Multiplicity
Globally unique
1
operationPlanId UUID identifier of this
operation plan.
Unique identifier This is needed for the

of the version of
UUID 1 history of the OP. See
version this operation
previousVersion reference
plan.
.
26
This reference builds up

the history of the OP. Upon
every change, a new
version of the OP shall be
created; this reference
points to the previous
version.
Reference to the
Reference to 0..* previous version
previousVersion This reference can simply
OperationPlan of this operation
be realized by storing the
plan.
version UUID of the
previous version.
Alternatively, it could be
realized by storing an
ordered linked list of
UUIDs, including the whole
history.
Informative text
about the
aircraft. Not
0..1
aircraftComment String used by the UTM
System. Only for
human
stakeholders.
The current
state of the
1
state OperationPlanState operation. Must
be maintained
by the USS.
String 1 Operator
operator
identification.
The submitTime value

Time that this MUST remain constant for
operation plan each recipient of the
DateTime 1 was first announcement since this
submitTime
announced to value is potentially part of a
the USS Network signature of the operation
in any way. plan in some cases.
27
A timestamp set
by the USS any
time the state of
the operation
plan is updated
within the USS
Network. An
update may be
minor or major,
but if/when the
operation plan is
shared in the When the operation plan is
USS Network, announced for the first
updateTime time, updateTime MUST be
must reflect the equal to submitTime. When
updateTime DateTime 1
time that update an operation plan is
was provided. modified (updated),
The updateTime updateTime MUST be
value MUST be greater than submitTime.
constant for
each update
data exchange.
This field is set

and maintained
by the USS
managing the
operation and is
communicated
to other USSs.
Indicates the
typeOfOperation OperationType 1 type of
operation.
28
Corus: "U-space considers

formation flights and
swarms as being
collections of aircraft that
do not need to be
Number of separated by U-space."
drones flying as
a swarm. "A swarm is considered by
U-space to be a single,
int 1
swarmSize If >1, this solid object. U-space will
indicates that not attempt to pass
this operation another flight through a
plan represents swarm.... A swarm will
a swarm. have a single operation
plan and this plan will
include dimensions for the
swarm. Swarms may be
prohibited in some
volumes."
Designator for a
formation flight.
Corus: "Drone formation
This string is
flights are individual
supposed to
string 0..1 operation plans that are
formationId have the same
linked, rather than single
value for all OPs
plans for multiple aircraft.
taking part in a
formation flight.
Corus: "Drone formation

References to
flights are individual
other OPs
UUID 0..* operation plans that are
formationOpIds belonging to the
linked, rather than single
same formation.
plans for multiple aircraft.
Minimum Minimum acceptable time

minContOpTime TimeDuration 0..1 continuous of the continuous
operation time. operation to recognize the
operation as succesfull.
Optional
instructions
atsInstruction string 0..1 provided by ATS
during approval
process.
Indication of the
EnumClosureReason reason for
closureReason 0..1
Type closing the
operation plan.
29
Each operation volume

MUST have non-zero 4D
volume (i.e. each of the 4
dimensions much have a
valid value).
Volume intersection must

pass the following checks:
a. When ordered by
ordinal values, a
succeeding operation
volume must have a 2D or
3D intersection in 3D space
with its immediately
preceding operation
volume. Note that a 2D
intersection in 3D space
implies two volumes that
"touch" and the
intersection has 2D area.
Sharing just an edge would
The actual not qualify. 3D volumes
geographical that don't touch at all
information for would not qualify, even if
the operation, they would intersect when
operationVolumes OperationVolume 0..*
defined by at projected into 2D space
least one (e.g. if "looking down" on
operation the two volumes).
volume. b. When ordered by
ordinal values, a
succeeding operation
volume must have a non-
negative temporal
intersection with its
immediately preceding
operation volume (Note
we'd calculate this by t1-t2
where t1 is the preceding
operation volume end time
and t2 is the succeeding
operation volume start
time.).
c. When ordered by ordinal
values, a succeeding
operation volume must
have either a non-zero
volume (3D) intersection
OR a positive temporal
intersection. (Note this is a
logical "OR" so it may have
both intersection types...
30
i.e. it is not an "exclusive

OR").
Each spatial dimension of

an operation volume's
bounding box must have
length less than 6000ft
(value TBD). This is a sanity
check against excessively
large volumes. Need to be
careful here as there may
be legitimate use cases
wherein large volumes are
required/allowed, but we
want to encourage
efficient planning and
protect against misuse of
the shared airspace.
The planned duration of an

operation volume must be
less than 120 minutes
(value TBD). Again, need to
be careful to not damage
legitimate use cases, but
need to protect against
misuse/poor planning. For
long duration missions, it
may be reasonable to have
them replan or to have
volumes with the same
geography and long time
values that slightly
intersect.
The start time of an

operation volume other
than the first in the array
must be greater than or
equal to the start time of
its immediately preceding
operation volume.
operation volumes may by

omitted if an
operationTrajectory is
provided.
Detailed planned If no operationTrajectory is

trajectory, provided, then the
operationTrajector OperationTrajectory 0..1
y including operationVolumes are
uncertainties. mandatory.
31
An array of
contingency
plans wherein
this operation
may land if
needed/require
ContingencyPlan 0..* d during
contingencyPlans
operation. Aids
in planning and
communication
during the
execution of a
contingency.
Two dimensional
location
(geographical
point) of the
controllerLocation Geometry 1 controller.
This is the actual

drone pilot
location.
Two dimensional
location
(geographical
point) of the
ground control
station.
Geometry 0..1
gcsLocation This is the
optional control
station location
for the
(potential) cases
where the pilot
is not co-located
with the GCS.
Two dimensional
location
Geometry 0..1 (geographical
takeoffLocation
point) of the
takeoff point.
Two dimensional
location
Geometry 0..1 (geographical
landingLocation
point) of the
landing target.
32
The registration The uasRegistrations array

data for the MUST NOT be used as a list
vehicle(s) to be of potential vehicles for this
used in this Operation. If the vehicle
Operation. Note data changes prior to an
that this is an Operation, an update to
array to allow for the plan may be submitted
uasRegistrations UasRegistration 1..*
future with the updated vehicle
operations information. Providing
involving multiple uasRegistrations in
multiple vehicles this manner implies that all
(e.g. 'swarms' or vehicles will conform to the
tandem provided operation
inspections). volumes.
More details
flightDetails FlightDetails 0..* related to the
flight.
If necessary, this priority

may be overruled by a
describes the priority definition in the
priority of this OperationVolume (for
Priority 1
priority operation example, if the high prio
operation. operation is limited to a
subset of the OP's
OperationVolumes).
Contact
contactDetails ContactDetails 0..1 information for
this operation.
Additional
information for
publicInfo PublicInformation 0..1
public
disclosure.
A mission allows collecting

common information for
flights related to each
other. E.g., a series of
Reference to a
Mission reference 0..1 flights to be executed for
mission mission.
one common goal, e.g.,
power line inspections
flights for one customer at
one specific day.
Table 9: The OperationPlan data structure
5.3 The OperationPlanResponse Data Structure

33
OperationPlanResponse is used to carry the result of query-operations asking for o peration plans.
Depending on the operation result, it may contain zero, one or several operation plans.
operationPlans OperationPlan 0..* Operation plan(s).
See common data

< inherited > All properties inherited from
types.
ServiceResponse.
Table 10: The OperationPlanResponse data structure
5.4 The OperationVolume Data Structure

OperationVolume is used to describe a portion of the actual geographical information for the
operation. It includes a definition of the three-dimensional boundaries of a portion of airspace,
associated with the time constraints when this portion is planned to be used. Additional flags
indicate whether the portion of airspace is beyond the visual line of sight, or if there is a structure
(e.g., building) in near vicinity.
Optional
alias String 0..1 descripitve
text.
Earliest time
the operation
will use the timeBegin <
timeBegin DateTime 1 operation timeEnd MUST
volume. It be true.
must be less
than timeEnd.
Latest time
the operation
will done with
timeBegin <
the operation
timeEnd DateTime 1 timeEnd MUST
volume. It
be true.
must be
greater than
timeBegin.
34
Time that the

operational
actualTimeEnd
volume was
MUST satisfy:
freed for use
actualTimeEnd >
by other
DateTime 0..1 timeBegin
actualTimeEnd operations.
whenever
Should be
actualTimeEnd is
populated and
not null.
stored by the
USS.
Describes
whether any
portion of the
operation
isBVLOS Boolean 1 volume is
beyond the
visual line of
sight of the
RPIC.
Is this
operation
volume within
isNearStructure Boolean 0..1
400' (value
TBD) of a
structure?
This integer
represents the
ordering of the
operation Need not be
Integer 1
ordinal volume within consecutive
the set of integers.
operation
volumes.
Three- The type of

dimensional Geometry, in
geometry
Geometry 1 this case, must
operationGeometry defining the
be a three-
operation dimensional
volume. shape.
35
Three-
dimensional
geometry
defining
minimum
operationGeometryMinimumSeparation Geometry 0..1
separation
around the
operation
volume.
Priority
This priority
indication for
overrules the
the operation
Priority 0..1 priority
priority within this
definition in the
operation
OperationPlan.
volume.
Table 11: The OperationVolume data structure
5.5 The ContingencyPlan Data Structure

ContingencyPlan is the
Multiplici
Property Type ty Description Note
An identifier
unique amongst
1 the set of
id UUID
Contingencies
for this
operation.
Describes the
cause(s) leading
1..*
causes ContingencyCauseType to this
contingency
plan.
Indication on
where the
ContingenyLocationDescriptio 1
locationDescr contingency
nType
plan is
described.
36
LANDING: targeting
the
contingencyGeograph
y, optionally heading
through the
contingencyExtraVolu
me.
LOITERING: loiter at
the
contingencyGeograph
y at the specified
loiterAltitude.
The type of
ContingencyResponseType 1 contingency
responseAction RETURN_TO_BASE: re
response.
turn to base as
specified by the
contingencyGeograph
y, optionally heading
through the
contingencyExtraVolu
me. The USS may
issue an update to the
operation plan to
support this
maneuver.
OTHER: details given

in freeText property.
Time that this

location is
validTimeBegin DateTime 1
expected to be
first available.
Time that this

location is
validTimeEnd DateTime 1 expected to
become
unavailable.
To be used for
For human use, not for
additional
String 0..1 automating any
freeText comments as
process.
needed.
37
This may be thought of

as a ranking of the
potential landing sites
with all other factors
being held equal,
Optional though dynamic
numerical value conditions will likely
that can be used play a role in adjusting
in ranking the this ranking in real
preference of time by the USS or
this Operator. For
relativePreference Float 0..1
Contingency example, one
versus any Contingency may be
other within the significantly further
set of from the operation at
Contingency for a given time and, thus,
this operation. would be less
preferred than it might
be otherwise. Further
interpretation of this
field is left to the
operator and USS.
This is an
indicator that
In the planning stage
this particular
of an operation, this
ContingencyPla
array may be
n is valid for use
populated with
when the
relevantOperationVol Integer 1..* ordinals that
operation is
umes correspond to the
active in any of
ordinal values
the particular
supplied with each
noted
OperationVolume.
OperationVolu
mes.
This is the maximum

Supplementary
remaining flight time
endurance TimeDuration 1 endurance
for this contingency
time.
plan.
38
If responseAction is
LANDING or
RETURN_TO_BASE,
then this is the area
on the ground that
the UA will be
targeting for a
landing. The polygon
should be large
The enough to provide
geographical high confidence (for
Geometry 1
contingencyGeometry area for this some TBD value of
contingency. "high") that the
vehicle will land
within it, but
hopefully be no larger
(for some TBD value
of hopefully). If
responseAction is
LOITERING, this is the
3D-volume the UA will
stay within during
loitering.
This extra 4D-volume

Describes an
shall be
extra portion of
adjacent/overlapping
airspace, which
to the referred
might be
relevantOperationVol
needed in the
umes in the same
contingecy plan
manner as subsequent
if the
contingencyExtraVolu OperationVolume 0..* OperationVolumes
emergency
me must be
landing shall
adjacient/overlapping
take place
(see descriptive Notes
outside the
on the
original
operationVolumes
operation
property of the
trajectory.
OperationPlan).
Table 12: The ContingencyPlan data structure
5.6 The UasRegistration Data Structure

UasRegistration is the collection of registration data for UAVs.
Multiplicity
droneId String 0..1 Drone identifier.
39
Unique identifier
registrationId UUID 0..1 referring to a
registration.
An Internet- More details to come, however, it is

reachable URL for thought that this should be an endpoint
registrationLocation String 1
the registration allowing an unauthenticated GET to obtain
authority. metadata about the registrar.
Table 13: The UasRegistration data structure
5.7 The FlightDetails Data Structure

FlightDetails provides some flight related data of interest for an operation plan.
Multiplicity
0..1 Optional. For use by USS for

flightNumber String
identification purposes.
Optional. Allows to
0..1
flightType String distinguish different types of
flight.
0..1 Optional informative text Not used by the UTM System.

flightComment String
about the operation. Only for human stakeholders.
Maximum flight speed in

Double 0..1
maxFlightSpeedKnots knots.
Table 14: The FlightDetails data structure
5.8 The Priority Data Structure

The Priority data structure describes the priority of an operation plan (or of an operation volume). On
of the two optional priorityLevel attributes must be provided.
Multiplicity
Free text description of the priority

priorityText String 0..1
classification.
Priority may be expressed in this simple way,

priorityLevelSimple PriorityLevelSimple 0..1 allowing to classify the OP as Low-, Medium-,
or High-Priority flight.
40
Alternatively, the priority may be expressed

priorityLevelCorus PriorityLevelCorus 0..1 as one of the 8 priority levels defined in
Corus.
Table 15: The Priority data structure
5.9 The OperationTrajectory Data Structure

An OperationTrajectory defines a 4D trajectory to be flown, including the uncertainty.
Coordinate Reference System used for the

positionCRS EnumCRSType 1 horizontal dimensions of the trajectory
elements.
1 Coordinate Reference System used for the

altitudeCRS EnumCRSType
vertical dimension of the trajectory elements.
Maximum allowed horizonal deviation from

positionUncertainty float 1
individual trajectory elements.
1 Maximum allowed vertical deviation from

altitudeUncertainty float
Maximum allowed timing deviation from

timingUncertainty Duration 1
Indicates how the vertical dimension is defined

altitudeType EnumAltitudeType 1
in the trajectory elements.
trajectoryElements TrajectoryElement 1..* Ordered list of 4D points
Table 16: The OperationTrajectory data structure
5.10The TrajectoryElement Data Structure

A Trajectoryelement defines a single 4D position to be used in an OperationTrajectory.
Reference coordinate system as well as allowed tolerances (uncertainties) are defined in the
OperationTrajectory, valid for all TrajectoryElements.
latitude float 1 latitude value.
longitude float 1 longitued value.
41
vertical position Altitude or height value, depending on the

altitude float 1
value. altitudeType given in the OperationTrajectory.
1
time DateTime time value.
Table 17: The TrajectoryElement data structure
5.11The Mission Data Structure

A Mission is an administrative object, allowing to provide common information about flights that are
related to each other, e.g., as they are defined to achieve a common goal.
missionId UUID 1 Globally unique identification of a mission.
0..1 Time stamp indicating the begin of the

beginTime DateTime
mission.
Time stamp indicating the end of the

endTime DateTime 0..1
mission.
description String 0..1 Mission description.
0..1
contactDetails ContactDetails Contact details for the mission.
Additional descriptive information of the

publicInfo PublicInformation 0..1
mission.
Reference to Reference to operation plans sharing this

operationPlans 0..*
OperationPlan mission.
Table 18: The Mission data structure
5.12The PublicInformation Data Structure

PublicInformation allows to provide additional information allowed for public disclosure.
title String 0..1 Short public title for the operation plan.
description String 0..1 Public description of the operation plan.
Table 19: The PublicInformation data structure
42
5.13The OperationPlanState Enumeration

The OperationPlanState enumeration type specifies the possible states of an operation plan.
This operation is not yet approved. It may be

awaiting information from the operator, it may be in
PROPOSED Initial state of the operation plan. conflict with another operation and undergoing a
negotiation process, or for some other reason it is
not yet able to be declared PERMITTED.
Authority has given permission to

PERMITTED proceed (Certification Processes, SORA,
...)
Authorization of an OP may include the approval by

This operation has been deemed
multiple stakeholders. ATM may be one such
approved by the supporting USS. This
stakeholder.
AUTHORIZED implies that the operation meets the
requirements for operating in the
In some cases an OP may be AUTHORIZED without
airspace based on the type of
the approval of ATM (in cases where no ATM
operation submitted.
airspace is involved.
The OperationPlanState remains ACTIVATED even

when the drone flight gets ACTIVE or INACTIVE (this
ACTIVATED Operation is cleared for takeoff.
is indicated by the DroneFlightState; see
DroneFlightExchange service).
If the UAS and the crew will fly again, it would need
to be submitted as a new operation. A USS may
This operation is closed. It is not announce the closure of any operation, but is not
CLOSED airborne and will not become airborne required to announce unless the operation was
again. ROGUE or NONCONFORMING.
The closure reason is noted in the operation plan

attribute closureReason.
Table 20: The OperationPlanState enumeration
5.14The EnumClosureReason Enumeration

The EnumClosureReason enumeration type specifies the possible reasons for closing an operation
plan
NOMINAL Operation completed nominally.
43
REJECTED OP has been rejected by USSP, CISP or authority.
REVOKED OP has been revoked by USSP, CISP or authority.
Table 21: The PriorityLevelSimple enumeration
5.15The ContingencyCauseType Enumeration

The ContingencyCauseType enumeration type specifies the possible causes for contingency
operations.
LOST_C2_UPLINK Command and control connection from controller to drone was lost.
LOST_C2_DOWNLINK
Command and control connection from drone to controller was lost.
LOST_NAV Navigation equipment lost.
LOST_SAA
LOW_FUEL Not enough energy.
NO_FUEL Energy lost.
MECHANICAL_PROBLEM Mechanical problem.
SOFTWARE_PROBLEM Software problem.
ENVIRONMENTAL Environmental issues.
SECURITY Security issues.
TRAFFIC Other traffic.
LOST_USS
OTHER
ANY
Table 22: The ContingencyCauseType enumeration
5.16The ContingencyLocationDescriptionType Enumeration
44
The ContingencyLocationDescriptionType enumeration type specifies the possible ways to describe a

contingency plan.
Contingency location that is determined prior to launch and programmed onto

PREPROGRAMMED
the UA.
OPERATOR_UPDATED Contingency location that is (or will be) updated during operation by operator
(e.g., sent to UA).
UA_IDENTIFIED Contingency location that is identified to be safe to land by the UA itself.
OTHER Contingency location does not fit any of the defined categories.
Table 23: The ContingencyLocationDescriptionType enumeration
5.17The ContingencyResponseType Enumeration

The ContingencyResponseType enumeration type specifies the possible kinds of contingency
response actions.
The contingency operation will

LANDING
be landing.
LOITERING
The operation will loitering.
RETURN_TO_BASE The operation will return to base.
Additional details should be If this gets used often for similar events, Enumeration
OTHER
provided in freeText. will be updated with new value.
Table 24: The ContingencyResponseType enumeration
5.18The PriorityLevelSimple Enumeration

The PriorityLevelSimple enumeration type specifies three simple priority levels.
PRIO_LOW low priority
PRIO_MEDIUM
medium priority
PRIO_HIGH high prioroty
Table 25: The PriorityLevelSimple enumeration
45
5.19The PriorityLevelCorus Enumeration

The PriorityLevelCorus enumeration type specifies priority levels defined in the Corus Conops.
PRIO_1_EMERGENCY
PRIO_2_HOSPITAL
PRIO_3_AUTHORITIES
PRIO_4_URGENT_TRANSPORT
PRIO_5_INDUSTRY
PRIO_6_TRANSPORT
PRIO_7_FILMING
PRIO_8_LEISURE
Table 26: The PriorityLevelCorus enumeration
46
Figure 3: Operation Plan Services - Operation Plan Processing Response data structure diagram
5.20The OperationPlanProcessingResponse Data Structure

OperationPlanProcessingResponse is used to carry the result of evaluation or processing requests
for operation plans.
In case of a negative result, it may contain one or several alternative operation plans.
Type Multiplic Description

Property Note
ity
Indicates the result of evaluating

or processing an operation plan.
ProcessingResul
1..* In case of negative result, more
resultInformation tInfo
than one resultInformation may
be added.
Optional alternative Operation

Plans that may be proposed
instead of the evaluated see section on
operation plan, in case the Basic Operation
alternativeOperationP OperationPlan 0..* resultInformation.resultType is Plan data
lans other than OK. structures for a
description of
In case of OperationPlan.
resultInformation.resultType=OK,
this list shall be empty.
Operation plans to be rejected in

order to be able to accept the
given Operation Plan.
In case of conflicting operation
operationPlansToBeR UUID 0..* plans, the service provider may use
ejected this property to indicate that the
given OP could be accepted, if
other OPs (listed in this property)
would be rejected.
In this property,
the OperationPlanProcessingResp see section on
onse may contain the Basic Operation
OperationPlan for which the Plan data
< inherited >
OperationPlan 0..* evaluation/submission was structures for a
operationPlans
requested. description of
(inherited from OperationPlanRes
OperationPlanResponse data ponse .
structure)
47
All properties inherited from See common data

< inherited > ...
ServiceResponse. types.
Table 27: The OperationPlanProcessingResponse data structure
5.21The ProcessingResultInfo Data Structure

ProcessingResultInfo is used to carry information about the result of evaluation or processing
requests for operation plans.
Type Description
Property Multiplicity Note
Indicates the result of evaluating an

resultType EnumOperationPlanResultType 1 operation plan.
Textual description of the reason result.

For example, a textual description of the
rejection reason.
resultText String 0..1
In case of a positive resultType, this field

may be empty or omitted.
Table 28: The ProcessingResultInfo data structure
5.22The EnumOperationPlanResult Enumeration

The EnumOperationPlanResult enumeration type specifies potential results of an Operation Plan
processing.
OK The processing result is OK, i.e., the Operation Plan can be accepted.
CONFLICT_TRAFFIC
The Operation Plan cannot be accepted due to conflicting traffic.
The Operation Plan cannot be accepted due to a conflict related to airspace

CONFLICT_AIRSPACE
restriction.
The Operation plan cannot be accepted due to invalid data. E.g. invalid version,
INVALID_REQUEST forbidden
state transfer etc.

Table 29: The EnumOperationPlanResult enumeration
48
Figure 4: Operation Plan Services - Mission Response data structure diagram
5.23The MissionResponse Data Structure

MissionResponse is used to carry the result of query-operations asking for Missions.
Depending on the operation result, it may contain zero, one or several Mission objects.
Type Description
Property Multiplicity Note
Mission 0..* see section on Basic Operation Plan data

missions Mission data structure(s).
structures for a description of Mission.
< inherited
All properties inherited from See common data types.
> ServiceResponse.
Table 30: The MissionResponse data structure
5.24Common Data Structures Used in UTM Service Specifications
5.24.1NotificationEndpoint Data Structure
49

Multiplicity
5.24.2ServiceResponse Data Structure

Multiplicity
1
result OperationResult Indicates the result of the request to the service
0..1 Optional additional information to be provided in case

rejectReason String
of negative result
5.24.3OperationResult Enumeration
5.25Common Geometry Data Structures Used in UTM Service

Specifications
50
1 A geometric description of a Should be a 2-dimensional

area Geometry
Coordinate reference system used

(WGS-84, EPSG:4979)
2..* Collection of the coordinates,

coordinates Double
describing the geometry.
1 Type of geometry being Examples: Point, Polygon,

geometryType GeometryType
described by the coordinates. Polyhedron, etc.
51

ABOVE_MSL
World Mercator

EPSG3395_WGS84 CS. Euro-centric view of world excluding polar areas.
Axes: easting, northing (E, N).

UoM: metre.
52
OpenStreetMap, Bing, ArcGIS,
ESRI
Uses spherical development of ellipsoidal coordinates.
Geodetic CRS: WGS 84; Relative to WGS 84 / World Mercator (CRS code 3395)
EPSG3857_WGS84 errors of 0.7 percent in scale and differences in northing
Coordinate System: Cartesian of up to 43km in the map (equivalent to 21km on the
CS. ground) may arise.

UoM: metre.

EPSG4322_WGS72
UoM: degree.

Horizontal component of 3D system. Used by the GPS

EPSG4326_WGS84 satellite navigation system and for NATO military
2D CS.
geodetic surveying.

UoM: degree.

EPSG4760_WGS66
UoM: degree.
53

3D CS.
ellipsoidal height. Orientations:
north, east, up.

POINT Single point.
POLYGON
Polygon.
...
5.26Common Address Data Structures Used in UTM Service

Specifications
54
Figure 7: Common Address Data Types Used in UTM Service Specifications
5.26.1Address Data Structure
Address is used to represent an address of a person or an organization.
Multiplicity
addressLine1 string 1 First address line, typically the street name and house number.
Optional second address line, typically the unit, floor or

addressLine2 string 0..1
apartment number.
addressLine3 string 0..1 Optional third address line for country specific information.
city string 1 The name of the city.
county string 0..1 Optionally, the name of the county.
country string 1 The name of the country.
postCode string 1 Post code.
Table 39: Address Data Structure
5.26.2ContactDetails Data Structure
The ContactDetails data structure is used to collect contact information. A contact may be a Person,
State, Organisation, Authority, aircraft operating agency, handling agency etc.
1
firstName string First name of the contact.
1
lastName string Last name of the contact.
To establish best practices, the order of the

email addresses in the array should indicate
An optional array of email the order that they should be used.
email string 0..*
addresses.
The responsibility is on the USS providing the
email address to ensure it is valid and
operational.
55
To establish best practices, the order of the

An array of at least one
phone string 1..* phone numbers in the array should indicate the
phone number.
order that they should be used.
Optional fax number to

fax string 0..1
reach the contact
Any additional comments

comment string 0..* related to contact
information.
Table 40: ContactDetails Data Structure
56

Service Interface.
6.1 Service Interface OperationPlanRetrievalInterface

The service provider offers this interface to allow consumers to query operation plan data.
6.1.1 Operation getOperationPlanForId
A consumer calls this operation to explicitly request an operation plan by submitting the known id.

Parameter
Name
id Input UUID Identifier of an operation plan.
Query response, including the operation plan data, if

response Return OperationPlanResponse
the request was successful.
Table 41: Payload description of getOperationPlanForId operation
6.1.2 Operation getOperationPlanVersion

A consumer calls this operation to explicitly request a certain version of an operation plan by
submitting the known ids.

Parameter
Name
id Input UUID Identifier of an operation plan.
version Input UUID Version identifier.
Query response, including the operation plan data, if

the request was successful.
Table 42: Payload description of getOperationPlanVersion operation
57
6.1.3 Operation getOperationPlanForMission

A consumer calls this operation to explicitly request operation plan data belonging to a certain
mission.

Parameter
Name
missionId Input UUID Identifier of a mission.
Query response, including the operation plan data, if the

request was successful.
The OperationPlanResponse may contain a list of
OperationPlans: all OPs belonging to the mission.
Table 43: Payload description of getOperationPlanForMission operation
6.1.4 Operation getOperationPlanForGeometry

A consumer calls this operation to explicitly request operation plan data for a certain geographical
area.

Parameter
Name
geometry Input Geometry Geographical area of interest.

The OperationPlanResponse may contain a (potentially
empty) list of OperationPlans: all OPs for the area of
interest.
Table 44: Payload description of getOperationPlanForGeometry operation
6.1.5 Operation getOperationPlans

A consumer calls this operation to explicitly request operation plan data matching various criteria
58

Parameter
Name
Subset of an operation plan.

This allows to filter e.g., all OPs with a given
exampleOP Input OperationPlan
contactDetails, or all OPs for a certain drone registration
id.

The OperationPlanResponse may contain a list of
OperationPlans: all OPs matching the data given in the
exampleOP.
Table 45: Payload description of getOperationPlans operation
6.2 Service Interface OperationPlanSubscriptionInterface

The service provider offers this interface to allow consumers to subscribe/unsubscribe for operation
plan data.
6.2.1 Operation subscribeForOperationPlan
A consumer calls this operation to subscribe to receive operation plan data.

Parameter
Name

OperationPlan data.

Table 46: Payload description of subscribeForOperationPlans operation
6.2.2 Operation unsubscribe

A consumer calls this operation at the provider to unsubscribe from operation plan or no flight zone
data.
59

Parameter
Name
Which endpoint shall not be notified (anymore) in case of

new OperationPlans or No Flight Zones.

Table 47: Payload description of unsubscribe operation
6.3 Service Interface OperationPlanNotificationInterface

Once and while subscribed, consumer receives operation plan data via this interface.
6.3.1 Operation notifyOperationPlan
The service provider uses this logical operation (implemented by the consumer) to publish operation
plan data.

Parameter
Name
An operation plan matching the filter criteria provided in the

op Input OperationPlan
subscription
Table 48: Payload description of notifyOperationPlan operation
6.4 Service Interface OperationPlanManagementInterface

The service provider offers this interface to allow service consumers to manage operation plans. This
includes initial creation as well as modification of operation plans and missions; furthermore it
includes the life cycle management for operation plans (request for authorisation, request for
takeoff, cancellation, revocation, etc.)
6.4.1 Operation evaluateOperationPlan
This operation allows to evaluate an operation plan without actually submitting it for approval.
The service provider investigates the input operation plan and evaluates whether it can be accepted
as is, or whether there exist conflicts with other (planned) operations or with airspace restrictions.
If the operation plan is acceptable, this fact is simply given back as a result to the invoker, but the
operation plan is not pre-noted in any way.
60
If the operation plan is not acceptable, this fact is given back as a result to the invoker, and
alternative, acceptable operation plans may be added to the result (e.g., slightly modified in time or
space).

Parameter
Name
The "op" parameter specifies an OperationPlan

that shall be evaluated.
The return value provides the evaluation result.

In case of a negative result, the return value
<none> Return OperationPlanProcessingResponse may contain one or several alternative
OperationPlans, if the service provider is able
to make such proposals.
Table 49: Payload description of evaluateOperationPlan operation
6.4.2 Operation proposeOperationPlan
This operation allows to evaluate an operation plan and proposing it (i.e., scheduling it as a proposed
plan).
If the operation plan is acceptable, this fact is given back as a result to the invoker, and the operation
plan is pre-noted and published as a proposed plan to any subscribers.
If the operation plan is not acceptable, this fact is given back as a result to the invoker, and
alternative, acceptable operation plans may be added to the result (e.g., slightly modified in time or
space). Such alternatives should be pre-noted as proposed plans for a short amount of time.

Parameter
Name

that shall be evaluated and proposed.

Table 50: Payload description of proposeOperationPlan operation
61
6.4.3 Operation submitOperationPlan
This operation allows to propose an operation plan and submitting it (i.e., requesting for
authorisation) in one shot.
Furthermore, if there are no conflicts, the service provider initiates all necessary approval steps for
the operation plan.
If the operation plan is acceptable and can be approved, this fact is given back as a result to the
invoker, and the operation plan is published as an approved plan to any subscribers.
If the operation plan is not acceptable or cannot be approved, this fact is given back as a result to the
invoker.

Parameter
Name

that shall be evaluated and authorised.

Table 51: Payload description of submitOperationPlan operation
6.4.4 Operation updateOperationPlan
This operation allows to modify an operation plan by providing the updated operation plan data.
The service provider looks up the operation plans in order to find one which's identifier matches the
input operation plan. If there is a matching OP, the service provider tries to create a new version of
the OP, taking into account the values given in the input OP.
If the updates to the operation plan are acceptable, this fact is given back as a result to the invoker,
and the updated operation plan is published to any subscribers.
62
If the operation plan is not acceptable, this fact is given back as a result to the invoker, and no
publication takes place.

Parameter
Name
The "op" parameter specifies an updated version of an

operation plan.
<none> Return ServiceResponse The return value provides the operation result.
Table 52: Payload description of updateOperationPlan operation
6.4.5 Operation cancelOperationPlan
This operation allows to cancel an operation plan by providing the operation plan identifier.
input opId. If there is a matching OP, the service provider changes the state of this OP to "CLOSED"
and the closureReason to "CANCELLED".
If the operation was successful, this fact is given back as a result to the invoker, and the cancelled
operation plan is published to any subscribers.
If the operation plan is not successful, this fact is given back as a result to the invoker, and no

Parameter Name Direction Data Type Description
opId Input UUID Identifier of an operation plan that shall be cancelled.
Table 53: Payload description of cancelOperationPlan operation
6.4.6 Operation requestOperationPlanAuthorisation

This operation allows to request the necessary approval steps for a proposed operation plan by
providing the operation plan identifier.
input opId. If there is a matching OP, the service provider initiates the authorisation process for this
OP.
63
Note that authorisation may include several steps and involvement of several stakeholders and
therefore may take some time to compete.
If the operation was successful, this fact is given back as a result to the invoker, and the authorized
operation plan is published to any subscribers, as soon as the authorisation is complete.
If the operation is not successful, this fact is given back as a result to the invoker, and no publication
takes place.

opId Input UUID Identifier of an operation plan that shall be authorised.
Table 54: Payload description of requestOperationPlanAuthorisation operation
6.4.7 Operation revokeOperationPlan
This operation allows to revoke an operation plan by providing the operation plan identifier.
input opId. If there is a matching OP, the service provider changes the state of this OP to "CLOSED"
and the closureReason to "REVOKED".
If the operation was successful, this fact is given back as a result to the invoker, and the revoked

opId Input UUID Identifier of an operation plan that shall be revoked.
Table 55: Payload description of revokeOperationPlan operation
6.4.8 Operation requestTakeOff
This operation allows to request take-off permission for an authorized operation plan by providing
the operation plan identifier.
64
input opId. If there is a matching OP, and if the OP is in state AUTHORIZED, the service provider
changes the state of this OP to "TAKEOFFGRANTED".
If the operation was successful, this fact is given back as a result to the invoker, and the operation
plan is published to any subscribers.

Parameter
Name
Identifier of an operation plan for which takeoff is

opId Input UUID
requested.
Table 56: Payload description of requestTakeOff operation
6.4.9 Operation declareEndOfFlight
This operation allows to declare the end of flight for an active operation plan by providing the
operation plan identifier.
input opId. If there is a matching OP, and if the OP is in state TAKEOFFGRANTED, the service provider
changes the state of this OP to "CLOSED" and the closureReason to "NOMINAL".
If the operation was successful, this fact is given back as a result to the invoker, and the closed

Parameter
Name
Identifier of an operation plan that shall be declared

opId Input UUID
finished.
Table 57: Payload description of declareEndOfFlight operation
65
6.4.10Operation createMission
This operation allows to initiate a mission.
TBD
6.4.11Operation updateMission
This operation allows update a mission.
TBD
66

7.1 Sequence of events, cooperation with other services
Figure 8: OperationPlanExchange service operation sequence diagram
Note:
additional operations from other services, not only OperationPlanExchange service operations.
The figure above provides an example scenario for the OperationPlanExchange service. The scenario
assumes an Operation Plan Processing system at USSP1 providing the OperationPlanExchange
service. Another Operation Plan Processing system at a second USSP2 in this scenario plays the role
of a consumer of the OperationPlanExchange service, by subscribing to the first USSP. In addition, the
scenario includes a Drone Operator (in the role of a consumer of the OperationPlanExchange service
of USSP1). Furthermore, the scenario finally illustrates an example Conflict Resolution system
(providing the StrategicConflictResolution service) and an example ATC System (providing the
ProceduralATCInterface service).
 The scenario starts with the consumers of the OperationPlanExchange service subscribing for
operation plans:
67
o USSP2 subscribes at USSP1 in order to receive all operation plans (under the
assumption that USSP2 provides services in the same or overlapping geographical
area as USSP1)
o Drone Operator subscribes at USSP1 in order to get informed about operation plans
in a certain area.
 Drone Operator submits a tentative Operation Plan by using the
OperationPlanManagmentInterface of the OperationPlanExchange service
 USSP1 immediately publishes the (tentative) operation plan to all subscribers. So the second
USSP gets informed about the ongoing planning performed in the first USSP in an early stage.
 USSP1 may need to contact a Conflict Resolution System (via StrategicConflictReslution
service) in order to check the requested operation plans for conflicts with existing plans.
 USSP1 may need to contact the ATC System (via ProceduralATCInterface service) in order to
get an approval from ATC.
 As soon as all checks are done and the operation plan is approved, USSP1 will provide the
response to Drone Operator.
 At the same time, USSP1 will publish the OperationPlan to all subscribers.
7.2 Operation Plan State Machine
Figure 9: Operation Plan states - state transition diagram
68
8 References
This section identifies the documents (name, reference, source project) the Study Plan has to comply
to or to be used as additional inputs.
CFP Reference CEF-SESAR-2018-1, “Finnish-Estonian "Gulf of Finland" Very Large U-

[1] n/a
Space Demonstration”
Advanced
[2] Edition ICAO Doc 10039, Manual on System Wide Information Management (SWIM) Concept
(unedited)
SESAR 2020 GOF USPACE FIMS Design and Architecture, Appendix A Service
[3] 00.05.00 Description Templates, document SESAR 2020 GOF USPACE Service Documentation
Guidelines
Ed. EUROCONTROL Concept of Operations for U-space (CORUS), D6.2, Grant Ref. 763551,
[4] 00.02.RC1, 1 Call Ref. 2016 SESAR 2020 RPAS Exploratory Research Call (H2020 – SESAR -2016-1),
March 2019 Release Candidate 1
Global UTM Association (GUTMA) Flight Logging Protocol, https://github.com/gutma-

[5] n/a
org/flight-logging-protocol/blob/master/Flight_logging_protocol.md

[6] n/a
Protocol, https://github.com/hrishiballal/airtraffic-data-protocol-development
Federal Aviation Administration NextGEN Concept of Operations, Foundational

[7] V1.0 Principles, Roles and Responsibilities, Use Cases and Operational Threads, Unmanned
Aircraft System (UAS), Traffic Management (UTM)
Federal Office of Civil Aviation (FOCA), Swiss U-Space ConOps, U-Space Program
[8] 1.0
[9] 5th Ed. - 2016 ICAO Doc. 9750-AN/963, Global Air Navigation Plan (GANP) 2016-2030
Intel Corporation, Open Drone ID Message Specification, Draft Specification,

[10] 0.61.1
November 13, 2018
SESAR, European ATM Master Plan: Roadmap for the safe integration of drones into
[11] n/a
all classes of airspace
[12] n/a SESAR, eATM PORTAL, European ATM Master Plan, https://www.atmmasterplan.eu/
Efficient, safe and sustainable traffic at sea (EfficienSea2), a Horizon 2020 Project,
Grant Agreement No 636329
https://efficiensea2.org/wp-content/uploads/2018/04/Deliverable-3.6.Standard-
proposal-for-Maritime-Cloud-service-specification.pdf
69

[15] n/a
https://www.iala-aism.org/product/g1128-specification-e-navigation-technical-
services

[16] Ed. 1.0 EUROCONTROL-SPEC-0147, https://www.eurocontrol.int/publications/eurocontrol-
specification-atm-surveillance-system-performance
Federal Aviation Administration, Project Report ATC-323, Required Surveillance

1 November
[17] Performance Accuracy to Support 3-Mile and 5-Mile Separation in the National
2006
Airspace System
70
D2.4 Appendix C
Geographical zones / AIM
Exchange Service
Specification
Deliverable ID: D2.4-C
Grant: 101017689
Topic:
Air Mobility
Edition: 01.00.00
D2.4 APPENDIX C GEOGRAPHICAL ZONES / AIM EXCHANGE SERVICE SPECIFICATION


2


Document History
draft for D2.4
Copyright Statement
conditions.
3
GOF2.0
This Updated Service Specification is part of a project that has received funding from the SESAR Joint Undertaking under grant
agreement No 101017689 under European Union’s Horizon 2020 research and innovation programme.
Abstract
Exchange Service.
This document describes one of these Bridge Services, the Geozones Exchange service in a logical,
4
Table of Contents
Abstract ................................................................................................................................... 4
1 Introduction ............................................................................................................... 6
1.2 Scope ............................................................................................................................ 6
1.4 Background ................................................................................................................... 6
1.4.1 EUROCONTROL Concept of Operations for U-space (CORUS) .......................................................... 6
1.4.2 Institute of Aeronautics and Astronautics CONOPS .......................................................................... 8
1.4.3 Global UTM Association (GUTMA) .................................................................................................... 9
1.4.5 Swiss Federal Office of Civil Aviation (FOCA) .................................................................................. 10
1.4.7 SESAR-JU.......................................................................................................................................... 11
1.4.8 SESAR-JU DREAMS........................................................................................................................... 12
1.5 Operational systems .................................................................................................... 14
1.5.1 PANSA.............................................................................................................................................. 14
1.5.2 AVINOR ............................................................................................................................................ 20
1.7 List of Acronyms .......................................................................................................... 23
3.3 Operational Stakeholders ............................................................................................ 32
4.1 Service Data Model...................................................................................................... 35
4.2 Service Interface Specifications .................................................................................... 36
5 Service Provisioning ................................................................................................. 38
6 References ............................................................................................................... 39
5
1 Introduction
This document describes the Geozones / AIM Service for the GOF2 USPACE project on a logical
technology-independent manner, that is:
1.2 Scope
This document describes the Geozones / AIM service for the GOF2 USPACE project.
The Geozones / AIM service provides a means for the operational nodes of the GOF2 USPACE project
to exchange necessary situational awareness information and make them available for further
processing.
The Geozones / AIM service furthermore may be used in official specifications and recommendations.

This service specification is intended to be read by service architects, system engineers and developers
in charge of designing and developing an instance of the Geozones / AIM service.
1.4 Background
6
EUROCONTROL CORUS [4] elaborates in 5.3 Geo-fencing and aeronautical information as follows.
“Geo-fencing appears in U1, U2 and U3 and is successively refined. It is supported by aeronautical

information for drones. This table summarises the different features by level:
Service or Capability Level Features
Pre-Tactical Geo- U1 Information provided before flight. The user

Fencing should have
access to AIP and NOTAM defined geo-fences in

a form that can be used when planning and that
can be loaded onto the drone if it has geo-fence
fence features in its navigation system
On-drone Geo-Fencing U1 The ability of the drone to keep itself on the

correct side of a geo-fence by having geo-fence
definitions (location, time, height) within its
navigation system
Tactical Geo-Fencing U2 This service delivers to the pilot and /or drone
operator updates to and new definitions of
Geo-Fences occurring at any time, including
during flight. The creation of geo-fences with
immediate effect may (tbd) require that they
are defined outside the AIP. (See below)
Drone Aeronautical U2 U2 may (tbd) include a non-AIP repository of

Information Geo-Fences. The Drone Aeronautical
Management Information Management service includes all
information coming from such a source,
combined with information from the AIP and
NOTAMS together with any other drone
relevant sources.
Dynamic Geo-Fencing U3 This service delivers updates and new

definitions of geofences directly into the drone,
even in flight. This service relies on capabilities
of the drone in U3 to receive communications
from U-space and to deal with geo-fence
updates.
Geo-Fences may be defined, even today, using the existing aeronautical information publishing (AIP)
mechanism. A geo-fence may be defined as “Restricted Area”. The existing aeronautical information
publishing mechanism is linked the ‘AIRAC’ cycle of 28 days. The process is well established but requires
that changes, such as the definition of new geo-fences, are known weeks in advance. A “Danger Area”
might also be used and has the advantage that it can be defined in advance but left inactive and then
activated at short notice by a NOTAM. The Danger Area lacks the Restricted Area’s concept of “entry is
7
forbidden unless certain conditions are met” which is likely to be a necessary part of using geo-fences
to define geo-cages for some operations – as in the red airspace of section 4.1.
Creation of Geo-Fences requires accreditation. There needs to be a way for the relevant people or
organisations to create geo-fences and there needs to be a way for them to establish that they are the
relevant people and should have that ability. U-space will need tools and procedures for geo-fence
creation and maintenance.
U2 brings the idea of Geo-Fences with immediate, or near-immediate, effect. The authors are not sure
how these will be published, whether inside the AIP or outside, but that does not matter here.
Immediate effect geo-fences will be used when emergency situations occur, like the need for an air
ambulance to land, firefighters operating in an active fire area, or similar. U-space in U2 will have at
least one channel to send this information to every drone pilot immediately. Thus we require that the
U2 drone pilot is somehow connected to these communication channels and he/she monitors them.
The Emergency Management Service should signal to the pilot if an emergency has triggered the
creation of a geo-fence with immediate effect in the vicinity of the flight.
If the pilot is using a Traffic Information Service for his flight (it may be mandatory, tbd) then that should
signal to the pilot that the flight is the wrong side of a newly created Geo-Fence or when the flight
approaches a Geo-Fence.
If the remote piloting station has a map display, then it should be updated via the Drone Aeronautical
Information Management service to show any new Geo-Fence as soon as reasonably possible after its
creation.
The correct response to finding that the drone is on the wrong side of a newly created geo-fence will
probably depend on the exact situation but options might include landing, ditching, returning to base,
flying as directly as possible to exit the geo fence or flying in some specific, prearranged way expected
to minimise the chance of collision, such flying as at very low speed and very low altitude, or hovering.
CORUS awaits the recommendations of the relevant bodies.
U3 brings the direct communication of Geo-Fences to the drone. This augments the U2 service by having
the drone react without the need for the remote pilot to get involved. There will need to be a way to
inhibit this for those drone flights that have permission to cross or be inside any geo-fence. Or for
operators / pilots who prefer to maintain manual control. “
1.4.2 Institute of Aeronautics and Astronautics CONOPS
[5] Unmanned Aircraft Concept of Operation of the American Institute of Aeronautics and Astronautics
defines ANSP and UAS Operator responsibility as follows.
8
“…The ANSP defines and updates the airspace constraints as necessary in real time, for example if
airport configurations change or certain airspaces have to be closed. The interactions between the
ANSP and UAS operators/USS will be primarily governed through Interface Control Documents (ICD)
and Application Programming Interface (API) based integration of the components. This will create an
architecture that will foster collaboration and information exchange among multiple stakeholders. The
ANSP may add static or dynamic geo-fences or other means of airspace control and provide
notifications to operators and other stakeholders. The regulator/ANSP will also manage access to
controlled airspace. …”
1.4.3 Global UTM Association (GUTMA)
Global UTM Association (GUTMA) describes in the first version of the UAS Traffic Management
Architecture [6] the UAS Traffic Management System as follows in Figure 1. Aeronautical Info Service
is described between UAS Traffic Management System and ATM System(s).
9
Figure 1: GUTMA UAS TM
“FIMS is a gateway for data exchange between UTM participants and FAA systems, through which the
FAA can provide directives and make relevant NAS information available to UAS Operators via the USS
Network. The FAA also uses this gateway as an access point for information on operations (as required)
and is informed about any situations that could have an impact on the NAS. FIMS provides a mechanism
for common situational awareness among all UTM participants and is a central component of the
overall UTM ecosystem. FIMS is the UTM component the FAA will build and manage to support UTM
operations.”
The FAA defines a messaging service in its Concepts of Operations v1.0 - Appendix C - UTM Services -
Airspace Authorization Service[7] as follows.
“A service which provides airspace authorization from the Airspace Authority/Air Navigation Service
Provider to a UAS Operator.”
1.4.5 Swiss Federal Office of Civil Aviation (FOCA)
From the FOCA Concepts of Operations v1.0 [8], section 3.5.5 – Airspace Authorization Service:
“A service, which provides the needed authorizations to fly from the Airspace Authority/ANSP to a UAS
Operator. It fulfils following functions:
 To provide the opportunity for the pilot and/or the Operator to request an authorization.
 To automatically approve requests when possible
 To transmit authorization requests to competent authorities when automatic approval is not

possible
10
 To support the Air Traffic Control (ATC) or other relevant stakeholders in managing the
authorization requests
 To notify other relevant parties of issued authorizations
This service benefits the UAS Operator, the pilot, as well as the competent authorities. Airspace
Authorization will be managed digitally with efficiency gains for all actors involved.”
“Within the SWIM Global Interoperability Framework, the Information Exchange layer is instantiated
by ‘information services’ as is further explained. Information services ensure interoperability between
ATM applications which consume and provide interoperable information services. Consequently, the
concept of information service is a fundamental building block of SWIM which enables interoperability
through well-defined information exchanges.”
1.4.7 SESAR-JU
The European Commission identifies an increasing demand for a non-segregated use of airspace which
is being driven by a rapidly growing market of Very-Low-Level (VLL) airspace users, most of which are
expected to be drones.
Via the Roadmap for the safe integration of drones into all classes of airspace [9], within the European
ATM Masterplan [10], the European Commission seeks to ensure that this rapid growth of airspace use
happens in a safe and controlled manner.
 U-space foundation services,
 U-space initial services,
 U-space advanced services, and
 U-space full services.
These stages reflect the anticipated quick growth of demand for U-space services. The state of the art
is being validated throughout Europe via several Very Large Demonstrator (VLD) projects such as the
Error! Reference source not found. project.
The European ATM Master Plan describes the drone aeronautical information management as part of
U2 – U-Space initial services as follows.
“Drone aeronautical information management.
This service provides the operator with relevant aeronautical information for drone operations. It will
11
connect to the Aeronautical information service (AIS) to guarantee coherent information provision for
manned and unmanned operators.”
1.4.8 SESAR-JU DREAMS
The SESAR JU DREAMS U-Space scenarios [11]are describing in Scenario 6, Long range operations, the
aeronautical information service as follows.
“The U–space application requests the Drone aeronautical information management service (Drone
AIM) service information about the drones flying in the vicinity. The Drone AIM service updates the
information by requesting the Flight planning management service the active flight plans. As a bonus,
the U–space application could also provide information about the presence of general aviation traffic
to drone users, using the same interface.”
As described in chapter 5.2 Gap analysis of DREAMS Gap Analysis, [12], data comparison between
demand and supply was considered for further validation:
12
Figure 2: DREAMS Gap analysis extract [12]
13
Also within the GOF-U-space project, a thorough use-case centric analysis was brought underway
focusing on how to leverage a common data storage and -management for ATM and UTM. This
approach is highly important to satisfy needs for interoperability, stakeholder collaboration and data
quality. In this context, a strong focus was put on the storage and management of geofences as
airspace volume outer shells to convey geospatial restrictions for UTM operations.
Since AIXM (in its 5.1 version) constitutes a current industry standard to store and share aeronautical
static and dynamic information within a SWIM enabled environment, the GOF-U-space project did also
focus on assessing whether AIXM is suitable format to manage geofenced airspace volumes and
properties needed.
GOF2 Update:
Although AIXM-based services are still standard in legacy airspace management, moving to UAS
airspaces requires additional converters to provide data conforming to new data format.
1.5 Operational systems

1.5.1 PANSA
1.5.1.1 Geopraphical zones implementation

Legal background and assumptions
Airspace structures presented to UAS users on basis of art. 15 of the Regulation 2019/947 are
called UAS geographical zones.
Art. 15 - Operational conditions for UAS geographical zones
When defining UAS geographical zones for safety, security, privacy or environmental reasons,
Member States may: (a) prohibit certain or all UAS operations, request particular conditions for
certain or all UAS operations or request a prior operational authorisation for certain or all UAS
operations; (b) subject UAS operations to specified environmental standards; (c) allow access to
certain UAS classes only; (d) allow access only to UAS equipped with certain technical features, in
particular remote identification systems or geo awareness systems.
2. On the basis of a risk assessment carried out by the competent authority, Member States may
designate certain geographical zones in which UAS operations are exempt from one or more of the
‘open’ category requirements.
3. When pursuant to paragraphs 1 or 2 Member States define UAS geographical zones, for geo
awareness purposes they shall ensure that the information on the UAS geographical zones,
including their period of validity, is made publicly available in a common unique digital format.
Art. 18 – Tasks of Competent Authority
(f) making available in a common unique digital format information on UAS geographical zones
identified by the Member States and established within the national airspace of its State;
Common unique digital format will be published in the AMC to the Regulation 2019/947.
COMMISSION IMPLEMENTING REGULATION (EU) …/... of XXX on a regulatory framework for the
U-space (U-space regulation)
14
Art. 2 (1) ‘U-space airspace’ means a UAS geographical zone designated by Member States, where
UAS operations are only allowed to take place with the support of U-space services;
According to art. 5 (e) UAS geographical zones relevant to the U-space airspace and published by
Member States in accordance with Implementing Regulation (EU) 2019/947;
When Member States define UAS geographical zones for safety, security, privacy or environmental
reasons as provided for in Implementing Regulation (EU) 2019/947, they may impose specific
conditions for certain or all UAS operations or allow access only to UAS equipped with certain
technical features.
Aeronautical information data publication for UAS operators.
Before entering into force 2019/947 – static and dynamic airspace structures to UAS users.
Airspace structures published for legacy aviation were published in the same manner to UAS users.
The regulation 2019/947 changed the way of presenting data to UAS users introducing the concept
of geographical zones. In order to create consistency in the aeronautical data presented to the
UAS users, the legacy aviation airspace structures should be translated to the language of
geographical zones and new characteristics.
Note: The names of the geographical zones presented in this document are official in the certified
PansaUTM system and may be used as an example of possible way to tackle them into European
legislation.
15
The geographical zones which will be published solely for the purposes of UAS operations will be
not connected to existing airspace structures.
The approach proposed by PANSA also considers the needs of UAS Pilots. Based on the experience
gained in managing tactical approvals (more than 10 000), the hereby proposed Geozones concept
also includes information about the likelihood (probability) of obtaining approval to fly. Also
bearing in mind that there may be a need for an airspace defining only the boundaries of the U-
16
space, the proposal takes this need into account. Different type of geographical zone serve
different purposes.
The example of geographical zones types:
No Proposed Function / Description

name
1 DRA-RH restricted area for UAS with a high probability of obtaining approval for
the operations
2 DRA-RM restricted area for unmanned aerial vehicle systems with average
probability of obtaining approval for the operations
3 DRA-RL restricted area for UAS with a low probability of obtaining approval for
the operations
4 DRA-RL restricted area for UAS with a low probability of obtaining approval for
the operations
5 DRA-P prohibited area for UAS, in which UAS operations cannot be performed
6 DRA-I information area for unmanned aerial vehicles, containing information

necessary to ensure the safety of operations with the use of unmanned
aerial vehicles, including navigational warnings
7 DRA-T a restricted area for UAS, in which UAS operations may be performed
only with the use of UAS that meet the technical requirements indicated
by the Agency and under the conditions specified by the Agency, if such
conditions for a given zone have been determined
8 DRA-U a geographic zone for UAS where UAS operations can only be performed
with the support of specific, verified services provided in this area and
under the conditions specified by the Competent Authority, after U-
space regulation implementation – the U-space airspace
restricted area for UAS with a high probability of obtaining approval for the operations
All the proposed geographical zones could be used to address the general reasons for geographical
zones publications stated in art. 15 of Regulation 2019/947, namely: safety, security, privacy or
environmental reasons. The procedure of geographical zones publication is subject to competent
authority.
17
Overall Geozones naming convention with activity triggers
18
19
Figure 3 Table of proposed PANSA Geozones types mapping
*It should be taken into account the distinction between the entire volume of aeronautical R airspace
and only the protected area, such as e.g. building
1.5.2 AVINOR
In an integrated approach, geo awareness is provided for both UAS Operators and Air Traffic
Controllers in daily operations. Aeronautical information is combined with so called NDZ (No Drone
Zones) and displayed in map overlays, which are tailored for the user group.
NDZ can be retrieved from authorized sources, or manually created by authorized ATC personnel. They
are modelled as 4D volumes, can hold additional information such as labels, reasons,
restrictions/permissions, and metadata. For a short term NDZ, providing a 4D volume and very few
mandatory attributes are sufficient.
The aim is to reduce workload on controllers and operators. Focus is put on presenting go/no go
information, providing more details where relevant or on user request/action (e.g. for AIM data).
The UTM system uses NDZ to assist controllers in operation plan processing, e.g. in approval processes
or in case airspace is closed, notifying affected operations.
Term Definition
Alerting The Geoawaraness function shell provide the remote pilot with Geowareness
warning alert when a potential or actual breach of airspace restrictions (as defined
by the UAS Geozone information) is detected, either in horizontal plane in vertical
axis or both.
The time or threshold to alert shall be defined by the manufacturer, taking into
account the subsequent reaction time and trajectory correction manoeuvre span, in
order to avoid the UAS penetrating the forbidden zone.
Margin on limits (meaning additional distance to the border) shall be defined and
implemented by the manufacturer, taking into account the accuracy of the UAS
position/altitude measurement which is compared to the geographical limit. [25]
Alerting as described here is a conformance service, which should be combined with

telemetry service, not Geozones service.
UAS geographical 4D part of airspace defined as geoshape with vertical projection limits and time
zone window, established by the competent authority that facilitates, restricts or
excludes UAS operations in order to address risks part [24]
20
External Data Describes the semantics of the domain (or a significant part thereof) by defining data
Model structures and their relations. This could be at logical level (e.g., in UML) or at
physical level (e.g., in XSD schema definitions), as for example standard data models.
Geofencing The overall Geo-fencing provides the capability to use airspace volumes (geographic
fences) to control operations of UAS. [13]
Old umbrella term for defining airspaces function (it made a sense when only NFZs
were used).
Geoshape A series of geographical coordinates and dimensions that define a geometrical shape
by means of polygons or circles.[25]
While a term ‘circle’ is widely used in industry, its mathematical definition - every
point on circle is equistand to centre – and projecting it on ellipsoid/geoid causes
problems. Implementations of machine intersections/within checks and HMI display
usually interpolates curves to lines, and due to lack of standard conversion
definition, it may yield different results.
Height/Altitude The Geozone data format enables to set per zone lower/upper altitude limits (Above
limits Mean Sea Level) or heights (Above Ground Level). The reference and unit of
measurement are sent along with the data. [25]
Message Describes the principles how two different parts of a message passing system (in our
Exchange Pattern case: the service provider and the service consumer) interact and communicate with
each other. Examples:
provider in order to obtain certain information; the service provider provides the
requested information in a dedicated response.
In the Publish/Subscribe MEP, the service consumer establishes a subscription with

the service provider in order to obtain certain information; the service provider
publishes information (either in regular intervals or upon change) to all subscribed
service consumers.
Operational An activity performed by an operational node. Examples of operational activities

Activity are: Route Planning, Route Optimization, Logistics, Safety, Weather Forecast
Provision, …
Operational A structure of operational nodes and associated operational activities and their
Model inter-relations in a process model.
Operational Node A logical entity that performs activities. Note: nodes are specified independently of
any physical realisation.

Provider, …
21
Service The provision of something (a non-physical object), by one, for the use of one or
more others, regulated by formal definitions and mutual agreements. Services
involve interactions between providers and consumers, which may be performed in
a digital form (data exchanges) or through voice communication or written
processes and procedures.
Service Data Formal description of one dedicated service at logical level. The service data model
Model is part of the service specification. Is typically defined in UML and/or XSD. If an
external data model exists (e.g., a standard data model), then the service data model
shall refer to it: each data item of the service data model shall be mapped to a data
Service Design Documents the details of a service technical design (most likely documented by the
Description service implementer). The service design description includes (but is not limited to)
a service physical data model and describes the used technology, transport
mechanism, quality of service, etc.
Service Instance One service implementation may be deployed at several places by same or different
service providers; each such deployment represents a different service instance,
being accessible via different URLs.
Service Instance Documents the details of a service implementation (most likely documented by the
Description service implementer) and deployment (most likely documented by the service
provider). The service instance description includes (but is not limited to) service
technical design reference, service provider reference, service access information,
service coverage information, etc.
Service Interface The communication mechanism of the service, i.e., interaction mechanism between
service provider and service consumer. A service interface is characterised by a
message exchange pattern and consists of service operations that are either
allocated to the provider or the consumer of the service.
Service Operation Functions or procedure which enables programmatic communication with a service
via a service interface.
Service Physical Describes the realisation of a dedicated service data model in a dedicated
Data Model technology. This includes a detailed description of the data payload to be exchanged
using the chosen technology. The actual format of the service physical data model
depends on the chosen technology. Examples may be WSDL and XSD files (e.g., for
SOAP services) or swagger (Open API) specifications (e.g., for REST services). If an
external data model exists (e.g., a standard data model), then the service physical
22
data model shall refer to it: each data item of the service physical data model shall
be mapped to a data item defined in the external data model.
In order to prove correct implementation of the service specification, there shall

exist a mapping between the service physical data model and the service data
model. This means, each data item used in the service physical data model shall be
mapped to a corresponding data item of the service data model. (In case of existing
mappings to a common external (standard) data model from both the service data
model and the service physical data model, such a mapping is implicitly given.)
Service Provider A service provider provides instances of services according to a service specification
and service instance description. All users within the domain can be service
providers, e.g., authorities, organizations (e.g., meteorological), commercial service
providers, etc.
Service Describes one dedicated service at logical level. The Service Specification is
Specification technology-agnostic. The Service Specification includes (but is not limited to) a
description of the Service Interfaces and Service Operations with their data payload.
The data payload description may be formally defined by a Service Data Model.
Service Producers of service specifications in accordance with the service documentation

Specification guidelines.
Producer
Service Technical The technical design of a dedicated service in a dedicated technology. One service
Design specification may result in several technical service designs, realising the service
with different or same technologies.
Service List and specifications of allowed technologies for service implementations.

Technology Currently, SOAP and REST are envisaged to be allowed service technologies. The
Catalogue service technology catalogue shall describe in detail the allowed service profiles,
e.g., by listing communication standards, security standards, stacks, bindings, etc.
Spatial A service specification is characterised as “spatially exclusive”, if in any geographical

Exclusiveness region just one service instance of that specification is allowed to be registered per
technology.
Table: Glossary of terms

Acronym Definition
23
HMI Human Machine Interface
JSON JavaScript Object Notation
Table: List of acronyms
24
The purpose of this chapter is to provide a unique identification of the service and describe where the
service is in terms of the engineering lifecycle.
Name GeozonesExchangeService
ID urn:gof:services:GeozonesExchangeService
Version 2.0
Description An information exchange service which provides Geozones information
Keywords Airspace, Geozones, AIM
2020-2021 The Frequentis Group

Architect(s)
2020-2021 Droneradar Sp. z o.o.
Status Provisional
Table: Service Identification
25

The table below lists applicable existing requirements for the Geozones service.
Requirement Requirement Requirement Text References

Id Name
[R-1] Common At all times, all airspace users as well as ATC shall CORUS [4],
Situational operate on the same common set of data, during 4.1.1.2 Amber
Awareness pre-flight planning stages as well as during all airspace;
stages of flight operations.
B1-RPAS [17];
CEF-SESAR-
2018-1 [1],
Objective O5
[R-2] SWIM The implementation of a UTM Flight Information CEF-SESAR-

Management System (FIMS) shall be based on an 2018-1 [1], 5.3.4
ICAO SWIM-compliant architecture. Overall
approach and
methodology
[R-3] Interoperability There shall be an implementation of a Flight ICAO Doc 10039

Information Management System (FIMS) which [2];
ensures that, at all times, emerging unmanned
traffic management systems and existing CEF-SESAR-
technologies from manned operations can 2018-1 [1],
exchange any data required to support such Objective O6;
common situational awareness, be it for drone
CEF-SESAR-
operations in areas where established ATC
2018-1 [1], Table
procedures apply, or in zones outside established
8 – Key
ATC.
Challenges
[R-4] Regulatory The U-space concept shall allow regulators to

Framework define a framework to pro-actively steer
unmanned traffic and declare restricted or closed
areas for unmanned aviation. These properties
may be permanent or activated according to
schedules or following ad-hoc notice. Regulation
is desired i.e. for the purpose of protection of
critical infrastructure, privacy of residents, noise
abatement, natural conservation or security
concerns. The regulator may offer a granular
26

Id Name
definition of rules and procedures applicable for

restricted areas.
[R-5] Georeferenced Restrictive airspace is to be defined as

volumes georeferenced volumes with altitude thresholds
to offer maximal flexibility.
[R-6] Static Data There shall be a single source for static

Usage aeronautical data provision for pre-flight and
inflight operations to be used for both, the U-
space as well as legacy aviation.
[R-7] Static Data Static Data shall be maintained by dedicated local

Management ANSP in close collaboration with the local
regulators and other relevant authorities. The
Static Data maintenance shall follow the
established process of data origination, data
management and data provision.
[R-8] Dynamic Data There shall be a single source for dynamic

Usage aeronautical data provision to be referenced for
both, the U-space as well as manned aviation.
[R-9] Dynamic Data Dynamic Data feeds relevant for unmanned

Management aviation only , shall be retrieved by the ANSP as a
for U-Space trusted source input (e.g. a notification input
from a public safety control centre) and
automatically processed to the data store.
[R-10] Error Handling Dedicated ATM supervisors in the respective

in Data Feeds responsible area control centres or TMAs shall
have access to an error queue to manually
manage any inconsistences deriving from ad-hoc
restrictions to certain areas for unmanned
aviation.
[R-11] Incident Registered aircraft (trusted source with privilege

Management access) shall be able to trigger automated
creations of restricted geofence volumes once
they are involved in an incident inspection and
transmit a data message with GML and radius
information. This will allow a faster notification to
other unmanned airspace users.
[R-12] Alert In case an area (volume) has been restricted by

the regulator or ad-hoc by public safety, etc., an
alert shall be sent to all U-space users currently
27

Id Name
planning to depart, transit or arrive at the defined

and recently restricted geofence.
[R-13] U-Space Flight Flight Plans shall be validated against established

Planning airspace volumes, their status and other airspace
restrictions through which the unmanned aircraft
is planning to fly. In case of a regulatory
restriction, an alternative routing shall be offered
to avoid restricted areas.
[R-14] Data Quality All data consumed by the U-space shall be ADQ European
Assurance grade information (according to EU-Regulation Regulation
73/2010), thus ensuring the highest level of data 73/2010 & ICAO
quality for all airspace users regardless of Annex 15
manned or unmanned operations.
[R-15] Basis for Open The U-space concept shall be designed such as to SESAR Drone
Market ensure a well-established line of authority while Roadmap [9],
at the same time ensuring that an open market Foreword, 4.1
for VLL services may develop. and 4.2;
U-space
Blueprint [18],
Benefits to
European
society and
economy;
CEF-SESAR-
2018-1 [1], Table
8 – Key
Challenges
[R-16] Open Interfaces Any interface and protocol hence must be openly CEF-SESAR-
defined and its definition be freely accessible in 2018-1 [1], Table
order to ensure the lowest level of obstruction 8 – Key
for an open VLL airspace use market to develop. Challenges
[R-17] Latency The AIXM store shall respond with minimal

latency to not delay changes in airspace volume
configuration and restrictions changed ad-hoc in
daily operations.
[R-18] UAS Every unmanned aircraft shall be identifiable by

Registration UTM and ATM and relevant State authorities.
Next to the unique registration identifier,
28

Id Name
information on the type of aircraft shall also be

transmitted taccording to EASA specification
[R-19] Audit Trail Any creation, update, withdrawal or exchange of

data and notifications/alerts shall be logged in a
detailed audit trail to be able to allow complete
and transparent recovery of the history of
actions.
Table 1: Requirements for the Geozones service

3.2.1.1 ICAO SWIM

3.2.1.2 AIXM – Aeronautical Information Exchange Model

To comply with ICAO global and regional requirements for the provision for aeronautical information
in the context of the evolution towards SWIM, AIXM is aiming to enable the provision of aeronautical
information in digital format. [14][12]
The following main information areas are in the scope of AIXM:
 Aerodrome/Heliport including movement areas, services, facilities, etc.
 Airspace structures
 Organisations and units, including services
 Points and Navaids
 Procedures
 Routes
 Flying restrictions
AIXM 4.5
AIXM 4.5 was published in 2005, as an update of an earlier AIXM 3.3 version, which was originally
developed by Eurocontrol for the needs of the European AIS Database (EAD) project. It comprises an
entity-relationship data model (called "AICM") and an XML Schema.
29
AIXM 4.5 is still in use in many systems around the world, in particular for the coding of a subset of the
static aeronautical data.
AIXM 5.0
AIXM 5.0 constituted a significant leap-forward in the evolution of the model. Starting from the
experience accumulated with the operational implementation of the earlier versions, in particular
AIXM 4.5, the objective was to take advantages of established information engineering standards, in
particular Unified Modelling Language (UML) and the ISO-OGC standards for geographical information
encoding and provision.
Main differences between AIXM 4.5 and AIXM 5 are given bellow:
Topic AIXM 4.5 AIXM 5
Data Scope Only Static Data Static and Dynamic Data,

enabling Digital NOTAM
Geographical Elements XML XML/GML

(ISO standard for geometry)
Temporality Temporality is a property of Temporality is a property of

the message the aeronautical feature,
Supports only static data Supports both static and
dynamic data
Model Extensibility Limited extensibility Defined extensibility

(part of local system) concept for the AIXM
Schema
Current version: AIXM 5.1 /5.1.1
Followed soon (in 2010) as an updated version of the initial AIXM 5.0. Many existing implementations
have made the transition from AIXM 4.5 to AIXM 5.1 and newly developed AIS systems use AIXM 5.1.
3.2.1.3 FIXM – Flight Information Exchange Model

The ICAO Flight and Flow Information for a Collaborative Environment concept provides a globally
harmonized process for planning and providing consistent flight information. It is guided by the
requirement to eliminate or reduce the limitations of the present Flight Plan and to accommodate the
future environment detailed in the Global Air Traffic Management Operational Concept.
FIXM is one component belonging to the Information Exchange Models layer of the SWIM Global
Interoperability Framework described by the ICAO SWIM concept (ICAO Doc 10039), which is being
refined by the ICAO Information Management Panel (IMP). FIXM therefore monitors the work and
conclusions of this panel and will align over time with any relevant recommendations from this panel,
as appropriate. [15]
The current version of FIXM format is v4.1.0 and was released in December, 2017.
30
3.2.1.4 IWXXM – ICAO Weather Information Exchange Model

The Weather Information Exchange Models and Schema are designed to enable a platform
independent, harmonized and interoperable meteorological information exchange covering all the
needs of the air transport industry.
The WXXM follows the GML object-property model, which requires the properties of objects to be
encapsulated by a simple type (domain value). Should a ‘property’ consist of a complex object or
feature, the relationship must be represented through the use of an association. [16]
3.2.1.5 Network Availability Coverage

New service: Information about Network availability (Coverage) in 4D airspace - DIAMETOR
In order to enable Beyond Visual Line Of Sight (BVLOS) operations at scale, UAVs need reliable
connectivity. To ensure that flight planning can include information on where such connectivity is
available, additional data from connectivity providers is required.
In particular, for safety it is necessary to understand where cellular coverage is available to support
the needs of the mission. “Coverage” implies a range of requirements such as signal level, interference,
dynamic handover/switchover behavior and others to enable a minimum connectivity performance
along a flight route in a technology and spectrum independent manner. “Coverage” for a
communication service provider (CSP) is also a synonym for “signal availability”, whereas in aviation
terms it is typically a combination of sufficient availability, continuity, latency and integrity [EUROCAE
ER012, RTCA DO 377].
Interfaces are being established to harmonize the data exchange between CSPs and the aviation eco-
systems.
3.2.1.6 ASTM UTM Protocol

Based on publicly available OpenAPI specification, new ASTM protocol draft is similar to ED-269 but
more concentrated on American/FAA approach, and little bit less suitable for GOF2
Source: https://github.com/astm-utm/Protocol
3.2.1.7 ISO/DIS 23629-7

In 2020 new ISO standard for UAS traffic management emerged. Important part for the scope of this
document is ISO/DIS 23629-7: Data model for spatial data, (final draft stage at the moment of writing
this document).
The standard is rather simple and format-agnostic. Supported airspace attributes are:
 Identifier
 Generate time
 Disappearance time
 Maximum height
 Minimum height
 Type of height
31
 Shape (polygon or circle)
 Location (centroid)
 Administration contact details
 Conditions for operation
 Availability of UTM services
 Type of airspace
In the light of above requirements, and missing attributes – especially time-related (I.e. missing
activation times) - GOF 2.0 Geozones data-model should be a superset of ISO/DIS 23629-7 format.
As a side note: aforementioned standard also defines other important entities, like obstacles, flight
routes, take-off and landing areas, CNS coverage and dynamic phenomena, but they are beyond of the
scope of this document.
3.2.1.8 ED-269
Another new document is EUROCAE ED-269 - ‘Minimum Operational Performance Standard for
Geofencing’. It is probably most mature approach, supporting most of the requirements we’ve met
during development of operational systems.
 Most important aspects are:
 Clearly defined format
 Support of multiple airspace volumes per airspace,
 Support of airspace activity periods.
 Services definition: both Pub-Sub and retrieval/updateRetrieval
Although there are some relatively minor issues within the format, we recommend to use it as a base
of GOF 2.0 geozones service(s). For more in-depth view see chapters related to Service
implementation.
3.3 Operational Stakeholders

Aeronautical information comprises both dynamic and static data enabling safe navigation for airspace
users.
The data usually designated by the term ‘Static Data’ is the data known to the aviation world and
documented in publications such as AIP, e.g. FIR(s), Aerodromes, Navigation Aids, Areas, Maps, Rules,
Subjects to which a NOTAM may be related and other aeronautical information such AIC, etc.
Static data are long-term data and are updated according to AIRAC system that is a stringent and
lengthy process involving multiple stakeholders. All data must also undergo a four-eyes principle for
manual updates and business rule and CRC checks for structured data uploads. ICAO Annex 15 and the
EU Regulation 73/2010 govern the collection, processing and provision of aeronautical data.
32
Dynamic data is a critically important information distributed at short notice as NOTAM and Pre-Flight
Information Bulletin. NOTAM is a notice filed with an aviation authority to alert aircraft pilots of
potential hazards along a flight route or at a location that could affect the safety of the flight.
Flight plan, changes thereto and Meteorological information (OPMET) are another type dynamic data.
Meteorological reports are related to a specific time and location and shall be updated at specific
period. OPMET shall be available at all phases of flight.
Flight plan and its changes are related to specific flight and indicate the status of flight (submitted,
modified, current, closed, cancelled).
Different stakeholders are involved in update of OPMET and Flight Plan data at different phase of flight
(e.g. Met Office, ATS units, ATC). The way of communication differs at each phase of flight: AFTN
(NOTAM, FPL), Web page (PIB), radio (VCS), data-link (CPDLC).
The reporting of static and dynamic aeronautical data involves a stringent origination, maintenance
and publication process to ensure data quality and accurate data flow. Information is originated from
the following sources:
 Survey Data (Terrain and Obstacle Data) from civil engineers
 Sensors
 Airport Authorities
 Civil Aviation Authorities / Regulating Bodies
 ANSPs (e.g. for Instrument Flight Procedure and Airspace Design)
 Military Data (on no-fly areas, etc.)
 International Organisations (e.g. Eurocontrol Airspace Use Plan, Network Manager, etc.)
 EAD – European AIS Data Base
In the U-space, unmanned aviation must also consume relevant static and dynamic data to gain
situational awareness on the aeronautical and physical surroundings along the actual or planned flight
path as well as their current operational status and provide safety at area defined by flight plan.
Obviously, weather is also an important factor with massive impact on flight performance and safety.
For unmanned aviation static/dynamic data is not limited by airspace volumes, restrictive airspaces.
Additional information shall be provided by U-AIM such protected areas (airports, prisons) public areas
(schools, stadium, park) etc.
As in manned aviation, drone operators shall validate their flight plans against the actual (real-time)
status of the aeronautical and physical entities along the planned trajectory. Obviously not all
information used in manned aviation will be relevant for drones. The following data are considered
key to allow drones to operate in a unified airspace:
 Obstacle/terrain data
 Airspace reservation/activation (volumes defined by vertical and horizontal limits and

Geoshape data) to convey procedures and limitations to manned and unmanned traffic.
33
 Points – predefined (published) in U-AIM points that could be used in flight plan, similar with
VFR points published in AIP (entry/exit CTR VFR points etc).
 Airspace usage criteria: definition what operation/separation is allowed and what aircraft
types (or even aircraft registration) with what type of equipment requirements are established
(eg. ADS-B) in the respective airspace
 Flight Information of manned aircraft, particularly GAT aviation in uncontrolled airspace.
 Weather Information: global weather and microclimatic conditions for flight conditions and
drift calculations
While obstacles/terrain are considered static data, airspace volumes may have permanent and
dynamic nature i.e. some areas are permanently restricted when some are available for drone
operations and others are activated ad-hoc or on a pre-defined schedule. Some dedicated drone
operators (Police, SAR) shall be able to create ad-hoc geo-fences for special missions. Thus, the U-
space users must consider the current operational status of the geofences during pre-flight planning
phase (when filing the flight plan) as well as in-flight (so to react on ad-hoc activations of restrictions).
Alerts to the drone pilot and/or its FMS is therefore key. It should be possible to obtain airspace status
data from U-AIM at post-flight phase when it is required by authority for investigation.
Information needed for drone operations is originated following the standard process for data
origination and therefore subject to EU-Regulation 73/2010 and ICAO Annex 15 quality assurance.
However, given the nature of unmanned traffic and its operation in very low altitude, the standard
NOTAM process is considered not sufficient to the U-space concept. Ad-hoc airspace reservation and
activations shall be possible for drone operators and may include:
- restrictions for volumes representing event arenas (e.g. stadiums during a match),
- incident sites (e.g. a roadside accident, search and rescue activity, etc.)
- public safety announcements (e.g. during demonstrations, etc.)
- and many more
Such creation, change or withdrawal of restricted volumes must be performed by trusted sources
outside the usual context of aviation i.e. the public safety control centre, the city government or even
sensors in case of a drone accident. This can be achieved by providing a simple, map-based Geofence
Creation HMI. Incoming data transmissions to dedicated ANSP FIMS shall be processed automatically
unless of a business rule validation error. A fall-back process on ANSP side shall therefore be elaborated
to ensure that errors from incoming data origination can be manually corrected at all times to ensure
a swift exchange of information to all airspace users. A NOTAM shall only be published in case the
originated information is also of use for manned aviation. Otherwise, a notification/alert to the drone
operators and/or their FMS is sufficient. Dynamic geofence information is also subject to ICAO Annex
15 and EU Regulation 73/2010 data quality regulations and must therefore pass business rule when
provided to the central store.
34
4 Service Overview
This chapter aims at providing an overview of the main elements of the service. Architectural elements
applicable for this description are:
 Service: the element representing the service in its entirety.
 Service Interfaces: the mechanisms by which a service communicates. Defined by allocating

service operations to either the provider or the consumer of the service.
 Service Operations: describe the logical operations used to access the service.
 Service Operations Parameter Definitions: identify data structures being exchanged via Service
Operations.
The above elements may be depicted in one or more diagrams.
4.1 Service Data Model

This section describes the information model, i.e., the logical data structures to be exchanged between
providers and consumers of the service.
35
Figure (x). UAS GEOGRAPHICAL ZONE DATA MODEL (src: ED-269.pdf chapter 8 figure 2)
ED-269 based data-model supports most of the foreseen GOF 2.0 requirements, like multiple airspace
volumes, activity time management and per-zone operational rules. There are still some relatively
minor issues to be solved or reported during GOF 2.0 implementation like
 importing/mapping legacy AIXM-based airspaces (different timeslice relation), ED-269 7 chars

limit for airspace identifier, AIXM curves support and alike)
 Circle support implementation.
 Polygon with holes implementation
 FUA integration
4.2 Service Interface Specifications

Overview
Service Interface Specifications should be replaced with new ones, and should follow ED-269 specs,
possibly with some changes/extensions due to GOF2.0 scope/implementation.
36
Figure (x). INTERFACES OVERVIEW (src: ED-269.pdf chapter 9 figure 4)
Figure (x). SUBSCRIPTION STATES (src: ED-269.pdf chapter 9 figure 5)
ED-269 based interfaces supports most of the foreseen GOF 2.0 requirements, I.e. defines pub-sub
mechanism combined with queried retrievals for data sync
During GOF 2.0 implementation we should check if the there are some extra interfaces needed to solve
possible issues with implementations
 Batch updates on AIRAC imports, per-type operational rules changes and alike
 Short-term airspace (PANSA ‘alerts’, FREQUENTIS ‘dynamic UVR’)
 Optimized queries for operation flight plans support
37
5 Service Provisioning
Left Empty.
38
6 References
NOTE: The list of references provided hereafter is for guidance. Before the documents are delivered
to the SJU, please make sure that you are listing the latest applicable version of the relevant references
as in the Programme Library.
Nr. Version Title
[1] n/a CFP Reference CEF-SESAR-2018-1, “Finnish-Estonian "Gulf of Finland" Very Large
U-Space Demonstration”
[2] Advanced ICAO Doc 10039, Manual on System Wide Information Management (SWIM)
Edition Concept
(unedited)
[3] 00.05.00 SESAR 2020 GOF2 USPACE FIMS Design and Architecture, Appendix A Service
Description Templates, document SESAR 2020 GOF2 USPACE Service
Documentation Guidelines
[4] Ed. EUROCONTROL Concept of Operations for U-space (CORUS), D6.1, Grant Ref.
01.00.00, 763551, Call Ref. 2016 SESAR 2020 RPAS Exploratory Research Call (H2020 –
25 June SESAR -2016-1)
2018
[5] n/a Unmanned Aircraft System Traffic Management (UTM) Concept of Operation
American Institute of Aeronautics and Astronautics
[6] V1.0 GUTMA UAS Traffic Management Architecture
April 2017
[7] V1.0 Federal Aviation Administration NextGEN Concept of Operations, Foundational

Principles, Roles and Responsibilities, Use Cases and Operational Threads,
Unmanned Aircraft System (UAS), Traffic Management (UTM)
[8] 1.0 Federal Office of Civil Aviation (FOCA), Swiss U-Space ConOps, U-Space Program
[9] n/a SESAR, European ATM Master Plan: Roadmap for the safe integration of drones
into all classes of airspace
[10] n/a SESAR, eATM PORTAL, European ATM Master Plan
[11] V1.0 SESAR-JU, DREAMS U-Space Scenarios
12-2018
[12] 00.01.00 SESAR-JU, DREAMS, D4.2 - Gap Analysis,
09- 2018
39
[13] V 1.0 EUROCAE,White Paper on Geofencing and Definitions
[14] April 2019 Aeronautical Information Exchange Model, http://aixm.aero/
[15] April 2019 Flight Information Exchange Model, www.fixm.aero
[16] April 2019 ICAO Weather Information Exchange Model,
[17] 5th Ed. - ICAO Doc. 9750-AN/963, Global Air Navigation Plan (GANP) 2016-2030
2016
[18] 2017 SESAR-JU, U-space Blueprint,
[19] n/a IALA specification for e-navigation technical services
[20] Ed. 1.0 EUROCONTROL Specification for ATM Surveillance System Performance,
EUROCONTROL-SPEC-0147,
[21] 1 Nov. Federal Aviation Administration, Project Report ATC-323, Required Surveillance
2006 Performance Accuracy to Support 3-Mile and 5-Mile Separation in the National
Airspace System
[22] EfficienSea2, a Horizon 2020 Project, Grant Agreement No 636329
https://efficiensea2.org
https://efficiensea2.org/wp-content/uploads/2018/04/Deliverable-
3.6.Standard-proposal-for-Maritime-Cloud-service-specification.pdf
[23] IALA specification for e-navigation technical services
serviceshttps://www.iala-aism.org/product/g1128-specification-e-navigation-
technical-services
[24] C(2021) COMMISSION IMPLEMENTING REGULATION (EU) …/664 of XXX on a regulatory

2671 final framework for the U-space
[25] June 2020 ED-269 Minimum Operational Performance Standard for Geofencing
40
D2.4 Appendix D
Registration Service
Specification
Deliverable ID: D2.4-D
Grant: 101017689
Topic:
Air Mobility
Edition: 01.00.00
D2.4 APPENDIX D REGISTRATION SERVICE SPECIFICATION


Iris Röhrich / FRQ WP1 member 3.11.2022
2


Document History
draft for D2.4
Copyright Statement
conditions.
3
GOF2.0
Abstract
Exchange Service.
This document describes one of these Bridge Services, the Registration service in a logical, technology-
independent manner.
4
Table of Contents
Abstract ................................................................................................................................... 4
1 Introduction ............................................................................................................... 6
1.2 Scope ............................................................................................................................ 6
1.4 Background ................................................................................................................... 7
1.4.1 EASA .................................................................................................................................................. 7
1.4.2 Legal background .............................................................................................................................. 7
1.4.3 Regulatory framework for Drones [13] ............................................................................................. 7
1.4.4 Stakeholders [13] .............................................................................................................................. 9
1.4.5 Data Protection ................................................................................................................................. 9
1.4.6 (EU) 2018/1725 ............................................................................................................................... 10
1.4.7 GDPR (General Data Protection Regulation) ................................................................................... 10
1.4.8 EASA Registration Broker concept [13] ........................................................................................... 10
1.6 List of Acronyms .......................................................................................................... 14
3.1 Overview..................................................................................................................... 17

4.1 Overview..................................................................................................................... 24
4.2 General comment ........................................................................................................ 25
4.3 EASA PROTOCOLS ........................................................................................................ 26
4.3.1 Methods (src: API usage guide) ....................................................................................................... 26
4.4 Reference Data ............................................................................................................ 44
4.4.1 EASA OData EntitySets (source: API_USAGE DOC) – Annex A......................................................... 44
4.4.2 Country Codes ................................................................................................................................. 50
4.4.3 Language Codes............................................................................................................................... 51
4.4.4 STS Values ....................................................................................................................................... 52
4.4.5 Requester Types .............................................................................................................................. 52

6 References ............................................................................................................... 56
5
1 Introduction
The purpose of this service specification document is to provide a holistic overview of the Registration
Service and its building blocks in a technology-independent way, according to the guidelines given in
[1]. It describes a well-defined baseline of the service by clearly identifying the service version. service
and its building blocks in a technology-independent way, according to the guidelines given in [1].
The aim is to document the key aspects of the Registration Service at the logical level:
1.2 Scope
This document describes the Registration service.
The Registration service provides a means for the operational nodes to share their intends and make
them available for further processing.

in charge of designing and developing an instance of the Registration Service.
6
1.4 Background
1.4.1 EASA
Due to introduction of the EASA e-Registration service in EU member states, GOF1.0 Services
Specification for Registration became outdated. For this reason, it was decided by Consortium
Members, to implement at least minimal mock-up of data structures – especially unified pan-European
“operator id” in EASA format (i.e. FIN87astrdge12k-xyz-c, see Business Analysis, 3.2.1) for data retrieval
and other service layers as described in REPIF documents.
Due to nature of changes, it probably should skip user/drones creation procedures in the scope of GOF
2.0 project.
1.4.2 Legal background
As per Article 74 of the Basic Regulation 2018/1139 (BR), “the Agency, in cooperation with the
Commission and the national competent authorities, establish and manage a repository of information
necessary to ensure effective cooperation between the Agency and the national competent authorities
concerning the exercise of their tasks relation to certification, oversight and enforcement under the
Regulation […]”. [13]
1.4.3 Regulatory framework for Drones [13]
As per Article 56.7 of the BR: “Member States shall ensure that information about registration of
unmanned aircraft and of operators of unmanned aircraft …/… is stored in digital, harmonised,
interoperable national registration systems.”
Member States have thus the obligation to share data on certified drones and drone operators
registered in their register to other member states. This could be ensured through bilateral agreements
with each other Member States but this is not considered efficient.
Article 14 of the Implementing Regulation (EU) 2019/947 on rules and procedures for the operation of
drones dealing with: “Registration of UAS operators and certified UAS“ states:
“1. Member States shall establish and maintain accurate registration systems for UAS whose
design is subject to certification and for UAS operators whose operation may present a risk to
safety, security, privacy, and protection of personal data or the environment.
2. The registration systems for UAS operators shall provide the fields for introducing and
exchanging the following information:
(a) the full name and the date of birth for natural persons and the name and their
identification number for legal persons;
(b) the address of UAS operators;
(c) their email address and telephone number;
(d) an insurance policy number for UAS if required by Union or national law;
7
(e) the confirmation by legal persons of the following statement: ‘All personnel directly
involved in the operations are competent to perform their tasks, and the UAS will be
operated only by remote pilots with the appropriate level of competency’;
(f) operational authorisations and LUC held and declarations followed by a

confirmation in accordance with Article 12(5)(b).
3. The registration systems for unmanned aircraft whose design is subject to certification shall
provide the fields for introducing and exchanging the following information:
(a) manufacturer's name;
(b) manufacturer's designation of the unmanned aircraft;
(c) unmanned aircraft’s serial number;
(d) full name, address, email address and telephone number of the natural or legal
person under whose name the unmanned aircraft is registered.
4. Member States shall ensure that the registration systems are digital and interoperable and
allow for mutual access and exchange of information through the repository referred to in
Article 74 of Regulation (EU) 2018/1139.
5. UAS operators shall register themselves:
(a) when operating within the ‘open category’ any of the following unmanned aircraft:
i. with a maximum take-off mass of 250 g or more, or, which in the case of an impact
can transfer to a human kinetic energy above 80 Joules;
ii. that is equipped with a sensor able to capture personal data , unless it complies with
Directive 2009/48/EC.
(b) when operating within the ‘specific’ category an unmanned aircraft of any mass.
6. UAS operators shall register themselves in the Member State where they have their residence
for natural persons or where they have their principal place of business for legal persons and
ensure that their registration information is accurate. A UAS operator cannot be registered in
more than one Member State at a time.
Member States shall issue a unique digital registration number for UAS operators and for the
UAS that require registration, allowing their individual identification.
The registration number for UAS operators shall be established on the basis of standards that
support the interoperability of the registration systems.
7. The owner of an unmanned aircraft whose design is subject to certification shall register the
unmanned aircraft.
The nationality and registration mark of an unmanned aircraft shall be established in line with
ICAO Annex 7. An unmanned aircraft cannot be registered in more than one State at a time.
8
8. The UAS operators shall display their registration number on every unmanned aircraft
meeting the conditions described in paragraph 5.”
1.4.4 Stakeholders [13]
Access to the exchange of information is ruled by Article 74.6 of the BR which states:
“6. Without prejudice to paragraph 7, the Commission, the Agency, national competent
authorities and any competent authority of the Member States entrusted with the
investigation of civil aviation accidents and incidents shall, for the exercise of their tasks, have
on-line and secure access to all information included in the repository. Where relevant, the
Commission and the Agency may disseminate certain information included in the repository,
other than information referred to in paragraph 2, to interested parties or make it publicly
available.”
Note that there is no need identified to make information available to interested parties or to
the public for the drones repository at this time.
Note that the term national competent authorities is defined in Article 3(34) of the BR which
states: “‘national competent authority‘ means one or more entities designated by a Member
State and having the necessary powers and allocated responsibilities for performing the tasks
related to certification, oversight and enforcement in accordance with this Regulation and with
the delegated and implementing acts adopted on the basis thereof, and with Regulation (EC)
No 549/2004.”
Table 1 below provides for illustration typical stakeholders which may be given access to the
Repository of Information for the Drones domain:
No Stakeholder Internal/ external

(related to EASA)
1 European Union Aviation Safety Agency (EASA) Internal
2 National Aviation Authorities (NAAs) External
3 Law Enforcement Authorities for aviation safety of each Member State External
(within the scope of the BR)
4 Accident Investigation officers of each Member State External
5 ANSP / USSP / Aeronautical Information Service Providers (as External

“interested parties” per BR Article 74 .6)
Table 1: Example of typical stakeholders [13]
1.4.5 Data Protection
Any activities related to the handling of personal data for the purposes of UAS flights must be at least
performed in accordance with generally accepted rules and regulations:
1 Compliance with Regulation (EU) 2018/1725 of the European Parliament and of the Council of
23 October 2018 on the protection of natural persons with regard to the processing of personal
9
data by the Union institutions, bodies, offices and agencies and on the free movement of such
data, and repealing Regulation (EC) No 45/2001 and Decision No 1247/2002/EC.
2 Compliance with Regulation (EU) 2016/679 of the European Parliament and of the Council of
27 April 2016 on the protection of natural persons with regard to the processing of personal
data and on the free movement of such data, and repealing Directive 95/46/EC (GDPR).
1.4.6 (EU) 2018/1725
Persons whose personal data are processed by Union institutions and bodies in any context
whatsoever, for example, because they are employed by those institutions and bodies, should be
protected. [16]
In order to prevent creating a serious risk of circumvention, the protection of natural persons should
be technologically neutral and should not depend on the techniques used. [16]
This Regulation should apply to the processing of personal data by all Union institutions, bodies, offices
and agencies. It should apply to the processing of personal data wholly or partly by automated means
and to the processing other than by automated means of personal data which form part of a filing
system or are intended to form part of a filing system. Files or sets of files, as well as their cover pages,
which are not structured according to specific criteria should not fall within the scope of this
Regulation.[16]
1.4.7 GDPR (General Data Protection Regulation)
The protection of natural persons in relation to the processing of personal data is a fundamental
right. The principles of, and rules on the protection of natural persons with regard to the processing
of their personal data should, whatever their nationality or residence, respect their fundamental rights
and freedoms, in particular their right to the protection of personal data. This Regulation is intended
to contribute to the accomplishment of an area of freedom, security and justice and of an economic
union, to economic and social progress, to the strengthening and the convergence of the economies
within the internal market, and to the well-being of natural persons. [15]
1.4.8 EASA Registration Broker concept [13]
The diagram below illustrates the EASA broker concept which is based on the existence of national
repositories for registration data. At the time of writing this specification, it is known that EASA is
establishing a broker, but the technical details are still unknown. The GOF2 consortium accepts this
idea, and as soon as the technical specification of the solution is known, it will be integrated into this
specification.
10
Figure (x): Context diagram (src: REPIF – Business Analisis, Figure 1)

Term Definition
Describes the semantics of the domain (or a significant part thereof) by defining
External Data data structures and their relations. This could be at logical level (e.g., in UML)
Model or at physical level (e.g., in XSD schema definitions), as for example standard
data models.

Message Exchange service provider in order to obtain certain information; the service provider
Pattern provides the requested information in a dedicated response.

11

Operational
Activity

Operational Node
model is part of the service specification. Is typically defined in UML and/or XSD.
Service Data
If an external data model exists (e.g., a standard data model), then the service
Model
data model shall refer to it: each data item of the service data model shall be
mapped to a data item defined in the external data model.
Documents the details of a service technical design (most likely documented by

Service Design the service implementer). The service design description includes (but is not
Description limited to) a service physical data model and describes the used technology,
transport mechanism, quality of service, etc.

Service Instance different service providers; each such deployment represents a different service
instance, being accessible via different URLs.
12
Documents the details of a service implementation (most likely documented by

the service implementer) and deployment (most likely documented by the
Service Instance
Description
to) service technical design reference, service provider reference, service access
information, service coverage information, etc.

Service Interface
characterised by a message exchange pattern and consists of service operations
that are either allocated to the provider or the consumer of the service.

Service Operation

standard data model), then the service physical data model shall refer to it: each
Service Physical data item of the service physical data model shall be mapped to a data item
Data Model defined in the external data model.
In order to prove correct implementation of the service specification, there shall

exist a mapping between the service physical data model and the service data
model. This means, each data item used in the service physical data model shall
be mapped to a corresponding data item of the service data model. (In case of
existing mappings to a common external (standard) data model from both the
service data model and the service physical data model, such a mapping is
implicitly given.)

Service Provider

Service
Specification
Data Model.
Service
Specification
Producer
13

Service Technical
service specification may result in several technical service designs, realising the
Design
service with different or same technologies.

Service Currently, SOAP and REST are envisaged to be allowed service technologies. The
Technology service technology catalogue shall describe in detail the allowed service
bindings, etc.

Spatial be registered per technology.
Exclusiveness The decision, which service instance (out of a number of available spatially
governance issue.
Table: Glossary of terms

Acronym Definition
JSON JavaScript Object Notation
14
Table: List of acronyms
15
Name Registration Service
ID urn:gof:services:RegistrationService
Version 2.0.1
A service that allows the registration of the UAS, UAS operators, related persons (crew)
Description
and associated data.
Registration, eRegistration, Pilot, Operator, UAS, Manufacturer, National Authority,

Keywords
CAA, ANSP, USSP, CIS, Identity, License, Competence
Architect(s) 2020-2021 Droneradar Sp. z o.o.
Status Provisional
Table: Service Identification
16
3.1 Overview
Drone registration is a key part towards commercialization of unmanned air vehicles, and is required
by current or upcoming legislation. In most countries, the CAA operates a drone registry which collects
data of UTM operators, drone pilots, drones, operational authorizations and verifications of identity.
UAS operators are companies or individuals that operate one or more drones. UAS operators may
employ one or more pilots. In the case of private citizens operating drones, they themselves are both
UAS operators and the sole pilot.
ID verification systems provide proof of identity of registered pilots and operators. Operators register
their drone(s) along with type and id (serial, remoteID, etc.) information, and provide proof of
competency as part of their profile in the registry. On December 31, 2020, the registration obligation
resulting from the entry into force:
1 Commission Implementing Regulation (EU) 2019/947 of 24 May 2019 on the rules and
procedures for the operation of unmanned aircraft
2 Commission Delegated Regulation (EU) 2019/945 of 12 March 2019 on unmanned aircraft

systems and on third-country operators of unmanned aircraft systems
The registry allows for drone lookup by ID to support other stakeholders, systems or accident
investigations.
The operational context description should be based on the description of the operational model,
consisting of a structure of operational nodes and operational activities. If such an operational model
exists, this section shall provide references to it. If no such operational model exists, then its main
aspects shall be described in this section.
The operational context shall be a description of how the service supports interaction among
operational nodes. This can be achieved in two different levels of granularity:
 A description of how the service supports the interaction between operational nodes. This
basically consists of an overview about which operational nodes shall provide the service and
which operational nodes will consume the service.
 A more detailed description that indicates what operational activities the service supports in
a process model.
Moreover, the operational context should describe any requirement the service will fulfil or adhere to.
This refers to functional as well as non-functional requirements at high level (business/regulatory
requirements, system requirements, user requirements). Especially, information exchange
requirements are of much interest since the major objective of services is to support interaction
between operational nodes.
The source material for the operational context description should ideally be provided by operational
17
users and is normally expressed in dedicated requirements documentation. Ensure that the applicable
documents are defined in the References section. If no requirements documents are available, then
the basic requirements for the service shall be defined in the dedicated sub-section below.
Architectural elements applicable for this description are:
 Service
 Nodes
 Operational Activities
 Information Exchange Requirements

This section lists (functional and non-functional) requirements applicable to the service being
described. A tabular list of requirements shall be added here. If external requirements documents are
available, then the tables shall refer to these requirements, otherwise the requirements shall be
documented here.
The service MUST be linked to at least one requirement. At least one of the following tables shall be
presented in this section. The first table lists references to requirements available from external
documents. Make sure you document the sources from where the requirements are coming from. The
second table lists new requirements defined for the first time in this service specification document.
The table below lists applicable existing requirements for the Registration Service.
18
Id Name
CORUS [4], 4.1.1.2

Amber airspace;
At all times, all U-space participants shall

Common
operate on the same common set of data, B1-RPAS [9];
Situational
during pre-flight planning stages as well as
Awareness
during all stages of flight operations.
CEF-SESAR-2018-
1 [1], Objective
O5
19
Id Name
SESAR Drone
Roadmap [11],
Foreword, 4.1 and
4.2;
The U-space concept shall be designed such as

U-space Blueprint
Basis for Open to ensure a well-established line of authority
[13], Benefits to
Market while at the same time ensuring that an open
European society
market for VLL services may develop
and economy;
CEF-SESAR-2018-
1 [1], Table 8 –
Key Challenges
20
Id Name
ICAO Doc 10039

[2];
There shall be an implementation of a Flight [R-2];

Information Management System (FIMS)
which ensures that, at all times, emerging
unmanned traffic management systems and
existing technologies from manned
Interoperability
operations can exchange any data required to
support such common situational awareness, CEF-SESAR-2018-
be it for drone operations in areas where 1 [1], Objective
established ATC procedures apply, or in zones O6;
outside established ATC.
CEF-SESAR-2018-
1 [1], Table 8 –
Key Challenges
21
Id Name
[R-2];
Standard communication protocols shall SESAR Drone

hence be used where available, and such Roadmap [11],
Standard standard protocols be developed otherwise, 3.5, section
Protocols in order to ensure the lowest level of 'Standards';
obstruction for an open VLL airspace use
market to develop.
CEF-SESAR-2018-
1 [1], Table 8 –
Key Challenges
[R-2];
Any interface and protocol hence must be
openly defined, and its definition be freely
Open Interfaces accessible in order to ensure the lowest level
of obstruction for an open VLL airspace use
market to develop. CEF-SESAR-2018-
1 [1], Table 8 –
Key Challenges
22
Id Name
[R-3];
The implementation of a Flight Information

SWIM Management System (FIMS) shall be based on
an ICAO SWIM-compliant architecture. CEF-SESAR-2018-
1 [1], 5.3.4 Overall
approach and
methodology
Tab.: Requirements for the Registration Service

3.3.1.1 ICAO SWIM

23

4.1 Overview
Figure (x+1): Entity-Relations diagram for drones (src: REPIF 0- - Business Analysis, Figure 3)
24
Figure (x+2): Entity Relationships (src: API usage guide)
4.2 General comment

Due to the fact that there is no official, approved version of the concept for creating and distributing
Registration data, it is at the moment of writing this document, impossible to propose a final,
consistent and uniform data model. Given the relatively extensive experience of consortium members
represented by technology companies as well as ANSP, the final proposal including best-of-breed
practices will be created after the completion of the practical part (trials).
In addition, the conceptual version of the registration as described in EASA official documents appears
to be incomplete (API-GUIDE draft status still draft status) and is likely to be modified.
Probably most striking is lack of ‘air-worthiness’ estimation in certified drone data, which will cause
problems with operation plan verification flows. For the purpose of this VLD, the verification process
of UAS equipment will be skipped, assuming that it is UAS Operator/Pilot responsibility to use a drone
satisfying expected requirements.
Other challenges found include (minor ones):
- concatenate operator names, effectively disabling ‘sort/find by surname’
- performance (like mandatory attachment download)
25
4.3 EASA PROTOCOLS

EASA message broker acts as mediating party between the different Member States applications to
route a request from a requesting MS to a queried MS. Authentication, integrity and confidentiality on
the transport layer are provided using secure TLS connections.
Figure (x+2): Entity Relationships (src: API usage guide, page 5)
4.3.1 Methods (src: API usage guide)
4.3.1.1 GET UAS Operator

This method will return the information object of a UAS operator
GET
/registration/{DestinationMS}/v1/uas.svc/UASOperators?$filter={filterparameters}&$expand={expan
dparameters}
Required Query Parameters How to use Description
DestinationMS Provide the ISO3166-1 Alpha 3 This parameter selects the

country code (See Table 1) responder server
filterparameters Provide values at least for the This is a RESTful filter based on
mandatory properties. (see ODataV2. Setting the
table below) parameters will return the
requested information object
expandparameters This parameter selects the This parameter selects the

underlaying structures. All of underlaying structures the
the parameters defined below requester specifies to be
should be used to get all the included in the response
data of the information object
(see table below)
filterparameter M/O1 Description
1
Mandatory or Optional property
26
ObjectIDDomain M Value should be always ‘UAS’
ObjectIDCountry M Country code of the Member State where the information object is
registered. ISO 3166-1 alpha-3 country codes must be used (see
Table 1/Chapter 5).
ObjectIDUniqueIDScheme M Select the Scheme.
Value is “UARM” as the requested linked entity is CertifiedUAS.
ObjectIDUniqueID M As the requested object is CertifiedUAS the value of this attribute is

the requested value of the Certified UAS registration mark.
RequesterType M This attribute should contain the code value of the requester type
(see Table 4/Chapter 5).
ObjectType M Select the object type.
As the requested object is CertifiedUAS value ‘01’ should be set.
OriginatingMS M Country code of the MS originating the request. ISO 3166-1 alpha-
3 country codes must be used
Timestamp M Provide the request timestamp as datetimeoffset
OriginatingMSReference O Unique id of a request (see 3.1.3.1)
RepositoryID O Attribute not yet in use (attribute should not be provided in

request)
RelevantDate O This attribute can be used in case of investigation of a past UAS

activity, to indicate a date when the activity was executed. It is
therefore not the same as Timestamp
ReplyExpectedDate O Attribute not yet in use
expandparameter M/O Description
UASOperator, M UAS Operator basis information
UASOperator/Attachment, M Binary attachment and properties
UASOperator/OperationalDeclarations, M Operational declaration information
27
UASOperator/OperationalDeclarations/UASPro
ducts,
UASOperator/OperationalAuthorisations, M Operational authorisations information
UASOperator/OperationalAuthorisations/Autho
risedAirspaceRiskLevels,
UASOperator/OperationalAuthorisations/Autho
risedLocations,
UASOperator/OperationalAuthorisations/Mitig
ationMeasures,
UASOperator/OperationalAuthorisations/Opera
tionalLimitations,
UASOperator/OperationalAuthorisations/Other
StaffCompetencies,
UASOperator/OperationalAuthorisations/Remo
tePilotCompetencies,
UASOperator/OperationalAuthorisations/UASId
entifiers,
UASOperator/LUCHeld, M LUC held information
UASOperator/LUCHeld/Privileges,
UASOperator/LUCHeld/SpecialLimitations,
UASOperator/LUCHeld/Specifications,
UASOperator/LUCHeld/UASIdentifiers,
UASOperator/LUCHeld/UASOperationTypes
HTTP status codes
Code Description
200 OK. The responding server has processed the request. Examine the status of
ReplyStatus attribute of the UASObject entity provided in the payload.
In case of ReplyStatus = “01”, the requested information object exists and is
included in the result in payload as part of the expanded Property UASOperator
28
In case of ReplyStatus = “02”, the requested information object was not found
400 Bad Request. Please verify the request parameters. Contact EASA for further
troubleshooting
403 Forbidden. Request was denied either by the EASA broker or by the responding
server. Please verify the credentials used by the client application (client
certificate, IP address). Please contact EASA for further troubleshooting
404 Requested path in URI was not found or the responding server provided the error.
Please contact EASA for further troubleshooting
500 Internal server error. Please retry and if the problem persists please contact EASA
for further troubleshooting
501 Not implemented. Please verify the request parameters. Please contact EASA for
further troubleshooting
502 Bad gateway. Typically this problem indicates a problem in the routing of the
request. Please retry and if the problem persists please contact EASA for further
troubleshooting
504 Gateway Timeout. Typically this problem indicates a problem in the routing of the
troubleshooting
Note: The EASA message broker may mask the response of the server when an error occurs and relay
only the error code.
Example request URL:
https://repif-api-test.easa.europa.eu/registration/ZZZ/v1/uas.svc/UASObjects?
$filter=ObjectIDDomain eq 'UAS' and ObjectIDCountry eq 'ZZZ' and

ObjectIDUniqueIDScheme eq 'OPRN' and ObjectIDUniqueID eq 'ZZZ87astrdge12kc' and
ObjectType eq '02' and OriginatingMS eq 'ZZA' and RequesterType eq '02' and
Timestamp eq datetimeoffset'2020-07-22T10:10:10Z'&
$expand=UASOperator,UASOperator/OperationalDeclarations,UASOperator/Operational
Authorisations,UASOperator/Attachment,UASOperator/LUCHeld,UASOperator/Operation
alDeclarations/UASProducts,UASOperator/OperationalAuthorisations/AuthorisedAirs
paceRiskLevels,UASOperator/OperationalAuthorisations/AuthorisedLocations,UASOpe
rator/OperationalAuthorisations/MitigationMeasures,UASOperator/OperationalAutho
risations/OperationalLimitations,UASOperator/OperationalAuthorisations/OtherSta
ffCompetencies,UASOperator/OperationalAuthorisations/RemotePilotCompetencies,UA
29
SOperator/OperationalAuthorisations/UASIdentifiers,UASOperator/LUCHeld/Privileg
es,UASOperator/LUCHeld/SpecialLimitations,UASOperator/LUCHeld/Specifications,UA
SOperator/LUCHeld/UASIdentifiers,UASOperator/LUCHeld/UASOperationTypes

ObjectIDUniqueIDScheme eq 'OPRN' and ObjectIDUniqueID eq 'ZZZ87astrdge12kc' and
Timestamp eq datetimeoffset'2020-07-22T10:10:10Z'&
$expand=UASOperator,UASOperator/OperationalDeclarations,UASOperator/Operational
Authorisations,UASOperator/Attachment,UASOperator/LUCHeld,UASOperator/Operation
alDeclarations/UASProducts,UASOperator/OperationalAuthorisations/AuthorisedAirs
paceRiskLevels,UASOperator/OperationalAuthorisations/AuthorisedLocations,UASOpe
rator/OperationalAuthorisations/MitigationMeasures,UASOperator/OperationalAutho
risations/OperationalLimitations,UASOperator/OperationalAuthorisations/OtherSta
ffCompetencies,UASOperator/OperationalAuthorisations/RemotePilotCompetencies,UA
SOperator/OperationalAuthorisations/UASIdentifiers,UASOperator/LUCHeld/Privileg
es,UASOperator/LUCHeld/SpecialLimitations,UASOperator/LUCHeld/Specifications,UA
SOperator/LUCHeld/UASIdentifiers,UASOperator/LUCHeld/UASOperationTypes
Example response in HTTP:
Note: this example does not include operational authorisations, declarations, attachment or LUCheld
in the content to conserve space in this document
HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
dataserviceversion: 2.0
"d": {
30
"results": [
"__metadata": {
"id": "https://repif-api-
test.easa.europa.eu/registration/ZZZ/v1/uas.svc/UASObjects(ObjectIDDomain='UAS'
,ObjectIDCountry='ZZZ',ObjectIDUniqueIDScheme='OPRN',ObjectIDUniqueID='ZZZ87ast
rdge12kc')",
"uri": "https://repif-api-
rdge12kc')",
"type": "EASA.Repository.UAS.v1.UASObject"
},
"OriginatingMS": "ZZA",
"Timestamp": "/Date(1595412610000+0000)/",
"OriginatingMSReference": "",
"RequesterType": "02",
"ObjectType": "02",
"ObjectIDDomain": "UAS",
"ObjectIDCountry": "ZZZ",
"ObjectIDUniqueIDScheme": "OPRN",
"ObjectIDUniqueID": "ZZZ87astrdge12kc",
"RepositoryID": "",
"RelevantDate": null,
"ReplyExpectedDate": null,
"ReplyOriginatingMS": "ZZZ",
"ReplyDestinationMS": "ZZA",
"ReplyingMS": "ZZZ",
"ReplyingMSReference": "8392C57C-33D8-4613-A586-5B2F4AFBCB55",
"ReplyTimestamp": "/Date(1600876185946+0000)/",
"Language": "EN",
"ReplyStatus": "01",
31
"DateOfData": "/Date(1600819200000+0000)/",
"UASOperator": {
"__metadata": {
test.easa.europa.eu/registration/ZZZ/v1/uas.svc/UASOperators(RegistrationNumber
='ZZZ87astrdge12kc',RegistrationCountry='ZZZ')",
test.easa.europa.eu/registration/ZZZ/v1/uas.svc/UASOperators(RegistrationNumber
='ZZZ87astrdge12kc',RegistrationCountry='ZZZ')",
"type": "EASA.Repository.UAS.v1.UASOperator"
},
"RegistrationNumber": "ZZZ87astrdge12kc",
"RegistrationCountry": "ZZZ",
"RepositoryID": "",
"FullName": "Adam Xxxxx",
"Address": "Rheinstrasse 3 12345 Koln",
"Email": "xxxxx@xx.zz",
"Telephone": "+1234567890",
"Birthdate": "/Date(976579200000+0000)/",
"IdentificationNumber": "",
"Validity": true,
"RegistrationDate": "/Date(1576108800000+0000)/",
"Attachment": null,
"LUCHeld": null,
"OperationalAuthorisations": {
"results": []
},
"OperationalDeclarations": {
"results": []
},
32
"CertifiedUAS": {
"__deferred": {
rdge12kc')/CertifiedUAS"
EntitySet: LUCHeld
M/OError!
Bookmark Type
Attribute Description Length Notes
not (Mutliplicity)
defined.
Approval
reference (digital
and/or letter
LUCNumber LUC number M String code) of the LUC,
as issued by the
competent
authority
IssueDate Issue date M Date
Privileges Privileges M Navigation (1..*)
Serial number or UA
UASIdentifiers registration mark M Navigation (1..*)
(for certified UAS)
Type(s) of UAS
UASOperationTypes M Navigation (1..*)
operation
Specifications Specifications M Navigation (1..*)
SpecialLimitations Special limitations M Navigation (1..*)
33
EntitySet: Attachments
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
Technical ID to
identify each
AttachmentID ID of the attachment M String
entity, generated
by MS
Name of the file

Filename M String
attached
Type of file / MIME

ContentType M String application/pdf
type
AttachmentData Base64 encoded file M Binary
EntitySet: Privileges
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
Privilege Privileges M String
EntitySet: UASIdentifiers
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
Serial number or UA
UASIdentifier registration mark M String
(for certified UAS)
EntitySet: UASOperationTypes
Attribute Description M/OError! Type Length Notes

Bookmark (Mutliplicity)
34
not
defined.
Type(s) of UAS
UASOperationType M String
operation
EntitySet: Specifications
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
Specification Specifications M String
EntitySet: SpecialLimitations
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
SpecialLimitation Special limitations M String
EntitySet: AuthorisedLocations
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
Element 4.1
AuthorisedLocation Authorised location(s) M String
of the form
EntitySet: AuthorisedAirspaceRiskLevels
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
Element 4.2
AuthorisedAirspaceRiskLevel Authorised airspace risk level M String
of the form
35
EntitySet: OperationalLimitations
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
Element 4.3
OperationalLimitation Operational limitations M String
of the form
EntitySet: MitigationMeasures
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
Element 4.4
MitigationMeasure Mitigation measures M String
of the form
EntitySet: RemotePilotCompetencies
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
Element 4.5
RemotePilotCompetency Remote pilot competency M String
of the form
EntitySet: OtherStaffCompetencies
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
Competency of other staff

Element 4.6
OtherStaffCompetency essential for the safety of the M String
of the form
operation
4.3.1.2 GET Certified UAS
This method will return the information object of a Certified UAS
36
GET
/registration/{DestinationMS}/v1/uas.svc/UASOperators?$filter={filterparameters}&$expand={ex
pandparameters}
Required Query Parameters How to use Description
DestinationMS Provide the ISO3166-1 Alpha 3 This parameter selects the

country code (See Table 1) responder server
filterparameters Provide values at least for the This is a RESTful filter based on
mandatory properties. (see ODataV2. Setting the
table below) parameters will return the
requested information object
expandparameters This parameter selects the This parameter selects the

underlaying structures. All of underlaying structures the
the parameters defined below requester specifies to be
should be used to get all the included in the response
data of the information object
(see table below)
filterparameter M/O2 Description
ObjectIDDomain M Value should be always ‘UAS’
ObjectIDCountry M Country code of the Member State where the information object is
registered. ISO 3166-1 alpha-3 country codes must be used (see
Table 1/Chapter 5).
ObjectIDUniqueIDScheme M Select the Scheme.
Value is “UARM” as the requested linked entity is CertifiedUAS.
ObjectIDUniqueID M As the requested object is CertifiedUAS the value of this attribute is

the requested value of the Certified UAS registration mark.
RequesterType M This attribute should contain the code value of the requester type
(see Table 4/Chapter 5).
2
Mandatory or Optional property
37
ObjectType M Select the object type.
As the requested object is CertifiedUAS value ‘01’ should be set.
OriginatingMS M Country code of the MS originating the request. ISO 3166-1 alpha-
3 country codes must be used
Timestamp M Provide the request timestamp as datetimeoffset
OriginatingMSReference O Unique id of a request (see 3.1.3.1)
RepositoryID O Attribute not yet in use (attribute should not be provided in

request)
RelevantDate O This attribute can be used in case of investigation of a past UAS

activity, to indicate a date when the activity was executed. It is
therefore not the same as Timestamp
ReplyExpectedDate O Attribute not yet in use
expandparameter M/O Description
CertifiedUAS M Certified UAS information
HTTP status codes
Code Description
200 OK. The responding server has processed the request. Examine the status of
ReplyStatus attribute of the UASObject entity provided in the payload.
In case of ReplyStatus = “01”, the requested information object exists and is included
in the result in payload as part of the expanded Property CertifiedUAS
In case of ReplyStatus = “02”, the requested information object was not found
400 Bad Request. Please verify the request parameters. Contact EASA for further
troubleshooting
403 Forbidden. Request was denied either by the EASA broker or by the responding server.
Please verify the credentials used by the client application (client certificate, IP
address). Please contact EASA for further troubleshooting
38
404 Requested path in URI was not found or the responding server provided the error.
Please contact EASA for further troubleshooting
500 Internal server error. Please retry and if the problem persists please contact EASA for
501 Not implemented. Please verify the request parameters. Please contact EASA for
502 Bad gateway. Typically this problem indicates a problem in the routing of the request.
Please retry and if the problem persists please contact EASA for further
troubleshooting
504 Gateway Timeout. Typically this problem indicates a problem in the routing of the
troubleshooting
Note: The EASA message broker may mask the response of the server when an error occurs and relay
only the error code.

ObjectIDUniqueIDScheme eq 'UARM' and ObjectIDUniqueID eq 'ZZZ-S234' and
Timestamp eq datetimeoffset'2020-07-22T10:10:10.123Z'&
$expand=CertifiedUAS
Example request in HTTP:
GET
/registration/ZZZ/v1/uas.svc/UASObjects?$filter=ObjectIDDomain%20eq%20'UAS'%20
and%20ObjectIDCountry%20eq%20'ZZZ'%20and%20ObjectIDUniqueIDScheme%20eq%20'UARM'
%20and%20
ObjectIDUniqueID%20eq%20'ZZZ-S234'%20and%20ObjectType%20eq%20'01'%20and%20
OriginatingMS%20eq%20'ZZA'%20and%20RequesterType%20eq%20'01'%20and%20Timestamp%
20eq%20
datetimeoffset'2020-07-22T10:10:10.123Z'&$expand=CertifiedUASHTTP/1.1
Host: repif-api-test.easa.europa.eu
39
Accept: application/json
DataServiceVersion: 2.0
Example response in HTTP:
HTTP/1.1 200 OK
"d": {
"results": [
"__metadata": {
,ObjectIDCountry='ZZZ',ObjectIDUniqueIDScheme='UARM',ObjectIDUniqueID='ZZZ-
S234')",
S234')",
},
"Timestamp": "/Date(1595412610123+0000)/",
"ObjectType": "01",
40
"ObjectIDUniqueIDScheme": "UARM",
"ObjectIDUniqueID": "ZZZ-S234",
"RepositoryID": "",
"ReplyingMSReference": "A3B8C48B-20A2-4DA5-BE3B-5CB44B2E7666",
"Language": "EN",
"DateOfData": "/Date(1600819200000+0000)/",
"UASOperator": {
"__deferred": {
S234')/UASOperator"
},
"CertifiedUAS": {
"__metadata": {
test.easa.europa.eu/registration/ZZZ/v1/uas.svc/CertifiedUAS(RegistrationMark='
ZZZ-S234',RegistrationCountry='ZZZ')",
test.easa.europa.eu/registration/ZZZ/v1/uas.svc/CertifiedUAS(RegistrationMark='
ZZZ-S234',RegistrationCountry='ZZZ')",
"type": "EASA.Repository.UAS.v1.CertifiedUAS"
},
"CertifiedUASOwner": {
41
"__metadata": {
"type": "EASA.Repository.UAS.v1.CertifiedUASOwner"
},
"RepositoryID": "",
"FullName": "Barbara Kowalska",
"Address": "Hoża 22 00-123 Warszawa, Polska",
"Email": "barbara.kowalska@xxx.com",
"Telephone": "+123456789",
"Birthdate": "/Date(788054400000+0000)/",
"IdentificationNumber": ""
},
"RegistrationMark": "ZZZ-S234",
"RegistrationCountry": "ZZZ",
"UASManufacturer": "ABC",
"UASModel": "Super 100",
"UASSerialNumber": "OK1DGT567YF",
"RegistrationDate": "/Date(1103673600000+0000)/",
"Validity": true
Example of a response where the requested object was not found:
42
HTTP/1.1 200 OK
"d": {
"results": [
"__metadata": {
S235')",
S235')",
},
"Timestamp": "/Date(1595412610123+0000)/",
"ObjectType": "01",
"ObjectIDUniqueIDScheme": "UARM",
"ObjectIDUniqueID": "ZZZ-S235",
"RepositoryID": "",
43
"ReplyingMSReference": "D6CFAAF2-6C69-40D6-A620-B4DF66E6DE79",
"Language": "EN",
"DateOfData": "/Date(1600819200000+0000)/",
"UASOperator": {
"__deferred": {
S235')/UASOperator"
},
"CertifiedUAS": null
4.4 Reference Data

4.4.1 EASA OData EntitySets (source: API_USAGE DOC) – Annex A
EntitySet: UASObjects
44
Type
Attribute Description M/O3 Length Notes
(Mutliplicity)
ObjectIDDomain Object identifier domain M String 3
ObjectIDCountry Object identifier country M String 3
Representation scheme of
ObjectIDUniqueIDScheme M String 4
the Unique ID
Certified UAS registration
ObjectIDUniqueID mark / Operator M String
registration number
OriginatingMS Originating MS M String 3
Timestamp Request timestamp M TimeStamp
OriginatingMSReference Originating MS reference O String
RequesterType Requester type M String Please
ObjectType Object type M String read
Repository ID of the chapter 3
registered operator of this
RepositoryID (Placeholder for future O String document
use, value should be for details
empty or null) on the
values
RelevantDate Relevant date O Date
and
ReplyExpectedDate Expected reply date O Date
handling
ReplyOriginatingMS Originating MS of reply M String 3 of the
ReplyDestinationMS Destination MS of reply M String 3 attributes
ReplyingMS Replying MS M String 3 of this
ReplyingMSReference Replying MS reference M String entityset
ReplyTimestamp Reply timestamp M TimeStamp
Language in which the
Language value of the reply is M String
provided
ReplyStatus Reply status M String
DateOfData Date of the data O Date
Navigation
UASOperator UASOperator linked entity O
(0..1)
Navigation
CertifiedUAS CertifiedUAS linked entity O
(0..1)
EntitySet: CertifiedUAS
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
RegistrationMark UA registration mark M String
3
Mandatory / Optional to provide a value for the attribute
45
Values
from
RegistrationCountry Registration country M String 3 Table 1 of
API usage
guide
UASManufacturer Manufacturer’s name M String
Manufacturer’s
UASModel M String
designation of the UAS
UASSerialNumber UAS Serial Number M String
RegistrationDate Registration date M Date
Validity of the certified
Validity unmanned aircraft M Boolean 1
registration
Operator details of the
CertifiedUASOwner M Complex
certified UAS
ComplexType: CertifiedUASOwner
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
Will
become
mandatory
once the
Repository ID of the technical
person under whose name solution
RepositoryID O String
the certified drone is available.
registered Value
should be
empty or
null for
now
Full name of the person
under whose name the
FullName M String
certified drone is
registered
Address of the person
Address M String
certified drone is
registered
Email of the person under
Email whose name the certified M String
drone is registered
Tel. number of the person
Telephone M String
46
certified drone is
registered
Date of birth of the person
Birthdate certified drone is O Date
registered in case it is a
natural person
Identification number of
the person under whose
IdentificationNumber name the certified drone is O String
registered in case it is a
legal entity
EntitySet: UASOperators
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
Operator registration Example:
RegistrationNumber M String 16
number FIN87astrdge1
Values from
RegistrationCountry Registration country M String 3 Table 1 of API
usage guide
Value should b
Repository ID of the
RepositoryID O String empty or null f
registered operator
now
Full name of the
FullName M String
registered operator
Address of the registered
Address M String
operator
Email of the registered
Email M String
operator
Tel. number of the
Telephone M String
registered operator
Date of birth of the Each of these t
registered operator in attributes is
Birthdate O Date
case it is a natural optional but it i
person mandatory to
specify one of
Identification number of
two, depending
IdentificationNumber the registered operator in O String
the person type
case it is a legal entity
(natural or lega
Validity of the UAS
Validity M Boolean 1
operator registration
RegistrationDate Registration date M Date
47
Operational Navigation
OperationalAuthorisations O
authorisations (0..*)
Navigation
OperationalDeclarations Operational declarations O
(0..*)
Navigation
LUCHeld LUC held O
(0..1)
MS should
provide a copy
the operational
authorisation a
of the LUC ‘ter
of approval’ he
by the UAS
operator
Navigation
Attachment Reply attachment O registered in th
(0..1)
Member State.
The copy shoul
be exchanged
through the
repository as an
unstructured
attachment (e.g
PDF file)
EntitySet: OperationalAuthorisations
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
Eleme
the for
elemen
form a
numbe
accord
AuthorisationNumber Authorisation number M String Operat
author
templa
include
AMC1
UAS.S
(1)
48
Serial number or UA
Navigation Eleme
UASIdentifiers registration mark (for M
(1..*) the for
certified UAS)
Navigation
AuthorisedLocations Authorised location(s) M
(1..*)
Authorised airspace risk Navigation
AuthorisedAirspaceRiskLevels M
level (1..*)
Navigation
OperationalLimitations Operational limitations M
(1..*)
Navigation
MitigationMeasures Mitigation measures M
(1..*)
Navigation
RemotePilotCompetencies Remote pilot competency M
(1..*)
Competency of other staff
Navigation
OtherStaffCompetencies essential for the safety of O
(0..*)
the operation
Eleme
ExpirationDate Expiration date M Date
the for
EntitySet: OperationalDeclarations
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
Techni
identif
Technical ID to identify
OperationalDeclarationID M String entity,
each entity
genera
MS
Navigation
UASProducts UAS products M
(1..*)
Values
STSNumber STS number M String Table 3
usage g
ExpirationDate Expiration date M Date
EntitySet: UASProducts
M/OError!
Bookmark Type
not (Mutliplicity)
defined.
UASManufacturer UAS manufacturer M String
UASModel UAS model M String
49
4.4.2 Country Codes
The following table shows the ISO3166-1 alpha-3 country codes (always in CAPITAL) that shall be used
for attributes indicating a Member State (eg OriginatingMS, RegistrationCountry). Additionally, for the
test environment, the EASA test server will emulate the country code “ZZZ”.
Member State Code
Austria AUT
Belgium BEL
Bulgaria BGR
Croatia HRV
Cyprus CYP
Czech Republic CZE
Denmark DNK
Estonia EST
Finland FIN
France FRA
Germany DEU
Greece GRC
Hungary HUN
Iceland ISL
Ireland IRL
Italy ITA
Latvia LVA
Liechtenstein LIE
Lithuania LTU
Luxembourg LUX
Malta MLT
50
Netherlands NLD
Norway NOR
Poland POL
Portugal PRT
Romania ROU
Slovakia SVK
Slovenia SVN
Spain ESP
Sweden SWE
Switzerland CHE
Table 2
4.4.3 Language Codes
The following table shows the ISO639-1 language codes (always in CAPITAL) that shall be used for
attributes indicating an EU language (Language attribute in UASObject).
Language Code
Bulgarian BG
Croatian HR
Czech CS
Danish DA
Dutch NL
English EN
Estonian ET
Finnish FI
French FR
German DE
Greek EL
Hungarian HU
51
Irish GA
Italian IT
Latvian LV
Lithuanian LT
Maltese MT
Polish PL
Portuguese PT
Romanian RO
Slovak SK
Slovenian SL
Spanish, Castilian ES
Swedish SV
Table 3
4.4.4 STS Values
Value
STS-01
STS-02
Table 4
4.4.5 Requester Types
Code Description
01 Public
02 Police
03 Other law enforcement authority
04 Search & Rescue
05 Competent authority entrusted with the investigation

of civil aviation accidents and incidents
06 ANSP / U-space Service Providers
52
07 National Aviation/Competent Authority
Table 5
53
54
Left Empty.
55
6 References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8] https://www.atmmasterplan.eu/
[9] https://www.sesarju.eu/u-space-blueprint
[10] Efficient, safe and sustainable traffic at sea (EfficienSea2), a Horizon 2020 Project,
Grant Agreement No 636329
https://efficiensea2.orghttps://efficiensea2.org/wp-
content/uploads/2018/04/Deliverable-3.6.Standard-proposal-for-Maritime-
Cloud-service-specification.pdf
[11] IALA specification for e-navigation technical services
services
[12] IATA Safety Report 2014 (Issued April 2015)
http://www.aviation-accidents.net/report-download.php?id=90003
[13]
56
[14]
[15] REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE

COUNCIL
of 27 April 2016 on the protection of natural persons with regard to the processing
of personal data and on the free movement of such data, and repealing
Directive 95/46/EC (General Data Protection Regulation)
[16] 2018/1725
57
D2.4 Appendix E
Operational Message
Exchange Service
Specification
Deliverable ID: D2.4-E
Grant: 101017689
Topic:
Air Mobility
Edition: 01.00.00
D2.4 APPENDIX E OPERATIONAL MESSAGE EXCHANGE SERVICE SPECIFICATION


2


Document History
00.00.01 21.04.2021 Draft Peter CORNELIUS Document created.
00.00.02 26.10.2022 draft WP2 Partners Enhance and update
01.00.00 4.11.2022 released WP2 Partners submit
Copyright Statement
conditions.
3
GOF2.0
Abstract
This specification introduces an information exchange service which ensures interoperability and
hence transparent and reliable information flow between the stakeholders in an operational U-space
environment.
In accordance with ICAO SWIM, this document describes one of these Bridge Services, the Operational
Message Exchange service in a logical, technology-independent manner.
4
Table of Contents
Abstract ................................................................................................................................... 4
1 Introduction ............................................................................................................... 7
1.2 Scope ............................................................................................................................ 7
1.3 Target Group ................................................................................................................. 7
1.4 Background ................................................................................................................... 8
1.4.1 EU Regulation .................................................................................................................................... 8
1.4.2 EUROCONTROL Specification for Monitoring Aids (MONA).............................................................. 8
1.4.4 International Civil Aviation Organization (ICAO) ............................................................................... 9
1.4.5 SESAR-JU............................................................................................................................................ 9
1.4.6 Efficient, Safe and Sustainable Traffic at Sea (EfficienSea2) ........................................................... 10
1.5 Glossary of Terms ........................................................................................................ 10
1.6 List of Acronyms .......................................................................................................... 12
4 Service Interfaces ..................................................................................................... 20

5.1 Overview..................................................................................................................... 21
5.2 OperationalMessage Data Structure............................................................................. 22
5.3 AckMessage Data Structure ......................................................................................... 23
5.4 EnumOperationalMessageSeverity Enumeration .......................................................... 23
5.5 EnumOperationalMessageType Enumeration ............................................................... 24
5.6 EnumOperationalMessageSeverity Enumeration .......................................................... 25
5.7 EnumOperationalMessageState Enumeration .............................................................. 25
5.8 EnumAcknowlegement Enumeration ........................................................................... 26
5.9 OperationPlan Data Structure ...................................................................................... 26
5.10 UasRegistration Data Structure .................................................................................... 26
5.11 PositionReport Data Structure ..................................................................................... 26
5
6.1 Service Interface OperationalMessageSubscriptionInterface......................................... 27

6.1.1 Operation subscribeForOperationalMessages ................................................................................ 27
6.1.2 Operation subscribeForOperationalMessageMonitoring ............................................................... 27
6.1.3 Operation unSubscribeForOperationalMessages ........................................................................... 28
6.2 Service Interface OperationalMessageNotificationInterface ......................................... 28
6.2.1 Operation notifyOperationalMessage ............................................................................................ 28
6.2.2 Operation notifyOperationalMessageState .................................................................................... 29
6.3 Service Interface OperationalMessageAcknowledgementInterface ............................... 29
6.3.1 Operation acknowledgeOperationalMessage ................................................................................. 29

7.2 OperationalMessage State Machine ............................................................................. 32
8 References ............................................................................................................... 33
6
1 Introduction
Based on the guidelines given in [GOF1-Arch-AppA], this document describes the OperationalMessage
exchange service of a Common Information Service (CIS) in a logical technology-independent manner,
that is:
 operational and business context of the service

o requirements for the service, e.g. information exchange requirements
 service description
In addition, this document clearly defines the version of the service.
1.2 Scope
This document describes the OperationalMessage Exchange service for a CIS.
The OperationalMessage service provides a means for the operational nodes of the U-space to
exchange operational messages, and a corresponding acknowlegement.
1.3 Target Group

This service specification is written for:
 service architects,
 system engineers and
 developers in charge of designing and developing an instance of the ConformanceMonitoring
service.
In addition, this service specification is written for:
 enterprise architects,
 information architects,
 system engineers and developers in pursuing architecting, design and development activities
of other related services.
7
1.4 Background
1.4.1 EU Regulation
The latest EU regulation draft contains requirements for conveying messages between operators,
USSPs, and ATSUs involved in a given area whenever a non-conforming operation is detected. [EASA-
Commission-Draft], Article 13, Conformance monitoring service refers:
"1. A conformance monitoring service shall enable the UAS operators to verify
whether they comply with the requirements set out in Article 6(1) and the terms
of the UAS flight authorisation. To this end, this service shall alert the UAS
operator when the flight authorisation deviation thresholds are violated and
when the requirements in Article 6(1) are not complied with.
2. Where the conformance monitoring service detects a deviation from the flight
authorisation, the U-space service provider shall alert the other UAS operators
operating in the vicinity of the UAS concerned, other U-space service providers
offering services in the same airspace and relevant air traffic services units,
which shall acknowledge the alert."
1.4.2 EUROCONTROL Specification for Monitoring Aids (MONA)
EUROCONTROL MONA [EC-MONA] defines conformance monitoring as follows.
“2.2. Conformance Monitoring
The conformance monitoring function compares the system tracks with the
corresponding flight clearances in order to warn the controller of any deviation
of a flight from its clearance and, where possible, to establish the progress of
the flight and to refine the prediction of the remaining trajectory to be flown.
Conformance is monitored in three dimensions, though the monitoring

performed varies according to the type of clearance issued. In principle,
warnings of deviation are generated in cases where the controller might be
required to act to re-clear an aircraft that is assumed to be deviating from its
clearance or to re-coordinate an aircraft whose boundary estimate changes
significantly.
The [TP-SPEC] defines a planned trajectory and a tactical trajectory. Where

possible, the system recalculates the trajectories that are active for a flight
according to the actual behaviour of the aircraft, as described below.
..."
EUROCONTROL CORUS [CORUS] Vol. 2 elaborates in 5.1.6.1 Monitoring service as follows.
“5.1.6.1 Monitoring service
Subject to appropriate data-quality requirements, this service retrieves data

from the tracking service and combines it with information related to non-
8
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 5.1.2.2), weather limit compliance monitoring,
ground risk compliance monitoring, electromagnetic risk monitoring. The geo-
fence compliance monitoring and warnings constitute U-space providing Geo-
Awareness.
..."
ICAO Doc 10039 [ICAO-SWIM] elaborates in section 3.4 INFORMATION EXCHANGE SERVICES on
information exchange services as follow (para. 3.4.2).
“Within the SWIM Global Interoperability Framework, the Information

Exchange layer is instantiated by ‘information services’ as is further explained.
Information services ensure interoperability between ATM applications which
consume and provide interoperable information services. Consequently, the
concept of information service is a fundamental building block of SWIM which
enables interoperability through well-defined information exchanges.”
1.4.5 SESAR-JU
is being driven by a rapidly growing market of EVery-Low-Level (VLL) airspace users, most of which are
Via the Roadmap for the safe integration of drones into all classes of airspace [EATMP-Drone], within
the European ATM Masterplan [EATMP], the European Commission seeks to ensure that this rapid
growth of airspace use happens in a safe and controlled manner.
[EATMP-Drone], in alignment with ICAO recommendations, identifies three phases for the integration,
from which SESAR derives the four U-space service blocks presented in the U-space blueprint
[UspaceBlueprint],
has been, and is being, validated throughout Europe via several Very Large Demonstrator (VLD)
projects such as the GOF USPACE project.
During the U1 phases, SESAR expects drones capable to supply their position via telemetry. The U1 and
U2 blocks are anticipated to provide tracking capabilities and services.
9
1.4.6 Efficient, Safe and Sustainable Traffic at Sea (EfficienSea2)
The design method and terminology builds on experience from the EfficienSea2 project [EfficienSea2],
[IALA-ENAV].
1.5 Glossary of Terms

Term Definition
External Data Describes the semantics of the domain (or a significant part thereof) by
Model defining data structures and their relations. This could be at logical level, e.g.
in UML or at physical level, e.g. in XSD schema definitions, as for example
Message Describes the principles how two different parts of a message passing system
Exchange Pattern (in our case: the service provider and the service consumer) interact and
service provider in order to obtain certain information; the service provider
provides the requested information in a dedicated response.
Operational An activity performed by an operational node. Examples of operational

Activity activities are: Route Planning, Route Optimization, Logistics, Safety, Weather
Operational Node A logical entity that performs activities. Note: nodes are specified
Service The provision of something (a non-physical object), by one, for the use of one
Services involve interactions between providers and consumers, which can be
Service Data Formal description of one dedicated service at logical level. The service data
Model model is part of the service specification. Is typically defined in UML and/or
XSD. If an external data model exists, e.g. a standard data model, then the
10
Service Design Documents the details of a service technical design (most likely documented
Description by the service implementer). The service design description includes (but is not
limited to) a service physical data model and describes the used technology,
Service The provider side implementation of a dedicated service technical design, i.e.
Implementation implementation of a dedicated service in a dedicated technology.
Service Instance One service implementation may be deployed at several places by same or
different service providers; each such deployment represents a different
Service Instance Documents the details of a service implementation (most likely documented
Description by the service implementer) and deployment (most likely documented by the
Service Interface Communication mechanism of the service, i.e., interaction mechanism

characterised by a message exchange pattern and consists of service
service.
Service Operation Functions or procedure which enables programmatic communication with a

Data Model technology. This includes a detailed description of the data payload to be
data model. This means, each data item used in the service physical data model
shall be mapped to a corresponding data item of the service data model. (In
case of existing mappings to a common external (standard) data model from
both the service data model and the service physical data model, such a
mapping is implicitly given.)
Service Provider A service provider provides instances of services according to a service

11

Service Describes one dedicated service at logical level. The Service Specification is
Specification technology-agnostic. The Service Specification includes (but is not limited to) a
Data Model.
Service Producers of service specifications in accordance with the service

Specification documentation guidelines.
Producer
Service Technical Technical design of a dedicated service in a dedicated technology. One service
Design specification may result in several technical service designs, realising the

Technology Currently, SOAP and REST are envisaged to be allowed service technologies.
Catalogue The service technology catalogue shall describe in detail the allowed service
profiles, e.g., by listing communication standards, security standards, stacks,
bindings, etc.
Spatial Service specification is characterised as "spatially exclusive", if in any

Exclusiveness geographical region only one service instance of that specification is allowed
to be registered per technology.
governance issue.
Tab. 1: Glossary of Terms

Acronym Definition
12
Tab. 2: List of Acronyms
13
This chapter gives a unique identification of the service and describes where the service is in terms of
the engineering lifecycle.
Name OperationalMessageExchange Service
ID urn:frequentis:services:OperationalMessageExchangeService
Version 1.0
Description A service which exchanges operational messages between UAS operators, USSPs, or
ATSU including such to alert a party about a non-conforming operation, and require a
corresponding acknowledgement.
Keywords OperationalMessage Service, U-space, Warning, Alert
Architect(s) 2021-today The Frequentis Group
2021-2022 The GOF2.0 U-Space Project Consortium
Status Provisional
Tab. 3: Service Identification
14
This section describes the context of the service from an operational perspective

The table below lists applicable existing requirements for the OperationalMessageExchange service:

Id Name
[R-1] Common At all times, all U-space CORUS [CORUS], 3.1.1.2 Z

Situational participants shall operate on Volumes; B1-RPAS [ICAO-
Awareness the same common set of data, GANP];CEF-SESAR-2018-1
during pre-flight planning [GOF1-I-CFP], Objective O5
stages as well as during all
stages of flight operations.
[R-2] Basis for Open The U-space concept shall be SESAR Drone Roadmap
Market designed such as to ensure a [EATMP-Drone], Foreword,
well-established line of 4.1 and 4.2;U-space
authority while at the same Blueprint
time ensuring that an open [UspaceBlueprint], Benefits
market for VLL services may to European society and
develop economy; CEF-SESAR-2018-
1 [GOF1-I-CFP], Table 8 –
Key Challenges
[R-3] Interoperability There shall be an ICAO Doc 10039 [ICAO-

implementation of a Flight SWIM];[R-2];CEF-SESAR-
Information Management 2018-1 [GOF1-I-CFP],
System (FIMS) which ensures Objective O6; CEF-SESAR-
that, at all times, emerging 2018-1 [GOF1-I-CFP], Table
unmanned traffic management 8 – Key Challenges
systems and existing
technologies from manned Note: The term 'Flight
operations can exchange any Information Management
data required to support such System (FIMS)' in some of
common situational awareness, these references has been
be it for drone operations in since replaced by 'Common
areas where established ATC Information Services (CIS)'.
procedures apply, or in zones This text hence elsewhere
outside established ATC. refers to CIS, rather than
FIMS.
[R-4] Standard Standard communication [R-2];SESAR Drone

Protocols protocols shall hence be used Roadmap [EATMP-Drone],
where available, and such 3.5, section ‘Standards’;
standard protocols be CEF-SESAR-2018-1 [GOF1-I-
15
developed otherwise, in order CFP], Table 8 – Key

to ensure the lowest level of Challenges
obstruction for an open VLL
[R-5] Open Interfaces Any interface and protocol [R-2];CEF-SESAR-2018-1

hence must be openly defined [GOF1-I-CFP], Table 8 – Key
and its definition be freely Challenges
accessible in order to ensure the
lowest level of obstruction for
an open VLL airspace use
market to develop.
[R-6] SWIM The implementation of a Flight [R-3];CEF-SESAR-2018-1

Information Management [GOF1-I-CFP], 5.3.4 Overall
System (FIMS) shall be based on approach and methodology
architecture. Note: The term 'Flight
System (FIMS)' used therein
has been since replaced by
'Common Information
hence elsewhere refers to
CIS, rather than FIMS.
[R-7] Latency Under no operational [FAA-SUR-PERF], tables in

circumstance, the processing of the Executive Summary,
position data may add [EC-ATM-PERF], 3N_C-R8
significant latency to the overall and 5N_C-R8
detection-to-display latency of
position data. In particular,
The processing latency added

by the processing of positional
data shall never exceed 10 per
cent of the maximum value of
the corresponding value
automation system.
The processing latency and

delay added by the processing
of positional data should not
exceed 1 per cent of the
maximum value of the
corresponding value permitted
for the entire ATM automation
system.
16

values defined by the ATM
system performance
requirements by EUROCONTOL
and the FAA; for a 3 NM minimal
separation, this is 2.2 s, for a 5
NM separation, 2.5 s.
[R-8] UAS flight The UAS flight authorisation [EASA-Commission-Draft],

authorisation request shall comprise the Annex IV
request following information:
1. the unique serial number of

the unmanned aircraft or, if the
unmanned aircraft is privately
built, the unique serial number
of the add-on;
2. mode of operation;
3. type of flight (special

operations);
4. category of UAS operation

(‘open’, ‘specific’, ‘certified’)
and UAS aircraft class or UAS
type certificate if applicable;
5. 4D trajectory;
6. identification technology;
7. expected connectivity
methods ;
8. endurance;
9. applicable emergency
procedure in case of a loss of
command and control link;
10. registration number of the

UAS operator and, when
applicable, of the unmanned
aircraft.1.
[R-9] Non-conformance Subject to the airspace type [EASA-Commission-Draft],

alerting and requirements, there shall be Article 13
acknowlegement continuous oversight about the
compliance of U-space
operations with the
17
corresponding flight
authorization.
There must be means to alert

the UAS operator conducting an
operation about any non-
compliance with his flight
authorization.
There must be means to alert

other UAS operators operating
in the vicinity of the non-
compliant operation about this
circumstance, other U-space
service providers offering
services in the same airspace
and relevant air traffic services
units, all which shall
acknowledge the alert.
Tab. 4: Requirements for the OperationalMessageExchange Service

3.2.1.1 ICAO SWIM

The System Wide Information Management (SWIM, [ICAO-SWIM]) complements human-to-human
with machine-to-machine communication, and improves data distribution and accessibility in terms of
The OperationalMessageExchange Service may consume and/or refer to information from a number
of other services nodes including the following ones.
Operational Service Node Remarks
OperationPlan Operation plans from the OperationPlan service, e. g. of a USSP,

or an ATSU/ATSP
UasRegistration Registry data from the UAS Registry service, e. g. of a USSP or an

authority
TrafficTelemetry PositionReports from the Traffic/Telemetry service, e. g. of a UAS

operator, USSP, a CIS, a SDSP, an aircraft, or an ATSU/ATSP
18
GeoZone GeoZone data from the GeoZone service, e. g. of a USSP, an

ATSU/ATSP, or an authority
TrafficConformanceMonitoring Traffic/Telemetry-based conformance monitoring service, e. g. of

a USSP, an ATSU/ATSP, or an authority
Tab. 5: Operational Services Nodes Providing Data for the OperationalMessageExchange Service
Operational nodes which may consume the service include the following ones:
Operational Remarks
Node
GCS / UAS Operator ground control station of a UAS operator operating in the same area as
Operator this OperationalMessageExchange service
USSP Other USSP(s) operating in the same area as this OperationalMessageExchange

service
ATSU / ATSP Air traffic service unit(s) or air traffic services provider operating in the same area
as this OperationalMessageExchange service
SDSP Supplementary data service provider(s) operating in the same area as this
OperationalMessageExchange service
CIS Common Information Servces operating in the same area as this

OperationalMessageExchange service
Tab. 6: Operational Nodes Consuming the OperationalMessageExchange Service
Operational activities supported by the service include the following ones:
Operational Activity Remarks
Pre-Flight Short-term communication with other stakeholders possible, e. g. to

prevent a pending immediate take-off.
Normal flight Communication of traffic advisories, or operational commands such as

operations order to land immediately.
Abnormal flight Communication of non-conforming or emergency operational state.

operations
Post-flight activities Evaluation of any message exchange for statistics or conformance

evaluation purposes.
Tab. 7: Operational Activities Supported by the OperationalMessageExchange Service
19
4 Service Interfaces
Figure 1 OperationalMessageExchangeService Interface Definition diagram
An operator subscribes to the OperationalMessageExchangeSunscriptionInterface of her USSP for

each one of her operationPlanId.
A USSP or ATSU subscribes to the OperationalMessageExchangeSubscriptionInterface for its

areaOfInterest of the other USSPs or ATSUs operating that area, as does a monitoring consumer which
subscribeOperationalMessageMonitoring.
ServiceInterface Role ServiceOperation

(from
service
provider
point of
view)
OperationalMessageSubscriptionInterface Provide subscribeForOperationalMessages

d
unsubscribeForOperationalMessages
subscribeOperationalMessageMonitori
ng
OperationalMessageAcknowledgementInterf Provide acknowlegeOperationalMessage

ace d
OperationalMessageNotificationInterface Require notifyOperationalMessage

d
notifyAcknowledgementState
Tab. 8: Service Interfaces
20

5.1 Overview
The OperationalMessageExchange service transfers operational messages, such as instructions by air
traffic control or a UTM service provider (e. g. "Land now!"), and the corresponding acknowledgements
via the OperationalMessage and AckMessage a data structures, respectively.
Such message exchange may take place between an operator and 'her' UTM service provider (USP), or
between the involved USPs and/or air traffic services units (ATSU).
Each OperationalMessage shall be acknowledged by a corresponding AckMessage. Reference to the

related operationPlan(s) should be provided. Likewise, the corresponding droneRegistration(s),
positionInfo and reference to airspace(s) may be provided as required.
Figure 2: Data Model diagram of the Identification Service
21
5.2 OperationalMessage Data Structure

The OperationalMessage data structure carries the details of operational information being
exchanged.
Property Type Multipli Description Note

city
messageId UUID 1 Globally

unique Operational
Message identifier
source string 1 The name of the Should be a

source of the recognized string
OperationalMessage by the CIS.
time DateTime 1 The time stamp when

the
OperationalMessage
was sent
messageSeve EnumOperationalMessag 1 The severity of the

rity eSeverity OperationalMessage.
messageType EnumOperationalMessag 1 The type of the

eType OperationalMessage.
freeText string 0..1 Additional textual

description of the
OperationalMessage
.
messageStat EnumOperationalMessag 1 The state

e eState the OperationalMes
sage is in when it was
sent
operationPla reference to 0..* List of references to May consist of a

n OperationPlan OperationPlans list of UUIDs,
the OperationalMes referring to the
sage is related to. OperationPlan
identifiers.
droneRegistr UasRegistration 0..* UAS Registration May be omitted if

ation Information information is
present in the
referred
OperationPlan.
positionInfo PositionReport 0..* Positional indication

of the
22
OperationalMessage
.
airspace GeoZone 0..1 Optional reference to

an airspace.
relatedMessa reference to 0..* List of references to may consist of a list

ges OperationalMessage other related of UUIDs, referring
OperationalMessage to
objects the OperationalM
essage identifiers.
Tab. 9: The OperationalMessage data structure
5.3 AckMessage Data Structure

The AckMessage data structure carries the acknowledgements to an OperationalMessage.
ackMsgId UUID 1 Globally unique

AckMessage identifier
msgBeingAcknowledged UUID 1 UUID of the

OperationalMessage
which this AckMessage
acknowledges
acknowlegement EnumAcknowlegement 1 The kind of

acknowlegement
returned by this
AckMessage
Tab. 10: The AckMessage data structure
5.4 EnumOperationalMessageSeverity Enumeration

The EnumOperationalMessageSeveroty enumeration type specifies the OperationalMessage
severtities.
EMERGENCY There is an *immediate* impact to the safety of other air operations, the
safety of people, or the safety of structures on the ground. Actions to
mitigate required by other operations.
ALERT There may be an impact to the safety of other air operations, the safety of
people, or the safety of structures on the ground. Actions to mitigate
required by other operations.
23
CRITICAL Without mitigations by the affected operation, the situation may rise to an
emergency in the near future.
WARNING There is a contained issue in this OperationalMessage that may result in

the loss of aircraft. No immediate or likely effect to other operations,
people on the ground, or structures.
NOTICE The information conveyed in this OperationalMessage is provided for

situational awareness. Planning by operators and USSs may be affected.
INFORMATION The information conveyed in this OperationalMessage is provided for

situational awareness.
Tab. 11: EnumOperationalMessageSeverity Enumeration
5.5 EnumOperationalMessageType Enumeration

The EnumOperationalMessageType enumeration type specifies the OperationalMessage types.
LAND_NOW Instruct the receiver to land

the drone immediately.
CONTACT_TOWER Instruct the receiver to

contact the ATC tower.
CAUTION_TRAFFIC Informs the receiver about

nearby traffic.
CONFIRM_LANDED Informs the receiver that the

drone was landed.
OPERATION_CONFORMING Informs the receiver about a

conforming operation.
OPERATION_NONCONFORMING Informs the receiver about a

non-conforming operation.
ACTIVATE_CONTINGENCY Informs the receiver that the

state of Contingency has been
entered
ACTIVATE_EMERGENCY Informs the receiver that the

state of Emergency has been
entered
OTHER Any other message as This option should not be used,

described in the freeText as it cannot be processed
field. automatically.
Tab. 12: EnumAertType Enumeration
24
5.6 EnumOperationalMessageSeverity Enumeration

The EnumOperationalMessageSeverity enumeration type specifies the OperationalMessage
severtities.
EMERGENCY There is an *immediate* impact to the safety of other air operations, the
safety of people, or the safety of structures on the ground. Actions to
mitigate required by other operations.
ALERT There may be an impact to the safety of other air operations, the safety of
people, or the safety of structures on the ground. Actions to mitigate
required by other operations.
CRITICAL Without mitigations by the affected operation, the situation may rise to an
emergency in the near future.
WARNING There is a contained issue in this OperationalMessage that may result in

the loss of aircraft. No immediate or likely effect to other operations,
people on the ground, or structures.
NOTICE The information conveyed in this OperationalMessage is provided for

situational awareness. Planning by operators and USSs may be affected.
INFORMATION The information conveyed in this OperationalMessage is provided for

situational awareness.
Tab. 13: EnumOperationalMessageSeverity Enumeration
5.7 EnumOperationalMessageState Enumeration

The EnumOperationalMessageState enumeration type specifies the possible OperationalMessage
states.
OPEN At the time of the transmission of this OperationalMessage,

it was in the OPEN state.
PARTIALLY_ACKNOWLEDGED At the time of the transmission of this OperationalMessage,

it has been PARTIALLY_ACKNOWLEDGED, i. e., with some
acknowlegements received, at least one expected
acknowledgement was outstanding.
ACKNOWLEDGED At the time of the transmission of this OperationalMessage,

it has been ACKNOWLEDGED from all recipients.
CLOSED At the time of the transmission of this OperationalMessage,

it was in the CLOSED state.
Tab. 14: EnumOperationalMessageState Enumeration
25
5.8 EnumAcknowlegement Enumeration

The EnumAcknowlegement enumeration type specifies the available kinds of OperationalMessage
acknowlegements available.
WILCO Indicates that the acknowledging party will cooperate and comply with an
instruction.
UNABLE Indicates that the acknowledging party CANNOT cooperate and will NOT comply
with an instruction.
AFFIRM Indicates that the acknowledging party received the information conveyed via
the corresponding OperationalMessage and confirms it.
NEGATIVE Indicates that the acknowledging party received the information conveyed via
the corresponding OperationalMessage but does NOT confirm it.
ROGER Indicates that the acknowledging party received the information conveyed via
the corresponding OperationalMessage.
Tab. 15: EnumAcknowlegement Enumeration
5.9 OperationPlan Data Structure

The OperationPlan data structure is defined in the OperationPlanExchange Service data model.
5.10 UasRegistration Data Structure

The UasRegistration data structure is defined in the OperationPlanExchange Service data model.
5.11 PositionReport Data Structure

The PositionReport data structure is defined in the TrafficTelemetry Service data model.
26

This chapter describes the details of each service interface. Each Service Interface has its own sub-
chapter.
6.1 Service Interface OperationalMessageSubscriptionInterface

6.1.1 Operation subscribeForOperationalMessages

A consumer calls this operation to subscribe for receiving operational messages related to a certain
geographical area of interest, or related to a certain operation plan.
The operation either expects an operationPlanId or an areaOfInterest input parameter.

Parameter Direction Data Type Description
Name
consumer Input NotificationEndpoint Which endpoint shall be notified in case of

new OperationalMessages
operationPlanId Input UUID GUFI of the OperationPlan of interest to the

consumer
Tab. 16: Payload Description of subscribeForOperationalMessage Operation
6.1.2 Operation subscribeForOperationalMessageMonitoring

A consumer calls this operation to subscribe to monitoring of operational messages related to a certain
geographical area of interest.

Name

new OperationalMessages
27
Tab. 17: Payload Description of subscribeForOperationalMessageMonitoring Operation
An operator subscribes to the OperationalMessageExchangeSunscriptionInterface of her USSP for

each one of her operationPlanId.

6.1.3 Operation unSubscribeForOperationalMessages

A consumer calls this operation at the provider to unsubscribe from operational messages related to
a certain geographical area of interest or related to a certain operation plan.

Name
consumer Input NotificationEndpoint Which endpoint shall be not be notified

(anymore) in case of new
OperationalMessages
operationPlanId Input UUID GUFI of the OperationPlan of interest to the

consumer, as given in the subscription
areaOfInterest Input AreaOfInterest Area of interest to the consumer, as given in

the subscription
Tab. 18: Payload Description of unSubscribeForOperationalMessages Operation
6.2 Service Interface OperationalMessageNotificationInterface

Consumer provides this interface, allowing the service provider to submit to the consumer operational
messages.
6.2.1 Operation notifyOperationalMessage

Once and while subscribed, consumer receives operational messages via this operation.

28
operationalMessage Input OperationalMessage An operational message that matches the

OperationPlan UUID or area criterium
provided with the subscription
Response Return ServiceResponse Technical confirmation that the

notification was delivered.
Tab. 19: Payload Description of notifyOperationalMessage Operation
6.2.2 Operation notifyOperationalMessageState

Once and while subscribed, consumer receives state changes of the operational message via this
operation.

messageId Input UUID Unique identifier of the

message for which a
state change is notified.
operationalMessageState Input EnumOperationalMessageState The state of the

operational message that
matches the
OperationPlan UUID or
area criterium provided
with the subscription
Response Return ServiceResponse Technical confirmation

that the notification was
delivered.
Tab. 20: Payload Description of notifyOperationalMessageState Operation
6.3 Service Interface

OperationalMessageAcknowledgementInterface
6.3.1 Operation acknowledgeOperationalMessage

A consumer calls this operation to acknowledge an operational message.

acknowledgeOperationalMessage Input AckMessage Acknowledgment to

operational message as
requested by the OperationPlan
29
UUID or area criterium provided

with the subscription
Response Return ServiceResponse Technical confirmation that the

acknowledgement was
delivered.
Tab. 21: Payload Description of acknowledgeOperationalMessage Operation
30

Figure 3: OperationalMessageExchange service operation sequence diagram
31
7.2 OperationalMessage State Machine
Figure 4 OperationalMessage states - state transition diagram
32
8 References
[CORUS] Ed. CORUS Vol. 1, Enhanced Overview

01.01.0 https://www.sesarju.eu/sites/default/files/documents/u-
3 space/CORUS%20ConOps%20vol1.pdf
CORUS Vol. 2, U-space Concept of Operations
Ed. https://www.sesarju.eu/sites/default/files/documents/u-
03.00.0 space/CORUS%20ConOps%20vol2.pdf
2
[EASA- n/a Annex to EASA Opinion No 01/2020,

Commission-Draft] (03/03/ https://www.easa.europa.eu/document-library/opinions/opinion-
2021) 012020
COMMISSION IMPLEMENTING REGULATION (EU) .../...of XXXon a

high-level regulatory framework for the U-space,
https://ec.europa.eu/transparency/regexpert/index.cfm?do=grou
pDetail.groupMeetingDoc&docid=48688
ANNEXES to the COMMISSION IMPLEMENTING REGULATION on

aregulatory framework for the U-space,
https://ec.europa.eu/transparency/regexpert/index.cfm?do=grou
pDetail.groupMeetingDoc&docid=48689
[EASA-Incident- 08.03.2 EASA Manual on Drone Incident Management at Aerodromes

Manual] 021
PART 1: The challenge of unauthorised drones in the surroundings
of aerodromes
PART 2: Guidance and recommendations
PART 3: Resources and practical tools
https://www.easa.europa.eu/newsroom-and-events/press-
releases/easa-issues-guidelines-management-drone-incidents-
airports
[EATMP] 2020 SESAR, eATM PORTAL, European ATM Master Plan,

https://www.atmmasterplan.eu/
[EATMP-Drone] n/a SESAR, European ATM Master Plan: Roadmap for the safe
integration of drones into all classes of airspace
[EC-ATM-PERF] Ed. 1.2 EUROCONTROL Specification for ATM Surveillance System

Performance (ESASSP), EUROCONTROL-GUID-
0147, https://www.eurocontrol.int/publication/eurocontrol-
specification-atm-surveillance-system-performance-esassp
[EC-ASTERIX] n/a ASTERIX Library: ASTERIX, All-purpose structured EUROCONTROL

surveillance information exchange, Defining the low level
33
implementation of a data format used for exchanging surveillance-

related information in ATM applications. Available at
[EC-MONA] Ed. 2.0, EUROCONTROL Specification for Monitoring Aids, EUROCONTROL-

03/03/2 SPEC-0142,
017 https://www.eurocontrol.int/sites/default/files/publication/files/
EUROCONTROL-SPEC-0142%20MONA%20Ed%202.0.pdf
[EC-SN-Guide] August Safety Nets, A guide for ensuring effectiveness,

2017 https://www.eurocontrol.int/sites/default/files/publication/files/
safety-nets-guide-august-2017.pdf
[EfficienSea2] n/a Efficient, safe and sustainable traffic at sea (EfficienSea2), a Horizon
2020 Project, Grant Agreement No 636329
https://efficiensea2.org/wp-
content/uploads/2018/04/Deliverable-3.6.Standard-proposal-for-
Maritime-Cloud-service-specification.pdf
[FAA-SUR-PERF] 1 Massachusetts Institute of Technology Lincoln Laboratory for the

Novem Federal Aviation Administration, Project Report ATC-323, Required
ber Surveillance Performance Accuracy to Support 3-Mile and 5-Mile
2006 Separation in the National Airspace System,
https://www.ll.mit.edu/sites/default/files/publication/doc/2018-
[FAA-UAS- V1.0 Federal Aviation Administration NextGEN Concept of Operations,

CONOPS] Foundational Principles, Roles and Responsibilities, Use Cases and
Operational Threads, Unmanned Aircraft System (UAS), Traffic
Management (UTM)
[FALKE-ARCH] V1.0 FALKE System Architecture
[FALKE-GVB] 21.08.2 Gesamtvorhabensbeschreibung zum Verbundprojekt "Fähigkeit

019 des Abfangens von in gesperrte Lufträume eindringenden
Kleinfluggeräten durch zivile Einsatzmittel" (FALKE), Az: DG20-
837.4/4-1
[FOCA-USPACE- 1.0 Federal Office of Civil Aviation (FOCA), Swiss U-Space ConOps, U-
CONOPS] Space Program Management, 31.10.2018, FOCA muo / 042.2-
00002/00001/00005/00021/00003
[GOF1-Arch- 00.05.0 SESAR 2020 GOF USPACE FIMS Design and Architecture, Appendix
AppA] 0 A Service Description Templates, document SESAR 2020 GOF
USPACE Service Documentation Guidelines
[GOF1-I-CFP] n/a CFP Reference CEF-SESAR-2018-1, "Finnish-Estonian "Gulf of

Finland" Very Large U-Space Demonstration"
34
[GUTMA-FLP] n/a Global UTM Association (GUTMA) Flight Logging Protocol,

https://github.com/gutma-org/flight-logging-
protocol/blob/master/Flight_logging_protocol.md
[GUTMA-ATP] n/a Global UTM Association (GUTMA) Air Traffic

Protocol, https://github.com/hrishiballal/airtraffic-data-protocol-
development
[IALA-ENAV] Ed. 1.1 IALA specification for e-navigation technical services

https://www.iala-aism.org/product/g1128-specification-e-
navigation-technical-services
[IATA-SR2014] 51st Edi IATA Safety Report 2014 (Issued April 2015)
tion http://www.aviation-accidents.net/report-
download.php?id=90003
[ICAO-GANP] 5th Ed. - ICAO Doc. 9750-AN/963, Global Air Navigation Plan (GANP) 2016-
2016 2030
[ICAO-SWIM] Advanc ICAO Doc 10039, Manual on System Wide Information

ed Management (SWIM) Concept
Edition
(unedit
ed)
[IDD] V1.0 FALKE Interface Definition Document
[INTEL-ODID] 0.61.1 Intel Corporation, Open Drone ID Message Specification, Draft

Specification, November 13, 2018
[OASIS-SOA] 12 Reference Model for Service Oriented Architecture 1.0, OASIS

October Standard
200 http://docs.oasis-open.org/soa-rm/v1.0
[OSED-CUAS] n/a EUROCAE ED-286 Operational Services and Environment Definition

for Counter-UAS in Controlled Airspace
[UspaceArchitectu Ed. Initial view on Principles for the U-space architecture

rePrinciples] 01.04 https://www.sesarju.eu/sites/default/files/documents/u-
space/SESAR%20principles%20for%20U-
space%20architecture.pdf
[UspaceBlueprint] 2017 SESAR-JU, U-space Blueprint,

https://www.sesarju.eu/u-space-blueprint
Tab. 22: List of References
35
D2.4 Appendix F Traffic

Conformance Monitoring
Exchange Service
Specification
Deliverable ID: D2.4-F
Grant: 101017689
Topic:
Air Mobility
Edition: 01.00.00
D2.4 APPENDIX F TRAFFIC CONFORMANCE MONITORING EXCHANGE SERVICE
SPECIFICATION


2
SPECIFICATION


Document History
00.00.01 21.04.2021 Draft Peter CORNELIUS Document created.
Copyright Statement
3
SPECIFICATION
GOF2.0
Figure 1
Abstract
Exchange Service.
This document describes one of these Bridge Services, the Traffic Conformance Monitoring Exchange
service in a logical, technology-independent manner.
4
SPECIFICATION
Table of Contents
Abstract ................................................................................................................................... 4
1 Introduction ............................................................................................................... 7
1.2 Scope ............................................................................................................................ 7
1.3 Target Group ................................................................................................................. 7
1.4 Background ................................................................................................................... 8
1.4.1 EUROCONTROL Specification for Monitoring Aids (MONA).............................................................. 8
1.4.2 EUROCONTROL Safety Nets, A Guide for Ensuring Effectiveness ..................................................... 8
1.4.4 International Civil Aviation Organization (ICAO) ............................................................................... 9
1.4.5 Open Drone ID................................................................................................................................... 9
1.4.6 SESAR-JU.......................................................................................................................................... 10
1.4.7 Efficient, Safe and Sustainable Traffic at Sea (EfficienSea2) ........................................................... 10
1.5 Glossary of Terms ........................................................................................................ 10
1.6 List of Acronyms .......................................................................................................... 13
4.1 Overview..................................................................................................................... 23
4.1 TrafficConformanceMonitoringReport Data Structure .................................................. 24
4.2 TrafficNonConformanceReport Data Structure ............................................................. 24
4.3 TrafficConformanceMonitoringStatus Data Structure ................................................... 31
4.4 EnumConformanceMonitoringFunction Enumeration ................................................... 31
4.5 EnumConflictSeverity Enumeration .............................................................................. 33
4.6 TrafficConformanceMonitoringObject Data Structure ................................................... 34
4.7 ObjectIdentification Data Structure.............................................................................. 35
4.8 The Position Data Structure ......................................................................................... 39
4.9 The Altitude Data Structure ......................................................................................... 40
4.10 The EnumAltitudeType Enumeration ........................................................................... 42
4.11 The EnumCRSType Enumeration ................................................................................. 42
5
SPECIFICATION
4.12 The AltitudeDeterminationMethod Enumeration ........................................................ 42

4.13 Separation Data Structure............................................................................................ 42

5.1 Service Interface TrafficConformanceMonitoringSubscriptionInterface ......................... 47
5.1.1 Operation subscribeForTrafficConformanceMonitoring ................................................................ 47
5.1.2 Operation unSubscribeForTrafficConformanceMonitoring ............................................................ 47
5.2 Service Interface TrafficConformanceMonitoringNotificationInterface .......................... 48
5.2.1 Operation notifyTrafficConformanceMonitoringReport ................................................................. 48

6.1 Service Interfaces TrafficConformanceMonitoringSubscriptionInterface and
TrafficConformanceMonitoringNotificationInterface ............................................................... 49
8 References ............................................................................................................... 51
6
SPECIFICATION
1 Introduction
Based on the guidelines given in [GOF1-Arch-AppA], this document describes the
TrafficConformanceMonitoring exchange service of a Common Information Service (CIS) in a logical
technology-independent manner, that is:
 operational and business context of the service

o requirements for the service, e.g. information exchange requirements
 service description
In addition, this document clearly defines the version of the service.
1.2 Scope
This document describes the TrafficConformanceMonitoring Exchange service for a CIS.
The TrafficConformanceMonitoring service provides a means for the operational nodes of the U-space
to exchange conformance-related target information and make it available for further processing.
1.3 Target Group

This service specification is written for:
 system engineers and
 developers in charge of designing and developing an instance of the
TrafficConformanceMonitoring service.
In addition, this service specification is written for:
 enterprise architects,
 information architects,
 system engineers and developers in pursuing architecting, design and development activities
of other related services.
7
SPECIFICATION
1.4 Background
1.4.1 EUROCONTROL Specification for Monitoring Aids (MONA)
EUROCONTROL MONA [EC-MONA] defines conformance monitoring as follows.
“2.2. Conformance Monitoring
The conformance monitoring function compares the system tracks with the
corresponding flight clearances in order to warn the controller of any deviation
of a flight from its clearance and, where possible, to establish the progress of
the flight and to refine the prediction of the remaining trajectory to be flown.
Conformance is monitored in three dimensions, though the monitoring

performed varies according to the type of clearance issued. In principle,
warnings of deviation are generated in cases where the controller might be
required to act to re-clear an aircraft that is assumed to be deviating from its
clearance or to re-coordinate an aircraft whose boundary estimate changes
significantly.
The [TP-SPEC] defines a planned trajectory and a tactical trajectory. Where

possible, the system recalculates the trajectories that are active for a flight
according to the actual behaviour of the aircraft, as described below.
..."
1.4.2 EUROCONTROL Safety Nets, A Guide for Ensuring Effectiveness
To ATM automation systems, EUROCONTROL applies such conformance monitoring aids in the form
of so-called ground-based safety nets which have been shown to very significantly improve ATM safety
[EC-SN-Guide]:
"What are safety nets?
Even the safest systems fail. Safety nets help prevent imminent or actual
hazardous situations from developing into major incidents or even accidents. In
doing so, they provide additional safety barriers in the overall system. In
addition, they help keep the societal outcome of aviation operations within
acceptable limits.
In Professor James Reason's Swiss Cheese Model, safety nets are the last system
safety defences against accidents. They are intended to provide timely alerts to
air traffic controllers or pilots of an increased risk to flight safety. As the impact
of accidents in aviation is high, multiple system safety defences are provided,
including redundant safety nets.
Safety nets are either ground-based or airborne:
Ground-based safety nets are an integral part of the ATM system. Primarily
using ATS surveillance data, they provide warning times of up to two minutes.
Upon receiving an alert, air traffic controllers are expected to immediately
assess the situation and take appropriate action.
8
SPECIFICATION
Airborne safety nets provide alerts and resolution advisories directly to the
pilots. Warning times are generally shorter, up to about 40 seconds. Pilots are
expected to immediately take appropriate avoiding action.
Airborne safety nets are covered only in terms of their interactions with ground
systems. ..."
"... Safety nets are there to provide an additional safety margin on top of the
inherently safe provision of ATS and aviation operations. They have been
demonstrated to deliver additional risk reduction of up to a factor of ten if
implemented and operated appropriately. ..."
EUROCONTROL CORUS [CORUS] Vol. 2 elaborates in 5.1.6.1 Monitoring service as follows.
“5.1.6.1 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 5.1.2.2), weather limit compliance monitoring,
ground risk compliance monitoring, electromagnetic risk monitoring. The geo-
fence compliance monitoring and warnings constitute U-space providing Geo-
Awareness.
..."
ICAO Doc 10039 [ICAO-SWIM] elaborates in section 3.4 INFORMATION EXCHANGE SERVICES on
information exchange services as follow (para. 3.4.2).
“Within the SWIM Global Interoperability Framework, the Information

Exchange layer is instantiated by ‘information services’ as is further explained.
Information services ensure interoperability between ATM applications which
consume and provide interoperable information services. Consequently, the
concept of information service is a fundamental building block of SWIM which
enables interoperability through well-defined information exchanges.”
1.4.5 Open Drone ID
Open Drone ID is a project to provide a low cost and reliable “beacon” capability for drones so that
they can be identified when within range of a receiver. Open Drone ID receives support from large
companies such as Intel.
The Open Drone ID Message Specification [INTEL-ODID] proposes a Location Message in both, a byte
and a JSON representation, which permits the transport of:
 a position in three space dimensions,

9
SPECIFICATION
 a velocity, and
 a data age.
The Open Drone ID Message Specification furthermore proposes messages to convey information
about:
 the type of drone,

 its in-flight status, and
 the location of the drone operator.
1.4.6 SESAR-JU
is being driven by a rapidly growing market of EVery-Low-Level (VLL) airspace users, most of which are
Via the Roadmap for the safe integration of drones into all classes of airspace [EATMP-Drone], within
the European ATM Masterplan [EATMP], the European Commission seeks to ensure that this rapid
growth of airspace use happens in a safe and controlled manner.
[EATMP-Drone], in alignment with ICAO recommendations, identifies three phases for the integration,
from which SESAR derives the four U-space service blocks presented in the U-space blueprint
[UspaceBlueprint],
has been, and is being, validated throughout Europe via several Very Large Demonstrator (VLD)
projects such as the GOF USPACE project.
U2 blocks are anticipated to provide tracking capabilities and services.
1.4.7 Efficient, Safe and Sustainable Traffic at Sea (EfficienSea2)
The design method and terminology builds on experience from the EfficienSea2 project [EfficienSea2],
[IALA-ENAV].
1.5 Glossary of Terms

Term Definition
AIR-REPORT Report from an aircraft in flight prepared in conformity with requirements for
position, and operational and/or meteorological reporting
10
SPECIFICATION
External Data Describes the semantics of the domain (or a significant part thereof) by
Model defining data structures and their relations. This could be at logical level (e.g.,
in UML) or at physical level (e.g., in XSD schema definitions), as for example
Message Exchange Describes the principles how two different parts of a message passing system
Pattern (in our case: the service provider and the service consumer) interact and

service provider in order to obtain certain information; the service provider
provides the requested information in a dedicated response.

Operational Activity performed by an operational node. Examples of operational activities

Activity are: Route Planning, Route Optimization, Logistics, Safety, Weather Forecast
Provision, …
Operational Structure of operational nodes and associated operational activities and their
Operational Node Logical entity that performs activities. Note: nodes are specified

Service Provision of something (a non-physical object), by one, for the use of one or
more others, regulated by formal definitions and mutual agreements. Services
involve interactions between providers and consumers, which may be
Service Consumer Service consumer uses service instances provided by service providers.
Service Data Formal description of one dedicated service at logical level. The service data
Model model is part of the service specification. Is typically defined in UML and/or
XSD.
If an external data model exists (e.g., a standard data model), then the service
data model shall refer to it: each data item of the service data model shall be
mapped to a data item defined in the external data model.
Service Design Specifies the details of a service technical design (most likely documented by
Description the service implementer). The service design description includes (but is not
limited to) a service physical data model and describes the used technology,
11
SPECIFICATION
Service Provider-side implementation of a dedicated service technical design, i.e.

Implementation implementation of a dedicated service in a dedicated technology
Implementer consumer side
Service Instance One service implementation can be deployed at several places by same or
different service providers; each such deployment represents a different
Service Instance Documents the details of a service implementation (most likely documented
Description by the service implementer) and deployment (most likely documented by the
Service Interface Communication mechanism of the service, i.e. interaction mechanism

characterised by a message exchange pattern and consists of service
service.
Service Operation Functions or procedure which enables programmatic communication with a

Data Model technology. This includes a detailed description of the data payload to be

Service Provider A service provider gives instances of services according to a service

Service Describes one specific service at logical level. The Service Specification is
Specification technology-agnostic. The Service Specification includes (but is not limited to)
a description of the Service Interfaces and Service Operations with their data
12
SPECIFICATION

Data Model.
Service Producers of service specifications in accordance with the service

Specification documentation guidelines.
Producer
Service Technical Technical design of a dedicated service in a dedicated technology. One service
Design specification may result in several technical service designs, realising the

Technology Currently, SOAP and REST are envisaged to be allowed service technologies.
Catalogue The service technology catalogue shall describe in detail the allowed service
profiles, e.g., by listing communication standards, security standards, stacks,
bindings, etc.
Spatial A service specification is characterised as “spatially exclusive”, if in any

Exclusiveness geographical region only one service instance of that specification is allowed
to be registered per technology.

governance issue.
Table 1: Glossary of Terms

Acronym Definition
CIS Common Information Services
13
SPECIFICATION
Table 2: List of Acronyms
14
SPECIFICATION
This chapter gives a unique identification of the service and describes where the service is in terms of
the engineering lifecycle.
Name TrafficConformanceMonitoring Exchange Service
ID urn:frequentis:services:TrafficConformanceMonitoringExchangeService
Version 1.0
Description A service which exchanges Traffic Conformance Monitoring warnings about tracks of
objects such as aircraft (manned and unmanned)
Keywords TrafficConformanceMonitoring Service, U-space Tracking, Warning, Alert
Architect(s) 2021-today The Frequentis Group
2021-2022 The GOF2 U-Space Project Consortium
Status Provisional
15
SPECIFICATION

The table below lists applicable existing requirements for the TrafficConformanceMonitoring
Exchange service.

Id Name
[R-1] Common At all times, all U-space CORUS [CORUS], 3.1.1.2 Z

Situational participants shall operate on the Volumes; B1-RPAS [ICAO-
Awareness same common set of data, during GANP];CEF-SESAR-2018-1
pre-flight planning stages as well [GOF1-I-CFP], Objective O5
as during all stages of flight
operations.
[R-2] Basis for Open The U-space concept shall be SESAR Drone Roadmap
Market designed such as to ensure a [EATMP-Drone], Foreword,
well-established line of authority 4.1 and 4.2;U-space
while at the same time ensuring Blueprint [UspaceBlueprint],
that an open market for VLL Benefits to European society
services may develop and economy; CEF-SESAR-
2018-1 [GOF1-I-CFP], Table 8
– Key Challenges
[R-3] Interoperability There shall be an ICAO Doc 10039 [ICAO-

implementation of a Flight SWIM];[R-2];CEF-SESAR-
Information Management 2018-1 [GOF1-I-CFP],
System (FIMS) which ensures Objective O6; CEF-SESAR-
that, at all times, emerging 2018-1 [GOF1-I-CFP], Table 8
unmanned traffic management – Key Challenges
systems and existing
technologies from manned Note: The term 'Flight
operations can exchange any Information Management
data required to support such System (FIMS)' in some of
common situational awareness, these references has been
be it for drone operations in since replaced by 'Common
areas where established ATC Information Services (CIS)'.
procedures apply, or in zones This text hence elsewhere
outside established ATC. refers to CIS, rather than
FIMS.
[R-4] Standard Standard communication [R-2];SESAR Drone Roadmap

Protocols protocols shall hence be used [EATMP-Drone], 3.5, section
where available, and such ‘Standards’; CEF-SESAR-
standard protocols be developed
16
SPECIFICATION
otherwise, in order to ensure the 2018-1 [GOF1-I-CFP], Table 8

lowest level of obstruction for an – Key Challenges
open VLL airspace use market to
develop.
[R-5] Open Interfaces Any interface and protocol hence [R-2];CEF-SESAR-2018-1

must be openly defined and its [GOF1-I-CFP], Table 8 – Key
definition be freely accessible in Challenges
order to ensure the lowest level
of obstruction for an open VLL
[R-6] SWIM The implementation of a Flight [R-3];CEF-SESAR-2018-1

Information Management [GOF1-I-CFP], 5.3.4 Overall
System (FIMS) shall be based on approach and methodology
architecture. Note: The term 'Flight
System (FIMS)' used therein
has been since replaced by
'Common Information
hence elsewhere refers to
CIS, rather than FIMS.
[R-7] Latency Under no operational [FAA-SUR-PERF], tables in

circumstance, the processing of the Executive Summary, [EC-
position data may add significant ATM-PERF], 3N_C-R8 and
latency to the overall detection- 5N_C-R8
to-display latency of position
data. In particular,
The processing latency added by

the processing of positional data
shall never exceed 10 per cent of
the maximum value of the
system.
The processing latency and delay

added by the processing of
positional data should not
system.

17
SPECIFICATION
values defined by the ATM

system performance
requirements by EUROCONTOL
and the FAA; for a 3 NM minimal
separation, this is 2.2 s, for a 5
Table 4: Requirements for the TrafficConformanceMonitoring Service

3.2.1.1 ICAO SWIM

The System Wide Information Management (SWIM, [ICAO-SWIM]) complements human-to-human
with machine-to-machine communication, and improves data distribution and accessibility in terms of
3.2.1.2 EUROCONTROL ASTERIX

The All-purpose structured EUROCONTROL surveillance information exchange (ASTERIX) [EC-ASTERIX]
is a set of documents defining the low level (“down to the bit”) implementation of a data format used
for exchanging surveillance-related information and other ATM applications.

Part 9 Category 062 SDPS Track Messages

Part 12 Category 21 ADS-B Target Reports

Part 14 Category 20 Multilateration Target Reports

Part 17 Category 004 Safety Net Messages

ASTERIX Part 28 - Category 015: INCS System Target Reports
EUROCONTROL-SPEC-0149-29 - EUROCONTROL Specification for Surveillance Data Exchange – ASTERIX

Part 29 - Category 129: UAS Identification Reports

Part 30 - Category 016: Independent Non-Cooperative Surveillance System Configuration Reports

Part 31 - Category 205: Radio Direction Finder Reports
18
SPECIFICATION
3.2.1.3 EUROCONTROL ATM Automation System Environment Performance

Requirements
EUROCONTROL defines clear operational requirements and an elaborated assessment methodology
for European surveillance in its Specification for ATM Surveillance System Performance [EC-ATM-
PERF]. For instance, for a separation of 3 nautical miles:
Req. # Quality of Service Mandatory Performance
3N_C- Forwarded pressure altitude average data age (see Note Less than or equal to 2.5
R8 7 in § 3.4.5) seconds
Table 5: Excerpt from EUROCONTROL Specification for ATM Surveillance System Performance [EC-
ATM-PERF]
INFO More requirements for update rates and error margins apply.
3.2.1.4 FAA ATM Automation System Environment Performance Requirements

In a similar fashion, the Federal Aviation Administration concludes that the time from the
determination of a position (measurement) to display (latency of the ATM system) shall not exceed
similar values [FAA-SUR-PERF]:
Latency 2.2 seconds to display maximum
The FAA also applies further requirements for update rates and error margins.
3.2.1.5 EUROCONTROL Safety Nets, A Guide for Ensuring Effectiveness

TrafficConformanceMonitoring with safety nets constitutes the ultimate safety layer with very short
timescales remaining to prevent the occurrence of a serious situation [EC-SN-Guide]:
"Safety nets are either ground-based or airborne:
Ground-based safety nets are an integral part of the ATM system. Primarily
using ATS surveillance data, they provide warning times of up to two minutes.
Upon receiving an alert, air traffic controllers are expected to immediately
assess the situation and take appropriate action.
Airborne safety nets provide alerts and resolution advisories directly to the
pilots. Warning times are generally shorter, up to about 40 seconds. Pilots are
expected to immediately take appropriate avoiding action. ..."
The TrafficConformanceMonitoring service primarily is relevant during the actual operational in-flight
stages of a U-space flight during which the flying device and/or the corresponding ground stations
produce the position data which we convey via the Traffic/Telemetry exchange service.
19
SPECIFICATION
The operational TrafficConformanceMonitoring service consumes position information provided by

the authoritative Tracking service of the area of its responsibility.
Figure 2: U-space Nodes Related to the TrafficConformanceMonitoring Service
Typically, consuming services and applications will utilize the service together with other services like:
 Tracking Services - for reliable, timely traffic information in the area of interest for a reliable
situational awareness
 Registration Services - for background on e.g. operator, pilot and flown device
 Geofencing Services – to draw a user’s attention to a potential area conflict and to act
accordingly, possibly even automatically
Consuming services and applications include the following services and applications:
 Tactical Deconfliction Service

 Traffic Alerting Service, including
o at an operator's U-space client U-space display for operator alerting, or
o at an operators ground station, triggering tactical collision avoidance
 Displays for Situational Overview
 Accident and Incident Reporting Services
 Legal Recording Service
Operational nodes which can provide data for the Traffic Conformance Monitoring service include the
following ones:
Operational Remarks
Node
Tracking Server Single Source of Truth for the area of responsibility of the Tracking and the
TrafficConformanceMonitoring services
Table 6: Operational Nodes Providing to the TrafficConformanceMonitoring Service
Operational nodes which may consume the Traffic Conformance Monitoring service include the
following ones.
20
SPECIFICATION
Information Display
Telemetry Converter
Legal Recorder
Table 7: Operational Nodes Consuming the TrafficConformanceMonitoring Service
Operational activities supported by the Traffic Conformance Monitoring service include the following
ones.
Phase Operational Remarks

Activity
Pre- Set-up (Telemetry input likely not operational yet at this stage)
flight
Plan (Telemetry input likely not operational yet at this stage)
Arm (Traffic/telemetry input should start to run here)
In-Flight Depart With the availability of Tracking information of the flight, Traffic
Conformance Monitoring starts now
Cruise Traffic Conformance Monitoring operational for the flight
Arrive Traffic Conformance Monitoring operational for the flight
Post- Disarm (Traffic/telemetry likely stops here, so the Traffic Conformance

Flight Monitoring for the flight ceases now)
Table 8: Operational Activities Supported by the TrafficConformanceMonitoring Service
21
SPECIFICATION
Figure 3: TrafficConformanceMonitoring Exchange Interface Definition Diagram
Service Interface Role Service Operation

(from
servic
e
provid
er
point
of
view)
TrafficConformanceMonitoringSubscriptionI Provid subscribeToTrafficConformanceMonitori

nterface ed ng
unSubscribeFromTrafficConformanceMo
nitoring
TrafficConformanceMonitoringNotificationI Requir notifyTrafficConformanceMonitoringRep

nterface ed ort
22
SPECIFICATION

This section describes the information model, i.e., the logical data structures that are exchanged
4.1 Overview
The Traffic Conformance Monitoring exchange service provides its consumers with
TrafficConformanceMonitoringReports. A TrafficConformanceMonitoringReport is one of
 TrafficNonConformanceMonitoringReport, or
 TrafficConformanceMonitoringStatusReport.
A TrafficNonConformanceMonitoringReport informs about a conflict situation reports of conflict

situations of one or more TrafficConformanceMonitoringObjects. It gives information about the
involved objects, characteristics of the conflict, and time and spatial separation.
It is mandatory to provide at least one TrafficConformanceMonitoringObject as the originatingObject

data item in each TrafficNonConformanceMonitoringReport.Additional
TrafficConformanceMonitoringObjects may be added as relatedObjects, if available.
Each TrafficConformanceMonitoringObject must include at least one ObjectIdentifiation data item

which refers to a TRACK. Data sources should report all further ObjectIdentification data items they
have information about. In fact, this specification relies on it as means to convey essential information.
23
SPECIFICATION
Figure 4: TrafficConformanceMonitoringReport Data Model Diagram of the Traffic

Conformance Monitoring Exchange Service
4.1 TrafficConformanceMonitoringReport Data Structure

The TrafficConformanceMonitoringReport data structure is the base report structure being
distributed to subscribed service consumers.
Its properties are inherited by both specific report structures TrafficNonConformanceReport and
TrafficConformanceMonitoringStatusReport.
reportId UUID 1 Globally unique identifier of the report.
timestamp DateTime 1 Timestamp of when the report was sent.
Tab.: TrafficConformanceMonitoringReport Data Structure
4.2 TrafficNonConformanceReport Data Structure

The TrafficNonConformanceReport data structure carries the data describing a traffic non-
conformance situation.
24
SPECIFICATION
Property Type Multipl Description Note

icity
originatingObject TrafficConformanceMonit 1 The

oringObject TrafficConformanceMonitor
ingObject structure holds
the object originating the
Traffic Conformance
Monitoring report.
relatedObject TrafficConformanceMonit 0..* The TrafficConformanceMo This

oringObject nitoringObject structure can
holds an object involved in be
the Traffic Conformance anot
Monitoring report. her
aircr
aft
but
also
an
area,
or
othe
r.
reportPosition Position 1 The Position structure holds

the anticipated or actual
position of the issue
conveyed with this Traffic
Conformance Monitoring
report.
reportAltitude Altitude 1 The corresponding Altitude

structure holds the altitude
of the issue conveyed with
this Traffic Conformance
Monitoring report.
currentSeparation Separation 1 The Separation structure

holds the current separation
from the conflict, plus the
estimated time left until the
conflict.
estimatedMinimum Separation 1 The Separation structure

Separation holds the estimated
minimum separation, plus
the estimated time left until
the minimum separation
occurs.
25
SPECIFICATION
deviation Separation 1 The Separation structure

holds the current deviation
from the agreed operation
plan.
reportType EnumConformanceMonit 1 The type of non-

oringFunction conformance carried inthe
report.
reportSubType String 0..1 If required, the subtype of

the report may be set as
follows.
For reportType = RIMCAS

alerts, one of:
RRC Runway/Run
way crossing
RTC Runway/Tax
iway crossing
RAS1 Alert stage
one
RAS2 Alert stage
two
For reportType = UTMM,

one of:
WrongDirection Object
travelling in direction it is
not cleared to travel
WrongTaxiway Object on
wrong taxiway
Speeding Object
travelling faster than
permitted
For reportType = MSAW:

MRVA Minimum radar
vector altitude alert
For reportType = VRAM, one

of:
CRM Cleared rate
monitor alert
VRM Vertical rate
monitor alert
VTM Vertical tracker
monitor alert
FastClimb Object
climbing fast
SlowClimb Object
climbing slowly
26
SPECIFICATION
FastDescent Object
descending fast
SlowDescent Object
descending slowly
For reportType = HAM, one

of:
HD Heading
deviation alert
RD Rate deviation
alert
VD Vertical
deviation alert
FastClimb Object
climbing fast
SlowClimb Object
climbing slowly
FastDescent Object
descending fast
SlowDescent Object
descending slowly
Above Object above
cleared level
Below Object below
cleared level
For reportType = DBPSM,

one of:
ARR Alert upon arrival
DEP Alert upon departure
TL Alert above transition
level
For reportType = AIW:

pAIW AIW relies on primary
surveillance only
For reportType = STCA, one

of:
LPF Linear Prediction Filter
set
CPF Current Proximity
Filter set
MHF Maneouvere Hazard
Filter set
For reportType = DSAM, one

of:
EarlyVManeouvre Verti
cal maneouvre of object
27
SPECIFICATION
comes early
LateVManeouvre Verti
cal maneouvre of object
comes late
For reportType = FTD, ITD

and IIA, one of:
(Real number) Separation
value in m
MRS1 Minimum
radar separation on arrival
(single RWY)
ROT1 Separation
based on runway separation
occupancy time (single
RWY)
GAP1 Separation
based on manually entered
ATCO gap (single RWY)
MRS2 Minimum
radar separation on arrival
(parallel RWY)
ROT2 Separation
based on runway separation
occupancy time (parallel
RWY)
GAP2 Separation
based on manually entered
ATCO gap (parallel RWY)
For reportType = CATC, one

of:
LineUpVsLineUp Lin
e-Up vs. Line-Up
LineUpVsCrossEnter Li
ne-Up vs. Cross or Enter
LineUpVsTakeoff Li
ne-Up vs. Takeoff
LineUpVsLanding Lin
e-Up vs. Landing
CrossEnterVsLineUp Cr
oss or Enter vs. Line-Up
CrossEnterVsCrossEnter Cr
oss or Enter vs. Cross or
Enter
CrossEnterVsTakeoff C
ross or Enter vs. Takeoff
CrossEnterVsLanding Cr
oss or Enter vs. Landing
TakeoffVsLineUp Ta
28
SPECIFICATION
ke-Off vs. Line-Up

TakeoffVsCrossEnter Ta
ke-Off vs. Cross or Enter
TakeoffVsTakeoff Ta
ke-Off vs. Takeoff
TakeoffVsLanding Ta
ke-Off vs. Landing
LandingVsLineUp Lan
ding vs. Line-Up
LandingVsCrossEnter La
nding vs. Cross or Enter
LandingVsTakeoff La
nding vs. Takeoff
LandingVsLanding Lan
ding vs. Landing
PushBackVsPushBack Pu
sh-back vs. Push-back
PushBackVsTaxi Pus
h-back vs. Taxi
TaxiVsPushBack Tax
i vs. Push-back
TaxiVsTaxi Taxi
vs. Taxi
For reportType = NOCLR,

one of:
NoPushBackClearance Obj
ect moving without
clearance to push back
NoTaxiClearance Obj
ect on taxiway without
clearance
NoLineUpClearance Obj
ect lining up without
clearance
NoCrossingClearance Obj
ect crossing runway without
clearance
NoEnterClearance Obj
ect entering runway without
clearance
NoTakeoffClearance Obj
ect taking off without
clearance
NoLandingClearance Obj
ect Landing without
clearance
For reportType = NOMOV,

one of:
29
SPECIFICATION
AfterPushBackClearance O
bject stationary despite
push-back clearance
AfterTaxiClearance O
bject stationary despite taxi
clearance
AfterLineUpClearance O
bject lining up too late
AfterCrossingClearance O
bject crossing runway too
clearance
AfterEnterClearance O
bject entering runway too
late
AfterTakeoffClearance O
bject too late for take-off
StationaryOnRWY Obj
ect stationary on runway
StationaryOnTWY Obj
ect stationary on taxiway
For reportType = NOH, one

of:
NoContact No contact
made, as seen from the
receiving ATSU side
NoTransfer No transfer
made, as seen from the
leaving ATSU side
flavour String 1..* The flavour of the report,

one or more of:
Military Confli
ct location in military
airspace
Civil Conflic
t location in civil airspace
StateReserved Conf
lict location in reserved
airspace
FastLateralDivergence Obj
ects are fast diverging
laterally at current time
FastVerticalDivergence Obj
ects are fast diverging
vertically at current time
Crossed Objec
ts have crossed at starting
time of conflict
30
SPECIFICATION
Diverging Object
s diverging at starting time
of conflict
Opposing Object
s in opposing direction
severity EnumConflictSeverity 0..1 The severity assigned to the

reported conflict.
probability Percentage 1 The probability of the

reported situation to occur.
Range: 0...100
duration TimeDuration 1 The duration, in seconds,

since the report is being
raised.
timeOfApplicability DateTime 1 The time of applicability of

this report
… All properties inherited from

TrafficConformanceMonitor
ingReport.
Table 10: TrafficNonConformanceReport Data Structure
4.3 TrafficConformanceMonitoringStatus Data Structure

The TrafficConformanceMonitoringStatusReport data structure carries the data describing the current
status of the TrafficConformanceMonitoring service provider.
It is expected that such TrafficConformanceMonitoringStatusReports are published periodically over

the same channel as non-conformance reports are published, so subscribed consumers get informed
about active service provision.
Property Type Multiplic Description Not

ity e
aliveFuncti EnumConformanceMonitoringF 0..1 The list of currently provided

ons unction monitoring functions.
... All properties inherited from

TrafficConformanceMonitoring
Report.
Tab.: TrafficConformanceMonitoringStatusReport Data Structure
4.4 EnumConformanceMonitoringFunction Enumeration

The EnumConformanceMonitoringFunction enumeration type specifies the available monitoring
functions .
31
SPECIFICATION
ACASRA ACAS Resolution Advisory
AIW Airspace Infringement Warning
ALM RIMCAS – Arrival / Landing Monitor
APM Approach Path Monitor
APW Area Proximity Warning
ASM RIMCAS – Arrival/Departure Aircraft Separation Monitor
CATC Conflicting ATC Clearances
CHAM Cleared Heading Adherence Monitor
CLAM Clearance Level Adherence Monitor
CRA RIMCAS – Arrival/Departure Close Runway Alert
CUW Catch-Up Warning
DBPSM Downlinked Barometric Pressure Setting Monitor
DSAM Downlinked Selected Altitude Monitor
FTD Final Target Distance Indicator
HAM Holding Adherence Monitor
HVI Holding Volume Infringement
IAVM RIMCAS – ILS Area Violation Monitor
IIA Wake Vortex Indicator Infringement Alert
ITD Initial Target Distance Indicator
LTW Lost Track Warning
LOCON Loss of Control warning
MSAW Minimum Safe Altitude Warning
NOCLR No ATC Clearance
NOH Aircraft Leaving/Entering Aerodrome Area without Handover
NOMOV Aircraft not moving despite ATC Clearance
NTCA Near Term Conflict Alert
32
SPECIFICATION
OCAT Outside Controlled Airspace Tool
ONGOING Ongoing Alert
OTA RIMCAS – Arrival / Departure Opposite Traffic Alert
RAMHD Route Adherence Monitor Heading Deviation
RAMLD Route Adherence Monitor Longitudinal Deviation
RCM RIMCAS – Runway / Taxiway Crossing Monitor
RDM RIMCAS – Departure Monitor
SAM Speed Adherence Monitor
SBOA RIMCAS – Stop Bar Overrun Alert
SQW Sequence Warning on Final Approach
STCA Short Term Conflict Alert
STOCC Stand Occupied
TSM RIMCAS – Taxiway Separation Monitor
TTA RIMCAS – Taxiway Traffic Alert
UTMM RIMCAS – Unauthorized Taxiway Movement Monitor
VCD Vertical Conflict Detection
VPM Vertical Path Monitor
VRAM Vertical Rate Adherence Monitor
WRA RIMCAS – Arrival / Departure Wrong Runway Alert
WRTY Wrong Runway or Taxiway Type
Tab.: EnumConformanceMonitoringFunction Enumeration
4.5 EnumConflictSeverity Enumeration

The EnumConflictSeverity enumeration type specifies levels of severity of a non-conformance.
MINOR minor severity
MEDIUM medium severity
MAJOR major severity
33
SPECIFICATION
Tab.: EnumConflictSeverity Enumeration
4.6 TrafficConformanceMonitoringObject Data Structure

The TrafficConformanceMonitoringObject data structure defines the structure which may carry the
required information about an object involved with this Traffic Conformance Monitoring report.
Property Type Multiplici Description Note

ty
objectCharacterist Strin 0..* Additional classification flags The

ics g regarding this objectCharacterist
Arra TrafficConformanceMonitoringOb ics can be empty
y ject, one or more of: under some
circumstances, or
GAT Indicates General Air hold multiple
Traffic entries.
OAT Indicates
Operational Air Traffic This item is there
IFR Indicates primarily to ensure
Instrumental Flight Rules immediate
VFR Indicates Visual forwarding of
Flight Rules resolution
CVFR Indicates Controlled advisories without
Visual Flight Rules delay of at least a
RVSM-OK Indicates approved minimum of
RVSM operation information
RVSM-NO Indicates without delay.
exemption from RVSM
RVSM-EX Indicates NOT Data originators
approved RVSM shall make use of
HPR Indicates High the
Priority operation ObjectIdentificati
CDM-UP Indicates climbing on structure to the
operation most complete
CDM-DOWN Indicates extent as possible
descending operation but also should fill
CDM-LEVEL Indicates operation this item as
maintaining flight level appropriate.
GV Indicates a ground
vehicle
cfl Real 0..1 Cleared flight level
Table 11: TrafficConformanceMonitoringObject Data Structure
There shall be at least one TrafficConformanceMonitoringObject type originatingObject data

structure provided for every TrafficNonConformanceReport which holds the information of the object
originating the Traffic Conformance Monitoring report. The Position shall be set to the position of the
34
SPECIFICATION
expected report situation. In most cases, there will be a TrafficConformanceMonitoringObject type

relatedObject data structure containing the corresponding information of the related object which
may be, for instance, another aircraft, a restricted area, or a gate.
4.7 ObjectIdentification Data Structure

The ObjectIdentification data structure can carry data to assist in identifying the object we report
about in this report. It can be a vehicle registration identifier, or any other identifier as listed in the
IdentificationType property.
Property Type Multiplicit Description Not

y e
object_identification_value String 1 The actual value of the

identification of the
object this report applies
to, of type
object_identification_typ
e.
object_identification_type IdentificationTy 1 Type of identification

pe conveyed by this
ObjectIdentification item,
one of:
ICAO indicating an
ICAO 24 bit address
CALLSIGN indicating an
(ITU) call sign as
designated by the country
of registration
ETHER indicating an
Ethernet address
Primary (primary
surveillance)
Mode3A (secondary
surveillance, 2D only,
squawk)
Mode3AC (secondary
surveillance, 3D, squawk)
ModeS (secondary
surveillance, ICAO 24 bit
address)
35
SPECIFICATION
Combined (combined
primary/secondary
surveillance)
ModeSES (dependent
address)
VDL (dependent
address)
UAT (dependent
address)
MLAT (secondary
address)
TRACK (combined
surveillance, numeric
track id)
TRACKID (combined
surveillance, track uuid)
ALERT (surveillance
, numeric alert id)
ALERTID (surveillanc
e, alert uuid)
ADSC (dependent
address)
FPL (dependent
surveillance, squawk or no
id)
GUFI (operation-
id, i. e. the uuid of the
operation)
FLARM (dependent
surveillance, FLARM-ID)
IMEI (dependent
surveillance, IMEI
number)
36
SPECIFICATION
IMSI (dependent
surveillance, IMSI
number)
MMSI (dependent
surveillance, MMSI
number)
SERIAL (dependent
surveillance, serial
number of the vehicle as
assigned by its
manufacturer)
MAKER (dependent
surveillance, three letters
identifying the
manufacturer of the
vehicle)
MODEL (dependent
surveillance, three letters
identifying the model of
the manufacturer of the
vehicle)
COUNTRY (dependent
surveillance, ISO 3166-1
Alpha 2 code of the
country of registration of
the vehicle)
AREA (name of an
area)
AREAID (uuid of an
area)
CROSS_AREA (name of a
crossing area)
CROSS_AREAID (uuid of a
crossing area)
GATE (designator
of a gate)
GATEID (uuid of a
gate)
37
SPECIFICATION
RWY (designator
of a runway)
RWYID (uuid of a
runway)
TWY (designator
of a taxiway)
TWYID (uuid of a
taxiway)
SECTOR (designator
of a control sector)
SECTORID (uuid of a
control sector)
STBAR (designator
of a stop bar)
STBARID (uuid of a
stop bar)
OTHER discouraged,
referring to
object_identification_oth
er below
object_identification_other String 0..1 Optional empty item for

temporary use until
standardization is in
place: Unless
e is set to “OTHER”, do not
set this field at all;
however, if
e is set to “OTHER”, set
this field to a descriptive
string for the type and set
object_identification_val
ue to the corresponding
value.
INFO Use of this field is

discouraged at any time
and permitted for local
bilateral temporary
deviation of standard only
38
SPECIFICATION
until updated
standardization is in place.
object_identification_confide Integer 0..1 Optional item with a

nce range from 0 to 100
representing the degree
of confidence the emitter
of this information has
that the object we report
about in this report
actually can be identified
by this particular
object_identification_val
ue.
Table 12: ObjectIdentification Data Structure
Data sources should report all ObjectIdentification data items they have data about.
There shall be at least one ObjectIdentification data structure present, carrying a data item of
object_identification_type=TRACK. Data sources should provide as many ObjectIdentification data
structures as they have data available for a given TrafficConformanceMonitoringObject.
4.8 The Position Data Structure

The Position data structure carries the position data of the object being reported about.
latitude Real 1 Latitude of position

record in unit of
measurement as
defined by
positionCrs
longitude Real 1 Longitude of

position record in
unit of
measurement as
defined by
positionCrs
positionAccuracy Real 1 Accuracy of latitude

and longitude in
unit of
measurement as
defined by
positionCrs
positionCrs Reference 1 Coordinate

reference system
39
SPECIFICATION
used (e. g., for

WGS-84,
EPSG:4979)
positionDataAge Real 0..1 Elapsed time in s This attribute shall be

since last position provided, if the Position is
data received by used in a reporting service
the reporter of this (e.g., in a PositionReport); in
Position other cases this attribute may
be omitted (e.g., in
conversion operations).
Table 13: The Position data structure
There shall be exactly one reportPosition for each TrafficNonConformanceReport.
4.9 The Altitude Data Structure

The Altitude data structure carries the altitude data of the object being reported about.
Property Type Multiplicit Description Note

y
altitude Real 1 Altitude of

position
record in m
unit of
measuremen
t as defined
by
altitudeCrs.
altitudeAccuracy Real 1 Accuracy of

altitude in in
unit of
measuremen
t as defined
by
altitudeCrs
altitudeType EnumAltitudeType 1 indicates the

reference
point for
altitude
measuremen
t, e. g.:
altitude
above mean-
40
SPECIFICATION
sea-level
(MSL)
altitude
above take-
off location
(ATO)
altitude
above
ground
(AGL/SFC)
determinationMeth AltitudeDeterminationMeth 1 Method of

od od determinatio
n of altitude,
e. g.:
radio-
altimeter
barometric
GNSS-based
calculated
against
reference
point and
mean-sea-
level
altitudeCrs EnumCRSType 1 Coordinate

reference
system used
(e. g., for
WGS-84,
EPSG:4979)
altitudeDataAge Real 0..1 Elapsed time This attribute

in s since last shall be
position data provided, if the
received by Altitude is used
the reporter in a reporting
of this service (e.g., in
Altitude a
PositionReport
); in other
cases this
attribute may
be omitted
41
SPECIFICATION
(e.g., in
conversion
operations).
Table 14: The Altitude data structure
4.10 The EnumAltitudeType Enumeration

4.11 The EnumCRSType Enumeration

system.
4.12 The AltitudeDeterminationMethod Enumeration

The AltitudeDeterminationMethod enumeration type specifies the possible ways to determine an
altitude.
RADIO_ALTIMETER Altitude measured via radio altimeter.
BAROMETRIC Altitude measured via air pressure.
GNSS_BASED Altitude obtained by satellite navigation system.
CALCULATED Altitude calculated against reference point.
Table 15: The AltitudeDeterminationMethod enumeration
There shall be exactly one reportAltitude for each TrafficNonConformanceReport.
4.13 Separation Data Structure

The Separation data structure provides a means to carry spatial separation information of the objects
considered.
longitudinal Real 1 The separation, in A deviation 'ahead' of the

metres, in the planned position should be
direction of annotated as a positive
movement, of this figure, or as a negative
object to the other figure if 'behind' the
object involved. planned position.
42
SPECIFICATION
transversal Real 1 The separation, in A deviation 'to the right' (in

metres, transversal to the sense of movement) of
the direction of the planned position should
movement, of this be annotated as a positive
object to the other figure, or as a negative
object involved. figure if 'to the left'.
vertical Real 1 The vertical A deviation 'above' of the

separation, in metres, planned position should be
in the direction of annotated as a positive
movement, of this figure, or as a negative
object to the other figure if 'below'.
object involved
timeLeft TimeDuration 0..1 The time left, in s, until A deviation has no

the reported conflict timeLeft.
occurs, or is expected
to occur.
Table 16: Separation Data Structure
4.14 Common Data Structures Used in UTM Service

Specifications
4.14.1 NotificationEndpoint Data Structure

4.14.2 ServiceResponse Data Structure

43
SPECIFICATION
result OperationResult 1 Indicates the result of the request to the

service
rejectReason String 0..1 Optional additional information to be

provided in case of negative result
4.15 Common Geometry Data Structures Used in UTM Service

Specifications
4.15.1 AreaOfInterest Data Structure
area Geometry 1 A geometric description of a Should be a 2-

geographic area. dimensional geometry in
this case.
areaCRS EnumCRSType 1 Coordinate reference

system used (WGS-84,
EPSG:4979)
44
SPECIFICATION
4.15.2 Geometry Data Structure
coordinates Double 2..* Collection of the

coordinates, describing
the geometry.
geometryType GeometryType 1 Type of geometry being Examples: Point,

described by the Polygon, Polyhedron,
coordinates. etc.
4.15.3 EnumAltitudeType Enumeration
ABOVE_MSL Altitude above mean-sea-level.
4.15.4 EnumCRSType Enumeration
system.
WGS84
EPSG4979
... to be continued ...
4.15.5 EnumGeometryType Enumeration
45
SPECIFICATION
POINT Single point.
POLYGON Polygon.
...
46
SPECIFICATION

This chapter describes the details of each service interface. Each Service Interface has its own sub-
chapter.

TrafficConformanceMonitoringSubscriptionInterface
5.1.1 Operation subscribeForTrafficConformanceMonitoring

A consumer calls this operation to subscribe to Traffic Conformance Monitoring report data.

Name

new ConformanceReports
Table 24: Payload Description of subscribeForTrafficConformanceMonitoring Operation
5.1.2 Operation unSubscribeForTrafficConformanceMonitoring

A consumer calls this operation at the provider to unsubscribe from Traffic Conformance Monitoring
report data.

Name
consumer Input NotificationEndpoint Which endpoint shall be not be notified

(anymore) in case of new
TrafficConformanceMonitoringReports
Table 25: Payload Description of unSubscribeForTrafficConformanceMonitoring Operation
47
SPECIFICATION

TrafficConformanceMonitoringNotificationInterface
Consumer provides this interface, allowing the service provider to submit to the consumer Traffic
Conformance Monitoring report data.
5.2.1 Operation notifyTrafficConformanceMonitoringReport

Once and while subscribed, consumer receives Traffic Conformance Monitoring report data via this
operation.

Parameter Name Directio Data Type Description
n
TrafficConformanceMonitoringRe Input TrafficConformanceMonitoringRe A Traffic

port port Conformanc
e
Monitoring
report that
matches the
area
criterium
provided
with
subscription
Table 26: Payload Description of notifyTrafficConformanceMonitoringReport Operation
48
SPECIFICATION

TrafficConformanceMonitoringSubscriptionInterface and
TrafficConformanceMonitoringNotificationInterface
Figure 7: Traffic Conformance Monitoring Exchange Service Interface

Operation Sequence Diagram
49
SPECIFICATION
Not available, left empty.
50
SPECIFICATION
8 References
Nr. Versio Reference
n
[CORUS] Ed. CORUS Vol. 1, Enhanced Overview

01.01. https://www.sesarju.eu/sites/default/files/documents/u-
03 space/CORUS%20ConOps%20vol1.pdf
CORUS Vol. 2, U-space Concept of Operations
Ed. https://www.sesarju.eu/sites/default/files/documents/u-
03.00. space/CORUS%20ConOps%20vol2.pdf
02
[EASA- n/a Annex to EASA Opinion No 01/2020; COMMISSION IMPLEMENTING

Commission- REGULATION (EU) .../...of XXXon a high-level regulatory framework for
Draft] the U-space
https://www.easa.europa.eu/sites/default/files/dfu/Draft%20COMMIS
SION%20IMPLEMENTING%20REGULATION%20on%20a%20high-
level%20regulatory%20fram....pdf
[EASA-Incident- 08.03. EASA Manual on Drone Incident Management at Aerodromes

Manual] 2021
PART 1: The challenge of unauthorised drones in the surroundings of
aerodromes
PART 2: Guidance and recommendations
PART 3: Resources and practical tools
https://www.easa.europa.eu/newsroom-and-events/press-
releases/easa-issues-guidelines-management-drone-incidents-airports
[EATMP] 2020 SESAR, eATM PORTAL, European ATM Master Plan,

[EATMP-Drone] n/a SESAR, European ATM Master Plan: Roadmap for the safe integration of
drones into all classes of airspace
[EC-ATM-PERF] Ed. EUROCONTROL Specification for ATM Surveillance System Performance

1.2 (ESASSP), EUROCONTROL-GUID-
0147, https://www.eurocontrol.int/publication/eurocontrol-
specification-atm-surveillance-system-performance-esassp
[EC-ASTERIX] n/a ASTERIX Library: ASTERIX, All-purpose structured EUROCONTROL

surveillance information exchange, Defining the low level
implementation of a data format used for exchanging surveillance-
related information in ATM applications. Available at
[EC-MONA] Ed. EUROCONTROL Specification for Monitoring Aids, EUROCONTROL-SPEC-

2.0, 0142,
51
SPECIFICATION
03/03 https://www.eurocontrol.int/sites/default/files/publication/files/EURO
/2017 CONTROL-SPEC-0142%20MONA%20Ed%202.0.pdf
[EC-SN-Guide] Augus Safety Nets, A guide for ensuring effectiveness,

t 2017 https://www.eurocontrol.int/sites/default/files/publication/files/safet
y-nets-guide-august-2017.pdf
[EfficienSea2] n/a Efficient, safe and sustainable traffic at sea (EfficienSea2), a Horizon
2020 Project, Grant Agreement No 636329
[FAA-SUR- 1 Massachusetts Institute of Technology Lincoln Laboratory for the

PERF] Nove Federal Aviation Administration, Project Report ATC-323, Required
mber Surveillance Performance Accuracy to Support 3-Mile and 5-Mile
2006 Separation in the National Airspace System,
https://www.ll.mit.edu/sites/default/files/publication/doc/2018-
[FAA-UAS- V1.0 Federal Aviation Administration NextGEN Concept of Operations,

CONOPS] Foundational Principles, Roles and Responsibilities, Use Cases and
Operational Threads, Unmanned Aircraft System (UAS), Traffic
Management (UTM)
[FALKE-ARCH] V1.0 FALKE System Architecture
[FALKE-GVB] 21.08. Gesamtvorhabensbeschreibung zum Verbundprojekt "Fähigkeit des

2019 Abfangens von in gesperrte Lufträume eindringenden Kleinfluggeräten
durch zivile Einsatzmittel" (FALKE), Az: DG20-837.4/4-1
[FOCA-USPACE- 1.0 Federal Office of Civil Aviation (FOCA), Swiss U-Space ConOps, U-Space
CONOPS] Program Management, 31.10.2018, FOCA muo / 042.2-
00002/00001/00005/00021/00003
[GOF1-Arch- 00.05. SESAR 2020 GOF USPACE FIMS Design and Architecture, Appendix A
AppA] 00 Service Description Templates, document SESAR 2020 GOF USPACE
Service Documentation Guidelines
[GOF1-I-CFP] n/a CFP Reference CEF-SESAR-2018-1, "Finnish-Estonian "Gulf of Finland"

Very Large U-Space Demonstration"
[GUTMA-FLP] n/a Global UTM Association (GUTMA) Flight Logging Protocol,

https://github.com/gutma-org/flight-logging-
[GUTMA-ATP] n/a Global UTM Association (GUTMA) Air Traffic

Protocol, https://github.com/hrishiballal/airtraffic-data-protocol-
development
52
SPECIFICATION
[IALA-ENAV] Ed. IALA specification for e-navigation technical services

1.1 https://www.iala-aism.org/product/g1128-specification-e-navigation-
technical-services
[IATA-SR2014] 51st E IATA Safety Report 2014 (Issued April 2015)

dition http://www.aviation-accidents.net/report-download.php?id=90003
[ICAO-GANP] 5th ICAO Doc. 9750-AN/963, Global Air Navigation Plan (GANP) 2016-2030
Ed. -
2016
[ICAO-SWIM] Advan ICAO Doc 10039, Manual on System Wide Information Management
ced (SWIM) Concept
Editio
n
(unedi
ted)
[IDD] V1.0 FALKE Interface Definition Document
[INTEL-ODID] 0.61.1 Intel Corporation, Open Drone ID Message Specification, Draft

Specification, November 13, 2018
[OASIS-SOA] 12 Reference Model for Service Oriented Architecture 1.0, OASIS Standard
Octob http://docs.oasis-open.org/soa-rm/v1.0
er 200
[OSED-CUAS] n/a EUROCAE ED-286 Operational Services and Environment Definition for
Counter-UAS in Controlled Airspace
[UspaceArchite Ed. Initial view on Principles for the U-space architecture

cturePrinciples] 01.04 https://www.sesarju.eu/sites/default/files/documents/u-
space/SESAR%20principles%20for%20U-space%20architecture.pdf
[UspaceBluepri 2017 SESAR-JU, U-space Blueprint,

nt] https://www.sesarju.eu/u-space-blueprint
53
D2.4 Appendix G Network

Coverage and Population
Density
Deliverable ID: D2.4-G
Grant: 101017689
Topic:
Air Mobility
Edition: 01.00.00
D2.4 APPENDIX G NETWORK COVERAGE AND POPULATION DENSITY


2


Document History
00.00.01 2021 Thomas Neubauer, ACJA ServiceCoverage
Definition participants.
Service Architects: Thomas Wana, Thomas Lutz,
Hubert Kuenig, Josef Jahn
00.00.03 30.04.2021 released WP2 Partners Release as D2.2
00.00.04 26.10.2022 Draft WP2 Partners Update to D2.4
01.00.00 04.11.2022 Released WP2 Partners Revise and submit
Copyright Statement
3
GOF2.0
Abstract
The Network Coverage service provides information about current and expected data connectivity
conditions along a flight route or in a geographical area of interest.
It provides information where connectivity conditions are or are not good enough for safe and reliable
data connectivity that adheres to a certain service level, provided by individual communication service
providers.
Provided connectivity conditions are provided in terms of quality and performance of network and C2
link data communication between drones and ground stations, as well as coverage information for
cellular networks. Targeted service consumers include aviation organisations, drone operators and end
users.
4
Table of Contents
Abstract ................................................................................................................................... 4
1 Introduction ............................................................................................................... 9
1.2 Scope ............................................................................................................................ 9
1.4 Background ................................................................................................................. 10
1.4.2 General principles and research basis ............................................................................................. 11
1.6 List of Acronyms .......................................................................................................... 13
3.1 Planning Phase ............................................................................................................ 16
3.2 Flight Phase ................................................................................................................. 16
3.3 Example Use Case ........................................................................................................ 16
3.5 Operational Nodes ...................................................................................................... 20
5.1 The ConnectivityProvider Data Structure ...................................................................... 23
5.2 The Cell4GConnectivityProvider Data Structure ............................................................ 24
5.3 The ContingencyPlan Data Structure ............................................................................ 24
5.4 The ContingencyPlanCoverageInformation Data Structure ............................................ 24
5.5 The CoverageData Data Structure ................................................................................ 25
5.6 The CoverageDataRef Data Structure ........................................................................... 26
5.7 The CoverageSummaryInfo Enumeration ..................................................................... 27
5.8 The GeometryCoverageInformation Data Structure ...................................................... 27
5.9 The OperationPlan Data Structure................................................................................ 27
5.10 The OperationPlanAnalyzeResult Data Structure .......................................................... 29
5.11 The PhysicalAntenna Data Structure ............................................................................ 30
5
5.12 The Polarization Enumeration ...................................................................................... 30

5.13 The RadioParameters Data Structure ........................................................................... 31
5.14 The ServiceLevel Enumeration ...................................................................................... 31
5.15 The Technology Enumeration ....................................................................................... 31
5.16 The TrajectoryCoverageInformation Data Structure...................................................... 32
5.17 The TrajectoryElement Data Structure .......................................................................... 32
5.18 The Volume Data Structure .......................................................................................... 32
6.1 Network Coverage Service Interface............................................................................. 33
6.1.1 Operation getVolumeCoverage....................................................................................................... 33
6.1.2 Operation downloadCoverageData................................................................................................. 34
6.1.3 Operation analyzeOperationPlan .................................................................................................... 34
6.2 Network Coverage Subscription Interface..................................................................... 35
6.2.1 Operation subscribe ........................................................................................................................ 35
6.2.2 Operation unsubscribe .................................................................................................................... 36
6.3 Network Coverage Notification Interface ..................................................................... 36
6.3.1 Operation volumeCoverageChanged .............................................................................................. 36

9 References ............................................................................................................... 41
List of Tables
Table 3: Service identification ............................................................................................................... 15
Table 4: Functional and Non-functional Requirements ........................................................................ 20
Table 5 - Operational Nodes providing the Connectivity Service ......................................................... 20
Table 6 - Operational Nodes (directly) consuming the Connectivity Service ........................................ 21
Table 7 – Operational Activities supported by the NetworkCoverage service ..................................... 21
Table 9: The ConnectivityProvider data structure ................................................................................ 24
Table 10: The Cell4GConnectivityProvider data structure .................................................................... 24
Table 11: The ContingencyPlan data structure ..................................................................................... 24
Table 12: The ContingencyPlanCoverageInformation data structure................................................... 25
6
Table 13: The CoverageData data structure ......................................................................................... 26
Table 14: The CoverageDataRef data structure .................................................................................... 26
Table 15: The CoverageSummaryInfo enumeration ............................................................................. 27
Table 16: The GeometryCoverageInformation data structure ............................................................. 27
Table 17: The Flight data structure ....................................................................................................... 28
Table 18: The OperationPlanAnalyzeResult data structure .................................................................. 30
Table 19: The PhysicalAntenna data structure ..................................................................................... 30
Table 20: The Polarization enumeration ............................................................................................... 31
Table 21: The RadioParameters data structure .................................................................................... 31
Table 22: The Technology enumeration................................................................................................ 31
Table 23: The Technology enumeration................................................................................................ 31
Table 24: The TrajectoryCoverageInformation data structure ............................................................. 32
Table 25: The Volume data structure .................................................................................................... 32
Table 26: Payload description of getVolumeCoverage operation ........................................................ 34
Table 27: Payload description of downloadCoverageData operation .................................................. 34
Table 28: Payload description of analyzeOperationPlan operation...................................................... 35
Table 29: Payload description of subscribe operation .......................................................................... 35
Table 30: Payload description of unsubscribe operation ...................................................................... 36
Table 31: Payload description of getVolumeCoverage operation ........................................................ 37
List of Figures
Figure 1 - Operational model diagram .................................................................................................. 17
Figure 2: Network Coverage Service Interface Definition diagram....................................................... 22
Figure 3: Data Model diagram of the Network Coverage Service......................................................... 23
Figure 4: Network Coverage Service Operation Sequence Diagram – Get area coverage ................... 38
Figure 5: Network Coverage Service Operation Sequence Diagram – Analyze Operation Plan ........... 38
Figure 6: Network Coverage Service Operation Sequence Diagram – subscription, notification and
unsubscription ....................................................................................................................................... 39
7
8
1 Introduction
This document describes the Network Coverage Service in a logical technology-independent manner,
that is:
1.2 Scope
The NetworkCoverage Service described in this document provides a general mechanism between the
various stakeholders, interfaces and data models that enable and allow the automated data exchange
between the respective parties.
The scope includes the following aspects:
 Operational Context
 Service Interfaces
 Service Interface Definition
 Service Dynamic Behavior
 Service Data Model
There are a number of goals defined that this paper aims to achieve:
1. A goal is to define logical messaging that might be exchanged between a traffic management
system (or drone operator, USS/USSP or equivalent) and an MNO.
9
2. A goal is to identify architectures that will be amenable to expedient implementation by a

variety of MNOs, given that MNOs have various operating procedures and means of
managing their networks.
3. A goal is to identify architectures that would support a variety of business models and data
sharing models in a technology independent way (i.e. limiting and avoiding exchange of
proprietary and/or sensitive data).
4. A goal is to provide coverage information primarily for C2 but also for payload traffic.
5. A goal is to maintain synchronization with other ACJA Work Tasks, such that the entirety
provides regulators and users with confidence on performance-based requirements.
6. A goal is to organize those needs that require standards input from ASTM, 3GPP or other
standards developing organizations (SDO) to help close the gap between standards orgs. For
example, flight plans may come from ASTM but Key Performance Indicator (KPI) analysis
methods may come from 3GPP, EUROCAE and RTCA.
7. A goal is to understand what real time metrics, non-real time and aggregated data can come
from the MNO, such as, but not limited to, population density, which could be useful in
predicting risk and/or performance-based metrics.
The overall objective is to provide a minimum set of descriptions to standardize the way data between
MNOs and the UTM ecosystem can be exchanged. The NetworkCoverage Service does not limit any
entity, by any means, to deploy or implement other data exchange in addition to the defined service
definitions.
This document is not anticipated to be a complete set of functions and definitions for an
implementable API.
in charge of designing and developing an instance of the NetworkCoverage Service.

in charge of designing and developing an instance of the Network Coverage service.

1.4 Background
The fact that ensuring robust communications is essential for safe drone operations is not new. Other
projects and papers have been looking into that extensively.
For example, the CORUS Project [2] identifies a so-called Communication Coverage information service
(see CORUS ConOps Volume 2, chapter 5.1.7.6).
10
This service is described there as "The service to provide information about the communication
coverage. It can be specialized depending on the communication infrastructure available (e.g. ground
or satellite based). This service is used to plan relying on required coverage."
The CORUS consortium and other references [13] depict the service as U-space level 2 service, likely
to be available mid-future.
1.4.2 General principles and research basis
A key principle of the U-spaces architecture is applying a service-oriented architecture approach,

where open, interoperable and standard based interfaces are offered based on SWIM principles .
This document is based on both research and commercial environments outlined in a range of
references such as [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [18], [19], [20], [21],
[22].
Term Definition
Describes the semantics of the domain (or a significant part thereof) by defining data
External Data Model structures and their relations. This could be at logical level (e.g., in UML) or at physical
level (e.g., in XSD schema definitions), as for example standard data models.
Describes the principles how two different parts of a message passing system (i.e.: the
service provider and the service consumer) interact and communicate with each
other. Examples:
provider in order to obtain certain information; the service provider provides the
Message Exchange Pattern
requested information in a dedicated response.
In the Publish/Subscribe MEP, the service consumer establishes a subscription with
the service provider in order to obtain certain information; the service provider
publishes information (either in regular intervals or upon change) to all subscribed
service consumers.
An activity performed by an operational node. Examples of operational activities are:
Operational Activity
Route Planning, Route Optimization, Logistics, Safety, Weather Forecast Provision, …
A structure of operational nodes and associated operational activities and their inter-
Operational Model
relations in a process model.
A logical entity that performs activities. Note: nodes are specified independently of
any physical realization.
Operational Node
Provider, …
11
The provision of something (a non-physical object), by one, for the use of one or more
others, regulated by formal definitions and mutual agreements. Services involve
Service interactions between providers and consumers, which may be performed in a digital
form (data exchanges) or through voice communication or written processes and
procedures.
Formal description of one dedicated service at logical level. The service data model is
part of the service specification. Is typically defined in UML and/or XSD. If an external
Service Data Model data model exists (e.g., a standard data model), then the service data model shall
refer to it: each data item of the service data model shall be mapped to a data item
defined in the external data model.
Documents the details of a service technical design (most likely documented by the
service implementer). The service design description includes (but is not limited to) a
Service Design Description
service physical data model and describes the used technology, transport mechanism,
quality of service, etc.
The provider side implementation of a dedicated service technical design (i.e.,
Service Implementation
implementation of a dedicated service in a dedicated technology).
Implementers of services from the service provider side and/or the service consumer
Service Implementer
side.
One service implementation may be deployed at several places by same or different
Service Instance service providers; each such deployment represents a different service instance,
being accessible via different URLs.
Documents the details of a service implementation (most likely documented by the
service implementer) and deployment (most likely documented by the service
Service Instance
provider). The service instance description includes (but is not limited to) service
Description
technical design reference, service provider reference, service access information,
service coverage information, etc.
The communication mechanism of the service, i.e., interaction mechanism between
service provider and service consumer. A service interface is characterized by a
Service Interface
message exchange pattern and consists of service operations that are either allocated
to the provider or the consumer of the service.
Functions or procedure that enables programmatic communication with a service via
Service Operation
a service interface.
Describes the realization of a dedicated service data model in a dedicated technology.
This includes a detailed description of the data payload to be exchanged using the
chosen technology. The actual format of the service physical data model depends on
the chosen technology. Examples may be WSDL and XSD files (e.g., for SOAP services)
or swagger (Open API) specifications (e.g., for REST services). If an external data
model exists (e.g., a standard data model), then the service physical data model shall
Service Physical Data refer to it: each data item of the service physical data model shall be mapped to a
Model data item defined in the external data model.
In order to prove correct implementation of the service specification, there shall exist
a mapping between the service physical data model and the service data model. This
means, each data item used in the service physical data model shall be mapped to a
corresponding data item of the service data model. (In case of existing mappings to a
common external (standard) data model from both the service data model and the
service physical data model, such a mapping is implicitly given.)
12
A service provider provides instances of services according to a service specification

and service instance description. All users within the domain can be service providers,
Service Provider
e.g., authorities, organizations (e.g., meteorological), commercial service providers,
etc.
technology-independent. The Service Specification includes (but is not limited to) a
Service Specification
description of the Service Interfaces and Service Operations with their data payload.
The data payload description may be formally defined by a Service Data Model.
Service Specification Producers of service specifications in accordance with the service documentation
Producer guidelines.
The technical design of a dedicated service in a dedicated technology. One service
Service Technical Design specification may result in several technical service designs, realizing the service with
different or same technologies.
List and specifications of allowed technologies for service implementations. Currently,
Service Technology SOAP and REST are envisaged to be allowed service technologies. The service
Catalogue technology catalogue shall describe in detail the allowed service profiles, e.g., by
listing communication standards, security standards, stacks, bindings, etc.
A service specification is characterized as "spatially exclusive", if in any geographical
region just one service instance of that specification is allowed to be registered per
Spatial Exclusiveness technology.

Acronym Explanation
3GPP 3rd Generation Partnership Project
ACJA Aerial Connectivity Joint Activity (by GSMA + GUTMA)
AIXM Aeronautical Information Exchange Model
AMQ Advanced Message Queuing
ASTM American Society for Testing and Materials
BVLOS Beyond Visual Line of Sight
DL Downlink connection, data transmission from a base station to a mobile device
DSS Discovery and Synchronization Service
EDT Estimated Time of Departure
FIXM Flight Information Exchange Model
13
Acronym Explanation
FPL Flight Plan
GSM Global System for Mobile Communication
GSMA GSM Association
GUTMA Global UTM Association
JMG Java Message Service
KPI Key Performance Indicator
MNO Mobile Network Operator
NOTAM Notice To Air Man
RF Radio Frequency
RSRP Reference Signal Received Power
SDO Standards Developing Organization
SINR Signal to Interference and Noise Ratio (in communication networks)
UL Uplink connection, data transmission from a mobile device to a base station
URN Uniform Resource Name
USS UAS Service Supplier
UTM UAV Traffic Management
UUID Universally Unique Identifier
WXDM Weather Information Exchange Model
XML Extensible Mark-up Language
14
Name Traffic Telemetry Service
ID urn:gof2:services:NetworkCoverageService
Version 1.1
The NetworkCoverage Service provides three-dimensional information about data

connectivity conditions along a flight route or in an area of interest. It provides
Description information where connectivity conditions are or are not good enough for safe and
reliable data connectivity that adheres to a certain service level, provided by individual
connectivity providers.
IP connectivity, data connectivity, data coverage, mobile communication, mobile

Keywords connectivity, mobile coverage, cell connectivity, cell communication, cell coverage, LTE,
4G, 5G, command and control, C2
2020-2021 Thomas Neubauer, ACJA ServiceCoverage Definition participants. Service

Architect(s) Architects: Thomas Wana, Thomas Lutz, Hubert Kuenig, Josef Jahn
2021 The GOF2 U-Space Project Consortium
Status Provisional
Table 3: Service identification
15
Safe operation of UAS / UAM may likely require knowledge of expected RF communications link quality
(performance) and coverage during planning and flight operation, as well as measurement and
monitoring of these parameters during the flight.
Communication coverage is not static information and is subject to continuous change due to a
multitude of factors. Consequently, the coverage information comprises real-time and non-real-time
data. Real-time data may include live performance indicators, alerts on significant changes, but also
real-time network outage information. Non-real-time data for instance could include, but is not limited
to, aggregated and historic information as well as planned events (such as planned maintenance
outages of the network), which allows connectivity analytics and projections into the future. Both
types of data complement each other.
3.1 Planning Phase

Before the start of a flight, there may likely be a need to determine how the planned flight path or
flight operations area fits into the following geographic areas:
Areas with or without cellular network coverage
Areas where non-cellular RF coverage is bad or non-existent, either due to atmospheric conditions,
terrain/building obstruction, or others.
These factors can be determined via network / surveillance coverage maps, RF propagation modeling,
as well through public space weather services. Deriving the necessary OK/not-OK information will
require automated processing and data exchange.
3.2 Flight Phase

During a flight, adherence to the flight plan needs and limitations to be monitored, and any non-
conformance outside of pre-established thresholds and safety margins defined in the operational
authorization, should trigger appropriate mitigation actions.
In addition, UTM service providers receive data about the link quality between UAV and ground station
/ pilot, measuring current signal strength, cumulative signal strength, data transmission latency,
number of packet retransmissions, network notifications, etc.
This data indicates the real time link quality and may be used to react to possible deterioration of link
quality, or even a complete loss of link. Although the safety criticality of the C2 link depends on
characteristics of the UA and the contingency procedures proposed by a UAV operator, some UAV may
pose a safety risk in case of C2 outage time beyond the expected availability as they are essentially
uncooperative drones that do not respond to commands until link is reestablished.
3.3 Example Use Case

An example service use is shown in Figure 1 and described in more detail below:
16
Figure 1 - Operational model diagram
A UAV operator wants to fly a mission from A to B.
In order to estimate the general feasibility of the flight, among other things, the connectivity situation
in the general area of the flight must be checked by the Operation Planning Service1. The
Communication Provider provides the area coverage information utilizing the NetworkCoverage
Service. Coverage information may also be complemented with measured data.
If the flight is feasible in a given area, a concrete route must be planned. Considering among others
the weather, airspace restrictions, aircraft performance, etc., one or more route candidates are
created by the drone operator (and/or USS/USSP or equivalent), which are checked with the support
of the NetworkCoverage Service whether the minimum service level (for example: continuous C2
availability) is met along the candidate routes. If requested, the NetworkCoverage Service can also
propose alternate routes to assure the minimum service level of the connectivity.
The drone operator prepares a flight intent plan ahead of ETD in line with the operational limitations
of his/her authorization. The operator can be assisted in this task by the Operation Planning Service
which may coordinate with the NetworkCoverage Service if the planned flight route meets the
minimum service level requirements.
Shortly before the flight actually commences, the Operation Planning Service may recheck that the
connectivity service level requirements are still met (together with meteorology, NOTAMs, etc.), and,
1
"Operational Planning" is derived from the FAA UTM Conops v2.0 section 2.4.4 [16]: "The Operation Planning service supports the operator
to define prior to the operation a four-dimensional (4D) volume of airspace within which the operation is expected to occur, the times and
locations of the key events associated with the operation, including launch, recovery, and any other information deemed important (e.g.,
segmentation of the operation trajectory by time)."
17
where necessary, alternate routes can be proposed. Then, clearance is requested from Flight/Airspace
Authorization Service2 to commence the flight.
During the flight, due to an outage at the communication provider, a certain segment of the flight
planned route ahead of the aircraft loses connectivity. For this the link quality could be used as key
performance indicator. A Connectivity Service at the Communication Provider identifies this situation
and informs the Notification Service3 by utilizing the NetworkCoverage Service.
The drone operator may have to re-plan the rest of the flight, and coordinate the changes using the
Operation Planning Services, again with the assistance of the NetworkCoverage Service, to stay on a
route that meets the connectivity minimum service level requirements, or apply
contingency/emergency procedures in line with the approved Concept of Operations.
Providers and actors might / will be different depending on the local legislation/regulations.

The table below lists applicable existing requirements for the Network Coverage service.
Id Name
The on-board system should provide a wireless

Communication
REQ-AIRPASS- data link and protocol to coordinate procedural SESAR U-space
for Procedural
D31-PACM-0010 directions from ATC services with the UAS ground requirements
ATC Interface
control station
Communication
REQ-AIRPASS- for Emergency
D31-EACM-0010, Management,
REQ-AIRPASS- Communication
Additional communication requirements like
D31-MNCM-0010, for Monitoring,
above, but for different use-cases: Emergency SESAR U-space
REQ-AIRPASS- Communication
Management, Monitoring, Traffic Information, E- requirements
D31-TICM-0010, for Traffic
Identification, Geofencing, ...
REQ-AIRPASS- Information,
D31-DFCM-0010, Communication
... for Dynamic
Geofencing, ...
2
This service is called "Airspace Authorization" service in FAA UTM Conops v2 section 2.4.3 [16] and "Flight
Authorisation" in EASA draft Commission U-Space regulation in Europe, Article 12 [17].
3
The Notification Service may provide such information to the “Constraint Information & Advisories” Service as
defined in the FAA ConOps v2.0, Section 2.4.5 [16] or equivalent. Similarly, in the SESAR CORUS “U-Space Concept
of Operations” [2] there are services defined in sections 5.1.5.1 and 5.1.6.6 that require “… to provide status
information about communication infrastructure. … The service should give warnings of degradation of
communications infrastructure”.
18
"Two different definitions are proposed:

Definition 1) ATS COM: ‘ATS communication services’ means
amendments are aeronautical fixed and mobile services to enable
proposed to ground-to-ground, air-to-ground for ATS purposes.
REQ-DREAMS- SESAR U-space
include the U- 2) SWIM-COM: ‘SWIM communication services’
D32-OPER.0008 requirements
Space context means fixed and mobile services to enable end
COM systems, either at fixed location, mobiles or in
(Communication) flight, to exchange digital information for
ATM/ANS purposes."
The UAV shall provide continuous information

REQ-IMPETUS- DTM-UAV about its position to the DTM, ensuring that at SESAR U-space
D31-INTR.0012 Interface least this direct link with U-Space is not requirements
compromised.
Legacy networks such as cellular and GPS networks

shall beused to support drone operations and
provide communications between different roles.
REQ-IMPETUS- The networks can be used to communicate U- SESAR U-space
Legacy networks
D31-DECO.0017 space services needed to carry out safe drone requirements
operations. The system will programmatically
communicate with these networks for facilitate
safe drone operations.
The selected communication infrastructure shall

General
REQ-TERRA-D32- ensure the connectivity of the ground segment SESAR U-space
Communications
FPER-0190 with the external systems with which the system requirements
availability
shall interface.
General
REQ-TERRA-D32- SESAR U-space
Communications V2I latency has to be lower than 3 second.
FPER-0192 requirements
latency
The selected communication infrastructure shall

REQ-TERRA-D32- SESAR U-space
Connectivity provide connectivity between the central system
FPER-020 requirements
and all nodes.
The C2 Link System shall offer, for all addressed

REQ-DROC2OM- WP2-GENUS- SESAR U-space
data exchanges, an end-to-end availability of
D21-PERF.0010 PER-001 requirements
provision of at least 99.3%
The C2 Link System shall offer, for all addressed

data exchanges, an availability of use of at least
D21-PERF.0020 PER-002 requirements
99%
The C2 Link System shall offer integrity

REQ-DROC2OM- WP2-GENUS- performance in terms of packet error rate SESAR U-space
D21-PERF.0030 PER-003 measured at the interface between network and requirements
logical link layer of at least 10-3
19
The C2 Link System shall provide communication

links for the whole duration of flights as well as
D21-FUNC.0050 FUN-005 requirements
prior to take-off and after landing.
REQ-DROC2OM- WP2-GENUS- The C2 Link System shall support air-ground SESAR U-space
D21-FUNC.0080 FUN-008 communications for drones. requirements
The C2 Link System shall be compatible with data

REQ-DROC2OM- WP2-DATLI-FUN- links which will support all security related SESAR U-space
D21-FUNC.0100 001 countermeasures to prevent identity theft, theft- requirements
of-service and eavesdropping threats.
The C2 Link System shall be compatible with a

REQ-DROC2OM- WP2-TERST-FUN- 3GPP LTE/LTE-Advanced or 5G NR terrestrial SESAR U-space
D21-FUNC.0200 001 communication system operating in the 3GPP requirements
defined frequency bands.
When using a 3GPP LTE/LTE-Advanced or 5G NR

REQ-DROC2OM- WP2-TERST-FUN- terrestrial communication system, the C2 Link SESAR U-space
D21-FUNC.0220 003 System shall be able to satisfy the baseline traffic requirements
profile requirements listed in Section 3.1.*
The C2 Link System shall define an interface layer

REQ-DROC2OM- WP2-INTSE-FUN- for multi-network service integration, including SESAR U-space
D21-FUNC.0240 001 terrestrial and satellite networks relying on the IP requirements
protocol for global interconnection.
The C2 Link System shall allow deployment of

REQ-DROC2OM- WP2-MULOP- SESAR U-space
competing C2 Link Service providers and operators
in samegeographical locations.
The C2 Link System shall allow Interworking, i.e.

having the C2 Link data sent from the drone to
REQ-DROC2OM- WP2-MULOP- SESAR U-space
ground network through a provider, and reaching
the U-Space infrastructure servers through
another provider
Table 4: Functional and Non-functional Requirements
3.5 Operational Nodes
Connectivity Provider A provider of communication services like a Mobile Network Operator or

a Satellite Data Communications Provider.
Connectivity Service Service deployed close to mobile network operator infrastructure,
providing connectivity data for the Network Coverage Service.
Table 5 - Operational Nodes providing the Connectivity Service
20
Operation Planning Service Service defined in FAA UTM Conops v2.0 section 2.4.4 [16]: "The
Operation Planning service supports the operator to define prior to the
operation a four-dimensional (4D) volume of airspace within which the
operation is expected to occur, the times and locations of the key events
associated with the operation, including launch, recovery, and any other
information deemed important (e.g., segmentation of the operation
trajectory by time).".
Flight/Airspace Authorization Service Service providing authorization for a specific flight. Depending on local
regulation this service works with flight trajectories or airspace volumes.
Notification Service Notifies drone operators of relevant changes that occurred typically in-
flight, or pre-flight after the initial planning phase.
It could consume events from different services, not only the Network
Coverage Service.
Table 6 - Operational Nodes (directly) consuming the Connectivity Service
Operational Activity Remarks
Get area and flight route coverage Returns information about connectivity coverage for a certain area or
flight route for a particular technology and communication provider for a
particular time period in the future
Notify about changes in coverage For a given area or flight route, get notifications about changes to
connectivity.
Provide communication services The communication provider provides its infrastructure to the drone
operators for data communication.
Table 7 – Operational Activities supported by the NetworkCoverage service
21
4 Service Overview
The following diagram depicts the Service Interfaces of the NetworkCoverage Service, and their
allocations to the Service Provider and the Service Consumers, respectively:
Figure 2: Network Coverage Service Interface Definition diagram
Role (from service provider

point of view)
getVolumeCoverage
NetworkCoverageServiceInterface Provided downloadCoverageData
analyzeOperationPlan
subscribe
NetworkCoverageSubscriptionInterface Provided
unsubscribe
NetworkCoverageNotificationInterface Required volumeCoverageChanged

22

Figure 3: Data Model diagram of the Network Coverage Service
The Service Data Model focuses on the core service model and the diagram includes structures
(OperationPlan, Volume, Pose), whose detailed specification are out of scope of this document.
The data model supports and is compatible with a number of industry standards, such as ICAO, ASTM
F3411-19 [18], EUROCAE ED-269 [20], FIXM, etc. It is important to note that the data model can be
extended, for example for future requirements and additional information that may need to be
exchanged.
The following tables describe the entities and their attributes in more detail.
5.1 The ConnectivityProvider Data Structure

The ConnectivityProvider represents a connectivity provider, e.g. a provider of communication services
like a Mobile Network Operator or a Satellite Data Communication Provider.
23
technology Technology 1 The technology of the radio parameter.

Table 9: The ConnectivityProvider data structure
5.2 The Cell4GConnectivityProvider Data Structure

The Cell4GConnectivityProvider is an example specialization of the ConnectivityProvider class. It
contains additional attributes to identify a Mobile Network Operator that offers 4G cellular
connectivity services.
It works the same for 5G, while for satellite or other connectivity technology providers the attributes
might be different.
MCC int 1 Mobile Country Code.
Mobile Network Code. MCC and MNC together uniquely identify

MNC int 1
the Mobile Network Operator globally.
Table 10: The Cell4GConnectivityProvider data structure
5.3 The ContingencyPlan Data Structure

Note: ContingencyPlan is fullly described in a separate Operation Plan service specification, selected
attributes are listed here to provide context for better understanding.
The ContingencyPlan describes an alternative trajectory location for a flight by providing a three-
dimensional volume in space together with the applicable time span.
id UUID 1 Identifier of the contingency plan.
Three-dimensional space fragment, specifying

the envelope of contingency trajectory. Can be
contingencyGeometry Geometry 1
for example a cube, cylindar, quader, or other
geometry.
UTC point in time when the flight is expected to

validTimeBegin DateTime 1
enter the given contingency volume.
UTC point in time when the flight is expected to

validTimeEnd DateTime 1
leave the given contingency volume.
Table 11: The ContingencyPlan data structure
5.4 The ContingencyPlanCoverageInformation Data Structure

The ContingencyPlanCoverageInformation holds an analysis in regards to connectivity coverage for a
contingecy plan belonging to an operation plan.
24
Reference to the
contingencyPlanId UUID 1
contingency plan.
coverageAtContingency GeometryCoverageInformation 1 corresponding to the
contingency plan.
Table 12: The ContingencyPlanCoverageInformation data structure
5.5 The CoverageData Data Structure

The CoverageData structure contains 3D aerial coverage information in a raster of a certain
resolution. Full capabilities are to be described in an external CoverageData specification document
for further processing.
It is essentially a 3D grid where each grid cell has an assigned a value. CoverageData is like a 3D
bitmap, where the pixel content represents attributes relevant for exchanging network coverage
information, e.g. boolean values true/false to describe whether the requested service level is met at
that particular point or not.
In future versions of this data structure, CoverageData could support exchange of numeric values or
other types that can be encoded in a byte, allowing to transport e.g. minimum throughput in a grid
cell.
How exactly values are encoded in the byte array has to be described in a separate document specific
to and available for an implementation of CoverageData.
Latitude of the north-

west corner of the
latitude float 1
area covered in
WGS84.
Longitude of the
north-west corner of
longitude float 1
the area covered in
WGS84.
Altitude of the lower

altitude float 1 boundary of the 3D
area.
Height of the Area, in

latSize float 1 WGS 84 degrees.
Typically 1.0
25
Width of the Area, in

lonSize float 1 WGS 84 degrees.
Typically 1.0
Altitude of the Area,

altsize float 1 in meters. Typically
500 (?)
Horizontal resolution
of the raster, in arc
horizontalResolution int 1
seconds (WGS 84).
Typically 2.
Vertical resolution of
verticalResolution int 1 the raster, in arc
meters Typically 15.
Overview information
about how the
requested service
level is met for the
whole area.
coverageSummary CoverageSummaryInfo 1
If this is
FULLY_COVERED or
NON_COVERED, then
the buffer may be
omitted.
May be omitted
The actual 3D array
depending on
buffer byte 0..* that contains the
coverageSummary
raster’s values.
value.
Table 13: The CoverageData data structure
5.6 The CoverageDataRef Data Structure

The CoverageDataRef structure contains a reference to a CoverageData object. Actual coverage data
can be downloaded by passing a CoverageDataRef object to the downloadCoverageData method.
ref UUID 1 Unique reference.
volume Volume 0..1 optional definition of the space volume.

Table 14: The CoverageDataRef data structure
26
5.7 The CoverageSummaryInfo Enumeration

The CoverageSummaryInfo enumeration type specifies the level of coverage related to a certain entity
or volume.
FULLY_COVERED Network coverage is given for the whole entity/volume.
PARTIALLY_COVERED Network coverage is given for a part of the entity/volume.
NON_COVERED Network coverage is not given at all for the whole entity/volume.
Table 15: The CoverageSummaryInfo enumeration
5.8 The GeometryCoverageInformation Data Structure

The GeometryCoverageInformation holds an analysis in regards to connectivity coverage for certain
volume of 3-dimensional space.
geometry Geometry 1 Describes the volume of space.
Overview information about how the

requested service level is met for the
whole volume.
coverageSummary CoverageSummaryInfo 1 If this is FULLY_COVERED or
NON_COVERED, then the
coverageDataRef elements may be
omitted.
A series of references to CoverageData

structures, describing the coverage of
coverageDataRef CoverageDataRef 0..*
individual cells of a raster of 3D
partitions of the volume.
Table 16: The GeometryCoverageInformation data structure
5.9 The OperationPlan Data Structure

Note: OperationPlan is fullly described in a separate Operation Plan service specification, selected
attributes are listed here to provide context for better understanding.
The OperationPlan represents a complete flight plan. It refers to Pose instances providing spatial
orientation of the aircraft for positions along the planned flight trajectory.
The communication equipment used on the aircraft is provided when requesting a network coverage
analysis.
27
Unique identifier of the More information for

operation plan. A gufi: a flight could be
operationPlanId UUID 1 globally unique flight retrieved using a
identifier if form of a respective Flight
UUID Information Service
The OperationTrajectory
is an (ordered) list of 3-
dimensional points,
operationTrajectory OperationTrajectory 0..1
associated with time
span, representing the
flight route.
An ordered list of 3-
dimensional space
fragments, associated
with time span,
operationVolumes OperationVolume 0..*
representing the flight
route in a more rough
sequence of space
voluemes.
Holds information on
preplanned contingency
contingencyPlans ContingencyPlan 0..* situations, especially
regarding volumes and
when they are used.
Optional. Redundant
Explicit indication of the
with the information
takeoffLocation Geometry 0..1 starting point of the
given in the first
flight.
trajectoryElement.
Optional. Redundant
Explicit indication of the
with the information
landingLocation Geometry 0..1 landing point of the
given in the last
flight.
trajectoryElement.
Location of controller
controllerLocation Geometry 0..1 (e.g. the ground control
station).
Information about the

communication
radioParameters RadioParameters 0..1
equipment used during
the flight.
Table 17: The Flight data structure
28
5.10 The OperationPlanAnalyzeResult Data Structure

The OperationPlanAnalyzeResult holds an analysis in regards to connectivity coverage for an
OperationPlan.
Multiplici
ty
about how the
requested service level
is met for the whole
OperationPlan.
If this is
coverageSummary CoverageSummaryInfo 1 FULLY_COVERED or
NON_COVERED, then
all the other entries of
the
OperationPlanAnalyzeR
esult structure may be
omitted.
This is
optional,
as it is
redundan
t
related to the takeoff
coverageAtTakeoff GeometryCoverageInformation 0..1 informati
location of the
on also
operation plan.
available
in the
trajectory
.
This is
optional,
as it is
redundan
t
related to the landing
coverageAtLanding GeometryCoverageInformation 0..1 informati
location of the
on also
operation plan.
available
in the
trajectory
.
related to the ground
coverageAtController GeometryCoverageInformation 0..1
controller location of
the operation plan.
29
related to the
coverageAtTrajectory TrajectoryCoverageInformation 0..1
trajectory of the
operation plan.
coverageAtOperationVo related to the
TrajectoryCoverageInformation 0..1
lume operation volumes of
the operation plan.
coverageAtContingency ContingencyPlanCoverageInfor related to a
0..*
Plan mation contingency plan of the
operation plan.
Table 18: The OperationPlanAnalyzeResult data structure
5.11 The PhysicalAntenna Data Structure

The PhysicalAntenna provides information about the physical antenna used for communication on the
aircraft. There can be more than one such antennas. The orientation of the antenna on the aircraft is
modelled using Euler angles (more specifically, the orientation of the antenna pattern).
A type specifier of the antenna. Optional; can be

used instead of specifying the pattern, gain and
type string 0..1
polarization attributes if the antenna type is well-
known.
horizontalPattern string 1 Horizontal antenna pattern string.
verticalPattern string 1 Vertical antenna pattern string.
gain float 1 Antenna gain, in dBi.
polarization Polarization 1 Antenna polarization.
theta, phi, psi float 1 Orientation angles of the antenna.

Table 19: The PhysicalAntenna data structure
5.12 The Polarization Enumeration

The Polarization enumeration type specifies polarization types.
HORIZONTAL Horizontal polarization.
30
VERTICAL Vertical polarization.
CROSS Cross polarization.

Table 20: The Polarization enumeration
5.13 The RadioParameters Data Structure

The RadioParameters provides communication equipment (physical) and logical communication
information. This is an abstract class, needs technology-aware specialized implementation.
technology Technology 1 The technology of the radio parameters.
antenna Antenna 1..* The used antenna parameters.

Table 21: The RadioParameters data structure
5.14 The ServiceLevel Enumeration

The ServiceLevel enumeration type specifies service levels.
C2
STREAM_4K
...
Table 22: The Technology enumeration
5.15 The Technology Enumeration

The Technology enumeration type specifies Communication technologies.
CELL_4G
CELL_5G
...
Table 23: The Technology enumeration
31
5.16 The TrajectoryCoverageInformation Data Structure

The TrajectoryCoverageInformation holds an analysis in regards to connectivity coverage for a flight
trajectory belonging to an operation plan.
Multiplicit Not
Property Type Description
y e
about how the requested
service level is met for the
whole trajectory.
coverageSummary CoverageSummaryInfo 1 If this is FULLY_COVERED
or NON_COVERED, then
the
coverageAtTrjectoryEleme
nt elements may be
omitted.
coverageAtTrjectoryEleme GeometryCoverageInformati corresponding to a certain
0..*
nt on trajectory element or
operation volume.
Table 24: The TrajectoryCoverageInformation data structure
5.17 The TrajectoryElement Data Structure

Note: TrajectoryElement is fullly described in a separate Operation Plan service specification.
The TrajectoryElement describes a segment of a flight trajectory by providing a four-dimensional point

in space-time.
5.18 The Volume Data Structure

The Volume structure describes a geographic 3D volume in space. These are covered in greater detail
in an external Volume specification. Typical volumes are cylinders with a certain radius and height or
polyhedrons.
id UUID 1 Unique reference.
type enum 1 The type of volume
geometry Geonetry 1 The geometry that describes this volume

Table 25: The Volume data structure
32

Service Interface.
(behaviour) is described in a subsequent chapter.
6.1 Network Coverage Service Interface

This Service Interface is the main point of interaction for Service Consumers. It provides methods to
fetch volume coverage and conduct operation plan analyzes. It is provided by the Network Coverage
Service.
The NetworkCoverageServiceInterface realizes the Request/Response Message Exchange Pattern

(MEP), where the Service Consumer calls Operations at the Service Provider and the Service Provider
answers synchronously with a result. This MEP is most suitable for the synchronous, 1:1 nature of the
included Service Operations.
6.1.1 Operation getVolumeCoverage
The getVolumeCoverage operation produces information about three-dimensional area connectivity

conditions for a certain Service Level and a certain Connectivity Provider. It basically answers the
question where in three-dimensional space can the requested Service Level be provided by the
Connectivity Provider right now. Note that this is only a high-level overview on the connectivity
conditions as other significant factors like aircraft speed and orientation are conceptually not available
at the time of requesting large area coverage.
Coverage information is transported in 3D buffer CoverageData objects. This operation returns

references to such objects for the requested volume. The actual coverage data can then be
downloaded via the downloadCoverageData operation.
Parameter
Name
Specifies the 3-dimensional space for

volume Input Volume which the network coverage shall be
determined.
serviceLevel Input ServiceLevel Requested service level.
connectivityProvider Input ConnectivityProvider Requested connectivity provider.
33
The return value contains a structure

with connectivity information for the
requested 3D volume.
If network connectivity is not
homogeneously covered or not covered
<none> Return GeometryCoverageInformation
for the whole volume, then the result
contains a list of references to
CoverageData elements, comprising a
3D raster of 3D cells with finer graned
coverage information.
Table 26: Payload description of getVolumeCoverage operation
6.1.2 Operation downloadCoverageData
The download CoverageData operation is used to download the actual coverage data for a given
CoverageData reference. CoverageData references can be be obtained from the getVolumeCoverage
operation or are reported via the volumeCoverageChanged operation in the
NetworkCoverageServiceNotificationInterface.
Parameter
Name
CoverageData reference, pointing to the coverage data

coverageDataRef Input CoverageDataRef obtained via a different operation (getVolumeCoverage
or volumeCoverageChanged).
The return value contains the detailed coverage

<none> Return CoverateData
information.
Table 27: Payload description of downloadCoverageData operation
6.1.3 Operation analyzeOperationPlan
The analyzeOperationPlan operation answers the question “where on the given flight route is the given
Service Level met for a particular Connectivity Provider?” It can also help with route planning by
providing the option to alter the route in certain limits for locations so that the complete route fulfils
the Service Level requirements.
The Network Coverage Service brokers with the Connectivity Provider or connectivity data provider so
that the given flight route is evaluated on their premises. The Network Coverage Service then returns
the results to the Consumer.
A “service level” in the context of this interface is an abstract name for a combination of connectivity
conditions. For example, a “C2” (command & control) service level might require a certain maximum
physical layer latency, whereas a “streaming 4K” service level might require a minimum guaranteed
throughput in mbit/s. Additionally, depending on the communication technology, other technical
thresholds and limits will be in place for the different service levels (in 4G for example, a minimum
RSRP and SINR value). These thresholds and limits are configured on the connectivity provider’s side
and likely be specified by standardization. The aviation user does not need to know these; she only
requests the service levels by name that are relevant for the planned mission.
34
Parameter
Name
An operation plan, including four-dimensional

trajectory information and optional
operationPlan Input OperationPlan
contingency planning (i.e., alternative flight
locations).
Connectivity Connectivity or connectivity

Input
Provider data Provider
The return value contains a structure with

connectivity information for the given
operation plan.
If network connectivity is not homogeneously
<none> Return OperationPlanAnalyzeResult covered or not covered for the whole
operation plan, then the result contains
dedicated coverage information structures for
individual trajectory elements and for
individual contingency planning elements.
Table 28: Payload description of analyzeOperationPlan operation
6.2 Network Coverage Subscription Interface

This Service Interface provides Subscribe operations to Service Consumers. It is provided by the
Network Coverage Service.
The NetworkCoverageSubscriptionInterface and the NetworkCoverageNotificationInterface together

realize the Publisher/Subscriber MEP. As the connectivity information in a certain area constantly
changes, the notification for such changes is posted to a Publisher/Subscriber topic. Service Consumers
can attach to those topics and get asynchronously notified about changes to areas of their interest.
6.2.1 Operation subscribe
The subscribe operation allows a Service Consumer to subscribe to changes in area connectivity
coverage.
Whenever the connectivity information for a certain Service Level and Connectivity Provider happens
to change, a notification is posted in a dedicated topic. Service Consumers can subscribe to that topic
to be notified about those changes.
connectivityProvider Input ConnectivityProvider Requested connectivity provider.

Table 29: Payload description of subscribe operation
35
6.2.2 Operation unsubscribe
As the opposite operation of subscribe, this operation allows a Service Consumer to stop receiving
notifications about changes for a certain Service Level and Connectivity Provider.
This removes the service consumer from the list of consumers to be notified.
serviceLevel Input ServiceLevel Service level for unsubscription.
connectivityProvider Input ConnectivityProvider Connectivity provider for unsubscription.

Table 30: Payload description of unsubscribe operation
6.3 Network Coverage Notification Interface

This Service Interface is provided by and implemented on the service consumer’s side. It is called to
notify the service consumer about changes it subscribed to via the operations in the
NetworkCoverageSubscriptionInterface.
The NetworkCoverageSubscriptionInterface and the NetworkCoverageNotificationInterface together

realize the Publisher/Subscriber MEP. As the connectivity information in a certain area constantly
changes, the notification for such changes is posted to a Publisher/Subscriber topic. Service consumers
can attach to those topics and get asynchronously notified about changes to areas of their interest.
6.3.1 Operation volumeCoverageChanged
This Operation is called on the service consumer’s side whenever the coverage information for a
certain Service Level and a certain Connectivity Provider changed.
Whenever the connectivity information for a certain Service Level and Connectivity Provider happens
to change, a notification is posted in a dedicated topic. If the service consumer subscribed to that topic,
it will receive notifications via this operation.
Parameter
Name
Service level for which the coverage

serviceLevel Input ServiceLevel
changed.
Connectivity provider for which the

connectivityProvider Input ConnectivityProvider
coverage changed.
36
Details with connectivity information for

the 3D volume in which the connectivity
changed.
If network connectivity is not
homogeneously covered or not covered
coverageInfo Return GeometryCoverageInformation
for the whole volume, then the
coverageInfo contains a list of
references to CoverageData elements,
comprising a 3D raster of 3D cells with
finer graned coverage information.
Table 31: Payload description of getVolumeCoverage operation
37

The following diagrams describe examples for the dynamic behavior of the NetworkCoverageService.
Figure 4: Network Coverage Service Operation Sequence Diagram – Get area coverage
Figure 5: Network Coverage Service Operation Sequence Diagram – Analyze Operation Plan
Please note that the interface between the Connectivity Provider and the NetworkCoverage Service
are out of scope of this document, however to indicate the dynamic behavior they are shown here.
38
Figure 6: Network Coverage Service Operation Sequence Diagram – subscription, notification and unsubscription
39
Left Empty.
40
9 References
[1] 3GPP – "Enhanced LTE support for aerial vehicles", RR 35.777, Release 15, 2019,
"http://www.3gpp.org" www.3gpp.org
[2] CORUS – SESAR "Concept of Operations for U-Space", https://www.sesarju.eu/node/3411
[3] 5G!Drones, "Initial Definition of the trial controller architecture, mechanisms and APIs", 2020
https://5gdrones.eu/wp-content/uploads/2020/06/D2.1-Initial-definition-of-the-trial-
controller-architecture-mechanisms-and-APIs_v1.1.pdf
[4] SESAR – SWIM Profiles, 2015, https://www.sesarju.eu/sites/default/files/SESAR-Factsheet-

2015-SWIM-Profiles.pdf
[5] DroC2om – Drone Critical Communications Project, including C2 for U-Space via combined
cellular and satellite systems, https://www.droc2om.eu/
[6] U-Space DREAMS (Drones European Aims Study) Final Project Results Report, 2019,
https://www.u-spacedreams.eu/wp-content/uploads/ER-DREAMS-D2.2-U-space-Final-Project-Results-
Report_1.1.pdf
[7] FAA – UAS Identification and Tracking – Aviation Rulemaking Committee (ARC) Final Report,
2017,https://www.faa.gov/regulations_policies/rulemaking/committees/documents/media/UAS%20ID
%20ARC%20Final%20Report%20with%20Appendices.pdf
[8] European Commission, "SESAR Standardisation Roadmap 2020", 2019,

https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5c9ec6
a75&appId=PPGMS
[9] SESAR - "GOF USPACE - Successful demonstration of UTM in international validations, applying
SWIM principles to connect 2 air navigation service providers and 3 U-space service provider",
2019 https://www.sesarju.eu/node/3387
[10] ICAO, "International work on high level standardisation of information exchange",

https://www.icao.int/APAC/Pages/swim.aspx
[11] EU Commission – "IMPETUS (Information Management Portal to Enable the Integration of

Unmanned Systems) - Architecture and Technical Requirements", 2019,
https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5c1c8fa
04&appId=PPGMS
[12] SESAR - EMPHASIS, "Empowering heterogeneous aviation through cellular signals", 2020,
https://www.sesarju.eu/node/3109
[13] SESAR – “Consolidated Report on SESAR U-Space Research and Innovations Results”, Nov 2020,
[14] ICAO – “Technology Workshop ICAO RPAS MANUAL C2 Link and Communications”, 2015,
https://www.icao.int/Meetings/RPAS/RPASSymposiumPresentation/Day%202%20Workshop%205%20T
echnology%20Michael%20Neale%20-
%20ICAO%20RPAS%20Manual%20C2%20Link%20and%20Communications.pdf
41
[15] Open Geospatial Consortium, “OGC GeoTIFF standard”, http://docs.opengeospatial.org/is/19-

008r4/19-008r4.html
[16] FAA, UTM Concept of Operations v2.0, March 2020,

https://www.faa.gov/uas/research_development/traffic_management/media/UTM_ConOps_v2.pdf
[17] European Commission, Annex to EASA Opinion No 01/2020, “Commission Implementing

Regulation (EU), DRAFT”, Oct 2020,
https://www.easa.europa.eu/sites/default/files/dfu/Draft%20COMMISSION%20IMPLEMENTING%20RE
GULATION%20on%20a%20high-level%20regulatory%20fram....pdf
[18] ASTM F3411-19, “Standard Specification for Remote ID and Tracking”, Committee F38 on
Unmanned Aircraft Systems, https://www.astm.org/COMMITTEE/F38.htm
[19] RTCA DO-377, “Minimum Aviation System Performance Standards for C2 Link Systems
Supporting Operations of Unmanned Aircraft Systems in U.S. Airspace”,
https://standards.globalspec.com/std/13301563/rtca-do-377, March 2019
[20] EUROCAE ED-269, “Minimum Operational Performance Standard for Geofencing”,

www.eurocae.net, June 2020
[21] ACJA, “NetworkCoverage Service Definition 1.0”, published by GSMA and GUTMA, February
2021, https://www.gsma.com/iot/resources/acja-wt2-interface-for-data-exchange-between-mnos-and-
the-utm-ecosystem/
[22] EUROCAE ER 012, Command, Control and ATC Communications Operational Concept (C3
CONOPS) for Remotely Piloted Aircraft
42
D2.4 Appendix I Drone

Flight Exchange Service
Specification
Deliverable ID: D2.4-I
Grant: 101017689
Edition: 01.00.00
D2.4 APPENDIX I DRONE FLIGHT EXCHANGE SERVICE SPECIFICATION

Hubert Künig / FRQ Scientist 31.10.2022
Thomas Lutz / FRQ WP2 Lead 31.10.2022
Gregor Mogertisch WP2 31.10.2022

Lukasz Gorny - Zajac Solution Architect 1.11.2022
Pawel Korzec PM 1.11.2022

Document History
2

00.00.01 31.10.2022 draft FRQ New Document
00.00.02 3.11.2022 draft WP2 Partners Revision and updates
01.00.00 4.11.2022 Released Coordinator submit
Copyright Statement
3
GOF 2.0
Abstract
Exchange Service.
This document describes one of these Bridge Services, the Drone Flight Exchange service in a logical,
4
Table of Contents
Abstract ................................................................................................................................... 4
1 Abstract ........................................................................... Error! Bookmark not defined.
2 Introduction ............................................................................................................... 9
2.2 Scope ............................................................................................................................ 9
2.4 Background ................................................................................................................... 9
2.4.4 SESAR-JU.......................................................................................................................................... 11
2.6 List of Acronyms .......................................................................................................... 15
4.2.1.1 ICAO SWIM ............................................................................................................................. 19
5 Service Interfaces ..................................................................................................... 21

6.1 Overview..................................................................................................................... 23
6.2 The DroneFlight Data Structure .................................................................................... 23
6.3 The DroneFlightResponse Data Structure ..................................................................... 27
6.4 The OperationPlanState Enumeration .......................................................................... 27
6.5 The EnumDroneFlightState Enumeration...................................................................... 28
6.6 The EnumDroneFlightConformanceState Enumeration ................................................ 29
6.7 The EnumDroneFlightEmergencyState Enumeration ..................................................... 29
6.8 The EnumDroneFlightCooperationState Enumeration ................................................... 30
6.9.1 NotificationEndpoint Data Structure............................................................................................... 30
6.9.2 ServiceResponse Data Structure ..................................................................................................... 31
5
6.9.3 OperationResult Enumeration ........................................................................................................ 31


7.1 Service Interface DroneFlightRetreivalInterface ............................................................ 36
7.1.1 Operation getDroneFlight ............................................................................................................... 36
7.1.2 Operation getDroneFlightsForGeometry ........................................................................................ 36
7.2 Service Interface DroneFlightSubscriptionInterface ...................................................... 37
7.2.1 Operation subscribeForDroneFlights .............................................................................................. 37
7.2.2 Operation unsubscribeForDroneFlights .......................................................................................... 37
7.3 Service Interface DroneFlightNotificationInterface ....................................................... 37
7.3.1 Operation notifyDroneFlight ........................................................................................................... 37
7.4 Service Interface DroneFlightManagementInterface ..................................................... 38
7.4.1 Operation createDroneFlight .......................................................................................................... 38
7.4.2 Operation updateDroneFlight ......................................................................................................... 38
7.4.3 Operation pauseDroneFlight ........................................................................................................... 39
7.4.4 Operation resumeDroneFlight ........................................................................................................ 39
7.4.5 Operation finishDroneFlight ............................................................................................................ 39
7.4.6 Operation setDroneFlightConformanceState ................................................................................. 40
7.4.7 Operation setDroneFlightEmergencyState ..................................................................................... 40
7.4.8 Operation setDroneFlightCooperationState ................................................................................... 40
6


8.2 Drone Flight State Machine .......................................................................................... 43
9 References ............................................................................................................... 45
List of Tables
Table 4: Requirements for the DroneFlightExchange Service ............................................................... 18
Table 5: Operational Nodes providing the DroneFlightExchange service ............................................. 19
Table 6: Operational Nodes consuming the DroneFlightExchange service .......................................... 20
Table 7: Operational Activities supported by the DroneFlightExchange service .................................. 20
Table 9: The DroneFlight data structure ............................................................................................... 27
Table 10: The DroneFlightResponse data structure .............................................................................. 27
Table 11: The OperationPlanState enumeration .................................................................................. 28
Table 12: The EnumDroneFlightState enumeration ............................................................................. 29
Table 13: The EnumDroneFlightConformanceState enumeration........................................................ 29
Table 14: The EnumDroneFlightEmergencyState enumeration............................................................ 30
Table 15: The EnumDroneFlightCooperationState enumeration ......................................................... 30
7
Table 24: Payload description of getDroneFlight operation ................................................................. 36
Table 25: Payload description of getDroneFlightForGeometry operation ........................................... 36
Table 26: Payload description of subscribeForDroneFlights operation ................................................ 37
Table 27: Payload description of unsubscribeForDroneFlights operation ............................................ 37
Table 28: Payload description of notifyDroneFlight operation ............................................................. 38
Table 29: Payload description of createDroneFlight operation ............................................................ 38
Table 30: Payload description of updateDroneFlight operation ........................................................... 38
Table 31: Payload description of pauseDroneFlight operation............................................................. 39
Table 32: Payload description of resumeDroneFlight operation .......................................................... 39
Table 33: Payload description of finishDroneFlight operation ............................................................. 40
Table 34: Payload description of setDroneFlightConformanceState operation ................................... 40
Table 35: Payload description of setDroneFlightEmergencyState operation ....................................... 40
Table 36: Payload description of setDroneFlightCooperationState operation ..................................... 41
List of Figures
Figure 1: U-space nodes related to the DroneFlightExchange service................................................. 19
Figure 2: DroneFlightExchangeService Interface Definition diagram ................................................... 21
Figure 3: Drone Flight Service Data Model diagram ............................................................................. 23
Figure 6: DroneFlightExchange service example operation sequence diagram ................................... 42
Figure 7: Drone flight states - state transition diagram in comparison with Operation Plan state
machine ................................................................................................................................................ 44
8
1 Introduction
In accordance with according to the guidelines given in [3], this document describes the Drone Flight
Exchange service for the GOF 2.0 project on a logical technology-independent manner, that is:

1.2 Scope
This document describes the Drone Flight Exchange service for the GOF USPACE project.
The Drone Flight Exchange service provides a means for the operational nodes of the GOF USPACE
project to share information about drone flights and make them available for further processing.
The Drone Flight Exchange service furthermore provides a means for the operational nodes of the GOF
USPACE project to consume information about drone flights from the U-space participants for further
processing.

in charge of designing and developing an instance of the Drone Flight Exchange service as well as of
the Operation Plan Information Exchange service.

1.4 Background
9
EUROCONTROL CORUS [4] elaborates the Operation Plan Processing service as follows:
“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 plan.
 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.
 If available, the Dynamic capacity management service is invoked.“
In other words, the Operation Plan Processing service deals with the planning aspects of a drone flight.
There is no mentioning about the dynamic execution of the drone flight, other than the following:
“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.”
In this document we propose to introduce the Drone Flight Exchange service to bridge the gap between
Operation Plan Processing service and Tracking Service.

The FAA defines a messaging service in its Concepts of Operations v1.0 - Appendix C - UTM Services -
Messaging Service [7] as follows.
“A service which provides on demand, periodic, or event driven information on UAS operations (e.g.
position reports, intent information, and status information) occurring within the subscribed airspace
volume and time. Additional filtering may be performed as part of the service.”
10
In the Global Air Navigation Plan [9], ICAO defines three Aviation System Block Upgrade (ASBU) blocks,
B1-RPAS, B2-RPAS, and B3-RPAS, referring to scheduled implementation years of 2019, 2025, 2031,
and beyond, and expects increased situational awareness from B1-RPAS onwards.
“Within the SWIM Global Interoperability Framework, the Information Exchange layer is instantiated
by ‘information services’ as is further explained. Information services ensure interoperability between
ATM applications which consume and provide interoperable information services. Consequently, the
concept of information service is a fundamental building block of SWIM which enables
interoperability through well-defined information exchanges.”
1.4.4 SESAR-JU
is being driven by a rapidly growing market of Very-Low-Level (VLL) airspace users, most of which are
Via the Roadmap for the safe integration of drones into all classes of airspace [11], within the European
ATM Masterplan [12], the European Commission seeks to ensure that this rapid growth of airspace use
happens in a safe and controlled manner.
is being validated throughout Europe via several Very Large Demonstrator (VLD) projects such as the
GOF USPACE project.
U2 is anticipated to provide tracking capabilities and services.


Term Definition
11
A report from an aircraft in flight prepared in conformity with requirements

AIR-REPORT
for position, and operational and/or meteorological reporting.
Drone Flight Information about the actual conduction of a drone flight.
Describes the semantics of the domain (or a significant part thereof) by

External Data defining data structures and their relations. This could be at logical level (e.g.,
Model in UML) or at physical level (e.g., in XSD schema definitions), as for example

Message service provider in order to obtain certain information; the service provider
Exchange Pattern provides the requested information in a dedicated response.

Operation Plan Information about the planning of a drone operation.

Operational
Activity
Operational A structure of operational nodes and associated operational activities and
Model their inter-relations in a process model.
Operational Node
12
model is part of the service specification. Is typically defined in UML and/or
Service Data
XSD. If an external data model exists (e.g., a standard data model), then the
Model
Documents the details of a service technical design (most likely documented
Service Design by the service implementer). The service design description includes (but is
Description not limited to) a service physical data model and describes the used
technology, transport mechanism, quality of service, etc.
Service Instance different service providers; each such deployment represents a different
Documents the details of a service implementation (most likely documented
by the service implementer) and deployment (most likely documented by the
Service Instance
Description
Service Interface characterised by a message exchange pattern and consists of service
service.
Service Operation
13

Service Physical
Data Model
Service Provider
Service
Specification
Data Model.
Service
Specification
Producer
Service Technical
service specification may result in several technical service designs, realising
Design
the service with different or same technologies.
Service Currently, SOAP and REST are envisaged to be allowed service technologies.
Technology The service technology catalogue shall describe in detail the allowed service
bindings, etc.
14

be registered per technology.
Spatial
Exclusiveness
governance issue.

Acronym Definition
OP Operation Plan
15
Name DroneFlightExchange Service

ID urn:gof:services:DroneFlightExchangeService
Version 1.0
Description An information exchange service which provides drone flight information
Operation Plan, Drone Flight execution, Drone Flight States, Correlation between
Keywords
Operation Plan and Position Reporting
2022 The GOF 2.0 Project Consortium
Architect(s)
2022 The Frequentis Group
Status Provisional
16

The table below lists applicable existing requirements for the DroneFlightExchange service.
Id Name
At all times, all U-space participants CORUS [4], 4.1.1.2
Common shall operate on the same common set Amber airspace;B1-
[R-1] Situational of data, during pre-flight planning RPAS [9];CEF-SESAR-
Awareness stages as well as during all stages of 2018-1 [1], Objective
flight operations. O5
SESAR Drone Roadmap
The U-space concept shall be designed
4.2;U-space Blueprint
such as to ensure a well-established line
Basis for Open [13], Benefits to
[R-2] of authority while at the same time
Market European society and
ensuring that an open market for VLL
economy;CEF-SESAR-
services may develop
2018-1 [1], Table 8 –
Key Challenges
There shall be an implementation of a
(FIMS) which ensures that, at all times,
emerging unmanned traffic
ICAO Doc 10039 [2];[R-
management systems and existing
2];CEF-SESAR-2018-1
technologies from manned operations
[R-3] Interoperability [1], Objective O6;CEF-
can exchange any data required to
SESAR-2018-1 [1], Table
support such common situational
8 – Key Challenges
awareness, be it for drone operations in
areas where established ATC
procedures apply, or in zones outside
established ATC.
Standard communication protocols
shall hence be used where available, [R-2];SESAR Drone
and such standard protocols be Roadmap [11], 3.5,
Standard
[R-4] developed otherwise, in order to section ‘Standards’;CEF-
Protocols
ensure the lowest level of obstruction SESAR-2018-1 [1], Table
for an open VLL airspace use market to 8 – Key Challenges
develop.
17
Any interface and protocol hence must

be openly defined and its definition be [R-2];CEF-SESAR-2018-1
[R-5] Open Interfaces freely accessible in order to ensure the [1], Table 8 – Key
lowest level of obstruction for an open Challenges
VLL airspace use market to develop.
The implementation of a Flight [R-3];CEF-SESAR-2018-1
Information Management System [1], 5.3.4 Overall
[R-6] SWIM
(FIMS) shall be based on an ICAO approach and
SWIM-compliant architecture. methodology
Under no operational circumstance, the
processing of position data may add
significant latency to the overall
detection-to-display latency of position
data. In particular,
1. The processing latency added

by the processing of positional
data shall never exceed 10 per
cent of the maximum value of
the corresponding value
automation system.
[17], tables in the
2. The processing latency and
Executive Summary,
[R-7] Latency delay added by the processing
[16], 3N_C-R8 and
of positional data should not
5N_C-R8
system.
The maximum value for latency and

delay is the minimum of the values
defined by the ATM system
performance requirements by
EUROCONTOL and the FAA; for a 3 NM
minimal separation, this is 2.2 s, for a 5
Table 4: Requirements for the DroneFlightExchange Service

18
3.2.1.1 ICAO SWIM


The DroneFlightExchange service primarily is relevant during the actual operational in-flight stages of
a U-space flight during which the flying device and/or the corresponding ground stations produce the
position data which we convey via the Traffic/Telemetry service.
The DroneFlightExchange service may be seen as a means of correlation between the position
reporting (provided by the Traffic/Telemetry service) on one side and the operation planning (provided
by the OperationPlanInformationExchange service) on the other side.
There are several nodes in U-space which could provide position information to the
DroneFlightExchange service.
(Figure TBD)
Figure 1: U-space nodes related to the DroneFlightExchange service
Operational nodes which may provide data for the DroneFlightExchange service include the following
ones.

Aircraft ?
Ground Station ?
Table 5: Operational Nodes providing the DroneFlightExchange service
Operational nodes which may consume the DroneFlightExchange service include the following ones.
19

Information Display
Legal Recorder
Table 6: Operational Nodes consuming the DroneFlightExchange service

Operational activities supported by the DroneFlightExchange service include the following ones.
Phase Operational Activity Remarks
Pre-flight Set-up (Drone Flight not available yet at this stage)

Plan (Drone Flight not available yet at this stage)
Arm (Drone Flight exchange should start to run here)
In-Flight Depart Drone Flight data available for the flight
Cruise Drone Flight data available for the flight
Arrive Drone Flight data available for the flight
Post-Flight Disarm (Drone Flight exchange likely stops here)
Table 7: Operational Activities supported by the DroneFlightExchange service
20
4 Service Interfaces
Figure 2: DroneFlightExchangeService Interface Definition diagram
Role (from service provider

point of view)
createDroneFlight
updateDroneFlight
pauseDroneFlight
resumeDroneFlight
DroneFlightManagementInterface Provided
finishDroneFlight
setDroneFlightConformanceState
setDroneFlightEmergencyState
setDroneFlightCoorperationState
DroneFlightSubscriptionInterface Provided subscribeForDroneFlights

unSubscribeForDroneFlights
DroneFlightNotificationInterface Required notifyDroneFlight
21
getDroneFlight
DroneFlightRetrievalInterface Provided
getDroneFlightsForGeometry
22

5.1 Overview
The DroneFlight exchange service transfers information about an ongoing drone flight and associated
data. The central part of the data model for this service is the DroneFlight structure, which includes a
summary of the drone flight state information, together with a reference to the related Operation Plan
and optionally a reference to tracking information.
Figure 3: Drone Flight Service Data Model diagram
5.2 The DroneFlight Data Structure

DroneFlight is the central part of the DroneFlightExchange service data model.
Multiplic
ity
Globally
unique
droneFlightId UUID 1 identifier of
this drone
flight.
23
Multiplic
ity
Globally
unique
identifier of
droneFlightVersion UUID 1
this version
of the drone
flight.
The basic life

cycle state of
flightState DroneFlightState 1
the drone
flight.
24
A drone flight is
CONFORMANT
if it has a
reference to an
Operation Plan
that is in
AUTHORIZED
state and if the
drone flight
behaves as
planned, i.e., if
the spatial and
temporal
limitations given
in the OP
volume (and/or
trajectory) are
The respected.
conformanc
e state of Note that a
the drone drone flight is
flight. It still
indicates CONFORMANT,
conformanceState DroneFlightConformanceState 1 whether the even if it is in
drone flight contingency
conforms to mode, as long
the referred, as it follows the
approved contingency
Operation plan provided
Plan. within the
Operation Plan.
A drone flight is
considered
NON_CONFOR
MANT if there is
no reference to
an Operation
Plan, or if the
referred
Operation Plan
is not approved,
or if the drone is
flying outside
the approved
(spatial and/or
temporal) limits.
25
Multiplic
ity
This state is to
be explicitly
declared by the
drone operator.
The Note that a

emergency drone flight may
emergencyDeclaratio DroneFlightEmergencyDeclarat 1
declaration be in
nState ionState
state of the EMERGENCY
drone flight. state while it is
still
CONFORMANT
(e.g., in
contingency
operation).
A
NON_COOPERA
The TIVE
cooperative NON_CONFOR
cooperationState DroneFlightCooperationState 1
ness of the MING drone
drone flight. flight is
considered
rogue!
Indicates
who did the
lastChangedBy String 1 last update
on this
object.
This reference is
The
usually given by
reference to
0..1 providing the
operationPlan Reference to OperationPlan the
operationPlanId
Operation
of the referred
Plan.
Operation Plan.
26
Multiplic
ity
By this
reference, the
DroneFlight is
Optional used to transmit
Reference to Track 0..* references correlation
track
to Track information
Identifiers. between
OperationPlan
and Position
Reporting.
May be realized
Refers to the
by simply adding
historically
the
Reference to DroneFlight previous
previousVersion 0..1 droneFlightVersi
Object version of
on UUID of the
this
previous
DroneFlight.
version.
Table 9: The DroneFlight data structure
5.3 The DroneFlightResponse Data Structure

DroneFlightResponse is used to carry the result of query-operations asking for drone flights.
Depending on the operation result, it may contain zero, one or several drone flights.
droneFlights DroneFlight 0..* Drone flight(s).
< inherited All properties inherited from See common data

> ServiceResponse. types.
Table 10: The DroneFlightResponse data structure
5.4 The OperationPlanState Enumeration

The OperationPlanState enumeration type specifies the possible states of an operation plan.
27

Initial state of the operation plan.
This operation is not yet APPROVED. It

may be awaiting information from the
PROPOSED operator, it may be in conflict with
another APPROVED or ACTIVATED
operation and undergoing a negotiation
process, or for some other reason it is
not yet able to be declared APPROVED.
Authority has given permission to
PERMITTED proceed (Certification Processes, SORA,
...)
Authorization of an OP may include the

This operation has been deemed approval by multiple stakeholders. ATM
approved by the supporting USS. This may be one such stakeholder.
AUTHORIZED implies that the operation meets the
requirements for operating in the In some cases an OP may be
airspace based on the type of operation AUTHORIZED without the approval of
submitted. ATM (in cases where no ATM airspace is
involved.
Operation plan has been activated. Drone
ACTIVATED
is cleared to take off.
If the UAS and the crew will fly again, it

would need to be as a new operation. A
This operation is closed. It is not airborne USS may announce the closure of any
CLOSED
and will not become airborne again. operation, but is not required to
announce unless the operation was
ROGUE or NONCONFORMING.
Table 11: The OperationPlanState enumeration
5.5 The EnumDroneFlightState Enumeration

The EnumDroneFlightState enumeration type specifies the possible life cycle states of a drone flight.
The drone has potentially taken off and is This is the initial state of a drone flight, as
ACTIVE performing its mission according to the the drone flight is created with its
operation plan. activation.
28

The drone flight was activated but is currently
INACTIVE
pausing or has not taken off yet.
FINISHED The drone flight is completed.
Table 12: The EnumDroneFlightState enumeration
5.6 The EnumDroneFlightConformanceState Enumeration

The EnumDroneFlightConformanceState enumeration type specifies the possible conformance states
of a drone flight.
The conformance state indicates whether the drone flight conforms to an approved Operation Plan..

The drone flight conforms to the
Note that a drone flight is still
referred Operation Plan.
CONFORMANT, even if it is in
contingency mode, as long as it
CONFORMANT This means, the drone plan is
follows the contingency plan
currently in line with the planned 4D-
provided within the Operation
constraints described by the
Plan.
Operation Plan.
The drone flight is currently not
conformant to the referred
Operation Plan, or there is no
Operation Plan known for the drone
flight.
NON_CONFORMANT
The Non-Conformance may be a
violation of spatial or temporal
constraints specified in the Operation
Plans Operation Volume or Trajectory
or Contingency Plan. Overdue is an
example of Non-Conformant state.
Table 13: The EnumDroneFlightConformanceState enumeration
5.7 The EnumDroneFlightEmergencyState Enumeration

The EnumDroneFlightEmergencyState enumeration type specifies the possible kinds of
contingency/emergency states that can be declared by the drone operator.

NOMINAL The drone flight is in nominal conditions.
29

CONTINGENCY The drone flight is in contingency conditions.
EMERGENCY The drone flight is in emergency conditions.
Table 14: The EnumDroneFlightEmergencyState enumeration
5.8 The EnumDroneFlightCooperationState Enumeration

The EnumDroneFlightCooperationState enumeration type specifies whether the drone flight is co-
operative or not.

The drone flight is If only a flight declaration is possible (without
CO_OPERATIVE behaving co- telemetry transmission), the CO_OPERATIVE flight
operatively. may be a flight reported (submited) to the system.
The drone flight is A NON_COOPERATIVE NON_CONFORMING drone
NON_COOPERATIVE not behaving co-
flight is considered rogue!
operatively.
Table 15: The EnumDroneFlightCooperationState enumeration
5.9 Common Data Structures Used in UTM Service Specifications
5.9.1 NotificationEndpoint Data Structure

30
5.9.2 ServiceResponse Data Structure

Indicates the result of the request to the

result OperationResult 1
service
0..1 Optional additional information to be

rejectReason String
provided in case of negative result
5.9.3 OperationResult Enumeration


5.10 Common Geometry Data Structures Used in UTM Service

Specifications
31

1 A geometric description of a Should be a 2-dimensional

area Geometry
Coordinate reference system
used (WGS-84, EPSG:4979)

Collection of the
coordinates Double 2..* coordinates, describing the
geometry.
32
Type of geometry being Examples: Point,

geometryType GeometryType 1 described by the Polygon, Polyhedron,
coordinates. etc.
The respective values should be measured or converted using CARS system.

ABOVE_MSL
ABOVE_ELLIPSOID Altitude above the WGS-84 ellipsoid; value delivered by GNSS.

World Mercator
Coordinate Euro-centric view of world excluding polar

EPSG3395_WGS84 System: Cartesian CS.
areas.
Axes: easting, northing (E,

N). Orientations: east, north.
UoM: metre.
33
OpenStreetMap, Bing,
ArcGIS, ESRI
Uses spherical development of ellipsoidal
Geodetic CRS: WGS 84; coordinates. Relative to WGS 84 / World
Mercator (CRS code 3395) errors of 0.7 percent
EPSG3857_WGS84
Coordinate in scale and differences in northing of up to
System: Cartesian CS. 43km in the map (equivalent to 21km on the
ground) may arise.
UoM: metre.
Coordinate
System: Ellipsoidal 2D CS. Uses Historic World Geodetic System 1972.
EPSG4322_WGS72
UoM: degree.

Horizontal component of 3D system. Used by
Coordinate
EPSG4326_WGS84 the GPS satellite navigation system and for
System: Ellipsoidal 2D CS.
NATO military geodetic surveying.
UoM: degree.
Coordinate
System: Ellipsoidal 2D CS. Uses Historic World Geodetic System 1966.
EPSG4760_WGS66
UoM: degree.
34
Coordinate
System: Ellipsoidal 3D CS.
ellipsoidal height.
Orientations: north, east, up.


POINT Single point.
POLYGON Polygon.
...
35

Service Interface.
6.1 Service Interface DroneFlightRetreivalInterface

The service provider offers this interface to allow consumers to retrieve/query drone flight data.
6.1.1 Operation getDroneFlight

A consumer calls this operation to explicitly request a drone flight by submitting the known id.

Parameter
Name
id Input UUID Identifier of a drone flight.
Query response, including the drone flight data,
response Return DroneFlightResponse
if the request was successful.
Table 24: Payload description of getDroneFlight operation
6.1.2 Operation getDroneFlightsForGeometry

A consumer calls this operation to explicitly request drone flight data for a certain geographical area.

Parameter
Name
areaOfInterest Input Geometry Geographical area of interest.
Query response, including the drone flight data,
if the request was successful.
response Return DroneFlightResponse
The DroneFlightResponse may contain a list of
DroneFlights: all current drone flights for the
area of interest.
Table 25: Payload description of getDroneFlightForGeometry operation
36
6.2 Service Interface DroneFlightSubscriptionInterface

The service provider offers this interface to allow consumers to subscribe/unsubscribe for drone flight
data.
6.2.1 Operation subscribeForDroneFlights

A consumer calls this operation to subscribe to receive drone flight data.

Parameter
Name
DroneFlight data.
Table 26: Payload description of subscribeForDroneFlights operation
6.2.2 Operation unsubscribeForDroneFlights

A consumer calls this operation at the provider to unsubscribe from drone flight data.

Parameter
Name
Which endpoint shall not be notified (anymore)
in case of new DroneFlights.
Table 27: Payload description of unsubscribeForDroneFlights operation
6.3 Service Interface DroneFlightNotificationInterface

Once and while subscribed, consumer receives drone flight data via this interface.
6.3.1 Operation notifyDroneFlight

The service provider uses this logical operation (implemented by the consumer) to publish drone flight
data.
37

Parameter
Name
A drone flight matching the filter criteria provided in the
droneFlight Input DroneFlight
subscription
Table 28: Payload description of notifyDroneFlight operation
6.4 Service Interface DroneFlightManagementInterface

The service provider offers this interface to allow consumers to administrate / manipulate drone
flights.
6.4.1 Operation createDroneFlight

The service consumer calls this operation to create a drone flight data object.

Parameter
Name
opId Input UUID Optional reference to an Operation Plan.
indicates whether the creation was successful or
response Return DroneFlightResponse not. In case of success it also contains the newly
created DroneFlight.
Table 29: Payload description of createDroneFlight operation
6.4.2 Operation updateDroneFlight

The service consumer calls this operation to modify a drone flight data object.

Parameter
Name
droneFlight Input DroneFlight An updated version of a drone flight object.
indicates whether the operation was successful or
response Return ServiceResponse
not.
Table 30: Payload description of updateDroneFlight operation
38
6.4.3 Operation pauseDroneFlight

The service consumer calls this operation to indicate that a drone flight is paused. This results in the
drone flight state set to "PAUSED".

Parameter
Name
id Input UUID Identifier of a drone flight object.
not.
Table 31: Payload description of pauseDroneFlight operation
6.4.4 Operation resumeDroneFlight

The service consumer calls this operation to indicate that a drone flight is re-activated. This results in
the drone flight state set to "ACTIVE".

Parameter
Name
not.
Table 32: Payload description of resumeDroneFlight operation
6.4.5 Operation finishDroneFlight

The service consumer calls this operation to terminate a drone flight. This results in the drone flight
state set to "FINISHED".

Parameter
Name
not.
39
Table 33: Payload description of finishDroneFlight operation
6.4.6 Operation setDroneFlightConformanceState

The service consumer calls this operation to update the conformance state of a drone flight data
object.

Parameter
Name
The new conformance state of the
state Input EnumDroneFlightConformanceState
drone flight object.
indicates whether the operation

was successful or not.
Table 34: Payload description of setDroneFlightConformanceState operation
6.4.7 Operation setDroneFlightEmergencyState

The service consumer calls this operation to update the emergency state of a drone flight data object.

Parameter
Name
The new emergency state of the
state Input EnumDroneFlightEmergencyState
indicates whether the operation was

successful or not.
Table 35: Payload description of setDroneFlightEmergencyState operation
6.4.8 Operation setDroneFlightCooperationState

The service consumer calls this operation to update the cooperation state of a drone flight data object.
40

Parameter
Name
The new cooperationstate of the
state Input EnumDroneFlightCooperationState
indicates whether the operation

was successful or not.
Table 36: Payload description of setDroneFlightCooperationState operation
41

Figure 6: DroneFlightExchange service example operation sequence diagram
Note:
additional operations (e.g. from OperationPlanExchange service), not only DroneFlightExchange
service operations.
The figure above provides an example scenario for the DroneFlightExchange service. The scenario
assumes an Operation Plan Processing system providing the OperationPlanExchange service interfaces
42
(OperationPlanSubscriptionInterface, OperationPlanManagementInterface). Furthermore, a Drone

Flight Processing System provides the DroneFlightExchange service interfaces
(DroneFlightSubscriptionInterface, DroneFlightManagementInterface). In addition, the scenario
includes a Drone Operator (in the role of a consumer of both, the OperationPlanExchange service as
well as the DroneFlightExchange service) and a second consumer of DroneFlightExchange service.
 The scenario starts with the service consumers subscribing for operation plans and drone
flights:
o Drone Operator subscribes at OperationPlanExchange service as well as
DroneFlightExchange service.
o Second consumer subscribes at DroneFlightExchange service.
 Drone Operator submits a tentative Operation Plan by using the
OperationPlanManagementInterface.
 Drone Operator requests authorization of the OP by using the
 Drone Operator requests take-off clearance for the Operation Plan by using the
o At this point in time, the Drone Flight object shall be created.
o The DroneFlightManagmentInterface is used to create the Drone Flight.
o In this example, the Drone Operator is responsible to create the Drone Flight.
o Creation of the Drone Flight leads to the publication of the Drone Flight to
subscribed consumers.
 Drone Operator may request a pause of the flight by using the
DroneFlightManagmentInterface .
o This leads to an update of the Drone Flight State being published to subscribed
consumers.
 Drone Operator may request to resume the paused flight by using the
DroneFlightManagmentInterface .
o This leads to an update of the Drone Flight State being published to subscribed
consumers.
 Drone flight processing system may be listening to conformance monitoring publications.
o When receiving a non-conformance report, the drone flight processing system shall
update the conformance state of the drone flight
o The updated conformance state leads to a drone flight publication to subscribed
consumers.
 Drone Operator declares the end of flight by using the DroneFlightManagmentInterface .
o This leads to an update of the Drone Flight State, which is again published to
subscribed consumers.
7.2 Drone Flight State Machine
43
Figure 7: Drone flight states - state transition diagram in comparison with Operation Plan state
machine
The figure above illustrates the state transitions of Drone Flights graphically aligned with an Operation
Plan state diagram. Note that in a nominal life cycle, a Drone Flight usually gets created when the
Operation Plan is going to be activated (i.e., the OP is already in state TAKEOFF_GRANTED).
However, there are also cases where a Drone Flight is activated without the existence of an Operation
Plan. Imagine the case where an airborne drone flight is detected (e.g., by observation of surveillance
tracks), but cannot be correlated to any existing OP. In such a case, a "NON_CONFORMANT" Drone
Flight shall be published, indicating that there is an ongoing flight without known Operation Plan.
44
8 References
NOTE: The list of references provided hereafter is for guidance. Before the documents are delivered
to the SJU, please make sure that you are listing the latest applicable version of the relevant references
as in the Programme Library.

CFP Reference CEF-SESAR-2018-1, “Finnish-Estonian "Gulf of Finland" Very
[1] n/a
Large U-Space Demonstration”
Advanced
ICAO Doc 10039, Manual on System Wide Information Management (SWIM)
[2] Edition
Concept
(unedited)
SESAR 2020 GOF USPACE FIMS Design and Architecture, Appendix A Service
[3] 00.05.00 Description Templates, document SESAR 2020 GOF USPACE Service
Documentation Guidelines
Ed. EUROCONTROL Concept of Operations for U-space (CORUS), D6.2, Grant Ref.
[4] 00.02.RC1, 1 763551, Call Ref. 2016 SESAR 2020 RPAS Exploratory Research Call (H2020 –
March 2019 SESAR -2016-1), Release Candidate 1
Global UTM Association (GUTMA) Flight Logging Protocol,
[5] n/a https://github.com/gutma-org/flight-logging-
[6] n/a Protocol, https://github.com/hrishiballal/airtraffic-data-protocol-
development
Federal Aviation Administration NextGEN Concept of Operations,
Foundational Principles, Roles and Responsibilities, Use Cases and
[7] V1.0
Operational Threads, Unmanned Aircraft System (UAS), Traffic Management
(UTM)
Federal Office of Civil Aviation (FOCA), Swiss U-Space ConOps, U-Space
[8] 1.0 Program Management, 31.10.2018, FOCA muo / 042.2-
00002/00001/00005/00021/00003
[9] 5th Ed. - 2016 ICAO Doc. 9750-AN/963, Global Air Navigation Plan (GANP) 2016-2030
Intel Corporation, Open Drone ID Message Specification, Draft Specification,
[10] 0.61.1
November 13, 2018
SESAR, European ATM Master Plan: Roadmap for the safe integration of
[11] n/a
drones into all classes of airspace
SESAR, eATM PORTAL, European ATM Master Plan,
[12] n/a
45

Efficient, safe and sustainable traffic at sea (EfficienSea2), a Horizon 2020
Project, Grant Agreement No 636329
[15] n/a
https://www.iala-aism.org/product/g1128-specification-e-navigation-
technical-services
EUROCONTROL-SPEC-0147,
[16] Ed. 1.0
https://www.eurocontrol.int/publications/eurocontrol-specification-atm-
surveillance-system-performance
Federal Aviation Administration, Project Report ATC-323, Required
1 November
[17] Surveillance Performance Accuracy to Support 3-Mile and 5-Mile Separation
2006
in the National Airspace System
Operation Plan Information Exchange Service Specification
Traffic/Telemetry Information Exchange Service Specification
46
D2.4 Appendix J Weather

Service Specification
Deliverable ID: D2.4-J
Grant: 101017689
Topic:
Air Mobility
Edition: 01.00.00
D2.4 APPENDIX J WEATHER SERVICE SPECIFICATION

Darshan Sathiyanarayanan / Vaisala WP2 03.1.2022
Remy Parmentier / Vaisala WP2 3.1.2022
Tapio Haarlaa/ Vaisala WP2 3.1.2022

Pawel Korzec / DroneRadar WP2 2.11.2022
Gokul Srinivasan / Robots Expert WP2 2.11.2022
Tanel Järvet / CAFA Tech WP2 2.11.2022
Thomas Lutz / Frequentis WP2 3.11.2022
2


Document History
00.00.02 24.08.2021 draft WP2 Partners For D2.2
00.00.03 03.01.2022 draft WP2 Partners Enhance and update for
D2.4
Copyright Statement
3
GOF2.0
Abstract
This specification introduces a Supplementary data service which ensures appropriate weather data is
accessible in a reliable manner to all stakeholders within the U-space environment.
In accordance with ICAO SWIM, this document describes one of these supplementary data Services,
the Weather data service in a logical, technology-independent manner.
4
Table of Contents
Abstract ................................................................................................................................... 4
1. Introduction ............................................................................................................. 10
1.1. Overview..................................................................................................................... 10
1.2. Scope .......................................................................................................................... 11
1.3. Intended readership .................................................................................................... 12
1.4. Issue context ............................................................................................................... 12
1.4.1. General principles ....................................................................................................................... 13
2. Operational context ................................................................................................. 14

2.1. Overview of operational requirements......................................................................... 14
2.2. Operational nodes ....................................................................................................... 16
2.3. Operational Activities .................................................................................................. 16
3. Service Interface overview ....................................................................................... 18
4. Service Data Model .................................................................................................. 20
4.1. Overview..................................................................................................................... 20
4.2. The WeatherData Data Structure ................................................................................. 21
4.3. The HistoricData Data Structure ................................................................................... 23
4.4. The ForecastData Data Structure.................................................................................. 24
4.5. The WeatherParameter Data StructureS ...................................................................... 24
4.6. The StructuredWeatherData Data Structure ................................................................. 26
4.7. The SingleVoxelData Data Structure ............................................................................. 27
4.8. The AllData Data Structure .......................................................................................... 28
4.1. The DiscretizedDomain Data Structure ......................................................................... 30
4.2. The AlertDetail Data Structure ..................................................................................... 31
4.3. The AlertVoxel Data Structure...................................................................................... 33
4.4. The Alerts Data Structure ............................................................................................. 33
4.5. The AlertData Data Structure ....................................................................................... 34
4.6. Common data structures used in U-space specifications ............................................... 35
4.6.1. ServiceResponse Data Structure ................................................................................................. 35
5
5. Service Interface specifications ................................................................................. 36

5.1. Service Interface .......................................................................................................... 36
5.2. SupplementaryWeatherDataretrievalInterface ............................................................. 36
5.2.1. Operation queryWeatherForecast .............................................................................................. 36
5.2.2. Operation queryCurrentWeather ............................................................................................... 37
5.2.3. Operation queryHistoricWeather ............................................................................................... 37
5.3. Service Interface SupplementaryWeatherDataSubscriptionInterface ............................ 39
5.3.1. Operation subscribeRegularWeatherData .................................................................................. 39
5.3.2. Operation unsubscribeRegularWeatherData ............................................................................. 39
5.3.3. Operation subscribeWeatherAlertData ...................................................................................... 40
5.3.4. Operation unsubscribeWeatherAlertData .................................................................................. 40
5.4. Service Interface SupplementaryWeatherDataPublicationInterface .............................. 41
5.4.1. Operation pushRegularWeatherData ......................................................................................... 41
5.4.2. Operation pushWeatherAlertData ............................................................................................. 41
6. Service Dynamic Behavior ........................................................................................ 43

7. Definitions of Acronyms and Terms .......................................................................... 45
7.1.1. List of Acronyms.......................................................................................................................... 45
8. References ............................................................................................................... 47
6
List of Tables
Table 1 : Operational Nodes .................................................................................................................. 16
Table 2: Operational Activities supported by the Supplementary Weather Data Service.................... 17
Table 4: WeatherData Data Structure ................................................................................................... 23
Table 5: HistoricData Data Structure..................................................................................................... 24
Table 6: ForecastData Data Structure ................................................................................................... 24
Table 7: WeatherParameter Data Structure ......................................................................................... 26
Table 8: StructuredWeatherData Data Structure ................................................................................. 27
Table 9: SingleVoxelData Data Structure .............................................................................................. 28
Table 10: AllData Data Structure ........................................................................................................... 30
Table 11: DiscretizedDomain Data Structure ........................................................................................ 31
Table 12: AlertDetail Data Structure ..................................................................................................... 32
Table 13: AlertVoxel Data Structure...................................................................................................... 33
Table 14: Alerts Data Structure ............................................................................................................. 33
Table 15: AlertData Data Structure ....................................................................................................... 34
Table 17: Operation queryWeatherForecast parameters ..................................................................... 37
Table 18: Operation queryCurrentWeather parameters ...................................................................... 37
Table 19: Operation queryHistoricWeather parameters ...................................................................... 38
Table 20: Operation subscribeRegularWeatherData parameters......................................................... 39
Table 21: Operation unsubscribeRegularWeatherData parameters .................................................... 40
Table 22: Operation subscribeWeatherAlertData parameters ............................................................. 40
Table 23: Operation pushRegularWeatherData parameters ................................................................ 41
7
Table 24: Operation pushWeatherAlertData parameters .................................................................... 42
8
List of Figures
Figure 1: Operational Phases diagram .................................................................................................. 15
Figure 2: Service Interface Overview..................................................................................................... 18
Figure 3: Data model Overview ............................................................................................................ 21
Figure 4: Common Data Types Used in U-space Service Specifications ................................................ 35
Figure 5: Service Dynamic Behavior ...................................................................................................... 43
9
1. Introduction
1.1. Overview
In order to enable safe and reliable operations at scale, drone operators need an accurate picture of
the weather conditions across the airspace before the flight for operations planning, to make a go-no
go decision at take-off, all along the flight duration to manage unexpected hazardous weather
conditions and post-flight, for a posteriori analysis of flight conditions [1].
Supplementary Weather Data Service1 [SWDS] is defined and implemented to supply accurate
hyperlocal weather data from observations, models and forecasts to SWDS subscribers such as drone
operators, USSP, ANSPs, Insurance companies and other interested parties.
SWDS aims at supporting a drone operator’s weather-related risk management and flight optimization.
SWDS will be used to make CARS height/altitude transformations, wherever conversion between
barometric and GNSS based systems will be required.
In particular, for safety it is necessary to identify and locate areas where weather conditions are not
compatible with a given UAV flight envelop and/or do not comply with predefined airspace regulations.
Presently, UAV pilots are checking various sources for regional and local weather information close to
the flights’ locations. Weather information sources are for example:
- Weather forecasts provided by the National Weather Service or other Public-domain

weather service such as Windy, Skysight, etc.
- Nearby meteorological stations (airports…)
- METAR, TAF
- Hand-held weather station deployed that the take-off location
Such weather data sources poorly represent actual weather conditions that the drone will encounter
all along its journey and the responsibility remains on the pilot to make the decision to take-off or not
based upon his experience. This is exacerbated for flights inside the urban environment at or below
house-roof height.
1
Third party information provided by a Supplementary Data Service Providers (SDSP) increases knowledge of the
operational flight area for a UAV with data and analysis delivered using web services.
10
Weather information can arise from multiple sources, it is currently up to the UAV operator /
automatic UAV systems to find the weather information from different sources, synthesize and make
the call on which information to trust and fly.
Thus, in this work, it is intended to provide a data structure and exchange framework to efficiently
synthesize weather data from multiple sources and make them most efficiently available to the
relevant entities.
This includes:
- Construct an adapted data structure model to provide weather data from different weather
sources in a more accessible structure
- Establish a framework for the exchange protocols adapted to all relevant weather data
types (Wind vector, Turbulence, Shear, Visibility, Temperature, etc)
1.2. Scope
The Supplementary Weather Data Service described in this document provides a general mechanism
between the various stakeholders, interfaces and data models that enable and allow the automated
data exchange and utilization between the respective parties.
The scope includes the following aspects:
 Operational Context
 Service Interfaces
 Service Data Model
There are a number of goals defined that this specification document aims to achieve:
1. A goal is to define the nature of the exchange protocol to communicate between a traffic
management system (or drone operator, USSP or equivalent) and a weather information
provider.
2. A goal is to identify architectures that will be amenable to expedient implementation by a

variety of weather information providers, given that weather information providers have
various weather data sources and numerical modelling capabilities.
3. A goal is to identify scalable architectures that would support a variety of business models
and data sharing models in a technology independent way (i.e. limiting and avoiding
exchange of proprietary and/or sensitive data) but enabling proprietary implementations of
a segregated instance of the weather data service that could make use of proprietary
weather information.
11
The overall objective is to provide a minimum set of descriptions to standardize the way data between
Weather Information providers and the UTM ecosystem can be exchanged. The Weather Data Service
does not limit any entity, by any means, to deploy or implement other data exchange in addition to
the defined service definitions.
1.3. Intended readership

This document is intended to be read by all members of the GOF2.0 USPACE project, specifically,
technical Point of Contacts (service architects, system engineers and developers) of members involved.
In general, the following entities are intended as readership:
• Air Navigation Service Providers (ANSPs)
• Civil Aviation Authorities (CAAs)
• Administrative Units
• Supplemental Data or Data Service Providers
• Drone Manufacturers
• Drone Operators
• General Aviation Operators
• Authorities
• U-space Service Provides
• U-space Infrastructure Providers
1.4. Issue context

The primary issue addressed in this document is to improve the interaction between weather data
sources/service providers and UAV stakeholders to facilitate the ingestion of high-quality hyperlocal
weather data.
Weather data are produced in multiple formats and sizes. Depending on the weather parameter of
interest and the measurement instrument employed, the final weather data files can have varied data
types and different update frequencies. This makes it difficult for non-meteorologists to exploit
multiple varied sources of high-quality weather data.
12
Thus, it is important to explore how the different weather data types and weather service interfaces
can be reworked for the benefit of UAV stakeholders.
1.4.1. General principles
A key principle of the U-space architecture is applying a service-oriented architecture approach, where
open, interoperable and standard based interfaces are offered based on SWIM principles2.
2
Note that by SWIM principles the general concept including not only AIXM, FIXM, WIXM via SOAP are meant,
but also web services / rest / messaging (JMS, AMQ) as considered in the SWIM Yellow profile [4].
13
2. Operational context
2.1. Overview of operational requirements

Acquiring, interpreting, and making operational decisions based on weather information is essential
to safe & efficient UAV operations.
Different stages of a UAV mission will require the appropriate weather information.
o Flight preparation: Weather Forecast
o Pre-flight: Weather Forecast, Current Weather and critical Weather Alerts
o In-flight: Current Weather and critical Weather Alerts
o Post Flight: Historic weather data
The nature of weather data and the weather service interface required will vary depending on the UAV
mission phase.
14
Figure 1: Operational Phases diagram
To accommodate for the different weather data and UAV operator interactions at the different UAV
mission phases, the Supplementary Weather data service should provide the following capabilities:
 To push weather data
o A regular update of current weather data in a selected domain at a requested

frequency
o An Irregular update of the current alert state in a selected domain of interest
 To allow for weather data query with input specifications from the user
o The Historic weather data at the requested time periods
o The Forecast weather data at the requested time horizons
The operational nature of the supplementary weather service data provider that meets these
requirements is detailed in the following two chapters in this section.
15
2.2. Operational nodes

Operational nodes which may consume the Weather Data service include the following ones.
U-space service provider
ANSP
UAV operator
Table 1 : Operational Nodes
2.3. Operational Activities

Operational activities supported by the Weather Data service include the following ones.
Operational
Phase Remarks
Activity
Flight The consumer will be able to query the weather service for a weather
Plan
preparation forecast at the required time scale.
The consumer will be able to query the weather service for a weather
forecast at the required time scale.
Pre-flight Plan The Consumer will be able to get a real-time high-resolution weather
data update from the weather service interface at mission critical
locations (along the whole Operation Plan including alternative
landing sites).
The Consumer will be able to get a real-time high-resolution weather

In-Flight Take-Off data update from the weather service interface at mission critical
locations (Take off sites).
16
The Consumer will be able to get a real time update of the Weather
Cruise at a requested frequency within a domain covering the flight path,
from the weather service.
The Consumer will be able to get a real-time high-resolution weather

Land/Arrive data update from the weather service interface at mission critical
locations (Landing sites).
The consumer will be able to query the weather service for historic
Post-Flight Report
weather data at given locations.
Table 2: Operational Activities supported by the Supplementary Weather Data Service
17
3. Service Interface overview

The weather data interface will accommodate a data subscription/publication interface and a query-
based interface. The former is meant to transfer regular data and weather alerts. The latter serves to
transfer weather data that need to be queried at each instance with user specific input parameters
(ex: weather forecasts).
Figure 2: Service Interface Overview
18
Role (from
service
ServiceInterface provider ServiceOperation
point of
view)
queryWeatherForecast
SupplementaryWeatherDataRetrievalInterface Provided queryCurrentWeather
queryHistoricWeather
subscribeRegularWeatherData
unsubscribeRegularWeatherData
SupplementaryWeatherDataSubscriptionInterface Provided
subscribeWeatherAlertData
unsubscribeWeatherAlertData
pushRegularWeatherData
SupplementaryWeatherDataPublicationInterface Used
pushWeatherAlertData
19
4. Service Data Model

4.1. Overview
Weather data comprises of the information pertaining to multiple different parameters of the
environment. For example, wind, temperature, visibility, lightning, fog, rain, Humidity, Icing etc.
However, weather data from different sources can vary in terms of spatial and temporal
characteristics. Thus, it becomes important to find a way to harmonize at least the spatial indexation
of this data, to make it easier to ingest (and appropriately average or regroup weather data points in
time).
The wind for example can be measured either by an anemometer -at one location at high frequency-
or through a Weather radar – at multiple locations at a lower frequency-. On one hand the high
frequency data could be more useful to optimize take-off and landing at the vertiport. And on the
other hand, the volumetric measurement of the wind field can be more useful to plan the flight
trajectory itself. Thus, a common data structure able to accommodate weather data that is spatially
and temporally distributed must be used.
Practically, each data file could be reformatted into a voxel grid format. Thus, each measurement, be
it from any instrument at any position can be allocated to a certain voxel in space.
The Weather data will be allocated to a 3D cartesian grid.
This grid will divide the space into cuboids, with a given horizontal dimension and a given vertical
dimension. (A parameter that can be varied by the consumer).
Each weather data file received from a different weather source will have to be first formatted to
incorporate this spatial referencing (allocated to the corresponding cuboid in which it is placed).
20
Figure 3: Data model Overview
4.2. The WeatherData Data Structure
21
A time stamp
corresponding to the time
The time period
period of the provided
used here is
OverallTimestamp DateTime 1 data. The TimeStamp
given by the
contains the value of the
TimeResoution.
time at the end of each
time period/bin.
The minimum
time resolution
is inversely
linked to the
The time between two domain size. (to
TimeResolution Float 1 consecutive regular avoid flooding
weather updates. the receiver
with high
frequency
updates of large
files ).
A sequency of strings
containing a summary of
AlertSummary String 1..* the different alerts for
each weather parameter
chosen.
A Weather parameter
Further
containing voxel
variables can be
structured information on
added to
the different variables
Wind WeatherParameter 0..1 expand
pertaining to Wind.
information
(HorizontalWindSped,
provided in the
HorizontalWindDirection,
wind.
Turbulence)
22
A Weather parameter
Further
containing voxel
variables can be
structured information on
added to
the different variables
Temperature WeatherParameter 0..1 expand
pertaining to
information
Temperature.
provided in the
(LocalTemperature,
temperature.
TemperatureGradient)
A Weather parameter Further

containing voxel variables can be
structured information on added to
Visibility WeatherParameter 0..1 the different variables expand
pertaining to Visibility. information
(VisibilityType, provided in the
VisibilityDistance) visibility.
Table 4: WeatherData Data Structure
4.3. The HistoricData Data Structure

A time stamp
corresponding to the
TimeStart DateTime 1 start of the historic
weather data
requested.
The minimum time resolution

A time stamp
is inversely linked to the
domain size. (to not flood too
TimeEnd DateTime 1 end of the historic
the bandwidth with high
weather data
frequency updates of large
requested.
files ).
23
Each of the WeatherData

Multiple WeatherData
contains all information on the
WeatherData WeatherData 1..* corresponding each to
state of the weather for a
a time period.
given time period.
Table 5: HistoricData Data Structure
4.4. The ForecastData Data Structure

A time stamp
TimeStart DateTime 1 start of the forecast
weather data
requested.
The minimum time resolution

A time stamp
is inversely linked to the
domain size. (to not flood too
TimeEnd DateTime 1 end of the forecast
the bandwidth with high
weather data
frequency updates of large
requested.
files ).
Multiple Each of the WeatherData

WeatherdData contains all information on the
WeatherData WeatherData 1..*
corresponding each to state of the weather for a
a time period. given time period.
Table 6: ForecastData Data Structure
4.5. The WeatherParameter Data StructureS

Multiplici
ty
24
A description of the It should describe the

group weather group weather
Description String 1 parameter: ex: Wind, parameter and not
Temperature, the sub weather
Visibility, etc parameter.
The The
HorizontalWindSpee HorizontalWindSpee
StructuredWeather
HWS 0..1 d provided in a voxel ed is provided in the
Data
structured format for Wind WeatherData
a given time period. structure.
The
The
HorizontalWindDirec
HorizontalWindDirec
StructuredWeather tion provided in a
HWD 0..1 tion is provided in the
Data voxel structured
Wind WeatherData
format for a given
structure.
time period.
The Turbulence The Turbulence is

StructuredWeather provided in a voxel provided in the Wind
Turbulence 0..1
Data structured format for WeatherData
a given time period. structure.
The
The
LocalTemperature is
LocalTepmerature
StructuredWeather provided in the
LocalTemperature 0..1 provided in a voxel
Data Temperature
structured format for
WeatherData
a given time period.
structure.
The
The
TemperatureGradien
TemperatureGradien
TemperatureGradi StructuredWeather t is provided in the
0..1 t provided in a voxel
ent Data Temperature
structured format for
WeatherData
structure.
25
The VisibilityType is
The VisibilityType
provided in the
StructuredWeather provided in a voxel
VisibilityType 0..1 Visibility
Data structured format for
WeatherData
structure.
The VisibilityDistance
The VisibilityDistance
is provided in the
StructuredWeather provided in a voxel
VisibilityDistance 0..1 Visibility
Data structured format for
WeatherData
structure.
Table 7: WeatherParameter Data Structure
4.6. The StructuredWeatherData Data Structure

It should describe the

A description of sub weather parameter
the weather and not simply the
parameter is weather group. For
ParameterDescription String 1
provided. This will example, it should
include the units describe the
used. Turbulence and not
simply the Wind.
A sequence of
strings listing the
different weather
SourceList String 1..* data sources used The list is unique.
for the given
weather
parameter.
26
The 3D array
A 3D array with indexation should
each data point correspond to the
providing all indexation used for the
weather domain discretization.
SingleVoxelData SingleVoxelData 1..*
information within This allows to find the
a voxel in the position of each voxel
SingleVoxelData using the
structure. DiscretisedDomain
variable.
Table 8: StructuredWeatherData Data Structure
4.7. The SingleVoxelData Data Structure

The AvgData in certain cases

Provides the averaged can also be replaced by the
value of a given weather most representative value of
AvgData float 1 parameter within a voxel a weather parameter within
during the given time the given voxel. This also
period. allows for quality filters to be
applied during the averaging.
Provides the
STD float 1 StandardDeviation of the
averaged data.
This allows for transparency

Provides Details on the in the filtering performed.
StatisticDetail string 0..1 averaging and Standard This information can be
Deviation computation. opted out to improve file
size.
The number of available

DataCount int 1
data points within a voxel.
27
The VoxelAlertState
shows state 1 if at least
VoxelAlertState boolean 1 one alert is present within
the given voxel. And 0
otherwise.
A list of data sources used

Source string [1..*] This list is unique.
within a given voxel.
This data can be opted out,

to keep file sizes
manageable. This data is
useful for certain given
All data points within a locations where it is
voxel (non-averaged at necessary to have the raw
AllData AllData [0..1]
least in space) are weather data, with least
provided. processing.
This data can be opted out
through a parameter
provided in the subscription
operation.
Detailed Alert information

within a voxel during the Each individual Alert will be
AlertDetail AlertData [0..*] given time period is held in a different AlertDetial
provided in the variable.
AlertDataStructure.
Table 9: SingleVoxelData Data Structure
4.8. The AllData Data Structure

28
The indexation is common

An array of strings with the Data variable
providing the source of within this data structure.
DataSource String [1..*]
the corresponding Each index along the array
individual data point. corresponds to an
individual measurement.

with the Data variable
An array of float providing within this data structure.
Data Float [1..*]
the raw data information. Each index along the array
corresponds to an
This variable may be

removed depending on
An array of strings the weather parameter
providing meta data for used.
the corresponding
MetaData String [0..*] individual data point. The indexation is common
(This could be instrument with the Data variable
specific measurement within this data structure.
points) Each index along the array
corresponds to an

An array of DateTime with the Data variable
providing the individual within this data structure.
TimeStampPrecise DateTime [1..*]
data TimeStamp Each index along the array
information. corresponds to an

An array of Float with the Data variable
LatitudePrecise Float [1..*]
data precise latitude Each index along the array
position information. corresponds to an
29

LongitudePrecise Float [1..*]
data precise longitude Each index along the array

AltitudePrecise Float [1..*]
data precise Altitude Each index along the array
Table 10: AllData Data Structure
4.1. The DiscretizedDomain Data Structure

The Domain limits max size is

The bounds of the domain for
linked to the space resolution
DomainLimits Float 1 the weather data to be
chooses. (to keep the size of
provided in.
each data file manageable)
The X, Y and Z resolution

corresponding to the size of
SpaceResolution Float 3 each voxel within the
discretised domain. Unit in
Meters.
A 3D array containing the

Xaxis position of the centre of The Xaxis is centred within
Xaxis Float 1..*
each voxel. Unit used in the chosen domain.
meters.
30

The Yaxis is centred within
Yaxis Float 1..* Yaxis position of the centre of
the chosen domain.
each voxel. Unit in meters.

The Zaxis is centred within
Zaxis Float 1..* Zaxis position of the centre of
the chosen domain.
each voxel. Unit in meters.

The coordinate system used
Latitude Float 1..* Latitude position of the
is WGS84.
centre of each voxel.

The coordinate system used
Longitude Float 1..* Longitude position of the
is WGS84.
centre of each voxel.
A 3D array containing the The coordinate system used

Altitude Float 1..* Altitude position of the centre is WGS84. And altitude is
of each voxel. Unit in meters. provided AMSL.
Table 11: DiscretizedDomain Data Structure
4.2. The AlertDetail Data Structure

Provides the
alert level, with
AlertMessage String 1
the relevant
description.
Provides the This will include the multiple Alert

AlertCondition String 1 Alert condition conditions for different alert levels
met. as well.
31
A float
Latitude Precise provides the
containing the
position of the raw measured data
exact Latitude of
LatitudePrecise Float 1 points within a voxel. This is in
the data point
contrast to Latitude (found in the
corresponding to
DiscretisedDomain data structure).
the alert.
A float
Longitude Precise provides the
containing the
exact Longitude
LongitudePrecise Float 1 points within a voxel. This is in
of the data point
contrast to Longitude (found in the
corresponding to
the alert.
A float
Altitude Precise provides the
containing the
exact Altitude of
AltitudePrecise Float 1 points within a voxel. This is in
the data point
contrast to Altitude (found in the
corresponding to
the alert.
A string
containing
particular
AlertMetadata String 0..1
metadata
relevant to the
Alert.
The precise Time stamp

corresponds to the exact time (high
A DateTime
resolution) of alert
containing the
measurement/occurrence. This is
exact TimeStamp
PreciseTimeStamp DateTime 1 in contrast to the “TimeStamp”
of the data point
provided in the AlertData variable
corresponding to
that corresponds to the end of each
the alert.
1 second bins used as the update
frequency.
Table 12: AlertDetail Data Structure
32
4.3. The AlertVoxel Data Structure

The Latitude of the Centre of the voxel containing the

Latitude Float 1
alert.
The Longitude of the Centre of the voxel containing

Longitude Float 1
the alert.
The Altitude of the Centre of the voxel containing the

Altitude Float 1
alert.
AlertCount Int 1 Provides the number of alerts within a given voxel.
AlertDetail AlertDetail 0..* Details about each alert in AlertDetail format.
Table 13: AlertVoxel Data Structure
4.4. The Alerts Data Structure

Describes the weather

WeatherParameterDescription String 1 parameter used to
create the alert.
Multiple Alert voxels,

containing each Only Voxels
AlertVoxel AlertVoxel 1..* information about the with an alert
alerts within each given are provided.
voxel.
Table 14: Alerts Data Structure
33
4.5. The AlertData Data Structure

The total number of alerts in a

AlertCount Int 1
given update.
The dimensions and spatial

Domain Float 3 resolution of the domain of
interest.
The time stamp of the alerts Provided at 1

TimeStamp DateTime 1
update. second steps.
All Alerts at a given instance

HighWindSpeedAlerts Alerts 0..1 pertaining to Wind speed going
beyond a threshold.
All Alerts at a given instance

WindShearAlerts Alerts 0..1 pertaining to Wind shear going
beyond a threshold.
All alerts at a given instance about

StormAlerts Alerts 0..1
storms in the alerts format.
All alerts within the given domain

LightningAlerts Alerts 0..1
providing lightning alerts.
Table 15: AlertData Data Structure
34
4.6. Common data structures used in U-space specifications
Figure 4: Common Data Types Used in U-space Service Specifications
4.6.1. ServiceResponse Data Structure
Multi-
plicity
Oper-
Indicates the result of the
result ation- 1
request to the service
Result
Optional additional
rejectReason String 0..1 information to be provided in
case of negative result
35
5. Service Interface specifications

Service Interface.
5.1. Service Interface

5.2. SupplementaryWeatherDataretrievalInterface
The supplementary Weather Data Retrieval Interface allows service consumers to retrieve weather
data on request. (Historic, Current and Forecast weather data)
5.2.1. Operation queryWeatherForecast

Returns a ForecastData file containing the weather forecast for the time indicated by the input
timestamp.

List of Weather
WeatherParametersList Input WeatherParametersList
Parameters requested.
The extent of the

spatial domain and the
Geometry Input Geometry
spatial resolution of
the output data.
The start time of the

StartTime Input DateTime requested weather
data.
36
The end time of the

EndTime Input DateTime requested weather
data.
The temporal
resolution of the
TemporalResolution Input Float
requested weather
data. (in seconds)
Query response,
including the
ForecastData Return ForecastData
requested forecast
Weather data.
Table 17: Operation queryWeatherForecast parameters
5.2.2. Operation queryCurrentWeather

Returns a WeatherData file containing the current weather data at the time of request.

List of Weather Parameters

requested.
The extent of the spatial domain and

Geometry Input Geometry the spatial resolution of the output
data.
Query response, including the

WeatherData Return WeatherData
requested current Weather data.
Table 18: Operation queryCurrentWeather parameters
5.2.3. Operation queryHistoricWeather
37
The Historic data service interface will allow the UAV operator/USSP to use an API command to query
historic weather data from the weather data base. The user will be able to query weather data for past
dates /times as per requirement.

Returns a HistoricData file containing the weather data corresponding to the requested time frame in
the past.


requested.

data.
The start time of the requested

StartTime Input DateTime
weather data.
The end time of the requested

EndTime Input DateTime
weather data.
The temporal resolution of the

TemporalResolution Input Float requested weather data. (in
seconds)
Query response, including the

HistoricData Return HistoricData
requested historic Weather data.
Table 19: Operation queryHistoricWeather parameters
38

SupplementaryWeatherDataSubscriptionInterface
Allows service consumers to subscribe/unsubscribe for reception of weather data publications
5.3.1. Operation subscribeRegularWeatherData

A consumer calls this operation to subscribe to Regular Weather Data.


requested.

data.
The temporal resolution of the

TemporalResolution Input Float requested weather data. (in
seconds)
Provide status information on

ServiceResponse Return ServiceResponse
subscription.
Table 20: Operation subscribeRegularWeatherData parameters
5.3.2. Operation unsubscribeRegularWeatherData

A consumer calls this operation to unsubscribe to Regular Weather Data.

Parameter
Name
39
ServiceResponse Return ServiceResponse Provide status information on subscription.
Table 21: Operation unsubscribeRegularWeatherData parameters
5.3.3. Operation subscribeWeatherAlertData

A consumer calls this operation to subscribe to Weather Alert Data.

List of Weather
WeatherParametersList Input WeatherParametersList Parameters
requested.
The extent of
the spatial
domain and the
Geometry Input Geometry spatial
resolution of
the output
data.
The temporal
resolution of
TemporalResolution Input Float the requested
weather data.
(in seconds)
Provide status
ServiceResponse Return ServiceResponse information on
subscription.
Table 22: Operation subscribeWeatherAlertData parameters
5.3.4. Operation unsubscribeWeatherAlertData

A consumer calls this operation to unsubscribe to Weather Alert Data.
40

Parameter
Name
ServiceResponse Return ServiceResponse Provide status information on subscription.

SupplementaryWeatherDataPublicationInterface
Supplementary Weather Data Service to publish (push) real time weather data to subscribed
consumers through this interface.
5.4.1. Operation pushRegularWeatherData

Publishes WeatherData file updates at a regular frequency containing current weather information.

Parameter
Name
A regular push of the requested weather data

WeatherData Return WeatherData
corresponding to subscription
Table 23: Operation pushRegularWeatherData parameters
5.4.2. Operation pushWeatherAlertData
Certain types of measurements such as wind shear and storms require real time alerts to be
communicated with the stakeholders. Thus, there will be made available an irregular data push. The
idea is to communicate an alert immediately after an alert grade phenomenon has been observed.

Publishes Weather AlertData file updates at a regular frequency containing current weather alert
information.
41

Parameter
Name
A high frequency irregular push of the

AlertData Return AlertData requested alert data corresponding to
subscription.
Table 24: Operation pushWeatherAlertData parameters
42
6. Service Dynamic Behavior
Figure 5: Service Dynamic Behavior
The figure above provides an example scenario for the Supplementary Weather data service.
The following three Scenarios are illustrated in the above diagram:
o U-space Regular weather data update and dispatch to UAV operators
o UAV operators subscribe to weather alerts
43
o UAV operator query for Historic and Forecast data.
44
7. Definitions of Acronyms and Terms

7.1.1. List of Acronyms
Acronym Explanation
3GPP 3rd Generation Partnership Project

ACJA Aerial Connectivity Joint Activity (by GSMA + GUTMA)
AIXM Aeronautical Information Exchange Model
AMQ Advanced Message Queuing
ASTM American Society for Testing and Materials
BVLOS Beyond Visual Line of Sight

EDT Estimated Time of Departure
FIXM Flight Information Exchange Model
FPL Flight Plan
GSMA GSM Association
GUTMA Global UTM Association
U-space Concept of procedures and services to support unmanned traffic management
45
Acronym Explanation
USSP U-space Service Providers

UTM UAV Traffic Management
46
8. References
[1] European ATM Master Plan: Roadmap for the safe integration of drones into all classes of
airspace
47
INDUSTRIAL RESEARCH
U-space ConOps: Interface

U-space/ATM (AURA
sol.2)
Project Acronym: PJ34 AURA
Topic: Collaborative ATM - U-space Interface
Consortium Coordinator: Indra
Edition Date: 17 February 2023
Edition: 01.00.01
U-SPACE CONOPS: INTERFACE U-SPACE/ATM (AURA SOL.2)

Beneficiary Date
Indra 10/02/2023

Beneficiary Date
Indra 16/02/2023

Beneficiary Date
project
Beneficiary Date

Beneficiary Date
Document History
01.00.01 17/02/2023 Finished INDRA Annex to be
introduced in
CORUS XUAM
ConOps
Copyright Statement © 2023 – PJ34 Solution 1 Partners. All rights reserved. Licensed to SESAR3
Page I 2
PJ34-W3-01 AURA
COLLABORATIVE ATM - U-SPACE INTERFACE
This document aims to provide a summary of the detail regarding PJ34-W3-01 in terms of being
introduced as an Annex associated to CORUS-XUAM ConOps documentation.
Abstract
During CORUS-XUAM ConOps seminars which were held during 2022, several projects were shown in
a way of being compared to the current CORUS concept. These seminars aimed to collect all valuable
information, concepts, details, systems, etc. which could enrich and give a more complete view of the
U-space.
AURA was presented in November 2022. The main issues addressed were:
 AURA General Description.
 AURA volumes of Operation.
 Introduction to solutions 1 and 2.
 Regarding Solution 1 Collaborative ATM-U-space Interface, the following points were

discussed:
o General description.
o Operational Processes Assessment.
o Clusters and services validation.
o Stakeholders.
o Systems.
o Standards.
o Conclusions.
All this material was presented in comparison to the CORUS concept and, following this presentation,
the need for the concept to be developed within the ConOps was derived. After several coordinations
with the CORUS XUAM team, definition of services is going to be included in the main ConOps
documentation and, in order to address additional information and details linked to the services
defined, the present document represents an annex that could be considered, pending review and
approval.
Page I 3
Page I 4
Table of Contents
Abstract ................................................................................................................................... 3
1 Introduction to the concept ........................................................................................ 8
2 New Operating Method ............................................................................................. 9
2.1 Flight Authorization (and nominal operation) ................................................................. 9
2.2 Dynamic Airspace Reconfiguration ............................................................................... 10
2.3 Emergency Management ............................................................................................. 10
2.4 Nominal Situation........................................................................................................ 11
2.5 Non Nominal Situation ................................................................................................ 11
3 Services description .................................................................................................. 12
3.1 Operation Plan Information Exchange Service .............................................................. 13
3.1.1 Service interface specifications ....................................................................................................... 13
3.1.2 Data payload diagram ..................................................................................................................... 21
3.2 Geofence Information Exchange Service ....................................................................... 22
3.3 Tactical Operational Message Information Exchange Service ........................................ 29
3.4 Tracking Information Exchange Service ........................................................................ 34
3.5 Traffic Non-Conformance Monitoring Information Exchange Service ............................. 37
3.5.1 Service Interface Specifications....................................................................................................... 37
4 Use Cases ................................................................................................................. 40

4.1 Cluster 1 Operational views ......................................................................................... 42
4.2 Cluster 1 Technical views ............................................................................................. 46
Page I 5
Index of figures
Figure 1: Flight Authorization .................................................................................................................. 9
Figure 2: Dynamic airspace reconfiguration ......................................................................................... 10
Figure 3: Emergency management ....................................................................................................... 10
Figure 4: Nominal situation ................................................................................................................... 11
Figure 5: Non nominal situation ............................................................................................................ 11
Figure 6: Solution 1 information exchange procedure ......................................................................... 12
Figure 7: Cluster 1- Use Case 1 - NOV-5 view ........................................................................................ 42
Figure 10: Cluster 1- Use Case 4 - NOV-5 view...................................................................................... 44
Figure 14: Cluster 1 - NSV-1 view .......................................................................................................... 46
Figure 15: Cluster 1- Use Case 1 - NSV-4 view....................................................................................... 47
Figure 22: Cluster 2 - Use Case 1 - NOV-5 view ..................................................................................... 51
Figure 24: Cluster 2 - Use Case 3 (Part I) - NOV-5 view ......................................................................... 53
Figure 25: Cluster 2 - Use Case 3 (Part II) - NOV-5 view ........................................................................ 53
Page I 6
Figure 29: Cluster 2 - Use Case 1 - NSV-4 view...................................................................................... 56
Figure 31: Cluster 2 - Use Case 3 (Part I) - NSV-4 view .......................................................................... 57
Figure 32: Cluster 2 - Use Case 3 (Part II) - NSV-4 view ......................................................................... 58
Figure 38: Cluster 3 - Use Case 1&2 - NSV-4 view ................................................................................. 63
Page I 7
1 Introduction to the concept
Solution PJ.34-W3-01 goal is the definition of the ATM/U-Space Interface by identifying the data
exchanges required between ATM and U-Space systems and by defining the information needed to be
shared. This identification leads to the generation of a set of basic services permitting the information
exchange through SWIM as middleware of the ATM - U-space systems interface. The information
exchange services defined conform the initial ATM-U-Space common interface.
The definition of the U-space/ATM common interface by identifying an initial set of basic services and
by considering the relevant information to be exchanged, permits and guarantees the interoperability
between both systems, avoiding airspace fragmentation and allowing safe drones’ operations into
controlled and uncontrolled airspace.
Due to the fact of operations being performed in a High Risk environment (UAS operation to be
conducted in CTR airspace whose planned trajectories are interfering with manned aircraft planned
trajectories, causing a potential conflict), the role of ATM/ATC Controller is very relevant as participant
in the operation flow. For example, in the flight authorization flow, ATC must confirm the FA request
and the FA request.
This clarification is done in order to avoid some divergence from the existing regulation. In the flight
authorization flow we consider the need for the ATM to approve the authorization when it is not
contemplated under EC 664/2021 regulation, because the operations are performed under controlled
airspace. The same consideration is applied for the activation request from ATM.
Page I 8
2 New Operating Method

The scope of this section is to provide information regarding the proposed “new operating method”
for enabling and describing the U-space-ATM Interface interaction.
Focusing on the U-space-ATM Interface and the main services addressed in the solution by the UCs
containing information exchanges between the two systems, different topics/services/information-
exchanges are impacted and need to be described in the New Operating Method definition in the
frame of Solution PJ34-W3-01 Collaborative U-space-ATM interface, which can be summarised as
follows:
 Flight Authorization.
 Drone Nominal Operation.
 Dynamic Airspace Reconfiguration (understood as how will work a future service associated to
DAR, immediately linked to Solution 2 development).
 Emergency Management.
 Drone Non Nominal Operation.
 Traffic Information:
o Tracking – From U-space to ATM and vice versa.
o Alerts – From U-space to ATM (Conformance Monitoring Alerts, Conflicts Alerts).
 Any other Topic/Service/Information-exchange performed via ATM-U-space Interface needed
to be considered for the Op. Method definition.
The following views represent in a more understandable way the approach to the new operating
methods mentioned. In this way, all of them are represented except from traffic information as not
being an operating method itself.
2.1 Flight Authorization (and nominal operation)
Figure 1: Flight Authorization
Page I 9
2.2 Dynamic Airspace Reconfiguration
Figure 2: Dynamic airspace reconfiguration
2.3 Emergency Management
Figure 3: Emergency management
Page I 10
2.4 Nominal Situation
Figure 4: Nominal situation
2.5 Non Nominal Situation
Figure 5: Non nominal situation
Page I 11
3 Services description
The main objective of this project is to define an ATM/U-Space common interface and validate the
information exchanges of a first set of defined services as part of this interface, using SWIM and further
develop the concept of operations for ATM-U-space Collaborative interface. The solution first assess
works from SESAR and other international entities and, then, the initial list of U-space U2/U3 services
candidates for information exchange will be determined. In particular, the solution determines which
services and which specific information is relevant to ATM systems. Therefore, the objective of solution
1 is to validate at V2 and V3 level the exchange of information and interface requirements needed to
allow a feasible interoperability between U-space (U-space U2 and U3 services) and ATM.
In this way, the main procedure followed is defined by the following picture:
Figure 6: Solution 1 information exchange procedure
From now on, focusing on the set of services which are covered by AURA Solution 1, the following
subsections give an additional level of information over the already shown in the main ConOps
documentation. These sections address the main interfaces involved in the interchange of information
required for each one of the services and the payload associated. This information comes from current
SDD documentation, which shall be further refined and developed in the subsequent SESAR3 proposals
using the different outputs, conclusions and recommendations obtained after Solution 1 validations.
Page I 12
3.1 Operation Plan Information Exchange Service

3.1.1 Service interface specifications
(* indicates that the Data Entity has been created for the needs of this service, but is not yet part of AIRM)
3.1.1.1 ActivationProvisionInformationExchangeInterface
The service provider offers this interface to allow consumers to request an activation for an Operation
Plan.
3.1.1.1.1 Operation getActivationForAuthorisationId
Input Service Payload Data Entity

AuthorizationId *AuthorizationId
Return Service Payload Data Entity

ActivationResponse *ActivationRequestResponse
Data Entity Attribute Data Type Mandatory (Yes/No)

or Multiplicity
* ActivationRequestResponse
rejectReason P-String No
result EnumOperationResult Yes
activations Activation 0..*
* AuthorizationId
authorizationId UUIDType Yes
3.1.1.1.2 Operation getActivationForOperationPlanId

The service provider offers this interface to allow consumers to request an authorization for
operatioPlan.

UASOperationPlanId *OperationPlanID

ActivationResponse *ActivationRequestResponse

or Multiplicity
* ActivationRequestResponse
Page I 13
activations Activation 0..*
* OperationPlanID
operationPlanID UUIDType Yes
3.1.1.2 AuthorizationProvisionInformationExchangeInterface
The service provider offers this interface to allow consumers to request an authorization for
operationPlan.
3.1.1.2.1 Operation getAuthorizationForId

A consumer calls this operation to explicitly request an authorization by submitting the known id.


AuthorizationResponse *AuthorizationRequestResponse

or Multiplicity
* AuthorizationRequestResponse
authorizations Authorization *
* OperationPlanID
3.1.1.3 OperationPlanNotificationInformationExchangeInterface
Once and while subscribed, consumer receives operation plan data via this interface.
3.1.1.3.1 Operation notifyMilitaryOperationPlan

The service provider uses this logical operation (implemented by the consumer) to publish military
operation plan data.

UASOperationPlan *OperationPlan
Page I 14
or Multiplicity
* OperationPlan
operationPlanId UUIDType Yes
version UUIDType Yes
typeOfOperation CodeOperationType Yes
state CodeOperationPlanState Yes
swarmsize P-Integer Yes
submitTime DateTimeType Yes
updateTime DateTimeType Yes
minContOpTime P-Integer No
missionId UUIDType Yes
atsInstruction P-String No
contactDetails ContactDetails 1
operationVolumes OperationVolume *
priority Priority 1
uASRegistration UASRegistration 1..*
3.1.1.3.2 Operation notifyOperationPlan

The service provider uses this logical operation (implemented by the consumer) to publish operation
plan data.


or Multiplicity
* OperationPlan
Page I 15
priority Priority 1
3.1.1.4 OperationPlanProvisionInformationExchangeInterface
The service provider offers this interface to allow consumers to query operation plan data.
3.1.1.4.1 Operation getOperationPlanForGeometry

A consumer calls this operation to explicitly request operation plan data for a certain geographical
area.

Geometry *Geometry

OperationPlanResponse *OperationPlanResponse

or Multiplicity
* Geometry
geometryType EnumGeometryType Yes
uomDimensions UomDistance Yes
lowerLimit P-Integer No
lowerVerticalReference CodeVerticalReferenceType No
upperLimit P-Integer Yes
upperVerticalReference CodeVerticalReferenceType Yes
* OperationPlanResponse
Page I 16
operationPlans OperationPlan 0..*
3.1.1.4.2 Operation getOperationPlanForId

A consumer calls this operation to explicitly request an operation plan by submitting the known id.



or Multiplicity
* OperationPlanID
3.1.1.4.3 Operation getOperationPlanForMission

A consumer calls this operation to explicitly request operation plan data belonging to a certain mission.

MissionId *MissionId


or Multiplicity
* MissionId
Page I 17
3.1.1.4.4 Operation getOperationPlans

A consumer calls this operation to explicitly request operation plan data matching various criteria.


or Multiplicity
* OperationPlan
priority Priority 1
3.1.1.4.5 Operation getOperationVersion

A consumer calls this operation to explicitly request a certain version of an operation plan by
submitting the known ids.
Page I 18


UASOperationPlanVersionId *OperationPlanVersion


or Multiplicity
* OperationPlanID
* OperationPlanVersion
3.1.1.4.6 Operation submitMission

A consumer calls this operation to explicitly submit a mission that contains a serie of operation plans
(at least one operation plan).

Mission *Mission


or Multiplicity
* Mission
beginTime DateTimeType No
endTime DateTimeType No
description P-String No
contactDetails ContactDetails 0..1
Page I 19
operationsPlans OperationPlan 1..*
publicInformation PublicInformation 0..1
3.1.1.5 OperationPlanSubscriptionExchangeInterface
The service provider offers this interface to allow consumers to subscribe/unsubscribe for operation
plan data.
3.1.1.5.1 Operation subscribeForOperationPlan

A consumer calls this operation to subscribe to receive operation plan data.

NotificationEndpoint *NotificationEndpoint

AreaOfInterest *AreaOfInterest

ServiceResponse *ServiceResponse

or Multiplicity
* AreaOfInterest
areaCRS EnumCRSType Yes
area P-String Yes
* NotificationEndpoint
URL P-String Yes
* ServiceResponse
3.1.1.5.2 Operation unsubscribe

A consumer calls this operation at the provider to unsubscribe from operation plan or no flight zone
data.
Page I 20



or Multiplicity
URL P-String Yes
* ServiceResponse
3.1.2 Data payload diagram

Ope ra tio nP la n U ASR e gistra tio n
operationPlanId:UUIDType uASRegistration droneId:P-String
Missio n version:UUIDType registrationId:UUIDType
operationsPlans typeOfOperation:CodeOperationType 1..* registrationLocation:P-String
missionId:UUIDType
beginTime:DateTimeType 1..* state:CodeOperationPlanState
endTime:DateTimeType swarmsize:P-Integer
description:P-String submitTime:DateTimeType
updateTime:DateTimeType
minContOpTime:P-Integer 0..1
missionId:UUIDType Op era tion T ra je c to ry
atsInstruction:P-String operationTrajectory positionCRS:EnumCRSType
altitudeCRS:EnumCRSType
operationPlans
Con ta c t D e tails 0..*
Priority
registrationId:P-String priority 1
contactDetails name:P-String contactDetails priorityText:P-String
publicInformation 0..1 e-mail:P-String priorityType:CodePriorityType
0..1 1 operationVolumes *
phone:P-String
fax:P-String Op era tion Vo lu me trajectoryElements
0..1 priority 0..1 1..*
Pu b lic I n fo rma tion comment:P-String
alias:P-String priority
title:P-String
timeBegin:DateTimeType T ra je c toryE le me n t
description:P-String
actualTimeEnd:DateTimeType
time:DateTimeType
timeEnd:DateTimeType
actualTimeEnd:DateTimeType
isBVLOS:P-Boolean
isBVLOS:P-Boolean
latitude:P-Float
longitude:P-Float
S erv ic e R e sp on se altitude:P-Float
result:EnumOperationResult
rejectReason:P-String
operationGeometry 1
Geometry
geometryType:EnumGeometryType
uomDimensions:UomDistance
lowerLimit:P-Integer
lowerVerticalReference:CodeVerticalReferenceType
upperLimit:P-Integer
Op era tion Pla n R e sp on se upperVerticalReference:CodeVerticalReferenceType
Poin t
Polygon
Co ord in a te s
coordinates longitude:P-Float coordinates
latitude:P-Float
4..* 1..*
Coordinates shall be set up as Longitude

first data and Latitude second data. !
Page I 21
3.2 Geofence Information Exchange Service

3.2.1.1 Geofence Information Exchange Publication Interface

The publication interface enables the provider to send UAS Zone information updates to subscribed
consumers. It allows sending subscription status information that enable the consumer to verify that
the publication interface and the dependencies with the Subscription interface are working as
expected.
In order for the provider to be able to send information to consumers, it is required as a prerequisite
that the consumers:
 Create a subscription via the subscribeToUASZonesUpdates operation.
 Create a connection to the publicationLocation provided as a result of the subscription
operation.
 Activate the subscription via the resumeUASZonesUpdatesSubscription
3.2.1.1.1 Operation notifySubscriptionStatus

This operation enables the provider to send the status of a subscription to the subscribed consumer.

SubscriptionStatusMessage *SubscriptionStatusNotification

or Multiplicity
* SubscriptionStatusNotification
subscriptionID P-String
subscriptionStatus EnumSubscriptionStatusTyp Yes

e
notificationReason EnumNotificationReason Yes
notificationReasonDescripti P-String
on
3.2.1.1.2 Operation publishUASZonesUpdates

This operation enables the provider, whenever a UASZone information is changed, to send an update
to subscribed consumers.

UASZoneUpdatePublication *UASZone

or Multiplicity
* UASZone
Page I 22
identifier CodeZoneIdentifierType Yes
country CodeCountryISOType Yes
3.2.1.2 Geofence Information Exchange Retrieval Interface

The retrieval interface enables the synchronous retrieval of all UAS Zone information available for a
particular timeframe, airspace and region of interest. It also enables synchronously retrieving the
information that has changed since a particular moment.
3.2.1.2.1 Operation retrieveUASZones

This operation enables the retrieval of UASZonesinformation.

UASZonesRequest *UASZonesRequest

UASZonesReply *UASZonesReply

or Multiplicity
* UASZonesReply
requestExceptionDescriptio P-String No
n
requestProcessedTimeStam DateTimeType Yes

p
requestStatus EnumRequestStatusType Yes
UASZoneList UASZone *
* UASZonesRequest
regions P-Integer
startDateTime DateTimeType No
endDateTime DateTimeType No
airspaceVolume AirspaceVolume *
3.2.1.2.2 Operation retrieveUASZonesUpdates

This operation enables the retrieval of recently updated UASZonesinformation. This is not an operation
to modify information.

UASZonesUpdatesRequest *UASZonesUpdatesReply
Page I 23

UASZonesUpdatesReply *UASZonesUpdatesReply

or Multiplicity
* UASZonesUpdatesReply
n

p
UASZoneList UASZone *
3.2.1.3 Geofence Information Exchange Subscription Interface

The subscription interface enables the Geofencing service consumer to express interest in receiving
updates to UAS Zone information for a particular airspace and region of interest.
3.2.1.3.1 Operation getUASZonesUpdatesSubscriptions

This operation allows a subscriber to obtain a list of its subscriptions, detailing.

GetUASZonesUpdatesSubscriptionsReply *GetUASZonesUpdatesSubscriptionsReply

or Multiplicity
*
GetUASZonesUpdatesSubscriptions
Reply
n

p
subscriptions Subscription *
3.2.1.3.2 Operation pauseUASZonesUpdatesSubscription

This operation sets the subscription to a “PAUSED” state, resulting in updates delivered via the
“Publication” interface to stop for the subscribed consumer. New messages are not stored in a paused
queue by the provider.
Page I 24

PauseUASZonesUpdatesSubscriptionReque *PauseUASZonesUpdatesSubscriptionRequ
st est

PauseUASZonesUpdatesSubscriptionReply *PauseUASZonesUpdatesSubscriptionReply

or Multiplicity
*
PauseUASZonesUpdatesSubscriptio
nReply
n

p
subscriptionStatus EnumSubscriptionStatusTyp
e
*
PauseUASZonesUpdatesSubscriptio
nRequest
e
3.2.1.3.3 Operation resumeUASZonesUpdatesSubscription

This operation sets the subscription to an “Active” state, resulting in updates delivered via the
“Publication” interface to start for the subscribed consumer

ResumeUASZonesUpdatesSubscriptionReq *ResumeUASZonesUpdatesSubscriptionRe
uest quest

ResumeUASZonesUpdatesSubscriptionRepl *ResumeUASZonesUpdatesSubscriptionRe
y ply

or Multiplicity
*
ResumeUASZonesUpdatesSubscripti
onReply
n
Page I 25

p
e
*
ResumeUASZonesUpdatesSubscripti
onRequest
e
3.2.1.3.4 Operation subscribeToUASZonesUpdates

This operation creates a subscription for the consumer, with “PAUSED” state. The operation creates
also a publication resource (i.e. queue) at the provider infrastructure, where all information updates
related to the subscription will be delivered.

SubscribeToUASZonesUpdatesRequest *SubscribeToUASZonesUpdatesRequest

SubscribeToUASZonesUpdatesReply *SubscribeToUASZonesUpdatesReply

or Multiplicity
*
SubscribeToUASZonesUpdatesReply
n

p
subscriptionID UUIDType Yes
publicationLocation P-String Yes
publicationLinkVerificationFr P-String
equency
e
*
SubscribeToUASZonesUpdatesRequ
est
Page I 26
regions P-Integer
startDateTime DateTimeType No
endDateTime DateTimeType No
airspaceVolume AirspaceVolume *
3.2.1.3.5 Operation unsubscribeToUASZonesUpdates

This operation sets the subscription to a “DELETED” state, resulting in updates
delivered via the “Publication” interface to stop for the subscribed consumer. The
operation also deletes the publication resource (i.e. queue) at the provider infrastructure
where all information related to the subscription was being delivered.

UnsubscribeToUASZonesUpdatesReply *UnsubscribeToUASZonesUpdatesReply

or Multiplicity
*
UnsubscribeToUASZonesUpdatesRe
ply
n

p
e
Page I 27
Page I 28
3.3 Tactical Operational Message Information Exchange Service

3.3.1.1 Tactical Operational Message Acknowledgement Interface

Consumer provides this interface, allowing the service provider to submit to the consumer
acknowledgement messages.
3.3.1.1.1 Operation acknowledgeOperationalMessage

A consumer calls this operation to acknowledge an operational message.

AckTacticalOperationalMessage *ackTacticalOperationMessage


or Multiplicity
* ackTacticalOperationMessage
ackMsgID UUIDType Yes
msgBeingAcknowledged UUIDType Yes
acknowlegement EnumAcknowlegement Yes
* ServiceResponse
3.3.1.2 Tactical Operational Message Notification Interface

messages.
3.3.1.2.1 Operation notifyOperationalMessage

messages.

TacticalOperationalMessage *TacticalOperationalMessage

Page I 29

or Multiplicity
* ServiceResponse
* TacticalOperationalMessage
messageID UUIDType Yes
source P-String Yes
time DateTimeType Yes
messageSeverity EnumTacticalOperationalMe Yes

ssageSeverity
messageType EnumTacticalOperationMess Yes

ageType
freeText P-String No
messageState EnumTacticalOperationMess Yes

ageState
3.3.1.3 Tactical Operational Message Subscription Interface

Consumer provides this interface, allowing the service provider to submit to the consumer subscription
messages.
3.3.1.3.1 Operation subscribeForOperationalMessageMonitoring

A consumer calls this operation to subscribe to monitoring of operational messages related to a certain
geographical area of interest.
An operator subscribes to the OperationalMessageExchangeSunscriptionInterface of her USSP for each

one of her operationPlanId.


Page I 30


or Multiplicity
* AreaOfInterest
area P-String Yes
URL P-String Yes
* ServiceResponse
3.3.1.3.2 Operation subscribeForOperationalMessages

A consumer calls this operation to subscribe for receiving operational messages related to a certain
geographical area of interest, or related to a certain operation plan.





or Multiplicity
* AreaOfInterest
area P-String Yes
URL P-String Yes
* OperationPlanID
Page I 31
* ServiceResponse
3.3.1.3.3 Operation unSubscribeForOperationalMessages

A consumer calls this operation at the provider to unsubscribe from operational messages related to
a certain geographical area of interest or related to a certain operation plan.





or Multiplicity
* AreaOfInterest
area P-String Yes
URL P-String Yes
* OperationPlanID
* ServiceResponse
Page I 32

T ac t ic a lOpe ra tion a lM e ssag e
messageID:UUIDType
source:P-String
time:DateTimeType
messageSeverity:EnumTacticalOperationalMessageSeverity
messageType:EnumTacticalOperationMessageType
freeText:P-String
messageState:EnumTacticalOperationMessageState
operationPlanID:UUIDType
version:UUIDType
relatedMessages
0..*
a c k T a c t ic a lOpe ra t ion M e ssag e

ackMsgID:UUIDType
msgBeingAcknowledged:UUIDType
acknowlegement:EnumAcknowlegement
Page I 33
3.4 Tracking Information Exchange Service

3.4.1.1 TrackingNotificationInterface
Consumer provides this interface, allowing the service provider to submit to the consumer position
report data (and flight event notifications, if supported).
3.4.1.1.1 Operation notifyFlightEvent

Once and while subscribed, consumer receives flight event notifications via this operation.

FlightEventNotification *FlightEventIndication

or Multiplicity
* FlightEventIndication
flightEvent EnumFlightEventType Yes
operationPlanId UUIDType No
startTime DateTimeType No
endTime DateTimeType No
positionReportFrecuency P-Float No
3.4.1.1.2 Operation notifyPositionReport

Once and while subscribed, consumer receives position report data via this operation.

PositionReport *PositionReport

or Multiplicity
* PositionReport
acquisitionDateTime DateTimeType Yes
acquisitionDatetimeAccurac P-Float Yes

y
operationId UUIDType No
origin P-String Yes
Page I 34
reportId UUIDType Yes
senderId UUIDType Yes
altitude Altitude 1..*
position Position 1
velocity Velocity 0..1
3.4.1.2 TrackingSubscriptionInterface
3.4.1.2.1 Operation subscribeForTracking





or Multiplicity
* AreaOfInterest
area P-String Yes
URL P-String Yes
* ServiceResponse
3.4.1.2.2 Operation unSubscribeForTracking

A consumer calls this operation at the provider to unsubscribe from position report data.
Page I 35


or Multiplicity
URL P-String Yes
* ServiceResponse

Pose
Velo c ity
senderId:UUIDType
reportId:UUIDType velocity latitude:P-Float
longitude:P-Float
operationId:UUIDType
0..1 altitude:P-Float
acquisitionDateTime:DateTimeType
horizontalAccuarcy:P-Float
acquisitionDatetimeAccuracy:P-Float
verticalAccuarcy:P-Float
origin:P-String
Altit u de
0..1 changeRate
altitude:P-Float
Po sition R e port
altitudeAccuarcy:P-Float 1..*
altitudeType:EnumAltitudeType Velo c ityChan g eR
determination:EnumAltitudeDeterminationMethodType altitude at e
altitudeCrs:EnumCRSType
latChangeRate:P-Float
altitudeDataAge:P-Float
lonChangeRate:P-Float
altChangeRate:P-Float
1
position
Position
latitude:P-Float
FlightEv e n tIndic at io n longitude:P-Float
positionAccuarcy:P-Float
flightEvent:EnumFlightEventType positionCrs:EnumCRSType
operationPlanId:UUIDType
positionDataAge:P-Float
startTime:DateTimeType
endTime:DateTimeType
positionReportFrecuency:P-Float
Page I 36
3.5 Traffic Non-Conformance Monitoring Information Exchange

Service
3.5.1 Service Interface Specifications
3.5.1.1 TrafficNonConformanceMonitoringNotificationInterface
Consumer provides this interface, allowing the service provider to submit to the consumer Traffic
Conformance Monitoring report data.
3.5.1.1.1 Operation notifyTrafficNonConformanceMonitoringReport

TrafficNonConformanceMonitoringReport *TrafficNonConformanceMonitoringReport

or Multiplicity
*
TrafficNonConformanceMonitoring
Report
reportId UUIDType Yes
positionReportCapability P-Boolean Yes
timestamp DateTimeType Yes
reportType EnumNonConformanceMoni Yes

toringFunctionType
reportSubType P-String No
flavour P-String No
severity EnumConflictSeverity No
probability PercentageType No
duration P-Integer Yes
currentSeparation Separation 0..1
deviation Separation 0..1
estimatedMinimumSeparati Separation 0..1

on
reportAltitude Altitude 1
Page I 37
3.5.1.2 TrafficNonConformanceMonitoringSubscriptionInterface
A consumer calls this interface to subscribe or unsubscribe to Traffic Conformance Monitoring report
notification.
3.5.1.2.1 Operation
TrafficNonConformanceMonitoringInformationExchangeService.TrafficNonConf
ormanceMonitoringSubcriptionInterface.subscribeForTrafficNonConformanceM
onitoring




or Multiplicity
* AreaOfInterest
area P-String Yes
URL P-String Yes
* ServiceResponse
3.5.1.2.2 Operation
TrafficNonConformanceMonitoringInformationExchangeService.TrafficNonConf
ormanceMonitoringSubcriptionInterface.unSubscribeForTrafficNonConformance
Monitoring


Page I 38
or Multiplicity
URL P-String Yes
* ServiceResponse

T raf fic N o nConfo rma n c eM onitoring Re p ort Position
reportId:UUIDType latitude:LatitudeType
operationPlanId:UUIDType reportPosition longitude:LongitudeType
version:UUIDType positionAccuracy:P-Float
1
positionReportCapability:P-Boolean positionCRS:EnumCRSType
timestamp:DateTimeType positionDataAge:P-Integer
reportType:EnumNonConformanceMonitoringFunctionType
reportSubType:P-String
flavour:P-String
severity:EnumConflictSeverity
probability:PercentageType
duration:P-Integer
Altit u de
altitude:P-Integer
reportAltitude altitudeAccuracy:P-Float
altitudeType:EnumAltitudeType
1 determinationMethod:EnumAltitudeDeterminationMethodType
altitudeCRS:EnumCRSType
altitudeDataAge:P-Integer
Sepa ration
currentSeparation
longitudinal:P-Integer
0..1 transversal:P-Integer
deviation vertical:P-Integer
timeLeft:P-Integer
0..1
estimatedMinimumSeparation
0..1
Page I 39
4 Use Cases
The exercises performed in this AURA Solution 1 aim to demonstrate and validate the potential of U-
space services already exposed in section 3 for unlocking these new operations in the short to medium
term.
This section addressed the most relevant information related to use cases and services being validated
in each one of them but, for further details, AURA Solution 1 documentation is available in STELLAR so
that:
 Use cases operations flows are detailed in section 3.3.2.6 of SPR-INTEROP/OSED Part I.
 Scenarios planning of each exercise are detailed in section 5 of the VALP.
 Results obtained from each one of these iterations can be found in Appendixes A, B, C and D
of VALR.
Each cluster will be centred on a different geographical area and will focus on different validation
exercises, allowing the project to cover the full scope of the problem using a “divide and conquer”
approach. Moreover, besides the leadership, different partners have collaborated in each one of them
so that validations cover a broad variety of ATC systems and practices across Europe.
This annex show NOV-5, NSV-4 and NSV-1 views as being the most representative linked to them, but
the rest of operational views (NOV-2) and technical views (NSV-2) are adequately presented and
accessible through EATMA tool.
The following table shows the group of clusters and use cases validated with its main description:
Cluster 1: Led by Cluster 2: Led by FRQ Cluster 3: Led by DSNA Cluster 4: Led by LDO
Indra
UC1: Drone Performing UC1: Airspace UC1: Flight authorisation UC1: Collaborative
Navaid calibration constraints management Interface for emergency
and information sharing originated from ATM and
application of Dynamic
Airspace Reservation for
management
UC2: Drone performs a UC2: Strategic de- UC2: Start of flight UC2: Application of
Navaid calibration confliction involving Dynamic airspace
interrupted by a approval from ATC Reservation for
manned aircraft management of UAS
operation operation in ATZ in case
of IFR departure/arrival
UC3: Drone performs UC3: Tactical UC3: Emergency originated

scheduled aerial contingency / emergency by ATS Operation
works– Flight Plan situation
submission for
approval
Page I 40
UC4: Drone performs UC4: Two-way

scheduled aerial works communication between
– Mission (tactical) ATS and UAS Pilots
UC5: Drone performs UC5: Common

scheduled aerial works situational awareness,
- Flight Plan crosses monitoring and
two countries significant change of
trajectory
UC6: Drone performs

scheduled aerial works
– Mission (Tactical).
Two countries.
UC7: Drone suffers a

failure triggering a
Non-nominal situation
Table 1: Clusters and use cases associated to PJ34-W3-01
In order to address which services are covered under which use cases, the traceability to be considered
is shown in the following table:
IEX1
IEX2 IEX3 IEX4
Operational IEX5
Geofencing Tracking Traffic Non-
Use plan Tactical
Cluster Information Information Conformance
case Information Op.
Exchange Exchange Monitoring
exchange messages
Service Service Service
service
UC 1 X X
UC2 X X X
UC3 X
CL 1 UC4 X X X X
UC5 X
UC6 X X X X
UC7 X X X
UC1 X X X
CL 2 UC2 X X X
UC3 X X X X X
Page I 41
UC4 X X X
UC5 X X X
UC1 X
CL 3 UC2 X
UC3 X X
CL 4 UC1 X X X X X
Table 2: Clusters and use cases traceability against collaborative services of PJ34-W3-01
4.1 Cluster 1 Operational views
Figure 7: Cluster 1- Use Case 1 - NOV-5 view
Page I 42
Page I 43
Page I 44
Page I 45
4.2 Cluster 1 Technical views
Figure 14: Cluster 1 - NSV-1 view
Page I 46
Figure 15: Cluster 1- Use Case 1 - NSV-4 view
Page I 47
Page I 48
Page I 49
Page I 50
Figure 22: Cluster 2 - Use Case 1 - NOV-5 view
Page I 51
Page I 52
Figure 24: Cluster 2 - Use Case 3 (Part I) - NOV-5 view
Figure 25: Cluster 2 - Use Case 3 (Part II) - NOV-5 view
Page I 53
Page I 54
Page I 55
Figure 29: Cluster 2 - Use Case 1 - NSV-4 view
Page I 56
Figure 31: Cluster 2 - Use Case 3 (Part I) - NSV-4 view
Page I 57
Figure 32: Cluster 2 - Use Case 3 (Part II) - NSV-4 view
Page I 58
Page I 59
Page I 60
Page I 61
Page I 62
Figure 38: Cluster 3 - Use Case 1&2 - NSV-4 view
Page I 63
Page I 64
Page I 65
Page I 66
Follow us
Follow us on social media
Follow us on social media @ SESAR_JU
on social media @ SESAR_JU

SESAR 3 Joint Undertaking
Follow us
on social media @ SESAR_JU SESAR 3 Joint Undertaking www.youtube.com/SESARJU
@ SESAR_JU
SESAR 3 Joint Undertaking www.youtube.com/SESARJU
SESAR 3 Joint Undertaking
www.youtube.com/SESARJU www.youtube.com/SESARJU
Cover: © Bluenest urban vertiport designed by luis+vidal architects
PDF ISBN 978-92-9216-204-7 doi:10.2829/207917 MG-07-23-357-EN-N

U-Space CONOPS 4th Edition

Uploaded by

Copyright:

Available Formats

U-Space CONOPS 4th Edition

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

U-Space CONOPS 4th Edition

Uploaded by

Copyright:

Available Formats

U-SPACE CONCEPT OF

U-space ConOps and

Authoring & Approval

Authors of the document

Reviewers internal to the project

Reviewers external to the project

Rejected By - Representatives of beneficiaries involved in the project

3.19 Vertical Conversion Service .......................................................................................... 73

Table 2 ICARUS services ........................................................................................................................ 32

Table 3 X Y Z Volumes ........................................................................................................................... 32

Table 5 Geo-awareness services in EU regulation ................................................................................ 54

Table 7: U-space Services cross reference ............................................................................................ 76

Table 8: U-space stakeholders .............................................................................................................. 98

Table 9 Acronyms ................................................................................................................................ 114

Table 10 Terminology .......................................................................................................................... 114

Figure 2 Urban Air Mobility Venn diagram ........................................................................................... 19

Figure 3: Timeline schema of the lifecycle of a U-plan ......................................................................... 20

Figure 4 Verification of the design of a UAS (diagram from EASA) ....................................................... 21

Figure 5: Air taxiing and Ground movement vertiport configuration ................................................... 40

Figure 6: Vertiport Classification from Operations Perspective [23] .................................................... 41

Figure 7 U-space services ...................................................................................................................... 47

Figure 8 Flight authorisation in EU IR 2021/664 ................................................................................... 58

Figure 9 Flight Authorisation flow chart including RTTA ....................................................................... 59

Figure 10 Area-based and Linear 4D trajectories, in green................................................................... 61

Figure 11 Deviation thresholds for two non-conflicting U-plans .......................................................... 62

Figure 13 AURA scenario with airspace predominantly controlled by ATC .......................................... 72

Figure 14 AURA scenario with airspace predominantly U-space .......................................................... 72

Figure 15 EU IR 2019/947 and U1 U-space services.............................................................................. 77

Figure 16 EU IR 2021/664 (default), 2021/665 and U2/U3 services (1)................................................ 77

Figure 19: U-space Stakeholders, shown in aggregation. ..................................................................... 99

Figure 20: information exchanges, informal presentation ................................................................. 100

Figure 22: Generic U-space system breakdown .................................................................................. 102

1.1 What is a ConOps

1.2 U-space Concept of Operations edition 4 compared to ed 3

The latter three bullets are expanded below.

1.2.1 The scope and impact of EU regulations

1.2.2 Impactful research projects

1.2.3 The key differences between edition 3 and edition 4

1.2.3.2 How the services differ between editions 3 and 4

1.3 What is in the scope of this ConOps

1.3.2 Urban Air Mobility

 above urban areas, at least for part of the flight,

1.3.4 Not in scope

1.4 Expected evolution of U-space

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

 Availability of the U-space services

1.4.2 Before 2023: the foundations of U-space

1.4.3 Initial U-space implementation (2023-2030)

 U-space airspaces are defined:

communications, navigation and surveillance will improve. Confidence in the Communication,

1.4.4 General U-space (2030-…)

1.4.5 Advanced U-space

1.4.6 Full U-space Integration

1.5 The structure of this ConOps and how to read it

Five documents are provided in annex to this ConOps.

 U-space ConOps Architecture Annex 1.0, “U-space ConOps - Architecture Annex_1.0.docx”.

o Definition of the Operational Framework

2.1 Urban Air Mobility

 Mobility: someone or something is made able to move