Migrating active sessions (v2-v3), will rx1 delay be 5s after the next join?

End Devices (Nodes)
1

Hi

If you migrate OTAA active sessions from v2 to v3, the rx1 delay is set to 1s (ref: Major Changes In The Things Stack | The Things Stack for LoRaWAN)

After the device is migrated, and perform a rejoin on v3 will the rx1 delay become 5s?

2

As far as I understand, OTAA nodes will always need a new join to migrate to v3.
Parameters like the rx delay are communicted to the node during the join (or communicated shortly after through a MAC command, not completely sure). So if you configured the LoRaWAN version in the console correctly for the node and your node is compatible/compliant, this will happen automatically.

3

Last I heard that it was possible but not recommended at all to migrate sessions.

Can you devices be told to rejoin or will they timeout quickly enough that they will rejoin automagically?

4

Not required. Check: https://www.thethingsnetwork.org/docs/the-things-stack/migrate-to-v3/migrate-using-migration-tool/

Afaik the RX1 delay will be set to 1 second for this device during migration and that will not change at a rejoin. To be sure a test would be required (for which I currently lack the time).

5

OTAA nodes will always need a new join to migrate to v3

For The Things Network v2 to The Things Stack CE, this is correct. Migration with session is not possible here due to the difference in DevAddr blocks used in both these cases.

After the device is migrated, and perform a rejoin on v3 will the rx1 delay become 5s?

Yes, once a device rejoins, it’ll get what ever RX1 delay is configured on TTS for this device.
In TTS (CE), the default RX delay is 5 seconds. So, if you use all defaults and allow your device to rejoin on TTS CE, then it will get an RX delay of 5 seconds via the Join Accept message.
You can set a custom RX delay via the --mac-settings.rx1-delay option (on the CLI) but we recommend using default values unless you really know what you’re doing and this needs to be modified.

1 Like
6

Not according to the documentation. See the link in my message above. Rejoining is recommended but the other option is available if a V3 gateway is present.

7

LOL, I had a guess, @kersing says you can, @KrishnaIyerEaswaran2 says you can’t, @kersing links to the docs and the answer is …

… the docs say you can if your gateway is on v3 before you start.

My question for @KrishnaIyerEaswaran2 is, if the OTAA device session is moved over, I presume with Rx1 set to 1s as part of the migration JSON, can we then update the Rx1 to 5s once we’ve figure out how to force a remote rejoin?

8

Not according to the documentation. See the link in my message above. Rejoining is recommended but the other option is available if a V3 gateway is present.

Yes sorry, you’re right. You can’t migrate via Packet Broker but regular session migration is theoretically possible. We do not recommend it however.

My question for @KrishnaIyerEaswaran2 is, if the OTAA device session is moved over, I presume with Rx1 set to 1s as part of the migration JSON, can we then update the Rx1 to 5s once we’ve figure out how to force a remote rejoin?

Yes you can use the aforementioned --mac-settings.rx1-delay setting to change this value.

1 Like