SESAR 2020 - 763601 - D4.2 Satellite system concepts ... · D4.2 Satellite system concepts solutions for high reliability UAS data links DeliverableID D4.2 ProjectAcronym DroC2om

SESAR 2020 - 763601 - D4.2 Satellite system concepts solutions for high reliability UAS data links

DeliverableID D4.2

ProjectAcronym DroC2om

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

EXPLORATORY RESEARCH Ref. Ares(2018)5578088 - 31/10/2018

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

2

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

Authoring & Approval

Authors of the document

Name/Beneficiary Position/Title Date

Matthieu Clergeaud D4.2 Editor 25/10/2018

Nicolas Van Wambeke WP2 lead 25/10/2018

István Z. Kovács WP4 lead 25/10/2018

Reviewers internal to the project


Jeroen Wigard / NBL Contributor 15/10/2018

Troels Bundgaard Sørensen/AAU Coordinator 15/10/2018

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


Nicolas Van Wambeke TAS 25/10/2018

Jeroen Wigard NBL 25/10/2018

Rejected By - Representatives of beneficiaries involved in the project


Document History

Edition Date Status Author Justification

00.00.00.01 07/05/2018 DRAFT MC Early ToC

00.00.00.02 18/05/2018 DRAFT MC Additional content

00.00.00.03 03/08/2018 DRAFT MC Draft version for review

00.00.00.04 30/08/2018 DRAFT MC Inclusion of reviewers comments

00.00.00.05 21/09/2018 DRAFT MC Additional content

00.00.00.06 15/10/2018 Internal review MC/NVW Updated ToC and additional content for review.


3


01.00 23/10/2018 Final MC Inclusion of reviewers comments

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 technical deliverable 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 programme1.

Abstract

In this Deliverable, satellite access is considered as a potential means to support the safe integration of drones into civil airspaces. The growing population of drones is estimated to thousands in a single urban area in the next two decades, however rural or unpopulated zones are not to be left.

In this context, satellite networks are good candidates for broadening the mission range, or even for imagining new applications, thus satellite access appears as an adequate complement to terrestrial networks systems, providing either a back-up link, a hybrid solution, or acting as the unique link connecting the drone to the world.

Some existing satellite communications (SATCOM) systems appear as reasonably good candidates for the provision of the Command and Control (C2) DataLink. However, regulation and standardisation bodies are now actively working to establish a “Satellite Control and Non-Payload Communication (CNPC, or in other words: C2) Minimum Operational Performance Standard”, with the objective to tackle the technical issues and to comply with the safety requirements necessary for the drone flight.

Those considerations highlight the need for a new concept, dedicated to the specific traffic profile of C2 communications. For this purpose, an analysis of the operational context involving the Command and Control for drones is provided, the central role of this drone capability in the U-space context and its dependencies with other services.

An extensive and detailed satellite communication system is then proposed, with the objective to simultaneously: tackle the requirements stated in WP2 deliverables, stay in line with recommendations and constraints imposed by international aeronautical regulation and standardisation bodies and remain sufficiently adaptive and modular to follow the future growth of

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.


5


drone operation. A short paragraph then summarises how the software environment developed in the frame of WP3 can formalise and exploit the satellite system parameters to process the overall evaluation of a complete hybrid system, involving both the satellite network access and the cellular network access.

Afterwards, an evaluation of the satellite C2 Link concept is performed; two different aspects have been addressed, the first one concerning the capacity of the satellite network at IP packet level, the second one studying the impact on the RF-sub-layer communications of such a system concept.

In a final chapter, we give our conclusions on the limitations and the possible extensions of the satellite network mechanisms to respond to the future of demand in drone connectivity in an European ATM system, and how this deliverable meets several system requirements.


6


Table of Contents

1 Introduction ............................................................................................................. 10

1.1 Purpose of the document............................................................................................. 10

1.2 Document overview .................................................................................................... 11

1.3 Glossary ...................................................................................................................... 11

2 Satellite system concept ........................................................................................... 15

2.1 Current satellite systems for aeronautical safety services ............................................. 15 2.1.1 Inmarsat .......................................................................................................................................... 15 2.1.2 Iridium ............................................................................................................................................. 16 2.1.3 5G New Radio Non-Terrestrial Networks ........................................................................................ 16

2.2 Regulation and standardisation aspects ....................................................................... 17 2.2.1 Regulatory elements for C2 Link provision ..................................................................................... 17 2.2.2 Spectrum related considerations for Aeronautical Services ........................................................... 18

2.2.2.1 AMS(R)S allocation in L band .................................................................................................. 19 2.2.2.2 AMS(R)S allocation in C band ................................................................................................. 21

2.3 Proposal for a C2 Link satellite system concept ............................................................. 21 2.3.1 Operational Analysis ....................................................................................................................... 22 2.3.2 System Analysis ............................................................................................................................... 23 2.3.3 Space vehicle physical architecture ................................................................................................ 25

2.3.3.1 Constellation........................................................................................................................... 25 2.3.3.2 Hosting platform..................................................................................................................... 25 2.3.3.3 Satellite payload ..................................................................................................................... 25 2.3.3.4 Satellite antenna .................................................................................................................... 26

2.3.4 Drone satcom transceiver physical architecture ............................................................................. 27 2.3.4.1 Airborne satcom antenna ....................................................................................................... 27 2.3.4.2 Airborne satcom radio ............................................................................................................ 28

2.3.5 Functional architecture ................................................................................................................... 29 2.3.5.1 Radio Bearers ......................................................................................................................... 30 2.3.5.2 Physical Layer ......................................................................................................................... 32 2.3.5.3 Link Layer ................................................................................................................................ 33 2.3.5.4 Security, identity, encryption ................................................................................................. 41

2.4 Integration with the cellular network ........................................................................... 43 2.4.1 Logical Architecture......................................................................................................................... 43 2.4.2 Combination of subsystems ............................................................................................................ 47

3 Satellite data link performance evaluation ............................................................... 49

3.1 Network capacity evaluation........................................................................................ 49 3.1.1 Methodology ................................................................................................................................... 49 3.1.2 Scenario description ........................................................................................................................ 50 3.1.3 Simulation results ............................................................................................................................ 51

3.2 Radio communication .................................................................................................. 54 3.2.1 Methodology ................................................................................................................................... 54 3.2.2 Scenario description ........................................................................................................................ 56 3.2.3 Results ............................................................................................................................................. 58


7


3.3 Interface with Work Package 3 ..................................................................................... 62

4 Conclusion ............................................................................................................... 64

4.1 Summary and recommendations ................................................................................. 64

4.2 Addressed requirements .............................................................................................. 65

5 References ............................................................................................................... 69

Appendix A Link Budget ............................................................................................. 70

A.1 Terminology ................................................................................................................ 70

A.2 Computation model ..................................................................................................... 72

A.3 Numerical example ...................................................................................................... 76

Appendix B Drone Session Control ............................................................................. 77

B.1 Session initiation ......................................................................................................... 77

B.2 Session maintenance ................................................................................................... 79

B.3 Beam Handover ........................................................................................................... 79

B.4 Handover detection ..................................................................................................... 80

B.5 Session release ............................................................................................................ 82

B.6 Summary of Protocol elements .................................................................................... 82

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

Table 2: Terminology and definitions .................................................................................................... 14

Table 3 : Link Layer Channel characteristics .......................................................................................... 41

Table 4 : Properties of the Classes of Service for the FWD link ............................................................ 51

Table 5 : Properties of the Classes of Service for the RTN link.............................................................. 51

Table 6: Drone flight waypoints ............................................................................................................ 56

Table 7: Main radio satcom simulation parameters ............................................................................. 57

Table 8: General user performance requirements................................................................................ 65

Table 9: Generic user functional requirements. ................................................................................... 66

Table 10: Generic data link functional requirements. ........................................................................... 66

Table 11: Satcom C2 link specific requirements. .................................................................................. 68

Table 12: List of constants for the link budget model ........................................................................... 70


8


Table 13 : List of fixed satellite subsystem parameters ........................................................................ 71

Table 14 : Link budget model variable computed quantities ................................................................ 72

Table 15 : Summary of drone session protocol elements ..................................................................... 83

List of Figures Figure 1 : Study Logic with focus on D4.2 and forward interactions .................................................... 10

Figure 2: Typical frequency bands used for safety aeronautical communications via satellite. These band allocations are managed by the ITU. ............................................................................................ 19

Figure 3: AMS(R)S L band allocation for SATCOM ................................................................................. 20

Figure 4 : C2 as a foundation capability for U-space services ............................................................... 22

Figure 5 : High-level system functional diagram ................................................................................... 24

Figure 6: Satellite repeater architecture ............................................................................................... 26

Figure 7: Footprint of a multi-beam satellite antenna covering the ECAC zone ................................... 27

Figure 8: Circular patch elements (model with 8 similar elements) ..................................................... 28

Figure 9:End-to-end service overview ................................................................................................... 30

Figure 10: FWD Radio Bearer : one carrier per spot beam ................................................................... 31

Figure 11: RTN Radio Bearer : one carrier per drone ............................................................................ 31

Figure 12 : Spectral occupation for radio bearers ................................................................................. 32

Figure 13 : Building a PLframe stream (FWD link) ................................................................................. 33

Figure 14 : Drone session timeline ........................................................................................................ 34

Figure 15: Link Layer Model .................................................................................................................. 35

Figure 16 : GSE adaptation - possible fragmentation ............................................................................ 37

Figure 17 : Time frame structure ........................................................................................................... 38

Figure 18 : FWD/RTN synchronisation on drone side ........................................................................... 38

Figure 19 : High-level Block Diagram of the Logical Architecture with external logical actors ............. 43

Figure 20 : Detailed Logical Architecture for SRS and Hybrid DataLink components ........................... 45

Figure 21 : Logical component breakdown structure (partial) ............................................................. 46

Figure 22: Overview of the Network Capacity Simulation Tool ............................................................ 50


9


Figure 23 : FWD Average Throughput and Delay for T1, T2, T3 ............................................................ 52

Figure 24 : RTN Average Throughput and Delay for T1, T2, T3 ............................................................. 52

Figure 25 : FWD Delay for 95% and 99.9% of transmitted IP packets for C2-Automatic ...................... 53

Figure 26 : RTN Delay for 95% and 99.9% of transmitted IP packets for C2-Automatic ....................... 53

Figure 27 : RTN Delay for 95% and 99.9% of transmitted IP packets for C2-Manual ........................... 54

Figure 28: Beam handover - global 2D view .......................................................................................... 55

Figure 29 : Global 3D view – Spot beams viewed from the satellite .................................................... 55

Figure 30: Beam handover : Regional 2D view ...................................................................................... 57

Figure 31: Beam handover : local 2D view ............................................................................................ 58

Figure 32: Azimuth, Elevation and Range ............................................................................................. 59

Figure 33: Satellite EIRP (dBW) vs. time for single beams and for multibeam with MaxGain strategy 60

Figure 34: C/N0 (dBHz) vs. time for single beams and for multibeam with MaxGain strategy ............ 61

Figure 35: BER profile vs. time for single beams and for multibeam with MaxGain strategy .............. 62

Figure 36 : Defining elements of a satellite beam ................................................................................. 74

Figure 37 : EIRPSAT profile vs. offset angle ............................................................................................. 75

Figure 38: Serving and adjacent spot beams ........................................................................................ 77

Figure 39 : Logon protocol .................................................................................................................... 78

Figure 40 : Echo protocol ...................................................................................................................... 79

Figure 41 : Beam Handover protocol .................................................................................................... 81

Figure 42 : Logoff protocol –initiated by the drone or by the SGW ...................................................... 82


10


1 Introduction

1.1 Purpose of the document

This document aims at providing a SATCOM system concept to support the command-and-control data link (C2) which is needed to operate civil drones in the future European drone and manned aviation traffic management system, also known as U-space.

The deliverable D4.2 focuses on the satellite component of the full command-and-control link system, which also includes a terrestrial (cellular network) component, described in Deliverable D4.1. The hybrid mechanisms ensuring that both satellite and terrestrial components complement each other are treated in the D4.3 deliverable.

The figure below sums up the study logic around D4.2

Figure 1 : Study Logic with focus on D4.2 and forward interactions

This deliverable is also in relation with WP3 deliverables since some scenario or simulation parameters given in this document will serve as input to the realisation of the software environment that will be used for the hybrid-access performance evaluation and also for the demonstration purpose. Outcomes of the performance evaluation may constitute inputs to the D4.3 deliverable that will cope with the


11


integration and the hybrid-system of both cellular and satellite sub-systems to offer a full reliable C2 solution.

1.2 Document overview

This document is structured as follows:

In the present chapter, the context is described, as well as the interactions with other work packages and deliverables. A glossary for domain-specific abbreviations and terms is also given.

The next chapter depicts the satellite-related aspects of the overall DroC2om system. First, some current satellite systems are presented, standardisation aspects are addressed and finally, a new SATCOM system concept for sustaining a reliable C2 link for U-space is proposed.

A third chapter presents an evaluation of the satellite link system concept, based on network/system level scenarios, and describes the performance models to be used in WP3 deliverables.

The last chapter gives conclusions on the potential advantages and shortcomings of the proposed SATCOM system concept.

1.3 Glossary

Abbreviation Explanation

AFRMS Airborne Flight and Radio Management System

ANS Air Navigation Services

AMS(R)S Aeronautical Mobile Satellite (Route) Service

ANSP Air Navigation Services Provider

ATM Air Traffic Management (manned and unmanned)

ATN Air Traffic Network

ATS Air Traffic Services

BGAN Broadband Global Area Network

BLOS Beyond Line-Of-Sight

BRLOS Beyond Radio Line-Of-Sight

BVLOS Beyond Visual Line-Of-Sight

C2 (C&C) Command and Control

CRS Cellular Radio Subsystem

DAA (D&A) Detect and Avoid

DUT Drone User Terminal

EASA European Aviation Safety Agency


12


FDD Frequency-Division Duplexing

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)

GBR Guaranteed Bit Rate

GES Ground Earth Station: Ground Facility hosting one or more components of the Satellite System.

GSE Generic Stream Encapsulation

HA Hybrid Access (BBF)

HAG Hybrid Access Gateway. A logical function in the operator network implementing the network side mechanisms for simultaneous use of both e.g. SAT and 3GPP access networks

HCPE Hybrid Customer Premises Equipment (CPE). CPE enhanced to support the access side mechanisms for simultaneous use of both e.g. SAT and 3GPP access

HDLGW Hybrid (MultiLink) DataLink Gateway

HDLUE Hybrid (MultiLink) DataLink User Equipment

HGW Hybrid-access Gateway

HO (Satellite beam) Hand-over

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 Indicator

L2 Layer 2 communication protocols

LA Link adaptation (radio)

LISP A Multi-Homing and Mobility Solutions for ATN using IPv6

LOS Line-Of-Sight

MAC Medium Access Control layer (communication protocol)

MLA MultiLink Adaptor

MLGW MultiLink Gateway

OC Operational Capability – this term is taken from the systems engineering method Arcadia implemented in the open-source tool Capella. In the frame of the project, an Operational Capability corresponds to a U-space Capability.


13


PHY Physical layer (communication protocol)

PiC Pilot in Command

QoS Quality of Service

RAN Radio Access Network

RCP Required Communication Performance

RLC Radio Link Control layer (communication protocol) – part of Link Layer

RLE Return Link Encapsulation

RLOS Radio Line-Of-Sight

RPA Remotely Piloted Aircraft: Equivalent to UAV, drone.

RPAS Remotely Piloted Aircraft System: Equivalent to UAS

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)

RTT Round Trip Time

SAT Satellite System/Network

SATPL Satellite Transparent Payload (supported by Platform)

SESAR JU Single European Sky Air traffic management Research Joint Undertaking

SFRMS Satellite Flight and Radio Management Subsystem

SGW Satellite Gateway

SRS Space Radio Subsystem

SWAN SRS - Wide Area Network

UAS Unmanned Aircraft System, including UAV, ground control station, and C2 link. Equivalent to RPAS

UAV Unmanned Aerial Vehicle. Equivalent to drone

UDR Unified Data Repository (5G)

U-Space See Table 2

UT User Terminal. Equivalent to DUT

VLOS Visual Line-Of-Sight

VPN Virtual Private Network

Table 1: Abbreviations


14


Term Explanation

C2, C2 DataLink, UAS DataLink

“Command and Control” Link, a data link established between the remote “Pilot in Command” (PiC) and the vehicle 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 vehicle from a customer point of view.

C-plane Control plane radio communication protocols; control messages, data packets used to manage the user plane (U-plane)

Drone UAV with private or commercial application, operating in the EASA Open or Specific category.

Hybrid Access The coordinated and simultaneous use of two heterogeneous access paths (e.g., LTE and SAT).

Hybrid Access path Network connectivity instance between HCPE and HAG over a given access network; SAT or 3GPP.

Hybrid Access session

A logical construct that represents the aggregate of network connectivity for a Hybrid Access subscriber at the HAG. It represents all traffic associated with a subscriber by a given service provider, with the exception of Hybrid Access bypass traffic, and provides a context for policy enforcement.

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

it can reference to a Drone payload, i.e. the equipment on board the UAV that is used to perform its mission (sensors, cameras, herbicide sprayers).

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

Radio adaptation Adaptation and configuration mechanisms on the PHY layer and MAC layer

SATCOM, satcom Abbreviation for satellite communication(s).

U-plane User plane radio communication protocols; payload end-user data packets

U-Space A set of new services and specific procedures designed to support safe, efficient and secure access to airspace for large number of drones.

Table 2: Terminology and definitions


15


2 Satellite system concept

In this chapter, first, we list some alternative SATCOM systems, which may seem good candidates for the provision of a C2 link for drone operation; second, today’s and tomorrow’s regulation aspects are overviewed, and the current orientations of involved standardisation bodies are portrayed. In a third section, a new satellite system design is proposed to cope with the provision of a reliable C2 link service. The last section gives a broader view and touches aspects of the integration with the cellular subsystem.

2.1 Current satellite systems for aeronautical safety services

Satellite communication systems have many differentiating arguments when compared to terrestrial solutions. Indeed, while the deployment costs of terrestrial systems can be sustainable in high-density areas, their use in low-density remote areas is much less interesting. In high-density areas, satellite could also be useful either as a primary means of communication or as a secondary one in order to improve the overall communication system’s availability. A satellite system, by nature, is able to cover large regions of the earth and can thus provide a cost effective solution to the coverage of both high and low density areas such as oceanic regions where reliable terrestrial coverage is non-existent.

2.1.1 Inmarsat

The Inmarsat service was initially targeted to providing a maritime communication service to the community for safety of life related issues. However, Inmarsat soon began to provide service to other communities such as aircraft and mobile users.

The space segment of the Inmarsat system is a constellation composed of several geostationary satellites (the number of satellites depend on the service as not all of them support all the services) that cover the earth with the exception of the poles. Aeronautical services supported by the system are currently Air Traffic Services (ATS) and Air Operator Certificate (AOC) services. These can either be used through the Inmarsat legacy ClassicAero service, or the recently introduced SwiftBroadband service (based on the BGAN technology adapted to the aeronautical context). The Inmarsat satellites use three different types of spot beams, one global spot beam for initial signalling and specific services, a set of regional spot beams (since the 3rd generation satellites) and very small spot beams (radius in the order of hundreds of kilometres) used for the BGAN service and allowing for smaller antennas to be used on the handheld terminals.

In terms of frequencies, the Inmarsat system operates the feeder link in Ku bands and the user link in AMS(R)S reserved portions of the L band – see section 2.2.2.1

The Classic Aero service is mainly used for establishing circuit oriented connections for low and medium quality voice and fax. In addition to these services, packet data services such as ACARS (Aircraft Communications Addressing and Reporting System) and ADS (Automatic Dependant Surveillance) can also be used.

The SwiftBroadband service offers much higher data rates than Classic Aero and takes advantage of the small spot beams of the fourth generation satellites to provide users with these data rates. The


16


SwiftBroadband service is based on the use of the IP protocol at network layer and is mainly used to provide passengers with Internet access.

In addition to the Inmarsat satellite constellation, the Classic Aero protocol is also used by the MTSAT system operated for the Japanese Civil Aviation Bureau (JCAB). The MTSAT system as described in (Oikawa & Kato, 2006) offers ATS and AOC services to airlines in the Asia/Pacific area and provides increased availability by using two specifically located geostationary satellites (MTSAT-1R and MTSAT-2).

Today, Inmarsat provides ATC services to the aeronautical community with a Required Communication Performance of RCP240. This corresponds to 240 seconds for any given controller/pilot interaction to take place.

2.1.2 Iridium

In addition to the Inmarsat and MTSAT satellite systems presented above, the Iridium low earth orbit constellation of telecommunication satellites also provides aeronautical communication services.

The Iridium constellation is comprised of 66 active satellites that provide complete coverage, including the earth poles. The feeder and inter-satellite links are operated in Ka frequency band while the user link is operated in the L band.

Services offered by the Iridium constellation are based on the GSM standard and include both voice and data oriented communications. In addition to these services, one-way paging services are also possible.

The Iridium constellation and services have completed the authorization process required to be used for AMS(R)S services.

Today, Iridium provides ATC services to the aeronautical community with a Required Communication Performance of RCP240, same as Inmarsat.

2.1.3 5G New Radio Non-Terrestrial Networks

Under the framework of 5G New Radio (NR) specifications, 3GPP has initiated in 2017 a first study item on “Study on New Radio () to support non-terrestrial networks”. The main target of these studies is to “foster the roll out of 5G service in un-served areas that cannot be covered by terrestrial 5G network (isolated/remote areas, on board aircrafts or vessels) and underserved areas (e.g. sub-urban/rural areas) to upgrade the performance of limited terrestrial networks in cost effective manner”.

The first study item work has concluded with a detailed technical report TR 38.811 [13]. Based on the outcome of this report, in a new 3GPP 5G NR Release 16 study item has been initiated in 2018 on “Study on solutions for NR to support non- terrestrial networks ()” in order to investigate “a set of necessary features/adaptations enabling the operation of NR protocol in non-terrestrial networks for 3GPP Release 16 with a priority on satellite access” [14]. The technical report TR 38.821 [15] contains the current agreements on the architectural and radio solutions proposed to be evaluated.

The 5G NR Non-Terrestrial Networks will enable the provision of radio connectivity services also to Aerial Vehicles. A common, standardised radio network architecture and radio interface with the 5G


17


terrestrial cellular networks will allow an optimised integration of the hybrid/multilink terrestrial and satellite access solution for UAVs.

2.2 Regulation and standardisation aspects

This section summarises the current work done by international standardisation bodies (ICAO, RTCA, EUROCAE). It expresses the satellite-related aspects for the Single European Sky and how they should be considered in the system design.

2.2.1 Regulatory elements for C2 Link provision

The Regulatory framework for services development in aviation involves several actors. During the past decade, for communication but not only for communication, the focus has been put on performance based operations. For communications, this translates in the definition of a “Required Communication Performance” that can be found in the ICAO published GOLD document [11]. 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. An RCP is expressed in seconds and ranges from RCP10 for the most stringent interactions, to RCP240 for the interactions in low density and oceanic regions. A similar metric, which is used to evaluate the systems in the frame of their support to ATC communications, is to be developed for the C2 Link.

Rulemaking in aviation is governed by ICAO and can be found in the 19 Appendixes to the Chicago Convention of 1944 as well as a set of ICAO document that serve as implementation guidelines and manuals to ease the interpretation of the Standards and Recommended Practices (SARPS) contained in the Annexes.

The C2 Link is defined in Appendix 10, Volume VI titled “C2 Link”. This Volume is not yet published but is under definition by the Remotely Piloted Aircraft Systems (RPAS) Panel of ICAO. A first part of Volume VI, Part I dealing with the operational SARPS related to the C2 Link will be studied by the Air Navigation Commission (ANC) in 2019 while a second part of Volume VI dealing with systems specifications will be made available in 2021.

Among the operational SARPS for the C2 Link, it is important to note that a requirement for operation in designated frequency bands is proposed (as an update to Annex 10 Volume V). As such, C2 Link is foreseen to be implemented in the following frequency bands:

For Satellite C2 Link, Frequency bands with an allocation to aeronautical safety services under the AMS(R)S. Frequency bands that meet these criteria are: the 1 610 - 1 626.5MHz and the 5 030-5 091 MHz frequency bands; or frequency bands with an allocation to aeronautical safety services under the Mobile-Satellite Services (MSS) where AMS(R)S operations have priority access. Frequency bands that meet these criteria are: the 1 545 - 1 555MHz and the 1 646.5 - 1 656.5MHz frequency bands;

For Terrestrial C2 Link, frequency bands allocated to the AM(R)S. Frequency bands with such allocations include the 117.975-137, 960-1164 and 5030-5091 MHz frequency bands.


18


In addition to these frequency band requirements, it is noted that provision of the C2 Link should only be performed using systems that are developed in accordance to internationally agreed aeronautical standards.

Civil aviation, and particularly the manufacturing community supporting the industry, are well used to working within a set of standards. In Europe, these are developed by EUROCAE, under EC mandate, and in the USA by RTCA under FAA direction. The standards are broadly grouped as MOPS (Minimum Operational Performance Standard) and MASPS (Minimum Aviation System Performance Standards), defining performance and functional requirements. Based on these standards, the safety agencies (FAA in the USA and EASA in Europe) publish TSO/ETSO ([European] Technical Standard Order) which define equipment interoperability and airworthiness standards for certification.

EUROCAE WG-105 is in charge of analysing the key issues related to the RPA operations in the context of European ATM (Air Traffic Management). In particular its activities are focused on Operations, Airworthiness, Command, Control, Communications, Spectrum and Security.

The objective of the work on Command, Control and Communication, Spectrum and Security (C3&S) is to maximise the relevance of its outputs to all classes of UAS and achieve alignment with regulatory directions and operational needs. The main technical deliverables (MASPS and MOPS) tactically address the needs of Certified RPAS for the C2 Link, Spectrum Management and Security. A series of technical reports will provide complementary guidance on communications, spectrum management and cybersecurity applicable to the other UAS categories.

The C3S Focus Team of WG-105 has already published the following document:

ER-016 - RPAS 5030-5091 MHz CNPC LOS and BLOS compatibility study

In addition to the above, the following documents useful for the subject of the C2 Link are foreseen to be delivered by the C3S Focus Team of the WG-105:

Minimum Operational Performance Specification for RPAS Command and Control Data Link (Terrestrial), a companion to DO-362 [12]

Minimum Operational Performance Specification for RPAS Command and Control Data Link (C-Band Satellite)

Minimum Aviation System Performance Specification for RPAS Command and Control Data Link

Guidance on Spectrum Access, Use and Management for UAS

2.2.2 Spectrum related considerations for Aeronautical Services

Aeronautical communication systems used for the transport of Command and Control for Unmanned Aerial Vehicles are considered as safety critical in their frequency allocation by the ITU.


19


Figure 2: Typical frequency bands used for safety aeronautical communications via satellite. These band allocations are managed by the ITU.

The principle of transmission in the safety satellite system is shown in Figure 2:

The mobile link, between the satellite and the aircraft, is built on a safety satellite spectrum allocation, based on AMS(R)S standard;

The satellite is in charge of signals frequency conversion, simultaneously from C or Ku band to L band for the forward link, and from L band to C or Ku band for the return link;

The fixed link, between the ground and the satellite, is built on a fixed satellite spectrum allocation, based on FSS (Fixed-Satellite Service) standard.

In following sections, the regulatory situation in the L band for safety and non-safety services is exposed, as well as for the Ku band.

2.2.2.1 AMS(R)S allocation in L band

The L band is defined as the Mobile Satellite Service allocation in the frequency ranges 1525-1559 MHz and 1626.5-1660.5 MHz.

Although the whole band is generally for MSS use, in certain portions of the band, safety related services are afforded a specific status in the ITU radio regulations, as shown on Figure 3.

In the sub-band 1646.5-1656.5 MHz and 1545-1555 MHz, the communications in the AMS(R)S are afforded priority over other types of communications, through the footnote 5.357A of the Radio Regulations (RR, 2008).

AMS(R)S AMS(R)S

mobile

forward

mobile

return

1545 1555 1646.5 1656.5 3600 or 12000 6400 or 14000

fixed

return

FSS FSS

fixed

forward

GESAES


20


Figure 3: AMS(R)S L band allocation for SATCOM

The concerned communications are those falling under categories 1 to 6 of Article 44 of the Radio Regulations, as listed below:

1: Distress calls, distress messages and distress traffic.

2: Communications preceded by the urgency signal.

3: Communications relating to radio direction finding.

4: Flight safety messages.

5: Meteorological messages.

6: Flight regularity messages.

7: Messages relating to the application of the United Nations Charter.

8: Government messages for which priority has been expressly requested.

9: Service communications relating to the working of the telecommunication service or to communications previously exchanged.

10: Other aeronautical communications.

In the specific context of the L band, given the technical nature of satellite systems involved, it has been felt more efficient to have multilateral meetings among the concerned parties instead of solely relying on Article 9 of the Radio Regulation (RR, 2008). In effect, the terminals in the L band have poor directivity which impacts any satellite network operating in visibility of that terminal, which leads to segmentation of the spectrum among systems.

Given the high demand for spectrum in the L band, it is difficult for a new entrant to have spectrum granted, even if this is for safety services. For non-safety services it is seen as impossible to have significant spectrum allocated for a new entrant.

Use limited to distress and safety communications

1626.5 (MHz) 1645.5 1656.5

1646.5 1660.5

1525 (MHz) 1544 1555 1545 1559 1530

Priority to AMS(R)S

(S5.357A) Priority to GMDSS

(S5.353A)

GMDSS: Global Maritime Distress and Safety System

AMS(R)S: Aeronautical Mobile Satellite (Route) System = In flight communications


21


2.2.2.2 AMS(R)S allocation in C band

The AMS(R)S has had a spectrum allocation in the 5000–50150 MHz band through footnote 5.367 of the ITU Radio Regulations since at least the early 90s. That allocation was therefore considered in the 2007-2012 timeframe for a SATCOM CNPC system in the framework of WRC-12 Agenda Item 1.3. The 5030-5091 MHz range, was until 2008 exclusively used by the Microwave Landing System (MLS) core band. Studies presented in ICAO and ITU-R showed that sharing between this SATCOM CNPC system and MLS was feasible, taken into account the largest deployment of MLS considered within ICAO.

The 2012 World Radiocommunication Conference (WRC-12) gave more visibility to this AMS(R)S allocation by including it directly in the Table of Frequency Allocations, and improved the regulatory framework related to the 5030-5091 MHz band.

The 2012 World Radiocommunication Conference (WRC-12) also granted an allocation to the aeronautical mobile route service (AM(R)S) throughout the same band 5030-5091 MHz.

Both AMS(R)S and AM(R)S allocations are limited to internationally standardised aeronautical systems. The only prospective user for both allocations is CNPC (Control and non-Payload Communications, i.e. C2 Link).

Since the SATCOM and terrestrial allocations exactly coincide in frequency, it is important to consider procedures by which they could share the band, this sharing strategy is under elaboration by ICAO and should allow for both terrestrial and satellite to co-exist using this frequency band.

2.3 Proposal for a C2 Link satellite system concept

This chapter aims at describing the satellite system concept with a top-down approach, starting from a reminder of the operational activities envisaged in the U-space context, down to proposals on the technical implementation of the physical architecture of the satellite system components. The functional architecture of the C2 link system is also depicted in a communication layer approach.

This chapter gives insight to C2-link-specific satellite concepts, although technical aspects may still be true for other satellite data services involving point-to-point communications or satellite mobile telecommunications with return channel – nothing comparable with mobile TV broadcasting. In particular, the fact that the C2 link satellite system described hereafter targets mobile aeronautical vehicles with relatively low data rates, rather than broadband land mobile terminals, has brought necessary adaptations to already existing techniques or standards. Other aspects, e.g. related to service management or interconnections of ground facilities, are not discussed since no critical or particular design is expected in these domains.

In order to provide more readability, a Model-Based System Engineering tool – named Capella – has been used by the project team. Some of the diagrams shown in the following sections are representations of the underlying system modelling that the project members have achieved.


22


2.3.1 Operational Analysis

Figure 4 presents the Operational Capabilities Diagram. At the moment of writing, this viewpoint is only one particular proposal, it is the starting point from which the system concept has derived, including the satellite-related aspects.

Figure 4 : C2 as a foundation capability for U-space services

This figure shows that some of the basic operational capabilities (OC), like e-identification, security, tracking, telemetry or emergency recover, can be seen as extensions (symbol “e” in Figure 4) of the “Command & Control” capability, in the sense that C2 can partly enable those OC or in other words the C2 capability is a foundation to other U-space capabilities (and thus U-space services). The view expressed in this figure is C2 centric, in that it is assumed that C2 plays a central role for U-space services and capabilities. However, alternatives implementations could be assumed, where, for instance, e-identification relies on a dedicated communication scheme.

The U-space capabilities are expected to involve drones (manufacturers), drone operators, and U-space service providers as well. Many of them would need information to be transmitted, post-processed, fused, managed, etc so that an U-space service provider exploits them to add value to raw collected data. Nevertheless, the transmission of these data requires the existence of a data link, and the C2 link that the DroC2om project has in charge seem a very good candidate. In consequence, drone operators (or the supposed C2 service provider itself) should interface with the U-space service provider so that all individual data are exploited by the U-space service provider. Many types of data on which other capabilities would rely, have to be considered: drone id for e-identification, drone position for tracking, telemetry data, C2 link performance indicators and/or C2 link loss for emergency, geofencing data (depending on the level of autonomy of the drone), …

From an U-space service provider point-of-view, the C2 capability is considered as already existing and accommodated by the drone operator and/or the drone manufacturer: at the centre of the figure, the Drone Operator “operates the drone flight through the C2 link”. This link is logically different from the mission link, which is the data link used for retrieval of the data collected by the drone payload


23


(photographs, videos, gas concentration measurements, surveillance data). The mission link is operated by a mission operator, and external actors are supposed to provide link services for that purpose. Those external operational actors, (of any kind: terrestrial or even satellite communication service providers) are not shown in this deliverable since it is out of the scope of C2 provision.

There may be situations where the drone operator itself could implement a proprietary reliable C2 link for the accomplishment of safe mission operations, in particular for Visual Line-of-Sight (VLOS) operations, as long as all authorisations and certifications are met.

Nevertheless, it is generally envisaged that the Command and Control Link would be the object of a service provision requiring a particular certification level, for all other missions where Beyond-Visual-Line-of-Sight (BVLOS) or Beyond-Radio-Line-Of-Sight (BRLOS) will occur.

DroC2om’s objective is to give a complete system concept to include both BVLOS and BRLOS in an integrated hybrid solution.

2.3.2 System Analysis

The current section presents the high-level System Analysis, showing interactions between the DroC2om system concept and other existing systems. The architecture is technology-agnostic and does not give any indication on the choices of implementation of the system. Only functional interactions with external systems are addressed.

In the following Figure 5, system functions are displayed in green boxes, either for the system-of-interest – the C2 Link System – or for the other external systems such as the U-space service provider, the drone operators, the C2 Link Communication Service Provider, and the drone platform (hosting communications device).

Figure 5 does not intend to portray an exhaustive list of system functions, at least for external systems. Of course, the U-space service provider will be in charge of a lot more functions, but some of them are emphasised here on purpose to illustrate the role of a C2 link system in U-space service provisioning.

More specifically, the C2 Link system primary function is to provide configurable end-to-end communication chains between a drone flight operating system and a drone platform, thanks to the following sub-functions:

Transmit Data from Ground to Air

Transmit Data from Air to Ground

Provide System Management


24


Figure 5 : High-level system functional diagram


25


These functions may be achieved with different architectural approaches. The DroC2om project intends to propose two potential sub-architectures with the ability to combine them into a hybrid-access scheme, as it will be depicted hereafter in section 2.4.

The following two sections of this chapter give details on physical architecture elements involved in the realisation of the main logical function of the system, i.e. the transmission of data between the RPS and the drone. An emphasis is put on the satellite payload and on the drone satcom transceiver, because the designs of these components are impacted by the C-band spectrum allocation; while at some extent, the design of the remaining components of the satellite radio subsystem (mostly ground-based equipment) can benefit from usual recurrent implementation choices.

2.3.3 Space vehicle physical architecture

2.3.3.1 Constellation

Satellite constellations are characterised by their orbital parameters, usually segregated into different groups: Low-Earth Orbit (LEO), Medium Earth Orbit (MEO), Highly Elliptical Orbit (HEO), and near-Geosynchronous Orbit (GEO).

This deliverable makes primary focus on GEO satellites since it is economically more suited to the development of new services in a well-defined region on Earth, however some elements described herein could also apply to other lower orbits satellite constellations for AMS(R)S, either for worldwide coverage or when polar coverage is expected. Geostationary satellite constellations also facilitate the deployment of ground facilities.

GEO constellations are compound of satellites at an approximate orbital altitude of 35,786 km, with an orbital period is 24 hours, whose consequence is that the satellite ground track only varies very slightly in time. From the drone viewpoint, the satellite is nearly fixed. Typical GEO constellations consist of only four or five satellites in equatorial orbits, quite uniformly spaced in longitude. In the scope of this deliverable, only the case of communications using a single GEO satellite covering the U-space region is addressed, but the system could be further extended to multiple-satellite constellation for worldwide coverage.

2.3.3.2 Hosting platform

The satellite (mission) payload is hosted on a satellite platform. The platform itself is considered out of the system scope and it could be either dedicated to the mission (C2 link relay), or shared for several missions – in that case we speak of a hosted payload. In the satcom system concept presented in this document, the choice of a dedicated or shared platform has no direct impact. Nevertheless, one assumption throughout this document is that the platform is geosynchronous. Hence a better coverage of the European sky would require that the platform’s orbital position is located at medium European longitudes (e.g. circa 5 or 6 degrees East). Moreover the choice of the platform type may be restricted by the specification of the embedded antennas (regarding their size or their capability to be deployable) either communicating with the Satellite Gateway on the one hand, or communicating with the drone on the other hand.

2.3.3.3 Satellite payload

The signal-in-space is relayed via a transparent GEO satellite payload. Figure 6 shows the top-level architecture of the satellite payload.


26


Figure 6: Satellite repeater architecture

The payload is a two-way relay and is actually composed of two repeaters, a first one for the forward communication from the ground to drones, a second one for the return communication between the drones and the ground. This type of repeater is known as bent-pipe.

Considering the forward repeater (upper part of Figure 6), one can find from the left to the right : the receive antenna, a Low-Noise Amplifier, a frequency converter, a High-Power Amplifier (HPA) link, an RF filter and finally the transmit antenna.

Figure 6 shows the RF links on each sides of the satellite: indeed, the satellite acts as a repeater:

either to amplify RF signals originating from the ground segment (named Feeder link - Forward) in direction of the drone (named UA-C2 link, forward),

or to amplify RF signals originating from the drones (named UA-C2 link - Return) in direction of the ground segment (named Feeder link - Return).

Apart from the C-band antenna, the frequency converters are the most critical elements.

The feeder link does not necessarily need to be operated in C-Band, although is remains the simplest option to avoid high frequency conversion on-board the satellite. Other bands like Ku or Ka may also be envisaged for the feeder link.

The frequency converter blocks here also concern the IMUX (Input Multiplexer) and the OMUX (Output Multiplexer) functions.

Other critical elements, such as precise local oscillators or signal pre-distorter (prior to the HPA), are not shown on this scheme.

2.3.3.4 Satellite antenna

In the proposed system concept, the transmit/receive satellite antenna (for the UA-C2 part) is composed of a reflector illuminated by an array of multiple RF sources, so as to create a multibeam antenna. As a baseline, the antenna could be composed of a relatively small number of sources (less than 10), nevertheless sufficient to provide a full coverage of the ECAC zone. The following figure depicts the beam configuration and the ECAC zone that such an antenna would cover, using 8 spot


27


beams. Of course the proposed concept can be extended to more spot beams, each with a lower single coverage; this could allow a more adaptive solution to closely fit to areas of higher drone density.

Figure 7: Footprint of a multi-beam satellite antenna covering the ECAC zone

The red, black and orange tracks are the projection of the edges-of-coverage (EoC) for each beam over the Earth surface. The Edge-of-coverage represents the geometrical bounds of the radiated power, after reduction by a factor of 2 (i.e. -3dB) with respect to the maximum EIRP at boresight. The EIRP results from the High Power Amplifier characteristics and from the antenna gain profile; for a dish reflector, the antenna gain depends on the dish diameter and the carrier frequency.

2.3.4 Drone satcom transceiver physical architecture

2.3.4.1 Airborne satcom antenna

The satcom antenna should be designed to receive and transmit RF signals in the AMS(R)S Band, more specifically in the 5030-5091 MHz frequency range. Several options can be envisaged :

A single-element antenna, such as a slotted waveguide, a quadrifilar antenna, a choke ring antenna, or a conical antenna

A sectorial antenna: a configuration compound of several simultaneously active single element; for instance 8 patch elements

A commutation antenna : several elements are accommodated, but only switched on when needed, based on the direction of arrival/transmission


28


A phased-array antenna, whether in an analog way or capable of achieving digital beamforming, with the particular advantage that transmitting and receiving patterns may be tuned independently.

In the proposal baseline, the commutation antenna is retained, with a total of 8 circular patch elements with the following layout, as shown in Figure 8.

seven azimuthal directions with mean elevation

one additional vertical direction.

Figure 8: Circular patch elements (model with 8 similar elements)

This structure is adopted such that each of the 7 azimuthal elements covers +/- 25 degrees (Az) in the 0-to-60 degree elevation range; whereas the top element covers all azimuthal directions for the 60 to 90 degree elevation range.

The following radiation pattern applies to phi=0° azimuthal direction, when the signal reception is at centred on one of the 7 surrounding elements. Here, the gain gets a very good value (>6 dB) from horizon to 65º of elevation. Moreover, the top element also has a +6dB minimum gain. A margin of 1dB will account for switching losses, so the typical antenna parameters are:

8-element circular patch commutation antenna structure

Gain = 5 dBi in all directions above horizon. More details are available in [4].

Antenna dimensions are 10cm x 10cm wide, 5 cm high.

This type antenna was chosen as the relatively small size allows an affordable accommodation on the drone body, compared to dish reflectors requiring tracking control system. It is also a good trade-off between cost, efficiency and complexity, compared to the realisation of possibly larger antenna arrays offering digital or analog beamforming capabilities.

2.3.4.2 Airborne satcom radio

The airborne satcom radio converts RF signals (PHY) into L2 datagrams, and reversely. It is composed of critical elements such as:

RF ports for the connection of the C-band antenna (receive and transmit)


29


RF filters : the filter bandwidth must be designed in accordance with AMS(R)S frequency range and take into account extra Doppler shifts due to satellite-to-drone relative velocities.

A modem including

o Analog-Digital converters (ADC and DAC). The design of the sampling unit must take into account the operating frequency band and consider the use of additional frequency converters if needed.

o A Digital Signal Processing unit to process to the signal demodulation/modulation. It converts signal samples into data bits by using the definition of the communication layers.

Network ports for transmitting/receiving IP packets with the drone internal systems via the MultiLink Adaptor and the AFRMS.

2.3.5 Functional architecture

The System high-level functions were listed above : transmitting data from ground (drone operator or pilot sending flight commands and logon messages) to air (drone receiver); reversely transmitting data from air to ground (return traffic at least includes flight parameters and status messages); along with system operation.

System operation functions are not being detailed hereafter. However, they need to be taken into consideration so that the System could be operated by an external actor to provide the C2 service. These functions can be partly shared with the cellular component of the overall system. Briefly, they would consist in: system configuration, drone and pilot registry management, system performance analysis, accounting, fault monitoring, etc.

The current section gets technically detailed; thus, in order to help the understanding of the layered communication system concept, numerous acronyms were used. Those acronyms are however not mentioned in the glossary at the beginning of the document, since their use is limited to the following sub-sections and Appendix B.

The current section focuses on the sub-functions needed to provide the end-of-end-communication capability, between the terminations of the satellite system: the MLA and the MLGW. From an OSI point-of-view, the Satellite subsystem is designed to provide IP-based services for upper-layer application traffic. Figure 9 shows the different domains covered by the stack of the communication layers. The logical components are represented with blue boxes; grey boxes stand for physical elements, i.e. from left to right : the drone platform, the satellite platform, the ground segment, the hosting facility of the Hybrid DataLink Gateway and the remote pilot station.


30


Figure 9:End-to-end service overview

The drone C2 application layer traffic is supported by the transmission of IP packets both ways, from the pilot centre to the AFRMS, also possibly to other airborne subsystems (navigation, Detect And Avoid systems camera, engine...), and reversely. In the scope of this satellite-related document, the Link Layer (L2) is defined between the drone satcom transceiver and the SGW. L2 then relies on the definition of an adequate air interface (Radio/PHY layer). It has to be noted that in this scheme, the components related to the hybrid-access solution, i.e. the MLA and the MLGW, are shown fully transparent in the IP level communication chain; however hybrid mechanisms are needed and will be discussed further in deliverable D4.3, on how to adapt transport packets from/to both the Cellular and the Satellite Radio Subsystems.

2.3.5.1 Radio Bearers

The radio bearers act as dedicated communication channels between the drone satcom receiver and the SGW. The service area is covered by several beams (below only five are represented for comprehension). The drone can move inside this coverage, and the System selects the best appropriate beam, regarding the conditions of propagation.

The beam footprints actually overlap each other, such that a drone could move out of a spot region without losing connectivity immediately after it has crosses the –3dB boundary. However, if the drone moves further and there is a change in the selected radio bearer, this situation is referred to as a “satellite beam handover”. This kind of handover management will be discussed in Appendix B and from a radio communication point-of-view, it will be illustrated in the scenario described in 3.2. Appendix A gives more insight on the radio link budget modelling.

As shown below, the Forward (FWD) radio bearers and the Return (RTN) radio bearers follow slightly different schemes.

FWD Radio Bearer

For the FWD link, only one channel per destination spot beam is defined. This means that the FWD communication links towards all drones considered as active in a given spot region share the same carrier as shown in Figure 10: on the left, the SGW selects the right carrier according to spot region where the drone is located. The superimposed PSD plot (Power Spectral Density) is displayed for concept illustration only and it does not reflect an actual strategic choice of consecutive channel frequencies.


31


Figure 10: FWD Radio Bearer : one carrier per spot beam

RTN Radio Bearer

For the RTN link however, each drone is given a dedicated channel carrier in the frequency plan. For illustration purpose, only 2 drones per spot are shown in Figure 11. As in the FWD case, the displayed spectrum allocation is not representative of an actual choice of order in frequency channels, but used for concept illustration purpose.

Figure 11: RTN Radio Bearer : one carrier per drone

Spectral occupation for radio bearers

The 5030-5091 MHz frequency band which is allocated by the ITU for the aeronautical mobile satellite (route) service [AMS(R)S] among other service will be considered for the definition of C2 Link satellite subsystem. This is applicable for the radio communication between the drone and the satellite only; the feeder links between the ground segment and the satellite could use different bands or the same C-Band.

The Satellite subsystem will work in Frequency-Division-Duplexing (FDD) scheme. Then separate bands are to be used for FWD and RTN links. More particularly, it would be an advantage to use the lowest part of this band for all drone-to-satellite uplinks (RTN) and the highest part for all satellite-to-drone


32


downlinks so that free-space losses conditions are slightly favourable regarding the drone power supply, as illustrated in Figure 12.

Figure 12 : Spectral occupation for radio bearers

2.3.5.2 Physical Layer

The above definition of the FWD and RTN radio bearers stand for the RF sub-layer of the PHY layer (frequency tuning).

In baseband domain, the consecutive steps to transform a BBframe into a PLframe (FWD) or an FPDU into a PLburst (RTN) are the following (see Link Layer definition in next section 2.3.5.3):

Scrambling the bits for energy dispersal

Slicing the BBframe into fixed-size blocks for coding

Coding the sliced blocks into code words

Interleaving the coded bits

Mapping bits to modulation symbols and add signalling symbols to ensure synchronisation and channel compensation at receiver side.

Pulse-shaping and modulation of a baseband signal and up-converting to the radio bearer centre frequency

Since the satellite payload is non-generative, it will essentially affect the RF sub-layer with band-pass filtering and frequency translation. However, the high-power amplification non-linearity will eventually cause signal degradation and distortion. Moreover because of drone mobility, the relative power gain between one drone and another could be seriously affected. Thus, the recommendation is to use a constant-envelope modulation scheme, such as CPM (constant-phase-modulation, e.g. MSK), in conjunction with the above-listed digital communication techniques.

FWD Physical Layer framing

The Satellite Gateway transmits a continuous stream of physical layer frames, named PLframes, on each forward radio bearer. A PLframe is designed to transmit a complete BBframe, as discussed hereafter in section 2.3.5.3. The portion of time allocated to a PLframe is therefore the same as the one allocated to a BBframe (one timeslot). Figure 13 depicts the steps for the construction of the PLframe, starting with a BBframe byte-stream.


33


Figure 13 : Building a PLframe stream (FWD link)

RTN Physical Layer framing

A PLburst is also a sequence of modulation symbols used to transmit the data bytes of the FPDU on the RTN link. The same steps are necessary to build a PLburst than those for the construction of a PLframe.

The main difference would be that additional symbols at the beginning and at the end of the PLburst are needed for power ramp-up and power ramp-down; indeed on the return link, from a single drone point of point, data is not necessarily transmitted over the air and silences are not filled with dummy PLbursts.

2.3.5.3 Link Layer

The current section focuses on the definition of the Link Layer (L2) between the drone satcom transceiver and the SGW as shown in Figure 9. From a L2 point of view, the satellite payload does not enter into consideration. Layer 2 shall :

provide bearers to user traffic IP packets (user plane)

provide drone control session (control plane)

More specifically, the Radio Link Control and Medium Access Control (RLC/MAC) functions consist in:

the identification of the traffic flows towards the different user terminals on the FWD link

the multiplexing/de-multiplexing of higher layer Protocol Data Units


34


the multiplexing/de-multiplexing of user and control plane data to/from the physical layer

the splitting/recombining of higher layer Protocol Data Units into Physical Protocol Data Units

the buffering and queuing of data flows

the scheduling and the priority management of flows for different classes of service the mapping to the physical link. This includes radio resources management on the FWD link and the identification of available timeslots for transmission on RTN link

Overview of a drone session

A drone session extends from the time a drone requests to log on the System until it logs off. In between, the drone-to-SGW communications are almost only user traffic, but depending on the drone position and the beam configuration, handovers must be anticipated and signalled. Figure 14 depicts the drone session timeline in terms of utilisation of L2 regarding the transmission of user traffic or signalling traffic for a single drone

Figure 14 : Drone session timeline

Session initiation : the session context is built on drone request. The drone logs on; no user traffic data are exchanged

Session maintenance : user traffic can be exchanged; and the SGW monitors the presence of the drone during possible silent periods with an echo protocol. Satellite beam handovers are managed.

Session release : the drone logs off.

Drone session control will be detailed further in Appendix B.

Link Layer channels

A link layer channel is one-way and is dedicated to the transport if a given type of data. Different types of link layer channels have to be implemented. Link Layer channels rely on the previously discussed radio bearers. How link layer channels map to radio bearers is explained further in this section. In order to provide the transmission of user traffic as well as signalling, the following L2 channels are defined:

FWDS : Forward Shared (/Spot) channel

FWDD : Forward Dedicated (/Drone) channel

RTNS : Return Shared (/Spot) channel

RTND : Return Dedicated (/Drone) channel


35


The FWDS (resp. RTNS) channel is shared among all drones within a beam already logged (resp. attempting to log on). Only control data are exchanged on these channels. They are permanent channels. The FWDS is assigned to broadcast and unicast signalling flows. The RTNS is assigned to logon requests.

The FWDD and the RTND are dedicated to a single drone ; they can convey user traffic data or control data as well. These two dedicated channels are temporary channels : they are built when a drone logs on and they are released when the drone logs off. The FWDD and the RTDD channels are assigned to unicast signalling flows and to data flows. A more detailed description of the L2 channel characteristics is given in section .

Layered model

The following section give rapid hints on the terminology being used in the layered model of the data transmission function and how it interfaces with the upper IP layer and with the lower PHY layer.

Figure 15: Link Layer Model

The four types of L2 channels are transmitted thanks to Link Service Data Units (LSDU). Depending on the type of L2 channel, an LSDU can be then either a user traffic IP packet, or a L2 control packet.

Any LSDU then goes through the adaptation sub-layer:

For the FWD link, the Generic Stream Encapsulation (GSE) is used

For the RTN link, the Return Link Encapsulation (RLE) is used


36


After encapsulation, on the FWD link, the GSE packets are sliced into BBFrames; on the RTN link, the RLE Packets are sliced into FPDU (Frame Protocol Data Unit).

Finally, the BBFrames are transmitted thanks to Physical Layer frames (PLframes) on the FWD link; FPDU are transmitted thanks to Physical Layer bursts (PLbursts) on the RTN link as described above in section 2.3.5.2.

Adaptation sub-layer (encapsulation) and framing

The adaptation mainly consists in performing fragmentation on the transmitting side, and reassembly on the receiving side. The adaptation sub-layer shall adapt variable-size LSDUs to fixed-size BBFrames or FPDUs. The adaptation sub-layer is crucial in that it adapts the upper layer to the physical medium.

FWD link

The Generic Stream Encapsulation method specified here is derived from [6] ETSI TS 102 606, “Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol”. Depending on the size of the LSDU, a GSE packet may fully contain the LSDU or only a fragment. A GSE packet always starts with a GSE header followed by a GSE payload, but if fragmentation is needed, a CRC field is appended at the end of the GSE payload.

The adaptation considers 3 cases, depending on the LSDU size, and taking also into account the additional GSE Header, the LSDU + GSE Header would fit into:

1 BBFrame

2 BBFrames

or 3 and more BBFrames

Only the first 2 cases are depicted in Figure 16; the case where fragmentation in 3 and more GSE packets (further mapped to BBFrames) is marginal. Actually, given the maximum expected size of an LDSU, this case should never occur. Figure 16 also shows the insertion of padding bytes: if no remaining encapsulated fragment of the LSDUs is to be transmitted, padding is necessary since the BBFrame has a fixed size.


37


Figure 16 : GSE adaptation - possible fragmentation

This section only aims at explaining the concept of encapsulation; details on the sizes of the different header fields or payload fields are not given.

RTN link

The Return Link Encapsulation method specified here is derived from ETSI TS 103 179, “Satellite Earth Stations and Systems ; Return Link Encapsulation (RLE) protocol” [7].

The adaptation sub-layer interfaces to the physical layer with FPDUs (Frame PDUs). The adaptation consists in:

transforming an LSDU into an Addressed Link PDU ( ALPDU)

fragmenting this ALPDU into 1 or more Payload-adapted PDU (PPDU)

assembling PPDUs into FPDUs

Transforming an LSDU into ALPDU consists in inserting an additional header for Link Layer Control and appending an optional CRC, in case fragmentation is needed. The inserted header allows for piggybacking signalling on a user data unit.

Fragmentation shall be performed when ALPDU size is not compatible with the available space of the current FPDU. The same 3 cases as in GSE can occur: no fragmentation, 2-fragment encapsulation or 3-and-more-fragment encapsulation. When necessary, padding should be used to complete fixed-size FPDUs.

Time frame structure

The FWD and the RTN carriers are used in Time Division Multiplex (TDM).

On the FWD link, the Satellite Gateway shall maintain a time frame on each spot. The Time Division Multiplex is a repetitive sequence of 300-millisecond multiframes (MF), each multi-frame being


38


structured in 5 time-slots (TS). Figure 17 shows several forward link time frame structures (one colour per beam). The first transmitted time slot in each multiframe (TS0) is reserved for the FWDS channel (signalling purpose).

Figure 17 : Time frame structure

On the return link, the drone satcom transceiver shall continuously maintain the time frame, with a similar structure. In particular, the beginning of TimeSlot0 must be kept synchronised between the reception (FWD) and the transmission (RTN), although a drone may not be continuously transmitting data, as illustrated in Figure 18.

Figure 18 : FWD/RTN synchronisation on drone side

From a framing point-of-view, one timeslot exactly maps to:

one BBFrame for the forward link and,

and to one FPDU on the return link.

From a L2-channel point-of view:


39


the FWDS channel is mapped to TS0. In case fragmentation occurs and several BBFrames are needed to transmit an LSDU for this shared channel, consecutive multiframes (TS0 only) are necessary.

The FWDD channel is mapped to any TS, respecting possible priority management rules and taking into account the half-duplex capability of the drone satcom transceiver. Usually TS1 to TS4 will convey the FWDD channel, but a GSE packet concerning a given FWDD channel can also be transmitted in TS0 if the associated BBFrame had enough space to convey this GSE packet.

The RTNS channel is mapped to any TS (used for logon only).

The RTND channel must use the time slots that were not already allocated to the FWDD channel of the concerned drone.

From an SGW point-of-view:

TS0 is reserved to transmit FWDS and possibly FWDD channels (shared carrier for all drones in one beam)

Logon requests sent by drones via the RTNS can be received and processed at any time by the SGW transceiver (one dedicated carrier per drone).

RTN user traffic

From a drone point-of-view

The satcom transceiver listens to shared system information broadcast in TS0 by the SGW

Synchronisation is maintained to continuously keep aligned both time frames on the FWD and the RTN sides, even if the drone RTN traffic is null.

Once system information is received/updated, the drone requests for log on any available time slots using the RTNS channel.

Once the drone has logged on, the drone RTN traffic uses the RTND channel on any available time slots.

Time Slot Allocation

Forward link

The SGW allocates FWD timeslots to a drone satcom transceiver, taking into account its Half-Duplex capability. TS allocation is notified using the FWDS channel at the beginning of every multiframe in a dedicated table named TSTP (Time Slot Time Plan):

TS0 is statically allocated to the FWDS channel and partially to FWDD channels when room is available instead of padding.


40


TS1 to TS4 are dynamically allocated to FWDD channels on a per-multiframe basis. Several FWDD channels can be multiplexed in one TS and one drone listens to all TS. As a conclusion, one TS may be allocated to several drones.

Each FWD timeslot is allocated taking into account the traffic needs on its return link : some timeslots are intentionally left “free” for a given drone so that its return traffic can occupy those timeslots (half duplex) backwards. Of course FWDD channel of other drones use these “free” time slots.

The TSTP table is renewed at each multiframe and transmitted at the beginning of the TS0 BBFrame and is valid for the current multiframe.

Priority management rules can be set-up to provide a strategic timeslot allocation, allowing slower transmission delays for the more urgent traffic types. The BBFrames are filled with GSE packets according to the priority level of an LSDU. If fragmentation occurs, the priority management rule is applied per fragment, possibly leading to the interleaving of fragments originating from different LSDUs. An appropriate header field identifying a fragment can be created to cope with the interleaving.

The priority levels for the FWDS channel are defined as :

a) TSTP

b) Other broadcast signalling

c) System tables for logon

d) FWDD channels – if the GSE packets can fit in the BBFrame.

The priority levels for the FWDD channel are defined as :

a) L2 Signalling

b) Pilot voice – in case C2 relays the ATC communications

c) Other data.

Return link

The drone can transmit its logon request in any timeslot (RTNS). Transmitting in a return TS0 supposes that the System tables have been acquired previously. Although a drone uses a dedicated carrier, RTN timeslots are not always free: the TSTP table provided at the start of received TS0 indicates which TS must be listened to, and so which remaining TS are available for RTN traffic.

In terms of priority management rules, the drone RTND channel should consider the following ordered levels:

a) L2 Signalling

b) ATC voice – in case C2 relays the ATC communications

c) Other data


41


Resource Management

The FWD channels are based on permanent carriers, one per spot beam. On the opposite, the RTN channels are based on several carriers:

For a given drone session, one dedicated carrier is dynamically assigned to a drone by the SGW. This carrier is chosen out of a pool of statically beam-assigned carriers.

One shared carrier is permanently assigned to a spot beam for use by the RTNS channel

Table 3 summarises the characteristics of the four defined L2 channels. Some information in this table is detailed in section Appendix B (Drone Session Control).

Channel Carrier Timeslot Topology From To Time span

FWDS

static beam FWD carrier

TS0 point-to-

multipoint SGW

all drones in spot beam

permanent

FWDD TS1-4

(+ TS0)

point-to-point

SGW one logged or logging

drone

drone session

RTNS static beam RTN shared

carrier TS0-4

Collect

(slotted ALOHA)

all drones initiating a

session within spot

beam

SGW permanent

RTND

dynamic beam RTN dedicated

carrier

available TS0-4

according to TSTP

point-to-point

one logged or logging

drone SGW

drone session

Table 3 : Link Layer Channel characteristics

2.3.5.4 Security, identity, encryption

The security, identity and encryption procedures are based on the DVB-RCS control procedures described in chapter 9 “Security, identity, encryption” [8] with the differences identified hereafter.

The goals of the security procedures defined hereafter are:

• Authentication of the DUT by the SGW

• Authentication of the SGW by the DUT

• Authentication of all control plane exchanges (for non-repudiation)

Upon logon, the DUT authenticates the SGW as belonging to the system. This is performed by verifying through a crypto challenge that the SGW is in control of the private key of the certificate either pre-loaded or obtained through broadcast in the system tables. Prior to engagement in the crypto challenge with the SGW, the DUT verifies that the SGW certificate is signed by the system Certification Authority.


42


Upon logon, the SGW authenticates the DUT as belonging to the system and being allowed to logon to the system. This is performed by verifying through a crypto challenge that the SGW is in control of the private key of the certificate either pre-loaded or obtained through broadcast in the system tables. Prior to engagement in the crypto challenge with the SGW, the DUT verifies that the SGW certificate is signed by the system Certification Authority.

Forward Link

All control messages exchanged on the FWD link are signed by the SGW using the HMAC hash value as defined in section 0. Upon reception of the message and prior to any action, the DUT verifies the HMAC value. The DUT discards the message without further action if verification fails.

Return Link

Similarly, all control messages exchanged on the RTN link are signed by the DUT using the HMAC hash value as defined in section 0. Upon reception of the message and prior to any action, the SGW verifies the HMAC value. The SGW discards the message without further action if verification fails.

Security cryptographic primitives

The DUT and the SGW are considered as each being in possession of an X.509 certificate issued by the CA of a common PKI. Additionally, each entity is in control of the associated Private Key (eventually stored on a hardware security module or smart card).

Optionally, the DUT certificate can be known to the SGW, indexed by its ID.

Optionally, the SGW certificate can be known to the DUT, indexed by its ID.

Public key exchange

A symmetric session key is established between the sender and receiver using the DH algorithm

Hashing

The symmetric session key established during logon is used to produce key-hashed authentication code for the messages exchanges that require it. The HMAC is truncated to t-leftmost bits with t an implementation variable. HMAC computation shall use SHA-256 function.

Encryption

Encryption of user data and/or control data is not supported.

Pseudo-random numbers

Random number generation shall follow the guidelines of cryptographically secure pseudorandom number generators.

Padding


43


When required, padding of control messages prior to computation of the HMAC function is performed using random bits generated using a generator with a salt value to be encrypted in the exchanged message header using the symmetric session key.

2.4 Integration with the cellular network

2.4.1 Logical Architecture

The Logical Architecture level splits the C2 Link System into Logical components and describes the logical interfaces between those components. Logical components accomplish logical functions that, in conjunction with each other, realise the high-level system functions.

High-level Logical Architecture

The following diagram shows the high-level Logical Architecture

Figure 19 : High-level Block Diagram of the Logical Architecture with external logical actors

The logical architecture splits into :

Logical components ensuring the multi-link communication synchronisation between the SRS and the CRS is ensured by the HDLGW subsystem on the ground; on board the aircraft, the synchronisation is ensured by the HDLUE. More details will be given in deliverable D4.3 and shortly in section 2.3.5.2:

o the Hybrid DataLink User Equipment : this component is airborne, i.e. it has to be accommodated upon the drone, but it is actually a part of the System. Its role is to be the entry point of all communications conveyed by the C2 link, without regarding the kind of access (cellular or satellite). It works both ways, gathering forward link data sent by the pilot over any air interface, through the cellular link and/or the satellite link, to the Air Flight and Radio Management System (AFRMS), connected to the “drone port”. The AFRMS is embedded on the drone platform and is not part of the C2 Link system. It is reversely in charge of gathering potentially useful sensor data,


44


emergency camera video, flight parameters, DAA data…to the HDLUE (through the “drone port”), which transmits it back to the pilot through the Cellular- and Satellite- Radio Systems.

o the Hybrid DataLink Gateway: this component is ground-based. Its actual location is not imposed by the system concept, but it must be accessible via a terrestrial network from the pilot centre where either the pilot-in-command or a piloting system (for semi-autonomous drones) is hosted. It is assumed that the Command and Control communication data entering this component have been conveyed over secure links that are outside the System scope. The Air Traffic Network (ATN) is envisaged as a good candidate for supporting this kind of traffic.

the Cellular Radio Subsystem: the details on the architecture of this subsystem, what radio mechanisms are considered, and the performance results are available in deliverable D4.1

The Space Radio Subsystem (SRS): this logical component is the subject of the current deliverable. The end-to-end transmission chain is detailed in the next section below.

Logical Flows

Two types of flow are shown in the above diagram.

User traffic flow

Management flow

The forward user traffic flow occurs between the pilot centre and the drone platform

through the HDLGW, that duplicates the flow simultaneously to both

the SRS and the CRS, then to the

airborne HDLUE, that processes datagrams possibly received from both cellular and satellite path and discards one if necessary

and finally to other systems aboard the drone platform (the entry point being the AFRMS)

The return user traffic uses the back path in a similar but mirrored approach.

The management flow occurs between the C2 Link Management System Centre and the different ground-based subsystems : SRS, CRS and HDLGW. It is expected that each of these subsystems will provide configuration and monitoring capabilities to a remote management centre hosted on the C2 Link operator side.

SRS Logical Architecture


45


Figure 20 : Detailed Logical Architecture for SRS and Hybrid DataLink components

Going into logical architecture one level down, we have the following Space Radio Subsystem breakdown structure:

SWAN stands for SRS-WAN. This component provides internal connectivity between all the ground-based SRS components : SGW1, SWG2, SRS-M and SFRMS. The SWAN conveys user traffic as well as control traffic and management traffic

SRS-M :Space Radio Subsystem Management centre. It is the single entry point for SRS management (link configuration, drone registration, space system update…). This centre has the possibility to configure, monitor other components of the SRS to match the C2 Link service provider requests, in response to the drone operator needs. It can also supervise the remote software updates and it hosts the registry for drones and drone users. It is connected to other components through the SWAN.

SGW1: The Primary Satellite Gateway is hosted in a Ground Earth Station and its role is to send the forward user traffic received from the pilot centre through the SFRMS and the SWAN up to the satellite repeater over the air interface. Similarly, the SGW1 receives the return user traffic from the satellite repeater and sends it back into the SWAN towards the SFRMS and the pilot centre. RF signal modulation and demodulation is achieved at the SGW.

SGW2: A redundant Satellite Gateway is anticipated in the system for maintaining a certain level of quality of service. It is expected to be a duplicate of the SGW1. Control traffic is conveyed between SGWs and the SFRMS for maintaining a drone session in case of failure of the primary SGW.

SFRMS: The Satellite Flight and Radio Management Subsystem is the entry point for the user traffic into the SRS. The SFRMS is responsible for the control of SGWs and has the ability to switch the user traffic from the primary SGW to the secondary (redundant) SGW in order to maintain the quality of service in case of failure.

Satellite Payload (SATPL): The role of the payload is to receive the user traffic (RF signals) sent by either the primary or the redundant SGW, and to repeat the signal down to the HDLUE. Reversely, the drone sends back the traffic to the HDLUE, up to the satellite repeater then


46


down to the active/selected SGW before this return user traffic is conveyed to the pilot through the other SRS components and HDLGW.

It has to be noted that the Satellite platform (hosting the SATPL) is not part of the SRS, or the overall System. This implies that the AOCS (Attitude and Orbit Control System) is not considered as a subsystem. At some point, there may an interface between the external C2 Link Management System and the AOCS.

Logical component breakdown structure

Figure 21 : Logical component breakdown structure (partial)

The Hybrid DataLink User Equipment collects signals from the cellular network and the satellite network; hence it is responsible for discarding duplicate messages if any. The collecting and discarding are performed by the Multilink adaptor (MLA) on the FWD datagrams provided by both the satcom and the cellular transceivers. The MLA also backwards dispatches RTN datagrams received from the AFRMS to the satcom and cellular transceivers.

At this state of the study, the transceivers processing the cellular and the satellite data are assumed to be separate, each of them hosting a domain-specific radio to modulate and demodulate binary messages into two kinds of RF signals transmitted over different PHY layers. Nevertheless, this logical


47


architecture would also remain applicable even if similar technologies were to be used in each separate link (e.g. 5G via satellite), with physical components able to work in both cellular and satellite domains.

2.4.2 Combination of subsystems

The combination of both cellular and satellite networks inside the Hybrid DataLink User Equipment and the Hybrid DataLink Gateway relies on the selection of the most appropriate subsystem at any time during the C2 communication. It is assumed that the applicative traffic is conveyed by IP packets, and an adapted Link Layer (L2) has been proposed here above.

Several hybrid-access schemes have been touched in deliverable D4.1; Deliverable D4.2 does not intend to emphasise one particular scheme. Such trade-off would be the object of deliverable D4.3.

Nevertheless, it has to be noted that the integration of both cellular and satellite subsystems in an overall dual DroC2om System could benefit from adaptive capacity management rules, potentially generating value-added feedback information from one subsystem to another. Below are described example situations where the overall system capacity is not the sum of its subsystem’s capacity.

Overall System capacity management

The chapter below focuses on the impact of an alternative available link on the Satellite Radio Subsystem network capacity management. This approach can be reversely applied to the Cellular Radio Subsystem.

One of the logical components, the SRS-M, provides an interface for configuration and monitoring (see) to the external C2 Link System operator. A similar interface would also be available for the Cellular Radio Subsystem, and for the Hybrid DataLink Gateway.

Hence, one of the operator’s roles would be to determine a dynamic capacity management strategy, based on the link Key Performance Indicators of each single cellular or satellite link. For the C2 Link System users, i.e. the drone operators, such balancing strategies would be either transparent or well-defined, depending on the operator’s business model and its ability to maintain the Quality of Service for the provision of the C2 link.

The following cases do not take into consideration the trivial case where only one of the cellular link or the satellite link is available.

In case both the Cellular Radio Subsystem and the Satellite Radio Subsystem show good link KPI (e.g. in rural areas equipped with cellular network), one strategy could consist in releasing e.g. the satellite access on purpose, so as to reserve satellite capacity in this area for another drone mission.

In case the CRS show good link performance but the SRS shows medium link performance, one particular strategy could consist in releasing the satellite link in order to get new resources for drones in more favourable conditions.

Link performance management

The evaluation of the satellite link performance requires a set of criteria, which include at least


48


Measurement of Latency at L2 level:

o When both cellular and satellite links offer reliable packet transmission, latency could be a selection criterion to release one of the two links. Nominally the HDLUE and the HDLGW would dispatch incoming data packets to both Radio Subsystems and then discards the late packet copy.

o If for a reason or another, one of the two links (cellular or satellite) always conveys packets with a higher latency, this link becomes somehow useless since all packets transmitted via this subsystem are discarded at the HDLUE or the HDLGW.

o The decision could be (manually or automatically) taken to log off the drone from the slowest Radio Subsystem so as to improve the overall system capacity

1. Measurement of Error rate level at PHY level. Indeed unfavourable propagation channels cause packets:

o to be lost and retransmitted, at some extent, in cellular networks. The link would suffer an increase in latency. In this case, packet-error rate measurement could allow the System operator to anticipate the activation of the satellite link as a backup, e.g. before the drone reaches the edge of a cell with no possible handover (flight over sea)

o to be lost in GEO satellite network where no retransmission is foreseen. The link loss remains acceptable up to a few seconds, depending on the drone mission type, speed, and environment. Forcing the activation of the cellular link would be an effective solution in case a drone flies near the edge-of-coverage of a satellite beam – capacity management could detect this kind of situation – but when a handover is not necessarily required by the drone – the mission remains within the beam coverage.


49


3 Satellite data link performance evaluation

In the scope of this Exploratory Research project, it was not foreseen to set up real drone measurements over a satellite network. Instead, it was decided to proceed with software simulation to target different aspects of the link performance evaluation.

The simulations performed in the frame of the project are not meant to show that the satellite solution is either better or worse than the terrestrial solution explored in DroC2om. Indeed, the systems being so different in nature, the accent is put here on the complementarity of these systems to serve different purposes in different scenarios as illustrated in WP2 deliverables. To this aim, the simulations are performed only with a traffic profile that is closer to the “DroC2om low” than the “DroC2om high”. Indeed, the requirements for the “DroC2om high” scenario are above the capacity of the satellite system concept proposed in this study.

This chapter is divided into three sections. The first two sections focuses each on a particular aspect of the link performance: first, the network capacity (L2) is analysed, second, the communication at radio level is inspected. In both cases, the methodology, the description of the scenario and the results are given. A third section, makes a proposal on the type of data that need to be exchanged with the software environment developed in the frame of WP3 in order to evaluate the global hybrid-access performances at system-level.

3.1 Network capacity evaluation

This first scenario focuses on the capacity of the satellite network to convey message datagrams within an acceptable delay. This scenario relies on the Link Layer mechanisms defined in section 2.3.5.3 and traffic model assumptions.

3.1.1 Methodology

The performance evaluation is achieved by means of dedicated proprietary software developed by Thales Alenia Space. The simulation tool allows a certain number of tuneable parameters, in order to test different frame sizes, to set up different Classes of Service (in relation with traffic model assumptions). The number of drones is also configurable.

The simulation focus on the session nominal phase: the logon and logoff phases are ignored, as well as the echo and beam handover protocol described in section Appendix B. The main goal is to evaluate the behaviour of the network in terms of packet latency when more and more drone user terminals exchange user and control traffic with the SGW within a single spot beam.

Figure 22 gives an overview of the analysis workflow of the simulation software. The different steps for the link layer performance are:

1. the generation of user traffic and control traffic (top-left hand corner) is done at IP-level (green). Different classes of user traffic are considered and control traffic is also inserted, to be representative of the FWDD and then FWDS channels. Each traffic generator is configurable in terms of bit rates and laws of time arrival.


50


2. Depending on the type of L2 channel and the type of traffic, the link layer mechanisms are implemented to closely match the L2 definition. If needed, timeslots are padded with dummy bytes. Priority management rules apply according to configuration.

3. An average channel delay is also configurable for more realistic latency results (GEO satellite). On the drone receiver side, the synchronisation of forward and return timeline is simulated with randomly-distributed satellite-to-drone propagation time deltas.

4. When an IP packet is fully recovered at the drone receiver side, the delay to transmit this packet counted from its generation time until the recovery time is recorded.

Figure 22: Overview of the Network Capacity Simulation Tool

The tool generates IP packets for a configurable simulation duration with a 1-ms resolution. The forward and return datagram sizes are configurable.

The same type of scheme is also applicable for the return link and the simulation tool actually simulates 2-way communications, implementing the constraints on the time slot availability for the return channels as summarised in Table 3 : Link Layer Channel characteristics.

3.1.2 Scenario description

The different Classes of Service (CoS) used as basis for traffic model are described hereafter in Table 4 and Table 5. The rates shown in these tables are issued from traffic analyses as they were conducted in WP2 deliverables. They are to be considered as a close match to the DroC2om low traffic profile.


51


Class of Service

IP datagram size

(Bytes)

IP datagram Arrival Law and rate

Voice call Arrival Law and rate

Voice call Mean Holding Time

(s)

Mean bitrate

(kbps)

T1 T2 T3

C2-Manual 200 5 Hz [D] - - 8.0 X

C2-Automatic 200 1 Hz [D] - - 1.6 X X

ATC-Voice 72 8 Hz [D] [M] @0.002 Hz 20 0.2 X

ATC-Data 400-2000 0.006 Hz [M] - - ~0.0 X

Bitrate 1.6 8.0 1.8

Table 4 : Properties of the Classes of Service for the FWD link

Class of Service

IP datagram size

(Bytes)

IP datagram Arrival rate [Law]

Voice call Arrival rate [Law]

Voice call Mean Holding Time

Mean bitrate

(kbps)

T1 T2 T3

C2-Manual 300 5 Hz [D] - - 12.0 X

C2-Automatic 300 1 Hz [D] - - 2.4 X X

ATC-Voice 72 8 Hz [D] 0.03 Hz [M] 20 s 2.7 X

ATC-Data 300-1400 0.005 Hz [M] - - ~0.0 X

DAA 500 2 Hz [D] - - 8.0 X X

Bitrate 10.4 12.0 10.1

Table 5 : Properties of the Classes of Service for the RTN link

In the above tables, the Arrival Laws of IP datagrams or Voice calls are marked with [D] or [M] when the times of arrival follow Deterministic or Markov (Poisson) processes.

In this scenario, a population of logged-on drones is simulated within the same spot beam. Simultaneously flying drones communicate using the same Type of Service. As described in the rightmost columns of Table 4 and Table 5, the Type of Service is T1, T2, or T3; depending on the simulated Type of Service, one or more Classes of Service are generated for each drone, for the forward communication link and for the return communication link. The last columns of Table 4 and Table 5 inform about which Classes of Service is concerned by the Type of Service. For instance, T1 simulates forward communication including only C2-Automatic traffic and return communication including C2-Automatic traffic and Detect-And-Avoid traffic.

3.1.3 Simulation results


52


A population of 10 to 60 drones simultaneously communicating with the SGW within one spot beam was considered. All Types of Service T1, T2, and T3 were simulated. After post-processing the raw result files delivered by the network capacity tool, the following statistics have been obtained.

Average Throughputs and Delay for FWD and RTN link for all Types of Service

Figure 23 : FWD Average Throughput and Delay for T1, T2, T3

Figure 24 : RTN Average Throughput and Delay for T1, T2, T3

As it can be seen on Figure 23 and Figure 24, the throughput increases linearly with the number of users. Regarding the delay, however, due to the access mechanism in place for the transmissions originating from the drone, its increase is not linear. After a rapid increase between 10 and 20 drones, a stable value for the delay is obtained with little increase after the initial one. In all cases, the delay offered to the various users is below 450ms on the RTN link and around 500ms on the FWD link (except for Type 2 for which the amount of FWD link traffic is higher).

Impact of ATC voice/data on the FWD delay for C2-Automatic traffic (T1 vs. T3)


53


Figure 25 : FWD Delay for 95% and 99.9% of transmitted IP packets for C2-Automatic

In this scenario, the types of users where ATC data and voice relay is the only difference are compared with each other. The results depict the evolution of the one way delay for the FWD link for the C2 automatic service for respectively 95% and 99.9% of packets.

ATC voice might not be required all the time; nevertheless, C2 link shall relay ATC voice and data in case interaction with ATC is required. This variation is introduced as Type 3 that has been defined as a refinement of Type 1’s definition to which ATC services have been added.

It can be seen that the introduction of ATC relaying functions has little to no impact on the transmission of C2 automatic services data. Regarding the delay variation, even if not significant, the result has been obtained thanks to the system design approach (where priority management is built in) and it is not a general case for satellite communications systems.

Impact of ATC voice/data and DAA data on the RTN delay for C2-Automatic traffic (T1 vs. T3)

Figure 26 : RTN Delay for 95% and 99.9% of transmitted IP packets for C2-Automatic

In this scenario, the types of users where ATC data and voice relay is the only difference are compared with each other. The results depict the evolution of the one way delay for the RTN link for the C2 automatic service for respectively 95% and 99.9% of packets.

As it can be seen on Figure 26, the introduction of an ATC relaying service causes the return link delay to increase linearly with the number of users. Indeed, while the priority management can help on the forward link, the return link access is linked to the forward link through the access mechanism and thus benefits are only seen on the forward.


54


As it can been seen, the delay for transmission of C2 automatic service data packets is maintained below 470 ms both for 95% and 99.9% of the service packets.

Delay distribution (95% and 99.9%) for the C2-Manual traffic on FWD and RTN links

Figure 27 : RTN Delay for 95% and 99.9% of transmitted IP packets for C2-Manual

Regarding the C2 Manual service, this service is only active for the Type 2 users. When observing the influence of the number of users on the delay for both the forward and return links, the results are provided on Figure 27.

While the transit delay on the forward link increases linearly with the number of users, the behaviour of the system on the return link is not symmetrical. Indeed, after a drastic increase in delay between 10 and 20 users, the performance stabilizes at around 450ms for the return link delay with little variations around that value for both 95% and 99.9% of the transmitted packets for that service.

3.2 Radio communication

The second scenario focuses on the radio communication link performance along with the occurrence of a satellite beam handover. The mission scenario described below is not exactly the same as the reference scenario evaluated in the frame of WP 3. However, both are comparable in the sense that the satellite beam coverage was similar and that the idea was to illustrate and evaluate the potential impact of a satellite beam handover on the radio link.

3.2.1 Methodology

The performance simulation is achieved by means of an external licensed tool able to simulate system-level RF communications between ground facilities, satellite and aircrafts. The tool allows modelling each part of the communication chain, also permits to use generic models for transmitting antennas, usual transceiver modulation techniques. It also gives performance analyses with the possibility to track a particular link performance indicator all along the execution of the dynamic scenario. The figure below depicts the elements modelled for the scenario on the left panel, and the map rendering on the right side.


55


Figure 28: Beam handover - global 2D view

The outer red line delimits the geographical area where the geostationary satellite is in view, i.e. where is has a positive elevation seen from an observer on the Earth surface. The two smaller regions delimited by purple lines are projections of the two spot beams represented by their -3 dB contours.

Figure 29 : Global 3D view – Spot beams viewed from the satellite


56


3.2.2 Scenario description

A drone trajectory was coarsely simulated, without taking ground surface or 3D building modelling into account. The scenario covers line-of-sight propagation, and focuses on the beam selection.

Drone-trajectory

The drone is flying from Berlin, over the northern part of Germany, then over the Baltic sea to Copenhagen, then to the Danish island of Bornholm, then over the sea (supposedly for the inspection of offshore wind turbines), then to the German island of Rügen, and finally back over Berlin. Table 6 gives the locations visited by the drone. A smoothed trajectory is then computed, taking into account an average constant velocity and airplane trajectory modelling, but this has no impact on the demonstration objective of this scenario because only long-range missions are being investigated.

Table 6: Drone flight waypoints

Drone configuration

The gain of the drone satcom antenna is considered constant in all directions of arrival, and no inclination of the drone is taken into account. A gain value of 5 dBi has been used, as discussed in section 2.3.4.1. It is worst case as the antenna radiation pattern would actually be more favourable in the z-axis of each single element of the compound antenna.

Satellite configuration

The satellite platform is geostationary, and it has been set with a longitudinal coordinate close to Brussels’, at ~5° East. Table 7 summarises the satellite configuration in the simulation scenario. Figure 30 shows the beam footprints used for this particular scenario. Two beams were simulated, with the drone flying in the overlap area. The displayed contours (from red to green) stand for relative gain with respect to the maximum gain of the satellite antenna. The range of relative gains was chosen here between -3.3 dB and -2.0 dB; to cover the whole drone trajectory.


57


Figure 30: Beam handover : Regional 2D view

Parameter Value Description

Satellite orbital position

5° East A central European longitudinal coordinate was chosen

Satellite Tx antenna main lobe gain

39.5 dBi For each beam, a Gaussian model was assumed, with an efficiency of 0.55 – See appendix section A.2

Beam width 1.90 degrees

The antenna beam angle width inside which the transmitted power is at least half the maximum power

See appendix section A.2

Frequency 5.060 GHz Carrier frequency in the middle of the 5GHz AMS(R)S band.

Western Beam centre [5.621°,51.293°] The [longitude latitude] location on Earth of the western beam centre, corresponding an offset angle of 0

Eastern Beam centre [24.046°,62.759°] The [longitude latitude] location on Earth of the eastern beam centre, corresponding an offset angle of 0

Modulation Type Constant envelope

An MSK modulation scheme was used as baseline for the PHY layer definition

Table 7: Main radio satcom simulation parameters


58


Figure 31: Beam handover : local 2D view

This trajectory is supposed to entail a handover situation since the propagation losses increase when the drone is moving towards the edge of coverage of the western beam, whilst moving towards the centre of coverage of the eastern beam until the propagation conditions become better for that latter one.

3.2.3 Results

Figure 32 shows how the aerial vehicle perceives the relative satellite position during the simulation time. In the context of satellite communications, the area is relatively small, hence the satellite elevation (in red) remains almost constant as it is expected for most missions in the context of U-space. The constellation is GEO, hence the satellite-to-drone range remains over 36000 km entailing important but almost constant free-space losses. The green curve depicts the relative azimuth of the satellite versus the drone.

Elevation and Azimuth profiles need to be taken into account for the design of the airborne satcom antenna. The antenna concept discussed in section 2.3.4.1 actually tackles the problem because the design was adopted to be rather independent of the direction of arrival. Its compound gain remains over 5 dBi whilst not giving any priviledges to any particular direction. From a system point-of-view the drone antenna is omnidirectional with a guaranteed minimal gain.


59


Figure 32: Azimuth, Elevation and Range

Satellite antenna gain contribution

At each step, the relative geometrical configuration of the drone and the satellite are re-computed, and all chain elements involved in the path loss are re-evaluated.

The Effective Isotropic Radiated Power emitted by each of the satellite beams is displayed in Figure 33. During the drone flight, three phases can be identified!

Phase 1 : at the take-off at 7:12 of the flight, a slight advantage is observable for Beam 1 (blue) over Beam 2.

Phase 2: between 08:20 and 10:50 approximately, Beam 1 EIRP decreases severely whereas Beam 2 EIRP increases

Phase 3 : after 10:50, Beam 1 gets the slight advantage again.

Every time the EIRP in the ‘destination beam’ becomes greater than the EIRP in the ‘current beam’, a satellite beam handover is likely.

Actually the power transmitted in the direction of the drone is not a sufficient criterion to determine if a beam handover event is required or requested. In the current simple scenario, a MaxGain strategy was chosen as a very simple assumption, i.e. the handover occurs every time one of the available beams can improve the gain.

However, to trigger a handover situation, the System could adopt a more complex strategy. Indeed, although a handover process has been defined and can be tuned to provide seamless connectivity, resource allocation should not suffer from repetitive handovers, especially in the case where a drone flights in an overlapping area following a Brownian-like motion, depending on its mission.

Different strategies can include:

Deterministic strategy: the flight plan is known in advance and handovers can be anticipated through modelling; the beam sequence could be programmed at the satellite payload operator level, based on the data given by the drone operator or a U-space service provider.

Real-time drone location strategy based on the drone location: an extension to the deterministic strategy, except that location of the drone is sent over the C2 link itself, so that


60


the System can decide which beam provides the better connectivity. This assumes that C2 conveys airborne system information such as the computed position of the drone (GPS or other means), and can more generally perform feedback-loop algorithms to optimise the resource allocation.

Real-time link performance monitoring strategy: thanks to data filtering, the frequency of beam handover events is maintained at a lower level, accounting for possible degradation in the link performance, but on the other side, enabling a higher overall availability and simplified resource allocation. For instance, if one drone keeps requesting for handovers between the same 2 beams, it could be preferable to temporarily accept a lower link performance instead of proceed to repetitive handovers, for instance in setting up hysteresis mechanisms.

Combining several strategies should also be considered.

Figure 33: Satellite EIRP (dBW) vs. time for single beams and for multibeam with MaxGain strategy

Slant Range contribution

In all three cases of strategy, the location of the drone has not only an influence on the satellite gain antenna. The loss due to a longer range is also to be considered. Figure 34 depicts the Carrier-to-Noise -Power-Density (C/N0) received by the drone user terminal. With the measurement of this quantity, it is almost straightforward to obtain an estimation of the link performance (or link degradation) and proceed to more complex beam selection strategy. In this simple scenario, the losses accounts for propagation losses and a constant receiving antenna gain (the minimum simulated gain).

The scenario flight trajectory, from a satellite point-of-view, is concentrated is a very narrow area, hence in this case, the satellite-to-drone slant range remains almost constant. The consequence is that the profile of the received power (or carrier-to-noise-density ratio) is quite similar to the satellite EIRP profile shown in Figure 33.

56,8

57

57,2

57,4

57,6

57,8

58

58,2

58,4

6:00:00 7:12:00 8:24:00 9:36:00 10:48:00 12:00:00 13:12:00 14:24:00 15:36:00

EIR

P (

dB

W)

MaxGain

Beam 1

Beam 2


61


Figure 34: C/N0 (dBHz) vs. time for single beams and for multibeam with MaxGain strategy

Error Rate measurement

At the drone user terminal, the link performance can also be monitored in terms of Error Rates at PHY layer level (Bit Error Rate or Packet Error Rate). In the particular case of GEO satellite transmission, where it is not foreseen to transmit IP packets more than once, the Packet Error Rate is an important indicator to evaluate the link performance.

Figure 35 shows the BER profile obtained for single beams; the PER was not simulated since no particular PLframe was applied. However, a threshold has been arbitrarily set to BER=10-6

and is supposed to be an illustrative equivalent to a PER threshold of 10-3. This explains the ‘missing data’ in the beam 1 link plot : if the drone has continued using Beam1 for an extra hour, the C2 link would have been degraded until completely lost.

68,2

68,4

68,6

68,8

69

69,2

69,4

69,6

6:00:00 7:12:00 8:24:00 9:36:00 10:48:00 12:00:00 13:12:00 14:24:00 15:36:00

C/N

0 (

dB

.Hz)

MaxGain

Beam 1

Beam 2


62


Figure 35: BER profile vs. time for single beams and for multibeam with MaxGain strategy

3.3 Interface with Work Package 3

This section briefly describes the interaction between the Work Package 4 and the Work Package 3. As mentioned in Deliverable D3.2 [5], data will be exchanged between software modules under WP3 responsibility on the one hand, and under WP4 responsibility on the other hand.

Document [5] gives a detailed view on file-formatting (json), but here it is simply reminded that WP3 output data are time series, and their generation, from a satellite network point-of-view, is based on the following parameters:

The dynamic drone trajectories

the fixed Satellite sub-system parameters

o single satellite antenna location

o satellite beam properties

