SESAR 2020 - 763601 - D2.1 - Scenarios and Requirements · SESAR 2020 - 763601 - D2.1 - Scenarios and Requirements DeliverableID [D2.1] ProjectAcronym DroC2om Grant: 763601 Call:

SESAR 2020 - 763601 - D2.1 - Scenarios and Requirements

DeliverableID [D2.1]

ProjectAcronym DroC2om

Grant: 763601 Call: H2020-SESAR-2016-1 Topic: RPAS-05 DataLink Consortium coordinator: AAU Edition date: [14 March 2018] Edition: [01.02.01.00] Template Edition: 02.00.00

EXPLORATORY RESEARCH

SESAR 2020 - 763601 - D2.1 - SCENARIOS AND REQUIREMENTS

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

2

Authoring & Approval

Authors of the document

Name/Beneficiary Position/Title Date

Nicolas Van Wambeke WP2 Leader / TASF 27/03/2018

Troels B. Sørensen Project Coordinator / AAU 27/03/2018

Istvàn Kovacs Task Contributor / Nokia 27/03/2018

Jeroen Wigard Task Contributor / Nokia 27/03/2018

Benjamin Hiller Task Contributor / atesio 27/03/2018

Matthieu Clergeaud Task Contributor / TASF 27/03/2018

Reviewers internal to the project


Troels B. Sørensen Project Coordinator / AAU 27/03/2018

Istvàn Kovacs Task Contributor / Nokia 27/03/2018

Jeroen Wigard Task Contributor / Nokia 27/03/2018

Benjamin Hiller Task Contributor / atesio 27/03/2018

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


Jeroen Wigard Task Contributor / NBL 28/03/2018

Rejected By - Representatives of beneficiaries involved in the project


Document History

Edition Date Status Author Justification

00.01.00 12/12/2017 Draft Nicolas Van Wambeke Structure defined

00.01.01 13/02/2018 Draft Nicolas Van Wambeke Content included

00.01.02 12/03/2018 Draft Nicolas Van Wambeke Content updated w. Nokia input

00.01.03 13/03/2018 Draft Nicolas Van Wambeke Content updated w.



3

atesio input

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

01.00.00 28/03/2018 Final version Jeroen Wigard Final editing and final version ready for submission

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

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



4

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 Scenarios and Requirements document key objectives are, first, to describe typical use-case scenarios for small to medium-size drones in rural as well as in urban areas, and second, from these example operational scenarios, to derive requirements, 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 ............................................................................................................... 6

2 Definition of Scenarios ............................................................................................. 10

3 Requirements for the C2 Link .................................................................................... 15

4 References & Bibliography ....................................................................................... 28

Appendix A Traffic Profile computation ...................................................................... 29

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

Table 2: Terminology and definitions ...................................................................................................... 9

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

Table 4: Selected radio communication requirements for CNPC/C2 at PHY layer. .............................. 22

List of Figures Aucune entrée de table d'illustration n'a été trouvée.



6

1 Introduction1

1.1 Purpose and Scope

In the frame 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 requirements are formalized and derived. Furthermore, it is foreseen that WP2 will determine and establish a set of KPIs to be used to evaluate the solutions proposed by the project.

The deliverable describes the operational scenarios to be considered by the project as well as the requirements that need to be taken into account to build the different sub-systems in the frame of WP3 and WP4. Two issues of the document are foreseen with incremental material. The present document constitutes the first release of this document, and documents the definitions and assumptions which have been used in the initial phase of the project.

1.2 Structure of this document

This document is structured as follows:

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

- A section dealing with the definition of scenarios, establishing, for each of them, the role of the C2 Link in support for safe operations of the drones and contributing context to the derivation of requirements for the link.

- A third section where the C2 link requirements emerging from the definition of the scenarios and the analysis performed previously are formalized and captured.

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

1.3 Abbreviations & Definitions

Abbreviation Explanation

3GPP 3rd

Generation Partnership Project (cellular systems)

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

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



7

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

PHY Physical layer (communication protocol)

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



8

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” has been 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

Table 1: Abbreviations

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 and 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 real time mission control.

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,



9

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 Definition found

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



10

2 Definition of Scenarios

This section describes three example use scenarios that will be considered for the evaluation and demoing of the C2 Link in the frame of the DroC2om project. At this point, only brief descriptions of these exploratory scenarios are given, expecting that they will evolve in the course of the project. The objective is to identify initial requirements used by the software-based evaluation environment developed in WP3 and described in Section 2.2. The intention is to later exploit these exploratory scenarios so that they will serve as a guideline for the implementation of one reference 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 typical use case. The next section (3) will focus on other requirements that are generally C2 Link system

2.1 Exploratory scenarios

