DroC2om - 763601 - D4.3 Integrated cellular-satellite ... · Figure 2 : Detailed hybrid cellular-satellite access components of the DroC2om System Concept highlighting the scope of

DroC2om - 763601 - D4.3 Integrated cellular-satellite inter-system design solutions for high reliability UAS data links

DeliverableID [D4.3]

ProjectAcronym DroC2om

Grant: 763601 Call: H2020-SESAR-2016-1

Topic: RPAS-05 DataLink

Consortium coordinator: AAU

Edition date: [30 May 2019]

Edition: [01.00]

Template Edition: 02.00.00

EXPLORATORY RESEARCH

EDITION [01.00]

2

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

2

Authoring & Approval

Authors of the document

Name/Beneficiary Position/Title Date

István Z. Kovács/ NBL WP4 lead 30/05/2019

Jeroen Wigard/ NBL Project TM 30/05/2019

Nicolas Van Wambeke/ Thales WP2 lead 30/05/2019

Matthieu Clergeaud / Thales Contributor 30/05/2019

Troels B. Sørensen/ AAU Project Coordinator 30/05/2019

Reviewers internal to the project


István Z. Kovács/ NBL WP4 lead 30/05/2019

Benjamin Hiller/ atesio Contributor 30/05/2019

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


Nicolas Van Wambeke TAS 30/05/2019

Troels B. Sørensen AAU 30/05/2019

Jeroen Wigard NBL 30/05/2019

Andreas Eisenblätter atesio GmbH 30/05/2019

Rejected By - Representatives of beneficiaries involved in the project


DROC2OM - 763601 - D4.3 INTEGRATED CELLULAR-SATELLITE INTER-SYSTEM DESIGN SOLUTIONS FOR HIGH RELIABILITY UAS DATA LINKS


3

Document History

Edition Date Status Author Justification

00.10 06/11/2018 DRAFT István Z. K. Early ToC

00.20 23/11/2018 DRAFT István Z. K. Adjusted ToC/Proposal for responsibilities

00.30 23/11/2018 DRAFT Matthieu Clergeaud Proposals on ToC

00.40 01/05/2019 DRAFT Matthieu Clergeaud Nicolas Van Wambeke

Updated concepts and results

00.50 09/05/2019 DRAFT István Z. K. Updated background and BF and 3GPP architectures

00.55 13/05/2019 DRAFT Troels B. Sørensen István Z. K.

Updated Section 2.4 and Section 3.2.

00.60 15/05/2019 DRAFT All contributors (WP4)

Adjustments to main Section in the F2F meeting

0.70 21/05/2019 DRAFT Matthieu Clergeaud Updated Section 1

0.75 22/05/2019 DRAFT Troels B. Sørensen Updated Section 2.4

0.8 23/05/2019 DRAFT István Z. K. Clean-ups

00.90 23/05/2019 DRAFT Matthieu Clergeaud Version for internal review

01.00 30/05/2019 FINAL Matthieu Clergeaud Final version submitted to EC

Dissemination level: Public

Copyright Statement:

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

EDITION [01.00]

4


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 programme 1.

Abstract

This Deliverable concludes the activities by the DroC2om project in the frame of Work Package 4, the main objective of which was to propose a concept for an integrated cellular-satellite system architecture for the provision of drone C2 data links.

Previous WP4 Deliverables D4.1 and D4.2 have provided methodologies and results for the link performance assessments respectively for each of the cellular-only or satellite-only networks. On top of these single-network sub-architectures, this deliverable proposes an overlay architecture that could take the benefits from both underlying radio access links specificities to improve the reliability , the availability or even the capacity of the overall system using hybrid network techniques.

After a short section introducing the contextual definitions and the interactions with other DroC2om activities, this deliverable provides an extensive list of the state-of-the-art network techniques or technologies in relation to the combination or the integration of multiple links – at the network level of the communication protocol stack. A coarse evaluation of the principles of those techniques is proposed, where two particular methods, LISP and MobileIP, are emphasized for the DroC2om concept proposal, as they allowing network address mobility or multi-homing for the airborne terminals with minimal impact on subnetwork architectures.

A functional analysis of the multilink subsystem is then provided, taking into account that it would mostly reside in the multilink gateway – i.e. at the network side – to limit the processing on the airborne multilink adaptor. The chapter also proposes a methodology for the link selection, based on KPIs measured at the different levels of the communication protocol stack.

The DroC2om approach for hybrid access is then evaluated against the LISP and Mobile IP technologies and results are provided with the help of generic testbed setups.

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

The final chapter gives our conclusions on the possibility to use such multi-homing technologies for the provision of safe and reliable C2 links in the frame of the improvement of U-space communication infrastructure, but it also provide recommendations in accordance with the assumptions these techniques take regarding the airborne equipment, or the adaptations needed on the network side. This chapter also summarises the requirements – as listed in D2.1/D2.3 that WP4 and more specifically D4.3 address, and finally opens the discussion on possible further enhancements or what sort of live experiments could be conducted to assess the overall system performances.

EDITION [01.00]

6


6

Table of Contents

1 Introduction ............................................................................................................... 9

2 Integrated cellular-satellite C2 Link alternatives ....................................................... 17

3 DroC2om hybrid access Approach Concept Definition ............................................... 37

4 Evaluation of the DroC2om Hybrid Access Approach ................................................. 48

5 Conclusions and recommendations ........................................................................... 55

6 References ............................................................................................................... 67



7

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

Table 2: Terminology and definitions .................................................................................................... 16

Table 3 Proposal for the Multilink database ......................................................................................... 45

Table 4 General user performance requirements. ................................................................................ 58

Table 5 Generic user functional requirements...................................................................................... 59

Table 6 Generic data link functional requirements. .............................................................................. 60

Table 7 Terrestrial C2 link specific requirements (see Deliverable D4.1 [1]). ....................................... 61

Table 8 Satellite C2 link specific requirements (see Deliverable D4.2 [2]). ........................................... 62

Table 9 Requirements on integration of C2 services ............................................................................ 63

Table 10 Requirements on integration of C2 data links ........................................................................ 65

Table 11 Requirements to support Multiple Operator. ........................................................................ 65

List of Figures Figure 1 : Study Logic with focus on D4.3 ............................................................................................... 9

Figure 2 : Detailed hybrid cellular-satellite access components of the DroC2om System Concept highlighting the scope of D4.3 ............................................................................................................... 10

Figure 3 Logical architecture for cellular-satellite hybrid access with L3 overlay tunnelling for the C2 link. ........................................................................................................................................................ 19

Figure 4 Logical architecture for cellular-satellite hybrid access with L3 network-based tunnelling for the C2 link. ............................................................................................................................................. 20

Figure 5 Logical architecture for cellular-satellite hybrid access with L4 multipath network for the C2 link. ........................................................................................................................................................ 21

Figure 6 Logical architecture for cellular-satellite hybrid access with 5G NR – Satellite system interworking for the C2 link. ................................................................................................................. 23

Figure 7 Logical architecture for (one possible) 5G NR based hybrid access with TN – NTN (terrestrial-satellite) C2 link. .................................................................................................................................... 24

Figure 8 LISP network architecture ....................................................................................................... 26

Figure 9 LISP Map-Request .................................................................................................................... 27

Figure 10 LISP Map-Registration ........................................................................................................... 27

Figure 11 LISP encapsulation header .................................................................................................... 28

EDITION [01.00]

8


8

Figure 12 AERO architecture ................................................................................................................. 29

Figure 13 Prefix Delegation Process ...................................................................................................... 30

Figure 14 MIPv6 Binding Update .......................................................................................................... 31

Figure 15 MIPv6 Tunnelling ................................................................................................................... 32

Figure 16 Hybrid access mechanism in a layered (user-plane) protocol stack ..................................... 35

Figure 17 Functional Analysis System Technique for the multilink ....................................................... 38

Figure 18 OOR Architecture .................................................................................................................. 39

Figure 19 LISP redundant link ................................................................................................................ 40

Figure 20 Hash Table used to store each received packet .................................................................... 41

Figure 21 Duplicates Handler Modification ........................................................................................... 42

Figure 22 Euclidian distance method to estimate the final link quality indicator ................................ 45

Figure 23 Diagram of actions for the link selection mechanism ........................................................... 47

Figure 24 MIPv6 testbed ....................................................................................................................... 48

½Figure 25 LISP testbed ........................................................................................................................ 49

Figure 26 MIPv6 TCP bandwidth variations results ............................................................................... 51

Figure 27 MIPv6 UDP bandwidth variations results .............................................................................. 51

Figure 28 LISP TCP bandwidth variations results .................................................................................. 52

Figure 29 LISP UDP bandwidth variations results ................................................................................. 52

Figure 30 Hard Handover LISP UDP bandwidth variations results ........................................................ 53

Figure 31 Hard Handover LISP TCP bandwidth variations results ......................................................... 53



9

1 Introduction

1.1 Purpose and Scope

This deliverable provides an assessment of various hybrid access mechanisms to combine multiple data links for the bidirectional communications between a drone and its operator. The work relies on the analysis performed in Deliverables D4.1 [1] and D4.2 [2], and it should be regarded as the complement of the results provided in the frame Deliverable D3.3 [3], as depicted in the Study Logic presented in Figure 1.

Figure 1 : Study Logic with focus on D4.3

On the first hand, Deliverable D4.1 [1] has provided an analysis for the use of a 3GPP LTE cellular network as a support to the UAS C2 Link communications. The radio access mechanisms and the radio mobility mechanisms have been described, the impact on the network performance has been evaluated, while proposing small network adaptations to support UAS missions in VLL (very low level) in high-loaded terrestrial network scenarios.

On the other hand, Deliverable D4.2 [2] has provided an overview of existing satellite systems, pointing out the need for the development of a novel satellite data link concept to meet the system requirements for performance and regulatory reasons; the document has thus focused on the full top-down concept description, from the top operational view, down to some proposals on the physical implementation, also providing analyses of radio access network mechanisms.

THIS DOCUMENT

EDITION [01.00]

10


10

The analyses conducted in the frame of WP3 are fundamental as they straightforwardly and visually demonstrate the need for cellular-satellite hybrid radio access links to safely accomplish a UAS mission in a given scenario, particularly pointing out that different types of radio access would be necessary to meet the safety, availability and reliability requirements. As complement to the results provided in Deliverable D3.3 [3], the Deliverable D4.3 focuses on several existing network hybrid mechanisms able to combine cellular and satellite links. Moreover, we provide a methodology and evaluation results of a multi-homing algorithm for the integration of multiple links for safe and reliable UAS data link provisioning.

Figure 2 : Detailed hybrid cellular-satellite access components of the DroC2om System Concept highlighting the scope of D4.3

