Over the past year or so we have migrated all our private network customers from V2 to V3 backends, and we now run all those customer apps and gateways on a fault tolerant multi-tenant V3 cluster.
I have to say that I have a lot of confidence in V3 and I’m glad to be finally leaving the V2 world behind.
But this migration is going to be challenging for many of us for all the reasons people are mentioning in this thread. The key issue being that application owners and gateway owners are often different people, who may not know each other, and have different priorities.
I’d like to provide my migration learnings to application/device owners in case they’re of use. I’m assuming here that you want to avoid physically visiting every device to reboot it and want to avoid device downtime.
For the purposes of migration, devices fall under a few different categories
-
Well behaved OTAA devices with Network Link Check (or similar). These devices will soon realise that they no longer have a valid connection to the network and will reissue an OTAA join-request on their own and come up on the new network without any intervention, and an outage of only a few packets. When you buy a device, this is the kind you want.
-
OTAA devices without any form of link check, but can be rebooted or forced to rejoin via downlink. You will be able to get these devices migrated by reconfiguring them as “ABP” devices on V2 (so that they won’t receive a join-accept from the old network) and sending a reboot command to them to force them to rejoin the new network.
-
OTAA devices without any link check and no way to remotely reboot them. In this case, you need to preserve the session keys when you register them in V3. By doing this, the device doesn’t know that it’s even changed backends and continues sending uplinks as it did before. But now you have other issues to worry about (which is why Johan suggested not to use this method). One issue we’ve found (on dynamic band plans like AS923) is that the new network will try and issue new channels to the device as it doesn’t know it already has them. This will lead to the device rejecting those MAC commands, causing potential issues. So these channels have to be “hard coded” when the device is registered. You will probably want to undo this hard code at a later time and reboot the device. This is all time consuming and complex if you aren’t familiar with V3 (The CLI is your friend!).
-
ABP devices. These are mostly like the previous category. However, if your DevAddrs are not in the TTN range (26xxxx) then they probably won’t traverse Packet Broker, so you may need your gateways to be on the same network as your devices. If you have this problem then you probably want to rethink your device strategy as the road ahead will be a bumpy ride for you.
Edit: Below Johan indicates that “the V2 issued DevAddr is not routed to V3”. This means that devices which fall into categories 3 & 4 below are going to need to communicate with gateways on the V3 network.
I may have missed something, and others have probably developed better migration strategies, so feel free to add your experiences too.