The following template will be used for the description of the scenarios described hereafter.

Scenario title:

Kind of drone (Mass/Volume/…):

Objective of the scenario:

Brief description of the main steps involved in the scenario:

EASA category for the scenario (estimation prior to SORA):

Traffic specification by phase of flight:

Performance requirements for C2 Link:

Primary/Secondary means of C2 Link for each phase of the scenario:

2.1.1 Scenario I: 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 of the main steps involved in the scenario: Takeoff from an off city drone

base, climb phase to cruise altitude below 500ft, fly-by-objective phase of 700km, return path identical to forward one, approach, landing

EASA category for the scenario (estimation prior to SORA): Specific or Certified (tbc) C2 Link Traffic specification by phase of flight: Manual command & Control for the takeoff

phase, semi-automated traffic for the cruise (mostly from drone to pilot), Semi-Automatic landing (higher traffic volume both ways than cruise)

Performance requirements for C2 Link: to be analysed in an OPA/SPA – most likely very high integrity and performance (low latency and PER)

Primary/Secondary means of C2 Link for each phase of the scenario: Primary link a terrestrial one of takeoff and landing with possibly a dual link requirement (packets sent on both links)



11

for these phases, primary link the satellite one for cruise, terrestrial backup only when in coverage.

2.1.2 Scenario II: Delivery Service by Drone

Scenario title: Delivery Service by Drone Kind of drone (Mass/Volume/…): medium sized drone Objective of the scenario: last mile packet delivery Brief description of the main steps involved in the scenario: Takeoff from a delivery truck or

base, climb phase to cruise altitude of 100 m, fly to destination 2 km away, land and leave package, and return to delivery truck/base (incl climb, fly and land phase)

Scenario: rural or urban EASA category for the scenario (estimation prior to SORA): Specific C2 Link Traffic specification by phase of flight: fully or semi- automated Performance requirements for C2 Link: in order of 100 kbps and 50-100 ms one-way delay Primary/Secondary means of C2 Link for each phase of the scenario: primary cellular network

with satellite as backup if there is no coverage.

2.1.3 Scenario III: Urban Fast-Delivery Service by Drone

Scenario title: Urban Fast-Delivery Service by Drone Kind of drone (Mass/Volume/…): medium sized drone Objective of the scenario: point-to-point time critical packet delivery Brief description of the main steps involved in the scenario: Takeoff 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), and return to base (incl climb, fly and land phase)

Scenario: urban or dense-urban EASA category for the scenario (estimation prior to SORA): Specific C2 Link Traffic specification by phase of flight: real-time monitoring with support for

direct/manual control Performance requirements for C2 Link: in order of 100 kbps and 50-100 ms one-way delay Primary/Secondary means of C2 Link for each phase of the scenario: primary cellular network

with satellite as backup if there is no coverage.

2.2 Requirements for Modelling Reference and Demo Scenarios

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

So far, neither the reference scenario nor the demo scenario have been finally settled. In fact, the scenarios are likely to evolve in the course of the project in several iterations, allowing to tailor them



12

to specific situations to be investigated. This necessitates a high-level, editable description of all the relevant scenario aspects, which can be turned into the scenario data using an automated process.

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 type, size, and weight impact the trajectories that are feasible for the drone.

It shall be possible to define and use different types of drones in a scenario. DroC2om focuses on the drone-to-drone operator communication. 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 should be possible to choose between 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) is 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 particular, 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 mission. Of course, it is desirable that these trajectories do not intersect with each other nor with forbidden regions (geofencing) or obstacles/buildings. This objective will need to be taken into account when generating trajectories. During the trajectory generation other aspects, such as preferring routes of travel over rivers, minimizing the crossing of highways, etc., may also be taken into account. Some choices for the degree of automation as per the U-Space availability are as follows:

Level 1: Based on U-Space foundation services

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 waypoints in the mission description, or by shifting the waypoints in time (provided the conflict depends on timing).



13

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 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, cf. 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 correspond 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 landing, combining horizontal and vertical movement.

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

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

Static obstacles in the environment may be described by 3D boxes that 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.

2.2.3 Infrastructure Model

A drone-to-drone operator communication is made available 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 infrastructures. DroC2om focuses on a C2 Link System that would be based on the combination of



14

both cellular and satellite network in a single multilink hybrid system. During any phase of its mission, a drone may establish a radio link either 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 configuration. 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 in one geosynchronous satellite (optionally two) whose trajectory is considered quasi-geostationary. Gain maps for each spot beam can be 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 in the previously described scenarios. As the satellite network will essentially be used in the long endurance scenario, a terrain type (sea, earth, mountains, urban area) model will be necessary.

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



15

