We are experimenting with the things network right now, and also we joined the Cibicom network in Denmark. We added our test device to both LoraWAN networks.
My plan was to use TTN as the primary network, and then Cibicom as a kind of backup network, where TTN does not cover properly.
I am testing with a dragino lgt92 gps tracker.
Unfortunately it seems that the device on power up connects and exchange keys with a network, and then its not able to communicate on the other network until its restarted.
My plan was that the device could smoothly join one of the networks around to get more coverage. So if i drive from A to B, then maybe near A its on TTN and near B its on Cibicom, and all this happens automatically.
Is this a known problem to LoraWAN? Or is it the device that is not working properly?
Its no problem on the server, we just have two entries for each LoraWAN and handles it there.
Using OTAA this won’t work. You might be able to get this to work using ABP however that would be less secure as the counters will be reset on every power up leaving you vulnerable to replay attacks.
What could work would be to heavily rework the node software stack so that it was basically two “virtual nodes” sharing the same hardware.
Each would have almost completely independent state, secrets, status, etc
If duty cycle limits apply, those would have to be shared between the two instances
Of course you can’t schedule things that conflict in time, mostly you let one node transmit and listen, then when it would go to sleep you let the other virtual instance run
Keep in mind this would be a rather advanced project - along the way you’d have to develop a very deep understanding not only of the protocol but of however the software stack you start from implements that.