[参考译文] CC2652P：无法从大型网络中的 ZNP 发送 ZDO 消息

您好、Shuyang、

我注意到0x3049中缺少几个 MAC 序列号、但这可能是由于监听器日志筛选器造成的。  监听器与相关节点的距离有多远？  最可能的原因是通道噪声太大、因此 CSMA 碰撞会阻止 ZNP 的传输。  如果 定义了 MT_AF_CB_FUNC、则您将能够监控 MT_AF_DATA_CONFIRM 的 ZStack_ZStatusValues。

此致、
Ryan

您好、Ryan、

在测试期间、我们将 ZNP 中的 CCA 阈值设置为-63、将广播表设置为30、并且所有器件都放置在同一个表上(当然、节点密度会更高)。

然后、我们将按照您的建议监控 AF_DATA_CONFIRM 的 ZStack_ZStatusValues。
此外、当我定义 MT_MAC_FUNC 和 MT_MAC_CB_FUNC 时、ZNP 编译将报告错误。 您可以确认吗？

出现问题时、我上载了监听器文件、注释如下面的屏幕截图所示：

e2e.ti.com/.../node-req-fail_5F00_panid0x55B3_5F00_0917.zip

谢谢、

Howjie

您好、Howjie、

您遇到的发送故障可能是由于 CCA 阈值的变化所致。  在  mT_mac.c 中将 MAC_CHAN_END 更改为27 并替换 DMMGR_SAveMacCbReg (0xFFFF)之后、我能够使用定义的 MT_MAC_FUNC 和 MT_MAC_CB_FUNC 构建 ZNP；使用_macCallbackSub = 0xFFFF； 但是、在 mT_util.c 中 、请注意、TI 多年来并未对该层进行维护或测试、因此建议您在尝试将其用于应用目的时务必小心谨慎。

此致、
Ryan

您好、Ryan、

当我们重现问题时、ZNP 收到 node_desc_req 消息并发送 node_desc_rsp 消息、但消息的 AF_DATA_CONFIRM 状态为 ZNWKNORoute。
这种情况可以通过提前触发路由发现来解决。

我们在测试期间出现了新情况：
ZNP 的 MAC 层接收到 node_desc_req 消息、但 ZDP_IncomingData 函数没有接收到该消息。 如何确定这种情况的原因？

谢谢、

Howjie

由于 ZDP_IncomingData 是来自 AF 层的回调、因此没有相关性、而 Node_Desc_req 由 ZDO_ProcessNodeDescReq 中的 ZDO 层处理。

此致、
Ryan

您好、Ryan、

从代码执行的角度来看、Node_Desc_req 消息将通过在 ZDP_IncomingData 函数中调用 ZDO_ProcessNodeDescReq 进行处理。

void ZDP_IncomingData( afIncomingMSGPacket_t *pData )
{

    ...
    
    
  while ( zdpMsgProcs[x].clusterID != 0xFFFF )
  {
    if ( zdpMsgProcs[x].clusterID == inMsg.clusterID )
    {
      zdpMsgProcs[x].pFn( &inMsg ); //Processed here++++++++++++++++++++++
      return;
    }
    x++;
  }



}

谢谢、

Howjie

感谢您的澄清。  那么  ZDO_ProcessNodeDEScReq 永远不会执行？  您能否提供节点描述符请求的监听器日志以及 ZNP 是否对其作出响应 ？

此致、
Ryan

您好、Ryan、

仅 当问题再次出现时、才不会执行 ZDO_ProcessNodeDescReq。

屏幕截图中显示了问题再次出现的位置：

e2e.ti.com/.../nodeDescReq0924.zip

谢谢、

Howjie

您好、Howjie、

我感谢监听器日志、因为它显示此行为是正常操作的例外情况。  节点描述符请求的格式正确、MAC 通过 ZC 进行了连接、之前 ZC 已向其他器件返回节点描述符响应。  我注意到0x0000和0x7C0E 不在彼此的链路状态消息中列出、这可能会解释为什么0x7C0E 发起路由请求(没有可用路由)并且0x0000拒绝数据包(节点未列在其关联/邻居表中)。

