关于使用 ZigBee PRO / EmberZNet PRO 进行超大型和/或超密集网络设计

网络密度：
虽然网状网络通常通过更多的路由器覆盖来改善（以获得更良好的连接网状网络），但大型楼宇自动化网络（您可能在每个灯镇流器和灯开关中都有无线电）往往过于密集，特别是如果您将所有线路供电设备是路由器。堆栈只能跟踪有限数量的相邻路由器（在 EmberZNet 的情况下为 16 个），并且此邻居表之外的任何节点都将需要多跳路由（通过已知邻居），尽管位于发送方的直接无线电范围内，因为只有在路由发现时已知的邻居才被视为新路由中的潜在下一跳。（您可以通过强制 1 跳源路由到目标来潜在地克服此行为，但目标不在邻居表中，它' 不清楚您将如何评估目标在无线电范围内是否可以到达。最近有一个 EmberZNet 功能请求，建议对传入的链路状态消息进行潜在的堆栈回调，这样一个节点就可以确定谁在直接无线电范围内，即使它不是幸运地位于邻居表中的首选节点之一。虽然这个想法有其优点，但像这样一个非常密集的网络中的节点会听到*大量*传入的链接状态消息，因此应用程序需要管理大量回调活动。）并且，类似地， NWK/APS 广播流量仅在从已知邻居听到数据包时才会重复（否则 NWK 安全帧计数器无法验证，因此恶意注入广播的风险太大），因此广播不会

