Migration of Devices Without Ability to Rejoin

V2 to V3 Upgrade Migrating Devices to V3
#1

Hello, Would be possible to help explain how I can handle the V2 to V3 migration for my specific case:

  • Devices are OTAA, joined on V2 TTN network - router.as2.thethings.network
  • Gateways are point traffic to router.as2.thethings.network
  • I have no ability to initiate a rejoin request onto the network. The entire device is potted (board, batteries, everything). As far as I know I capability wasn’t developed to trigger a rejoin by sending a command from the network.
  • Board is Pycom LopPy4 module
  • Device was designed for a long lifetime and to not ever have batteries replaced or be repaired.
  • There is a significant investment in the devices, so just straight up replacing them would be costly.

I have provided all of the information that I know to be relevant based on my knowledge, but if there is something missing please let me know and I’m happy to answer.

Note also: I am aware this setup is not ideal, but it was done when new to LoRaWAN. Any future devices will not be designed this way again.

#2

What is base device, LoRaWAN module or a stack running on an MCU. If so which library/stack. Some devices have a download MAC command or other that might be used to force a restart or a rejoin, but without full info your question might not be easy to answer…will they rejoin if they do not see network activity for a time ( I assume that is what you mean by no automatic rejoin feature?), some devices might but again without a full post you will struggle for answers I suspect.

BTW for future ref if you have control over the hardware design, it is alway worth adding a magnet operated reed switch if potting then you can always look at possibly using a high powered magnet to trigger and interrupt power, operate reset line, toggle gpio etc. To initiate some recovery action…

#3

Hi Jeff, Happy to provide any additional info just not sure what is needed. Base device is a Pycom LopPy4 module. It does not rejoin if no network is seen have seen this from testing out in the field.

#4

Have you asked Pycom if there is a download command that can be used to trigger reset or new join? (Nothing in manuals/data sheets?)… or perhaps other Forumites have experience with that one…

#5

I have checked with our developer and they said that for Pycom Lopy 4 you need to specifically open the receive window to get commands/rejoin from the server. The device does not open this window so it can conserve battery life.

#6

It’s not clear to me, so worth an ask, is the battery inside the pot?

Not tried on a LoRaWAN device, but there are some gadgets that can generate an impressive EMP that can really mess with an iPhone. Perhaps toned down it could reset a device.

How many of these do you have deployed?

#7

Based on the following information:

It appears that migrating devices ‘including security session’ should be possible under certain conditions. I personally have no experience with these migration tool(s), but TTI staff probably will.

And please provide detailed information about your case and devices (if necessary ask the developers). Without it this thread will only turn into a cat and mouse game.
Don’t make others have to guess and ask for more information that you can already provide yourself.

#8

Yes battery is inside the potting. EMP sounds risky - could that also damage the entire device? 15 devices worth about $2000 each.

#9

$2000 each and you poured potting compound around them ensuring they could never be repaired / updated / battery change?

What on earth are they?

1 Like
#10

So the batteries will never be replaced?

#11

Yes - as mentioned originally I am aware this setup is not ideal but it was done when new to LoRaWAN and that is how they are now.

#12

Correct they were designed for a fixed lifetime with no battery replacement.

#13

@johan
Can you elaborate? Why do you expect ‘most devices’ will?
Are you referring to commercial devices here (not custom builds)?
This presumably is not standard automatic behavior built-in into most of the common LoRaWAN stacks, but is somethings that will have to be programmed into the application logic explicitly.

Is the documentation for doing a ‘migration with preservation of security sessions’ already available somewhere? If not, when can it be expected?

#14

If it doesn’t honor receive windows (and correctly process and respond to the more standard MAC commands implied by the spec), then it’s not allowable on the present form of V3 anyway.

Maybe if/when V3 gets the desperately needed automatic DOS limiting and intentional user disabling of unproductive downlinks, but not currently without either of those options.

First step would be to immediately extract and archive the current session secrets for each from V2. With the in-effect sessions’ device address, keys, and full 32 bit up and down counters you might be able to continue to continue to manage them with something else. If they are truly uplink only (not even any ADR???) then that could potentially be a decode-only path twinned off a gateway that otherwise belongs to V3 in terms of any bidirectional actual LoRaWan traffic.

#15

@cslorabox thank you for your help. I am evaluating all options I have to be able to be able to have these devices continue to operate:

I have archived all data as you suggested. Do you have any recommendation of another platform that would be able to continue to manage them?

Upon further checking with device developer it does appear it should open the receive window after a transmission. That said, nothing was ever built to do anything with received messages. Are you able to provide more details on what standard MAC commands could be expected that device could follow by sending it a downlink message?

bluejedi - thanks for the info also.
TTI staff - if you have further information available about migrating devices ‘including security session’ under certain conditions. It would much appreciated.

#16

First question would be if ADR works, as a capability of the underlying software stack provided by pycom rather than something your code would need to do anything more than leave at what is hopefully a default of enabled.

Next would be if LoRaWan level MAC operations such as the Device Status Request that V3 likes to send seem supported, as any of trying it, asking Pycom, or reading through the code which they do publish.

It might make sense to bring up a copy of the deployed firmware on an un-encapsulated device conveniently located on your bench for experiments, maybe point one gateway at V3, etc.

If in fact your devices are working with ADR, then there’s a fair chance one that is “orphaned” would after enough time try a new join - that’s not “required” but it is fairly “typical”. You could also examine the code for evidence or ask pycom.

#17

I have confirmed that the Pycom has no built-in ability to trigger a rejoin request via downlink. It needs to be specifically coded to be able to do this.
The device also does not ever look for ack requests, so it would never know it is orphaned and to trigger a rejoin automatically.

So my my only option would be if TTN will support some kind of feature to migrate existing join keys. TTN staff are you able to clarify if this will be the case?