LoRa Raw Network, how many nodes possible ?

[gaet]

Hello everyone,

I didn't manage to find what I was looking for in the documentation so I'm counting on you now.
I want to use some Lopy4 in a network, with 1 "master" which will receive the data sent by the others in LoRa Raw exclusively. But the thing is, I would like to know if there is a theorical max number of lopys that I can use ?
The application doesn't matter, I just want to know if sky is the only limit ?

Thanks in advance and have a great day

[robert-hh]

@gaet There is no single answer to that question. It depends on many factors, regulatory and implementation. as there are:

• the duty cycle limit of the region you're in. That defines how long in average a station is allowed to transmit. If set, that is typically 1%.
• the average air time of your application, depending on the air time of each message and it's frequency.
• the number of channels the gateway (master) can handle simultaneously.
• and the usual message collision statistics math, which will be complicated by the fact, that a station close to the gateway will override a station further away.

I faintly recall that people reported of applications with several thousand nodes, which then would each have a relatively short airtime.

[gaet]

@robert-hh ok great, thanks a lot for your time and this precise answer

[jcaron]

@robert-hh Let's add for the sake of precision:

• All devices are subject to the same regulatory limits. If the region you are in has a 1% duty cycle limit, this applies to all devices, including the "master". So if your implementation involves ACKs from the master, that effectively limits the number of devices or how often they can talk quite a lot.

• Remember that at the slowest data rates (which are supposed to carry further), even the smallest frame can take over a second to transmit once you factor in all the overhead. That means that with a 1% duty cycle, you cannot transmit more often than 100+ seconds on average. It also means that even without a duty cycle limit, and even if you do collision avoidance (see below about LBT), that means that if you have 1000 devices on a single channel for instance, each device can't transmit more often than once every 1000 seconds.

• Note however that in the EU region for instance, there are channels with a 10% duty cycle limit. But there's only one (or two, don't remember off the top of my head) and it's of course quite busy.

• LoRaWAN does not use "Listen Before Talk" (LBT). If you use it (together with "Adaptive Frequency Agility" (AFA), you can in some regulatory regimes get rid of the duty cycle limitation. But LBT has its own limits, especially when large distances are involved (it's not because the master can hear stations A and B that A can hear B or vice-versa).

• If you don't use LBT-AFA (and even if you use it, depending on the above factors), you'll have to deal with collisions. This breaks down quite quickly when slow data rates, frequent communication and high number of devices are involved. Remember the bad old days of non-switched Ethernet? They're back!

• You want to to use "raw" LoRa, but your own network implementation will need to add overhead for message types, frame counters, source/destination identifiers, security signatures and/or encryption, and more. You'll probably quickly end up re-inventing the LoRaWAN wheel.

• Since the band is shared, you may not be the only one using it, which will in turn have an effect on how many of your own devices you can have.

So basically, things depend a lot on:

• the region you are in and the regulatory regime that goes with it
• the distances involved and the environment in general (indoors / outdoors, interference...)
• how often your devices need to talk
• whether "fire and forget" (you can lose packets) is fine with you or not
• whether you need to receive packets timely or not

Having 1000 devices that send a message once a day at SF7 with packet loss not being a major issue (e.g. metering) is no problem. Having 1000 devices that send a message every hour at SF12 which you definitely need to receive in a timely fashion (e.g. knowing that a parking spot is currently available or not to guide users to that spot) is a lot more problematic.

[gaet]

That is a great explanation, thank you.