Best approach to OTAA join for multiple devices turning ON at the same time

[interravikram]

Hi everyone
I have been trying to get the OTAA done perfectly , and this forum has helped a lot in the purpose.
Thanks for that
The question is
What is the best practice for OTAA devices if there are 20 devices booting at the same time and asking for a join request on TTN Gateway?
Many a times . the join get accepted , but the data doesn’t make it through for some applications.
What can be the possible solution for this?
Thanks

[BoRRoZ]

@interravikram

20 devices booting at the same

don’t boot them at the same time at the same location, or just be patient.
what is your use case that you have 20 nodes booting exactly at the same time/location ?
or is this a ‘theoretical’ question

[interravikram]

I have 8 devices and we faced a lot of problems with them joining at the same time.
What i have tried is
Join request sent on SF7 by default
Accepted -> No need to retry , move ahead to send message
Denied -> Yes - > Send again on SF8 and continue untill SF10 -> Fails -> YES -> Retry on SF7 and Repeat untill SF10.
Send message on SF7 by default
Lora response != mac_tx_ok -> Try again on SF8 and so untill SF10 .
Lora response == mac_tx_ok -> Good to go , no need to retry on other SF

[cslorabox]

This seems like a distinct problem (even if encountered in the course of the other), and it’s a theoretically real one.

Although a typical LoRa concentrator card is a parallel receiver, it only has a single transmitter. Thus while in a situation of perfect luck in channel choice 8 simultaneous join requests could be received and processed, only one could actually have a join accept transmitted in reply (or two, if the RX2 slots is supported all the way through the system).

In theory, if you have multiple copies of the same hardware and firmware turned on all at the same time, you could not only get a collision of join requests all needing replies at the same time, the losers’ retries could also stay aligned in time for a substantial period of time.

So the solution is to introduce some random time delay. Have the nodes wait a random period of time before their initial join attempt, and another random delay before they retry. And much as you are hopefully doing with your channel selection, don’t just use a pseudo random number generator with a fixed seed, use an actual source of entropy like an ADC or radio noise reading.

[BoRRoZ]

@cslorabox

don’t just use a pseudo random number generator with a fixed seed, use an actual source of entropy like an ADC or radio noise reading.

really ? all that in a simple node

[cslorabox]

Yes, if you want a multi-node system to work, preventing perpetuated collisions is key.

Keep in mind that almost all these systems already have such inputs as an implicit part of their operation - they have a radio to communicate, and they have sensors that produce data to be communicated. So there are ways to get entropy sufficient for de-confliction. Entropy sufficient for cryptography is a bit beyond the scope of this.

[kersing (Jac Kersing)]

@cslorabox

Although a typical LoRa concentrator card is a parallel receiver , it only has a single transmitter .

For locations with a duty cycle limit the worse issue is the gateway running out of airtime. Had that problem a couple of times while running workshops.
Only work around is to deploy more gateways (people attending a workshop won’t wait even if asked to)

[interravikram]

@cslorabox

So the solution is to introduce some random time delay . Have the nodes wait a random period of time before their initial join attempt, and another random delay before they retry. And much as you are hopefully doing with your channel selection, don’t just use a pseudo random number generator with a fixed seed, use an actual source of entropy like an ADC or radio noise reading.

When we use ADC for random delay generation , imagine this scenario.
Device 1 → ADC VALUE → 200
Device 2 → ADC VALUE ->210

if i multiply the adc data by 10 , the total difference between two initial join request is only 100ms.
What factor/logic should i use so i can be very sure that even if the adc raw value was close but the delay generated on a minimum is always > 6 seconds

[interravikram]

https://www.pentestpartners.com/security-blog/want-entropy-dont-use-a-floating-adc-input/

I found this article about why not to use ADC as the entropy source.
I think more Gateway is the only workaround.

[UdLoRa]

Of course it is better to have more gateways, but you are not encrypting data (which is what your link refers to), just delaying join. Regarding the factor, just observe how variable is the input and choose an adequate multiplier and offset.
However, consider also that you do not have to join everytime you switch on (best practices here).

[cjhdev]

Best practice would be to implement the randomised retry algorithm described in the “Retransmissions back-off” section of the specification. It should come unstuck eventually.

[cslorabox]

@interravikram

When we use ADC for random delay generation , imagine this scenario.
Device 1 -> ADC VALUE -> 200
Device 2 -> ADC VALUE ->210

In an ideal world, you do not use the hardware source of entropy directly, but rather use it to seed a pseudorandom number generation algorithm.

Additionally as pointed out, this isn’t only about the first delay but cumulative ones as well - it is not as much about preventing any conflict as it is about preventing sustained conflict as could occur if clock oscillator variation were the only difference driving things apart in time.

In general LoRaWan is designed around an assumption of having fewer downlinks than uplinks; a bunch of nodes all trying to join at the same time(s) is a challenging exception.

A more typical concern that the randomization mechanisms you may find in existing code would be there to prevent is that that two nodes don’t stay aligned in time and frequency (and SF) for multiple transmissions, stepping on each other.

[interravikram]

@UdLoRa

However, consider also that you do not have to join everytime you switch on

Thanks for the information , So we are going ahead with joining once in the device lifetime(during first setup) and never again

[cslorabox]

@interravikram

So we are going ahead with joining once in the device lifetime(during first setup) and never again

That is unlikely to work in many real-world situations. There are limit to things like how long a node can be unheard (because it is off, or because it is out of range of any working gateway) without the session becoming invalid. Not unecessarily joining anew is a good idea; being unable to is a bad one.

[Guy]

What I do is to:

• each device has a random delay factor based on the DevEUI (i.e. checksum it or something to get a single byte random number (0x00 - 0xFF);
• define a delay to be some number +/- a deviation based on this random number, e.g. 10Sec + (delay/256) * 10 sec, so you get 10-20 sec;
• use this to delay the response of your devices to everything: join, response to stimulus etc
• use an exponential backoff if you have a join failure, e.g keep adding the (delay * 2) to the next delay;
• be very aware of stimulus that can cause all your devices to transmit at once, e.g power coming on, earthquake etc. If they are sensitive to this then add more random delay to spread them out more;
• consider the number of devices likely to be seen by a gateway. If there is a high probability of a large number of devices transmitting simultaneously to a single gateway then increase the delay/randomisation factors;

[cslorabox]

Incidentally, the LoRaWan 1.1 specification specifically addresses this concern, and part of the recommendation there is a pseudorandom number generator seeded by part of the EUI.

That part is worth a read even when building for LoRaWan 1.0