[参考译文] CC2652R：ZNP 收到消息，但似乎没有处理该消息

尊敬的 Akhilesh：

感谢您提供监听器日志。  某些器件会丢失数据包、例如来自 ZC 的链路状态消息、如跳过的 MAC 序列数据包编号中所示。  这可能是由于这些节点和监听器件之间的距离所致。

您是否仍具有与上一主题相同的设置、或者是否已升级 SDK？  我建议将 SRC_RTG_EXPIRATION_TIME 设置为有效设置(如果尝试关闭、则为0xFF)、因为会意外设置零、并在存在内存限制的情况下将 CONUSTER_ROUT_CACHE 设置为 FALSE。  我还建议将  MAX_RTG_SRC_ENTRIES 设置 为最大值255。

在当前条件下、源路由表已完全填充是可行的、因此 ZNP 集中器无法为 0x8B23添加路由、从而丢弃从该节点接收到的数据包。

此致、
Ryan

您好、Ryan、

由于距离或消息重叠、可能会错过序列号、这是因为网络相当大、而且有一些地方集中了设备(例如4-5个设备、彼此之间距离不足1米)。

我们仍在使用以前的 SDK。 我们将更新到较新的 SDK、并在调试代码的同时尝试建议的更改以观察器件的路由记录。

此外、我们的 MAX_RTG_SRC_entries 也为200、此处网络中包含大约180台设备。 设置此值是否会产生影响？ 桌子是否有其他方式可以被填满?

谢谢
Akhilesh

您好、Ryan、

是否有可能

Unknown 说：

此外，我们的 MAX_RTG_SRC_entries 也是200台，我们在这个网络中拥有大约180台设备。 设置此值是否会产生影响？ 表是否有任何其他方式可以获得完整？

我将根据我们在此处的讨论以及该主题中的讨论、设置改进的 ZNP 和路由器定义
https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1215285/cc2652r-device-taking-too-long-to-initialize-start-up

将分析 100多个设备网络上的行为并对您进行更新。

谢谢
Akhilesh

很抱歉响应出现延迟。  如果路由未设置为"已过期"，则当新路由需要更多空间时，不会将其删除。  您可以在 《Z-Stack 用户指南》的"布线"部分中阅读有关此内容的更多信息。  请确保相应地设置有效的 SRC_RTG_EXPIRE_TIME 和 MTO_ROUT_EXPIRE_TIME 值、此外、如果能够、还应将 MAX_RTG_SRC_ENTRINTS 增加到最大值255。

此致、
Ryan

您好、Ryan、

我们能够重现并确定单播未得到处理的问题。

基本上、问题在于某个器件(C)不是 ZNP (HUB)的邻居表/关联列表的一部分、因此每当从该器件接收到消息时、该消息都会被忽略。 集线器正在使用邻居向设备发送消息。

hub->neigbour>c.
C->集线器 (集线器不进行处理、因为邻居表中没有 linkInfo)。
C 由于 MTO 的原因具有到集线器的路径、连续的 MTOs 也导致相同的直接链接和相同的重复。

我们当时正在考虑增加邻居表的大小,希望了解其后果。

谢谢
Akhilesh

尊敬的 Akhilesh：

您提供的行为说明是合理的。  ZC 将丢弃 ZR 的直接消息，但该消息尚未记录在其邻居表中。

您增加邻居表的目的是什么？  这将增加要补偿的路由表、NV 和 SRAM 要求。  实际上、 考虑到众多邻居、这可能效率低下、并且可能会使器件处理更加紧张。

相关的 ZR 器件是否使用 TI Z-Stack 器件？  理想情况下、发送路由记录或网络路由请求以了解将数据包路由到 ZC 的最佳方式。    ZC 上的 MAX_RTG_SRC_ENTRIES 和 SRC_RTG_TIMEOUT_TIME 是什么？  

您好、Ryan、

对于此设置、我们的器件数为~130个器件。
当前邻居条目大小为100。

我理解,进一步增加这一规模将影响组播行为,这是一个问题。 我想了解是否有其他选择。

所有器件均为 TI Z-Stack 器件。 设备在此单播消息之前以路由记录发送。 路由记录是直接链接。
MAX_RTG_SRC_ENTRIES 为200
SRC_RTG_DEVERY_TIME 为0

请告诉我任何建议的更改、可以进行检查、因为我现在能够始终如一地重现问题。

谢谢
Akhilesh

