LoRaWAN vs. LoRa node-to-node

Hi. I know that this group focuses on LoRaWAN and I have seen the TTN limitations and rules on the number of packets linked to this methodology that might limit the LoRa applications.
I have been developing a node-to-node application for years and it is ready to use for higher data rates now. Does anybody know if those limitations in LoRAWAN has to be applied to node-to-node cases in practice?

Thanks for your comments.

Depends where in the World you are and what frequency you using.

In the UK I would read ir-2030 to find out what the legal restrictions in the UK are and of course LoRaWAN has to follow these too.

1 Like

I looked at the document. What I conclude is: there is no difference between the two implementations either LoRaWAN or node-to-node regulations at least in the UK. This is the worst news for me! Please comment if there is any other interpretation.

If you are looking for a solution, then some detail on the use case would help.

If you want a re-interpretation of the rules, then a lawyer is probably better than someone else’s reading of the regulations.

As I see the fair access policy does not apply in private networks, but the duty cycle limitations are imposed by law. Then, maybe this is the way to go with the node-to-node high data rate applications?

As I said, almost impossible to tell as we have no idea what DR/SF/duty cycle you are using - it’s almost impossible to get sensible community support when you hold all your cards so close to your chest.

But it definitely sounds off topic for TTN

Same comparison in most parts of the world where there are legal limits. These are Radio/RF limits NOT LoRa or LoRaWAN limits. Indeed from RF perspective LoRa & LoRa can be thought one and the same. LoRaWan is an overlay of MAC & Protcol functions, Packet Structure, support headers and overall system and securit architecture etc., defined and maintained by the LoRaWAN-Alliance, built on top of the LoRa RF modulation functionality. As such the legal limts are just as applicable to LoRa as to any e.g. legacy FSK or OOK based modulation schemes etc. The only addition through this forum is that of the TTN FUP which should be followed even though not yet agressively enforced - as this is a limitation put in place to protect a shared community resource. Note many commercially available Public and Private LoRaWAN network offerings also come with (sometimes more limiting) usage restrictions to protiect their own instances, and more importantly for all to protect abuse of what is, after all, a shared and limited RF spectrum. If your use case cant fit the legal (and network policy) limits then sadly you may have to look for alternate RF technologies, in less rgidly regulated bands, to implement it. As Nick indicates if you share more details on your usecase/application it may be the shared brain of the Forumites can help you adapt and define alternate ways to use LoRaWAN (e.g. optimising payloadl/comprression etc) to meet your needs. :slight_smile:

1 Like

You can only operate within the legal constraints and they are clear enough.

There is a bit more choice of duty cycle for point to point stuff since you can use any of the allocated frequencies. Study the regs, there are frequencies that allow 100% and 10% duty cycles.

That is right. However for point to point you could look at 434 MHz as those ISM frequencies traditionally allow more airtime. (Might have changed by now)

Just a reminder for LoRaWAN enthusiasts: TTN does NOT support 434 in regions where 868 is available!

1 Like
When I started the application 4 years ago, it was defined as a LoRa-based measurement system with a 100 Hz sampling rate, it compresses the data and stores it for the time when a center/gateway requests a part of the compressed data, then transmit that part. As you know, this is better than just transmitting all the data frequently in terms of payload size and power consumption, etc. 

Recently, I added taking the photo by nodes to the scenario. In addition to monitoring, the system can do anomaly detection.
Now each node can connect to at least five sensors to store 5 series of sensory compressed data together with taking a photo (every 10 sec or so). Every node can locally analyze the data and also can transmit compressed data if requested. Meanwhile, everything in the network is under the control of the center/gateway.
The only question mark was: if the system can be commercialized as it is now? or the regulations don’t allow this, either in the form of the public/private node-to node or LoRaWAN. I use 433 MHz as allowed in my region.

You know the application so read the regs for your part of the World and work it out.

We have views, experiences, interpretations and opinions - but what we are not is a free legal service that you could use at a later point to use as a get out of jail free card, possibly literally.

Transmitting pictures with any regularity is well beyond what you’re going to be able to legally do.

Unless you can analyze the pictures on the node and report just a short conclusion in a few bytes, you probably need to look at something like a mobile (telephone) provider’s data network.

1 Like

Thank you all for your great and valuable comments!

You have to read the LoRa(Wan) limitations of your region.

Some accept frequency hoping (FHSS - Frequency-hopping spread spectrum), changing the channels at least N times during period T.

Depending on the resolution of your image, compression, etc, efficiency of your FHSS implementation, and your region limitations, it can be possible to send images using LoRa at a rate not too low (each X seconds).

Yes. Totally agree with you!
Even considering regulations, I also think LoRa(WAN) is intended for more serious industrial applications than just sending short messages like high/low commands or so.
Maybe I am wrong. But, how rules are applied if a private gateway is developed for a private application? Do we have to apply those regulations of the duty cycle, the maximum number of bytes, etc.?

AFAIK, there are 3 limitations :

  • radio spectrum limitations on your country/region for the LoRa band;
  • LoRaWan regulations/specifications for your region, not needed when using LoRa-Raw/LoRa-Mac;
  • TTN limitations when using public TTN server, only when using LoRaWan (and of course TTN).
1 Like

The law is the law, regardless if it is a private or public network. If you break the law, you must be prepared to face the consequences.

Also, the ISM bands are shared, so anyone misusing the band will affect other (law-abiding) users. If there is too much misuse, governments will step in with tougher regulations which will ruin things for everyone. Due to this, law-abiding users are likey to report misuses, and assist in finding the culprit. The LoRaWAN community has a lot of people skilled in tracking down bad users.

1 Like

I am not aware of any countries that have a ‘LoRa band’, i.e. specific legal specifications for just LoRa.

LoRaWAN is intended to follow the legal restrictions for ISM band use, end of.

That you may not like the use restrictions imposed on ISM band use (and hence LoRa\LoRaWAN) is beyond the scope of this forum to assist you with.

Complain to the regulators.