问题 还可能是由于网络拥塞、填充的 Z-Stack 缓冲区或堆不足。  您能否 考虑以下因素来改善堆栈行为？

• 在 ZNP_conf.opts 中增加 MAC_CFG_*
• 在 NWK_globals.c 中增加 NWK_MAX_DATABIFS_*
• 在 app.cfg 中增加 HEAPMGR_SIZE (如果 评估 SDK v5.20)

此致、
Ryan

您好、Ryan、

如上面的屏幕截图所示：
0x0000接收到由0x7C0E 广播的 Dev Annce 消息、0x0000还返回相应的路由应答消息、这表示0x7C0E 已存储在0x0000的表(至少是路由表)中。

数据包编号57132：0x7C0E 直接将 NODE_desc_req 发送到0x0000、但未启动路由 req；
这里看起来很正常、但协调器没有发送 node_desc_rsp 消息。

数据包编号57680和57695：ZNP 的串行端口打印显示这两个数据包已接收、但似乎在0x7C0E 的网络层重新传输。 如果0x7C0E 从未收到0x0000 MAC 层 ACK、它最终会将路由发现初始化到0x0000。
我们将根据您的建议修改相关配置并进行测试。 如果有新结果、我将向您更新。

谢谢、

Howjie

您好、Ryan、

我们将您提到的参数加倍、并对其进行了测试。 似乎有所改善，但这种现象仍然存在。

这种现象与前一种现象相似。

在监听器中、可以看到数据传输期间的 MAC 层 ACK、但接收器似乎没有接收 和处理它。

谢谢、

Howjie

由于 TCLK 交换在中间路由器之间隧道化、来自 ZC 的路由应答显然是一个错误。  您能否刷新当前评估的 ZC 网络设置和 SDK 版本？  此问题是否只能通过大型网络设置发生？是否任何加入路由器的设备都可能遇到此问题？  路由器是否能够在后续尝试时正确加入？

此致、
Ryan

您好、Ryan、

1．" 此问题是否只能通过大型网络设置发生？是否任何加入路由器的设备都可能遇到此问题？   "

ZC：ZNP (SDK5.20)
我们主要根据 swra650b.pdf 配置 ZNP。

其他修改：
NV：5页、区域基地址0x4C000、区域大小0xA000
CCA 阈值：-63
最大工艺路线申请条目：20
MAX_RTG_ENTRINTRUTERINES: 100

如果协调器接收到新器件的 DevAnnce、协调器 ZNP 将触发一个 AODV 路由请求。

ZR：ONOffLight (SDK4.40)
网络参数尚未进行大幅修改、基本上处于默认状态。

2．"  路由器是否能够在后续尝试时正确加入？"

路由设备最终可以成功加入，但需要多次尝试。

3."ZC 的路由应答显然是错误的、因为 TCLK 交换在中间路由器之间隧道化。   "

是的、0x0000和0x7C0E 是无效的相邻设备、它们的直接通信行为将非常奇怪。

但是、后续的0x7C0E 可以直接发送 Node_Desc_req、这表示0x7C0E "正常"处理 RouteReply 消息并使用此路径。

0x0000的 MAC 层接收到 Node_Desc_req、未将其传递到上层。 也许 NWK 层会将其丢弃、因为它在检查 secrity 帧计数器时找不到与器件匹配的转换器？ 如果这是原因、为什么0x7C0E 可以处理路由应答消息？

目前、在具有1条 ZC（ZNP）和20条路由的网络中可能会出现类似的问题、但问题的消息不是 Node_Desc_req。
我们看到、在协调器从无效邻居器件接收到 ZCL 消息后、协调器没有通过串行端口将数据发送到主机。

谢谢、

Howjie

感谢 Howjie 的详细介绍、我将继续对此进行研究。

此致、
Ryan

你好，Howjie，

