[参考译文] CC2652R：通过其他器件路由的 Zigbee 器件上的数据包损耗较高

尊敬的 Grant：

中间器件是 CC2530还是 CC2652Rs、是否有任何 ZEd 或是否所有这些 ZRS？  与 MAC 目的相比、器件的 NWK 目的是什么？  您可以在 Wireshark 中选择数据包、以了解有关数据包来源和目的的更多信息。  请提供监听器日志和相关的确切数据包编号、以便进行更详细的审查。  另请注意、SimpleLink CC13XX/CC26XX Z-Stack 器件每季度进行一次大型网络稳定性测试。  SWRA650中提供了一些建议。  我还建议采用不同的 ZC、因为 CC2530具有显著 的 RAM 限制、并且它的 Z-Stack 解决方案已有几年未更新(与 CC2652R 不同)。

此致、
Ryan

您好、Ryan、感谢您的回答。 网状网络是 CC2652Rs 和 CC2530的良好组合、但对于我在以下示例中查看的特定 CC2652R ZR、ZR 通过 CC2530 ZR 进行路由。 除了 ZC、网状网络上的所有器件都是 ZRS。

这是我的捕获文件： app.box.com/.../z430requg287tl9yo4y0q7xfhm5lklc9

如果您在下载时遇到任何问题、请告诉我。 很抱歉、我没有一个最小的捕获量供您查看、这是一个网格、上面有多个 ZRS。 它是一个非常繁忙的捕获文件。

首先、让我们看看成功到达 ZC 的数据包。 看看从数据包#2097开始的4个数据包序列。 这是 ZR 发送到 ZC 的数据包。 在数据包#2097中、NWK 目的地址为0x0000。 NWK 源是 bbba4，它是源自 ZR。 此数据包的 WPAN 源 MAC 为00：12：4b：00：25：CB：6F：cc。 下一个数据包#2098是 Ack。 然后在数据包#2099中、我们看到另一个 ZR 器件、WPAN 源 MAC 00：12：4b：00：25：CB：6F：A5、重复完全相同的数据包、与第一个数据包相同的 NWK src 和 dst。 此数据包也会被数据包#2100确认。 正如我说过的、ZC 可以看到该数据包正常、并将其发送到我们的应用程序。

有关丢失的数据包的示例、请查看数据包#2026。 这是来自同一初始 ZR 的数据包、但该数据包从不会将其传输到 ZC。 同样、该数据包的 NWK 目标为0x0000。 同样、NWK 源是 bbba4、此数据包的 WPAN 源 MAC 是00：12：4b：00：25：CB：6F：cc。 此数据包通过数据包#2027得到确认。 就是这样。 ZC 从未检测到数据包。

这种模式非常一致。 对于这个特定的源自 ZR、NWK 源 bbba4、使其进入 ZC 的每个数据包都由具有 WPAN 源 MAC 00：12：4b：00：25：CB：6F：A5的 ZR 重复。 每个被丢弃的数据包都由始发 ZR 进行传输、但我从未看到它重复。 它得到了确认、但就是这样、ZC 从未看到过它。

我双击了 Ack 数据包、但 Wireshark 并未提供有关谁在传输 Ack 的详细信息。 我不认为该信息在 Ack 数据包本身的任何位置。

如果您能帮助我了解嗅探器日志中发生的情况以及它如何导致我们网状网络上的数据包丢失、我将不胜感激。

关于为 ZC 采用不同的芯片、我们确实有过渡到 CC2652R 的计划。 当然、CC2652Rs 最近变得非常难实现。 你不会碰巧有几千人躺在上面，我们可以把你的手拿出来，你会吗？ :-)

此致、
授予

感谢您的监听器日志！  在数据包2097中、ZC (0x0000)是 NWK 地址(最终目的)、而0xcd82是 MAC 地址(下一跳)。  对于数据包2026、ZC 同时是 NWK 和 MAC 地址、这意味着只需直接传输一个数据包、而不需要通过中间路由器传输。  在数据包2026和2097之间发生某种情况，对于这些数据包，babb4路由器决定通过0xcd82路由消息比直接发送到0x0000更稳定。  在上面的屏幕截图中显示的是 NWK 地址、而不是 MAC 地址。  我目前无法进一步调查、因为我可能缺少 NWK 密钥 、因为所有 Zigbee 消息都显示为"Bad FCS"。

