[参考译文] CC1352R：孤立扫描连接问题

感谢你的评分

我做了你建议的测试,你是对的。

如果我预先注册协调器扩展地址、则接受协调器重新调整。 但是、如果你放纵我、这就带我来回答我的下一个问题。

我理解、从 IEEE 802.15.4 孤立请求的角度来看、它被视为重新关联机制。 但是、 该标准从未规定必须在接收协调器重新调整（或必须存在 PAN ID）时验证扩展地址、这纯粹是 TI 15.4 实现、可以接受。

但这让我有了这个问题, 根据 ZigBee 规范,它利用孤立扫描并使用它来加入机制（不只是重新加入）,如 NLDE-join.request 基元中所述 ,因为 ZigBee 不使用 IEEE 802.15.4 关联。 如果 TI 15.4 在协调器重新调整中强制执行该协调器扩展地址验证、并且 Z-Stack 正在使用 Zigbee 规范、那么 如果 TI z-stack 无法使用孤立扫描来加入、我想知道如何在 TI z-stack 中实现 NLDE-join.Request（孤立）？

我会验证自己... 但您知道... 闭源。

任何提示都将受到欢迎、或者如果我的信息有误、请告诉我。


此致、

Alberto

我似乎在一件事上错了。
如果与设置为 0x00 的 RejoinNetwork 参数结合使用、则 NLDE-join.Request 可以使用关联。

但是、如果将 NLDE-join.request 与 RejoinNetwork 参数设置为 0x01（这将触发孤立扫描过程）一起使用、我认为这个问题仍然存在。 （协调器具有希望加入的设备的扩展地址，该设备以前是使用 NLME-DIRECT-JOIN 注册的，但其它方式不是这样）

尊敬的 Alberto：

我会尝试从我们的 ZigBee 团队那里获得某人。

此致、

Daniel

尊敬的 Alberto：

您参考的是哪个 Zigbee 规范文档？  请参阅 Zigbee PRO 规范 R22/2017、因为这是用于 SimpleLink F2 SDK Z-Stack 解决方案的版本。  NLDE 是网络层数据实体、NLME 是网络层管理实体、我更熟悉如何处理 加入请求基元。  然而、在第 3.2.2.13.2 节中、NLME-join.request 被声明为针对“使用孤立过程加入或重新加入网络“等情况生成的。  有关更多详细信息、请参阅第 3.6.1.4.3.1 节

本节说明如何通过直接加入网络的设备（通过孤立加入）或之前加入网络但与其父设备失去联系的设备（通过孤立重新加入）来启动孤立过程。
直接添加到网络中的设备应启动孤立过程、以便完成与其父设备的关系建立。 器件上的应用程序将决定是否启动此过程、如果启动、还将在上电时通知网络层。
如果设备的 NLME 反复收到来自其 MAC 子层的通信故障通知、则先前加入网络的设备可以选择启动孤立过程。

可选的通过孤立过程加入由使用 NLME-join.request 基元且 RejoinNetwork 参数设置为 0x01 的设备启动。
启动此过程时、NLME 应首先请求 MAC 子层通过 ScanChannelsListStructure 参数给出的信道集执行孤立扫描。 通过向 MAC 子层发出 MLME-scan.request 基元来启动孤立扫描、结果通过 MLME-scan.confirm 基元传回 NLME。
如果子级已找到其父级、孤立扫描成功、NLME 应通过发出 NLME-join.confirm 基元并将状态参数设置为成功、将其加入或重新加入网络的请求通知下一个更高层。
请注意、如果子设备是第一次加入、或者子设备以前已加入网络、但未能按照第 3.6.1.8 节的规定保留树深信息、则在不采取本规范范围之外的措施来恢复此信息的情况下、它可能无法在网络上正常运行。
如果孤立扫描不成功（未找到父级）、NLME 应终止该过程并通知下一个更高层未找到网络。 这是通过发出 NLME-join.confirm 基元并将 Status 参数设置为 NO_NETWORKS 来实现的。

根据我收集到的信息、孩子 在“重新加入“过程中已经拥有 ZC 地址、可能还有 NWK 密钥、即使用预配置的网络参数重新加入。   Z-Stack 用户指南的“Z-Stack 概述“部分介绍了多种连接过程选项、具体取决于 ZC 的设置。  TI 的 CC26X2/CC13X2 器件是 符合 CSA 标准的平台。