一种可能的解决方案是使您的具有路由器功能的节点的子集充当终端设备（通常是非休眠 [RxOnWhenIdle] 的，因此它们不必轮询以接收消息/ACK）或非中继路由器。我们的软件在编译/EZSP 配置时支持这两种行为，尽管您如何确定哪些节点和多少应该以这种方式“绝育”取决于系统设计人员，并且通常涉及一些专有方案（由安装程序直接强制执行或通过一些先进的软件算法，在节点进入网络之前考虑一些带外信息）。要使该节点成为非休眠终端设备，只需在您的 AppBuilder 设置中为相关节点选择“终端设备”节点类型（或者如果您以 EMBER_END_DEVICE 身份加入）直接与堆栈交互，而不是使用我们基于 ZCL 的应用程序框架）。要使节点充当非中继路由器，只需为您的 SoC 构建全局定义 EMBER_DISABLE_RELAY，或为 EZSP 主机应用构建将 EzspConfigId EZSP_CONFIG_DISABLE_RELAY 设置为值 0x01。对比这两种解决方案，非休眠终端设备需要将路由器/协调器节点指定为其“父节点”，并且需要定期轮询该节点（或通过它发送消息）——大约每 5 分钟一次，通常- 确保它不会作为一个过时的孩子老化，否则它将失去与网络的连接，并且需要重新加入才能再次获得正确的父连接。终端设备也不直接参与路由，而是将其父节点用作任何传出消息的第一跳或任何传入消息的最后一跳，因此除非由其父节点中继，否则它不会听到广播，需要依靠其父节点进行路由发现，不能使用多对一作为集中器路由，不能作为加入/重新加入终端设备的父级。但是，它也不需要维护邻居表、子表或路由表（减少 RAM 密集型），可以使用我们的“zigbee-pro-leaf-stack”库运行（节省大约 5-比标准 ZigBee Pro 堆栈库高 6KB），不发送链路状态消息，也不会回显广播，因此这些都是优于非中继路由器的潜在优势。非中继路由器使用标准的 EMBER_ROUTER 节点类型，并且加入/行为与标准路由器节点一样，只是它不会中继任何单播流量或路由请求广播或使用任何路由回复来响应路由请求，除非message/route 是节点本身或其终端设备子节点之一。该节点仍然发送链接状态消息，仍然按预期回显广播，并且仍然允许终端设备子节点通过它加入/重新加入（除非 EMBER_MAX_END_DEVICE_CHILDREN 被定义/配置为 0 用于构建）。此外，虽然它不受官方支持，但可以设置/清除允许中继标志 ( 并且仍然允许终端设备子设备通过它加入/重新加入（除非 EMBER_MAX_END_DEVICE_CHILDREN 被定义/配置为 0 用于构建）。此外，虽然它不受官方支持，但可以设置/清除允许中继标志 ( 并且仍然允许终端设备子设备通过它加入/重新加入（除非 EMBER_MAX_END_DEVICE_CHILDREN 被定义/配置为 0 用于构建）。此外，虽然它不受官方支持，但可以设置/清除允许中继标志 (extern int8u emAllowRelay）在 SoC 设备上运行时，而更改节点类型可以在运行时完成，但更繁重，因为它需要离开网络并再次加入新的节点类型。

广播：
在任何可感知规模的网络中，应尽可能避免或最小化广播，并且在已知感兴趣的节点与发送者非常接近（在有限的跳数内）的情况下，应限制传播半径。（请参阅上面的说明，由于密度，这些邻居中的跳数略高。）此外，ZigBee Pro 堆栈将广播流量限制为在任何 9 秒窗口内大约 8 个广播，因此任何 NWK 层广播活动（APS 广播，APS任何节点（即使是具有 1 跳半径的节点）的多播、路由发现、ZDO 公告或广播请求、PAN ID/频道/NWK 密钥更新通知）都将计入此限制，并且如果任何节点遇到超过此数量的广播流量，它将丢弃数据包，因为它可以'

虽然广播表（用于跟踪未完成的广播并限制一次可以活动的广播）理论上可以调整大小，但标准 EmberZNet PRO 堆栈不允许这样做，因为更改此参数可能会违反 ZigBee Pro 堆栈合规性并且可能影响与具有不同广播表参数的其他节点（甚至那些运行 EmberZNet PRO 堆栈的节点）的互操作性。然而，一些设计完全专有网络的客户（合规性和第三方互操作性不是这样的问题，并且他们可以指定 PAN 中涉及的所有节点的构建参数）能够从可配置的广播表中受益，以适应广播他们设计的带宽期望，在这种情况下，可以根据具体情况向了解风险的客户提供特殊的堆栈库变体。如果您认为这适用于您，请通过技术支持门户联系您的 Silicon Labs 支持代表 (https://siliconlabs.force.com）。另请注意，即使调整广播表的大小以允许在短时间内在网络中进行更多广播，发送广播也会对网络的吞吐量产生重大影响，并且不打算成为可靠的通信形式，因为没有 ACK是由接收者产生的，因为在中继消息时，并非所有节点都可以使用清晰的通道访问。

路由：
您希望在大型网络中看到的一种广播类型，尤其是在楼宇自动化网络中具有中央控制点的广播，是多对一路由请求 (MTORR)。建议让网络中的中央收集/控制点充当网络集中器（例如通过我们的应用程序框架中的集中器支持插件），以使该节点与其他节点之间的通信更有效，从而减少一对一的路由发现非集中器节点的必要和路由表不会因流入/流出这些集中器的通信而过度使用。虽然 MTORR 仍然是广播，并且需要定期刷新/维护到集中器的路由（并从集中器导出反向路由），MTORR 在本质上比 1 对 1 路由请求更具规律性/周期性，并且源自特定点，因此流量影响具有很大的确定性且更易于建模。MTORR 的速率，即使用于纠正非功能性路由，也可以通过集中器支持插件中的最小/最大广播之间的时间参数以及生成 MTORR 以响应路由错误和传递失败的阈值进行调整。随着网络规模和/或集中器数量的增长，将广播之间的最大时间调整为更长很重要，这样网络就不会被几个在短时间内执行周期性 MTORR 的集中器淹没。请注意，您不仅要为 MTORR，还要为偶尔的地址发现（ZDO IEEE 地址请求或网络地址请求）留出足够的广播带宽，堆栈可能需要这些带宽来解析绑定/地址表的节点 ID目的地或（在 IEEE 地址请求的情况下）从非集中器引出单播回复，以便在多对一路由已更改或未知后为集中器的利益生成路由记录。（EmberZNet PRO 5.1.2 及更高版本中的集中器支持插件采用了这种主动源路由修复方式。）堆栈可能需要它来解析绑定/地址表目标的节点 ID，或者（在 IEEE 地址请求的情况下）从非集中器引出单播回复，以便为集中器的利益生成路由记录在多对一路由改变或未知之后。（EmberZNet PRO 5.1.2 及更高版本中的集中器支持插件采用了这种主动源路由修复方式。）堆栈可能需要它来解析绑定/地址表目标的节点 ID，或者（在 IEEE 地址请求的情况下）从非集中器引出单播回复，以便为集中器的利益生成路由记录在多对一路由改变或未知之后。（EmberZNet PRO 5.1.2 及更高版本中的集中器支持插件采用了这种主动源路由修复方式。）

为了确保实现源路由和多对一路由的好处，集中器应确保抑制传出消息的路由发现（不允许设置 EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY），而不是从传入路由记录中派生源路由。类似地，与集中器通信的节点也应该在其到集中器的单播中抑制路由发现，而不是等待 MTORR 设置来自集中器的入站路由。虽然这些调整可能会在集中器和伙伴节点之间的初始通信中引入一些延迟（因为正在设置路由），但避免一对一路由发现广播所获得的好处对于网络的可扩展性很重要。如果非集中器节点难以知道哪些目的地是集中器以便在适当的情况下抑制路由发现，则可以使用可选的堆栈回调 emberIncomingManyToOneRouteRequestHandler()，这需要在构建过程中定义 EMBER_APPLICATION_HAS_INCOMING_ROUTE_ERROR_HANDLER。另请注意，如果使用绑定表与集中器通信，则可以在创建 EmberBindingTableEntry 时使用 EMBER_MANY_TO_ONE_BINDING 类型，这将在传递到绑定目标失败时抑制堆栈的正常地址发现，即使启用了 EMBER_APS_OPTION_ENABLE_ADDRESS_DISCOVERY 也是如此。但是，如果为当前单播启用了 EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY 或 EMBER_APS_OPTION_FORCE_ROUTE_DISCOVERY 选项，它不会抑制路由发现。

请注意，您的信任中心（协调器）节点应始终实现集中器支持，以便它可以促进对来自加入/重新加入节点的父节点的身份验证请求的响应，这些请求在请求到达时可能尚未在路由表中。未能在信任中心上启用此功能可能会导致通过多个跃点加入节点时出现问题。

资源利用：
为了确保集中器有节点的源路由而不必求助于它们，大型网络中集中器节点的应用程序设计者应该努力为资源允许的尽可能多的节点提供源路由。这意味着使用高 RAM 集中器（与低 RAM 集中器相反，它将强制节点为每个单播向集中器发送路由记录，增加流量负载）并将源路由表大小设置为足够大（理想情况下）集中器在 PAN 生命周期内将与之通信的最大预期节点集。对于 SoC 应用程序，这意味着将 EMBER_SOURCE_ROUTE_TABLE_SIZE 设置为尽可能大。（如果预计超过 255 个节点，设计人员可以根据需要更改 app/util/source-route.c 中使用的 SourceRouteTableEntry 表索引的数据类型，以适应 16 位索引。）对于使用 NCP 的 EZSP 主机应用程序，理想情况下，NCP 自己的源路由表应该与 RAM 所能容纳的一样大，即使主机计划自己维护源路由数据，因为在某些情况下（例如信任中心身份验证请求和传入的 ZDO 请求）堆栈需要自己响应而无需主机参与，因此只需要使用 NCP 的可用路由/源路由表来调用路由。（如果您的版本包含此功能，请确保选中 AppBuilder 集中器支持插件中的“在 NCP 处启用集中器支持”选项。）如果主机也计划存储源路由，

另请注意，对于具有许多跃点的大型/密集网络，附加到消息的源路由可能非常大，因此传出源路由单播的最大应用程序有效负载大小将受到此开销的影响。有关有效负载大小的更多信息，请参阅知识库文章（位于community.silabs.com），标题为“安全和非安全模式下 ZigBee 消息有效负载的最大长度是多少？ ”。因此，对于具有大负载的某些消息，可能需要分段（可以通过 AppBuilder 的 Fragmentation 插件提供）。

除了源路由开销之外，诸如此类的大型网络应用程序可能还需要考虑增加以下参数（可以通过构建符号重新定义，例如通过 AppBuilder“包含”选项卡的宏部分）：

EMBER_PACKET_BUFFER_COUNT - 由于网络大小/密度，更多的流量进出/通过节点意味着更多的数据包数据需要被路由器缓冲。单个数据包缓冲区最多可容纳 32 个字节的数据，因此一个大数据包可能需要多达 4 个数据包缓冲区来存储。对于休眠的终端设备子设备在父设备上缓冲的消息以及堆栈使用的其他瞬态网络数据，也需要数据包缓冲区。对于 EZSP 主机应用，Silicon Labs 建议将 NCP 上任何未使用的 RAM 分配给数据包缓冲区，以确保 NCP 有足够的数据，特别是因为数据包缓冲区还用于存储排队等待传输到主机的 EZSP 帧。（这已经是应用程序框架的默认行为。）应用程序框架对 SoC 构建使用默认的 75 个数据包缓冲区，

EMBER_APS_UNICAST_MESSAGE_COUNT - 任何时候来自发送节点的未决（等待 ACK/超时）APS 单播的数量。默认值为 10。

EMBER_MAX_END_DEVICE_CHILDREN - 单个父路由器/协调器可以支持的终端设备子设备的数量。默认为 6；最大值为 64。

EMBER_BINDING_TABLE_SIZE - 节点可以利用堆栈进行基于绑定的通信的绑定数量。根据用于保存这些的 SimEEPROM 存储模型的限制，最大值为 126，但 EZSP NCP 固件中的最大值为 100（基于 EM260 和 EM351 的固件除外，限制为 12 个绑定）。如果需要超过此数量的绑定，则应用程序将需要自行管理绑定，这可以通过为 SoC 构建定义 EMBER_APPLICATION_HANDLES_BINDING_ZDO_REQUESTS 来实现，或者对于 NCP 构建，通过设置 EzspConfigId EZSP_CONFIG_APPLICATION_ZDO_FLAGS 以包含位掩码 EMBER_APP_HANDLES_ZDO_BINDING_REQUESTS 来实现。此设置将导致所有 clusterId 为 BINDING_TABLE_REQUEST、BIND_REQUEST 或 UNBIND_REQUEST 的 ZDO 请求被传递给 [host] 应用程序进行处理。