From a System Architecture point-of-view, the scope of this document is highlighted by the green boxes in Figure 2. The evaluated hybrid access mechanisms are at the heart of the main logical functions of the Hybrid Data Link User Equipment (HDLUE) and Hybrid Data Link Gateway (HDLGW) components described hereinafter.



11

1.2 Document overview

This document is structured as follows:

In Chapter 1, 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.

Chapter 2 presents the state-of-the-art hybrid or multilink network mechanisms: the Broadband Forum (BBF) concepts, the Terrestrial Networks approach, and several proposals made by the aeronautical community. The chapter closes with discussion on the motivation for the adopted DroC2om approach.

Chapter 3 defines the concept for the hybrid access mechanism proposed by the DroC2om project team and how it articulates with the work done in WP3.

Chapter 4 focuses on the evaluation of two particular multilink access solutions adapted for the cellular-satellite hybrid operation: MIPv6 and LISP.

The last chapter gives conclusions on the potential advantages and shortcomings of the proposed DroC2om hybrid access concept and gives a general review on the Requirements covered by the WP4 Deliverables.

1.3 Technical contributions

The work documented in this Deliverable D4.3 has contributed to the following technical DroC2om areas:

o Review of SoA Hybrid access mechanisms, taking into account different domain approaches; adaptation to the DroC2om concept for an hybrid access solution for C2 Link provisioning – Section 2 and Section 3

o Methodology and evaluation results of a multi-homing algorithm for the integration of multiple radio access links for safe and reliable UAS data link provisioning – Section 4

o Recommendations of the DroC2om project for implementing a hybrid access solution for C2 Link provisioning – Section 5

o Outline of potential future work topics and areas related to C2 Link provisioning for UAS in U-Space – Section 5

EDITION [01.00]

12


12

1.4 Glossary

Abbreviation Explanation

3G 3GPP UMTS 3rd generation cellular systems

3GPP 3rd Generation Partnership Project (cellular systems)

4G 3GPP UMTS-LTE (E-UTRAN) 4th generation cellular systems (aka LTE)

5G 3GPP 5th generation cellular systems

5GC 3GPP 5G Core Network

5G NR 3GPP 5th generation New Radio cellular systems

AERO Asymmetric Extended Route Optimization

AF Application Function (5G)

AFRMS Airborne Flight and Radio Management System

AGDL Air Ground Data Link

AMF Access and Mobility Management Function (5G)

ANS Air Navigation Services

AP Access Point

AS Access Stratum (communication protocol)

ATM Air Traffic Management (manned and unmanned)

ATS Air Traffic Services

AUSF Authentication Server Function (5G)

AV Aerial Vehicle(3GPP) or Drone (SJU)

BBF Broadband Forum

BF Broadband Forum

BVLOS Beyond Visual Line-Of-Sight

C2 (C&C) Command and Control

CN Core Network (3GPP)

CM Connection Management

EASA European Aviation Safety Agency

D&A (DAA) Detect and Avoid

DL Downlink radio communication, Forward link (FWD): Network/Satellite -to- UA

DN Data Network e.g. operator services, Internet access or 3rd party services

DTM Drone Traffic Management

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

GBR Guaranteed Bit Rate

gNB 5G Node B



13

gNodeB (gNB) Next generation NodeB (5G)

gNB-CU gNB Central Unit

gNB-DU gNB Distributed Unit

GRE Generic Routing 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) C2 Link Gateway. Alternative term for Multi-Link Gateway (MLGW)

HDLUE Hybrid (multilink) C2 Link User Equipment. Alternative term for Multi-Link Adaptor (MLA)

HO Radio hand-over (serving cell change)

IETF Internet Engineering Task Force

HCPE Hybrid-access Consumer Premises Equipment

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 Locator Identity Separation Protocol.

A Multi-Homing and Mobility Solutions for ATN using IPv6

LOS Radio Line-Of-Sight

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

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

MAC Medium Access Control layer (communication protocol)

MLA MultiLink Adaptor

MLGW MultiLink Gateway

MME Mobility Management Entity (4G)

MPTCP Multipath TCP

NAS Non-access Stratum (communication protocol)

N3IWF Non-3GPP InterWorking Function (5G)

EDITION [01.00]

14


14

NEF Network Exposure Function (5G)

NG Next Generation (5G)

NLOS Radio Non-Line-Of-Sight

NRF NF Repository Function (5G)

NSSF Network Slice Selection Function (5G)

OWD One-way delay

PCF Policy Control Function (5G)

PDCP Packet Data Convergence Protocol (communication protocol, 3GPP)

P-GW Packet Data Network Gateway (4G)

PHY Physical layer (communication protocol)

PiC Pilot in Command

QCI QoS Class Identifier

QoS Quality of Service

Qout (DL) Serving Signal Quality Outage

QUIC Quick UPD Internet Connections

RAN Radio Access Network

RLC Radio Link Control layer (communication protocol)

RLF Radio Link Failure

RMa Rural Macro (3GPP scenario)

RTT Round Trip Time

RPAS Remotely Piloted Aircraft System: Equivalent to UAS

RRC Radio Resource Control layer (communication protocol)

RRM Radio Resource Management

SAT Satellite System/Network

S(at)GW Satellite Gateway

SATPL Satellite Transparent payload (supported by Platform)

SEPP Security Edge Protection Proxy (5G)

SDAP Service Data Adaptation Protocol (5G)

SESAR JU Single European Sky Air traffic management Research Joint Undertaking

SFRMS Satellite Flight and Radio Management System

S-GW Serving Gateway (4G)

SoA State-Of-the-Art (literature, solution, concept)

SMF Session Management Function (5G)

TCP Transmission Control Protocol

TR Technical Report



15

UA Unmanned Aerial/Aircraft

UAS Unmanned Aerial/Aircraft System, including UAV, ground control, and communication link

UDM Unified Data Management (5G)

UDP User Datagram Protocol

UDR Unified Data Repository (5G)

UDSF Unstructured Data Storage Function (5G)

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

UL Uplink radio communication, Reverse link: UA -to- Network/Satellite

UMa Urban Macro (3GPP scenario)

UPF User Plane Function (5G)

U-Space See Table 2

VLOS Visual Line-Of-Sight

VLL Very Low Level

VPN Virtual Private Network

Table 1: Abbreviations

Term Explanation

C2, C2 Link, UAS C2 Link

“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 aerial/airborne platform for the purpose of performing the mission.

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

The term payload can be used in reference to a Satellite Payload (i.e. the equipment on board a satellite that is used for the satellite to perform its mission,

EDITION [01.00]

16


16

e.g. a transparent signal repeater in a telecommunication satellite or an optical equipment in an earth observation satellite).

The term payload can designate the data encapsulated in a packet in the frame of network protocols.

Radio adaptation Adaptation and configuration mechanisms on the PHYsical layer and Medium Access Control layer

Radio capacity The transmission (DL and UL) radio resources available in the radio system.

Radio link The DL or UL radio transmission link

Radio mobility UE changing the serving radio cell (base station, eNB, satellite) due to physical movement, radio channel changes, or explicit commands from the serving cell.

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



17

2 Integrated cellular-satellite C2 Link alternatives

In this section we provide brief descriptions of the available state-of-the art (SoA) technical solutions which have potential and/ or are related to the hybrid access solutions targeted in DroC2om. Details are provided in addition to the Deliverables D4.1 and D4.2 on the mechanisms selected to be used in the hybrid access DroC2om concept.

The technologies described hereafter target either the management of multiple available links and/or paths between a source and a destination in a network environment or the management of the change in available link (or links) over time for a set of mobile users. None of these technologies directly fit the purpose of the DroC2om concept where traffic must be, on a case by case basis, sent over one or several of the links with the available links selection and availability being masked to the end users. Nevertheless, the presentation of these technologies is key to the DroC2om concept as they are used as a basis for the definition of the approach and the implementation of the C2 Link service in U-Space.

Section 2.1 discusses the approaches promoted by the broadband forum. Indeed, the forum provides approaches for hybrid access to combine 3GPP mobile and fixed broadband. A broader view specifically targeting integration with Satellite systems, from a 3GPP point of view is provided in section 2.2 while approaches and technologies considered by the aeronautical community for the management of multiple data links between the ground and the aircrafts are described in section 2.3.

2.1 Broadband Forum approaches to hybrid access

Mobile broadband hybrid access

The Broadband Forum (BBF) has specified a hybrid access network architecture, primarily used for combined 3GPP mobile and fixed broadband access [4].

The definition of the hybrid access is that of a communication system composed of several (radio and/or wired) access systems which enable coordinated and simultaneous use of the access technologies involved. At a network abstraction layer, typically the Internet Protocol (IP) layer, it appears as a single connection, thus implementing a coordinated and simultaneous use of the two or more access technologies. Logically, it is implemented by a hybrid access protocol mechanism in the terminal and a similar mechanism associated with a hybrid access gateway in the access network (see Section 2.4). The mechanisms classify (for QoS enforcement) and distribute the traffic that passes in both uplink and downlink directions2. Physically, at the terminal side, the mechanism is implemented in the drone for the DroC2om case, whereas at the network side, there are different

2 It is possible to have a hybrid access mechanism on the terminal side only, however in this case, it is not possible to directly control the downlink traffic; this option is not considered.

EDITION [01.00]

18


18

possible implementations, i.e. as part of one or the other sub-networks or completely outside of the sub-networks. Usually, all traffic between the terminal and the network will pass the hybrid access mechanism, but it is possible that certain parts, e.g. control plane traffic, will bypass and only pass one of the sub-networks. By means of the hybrid access gateway, distribution of packets or flows, between the different sub-networks, can be done independently for the two directions.

The hybrid access mechanism is typically implemented at TCP/IP layer. The use of tunnels is one way to do this, using native transport layer protocols for embedding IP traffic. Tunnelling protocols are typically used to operate another protocol transparently across a network that does not natively support it. With TCP/IP as the underlying network protocol, the unsupported protocol is carried in the TCP/IP packets over the network. Tunnelling encapsulates payload/packets from a layer equal to or lower than that the one being used to carry the payload, as compared to the usual encapsulation from top to bottom in the layered protocol stack: For example, TCP/IP packets, over TCP/IP, destined for ports that are otherwise blocked by routers in the underlying network, or to cope with different IP address domains (cf. GRE tunnelling protocol use). For all the BF approaches for hybrid access, both flow- and packet-based distribution of traffic over the underlying access networks can take place.

There are three main transport models for hybrid access as defined by BF [4] [1]. Using the terminology from reference [4] they rely on different capabilities for the hybrid-access consumer premises equipment (HCPE), the hybrid-access gateway (HAG), and the functionality required in the radio access networks infrastructure. In DroC2om, the corresponding terms for these entities are Hybrid (multilink) DataLink User Equipment (HDLUE) and Hybrid (multilink) DataLink Gateway (HDLGW) [2]. In the context of the two radio access technologies used in DroC2om, the Hybrid Access refers to the aggregation of radio network connectivity over the cellular and satellite radio networks, between a terminal equipment (on-board the drone) and a gateway network entity with access to both communication networks.

