LoRaWAN 终端设备必须处理 2 种不同类型的网络连接问题：

1. 设备暂时失去网络连接。
   这可能发生在以下示例情况中：
   • 移动设备当前位置没有网络覆盖
   • 固定设备区域出现临时网络中断。（例如：应该为设备提供服务的 LoRaWAN 网关丢失了回程连接。）
2. 网络服务器丢失了设备的会话上下文（AppSkey，NwkSkey）。
   这可能发生，如果
   • 网络服务器出现不可恢复的数据库故障，或者新服务器在不提供会话连续性的情况下接管旧服务器的角色。
   • 或者所有者只是从网络服务器中删除了设备并重新配置。

失去网络连接

设备有 2 种方式检测网络连接暂时丢失：

• 如果 ADR 开启：在 ADR_ACK_LIMIT 上行链路没有跟随下行链路之后，它将其上行链路帧的 ADRACKReq 位设置为 1，告诉网络它期望在下一个 ADR_ACK_DELAY 帧内有一个下行链路帧。
• 在任何情况下：终端设备可以向网络发送LinkCheckRequest MAC 命令，网络必须通过LinkCheckAns MAC 命令回答该命令。

如果设备检测到（以任何方式）网络不可用，它应该首先尝试以尽可能低的数据速率发送上行链路消息（例如：LinkCheckReq消息）（这会将链路预算增加到最大值），如果它仍然没有解决连接问题，设备应该以指数方式回退连续的上行链路消息。在实践中，终端设备更倾向于发送新的 JoinRequest 消息而不是基本的 UL 消息。下一章解释了原因。

丢失会话上下文

在 LoRaWAN 1.0 网络中，如果网络服务器丢失了会话上下文，重新连接设备的唯一方法是让它发送新的加入请求。
但是，设备无法检查其网络连接问题是由于网络临时中断还是会话丢失所致。（两者都导致没有下行消息。）此问题的解决方案是，如果出现任何长期连接问题（无法通过降低数据速率来解决），设备开始发送新的加入请求消息，这将使网络服务器启动一个新的会话上下文并重置帧计数器。

这个“丢失会话”问题由 LoRaWAN 1.1 网络以更好的方式管理。LoRaWAN 1.1 引入了一种新的消息类型：Rejoin-Request。终端设备会定期发送Rejoin-Request Type 1 消息，这为网络服务器提供了一个选项，通过使用 Join Accept 消息来回答它们来创建新的设备会话。然而，如果网络服务器仍然有一个有效的会话，它会悄悄地丢弃这些消息。此解决方案可防止在出现连接问题时触发对有效设备会话进行不必要的重置，并提高安全级别。

这是 Abeeway 品牌跟踪器的详细行为。

网络超时监控

没有收到来自网络的任何下行通信是一个严重的症状。这可能意味着跟踪器与网络隔离，不再在该网络中活动，或者设备 LoRa 无线电（或其 MCU 驱动程序）可能变得不稳定。设备无法知道网络缺少下行链路通信是由于问题引起的，还是仅仅是因为网络或应用服务器无话可说。为了解决这个问题，LoRaWAN MAC 提供了LinkCheckRequest。

在 Abeeway 跟踪器上提供以下参数：

• network_timeout_check：一旦此持续时间过去，跟踪器就会向所有 LoRaWAN 上行链路预先发送链路检查请求（以强制网络触发下行链路）。每次接收到 LoRaWAN 下行链路时都会重新启动相关的计时器。
• network_timeout_reset：该持续时间涵盖链路检查请求周期。一旦在没有链接检查答案的情况下过去，跟踪器将假定存在问题并将重置。这将导致设备尝试重新加入。我们建议保持这种行为，因为这是确保孤立设备最终在网络中产生非常低的寄生流量的唯一方法（因为加入指数退避）。

示例：
network_timeout_check= 172800 秒（2 天）
network_timeout_reset= 86400 秒（1 天）
如果 2 天后跟踪器没有收到任何下行链路，则启动链路检查请求过程。经过 1 天的链接检查请求过程没有答案，跟踪器将重置。

跟踪器接收到的任何下行链路都会重新启动计时器/机制。如果在相应参数中设置零值，则此看门狗功能将被禁用。

加入和指数退避

LoRaWAN 规范强加了加入的占空比（适用于所有区域），旨在避免网络在流量风暴中被锁定。

占空比回退适用于每个频段。例如，IN865 区域使用单个频段：BAND0。

• 在第一个小时内，占空比 = 100 。
• 在第一个小时和接下来的 10 个小时之间，占空比 = 1000 秒
• 超过 11 小时，占空比 = 10000 秒

Abeeway 跟踪器遵循 LoRaWAN 规范，但是，按下按钮将跳过应用程序级别的等待计时器并立即触发 Join。由于这是用户触发的操作，因此不会引起消息风暴。