您如何观察 ZC 应用中的数据包丢失并将其量化为25%？  此外、Zigbee 网络中总共有多少个节点、每个节点向 ZC 报告的频率如何？

此致、
Ryan

啊、谢谢、我没有看到802.15.4层的源和目标(如此多的层和字段！) 看看它会有很大帮助。   在我看来、路由器可能会随着条件的变化而更改路由路径、但看起来它确实频繁地更改路径、这是很有意义的。  在这里、它会改变每个报告上的路径。  以下是一系列连续报告：

• 数据包2313将经过0xcd82、并由应用程序接收
• 数据包2391将直接发送到0x0000、应用程序未接收到该数据包
• 数据包2481正在经过0xcd82并被应用接收
• 数据包2556将直接发送到0x0000、应用程序未接收到该数据包
• 数据包2609将经过0xcd82、并被应用接收

考虑到数据包已被确认、问题可能出在 ZC 端？

抱歉、当我说 MAC 时、我实际上指的是 IEEE 802.15.4扩展源地址、我始终认为它类似于以太网 MAC。

显示"BAD FCS"消息是因为 TI CC231监听器使用 RSSI 和 LQI 值覆盖 FCS 字段。  您可以通过转至 Preferences 并在"Protocols (协议)"下找到"IEEE 802.15.4"、让 Wireshark 正确解码。  将"FCS 格式"值更改为"TI CC24xx 元数据"。

我们的 ZC 应用程序将数据包从每个 ZR 转发到 Web 应用程序。  每个数据包中都有一个序列号、因此我们可以判断何时缺少报告。  仔细看一下、它可能是15%而不是25%。  每个 ZR 节点每15秒发送一次报告。

此致、

授予

[引用 userid="429244" URL"~/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1170355/cc2652r-high-packet-loss-on-zigbee-devices-routed-through-other-devices/4408209 #4408209"]"Bad FCS"消息出现的原因是 TI CC231监听器使用 RSSI 和 LQI 值覆盖 FCS 字段。  您可以通过转至 Preferences 并在"Protocols (协议)"下找到"IEEE 802.15.4"、让 Wireshark 正确解码。  将"FCS 格式"值更改为"TI CC24xx 元数据"。

感谢您的提示、在进行更改后、我现在正式看到加密的有效负载、因为我不知道 NWK 密钥。

[引用 userid="429244" URL"~/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1170355/cc2652r-high-packet-loss-on-zigbee-devices-routed-through-other-devices/4408209 #4408209"]考虑到数据包已被确认，问题可能出在 ZC 端？

ZC 可能不会将0xBBA4视为邻居、因此会丢弃来自该器件的直接消息。  在此期间、0x0000和0xBBA4的链路状态消息的内容是什么？  如果您可以调试 CC2530 ZC、那么您是否能够直接观察从该 ZR 传送到应用程序的消息、或者它似乎被预构建的 Z-Stack 库阻止了？  CC2530 ZC 是什么版本的 Z-Stack？  请记住 有关 已知问题和限制的 E2E 帖子。

此致、
Ryan

Ryan、

查看链接状态消息很有趣。 我只查看了几个数据报告中的链路状态消息、因为挖掘 Wireshark 捕获数据非常耗时。

来自0x0000的链路状态消息非常一致。 0xBBA4的邻居条目始终具有传入值0和传出值0。

来自0xBBA4的链路状态消息不一致。 0xCD82的邻居条目始终具有传入值1和传出值1。 但0x0000的邻居条目显示了一个模式。 每次 ZC 看到数据报告包时、0x000的邻居条目始终具有传入值1和传出值3。 在此提醒、数据报告在这种情况下通过0xCD82进行路由。 每次 ZC 看不到报告数据包时、邻居条目总是有一个传入值1和一个传出值0。 这是数据报告直接进入0x0000的情况。 您可能会想到、ZC 不会将0xBBA4视为邻居、但这是一些深堆栈魔法。