We summarize below the three main hybrid access transport models as specified in [4], with explanations on how these would be applicable in the DroC2om context for the C2 link, when a hybrid access over cellular and satellite radio networks is used. For simplicity, we only show and discuss the C2 link aspects related to the hybrid access, and do not address here the other external communication interface needed for the C2 link system operation [2]. The security aspects of the various models are not addressed either. We believe the industry standards applicable for the cellular and satellite radio access networks are sufficiently well established and can provide the desired level of security, authentication and privacy.

Layer 3 Overlay Tunnelling

“The connectivity between the HCPE [HDLUE in Droc2om] and the HAG [HDLGW in Droc2om] is established using tunnels on top of the access infrastructure. The tunnels are established between the HCPE and the HAG over each of the access paths. The HCPE is responsible for managing the tunnel (both establishment and tear down) as well as upstream forwarding decisions. The HAG is responsible for downstream forwarding decisions. The implementation itself is access network agnostic, therefore no changes to either the fixed broadband or the 3GPP access networks are necessary”. [4]

Figure 3 shows the logical architecture for cellular-satellite hybrid access with L3 overlay tunnelling for the C2 link. Given the access network agnostic approach of the overlay tunnelling approach,



19

conversely there is no possibility for the access networks (satellite or cellular) to dynamically optimise the transport of data over the respective networks.

Besides the establishment and teardown of tunnels (SAT tunnel and CEL tunnel), the hybrid access mechanisms implemented in HDLGW and HDLUE must detect the availability of and make decisions in the use of the respective access paths (C2 traffic distribution), including how to deal with different latencies on the two access paths. In a flow-based implementation, the latency is only a concern in decision making. Note that separate IP addresses (IP SAT and IP CEL) are needed for the different tunnels through the two access networks.

For C2, this architecture option has as direct consequence the unavailability of any quality of service control mechanisms for the C2 link in either of the radio access networks, as these are ‘un-aware’ of the type of data packets they are transporting. This further means that the C2 link communication service provider, via the control of the HDLGW and HDLUE, is fully in control (and responsible) for ensuring the target C2 link reliability KPI while the radio access service providers are only responsible for providing the availability and coverage KPIs.

Figure 3 Logical architecture for cellular-satellite hybrid access with L3 overlay tunnelling for the C2 link.

Layer 3 Network-based Tunnelling

“The connectivity between the HCPE [HDLUE in Droc2om] and the HAG [HDLGW in Droc2om] is realized by making use of the native technologies in both the fixed broadband (e.g. IPoE/PPPoE) and 3GPP access networks, from HCPE to BNG and from HCPE to eNodeB respectively. On setup, the network establishes the tunnels to the HAG on behalf of the subscriber’s HCPE and stitches traffic from the access sessions to those tunnels, in order to reach the HAG. Each Hybrid Access path is the end-to-end path resulting from stitching the access session in the respective access network with the corresponding tunnel from the access network to the HAG”. [4]

Figure 4 shows the logical architecture for cellular-satellite hybrid access with layer 3 network-based tunnelling for the C2 link. In this approach, the data are exposed to the different access networks and they can dynamically optimise the transport according to the type of traffic, but otherwise this hybrid access mechanism requires the same functionalities as in the case of L3 overlay tunnelling. Compared to the overlay tunnelling, less IP addresses are consumed as both the links can use the same IP address.

For C2, this architecture option means that quality of service control mechanisms for the C2 link can be used in both radio access networks. Thus, the C2 link communication service provider, in addition to the control via the HDLGW and HDLUE, can establish service level agreements with the two radio

EDITION [01.00]

20


20

access service providers to ensure the target C2 link reliability KPI, while the radio access service providers are also responsible for providing the availability and coverage KPIs.

Figure 4 Logical architecture for cellular-satellite hybrid access with L3 network-based tunnelling for the C2 link.

Layer 4 Multipath (Multi Path TCP)

“The connectivity between the HCPE [HDLUE in Droc2om] and the HAG [HDLGW in Droc2om] is established using a Layer 4 multipath transport service enabling IP flows to use multiple paths in the Hybrid Access path group simultaneously. As an example, a L4 multipath implementation using MPTCP sets up multiple TCP sub-flows over the different access networks and utilizes real time HCPE to HAG flow control. The HCPE and HAG are responsible for managing the MPTCP paths, including establishment and tear down”. [4]

Figure 5 shows the logical architecture for cellular-satellite hybrid access with layer 4 multipath network for the C2 link. Multi-path TCP [5] [6] provides an application level connectivity option using multiple TCP flows transmitted over different paths and/or access networks, thus improving the overall reliability and latency of the data connection. In this case, the hybrid access mechanism is implemented at the transport layer. Most of the hybrid access functionality in relation to link availability and decisions is covered by MPTCP.

For C2, this architecture option means that quality of service control mechanisms for the C2 link can be used in both radio access networks. Thus, the C2 link communication service provider, in addition to the control via the HDLGW and HDLUE (and the MPTCP policies), can establish service level agreements with the two radio access service providers to ensure the target C2 link reliability KPI, while the radio access service providers are also responsible for providing the availability and coverage KPIs.



21

Figure 5 Logical architecture for cellular-satellite hybrid access with L4 multipath network for the C2 link.

EDITION [01.00]

22


22

2.2 Terrestrial Systems Architecture approaches to hybrid access

For the integration of the cellular access with satellite access, there are three main options to consider from 3GPP access point of view:

1. Hybrid access integration with satellite access

2. Interworking with satellite access as non-3GPP access

3. 5G New Radio based satellite access

Hybrid access integration with satellite access

This solution was introduced in Deliverable D2.2 [7] Section 3 as the preferred DroC2om architecture solution and is described in more details later in this document, Section 3. The flow of the C2 service data packets is managed by the Hybrid (Multilink) Datalink Gateway and the Hybrid (Multilink) Datalink User Equipment entities. The network management functions within the two access networks (cellular and satellite) cannot control the hybrid C2 service quality. This solution is similar to the Layer 3 Overlay Tunnelling (see Figure 3) hybrid access network architecture as specified in the Broadband Forum [4].

The main advantage of this solution is the relatively low complexity integration at application level between satellite and (4G or 5G) terrestrial networks.

Interworking with satellite access as non-3GPP access

The 5G New Radio (NR) core network supports the connectivity of the user equipment via non-3GPP access networks, e.g. WLAN access. To realize the hybrid cellular-satellite access for the C2 service, the 5G Core Network (5GC) needs to be interfaced with the satellite access network, ideally re-using one of the interworking options already defined in 3GPP for interworking with non-3GPP access [2] [8] [9]. In Figure 6 we show the logical architecture for the 5G NR – satellite system interworking solution for the C2 link. The key element in this solution is the Interworking Function (Non-3GPP Interworking Function in 3GPP, N3IWF), which provides 3GPP interfaces between the satellite access and the 5G core network elements as follows:

o Between the Drone UE and N3IWF for establishing secure tunnel(s) between the Drone UE and N3IWF so that control-plane and user-plane exchanges between the UE and the 5G Core Network is transferred securely over satellite access.

o Between the Drone UE and the satellite access. This depends on the satellite access technology and is outside the scope of 3GPP.

o Between the satellite access and the N3IWF. Additional support functions are required in the 5GC network, e.g. to enforce the link service levels specific for C2, handle C2 specific traffic steering and policy rules, and to interact with the 3GPP core network for C2 related services in general. The main advantage of this solution is the tighter integration at radio access level between satellite and (4G or 5G) terrestrial networks.



23

Figure 6 Logical architecture for cellular-satellite hybrid access with 5G NR – Satellite system interworking for the C2 link.

5G New Radio based satellite access (non-terrestrial networks)

Under the framework of 5G NR specifications, 3GPP has initiated in 2017 a first study item on “Study on NR 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” [10].

The 5G NR Non-Terrestrial Networks (NTN) will enable the provision of radio connectivity services also to Aerial Vehicles. A common, standardized radio network architecture and radio interface with the 5G terrestrial cellular networks (TN) will allow an optimized integration of the hybrid/multilink terrestrial and satellite access solution for UAVs. In this solution the satellite network is fully integrated with terrestrial cellular networks(s) and the hybrid C2 service can be provisioned in both non-roaming (same operator) and roaming (different operators) scenarios.

Figure 7 shows one possible logical architecture for the cellular-satellite hybrid access for the C2 link when a 5G NR dual TN – NTN network deployment is assumed. The main advantage of this solution is the tight integration at radio access and protocol level between satellite and 5G NR terrestrial networks. Thus, the cellular (terrestrial and satellite) radio access service provider can fully optimize the reliability, availability and coverage KPIs for the C2 link.

This deployment architecture further allows the use of any of the hybrid-access solutions as described in Section 2.1. Nevertheless, the HDLUE and HDLGW functionalities can be significantly better integrated with the radio access networks. Figure 7 shows only one possible solution for the HDLGW. Another option could be, for example, to have the HDLGW owned (and provided as service) by the 5G NR radio access service provider. Ultimately, the tight integration of the TN and NTN means that the C2 link communication service provider has improved control over the C2 link system operation and does not need to have mechanisms for enforcing the actual radio access link selection.

EDITION [01.00]

24


24

Figure 7 Logical architecture for (one possible) 5G NR based hybrid access with TN – NTN (terrestrial-satellite) C2 link.



25

2.3 Aeronautical Community Approaches to Hybrid Access (Multilink)

The aeronautical community has been working on the management of multiple links in the frame of the SESAR (LISP, Mobile IPv6, NEMO) and NextGEN (AERO) projects. Indeed, as aircrafts are mobile by nature, the data links that are available change over the course of their movement in the airspace. Furthermore, more than one link can be available at a given time. The efficient use of these data links is performed under the umbrella of the concept called the Multlink. This section describes the standard internet technologies for management of mobility and multiple links that have been considered by the SESAR and NetGEN projects for the implementation of the Multilink concept that could serve as a basis for the implementation of the DroC2om C2 Link Service in U-Space as further detailed in section 3.

Locator Identity Separation Protocol (LISP)

LISP [11] “is a routing architecture that creates a new paradigm by splitting the device identity and its location into two different numbering spaces. This capability brings renewed scale and flexibility to the network in a single protocol, enabling the areas of mobility, scalability and security”.

“LISP has the capability to provide a transparent multi-homing solution for the end systems which allows load sharing between the different radio technologies dependent on the available QoS. It also solves the network mobility problem of the aircraft network and together with GETVPN it provides a maintainable security solution”.

LISP stands for Locator Identity Separation Protocol. This protocol replaces the IP addresses by two addresses :

Routing Locator (RLOC) : they are assigned to network attachment points and are used for routing and forwarding of packets through the network

