Re: [Drip] ADSB

Robert Moskowitz <rgm@labs.htt-consult.com> Wed, 05 August 2020 11:42 UTC

Return-Path: <rgm@labs.htt-consult.com>
X-Original-To: tm-rid@ietfa.amsl.com
Delivered-To: tm-rid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6009B3A1459 for <tm-rid@ietfa.amsl.com>; Wed, 5 Aug 2020 04:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.847
X-Spam-Level:
X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnPSHJbHTNbz for <tm-rid@ietfa.amsl.com>; Wed, 5 Aug 2020 04:42:16 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062543A1447 for <tm-rid@ietf.org>; Wed, 5 Aug 2020 04:42:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id CBA2762422; Wed, 5 Aug 2020 07:42:13 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id E8Hmh5bMyJvh; Wed, 5 Aug 2020 07:41:58 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.29]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 4907062416; Wed, 5 Aug 2020 07:41:58 -0400 (EDT)
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, Stephan Wenger <stewe@stewe.org>
Cc: "tm-rid@ietf.org" <tm-rid@ietf.org>
References: <1bebf5b1-1fa5-6902-5bb7-9ec3582e6d9a@andersdotter.cc> <2990FBF0-FCB0-49CE-8F4B-BF5111CE5D57@tzi.org> <01a21161-aa8d-6d4b-b384-3129fe6d799b@gmail.com> <973223fd-0119-376d-12cd-21559a14ce87@labs.htt-consult.com> <b88975b0-ecfd-3091-4314-304c36d51e8f@gmail.com> <3c632ce9-115d-11f5-ee33-bfabd4973522@labs.htt-consult.com> <f5dc0567-c9a1-a26f-b240-aead0d85c11f@gmail.com> <c9cc2ff4-c24f-f575-150b-8b978a4c2ac5@labs.htt-consult.com> <7ddd9a2f-23ba-dd82-8cfb-1d2974969e67@gmail.com> <d8cf3a43-910a-db2f-4408-184b52446c97@labs.htt-consult.com> <a288966d-d22a-d0fa-c544-ae2db7d1533e@gmail.com> <e60a44a7-a659-1937-19fb-d468c4329bb2@axenterprize.com> <A80AB482-557C-44C7-A99A-B494852D59AB@tencent.com> <f4dd60a2-da57-35d5-6467-9a4b09b3d73c@gmail.com> <CCFDD2A2-C8A6-4FAA-A058-33A58B2B7E65@stewe.org> <079a0a22-f46b-b0a7-de41-63cfb2d1574e@gmail.com>
From: Robert Moskowitz <rgm@labs.htt-consult.com>
Message-ID: <eb5626ec-c9cd-80ff-7d31-917d9b8da2ba@labs.htt-consult.com>
Date: Wed, 05 Aug 2020 07:41:54 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <079a0a22-f46b-b0a7-de41-63cfb2d1574e@gmail.com>
Content-Type: multipart/alternative; boundary="------------F464D4751F994CCFC9843FFF"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tm-rid/YPGttFS4nCByGaj8LP4NHT5Fyq8>
Subject: Re: [Drip] ADSB
X-BeenThere: tm-rid@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Drone Remote Identification Protocol <tm-rid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tm-rid/>
List-Post: <mailto:tm-rid@ietf.org>
List-Help: <mailto:tm-rid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tm-rid>, <mailto:tm-rid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2020 11:42:19 -0000