以下是更多表格形式的相同信息：

从0x0000开始的链路状态 来自0xBBA4的链路状态 
0xBBA4的邻居条目：In 0、Out 0 0x0000的邻居条目：输入1、输出3 
0xCD82的邻居条目：输入1、输出1 0xCD82的邻居条目：输入1、输出1 

数据包#2313 (良好数据包) 0xBBA4 -> 0xCD82 -> 0x0000 

从0x0000开始的链路状态 来自0xBBA4的链路状态 
0xBBA4的邻居条目：In 0、Out 0 0x0000的邻居条目：输入1、输出0 
0xCD82的邻居条目：输入1、输出1 0xCD82的邻居条目：输入1、输出1 

数据包#2391 (错误数据包) 0xBBA4 -> 0x0000 

从0x0000开始的链路状态 来自0xBBA4的链路状态 
0xBBA4的邻居条目：In 0、Out 0 0x0000的邻居条目：输入1、输出3 
0xCD82的邻居条目：输入1、输出1 0xCD82的邻居条目：输入1、输出1 

数据包#2481 (良好数据包) 0xBBA4 -> 0xCD82 -> 0x0000 

从0x0000开始的链路状态 来自0xBBA4的链路状态 
0xBBA4的邻居条目：In 0、Out 0 缺少！ 
0xCD82的邻居条目：输入1、输出1 

数据包#2556 (错误数据包) 0xBBA4 -> 0x0000 

我们在 ZC 上使用 ZStack-CC2530版本2.5.1a。 目前、我还没有一种在 ZC 上进行调试的简单方法。

在我看来、E2E 已知问题中没有任何可能导致此症状的问题、但这些问题当然适用于栈的版本3.0.2。

此致、
授予

Ryan、很遗憾我们听到这个问题可能是在协调员一方。 我们已经在 ZStack 版本2.5.1a 的 CC2530上运行了很少数量的现场装置、升级现场的协调器将是一项重大的挑战。

请注意、与我们的 CC2530 ZC 一起、我们多年来一直在该领域拥有 CC2530 ZRS、从未见过这个问题。 我注意到的一点是、我们已配置 CC2530 ZRS、以记住它们加入了哪些网状网络、并在加电时立即开始发送数据报告。

我们的新 CC2652产品每次加电时、都会进行完整的网格加入协商、从信标请求开始。 即使过去已成功加入相同网格、它也会执行此操作。 CC2652上是否有办法让器件记住它打开的最后一个网状网络并跳过协商过程？ 上电时、我调用以下代码片段：

Zstack_bdbStartCommissioningReq_t Zstack_bdbStartCommissioningReq；
zstack_bdbStartCommissioningReq.commissioning_mode = 0；
Zstackapi_BdbStartCommissioningReq (appServiceTaskId、&ZStack_BdbStartCommissioningReq)；

我还有一些后续问题。

• 您提到您每季度进行一次大型网络稳定性测试。 这是一个包含不同版本芯片组和软件堆栈的混合环境吗？ 或者、您的季度测试是使用同质器件完成的吗？
• 您提供了有关 Z-Stack 3.0.2已知问题的 E2E 帖子链接。 我想您没有指向 Z-Stack 2.5.1a 中已知问题的链接？

谢谢、
授予

• Zigbee 终端设备确实记得它通过保存的 NV 存储器开启的最后一个网络、如果它看到信标响应及其识别的网络信息、将发送重新加入请求。
• 每个季度有不同的芯片组使用相同的 SIMPLELINK-CC13XX-CC26XX-SDK 版本。
• 对于 Z-Stack 2.5.1a 之后的版本、您必须检查发行说明中的错误修复部分、但是除 Z-STACK-ARCHIVE 中的剩余内容外、所有内容 都已从 TI 网站中删除。

此致、
Ryan