[参考译文] CC2652P：关于邻居表和路由器表的更新

 在过滤：之前添加捕获文件

e2e.ti.com/.../origin.zip

您好、Howjie、

由于您未启用 MTO、因此源路由未启用、因此与 SWRA650不同 、建议增加 SysConfig 生成的 ti_zstack_config.h 内 MAX_RTG_ENTRINTRINTRUGINTRUTERS[40默认情况下]的值。  由于网络中有多个设备处于活动状态、ZC 可能会从0x5A14接收到路由应答、但无法将此路径添加到路由表中、因此会直接发送其预期的消息、作为发送消息的最后一项工作。

第二个问题可能是一个相关的问题。  ZC 知道它可以从0x0F80接收传入的链路状态消息、但此 ZR 无法接收来自 ZC 的传出消息。  但是，由于路由表已满，ZC 会在尝试通过路由请求查找现有路径之前尝试直接发送消息。

此致、
Ryan

感谢您提供进一步的澄清。  我注意到、这不是一个孤立的实例、因为 ZC 和 ZRS 之间存在大量类似的交互。  在大多数情况下、行为都是一致的、其中  ZR 器件 的链路状态条目中没有 ZC、而 ZC 的发送成本较低/较差。   

由于传出开销为0x00、ZC 可能会发送路由请求、但会忽略回复、因为存在路由(尽管路由不正确)。 然后、由于0xEB01中的"无路由可用"网络状态(188960中未显示)、它将完全删除该路由、以便在下次尝试时实际保存并应用路由响应。

我有一个理论、如果能进一步调试您的设置、我将不胜感激。  我将直接通过 Shuyang 传达进一步的指示。

此致、
Ryan

您好、Ryan、

第一个问题是，水阳告诉我们如何调试。 如果有新信息，我们将同步到 Shuyang。

此外、我们还有关于需要确认的数据传输的问题：

如果器件调用 AF_DATA_REQ (禁用 APS ACK)两次以发送数据、当第一条消息到达 MACTxQueue 时、第二条消息是否会缓存在 MACTxQueue 或 NWKTxQueue 中？

如果在发送第二条消息之前路径发生变化，则在发送第二条消息时会使用新路径还是旧路径？

关于问题2、可能是什么原因导致了这种情况？
0x0F80的链路状态中没有0x0000。 通常情况下、链接状态为0x0000的0x0F80的 outCost 应始终为0、但监听器显示0x0000会将0x0F80的 outCost 更改为1。 这似乎非常奇怪、这种意外变化会导致路径频繁变化。

谢谢、

Howjie

消息将在 NWK 层上排队、直到从 MAC 层接收到已发送上一条消息的确认。   确定下一个路由跃点后，消息将存储在缓冲区中，因此将使用旧路径。  此行为可能发生的窗口非常小。

我没有线索、因为这与您的第二个问题有关。  我只能推测路由条目已刷新为默认链路成本(1)、尽管监听器日志中没有任何内容表明这种情况的发生原因。  这是一个反复出现的问题还是很少观察到的问题？

请注意、由于美国的原因、进一步的回复将延迟至11月29日 感恩节假期  

此致、
Ryan

您好、Ryan、

客户 已重现协调员未处理 Reply 问题的问题(不确定是否是相同的原因)。

当问题再次出现时，协调器的 MAC 层接收到 RReply (ReqID=9)消息，但程序没有执行到 RTG_ProcessRrep()。

在0x0000接收到0xDAF8的 RReply 消息后、该消息似乎被从 Mac 层丢弃到 NWK 层。 是因为 NWK 帧计数器？

大约40秒后、客户继续控制0xA718器件。 路由发现(ReqID = 10)成功。  在监听器中、通信路径为0x0000→0x152F→0xA718、并且是对称的。

在 ReqID = 9的过程中、0xA718的路由表存储路由条目：

DESTADDR-0x0000、

nextHopAddr-0xDAF8。

在 ReqID = 10的过程中、0xA718接收到0x152F 的 RREQ 消息。 由于0xA718返回 RReqpy、RTG_ProcessRreq()→RTG_UpdateRtDiscEntry ()返回 RTG_Success、应调用 RTG_AddRtgEntry ()以修改 pRtg->nextHopniffer。  换句话说、需要将0xA718的路由条目更新为：

