Subject: [lp-wan] Want to talk to LoRa knowledgeable person(s) for use for unmanned aircraft

From: Robert Moskowitz <[email-masked]>
Date: Sat, 9 Apr 2022 22:44:17 -0400

Greetings,

I want to get a conversation going with some people that understand, and 
perhaps operate LoRa networking.

The application is for Unmanned Aircraft Network Remote ID.

This would result in a UA sending 10 256byte datagrams per sec, maybe 
more.  And I have to work out the transmission overhead to see if it is 
possible to get this into a single LoRa datagram or if fragmentation is 
needed.  But first have to understand capacity and the like.

I have found some information, but I could easily be missing key things, 
and then there is how to package the whole thing up.

Right now Network Remote ID (N-RID) is a collection of proprietary 
protocols by some USS (Unmanned Aircraft Systems [UAS] Service 
Suppliers) for their captive UAS clients.  Typically over a 3GPP network.

EUROCAE (and some others) has called for an open standard for N-RID, and 
we are looking to tackle this in the ASTM F38.02 workgroup as the next 
work item, but I want to input some reasonable alternative than 'just 
manage these JSON messages'.

For right now I have a draft for the secure transport at:

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

I want to expand this into what the CBOR content is over CoAP over UDP 
within the secure envelope.  And then take into consideration stuffing 
this along wireless solutions like LoRa.

I look forward to your view(s).

Bob Moskowitz

---

From: Olivier Gimenez <[email-masked]>
Date: Mon, 11 Apr 2022 07:16:25 +0000

Hi Robert,

I advise you to ask on Semtech developer portal: https://forum.lora-developers.semtech.com/ or open a support ticket at https://semtech.force.com/ldp/ldp_support
For your information Semtech's chips maximum payload length in LoRa mode is 255.

Best regards
Olivier

-----Original Message-----
From: lp-wan <[email-masked]> On Behalf Of Robert Moskowitz
Sent: dimanche 10 avril 2022 04:44
To: lp-wan <[email-masked]>
Subject: [lp-wan] Want to talk to LoRa knowledgeable person(s) for use for unmanned aircraft

Warning - External Email
________________________________

Greetings,

I want to get a conversation going with some people that understand, and perhaps operate LoRa networking.

This would result in a UA sending 10 256byte datagrams per sec, maybe more.  And I have to work out the transmission overhead to see if it is possible to get this into a single LoRa datagram or if fragmentation is needed.  But first have to understand capacity and the like.

I have found some information, but I could easily be missing key things, and then there is how to package the whole thing up.

Right now Network Remote ID (N-RID) is a collection of proprietary protocols by some USS (Unmanned Aircraft Systems [UAS] Service
Suppliers) for their captive UAS clients.  Typically over a 3GPP network.

EUROCAE (and some others) has called for an open standard for N-RID, and we are looking to tackle this in the ASTM F38.02 workgroup as the next work item, but I want to input some reasonable alternative than 'just manage these JSON messages'.

I want to expand this into what the CBOR content is over CoAP over UDP within the secure envelope.  And then take into consideration stuffing this along wireless solutions like LoRa.

Bob Moskowitz

_______________________________________________
lp-wan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lp-wan

To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.

---

From: <[email-masked]>
Date: Mon, 11 Apr 2022 07:42:42 +0000

Hello Robert,

Clarification question: your question contains the term "LoRa", which is a PHY Layer technology. Do you intend to use bespoke Layer 2 framing, access control etc., or did you mean using the industry-standard "LoRaWAN" Layer 2 that has been specified by the LoRa Alliance to run over the LoRa PHY?

The appropriate forum to run your question by could differ based on the answer to the above question.

Another comment: 10 x 256 bytes per second, is this steady state or burst? If steady state, this seems a high datarate for LoRa in Europe (duty cycle limitation). You would be restricted to the fastest modulation rates, i.e. the better link qualities, not benefitting from the full LoRa long-range capability. I don't have the numbers handy, but many experts on this mailing list, including Olivier, will be able to fill in the blank. Just a note of caution, though.

I think we have got a conversation going here :-)
Best regards

