I’m writing this post as a quick draft that will be extended and eventually turned into a documentation page.
Migrating existing ABP devices requires one of the following:
- Your gateway is connected to V3, or
- You update the device address (DevAddr) in your end device(s) with a new device address generated in the V3 console. This option may require flashing new firmware to the device.
Read below instructions carefully. If you make a mistake it might not be possible to correct it later. If so, a new device will have to be added instead and the current
device ID will become unusable because it cannot be re-used.
Before you Begin
- Using ABP devices is discouraged. We recommend to use OTAA unless you really have a good reason to use ABP.
- ABP devices are (by definition) hard-coded (personalized) to a specific Network Server, so it’s technically not possible to migrate them to a different Network Server.
- If you do migrate ABP devices, they will keep their V2 DevAddr. Packet Broker will not route traffic for these devices to V3. This means that you will have to connect your gateway to V3.
(Note: a gateway connected to V3 will not forward traffic from V2 devices to V2).
- ABP devices on V2 use an RX delay of 1 second. V3 uses an RX delay of 5 seconds. V3 will try to send this configuration to the end device in a donwlink MAC command, but still, downlink may be unreliable for these devices.
- You may have to reset your end device if it has a high frame counter.
- If you have easy access to your device, it’s probably better to just re-program it. This would be a good opportunity to update the firmware to switch to OTAA and add some best practices.
1. Migrating a Few Devices
If you’re migrating a few devices, you can just do that in the Console:
- If you don’t have an application in V3, add a new one.
- The Application ID does not have to match your V2 application ID.
- Add a new End Device in V3.
- Follow the manual steps:
- Select Activation by personalization (ABP)
- The LoRaWAN version is probably
- In the Basic settings step, the End device ID does not have to match your V2 device ID.
- The DevEUI is optional.
- In the Network layer settings step, Select a Frequency Plan. For EU868 devices coming from v2, you select Europe 863-870 MHz (SF9 for RX2 - recommended).
- The Regional Parameters version is probably
v1.0.2 rev B
- Your device does not support class B or class C
- The DevAddr and NwkSKey must be exactly the same as for your v2 device registration.
- The Advanced settings must be set on registration.
Changing these settings later may not work.
- The Frame counter width is probably 32 bit
- The RX1 Delay is 1 second
- The RX1 Data Rate Offset is 0
- The device probably resets frame counters
- The RX2 Data Rate Index for EU868 devices coming from v2 is 3
- The RX2 Frequency for EU868 devices coming from v2 is 869525000
- The Factory Preset Frequencies for EU868 devices coming from v2 are:
- for all devices:
- for devices that use 8 channels
(in addition to the 3 channels above )
- for all devices:
- In the Application layer settings step, the AppSKey must be exactly the same as for your v2 device registration.
Deleting the Device from V2
With the registration in v3 set up, you need to prevent the V2 Network Server from handling traffic for your device. You can do that by deleting the device from V2.
Connecting Your Gateway to V3
Because your device is still using a V2 DevAddr, Packet Broker won’t route traffic for it to the V3 Network Server if your gateway is still connected to V2, so you have to connect your gateway to V3.
2. Migrating a Lot of Devices
If you need to migrate a lot of devices, you can use the migration tool.
[to be added later]