How to Migrate ABP Devices from V2 to V3

kersing · May 3, 2021, 9:28am

Sounds like a bug/configuration issue. There are no gateways serving 36 channels so pushing all of them to a node would result in it transmitting on channels not being listened to for a fair amount of its transmissions.

@htdvisser is TTN really meant to be pushing 35 additional channels???

htdvisser · May 3, 2021, 1:32pm

No, that doesn’t sound right.

I’m not quite sure if/what advanced settings need to be set for US915/AU915 ABP devices. I actually thought that you didn’t need to set those at all, but I could be wrong.

And just for completeness, I’d like to repeat the first bullet point from the first post in this thread:

ABP is terrible; you can save yourself (and others) a lot of trouble by using OTAA.

descartes · May 3, 2021, 2:38pm

OTAA is terrible, you can save yourself a lot of trouble by using ABP when you are developing your firmware as you don’t have to reset DevNonces and wot not.

bluejedi · May 3, 2021, 8:55pm

That sounds like an opinion. ABP is part of the official LoRaWAN specifications however.
Users are much better served with an article where this is explained in detail and properly motivated.

Stating that “ABP is terrible” is not convincing and does not have any educational value because it lacks substance. Where can users find information with pros and cons about this?

You may be correct in your statement but I miss the motivation. What I can confirm though is that manually adding (‘Custom’) an ABP device in the console currently is a terrible and error prone process for the user, having to enter every single (advanced) setting manually for each and every device.

smbunn · May 3, 2021, 9:46pm

I think my post was misunderstood. I know how to get to ‘advanced settings’, my question was WHAT do I put into these settings for AU915 since the only example is for EU868.

Can I put in any value into RX2 data rate? anything at all?, Where would I find useful information on what is an appropriate value to use for AU915?

What RX2 frequencies are appropriate for AU915? There are a lot listed as transmit and receive,

AU915-928 
Uplink:

916.8 - SF7BW125 to SF12BW125
917.0 - SF7BW125 to SF12BW125
917.2 - SF7BW125 to SF12BW125
917.4 - SF7BW125 to SF12BW125
917.6 - SF7BW125 to SF12BW125
917.8 - SF7BW125 to SF12BW125
918.0 - SF7BW125 to SF12BW125
918.2 - SF7BW125 to SF12BW125
917.5 - SF8BW500
Downlink:

923.3 - SF7BW500 to SF12BW500 (RX1)
923.9 - SF7BW500 to SF12BW500 (RX1)
924.5 - SF7BW500 to SF12BW500 (RX1)
925.1 - SF7BW500 to SF12BW500 (RX1)
925.7 - SF7BW500 to SF12BW500 (RX1)
926.3 - SF7BW500 to SF12BW500 (RX1)
926.9 - SF7BW500 to SF12BW500 (RX1)
927.5 - SF7BW500 to SF12BW500 (RX1)
923.3 - SF12BW500 (RX2)

so do I put them all in?

Do I just put in 923300000 for RX2?

thanks

kersing · May 3, 2021, 10:45pm

Have you considered taking a look at the regional parameters?

From LoRaWAN regional parameters, chapter 2.5.7 AU915-928 Receive windows:

The RX2 (second receive window) settings uses a fixed data rate and frequency. Default parameters are 923.3Mhz / DR8

smbunn · May 4, 2021, 12:06am

So I put in RX2 rate as 8 and RX2 frequency as 923300000?
Plus I add in all 8 uplink frequencies and all 8 downlink frequencies?

kersing · May 4, 2021, 8:37am

Yes.

At least the 8 uplink frequencies. I’m not sure if the downlink frequencies need to be specified as well. (I’m in EU868 where those overlap so I can’t test)

smbunn · May 4, 2021, 11:38pm

I tried manually transferring one device across (I cannot use the trasnfer tool as all my devices are on ABP). It failed with a message that “Invalild value of field 'mac_settings.factory_preset_frequencies” and takes me to the box where you choose the frequency plan. I tried Australia 915-928 MHz, FSB 1 right through to FSB 8, and all fail with the same message.
It appears I should be using Australia 915-028 MHz FSB 2 but this fails

