Document why OTAA is better than ABP

[htdvisser]

Summary

We need to write some documentation that recommends OTAA over ABP.

Why do we need this ?

Until last week, we didn't, because most of our Cloud customers already use OTAA. However, we're now seeing a large number of TTN users starting to migrate devices to v3, and many of those are ABP.

What is already there? What do you see now?

There's a lot of documentation (in the wild) that uses ABP. This is mostly because it used to be easier (simpler) to start with ABP. There are also a lot of ABP devices on TTN v2 that will (hopefully not) get migrated to TTN v3.

What is missing? What do you want to see?

We need to document the limitations of ABP and explain why it's better to use OTAA.

How do you propose to document this?

• ABP devices use a fixed DevAddr
  • This means you can not switch to a different network or cluster.
    • Even if a network or cluster allows you to register end devices with an DevAddr that isn't assigned to the cluster, Packet Broker won't route traffic from that end device to the right cluster.
  • This means the Network Server can't optimize DevAddr allocation when additional blocks are assigned to a cluster. As a result, device matching will not improve for these devices.
• ABP devices use a fixed security session
  • This means that a device is EOL when it runs out of frame counters
  • This means that session keys can not be rotated if leaked
• ABP devices use fixed network parameters
  • This means that the RX1 delay, RX1 DR offset, RX2 DR index, RX2 Frequency and channel frequencies need to be customized, and registered on the Network Server. If not configured exactly right, uplinks/downlinks may not work, and this will be very difficult to debug.
• ...

Let's discuss what else we can say

[htdvisser]

Re: DevAddrs: here's how DevAddr blocks are currently routed:

V2 Cross-Region Routing Destinations (public clusters)

DevAddr Block	Cluster
26010000/16	TTN v2 eu
26020000/16	TTN v2 us-west
26030000/16	TTN v2 brazil
26040000/16	TTN v2 asia-se
26050000/16	TTN v2 switch CH
26060000/16	TTN v2 meshed AU
26070000/16	TTN v2 digitalcatapult UK

Packet Broker Routing Destinations (shared clusters)

DevAddr Block	Cluster
26080000/16	TTI Cloud Hosted eu1
26090000/16	TTI Cloud Hosted nam1
260A0000/16	TTI Cloud Hosted au1
260B0000/16	TTN v3 eu1
260C0000/16	Reserved for TTN v3 North America
260D0000/16	Reserved for TTN v3 Australia

[benolayinka]

@nejraselimovic can you see what's already in our docs and take on adding information in a place that people will see?

[nejraselimovic]

@nejraselimovic can you see what's already in our docs and take on adding information in a place that people will see?

Sure

[nejraselimovic]

Re: DevAddrs: here's how DevAddr blocks are currently routed:

V2 Cross-Region Routing Destinations (public clusters)
DevAddr Block Cluster
26010000/16 TTN v2 eu
26020000/16 TTN v2 us-west
26030000/16 TTN v2 brazil
26040000/16 TTN v2 asia-se
26050000/16 TTN v2 switch CH
26060000/16 TTN v2 meshed AU
26070000/16 TTN v2 digitalcatapult UK

Packet Broker Routing Destinations (shared clusters)
DevAddr Block Cluster
26080000/16 TTI Cloud Hosted eu1
26090000/16 TTI Cloud Hosted nam1
260A0000/16 TTI Cloud Hosted au1
260B0000/16 TTN v3 eu1
260C0000/16 Reserved for TTN v3 North America
260D0000/16 Reserved for TTN v3 Australia

Should this be included in the documentation?

[htdvisser]

I don't know if this should be the place to document what Packet Broker does. I definitely think that documenting v2 PCN DevAddr blocks is out of scope for the documentation site of The Things Stack.

[johanstokking]

I agree, let's scope this really to OTAA vs ABP.