sesar 2020 - 763601 - d2.3 - scenarios and requirements ... · description, incl. justification for...

SESAR 2020 - 763601 - D2.3 - Scenar-ios and Requirements - Update to D2.1

DeliverableID [D2.3]

ProjectAcronym DroC2om

Grant: 763601 Call: H2020-SESAR-2016-1 Topic: RPAS-05 DataLink Consortium coordinator: AAU Edition date: [30 October 2018] Edition: [02.03.00.00] Template Edition: 02.00.00

EXPLORATORY RESEARCH

EDITION [02.03.00.00]

© – 2018 – Thales Alenia Space, Aalborg University, Nokia Bell Labs, atesio GmbH. All rights reserved. Licensed to the SESAR Joint Undertaking under conditions.

Authoring & Approval

Authors of the document

Name/Beneficiary Position/Title Date

Nicolas Van Wambeke WP2 Leader / TAS 30/1010/2018

Troels B. Sørensen Project Coordinator / AAU 30/1010/2018

Istvàn Kovacs Task Contributor / NBL 30/1010/2018

Jeroen Wigard Task Contributor / NBL 30/1010/2018

Benjamin Hiller Task Contributor / atesio GmbH 30/1010/2018

Matthieu Clergeaud Task Contributor / TAS 30/1010/2018

Reviewers internal to the project


Troels B. Sørensen Project Coordinator / AAU 30/1010/2018

Istvàn Kovacs Task Contributor / NBL 30/1010/2018

Andreas Eisenblätter Task Contributor / atesio GmbH 30/1010/2018

Approved for submission to the SJU By - Representatives of beneficiaries involved in the project


Nicolas Van Wambeke TAS 30/10/2018

Troels B. Sørensen AAU 30/10/2018

Jeroen Wigard NBL 30/10/2018

Andreas Eisenblätter atesio GmbH 30/10/2018

Rejected By - Representatives of beneficiaries involved in the project


Document History

Edition Date Status Author Justification

00.01.00 Draft Nicolas Van Wambeke Structure defined

01.00.00 Draft Nicolas Van Wambeke Content included

01.01.00 12/03/18 Draft Nicolas Van Wambeke Content updated w. Nokia input

SESAR 2020 - 763601 - SATELLITE SYSTEM CONCEPTS SOLUTIONS FOR HIGH RELIABILITY UAS DATA LINKS

© – 2018 – Thales Alenia Space, Aalborg University, Nokia Bell Labs, atesio. All rights reserved. Licensed to the SESAR Joint Undertaking under conditions.

3

01.02.01 13/03/18 Draft Nicolas Van Wambeke Content updated w. atesio input

01.03.00 27/03/18 First Release Matthieu Clergeaud Revised version including internal reviewer’s comments, to be submitted for approval

02.01.00 17/10/18 Update for D2.3 Draft

Nicolas Van Wambeke Revision of Requirements, Extension of scenarios description, incl. justification for Requirements and allocation to WP

02.02.00 30/10/18 D2.3 Final Nicolas Van Wambeke Final Version resolving all internal comments on the document

02.03.00 10/12/10 D2.3 Updated Final M. Clergeaud Update after review by SJU

Copyright Statement © – 2018 – Thales Alenia Space, Aalborg University, Nokia Bell Labs, atesio GmbH.

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

EDITION [02.03.00.00]


DroC2om DRONE CRITICAL COMMUNICATIONS

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

Abstract

The key objectives of Scenarios and Requirements document are, first, to describe typical use-case scenarios for small to medium-size drones in rural as well as in urban areas, and, second, to derive requirements from these example operational scenarios for the following:

the Command and Control (C2) Link system itself, which is the main focus of the project DroC2om

the demo-capable simulation software-based evaluation environment, whose purpose is to assess the drone connectivity capabilities in realistic simulations at system/network level



5

Table of Contents

1 Introduction ............................................................................................................... 7

2 Definition of Scenarios ............................................................................................. 12

3 Requirements for the C2 Link .................................................................................... 28

4 References & Bibliography ....................................................................................... 50

Appendix A – Rationale for Traffic Profile Definition .................................................. 51

List of Tables Table 1: Abbreviations ............................................................................................................................. 9

Table 2: Terminology and definitions .................................................................................................... 10

Table 3: Summary of Infrastructure Monitoring for Long Endurance Drone ........................................ 14

Table 4: Summary of Urban Fast-Delivery Service by Drone ................................................................ 23

Table 5: Summary of the characteristics of C2 Link Traffic Profile ........................................................ 37

Table 6: Requirements for aerial vehicles connectivity services (Table 5.1-1 [5]) ................................ 37

Table 7: Selected radio communication requirements for CNPC/C2 at PHY layer ............................... 38

Table 8: Command Average Rates ........................................................................................................ 53

Table 9: Control Average Rates ............................................................................................................. 54

Table 10: ATC Voice Relay Message Average Rates ................................................................................ 1

Table 11: ATC Data Relay Message Rates and Sizes (En Route) .............................................................. 1

Table 12: ATC Data Relay Message Rates and Sizes (Departure) ............................................................ 2

Table 13: ATC Data Relay Message Rates and Sizes (Arrival) .................................................................. 2

Table 14: ATC Data Relay Message Rates and Sizes (Totals) ................................................................... 2

Table 15: Situational Awareness Rates and Sizes (Overhead included) .................................................. 2

Table 16: Situational Awareness Total Rates and Sizes (Overhead included) ........................................ 3

List of Figures Figure 1 – Assumptions for the U-Space services and capabilities active for each phase of flight [9] . 12

Figure 2 – Summary Illustration of Infrastructure Monitoring for Long Endurance Drone .................. 13

EDITION [02.03.00.00]


Figure 3 –Summary of C2 Link Involvement in U-Space Service Provision for Scenario 1 .................... 18

Figure 4 - Summary Illustration of Delivery Service by Drone .............................................................. 19


Figure 6 - Summary Illustration of Urban Fast-Delivery Service by Drone ............................................ 22


Figure 8 – Data routing between Pilot, UA, and Control Center ......................................................... 51



7

1 Introduction1

1.1 Purpose and Scope

In the framework of the DroC2om project, WP2 is responsible for the definition of the use cases and scenarios to be considered as context for the activities of the other WPs of the project. In addition to this, for each identified scenario, an analysis of the role and requirements for the Command and Control (C2) Link to support safe operations of the vehicle should be performed from which require-ments are formalized and derived. Furthermore, WP2 determines and establishes a set of generic KPIs to be used to evaluate the solutions proposed by the project.

The deliverable describes operational scenarios to be considered by the project as well as the re-quirements that need to be taken into account when building the different sub-systems in WP3 and WP4. Two releases of the document are foreseen. The present document constitutes the final re-lease of this document, it supersedes the first release contained in D2.1 and documents the defini-tions and assumptions that have been used in the project.

1.2 Structure of this document

This document is structured as follows:

- The first section (this one) describes the context, purpose and scope of the document as well as identifies relevant documents and defines abbreviations and terms that are specific to the domain used in this document.

- The second section deals with the definition of scenarios, establishes, for each of them, the role of the C2 Link in support for safe operations of the drones and provides the context to the derivation of requirements for the link.

- The third section captures and formalizes the C2 link requirements emerging from the defini-tion of the scenarios and the analysis performed previously.

- Finally, the fourth section describes the overall KPIs to be used for evaluation of the solu-tion’s fitness to the various scenarios.

1 The opinions expressed herein reflect the authors’ view only. Under no circumstances shall the SESAR Joint

Undertaking be responsible for any use that may be made of the information contained herein.

EDITION [02.03.00.00]


1.3 Abbreviations & Definitions

Abbreviation Explanation

3GPP 3rd

Generation Partnership Project (cellular systems)