smbunn · May 4, 2021, 11:38pm

  "code": 3,
  "message": "error:pkg/networkserver:field_value (invalid value of field `mac_settings.factory_preset_frequencies`)",
  "details": [
    {
      "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
      "namespace": "pkg/networkserver",
      "name": "field_value",
      "message_format": "invalid value of field `{field}`",
      "attributes": {
        "field": "mac_settings.factory_preset_frequencies"
      },
      "correlation_id": "9dd945c7a84c426c88fd97288ee264c3",
      "code": 3
    }
  ],```

htdvisser · May 5, 2021, 7:12am

Here’s our documentation page on ABP vs OTAA:

https://www.thethingsindustries.com/docs/devices/abp-vs-otaa/

descartes · May 5, 2021, 9:01am

We strongly recommend people use ABP for development.

It’s not terrible, it’s just not the best for deployment.

clv · May 8, 2021, 6:27pm

I am pretty sure I read many times here the recomendation that an OTAA device must be join only once in a lifetime. So in reality the ABP vs OTAA comparison has value only for roaming and not for security.

The real problem is that ABP projects don’t support MAC downlink commands. I don’t get this statement. How an OTAA device knows the RX1/2 Delay (e.t.c.) and ABP does not?
" When registering an ABP device on The Things Stack, you will need to provide the RX1 Delay, RX1 Data Rate Offset, RX2 Data Rate Index, RX2 Frequency and a list of Factory Preset Frequencies. If these values are not correctly configured, uplinks and/or downlinks might not work."

I don’t like to type even 8. So I prepared a script WORK IN PROGRESS to semi-automate the procedure via CLI.

I abandoned all my LoRa projects. I hope I will restart them soon to update the script.

descartes · May 8, 2021, 8:38pm

I’m not seeing where it says that. But I agree the document feels unscientifically biased towards OTAA, particularly with some scare mongering like:

“When an ABP end device runs out of frame counters, it is the end of its lifetime.”

With 32 bit counters, that would be a mere 4,294,967,296 uplinks. I’m sure I’ll cope with that.

Great script BTW.

Please don’t lose faith, the ABP ‘challenge’ was noted early on, has been well discussed over the forum and I for one have two other solutions as work in progress to add to yours.

AndyG · May 8, 2021, 9:44pm

I have since found a solution to the problem that was driving me towards ABP.

V3 OTAA on AU915 with the Heltec boards I am using is sensitive to the Regional Parameters Version. I had to select “PHY V1.0.2 REV B” to get OTAA to work. Kudos goes to @bwooce for debugging and finding the solution for that one.

I now get an immediate join with my test device on V3. I only have a few nodes, all DIY. It is not going to be an issue to reprogram the rest to OTAA when I migrate them to V3.

clv · May 9, 2021, 6:30am

@descartes if I remember properly (I want to re-read the protocol 2-3 times) the frame counter is always 16bit and the interpretation is done on app / whatever server.

I don’t get your disagreement about ABP. Most of the projects with ABP don’t support MAC downlinks, since most of them don’t use LMIC. That is my view. If not, even worse for the “better” OTAA in usage.

Sorry I have language barrier (not native English) so maybe I can’t express it properly. As I understand it, OTAA is better for security if your are paranoid and you reset the device (something is NOT recommended and I agree) and a necessity (?) for roaming.

descartes · May 9, 2021, 8:42am

It is 16 bit on the device but can rollover 2^16 times - I’m a bit fuzzy on the actual details and implementation, but I do know I have a test device on ABP on 105936 uplinks so I know the rollover works!

I don’t know what the spread of library usage is - I can imagine that there are quite a few TinyLoRa etc ABP devices in the maker community that would be a wasted if they can’t carry on. The settings are there for us to continue to use them, we just need to make it a lot simpler to setup on v3!

The LoRaWAN Alliance FAQ pdf on security is a little less biased but does outline how OTAA is more secure. Technically ‘roaming’ is the correct word, as that’s what we think of with mobile phones etc, but the reality is that a device won’t roam, that’s the job of a packet forwarder to sort out. What TTI mean by roaming is actually switching host network. This you can only do with OTAA and only if your OTAA device is clever enough to notice it hasn’t got a valid session running OR you can send it a re-join command.

We are well aware that TTI want their offering to be the flagship stack - and that comes with changes that aren’t convenient to the more casual user - but the tools are there so we can make it happen.

kersing · May 9, 2021, 11:07am

For modern (last 3-4 years) LoRaWAN stacks the frame counter is 32 bit. The transmitted packet contains only the lower 16 bits of the packet but all message integrity check (MIC) uses all 32 bits.

jpmeijers · May 9, 2021, 2:30pm

I find that the updated docs are less opinionated about OTAA vs ABP:

github.com

TheThingsNetwork/docs/blob/master/doc/content/devices/bestpractices/_index.md

---
title: Best Practices
weight: -100
---

If you've been using development devices, you might want at some point to transition to production-grade device development. Here are best practices for you to build devices that will last in the long-term, and that will help you achieve [LoRaWAN compliancy](https://www.lora-alliance.org/lorawan-for-developers).

## Device activation

### OTAA and ABP

LoRaWAN offers two methods of device activation: **OTAA** (Over The Air) and **ABP** (Activation by Personalization). OTAA is the **preferred method** to join any LoRaWAN network, including the Things Network: it offers more security, more flexibility, as well as scalability.

+ **Security**: OTAA is more reliable because the activation will be confirmed, and more secure because the session keys will be negotiated with every activation.

+ **Flexibility**: Configuring your device with OTAA gives you the liberty of changing the network server by re-registering a device on a different network server, and by performing a re-join. The new network server will then attribute to this device a `DevAddr` that will be part of its address space, and the device will be interacting with the new network server without reprogramming.

    ABP devices need the `DevAddr` to be registered in the device by another way - usually hardcoding. This means the device is tightly coupled to the network server, and even more to the specific activation. Although network servers are designed to keep activations in permanent storage, there can be situations where a device needs to rejoin - in those cases, ABP devices need to be reprogrammed.

+ **Scalability**: On select regional bands, when a device performs activation, the network server answers with a list of additional frequencies the device can use to exchange messages. This means the device doesn't have to use only the default regional bands, but also the ones defined by the network server operators.

This file has been truncated. show original

It might however be worth stating the facts to tell where ABP is better, and where OTAA is better.

For me the most important thing is that I need to switch a GPS tracker on in any location. Therefore also places without coverage. If this device uses OTAA it will never work. Using ABP the device can switch on and start transmitting packets, and as soon as it comes into range of the network, these packets will be received and forwarded to the application.

One can however argue that using OTAA for a GPS tracker, and persisting the session, restoring it after startup, will also work. But this complicates the design of the hardware. Using ABP with a frame counter that resets is a very easy piece of software that can be written by hobbyists.

descartes · May 9, 2021, 3:09pm

Those are the version 2 docs.

We are/were enjoying the v3 docs: https://www.thethingsindustries.com/docs/devices/abp-vs-otaa/

The new rampant rabbit MAC command processor will flood your ABP device with ADR requests, particularly if you have told the device to stay fixed to DR5 as you recommend - at present ADR can only be turned off using the CLI