ZC 是否确认路由记录、您是否可以提供此交互的监听器日志？  您需要确定路由记录为何不影响 ZC 处理传入 ZR 数据包。  我建议您将  SRC_RTG_TIMEOUT_TIME 增加 到有效秒数、我建议在2到10之间。  这是一个 类似的 E2E 主题。

此致、
Ryan

您好！

--

是的，问题似乎与建议的主题相似？ 最终分辨率是多少。 我们启用了 MTO。

--

是的、路由记录已确认(MAC ack)。 请查看此问题说明随附的监听器。 该行为与此相同、由于设备不属于邻居条目、因此不处理路由记录消息。

这会触发 MTO。

在触发消息时、会触发路由请求、并在路由表中生成和更新路由回复。 它使用中间节点。
ZC ->中间节点-> ZR

传入消息通过源路由(连同路由记录)发送
路由记录(MAC 已堆叠、未处理、srcRoutingTable 未更新)
zr->ZC (MAC 已加载、未处理)

MTO 被触发
路由记录 MAC 已堆叠、但未处理并重复上述过程

***已将 SRC_RTG_EXPIRATION_TIME 更新 为10、但仍然会发生相同的情况。

我还观察到在多个 MTO 之后,路线记录使用了中间装置。
因此 src 路由记录(中继计数=0、直接)更改为路由记录(中继计数=1、有效的中间节点)、通信稳定。

在上述情况下，会将路由记录生成到中间设备，然后将路由记录发送到父设备。

这是在我将 ZNP 减少到10个邻居之后发生的,所以我的理解是,在 ZR 上, ZNP 被移除作为 neigbour ,因此通过中间设备发送路由记录。
虽然我无法理解为什么会发生这种情况、因为我在几分钟后尝试过的另一款设备没有发生这种情况。

自问题在此重现以来、一直在4.40上测试此问题、将在6.10上执行相同的操作以查看其是否仍然存在。
请提供有助于更好地处理这种情况的任何建议。

谢谢
Akhilesh

第439行,第439页
e2e.ti.com/.../mto_5F00_reset_5F00_rename_5F00_to_5F00_cubx.txt

我将与软件开发团队讨论、以进一步了解该行为。  似乎路由最终会起效，您的问题是所需时间还是在问题发生期间发送的消息数量？  据他们所知、 如果启用了对称链路功能(默认情况下启用)、那么如果协调器的邻居表中没有 ZR、则 ZR 不应向协调器发送消息。  如果您可以验证此问题在更新的 SDK 中是否仍然存在、则会有所帮助。  最终分辨率如之前的 E2E 主题中所示。

此致、
Ryan

您好、Ryan、

我在将 ZNP 移植到6.10的过程中遇到了一些问题。 现在可以运行了。

即使在6.10 SDK 上、此问题也可以重现。 当我将邻居表减少到较小的数字时、问题很容易重现、在本例中、我将其减少到20、但几乎有100个设备(所有路由器)足够接近 ZNP 的邻居

此外、我还观察到在4.40 SDK 和6.10 SDK 之间、堆在 app.cfg 中从动态更改为静态。 此问题引起了一些问题。

1.你建议堆的配置是什么?
如果是静态的，那么首选的大小是多少，或者应该考虑哪些参数来决定这一点？
当前设置为静态和32KB

2.这些堆设置是否会影响消息处理? 消息处理会变得更慢、因为它们可能是在运行时等位置分配的

3.关于邻居表问题
>我们正在播放以使 NWK_MAX_DEVICE_LIST = MAX_IRAME_ENTERINDS (200)。  
>我们了解这将显著影响组播和链路状态性能，因此我们计划将组播重试次数减少到0，将链路状态间隔减少到5分钟(链路下行触发器= 2)。
这是因为由于所有设备都是邻居的一部分、消息可能会由随机的设备进行处理、并禁用重试以防止网络泛洪、以防在 neigbours 未确认的情况下发生重试。

您认为这种方法会有帮助还是会看到任何疑虑？

此外，您/软件开发团队是否对我们可以尝试处理这种情况的任何事情有任何意见？
期待您的意见。

谢谢
Akhilesh

1.堆在最新的 Z-Stack SDK 中是动态的,这是首选设置。

2.堆设置会根据缓冲区大小影响消息处理。   

3.所有设备是否在 彼此的无线电范围内？  根据处理链路状态消息填充邻居表、如果无法保持连接、则将删除条目。  您可以减小消息的半径以避免不必要的重新广播。

此致、
Ryan