Subject: [Tm-rid] OpenDrone ID spec

From: Robert Moskowitz <[email-masked]>
Date: Mon, 23 Sep 2019 12:05:29 -0400

tm-rid members:

I will start this with a pointer to the current OpenDroneID spec (0.64.3):

https://www.opendroneid.org/

Code and other items are available at:

https://github.com/opendroneid

At the Symposium last week, a comment was made that this version is out 
to ballot to the ASTM members.  We have identified a few areas of 
concern on this version.  More on that later.

First, this messaging standard was developed to fit within the BT 4 
“Beacon Advertisements” which effectively limits the messages to 25 
bytes.  24 bytes are available to each OpenDroneID message.

Note that the BT 4 Beacon Advertisements include a 1 byte counter 
managed by the application (it seems).

Beacon Advertisements were chosen as these (it is claimed) are the only 
BT messages available to an application to send and receive that do not 
require pairing.  BT does not have an equivalent to IEEE 802.11OCB (at 
least for BT4).  BT4 itself was selected as the base transport to 
include the largest number of UAVs on the market.

Development platforms include:  UAVs, smartphones, tablets.

Further claimed that UAVs are in listen mode only.  These messages 
cannot be used by the ground to get specific information from the UAV.  
I have problems believing this, but will use this limit for now.

Note that BT4 has a claimed range of 300M.  At 60MPH (~90KPM), the UAV 
will cover that range in ~11sec.  Beacon range MAY be longer due to 
their short size, much like 802.11 Beacons.

Further BT5 supports 255 bytes for Beacons.  This is important to know 
when you look at the Auth message size limit.

There are 5 messages defined in this draft.  I will discuss each.

Basic ID Message

We are going to work toward adding HIT as a standard ID type, per RFC 
7401.  HHITs per draft-moskowitz-hip-hierarchical-hit will be an update 
to 7401, so I do not feel that OpenDrone spec needs to allocate a type 
for HHIT.

This message allows for 20 bytes for ID and has 3 bytes reserved.  I do 
not know anyway to authenticate this message within this limitation.  
Give me 255 bytes and much can be done!  That may be in ver 2.0.  More 
on this later.

Location/Vector Message

Stuffed into the 24 byte limit.  Nothing can be added to this message.  
The BAD thing about this message is what UAV is it from? You have a 
cluster of UAVs all sending these messages, they are close to useless.  
If any message in this spec needs lengthening, this is it.  BT does have 
a 6 byte device? address.  Perhaps they are expecting this to be used, 
but it is not called out in the spec.

Authentication Message

This is defined as a static message.  That is it never changes for a 
flight.  We are calling for it to be dynamic, and Adam has a proposal to 
use this to authenticate a group of prior messages.  The HI private key 
will be used as the sig for our Extended Auth messages.  This will be 
discussed in a separate message and one of the important outputs of this 
effort.

Self ID Message

This is text about the UAV/mission.  23 bytes is not enough for many 
uses.  We are going to recommend this (like Auth), allow for extending 
to a max of 255 bytes.  At this point we are not thinking of adding 
signing to it, rather the Extended Auth message will cover it.

System Message

Similar issues as with Location/Vector.  Plus the UPS application has 
the GCS (the UPS truck!) moving rather rapidly so no slow updates to 
content for them.

This is a quick presentation of the OpenDroneID messages.  Our initial 
focus will be to place HITs in the Basic Message, and to define an 
Extended Authentication Message that will strongly bind the HIT to a 
group of messages by using the HI private key in a signature operation.

More to follow.

Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 23 Sep 2019 12:53:06 -0400

Oh, I left as one of this group's activities is using HIP for HIT 
registry with UAV management systems (e.g. UTMs).

Bob

On 9/23/19 12:05 PM, Robert Moskowitz wrote:
> At the Symposium last week, a comment was made that this version is 
> out to ballot to the ASTM members.  We have identified a few areas of 
> Beacon Advertisements were chosen as these (it is claimed) are the 
> only BT messages available to an application to send and receive that 
> do not require pairing.  BT does not have an equivalent to IEEE 
> 802.11OCB (at least for BT4).  BT4 itself was selected as the base 
> transport to include the largest number of UAVs on the market.
>
> cannot be used by the ground to get specific information from the 
> UAV.  I have problems believing this, but will use this limit for now.
>
> 7401.  HHITs per draft-moskowitz-hip-hierarchical-hit will be an 
> update to 7401, so I do not feel that OpenDrone spec needs to allocate 
> a type for HHIT.
>
> Stuffed into the 24 byte limit.  Nothing can be added to this 
> message.  The BAD thing about this message is what UAV is it from? You 
> have a cluster of UAVs all sending these messages, they are close to 
> useless.  If any message in this spec needs lengthening, this is it.  
> BT does have a 6 byte device? address.  Perhaps they are expecting 
> this to be used, but it is not called out in the spec.
>
>
> Authentication Message
>
> flight.  We are calling for it to be dynamic, and Adam has a proposal 
> to use this to authenticate a group of prior messages. The HI private 
> key will be used as the sig for our Extended Auth messages.  This will 
> be discussed in a separate message and one of the important outputs of 
> this effort.
>
>
> Self ID Message
>

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

---

From: "Card, Stu" <[email-masked]>
Date: Mon, 23 Sep 2019 13:29:43 -0400

Actually the Unmanned Aircraft will only _transmit_, never receive, in
Broadcast Remote ID, but the effect is the same: they cannot respond to
queries that they would never hear.

On Mon, Sep 23, 2019, 12:06 Robert Moskowitz <[email-masked]>
wrote:

> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 23 Sep 2019 17:16:03 -0400

> queries that they would never hear.

That makes it hard to get freshness.

Perhaps if they were allowed to listen to some other common source (low-bits
of GPS signal, or some other signal), that could become a proxy for freshness.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 23 Sep 2019 19:19:34 -0400

Most UAV have some other interface for the GCS (Ground Comm System) to 
talk to them.  These are highly unstandardized.  Sometimes just some RF 
control commands.  So potentially they do have a source of freshness.

But in the ASTM standard, there is no need for freshness.  Oh there are 
time fields but they are in not absolute time, but and offset from 
something like start of flight time.

The Extended Auth Message we are working on (I or Adam will post that 
soon) will have a 4byte timestamp that will need some approximation to 
real time.  But there are ways for the UAV to get that before it launches.