location of beam centres on Earth (see

beam width

The radio propagation model

o Line-of-Sight path loss described in appendix A.2

o Earth surface map (ground type : sea or land) used for Ground Reflection modelling

WP3-to-WP4 data flow

1,00E-08

1,00E-07

1,00E-06

1,00E-05

1,00E-04

1,00E-03

6:00:00 7:12:00 8:24:00 9:36:0010:48:0012:00:0013:12:0014:24:0015:36:00

Bit

Err

or

Rat

e

MaxGain

Beam 1

Beam 2


63


The software environment developed in WP3 implements all models and is able to provide a time series of the signal-to-noise ratio (Es/N0), along with drone positions and the ground type, to the Satellite Computation Module.

WP4-to-WP3 data flow

Thanks to the knowledge of fixed system, dynamic trajectories and signal-to-noise estimation, the Satellite Computation module estimates link Key Performance Indicators (Delay, Throughput, Packet Error Rate, Radio Link Failure…) and the WP3 software environment display trajectories enriched with the visualisation of the computed KPI.


64


4 Conclusion

4.1 Summary and recommendations

Deliverable D4.2 has addressed several aspects of satellite systems as a support to the drone to drone operator data link. In this document, different points of view were expressed: from top-level considerations and analysis of the UAS operational context down to details on the design of critical physical elements. This approach was driven by the will to have a general description of the System design, while putting emphasis on some non-recurrent aspects of the proposed satellite system concept.

The high-level analysis has shown the C2 centric operational view, putting emphasis on the role of the Command and Control Data link, used by the drone operator to convey miscellaneous types of traffic apart from the mission-specific communications. Indeed the C2 drone capability and hence the C2 Link System shared between the drone and the drone operator, reveals to be key for enabling other U-space services or capabilities. Therefore, it is essential to design a safe and reliable data link system.

In a first part, it was provided an overview of existing satellite systems like Iridium or Inmarsat. The main point was that those candidate systems do not entirely match the technical or regulation recommendations pointed out by the aeronautical standardisation and regulation bodies, raising the need for the development of a dedicated satcom concept.

With the objective to meet the System requirements stated in Deliverable D2.1, as well as to comply with the satellite aeronautical minimum operational performance specification, a novel satellite data link concept has been proposed; some mechanisms are derived from existing ETSI standards for the two-way communication via satellite, but physical and link layer adaptations were performed to take into account the particularities of the C2 communications to align the overall performance with the system requirements

Critical elements of the physical architecture were highlighted and solutions have been proposed, especially for the design of the drone satcom antenna and the satellite antenna, with the joint objective to be cost effective and to maintain technical gains as high as possible, while managing to accommodate the antenna solution on the airborne platform or space vehicle.

The Logical Architecture of the overall system has been described to introduce the logical elements, such as the MultiLink User Equipment and MultiLink Gateway that realise the actual integration of the satellite system with the cellular subsystem. The technical and physical implementation of the cellular-satellite integration is not addressed here and is the object of D4.3.

The C2 satellite link performance has been evaluated through the use of simulations and has shown that the System definition could endorse a population of 50 simultaneous drone communications in a single spot beam with a delay of 500ms - acceptable in many flight phases. In the specific case of the Single European Sky coverage, the baseline solution could be to use satellite multibeam antennas with 6-to-8 spot beams hosted on a geosynchronous platform for initial service. However, the system proposal was designed to adapt to other satellite spot configurations in case of a high increase of the drone population in a second step bridging the gap between U-space and the European ATM.


65


Our recommendation is to design a C2 dedicated satellite sub system that would fit into the proposal for a new concept depicted in this deliverable. This would ensure the provision of a safe and reliable data link respecting the satellite aeronautical regulations, and that subsystem could be combined with other terrestrial network accesses, either in the same frequency bands as suggested in DO-362 [12] (for certified drones transitioning to the ATM) or integrated with other technical solutions such as cellular networks as it will be described in D4.3 (for open and specific drones evolving outside of the ATM).

4.2 Addressed requirements

Deliverable D4.2 has addressed a part of the general requirements and most of the satellite-specific requirements. Table 9, Table 10, and Table 11 list the relevant requirements stated in [2] that are addressed in the context of D4.2. Other requirements are to be addressed in the upcoming work in the frame of D4.3 and other Work Packages.

Requirement

reference (SESAR 2020-763601

DROC2OM deliverable,

October 2018)

Requirement description

(SESAR 2020-763601 DROC2OM deliverable,

October 2018)

Comments in the context of Deliverable D4.2

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 system architecture foresees redundancy by design that should allow meeting the targeted availability figure.

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

The system architecture foresees redundancy by design that should allow meeting the targeted availability figure.

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

The proposed waveform allows reaching a 10-3 PER in a satellite context..

Table 8: General user performance requirements.

Requirement



October 2018)



October 2018)



66


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

The simulations performed and results reported show that the system supports U1 to U4 services including relay of ATC communications.

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

The C2 Link service is planned for use in all phases of the U-space timeline

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

All users communicate with air-ground interfaces

WP2-GENUS-FUN-009 The System may support:

- point-to-point data communications

- point-to-multipoint data communications

- broadcast data communications

Satellite communications offer a natural broadcast communication mean. On top of this, the system implements mechanisms to allow for point-to-point communications. Point-to-multipoint can be emulated through multiple point-to-point communication links.

Table 9: Generic user functional requirements.

Requirement



October 2018)



October 2018)


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

Security procedures have been provided

Table 10: Generic data link functional requirements.

Requirement


DROC2OM



October 2018)



67


deliverable, October 2018)

WP2-SATCO-FUN-001

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

The proposed system is compatible with the AMS(R)S allocation to C-Band, from 5030 to 5091 MHz

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 satellite payload is equipped with antennas and on-board RF components allowing the transmission and the reception from and to

a) the ground mission segment and,

b) the airborne platform.

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)

The GEO approach has been studied. Some system elements may be reused for other constellation types.

WP2-SATCO-FUN-004

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

The SWAN connects ground segment elements with each other in a decentralized manner. Apart from the RF link, The drone pilot reaches the drone through dedicated terrestrial networks (ATN, SWAN)

WP2-SATCO-FUN-005

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

The proposed system considers dynamic resource allocation

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

The system concept addresses handovers between beams belonging to a single-satellite constellation but the concept can be extended to multiple satellites, and multiple satellite operators.


68


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.

Priority management rules have been proposed to improve the relay of ATC communications if needed.

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

Recommendations have been proposed to ensure good performances : adequate channel coding in conjunction with constant-envelope modulation scheme have to be implemented

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

Pools of communication resources are shared on the FWD and the RTN 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

Radio resource management, frequency planning and channel allocations have been tacked. Administration functions are not directly addressed in this deliverable.

Table 11: Satcom C2 link specific requirements.


69


5 References

[1] SESAR 2020-763601 DROC2OM, “Technical Annex,” September 2017

[2] SESAR 2020-763601 DROC2OM deliverable, “D2.1 - Scenarios and requirements,” March 2018

[3] SESAR 2020-763601 DROC2OM deliverable, “D2.3 - Scenarios and requirements – Update to D2.1,” October 2018

[4] SESAR 2020-763601 DROC2OM deliverable, “D3.1 - Models for combined cellular-satellite UAS communication,” March 2018

[5] SESAR 2020-763601 DROC2OM deliverable, “D3.2 - Reference simulation scenario,” August 2018

[6] ETSI TS 102 606, “Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol”

[7] ETSI TS 103 179, “Satellite Earth Stations and Systems ; Return Link Encapsulation (RLE) protocol”

[8] ETSI EN 301 790, “Digital Video Broadcasting (DVB); Interaction channel for satellite distribution systems”

[9] Maral, G., and M. Bousquet, Satellite Communications Systems: Systems, Techniques and Technology, 2nd ed., Chichester: Wiley (1993), sec. 2.1.3; Gagliardi, Robert M., Satellite Communications, 2nd ed., New York: Van Nostrand Reinhold (1991), sec. 3.2.

[10] Gagliardi, Robert M., Satellite Communications, 2nd ed., New York: Van Nostrand Reinhold (1991), p. 104

[11] ICAO GOLD Document: Global Operational Data Link Document (GOLD), second edition – 2013

[12] RTCA-DO-362, “Command and Control (C2) Data Link Minimum Operational Performance Standards (MOPS) (Terrestrial)”, 2016

[13] 3GPP Technical Specification Group Radio Network, “TR38.811 - Enhanced Study on New radio (NR) to support non terrestrial networks (Release 15),” 2018.

[14] 3GPP, RP-1813703 “Study on solutions for NR to support non- terrestrial networks (NTN)”, 2018.

[15] 3GPP Technical Specification Group Radio Network, “TR38.821 – Solutions for New radio (NR) to support non terrestrial networks (Release 16),” 2018.


70


Appendix A Link Budget This appendix provides reference material related to the radio connectivity scheme propose in section 2.3.5.1. It is also a support to the understanding of the radio communication scenario detailed in section 3.1.2 and offers a summarised view of the some aspects of the results presented in section3.2.3.

This section proposes an approach to the path loss modelling for the satcom radio communications.

As depicted in Figure 9, Figure 10 and Figure 11, the radio bearers are physical channels supporting the Layer-2 communications between the drone satcom transceiver and the Satellite Gateway, through the satellite payload. However, this deliverable only considers the (most critical) part of the communication between the satellite payload and the drone transceiver.

The following paragraph presents the link budget model retained in the frame of the project, especially for the software simulation environment developed in Work Package 3.

A.1 Terminology All physical elements or quantities relating the satellite (payload) will be subscripted with SAT.

All physical elements or quantities relating the drone (user terminal) will be subscripted with DUT.

All physical elements or quantities relating the satellite-to-drone link will be subscripted with FWD.

All physical elements or quantities relating the drone-to-satellite link will be subscripted with RTN.

Table 12 gives the constant quantities involved in the link budget model. The Boltzmann’s constant is given here with its dB-scale value since it will not be used in linear equations in the next sections.

In Table 13 are given the system-level physical quantities that were used in the modelling and the link budget analysis. The values are to be representative of an achievable satellite radio subsystem and are considered fixed in the analysis.

Finally, in Table 14 are summarised the variable quantities. Those are the results of the relative situation in which the drone and the satellite communicate, but also depend on the drone position. The model depicted in this appendix only accounts for the coarse path loss and does not consider other losses due to the type of drone, the relative speed of the drone with respect to the satellite (Doppler effect), nor the multipath propagation issues. These contributions are to be addressed in Work Package 3.

Constant name Unit Description Value

c m/s Speed of light in vacuum 299792458

RE m Earth radius 6378137

kB dBW/K-Hz Boltzmann’s constant -228.6

Table 12: List of constants for the link budget model


71


Quantity Unit Description Fixed Value

EIRPSAT,MAX dBW Maximum Equivalent Isotropic Radiated Power for the satellite

55.0

EIRPDUT,MAX dBW Maximum Equivalent Isotropic Radiated Power for the drone user terminal

20.0

(G/T)SAT dB.K-1 Figure of Merit for satellite antenna 3.0

(G/T)DUT dB.K-1 Figure of Merit for drone antenna -19.0

λSAT rad Latitude of the satellite 0.0

φSAT rad Longitude of the satellite 5.0

HSAT m Altitude of the geostationary satellite above sub-satellite point

35786000

fFWD Hz Satellite-to-drone forward link carrier frequency

5.060 GHz

fRTN Hz Drone-to-satellite return link carrier frequency

5.060 GHz

RsFWD Hz Forward link symbol rate

RsRTN Hz Return link symbol rate

Table 13 : List of fixed satellite subsystem parameters

Quantity Unit Description

λDUT rad Latitude of the drone

ΦDUT rad Longitude of the drone

hDUT m Altitude of the drone over virtual Earth with a radius of RE

R m Satellite-to-drone slant range

LFS dB Free-space losses

LA dB Atmospheric losses (LG for gaseous attenuation, LR for rain attenuation)

L dB Total propagation losses

E rad Satellite elevation


72


C/N0 dBHz Carrier-to-Noise-Density Ratio

Es/N0 dB Symbol-Energy-to-Noise-Density Ratio. SNR

Table 14 : Link budget model variable computed quantities

A.2 Computation model The following computation model for path loss proposes a simplified approach for interaction with the work done in Work Package 3. However, simulations performed in the frame of the radio communication scenario in section 3.1.2 use a similar but not perfectly aligned parameterisation.

The carrier power C can be expressed thanks to the energy-per-symbol ES and the symbol rate RS.

linear

scale

𝐶 = 𝐸𝑆 × 𝑅𝑆

Dividing the equation by the noise power spectral density: 𝐶

𝑁0=

𝐸𝑆

𝑁0× 𝑅𝑆

10log10 (𝐶

𝑁0) = 10log10 (

𝐸𝑆𝑁0) + 10log10(𝑅𝑆)

For more convenience, the dB-scale is employed. The ‘dB’ subscript means that a quantity X is used in its dB-form, i.e. equivalent to 10log10(𝑋).

dB

scale (𝐸𝑆

𝑁0)𝑑𝐵

= (𝐶

𝑁0)𝑑𝐵− 10log10(𝑅𝑠)

The Carrier-to-Noise-Density ratio can be expressed using the transmitted power, the path loss, the receiver’s figure of merit and the Boltzmann’s constant as:

dB

scale (𝐶

𝑁0)𝑑𝐵

= 𝐸𝐼𝑅𝑃 − 𝐿 + (𝐺

𝑇)𝑑𝐵− 𝑘𝐵

The above expression is applicable for the forward or return link.

The EIRP, (G/T) and RS are considered as system fixed parameters, for the satellite and for the drone.

In our model, total losses (LFWD or LRTN) only account for free-space losses and atmospheric losses: additional losses due to as mispointing or depolarisation are not modelled here and taken into account in the system margin, so is the rain attenuation (not preponderant in C-band).


73


FWD

dB (𝐸𝑆

𝑁0)𝐷𝑈𝑇

= 𝐸𝐼𝑅𝑃𝑆𝐴𝑇 − 𝐿𝐹𝑊𝐷 + (𝐺

𝑇)𝑑𝐵𝐷𝑈𝑇

− 𝑘𝐵 − 10log10(𝑅𝑆𝐹𝑊𝐷)

RTN

dB (𝐸𝑆

𝑁0)𝑆𝐴𝑇

= 𝐸𝐼𝑅𝑃𝐷𝑈𝑇 − 𝐿𝑅𝑇𝑁 + (𝐺

𝑇)𝑑𝐵𝑆𝐴𝑇

− 𝑘𝐵 − 10log10(𝑅𝑆𝑅𝑇𝑁)

The following equation gives the expression of the Line-of-Sight path loss. Hereafter, the frequency f should be replaced with the allocated radio bearer frequency for either the forward channel frequency (fFWD)or the return channel frequency (fRTN), attributed by the SGW, as explained in section 2.3.5. For the sake of simplicity in the context of this appendix, the carrier frequency is set to 5060 MHz for both links.

dB

𝐿 = 𝐿𝐹𝑆 + 𝐿𝐴

𝐿𝐹𝑆 = 20log10 (4𝜋𝑅𝑓

𝑐)

𝐿𝐴 = 𝐿𝐺+𝐿𝑅

In our proposal of simplified model for C-Band, the atmospheric loss LA is almost negligible – especially compared to frequencies over 10 GHz – and is composed of

