Density-Adapting Layers towards PBN for UTM

Vincent Duchamp - Ecole Nationale de l’Aviation Civile Toulouse, France

Leonid Sedov and Valentin Polishchuk - Linköping University

Norrköping, SwedenSupport: Gouvernement de la République française. Vetenskapsrådet and Trafikverket via Swedish ANSP (LFV)

Airpsaces are like ogres

AltAlt Rule

RVSM

youtube

Levels in ATM prevail

Metropolis

Thorough investigation of several air traffic structuring concepts

● Full Mix● Layers● Zones● Tubes

Metropolis@ICRAT'18 →

Metropolis

same (# of) layers over whole ROI

Findings

Layers performed best… The Layers concept, being the most promising, definitely deserves more attention in future research

Assumption

Uniform traffic distribution (a/c equally likely anywhere in ROI)

UTM: non-uniform vehicle distribution

Expected traffic densityhow likely it is to see a drone

Population density

Likely UTM (LiU) map [S,P,Bulusu DASC'17]

This paper # of layers adapting to conflict severity

Algorithms ⇒ frequent change eg hourly updates or faster (ATM-like AIRAC cycles for AIP

too slow for dynamic UTM)

↓

Software-Defined Airspace!?

http://www.youtube.com/watch?v=zZHPtnTC6wM

VLL airspace: thin band for drones

MetropolisNASA UTM

Better now (proactively, from scratch)

than ever (retrofitting is painful, cf. ATM)

PBN4UTM: much needed - high diversity of users

need to quantify their RNP- need diverse airspaces

ConOps'es work towards these

Layers (scarce VLL resource) → performance requirements

+ less noisyimproved vertical

precision

Performance requirements

Asked for multiple times:

● Ectl RPAS ConOps○ need to define classification of drones capabilities

● CARS solution from Ectl+EASA: ○ "still requires research and validation campaigns to specify the

performance requirements of each of the airspace users and sub-systems."

● …

Some answers, e.g. [Ren, Castillo-Effen, Yu, Johnson, Yoon, Takuma, Ippolito DASC'17]

Categorization of drone PBN capabilitiesincluding the vertical performance

Our adaptive airspace design

Suggests performance needs + Relies on PBN to separate traffic classes based on their performance

PBN4UTM: long promoted [PK DASC'16 plenary, @Google, pers comm]

● encourage to adopt different regulations in different airspaces ○ incl. restrictions for drones with weaker capabilities from flying

through congested urban spaces● establish restrictions only when and where necessary

○ cruising, lanes, corridors, altitude separation ● match the geography to the required performance to operate in

the airspace

Reflected many times...

Our am

bitions

Great minds think alike

● NASA ConOps Mantras- flexibility where possible, structure only where necessary- risk-based approach where geographical needs and use cases determine the airspace performance requirements

● SESAR U-space Blueprint Key principle- follow risk-based, performance-driven approach when setting up appropriate requirements...

● FAA@UberElevate summit: - importance of performance-based regulatory regime, risk-based analysis for urban airspaces

● AirMap requirement for U-space: - to be performance-based to encourage innovation

● All 3 airspace issues identified at CORUS Exploratory Workshop:- related to height; overall view on question of airspace division into bands was that many layers should be an exception, for drone-busy areas, rather than the rule

Our solutions: ConOps → action!?

Concrete examples of possible use

areas in the city center: Amber airspaces [CORUS]? →

← segment the airspace "into cells of similar requirements"

[DLR Concept for Urban Airspace Integration] (which develops concepts to "form a basis forfurther research in the area of separationand performance-based operations for UAS")

What our methods are based on

Push off UTM probabilistic capacity thresholds [UC Berkeley + Linköping U '17]

Inspired by perfect graphs [chromatic number = max clique]

Definitions (graph, chrom #, max clique, threshold...),

technical details follow…

Model

● UAV = radius-r disk

● conflict = disks overlap

Conflict graph

● vertices = UAVs

● edge = conflicting pair

Layer assignment = Graph coloring

any edge: endpoints have different colors

colors = layers (any 2 conflicting UAVs → different layers)

chrom# of a graph =

min # of colors to color the graph

Clique = set of pairwise-connected vertices

maximal clique = can't add a vertex

Useful fact: chrom# ≥ clique size

Finding chrom# and cliques

Computationally hard (∄ fast alg to find opt); heuristics ∃

● Clique enumeration [Bron–Kerbosch]

○ complicated○ guarantees to list all cliques○ slow (exponentially many cliques)

lucky if fast● Greedy coloring [DSATUR]

○ simple and efficient○ no opt guarantee (in theory)

lucky if good result

[Michail, Kinable, Naveh, Sichi A Java library for graph data

structures and algorithms]

On drone conflict graphs: got lucky with both!

Experiments

On drone conflict graphs:

● Cliques were listed fast ● Greedy coloring: |max clique|

or |max clique| +1 colors○ proof of (near) opt!

In what follows:layers = drone cliques

Why lucky (ruminations)intuition (curiosity only)

Conflict graphs: (almost always)perfect (chrom# = |max clique|)

= no chordless odd cycle• "unlikely"

Perfect graphs: chrom#, clique are easy (efficient algs) - possible reason greedy works well

Key to demand--capacity balancing

How to match demand to capacity of resources?

● Resource = airspace (layers)● Conflict graph: a representation of demand

Know where to look in the demand (bottleneck): drone cliques in the conflict graph

How to use it to decide layers over the city?Study "geography of conflicts"

(spatial distribution of clique size)

Q1: How many layers in the city center (largest clique)?Q0: Why is it <∞ ( < N = total # of UAVs )?

UTM

● Unpredictable behaviour● Kindergarten is enough● Can takeoff from anywhere● Jammy urban GPS signal

Stochastic nature of UTMATM

● Scheduled, precalculated flights● Trained cabin crew● Can takeoff only from airport● Accurate geopositioning

Randomness is good:

● Malicious (deterministic) users could create large conflicts● Random flights "smear" conflicts (lower their prob)

○ under a "reasonable" randomness model

Cal model

● Bulusu, Sengupta, Liu (UC Berkeley "Cal") @ ICRAT'16] ● [PK (NASA Ames, CA) @ Google: "every home will have

a drone and every home will serve as an aerodrome"]

Endpoints: ~ population density

@ ∀ pt:Poisson process

intensity ~ pop density [Bulusu, Sengupta, Liu ICRAT'16]: Figure 3

VTOL, direct flights, same speed, r

Prob{conflict}?

Depends on

● r conflict radius● N expected # of flights

(traffic intensity)

P{conflict}(N,r)

● ~0 for "small" N, r hard to bump into a drone

● ~1 for "large" N, r hard to avoid a drone

What is the exact dependence?

r = 100m

Joint with UC Berkeley, IEEE SysCon'17

Prob{conflict}(N)

r = 50m

Joint with UC Berkeley, IEEE SysCon'17

Prob{conflict}(N)

r = 5...300m

Joint with UC Berkeley, IEEE SysCon'17

Prob{conflict}(r)

Joint with UC Berkeley, IEEE SysCon'17

Safe

Unsafe

MasterPlan's "drone density thresholds"?

Prob{conflict}(N,r) -- sharp 0/1 thresholds

Conflict graph: rnd geometric graph (RGG)- vertices are rnd distributed- edges defined by proximity

Deep result from RGG theory [Goel, Rai, Krishnamachari'05]:

Monotone properties have (sharp) thresholdsVery general (applies to any property)Theory: for uniformly distributed vertices

Experimental confirmation (simulation, sampling)for (highly non-uniform) drone conflict graphs

[UC Berkeley + Linköping U '17]

"Having a conflict" -- monotone property+edge → conflict "even more"

"Having a large conflict (clique)" -- monotone property

Graph propertiesMonotone: holds on+edge ("even more")

● Connectedness● Being a tree● Having edges

○ component of size >1

● Component of size >2● Component of size >3● Component of size 2● >2 comps of size 2● >2 comps of size >2● 2 comps of size 2● 2 comps of size >2● …

Prob{|clique|≥2}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥3}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥4}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥5}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥6}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥7}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥8}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥9}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥10}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥11}(N,r) -- sharp 0/1 threshold

Thresholds (for cliques) → max # of layers

For given N,r Different N, r → different (# of) layers

(Software-Defined Airspace)

Just know your thresholds (for all drone trips)

● computed once ● for the full range of● N, r, clique size

Prob{|clique|≥11}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥10}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥9}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥8}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥7}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥6}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥5}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥4}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥3}(N,r) -- sharp 0/1 threshold

Prob{|clique|≥2}(N,r) -- sharp 0/1 threshold

Thresholds: max clique = 4 for given N,r

4-clique somewhere in the city [earlier thresholds work]

4 layers over the whole city? [SP ICRAT'18]

defeat our purpose

Spatial distribution of 4-cliques- take many traffic samples- find locations of 4-cliques- 4-layer area = CH(4-cliques)

Recursively - 3-layer area = CH(3-cliques)- 2-layer area = CH(2-cliques)

(larger has negligible prob)

Results

Results

Results

r = 200 r = 300

N = 60000

N=100000

More pix: https://tiny.cc/atm_sem_pics

Extensions of CH

CH(S) = complement of all empty halfplanesTo curve out CH(S), roll a halfplane around S

S = choc chips in universe of icecreamCH(S) = what's left after choc allergic eats all icecream with knife

Extension 1/3: k-hull

k-hull(S) = complement of all halfplanes with ≤ k pts of STo curve out k-hull(S), roll a halfplane with k pts of S around S

S = choc chips in universe of icecreamk-hull(S) = what's left after choc allergic eats all icecream with cheese knife (k holes)

a.k.a. k-depth contour in statisticspts "deeper" inside S ("k-deep")statistically meaningful (sans outliers)

generalization of CHCH = 0-hull

k-hulls for k = 0, 10, 30

Extension 2/3: ɑ-hull

ɑ-hull(S) = complement of all empty ɑ-disks To curve out ɑ-hull(S), roll an ɑ-disk around S

S = choc chips in universe of icecreamɑ-hull(S) = what's left after choc allergic eats all icecream with scoop (radius ɑ)

ɑ-shape(S): straightline version of ɑ-hull(S)better conforms to "shape" of S may have >1 cluster

generalization of CHCH = ∞-hull = ∞-shape

ɑ-shape

CH

+ Avoiding restrictions

- Non-convex (re-entry possible)

Extension 1+2 / 3: k-order ɑ-hull

k-o ɑ-hull(S) = complement of all ɑ-disks with ≤ k pts of STo curve out k-o ɑ-hull(S), roll an ɑ-disk with k pts of S around S

S = choc chips in universe of icecreamk-o ɑ-hull(S) = what's left after choc allergic eats all icecream with colander (k holes, radius ɑ)

k-o ɑ-shape(S): straightline version of k-o ɑ-hull(S)combines features of k-hull and ɑ-shape(generalizes both, hence generalizes CH)

k-order ɑ-shape

+ ignores some outer pts (outliers?)

as k-hull

+ saves space (permits less equipped drones to operate in unrestricted area)

as ɑ-shape

k-order ɑ-shapes →more parsimonious than CHs

CHs↓

SummaryLayered structure

adapting to conflict severity

Algorithms ⇒ changes eg due to events

Follow ConOpses towards PBN4UTM in Software-Defined Airspace

Open questions

● name for the different-layers places

○ sectors (ATM), areas, zones

● distributing among layers optimally

○ eg min jumps between layersfor "through" flights

● managing insufficient layers (DCB)

○ eg with economic incentives? [Saez, Josefsson, D, P, Wiren DASC'19]

● study possible impact of geovectiring [Hoekstra, Ellerbroek, Sunil, Maas ICRAT'18]

○ no-fly zones, for starters