3 Requirements for the C2 Link

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 3 to 5 characters chain attached to the domain name;

GENUS: general user needs

SPEUS: specific user needs

INTSE: integration of services

PERFO: performances

DATLI: data links

SATCO: satellite communications

TERST: terrestrial communications

AIRCO: airport communications



16

INTLI: integration of data links

MULOP: multi operators

INTOP: interoperability

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

FUN: Functional

PER: Performance

DES: Design & Certification

4. Incremental reference number on 3 digits; the numbering increments whatever the other fields; the maximum value of this reference number corresponds to the number of requirements.

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 complete 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 second hand

has 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 understanding

“may” is used to identify the optional requirements and/or the requirements that the DroC2om system concept will not specifically fully comply with.

“shall” is used for the other requirements, taken into consideration for the elaboration of the DroC2om system concept. At the moment, it is not determined whether DroC2om system concept will fully comply with.

In any case, the list of requirements and the particular use of “may and “shall” is to be updated in the second release of this document.



17

3.1 Performance Requirements

SYSTEM

domain Requirement reference Requirement description

Performances WP2-GENUS-PER-001 The S ystem shall offer, for all addressed data exchanges, an end-to-end availability of provision of at least 99.3%

WP2-GENUS-PER-002 The System shall offer, for all addressed data exchanges, an availability of use of at least 99%

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 layer of at least 10

-

3

WP2-GENUS-PER-004

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

- Voice latency: 400 ms

- Availability: 99.998%

WP2-GENUS-PER-005

The System shall not limit the number of drones supported and/or air-ground data throughput compared to the services offered by the underlying supported data links (with the exception of the throughput limitation resulting from tunneling overhead if used)

WP2-GENUS-PER-006 The System shall not limit the capacity to accommodate a growth of traffic offered by the underlying data links.

3.2 C2 Link Requirements

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



18

MISSION


General user needs

WP2-GENUS-FUN-001

The System shall support message exchanges for U1 to U3 U-SPACE services.

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

WP2-GENUS-FUN-002 The System may support ATS services for certain classes of users.

WP2-GENUS-FUN-003

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

WP2-GENUS-FUN-004 The System shall provide communication resources that can be reassigned as needed to provide coverage for the changing sector layouts

WP2-GENUS-FUN-005 The System shall provide communication links for the whole duration of flights as well as prior to takeoff and after landing.

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

WP2-GENUS-FUN-007 The System may support relay of ATC data and voice services for part of its serviced users.

WP2-GENUS-FUN-008 The System shall support air-ground communications for all users

WP2-GENUS-FUN-009

The System may support:

- point-to-point data communications

- point-to-multipoint data communications

- broadcast data communications

WP2-GENUS-DES-010 The DroC2om aircraft terminal shall be free of ITAR and EAR restrictions that would significantly and adversely affect the deployment of the solution.



19

SYSTEM

domain

Requirement reference

Requirement description

Data links generic 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

WP2-DATLI-FUN-002

The System shall be compatible with data links which may provide the following services to the upper layers: - Connectionless - Connection-oriented

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 very complex today to determine 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 from 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 analysis such as the one performed by RTCA in the frame of SC-228 for the establishment 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



20

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 Appendix A, although DroC2om is mainly to focus strictly on the command and control part.

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

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 3. 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.

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



21

Item Definition

Data type

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

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

