ZigBee 网络中的自动链路故障检测方法

物联网 联网 能量消耗 紫蜂
2021-06-03 02:59:24

给定一个包含多个节点的 ZigBee 网状网络。每个节点之间通过路由器节点建立链接。

如果节点 A第一次节点 Z发送消息,节点 A必须执行路由发现以确定哪些中间节点将转发其消息。

此处描述路由发现机制根据它,具有最低成本的路由将存储在节点的路由表中。

到目前为止一切都很好,每个节点都知道要做什么,它们可以相互访问。


现在,节点 A节点 B之间的中间节点发生故障,因此当前存储的路由变得不可用。

在这种情况下会发生什么?我想当节点 A想要发送消息时,它会一直传播到断开的链接,在那里它会卡住。路由中的最后一个节点将发回有关失败的消息,这将触发节点 A的新路由发现,然后将找到一条新路由,一切都会恢复正常。

总体来说没问题(假设我是对的);网络恢复。但我想知道是否有任何算法或方法可以提供网络监控功能,以不断检查路由表中显示的链接状态。因此,节点 A可以在它想要向节点 Z发送另一条消息之前收到有关失败的通知,而不是陷入死胡同,它可以立即从路由发现开始。所以基本上我在想的是一种定期检查链接的服务。


我知道由于 ZigBee 通常用于电池供电的低功耗设备,因此这种机制并不节能。

那么总的来说,现在可用于低功耗无线传感器网络,尤其是 ZigBee 网状网络的最有效的链路故障检测机制是什么?

1个回答

根据我的发现,似乎某些实现(例如 TI 的Z-STACK)建议经常刷新路由表以避免“死”节点

是的,我等了 5 到 10 分钟。什么是“一段时间”?我见过需要几分钟才能恢复的情况。例如,如果我在网关上循环通电,最近的节点可能需要一两分钟才能连接,然后每个连续级别又需要一两分钟。但是我等待网格从这个路由变化中恢复的时间比这长得多。


是的,最多可能需要几分钟。那么,如果您想要 5 或分钟,您的设备会回来吗?建议定期调用 NLME_RouteDiscoveryRequest() 来维护路由表。

您可以NLME_RouteDiscoveryRequest()开发人员指南(请参阅第 11/12 页)中阅读有关功能的更多信息

下图显示了多对一路由发现过程的示例。为了发起多对一路由发现,集中器向全网广播多对一路由请求。收到路由请求后,每个设备都会为集中器添加一个路由表条目,并将转发请求的一跳邻居存储为下一跳地址。不会生成路由回复。

多对一路由请求命令类似于单播路由请求命令,具有相同的命令 ID 和有效载荷帧格式。路由请求中的选项字段是多对一的,目的地址是0xFFFC。以下 Z-Stack API 可用于集中器发出多对一路由请求。该 API 的详细使用请参考 ZStack API 文档。

ZStatus_t NLME_RouteDiscoveryRequest( uint16 DstAddress, byte options, uint8 radius )

ZigBee 无线传感器网络中的容错是一篇有趣的论文,其中包含有关 ZigBee 网络如何容忍节点故障的更多信息。当其中一个节点被移除时,那里使用的实现似乎重建了网络(不幸的是,具体方法尚不清楚),因此出现故障的节点不再包含在网格中。在某些情况下,这会导致传感器在请求通过不同的路由重新加入网状网络之前变得“孤立”。

总之,从我发现的资源来看这取决于您的实现,但大多数会合理频繁地重新评估路由表,以避免损坏的节点损害网络我怀疑如果您询问特定 ZigBee 实施的供应商,您将能够得到更准确的答复,因为确切的操作会有所不同。