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

[Robert Moskowitz <[e-mail]>]

On 4/12/22 12:17, [e-mail] wrote:
> 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.

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.

>
> Dominique
>
> -----Original Message-----
> From: Robert Moskowitz [mailto:[e-mail]]
> Sent: 12 April 2022 17:44
> To: BARTHEL Dominique INNOV/IT-S <[e-mail]>; Olivier Gimenez <ogimenez=[e-mail]>; lp-wan <[e-mail]>
> 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, [e-mail] wrote:
>> 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:[e-mail]] On Behalf Of
>> [e-mail]
>> Sent: 12 April 2022 14:55
>> To: Robert Moskowitz <[e-mail]>; Olivier Gimenez
>> <ogimenez=[e-mail]>; lp-wan <[e-mail]>
>> Subject: Re: [lp-wan] Want to talk to LoRa knowledgeable person(s) for
>> use for unmanned aircraft
>>
>> 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:[e-mail]]
>> Sent: 11 April 2022 14:48
>> To: BARTHEL Dominique INNOV/IT-S <[e-mail]>;
>> Olivier Gimenez <ogimenez=[e-mail]>; lp-wan
>> <[e-mail]>
>> Subject: Re: [lp-wan] Want to talk to LoRa knowledgeable person(s) for
>> use for unmanned aircraft
>>
>> 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:
>>> On 4/11/22 03:42, [e-mail] wrote:
>>>> 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?
>>> I was a bit sloppy, perhaps, as I did not know enough to use the
>>> proper terminology.  It would be LoRaWAN.
>>>
>>>> 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.
>>> 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!
>>>
>>>> Best regards
>>>>
>>>> Dominique
>>>>
>>>> -----Original Message-----
>>>> From: lp-wan [mailto:[e-mail]] On Behalf Of Olivier
>>>> Gimenez
>>>> Sent: 11 April 2022 09:16
>>>> To: Robert Moskowitz <[e-mail]>; lp-wan
>>>> <[e-mail]>
>>>> Subject: Re: [lp-wan] Want to talk to LoRa knowledgeable person(s)
>>>> for use for unmanned aircraft
>>>>
>>>> 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 <[e-mail]> On Behalf Of Robert Moskowitz
>>>> Sent: dimanche 10 avril 2022 04:44
>>>> To: lp-wan <[e-mail]>
>>>> 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.
>>>>
>>>> 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
>>>>
>>>> _______________________________________________
>>>> lp-wan mailing list
>>>> [e-mail]
>>>> 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.
>>>> _______________________________________________
>>>> lp-wan mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/lp-wan
>>>>
>>>> ____________________________________________________________________
>>>> _ ____________________________________________________
>>>>
>>>>
>>>> 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.
>>>>
>>>> _______________________________________________
>>>> lp-wan mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/lp-wan
>>> _______________________________________________
>>> lp-wan mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lp-wan
>> ______________________________________________________________________
>> ___________________________________________________
>>
>> 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.
>>
>> _______________________________________________
>> lp-wan mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lp-wan
>>
>> ______________________________________________________________________
>> ___________________________________________________
>>
>> 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.
>>
>> _______________________________________________
>> lp-wan mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lp-wan
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> lp-wan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lp-wan