Dominique

-----Original Message-----
From: lp-wan [mailto:[email-masked]] On Behalf Of Olivier Gimenez
Sent: 11 April 2022 09:16
To: Robert Moskowitz <[email-masked]>; lp-wan <[email-masked]>
Subject: Re: [lp-wan] Want to talk to LoRa knowledgeable person(s) for use for unmanned aircraft

Hi Robert,

Best regards
Olivier

-----Original Message-----
From: lp-wan <[email-masked]> On Behalf Of Robert Moskowitz
Sent: dimanche 10 avril 2022 04:44
To: lp-wan <[email-masked]>
Subject: [lp-wan] Want to talk to LoRa knowledgeable person(s) for use for unmanned aircraft

Warning - External Email

Greetings,

Bob Moskowitz

_________________________________________________________________________________________________________________________

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.

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 11 Apr 2022 08:22:46 -0400

> Clarification question: your question contains the term "LoRa", which is a PHY Layer technology. Do you intend to use bespoke Layer 2 framing, access control etc., or did you mean using the industr…

I was a bit sloppy, perhaps, as I did not know enough to use the proper 
terminology.  It would be LoRaWAN.

> Another comment: 10 x 256 bytes per second, is this steady state or burst? If steady state, this seems a high datarate for LoRa in Europe (duty cycle limitation). You would be restricted to the fas…

Quite steady state.  Of course depending on the behaviour of the UA.  Is 
it hovering or staying in a rather small 3D space?  Or is it traversing 
the coverage?  But the regulatory requirements is for the UA to 
constantly send its information to the monitoring service.  I would have 
to work out the minimum data to send.  Since this is Network and not 
Broadcast, much of the general, static, information is known.  Thus 
really only the dynamic location/vector information is really needed all 
the time (some information changes slowly, like the Operator location).  
So If only this is needed, then the Location/Vector Broadcast format is 
only 24 bytes.  This would then have to include a UDP header and either 
an ESP or DTLS wrapper plus an IPV6 header, all SCHC compressed.  
Occationally would be additional datum.

Almost all traffic is from the UA.  Occationally the other way.

Now if C2 support is added, then you might see bi-directional MavLink 
messages.

But it is this duty cycle concern that I want to get a handle on. How 
practical, for what range, is this; for what density of UA?

The HIP or DTLS security setup could initially traverse, say WiFi, and 
then migrate to the LoRaWAN link.  So the key exchange setup cost need 
not be carried by LoRaWAN.  The implications to SCHC of multilink 
support will have to be included.

> I think we have got a conversation going here :-)

Thanks!

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 11 Apr 2022 08:47:49 -0400

I left off the CoAP and CBOR layers.  :)

I remember international airmail letters of my youth where the letter 
was the envelope to save weight.  And IF you needed a second page,  it 
was written on "onion paper",  And you wrote carefully on it not to tear 
it...