4G 3GPP UMTS-LTE (E-UTRAN) 4th

generation cellular systems (aka LTE)

5G 3GPP 5th

generation cellular systems

CNPC Command and Non-Payload Communication. Depending on the kind of integration of the drone, CNPC may include:

C2 (Command and Control) [mandatory]

ATC data/voice [mandatory for safe integration of RPAS into civil airspace]

DAA /situational awareness [mandatory for safe integration of RPAS into civil airspace]

C&C / C2 Command and Control

DAA Detect & Avoid. This term is generally preferred to Sense & Avoid.

FWD Forward Link. From Cellular Network/Satellite Ground Segment to drone. This term will be used in the document in place of the following domain-specific terms

Cellular Network to drone “Downlink”

Combination of

o “Satellite Ground Segment to satellite” link +

o “Satellite to drone” link

The opposite concept is named RTN (Return Link)

eNodeB (eNB) E-UTRAN Node B (base station)

gNB 5G Node B

ICAO International Civil Aviation Organization

IP Internet Protocol

IPv4 IP version 4

IPv6 IP version 6

JARUS Joint Authorities for Rulemaking of Unmanned Systems

KPI Key Performance Indicators

LTE 3GPP UMTS Long Term Evolution (Release 8-9)

LTE-A, LTE-Advanced

3GPP UMTS Long Term Evolution Advanced (Release 10-15)

GBR Guaranteed Bit Rate

gNodeB (gNB) Next generation NodeB (5G)

OPA Operational Performance Analysis/Assessment

PiC Pilot in Command

PHY Physical layer (communication protocol)



9

RAN Radio Access Network

RPAS Remotely Piloted Aircraft System

RRM Radio Resource Management

RTN Return Link. From drone to Cellular Network/Satellite Ground Segment. This term will be used in the document in place of the following domain-specific terms

Drone to Cellular Network “Uplink”

Combination of

o “Drone to satellite” Link +

o “Satellite to Satellite Ground Segment” Link

The opposite concept is named FWD (Forward Link)

SAT Satellite System/Network

SATPL Satellite Transparent payload (supported by Platform)

SPA System Performance Assessment

UA Unmanned Aircraft

UAV Unmanned Aerial Vehicle. The term “drone” is used preferably throughout the document.

UE User Equipment (3GPP 4G/5G)

UL Uplink radio communication, drone-to-network. RTN is preferred.

U-Space See Table 2 for more information

Table 1: Abbreviations

EDITION [02.03.00.00]


Term Definition

C2 Link “Command and Control” Link, a data link established between a remote PiC (in case of RPAS) or automated system, and the drone it is controlling. This link is used to exchange data necessary for the Aviate, Navigate, Communicate functions of the airborne platform. This is different from the “Payload Communication” link that is used to carry data related to the mission of the drone from a customer point of view.

Drone The term refers to an unmanned aerial vehicle (UAV), whether this vehicle

is semi-autonomous or fully autonomous to conduct its flight, or

is remotely piloted (RPAS) by a PiC

Payload The term payload designates the equipment that is hosted on a physical platform for the purpose of performing the mission.

The term payload can be used in reference to a drone payload (i.e. the equipment on-board the drone that is used by the drone to perform its mission, e.g. sensors or cameras used to examine a given geographical area).

The term payload can be used in reference to a Satellite Payload (i.e. the equipment on-board a satellite that is used by the satellite to perform its mission, e.g. a transparent signal repeater in a telecommunication satellite or an optical equipment in an earth observation satellite).

Payload Communication

Communication between the Payload on-board a UAV and a mission control centre on the ground for the purpose of mission control (possibly real time).

Payload communication is not part of C2, although both may be carried on the same physical link; in this particular case, provision is likely needed to ensure the C2 Link requirements as per the scenario.

PiC / Pilot in Command

As per ICAO Annex 2 to the Chicago Convention, “Rules of the Air”: The pilot-in-command of an aircraft shall, whether manipulating the controls or not, be responsible for the operation of the aircraft in accordance with the rules of the air, except that the pilot-in-command may depart from these rules in circumstances that render such departure absolutely necessary in the interests of safety.

U-Space U-Space is a set of new services relying on a high level of digitalisation and automation of functions and specific procedures designed to support safe, efficient and secure access to airspace for large numbers of drones. As such, U-Space is an enabling framework designed to facilitate any kind of routine mission, in all classes of airspace and all types of environment – even the most congested – while addressing an appropriate interface with manned aviation and air traffic control / ATC

Table 2: Terminology and definitions



11

1.3.1 Definition of Availability

When not explicitly specified otherwise in this document, the term availability used on its own refers to the Average Uptime Availability as defined below

Instantaneous (or point) availability: This is the probability that a service (or system) will be opera-tional (up and running) at any random point in time, t. This is similar to the reliability function in that it gives a probability that a system will function at the given time, t. Unlike reliability, the instantane-ous availability measure incorporates maintainability information. At any given time, t, the System will be operational if the following condition is met:

The System functioned properly from 0 to t with probability R(t) or it functioned properly since the last repair at time u, 0 < u < t, with probability:

∫ ( ) ( )

With m(u) being the renewal density function of the system.

Then, the point availability is the summation of these two probabilities, namely:

( ) ( ) ∫ ( ) ( )

Average Uptime Availability (or Mean Availability): The mean availability is the proportion of time during a mission or time period that the system (or service) is available for use. It represents the mean value of the instantaneous availability function over the period (0, T] and is given by:

( )

∫ ( )

Availability of provision: The probability that the service is operational considering all users are in the coverage area.

Availability of use: The probability that the service between two given parties is operational when needed.

EDITION [02.03.00.00]


2 Definition of Scenarios

This section describes three scenarios that are considered for the evaluation and demoing of the C2 Link in the framework of the DroC2om project. The objective is to identify requirements used by the software-based evaluation environment developed in WP3 and described in Section 2.2. The inten-tion is to make use of these exploratory scenarios as guidelines for the implementation of one refer-ence scenario and one demo scenario, as outcomes of WP3.

Apart from helping identifying requirements for the evaluation software, a performance requirement (related to the C2 Link system itself) is also proposed for each use case. Section 3 focusses on other requirements that are generally C2 Link system.

2.1 Exploratory scenarios

Three scenarios have been defined: “Infrastructure Monitoring for Long Endurance Drone”, “Delivery Service by Drone”, and “Urban Fast-Delivery Service by Drone.” The three scenarios are summarized in Figure 1, relating to the operational aspects in each scenario, and focussing on the role of C2 dur-ing the various phases of the flight and the interactions with other U-Space services. This is aligned with the CORUS published CONOPS [9]. As many operational aspects are identical among the three, they are provided only for the first scenario (and referenced for the remaining).

Figure 1 – Assumptions for the U-Space services and capabilities active for each phase of flight [9]

Dron

e ae

rona

utica

l

info

rmat

ion

man

agem

ent

Pre-

tact

ical g

eo-fe

ncin

g

Wea

ther

info

rmat

ion

Traf

fic in

form

atio

n

Fligh

t Plan

ning

Man

agem

ent

E-Re

gist

ratio

n

Stra

tegic

Dec

onfli

ctio

n

Tact

ical g

eo-fe

ncin

g

Mon

itorin

g

Emer

genc

y Man

agem

ent

E-id

entif

icatio

n

Trac

king

Terrain,

Build

ings

, Obs

tacles

,

Pop

ulat

ion

map

s

Lega

l Rec

ording

Acc

iden

t and

Incide

nt R

epor

ting

Pre-flight

Check flight conditions

Operator Flight Planning

Autorisation

Strategic conflict management

Report flight position

Emergency management

Update Flight conditions

Pre-flight

Check flight conditions

Create and File

the flight plan

Flight Preparation

Flight

Start-up

