Moving a device from Loriot to TTN

End Devices (Nodes)
1

One of my clients has deployed a number of devices (using OTAA) that are currently working with Loriot. Now they have set up a TTN gateway and added the devices with keys to the TTN console. The TTN gateway sees the messages from the devices, but the messages are not routed to the application.

I have read Different LoRa Servers which discusses a similar topic.

From what I understand, moving a device from one network (Loriot in this case) to another (TTN in this case) will require reprogramming of the devices to use new device IDs, because the Loriot device IDs are (naturally) not in the TTN address range. Is this correct? If not, is there some other limitation, or how can we move the devices?

2

Not for OTAA. Assuming the devices have been deleted from Loriot, a new OTAA Join Request will only be handled by TTN, and then TTN will supply new session keys and a new DevAddr (with the proper prefix for the TTN network) in its Join Accept.

However, your problem is: how to make the devices initiate a new OTAA Join.

See also How can an operational node be triggered to join a different network? but that’s too late for existing devices.

2 Likes
3

Thanks for your reply arjanvanb. Sorry for the late response.

We have now gotten information from the vendor that the devices use ABP. The vendor also claims the following:

  • the dev addr is optional when using ABP
  • the vendor has delivered devices with this dev addr prefix (0x14) to multiple networks, including Loriot and Blink Services and the devices work in those networks.

0x14 is KPN according to this list

The vendor’s information conflicts with the following:
From The Things Networks documentation for adding devices using ABP: “The device address will be assigned by the network server and is not customizable”

Laird documentation states that DevAddr is “End device address - Identifies the device within the current network”

I don’t see any reason for the device vendor to be intentionally misleading. Could it be that Blink Services and Loriot route all messages, regardless of dev addr prefix, but TTN doesn’t?

In any case, does anyone have a suggestion on how to move these devices to TTN? Doing a new ABP (or reprogramming the devices to use OTAA) is the only solution that comes to my mind.

1 Like
4

A device with an active session in a Network Server (Loriot in this example) can be migrated to another Network Server (TTN in this example) without the need of a new join or reprogram IDs or KEYs on the device.

This is not the cleanest way to migrate devices to a new server but it can be done if the donor Network Server (LORIOT) can provide the current session parameters DevAddr, NwkSKey, AppSKey… and importing it to the new Network Server (TTN) as an ABP device.

Steps in TTN:
1- In the web console add it as a new device, OTAA mode is only possible, type DevEUI, AppEUI and Apkey with correct values or whatever values.
2- Change the thevice settings to ABP mode, and type NwkSKey and AppSKey values provided from loriot. (DevAddr value can’t be changed from console).
3- use ttnctl to change device’s DevAddr with the value provided from loriot.

And that’s it. Now you can start receiving data in TTN server (even in both servers simultaneously).

BUT, there are some problems:
1- Downlink won’t work because the downlink counters will mismatch.
2- Some lorawan settings can be different between TTN and Loriot, for example channel plan, DL2 datarate…

2 Likes
5

Thanks nestorayuso! We do have access to all keys so we’ll try this.

6

Did you (recently) try that? Even if it works today, I’m quite sure it’s not a future proof way to do this. @htdvisser has been very clear about this:

Also, no downlink also implies no ADR.

And this is bogus:

And, yes:

Of course, but they should not?

Bummer. For ABP, TTN’s answer is clear; see Can I register an ABP device that has fixed DevAddr, NwkSKey and AppSKey? Also beware that the backend network stack version V3 is due, so don’t rely on hacks that work in the current V2…

2 Likes
7

We’ve tried nestorayuso’s suggestion. There were no error messages during the process, and the DevAddr is now the address starting in 0x14:

ttnctl-windows-386.exe devices set 140024be --dev-addr 140024BE --override
  INFO Using Application                        AppEUI=70B3D57ED0011CB1 AppID=export_data_watermeter_lora
  INFO Discovering Handler...                   Handler=ttn-handler-eu
  INFO Connecting with Handler...               Handler=eu.thethings.network:1904
  WARN Manually changing the DevAddr of a device might break routing for this device
  INFO Updated device                           AppID=export_data_watermeter_lora DevID=140024be
ttnctl-windows-386.exe devices info 140024be
  INFO Using Application                        AppEUI=70B3D57ED0011CB1 AppID=export_data_watermeter_lora
  INFO Discovering Handler...                   Handler=ttn-handler-eu
  INFO Connecting with Handler...               Handler=eu.thethings.network:1904
  INFO Found device
  Application ID: export_data_watermeter_lora
       Device ID: 140024be
     Description: 00115261
       Last Seen: never
    LoRaWAN Info:
     AppEUI: 70B3D57ED0011CB1
     DevEUI: 33530118126701B7
     DevAddr: 140024BE
     AppKey: <nil>
     AppSKey: 6897E9...1418275
     NwkSKey: 78D8DB...858C031
     FCntUp: 0
     FCntDown: 0
     Options: FCntCheckEnabled, 32BitFCnt

However, messages are still not routed to out TTN application so it seems this workaround didn’t work. Thanks anyway for the suggestion.

2 Likes
8

As you wrote your client has deployed a TTN Gateway, you should be able to see some debugging information in TTN Console. Like:

router ttn-router-eu drop reason: no brokers

image
image2006×1766 390 KB

1 Like
9

Yes, no brokers is what we’re getting.
image

10

We’ve verified that we’re getting “no brokers” also with a different gateway and two different devices.
ambiductor%2000115258 ambiductor%2000115259

Is there a way to further troubleshoot “no brokers”? Does it simply mean the device address is out of TTN’s address range?

11

As the Console also shows, the DevAddr of that message belongs to the KPN network. The “no brokers” message means that the DevAddr is from a range that isn’t currently assigned to any TTN cluster. We only route addresses from TTN-assigned sub-ranges starting with 26 or 27 and the “testing” ranges starting with 00, 01, 02 or 03. Also note that DevAddrs must be assigned by the network server. The only way application developers can assign DevAddrs of their choice, is to use the testing range. This is however not recommended, and the usual advice is: use OTAA.