Latency* 1. C&C: 50ms (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 3: Requirements for aerial vehicles connectivity services (Table 5.1-1 [5]).

3.2.1.1.3 DroC2om baseline traffic profile

The required radio connectivity performance for drones has been widely addressed in the literature. 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 further 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. Furthermore, downlink (from drone) and uplink (to drone) requirements are provided separately. In contrast, 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 4 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 300 kbps

Uplink 7-9 kbps 100 kbps 7 kbps 100 kbps

Latency (PHY one-way-



22

delay)

Downlink NA 50 ms 50 ms 200 ms

Uplink NA 50 ms 50 ms 200 ms

Table 4: Selected radio communication requirements for CNPC/C2 at PHY layer.2

3.2.2 Satellite Specific C2 Link Requirements

SYSTEM


Satellite communications

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

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

WP2-SATCO-FUN-003

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

WP2-SATCO-FUN-004 The System shall be compatible with a satellite communication system, in which the ground segment may be centralized or decentralized.

WP2-SATCO-FUN-005 The System shall be compatible with a satellite communication system, in which the resource allocation may be dynamic.

2 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.



23

SYSTEM


WP2-SATCO-FUN-006

The System shall be compatible with a satellite communication system, 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

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 available.

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

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

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



24

3.2.3 Terrestrial C2 Link Specific Requirements

SYSTEM


Terrestrial communications

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.

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.

WP2-TERST-FUN-003

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

WP2-TERST-FUN-004

The System shall be compatible with a 3GPP LTE/LTE-Advanced or 5G NR terrestrial communication system, in which any combination of the following handovers may occur - Handover between different cells assigned to the same e/gNodeB - Handover between cells assigned to different e/gNodeB - Handover between cells provided through different e/gNodeB antenna beams - Handover between cells provided through different e/gNodeB owned by the same operator - Handover between cells provided through different e/gNodeB owned by different operators

3.3 Integration Requirements for Satellite & Terrestrial Data Links

3.3.1 Interoperability Requirements for Satellite & Terrestrial systems



25

SYSTEM


Integration of services

WP2-INTSE-FUN-001

The System shall define an interface layer for multi-network service integration, including terrestrial and satellite networks relying on the IP protocol for global interconnection.

WP2-INTSE-FUN-002 The System shall provide the appropriate segregation in the provision of various services of the U-Space.

WP2-INTSE-FUN-003

The System shall differentiate various classes of service provisioned through mapping on the traffic differentiation mechanisms provided by the underlying communication systems.

SYSTEM


Integration of data links

WP2-INTLI-FUN-001 The System shall be a system of systems able to integrate existing communication systems as well as new communication systems.

WP2-INTLI-FUN-002

The System shall be flexible to integrate as easily as possible new communication technologies

WP2-DATLI-FUN-003 Within the System, upper protocol layers must work transparently with any supported communication technology for both user and control planes

WP2-INTLI-FUN-004 The System shall be capable of allocating any available link that is suitable to a required U-Space service implementation

WP2-INTLI-FUN-005

The System shall provide a mean to carry appropriate communications only over authorized paths for the traffic type and category specified by the user.



26

SYSTEM


WP2-INTLI-FUN-006

In the event that multiple links are available concurrently, the System shall automatically perform the mapping between services and links according to a pre-selected configuration, which may be modified

WP2-INTLI-FUN-007

The System shall be able to support automatic link selection as well as manual link(s) selection by the U-Space operator in bypassing automatic selection at any time of the service

WP2-INTLI-FUN-008

The System shall ensure that the change from one communication link to another one may be automatic and does not need intervention of the communication service user

WP2-INTLI-FUN-009 The System shall execute link technology handover for safety related services only if the new sub-network is certified for this service class

WP2-INTLI-FUN-010

The System shall provide mechanisms that allow to manage usage of underlying cellular and satellite sub-networks according to existing and emerging constraints and regulations related to the usage of aeronautical spectrum and as required by U-Space services.

WP2-INTLI-FUN-011

The System shall provide mechanisms to allocate resources from different sub-networks efficiently in order to optimize overall capacity and effective performance

WP2-INTLI-FUN-012 The System shall support backup scenarios by sending the traffic over a new sub-network in case the first one fails

WP2-INTLI-FUN-013 The System shall enable a drone to be simultaneously connected to and to roam between multiple independent access networks

WP2-INTLI-FUN-014

The System shall use satellite communications either as the sole communication link (e.g. oceanic areas) or as a redundant communication link when the terrestrial C2 Link link is available



27

SYSTEM


WP2-INTLI-FUN-015

The System shall support handovers between different access technologies and access networks. (inter-technology and inter-access network handover)

3.3.2 Requirements for the support of Multiple Operators

SYSTEM


Multi-operators WP2-MULOP-FUN-001

The System shall allow deployment of competing C2 Link Service providers and operators in same geographical locations.

WP2-MULOP-FUN-002

The System underlying network shall support interoperability with multiple ground operators and multiple communication service providers simultaneously

WP2-MULOP-FUN-003 The System shall be compatible with data links in which gateways may provide services to multiple drone operators and service providers.

WP2-MULOP-FUN-004

The System shall allow Interworking, i.e. having the C2 Link data sent from the drone to ground network through a provider, and reaching the U-Space infrastructure servers through another provider

WP2-MULOP-FUN-005

The DroC2om network shall support user traffic performance indicators and usage statistics in the context of multiple operators

WP2-MULOP-FUN-006

The System shall support security requirements over multiple operators / service providers.



28

4 References & Bibliography

The following publications have been used in support for the elaboration of this document.

[1] “U-Space Blueprint”, Final brochure, SESAR Joint Undertaking, DOI: 10.2829/335092

[2] “European ATM Master Plan; Roadmap for the safe integration of drones into all classes of airspace”, SESAR Joint Undertaking, March 8, 2018

[3] SESAR 2020-763601 DROC2OM Technical Annex, September 2017.

[4] Report ITU-R M.2171, “Characteristics of unmanned aircraft systems and spectrum requirements to support their safe operation in non-segregated airspace”, December 2009.

[5] 3GPP, Technical Specification Group Services and System Aspects, TR 36.777, “Enhanced LTE support for aerial vehicles (Release 15)”, v15.0.0, January 2018.

[6] European Aviation Safety Agency, “Notice of Propose Amendment 2017-05 (A) - Introduction of a regulatory framework for the operation of drones: Unmanned aircraft system operations in the open and specific category”, May 2017.

[7] Joint Authorities for Rulemaking of Unmanned Systems (JARUS), “JARUS guidelines on Specific Operations Risk Assessment (SOAR)”, June 2017.

[8] Robert J. Kerczewski, James H. Griner, "Control and Non-payload communications links for integrated unmanned aircraft operations", 2012. (http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20120016398.pdf).

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20120016398.pdf



29

Appendix A Traffic Profile computation

Throughput rates are calculated based on data load and overhead associated with different flight phases :

Terminal Departure

En Route

Terminal Arrival

For each phase, the data rates were estimated for forward (FWD) and return (RTN) ways and for both Manual and Automatic mode.

The following paragraph will give an overview of the communication between pilot, drone and an assumed U-Space command and non-payload traffic controller. From the point of view of DroC2om, the latter serves as the origin of the information, whether this is generated by a pilot operator or an automated system. In the following we will used the term pilot, although this could be an automated system.

Information routing

The information that have to be exchanged between pilot and UA are organised in services and include:

UAV telecommands and telemetry

ATC Voice messages

ATC Data messages

Detect and Avoid Data (Situational Awareness)

The next figure explains through a diagram how such information are routed and exchanged.

PILOT UA

Control Commands

UA Telemetry

ATC Voice Relay

ATC Data Relay

Situation Awareness

UACONTROLCENTER

ATC Voice Relay

ATC Data Relay

Information routing between Pilot, UA and Control Center

Services descriptions

The required services and their data throughput are described and analysed in the next paragraphs. The data load analysis is based on the NATO standard STANAG 4586, which regulates UAS control



30

links. Civil aviation is not requirement to adopt the STANAG 4586 standard, but such assumption allows a reliable first estimation of data throughput for civil UAS.

Command & Control

The Command & Control Service is compound of the telecommands sent by the pilot and the telemetry sent by the drone, both in either automatic or manual mode.

Telecommands consist in:

Flaps, rudder and other control surfaces on the UA

Communication equipment

Landing gear

Lights

Telemetry consists in:

Attitude information

Communication equipment status

Landing gear status

Lights status

The analysis of the messages to be exchanged between the drone and the ground segment is presented in the tables below for both Forward and Return links in Manual and Automatic approaches. The peak data rate is equal to the average data rate given that all messages are transmitted periodically.



31

Command Average Rates

Repetition

Rate (Hz)

Periodicity

(s)

Sent

every

200ms

Sent

every

1s

Sent

every

10s

Message

length

(bytes)

Message

length with

overheads

(bytes)

Datagram

length with

overheads

(bytes)

Average

Data Rate

(bps)

Repetition

Rate (Hz)

Periodicity

(s)

Sent

every

200ms

Sent

every

1s

Sent

every

10s

Message

length

(bytes)

Message

length with

overheads

(bytes)

Datagram

length with

overheads

(bytes)

Average

Data Rate

(bps)

Select Flight Path Control Mode 2001 (Vehicle Operating Mode Command) 8 1 1 0 1 1 1 1 0 1 1

Message sent every 200ms 2001 (Vehicle Operating Mode Command) 5 0.2 0 0 5 0.2 0 0

Message sent every 1s 2001 (Vehicle Operating Mode Command) 1 1 1 30 1 1 1 30

Message sent every 10s 2001 (Vehicle Operating Mode Command) 0.1 10 1 30 0.1 10 1 30

Commanded Altitude or Throttle Command 2002 (Vehicle Steering Command) 24 5 0.2 1 1 1 1 1 0 1 1

Altitude Type 2002 (Vehicle Steering Command) 8 5 0.2 1 1 1 1 1 0 1 1

Heading Command Type 2002 (Vehicle Steering Command) 8 1 1 0 1 1 1 1 0 1 1

Heading Reference 2002 (Vehicle Steering Command) 8 1 1 0 1 1 1 1 0 1 1

Commanded Heading/Turn Rate or Aileron

Command

2002 (Vehicle Steering Command) 16 5 0.2 1 1 1 1 1 0 1 1

Commanded Course 2002 (Vehicle Steering Command) 16 5 0.2 1 1 1 1 1 0 1 1

Commanded Speed or Elevator Command 2002 (Vehicle Steering Command) 16 5 0.2 1 1 1 1 1 0 1 1

Speed Type 2002 (Vehicle Steering Command) 8 1 1 0 1 1 1 1 0 1 1

Message sent every 200ms 2002 (Vehicle Steering Command) 5 0.2 10 39 5 0.2 0 0

Message sent every 1s 2002 (Vehicle Steering Command) 1 1 13 42 1 1 13 42

Message sent every 10s 2002 (Vehicle Steering Command) 0.1 10 13 42 0.1 10 13 42

Set Navaid Radio State 7001 (NAVAID radio command) 8 1 1 0 1 1 0.1 10 0 0 1

Set Navaid Frequency 7001 (NAVAID radio command) 16 1 1 0 1 1 0.1 10 0 0 1

VOR Radial 7001 (NAVAID radio command) 16 5 0.2 1 1 1 1 1 0 1 1

Radial To/From 7001 (NAVAID radio command) 8 5 0.2 1 1 1 1 1 0 1 1

Radio Unit 7001 (NAVAID radio command) 8 1 1 0 1 1 1 1 0 1 1

Message sent every 200ms 7001 (NAVAID radio command) 5 0.2 3 32 5 0.2 0 0

Message sent every 1s 7001 (NAVAID radio command) 1 1 7 36 1 1 4 33

Message sent every 10s 7001 (NAVAID radio command) 0.1 10 7 36 0.1 10 7 36

Datagram sent every 200ms ALL 5 0.2 71 159 5 0.2 0 0

Datagram sent every 1s ALL 1 1 108 196 1 1 105 193

Datagram sent every 10s ALL 0.1 10 108 196 0.1 10 108 196

Mean datagram size ALL 78 166 0.1 10 105 193

Max datagram size ALL 108 196 0.1 10 108 196

All datagrams ALL 392 832 6656 105 193 1546

Automatic Mode

Field length

(bits)

ENR, FWD

STANAG 4586 Edition 3 Message

Manual Mode

Field



32

Control Average Rates

Repetition

Rate (Hz)

Periodicity

(s)

Sent

every

200ms

Sent

every

1s

Sent

every

10s

Message

length

(bytes)

Message

length with

overheads

(bytes)

Datagram

length with

overheads

(bytes)

Average

Data Rate

(bps)

Repetition

Rate (Hz)

Periodicity

(s)

Sent

every

200ms

Sent

every

1s

Sent

every

10s

Message

length

(bytes)

Message

length with

overheads

(bytes)

Datagram

length with

overheads

(bytes)

Average

Data Rate

(bps)

Latitude 4000 (Inertial States) 32 5 0.2 1 1 1 1 1 0 1 1

Longitude 4000 (Inertial States) 32 5 0.2 1 1 1 1 1 0 1 1

Altitude 4000 (Inertial States) 24 5 0.2 1 1 1 1 1 0 1 1

Message sent every 200ms 4000 (Inertial States) 5 0.2 11 40 5 0.2 0 0

Message sent every 1s 4000 (Inertial States) 1 1 11 40 1 1 11 40

Message sent every 10s 4000 (Inertial States) 0.1 10 11 40 0.1 10 11 40

Engine Temperature 3007 (Engine Operating States) 8 1 1 0 1 1 1 1 0 1 1

Engine Speed 3007 (Engine Operating States) 16 1 1 0 1 1 1 1 0 1 1

Message sent every 200ms 3007 (Engine Operating States) 5 0.2 0 0 5 0.2 0 0

Message sent every 1s 3007 (Engine Operating States) 1 1 3 32 1 1 3 32

Message sent every 10s 3007 (Engine Operating States) 0.1 10 3 32 0.1 10 3 32

Air Speed 3009 (Air and Ground Relative States) 16 5 0.2 1 1 1 1 1 0 1 1

Ground Speed 3009 (Air and Ground Relative States) 32 5 0.2 1 1 1 1 1 0 1 1

Message sent every 200ms 3009 (Air and Ground Relative States) 5 0.2 6 35 5 0.2 0 0

Message sent every 1s 3009 (Air and Ground Relative States) 1 1 6 35 1 1 6 35

Message sent every 10s 3009 (Air and Ground Relative States) 0.1 10 6 35 0.1 10 6 35

Roll 3010 (Body-Relative Sensed States) 16 5 0.2 1 1 1 1 1 0 1 1

Yaw 3010 (Body-Relative Sensed States) 16 5 0.2 1 1 1 1 1 0 1 1

Pitch 3010 (Body-Relative Sensed States) 16 5 0.2 1 1 1 1 1 0 1 1

Message sent every 200ms 3010 (Body-Relative Sensed States) 5 0.2 6 35 5 0.2 0 0

Message sent every 1s 3010 (Body-Relative Sensed States) 1 1 6 35 1 1 6 35

Message sent every 10s 3010 (Body-Relative Sensed States) 0.1 10 6 35 0.1 10 6 35

Heading 3002 (Vehicle Operating States) 16 5 0.2 1 1 1 1 1 0 1 1

Message sent every 200ms 3002 (Vehicle Operating States) 5 0.2 2 31 5 0.2 0 0

Message sent every 1s 3002 (Vehicle Operating States) 1 1 2 31 1 1 2 31

Message sent every 10s 3002 (Vehicle Operating States) 0.1 10 2 31 0.1 10 2 31

Remaining Fuel 16 1 1 0 1 1 1 1 0 1 1

Message sent every 200ms 5 0.2 0 0 5 0.2 0 0

Message sent every 1s 1 1 2 31 1 1 2 31

Message sent every 10s 0.1 10 2 31 0.1 10 2 31

VOR Navaid State 9001 (NAVAID Radio Status) 8 1 1 0 1 1 0.1 10 0 0 1

Navaid Frequency 9001 (NAVAID Radio Status) 16 1 1 0 1 1 0.1 10 0 0 1

Navaid Receiver State 9001 (NAVAID Radio Status) 8 1 1 0 1 1 1 1 0 1 1

Radio Unit 9001 (NAVAID Radio Status) 8 1 1 0 1 1 1 1 0 1 1

VOR Azimuth 9001 (NAVAID Radio Status) 16 5 0.2 1 1 1 1 1 0 1 1

DME 9001 (NAVAID Radio Status) 24 5 0.2 1 1 1 1 1 0 1 1

Message sent every 200ms 9001 (NAVAID Radio Status) 5 0.2 5 34 5 0.2 0 0

Message sent every 1s 9001 (NAVAID Radio Status) 1 1 10 39 1 1 7 36

Message sent every 10s 9001 (NAVAID Radio Status) 0.1 10 10 39 0.1 10 10 39

Datagram sent every 200ms ALL 175 263 0 0

Datagram sent every 1s ALL 243 331 240 328

Datagram sent every 10s ALL 243 331 243 331

Mean datagram size ALL 189 277 0.1 10 240 328

Max datagram size ALL 243 331 0.1 10 243 331

All datagrams ALL 943 1 383 11064 240 328 2626

Automatic Mode

ENR, RTN

STANAG 4586 Edition 3 Message

Field length

(bits)

Manual Mode

Field



1

ATC Voice Relay

ATC Voice Relay between Pilot and Control Center, through the UA, is handled in digital format with a 4800bps throughput, compound of 4133 bps message and a 667 bps overhead. ATC traffic typically consists of clearances and instructions, as well as meteorological, aeronautical and (airspace) traffic information.

More in detail, each 100ms of audio are packet into a 480 bits frame, constituted by 5 vocoder frames of 96 bits. A 10Hz update rate, yields to 4800 bits of data for each second of audio.

The usage ratio from COCR are used to compute the average bit rate considering that a dedicated channel is not allocated permanently. This assumption may be reviewed.

ATC Voice Relay Message Average Rates

ATC Data Relay

ATC Data Relay between Pilot and Control Center, through the UA, is an alternative way of transmitting information to the Pilot instead of using the ATC Voice Relay.

There are different kinds of ATC Data Relay messages, each with their specific size for Forward and Return ways. They are detailed in the following three tables, each for a determined flight phase (Terminal Departure, En Route, Terminal Arrival).

TMA ENR

Peak voice traffic bit rate at L3 level (bps) 4800 4800

Voice traffic per hour per aircraft - Phase 1 HD (s) 206 155

Voice traffic per hour per aircraft - Phase 1 LD (s) 132 116

Voice traffic per hour per aircraft - Phase 2 HD (s) 257 106

Voice traffic per hour per aircraft - Phase 2 LD (s) 165 85

Party Line Occupancy (%) - Phase 1 HD 64% 57%

Party Line Occupancy (%) - Phase 1 LD 36% 43%

Party Line Occupancy (%) - Phase 2 HD 87% 7%

Party Line Occupancy (%) - Phase 2 LD 50% 7%

Average voice traffic bit rate at L3 level FWD (bps) 275 207

Average voice traffic bit rate at L3 level RTN (bps)

Party Line Included because relayed to the pilot

3072 2736

Msgs per

instance

Msg size

(bytes)

Msgs per

instance

Msg size

(bytes)

#instances #msgs FWD #msgs RTN

Average data

rate FWD (bps)

Average data

rate RTN (bps)

ACL ATC Clearance 2 93 2 93 5 10 10 0.7 0.7

ACM ATC Communication Management 1 126 1 88 5 5 5 0.5 0.3

AMC ATC Microphone Check 1 89 0 0 1 1 0 0.1 0.0

ATSA-ITP In Trail Procedure 2 93 2 93 1 2 2 0.1 0.1

COTRAC Common Trajectory Coordination

D-ATIS (arrival) Data Link ATIS 5 100 3 93 1 5 3 0.4 0.2

D-ATIS (departure) Data Link ATIS 3 101 2 96 0 0 0 0.0 0.0

D-FLUP Data Link Flight Update 5 190 3 129 1 5 3 0.7 0.3

DLIC (DLL) DLL – Data Link Logon 1 491 1 222 1 1 1 0.4 0.2

D-OTIS Data Link Operational Terminal Info Service 11 193 3 107 1 11 3 1.6 0.2

D-RVR Data Link Runway Visual Range 4 116 3 121 1 4 3 0.3 0.3

FLIPINT Flight Path Intent

NOTAM Notice to Airmen 4 287 2 134 2 8 4 1.7 0.4

VOLMET Assumed to be Equal to D-SIGMET 4 130 3 129 1 4 3 0.4 0.3

4DTRAD 4-D Trajectory Data Link 3 1969 4 1380 5 15 20 21.6 20.2

Max Msg Size 1969 1380

Mean Msg Size 545.3 555.3

Total at L3 level (bps) 71 57 28.3 23.1

ENR

No flight crew involvement, so no need to relay data between UACS and UA

Subsumed in 4DTRAD

FWD RTN



2

ATC Data Relay Message Rates and Sizes (En Route)

ATC Data Relay Message Rates and Sizes (Departure)

ATC Data Relay Message Rates and Sizes (Arrival)

ATC Data Relay Message Rates and Sizes (Totals)

Situational Awareness

The Situational Awareness Data are exploited to provide the Detect and Avoid functions. It consists of control information for the configuration and operational status. Once per second, they deliver information on a traffic display at Pilot’s premises.

The data are organized in 400 bytes packets each with a 170 bytes overhead.

Msgs per

instance

Msg size

(bytes)

Msgs per

instance

Msg size

(bytes)

#instances #msgs FWD #msgs RTNAverage data

rate FWD (bps)

Average data

rate RTN (bps)












D-TAXI Data Link Taxi Clearance 2 132 1 98 1 2 1 1.8 0.7








TMA (departure)


Subsumed in 4DTRAD

FWD RTN

Msgs per

instance

Msg size

(bytes)

Msgs per

instance

Msg size

(bytes)

#instances #msgs FWD #msgs RTN

Average data

rate FWD (bps)

Average data

rate RTN (bps)












D-TAXI Data Link Taxi Clearance 2 132 1 98 1 2 1 1.3 0.5








FWD RTN TMA (arrival)

Subsumed in 4DTRAD


Msgs per

instance

Msg size

(bytes)

Msgs per

instance

Msg size

(bytes)

#instances #msgs FWD #msgs RTN Average data

rate FWD (bps)

Average data

rate RTN (bps)





3

Situational Awareness Rates and Sizes (Overhead included)

Situational Awareness Total Rates and Sizes (Overhead included)

Category Unit Level TMA, FWD ENR, FWD TMA, RTN ENR, RTN

Situational awareness min. quality kbps L3 0.0 0.0 28.5 0.0

Situational awareness high quality kbps L3 0.0 0.0 285.0 0.0

ADS-B-in kbps L3 0.0 0.0 4.7 4.7

ADS-B-out kbps L3 0.0 0.0 1.0 1.0

TCAS kbps L3 0.0 0.0 2.3 2.3

Collision avoidance kbps L3 0.0 0.0 2.9 2.9

Terrain awareness kbps L3 0.0 0.0 0.1 0.1

Integrated surveillance kbps L3 0.0 0.0 7.8 7.8

Traffic situation kbps L3 4.7 4.7 0.0 0.0

Category Unit Level TMA, FWD ENR, FWD TMA, RTN ENR, RTN

Total peak (min quality) - Integrated approach kbps L3 4.7 4.7 36.3 7.8

Total peak (high quality) - Integrated approach kbps L3 4.7 4.7 292.8 7.8

Total peak periodic - Integrated approach kbps L3 4.7 4.7 7.8 7.8

Total peak aperiodic (min quality) - Integrated approach kbps L3 0.0 0.0 28.5 0.0

Total peak aperiodic (high quality) - Integrated approach kbps L3 0.0 0.0 285.0 0.0

Documents

SESAR 2020 - 763601 - D2.1 - Scenarios and Requirements · SESAR 2020 - 763601 - D2.1 - Scenarios and Requirements DeliverableID [D2.1] ProjectAcronym DroC2om Grant: 763601 Call: