如果节点A希望第一次向节点Z发送消息，则节点A必须执行路由发现以确定哪些中间节点将转发其路由。消息。
此处描述了路由发现机制。根据它，成本最低的路由将存储在节点的路由表中。
到目前为止，一切都很好，每个节点都知道该怎么做，它们可以相互到达。 >
现在，节点A和节点B之间的中间节点发生故障，因此当前存储的路由变得不可用。
这种情况下会发生什么？我可以想象，当节点A要发送消息时，它将一直传播到断开的链接，并在该链接中被卡住。路由中的最后一个节点将发送回有关失败的消息，这将触发节点A进行新的路由发现，然后将找到新的路由，一切都会恢复。
通常很好（假设我是正确的）；网络恢复。但是我想知道是否有提供网络监视功能的算法或方法，可以连续检查路由表中显示的链接状态。因此，可以在希望向节点Z发送另一条消息之前将其通知给节点A，并且可以立即从路由发现开始，而不必陷入僵局。因此，基本上我想的是一种定期检查链接的服务。
我知道，由于ZigBee通常用于电池供电的低功耗设备，因此这种机制应该
那么总的来说，现在可以在低功率无线传感器网络（尤其是ZigBee网状网络）中使用的最有效的链路故障检测机制是什么？
#1 楼
从我发现的结果来看，似乎某些实现（例如TI的Z-STACK）建议每隔一段时间刷新一次路由表，以避免出现“死”节点：是的，我等了5至10分钟。什么是“某个时间”？我看到了需要几分钟才能恢复的情况。例如，如果我打开网关的电源，则最近的节点可能需要一两分钟才能连接，然后每个连续级别又需要一两分钟。但是我等待的时间比这要长得多，以便网格可以从此路由更改中恢复。
是的，这可能要花费很多时间。因此，如果您需要5分钟或5分钟，设备会回来吗？建议定期调用NLME_RouteDiscoveryRequest（）来维护路由表。
您可以在开发人员指南（请参阅第11/12页）中详细了解
NLME_RouteDiscoveryRequest()的作用：下图显示了多对一路由发现过程的示例。为了启动多对一路由发现，集中器将多对一路由请求广播到整个网络。收到
路由请求后，每个设备都会为集中器添加一个路由表条目，并将中继请求的一个跃点邻居存储为下一跃点地址。
多对一路由请求命令类似于单播路由请求命令，具有相同的命令ID和
有效负载帧格式。路由请求中的选项字段为多对一，目的地址为0xFFFC。 Z-Stack API后面的
可用于集中器发送多对一路由请求。有关此API的详细用法，请参阅ZStack
API文档。
ZStatus_t NLME_RouteDiscoveryRequest( uint16 DstAddress, byte options, uint8 radius ) ZigBee无线传感器网络中的容错是一篇有趣的论文，其中包含有关ZigBee网络如何容忍节点故障的更多信息。看来，当其中一个节点被删除时（不幸的是，确切的方法尚不清楚），在那里使用的实现方式重构了网络，因此故障节点不再包含在网格中。在某些情况下，这导致传感器在请求通过另一条路径重新加入网状网络之前变为“孤立”状态。
总而言之，根据我发现的资源：这取决于您的实现，但是大多数将合理地频繁地重新评估路由表，以避免损坏的节点损害网络。我怀疑如果您询问特定ZigBee实现的供应商，您将能够得到更准确的答复，因为确切的操作会有所不同。