Re: [Drip] Fwd: ADSB

[Robert Moskowitz <[e-mail]>]

Much more official read than I provided.  And trust Stu on this; 
particularly wrt sat ADS-B receivers.  I have also spoken to some of 
them.  Stu is being kind on their reaction.

On 7/11/23 09:03, Stu Card wrote:
>
> 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).
>
> 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.
>
> 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, 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.
>
> 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.
>
> Please trust me, using ADS-B for UAS RID is a _/dead issue/_ for large 
> numbers of “low-flying small UAS”.
>
> 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.
>
>
>
>