How to Migrate ABP Devices from V2 to V3

[johan (Johan Stokking)]

@bluejedi

Not for users manually adding their (former) V2 devices to V3.

@neoaggelos @roman please comment on this.

@bluejedi

The console does not give any hints or instructions for this.It also does not make clear that all 8 frequenties must be entered.

We’re tracking this issue:

https://github.com/TheThingsNetwork/lorawan-stack/issues/3785

@bluejedi

What do you mean with ‘this’ here?

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.

@bluejedi

Is the configuring of the 5 other channels via MAC commands implemented in V3 but was not in V2?

Yes

---

On another note, @snejra made lots of progress on the migration documentation on thethingsnetwork.org/docs, see https://github.com/TheThingsNetwork/docs/pull/425

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

[bluejedi]

@htdvisser

1. Migrating a Few Devices

If you’re migrating a few devices, you can just do that in the Console:

@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?

[thomaswa]

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
  20:46:43
  Forward uplink message
• arrow_upward
  20:46:43
  Receive uplink message
  DevAddr
  26011DDF
  FPort
  1
  FCnt
  17685
  MAC payload
  D71319B22FC0665C
  Bandwidth
  125000
  SNR
  7
  Raw payload
  40DF1D012600154501D713

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

What should I do?

regards,
Thomas

[bluejedi]

@thomaswa

Host cluster failed to handle message: No device matches uplink

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).

@thomaswa

What should I do?

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.

[thomaswa]

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”: “type.googleapis.com/ttn.lorawan.v3.UplinkMessage”,
“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”: [
“gs:conn:01EYRN51XNNF4RGGC944H354CX”,
“gs:uplink:01EYSBGSQZHJ0E845VGTRKW8YT”
]
},
“correlation_ids”: [
“gs:conn:01EYRN51XNNF4RGGC944H354CX”,
“gs:uplink:01EYSBGSQZHJ0E845VGTRKW8YT”
],
“origin”: “ip-10-100-12-248.eu-west-1.compute.internal”,
“context”: {
“tenant-id”: “CgN0dG4=”
},
“visibility”: {
“rights”: [
“RIGHT_GATEWAY_TRAFFIC_READ”
]
},
“unique_id”: “01EYSBGSQZNXDD2SGSYV7DRBND”
}

But it says: No device matches uplink

[bluejedi]

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

[thomaswa]

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.

[htdvisser (Hylke Visser)]

@bluejedi

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?

Looks like I skipped that. Fixed.

[bluejedi]

@htdvisser

The Advanced settings must be set on registration. Changing these settings later may not work.

‘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?

[htdvisser (Hylke Visser)]

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.

[pe1mew (Remko)]

@htdvisser

And maybe it’s also triggered on an ABP frame counter reset if you’ve enabled those

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

[ceonuvathings (Joanquark)]

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?

[ceonuvathings (Joanquark)]

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”.

[pe1mew (Remko)]

@ceonuvathings

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.

[Jeff-UK]

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!

[ceonuvathings (Joanquark)]

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.

[roman (Roman Volosatovs)]

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.

[pe1mew (Remko)]

@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.

[roman (Roman Volosatovs)]

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.

[cslorabox]

@ceonuvathings

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 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.