DESTADDR-0x0000、

nextHopAddr-0x152F。

但是、在三小时后再次控制0xA718时、路径不是这样。

由于 ZNP 被用作协调器、所以在3小时内网络中将只会显示链接状态消息、然后客户再次使用0x0000来控制0xA718、正向路径为0x0000→0x152F→0xA718、反向路径为0xA718→0xDAF8。 为什么？

e2e.ti.com/.../1129.zip

 此致、

水阳

我相信来自0xDAF8的路由应答被 ZC 丢弃、因为它没有链接状态消息中显示的可用于此 ZR 的链接、而0x152F 是有效的路由。  0xA718似乎认为到 ZC 的最佳路由是通过0xDAF8而不是0x152F、这会导致问题。  实际上、0xA718应识别此问题并发送0x0000的路由请求。  多对一/源路由有助于消除这种差异。

此致、
Ryan

您好、Ryan、

在路径发现过程中，它使用无效邻居的目的是什么？  以便选择更好的通信路径？

如果我们按如下方式修改代码、我们是否可以避免路径发现过程中出现无效邻居的问题？

MTO 中的路由记录可以避免使用无效的邻居？

此致，

Howjie

您好、Howjie、

注意：删除了源代码摘录。  不应修改相关行、因为仍应按照注释和下面说明中的说明处理无效邻居。

我假设 来自无效链路的路由响应(源节点不在邻居表中)将继续由路由层处理、并将源节点添加到其邻居表(因此存在于链路状态消息中)、或者、如果邻居表已满、 重新广播路由请求以尝试查找有效链接。  这不是您观察到的结果吗？

我无法确认 MTO 路由是否可以解决此问题、尤其是在允许使用有限邻居的情况下。  您可以查看  《Z-Stack 用户指南 》的 MTO 路线维护部分、以进一步了解它可为您的系统带来的好处。

此致、
Ryan

您好、Ryan、

我之前的描述不是很清楚。

如果 Zigbee 的邻居分为以下三种类型：
1.有效邻居：inCost 和 outCost 是有效值
2.无效邻居：只有 inCost 是有效值
3.潜在邻居：邻居不会出现在设备的链路状态中。

在本主题中、我们了解协调员不处理 RReply 的情况：

案例1
0x0000→0x5A14→0xEB01
当问题发生时、0x5A14和0x0000是有效的邻居、但0x0000不处理由0x5A14中继的 RReply。

在本例中、我们根据您的指令进行调试、以获取更具体的异常位置、例如 RTG_UST_Cost。

案例2
0x0000→0xDAF8→0xA718
当问题发生时、0xDAF8和0x0000是潜在的邻居、但0x0000不处理由0xDAF8转发的 RReply。
根据0x0000的调试信息、RReply 消息没有到达0x0000的 NWK 进行处理、因为这两个地址不是有效的邻居。

这种情况似乎是由 ZStack 尝试使用潜在邻居发送 RReply 而导致的、器件将丢弃由无效邻居发送的消息。

针对 CASE2中的现象、我们希望禁止在路由发现过程中使用潜在的邻居来避免此问题。
我们的修改也是出于此目的、添加了禁用潜在邻居的条件、但我们仍然不确定使用潜在邻居的 ZStack 的设计意图、因此我们需要与您确认这是否可行？

我们在测试开始时在 ZStack 中启用了 MTO、但在测试过程中遇到了一个奇怪的问题、因此我们禁用了 MTO、我们将尝试启用多对一/源并提供特定的问题反馈。

此致、

Howjie

在情况2期间、潜在邻居0xDAF8在其链路状态消息中将 ZC 列为无效邻居。  它会回复路由请求、希望在源节点和目标节点之间重新建立路由。  在 ZC 上处理路由应答时，预期的行为是将该条目添加到路由表和邻居表中。  无论出于何种原因(例如填充的表)，都将通过路由层的处理在 ZC 上拒绝该请求。   因此，尽管可以修改此层以完全放弃来自无效或潜在邻居的消息，但没有任何东西可以阻止潜在/无效邻居也回复下一个路由请求并重复该过程。  建议的最佳路径是优化 ZC 设置、以允许 CC2652P 器件上可用闪存/RAM 允许的大量路由和邻居。  如果尚未提到、请确保 根据需要增加 NV 内存和堆。

此致、
Ryan