Re: [Drip] ADSB

[Robert Moskowitz <[e-mail]>]

On 8/5/20 8:13 AM, Alexandre Petrescu wrote:
>
>
> Le 05/08/2020 à 13:41, Robert Moskowitz a écrit :
>>
>>
>> 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
>
> I looked at some of the slides of 802.15.16th of presentations in 
> July, 2020.
>
> The best I could understand is this:
>   "The IEEE 802.15.16t Task Group is developing an amendment to
>    802.16-2017. Project 802.16t “Amendment - Fixed and Mobile Wireless
>    Access in Narrowband Channels” This project specifies operation in
>    licensed spectrum with channel bandwidths greater than or equal to 5
>    kHz and less than 100 kHz. A new PHY will be specified, with changes
>    to the MAC as necessary. The amendment is frequency independent but
>    focuses on spectrum less than 2 GHz. Aggregated operation in adjacent
>    and non-adjacent channels will be supported."
>
>> 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.
>
> I see, that's why.
>
> So, the question that could be made to 802.15.16t is: would the new 
> 802.16 (the one including 802.15.16t) consider drones and their 
> identification as a potential use-case?  If yes, would the new 802.16 
> like to use IP to carry the drone identification?  Or would the new 
> 802.16 rather carry the drone identification in a new 802.16 header 
> that sits below IP?
>
>> 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.
>
> Fair enough.
>
> There would be however some differences between carrying drone 
> identification numbers by Bluetooth headers or by 802.16 headers.   
> IEEE and Bluetooth SIG made different formats.

Where do you see in any of the DRIP documents that the proposed Remote 
ID numbers are carried in the Bluetooth headers?

In the Basic ID Message, the Remote ID IS the payload.  Look at Adam's 
slide 8 where he lays out the BT frame content for ASTM. There are 19 
bytes of BT header and 25 bytes for ASTM content.  In the Basic ID 
Message, 20 of those 25 bytes are the Remote ID.

Now where the BT header (4, 5, and even WiFi) comes in to play is that 
the RID is ONLY in the Basic ID message and some Authentication Message 
payloads.  So to determine which messages are from which UA, the MAC 
address is used as the value to link all messages from a UA to its RID.

This is spelled out in the ASTM standard, and perhaps it should be 
restated in the drip-arch and drip-uas-rid drafts (actually I do think 
it is in there somewhere).

> If one wanted a unique format for drone identification to be 
> transmitted on all these link layers similarly, one would need to use 
> IP.  IP sits ok on both 802.16 and on Bluetooth.

No, you don't need IP.  Or you have to pay the cost of IP on media where 
it is very expensive.

>
> Alex
>
>>
>>>
>>> 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" 
>>>> <[e-mail] on behalf of [e-mail]> 
>>>> 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 <[e-mail]> on behalf of "Stuart W. 
>>>>> Card" <[e-mail]> *Date: *Wednesday, July 29, 2020
>>>>>  at 19:46 *To: *"[e-mail]" <[e-mail]> *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 [e-mail] 
>>>> https://www.ietf.org/mailman/listinfo/tm-rid
>>>>
>>>
>>
>> -- 
>> 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
>

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