How to Migrate ABP Devices from V2 to V3

@neoaggelos @roman please comment on this.

We’re tracking this issue:

That there are two ways, and that any LoRaWAN network server needs to explicitly know if the device uses factory preset frequencies that are different from the default set of join channels.

Note that LoRaWAN networks can also choose not to use the three join channels once devices joined the network, to dedicate those channels to device activations (and other networks). This is why the factory preset frequencies are all the channels and are independent of LoRaWAN join channels.


On another note, @snejra made lots of progress on the migration documentation on, see doc: Add V3 info by nejraselimovic · Pull Request #425 · TheThingsNetwork/docs · GitHub

We very much welcome clarifications there. I highly appreciate articles and forum posts, but ultimately we need to get this documented.


@htdevisser I see no mentioning of copying AppSKey in your instructions.
I assume this needs to be copied from V2 settings as well because that is the AppSKey that is programmed into the device. Correct?

I have migrated one ABP device regarding the description here.
I can see the device traffic in the gateway:

  • 20:46:43 Drop uplink message
    Host cluster failed to handle message: No device matches uplink
  • arrow_upward
    Forward uplink message
  • arrow_upward
    Receive uplink message
    MAC payload
    Raw payload

But in the device is displayed:
Last seen info unavailable
And no activity.

What should I do?


It says it can’t deliver the message. A possible cause is not explicitly having added all 8 channel frequencies (or any of the other required settings).

First: provide more details about your device and what you have done.

What is your region, EU 868MHz?

Have you followed all steps in " 1. Migrating a Few Devices", including adding all 8 channel frequencies?

Have you also copied the AppSKey from V2 and configured this in V3 device settings.
The AppSKey step is missing from the instructions in the OP.

Apparently you already have a gateway connected to V3, otherwise you would not see any traffic in the V3 console for a migrated ABP device.

1 Like

Device is The Things Uno Using ABP.
Its EU868.
All Step including all frequency done.
AppSKey is also copied.
Gateway is connected to V3, correct.

What I receive there:

“name”: “gs.up.receive”,
“time”: “2021-02-18T01:19:25.439765941Z”,
“identifiers”: [
“gateway_ids”: {
“gateway_id”: “856911494457109”,
“eui”: “B827EBFFFEC8AF61”
“data”: {
@type”: “”,
“raw_payload”: “QN8dASYAV0UBaFIINAboy39Vnmn9”,
“payload”: {
“m_hdr”: {
“m_type”: “UNCONFIRMED_UP”
“mic”: “VZ5p/Q==”,
“mac_payload”: {
“f_hdr”: {
“dev_addr”: “26011DDF”,
“f_ctrl”: {},
“f_cnt”: 17751
“f_port”: 1,
“frm_payload”: “aFIINAboy38=”
“settings”: {
“data_rate”: {
“lora”: {
“bandwidth”: 125000,
“spreading_factor”: 7
“coding_rate”: “4/5”,
“frequency”: “868300000”,
“timestamp”: 1981111955
“rx_metadata”: [
“gateway_ids”: {
“gateway_id”: “856911494457109”,
“eui”: “B827EBFFFEC8AF61”
“timestamp”: 1981111955,
“rssi”: -69,
“channel_rssi”: -69,
“snr”: 10.5,
“uplink_token”: “Ch0KGwoPODU2OTExNDk0NDU3MTA5Egi4J+v//sivYRCTvdWwBxoMCJ2Bt4EGEI7i0dEBILjc5ZvUqgU=”,
“channel_index”: 1
“received_at”: “2021-02-18T01:19:25.439644430Z”,
“correlation_ids”: [
“correlation_ids”: [
“origin”: “”,
“context”: {
“tenant-id”: “CgN0dG4=”
“visibility”: {
“rights”: [

But it says: No device matches uplink

Please spend some minutes to read: How do I format my forum post? [HowTo]

It seems to be the case that always only 3 frequencies are saved also when I add more.
I can press save, but when I switch to different page and go back there are only 3 frequencies displayed.

Looks like I skipped that. Fixed.

1 Like

‘May not’ or ‘will not’?

What is the reason that changing Advanced setting later may/will not work?
The console gives the impression that it should work and allows these fields to be edited.

Can ‘may not work’ be fixed?

If not then why are these fields allowed to be edited in the console after the device has been added/registered?

1 Like

Maybe @roman can give some details here, but as far as I know those settings are applied to new sessions of the device, not the existing session of the device. A new session starts with an OTAA join. In case of ABP, the LoRaWAN 1.1 ResetInd MAC command indicates that some session state was reset. And maybe it’s also triggered on an ABP frame counter reset if you’ve enabled those (don’t, it’s insecure).

@roman please confirm how this works exactly, then perhaps we can clarify this in the Console.

1 Like

That would be a very helpful feature. Think it should be there.

I’ve got a V2 device working with ABP, i’ve deleted from V2 console, then added to V3 console keeping the same DEVId, DEVADD, NWSKEY and APPSKEY, now on my gateway (still V2) i can see the traffic of the device, but on V3 console no data is displayed, what i’m doing wrong?

Let me explain why i’m using ABP instead of OTAA.

  • save energy of joining proces.
  • Not compiling OTAA saves source code.
  • In my case devices are usually placed deep indoors, so i realized that there is the chance to setup the same device settings in TTN and EVERYNET… so i can receive data from my device in two different networks, that’s not posible with OTAA, and gives an “antenna diversity” that improves the chance of the device to communicate, and at the end my customers want “service”.

I understand the reasoning for choosing ABP. But my question is: Are you willing to accept that two LoRaWAN network servers talking back to your device? It could happen that the network servers are issuing conflicting commands to your end device that will disrupt the service that your customer expects. The architecture choice is not something to blame the network server for. If this was part of your risk assessment an you accept the risk it should be fine.

The classic one when servicing two networks (though perhaps not the case here) being both connections telling the node to change settings under ADR - with the poor node changing up and down the gears (SF & Tx pwr) based on which ADR command last seen…in worst case then the network with GW ‘closest’ in terms of best signal perhaps telling the node to go to SF7 (for example) and lower Tx power such that the other networks GW can no longer even hear the node and result is that ‘service’ failing totally! :rofl:

Thank you for the feedback, i don’t use ADR, so these MAC commands are not sent by NS, fortunately the RX1 delay on both networks are now different and Rx2 SF too ( 9 for TTN and 12 for Everynet ) so that makes posible to receive MAC commands from both, concerning ADR, my app server chooses best network case to send donwlinks, and the device with the received RSSI tunes the uplink SF and power. i think that it is possible to work that way, thus improving the chance to communicate.

1 Like

For ABP devices, apart from ResetInd, MAC state is reset on FCnt reset.
Since 3.11 we also have a Reset RPC (see ttn-lw-cli end-devices reset CLI command), which lets you reset an ABP device MAC state or forget OTAA device session in the Network Server.

@roman, I tried to reset the MAC but it has no effect.

I executed:

remko@DESKTOP-RLF1S9G:~/ttn-lw-stack$ ./ttn-lw-cli device reset geocaching gc-10 --mac-settings.resets-f-cnt
  "ids": {
    "device_id": "gc-10",
    "application_ids": {
      "application_id": "geocaching"
    "dev_eui": "AF5EE00000009C03",
    "dev_addr": "260B204B"
  "created_at": "2021-02-18T13:27:47.737Z",
  "updated_at": "2021-02-25T20:02:30.933256929Z",
  "mac_settings": {
    "resets_f_cnt": true

The frame counter was reset in console but the downlink for RX1 delay is still scheduled.


I still feel that it is not working.

Can I see ttn-lw-cli device get geocaching gc-10 --mac-settings.rx1-delay --mac-settings.desired-rx1-delay?
And what RX1 delay would you like to use on your device?
By default we use 5 - that requires a RxTimingSetupReq.

That’s actually not legitimate or workable, unless you’ve rigged things such that one of the networks is physically incapable of ever transmitting down to the node.

Otherwise, one will capture the downlink frame counter locking the other out, nevermind the confusion over MAC state.

Keep in mind that downlink support is mandatory with TTN V3, so if you’re going to try to feed two networks, then you must make sure the non-TTN network can never transmit.

fortunately the RX1 delay on both networks are now different and Rx2 SF too ( 9 for TTN and 12 for Everynet ) so that makes posible to receive MAC commands from both, concerning ADR, my app server chooses best network case to send donwlinks, and the device with the received RSSI tunes the uplink SF and power. i think that it is possible to work that way, thus improving the chance to communicate.

No, that is unworkable and should not even be attempted, as it will cause one or both networks to waste downlink capacity on housekeeping messages originated automatically and not by you.

TTN V3 makes it absolutely mandatory that your node support downlinks, and not be registered with anything else that has the capability to send them.

In simple terms, a LoRaWan network (be it TTN or something else) must have exclusive ownership of a node. The protocol simply will not work correctly otherwise.