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)
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
"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
}
],```Here’s our documentation page on ABP vs OTAA:
https://www.thethingsindustries.com/docs/devices/abp-vs-otaa/
We strongly recommend people use ABP for development.
It’s not terrible, it’s just not the best for deployment.
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.
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.
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.
@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.
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.
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.
2 Likes
I find that the updated docs are less opinionated about OTAA vs ABP:
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.
1 Like
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
Last time I checked the specification there was an ADR bit in the packet header specifying if the network could control the nodes data rate. If it is not set the backend should not send any ADR command. So the node can signal the network it won’t do ADR and the stack has to refrain from sending ADR MAC commands, no need for cli commands.
As far as I know I linked to the latest docs on github - last edited 6 days ago. But clicking on the “edit on github” link takes me to GitHub - TheThingsIndustries/lorawan-stack-docs: Documentation for The Things Stack (last edited 4 days ago), not to GitHub - TheThingsNetwork/docs: Documentation for The Things Network. Yet another very confusing thing about the migration from v2 to v3 
Yup, makes sense that it makes no sense.
I shall look in to it at LMiC and the various modules I have, but I think this is probably going to be a little esoteric for many makers.
The console has come a long way since this guide was written. When registering an ABP device I now see an option:
My expectation from this is that the 8 frequencies should be automatically set depending on which frequency plan I chose at the top.
I’ve registered a device to test, but I do not see any “Factory programmed frequencies” set in the advanced network settings. Packets are however received, unlike in the past when they were dropped when the frequencies were not set.
What is the current expected behaviour, and do we still need to manually set the factory programmed frequencies for ABP devices?
Hi, first post on this forum. It seems my problem fits the topic.
I am trying to migrate ABP devices from V2 and I can’t make it work. However I could migrate the same kind of devices without any problem a few month back (let’s say April 21).
I check the config of my previously migrated devices and it is the same as the devices I want to migrate now.
Since the UI has changed (missing reset frame counter checkbox) I was wondering if something changed in the device creation or if I am missing something new ?
What I did step by step:
- Create device from the V3 console carefully copying devAddr AppSKey and NetSKey from V2
- Changed keys on V2 to avoid Network server conflicts
- Realised I doesn’t work
- Realise I did not check “reset frame counter checkbox” because it is not available in the console anymore
- Remove the device from the console
- Create device with CLI
- Still don’t work
- Asking the community
This is what is used to create my device from the CLI:
ttn-lw-cli end-devices create myapp mydevice \
--frequency-plan-id EU_863_870_TTN \
--lorawan-version 1.0.2 \
--lorawan-phy-version 1.0.2-b \
--abp \
--session.dev-addr 111111 \
--session.keys.app-s-key.key 11111111111111112222222222222222 \
--session.keys.f_nwk_s_int_key.key 11111111111111112222222222222222 \
--dev-eui 1111111111111111 \
--mac-settings.factory-preset-frequencies 868100000,868300000,868500000,867100000,867300000,867500000,867700000,867900000 \
--mac-settings.resets-f-cnt=true \
--mac-settings.supports-32-bit-f-cnt=true \
--mac-settings.rx1-data-rate-offset 0 \
--mac-settings.rx1-delay RX_DELAY_1 \
--mac-settings.rx2-data-rate-index DATA_RATE_3 \
--mac-settings.rx2-frequency 869525000
Is there option for migrationg many ABP devices to V3? The post above says
[to be added later]
I was trying to add some of my V2 gateway in V3 console without success. Now I will have 4 scrap gateways. I bought new mikrotik console and registered in V3. I hope I could migrate devices now… Could soumeone point to the correct instructions for batch migrate (looks like I will have a bunch of useless devices soon)… ???