Is rejoining in new rejoins necessary?

[Jakub_Nagy]

Hey everyone,
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:

1. 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?
2. 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?
3. 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!

[kersing (Jac Kersing)]

1. According to information on this forum, yes.
2. Using the information in the CF list is mandatory. TTN will ignore transmissions on any other frequencies. For regions where CF lists aren’t used you will get other MAC commands to configure the node. Do not ignore these as that results in endless retransmits.
3. You should observe the values you get from the LNS. Things might be the same now but might change in the (near) future. Hard coding information / cutting corners will result in issues at some point.

Did you see the Kickstarter campaign from Seeed for their new tracker node? From its description is does exactly what you are trying to achieve. There is a reference to it on this forum…

BTW, testing doesn’t need to be that difficult. Just get a gateway with the right frequencies, connect the node and the gateway with (attenuated) antenna cable, put in a RF shield to kill the remaining RF energy and you are good to go. You just need to make the node believe it is at the different location, that shouldn’t be too hard if you develop the firmware.

[descartes (Nick McCloud)]

@Jakub_Nagy

I’m asking this because the LoRaMac-node implementation doesn’t support this out of the box

As edge cases go, HAB floaters are definitely “up there”, but prone to being shot down by the USAF. So this shouldn’t be surprise. Devices roaming beyond continents at ground level are pretty niche as well.

But there is a fair amount of code for saving all of the state in NVM so in theory once you have a join, you can save the state with an offset so different regions get saved in to different parts of flash. It’s a #define at present but easily turned in to a variable. Off the top of my head from some prior fiddling that was somewhat related I’d nuke the whole stack (de-init), change the region, re-initalise that is very very close to a reboot and recall the settings for the new region.

As for testing, as Jac says, TTIG US915 in a 20" container does it for my overseas testing - TTS is even obliging enough to let you flip the gateway region on the console without having to re-register - so my TTIG can get severely travel sick as it bounces between US & AU on a test day…

[Jakub_Nagy]

@kersing

• Hard coding information / cutting corners will result in issues at some point.

Okay I understand. I knew it would most likely not be compliant, that’s why I was asking about how this works in practice. But based on your replies this doesn’t seem like a viable solution to pursue.

@kersing

Did you see the Kickstarter campaign from Seeed for their new tracker node? From its description is does exactly what you are trying to achieve. There is a reference to it on this forum…

No, Seeed has a lot of products. I found the “LoRaWAN Field Tester” but that’s only compatible with Helium from what I found.

@descartes

As edge cases go, HAB floaters are definitely “up there”, but prone to being shot down by the USAF. So this shouldn’t be surprise. Devices roaming beyond continents at ground level are pretty niche as well.

You’re right, we had to develop a lot of technologies to make it work.

@descartes

It’s a #define at present but easily turned in to a variable. Off the top of my head from some prior fiddling that was somewhat related I’d nuke the whole stack (de-init), change the region, re-initalise that is very very close to a reboot and recall the settings for the new region.

Yes, but I think there is an error in the implementation. See, the usage of “context storage” is mandatory from 1.0.4 but also should be supported in 1.0.3. But it simply is not. When running LmHandlerConfigure the OnRestoreContextRequest callback is triggered, which is fine. But then when LmHandlerJoin is called in the version is 1.0.3 then LoRaMacMlmeRequest is always called forcing a join while in 1.0.4 the CtxRestoreDone flag is first validated. I don’t know why it is that way, since the context restore is also done in 1.0.3. Anyway this little change makes NVM restore work.

@descartes

once you have a join, you can save the state with an offset so different regions get saved in to different parts of flash.

That’s a great idea which I also had in the past, the question is, is the old session in the old region valid when joining to a new region? Meaning, can I join in the US, then rejoin in the EU and then again use the same DevAddr and settings used when I return back to the US? Are they just separate sessions? Even if they aren’t I could just use the API to create a device for each region (device-1-eu, device-1-us…) and save separate root keys into the memory, but this would be more finicky.

@descartes

As for testing, as Jac says, TTIG US915 in a 20" container does it for my overseas testing - TTS is even obliging enough to let you flip the gateway region on the console without having to re-register - so my TTIG can get severely travel sick as it bounces between US & AU on a test day…

Okay great, time to get a TTIG for testing. The only caveat I see is that we also use Helium in addition to TTN and there I think you cannot set the region manually but instead is configured by the internal GPS, but that’s a future problem.

The original concern wasn’t having to rejoin into different regions multiple times, but rather the initial join when crossing the region border due to signal quality concerns. One more idea I have would be to “prejoin” into every region. This would mean having gateways setup for every region in one room and joining into each one by one and storing the contexts. If this wouldn’t work because of the geofencing, I could even setup physical devices in all the different regions and transmit the root keys securely to them and then get the contexts back, doing sort of a “virtual join”. But that’s definitely not an optimal solution either.

[kersing (Jac Kersing)]

@Jakub_Nagy

@kersing

Did you see the Kickstarter campaign from Seeed for their new tracker node? From its description is does exactly what you are trying to achieve. There is a reference to it on this forum…

No, Seeed has a lot of products. I found the “LoRaWAN Field Tester” but that’s only compatible with Helium from what I found.

Kickstarter …

[edit]
https://www.kickstarter.com/projects/seeed/sensecap-t1000-track-what-you-care-with-no-boundaries

[descartes (Nick McCloud)]

@Jakub_Nagy

the question is, is the old session in the old region valid when joining to a new region?

The old session in the old region is irrelevant to the new region, there is nothing to pass over. Just find a way to set the stack to the new region and do a join.

@Jakub_Nagy

then rejoin in the EU

What’s with all the re-joining? You join in a region, you use that, you save the state, you move region, you restore that regions state, you use that, rinse, repeat.

@Jakub_Nagy

Are they just separate sessions?

Yes - not sure what implies there would be any correlation. Perhaps the fact you have the same Dev/JoinEUI - but that’s not a thing either as you can change that as you change region.

@Jakub_Nagy

and save separate root keys into the memory, but this would be more finicky.

They are saved for you in the NVM …

I think you are thinking too hard. Sure, 1.0.3 isn’t well setup for the NVM implementation and my forthright personal opinions about 1.0.4 mandating write to flash are already documented on the forum in an exchange with the developers - but if you put your hand over 1.0.3 so you can’t see it and use 1.0.4 and it’s state save, it is meant to be comprehensive enough to allow a total power down and restart of a device. Which means the job is done for you - you just need to hack the region switch & the offset in the flash save.

@Jakub_Nagy

One more idea I have would be to “prejoin” into every region. This would mean having gateways setup for every region in one room and joining into each one by one and storing the contexts

Almost a brilliant idea, spoilt only by the subsequent geofencing comment. If we ignore CN470 for a moment, you two gateways, possibly only one if it can do 868 - 928, set it a region, do a join, save, set it to the next region, join, save, rinse, repeat. There is no reason for a session to expire on the LNS.

There is no geofencing in “normal” LoRaWAN. But if you happen to have a gateway that has to insist on knowing where it is so it can fill the coffers of the 50 or so staff & family of the crypto founders, with all this other hacking about, you should be able to do a join in the air and save the state, knowing that at worst the TTN joins are already setup.