On 4/11/22 08:22, Robert Moskowitz wrote:
>> Clarification question: your question contains the term "LoRa", which 
>> is a PHY Layer technology. Do you intend to use bespoke Layer 2 
>> framing, access control etc., or did you mean using the 
>> industry-standard "LoRaWAN" Layer 2 that has been specified by the 
>> LoRa Alliance to run over the LoRa PHY?
>
> I was a bit sloppy, perhaps, as I did not know enough to use the 
> proper terminology.  It would be LoRaWAN.
>
>> Another comment: 10 x 256 bytes per second, is this steady state or 
>> burst? If steady state, this seems a high datarate for LoRa in Europe 
>> (duty cycle limitation). You would be restricted to the fastest 
>> modulation rates, i.e. the better link qualities, not benefitting 
>> from the full LoRa long-range capability. I don't have the numbers 
>> handy, but many experts on this mailing list, including Olivier, will 
>> be able to fill in the blank. Just a note of caution, though.
>
> Quite steady state.  Of course depending on the behaviour of the UA.  
> Is it hovering or staying in a rather small 3D space?  Or is it 
> traversing the coverage?  But the regulatory requirements is for the 
> UA to constantly send its information to the monitoring service.  I 
> would have to work out the minimum data to send. Since this is Network 
> and not Broadcast, much of the general, static, information is known.  
> Thus really only the dynamic location/vector information is really 
> needed all the time (some information changes slowly, like the 
> Operator location).  So If only this is needed, then the 
> Location/Vector Broadcast format is only 24 bytes.  This would then 
> have to include a UDP header and either an ESP or DTLS wrapper plus an 
> IPV6 header, all SCHC compressed.  Occationally would be additional 
> datum.
>
>> I advise you to ask on Semtech developer portal: 
>> https://forum.lora-developers.semtech.com/ or open a support ticket 
>> at https://semtech.force.com/ldp/ldp_support
>> more.  And I have to work out the transmission overhead to see if it 
>> is possible to get this into a single LoRa datagram or if 
>> fragmentation is needed.  But first have to understand capacity and 
>> the like.
>>
>> I have found some information, but I could easily be missing key 
>> things, and then there is how to package the whole thing up.
>>
>> EUROCAE (and some others) has called for an open standard for N-RID, 
>> and we are looking to tackle this in the ASTM F38.02 workgroup as the 
>> next work item, but I want to input some reasonable alternative than 
>> 'just manage these JSON messages'.
>>
>> I want to expand this into what the CBOR content is over CoAP over 
>> UDP within the secure envelope.  And then take into consideration 
>> stuffing this along wireless solutions like LoRa.
>>
>> To view our privacy policy, including the types of personal 
>> information we collect, process and share, and the rights and options 
>> you have in this respect, see www.semtech.com/legal.
>> 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,
>> This message and its attachments may contain confidential or 
>> privileged information that may be protected by law;
>> If you have received this email in error, please notify the sender 
>> and delete this message and its attachments.

---

From: <[email-masked]>
Date: Tue, 12 Apr 2022 12:55:28 +0000

Hello again Bob,

You might find interesting to read a paper of ours that got published recently, which has quite a few points in common with your application.
M. Dumay, D. Barthel, L. Toutain and J. Lecoeuvre, "Effective interoperability and security support for constrained IoT networks," 2021 IEEE Global Communications Conference (GLOBECOM), 2021, pp. 1-6, doi: 10.1109/GLOBECOM46510.2021.9685592.
https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9685592
I can also provide the pdf if you need.
The paper is not specific to LoRaWAN but it has figures about message sizes for CoAP/DTLS/UDP/IPv6 after SCHC compression, for a mock tracking application.

Best regards

Dominique

-----Original Message-----
From: Robert Moskowitz [mailto:[email-masked]] 
Sent: 11 April 2022 14:48
To: BARTHEL Dominique INNOV/IT-S <[email-masked]>; Olivier Gimenez <ogimenez=[email-masked]>; lp-wan <[email-masked]>
Subject: Re: [lp-wan] Want to talk to LoRa knowledgeable person(s) for use for unmanned aircraft

I remember international airmail letters of my youth where the letter was the envelope to save weight.  And IF you needed a second page,  it was written on "onion paper",  And you wrote carefully on it not to tear it...

On 4/11/22 08:22, Robert Moskowitz wrote:
>> _____________________________________________________________________
>> ____________________________________________________
>>
>>
>> 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.
>>
>> privileged information that may be protected by law; they should not 
>> be distributed, used or copied without authorisation.

---

From: <[email-masked]>
Date: Tue, 12 Apr 2022 15:15:48 +0000

Regarding the second part of your question, i.e., the effect of duty-cycle limitations, here are a few numbers.
Time on Air for payloads of 11 bytes, 32 bytes and 64 bytes at the following spreading factors and bandwidth (EU region):
- SF7 125KHz 62 ms 92 ms 138 ms
- SF10 125KHz 371 ms 575 ms 821 ms
- SF12 125KHz 1483 ms 2138 ms 3285 ms
Most EU868 sub-bands have a duty-cycle of 1%, meaning you can transmit for 3.6 seconds every hour.
Depending on your frequency plan, you can pool together the duty-cycle of a few sub-bands.
The three PHY configurations listed above will give you line of sight ranges of at least a few km (SF7) to a 10's of km (SF12), at 14dBm transmission power.
I'll leave it to Olivier or others to complement this, I'm reaching the limits of my reliable knowledge.
Olivier also suggested you open a ticket on Semtech's developers support website, although I'd love to see the conversation happen here as well.
Best regards,

