CC2530在Many to One 的通信模式，在使用过程中出现个别节点掉线，其他节点陆续掉线导致网络瘫痪

   在Z-Stack Developer's Guide.pdf手册中提到，在使用many to one模式时，为避免父节点掉线后重新恢复后，它的子节点无法正常通信的问题，需要配置zgRouterOffAssocCleanup该参数进行解决，如图所示

Viki Shi：

1、这个协议栈版本太低，建议升级版本。很多问题在新版本已经修复
2、MTO的应用建议参考TI文档— Breaking the 400-Node ZigBee® Network Barrier：www.ti.com/lit/an/swra427c/swra427c.pdf

VV：

这个主要跟关联表有关系，跟Many-to-one没有关系。

信道跳频可以实现，协议栈有现场的API可以使用，但是对于终端设备来说，可能存在休眠期间，不一定能够收到这个跳频的命令。

所以在终端设备上，需要有去其他信道搜索网络的功能。

user3684748：

回复 Viki Shi:

你好，Viki Shi ！

由于我们已经在之前ZStack-CC2530-2.3.1-1.4.0协议栈的基础上做了很多工作，所以暂时无法更新协议栈。所以我想问一下，Z-Stack Developer's Guide文中关于cleanupChildTable的描述，是否确实存在该问题呢？像我们这种已经用的旧版本协议栈的公司，该如何操作从而避免问题的发生呢？期待您的答复，谢谢。

YiKai Chen：

回复 user3684748:

這個確定是Zigbee spec存在的問題所以才會有R21 core spec出現修正、如果無法使用Z-Stack 3.0，建議device 在離網一定要發出leave request 並得到leave response 基本上可以避免問題

user3684748：

回复 YiKai Chen:

谢谢您的回复。

有两个问题需要请教一下：

1、该问题只是存在于终端设备，还是也存在于路由设备中？

2、作为终端设备或路由，从协议栈中如何判断设备掉线呢？能讲一下具体操作流程吗？谢谢

YiKai Chen：

回复 user3684748:

1. 路由设备如果是不正常離網也是會殘留在關聯表
2.协议栈中沒有定義如何判断设备掉线，建議在终端设备或路由设备應用程式中定期跟coordinator通訊，來判断设备掉线

user3684748：

回复 YiKai Chen:

谢谢回复。

如果不对路由或者终端设备进行离网判断，而是定时给协调器清除链路表，是否可行？在这种低版本的协议栈中，针对定时清除链路表是否有可行方案呢？

YiKai Chen：

回复 user3684748:

不建議定时给协调器清除链路表