This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CC2652R:有关下电上电的邻居表

Guru**** 1133960 points
Other Parts Discussed in Thread: Z-STACK
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1329244/cc2652r-neighbor-tables-on-power-cycle

器件型号:CC2652R
主题中讨论的其他器件:Z-STACK

您好!

我们发现由55个路由器和一个协调器组成的大型网络存在问题、所有这些路由器和协调器都在同一个 Zigbee 网络上并且距离很近。  如果我们关闭5台路由器、并让其他路由器和协调器保持运行几分钟、当我们再次启动5台路由器时、5台路由器会发送一条路由发现消息、以尝试向协调器发现路由。  没有其它路由器重新广播路由请求,协调器不发送路由应答。

我们有一个相对较旧的 SimpleLink CC13X2-CC26x2 SDK 版本、版本4.20.104。  我们确实有迁移到更 新版的计划、但短期内不会这样做。

我们有一个理论,为什么发生这种情况,并赞赏任何建议的修复。  我们注意到50台路由器中的链路状态消息没有关闭的5台路由器的短地址。  由于5台路由器不在任何邻居表中,因此可能50台路由器不会重新广播路由发现数据包,因为它们看不到这些路由器作为邻居。  同样、协调器可能不会发送路由回复、因为它不会从任何知道的邻居接收路由发现广播。  当它从关闭的5个路由中的一个接收到路由发现广播时、它也不会在自己的邻居表中显示其地址。  (50个路由器全部重新广播从50个路由器中的一个发出的罕见路由发现命令,并且协调器向这些命令发送路由应答。)  我确认路由器具有相同的 PAN ID、网络密钥、网络密钥序列号等。  在为5加电后让网络运行数分钟。  在这几分钟内,其他50台路由器中的链路状态消息似乎根本没有变化。

这是 TI 堆栈中的一个已知错误吗?  或者、我们是否可以启用某个设置来使堆栈将较晚的节点添加到邻居表中?  它们似乎处于被排除在网络其余部分之外的状态。

我们正在考虑添加自己的代码、以便偶尔从邻居表中删除1或2个条目、以帮助设备进入其他路由器的邻居表。  但是、如果有任何更好的解决方案、或者缺少堆栈设置、我们将感激您能有任何其他方向。

我们的邻居表大小为16个条目、我们的网络可扩展到100多台路由器、因此我们不希望仅仅扩大网络表。  此外、我们目前也不对多对一和源路由感兴趣、也不能提供支持。  (说来话长。)

提前感谢、

格兰特中国有限公司

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Grant:

    感谢您提供系统行为的完整描述。  提供用于演示问题的监听器日志可能也会有所帮助。  但是、您所描述的行为是在 Zigbee 协议和 Z-Stack 网络配置的边界内预期且可能发生的。  由于附近有大量路由器并且禁用了源路由,因此路由器的网络表已完全填充是可行的。  在这些情况下,由于没有更多表空间来添加更多条目,因此不会重新广播来自重新加入的路由器的路由发现。

    如前所述、可以 增大 MAX_SHIFTER_ENTRIES 来容纳更多的邻居。  这是可行的、但您应注意靠近太多路由器并造成广播风暴。  是否可以对其中一些器件使用 ZED 而不是 ZRS?  您还可以降低 good_link_cost (也在 NWK_globals.h 中)的值、以便 在将路由器添加到本地邻居表之前限制传入链路状态消息的质量。 nwk_util.h 文件包含多个 API,如有必要,您可以在应用程序中使用这些 API 直接修改邻居表。

    此致、
    瑞安

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    感谢您的答复!  我们在当前架构方面的距离已经足够远、以至于我们无法将其中的某些器件转换为终端器件。  我们能够实施一种简单的算法来在表已满时定期删除一个邻居表条目、这似乎解决了我们的初始问题。


    我们现在看到的情况是、某些数据包似乎被协调器丢弃。  作为简单的背景介绍、我们正在运行一个包含30台路由器的测试网络。  路由器向协调器发送周期性数据包,但它们没有启用 APS 确认。  (不详细介绍、现在启用确认并不是可取或必要的解决方案。)  该协调器的邻居表大小为16、路由表大小为40。

    在发生故障的情况下,一台路由器能够建立通过另一台路由器跳过并可靠地到达协调器的路由。  但出于某种原因、该路由器有时会开始直接向协调器发送数据包。  当它直接路由到协调器时、协调器发送一个 MAC 确认、但是数据永远不会进入应用程序代码。  似乎协调器的堆栈正在丢弃数据包。  当路由器最终再次通过1跳路由器路由数据时、协调器应用会接收数据。

    我了解路由为什么会发生变化。  当路由器直接路由到协调器时,路由器的链路状态广播将该协调器包括在邻居列表中,因此该协调器位于路由器的邻居表中。  当路由器通过另一台路由器路由时,路由器的链路状态消息显示该协调器不在邻居列表中。  这是有道理的、因为我猜路由算法会直接路由至邻居节点、或者在目标不是邻居的情况下使用路由表。

    那么我们面临的一个大问题是、当数据包直接从路由器接收时、什么会导致协调器丢弃该数据包?  我确认路由器不在协调器的邻居表中。  如果发送方不在邻居表中,路由器是否会丢弃直接数据包?

    另外,什么会导致协调器进入路由器的邻居表?  我们并不是根据我的经验将它添加到我们的应用中。  堆栈是否具有在某些情况下(Rx 广播数据包、Rx 链路状态等)尝试将协调器添加到路由器邻居表中的代码?  如果可以、我们是否可以禁用该代码?  另外,似乎是某种原因导致协调器的地址从邻居表中删除(允许路由器继续使用单跳路由,这是成功的)。  堆栈可能看到路由器不在协调器的链路状态消息中并将其删除?

    此致、

    授予

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Grant:

    您确定了正确的问题:路由器链路状态将协调器视为有效的邻居并直接发送数据包、而协调器链路状态不将路由器视为有效邻居、因此丢弃数据包。

    Z-STACK 布线层并不为协调器创造特殊条件。 路由经过了4.20版的改进、但您解释说目前无法迁移。

    要解决此问题、您可以增加协调器的邻居表、降低路由器的良好链路成本、 或者、如果您可以从路由器应用程序检测到问题(或从邻居表中删除协调器)并尝试再次发送数据包、则将路由器的路由请求发送到协调器。

    此致、Ryan