Endpoint Identifier (EID) : they are assigned independently from the network topology

LISP defines a Network Manager Node which maps the RLOCs with the EIDs. RLOCs and EIDs are similar to IP addresses but they are not used the same.

The Locator/Identifier Separation protocol has been designed to answer to the scalability issue in addition to the mobility. Nowadays, the IP addresses have two purposes : localization and identification. Localization because the IP address prefix gives information about our location and identification because an IP address targets a unique terminal. But the biggest issue concerns the routing. As the number of terminals are constantly increasing, more and more routes have to be handled by the routers. But the actual routing has its limitation, the routing scalability is very worrying mainly because of the growth of BGP tables. That is why the locator/identifier separation has been proposed.

Therefore, LISP proposes a solution to this problem by separating the locator and the identifier. The idea is to modify the network organization, it is split in two parts : the RLOC (Routing Locators) and the EID (Endpoint Identifier). These elements replace the IP addresses within the LISP network. The RLOCs are assigned to attachment points of the network. The RLOC space is the network between the EIDs. The EIDs can be seen as end networks along the RLOC space. Thus, by mapping the EIDs with the RLOCs any LISP router can find the right RLOC for the EID it wants to communicate with. The

EDITION [01.00]

26


26

LISP capable routers encapsulate and de-capsulate the IP traffic to send it across the RLOC space. Thus, the LISP mechanism is transparent for the terminals within the EIDs.

Figure 8 LISP network architecture

Here are some definitions concerning the elements that constitute the LISP network :

xTR : the xTR can be an ITR (Ingress Tunnel Router) or an ETR (Egress Tunnel Router) which means that this router accepts IP packets going to or coming from a LISP site. It is its responsibility to encapsulate and de-capsulate the IP traffic. The xTR also has a mapping cache which is local and dynamic, where EID/RLOC mapping are stored for a specific time.

Mapping System : It is a LISP server located within the RLOC space, reachable by every xTR. It is composed of a Map Resolver and a Mapping Server. Whenever an EID has to communicate with another one, the source xTR sends a request to the mapping system to retrieve the current destination RLOC. For instance, with respect to the Figure 8, the mapping system would contain the following mapping table :

o EID 1 RLOC xTR1 o EID 2 RLOC xTR2 o EID 2 RLOC xTR3 o EID 3 RLOC xTR4

The LISP entities exchange specific LISP control messages. There are three types of these messages, all of them are sent over UDP on port 4342 :

LISP Map-Register : It is sent by the xTR in order to inform the Mapping System that it has a RLOC interface up. It specifies which EID it can access to. This message is acknowledged with a Map-Notify sent by the Mapping System. If others RLOCs can be used to reach the same EID, it will also be notified in the Map-Registration.

LISP Map-Notify : It is sent by the Mapping System in order to acknowledge a Map-Registration.

LISP Map-Request : it is sent by an ITR when it requires a RLOC destination for a specific EID or if it needs to update its mapping cache.



27

Figure 9 LISP Map-Request

Figure 10 LISP Map-Registration

Figure 10 illustrates the Map-Registration process while Figure 9 describes the Map-Request’s one. [12] As soon as the mapping system receives a Map-Register from an ETR, it stores the information in the mapping table and sends a Map-Notify to inform the corresponding ETR that its registration has been taken into account. For the Map-Request, a triangular communication is triggered. If an ITR needs a mapping for a specific EID it sends a Map-Request to the mapping system. The latter also sends a Map-Request to the corresponding ETR which responds with a Map-Reply to the initial ITR. After the reception of this message, the ITR fills the mapping cache with the new mapping. This one will last for a certain time defined by the TTL (Time To Live). Thus, if the ETR wants to send another message toward the same EID, it will not have to repeat the Map-Request process as long as the mapping is still in cache.

The LISP protocol supports multi-homing which consists in being connected to several operators simultaneously. It also has a prioritization functionality. Actually, a priority and a weight are associated to every RLOC interface. If several interfaces are associated to the same EID, the protocol will route the packets toward the interface with the best priority (the lower number). The weight is used when two or more interfaces have the same priority. In this case, the weight indicates how to

EDITION [01.00]

28


28

balance the traffic between the interfaces. Thus, it is possible to perform flow balancing with the LISP protocol.

In order to send a message from one EID to another, the LISP protocol has to encapsulate the initial IP packet several times. This encapsulation is depicted in the following figure (Figure 11).

Figure 11 LISP encapsulation header

There are two headers, firstly the inner header which corresponds to the initial IP packet header sent by a terminal in the source EID. The source and destination addresses are the addresses of the respective EID’s terminals. And secondly the outer header which corresponds to the IP packet that encapsulate the initial packet over the RLOC space. The source and destination addresses are the RLOC addresses. Moreover, between these two headers there is the LISP header which is sent over UDP. UDP is sufficient because the tunnelling ensure the quality of service usually offered by TCP.

SESAR has even defined a better version of LISP which is the Ground Based LISP. This version is better than the previous one because all the routing processing is done on the ground. Thus we save the resources on board the aircraft. In this case, the drone assumes that the on ground router to which it is connected is capable of reaching any node in the ground network. Moreover this method minimizes the overhead traffic on the Air-to-Ground data links.

The LISP protocol is also independent from any delays or from the differences of the different types of access networks.

Asymmetric Extended Route Optimization (AERO)

AERO [13] “supports mobility by modelling the enterprise network as a virtual link through a process known as encapsulation. AERO is based on a Non-Broadcast, Multiple Access (NBMA) tunnel virtual link model, where all nodes appear as neighbours the same as if they were attached to the same physical link”.

The AERO “system tracks mobile devices through control message signalling and an efficient routing system. Dynamic link selection, mobility management, quality of service (QoS) signalling and



29

route optimization are naturally supported through dynamic neighbour cache updates, while prefix delegation (PD) is supported by the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”.

The AERO (Asymmetric Extended Route Optimization) is a mobility protocol which performs IP tunnelling over virtual links. This protocol can either tunnel over IPv4 or IPv6. Like the previous protocols, here is some definition of the different AERO entities :

AERO link : it is a non-broadcast, multiple access tunnel virtual link on which all the connected nodes have an IPv6 or IPv4 address. The nodes are single-hop neighbors with each other.

AERO Server : it is an AERO node which provides forwarding and DHCPv6 services to the AERO clients. It assigns an IPv6 link-local unicast address to each AERO interface of the connected nodes.

AERO Client : it is an AERO node which sends DHCPv6 request to the AERO server in order to receive an IP Prefix Delegation. Then it can assign an AERO address to one of its interfaces so that it can support DHCPv6 and IPv6 Neighbor Discovery services.

AERO Relay : it is an AERO node which is configured to relay packets between the AERO link and the native Internet.

AERO address : it is an IPv6 link-local address within which the address of the network behind the AERO client. For instance, in Figure 12, fe80::2001:db8:0:1 is an AERO address.

Figure 12 AERO architecture

EDITION [01.00]

30


30

Figure 13 Prefix Delegation Process

Figure 12 presents a simple AERO use case. All the AERO client are not necessarily aware of the presence of the other AERO clients. However all of them have a default route which points to the AERO server. For instance, in this case, the AERO client 1 wants to communicate with the correspondent node. Client 1 has no routes linked to this node so it sends its packets to the server. As the server knows that the next hop for reaching the correspondent node is the AERO client 3, it forwards the packet to it and sends a redirect message to client 1 to inform it that the correspondent node is in fact reachable via an AERO client in the same virtual link. Therefore, client 1 can add a new route : CN Client 3. This process is similar to route optimization.

Moreover, the prefixes of the AERO addresses are dynamically assigned. The prefixes delegations are handled by the DHCPv6 server. As presented in the Figure 13, before being able to send the first packet, the clients go through the process of prefix delegation by requesting an address to the DHCPv6. Then it has to send a router solicitation in order to find the server associated to the AERO link.

This dynamic discovery of neighbors is similar in its objectives and provided functions to the concept of an Enterprise Service Bus (ESB) which is a computing technology used to enable the communication between applications which have not been made to work together.



31

Mobile IPv6

Mobile IPv6 is a standard proposed by IETF. It has brought the capability to roam to nodes in IPv6 networks. The main advantage of this protocol is that mobile nodes keep the same IPv6 address at any time even if they change their entry to the network while roaming. In order to better understand the MIPv6 operating, it is necessary to define the specific terms of this protocol :

Home Link : it is the Home Network of the Mobile Node (MN), his Home Address has the same prefix as the Home Link’s address.

Foreign Link : it is a network which is not part of the Home Link.

Home Agent (HA): it is a router on the Home Link which keeps a mapping of the mobile nodes that are away from the Home Link and their current address.

Home Address : it is the permanent address of the mobile node. It is always reachable with this address.

Care-Of-Address (CoA): when a mobile node moves away from the home network, a Care-Of-address is assigned to it. This specifies the current position of the mobile node. This address is also the end point of the tunnel built between the mobile node and its home agent. The association of a Home Address with a Care-Of-Address is called binding.

Correspondent Node (CN) : it is a IPv6 node which communicates with the mobile node anywhere in the network.

The mobile node has to perform neighbor discovery and auto-configuration address to support the mobility. All the Home Agents and the Foreign Agents are broadcasting their presence with router advertisements. Thus, when a mobile node moves away from the Home Link it has to find a Foreign Agent Care-Of-Address.

Figure 14 MIPv6 Binding Update

EDITION [01.00]

32


32

Figure 15 MIPv6 Tunnelling

The above Figure 14describes the Binding Update (BU) mechanism. It is performed by the mobile node in order to notify to other nodes that a new Care-Of-Address has been assigned to his interface. In the binding update message, the mobile node has the choice to set or not the Acknowledgement bit to request a Binding Acknowledgement from the notified node.

Then, the above Figure 14 and Figure 15 describe the communication process between a mobile node and a correspondent node. Two different communication modes are possible. The first one is the bidirectional tunnelling. The packets coming from the correspondent node are routed toward the home agent which tunnels them to the mobile node (at t0 and t1 on Figure 14). The packets follow the same path from the mobile node to the correspondent node. The home agent is able to capture the packets addressed to the mobile node with the proxy Neighbor Discovery. So in this case, all the traffic is going through the home agent. However, another communication mode makes it possible to avoid permanent triangular communication. This is possible when using the route optimization mode. This is the case when the correspondent node sends packets directly to the mobile node using the MN’s care-of-address. But this implies that it knows it. Therefore, in route optimization mode, the mobile node registers his current binding to the correspondent node so that the binding will be stored in his binding cache.

Network Mobility & Extensions – NEMO

The NEMO protocol is an extension of the Mobile IPv6 (MIPv6) protocol just as Proxy MIPv6 or Fast Handover MIPv6. It allows an entire Mobile Network to keep a connection with the correspondent



33

