Re: [Tm-rid] Benjamin Kaduk's Block on charter-ietf-tmrid-00-03: (with BLOCK and COMMENT)

["Card, Stu" <[e-mail]>]

Ref [2] doesn't use the word "constrained" but talks about some of the
issues, esp. around p. 13 & p. 27.

Batteries must support not only RID but also whatever the mission payload
is doing, Command & Control of the aircraft, and propulsion/lift (inc. the
weight of the battery itself). Every watt of power and joule of energy is
precious.

Essentially, the constraints are: low cost, size, weight and power CPUs;
small radio antenna, rarely oriented anywhere near optimally for
communication with any given peer (due to UA flight maneuvers); the need to
support data link types now ubiquitous on deployed observer devices (WiFi,
BT5 & worst BT4, as Bob wrote); and usually no professional RF or IT staff
to keep things maintained & secure.

We can say this explicitly in our charter rather than relying on ref [2]
and general reader knowledge, but were trying to keep charter text to a
reasonable length. Ref [2] is essential background on UAS RID, which we
should retain, but perhaps we should augment it with another reference that
addresses UAS wireless networking constraints more explicitly?



On Thu, Feb 6, 2020, 06:04 Robert Moskowitz <[e-mail]>
wrote:

> Bluetooth 4 is "highly constrained".  It is extremely challenging to do
> anything with 21 byte packets in broadcast mode.
>
> Although the documents do not discuss this, many UAs use very limited
> cpus, or rather said processing power is dedicated to flight, not
> communications.  Battery life is another large constraint; additional
> processing demands for communications take away from flight time.
>
> So when you look into the UAS environment, "highly constrained".
>
> Even Bluetooth 5 with 251 bytes in broadcast messages is hard.
>
> On 2/6/20 1:27 AM, Benjamin Kaduk via Datatracker wrote:
>
> Benjamin Kaduk has entered the following ballot position for
> charter-ietf-tmrid-00-03: Block
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:https://datatracker.ietf.org/doc/charter-ietf-tmrid/
>
>
>
> ----------------------------------------------------------------------
> BLOCK:
> ----------------------------------------------------------------------
>
> W.r.t "severely constrained UAS environments [2]", I followed the reference for [2] and found
> no discussion of constrained environments, so it seems that some discussion of the nature
> of the constraints is needed in-band if [2] is intended only as a reference for "UAS environments".
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> "Network RID defines a set of information for UAS to make available globally indirectly
> via the Internet" is hard to parse ("globally indirectly"?).
>
> I don't understand what "make RIDs immediately actionable" means (along the lines of
> Magnus' Block).
>
> (As a side note, I note that [3] lists as a "minimum requirement" for both standard and limited
> remote identification UAS of "Cybersecurity" with fairly vague definition thereof, so we might
> have room to supply some more usable definition.)
>
>
>
>
> --
> Robert Moskowitz
> Owner
> HTT Consulting
> C:      248-219-2059
> F:      248-968-2824
> E:      [e-mail]
>
> There's no limit to what can be accomplished if it doesn't matter who gets
> the credit
> --
> Tm-rid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tm-rid
>