Dominique

-----Original Message-----
From: lp-wan [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 12 April 2022 14:55
To: Robert Moskowitz <[email-masked]>; Olivier Gimenez <ogimenez=[email-masked]>; lp-wan <[email-masked]>
Subject: Re: [lp-wan] Want to talk to LoRa knowledgeable person(s) for use for unmanned aircraft

Hello again Bob,

Best regards

Dominique

-----Original Message-----
From: Robert Moskowitz [mailto:[email-masked]]
Sent: 11 April 2022 14:48
To: BARTHEL Dominique INNOV/IT-S <[email-masked]>; Olivier Gimenez <ogimenez=[email-masked]>; lp-wan <[email-masked]>
Subject: Re: [lp-wan] Want to talk to LoRa knowledgeable person(s) for use for unmanned aircraft

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.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 12 Apr 2022 11:43:59 -0400

I suspect I will have to get on the Semtech support website, though I 
really struggle with those beasts...

I am NOT an RF knowlegeable person, though I have sat with these people 
at IEEE 802.11 and 802.15 meetings in the past.  I am a crypto person, 
so I deal more in raw math, compared to an RF person that is more 
dealing with physics (fun debate I had with 802.15 people in my chairing 
of 802.15.9).  Thus I need a translator :)

I rescaned the US FAA Remote ID Final Rules and a UA need only 
"broadcast the message elements at a rate
of at least 1 message per second".  At 90KPM (60MPH), that is 25MPS 
(81fps?); Ouch!  If that is a flying bomb we is dead...

But if the whole packet fits into 64 bytes (Got to look at your paper 
and other sources to figure out total size for secure 24bytes of data), 
can I get 3,600 of these messages in my allotment in that hour?  Can I 
send at a higher rate?  How many UA to a tower?

Fun stuff.

---

From: <[email-masked]>
Date: Tue, 12 Apr 2022 16:17:35 +0000

Hi Bob,

No worries, I for one need a translator when it comes to crypto :-)

I thinks we're closing in on your question.
1 message per second at 1% duty-cycle is 10 ms per message.
Using LoRaWAN in Europe, even at the fastest datarate, even with the smallest payload (*zero* bytes), the PHY and MAC headers alone will exceed the allotment.
Olivier, can you confirm that this will not fly? (pun intended)

US has different regulations, but I'm not versed well enough in them to be able to tell.

Just curious, why did you consider LoRaWAN for this application in the first place? It seems your application either needs no duty-cycle limitation *or* much higher datarates than LoRa provides.

Dominique

-----Original Message-----
From: Robert Moskowitz [mailto:[email-masked]] 
Sent: 12 April 2022 17:44
To: BARTHEL Dominique INNOV/IT-S <[email-masked]>; Olivier Gimenez <ogimenez=[email-masked]>; lp-wan <[email-masked]>
Subject: Re: [lp-wan] Want to talk to LoRa knowledgeable person(s) for use for unmanned aircraft

I suspect I will have to get on the Semtech support website, though I really struggle with those beasts...

I am NOT an RF knowlegeable person, though I have sat with these people at IEEE 802.11 and 802.15 meetings in the past.  I am a crypto person, so I deal more in raw math, compared to an RF person that is more dealing with physics (fun debate I had with 802.15 people in my chairing of 802.15.9).  Thus I need a translator :)

I rescaned the US FAA Remote ID Final Rules and a UA need only "broadcast the message elements at a rate of at least 1 message per second".  At 90KPM (60MPH), that is 25MPS (81fps?); Ouch!  If that is a flying bomb we is dead...

But if the whole packet fits into 64 bytes (Got to look at your paper and other sources to figure out total size for secure 24bytes of data), can I get 3,600 of these messages in my allotment in that hour?  Can I send at a higher rate?  How many UA to a tower?

Fun stuff.