我对迟迟不作出答复表示歉意，感谢您的耐心。  进一步了解后、您的网络拓扑和 SWRA650之间存在一些基本差异 、应在配置设置中反映这些差异。  SWRA650的设置包括一个 ZC、12 ZR 和62 ZED。  由于您的网络实际上是所有 ZR、因此必须考虑多个路由选项、因此应增加路由变量、如  Z-Stack 用户指南的路由设置快速参考部分所示。  您可能需要考虑增加 MAX_RTG_SRC_entries 或使用 集中器_route_cache。  广播风暴在您的网络上确实存在。  我看到集中器在每个 MTO_RREQ_LIMIT_TIME 而不是集中器发现时间发送一个 MTO 请求。  这显示了现有的多条断开的路由 、可通过进一步监控 ZDO_ManytoOneFailureIndicationCB 来验证这些路由。

关于监听器日志、由于 ZC 似乎没有存储到0x7C0E 节点的路由路径、因此它将提供直接路由应答、作为完成路由请求的最后一项工作。  如果可以在 ZC 上检测到此错误、则可以选择执行 Zstackapi_DevNWKRouteReq 来确定所述器件的最佳路径。  您还可以尝试错开设备联接、以便 ZNP 不必同时处理多个联接。   

此致、
Ryan

您好、 Ryan、

感谢您的回复。

在监听器文件中、我看到您说过您经常发送 MTO 路由请求。 集中器收到路由器错误后、此处是否会自动触发 MTO 路由请求？

关于监听器日志、由于 ZC 似乎没有存储到0x7C0E 节点的路由路径、因此它提供了直接路由应答、作为完成路由请求的最后一项工作。"
根据规范、一旦器件响应或接收到路由应答、就会建立并存储路径。 如果我的理解有误、您可以随时纠正。

是否有办法控制路由器是否发送信标以避免网络中的信标过多？ 我们尝试在 MAC_CbackEvent 中处理它、但它似乎不可行。

此致、

Howjie

您可以在  ZDO_ManytoOneFailureIndicationCB 中选择不同于 RTG_MTORouteReq (或作为测试禁用)的不同逻辑、增加 MTO_RREQ_LIMIT_TIME 和/或定义 集中器_route 高速缓存。

此致、
Ryan

您好、Ryan、

当设备收到路由错误消息时、我们处理了异常路径、似乎有了一些改进。

目前、我们希望尝试选择性地控制路由器是否发送信标消息以减少当前信道上的流量。
我可以在 SDK 中的何处接收信标请求消息、并可以进行干预以响应该消息？

谢谢、

Howjie

我很高兴听到您能够改进您当前的系统实施。  遗憾的是、Z-Stack 不能让用户截获和/或修改对信标请求的响应。

此致、
Ryan

ZDO 消息不支持 MT_AF_DATA_CONFIRM。

ZNWKNORoute？ ZNP 可能正忙路由。 如果 ZNP 向多个目标发送 ZDP 命令、则 ZNP 处于路由忙状态。   

尊敬的主：

我们在 afDataConfirm()中获取并处理 ZDO 消息的数据确认。

我们检查并确认 器件的当前状态在相关表中没有相应的通信路径。

谢谢、

Howjie

您将来是否会考虑向用户添加此功能界面、以便用户提高其产品的竞争力？

谢谢、

Howjie

我之前已将此反馈传递给软件开发团队、但未采取任何进一步措施。

此致、
Ryan

这并不意味 着需要处理 ZDO 消息的数据确认、但需要等待。 ZNP 等待 数据-在发送下一个 ZDO 消息之前确认。

您可以尝试我的固定 SDK、可以将 ZDO 的数据确认消息设置为回调函数。

https://gitee.com/zigbee_luo/simplelink_zstack_sdk.git

谢谢，我们稍后将查看您修改过的项目。

如果有关于此功能的新消息、您能告诉我们吗？ 我们非常需要该函数。

谢谢、

Howjie

之前的 E2E 主题提醒我  、Zigbee 2017 PRO 规范的附录 D.9.1.5规定："所有协调器/路由器都应使用信标响应信标请求。"  否则会违反 Zigbee 规范。

此致、
Ryan

如果 ZStack 仅用作可选功能、则默认情况下仍符合规范。

此函数是否易于在 ZStack 中实现？

如果可以实现、如果涉及业务、是否有利于解决问题？ 因为此功能可让我们的产品获得更好的用户体验。

谢谢、

Howjie

我已向您发送了一个好友请求。

此致、
Howjie