Re: [Drip] Comment on -arch-22

[Robert Moskowitz <[e-mail]>]

Jens,

Please see my draft:

https://datatracker.ietf.org/doc/draft-moskowitz-drip-secure-nrid-c2/

It specifically deals with Network RID and C2 with multiple links. Stu 
has demonstrated this over a year ago a the US Griffiths UAS test site 
in Rome NY.

Perhaps Med can pull up the URL for the video session where Stu covers this.

This is architecture.  There are a number of actual implementation 
drafts coming along at various states of readiness.

Again, I will comment more closely to your message later.  Got the 
madinas session right now, and that has specific impact to UAS.

Bob

On 3/24/22 07:36, Jens Finkhaeuser wrote:
> Hi,
>
> I am (recently) subscribed to the list, unfortunately under a 
> different email address than I selected previously.
>
> Yes, NPA-2021-14 is a good starting point. It refers to the U-SPACE 
> regulation (EU) 2021/664 which concerns itself in more detail with 
> identification. I don't think that offhand there is much conflict here 
> with the draft in principle.
>
> I am actually a little more concerned with the implications of the 
> last paragraph on page 5 referring to C2 links and the first on the 
> following page. The AMC on C2/C3 links always require mission 
> appropriate link performance; in this they provide some parameters, 
> but also refer back to ICAO regulations.
>
> At any rate, given current state of the art, it is unlikely for a 
> multi-purpose drone to carry a single link technology, but hand over 
> C2/C3 connectivity between several. This, and how this relates to 
> control hand over between different ground control stations is our 
> current research focus.
>
> Link technology and control handover tend to coincide with critical 
> phases of flight (i.e. takeoff and landing), as altitude changes often 
> trigger the need to switch links, and proximity to ground control 
> stations often require control handover. A particular challenge here 
> is posed by fixed-wing drones which can land at speeds in excess of 
> 100km/h; range and latency of RF technology clearly influence the 
> ability to switch over safely.
>
> But also BVLOS scenarios to areas not covered by conventional 3GPP 
> means (remote, offshore, in RF shadow) will require similar link and 
> perhaps control handover as BVLOS here implies beyond RF LOS.
>
> What this means is that the ASTM suggestion of e.g. Bluetooth 4 or 
> WiFi for broadcast RIDs is likely only workable to comparatively slow 
> drones. Conversely, the assumption that there is some Internet 
> connectivity provided by the C2 link is not in line with beyond RF LOS 
> scenarios - the draft acknowledges this, but seems to focus on 
> situations where Internet connectivity is given after all.
>
> Again, though, this doesn't invalidate any work done on this draft, or 
> its contents. It just raises the spectre of future work in fulfilling 
> regulatory requirements in such scenarios that are less ideal for 
> communications.
>
> I hope that clarifies my comment a little. It comes back to a question 
> of intended scope; regional scope is only one aspect.
>
> Unfortunately, I did not consider joining IETF mailing lists until 
> very recently, or I would have been able to raise this much earlier.
>
> Jens
>
> ------- Original Message -------
> On Thursday, March 24th, 2022 at 11:31, <[e-mail]> 
> wrote:
>
>> Hi Jens,
>>
>> Thank you for sharing these valuable comments.
>>
>> The intent was not to be centric but we are working under the usual 
>> volunteer-based constraints. This point was discussed early in the WG 
>> (e.g., 
>> https://datatracker.ietf.org/doc/minutes-interim-2020-drip-01-202004221100/) 
>> and this limitation was called out, e.g. (from the write-up of RFC9153):
>>
>>    Early versions of the document was largely based on the process
>>
>>    of one region (US). The WG discussed that issue at the time and
>>
>>    agreed to progress the work based on available inputs/volunteers
>>
>>    as any other IETF effort. Also, the WG agreed to record this issue
>>
>>    in an appendix. Since then, the document was enriched with inputs
>>
>>    and relevant documents from the EU region.
>>
>> For the first point, I guess you are referring to 
>> https://www.easa.europa.eu/document-library/notices-of-proposed-amendment/npa-2021-14. 
>> Right?
>>
>> If you can share more specific comments, this will help the WG and 
>> authors assess them.
>>
>> BTW, you may subscribe to the list because otherwise your messages 
>> will be delayed till a moderator validates them.
>>
>> Cheers,
>>
>> Med
>>
>> *De :* Tm-rid <[e-mail]> *De la part de* Jens Finkhaeuser
>> *Envoyé :* jeudi 24 mars 2022 10:46
>> *À :* [e-mail]
>> *Objet :* [Drip] Comment on -arch-22
>>
>> Hi all,
>>
>> since I am active through my employer in European drone research 
>> (ADACORSA and COMP4DRONES projects to name just two), and our 
>> speciality here is communications which relates to identification, I 
>> read the draft with some interest. I fear a full analysis and review 
>> would require more effort than I have managed to put into it.
>>
>> However, as a comment, it appears that the draft is very strongly 
>> related to ASTM F3411, and maybe more so than immediately apparent. I 
>> wonder how intentional that is?
>>
>> I ask for two reasons:
>>
>>  1. The EASA regulation referenced is not the most relevant, and
>>     potentially a bit out of date; consequently, it is unclear how
>>     well this proposal will work as-is in European airspace.
>>  2. The assumptions made on communications technologies seem to
>>     exclude some drone categories and use cases (which admittedly are
>>     also a source of disagreement between some of our research partners).
>>
>> I'd be happy to bring more perspectives to this, but I am not sure 
>> this is appropriate to the draft's intent.
>>
>> Jens
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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.
>
>