When we tested join procedure using multiple LoRaWAN end-devices via OTAA at the same time,we found that LoRaWAN server did not receive the uplink data sent by some end-devices after they joined.
After the analysis, we found that in the process of joining, some end-devices have a high probability of working at the same frequency and data rate. After sending join-request message, these end-devices will receive a join-accept message that carried parameters like “Device Address”, “AppNonce” and “NetID” assigned to one of them by the server.
Since the other end-devices can not identify whether the message is a response to their own request, they also parse the message and use these parameters, complete the join procedure successfully. Because of the use of wrong parameters, eventually leading to the server can not receive the uplink data of them.
Because it is unavoidable that end-devices join the network at the same time with the same frequency and same rate, we recommend that it is necessary to add / modify part of the join-accept message to identify the response to different end-device from LoRaWAN server.
That’s why you should not use the very same secret AppKey for each device.
Also, to derive the secret session keys, each node needs the unique DevNonce it has generated when creating the Join Request: https://runkit.com/avbentem/deciphering-a-lorawan-otaa-join-accept This means it cannot successfully decipher another node’s Join Accept. (But when using the same AppKey it might not know it actually retrieved erroneous keys.)
You should actually avoid that, as the gateway needs to adhere to a duty cycle as well and cannot handle simultaneous joins: Multiple new devices trying to OTAA.
Normaliter, I do think that the change that two devices are joining at exact the same moment is small.
Only in test environments where we power several devices at the same time, you will have this kind of problems.
So: Avoid switching on several devices at the same time.
I have done several tests with > 10 devices, manually powered on within seconds.
For testing I always use the same values for all parameters except DevEUI, just because keeping all the same is easier to test.
Yes I am also in similar situation.when multiple devices requesting join at same time or waiting to join during this time it is high possibility of receiving and processing via other device join accept message.