On 4/12/22 11:15, [email-masked] wrote:
> To: Robert Moskowitz <[email-masked]>; Olivier Gimenez 
> <ogimenez=[email-masked]>; lp-wan <[email-masked]>
> To: BARTHEL Dominique INNOV/IT-S <[email-masked]>; 
> Olivier Gimenez <ogimenez=[email-masked]>; lp-wan 
> <[email-masked]>
>>> Clarification question: your question contains the term "LoRa", 
>>> which is a PHY Layer technology. Do you intend to use bespoke Layer 
>>> 2 framing, access control etc., or did you mean using the 
>>> burst? If steady state, this seems a high datarate for LoRa in 
>>> Europe (duty cycle limitation). You would be restricted to the 
>>> fastest modulation rates, i.e. the better link qualities, not 
>>> benefitting from the full LoRa long-range capability. I don't have 
>>> the numbers handy, but many experts on this mailing list, including 
>>> Olivier, will be able to fill in the blank. Just a note of caution, though.
>> would have to work out the minimum data to send. Since this is 
>> Network and not Broadcast, much of the general, static, information is known.
>> The HIP or DTLS security setup could initially traverse, say WiFi, 
>> and then migrate to the LoRaWAN link.  So the key exchange setup cost 
>> need not be carried by LoRaWAN.  The implications to SCHC of 
>> multilink support will have to be included.
>>
>>
>>> This would result in a UA sending 10 256byte datagrams per sec, 
>>> maybe more.  And I have to work out the transmission overhead to see 
>>> if it is possible to get this into a single LoRa datagram or if 
>>> and we are looking to tackle this in the ASTM F38.02 workgroup as 
>>> the next work item, but I want to input some reasonable alternative 
>>> than 'just manage these JSON messages'.
>>>
>>> information we collect, process and share, and the rights and 
>>> options you have in this respect, see www.semtech.com/legal.
>>> ____________________________________________________________________
>>> _ ____________________________________________________
>>>
>>>
>>> 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.
>>>
>>> As emails may be altered, Orange is not liable for messages that 
>>> have been modified, changed or falsified.
>>> Thank you.
>>>
> ______________________________________________________________________
> ___________________________________________________
>
> ______________________________________________________________________
> ___________________________________________________
>
> 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.
>
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 12 Apr 2022 12:46:36 -0400

> Just curious, why did you consider LoRaWAN for this application in the first place? It seems your application either needs no duty-cycle limitation *or* much higher datarates than LoRa provides.

LoRa is deployed and has some capacity, but can it work for a 'steady 
stream' 'sensor'?

802.11ah might be an alternative, but is it?

What of 802.15.16t is enhancements for 802.16; will this work and how to 
get involved?

Answer really, LoRaWAN has worked with lpwan so has a visible side to 
learn about.  These others are either, maybe in some future, or talk in 
this closed sandbox.

Looking for viable alternatives to 4G/5G.

---

From: Olivier Gimenez <[email-masked]>
Date: Wed, 13 Apr 2022 07:49:16 +0000

Hi,

As mentioned by Dominique the LoRaWAN PHY/MAC header in SF7BW125 (EU DR5)  is 47.1 ms (MAC header=13 bytes), then you have to take some liberties with LoRaWAN protocol as a device have to open two RX windows after TX, at Tx+1s and Tx+2s.

A solution might be to use 2.4 GHz where there is no duty cycle and an 11 bytes packet time on air is 10 ms, including headers.
Another possibility would be to use SCHC over LoRa (not LoRaWAN) with higher bandwidth but it would require you to define your own protocol

> I suspect I will have to get on the Semtech support website, though I really struggle with those beasts...

Semtech support staff is usually friendly ;)

Olivier

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 13 Apr 2022 16:43:07 -0400

Getting ready for Passover Holiday.  I will get over to Semtech after 
the 26th.  Somehow, I don't think this is viable.  Grumble.  I really 
want a deployed network alternative to 4G/5G.  I suspect the Lpwan SCHC 
packet to be more than 32byte, but less than 64byte.  But this is at 
least 1 packet/sec and could be more.