node on the ground while moving. The main difference with MIPv6 is that the session continuity is applied to an entire network and not to a single mobile node. Thus, considering that a plane contains many terminals such as sensors, computers, it constitutes an entire network. If we use MIPv6 protocol for handling the mobility, each embedded terminal would have to send a Binding Update to the Home Agent. This would be very ineffective and would congest the mobile router. The NEMO protocol overcomes this issue by considering that the entire network is one mobile node. The mobile router is then responsible for routing the input packet toward the right terminal. The NEMO protocol works transparently for the nodes in the mobile network.

It is also important to say that all the extensions are backward compatible with MIPv6 and particularly the necessary elements of the NEMO architecture. On one hand, a mobile network can only have access to the ground network via specific router, the Mobile Routers. Generally, the Mobile Router is placed at the entry of the mobile network and has one or more interfaces with the ground network.

On the other hand, the main element of all MIPv6 protocols is the Home Agent. It is a router on the ground which separates the Home Network with the rest of the network. The role of the Home Agent is to tunnel datagrams to the mobile nodes while they are away from the home network.

RINA

RINA is the recently proposed Recursive InterNetwork Architecture [14]. It uses the concept of Distributed Inter-process communication Facility (DIF) to divide communication processes into manageable scopes across network subsystems, which results in a reduced routing table size per DIF. RINA routes hop-by-hop based on the destination’s no de address, not its interface. A teach hop, the next-hop node address is mapped to the (currently operational) interface to that next-hop node. This late binding of a node’s address to its interface (path) allows RINA to effectively deal with interface changes due to multi-homing or mobility . The cost of such late binding is relatively small since its scope is local to the routing “hop” that traverses the underlying DIF. By recursion on the DIF structure to make the DIF scopes small enough, the cost of such late bindings (location up dates) can be made arbitrarily small.

2.4 Discussion on the approaches and motivation for the DroC2om concept

The previous section has outlined a number of State of the Art (SoA) architectures and/or approaches to management of multiple links available between network nodes, possibly varying over time which are the building blocks to the definition of the DroC2om hybrid access mechanism. Concerning architecture approaches, 3GPP (LTE) specifications already accommodate non-3GPP access which can form the basis for including satellite based access in the DroC2om hybrid access design. The outlined interworking provides the necessary network elements for setting up the communication pipes over the terrestrial and satellite networks, respectively, as well as a (logical) network element where the hybrid mechanisms can reside, i.e. the User Plane Function in Section 2.2. On a longer term, in the frame of 5G, support for non-terrestrial networks is under study that

EDITION [01.00]

34


34

will allow for full integration of satellite access, providing optimised radio access in the hybrid access mechanism.

The hybrid cellular-satellite DataLink solution targeted in DroC2om has to re-use as much as possible from the SoA solutions and architectures. This is needed in order to be able to integrate the DroC2om solution into existing access networks (terrestrial 3GPP and satellite), without requiring excessive changes or upgrades. Along the same principle, the solution takes the assumption that the traffic handled by the hybrid access mechanism is conveyed by IP packets [2], thereby relying on a standardised interface for packet traffic. A number of approaches were outlined for how to handle the distribution of IP traffic over the access networks, based on the concept of tunnelling. Tunnelling is a concept already well proven in the context of combing mobile and fixed broadband access, and with the option to support both flow and packet based distribution of the traffic. Compared to Multipath TCP, tunnelling rely on standardised protocol mechanisms, and is therefore an already deployable solution.

Providing hybrid access for drones raises issues in concern of mobility handling and scalability, i.e. the ability to accommodate a large number of moving objects. The LISP and AERO protocols applies the tunnelling concept to handle these challenges – LISP by splitting the device identity and its location, and AERO by establishing virtual links. Some details of how this works were given in the previous sections. Besides tackling the mobility and scalability issues, these protocols also support efficient load sharing, dynamic link selection and QoS management, which are required for the hybrid access mechanism. Mobile IPv6, and its NEMO extension, is another alternative solution, addressing some of the same challenges with tunnelling.

All in all, there are a number of already existing SoA solutions on which to base the DroC2om hybrid access mechanism without requiring excessive changes and upgrades. It is not a goal in DroC2om to specify the exact solution, however, Section 4 will evaluate some key performance metrics of selected protocols to give overall recommendations for more detailed future evaluations.

A logical component structure for the HDLUE and HDLGW was outlined in deliverable D4.2 [2], Section 2.4, illustrating how these elements link to subsystems from a high level perspective. Complimentary to the logical structure, Figure 16 illustrates how the hybrid access mechanism interacts and interfaces in a layered view of the protocol stack, given the assumption in D4.2 that the applicative traffic is conveyed and handled by the hybrid access mechanism in the HDLUE, respectively HDLGW, at IP packet level. This can apply to both Figure 3 and Figure 4 in Section 2.1, and in this sense is similar, however, focusses on the protocol view and some further details of the IP interface. It serves to illustrate how the previously introduced concepts and protocols can be seen as part of, or supplementary to, the DroC2om hybrid access mechanism. LISP, as one eminent and SoA solution for handling the scalability and mobility challenges, simplifies the IP packet handling (e.g. setting up and maintaining dynamic IP connections to a large number of moving objects). LISP inherently uses the tunnelling concept introduced earlier. The communication transceivers processing the cellular and the satellite data are assumed to be separate, each of them hosting a domain-specific radio, handling the framing, formatting, modulation and demodulation of binary data into/from two kinds of wireless signals.



35

The hybrid access mechanism collects the IP packets from the subsystem transceivers to perform the appropriate processing for downlink (forward link for satellite) and uplink (return link for satellite) packet processing; for downlink, the transceivers process the signals through their respective protocol stack, going up from physical, through data link layer and finally network layer to deliver IP packets to the hybrid access mechanism at network/transport layer. Similarly, for uplink, the hybrid access mechanism distributes IP packets from the application layer to the respective network layers for transmission over the different wireless interfaces. Besides providing the interface to the HDLGW and HDLUE, the subsystem network layer may contain specific processing functions to optimise IP packet transport over the respective wireless networks, e.g. the packet data convergence layer typically used in the 3GPP terrestrial communication systems for processing user plane data.

Figure 16 Hybrid access mechanism in a layered (user-plane) protocol stack

The hybrid access mechanism in the HDLGW and HDLUE takes the application layer IP packets and distributes these, e.g. by duplication, to the IP interfaces of the underlying subnetworks, applying the necessary control mechanisms to manage the flow of packets over the combined access networks. The distribution can be based on QoS classification and/or by performance metrics provided from the respective subnetworks over appropriate control plane connections (dashed lines in Figure 16).

hybrid access mechanism

SAT

LISP(UDP) (UDP)

traffic distribution and handling

networking

datalink

physical

application

CEL

networking

datalink

physical

EDITION [01.00]

36


36

Although the overall protocol structure applies to both HDLGW and HDLUE, the control plane interfaces may be different. The HDLUE resides physically on the drone platform together with transceivers for the cellular and the satellite links, and therefore may have access to cross-layer information related to packet loss rate and delay. For the HDLGW, the hybrid access mechanism can be located in a number of places, with (physical) access core networks between the HDLGW and the subsystems, and therefore with no direct access to the transceivers. In this case, layer 3 (network) control interfaces may be accessible by the gateway (e.g. QoS estimation in terrestrial networks), or the hybrid access mechanism itself can probe the link quality of the subsystems at regular intervals. Depending on the hybrid access decisions, packets are then tunnelled over native transport layer interfaces (UDP) as part of the LISP routing protocol. Although shown in the protocol stack at transport layer level, the hybrid access mechanism is a hybrid layer 3 (network) and transport layer (layer 4) protocol mechanism.

The specific functions of the hybrid access mechanism in Figure 16 entail the following tasks:

Setup, maintenance and termination of hybrid access paths (e.g. system capacity monitoring as discussed in [2])

Access path performance monitoring (latency, congestion, packet loss rate) for dynamic link selection

Traffic classification and distribution on access paths (path selection, packet duplication)

IP packet handling (identification and removal of duplicates)

The DroC2om list of requirements in D2.3 [15] sets the overall frame for WP4 design work. The solutions and overall design guidelines presented here, supports directly or indirectly many of the requirements, e.g. as a fundamental enabler in meeting the availability requirements and the generic C2 link requirements (see Section 5.3).



37

3 DroC2om hybrid access Approach Concept Definition

The hybrid cellular-satellite C2 Link solution targeted in DroC2om has to re-use as much as possible from the SoA solutions and architectures. To this extent, this section proposes a definition of the concept based on the elements presented above taking as a base the aeronautical approaches based on LISP and extending it to fit the objectives and functionalities to be provided by the DroC2om concept.

3.1 Selected Approach Description

3.1.1 Hybrid link management model

In this part, the process of design is going to be presented through several diagrams which give an overview of the functions and the processes that should be implemented. All the work done and presented in the following part constitute a design approach. This means that a system and its mechanisms are proposed as a solution to the problem of making best possible use of the multiple links (terrestrial and satellite) available to provide the C2 Link service. Basically, it is a system proposal and not a definitive solution. In fact, most of the system design will not be implemented directly as some solutions are going to be offered by the mobility protocols.

In order to have a better understanding of the different multilink functionalities, this information was organized in a function analysis diagram (Figure 17).

EDITION [01.00]

38


38

Figure 17 Functional Analysis System Technique for the multilink

The multilink gateway functions are highlighted on Figure 17. However, the mechanisms on the access point side will be described in chapter 3.4.

The (X)FRMS, which is quoted in the fourth, fifth and sixth branch of the above figure, designate the ground-to-ground router between the ATN/IPS network and the access networks. It is also used in Figure 17 as GFRMS and SFRMS which stand for Ground and Satellite ground routers.

The first step consists in determining whether or not the received packet is a data link report. If not the multilink gateway acts as a simple router whereas if it is, it parses the report. The report’s format will be described in a following part. These reports should be sent periodically by every Access Point that is able to communicate with an aircraft. Thus, these messages inform the multilink gateway that this AP is able to establish a connection with the aircraft and gives information about the quality of this connection.

Note on the relationship with WP3 activities:

This deliverable focuses on Link Selection and Multi-Link implementation specification, definition and assessment. The results presented in the simulations performed in D3.3 are not influenced by the outcome of the studies performed in the frame of this document. Indeed, the simulations of WP3 operate at a higher layer than WP4 and on time scales that are also different.

The proposed solution, based on LISP, allows to establish either a selection of the transmission link and a transmission on both links when these are available at the same time. The results presented in WP3 consider that, when available, all links are used at the same time.



39

Finally, while the link establishment, management and selection are considered to be performed in the frame of WP3 without giving details on how these are performed, the solution outlined in this deliverable provide means for making the application layer totally unaware of the fact that multiple links are actually used in the information exchanges that take place between the UA and Remote Pilot.

