PreprintPDF Available

Reliable Command, Control and Communication Links for Unmanned Aircraft Systems

Authors:
Preprints and early-stage research may not have been peer reviewed yet.

Abstract and Figures

The operation of unmanned aircraft systems (UAS) currently sees limitations in beyond visual line of sight (BVLOS) missions. Outside of military operations, regulations and technology for safe operations are still being developed. To ensure alignment with regulatory demands in such scenarios, the complete UAS must be designed to meet the required safety standards. This includes the design of the Command, Control and Communication (C3) link. In this paper, we examine the nascent regulatory framework and technical challenges facing system designers who wish to achieve high levels of safety and compliance utilizing cost-effective communications networks. We further propose a path towards achieving this goal. This file is a preprint version of the paper with the given DOI to be presented at HiPEAC DroneSE '21.
Content may be subject to copyright.
Reliable Command, Control and Communication Links for Unmanned Aircra
Systems
Towards compliance of commercial drones
JENS FINKHÄUSER, AnyWi Technologies B.V., The Netherlands
MORTEN LARSEN, AnyWi Technologies B.V., The Netherlands
1 ABSTRACT
The operation of unmanned aircraft systems (UAS) currently sees limitations in beyond visual line of sight (BVLOS) missions. Outside
of military operations, regulations and technology for safe operations are still being developed.
To ensure alignment with regulatory demands in such scenarios, the complete UAS must be designed to meet the required safety
standards. This includes the design of the Command, Control and Communication (C3) link.
In this paper, we examine the nascent regulatory framework and technical challenges facing system designers who wish to achieve
high levels of safety and compliance utilizing cost-eective communications networks. We further propose a path towards achieving
this goal.
CCS Concepts:
Networks Transport protocols
;Programming interfaces;
Network reliability
;
Network mobility
;
Com-
puter systems organization Reliability;Availability;Redundancy.
Additional Key Words and Phrases: reliable wireless connection, unmanned aircraft systems, unmanned aerial vehicles, UAV, UAS,
drones, BVLOS, SORA, SAIL, C3 links, multipath networking, multipath communication,
ACM Reference Format:
Jens Finkhäuser and Morten Larsen. 2020. Reliable Command, Control and Communication Links for Unmanned Aircraft Systems:
Towards compliance of commercial drones. In Proceedings of HiPEAC 2021 – DroneSE: Drone Systems Engineering (HiPEAC 2021). ACM,
New York, NY, USA, 13 pages. https://doi.org/10.1145/3444950.3444954
2 INTRODUCTION
Use of unmanned aircraft systems (UAS) for commercial activities, is steadily increasing. However, aordable technolo-
gies for safe operations in complex use cases are not yet widely available, limiting uptake by commercial enterprises. At
the same time, regulations for commercial use outlining acceptable safety levels are still under development, further
adding to the uidity of the market.
In this, Beyond Visual Line of Sight (BVLOS) operations provide a particular challenge. For ights over populated
and other high risk areas, the draft regulation rightly places a high emphasis on reliable Command, Control and
Communications (C
3
) links between the unmanned aerial vehicle (UAV) and the rest of the UAS. Such reliability is
currently only available in costly bespoke solutions, which inhibits wide-spread commercial adoption.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not
made or distributed for prot or commercial advantage and that copies bear this notice and the full citation on the rst page. Copyrights for components
of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on
servers or to redistribute to lists, requires prior specic permission and/or a fee. Request permissions from permissions@acm.org.
©2020 Copyright held by the owner/author(s). Publication rights licensed to ACM.
Manuscript submitted to ACM
1
HiPEAC 2021, Jan 18, 2021, Budapest, Hungary (virtual event) Finkhäuser, Larsen
A more commercially feasible approach is to leverage already available, high-volume and low-cost technologies,
and provide additional reliability features on top of them. Several such technologies can be bundled; the most basic
use-cases, though, revolve around handover between base stations and failover scenarios beween the dierent link
technologies.
Either case can be improved by providing a stable abstract communications link to the application layer, whilst
transparently scheduling the application data across the best available underlying link or links in a multipath protocol.
As a provider of wireless technologies, AnyWi Technologies B.V. has been able to gather extensive experience
with technologies implementing this in previous research and commercial projects, but found that none of the examined
technologies to date provide a cohesive solution to the overall requirements placed on UAS C3links.
This paper outlines the nascent regulatory framework and related safety standards to consider in nding a solution.
We then explore the limitations of existing technologies, not only in terms of reliability but overall communications
safety.
Finally, we propose a component architecture that should provide the interfaces necessary to enable eective
coordination of the combined technologies, and that forms the basis for AnyWi ’s further research and development
eorts within the ECSEL-JU COMP4DRONES [
2
] project. Work in a sibling project, ADACORSA [
1
], is currently leading
towards the denition of a more abstract component architecture that may serve as a basis for integration of a broader
range of link technologies, in turn requiring a higher degree of modularisation of interfaces.
Drone operations
and control centre
Drone
working area
Flight goes behind buildings,
i.e., beyond visual line of sight
Mobile
network A Mobile
network B
Local ground
station
Drone control station
PH-ONE
LEO
satellite network
D-BEAT
Burgemeesters-
en Professorenwijk
Binnenstad
Lage Mors
Haagwegkwartier
Noorderkwartier
Maredijkbuurt
De Kooi
Leiden
Centraal
Kooitunnel
Padviaduct
Rijnsburgerviaduct
Plesmanviaduct
Churchillbrug
Joop Walenkamptunnel
Morsviaduct
elyviaduct
Wilhelminabrug
Sumatrabrug
Duikerbrug
Leeuwenhoek
1
Valkbrug
Rijnzichtbrug
Gouden
Balbrug
Pauwbrug
Wittepoortsbrug
Herenpoortsbrug
Utrechtse
Brug
Schrijversbrug
Karnemelksbrug
Weverbrug
Blauwpoortsbrug
Bostelbrug
Rembrandtbrug
Marebrug
Rijnsburgerbrug
KoepoortsbrugJan van
Houtbrug
Zijlpoortsbrug
Verversbrug
Vreewijkbrug
Kerkpleinbrug
Staatsspoorbrug
Spanjaardsbrug
Duikerbrug
Leeuwenhoek
3
Gansoordbrug
Gepekte
Brug
Groenebrug
Roombu
Turfmarktsbrug
N206
C
hurc
h
illlaa
n
Chu
Stationsplein
Willem de Zwijgerlaan
Stationsplein
Schipholweg
P
l
e
s
m
a
nl
a
a
n
Pl
e
sm
a
nl
a
a
n
K
a
naal
w
eg
H
a
ag
w
e
g
Lamme
n
scha
n
sw
e
g
Sandifort
d
reef
B
u
r
g
grav
e
n
laan
S
u
matr
a
st
r
aat
Sum
a
trastr
a
at
Sc
h
utter
s
ve
l
d
L
a
g
e
R
ijndij
k
L
a
ge Ri
j
ndijk
Lage Rijn
d
ijk
Hoge Ri
j
n
dijk
L
a
n
gegracht
Langegr
a
cht
H
e
r
ensingel
H
erensingel
Z
i
j
l
s
i
n
g
e
l
Z
i
jls
i
n
g
e
l
Z
i
j
l
s
ingel
Von
d
e
ll
a
a
n
N
o
o
r
dei
n
d
e
M
orssingel
Hooi
g
r
acht
B
r
eestra
a
t
B
r
eest
r
aat
M
o
le
n
w
e
r
f
Le
v
e
nd
a
al
Levenda
a
l
Klokpo
o
rt
Darwin
w
eg
Zi
j
ldij
k
Z
ijldijk
Kooilaan
K
o
oil
a
a
n
M
o
rs
w
eg
H
a
a
g
w
eg
Haagw
e
g
L
D
e
L
a
at
de
K
an
t
erst
r
yge
n
slaan
Jacques Urlu
J
a
cques Urlusp
W
illem d
e
Z
w
ijgerl
a
an
Willem Bar
e
ntszstraat
traat
A
Al
b
e
rt
V
e
r
we
i
j
st
r
a
a
t
Admiraal
B
anckertweg
5e Bi
n
nenvestgr
a
cht
Zoeterwo
u
d
s
e
s
ingel
Zoet
e
r
w
o
udsesingel
Z
o
e
t
e
r
w
o
udsesi
n
gel
Zoeterwo
u
dsesingel
Tesse
l
scha
d
e
s
t
ra
a
t
J
.
C
. de Rij
p
straat
Gl
e
n
n
M
ille
De Gijsel
a
arstraa
Witte Roz
e
nstraat
W
a
t
e
rg
e
uz
e
ns
t
r
a
at
U
t
r
echtse Jaagpa
d
Utr
e
cht
s
e Jaagpad
Utr
e
chtse Jaagpad
Rijns
b
urgersingel
Rijns
b
ur
g
e
r
s
i
n
gel
Ri
j
n
e
n Schie
k
a
d
e
Os
e
n Paar
d
enlaan
O
os
t
e
r
dwar
s
straat
J
a
n W
o
lkers
s
traa
t
J
an van Goye
n
kade
D
e
Ge
n
e
st
e
t
s
t
raat
Bl
a
u
we T
r
amstr
a
a
t
Wi
l
le
m
K
l
ooslaan
G
e
rrit D
o
ustraat
Brandts B
u
yska
d
e
k
e
straat
P.J. Blo
k
str
aat
M
iddelste
g
rac
h
t
K
o
rtena
e
rstra
a
t
He
e
mskerkstraat
Gr
o
enoo
r
dstraat
aat
C
oor
n
h
e
rts
tr
a
a
t
Alex
a
nd
e
rstraat
A
l
ex
a
n
d
erstr
a
a
t
Vreewi
j
kstraat
Utrechtse Veer
Utrechtse Veer
U
iterst
e
gr
a
cht
S
u
riname
s
traat
ieg
h
e
lstraat
Sl
a
chth
u
isla
a
n
R
ijndi
j
kstraat
P
.C.Hoo
f
tlaan
M
u
nni
ke
n
straat
Me
e
rburger
k
ade
Margrietstra
a
t
Ja
c
ob
C
atsl
a
an
H
u
izingast
r
a
a
t
Ev
e
rtsen
s
traat
D
e
G
oejestr
aat
D
e
Goejestr
a
a
t
Da Costastr
aat
de
Caecil
i
a
s
traat
Caecilia
s
traa
t
Bo
n
tek
o
e
st
r
aat
Bloemis
t
e
n
laan
B
e
rnhar
d
s
tra
a
t
Ap
o
t
hekersdijk
An
t
i
llens
t
raat
Vol
l
e
r
s
g
racht
Uhle
T
o
u
ssaintka
d
e
S
u
m
a
t
ra
s
tr
a
at
Sieboldstraat
Ro
o
mburgerwe
g
Prins
e
n
s
tr
a
at
Po
t
gi
e
t
e
rl
a
an
Pas
t
e
u
r
s
t
ra
a
t
Me
rwe
d
es
M
aurit
s
s
t
raa
t
M
arijkestra
a
t
J
u
l
ia
n
a
s
t
r
a
at
Jou
b
ert
s
t
raat
Haar
l
e
m
me
r
weg
Breder
o
straat
B
o
sh
u
izer
k
ade
B
ea
t
rixstraat
Z
ijloo
r
dkad
W
i
tt
e
Singel
Witt
e
S
i
n
g
e
l
W
i
t
t
e
Si
n
gel
Willemstraat
Ver
d
amstra
a
t
Valdezst
T
e
r
H
a
arkade
Tasman
s
traat
So
p
hiast
r
aat
So
e
mbastr
a
at
h
elpe
n
k
ade
Oran
j
egrach
t
O
o
sterstraa
t
Mar
n
ixst
r
aa
t
L
ombok
s
tr
a
at
K
ana
a
lstraat
K
a
is
e
r
s
t
ra
a
t
Hanse
n
straat
Han
Floresstraat
a
t
k
ers
t
r
aat
Doelengracht
De Wetstraat
Decimastraat
C
o
sijnstra
at
Bo
r
n
eost
r
a
a
t
Bo
r
ne
o
straat
B
ernha
r
dkad
e
Admir
a
alsweg
W
a
ar
d
s
t
ra
a
t
Wa
a
r
d
g
racht
V
este
s
tr
a
at
V
e
stestr
aat
h
aartp
a
d
T
i
mo
r
straat
Ti
m
o
r
straat
S
t
ille Ri
j
n
Steens
c
huur
Rei
t
zstraa
t
P
a
pen
g
racht
Ou
d
e Singel
Ou
d
e Singel
Ou
d
e Singel
N
o
achstraa
Ni
e
uwe Rijn
Mol
e
ns
t
r
a
a
t
Lustho
f
l
a
a
n
Leli
e
s
t
raat
Le
l
iestr
a
at
L
a
ng
e
str
a
at
Lan
g
estr
a
at
Kr
e
f
eldlaan
Julianak
a
de
J
o
ulest
r
aat
Irenestraat
e
re
n
s
t
raa
t
Herengracht
He
r
engracht
Herengracht
Gortestra
a
t
Fal
c
kstraat
D
riftstr
a
a
t
D
r
iftstr
a
at
D
riftstraat
Drif
t
straat
Doez
a
stra
a
t
C
o
be
t
straat
C
obet
s
tr
a
a
t
C
o
betstraat
At
j
e
hs
t
ra
a
t
Atjeh
s
tra
at
A
tjeh
s
traat
Am
b
ons
t
ra
a
t
Zuids
i
ngel
Zand
s
traa
t
Zaanstraat
Voorstraat
Von
d
ellaan
Vonde
l
laa
n
St
u
ws
t
r
aat
S
cha
p
enw
e
i
R
ijn
s
tr
a
at
P
ar
k
stra
a
t
Parks
t
raa
t
O
xfordl
a
a
n
Morssinge
l
Molensteeg
M
a
resi
n
g
e
l
M
aresingel
Maresi
n
g
el
M
a
res
i
n
g
e
l
M
aasst
r
aat
La
k
enplein
Korte Mare
Kools
t
raat
Kijfgracht
Ker
n
s
t
raat
J
a
v
a
st
r
a
at
Jav
a
s
t
r
a
at
IJsselkad
e
IJs
s
elkade
Hoef
s
traat
Geregrach
t
G
algewa
t
er
B
o
te
r
ma
r
kt
Boisotkad
e
B
alistraa
t
Ba
a
t
s
traat
oraweg
Wasstra
a
t
S
p
ilsteeg
Rapenburg
Rap
e
n
b
urg
Rapenburg
Rapen
b
urg
Rap
e
nb
u
rg
Ra
a
mstee
g
Raa
m
steeg
P
l
a
n
t
s
o
e
n
P
l
a
nt
s
o
e
n
P
lan
t
s
o
e
n
O
u
d
e Ve
s
t
Oud
e
Vest
O
u
de
V
est
O
ude Ve
s
t
Ou
d
e Rijn
O
u
de Ri
j
n
O
ud
e
Rijn
Middelweg
Men
d
e
l
w
e
g
Marislaan
Ma
l
ie
b
aan
Mali
e
ba
a
n
L
a
ngeb
r
u
g
L
a
n
gebru
g
Kooi
z
icht
Kl
o
k
steeg
Kanaalweg
Kanaalweg
Kana
a
lweg
Houtmark
t
H
o
gewoer
d
Have
n
kade
Fruinl
a
a
n
B
o
omm
a
rkt
Aarstr
a
at
Aars
t
raat
Z
ijllaa
Zijldij
k
Zijldijk
Zi
j
lba
a
n
Vl
a
s
Rin
g
kade
Rijn
k
ade
Pl
a
ntage
O
verrijn
O
u
d
p
l
e
i
n
M
o
rslaan
Morskade
M
are
d
ijk
M
ar
e
d
ij
k
Alo
ë
la
a
n
A
kk
e
r
h
o
f
Morsweg
M
o
rsweg
H
o
f
laan
D
uinhof
an
B
os
h
o
f
Vli
e
t
V
liet
Ha
v
en
O
ude Singel
Antoon
Coolenk
a
de
U
i
ter
s
t
e
gracht
Sl
a
u
erhoff
p
ad
Klik
s
pa
a
nw
e
g
N
e
sciok
a
d
e
Lodewij
k
Napol
e
onstraat
H
a
arle
m
m
e
r
str
a
at
Kr
a
l
e
ndij
k
k
ade
O
ranj
e
gr
a
cht
Ampèr
e
straat
Waa
r
dgracht
Sc
h
ool
s
t
e
e
g
N
ie
u
w
e
Rij
n
Hertzs
t
raat
H
a
v
e
rstraat
Koddesteeg
O
r
a
n
jeri
e
Dief
s
teeg
V
is
m
arkt
Haagweg
W
est-In
d
iëba
a
e
s
terwatering
an
Po
e
lweter
i
ng
P
esthuislaa
n
Ein
t
ho
v
enweg
B
a
r
g
elaan
L
eve
n
d
a
al
K
ilj
a
n
Anna Grollstraat
Bloem
s
tra
a
t
Drie
m
ansc
h
ap
s
ka
d
e
Van
de
r
Paauw
k
ad
e
Van d
A
n
k
erpark
H
i
ppocra
t
espa
d
Bontiuspad
N
i
c
ker
i
e
pa
d
Rijnzichtstraat
Pas
c
alstr
a
at
Fok
k
e
s
t
r
aa
t
H
u
ig
s
t
r
a
a
t
P
a
p
e
g
a
a
i
s
b
o
lw
e
r
k
H
og
e
woerd
Boshuizerpad
Z
i
j
l
o
ev
e
r
V
a
n T
o
ornv
l
ietstraat
Evertsenpad
H
ortus
b
ota
n
icus
S
p
oor
Sp
De Waard
Leids Universitair
Medisch
Centrum
Plantsoen
Hogeschool
Leiden
Leeuwenhoekpark
Kooipark
Van der
Werfpark
Ankerpark
Haagweg
Stedelijk
Gymnasium
Slachthuispark
De Burcht
G
roenhaz
e
ngracht
Spoorhaven
Nieuwe Rij
n
Oud
e
Rijn
Oude Rijn
Rijn-Vlietk
a
naal
Zijl
Binnenvestgr
a
cht
L
e
i
d
e
n
Internet
Fig. 1. Multi-Link handover in BVLOS flights
3 REGULATORY BACKGROUND & STANDARDS
The European Union is currently undergoing the process of regulating the use of commercial UAS under the JARUS
SORA framework [
13
] from the point of view of single operations and U-Space for a more comprehensive view on
2
Reliable C3Links for UAS HiPEAC 2021, Jan 18, 2021, Budapest, Hungary (virtual event)
unmanned operations. In January 2020, EASA published its opinion [
5
] on utilizing the U-Space Concept of Operations
[8] in order to provide European-wide regulations in the specific category of UAS.
3.1 UAV Categories
These regulations distinguish between dierent classes of UAV, based on weight, range, and similar parameters of the
vehicle. In addition to the specific category, these classes are the open, and certified categories. The open category
does not represent a disruptive new technology, as it requires the operator to be near the vehicle and within visual
line of sight, often dened as 500m horizontally and 120m vertically. As such it is akin to a traditional advanced tool
controlled by a human operator – albeit a tool with more degrees of freedom and a longer reach than traditional
categories of machinery.
To truly release the economic potential of drones as a tool for automation of a multitude of tasks, it is necessary to
have simple and economic access to operations beyond visual line of sight for a broad range of commercial users. In
manned aviation, this requires deployment of certied equipment, for which the certication process is very costly [
19
]
[
9
]. In the case of unmanned aviation (drones), the road to design and production of aircraft for the certified is still
long.
The specific category has been dened to help bridge this gap by forming a halfway point between them between the
open and certified categories. It focuses on mid-sized drones for various purposes, including commercial applications,
and allowing for long-range, BVLOS missions. In the following, we will be concentrating on this category.
3.2 U-Space CONOPS
For the specific category of UAV, the U-Space Concept of Operations [
8
] and UTM [
16
] is to be the equivalent of Air
Trac Management for manned ights, and the primary system within which UAS missions are planned and executed.
In order to do so safely, U-Space must coordinate with ATM.
U-Space contains a concept of dierent airspace categories, classifying spaces with higher or lower safety requirements.
Flights near airports or critical infrastructure, but also over densely populated areas require more safety features of
UAS than ights over sparsely populated, rural environments.
3.3 SORA Requirements on C3Links
In addition to airspace classes, the mission parameters contribute to the overall risk assessment. Here in particular
Beyond Visual Line of Sight (BVLOS) ights, such as ights at long range or behind obstacles, increase the overall
mission risk. To manage this risk without necessarily resorting to the full framework of aircraft certication, the adopted
SORA framework is based on risk assessments, which in turn denes Specic Assurance and Integrity Levels (SAIL).
Here, the higher SAIL levels dene increased requirements, such as mandating Command and Control (C
2
) link
reliability that existing commercial solutions cannot adequately guarantee. The SAIL levels place similar requirements
on Command, Control and Communications (C3) links.
Under the proposed regulations, the problem of providing reliable C
3
links for BVLOS ights becomes one of meeting
the requirements of high SAIL levels.
3.4 IEC 61508
While U-Space and SORA provide a good starting point for the safety requirements of higher risk UAS operations,
EASA is currently still working on recommendations outlining how such safety may be achieved. It is therefore prudent
3
HiPEAC 2021, Jan 18, 2021, Budapest, Hungary (virtual event) Finkhäuser, Larsen
to look towards how safe communications have been regulated in other application areas, as the likelihood that future
regulation is aligned with already established best practices is fairly high.
Here, as a general safety standard, IEC 61508 [
10
] provides two ways for achieving certied safety: a white channel
and black channel approach. Where the former assumes that the entire communications stack from hardware to
software is certied as a whole, the latter suggests layering safety protocols over otherwise unreliable communications
subsystems. Such a black channel concept applies well to the high-volume, low-cost technologies easily available to
commercial UAS operations.
3.5 IEC 62280
The standard that describes a safety protocol for black channel use in railway systems is IEC 62280 [11] / EN 50159
[17]. The standard denes risks to safe electronic communications, as well as mitigation techniques against them.
For a safe and reliable C3link for UAV, eventually all of these risks have to be addressed.
3.6 Unaddressed Issues
Where IEC 62280 addresses issues such as handling the loss of individual control messages, it does not address outright
loss of signal – that is, a situation where re-sending a lost message is impossible.
This is, of course, the most concerning scenario in BVLOS ights – where a UAV either goes out of range of a base
station due to the distances or orientations of antenna involved, or due to interference from obstacles such as mountain
ranges or tall buildings.
The matter is complicated in that technologies oering better coverage are often more costly, or provide lower
bandwidth or higher latency, or are simply not available in all phases of the ight.
Part of the problem of providing reliability in C
3
links is choosing the most appropriate link technologies, such as
LTE/5G [
4
], WiFi/WiFi-p [
7
], LoRaWAN [
6
] or satellite technologies. Each of these low-cost links typically full the
SAIL requirements under ideal operating conditions (see Figure 1).
When conditions are less ideal, the immediately related problem is then to provide handover between these tech-
nologies such that overall C3link performance is not unduly degraded. This is the focus of AnyWi ’s eorts.
The proposed approach is to utilize multiple links in parallel via a multipath protocol. While this approach may be
used in all phases of ight for the purpose increasing overall available bandwidth, in critical phases of ight where
handover is imminent, parallel use of multiple links can hide the transition between links entirely where signals from
dierent technologies overlap.
The following section explores technical challenges for such a protocol.
4 TECHNICAL CHALLENGES
There exist a number of technical challenges when proposing to hand over between several black channel communi-
cations links, some more conceptual in nature, others more related to implementation details of the underlying link
technologies.
4.1 OSI model
The standard model for describing layers in a communications protocol is the OSI model. It evolved in parallel to
the widely used Transmission Control Protocol (TCP), which underlies the modern World Wide Web. Herein lies the
historical reason why TCP does not t neatly into the OSI model, instead spanning the transport and session layers.
4
Reliable C3Links for UAS HiPEAC 2021, Jan 18, 2021, Budapest, Hungary (virtual event)
The other reason, of course, is eciency: a protocol oering a stream oriented interface to applications must be able
to assign each received datagram to a session. While co-operation between dierent protocols at dierent layers to this
purpose is feasible, it is generally more ecient to violate strict layering, and the path of choice for TCP.
A multipath protocol providing co-operation between several dierent radio technologies in one direction, and
presenting an abstract data transport in the other direction spans even more of the conceptual OSI layers – a deteriorating
signal strength can already be an indicator that handover between links should be initiated.
One of the challenges, then, is an exercise in abstraction: provide the components to the system and the interfaces
between them such that each component individually can t as comfortably into a single OSI layer as possible, even if
the overall system spans several of them.
4.2 Black Channel/Black Box Technologies
While a black channel approach is the right choice for cost management, the inner workings of commercially available
communications modules are often opaque. To mitigate for failures in these black boxes, implementations must be able
to exercise some control over them – in practice, that can mean something as crude as being able to power cycle an
unresponsive communications module.
4.3 Cell selection
In the instance of GMS/UMTS/LTE/5G modules, a semi-opaque issue is that the algorithm that decides which cell to
camp on [18] may not provide the best availability.
Rather, standards in this area tend to default to using cells that are known to be serviced by the currently selected
network operator. Wireless modules can be operated in other modes, which then place the burden of operator selection
on the user – in this case, the system providing reliable C3links.
4.4 Link Technology Selection
The same problem in a dierent avour exists where the system decides on link technologies to utilize. In either case,
the following factors are a selection of data to consider:
speed of switchover to a new technology/cell;
connection characteristics, such as bandwidth and latency – this is of particular interest when considering
satellite technology;
expected connection coverage, including altitudes;
and cost of utilization.
4.5 Linux Link Discovery
Whereas none of the presented issues so far are specic to the Linux operating system, the mature tooling the platform
presents coupled with its popularity in embedded platforms make for a prime target for development.
Linux distributions provide a range of solutions for managing wireless links. 3GPP links are typically handled by
ModemManager [
3
], while other links – wired or wireless – are detected and initialized by more or less distribution
specic management systems, such as NetworkManager, systemd-networkd and/or netplan.
Merely understanding that these dierent components exist already informs us that in order to maintain interoper-
ability between them, lower-level components must provide abstract information to higher level components. These
5
HiPEAC 2021, Jan 18, 2021, Budapest, Hungary (virtual event) Finkhäuser, Larsen
abstractions then make it signicantly harder for a higher level quality of service estimator algorithm to access low-level
radio signal information, as such data is typically lost along the path.
The reason is, of course, that in these existing systems the purpose is compatibility with a wide range of hardware,
not eciency in link technology handover. Alternative data exchange paths will need to be established in order to reach
higher eciency.
4.6 Multipath Protocol Characteristics
When link characteristics are determined, the next set of challenges lie in selecting an appropriate protocol to interface
with the application layer. The aim of providing a reliable link to the application can be viewed in technological
terms as providing an abstraction for the underlying link technology selection. That abstraction, in whichever form,
should present itself to the application as a constantly available communications link without imposing unnecessary
adaptations on the application.
Several such protocols already exist, which each come with their own set of drawbacks.
4.6.1 TCP Extensions for Multipath Operations (MPTCP). MPTCP is a standard [
14
] [
20
] extension to the TCP protocol,
which bundles and orchestrates distinct TCP paths.
One of the features of TCP is that it is connection oriented, which means that implementations maintain state on the
relationship between physical interfaces and TCP sessions. As a packet belonging to a TCP session gets received on an
interface, an implementation will try and use the same interface for routing outbound packets of the same session. This,
then, forms a TCP path from source to destination.
MPTCP allows machines to advertise other IP addresses they communicate on to peers, adding a number of (potential)
paths for MPTCP to join into a single virtual session.
While MPTCP thus provides for the multipath capabilities one might wish for, it is the fact that it is an extension to
TCP that is less helpful, as TCP itself has characteristics not ideally suitable to the use-case.
Buerbloat. One is that TCP mandates not only recovery of lost packets, but also strict ordering – streaming
operations, in other words. A receiving application cannot read packets from the receive buer if a previous packet has
been lost. Attempts at recovery are made, and the session either terminates or continues depending on whether the
packet is recovered.
In order to increase reliable re-sends and recovery, the standard solution in TCP is to increase the size of send and
receive buers.
Where this serves the goal of presenting a consistent data stream to the receiver, it makes the reaction time of
the application to packet loss conditions highly dependent on the receive and send buer sizes. In order to increase
reliability, the standard solution in the past has been to increase these buers in size in a phenomenon known as
buerbloat [15], further decreasing responsiveness.
TCP Meltdown. At the same time, the reliable re-send mechanism makes TCP unsuitable for tunnelling TCP itself,
and thus not a good choice for a general purpose virtual link.
Under packet loss conditions in a TCP-over-TCP tunnel, both TCP layers will try to recover lost packets, leading to
an eect dubbed the TCP meltdown problem [22].
6
Reliable C3Links for UAS HiPEAC 2021, Jan 18, 2021, Budapest, Hungary (virtual event)
Out-of-Band Communications. The other issue TCP inadvertently introduces is that it precludes high priority out-of-
band message transmission. Such messaging will however be particularly necessary for C
3
links when a UAV faces
unplanned conditions, such as obstacles on its planned ight path.
Miscellaneous Issues. Other issues around MPTCP focus more on its implementation in Linux. The Linux kernel,
however, is used to maintain the reference implementation of the protocol, which other implementations largely
emulate.
TCP and MPTCP reference implementations on Linux are implemented in-kernel, reducing the speed at which
development can take place for purely practical purposes.
MPTCP discovers new links when a Linux data link layer device comes into existence – which can be a long
time, relatively speaking, after the underlying communications module has established a connection.
The MPTCP standard propose scheduler classes that essentially treat every link equally. Real reliability benets
will be made when other link information, as discussed previously, inuence packet scheduling.
4.6.2 Stream Control Transmission Protocol (SCTP). SCTP is an attempt at addressing the strict sequencing requirements
in TCP. As it happens, SCTP also includes a multipath feature, here called multi-homing.
SCTP allows applications to decide whether to have a connection operate in datagram or stream mode, and even
introduces a reliable mode without strict packet ordering.
Where SCTP fails to provide ideal conditions is in threat mitigation (see subsection 4.7).
4.6.3 QUIC. QUIC may be best known as the proposed newest instalment in the HTTP family of protocols. One of its
dening characteristics, however, is that it is UDP-based instead of relying on TCP. In order to still transport data as
expected of an HTTP protocol, it introduces many of the reliability features of TCP, albeit at a higher OSI level and in
userspace.
This makes QUIC signicantly more accessible for research purposes. However, QUIC inherits the same strict
sequencing concept from TCP, and therefore some of the same issues.
An extension to QUIC for Multipath [12] is currently undergoing the RFC draft process.
4.7 Threat Mitigation
As previously discussed, standards for safe communications in other application areas such as IEC 62280 [
11
] outline
specic threats against safe communications, as well as a set of mitigation techniques to address them.
While the current area of research for AnyWi is not focused on implementing these mitigation techniques, they
nevertheless must be considered in order not to introduce new obstacles to their later adoption.
One subset of threats including deliberate tampering is best addressed by cryptographic mitigation techniques.
Unfortunately, existing cryptographic protocols introduce issues that conict with other safety requirements, in
particular the ability to send high priority out-of-band messages.
4.7.1 Transport Layer Security (TLS). TLS is the default protocol on the world wide web for security HTTP connections,
and through the widespread use of this technology stack has reached a high level of maturity in securing network
connections.
As a highly used protocol, it is also the most prominent target of attacks. Over the years, a number of aws have
been discovered and addressed in TLS, which only serves to improve its safety.
7
HiPEAC 2021, Jan 18, 2021, Budapest, Hungary (virtual event) Finkhäuser, Larsen
The downside of TLS lies not in its features or maturity, but in its use-case. It started life as SSL as a layer between
plain, unencrypted TCP sockets and the higher level HTTP protocol. As such, it is inherently stream oriented, and
cannot be used with datagram oriented protocols.
The issue here is that TLS uses cryptographic stream ciphers to secure communications, and therefore fundamentally
relies on the underlying TCP protocol’s ability to deliver packets in strict sequence.
While TLS has many other applications, its requirement on stream operations of its underlying protocol does not
change. It cannot, for example, secure the datagram mode of operation for SCTP.
4.7.2 Datagram TLS. Of course, that issue is well understood, and a datagram variant of TLS [
21
] also exists. Currently
still in version 1.2, the 1.3 revision is undergoing the RFC draft process.
Datagram TLS does not work with stream ciphers, and encrypts every datagram individiually, marking the biggest
change to its streaming counterpart.
It is also worth pointing out that DTLS maintains a window of valid packet numbers. Any packet with a sequence
number inside the window will be processed, packets outside the window are discarded. Amongst other things, this
prevents replay attacks.
The window is also tied to negotiated cryptographic parameters, though, which means that under some conditions,
when the safety of the communications can no longer be guaranteed, DTLS requires peers to perform a new handshake
and start over.
This is not a problem in the general application space – but when packet loss conditions induced by bad radio link
quality or a similar underlying issue cause a new handshake, recovery of the communications link relies heavily on this
handshake being very light weight.
Here, DTLS has a dierent focus. Because it assumes peers know nothing about each other when connecting, it
species a fairly heavy weight handshake protocol, exchanging certicate data that may even span several datagrams.
Losing any of those datagrams leads to the handshake not completing and re-starting.
While the situation is far less dire as with a TCP meltdown, DTLS still is not ideally suited to providing reliability in
precisely the conditions UAS face during a link handover scenario.
4.7.3 Wireguard. A relative newcomer to the encryption protocol scene is Wireguard. Conceived as a secure tunnelling
protocol between networking sites, it cannot be easily applied to the problem of UAVs handing over control between
base stations. Aside from leaving the initial key sharing problem open, as it is easily solved by out-of-band methods
when securely connecting remote networking sites, it also requires static IP address for establishing a communications
link that are not present in roaming devices such as UAV.
It does, however, provide an extremely light-weight encrypted tunnel. In particular, as its assumptions are wholly
dierent from DTLS, it can reconnect machines using a single round trip, and therefore serves as good inspiration for
addressing DTLS’ handshake issue.
The conclusion to this brief look at encryption protocols is that they do not full all requirements for reliable
handover scenarios. Focusing on datagram delivery for guaranteeing the ability for out-of-band messaging will exclude
the use of TLS, but at least leaves room for innovation in that area.
8
Reliable C3Links for UAS HiPEAC 2021, Jan 18, 2021, Budapest, Hungary (virtual event)
4.8 Other Communications
Finally, it is worth noting that not all communication links present themselves the same way to the system. Since some of
the safety requirements push possible solutions into a space where link technologies are best treated as message-oriented,
point-to-point channels, we can consider also other means of establishing communications with remote peers.
A unifying characteristic of network protocols is that in some senses, data link and transport layers work like a bus,
in that point-to-point communications are established by addressing each peer according to the needs of the layer –
whether that is an Ethernet MAC address, an IP address, or an additional TCP port. Other bus-type systems such as
USB t the abstract model.
In contrast, point-to-point connections such as serial/UART links do not require peer addressing, but can also be
considered message-oriented.
A good multipath protocol should remain applicable also to routing over non-networking channels.
5 SYSTEM DESIGN & ARCHITECTURE
The technical challenges outlined in the previous section lead to the conclusion that a robust multipath protocol suitable
for fast handover between black channel wireless communications modules is currently missing. Such a protocol
must make provisions for expected safety regulations in the application space of commercial UAS. Finally, the protocol
handover must be managed utilizing link availability and quality data that can only be accessed when breaking strict OSI
layering. Any such abstraction leakage should be minimal and purposeful in order to avoid getting lost in undesirable
complexity in a way that the OSI model of layering intends to address.
By providing an opaque virtual IP link to the application layer in the form of a multipath "tunnel", we can support
both reliable, in-sequence modes of operation for the application as well as high-priority messaging in parallel. All the
application layer needs to do is employ standard socket communications, choosing between stream (TCP) or datagram
(UDP) modes of operation, or a mixture thereof (SCTP).
Additional safety measures targeting threats to message integrity can be layered atop such a tunnel, with some
restrictions applying to the use of typical encryption protocols. Future work can focus on embedding such measures
into the tunnel protocol without disrupting these modes of operation.
5.1 Component Architecture
In a data stream between an aircraft and ground based system (left and right sides of Figure 2 respectively), data passes
into a multipath network gateway. A scheduler component decides packet-by-packet which established link to use
for sending a packet, possibly multiplexing across several links simultaneously. At the receiver side, a concentrator
component re-assembles the data stream before passing it on to the ground station. Underlying link technologies may
themselves provide an IP-based communication protocol; for avoiding the TCP meltdown scenario, packets sent across
these links will be encapsulated in UDP datagrams. This also avoids TCP session negotiation.
Apath manager component provides the oversight in this operation. Using link availability data from link discovery,
and link quality data from both the underlying communications module rmware as well as from a quality feedback
loop in the tunnel protocol, it establishes for the scheduler component which links provide the best tradeo of
characteristics at any given time.
9
HiPEAC 2021, Jan 18, 2021, Budapest, Hungary (virtual event) Finkhäuser, Larsen
Link quality
feedback loop
Flight status message,
e.g. position
Ground-based
backend system
(e.g., flight monitoring
or management
system)
Local IP
network
and
internet
Mobile operator 1
Mobile operator 2
Satellite operator
Local WiFi
Multipath network
gateway for IP trac
with intelligent path
management and
scheduler
Network
trac
concen-
trator
Re-combined from
concentrator
Dedicated technology,
e.g., C-V2X, WiFi-p, ADS-B, etc.
Outgoing data trac
Flight status
message ground
station
Non-IP trac
Path manager:
Discovers and manages paths to the ground. These
will become links for the scheduler
Scheduler:
Decides
packet per
packet which
link to use
Link availability data
Scheduler
API
Fig. 2. Components in multipath UAS communications
As both path manager and scheduler are participating in the decision making, it is worth highlighting the time
frames on which they operate, as that helps separate their respective roles. scheduler must make its decisions with
sub-millisecond precision to sustain high data transmission rates, such as for C
3
links streaming real-time camera data.
By contrast, the specics of individual communication modules do not permit path manager the same speed. Cell
selection in LTE networks, for example, may require 30-60 seconds, implying that hand-over must be scheduled well in
advance of the scheduler becoming aware of an available link to utilize.
5.2 System Design
From a system design point of view, there are two possible entry points for applications to utilize such a communications
stack. On the one hand, applications can connect to the system via a socket-like API; this could in fact be a local socket
as illustrated in Figure 3. While such an API could provide higher exibility of use, it also requires applications to
specically integrate with this communications stack.
For reasons of general applicability, it is likely preferable to provide a TUN device that channels all trac through
the reliable communications system. A default route to the device would suce to ensure that any application benets
from enhanced reliability.
The gure also illustrates the APIs utilized by the dierent components, including those from external sources such
as from a potential QoS estimator, etc.
5.3 APIs
The design highlights the need for three distinct APIs.
5.3.1 Connection Management. AConnection Management API provides an interface between path manager and
scheduler. This API is strictly speaking internal to the system. However, exposing it as an explicit API helps delineate
10
Reliable C3Links for UAS HiPEAC 2021, Jan 18, 2021, Budapest, Hungary (virtual event)
Technology
Providers
Software
Architecture
Level
Multi-path gateway
functionality for reliability
Supporting
Technology
Fig. 3. Architectural layers of the multipath communications stack
the responsibilities of the two connected components, and allows for the use of dierent technologies and programming
languages or indeed independent innovation cycles for both.
5.3.2 Link Discovery. Figure 3 illustrates the ow of information back from other components to the path manager
using a "Connection data" label. This connection data comes from dierent sources, and really comprises two distinct
areas of concern. The Link Discovery API is used to further modularize the concerns of path manager into discovering
available connections as distinct from the decision making processes yielding the Connection Management API data.
11
HiPEAC 2021, Jan 18, 2021, Budapest, Hungary (virtual event) Finkhäuser, Larsen
5.3.3 ality of Service. Finally, a ality of Service API can be employed by various components to report link
reliability information to the path manager: this can come from information gleaned from wireless module rmware,
or from an external QoS estimator. Finally, the tunnel protocol itself can provide its own measurement of actual link
reliability to path manager.
5.4 Conclusion
AnyWi has been commercially providing gateways for reliable communications for a number of years, targeting
predominantly naval trac. We have further applied this experience to research in the automotive industry, and now
also to UAS. This work has led to the presented understanding of both the regulatory requirements as well as existing
technical challenges. It is our view that implementing the proposed architecture and multipath protocol forges a path
towards reliable Command, Control and Communications links in Unmanned Aerial Vehicles.
ACKNOWLEDGMENTS
This work has received funding from the ECSEL Joint Undertaking (JU) under grant agreement 826610 (https://cordis.
europa.eu/project/id/826610). The JU receives support from the European Union’s Horizon 2020 research and innovation
programme and Spain, Austria, Belgium, Czech Republic, France, Italy, Latvia, Netherlands.
REFERENCES
[1] [n.d.]. ADACORSA - Airborne data collection on resilient system architectures. https://cordis.europa.eu/project/id/876019
[2]
[n.d.]. COMP4DRONES - Framework of key enabling technologies for safe and autonomous drones’ applications. https://cordis.europa.eu/project/
id/826610
[3] freedesktop.org [n.d.]. ModemManager. freedesktop.org. https://www.freedesktop.org/wiki/Software/ModemManager/
[4] 3rd Generation Partnership Project. [n.d.]. 3GPP Specication Set: 5G. https://www.3gpp.org/dynareport/SpecList.htm?release=Rel-15&tech=4
[5]
European Union Aviation Safety Agency. 2020. EASA Opinion 01/2020. https://www.easa.europa.eu/document-library/opinions/opinion- 012020
[6] LoRa Alliance. [n.d.]. LoRa Alliance LoRaWAN Specications. https://lora-alliance.org/about- lorawan
[7] WiFi Alliance. [n.d.]. WiFi Alliance Specications. https://www.wi-.org/discover-wi-/specications
[8]
Cristina Barrado, Mario Boyero, Luigi Brucculeri, Giancarlo Ferrara, Andrew Hately, Peter Hullah, David Martin-Marrero, Enric Pastor, Anthony Peter
Rushton, , and Andreas Volkert. 2020. U-Space Concept of Operations: A Key Enabler for Opening Airspace to Emerging Low-Altitude Operations.
https://www.mdpi.com/2226-4310/7/3/24/htm
[9]
Leisha Bell, Stan Mackiewicz, Lowell Foster, Tausif Butt, Marty Bailey, Ric Peri, Mike Lenz, Tom Glista, Pat Mullen, Walter Desrosier, Paul Nguyen,
Rick Baldwin, Peter L. Rouse, Arnold Spinelli, Dr. Bill Johnson, Barry Ballenger, Eli Cotti, Bog Stegeman, Gerald Baker, Jerey S. Gruber, Greg
Bowles, Cora Byrd, H. G. Frautschy, David Kenny, J. J. Greenway, Dennis Beringer, and James Brady. 2009. Part 23 - Small Airplane Certication
Process Study. https://www.faa.gov/about/oce_org/headquarters_oces/avs/oces/air/directorates_eld/small_airplanes/media/CPS_Part_23.pdf
[10]
International Electrotechnical Commission. 2010. IEC 61508: Functional safety of electrical/electronic/programmable electronic safety-related systems.
https://webstore.iec.ch/publication/5515
[11]
International Electrotechnical Commission. 2014. IEC 62280: Railway applications - Communication, signalling and processing systems - Safety related
communication in transmission systems. https://webstore.iec.ch/publication/6749
[12]
Quentin Coninck and Olivier Bonaventure. 2020. Multipath Extensions for QUIC (MP-QUIC). Internet-Draft draft-deconinck-quic-multipath-06. IETF
Secretariat. http://www.ietf.org/internet-drafts/draft-deconinck-quic- multipath-06.txt http://www.ietf.org/internet-drafts/draft- deconinck-quic-
multipath-06.txt.
[13] Joint Authorities for Rulemaking on Unmanned Systems. 2020. Joint Authorities for Rulemaking on Unmanned Systems. http://jarus-rpas.org/
[14]
A. Ford, C. Raiciu, M. Handley, O. Bonaventure, and C. Paasch. 2020. TCP Extensions for Multipath Operation with Multiple Addresses. RFC 8684. RFC
Editor. https://tools.ietf.org/html/rfc8684
[15]
Jim Gettys and Kathleen Nichols. 2012. Buerbloat: Dark Buers in the Internet. Commun. ACM 55, 1 (Jan. 2012), 57–65. https://doi.org/10.1145/
2063176.2063196
[16] ICAO. [n.d.]. UTM Guidance. https://www.icao.int/safety/UA/Pages/UTM-Guidance.aspx
[17] American National Standards Institute. 2011. EN 50159:2011. https://webstore.ansi.org/Standards/ON/OVEONORMEN501592011
[18]
European Telecommunications Standards Institute. [n.d.]. Universal Mobile Telecommunications System (UMTS); User Equipment (UE) procedures
in idle mode and procedures for cell reselection in connected mode (3GPP TS 25.304 version 16.0.0 Release 16). https://www.etsi.org/deliver/etsi_TS/
12
Reliable C3Links for UAS HiPEAC 2021, Jan 18, 2021, Budapest, Hungary (virtual event)
125300_125399/125304/16.00.00_60/ts_125304v160000p.pdf
[19] Dan Johnson. 2012. The cost of certication. https://generalaviationnews.com/2012/09/09/the- cost-of-certication/
[20] C. Paasch and S. Barre et al. [n.d.]. Multipath TCP in the Linux Kernel. http://www.multipath-tcp.org
[21]
Eric Rescorla, Hannes Tschofenig, and Nagendra Modadugu. 2020. The Datagram Transport Layer Security (DTLS) Protocol Version 1.3. Internet-Draft
draft-ietf-tls-dtls13-39. IETF Secretariat. http://www.ietf.org/internet-drafts/draft- ietf-tls-dtls13- 39.txt http://www.ietf.org/internet-drafts/draft-
ietf-tls- dtls13-39.txt.
[22] Olaf Titz. 2001. TCP Meltdown: Why TCP Over TCP Is A Bad Idea. http://sites.inka.de/~W1011/devel/tcp-tcp.html
13