正如您在问题的措辞中正确指出的那样，网关用于传输 LoRaWAN 下行链路消息的时间是非常昂贵的网络资源。在实践中，应用了几种技术来保持网关在发送下行链路消息上花费的时间较少：

• 对下行消息应用占空比规则。您可以在您的网络服务器上设置一条规则，规定不允许任何传输设备（网关和终端设备）花费超过总时间的特定百分比（例如：1%）。如果可以通过多个网关访问终端设备，则网络服务器可以选择剩余空闲占空比更多的那个。
• RX2 优化：
  与使用低数据速率的 RX1 接收窗口（例如：SF12）用于下行链路消息不同，网络服务器可以更喜欢使用具有较高数据速率（例如：SF9）的 RX2 接收窗口。这将缩短下行链路消息的播出时间。该技术可以有效地用于 EU868 频段，因为在 EU 中，RX2 接收窗口的 TX 功率为 500mW，而在 RX1 接收窗口中仅为 25mW。（具有 SF12,25mW 的 TX 与具有 SF9,500mW 的 TX 具有相似的链路预算）
• 上行数据包重复：
  您可以配置您的终端设备，而不是发送确认的上行消息（即要求 GW 发送下行确认），而是让您的终端设备使用相同的上行帧计数器值重复每个上行消息 2 或 3 次. 这些数据包将由网络服务器进行重复数据删除，这样数据包错误率将显着降低，从而无需 UL 确认。
• 安装更多 dence GW 网络：
  这总是有帮助的，因为终端设备将更接近网关，允许网关使用更高的数据速率进行通信。更高的数据速率总是导致更短的播出时间。

在 LoRaWAN 网络中，任何设备都可以请求确认，但默认情况下，完全取决于“网络服务器”来决定是否发送确认。高效 LoRaWAN 网络管理的规则不是 LoRaWAN 规范的一部分，取决于编码、配置和操作网络服务器的人员的专业知识。LoRaWAN 规范只给你命令、规则和杠杆来采取行动。

例如，可以通过以下方式避免网络崩溃或显着降低性能：

• 在几个“服务质量”类别中对设备进行分类
• 选择性地确认设备并优先考虑被认为“更重要”的设备
• 限制设备每天可以询问和接收的 ACK 数量
• 具有速率限制规则（每个网络、每个网关）并在超过某个阈值后立即丢弃对低 QoS 设备的 ACK 尝试
• 并不总是使用“最佳”网关来发送 ACK，而是使用目标设备“范围内”的另一个网关，但不是“关键”的网关（例如，看到很少或没有至少另一个网关也没有看到的流量)
• 关闭行为不端设备的流量
• 有足够的网关来实现适当的空间冗余
• 对低 QoS 设备使用更激进的“自适应数据速率”规则

对于许多简单的情况来说，“天真的”网络已经足够了，但是如果您想要可扩展性、可靠性和一些对攻击的免疫力，您必须超越大多数 LoRaWAN 网络服务器的“开箱即用”。这也不是火箭科学，我们谈论的是良好的实时指标、Python 脚本和一些人工监督:)

如果网络上运行的应用程序对每个下行链路都需要 ACK，那么它可以选择下行 CNF 消息。

终端设备可以在进一步的上行链路中搭载应用程序有效载荷和 ACK 位。这可以在终端设备所需的时间间隔内完成。