3.1.2 Existing LISP implementations and fitness to the DroC2om concept

An open source implementation of LISP is available as the Open Overlay Router (OOR). With OOR, it is possible for the program to work as a MN (Mobile Node), a xTR (Egress or Ingress Tunnel Router), a RTR (Re-encapsulating Tunnel Router) or a MS/MR (Mapping Server, Mapping Resolver).

For the mobile node, launching LISP creates a virtual interface called lispTun0. It corresponds to a TUN interface (namely network TUNnel). Those interfaces are used for network communications between a host and a virtual machine. It simulates a network layer device and is able to receive/send layer 3 packets. There is also TAP interface which is the same as TUN but for layer 2.

The following picture presents the OOR architecture.

Figure 18 OOR Architecture

Although the LISP protocol is quite interesting in the DroC2om project context as it allows to determine the presence and usability of multiple links, it does not fully fulfil the requirements. The main advantage of using a protocol such as LISP is to be able to work with a fixed IP address for the mobile node. Nevertheless, the link selection algorithm and the possibility to concurrently use multiple links for exchanging traffic, is not part of the protocol and therefore needs to be extended.

EDITION [01.00]

40


40

3.1.3 LISP extensions for Link Selection and concurrent use of multiple links

All the LISP communications are going through the MS/MR. This entity maps the EIDs with the corresponding RLOCs. Each entry is associated with a priority. Thus, it should be possible to manually modify the priority in order to prioritize the chosen link. This gives the following protocol at multilink level :

Evaluate the links quality from the received reports

Choose the best link with the link selection algorithm

Modify the priority of this link by sending the appropriate request to the MS/MR

Send the data

In the current LISP implementation, a connection is established between the correspondent node and the UA with a single link. Considering the fact that the system will have to handle thousands of UAs and must face link failures or link budget degradation, the addition of a redundant link is an important added value. This subsection describes the modification performed on the protocol for adding a redundant link and for handling the duplicates at aircraft level. Figure 19 describes what behavior is expected.

Figure 19 LISP redundant link

As the same traffic is sent on two different links but toward the same destination, the receiver detects half of the received packets as duplicates. It is necessary to handle these duplicates. In order to do that, a unique ID, which is thus the same for the duplicates, must be stored and compared each time a packet is received. It is impossible to consider storing the entire packet, it is far too heavy in processing time and memory efficiency. Storing the UDP checksum is also useless because it is calculated over the packet pseudo-header, so it is highly likely that two packets of the same exchange have the same value of checksum in their header.

A solution is to store in a table the hash of each received packet. Therefore, a hash function has to be chosen. For our purposes, a hash function is a function that maps a string of characters or bytes to



41

indexes in a fixed size table, the so-called hash table (see Figure 20). Important features of a hash functions are that the input strings are mapped uniformly across the table and that the functions can be computed efficiently.

Figure 20 Hash Table used to store each received packet

For the DroC2om concept, the djb2 hash function developed by Dan Bernstein has been implemented. Djb2 is a very efficient hash function with an excellent distribution and high speed processing.

Thus, this function has been implemented on the UA. When the UA receives a packet, it calculates its hash with djb2 starting at the IPv6 version (0x06 : version header field) of the encapsulated IPv6 packet. Then it compares the output hash with the previous hashes stored in an array in memory. If the hash is already in the table, that means that the received packet is a duplicate so it must be dropped. If it is not the case, the hash is stored in the array and the packet is processed as it would normally be (given that it has not been previously received). The following diagram (Figure 21) summarizes this process and displays in green color the provided modification to the LISP protocol algorithms.

EDITION [01.00]

42


42

Figure 21 Duplicates Handler Modification

3.1.4 Interfaces

The interfaces of the multi-link approach defined in the DroC2om concept are offered at the network Layer. An ATN/IPS network layer is considered as baseline while IPv6 and IPv4 protocols are also considered for the implementation of the interfaces to the multi-link concept.

Where required, the Multilink Adaptor and Multilink Gateway elements of the architecture establish a network tunnel offering a layer 3 interface to the external systems, masking the presence of multiple links in the implementation of the concept to external applications.

3.2 Link Selection Methodology

A solution had to be found in order to provide to the multilink gateway the necessary useful information for performing the link selection. For the C2 link, as presented in WP2 deliverables, the overall link quality should be estimated with at least the following parameters:

The capacity (transport and radio)

The delay for 95% (or 99.9%) of the packets



43

The packet loss rate

The decision on the link to be used will always be made by the multilink gateway. Indeed, for performance reasons, it is better to avoid to perform the link assessment on board the aircraft, because this would require additional processing resources on board the aircraft. That is why the overall link quality assessment should be performed by the access points (AP) in the terrestrial and satellite subnetworks. However, radio link quality assessment and control is still to be implemented in the corresponding radio access protocols.

The idea is to make the APs periodically evaluate the quality of the link as soon as they are able to establish a connection with the aircraft. Once all the configured/target parameters are measured the AP applies a high level link evaluation and forges a packet which is a report of the quality of the link for the multilink gateway. This report contains all the necessary information needed by the multilink gateway to perform the link selection algorithm. The APs should do this periodically in order for the multilink gateway to be able to maintain an updated status of each link. The report from each AP to the multilink gateway should contain at least the following information:

High level link evaluation [label/‘color’, one-dimensional score]

Estimated capacity [kbps]

Estimated delay at 95%-ile (or 99.9%-ile) [ms]

Estimated packet loss rate [%] High level link evaluation

The idea of this evaluation is to reduce the processing resources used by the multilink to perform the link selection. Thus, it is processed at the AP level. For each link a colour will be assigned to represent its quality: green, orange, red & black (indicating ‘excellent’, ‘good’, ‘poor’, ’unavailable’). The colours are separated by thresholds. These thresholds are set to values which depend on each data link technology. The value of a particular link is calculated with the Euclidian distance in three dimensions between the estimated point and a reference performance point as explained hereafter. The estimated point is the point obtained in the three dimension space, using the delay at 95% (or 99.9%), the capacity and the loss rate as coordinates. The reference point is the ideal performance point, within a target performance region, which optimises jointly the three link parameters. This technique is proposed in order to respond to the need of compressing the multi-dimensional link quality information (i.e. having a scalar measure for link selection).

Figure 22 represents generically this approach. In both 2-D planes, for Rate Loss vs. Delay and Capacity vs. Delay, the link performance is upper bounded (note: the bound depicted in left part of Figure 22 corresponds to an upper performance bound due to the nature of the KPIs) by a performance curve (indicated by the dotted lines) determined by the transmission conditions on the link and theoretical capacity considerations [16]. In these 2-D planes the target operating region can

EDITION [01.00]

44


44

be defined as regions parallel to the corresponding upper bound performance curves3; the width of the regions reflect the tolerable deviations for the target performance indicators. For C2 link we further assume that we have pre-defined limits for the maximum admissible Rate Loss, maximum admissible Delay and minimum required Capacity.

An estimated link performance point is determined by the estimated values for Delay Loss Rate and Capacity. The link quality indicator is derived calculating several Euclidian distances as follows (each might need additional normalisation):

Step 1: Fix the Delay performance indicator in the Loss Rate vs. Delay and Capacity vs. Delay planes; calculate the Euclidian distances to the closest performance points in the target operating region (green region, decreased Loss Rate and increased Capacity); in case the estimated performance point is within a target operating region the corresponding distance is set to 0. These two distance values are then combined geometrically as 2-D coordinates to obtain the delay-constrained link distance indicator (LDdly).

Step 2: Repeat step 1 by fixing the Loss Rate performance indicator; calculate the loss rate constrained link distance indicator (LDlr).

Step 3: Repeat step 1 by fixing the Capacity performance indicator; calculate the capacity constrained link distance indicator (LDcap).

Step 4: Use the maximum between the magnitude of the link distance indicators calculated in Step 1 -3 to determine the final link quality indicator and assign the one-dimensional score (or labels green, orange, red or black for visualisation purposes).

3 This reference does not provide the same bounding performance curves as reference [16], because the Authors in [16] address a slightly different problem (5G URLLC). Our "Capacity" metric should be understood as a sum of all individual C2 link throughputs.



45

Figure 22 Euclidian distance method to estimate the final link quality indicator

If no specific quality of service is required by the user, the high level evaluation allows the multilink gateway to sort and select the links more efficiently.

A database is foreseen at the multilink level. This database contains the information gathered from the received reports. The link selection algorithm is based on the links known by the multilink. It learns new links thanks to the Air to Ground data link report sent by the APs. The following Table 3 presents how the information is stored and managed within the multilink.

Table 3 Proposal for the Multilink database

IPv6 AP @

Link Evaluation TTL (s) Delay at 95% (ms) Throughput (kbits/s) Loss Rate (%)

The IPv6 address of the AP source is stored in order to know from which access network the report comes from and eventually where the drone is located. However, as the link expires after some time, the TTL (Time To Live) is decreased every second and the link is deleted when the TTL reaches 0.

Then, the link quality is represented by the Link Evaluation column. However, if there is a need of fulfilling a specific target QoS, it is possible to choose the most appropriate link according to the other three parameters displayed in the table.

It must be noted that this multi-link selection algorithm is not fully evaluated in WP3 (Deliverable D3.3 [3], June 2019) as discussed in the ending note of Section 3.1.1). Here we have described the full

EDITION [01.00]

46


46

selection algorithm based on the 2-D Euclidian distances using all three important link KPIs (Loss Rate, Delay, Capacity), while in the evaluations presented in WP3 we apply the labelling (green, orange, red, black) only to the distance based on the Delay estimate (at 95%-ile or 99.9%-ile) relative to one target operating point in the Loss Rate vs. Delay plane (see Figure 22).

3.2.1 Selection Algorithm

The objective of this part is to present and describe the link selection algorithm to be implemented in the multilink gateway. Thus, the link selection is performed on the ground only in order to minimize the processing on board the aircraft.

This algorithm should be able to collect information regarding the quality of the available links, to manage a database containing the links and finally to choose the best link.

However, for different communications the “best link” may be different. Thus the selection algorithm should take into account the following parameters :

Class Of Service related to the data

User preferences

Link quality

The link selection mechanism is depicted in the following diagram of actions, Figure 23. The estimation of the specifications of the exchanges implementing each of the U1-U4 services carried by the C2 Link is to be performed on a case by case basis in an joint effort between the drone manufacturer and the U-Space operator.



47

Figure 23 Diagram of actions for the link selection mechanism

Arrival of packet

Retrieve available links from the multilink

database

Do the communication needs particular

QoS ?

Classify the best links regarding the

high level evaluation

Classify the best links regarding the

appropriate parameter

Choose the most appropriate link(s)

(Link Selection Algorithm)

Apply user preferences & CoS

Send the packet on the chosen link

No Yes

EDITION [01.00]

48


48

