ABP vs OTAA type sensors for big deployment

Viewed 7

Hi all,

Planning a LoRaWAN deployment of ~20,000 battery-powered meters — static placement, wide-area coverage, ChirpStack v4 backend.

For a fleet of this size and profile, does ABP run into real problems at scale, or should OTAA be considered mandatory?

Main concerns are frame counter resets on device reboots, DevAddr management across batches, and the inability to rotate keys without site visits. But I'd rather hear from people who've actually run deployments at this scale either way.

Thanks!

1 Answers

Personally, I would avoid ABP where possible. In my opinion the biggest issue is that if the device power-cycles / reset, you run into frame-counter issue and unknown state of the device.

On OTAA, ChirpStack will reset its internal knowledge of the device to the default state after OTAA (e.g. RX1Delay, channel / channel-mask, etc...). With ABP if a device resets, you can do this either by disabling frame-coutner validation (which causes security issues) or by re-activating the device through the API (which requires your own logic).

Then if you have your own NetID, most likely the ABP devices will have a DevAddr that does not match your NetID, making filtering on data impossible.