5. LG = 0.3 for any drone position/satellite elevation

6. LR = (3.6/π) λDUT - 0.3, for drone latitudes between 20° and 65°, (λDUT in radians)

dB 𝐿 = 20log10 (4𝜋𝑅𝑓

𝑐) +

3.6

𝜋 λDUT

Computation of satellite-to-drone distance

The distance R between the satellite and the drone is obtained by using the ECEF coordinates.

Spherical coordinates are given with respect to a WGS84 ellipsoid, hence. The following formulae are used for spherical to ECEF coordinate system conversion, where 𝜆 stands for the latitude, 𝜆 represents the longitude, and 𝐻 is the height above the WGS84 ellipsoid.

𝑅𝐸 = 6378137


74


𝑒𝑐𝑐2 = 0.00669437999014

{

𝑥𝐸𝐶𝐸𝐹 = 𝑅𝐸

cos𝜙

√1 + (1 − 𝑒𝑐𝑐2) tan2 𝜆+ 𝐻 cos𝜙 cos 𝜆

𝑦𝐸𝐶𝐸𝐹 = 𝑅𝐸 sin𝜙

√1 + (1 − 𝑒𝑐𝑐2) tan2 𝜆+ 𝐻 sin𝜙 cos 𝜆

𝑧𝐸𝐶𝐸𝐹 = 𝑅𝐸 (1 − 𝑒𝑐𝑐2)

sin 𝜆

√1 − 𝑒𝑐𝑐2 sin2 𝜆+ 𝐻 sin 𝜆

The slant range R between the SATellite and the Drone User Terminal is expressed as:

𝑅 = √(𝑥𝑆𝐴𝑇 − 𝑥𝐷𝑈𝑇)2 + (𝑦𝑆𝐴𝑇 − 𝑦𝐷𝑈𝑇)

2 + (𝑧𝑆𝐴𝑇 − 𝑧𝐷𝑈𝑇)2

Computation of EIRPSAT

EIRPSAT represents the power that the satellite transmits in direction of the drone is modelled as a function of the offset angle and depends on the maximum satellite EIRP. As shown in Figure 36, a satellite beam can be defined by:

the position of the satellite antenna - origin of the beam

the position of the beam centre on Earth, and

the beam width, expressed in radians. The beam width is expressed as twice the angle 𝜃3𝑑𝐵 which corresponds to the offset angle (with respect to the boresight), where half the power is transmitted, due to the transmit satellite antenna radiation pattern.

Figure 36 : Defining elements of a satellite beam

Assuming a Gaussian antenna model for the radiation pattern, the satellite EIRP can be expressed as a function of the offset angle 𝜃.


75


dB

scale 𝐸𝐼𝑅𝑃𝑆𝐴𝑇(𝜃) = 𝐸𝐼𝑅𝑃𝑆𝐴𝑇,𝑀𝐴𝑋 − 3 (

𝜃

𝜃3𝑑𝐵)2

In Figure 37, the satellite EIRP is represented by the blue line; the red portion corresponds to the EIRP values for a range of offset angles ⌊−𝜃3𝑑𝐵, +𝜃3𝑑𝐵⌋ inside the beam width (green segment). Although it does not perfectly match real antenna patterns, this power profile gives rather good approximation of the resulting power radiated by a satellite dish antenna for small offset angles, until approximately -10 dB relative to the maximum gain.

Figure 37 : EIRPSAT profile vs. offset angle

Computation of the offset angle 𝜃 for a given drone position

The offset angle 𝜃 = (𝑆𝐵⃗⃗⃗⃗ ⃗, 𝑆𝐷⃗⃗⃗⃗ ⃗) is used in the scalar product 𝑆𝐵⃗⃗⃗⃗ ⃗. 𝑆𝐷⃗⃗⃗⃗ ⃗, where S stands for the satellite

position, (B) for the beam centre position, and (D) for the drone user terminal position, as depicted in Figure 36.

𝑆𝐵⃗⃗⃗⃗ ⃗. 𝑆𝐷⃗⃗⃗⃗ ⃗ = ‖𝑆𝐵‖ ‖𝑆𝐷‖ cos(𝑆𝐵⃗⃗⃗⃗ ⃗, 𝑆𝐷⃗⃗⃗⃗ ⃗)

‖𝑆𝐵‖ is the satellite-to-beam-centre distance and can be considered as a fixed value in the geostationary case; ‖𝑆𝐷‖ = 𝑅, so the offset angle 𝜃 is obtained using the inverse cosine function

𝜃 = cos−1 (𝑆𝐵⃗⃗⃗⃗ ⃗. 𝑆𝐷⃗⃗⃗⃗ ⃗

‖𝑆𝐵‖ 𝑅)

Computing the scalar product in the numerator is straightforward using the spherical-to-Cartesian conversion.


76


A.3 Numerical example

A geostationary satellite is located at (λSAT, φSAT, hSAT) = (0°N, 5°E, 35786km).

The beam centre is located at (λB, φB, hB) = (63°N, 24°E, 0m)

A drone flies at (55°N, 14°E, 100m).

The respective ECEF coordinates are :

{

𝑥𝑆 ≅ 42003689.7𝑦𝑆 ≅ 3674846.7

𝑧𝑆 ≅ 0.0 {

𝑥𝐵 ≅ 2652332.1𝑦𝐵 ≅ 1180894.3𝑧𝐵 ≅ 5659978.1

{

𝑥𝐷 ≅ 3557735.7𝑦𝐷 ≅ 887043.1𝑧𝐷 ≅ 5201465.4

The satellite-to-drone distance is :

𝑅 = √(𝑥𝑆 − 𝑥𝐷)2 + (𝑦𝑆 − 𝑦𝐷)

2 + (𝑧𝑆 − 𝑧𝐷)2 ≅ 38896252.7

The free-space losses are:

𝐿𝐹𝑆 = 20log10 (4𝜋𝑅𝑓

𝑐) = 198.33 dB and 𝐿𝐴 = 1.1 dB, then

𝐿 = 199.43 dB

𝜃 = cos−1 (𝑆𝐵⃗⃗⃗⃗ ⃗. 𝑆𝐷⃗⃗⃗⃗ ⃗

𝑅 ‖𝑆𝐵‖ ) ≅ 0.83272

In our case, a value of 𝜃3𝑑𝐵 ≅ 1.9072° was considered, so the satellite EIRP in direction of the drone is:

𝐸𝐼𝑅𝑃𝑆𝐴𝑇(𝜃) = 𝐸𝐼𝑅𝑃𝑆𝐴𝑇,𝑀𝐴𝑋 − 3(𝜃

𝜃3𝑑𝐵)2

𝐸𝐼𝑅𝑃𝑆𝐴𝑇(𝜃) = 55 − 3(0.83272

1.9072)2≅ 54.43 dBW


77


Appendix B Drone Session Control As shown in Figure 14, the C2 Link System provides the initiation, the maintenance and the release of a drone session. In the end-to-end communication chain, a drone session is only considered between a SGW and the drone satcom transceiver (Figure 9).

The SGW permanently and repetitively broadcasts System Information (SI) on a FWDS channel (over one shared carrier, 1 carrier per beam). This SI must allow any drone to initiate a logon procedure or a beam handover. The minimal information would be: the System identifier, and descriptors of the serving beam and adjacent beams.

Beam descriptor

The descriptor for any beam (adjacent or serving) contains the beam identifier and the spot map. Additionally, the descriptor for the serving beam also contains the beam carrier frequency dedicated to logon using the RTNS channel.

Figure 38: Serving and adjacent spot beams

The spot map contains information about the coverage area for all the considered spot beams of the satellite region. For each spot beam, the map is made of a list of geographical points on the earth surface. The nominal coverage area is delimited by great-circles arcs joining two consecutive points.

B.1 Session initiation The drone intending to initiate a session with the System shall first tune on the permanent FWD link devoted carrier, depending on its position and hence the beam.


78


Figure 39 : Logon protocol

Once the drone satcom transceiver has recovered the System Information tables and has performed time frame synchronisation, it is capable to use the RTNS devoted carrier to transmit a logon request. The logon request essentially contains the drone identifier. The logon process is depicted in Figure 39

The Satellite Gateway repetitively broadcasts its identifier and a set of beam descriptors on FWDS channels. The drone starts listening to the broadcast System Information, selects the beam and sends a logon request on the RTNS channel, containing its identifier.

The Satellite Gateway performs the admission control of the drone based. It consists in a set of various checks, related to authentication but also to administrative procedures, certification…

The Satellite Gateway then acknowledges the logon request over the FWDS channel, informing the drone that the admission control has been successful, or rejects the request in case the admission control failed. In case of success, the SGW also sends the description of the frequency to the drone for the RTND channel in the logon acknowledgment.

The drone itself then acknowledges back the SGW acknowledgement over the RTND channel (TS1 to TS4) so that the SGW is ensured that a proper communication has been established using the RTND channel.

The SGW notifies the logon to the other ground-based components of the SRS; the drone is now reachable using an IP address as depicted in Figure 9. The SGW starts allocating resources to the drone and updates the TSTP that is broadcasted on the FWDS channel to all drones in the concerned beam. The SGW is ready for forwarding user traffic towards the pilot centre.


79


The drone listens to the TSTP table and receives/transmits data over the FWDD/RTND channels.

The logon procedure, in its nominal course, takes about 1 second to complete.

B.2 Session maintenance If a logged drone remains inactive, i.e. it does not send data on its RTND channel for a while (using predetermined duration of a few seconds), the Satellite Gateway initiates an Echo protocol. An Echo protocol consists in sending an Echo Request protocol element to the drone, awaiting an Echo Reply from the drone as a response. In case of no Echo Reply is answered (after several retries), the Satellite Gateway assumes the session is over and releases all related resources

Figure 40 : Echo protocol

B.3 Beam Handover The beam handover keeps alive the session between the drone and the SGW when a drone leaves the serving beam and enters an adjacent beams as the UA is leaving the serving beam to an adjacent beam (Figure 38). The handover process breaks into three phases : HO detection, HO decision, HO execution.

Several types of flight paths can occur; particular attention must be paid to drone flying in areas where beams overlap. The beam selection could be parameterized at a high system level, or it could be performed by the drone or the SGW.

The system features seamless handovers to keep alive the user data service during a gradual migration to the destination beam without losing user data. This seamless handover procedure does not add any delay to the user transmissions during its execution.


80


B.4 Handover detection The drone satcom transceiver has the capability to evaluate the quality of reception of the FWD link. Moreover if the drone is equipped with an on-board GNSS receiver, the AFRMS can also provide the drone position and velocity, and thus the drone could infer the need to perform a handover request, using beam descriptors regularly sent by the SGW in the FWDS channel (System Information).

In this situation, the drone sends a Handover Request on its RTND channel to the Satellite Gateway. The handover request indicates a variable-size list of possible destination spots. During this phase, the drone and the Satellite Gateway keep exchanging user data over the FWDD and the RTND channels as usual.

Handover decision

The SGW receives the Handover Request over the RTND channel, containing the candidate destination spots.

If No destination spot is given, the decision is taken by the SGW

The drone may asks for one particular destination spot; the SGW has no choice to take

The drone proposes several destinations spots, and the SGW selects one of them

The beam selection strategy is left system-customizable in this deliverable, but in all cases, the SGW responds with a Handover Acknowledgement on the RTND channel, indicating the selected destination spot and the settings of the future RTND channel, even if the drone had already selected an only candidate spot. During this phase, the drone and the Satellite Gateway keep exchanging user data over the FWDD and the RTND channels as usual.

Handover execution

This phase extends from the moment the handover request has been acknowledged until the SGW and the drone FWDD and RTND channels have switched from the old serving beam to a new serving beam. This phase splits into two steps :

• Return handover : the drone starts using a new RTND channel on the new serving beam

• Forward handover : the SGW switches the FWDD channel to the new serving beam

The handover procedure, in its nominal course, takes up to 2 seconds to be performed. Nevertheless, the seamless nature of this procedure does not impact the delay of transmissions either on the forward or return link.

Return handover

After sending its Handover Acknowledgement, the SGW starts listening to the new RTND channel frequency and keeps listening on the old one. Upon reception of the SGW Handover Acknowledgement, the drone transmits a Handover Acknowledgement over the new RTND channel frequency but stills received data on the initial FWDD channel. The change will only occur at the start of the next multiframe.


81


Figure 41 : Beam Handover protocol

Forward handover

After the SGW receives the Handover Acknowledgement from the drone, it sends a Handover Command protocol element over the initial FWDD channel. For a seamless handover, the SGW shall allocate resource and send user data to the drone in the cycle right after the Handover Command cycle, although the protocol allows to wait for more cycles – in that latter case, user data would be buffered and delayed

After the on-going multiframe, the drone switches to the new FWD carrier and listens to FWDS channel, where the SGW transmits the updated TSTP table.

The drone acknowledges the Handover Command; on reception of this protocol element, the SGW stops listening to the initial RTND channel.


82


B.5 Session release The session release is effective once the drone has logged off the System. The logoff process can be initiated by either the drone or the SGW. After logoff is complete, no user traffic is conveyed between the pilot centre and the drone.

o Initiated by the drone: a Logoff Request is sent over the RTND channel to the SGW. Upon reception of this request, the SGW releases all contexts related to the session, de-allocates resources and stops forwarding traffic to the pilot through the SWAN

o Initiated by the SGW : a Logoff Request is sent over the FWDD channel to the drone, which responds with a Logoff Acknowledgement. The SGW waits for this acknowledgement and releases all contexts related to the session, de-allocates resources and stops forwarding traffic to the pilot through the SWAN.

Figure 42 : Logoff protocol –initiated by the drone or by the SGW

B.6 Summary of Protocol elements The following tables summarises all the protocol elements used to describe the session management in the above sections.

Protocol element Protocol Channel Description

System Information System Info FWDS Provided for initiating a logon

TSTP (Time Slot Time Plan)

Data FWDS Timeslot Allocation in the current multiframe concerning all logged-on drones

Logon Request Logon RTNS Session Initiation Request

Logon ACK Logon FWDS Session Initiation controlled and admitted by the SGW

Logon ACK Logon RTND Confirmation by the drone that it is ready for transmitting/receiving data

Echo Request Maintenance FWDD Request by the SGW that drone is alive


83


Echo Reply Maintenance RTND Confirmation by the drone that it is alive

HO Request Handover RTND Request by the drone to perform a beam handover

HO ACK Handover FWDD Confirmation by SGW that it is ready to receive data on current and future serving beams

HO ACK Handover RTND Confirmation by the drone that the Return handover has completed : transmission on the new RTND is OK.

HO CMD Handover FWDD Handover command sent by SGW to ask the drone to listen to new serving beam

HO CMD ACK Handover RTND Confirmation of achieved beam handover sent by the drone

Logoff Request Logoff FWDD Request by the SGW that the drone logs off

Logoff Request Logoff RTND Request by the drone to log off

Logoff ACK Logoff RTND Confirmation by the drone that it has logged off

Table 15 : Summary of drone session protocol elements


84


Documents

SESAR 2020 - 763601 - D4.2 Satellite system concepts ... · D4.2 Satellite system concepts solutions for high reliability UAS data links DeliverableID D4.2 ProjectAcronym DroC2om