In a LoRaWAN network, any device can ask for an acknowledgement, but with the tacit understanding that it's entirely up to the "network server" to decide if an acknowledgement will be sent or not. The rule for efficient LoRaWAN network management are not part of the LoRaWAN specification and depends on the know-how of the people coding, configuring and operating the network server. The LoRaWAN specifications only give you commands, rules and levers to act on.
For example, any collapse, or significant performance reduction of a network can be avoided by:
- categorizing devices in several "Quality of Service" classes
- selectively acknowledging devices and prioritizing the one that are considered "more important"
- limiting the number of ACKs a device can ask and receive every day
- having rate limiting rules (per network, per gateway) and dropping ACK attempts for low-QoS devices as soon as some threshold is passed
- not always using the "best" gateway to send ACKs, but another gateway "in range" of the target device, but one that is less "critical" (eg. see little or no traffic that is not also seen by at least another gateway)
- shutting down traffic for misbehaving devices
- having enough gateways for proper spatial redundancy
- using more aggressive "Adaptive Data Rate" rules for low-QoS devices
A 'naive' network is good enough for lots of simple cases, but if you want scalability, reliability and some immunity to attacks, you have to go way beyond what comes "out of the box" of most LoRaWAN network servers.
It's no rocket science either, we're talking good real-time metrics, Pythons scripts and some human supervision :)