Take-off

En-Route

Mission

Landing



13

2.1.1 Scenario I: Infrastructure Monitoring for Long Endurance Drone

2.1.1.1 Summary of the Scenario

Figure 2 – Summary Illustration of Infrastructure Monitoring for Long Endurance Drone

Scenario title Infrastructure Monitoring for Long Endurance Drone

Kind of drone (mass/volume/…):

In range 25kg - 150kg, Endurance of 10h Maximum speed of 150kph

Objective of the scenario: Infrastructure monitoring for large scale applications (oil pipelines, railway tracks, energy distribution systems, …)

Brief description

Take-off from urban/city drone base, Climb phase to cruise altitude below 500ft, Fly-by-objective phase of 700km, Return path identical to forward one Approach Landing

Environment: Mixed urban/rural depending on flight phase

EASA category Specific or certified

C2 Link traffic specifica-tion by phase of flight

Manual command & control for the take-off phase, semi-automated traffic for the cruise (mostly from drone to pilot), semi-automatic landing (higher traffic volume than cruise)

EDITION [02.03.00.00]


Performance require-ments for C2 Link:

In the order of 100 kbps throughput and max. 100 ms one-way delay at take-off and landing

In the order of 10 kbps throughput and max. 1 s one-way delay dur-ing cruise

Minimum 99.9 % reliability and above 99 % availability

Primary/secondary means of C2 Link

Primary link a terrestrial one of take-off and landing with possibly a dual link requirement (packets sent on both links) for these phases, primary link the satellite one for cruise, terrestrial backup only when in coverage.

Table 3: Summary of Infrastructure Monitoring for Long Endurance Drone

2.1.1.2 Detailed Scenario Description

2.1.1.2.1 The role of the C2 Link in support of pre-flight operations

Before the pre-departure operational phase takes place, in particular when long endurance drones are to be used, the drone operator would most of the time prepare a flight plan and obtain authori-zation to proceed to the flight. This preparatory step would require that the drone operator’s C2 Link system certifies it has the sufficient capacity for all flight phases and interacts with U-Space dynamic capacity management service to that purpose.

Once the flight has been planned, the pre-departure phase involves a series of operations designed to guarantee that the drone is in adequate conditions for the flight it is about to perform and that the systems are operating in their nominal mode. Additionally, the pilot is required to conduct a se-ries of administrative tasks in order for the flight to take place.

During this phase, the drone does not need to be located near the pilot (or Remote Pilot Station) in contrast to what is the case in manned aviation. The inspection of the drone systems can thus only be performed in two steps:

- Locally by appropriately skilled personnel physically close to the drone

- Remotely by the pilot to check consistency between the reports of the local personnel and the indications provided by the drone through the C2 Link

Furthermore, if a test of the actuators used for manual control is to be performed as part of the pre-flight checks, this test should be performed jointly to verify that the overall interactions between the pilot and the drone are in good working conditions.

Once the initial checks are performed, the remote pilot needs to upload data, which is specific for the flight in U-Space, to the drone through the C2 Link. In the case of the present scenario, this data in-cludes geo awareness data, geo-fencing areas definitions, possibly initial situation awareness data as well as configuration and test of S&A equipment, weather data, other data needed for the flight such as a list of waypoints, emergency behavior setup, and other air navigation related exchanges. Re-quirements for the C2 Link are modest during this phase, relaxing both delay and throughput.



15

Given the long endurance flight foreseen in this scenario, it is possible that the drone does not have capacity to store data for the whole duration of the flight. In that case, an initial set of information is transmitted and the subsequent data will be transmitted subsequently during the flight, using the C2 Link.

2.1.1.2.2 The role of the C2 Link in support of flight operations

Following the pre-flight, the flight can take place. This section details the role of the C2 Link in sup-port of the different phases of flight.

2.1.1.2.2.1 Take-off and departure

For take-off and departure, the C2 Link is used to transmit flight commands to the drone and receive monitoring information from the drone to the drone operator – useful monitoring data is next shared by drone operators to U-Space service providers. Should the take-off require a runway and the drone be equipped with an automated taxi function, the exchanges during this phase will be reduced com-pared to a manual taxi.

Given the nature of the drone mission, the take-off is considered to be a manual operation per-formed by the operator. The C2 Link will, during the take-off phase, relay commands from the re-mote pilot to the drone and provide the remote pilot with telemetry data from the drone in order for her or him to steer the drone in an appropriate fashion. If video transmission in FPV (First Person View) is considered to be a requirement for this phase of flight, its transmission is performed through the C2 Link. A high-level safety analysis shows that the requirements on the data link to be used in this part of the scenario are high. Indeed, any delay in delivery of the data packets to and from the drone can lead to hazardous to catastrophic outcomes. For this reason, the delay and jitter are criti-cal to maintain as low during this phase.

Once the take-off is completed, the drone will execute a semi-automated departure procedure lead-ing it to the first waypoint of its flight plan. Indeed, while the operations are performed automatically by the drone using a pre-programmed routing, which was uploaded during the pre-flight phase, the aviate and navigate functions are performed by the drone software itself under the supervision of the remote pilot. In this phase, the requirements for the C2 Link performances are lower than for the take-off phase. Indeed, the pilot is not directly interacting with the drone actuators anymore as a baseline, but is now supervising that the operations performed by the drone software (information reported through the C2 Link) are coherent with the plan as well as the evolving state of the airspace, which the remote pilot receives through the U-Space service providers.

Specifically, during this first phase of flight, the C2 Link is used to transmit the following data towards the remote pilot that could be of use to other U-Space services:

- Drone identifier

- Drone position (used by the remote pilot for location and tracking and monitoring purposes)

- Monitoring information useful for legal recording of the flight events (for future analysis in case of problems)

Depending on the drone’s capabilities, the following data could be of use to U-Space services:

- Detect And Avoid data if equipped

EDITION [02.03.00.00]


