I think about a commercial use-case.
If I have a client A and client B nearby, I don’t want that the sensors of client A can send through the gateway B.
Also other sensors should not be able to send through these gateways.
I’m also thinking about an ‘attack’ where someone brings a big amount of sensors nearby the gateways. So they are not registred at the server, but will block all other traffic with their join requests (which will never be accepted).
How long will an unregistered sensor try to join the network?
Or is somwhere a timeout or counter which blocks/pauses the join requests? (on gateway/server-side)
In a useful case this should be managed by the software on the node, right?
@hasiflo, the gateway is a ‘dumb’ device which basically forwards every valid LoRa packet it receives to the server, irrespective if it is originating from it’s own ‘cloud’ of devices or from other clouds. This means for a private LoRa network that the gateway(s) will also be forwarding traffic from other networks like incumbents and TTN, and that your server will need to be able to handle much more traffic than you are actually generating with your own devices.
That depends on the implementation of the software on the devices. I think most devices will keep trying to join indefinitely, although may turn down the frequency of requests.
Since the network does not respond at all to an invalid join request, the device itself cannot determine whether its keys have turned invalid or whether it is simply out of reach of the network.
Yes, it would be quite easy to design a ‘hostile’ node which continuously keeps sending with SF12, and which does not listen to MAC commands to tone down. And you would just need one of these for every channel on the gateway. This would not fully block the gateway but absorb a considerable amount of its capacity.