Subject: [Tm-rid] EASA drone id

From: Andrei Gurtov <[email-masked]>
Date: Wed, 6 May 2020 17:26:20 +0200

Hej,

According to EASA, in EU broadcasting drone identification will be
mandatory from July 2020. Following info will be sent in plaintext over
Wifi&bluetooth, so not privacy at all... Item V is the most controversial.

in real time during the whole duration of the flight, the direct
periodic broadcast from the UA using an open and documented transmission
protocol, of the following data, in a way that they can be received
directly by existing mobile devices within the broadcasting range:

i the UAS operator registration number;

ii the unique physical serial number of the UA compliant with standard
ANSI/CTA2063;

iii the geographical position of the UA and its height above the surface
or take-off point;

iv the route course measured clockwise from true north and ground speed
of the UA; and

v the geographical position of the remote pilot or, if not available,
the take-off point;

EASA eRules: aviation rules for the 21st century (published March 20, 2020)

https://www.easa.europa.eu/sites/default/files/dfu/Easy_Access_Rules_for_Unmanned_Aircraft_Systems.pdf

https://www.youtube.com/watch?v=VqO6uenRQdc

This site https://www.opendroneid.org/ has a nice prototype for ASTM
type drone ID transmission. I will contact them to ask put a news about
DRIP approach.

br Andrei

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 6 May 2020 12:05:13 -0400

> i the UAS operator registration number;

Is this only in the Operator-ID Message or as an alternative RID in the 
Basic Message (Type=2, CAA issued)?

The Operator-ID Message is "optional".

I will be revising draft-moskowitz-drip-operator-privacy to add this 
message.

> ii the unique physical serial number of the UA compliant with standard

We have discussed all that is wrong with this, particularly tracking 
resale and who currently owns the device.  Too much permanency.

See draft-moskowitz-drip-uas-rid

> iii the geographical position of the UA and its height above the surface

This is the Location/Vector Message.
> iv the route course measured clockwise from true north and ground speed

Again the Location/Vector Message.  Though some of this MAY be in System 
Message (optional).

> v the geographical position of the remote pilot or, if not available,

The System Message (optional).  See 
draft-moskowitz-drip-operator-privacy (I need to change "Operator" to 
"Pilot".

> type drone ID transmission. I will contact them to ask put a news about

Also point them to:  draft-moskowitz-drip-crowd-sourced-rid

We need to start planning a Hackathon?  Adam had code running at IETF106.

I would like to see someone do this on an ESP32 with Accelerometer, BT, 
and GPS.  We could strap it to a dog and track the dog (or hide it in 
someone's backpack :) )!  Much easier than tossing an phone in the air...

Any assistance we on this side of the pond can provide, let us know!

---

From: Amelia Andersdotter <[email-masked]>
Date: Thu, 7 May 2020 22:02:30 +0200

Bonjour a tous,

> Wifi&bluetooth, so not privacy at all... Item V is the most controversial.

It doesn't specify in the regulation that it needs to be sent plaintext,
actually. E.g. it doesn't say that existing receiving mobile devices
also must be able to decode them.

best regards,

Amelia

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 7 May 2020 16:16:23 -0400

> also must be able to decode them.

I am working on updating drip-operator-privacy.  Most of the cipher 
choices drop away as the Operator ID in the Operator ID Message is 20 
bytes; not a multiple of 4 bytes...

reworking the draft is a bit slow.  I was also distracted as I have 
upgraded from Fedora 30 to Fedora 32, with the usual things that don't 
work.  I am through most of those and so far only one bug report to file...

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit