Re: [Drip] ADSB

[Robert Moskowitz <[e-mail]>]

Stephan,

I would be interested in seeing the PHY and MAC specifications in DO-242 
(if they did these).

One other constraint in ADS-B is a 24 /bit/ aircraft number. 16M is 
totally inadequate for UAS ID; this would require a significant? change 
to ADS-B.  While this is likely to happen for other reasons (out of 
scope here), this is another practical limitation in considering ADS-B 
for a UAS Remote ID technology.



On 9/14/20 1:11 PM, Stephan Wenger wrote:
>
> Perhaps a para like this:
>
> For creating location information, manned aviation uses a technology 
> known as Automatic Dependent Surveillance Broadcast (ADS-B), which is 
> a ground and satellite based system designed in the early 2000s.  For 
> numerous technical and regulatory reasons, ADS-B is not suitable for 
> low-flying UAVs.  Technical reasons include a line-of-sight 
> requirement to expensive, large, (and hence scarce) ground stations, 
> the need for having onboard both a satellite receiver and 1090 MHz 
> transceiver resulting in a certain bulk and weight unsuitable for 
> small UAVs, the limited bandwidth of both uplink and downlink that, 
> while adequate for the current traffic volume of manned aviation, 
> could trivially be saturated by the use of drones and thereby 
> endangering manned aviation, and so forth.  Understanding these 
> technical shortcomings, regulators world-wide have ruled out the use 
> of ADS-B for UAS applications.
>
> We could also add a reference to RTCA DO-242 which is the technical 
> spec of ADS-B, but that document is not freely available ($250).
>
> S.
>
> *From: *Tm-rid <[e-mail]> on behalf of "Card, Stu" 
> <[e-mail]>
> *Date: *Monday, September 14, 2020 at 7:27 AM
> *To: *"[e-mail]" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *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] 
> <mailto:[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]
>     <mailto:[e-mail]>] *De la part de* Card, Stu
>     *Envoyé :* mercredi 5 août 2020 15:20
>     *À :* BOUCADAIR Mohamed TGI/OLN <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc :* [e-mail] <mailto:[e-mail]>
>     *Objet :* Re: [Drip] ADSB
>
>     Will do.
>
>     On Wed, Aug 5, 2020, 5:13 AM <[e-mail]
>     <mailto:[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]
>         <mailto:[e-mail]>] De la part de Stuart W.
>         > Card
>         > Envoyé : mardi 4 août 2020 19:12
>         > À : [e-mail] <mailto:[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.
>
>

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