Re: [Drip] Fwd: ADSB

[Alexandre Petrescu <[e-mail]>]

Thanks for the clarifications.  I was not aware.

Le 11/07/2023 à 15:03, Stu Card a écrit :
>
> A few clarifications from a US perspective, but EU rules are similar…
>
> “low-flying small UAS” in the US typically means aircraft flying under 
> FAA regulations part 107 
> (https://www.ecfr.gov/current/title-14/chapter-I/subchapter-F/part-107) 
> which limits them to a total loaded (with payload and fuel) takeoff 
> weight under 55 pounds (25 kg) flying at less than 100 statute (not 
> nautical) miles per hour (161 kph) at altitudes under 400 ft (122 m) 
> Above Ground Level (AGL).
>
It sounds reasonable, but a picky person might find difficult to abstain 
from commenting:

"low-flying small UAS" of the DRIP Archi I-D is not what the FAA 
document says.  That FAA document says in the title "SMALL UNMANNED 
AIRCRAFT SYSTEMS" (sorry caps).

Maybe the I-D wants to define the term.

Maybe this I-D and other I-Ds at IETF (e.g. in TVR WG) might benefit 
from use a same unique term describing the same thing; an use-case I-D 
in TVR WG talks about 'unmanned aerial vehicles', a term that might had 
other problems.

Maybe a more US-EU definition of altitude could benefit: why prefer an 
easy to remember 400 ft but cumbersome 122 meter whereas we could prefer 
an easy to remember 150 meter but difficult 492.126 feet?  At IETF we 
could do that direction of convergence, I believe.

This altitude to these UAS is based on a few other characteristics: 
based on allowed power levels and antenna orientations, the distance of 
Bluetooth, and of 3G/4G/5G.  I noticed it myself to be in the range of 
tens of meters for one and hundreds of meters for the other (ground to 
plane).  These are fixed numbers but they are not the numbers the FAA 
document proposes.  For example, the bluetooth range is 10m or 100m, and 
the 3G/4G/5G that I tested to plane is somewhere at 450 or 500 meter, in 
some places, depending of antenna orientation.

So, if we want to come up with a number that is an approximation 
anyways, why not 400m, which is easy to remember.  And 400m is not FAA's 
122m anyways.

I wonder how they FAA came up with 122m (400 feet) ?  What gives that 
number?  Is it the range of some radio tech, or the visibility range 
with some glasses, or what?

> The FAA final rule for UAS RID 
> (https://www.faa.gov/sites/faa.gov/files/2021-08/RemoteID_Final_Rule.pdf), 
> p. 12, states in part:
>
> 4. Prohibition against the Use of ADS-B Out and Transponders This rule 
> prohibits use of ADS-B Out and transponders for UAS operations under 
> 14 CFR part 107 unless otherwise authorized by the FAA, and defines 
> when ADS-B Out is appropriate for UAS operating under part 91. The FAA 
> is concerned the potential proliferation of ADS-B Out transmitters on 
> unmanned aircraft may negatively affect the safe operation of manned 
> aircraft in the airspace of the United States. The projected numbers 
> of unmanned aircraft operations have the potential to saturate 
> available ADS-B frequencies, affecting ADS-B capabilities for manned 
> aircraft and potentially blinding ADS-B ground receivers. Therefore, 
> unmanned aircraft operators, with limited exceptions, are prohibited 
> from using ADS-B Out or transponders. The prohibition against the use 
> of ADS-B Out and transponders is discussed in section XVII of this 
> preamble.
>
> ADS-B is received by “ADS-B In” equipped aircraft, ground stations 
> (that often relay it into terrestrial networks) and satellites (that 
> downlink it into terrestrial networks). Detect And Avoid (DAA) for 
> “self-separation” (maintenance of “well clear” so there is essentially 
> no chance of collision even without needing to maneuver dramatically 
> to avoid it), as well as “collision avoidance” (where self-separation 
> has failed, well clear has been violated, and dramatic maneuver may be 
> required), may use it. ADS-B In equipped aircraft could do AirBorne 
> Detect And Avoid (ABDAA), and aircraft not so equipped could take 
> advantage of ground and/or satellite based ADS-B receivers to do 
> Ground Based Detect And Avoid (GBDAA). Thus ADS-B is very safety 
> critical. Inter alia, this means we must not overwhelm it with 
> transmissions. The numbers of uncrewed aircraft (in the millions) 
> greatly exceed those of manned aircraft.
>
> The bandwidth dedicated to ADS-B is very limited (under 4 MHz total 
> between the 2 different frequencies used by various systems). There is 
> discussion of this in various places (a quick Google yielded 
> https://aviation.stackexchange.com/questions/84876/question-about-congestion-of-the-1090mhz-frequency 
> as one decent hit) but I have not seen a proper mathematical analysis.
>

Thanks.  I did not know of that FAA rule of prohibition.  It sounds 
reasonable to impose.

It might be difficult to implement (fine someone for not abiding), but 
it is good to know.

In the future, the text might be improved, depending on user experience.


> I have spoken directly with developers of a major satellite based 
> ADS-B receiver network: they were _/terrified/_ at the prospect of 
> large numbers of small UAS transmitting ADS-B, as each satellite sees 
> ~1/3 of the earth’s surface at any given time,
>

(1/3rd. depends how high the 'sat' is: HAP, vLEO, MEO, GEO or other 
orbits shapes and altitudes)


> so unlike a ground based receiver with a horizon-limited range (thus 
> area and thus total number of transmitters at any given density), the 
> numbers of transmitters in view at once could number in the hundreds 
> of thousands or more, _/swamping/_ the receiver with collisions such 
> that essentially none of those transmissions could be demodulated and 
> decoded.
>
> ADS-B is an option for what are expected to be the much smaller 
> numbers of UAS that are larger and flying higher (at least at some 
> point in any typical flight, also typically faster), e.g. in the US 
> under FAA part 91 as noted above.
>
Ah? And bluetooth can accommodate that many devices?  I dont think so 
either.

> However, ADS-B is inherently untrustworthy and it is not obvious that 
> it can be made trustworthy while remaining backwards compatible with 
> large numbers of installed systems, as unlike ASTM F3411 it has no 
> provisions in its framing for authentication.
>
True.

There is a point however about what kind of security model (archi?) one 
thinks about these ADS-B.

It might be that, like in TV, people might appreciate a lot this ADS-B 
being insecure but visible.  No-one cares about TV broadcasts could be 
faked at radio layer, and no-one fakes them either.  For ADS-B if 
someone wants to be seen s/he turns it on, otherwise turn it off.  It's 
a different concept of security.

GPS and Galileo are insecure either, efforts are underway to secure 
them, but since too long to consider them any success.  To secure these 
things one looks to 'electronic warfare' and that is a totally different 
dimension.  Maybe no-one would like to secure ADS-B in a first place.


> Please trust me, using ADS-B for UAS RID is a _/dead issue/_ for large 
> numbers of “low-flying small UAS”.
>

Sure, I believe.

In that direction, me too I think ADS-B might be not appropriate for 
UAS, maybe because also it might be too heavy for lightweight UASs.  I 
think an ADS-B long range device might be much heavier than a bluetooth 
short-range device.

And I am not advocating its use here in this WG.

But I am looking to see maybe one day a directory of live flying 
objects, like flightradar is for ADS-B.

Alex

> But please continue to review our drafts and generally be involved in 
> DRIP! 😊
>
> *From:*Tm-rid <[e-mail]> *On Behalf Of *Alexandre PETRESCU
> *Sent:* Tuesday, July 11, 2023 8:15 AM
> *To:* [e-mail]
> *Subject:* [Drip] Fwd: ADSB
>
> (sorry, Cc'ing the list as in my first email I just wrote to Med)
>
>
>
> -------- Message transféré --------
>
> *Sujet : *
>
> 	
>
> Re: [Drip] ADSB
>
> *Date : *
>
> 	
>
> Tue, 11 Jul 2023 14:12:55 +0200
>
> *De : *
>
> 	
>
> Alexandre Petrescu <[e-mail]> 
> <mailto:[e-mail]>
>
> *Pour : *
>
> 	
>
> [e-mail]
>
> Hi,
>
> ADSB for drones is this on flightradar?
>
> https://www.flightradar24.com/EOSCUAV/3116cefd
>
> The arch draft says "For numerous technical reasons, ADS-B itself is 
> not suitable for low-flying small UAS." ?  The drone(?) in the figure 
> is at approx. 500meter altitude, that I think it is very low.
>
> Also, the arch draft says "The ADS-B is the de jure technology used in 
> manned aviation for sharing location information, from the aircraft to 
> ground " - but I think it is also used for other equipment at airport 
> that is not aircraft.  It might be used for cars (kind of, but surely 
> not flying) or trucks at airport for collision avoidance, I think.
>
>
> Alex
>
> Le 15/09/2020 à 07:48, [e-mail] a écrit :
>
>     Hi Stu, all,
>
>     I was referring to your second point. We need to have a record on
>     these matters in the arch draft.
>
>     The text shared by Stephan (thanks) is a good start.
>
>     Cheers,
>
>     Med
>
>     *De :*Tm-rid [mailto:[e-mail]
>     <mailto:[e-mail]>] *De la part de* Card, Stu
>     *Envoyé :* lundi 14 septembre 2020 16:27
>     *À :* BOUCADAIR Mohamed TGI/OLN <[e-mail]>
>     <mailto:[e-mail]>
>     *Cc :* [e-mail]
>     *Objet :* Re: [Drip] ADSB
>
>     A pointer to the freely available earlier draft of what became
>     ASTM F3411-19 was added to -reqs; is that the outcome to which you
>     refer?
>
>     Or do we want something more about how the regulators et al have
>     ruled out ADSB as a RID mechanism for low altitude small UAS?
>
>     On Mon, Sep 14, 2020 at 7:07 AM <[e-mail]> wrote:
>
>         Hi Stu,
>
>         I wonder whether the outcome of this thread was recorded in
>         the arch draft.
>
>         Please share with the WG the current status of this action point.
>
>         Thank you.
>
>         Cheers,
>
>         Med
>
>         *De :*Tm-rid [mailto:[e-mail]] *De la part de*
>         Card, Stu
>         *Envoyé :* mercredi 5 août 2020 15:20
>         *À :* BOUCADAIR Mohamed TGI/OLN <[e-mail]>
>         *Cc :* [e-mail]
>         *Objet :* Re: [Drip] ADSB
>
>         Will do.
>
>         On Wed, Aug 5, 2020, 5:13 AM <[e-mail]> wrote:
>
>             Hi Stu,
>
>             I remember that Andrei raised in the past a question about
>             the use of ADB-S.. I suspect that others may make a
>             similar comment in the future.
>             Having some text in draft-ietf-drip-arch reflecting the
>             main arguments shared in this thread (by Shuai, Bob,
>             Stephan, you) will be useful.
>
>             Can you please consider adding such text to the draft?
>
>             Thank you.
>
>             Cheers,
>             Med
>
>             > -----Message d'origine-----
>             > De : Tm-rid [mailto:[e-mail]] De la part
>             de Stuart W.
>             > Card
>             > Envoyé : mardi 4 août 2020 19:12
>             > À : [e-mail]
>             > Objet : Re: [Drip] ADSB
>             >
>             > The proposed manifest and other DRIP authentication
>             related structures
>             > are all independent of transport, but designed to work
>             with the most
>             > constraining transport thus specified by regulators
>             and/or other SDOs,
>             > that being ASTM F3411 Broadcast RID over Bluetooth 4.
>             >
>             > So, for Broadcast RID, they would be encapsulated in
>             ASTM F3411
>             > messages over Bluetooth 4, Bluetooth 5 or WiFi Neighbor
>             Awareness
>             > Networking (without IP).
>             >
>             > For Network RID, they could be carried in any IP based
>             transport,
>             > HTTPS/TCP/IP initially (although, for Network RID, some
>             of them are
>             > superfluous).
>             >
>             > On 8/4/2020 11:27 AM, Alexandre Petrescu wrote:
>             > > Thanks for the clarification.
>             > >
>             > > Le 04/08/2020 à 17:17, Stuart W. Card a écrit :
>             > >> I just want to respond to one line that I think comes
>             from
>             > confusion:
>             > >>
>             > >>> But if we have reluctance about the use of ADS-B,
>             and thus of IP,
>             > >>> and we recommend Bluetooth-without-IP to identify drones
>             > >>
>             > >> We aren't recommending Bluetooth-without-IP, we are
>             _supporting_
>             > it,
>             > >
>             > > But, the security manifest that I have seen on slides
>             during the
>             > > presentation of the DRIP WG meeting - is something
>             below IP, right?
>             >
>             >
>             > --
>             > -----------------------------------------
>             > Stuart W. Card, PhD, Principal Engineer
>             > AX Enterprize, LLC www.axenterprize.com
>             <http://www.axenterprize.com>
>             > 4947 Commercial Drive, Yorkville NY 13495
>
>
>             _________________________________________________________________________________________________________________________
>
>             Ce message et ses pieces jointes peuvent contenir des
>             informations confidentielles ou privilegiees et ne doivent
>             donc
>             pas etre diffuses, exploites ou copies sans autorisation.
>             Si vous avez recu ce message par erreur, veuillez le signaler
>             a l'expediteur et le detruire ainsi que les pieces
>             jointes. Les messages electroniques etant susceptibles
>             d'alteration,
>             Orange decline toute responsabilite si ce message a ete
>             altere, deforme ou falsifie. Merci.
>
>             This message and its attachments may contain confidential
>             or privileged information that may be protected by law;
>             they should not be distributed, used or copied without
>             authorisation.
>             If you have received this email in error, please notify
>             the sender and delete this message and its attachments.
>             As emails may be altered, Orange is not liable for
>             messages that have been modified, changed or falsified.
>             Thank you.
>
>         _________________________________________________________________________________________________________________________
>
>           
>
>         Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
>         pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
>         a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
>         Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>           
>
>         This message and its attachments may contain confidential or privileged information that may be protected by law;
>
>         they should not be distributed, used or copied without authorisation.
>
>         If you have received this email in error, please notify the sender and delete this message and its attachments.
>
>         As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
>         Thank you.
>
>     _________________________________________________________________________________________________________________________
>
>     Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
>     pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
>     a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
>     Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>     This message and its attachments may contain confidential or privileged information that may be protected by law;
>
>     they should not be distributed, used or copied without authorisation.
>
>     If you have received this email in error, please notify the sender and delete this message and its attachments.
>
>     As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
>     Thank you.
>
>
>