4 Evaluation of the DroC2om Hybrid Access Approach

4.1 Evaluation approach definition

4.1.1 MIPv6 testbed

The following figure presents the testbed on which the MIPv6 protocol has been tested. It gathers the usual MIPv6 entities such as the Home Agent (HA), a Corresponding Node (CN) and the Mobile Node (MN). In our case, the MN is represented by an Unmanned Aircraft (UA, labelled DRONE on Figure 24).

Figure 24 MIPv6 testbed

4.1.2 LISP testbed

The following figure presents the testbed on which the LISP protocol has been tested. The particularity of this protocol is to divide the overall network in two parts : the Identifier parts (EID) and the Locator part (RLOC). The Identifier parts correspond to the terminal networks whereas the Locator part corresponds to the intermediary network. Each EID is mapped with one or more RLOC within the Mapping System (MS/MR). Thus, it is possible for any terminal within an EID to find and communicate another terminal located in another EID space.



49

½Figure 25 LISP testbed

4.1.3 Test Scenarios Description

4.1.3.1 MIPv6 scenarios

4.1.3.1.1 First scenario

For this scenario, the Corresponding Node is the client and the Drone is the server. This test has been performed with the following parameters:

Duration: 60 s

Transport Protocol: TCP

Without DoRouteOptimization

Hard Handover

Bit rate: 10 Mbits/s

Drone path: Home Network AP1 AP2 AP1

4.1.3.2 LISP scenarios

4.1.3.2.1 First scenario

For this scenario the Pilot is the client and the Drone is the server. This test has been performed with the following parameters :

Duration : 60 s

Transport Protocol : TCP

Soft Handover

Bit rate : 10 Mbits/s

Drone path : AP1 AP1 + AP2 AP2

4.1.3.2.2 Second scenario

For this scenario the Pilot is the client and the Drone is the server. This test has been performed with the following parameters :

Duration : 60 s

Transport Protocol : TCP

EDITION [01.00]

50


50

Hard Handover = Failure

Bit rate : 10 Mbits/s

Drone path : AP1 AP2 AP1

4.2 Results of approach evaluation

4.2.1 MIPv6 results

Before presenting the results a few definitions are required :

Handover: all the operations performed by a mobile device in order to change its communication cell without interruption of communication or data transfer.

Soft Handover: It occurs when the link with the source cell is maintained while the link with the destination cell is established. The communication with the destination cell is set up before the disconnection with the source cell. This method is also called make-before-break.

Hard Handover: it occurs when the link with the source cell is freed before the establishment of the connection with the destination cell. This method is also called break-before-make.

4.2.1.1 First scenario

For this scenario the Correspondent Node is the client and the Aircraft is the server. This test has been performed with the following parameters:

Duration: 60 s

Transport Protocol: TCP & UDP

Without DoRouteOptimization

Hard Handover

Bit rate: 10 Mbits/s Aircraft path: Home Network AP1 AP2 AP1

The graphs Figure 26 and Figure 27 present the bandwidth variations with respect to the time for TCP and UDP protocols. For NEMO protocol, all the measurements have been performed for hard handover.

Considering the TCP protocol, we have a first handover time of 11 seconds whereas the following ones have a duration lower than 4 seconds. Besides, NEMO is much more consistent with the UDP protocol. In this test, NEMO handled three hard handovers. Each of them has a disruption time lower than 2 seconds. UDP is faster than TCP because acknowledgment of packets (ACK) does not exist with UDP. TCP acknowledges a set of packets according to the TCP window size and the Round-Trip Time (RTT).



51

Figure 26 MIPv6 TCP bandwidth variations results

Figure 27 MIPv6 UDP bandwidth variations results

The graphs present the bandwidth variations with respect to the time for TCP and UDP protocols. For NEMO protocol, all the measurements have been performed for hard handover.

Considering the TCP protocol, we have a first handover time of 11 seconds whereas the following ones have a duration lower than 4 seconds. Besides, NEMO is much more consistent with the UDP protocol. In this test, NEMO handled three hard handovers. Each of them have a disruption time lower than 2 seconds. UDP is faster than TCP because acknowledgment of packets (ACK) does not exist with UDP. TCP acknowledges a set of packets according to the TCP window size and the Round-Trip Time (RTT).

4.2.2 LISP results

EDITION [01.00]

52


52

4.2.2.1 First scenario

For this scenario the Correspondent Node is the client and the Aircraft is the server. This test has been performed with the following parameters:

Duration: 60 s

Transport Protocol: TCP & UDP

Soft Handover

Bit rate: 10 Mbits/s

Aircraft path: AP1 AP1 + AP2 AP2

Figure 28 LISP TCP bandwidth variations results

Figure 29 LISP UDP bandwidth variations results



53

The three handovers of the drone are obviously distinguishable and their duration are remarkably constant unlike the ones seen previously in MIPv6. The protocol takes between 4 and 5 seconds to retrieve the standard communication bandwidth. Its behaviour is quite robust.

The same behaviour is observable for the UDP protocol.

4.2.2.2 Second scenario

This graph presents the behaviour reaction of the protocol when failures occur. The handover times are much longer than the previous one: 24 seconds for the first handover and 12 seconds for the second one. The protocol lost the handover time stability. Nevertheless, it still able to retrieve a communication link.

However, the handover times with UDP protocol are much more constant, around 5 seconds which fits with our requirements.

Figure 30 Hard Handover LISP UDP bandwidth variations results

Figure 31 Hard Handover LISP TCP bandwidth variations results

EDITION [01.00]

54


54

4.2.3 Summary of the results

However the handover times with UDP protocol are much more constant, around 5 seconds which fits with our requirements.

Soft Handover Hard Handover

NEMO TCP handover delay NA 6s

NEMO UDP handover delay NA 3s

LISP TCP handover delay 5s 14s

LISP UDP handover delay 5s 5s

According to all the previous results, considering the scenario where a terminal on the ground communicates with a mobile node:

LISP protocol is better for soft handovers and for unstable links as each connection it establishes is limited by a certain period of time. At the end of the period, it initializes a new connection, a controlled handover somewhat.

NEMO is very efficient for networks where hard handovers are frequent and has also the advantage of having few packet losses when using UDP

Moreover, LISP has several advantages that explain why we choose to implement this protocol for the multilink system. Firstly, LISP is entirely independent of IP version, it supports IPv4 and IPv6 encapsulation. Then, certainly the best advantage of LISP for our system is that is support much more scalability than NEMO. As the system is planned to support thousands of aircrafts scalability is a major parameter. Unfortunately, it was not possible to test those protocols with this amount of mobile nodes. It also interesting to recall that Airbus is supporting the LISP development at ICAO so it is strategical to build a system which might be compliant with the future ATM network.



55

5 Conclusions and recommendations

In this chapter we provide a brief summary of all WP4 deliverables D4.1 [1], D4.2 [2] and this D4.3 (Section 5.1). We highlight the main recommendations based on all findings from WP4 work (Section 5.1) and outline the potential future work topics (Section 5.2). The analysis of the corresponding system requirements from WP2 is presented (Section 5.3).

5.1 Summary and recommendations for U-Space

Summary

In Deliverable D4.1 [1] we have provided an extensive analysis for the use of a 3GPP LTE-Advanced cellular network as a support to the UAS C2 Link communications. The radio access mechanisms and the radio mobility mechanisms have been described, the impact on the network performance has been evaluated, while proposing small network adaptations or enhancements UAS missions in very low level (VLL) in high-loaded terrestrial network scenarios. The results show that all system requirements related to terrestrial C2 link provisioning can be met.

In Deliverable D4.2 [2] we have provided an overview of existing satellite systems, pointing out the need for the development of a novel satellite data link concept to meet the system requirements for performance and regulatory reasons; the document has thus focused on the full top-down concept description, from the top operational view, down to some proposals on the physical implementation, also providing analyses of radio access network mechanisms.

In this Deliverable D4.3, we have provided an assessment of hybrid access mechanisms to combine multiple data links for the bidirectional C2 Link communications between a drone and its operator. The work relies on the previous analysis performed in Deliverables D4.1 [1] and D4.2 [2], and it is complemented by the results provided in the frame of WP3 Deliverable D3.3 [3]. This Deliverable D4.3 has also addressed the remaining system requirements on the integration of the C2 services and data links, as well as the requirements to support multi-operator operations. The LISP SoA multi-link architecture framework has been adopted as the basis of DroC2om integrated cellular-satellite solution, in particular to support concurrent use of multiple links for C2 Link services. Specific elements in this framework had to be adapted to meet the set system requirements in Deliverable D2.1 [17] and D2.3 [15]. The validity of the DroC2om concept is demonstrated via multi-link simulations in Deliverable D4.3 combined with the hybrid radio access results presented in Deliverable D3.3 [3].

Recommendations

The extensive multilink hybrid-access studies carried out in WP4 and documented in Deliverable D4.1 [1], Deliverable D4.2 [2] and this Deliverable D4.3 have lead the DroC2om project team to the following main recommendations:

1. The integrated cellular-satellite hybrid access for C2 Link services in the U-Space shall be adopted as a future proof, scalable and high reliability solution for UAS data links.

2. LISP protocol is better suited for handling the IP mobility scenarios typical in UAS scenarios

EDITION [01.00]

56


56

3. 4G (LTE/LTE-advanced) terrestrial cellular networks shall be considered as the main terrestrial communication technology to provision the high reliability, low latency, wide area coverage C2 Link services in the U-Space.

4. Satellite communication systems shall be considered as the main non-terrestrial communication technology to provision technology to provision the high reliability, ultra-wide area coverage C2 Link services in the U-Space.



57

5.2 Future work

The DroC2om project has extensively analysed the applicability of current terrestrial cellular and satellite radio systems for provisioning C2 Link services in the U-Space. Throughout this work we have identified a couple of main topics and areas which could be considered for future investigations:

1. Enhancements using multi-cellular radio access combined with satellite access to provide close to 100% C2 link reliability, regardless of the UAS mission location and duration

2. Further enhancements by integration of the terrestrial cellular and non-terrestrial satellite radio access via interworking functions or by adoption of 5G Non-Terrestrial Network solutions, possibly also considering non aeronautical safety services satellite systems

3. Pursue the work on the C2 Link Service demonstration with the establishment of a prototype of the DroC2om concept to validate the results obtained by simulation in the frame of the DroC2om project

4. Live trials with a multilink adaptor and a multilink gateway base on multiple cellular-satellite radio access links

EDITION [01.00]

58


58

5.3 Addressed requirements

The Deliverable D4.1 [1] has addressed the relevant requirements from terrestrial (cellular) radio access point of view. The Deliverable D4.2 [2] has addressed the relevant requirements from satellite radio access point of view. All requirements are described in Deliverable D2.1 [17] and D2.3 [15].

In Table 4 to Table 11 we list the DroC2om system requirements along with comments and explanations in the context of the solutions proposed in WP3 and WP4, and updated based on the studies and conclusions in this final Deliverable D4.3.

Requirement reference

Requirement description Comments in the context of WP4

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%

Evaluations of the radio access part of the end-to-end C2 DataLink service.

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

Proposed solutions to provide up to 99.9% availability for the 3GPP C2 traffic profile.

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 standard terrestrial radio access is capable of achieving below 10^-3 PER.

The proposed waveform allows to reach a 10^-3 PER in a satellite context.

Detailed evaluation done in connection with Deliverable D3.3 [3] for specific use case scenarios.

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

Scenarios with multiple and simultaneous C2 DataLink have been evaluated in Deliverables D4.1 and D4.2. Detailed evaluation done in connection with deliverable D3.3 [3] for specific use case scenarios.

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

Scenarios with multiple and simultaneous C2 DataLink have been evaluated in Deliverables D4.1 and D4.2. Detailed evaluation done in connection with deliverable D3.3 [3] for specific use case scenarios.

Table 4 General user performance requirements.



59



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

Evaluation of the radio access for C2 DataLink under the C2 traffic requirements The simulations performed and results reported show that the system supports U1 to U4 services including relay of ATC.

The mapping to U1-U4 services is to be performed in Deliverable D4.3 and in conjunction with Workpackage 3 activities.

WP2-GENUS-FUN-003 The System may provide a coverage area of the ECAC region

The proposed hybrid access between terrestrial and satellite, as well as reusing SoA solutions, will help to ensure ECAC coverage

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

The proposed hybrid access is built on top of the adaptive resource allocation schemes of the individual systems, and resources are therefore reassigned as needed according to the protocol mechanism of these systems

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

The combination of cellular and satellite in the hybrid access ensures that the C2 link is available throughout the whole flight – on ground and in the air - subject to the availability constraints of the systems only

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

The C2 DataLink 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

The C2 DataLink performance has been evaluated assuming air-ground communication interfaces in the context of terrestrial and satellite radio access systems.

WP2-GENUS-FUN-009 The System may support: - point-to-point data communications - point-to-multipoint data communications - broadcast data communications

The C2 DataLink performance has been evaluated assuming point-to-point data communications. Broadcast communication from the radio access network has been assumed to be used for cell level radio configuration of the UEs.

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

No ITAR and EAR restrictions are identified in the DroC2om project. It is thus possible to produce ITAR and EAR free equipment implementing the DroC2om concept.

Table 5 Generic user functional requirements.

EDITION [01.00]

60


60



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

The proposed hybrid access design relies directly on the security related countermeasures of the individual systems, both of which provide the required measures.

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

Partly addressed. The C2 DataLink performance has been evaluated assuming connection-oriented radio communications.

Table 6 Generic data link functional requirements.



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

Addressed. All C2 Link evaluations have been performed using LTE radio access. No specific radio access evaluation is required for 5G.

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

Addressed. All C2 DataLink evaluations have been performed using LTE radio access mechanisms (link-adaptation, resource scheduling, etc.)

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

Partly addressed. All C2 DataLink evaluations have been performed using the 3GPP C2 traffic profile. The DroC2om ‘high’ traffic profile will be evaluated in Deliverable D4.3 and in conjunction with Workpackage 3 activities.

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

Partly addressed. All C2 DataLink evaluations have been performed using the assumption of single MNO. The standard cellular hand-over and radio mobility algorithms have been used.

The multi-MNO studies are to be performed in Deliverable D4.3 and in conjunction with Workpackage 3 activities.



61

- Handover between cells provided through different e/gNodeB owned by the same operator - Handover between cells provided through different e/gNodeB owned by different operators.

Table 7 Terrestrial C2 link specific requirements (see Deliverable D4.1 [1]).



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

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.

EDITION [01.00]

62


62

provided through different satellite antenna beams - Handover between channels provided through different satellites owned by the same operator - Handover between channels provided through different satellites owned by different operators

WP2-SATCO-FUN-007

The System may be compatible with a satellite communication system ensuring the following PER performances: - PER < 10-2 for voice ATC communications relay when the link is available.

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 8 Satellite C2 link specific requirements (see Deliverable D4.2 [2]).



63



WP2-INTSE-FUN-001

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

The proposed design provides a multi-network service integration relying on the IP protocol for global interconnection

WP2-INTSE-FUN-002

The System shall provide the appropriate segregation in the provision of various services of the U-Space

The design of the hybrid access mechanism allows for prioritization of traffic, and can therefore impose the necessary QoS restrictions for C2 drone critical communication

WP2-INTSE-FUN-003

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

The design of the hybrid access mechanism allows for prioritization of traffic, and can therefore impose the necessary QoS restrictions for C2 drone critical communication

Table 9 Requirements on integration of C2 services



WP2-INTLI-FUN-001

The System shall be a system of systems able to integrate existing communication systems as well as new communication systems.

The SoA architecture framework is continuously developed to integrate existing communication systems as well as new communication systems

WP2-INTLI-FUN-002 The System shall be flexible to integrate as easily as possible new communication technologies

The SoA architecture framework is continuously developed to integrate existing communication systems as well as new communication systems

WP2-INTLI-FUN-003

Within the System, upper protocol layers must work transparently with any supported communication technology for both user and control planes.

The hybrid access interfaces at the network layer and therefor work transparently with any communication technology based on IP – user vs. control plane

WP2-INTLI-FUN-004

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

The hybrid access mechanism is designed to automatically allocate subsystem links, based on availability and performance

WP2-INTLI-FUN-005

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

Authorization of communication resources is based on subscription to the services of the subsystems, e.g. by SIM card for terrestrial (cellular systems)

EDITION [01.00]

64


64

the user.

WP2-INTLI-FUN-006

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


WP2-INTLI-FUN-007

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

The automatic link selection in the hybrid access mechanism can be overwritten by configuration

WP2-INTLI-FUN-008

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


WP2-INTLI-FUN-009

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

The DroC2om concept does not limit or impose any constraints on the technologies that are supported for its implementation.

The decision of the subnetworks to be supported in the implementation of the DroC2om concept are under the responsibility of the manufacturer.

WP2-INTLI-FUN-010

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

The addition of sub-networks to the DroC2om concept for U-Space C2 Link can be performed without modifications of the concept itself.

The implementations of the DroC2om concept will determine the technologies to be considered for the various links in accordance with regulations and constraints that can be revised in future times.

WP2-INTLI-FUN-011

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

Given the proposed multi-link design, the hybrid access is built on top of the adaptive resource allocation schemes of the individual systems, and therefore optimised within these subsystems

WP2-INTLI-FUN-012

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

The LISP modification described in D4.3 allows to fulfil this requirement.

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

The LISP approach proposed as basis for implementation of the DroC2om concept supports this feature.



65

independent access networks

WP2-INTLI-FUN-014

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


WP2-INTLI-FUN-015

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


Table 10 Requirements on integration of C2 data links



WP2-MULOP-FUN-001 The System shall allow deployment of competing C2 Link Service providers and operators in same geographical locations.

The SoA architectures outlined in WP4 allow deployment of competing C2 Link Service providers and operators in same geographical locations

WP2- MULOP-FUN-002 The System underlying network shall support interoperability with multiple ground operators and multiple communication service providers simultaneously.

The SoA architectures outlined in WP4 allow for multiple U-Space and communication service providers

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

The support for multiple operators is part of future work on the DroC2om system concept and architecture

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

The support for interworking is provided by the use of ATN/IPS and IPv6/IPv4 interfaces for the system.

WP2- MULOP-FUN-005 The DroC2om network shall support user traffic performance indicators and usage statistics in the context of multiple operators

The DroC2om concept relies on the capabilities of the underlying sub-networks to report such indicators and statistics. The baseline considered for DroC2om allows to fulfil this requirement.

WP2- MULOP-FUN-006 The System shall support security requirements over multiple operators / service providers.

In the proposed design, the hybrid access design relies directly on the security related countermeasures of the individual systems, hence also supports security requirements over multiple operators / service providers

Table 11 Requirements to support Multiple Operator.

EDITION [01.00]

66


66



67

6 References

[1] SESAR 2020-763601 DROC2OM deliverable, “D4.1 - Cellular LTE-5G System concepts to provide optimal support for both terrestrial communications and high reliability UAS data links,” May 2018.

[2] SESAR 2020-763601 DROC2OM deliverable, “D4.2 - Satellite system concepts solutions for high reliability UAS data links,” October 2018.

[3] SESAR 2020-763601 DROC2OM deliverable, »D3.3 - Insights from simulation experiments on combined cellular-satellite UAS communications«.

[4] Broadband Forum (BBF), “TR-384 - Hybrid Access Broadband Network Architecture,” 2016.

[5] K.-J. Grinnemo and A. Brunstrom, “A First Study on Using MPTCP to Reduce Latency for Cloud Based Mobile Applications,” in IEEE Symposium on Computers and Communication (ISCC), 2015.

[6] H. Rasmussen, K. Mortensen, R. Mogensen og C. Markmøller, »Ultra Reliable LTE with Multiple Internet Interfaces,« Aalborg University, 2017.

[7] SESAR 2020-763601 DROC2OM deliverable, “D2.2 - Overall System Architecture,” February 2019.

[8] 3GPP Technical Specification Group Services and System Aspects, “TS23.401 - General Packet Radio Service (GPRS) Enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access,” 2017.

[9] 3GPP Technical Specification Group Services and System Aspects, »TS23.501 - System Architecture for the 5G System (Release 15),« 2017.

[10] 3GPP Technical Specification Group Services and System Aspects, »TR23.793 - Study on Access Traffic Steering, Switching and Splitting support in the 5G system architecture (Release 16),« 2018.

[11] International Civil Aviation Organization (ICAO), “LISP - A Multi-Homing and Mobility Solution for ATN using IPv6,” 2014.

[12] I. C. A. O. (ICAO), »LISP - A Multi-Homing and Mobility Solution for ATN using IPv6,« Montreal, 2014.

[13] F. Templin, »Asymmetric Extended Route Optimization (AERO),« Interdomain Routing Working Group, 2018.

[14] V. Ishakian, J. Akinwumi, F. Esposito og I. Matta, »On Supporting Mobility and Multihoming in Recursive Internet Architectures - BUCS-TR-2010-03,« Computer Science Department , Boston

EDITION [01.00]

68


68

Universty, 2010.

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

[16] B. Soret, P. Mogensen, K. I. Pedersen and M. C. Aguayo-Torres, “Fundamental tradeoffs among reliability, latency and throughput in cellular networks,” in IEEE Globecom Workshops (GC Wkshps),, Austin, TX, USA, 2014.

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

DroC2om - 763601 - D4.3 Integrated cellular-satellite ... · Figure 2 : Detailed hybrid cellular-satellite access components of the DroC2om System Concept highlighting the scope of

Documents