孤儿连接是非典型的 Zigbee 行为、我对此过程没有太多的经验。  这将需要开发人员代表 Z-Stack 应用进一步干预才能实现。  Zigbee 基于 IEEE 802.15.4 构建、并将 IEEE 802.15.4 数据包用于信标请求/响应、关联请求/响应、数据请求/ACK 等  您可以参考一些示例监听器日志或评估 TI 的 Zigbee 网络示例以进一步评估。

如果您对 Zigbee 协议有任何其他问题、敬请告知。

此致、
Ryan

感谢 Daniel Guarecuco Aguiar 和 Ryan Brown1 的回复。

Ryan、我使用相同的 Zigbee 规范 2017 R22 作为参考。
在您提到的章节中、我要重现的行为是“通过孤立加入“、这意味着将 已直接加入网络的子设备关联起来。 与您的报价和规范中的进一步说明一样、此连接过程需要两个步骤：

1-使用 NLME-DIRECT-JOIN．Request 在协调器设备中手动注册子设备扩展地址（第 3.6.1.4.3 节）

2 — 使用 NLME-join.Request (RejoinNetwork 参数= 0x01) 在子设备中触发孤立连接过程、该请求在内部使用 MLME-scan.Request （如您在第 3.6.1.4.3.1 节中提到的）。

“RejoinNetwork"参数“参数名称可能会造成误导、因为这两个过程都使用此过程、 全局链接密钥 这是直接添加的,以及那些以前加入并成为孤儿的。 然而,很明显,第二步使用 MLME-scan.request（Type=孤立）来实现这一点。

根据我阅读的 Zigbee 规范或 IEEE 802.15.4 中都没有提到子级必须具有注册的 ZC 地址。 但是、根据上述在 Daniel 指导下进行的实验、如果我们没有预注册协调器（如前面注释中的代码和监听器结果所示）、TI 15.4 MAC 显然正在过滤任何协调器重新调整命令。 这种限制使 TI 15.4 可以 进行孤立的重新连接、但不可能进行孤立的连接（因为子设备不知道将在孤立的连接情况下加入的协调器的地址） 。

所以我想我的问题是…  TI 15.4/Z-stack 如何实现分离连接？ 或者这是否意味着 Z-Stack 不支持孤立连接,或者它仅用于重新连接?

还值得一提的是、我在竞争对手器件 NXP JN5169 中成功实现并测试了孤立连接行为、这种连接行为可以说比 CC1352 旧得多、但仍符合 IEEE 802.15.4-2006 标准。  

抱歉、我知道 CC1352 已获得 CSA 认证、NXP JN5169 也是如此、 我们都知道、即使在认证存在的情况下、供应商也存在不一致之处和不同的解释。  

] TI 15.4/Z-stack 如何实现孤立连接？ 或者、这是否意味着 Z-Stack 不支持孤立联接、或者它仅用于重新联接？

根据我的经验、TI 14.4 协议栈和 Z 协议栈通常不使用孤立连接。  这并不是说这是不可能的,只是我没有关于如何修改现有的应用程序来完成它的明确指示。

我既没有阅读 Zigbee 规范、也没有在 IEEE 802.15.4 中提到子级必须事先注册 ZC 地址。

我认为加入/重新加入需要 ZC 地址。  连接过程需要父地址。 这通常是信标请求/响应程序（启用 ZC 允许加入）、后跟关联。 MLME-scan.CONFIRM 将返回 PAN 描述符（包括 16 位 PAN ID 和 64 位扩展地址）、将选择其中一个作为 ZC 地址。  子设备在尝试使用 RejoinNetwork=1 “加入“时仍需要预先安装 NWK 密钥、因为 ZC 已假定已发生这种情况。  或者、需要对其进行修改、以便始终在每个“重新加入“上传输 NWK 密钥。

值得一提的是、我在竞争对手设备 NXP JN5169 中成功实现并测试了孤立连接行为、但没有出现任何问题、尽管它可能比 CC1352 旧得多、但仍符合 IEEE 802.15.4-2006 标准。  [/报价]

您是否有此 NXP 器件的孤立“加入“过程的监听器日志、您可以尝试在 CC1352 上进一步复制该日志？   

