Re: [Drip] ADSB - draft-moskowitz-drip-crowd-sourced-rid/

[Robert Moskowitz <[e-mail]>]

Alexandre,

There is no draft.  It was a student project at Embry-Riddle Aviation 
University 2 years ago.  They saw it as the "easy" part of the assignment!

I am working with a couple of the profs there (and elsewhere) to see if 
I can get them to actually do an Internet Draft on it for this fall.

On 7/18/23 04:57, Alexandre Petrescu wrote:
>
> I read the abstract of draft-moskowitz-drip-crowd-sourced-rid.
>
> Disclaimer: I will not personally going to work on this, for other 
> reasons.
>
> But I wanted to ask: we discussed about people converting between 
> other formats, presumably bluetooth formats, into ADS-B to display in 
> flightradar.  That discussion assumed a simple 1-1 conversion.  Is 
> there a draft about that? (I am asking, but I am not going to work on 
> it either for various reasons, but the question is inevitable).
>
> Alex
>
> Le 12/07/2023 à 18:04, Robert Moskowitz a écrit :
>>
>>
>> On 7/12/23 11:52, Alexandre Petrescu wrote:
>>>
>>>
>>> Le 12/07/2023 à 17:31, Robert Moskowitz a écrit :
>>>>
>>>>
>>>> On 7/12/23 11:13, Alexandre Petrescu wrote:
>>>>> thanks for the clarification I must have endeavoured in
>>>>> unchartered lands...
>>>>>
>>>>> Just to clarify: I am not disputing.
>>>>>
>>>>> I came with this thread to say that I saw ADS-B drones on 
>>>>> flightradar.
>>>>
>>>> I am sure people do it.  How they get an aircraft number might be 
>>>> interesting.  Of course some transponders are preset for this from 
>>>> what I have heard.
>>>>
>>>> Also I am away of code that takes "standard" Remote ID messages and 
>>>> feeds that into ADS-B systems.  So you see them in things like 
>>>> FlightAware, but they are NOT sending ADS-B.
>>>
>>> Interesting.  If so then flightradar might say so somewhere on the
>>> Internet.
>>
>> See my draft:
>>
>> https://datatracker.ietf.org/doc/draft-moskowitz-drip-crowd-sourced-rid/
>>
>> For harvesting RemoteID messages to feed into UTM.  Feeding into ATC 
>> is probably not a good thing, IMHO.
>>
>>>
>>>> of course you have to lie about the aircraft number,
>>>
>>> For the aircraft type, registration and country of reg.: it says 'N/A'.
>>> (for 'Not Available' I suppose - never knew what a dash had to do 
>>> there,
>>> as if it were 'Not/Available').
>>>
>>> There is no 'aircraft number' in the page, but maybe you meant 
>>> something
>>> like that.
>>>
>>> Also, even the legally carrying ADS-B aircraft sometimes dont provide
>>> some of these ADS-B fields, or are some times badly read, or badly
>>> interpreted.
>>>
>>> But I am happy to see what is there to be seen.
>>>
>>>> going from the 20 character UA ID to the 24-bit aircraft number...
>>>
>>> The 'ADS-B' drone I saw on flightradar said the 'ICAO 24-bit address'
>>> was '511161' decimal I suppose.  Is there a means to check the validity
>>> of this number?  Or to tilt to thinking it is a fake?
>>
>> I do not know if there is a way for the general public to link the 
>> 24-bit address back to anything remotely interesting.   Just have not 
>> spent time in that direction.
>>
>>>
>>>> The one effort I reviewed on this I asked this question, and they 
>>>> said the hashed the UA ID down to 24 bits...
>>>
>>> Sure, we can do anything, put random or other crazy things in there -
>>> but maybe it is not very good to play like that with these numbers.  
>>> But
>>> I will not dispute that either.  I am just happy I could see it there.
>>>
>>> If they hashed the UA ID to 24 bit for a 'standard' Remote ID of a 
>>> drone
>>> into ADS-B - would they do the same for a ground vehicle at the 
>>> airport?
>>>  Do ground vehicles at airport also likely carry 'standard' Remote IDs?
>>> (obviously ignoring vehicles have other IDs like VINs...)
>>
>> WE would like to see Trustworthy Remote ID (DRIP work) used beyond 
>> UAS!  I am working along these paths in ICAO.  Civil Aviation is 
>> pushing a PKI; FAA and EUROCONTROL are doing initial testing.  
>> Aircraft and other moving things that participate could easily have 
>> DETs to use.  WIP.
>>
>>>
>>> Alex
>>>
>>>>
>>>>>
>>>>> That's about it.
>>>>>
>>>>> Alex
>>>>>
>>>>> Le 12/07/2023 à 16:56, Stu Card a écrit :
>>>>>> The UAS RID rules are _not_ defined in this WG!
>>>>>>
>>>>>> They are defined by Civil Aviation Authorities (CAAs) in each 
>>>>>> jurisdiction, with coordination via the International Civil 
>>>>>> Aviation Organization (ICAO).
>>>>>>
>>>>>> Disputing the rules should be taken up with them, not with the 
>>>>>> DRIP WG or any part of IETF.
>>>>>>
>>>>>> Such rules are mentioned in DRIP docs only as background: 
>>>>>> motivation, context & constraints.
>>>>>>
>>>>>> Standard Means of Compliance with UAS RID rules, in turn, is 
>>>>>> mostly the province of SDOs other than IETF, primarily ASTM 
>>>>>> International. Again, disputing those standards should be taken 
>>>>>> up with those SDOs, not us.
>>>>>>
>>>>>> Only if some reference, in DRIP docs, to the rules or external 
>>>>>> standards, is factually incorrect or unclear in expression for 
>>>>>> understanding by DRIP protocol implementors, is it something we 
>>>>>> should be debating here.
>>>>>>
>>>>>>
>>>>>> Get Outlook for Android <https://aka.ms/AAb9ysg>
>>>>>>
>>>>>> ------------------------------------------------------------------------ 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>> *From:* Alexandre Petrescu <[e-mail]>
>>>>>> *Sent:* Wednesday, July 12, 2023, 10:43 *To:* Stu Card 
>>>>>> <[e-mail]>; Robert Moskowitz 
>>>>>> <[e-mail]>; Carsten Bormann <[e-mail]> *Cc:* 
>>>>>> [e-mail] <[e-mail]> *Subject:* Re: [Drip] ADSB
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le 12/07/2023 à 16:00, Stu Card a écrit :
>>>>>>> Very short answers (all for which I have time):
>>>>>>>
>>>>>>> The rules for RID are based not primarily on RF
>>>>>>> considerations, but on aviation considerations.
>>>>>>
>>>>>> hmmm... it's a principle that is reasonable and that could be 
>>>>>> debated.
>>>>>>
>>>>>> One will excuse me for not knowing precisely what are the RID 
>>>>>> rules. The RID rules are defined in this WG and I will need to 
>>>>>> look at them.
>>>>>>
>>>>>> If I look at them, one day, I will look at them from this 
>>>>>> perspective:
>>>>>>
>>>>>> For example, when RID rules say 'altitude' they should say 
>>>>>> 'altitude expressed in meters and not in feet as is currently
>>>>>> the inherited case from WWII development of aviation'.
>>>>>>
>>>>>> This kind of text could be of enormous help to implementers:
>>>>>> they simply would need to call less functions(), because less
>>>>>> need of conversions.
>>>>>>
>>>>>> It is the same when RID rules say 'heading' or 'speed', or when 
>>>>>> we talk about airport track orientation.  It should be made easy 
>>>>>> to implementer to compare a heading value in a 'heading' of a
>>>>>> UAS to that of a track. One should come up with a single common
>>>>>> way of expressing track orientation, compatible to that of RID
>>>>>> rules, instead of several and incompatible, as is the case in
>>>>>> current air flight industry.  It is because if one does that 
>>>>>> (interoperable defs of headings) then the programmer has an 
>>>>>> easier task.
>>>>>>
>>>>>> Also, about RID rules: they should say that when ASTM wants to 
>>>>>> send position and heading they should send the NMEA statements, 
>>>>>> without conversion.
>>>>>>
>>>>>> Until then, if we can not do that, we can also have a human 
>>>>>> listening to the radio airport and maneouvering locally or from
>>>>>> a distance, using an innombrable number of calculators and 
>>>>>> conversions, after having learned tomes of manuals about how to 
>>>>>> fly things.  It is basically easier.
>>>>>>
>>>>>>>
>>>>>>> Crewed aircraft _mostly_ fly above 500 feet, except during 
>>>>>>> takeoff and landing.
>>>>>>
>>>>>> I always had problems with this term 'crewed' aircraft. I noticed 
>>>>>> it also in the TVR WG, in its reverse form 'uncrewed' aircraft.
>>>>>>
>>>>>> But in reality there can be uncrewed crewed aircrafts too 
>>>>>> (Unmanned Air Mobility device, a flying taxi, does carry a
>>>>>> couple of persons on board - 'crew?', yet none of them actually
>>>>>> drives the UAM - they just signed the insurance agreement).  An
>>>>>> uncrewed aircraft is still crewed by the fact that a (group of)
>>>>>> persons on the ground is its crew (drone Reaper is such).  There
>>>>>> can also be these devices that are not crewed, are not
>>>>>> continuously driven from a ground by a crew, yet there are very
>>>>>> many eyes of people loooking at where it is going to - they're
>>>>>> pre-programmed.  These would be the true 'uncrew' aircraft even
>>>>>> though there are many crews simply looking at them. They fly at
>>>>>> more altitudes than 500 feet.
>>>>>>
>>>>>> This is why I am not sure how to use this term 'crewed aircraft'.
>>>>>>
>>>>>> But I think you meant a 200 passenger aircraft like a regular 
>>>>>> airline flight from a city to another.  Even that can be 
>>>>>> automated (crewless?) soon.
>>>>>>
>>>>>>> Small uncrewed aircraft _mostly_ fly at much lower altitudes, as 
>>>>>>> they are flown largely not to get from one place to
>>>>>>> another, but for photographing or otherwise sensing things on
>>>>>>> the ground (or for recreation).
>>>>>>
>>>>>> BEcause of this term 'crew' I can not say whether I agree or not 
>>>>>> with you.
>>>>>>
>>>>>> Instinctively, I'd say that there are so many other flying 
>>>>>> aircraft that it is hard to say so easily at which altitudes are 
>>>>>> they allowed or not, simply based on that 'crewed' qualifier.
>>>>>>
>>>>>> I think the point of view of 'crewed' vs 'uncrewed' is limited in
>>>>>> itself, leading to potentially missing some aspects.
>>>>>>
>>>>>>> The FAA has established an upper limit of 400 feet AGL for small 
>>>>>>> uncrewed aircraft flying under their rule appropriate
>>>>>>> for most such, to provide 100 feet of vertical separation from 
>>>>>>> these small UAS and where the crewed aircraft _mostly_ fly.
>>>>>>
>>>>>> I will not oppose - maybe it is sufficient for them.
>>>>>>
>>>>>> If I were to be picky, I'd say that the notion of 'AGL' itself 
>>>>>> can be subject to debate (there are several sea levels in this 
>>>>>> world and moreover they change as we speak) and if one asks why 
>>>>>> then I reply that if one would like to put NMEA statements in 
>>>>>> ASTM messages for the goal of avoiding conversions then one
>>>>>> might be facing such aspects of precisely what is a sea level.
>>>>>>
>>>>>> But I will not go to the respective SDO, so I leave it there.  I 
>>>>>> agree they set limits where they need them.
>>>>>>
>>>>>>> WRT units: yes it is a mess; no the EU does not use precisely 
>>>>>>> the metric equivalents of feet etc. in their rules; note my 
>>>>>>> original message said "EU rules are similar" not "EU rules are 
>>>>>>> the same except for translation of metric units".
>>>>>>
>>>>>> I agree, you did not say that.
>>>>>>
>>>>>>> IETF does not get to write rules for aviation, therefore neither 
>>>>>>> does IETF get to write rules for aviation communications; we can 
>>>>>>> only provide technical standards for interoperable network 
>>>>>>> protocols that _enhance_ those communications.
>>>>>>
>>>>>> It's a good thing, because enhancing communications is always good.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>>
>>>>>>> -----Original Message----- From: Alexandre Petrescu 
>>>>>>> <[e-mail]> Sent: Wednesday, July 12, 2023 
>>>>>>> 9:45 AM To: Robert Moskowitz <[e-mail]>; Carsten 
>>>>>>> Bormann <[e-mail]> Cc: Stu Card <[e-mail]>; 
>>>>>>> [e-mail] Subject: Re: [Drip] ADSB
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le 12/07/2023 à 13:56, Robert Moskowitz a écrit :
>>>>>>>>
>>>>>>>>
>>>>>>>> On 7/12/23 06:45, Carsten Bormann wrote:
>>>>>>>>> On 2023-07-12, at 11:52, Alexandre Petrescu 
>>>>>>>>> <[e-mail]> wrote:
>>>>>>>>>> why not 400m
>>>>>>>>> This is not a domain where we get to invent boundaries.
>>>>>>>>>
>>>>>>>>> (Also, generally speaking, of course we should have a strong 
>>>>>>>>> bias to using SI units, but in a domain where regulation is 
>>>>>>>>> widely based on furlongs per fortnight,
>>>>>>>>> we’ll have to adapt.)
>>>>>>>>
>>>>>>>> And anyway it would be 125M to be a bit more than the Imperial 
>>>>>>>> 400'.
>>>>>>>
>>>>>>> True.
>>>>>>>
>>>>>>> And it obviously begs the question whether in Europe they also 
>>>>>>> have the same limit of 400' equivalent in meters.  I strongly 
>>>>>>> doubt that an EU document would talk about a limit of
>>>>>>> precisely 121.92 meters just because of being converted to the
>>>>>>> easy to grasp 400 feet.
>>>>>>>
>>>>>>> At that point we talk about devices that might be different in 
>>>>>>> an EU market than in an US market.
>>>>>>>
>>>>>>> What is the EU altitude limit for numerous drone aircraft to
>>>>>>> be considered flying very low, so numerous and so low such as
>>>>>>> to be forbidden to carry ADS-B equipment (or turn it off at
>>>>>>> lower than that altitude if it carries one)?
>>>>>>>
>>>>>>>> Why 400'?
>>>>>>>>
>>>>>>>> I think it was to keep general aviation some reasonable 
>>>>>>>> distance above people on the ground.  As the ceiling for UA 
>>>>>>>> that is a consequence.
>>>>>>>
>>>>>>> You see, I think there is an error.
>>>>>>>
>>>>>>> 400 feet might be a good limit in terms of separation of
>>>>>>> people and objects above their heads, but it is certainly not
>>>>>>> any limit in terms of radio communication.
>>>>>>>
>>>>>>> If there is to be a radio communication limit (use or not use 
>>>>>>> ADS-B) it should be based on the power levels it uses and the 
>>>>>>> guarantees of range. In WiFi, bluetooth and 2G..5G that's how 
>>>>>>> they separate.
>>>>>>>
>>>>>>> For example, an 5G-carrying UAS would be limited to 450meter 
>>>>>>> altitude because that is how high the ground 5G oriented towards 
>>>>>>> ground reaches high.
>>>>>>>
>>>>>>> A bluetooth-carrying UAS (and not carrying ADS-B) would be 
>>>>>>> limited to 100 meter altitude because that is how high a 
>>>>>>> bluetooth device is allowed to emit, by bluetooth regulation.
>>>>>>>
>>>>>>>> "They can't go any lower, you can't go any higher."
>>>>>>>
>>>>>>> Strange.  Many devices, especially those who plane or glide like 
>>>>>>> these UAS drones, and helicopters too, will stay stable
>>>>>>> at very many low altitudes.  Their power systems - more and
>>>>>>> more performing, allows for that.
>>>>>>>
>>>>>>> I very well see a helicopter stable 100meter above the ground, 
>>>>>>> and surely it carries an ADS-B device, if not several of them.
>>>>>>>
>>>>>>>>
>>>>>>>> It is called boundaries to keep unequal players apart.
>>>>>>>>
>>>>>>>> One of the interesting debates in this is that the 400'
>>>>>>>> floor is to ground obstacles like radio towers. Thus since
>>>>>>>> big birds have to stay 400' from that 700' radio tower down
>>>>>>>> the block, you can take your UA up to 1100' right next to
>>>>>>>> it... Or so some claim.
>>>>>>>
>>>>>>> Right!
>>>>>>>
>>>>>>> RAdio towers, or radio towers with even higher anti-flash 
>>>>>>> ('paratonnerre', fr.) on them?  That adds some 10 meter to the 
>>>>>>> picture, to which an UAS drone would need to pay attention, just 
>>>>>>> like helicopters need to care about power lines above ground too.
>>>>>>>
>>>>>>>>
>>>>>>>> And speaking of Imperial vs Metric...
>>>>>>>>
>>>>>>>> Civil aviation separation is 1000'.
>>>>>>>>
>>>>>>>> This has already caused incidents where a lesser Metric 
>>>>>>>> distance was used by one aircraft against one using the greater 
>>>>>>>> separation of Imperial.
>>>>>>>>
>>>>>>>> Fun!
>>>>>>>>
>>>>>>>> Not.
>>>>>>>
>>>>>>> I agree.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>>
>>>>>>>> Bob
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> -- 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
>