we have a device which can successfully work in most different LoRaWAN regions. How it works is that the device hardware is tuned to the 729-960MHz range (it won’t work well in the CN470 region). When the geofencing detects that the device has entered a new valid region it tries to join to said region and after the join is successful, the LoRaWAN context is replaced.
There is an issue with this approach. When the device (it’s a balloon probe) enters the new region, the signal quality is still very poor, meaning uplinks (join requests) can come through, but downlinks (join accepts) don’t. Last time it took 5 hours of transmitting join requests before the device successfully joined into the new region. We’re confident that this is not a firmware problem, as the device joins quickly in good signal coverage.
The question is, is there any reason to actually throw away the old context a rejoin into a new region? Or is it possible that the old context would work?
There are a couple of concerns/questions I have:
- Is DevAddr bound to a region in the network server? The DevAddr and session keys are linked to a single session on a certain network. Therefore when switching to a new network a rejoin should be performed. What about different regions though? If I simply transmit in the US915 region with session keys acquired by joining in the EU868 region, will the network server not process them?
- Are CF-lists restrictive? One of the important parameters sent in join accepts are channel frequency lists. Are they restrictive in any way? Because all channel frequencies are known, the server just sends you the ones it wants you to use. But is it more of a preference, or will it ignore transmissions on channels not on the CF-list? Also from what I understood, CF-lists are only used in Europe and even there you have default channels which always work. Does that mean using them is unnecessary?
- Do any other of the parameters in join accepts actually change with regions? There are several more parameters sent in the join accept, such as RX2DataRate, RX1DRoffset and RxDelay. Of course they can be initially configured from the first join in the region of origin. Do any of them actually change with changing regions assuming a fixed LoRaWAN version? Or can they just be hardcoded in firmware?
I’m asking this because the LoRaMac-node implementation doesn’t support this out of the box (it didn’t support the rejoins and region switching properly either) and it would require significant effort to implement these features. Something like this is also very difficult to test, because we could just send a device to a different region and it simply wouldn’t work. So I’m checking, are these concerns a limitation to global LoRaWAN use in any way? Thanks!