[引用 userid=“688373" url="“ url="~“~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1627004/cc1352r-orphan-scan-joining-issue/6282638 ]抱歉、我坚持认为、我知道 CC1352 已获得 CSA 认证、但 NXP JN5169 也是如此、我们都知道、即使存在认证、供应商也存在不一致之处和不同的解释。  [/报价]

经同意、认证中存在灰色区域、仍可自行确定程序。  仍然应该可以使用 IEEE 命令加入网络、但我想这将需要进一步获取 ZC 信息。

此致、
Ryan

根据我的经验、TI 14.4-Stack 和 Z-stack 通常不使用孤立连接。  这并不是说这是不可能的,只是我没有关于如何修改现有应用程序来完成它的明确说明。

与“关联过程“(RejoinNetwork=0) 相比、孤立连接并不是最常见的操作、这是正确的。 我的理解是、孤立连接 (RejoinNetwork=1)  对于指定子设备必须“加入“（关联）的路由器/协调器非常有用、并且可以更严格地控制网络中的父/子关系。 另一方面、当使用扫描/关联程序时  (RejoinNetwork=0)。 ,你没有严格的控制这,通常情况下,如果附近有多个路由器,这是可能关联,子设备将选择一个最好的 LQI 这是不是最好的事情,因为 LQI 在某些情况下不断变化的性质. 这是我的主要兴趣,实施一个孤单加入 程序,这基本上是一个“黑客“,由 ZigBee 使用关联程序,但与我上面描述的优势（严格控制关联,和网络形成）.

我对此很熟悉、这是扫描/关联过程（又称为 NLME.join.request (RejoinNetwork =0))、但正如我在上面所述、在使用此过程时、您不能严格控制关联。 在关联过程中、使用初始主动扫描（获取信标）获取父地址、这就是关联可以使用此扩展地址信息和信标 PAN 描述符中可能包含的其他信息的原因。

但是、在孤立联接中、此信息不可用（也不应要求）、因为子设备已通过在协调器/路由器中直接注册来“预先批准“。 在孤立扫描中,子设备通过协调器 realigment 命令获取协调器短地址及其分配的附加地址。当然,这是我对规范的解释……但你永远不知道……

您是否有此 NXP 器件的孤立“加入“过程的监听器日志、您可以尝试在 CC1352 上进一步复制该日志？   [/报价]

使用 JN5169、与使用 CC1352 获取的监听器日志没有区别、您只会看到 Orphan 通知命令、协调器重新调整命令。 和 Ack。 主要区别在于、对于 CC1352、如果在启动孤立扫描之前没有注册协调器地址、则在 MAC 层拒绝协调器重新调整命令（非常有趣，即使子设备拒绝协调器重新调整命令，仍会生成 ACK）。

但是... 如果你对此仍有疑问,我可以使用 JN5169 来获取孤立程序的监听器日志（我也会仔细检查结果）。 我会把它张贴在下面。 可能您在 realign 命令中发现了一个标志或我遗漏的东西。

同意、认证中存在一些灰色区域、这些区域的程序仍可自行处理。  应该仍然可以使用 IEEE 命令加入网络、但我想这将需要进一步获取 ZC 信息。

 目前、有证据 表明 CC1352 无法执行分离连接过程、即使它仍然可以执行分离重新连接过程。 需要协调器扩展地址来执行孤立扫描的 TI 15.4 并不违反 IEEE 802.15.4 per-se 的要求、但它间接地使不可能在使用 ZigBee 的孤立连接中使用。 我不会感到惊讶这被忽视,因为你说不是那么常见,和人们不关心或不使用它的任何方式。

我很乐意这样做。

感谢您发送编修。

此致、

Alberto

[/quote]

e2e.ti.com/.../OrphanScans.zip

此处显示了采用 NXP JN5169 和 CC1352R1 的孤单扫描

尊敬的 Albert：

Daniel Guarecuco Aguiar 指出、 如果扩展地址与  MAC PIB 属性中存储的值不匹配、则会从协调器重新调整的源代码返回 MAC_NO_BEAC标志 和 MAC_INT_SCAN_COMPLET_EVT。  这无法从发布代码修改、因此您需要手动编辑 MAC PIB 表中 MAC_COORD_EXTENDED_ADDRESS 的值、以便协调器重新调整能够 在 MAC 中成功通过。  据了解、NXP 选择了一种不同的方法、因此您可以进行观察

此致、
Ryan