EmberZNet PRO大型/密集网络指南

使用ZigBee PRO / EmberZNet PRO进行非常大和/或非常密集的网络设计技巧，例如用于办公室，酒店或大型居民区的楼宇自动化网络。

网络密度：

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

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

广播：

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

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

路由：

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

为了确保实现源​​路由和多对一路由的好处，集中器应确保抑制传出消息的路由发现（禁止设置EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY），而应从传入的路由记录中导出源路由。同样，与集中器通信的节点也应在单播中禁止到达集中器的路由发现，而应等待MTORR建立来自集中器的入站路由。尽管这些调整可能会在集中器和伙伴节点之间的初始通信中引入一些延迟（因为正在建立路由），但避免1对1路由发现广播所带来的好处对于网络的可伸缩性很重要。如果非集中器节点难以知道哪个目的地是集中器以便在适当的情况下抑制路由发现，则可以使用可选的堆栈回调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容纳的容量一样大，因为在某些情况下（例如Trust Center身份验证请求和传入的ZDO请求），堆栈将需要自己进行响应而不会主机参与，因此只需要使用NCP的可用路由/源路由表来召唤路由。（如果您的版本包括，请确保选中AppBuilder Concentrator支持插件中的“在NCP上启用Concentrator支持”选项。）如果主机也计划存储源路由，

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

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

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

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_APPS_HAND_SULTS_QUESTS_HAND_SULTS_QUESTS_HAND_SULTS_DINGSDINGS_SULTS_DINGSDINGS_HAND_SULTS_DINGSDINGS_SAND_QUESTS_SAND_QUESTS来包含绑定位EMBER_APPS。此设置将导致所有clusterId为BINDING_TABLE_REQUEST，BIND_REQUEST或UNBIND_REQUEST的ZDO请求都向上传递到[host]应用程序以进行处理和