- Other sensor data could be fused by the U-Space Traffic Information service (e.g., detection of other aircrafts

Additionally, during this phase, the pilot is able to upload new dynamic data to the drone such as new temporary no-fly zones, traffic information, flight plan changes… that he receives or establishes in accordance to information exchanged with U-Space services in real-time.

2.1.1.2.2.2 En route

For the en route phase, the drone evolves in multiple airspaces (always below 500ft). Given the long range of its operations, interactions with Air Traffic Control or Air Traffic Services is a requirement. For these interactions, the drone is equipped with the appropriate communication means (VHF radio and/or CPDLC (Controller Pilot Data Link Communication) application). Communication is performed in a seamless fashion with the infrastructure in the surroundings of the drone just as if the pilot was inside the vehicle. To achieve this, ATC and/or ATS communications are relayed through the C2 Link to the remote pilot. The replies from the remote pilot are in turn transmitted to the drone via the C2 Link and transmitted towards the ATC and/or the other airspace users (depending on the communi-cation technology) using the onboard equipment.2 For ATC voice, the requirements are even more stringent than for ATC data communications as the jitter is also an important factor to avoid interrup-tions in the packetized voice reconstruction. The time interval between packets is important for these applications. The value of the jitter has a direct impact on the required buffering on the receiv-er side in order to avoid under-runs (causing interruptions in audio reconstruction). The lower the jitter, the smaller the required buffer.

In addition to ATC interactions, all the onboard functions that are foreseen and described in the de-parture and take-off section are supported by the C2 Link. As such, data from the drone is continu-ously transmitted to the remote pilot for tracking and monitoring of the drone evolution and the onboard systems status. Furthermore, data about other airspace users is exchanged both ways (from the drone, data about the sensed environment is transmitted and data about the planned future environment, such as temporary no-fly zones and other traffic forecasts are transmitted from the pilot to the drone).

Once it is out of coverage of the terrestrial networks, the drone relies on the satellite link to maintain the C2 Link functionality. This hand-off is performed in a seamless fashion and does not require hu-man intervention. The pilot nevertheless is informed of the physical link used for provision of the C2 Link at all times. For some phases of flight, the safety analysis might conclude that multiple physical links should be combined and used simultaneously in order to ensure the appropriate level of per-formance. The DroC2om approach makes this combined use transparent to both the drone and the remote pilot.

2 For communications, the definition of a “Required Communication Performance” can be found in the ICAO

published GOLD document. An RCP is defined as a metric of the time for a given controller/pilot interaction to take place and is defined as the moment from which one of the parties determines that the other should take action and the moment that this same party is able to observe that the other party has taken action.



17

During the en route phase the Drone Mission Operator interacts with the drone’s payload to perform the monitoring of the infrastructure that constitutes the drone mission. This interaction does not take place using the C2 Link, but is performed using a different link dedicated to the operation of the drone’s mission. For the purpose of the mission, the Drone Mission Operator could interface with the Drone Operator and request specific actions to be performed by the drone. In that case, the C2 Link will be used by the drone pilot to perform the requested actions in accordance with the current state of traffic in the area and other elements known to the pilot either from the drone sensors (ex-changed through the C2 Link) or obtained from U-Space.

2.1.1.2.2.3 Approach and landing

The final phases of flight are, from a C2 Link point of view, similar to the take-off and departure phase. In this scenario, the landing is considered to be semi-automatic. In this context, the amount of interactions between the remote pilot and the drone are reduced compared to take-off.

The remote pilot will initiate the approach and landing procedure in accordance with the clearance and information received from U-Space. The actions required for this initiation and the exchanges that it implies are performed using the C2 Link. In this phase, the volume of data to be transmitted about the sensed environment increases due to the higher transmission frequency for a closer loop between the remote pilot and the drone. While the procedure is considered to be semi-automatic, the remote pilot can regain control at any time to either enter into manual mode or to initiate a pre-defined sequence such as the one for emergency management.

EDITION [02.03.00.00]


2.1.1.2.3 Summary of C2 Link involvement in U-Space service provision

Figure 3 –Summary of C2 Link Involvement in U-Space Service Provision for Scenario 1

Analyse

Flight

planning

Pre-

departureTaxi-out

Take-off

/ Climb

Cruise

over land

Cruise over

sea

Mission

Execution

Approach

/ LandingTaxi-in Post-flight

Drone ID

GNSS computed position First Fix

Flight commands Testing

Drone internal systems data Status

Geofencing data Initial Update Update Update Update

Link monitoring

Voice and data exchanged with ATC High High

First Person View video stream High High

Detect And Avoid data

Emergency data

Flight automation level (Auto/Semi/Manual) SEMI MANUAL SEMI SEMI MANUAL SEMI

Environment URBAN URBAN RURAL OFFSHORE URBAN URBAN

Cellular Network access PRIM. PRIM. DUAL SEC. PRIM. PRIM.

Satellite Network access SEC. SEC. DUAL PRIM. SEC. SEC.

Drone aeronautical information management

Pre-tactical geo-fencing

Weather information

Traffic information

Flight Planning Management

E-Registration

Strategic Deconfliction

Tactical geo-fencing C2 C2 C2 C2 C2

Tactical deconfliction C2 C2 C2 C2

Monitoring C2 C2 C2 C2 C2 C2

Emergency Management C2 C2 C2 C2

E-identification C2 C2 C2 C2 C2 C2 C2

Tracking C2 C2 C2 C2 C2 C2

Procedural interface with ATC C2 C2 C2 C2 C2 C2

Collaborative interface with ATC C2 C2 C2 C2 C2 C2

Dynamic capacity management C2 C2

Mapping services

Legal Recording

Accident and Incident Reporting

Oth

er

serv

ices

Infrastructure Monitoring for Long Endurance Drone

Ph

ase-

dep

end

ant

U-s

pac

e p

lan

ned

ser

vice

s

Prepare Execute

Dat

a o

ver

C2

No data

transmitted

over C2 for

the purpose

of the

mission



19

2.1.2 Scenario II: Delivery Service by Drone in Open Environment


Figure 4 - Summary Illustration of Delivery Service by Drone

Scenario title Delivery service by drone


Medium sized drone

Objective of the scenario: Last mile packet delivery in open environment

Brief description

Take-off from a delivery truck or off urban/city base, Climb phase to cruise altitude of 100 m, Fly to destination pick-up location 2 km away, Land and leave package, Return to delivery truck/base (incl climb, fly and land phase)

Environment: Open environment – rural, industrial area, village

EASA category Specific

C2 Link traffic specifica-tion by phase of flight

Semi-automatic take-off and landing (Real-time monitoring with support for direct/manual control at destination pick-up)

Fully automated or semi-automatic for the cruise (mostly from drone to pilot)

EDITION [02.03.00.00]



In the order of 100 kbps throughput and max. 100 ms one-way delay at take-off, landing and during cruise

In the order of 10 kbps throughput and max. 1 s one-way delay when satellite backup link is used



Primary cellular network with satellite as backup if there is no cov-erage



Same roles and condition apply as described in Section 2.1.1.2.1.


Same roles and condition apply as described in Section 2.1.1.2.2.

The availability of the C2 Link must be above 99%, i.e. the Drone Mission Operator must have con-nectivity with the drone at any given time during the flight mission.


Same roles and condition apply as described in Section 2.1.1.2.2.1.

2.1.2.2.2.2 En route

Same roles and condition apply as described in Section 2.1.1.2.2.2.

The Drone Mission Operator potentially interacts with the drone’s payload to perform the monitor-ing of the delivered payload.


Same roles and conditions apply as described in Section 2.1.1.2.2.3, except the landing at delivery is more challenging that upon return, where the landing zone can be controlled. One can imagine spe-cific destination pick-up locations located in open environment. However, since they are not fully controlled, this landing phase may need more interactions than the return, similar to take-off, de-spite both can be semi-automatic.

The Drone Mission Operator interacts with the drone’s payload to perform the registration and mon-itoring of the correct payload delivery and for the potential pick-up/registration of a new payload.



21

2.1.2.2.3 Summary of C2 Link Involvement in U-Space Service Provision


Analyse

Flight

planning

Pre-

departureTaxi-out

Take-off

/ Climb

Cruise

over land

Cruise over

sea

Mission

Execution

Approach


Drone ID




Geofencing data Initial Update Update Update

Link monitoring




Emergency data

Flight automation level (Auto/Semi/Manual) SEMI SEMI AUTO SEMI SEMI

Environment URBAN URBAN URBAN URBAN URBAN

Cellular Network access PRIM. PRIM. DUAL PRIM. PRIM.

Satellite Network access SEC. SEC. SEC. SEC. SEC.



Weather information

Traffic information


E-Registration


Tactical geo-fencing C2 C2 C2 C2

Tactical deconfliction C2 C2 C2

Monitoring C2 C2 C2 C2 C2

Emergency Management C2 C2 C2

E-identification C2 C2 C2 C2 C2 C2

Tracking C2 C2 C2 C2 C2

Procedural interface with ATC C2 C2 C2 C2 C2

Collaborative interface with ATC C2 C2 C2 C2 C2


Mapping services

Legal Recording


U-s

pac

e p

lan

ned

ser

vice

sO

ther

serv

ices

Urban Fast-Delivery Service by DronePrepare Execute

Dat

a o

ver

C2

No data

transmitted

over C2 for

the purpose

of the

mission

Ph

ase-

dep

end

ant

EDITION [02.03.00.00]


2.1.3 Scenario III: Urban Fast-Delivery Service by Drone


Figure 6 - Summary Illustration of Urban Fast-Delivery Service by Drone

Scenario title Urban Fast-Delivery Service by Drone


Medium sized drone

Objective of the scenario: Point-to-Point time critical packet delivery

Brief description

Take-off from a building rooftop base (e.g. hospital#1), Climb phase to cruise altitude of 100-300 m, Fly to destination up to 5 km away, Land and leave package on rooftop (e.g. hospital#2), Return to base (incl climb, fly and land phase)

Environment: Urban or dense-urban

EASA category Specific

C2 Link Traffic specifica-tion by phase of flight

Real-time monitoring with support for direct/manual control


In the order of 100 kbps throughput; max. 100 ms one-way delay at take-off, landing and during cruise



23

In the order of 10 kbps throughput and max. 1 s one-way delay when satellite backup link is used



Primary cellular network with satellite as backup

Table 4: Summary of Urban Fast-Delivery Service by Drone



Same roles and conditions apply as described in Section 2.1.1.2.1.


Same roles and conditions apply as described in Section 2.1.1.2.2.

The availability of the C2 Link must be above 99 %, i.e. the Drone Mission Operator must have con-nectivity with the drone at any given time during the flight mission. C2 Link is required to provide reliable coordination mechanism with other fast-delivery services (including emergency cases).


Same roles and conditions apply as described in Section 2.1.1.2.2.1.

2.1.3.2.2.2 En route


The Drone Mission Operator could need to interact with the drone’s payload during this phase of flight, but these exchanges are not performed through the C2 Link.



Note: The Drone Mission Operator must interact with the drone’s payload to perform ‘health-check’ and the registration/monitoring of the correct payload delivery and for the potential pick-up/registration of a new payload. These interactions are not performed through the C2 Link.

EDITION [02.03.00.00]


2.1.3.2.3 Summary of C2 Link Involvement in U-Space Service Provision


Analyse

Flight

planning

Pre-

departureTaxi-out

Take-off

/ Climb

Cruise

over land

Cruise over

sea

Mission

Execution

Approach


Drone ID




Geofencing data Initial Update Update Update

Link monitoring




Emergency data

Flight automation level (Auto/Semi/Manual) SEMI SEMI AUTO SEMI SEMI

Environment URBAN URBAN URBAN URBAN URBAN

Cellular Network access PRIM. PRIM. DUAL PRIM. PRIM.

Satellite Network access SEC. SEC. SEC. SEC. SEC.



Weather information

Traffic information


E-Registration


Tactical geo-fencing C2 C2 C2 C2

Tactical deconfliction C2 C2 C2

Monitoring C2 C2 C2 C2 C2

Emergency Management C2 C2 C2

E-identification C2 C2 C2 C2 C2 C2

Tracking C2 C2 C2 C2 C2

Procedural interface with ATC C2 C2 C2 C2 C2

Collaborative interface with ATC C2 C2 C2 C2 C2


Mapping services

Legal Recording


U-s

pac

e p

lan

ned

ser

vice

sO

ther

serv

ices

Urban Fast-Delivery Service by DronePrepare Execute

Dat

a o

ver

C2

No data

transmitted

over C2 for

the purpose

of the

mission

Phas

e-

dep

end

ant



25

2.2 Requirements for Modelling Reference and Demo Scenarios

A reference scenario is specified as part of WP3. The reference scenario is used for internal evalua-tion and benchmarking, and it is made publicly available. In addition, demo scenarios are considered, which can illustrate specific aspects or which are suitable for representing the project on a website or in presentations. In both cases, the scenarios are developed based on the use scenarios in Section 2.1.1 - 2.1.3.

The following sections detail requirements for different scenario aspects.

2.2.1 Drone Model

There is a large variety of drones, differing in type (e.g., helicopter, multiple rotors, or fixed-wing), size, equipment, and, thus, suitability for different types of missions. The characteristics of a drone determine which trajectories are feasible.

It shall be possible to define and use different types of drones in a scenario. DroC2om focuses on the communication between a drone and its operator. The drone can therefore be modelled regarding the relevant aspects for this type of communication, in particular:

Trajectory model

The trajectory model describes the in-flight behaviour of the drone and thus the limitations of feasible trajectories. To support different kinds of drones, it shall be possible to choose be-tween different dynamic models that are parameterized by the weight, maximum velocity, maximum acceleration/deceleration, etc. For the purposes of the dynamics in this context, it is sufficient to assume that the drone is just a point moving in 3D space.

For purposes of collision detection and avoidance, a minimum distance to any other object (other airspace users, buildings, obstacles) may be used.

Radio equipment model

A drone is equipped with one or more antennas. For each antenna, a 3D orientation relative to the forward direction of the drone is given via an azimuth and a (down-)tilt angle. For the purposes of radio simulation, the drone is again considered as a point in 3D space. In particu-lar, shadowing of any radio signal by physical elements of the drone (e.g. rotors) can only be considered to the extent by which the effect can be incorporated into the antenna model or the receiver / transmitter path within the drone.

The trajectory model is used to derive a trajectory for each drone based on the waypoints of its mis-sion. It is desirable that these trajectories do not intersect with each other nor with forbidden re-gions (geofencing) or obstacles/buildings. This objective be considered when generating trajectories. During the trajectory generation further aspects, such as preferring routes of travel over rivers, min-imizing the crossing of highways, etc., may also be considered.

Some choices for the degree of automation as per the U-Space availability are as follows:

Level 1: Based on U-Space foundation services

EDITION [02.03.00.00]


The trajectory is manually specified and conveyed to the drone via U-Space services, i.e. any intersections have been cleared and resolved by an operator, by specifying additional way-points in the mission description, or by shifting the waypoints in time (provided the conflict depends on timing).

Level 2: Based on U-Space initial services

Based on U-Space services the generated trajectories are checked for intersections with each other and with explicitly specified forbidden regions. Collisions need to be resolved manually as in Level 1, by operator interaction.

Level 3: Based on U-Space advanced services

Based on U-Space services, collision-free trajectories are generated automatically. In addition to avoiding specified forbidden regions, 3D data for buildings may be used to avoid collisions with buildings.

Higher levels of automation incur higher effort for the modelling of drones, which is, however, not the main focus of the project. It needs to be decided during the course of the project which level constitutes a reasonable effort/utility tradeoff.

2.2.2 Drone Mission and Environment Model

A drone mission consists of different phases, see Sections 2.1.1 - 2.1.3. A drone mission starts with a take-off phase and ends with a landing phase. Between the take-off and landing phases, there may be one or more mission phases (en route). The pre-flight and post-flight phases are not taken into consideration for the mission and environment model.

The take-off and landing phase are described by fixed initial and terminal trajectories that take the drone from the take-off site to a starting position for mission and from a terminal position back to the landing site. For instance, for a multiple rotor drone, the initial and terminal trajectories corre-spond to vertical movement from the ground to an initial altitude and from operation altitude to the ground. For fixed-wing drones, the initial and terminal trajectories correspond to take-off and land-ing, combining horizontal and vertical movement.

A mission phase is described by a sequence of waypoint given by 3D coordinates (2D WGS84 coordi-nates and altitude above ground) and possibly a time window. Trajectory planning tries to visit each waypoint within the time window. If this fails, scenario generation is aborted.

Each phase has performance requirements (bandwidth, latency, error rate) for the C2 Link and, op-tionally, for the payload. The necessary bandwidth may be provided by a cellular network, a satellite network, or a combination of both. The performance of the radio links will be evaluated during simu-lation, and a failure of meeting the requirements will be reported.

Static obstacles in the environment may be described by 3D boxes, which have to be avoided by the trajectories of the drones (static geofencing). In addition, temporary obstacles can be modelled by 3D boxes with a time window (dynamic geofencing). The trajectories are computed with the a-priori knowledge of obstacles, i.e., there is no on-line behaviour in reaction of temporary obstacles within a mission.



27

2.2.3 Infrastructure Model

A drone-to-drone-operator communication is facilitated by the provision of C2 Link Service Provider. This ecosystem actor is able to provide the drone operator with a C2 Link, based on radio infrastruc-tures. DroC2om focuses on a C2 Link system that is based on the combination of both cellular and satellite network in a single multilink hybrid system. During any phase of its mission, a drone may establish a radio link with a cellular LTE radio network and/or a geostationary satellite network.

The cellular network is given by a list of sites with sectorisation, sector configuration, and cell config-uration. Radio signals are transmitted and received at antennas, described by type, azimuth, and mechanical (down-)tilt. For the sake of simplicity, each cell shall be associated with only one antenna. (If necessary, however, a more detailed modelling of the cellular network may be used.) If available, 3D data for buildings, structures, etc., is used for computing the path loss in the cellular network. The capability of specifying and simulating temporary failures / outages of cellular network elements is desirable.

The satellite network consists of one or two geosynchronous satellite whose trajectory is considered quasi-geostationary. Gain maps for each spot beam are used to characterize the satellite transmitting and receiving antenna gains. A high level of availability of the satellite network is assumed, so as to consider it as a backup for the cellular network. As the satellite network is essentially be used in the long endurance scenario, a terrain type (sea, earth, mountains, urban area) model is necessary.

For each drone, the software environment uses the network models and combines it with the propa-gation (aero-cellular or aero-satellite) models to determine the link performance indicators at net-work level and at system level.

EDITION [02.03.00.00]


3 Requirements for the C2 Link

Definition of the System

The requirements in this section refer to the system. By system, it should be understood: an imple-mentation instance of the combined satellite and terrestrial DroC2om data link concept used to provide the C2 Link functionality of U-Space.

This section describes the system requirements identified

by the brief operational analysis that allowed the definition of the exploratory scenarios

by inspection of the SJU U-Space documents and other cited reference bibliography

based on the consortium expertise

The system requirements are split into the following categories:

- Performance

- Data links

o Generic Requirements: requirements linked to characteristics that are common to all data links

o Satellite communications

o Terrestrial communications

- Integration of data links: requirements linked to the integration of the various available data links, e.g., redundancy scheme, handovers

- Multi operators

- Interoperability

A Requirement ID is built up as a chain of characters under the following form:

WP2 - Domain name - Type of requirement - Number

1 2 3 4

1. The work package reference; here, it is WP2;

2. A three to five characters chain attached to the domain name;

GENUS: general user needs

SPEUS: specific user needs

INTSE: integration of services



29

PERFO: performances

DATLI: data links

SATCO: satellite communications

TERST: terrestrial communications

AIRCO: airport communications

INTLI: integration of data links

MULOP: multi operators

INTOP: interoperability

3. The first three characters attached to the type of requirement;

FUN: Functional

PER: Performance

DES: Design & Certification

4. Incremental reference number on three digits; the numbering increments whatever the oth-er fields; the maximum value of this reference number corresponds to the number of re-quirements.

In this Section 3, the term “System” refers to the full C2 Link system, as it can be perceived in the future European ATM Masterplan Technical Systems Overview over the next decades in the final U4 phase. An effort has been performed to identify the current or future requirements of such a com-plete system, so as to align with the SESAR Vision for the safe integration of drones. In fact, the two parallel threads of the full integration/evolution of manned and unmanned aviation.

Accommodation of IFR RPAS/ Integration of IFR and VFR RPAS, on the one hand

Development of U-Space services, on the other hand

have led the DroC2om team to envisage the possible (but not necessarily mandatory) inclusion of ATC data/voice relay in addition to the pure Command and Control (C2) Link, as well as DAA data – situational awareness – the same way it is envisaged for the integration of RPAS. The sum of all these service data flows is referred to as CNPC.

For this reason and other ones, the “DroC2om system concept” that the project intends to focus on in the deliverables does not necessarily comply with all listed requirements below. For better under-standing

“may” is used to identify the optional requirements and/or the requirements that the DroC2om system concept will not fully comply with, nevertheless work in the identified im-pacted work package is performed in order to facilitate future compliance with these re-quirements

“shall” is used to identify requirements that constitute the core of the DroC2om system con-cept. These requirements are to be taken into consideration for the elaboration of the DroC2om system concept. They are considered to be the core set to be used in the work per-formed by the work package identified as impacted. Nevertheless, given the nature of the work in the project, compliance with all requirements is not a goal.

EDITION [02.03.00.00]


The following tables list the requirement ID along with a short description of the requirement, the motivation for the requirement, and indication of which DroC2om WP is impacted by the require-ment. Note: by impact we imply that the requirement is relevant for the work in the respective WP(s). The requirement may be partly or fully considered as part of the work, but mostly it serves as a reference to the context where it would need consideration. Some of the requirements have implications far beyond the aim and technology readiness level of DroC2om, and therefore should be seen as in-formative, rather than normative for the DroC2om work. The different WPs will not give specific back reference to the requirements list.



31

3.1 Performance Requirements

Requirement refer-ence

Requirement description Requirement justification DroC2om WP

impacted by Re-quirement

WP2-GENUS-PER-001

The System shall offer, for all addressed data exchanges, an end-to-end availability of provision of at least 99.3 %

The availability of provision target is taken from ATC communication systems in use to-day. It is considered that a C2 Link communi-cation system should provide, at least, the same availability of provision than these sys-tems.

WP2 / WP4

WP2-GENUS-PER-002

The System shall offer, for all addressed data exchanges, an availabil-ity of use of at least 99 %

The availability of use target is taken from ATC communication systems in use today. It is considered that a C2 Link communication sys-tem should provide, at least, the same availa-bility of use than these systems. Indeed, in case of ATC communications relay, this re-quirement is unavoidable in order not to de-grade the communication performance (w.r.t. RCP).

WP2 / WP4

WP2-GENUS-PER-003

The System shall offer integrity performance in terms of packet error rate measured at the interface between network and logical link lay-er of at least 10

-3

The integrity levels are taken from ATC com-munication systems in use today. For C2 Link, a similar level of integrity at physical and logi-cal link layer is adequate since higher layers will most likely improve the end to end per-formance by use of ARQ techniques.

WP4

EDITION [02.03.00.00]


Requirement refer-ence



WP2-GENUS-PER-004

The System may offer, for the relay of ATC voice services, at least following performance:

- Voice latency: 400 ms

- Availability: 99.998 %

The voice latency requirement is taken from ITU-R G.1010 recommendation where “inter-active voice exchanges” are defined with a maximum latency of 400 ms.

The availability requirement is taken from existing ATC systems in use today and the forecast for tomorrow systems as described in ED-228.

WP2 / WP4

WP2-GENUS-PER-005

The System capacity shall not be limited by the capacities of the ser-vices provided by the underlying subsystems; either in terms of number of drones or in terms of air/ground data throughput, apart from the possible throughput limitation due the use of tunneling techniques.

The hybrid system concept developed by DroC2om should exploit at its best the capa-bilities of the underlying communication technologies.

WP4

WP2-GENUS-PER-006

The System shall not limit the capacity to accommodate a growth of traffic offered by the underlying data links.

The hybrid system concept developed by DroC2om should be designed in such a way that future capacity increases of underlying communication technologies result in overall capacity increase for the hybrid system con-cept.

WP4

3.2 C2 Link Requirements



33

The DroC2om system concept relies on the use of a satellite and a terrestrial system, possibly in conjunction with each other depending on the scenario and concept of operations. This section first lists the requirements that are applicable to the C2 Data Link independently of the system used for its implementation. Two subsequent sections list the requirements that are specific to the Satellite and Terrestrial C2 Data Links.

3.2.1 Generic C2 Link Requirements

Requirement ref-erence



WP2-GENUS-FUN-001

The System shall support message exchanges for U1 to U2 U-Space services.

The System may support message exchanges for U3 and U4 U-Space services.

While the services definition for U1 and U2 is known, the definition of services for U3 and U4 (higher density and ATC interactions) is still under definition and may change in the future.

WP2 / WP4

WP2-GENUS-FUN-002

The System may support ATM services for certain classes of users. Certain users (esp. U4 use cases) will require interaction with the ATM, the system should avoid making these interactions impossible.

WP2 / WP4

WP2-GENUS-FUN-003

The System may provide a coverage area of the ECAC region.

Because the U-Space concept is European, the coverage area for U-Space services is pro-posed to be as wide as ECAC. In case of Satel-lite this helps with the dimensioning, for the terrestrial it has little to no impact.

WP4

EDITION [02.03.00.00]





WP2-GENUS-FUN-004

The System shall provide communication resources that can be reas-signed as needed to provide coverage for the changing sector layouts.

The hybrid system concept should be such that its design does not suppose a pre-defined capacity spatial organization and should re-main flexible to future changes in airspace use.

WP4

WP2-GENUS-FUN-005

The System shall provide communication links for the whole duration of flights as well as prior to take-off and after landing.

Given the nature of the C2 Link and its crucial role in the operation of UAS, it should be available at all times.

WP4

WP2-GENUS-FUN-006

The System shall provide service for the different U-Space steps: U1, U2, U3, and U4.

The C2 Link concept developed in DroC2om should cover all the services for the U-Space up to U4 and not limit its uses and capabilities to earlier services resulting in issues later in time.

WP2

WP2-GENUS-FUN-007

The System may support relay of ATC data and voice services for part of its serviced users.

The relay of ATC communication is a neces-sary step for some usage scenarios in U-Space but it is also a key enabler for U-Space/ATM integration that is a natural evolution of the U-Space concept.

WP2 / WP4

WP2-GENUS-FUN-008

The System shall support air-ground communications for drones.

The purpose of the system is to provide an air/ground data link. All other uses, air/air, ground/ground are out of scope of the devel-oped concept.

WP2 / WP4



35




WP2-GENUS-FUN-009

The System shall support:

- point-to-point (unicast) data communications

In addition, the System may support:

- point-to-multipoint (multicast) data communications

- broadcast data communications

C2 is generally performed using Point-to-Point interactions between the remote pilot and the drone. However, to accommodate future applications (e.g. ATM integration), the sup-port of multicast and broadcast is foreseen as it is used by some ED-228 foreseen applica-tions.

WP2/ WP3 / WP4




WP2-DATLI-FUN-001

The System shall be compatible with data links which will support all security related countermeasures to prevent identity theft, theft-of-service and eavesdropping threats.

Benefits provided by underlying communica-tion technologies should be taken advantage of by the hybrid system concept.

WP2 / WP4

EDITION [02.03.00.00]


3.2.1.1 Traffic Profile for the C2 Link

In order to determine the fitness of a given technology to the purpose of offering C2 Link services for the U-Space, the requirements in terms of traffic profile of the data to be exchanged on the link itself need to be determined.

It is hard to predict the exact values for the exchanges that will take place over the C2 Link. Indeed, most of the services that could require the C2 Link in order to be implemented (e.g. Detect & Avoid, Situational Awareness, Dynamic Geofencing, …) are still under definition themselves and it is thus unclear what their requirements will be.

Nevertheless, aeronautical and non-aeronautical standardisation bodies have analysed the question of drone traffic profile estimation and derivation.

From the aeronautical point of view, the earliest studies are from ITU [4] and date back to 2007 in preparation of the WRC-2007 agenda item on aeronautical spectrum allocation for UAS Control & Non Payload Communications (CNPC). These studies are now outdated and have been superseded by more recent analyses such as the one performed by RTCA in the frame of SC-228 for the establish-ment of the DO-362 MOPS (Minimal Operational and Performance Specifications). Another source of information is the STANAG-4856 document.

From the non-aeronautical standardisation bodies, the 3GPP has also performed and analysis of the traffic profile. Both approaches are presented hereafter. The System should be designed to cope, as much as possible, with both approaches (the specific assumption made in the frame of DroC2om is explicitly indicated in the description of the scenarios of this document).

3.2.1.1.1 STANAG/RTCA/EUROCAE approach

This section provides a description of the services expected to be provided to the U-Space users in terms of command and control. The data rates for a single drone are estimated using the most up-to-date available aeronautical sources. The estimations are carried out on the following services:

Command & Control (Automatic)

Command & Control (Manual)

UA Telemetry

ATC Voice relay

ATC Data Relay

Situational Awareness

The communication involved with these services is often referred as Command and Non-Payload Communication, including the data link traffic for drone command and control (C2), for Air Traffic Control (ATC) and for support of DAA data, i.e., situational awareness. For completeness, details for each one will be provided in [9], although DroC2om is mainly to focus strictly on the command and control part.

The analysis presented in [9] can be summarized as follows in terms of characteristics of the various services that need to exchange data using the System.



37

Table 5: Summary of the characteristics of C2 Link Traffic Profile

3.2.1.1.2 3GPP approach

The 3GPP Study Item “Study on Enhanced LTE Support for Aerial Vehicles” (finalized in December 2017) had as main objective to study aspects associated with using terrestrial networks to provide connectivity to aerial vehicles. During the study, a set of reference deployment scenarios, radio channel models and traffic model to be used in the performance evaluations, have been defined. The summary of the findings and proposals is available in the technical report TR 36.777 [5].

In terms of performance requirements, the TR36.777 specifies the connectivity service requirements listed in Table 6. The service for the C&C (or C2) data type is the one in the scope of the DroC2om project, hence the corresponding latency, data rate and reliability requirements are to be considered henceforth in this document.

Item Definition

Data type

1. C&C: This includes telemetry, waypoint update for autonomous drone operation, real time piloting, identity, flight authorisation, navigation da-tabase update, etc.

2. Application Data: This includes video (streaming), images, other sensors data, etc.

Latency* 1. C&C: 50 ms (one way from eNB to drone)

2. Application data: similar to LTE UE (terrestrial user)

Data rates 1. C&C: 60-100 kbps for FWD/RTN

2. Application data: up to 50 Mbps for drone-to-mission operator

C&C reliability Up to 10-3 Packet Error Loss Rate

* The definition of Latency is given in 3GPP TR 38.913 [12], subclause 7.5.

Table 6: Requirements for aerial vehicles connectivity services (Table 5.1-1 [5])

FWD

Traffic Type

Mean IP

datagram

size

[Bytes]

Max IP

datagram

size

[Bytes]

IP

datagram

Arrival

Law

IP datagram

Arrival Rate

[Hz]

Call

Arrival

Law

Call Arrival

Rate

[Hz]

Mean Call

Holding Time

[s]

TT95 (two

ways)

[s]

ET

[s]

Latency

(one-way)

[s]

Mean bit

rate

[kbps]

Type 1Type 2 Type 3

C2-Manual 166 196 D 5 N/A N/A N/A 0.85 1 N/A 6.7 1

C2-Automatic 193 196 D 1 N/A N/A N/A 0.85 1 N/A 1.5 1 1

ATC-Voice 72 72 D 8 M 0.002 20 N/A N/A 0.4 0.2

ATC-Voice Party Line 72 72 D 8 M 0.029 20 N/A N/A 0.4 2.7 1

ATC-Data 350 1969 M 0.006 N/A N/A N/A 8 10 N/A 0.0 1

SA 588 588 D 1 N/A N/A N/A 0.85 1 N/A 4.7

1.5 6.7 4.3

RTN

Traffic Type

Mean IP

datagram

size

[Bytes]

Max IP

datagram

size

[Bytes]

IP

datagram

Arrival

Law

IP datagram

Arrival Rate

[Hz]

Call

Arrival

Law

Call Arrival

Rate

[Hz]

Mean Call

Holding Time

[s]

TT95 (two

ways)

[s]

ET

[s]

Latency

(one-way)

[s]

Mean bit

rate

[kbps]

Type 1 Type 2 Type 3

C2-Manual 277 331 D 5 N/A N/A N/A 0.85 1 N/A 11.1 1

C2-Automatic 328 331 D 1 N/A N/A N/A 0.85 1 N/A 2.6 1 1

ATC-Voice 72 72 D 8 M 0.03 20 N/A N/A 0.4 2.7 1

ATC-Data 338 1380 M 0.005 N/A N/A N/A 8 10 N/A 0.0 1

SA 490 490 D 2 N/A N/A N/A 0.85 1 N/A 7.8 1 1

VID 500 500 D 5 N/A N/A N/A 0.85 1 N/A 20.0 1

10.5 31.1 13.2

EDITION [02.03.00.00]


3.2.1.1.3 DroC2om baseline traffic profile

The required radio connectivity performance for drones has been widely addressed in litera-ture. The most relevant documents have been discussed in the previous sections to specify ‘limit’ requirements, i.e. ‘low’ and ‘high’ values, which are expected to cover a large set of possible practical scenarios. We focus only on the radio communication requirements for CNPC, or C2, the main topic of the investigations in DroC2om.

The ITU-R reference [4] provides very detailed traffic requirements for the various flight phases in a typical drone mission: pre-flight, terminal (departure/arrival), en route, and post-flight. Further-more, downlink (from drone) and uplink (to drone) requirements are provided separately. In con-trast, the 3GPP reference [5] provides only one set of requirements (same for FWD and RTN) meant to cover the most demanding communication scenarios to/from drones. Table 7 summarizes the requirements we have used and the derived DroC2om ‘low’ and ‘high’ requirements for CNPC/C2.

ITU-R M.2171 [4]

3GPP TR 36.777 [5]

DroC2om ‘low’

DroC2om ‘high’

Packet size (PHY payload)

Downlink Varying 1250 Bytes 100 B 1250 B

Uplink Varying 1250 Bytes 100 B 1250 B

Throughput (PHY average)

Downlink 17-292 kbps 100 kbps 17 kbps 100 kbps

Uplink 7-9 kbps 100 kbps 7 kbps 100 kbps

Latency (PHY one-way-delay)

Downlink NA 50 ms 1 s 50 ms

Uplink NA 50 ms 1 s 50 ms

Table 7: Selected radio communication requirements for CNPC/C2 at PHY layer3

3 Please note that the values of this Table will be updated in the next deliverable D2.2 in order to reflect the

updated material which will be available from DO-362 MOPS.



39

3.2.2 Satellite Specific C2 Link Requirements




WP2-SATCO-FUN-001

The System shall be compatible with a satellite communication system operating in AMS(R)S frequency bands.

Aeronautical Safety frequency bands are im-portant for the protection of equipment op-erating in this band from harmful interfer-ences. Satellite links for RPAS C2 Link being defined by ICAO today will use spectrum in these specific allocations. For future U-Space/ATM integration, it is important that the concept proposed in DroC2om supports the hybrid use of a safety and a “non-safety” service.

WP2 / WP4

WP2- SATCO-FUN-002

The System shall be compatible with a satellite communication system which will provide the following connection modes:

- Drone to Ground Station

- Ground to Drone

The communications through the satellite link should be bi-directional.

WP2 / WP4

WP2-SATCO-FUN-003

The System shall be compatible with a satellite communication sys-tem, in which the space segment is based on GEO and/or LEO satel-lites (and HEO satellites for polar regions).

The architecture of the Space segment of the satellite communication system should not have an impact on the DroC2om system con-cept.

WP2 / WP4

EDITION [02.03.00.00]





WP2-SATCO-FUN-004

The System shall be compatible with a satellite communication sys-tem, in which the ground segment may be centralized or decentral-ized.

The architecture of the Ground segment of the satellite communication system should not have an impact on the DroC2om system concept.

WP2 / WP4

WP2-SATCO-FUN-005

The System shall be compatible with a satellite communication sys-tem, in which the resource allocation may be dynamic.

Modern satellite systems make use of dynam-ic capacity allocation and the DroC2om sys-tem concept should be compatible with such modes of operations so as not to limit the candidate satellite links to be used by the system.

WP2 / WP4

WP2-SATCO-FUN-006

The System shall be compatible with a satellite communication sys-tem, in which any combination of the following handovers may occur - Handover between different channels assigned to the same GES (Ground Earth Station) - Handover between channels assigned to different GES - Handover between channels provided through different satellite antenna beams - Handover between channels provided through different satellites owned by the same operator - Handover between channels provided through different satellites owned by different operators

Modern satellite systems make use of multi-ple internal handover types. The DroC2om system concept should be compatible with currently existing systems as well as future systems that implement the various handover types listed here.

WP2 / WP4



41




WP2-SATCO-FUN-007

The System may be compatible with a satellite communication system ensuring the following PER performances: - PER < 10

-2 for voice ATC communications relay when the link is avail-

able.

The performance of satellite communication systems in use nowadays should be taken into account in the overall system definition for DroC2om.

WP2 / WP4

WP2-SATCO-FUN-008

The System shall be compatible with a satellite communication system ensuring the following PER performances: - PER < 10

-3 after forward error correction for all exchanges but ATC

communications relay

The performance of satellite communication systems in use nowadays should be taken into account in the overall system definition for DroC2om.

WP2 / WP4

WP2-SATCO-FUN-009

The System shall be compatible with a satellite communication system that allows multiple user terminals (resp. GES) to share a pool of communication of resources on the return (resp. forward) link.

Modern satellite systems make use of dynam-ic capacity allocation and the DroC2om sys-tem concept should be compatible with such modes of operations so as not to limit the candidate satellite links to be used by the system.

WP4

WP2-SATCO-FUN-010

The System shall be compatible with a satellite communication system in which following functions are performed by dedicated Network and Management control elements: - Radio resource management and control - Administration functions (e.g., authorisation, accounting, billing) - Management of the frequency plan and of channel allocations to gateways

Interaction with these functions of the satel-lite system is foreseen. This requirement serves as an assumption that these functions exist and are handled by a single logical func-tion to which an interface can be foreseen to accommodate the DroC2om system concept.

WP4

EDITION [02.03.00.00]


3.2.3 Terrestrial C2 Link Specific Requirements




WP2-TERST-FUN-001

The System shall be compatible with a 3GPP LTE/LTE-Advanced or 5G NR terrestrial communication system operating in the 3GPP defined frequency bands.

Several ITU defined cellular frequency bands in each Region. 3GPP LTE/LTE-Advanced and 5G New Radio terrestrial networks operate in licensed frequency bands.

WP2 / WP3 / WP4

WP2-TERST-FUN-002

The System shall be compatible with a 3GPP LTE/LTE-Advanced or 5G NR terrestrial communication system, in which the radio resource allocation may be dynamic.

The primary role of 3GPP LTE/LTE-Advanced and 5G New Radio terrestrial communication systems is to serve terrestrial users (broad-band, MTC). UAV radio connectivity can be provided only by sharing the available radio resources in given 3GPP terrestrial network.

WP2 / WP3 / WP4

WP2-TERST-FUN-003

When using a 3GPP LTE/LTE-Advanced or 5G NR terrestrial communi-cation system, the System shall be able to satisfy the baseline traffic profile requirements listed in Section 3.1.*

WP2 / WP4



43


Requirement description Requirement justification DroC2o

sesar 2020 - 763601 - d2.3 - scenarios and requirements ... · description, incl. justification for...

Documents