On 8/5/20 5:53 AM, Alexandre Petrescu wrote:
> Stephan,
>
> Le 04/08/2020 à 17:16, Stephan Wenger a écrit :
>> Alexandre,
>>
>> ADS-B is a 20+ year old technology and offers properties (bandwidth,
>>  security, cost) of a 20 year old technology.  That it just recently
>>  sees widespread adoption is a result of incredibly slow (even by
>> IETF standards) deployment process, and that in turn is the result of
>> the very conservative and safety conscious aviation community and 
>> regulators, as well as the high cost related to anything manmade
>> that flies.  By speculating to use ADS-B as an underlying technology
>> for IP, I fear you demonstrate a certain lack of background. The 
>> Wikipedia article on ADS-B 
>> (https://en.wikipedia.org/wiki/Automatic_dependent_surveillance_–_broadcast)
>>
>>
>>
>>
> is mostly correct, and I recommend in particular the sections on
>> "Theory of operation" and "System Design Considerations".
>
> There is no worry to fear I demonstrate lack of background in this
> field.  It is true.  I still need to learn many things here.
>
> I continue to look for a wireless link layer that is well adapted
> for communication between flying devices (drones, flying taxis) and
> ground.  And that would support very well IP.
>
> Maybe ADS-B is not that link, but Bluetooth isnt it either because too
> low power.
>
> Maybe WiFi at 5.4GHz, which also used for remote control.

I recommend you look at IEEE 802.15.16t:

http://www.ieee802.org/15/pub/TG16t.html

This is actually an addendum to 802.16.  A bit of 802 politics. 802.16 
is in hibernation.  802 EC did not want to go through the process and 
risks of reactivating it for this work.  So they turned over management 
of the work to the 802.15 leadership.

This is licensed spectrum.  The current use cases:

https://mentor.ieee.org/802.15/documents?is_dcn=DCN%2C%20Title%2C%20Author%20or%20Affiliation&is_group=016t

Does not include aviation, but so what?  Get one of the RF license 
holders in this business model and you are in business.

Some of these frequencies have the bandwidth and range for practical use 
here.

>
> That aside, let me try to answer some of the points below.
>
>> A few (of many) reasons why ADS-B is unsuitable for light drones 
>> (anything significantly smaller than a man-carrying aircraft): -24 
>> bit ICAO transponder code, limiting the number of (active or 
>> inactive) ADS-B equipment. Each modern aircraft over a certain size
>>  (except the smallest two-seaters, powered parachutes, and aircraft 
>> without electrical systems such as antiques) has a unique code 
>> assigned for its lifetime.
>
> Ok.  But MAC addresses of Bluetooth also are limited.  They have 48bit
> which is more than 24bit of ADS-B, but it is still limited.
>
>> -line-of-sight wireless connection for the "uplink" with only a few 
>> hundred ground stations for the whole US (or 70 for the whole 
>> Australia).  That means ADS-B coverage is almost everywhere only 
>> available at altitudes in which small drones are neither legal nor, 
>> in most cases, physically capable to fly (a few thousand feet in the 
>> US except near major airports where you don't want drones, 30000 ft 
>> in Australia).  Aircraft send over the uplink information such as 
>> aircraft ICAO code, aircraft type, speed, direction of flight, 
>> altitude, etc.). Information is sent in the clear, by design.  You 
>> can buy a box receiving this info, hook it up to an Raspberry PI or 
>> something, and look at the traffic near your house and send it on to 
>> your friends--in fact, this type of crowdsourced ATC info is what 
>> makes flightradar24 and similar sites work.
>
> This sounds like an argument in favor of using ADS-B for identification,
> not against.  Or maybe I dont understand.
>
> Only a few ground stations: I suspect this is around airport areas,
> which is good.
>
> ADS-B messages sent by the ground stations only to altitudes where
> drones are forbidden (I suspect above 150m or so): I dont think it is
> possible to restrict the altitude at which a message is sent to. It
> would be impossible for an ADS-B message sent by a ground station to not
> be heard at 100meters and only be heard at 200meters.  Or I do not
> udnertsand.
>
> Planes that send ADS-B messages over the 'uplink'.  I think I have to
> understand this better.  Until now I thought 'uplink' means a direction
> from ground to up in the sky.  It is a distinct meaning than networking.
>
> In networking, a smartphone has an uplink, but the base-station also has
> an uplink.  One's uplink is the other's downlink.  Compared to that, I
> thought that in ADS-B the 'uplink' is only from ground up, but it seems
> to not be so.
>
>
>> -the downlink (system to aircraft)
>
> Again, I thought the 'downlink' is from the plane down to ground.   You
> seem to say it reversely.
>
> I think the notion of 'uplink' and 'downlink' are with respect to a
> device.  A device's uplink  is the other device's downlink, when they
> communicate with each other.
>
>> is bandwidth-limited to a few hundred kbit/s for all aircraft 
>> combined in the coverage of the satellite transponder.  (This is 
>> somewhat over-simplified, as the uplink is intentionally sent in the 
>> clear, and many ADS-B receivers monitor the uplink of other aircraft 
>> for redundancy and more up-to-date information about traffic; see 
>> abive.) AFAIK, the whole continental US is covered by less than 20 
>> transponders. N The downlink carries not only traffic information
>> but also cruise and airport weather, certain airspace restrictions,
>> and so forth.  All this is broadcasted and the ADS-B receivers in
>> the aircraft need to filter out the information relevant for its 
>> position, course, and intentions.  Already, the bandwidth available 
>> is almost fully utilized to the point that the broadcast
>> occasionally needs to omit certain less-critical information to make
>> space for more critical one.  The system scales only by adding
>> satellite transponders, which is expensive and not a fine
>> granularity.
>
> I agree there might be bandwidth limitation that needs to be respected.
>
> It still is that putting an IP message on it can still work.
>
>> As for Mars, ADS-B is unsuitable until someone builds a 
>> ground-station network and has suitable satellites in orbit.
>
> YEs, the ground station would be on the rover and the satellite would
> be on one of the stations (I dont know their names) that currently hover
> above Mars routinely.
>
>> A bit closer to earth, for over-water and trans-pole operations
>> there is ADS-C, which is completely satellite based and, AFAIK, even
>> more bandwidth limited than ADS-B.  Yet another example for a network
>>  unsuitable to carry IP traffic, but I digress.
>>
>> In short, forget ADS-B for the DRIP work..
>
> Ok, if no ADS-B for DRIP work, then Bluetooth?  Is it more appropriate?
>
> Knowing that Bluetooth has a typical range of 10meter (I mean distance
> range), is it reasonable to rely on it for identifying drones at
> several hundred meters away?
>
> Knowing that Bluetooth is lower power than WiFi at 5.4Ghz, and that that
> 5.4GHz is already used to control drone flight, video, etc, is it
> preferrable to use Bluetooth instead of that WiFi at 5.4GHz?
>
> Alex
>
>>
>> Stephan
>>
>>
>> On 8/4/20, 6:53 AM, "Tm-rid on behalf of Alexandre Petrescu" 
>> <tm-rid-bounces@ietf.org on behalf of alexandre.petrescu@gmail.com> 
>> wrote:
>>
>> architectural layers discussion...
>>
>> Le 30/07/2020 à 11:49, shuaiizhao(Shuai Zhao) a écrit :
>>> Just to echo Stu on the ADSB, AFAIK, ADSB will  not be feasible
>>> for most of the drones mostly due to SwaP, commercial drones might
>>> be exception.
>>
>> It might be that ADS-B might be forbidden in drones on Earth, but
>> how about the drones on Mars? ('NASA Mars helicopters', or ESA too).
>> On Mars there would be much less such drones, so less risk of 
>> interference.
>>
>> With such a system (ADS-B under IP) one could re-use DTN (Delay 
>> Tolerant Networking) between planets, and so identify drones even on
>>  Mars.
>>
>> But if we have reluctance about the use of ADS-B, and thus of IP, and
>> we recommend Bluetooth-without-IP to identify drones, then we might
>> become too dependent on it?
>>
>> (do not get me wrong, I do like Bluetooth, but I like many other 
>> things together with Bluetooth).
>>
>> Alex
>>
>>>
>>> Best,
>>>
>>> Shuai Zhao
>>>
>>> *From: *Tm-rid <tm-rid-bounces@ietf.org> on behalf of "Stuart W. 
>>> Card" <stu.card@axenterprize.com> *Date: *Wednesday, July 29, 2020
>>>  at 19:46 *To: *"tm-rid@ietf.org" <tm-rid@ietf.org> *Subject: 
>>> *[Drip] ADSB (was: Review of draft-drip-arch-02 w.r.t. RFC6973, 
>>> RFC8280 and other)(Internet mail)
>>>
>>> Sorry for the slow reply.
>>>
>>> ADS-B is gradually being mandated for essentially all manned aircraft.
>>>
>>> ADSB-In and ADSB-Out are mandated for airliners: -In gives their pilots
>>>
>>> some Situational Awareness (SA) of other aircraft; -Out gives other
>>>
>>> pilots SA of the airliners.
>>>
>>> "ADSB-Out" is mandated even for small general aviation aircraft:
>>> it does
>>>
>>> not directly benefit the pilots of those aircraft; but by
>>> providing SA
>>>
>>> to others, it indirectly benefits all.
>>>
>>> ADSB is _not_ going to be deployed on large numbers of small UAS
>>> as it
>>>
>>> would overwhelm the limited bandwidth available at those lower radio
>>>
>>> frequencies (which propagate long ranges). In fact, it is expected
>>>  to be
>>>
>>> explicitly prohibited in the US per the FAA NPRM; I suspect most
>>> of the
>>>
>>> rest of the world will do likewise.
>>>
>>> ADSB is also altogether insecure.
>>>
>>> On 7/9/2020 3:02 AM, Alexandre Petrescu wrote:
>>>
>>> ...
>>>
>>> They call it "ADS-B Receivers" (Automatic Dependent Surveillance -
>>>
>>> Broadcast).
>>>
>>> I wouuld like to ask if there is a packet dump available showing such
>>>
>>> presence data form planes?  Maybe wireshark already supports it, maybe
>>>
>>> it even dissects it...
>>>
>>> -- 
>>>
>>> -----------------------------------------
>>>
>>> Stuart W. Card, PhD, Principal Engineer
>>>
>>> AX Enterprize, LLC  www.axenterprize.com
>>>
>>> 4947 Commercial Drive, Yorkville NY 13495
>>>
>>>
>>
>> -- Tm-rid mailing list Tm-rid@ietf.org 
>> https://www.ietf.org/mailman/listinfo/tm-rid
>>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:rgm@labs.htt-consult.com

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit