【ember zigbee】第六章：ug103-03-Application Development Fundamentals: Design Choices 学习笔记(中)

写在前面

• 索引
  • 【ember zigbee】序章:协议栈相关文档学习笔记

1. zigbee设计选择

  Although the application framework simplifies and abstracts the design process, some design decisions must be made as part of implementation regardless of whether the design is based on the application framework or not. The following design choices are applicable
when developing applications for zigbee protocols, including zigbee PRO and zigbee RF4CE:

• Single Network or Multi-Network
• Network Discovery / Commissioning Method
• Device Discovery and Provisioning Method
• Route Establishment Method
• Message Delivery Method
• NCP and Host Application Compatibility

• 尽管应用程序框架简化并抽象了设计过程，但无论设计是否基于应用程序框架，一些设计决策都必须作为实现的一部分，因此需要有所考虑。 在开发zigbee协议的应用程序时，以下设计选择适用，包括zigbee PRO和zigbee RF4CE：
  • 单网络或多网络
  • 网络发现/调试方法
  • 设备发现和配置方法
  • 路线建立方法
  • 消息传递方法
  • NCP和主机应用程序兼容性

1.1 单网络 VS 多网络

  A single network node is a node that forms or joins one network and must leave that network before forming or joining a second network. EmberZNet PRO 4.7 introduced the possibility for a node to be concurrently part of more than one network (this feature is not supported on the EM351).
  Note: For EmberZNet PRO, multi-network support is limited to two networks. More than two networks may be supported in the future.
  Until now, any device required two physical chips to be part of two networks. For instance, a device that is designed to be a gateway between an HA (Home Automation) PAN (personal area network) and an SE (Smart Energy) PAN would join the first network using the first chip and the second network using the second chip. The application had to manage two pieces of hardware, resulting in increased complexity for the hardware and the application designer.
  A multi-network stack removes the 1-to-1 mapping between logical PANs and physical chip, extending it to an n-to-1 mapping. An application for a device with a single chip can be designed to be part of multiple PANs possibly running different security profiles (for instance HA and SE). Use of one instead of two chips results in cost savings from reduced hardware requirements and reduced complexity of the hardware and application code design.
  Some applications still require a dual-chip configuration. This configuration is needed if the device needs to be coordinator or router on two networks (see more details below) or if the application needs to operate on two different stacks such as EmberZNet PRO and Silicon Labs Thread.

• 单个网络节点是形成或加入一个网络的节点，必须在加入第二个网络之前就要离开该第一个网络。 EmberZNet PRO 4.7引入了节点同时成为多个网络一部分的可能性（EM351不支持此功能）。
• 注意：对于EmberZNet PRO，多网络支持仅限于两个网络。将来可能会支持两个以上的网络。
• 到目前为止，任何设备都需要两个物理芯片作为两个网络的一部分。例如，设计为HA（家庭自动化）PAN（个人区域网络）和SE（智能能源）PAN之间的网关的设备将使用第一芯片加入第一网络，使用第二芯片加入第二网络。该应用程序必须管理两个硬件，导致硬件和应用程序设计人员的复杂性增加。
• 多网络堆栈消除了逻辑PAN和物理芯片之间的1对1映射，将其扩展为n对1映射。具有单个芯片的设备的应用可以被设计为可能运行不同安全配置文件的多个PAN的一部分（例如HA和SE）。使用一个而不是两个芯片可以降低硬件要求并降低硬件和应用程序代码设计的复杂性，从而节省成本。
• 某些应用仍需要双芯片配置。如果设备需要是两个网络上的协调器或路由器（请参阅下面的详细信息），或者应用程序需要在两个不同的堆栈（如EmberZNet PRO和Silicon Labs Thread）上运行，则需要此配置。

  Multi-networking on a single chip is achieved by timesharing the chip’s only radio on the networks. In other words, the multi-network node resets all the radio parameters between the networks according to a network scheduling algorithm.
  The fact that the node is concurrently active on more than one network is totally transparent to the application. APIs allow the application to specify which network a set of API calls are referred to. Similarly, APIs allow the application to understand which network a stack callback is related to. See document AN724, Designing for Multiple Networks on a Single Chip, for more details regarding dual network APIs.
  Both AFV2 and the Network Coprocessor Application Framework provide dual network support. We strongly encourage using an application framework when developing a dual network application. The application framework provides many advantages in terms of reduced complexity, mostly related to how the framework seamlessly manages the different network contexts.
  Typically a multi-network stack switches network, or retunes the radio on a different network, when an outgoing packet needs to be sent on a particular network. During the non-transmission time, the radio is always tuned on one of the networks, according to the stack’s internal network scheduling algorithm.
  There are some restrictions to the roles a node can assume on the networks. Since a coordinator or a router node is expected to keep the radio constantly on listening for incoming packets, a multi-network node can be coordinator or router on only one network, while it must be a sleepy end device on the other networks.
  Note: A node can assume any role on one network, but must be a sleepy end device on the other networks.

• 单个芯片上的多网络是通过分享网络上芯片唯一的无线电来实现的。换句话说，多网络节点根据网络调度算法重置网络之间的所有无线电参数。
• 节点在多个网络上同时活动的事实对应用程序完全透明。 API允许应用程序指定引用一组API调用的网络。类似地，API允许应用程序了解堆栈回调与哪个网络相关。有关双网络API的更多详细信息，请参见文档AN724，单芯片上的多个网络设计。
• AFV2和网络协处理器应用框架都提供双网络支持。我们强烈建议在开发双网络应用程序时使用应用程序框架。应用程序框架在降低复杂性方面提供了许多优势，主要与框架如何无缝地管理不同的网络上下文有关。
  通常，当需要在特定网络上发送传出分组时，多网络堆栈切换网络或在不同网络上重新调谐无线电。在非传输时间期间，根据栈的内部网络调度算法，无线电总是在其中一个网络上进行调谐。
• 节点可以在网络上承担的角色存在一些限制。由于期望协调器或路由器节点始终保持无线电监听传入的分组，因此多网络节点可以仅在一个网络上是协调器或路由器，而在其他网络上它必须是困的终端设备。
  注意：节点可以在一个网络上承担任何角色，但必须是其他网络上的一个困倦的终端设备。

  The networks in which a node participates can be on different channels, different PAN IDs, different short IDs, different profiles, and so on. However, a multi-network node maintains the same EUI64 address across the networks in which it participates. The next sections discuss in more detail the two basic configurations, the first where the multi-network node is a coordinator or router on one and a sleepy end device on all other networks, and the second where it is a sleepy end device on all networks.

• 节点参与的网络可以在不同的信道，不同的PAN ID，不同的短ID，不同的配置文件等上。 但是，多网络节点在其参与的网络中维护相同的EUI64地址。 接下来的部分将更详细地讨论两种基本配置，第一种是多网络节点是一个协调器或路由器，另一个是所有其他网络上的一个困倦的终端设备，第二个是所有网络上的一个困倦的终端设备。

1.1.1 协调器/ 路由设备 + 睡眠设备的网络(s)

  A multi-network node that is a coordinator/router on one network and a sleepy end device on the other networks should spend most of its time on the coordinator/router network. A network scheduling algorithm seamlessly takes care of switching from one network to the other so that the node is always on the coordinator/router network except for short periods of time. In particular, the node temporarily leaves the coordinator/router network to complete certain transactions on the sleepy end device networks, such as polling/data retrieving from the parent and/or data sending to the parent. These transactions are typically initiated at the application layer. Therefore the application designer should design the application so that the node does not spend too much time away from the coordinator/router network. Having a multi-network node too busy on a sleepy end device network can consistently impact the throughput of the node and in general could delay all the traffic that gets routed through the node on the coordinator/router network.
  In document AN724, Designing for Multiple Networks on a Single Chip, Silicon Labs provides data obtained from extensive experiments that show the average duration of some typical polling and data transactions between a sleepy end device and its parent. The document also includes a detailed study on how the activity on the sleepy end device network impacts the throughput on the coordinator/ router network. With this data, you can make educated design choices based on how much traffic the multi-network node will handle on the sleepy network and how this traffic impacts the performance of the coordinator/router network.
  Notice that even if the node behaves as a sleepy end device on most of the networks, if it is also a coordinator/router on any one network, it will not be able to save energy by temporarily shutting down the radio (sleep mode).

• 作为一个网络上的协调器/路由器和其他网络上的睡眠设备的多网络节点应该将大部分时间花在协调器/路由器网络上。网络调度算法无缝地负责从一个网络切换到另一个网络，使得节点始终在协调器/路由器网络上，除了短时间。特别地，节点临时离开协调器/路由器网络以完成在睡眠设备网络上的某些事务，例如从父节点检索轮询/数据和/或发送到父节点的数据。这些事务通常在应用程序层启动。因此，应用程序设计人员应该设计应用程序，以便节点不会花费太多时间远离协调器/路由器网络。在睡眠设备网络上使多网络节点太忙可以一致地影响节点的吞吐量，并且通常可以延迟通过协调器/路由器网络上的节点路由的所有流量。
• 在文档AN724“单片机上的多个网络设计”中，Silicon Labs提供了从广泛实验中获得的数据，这些实验显示了一个典型的轮询终端设备与其父设备之间的一些典型轮询和数据事务的平均持续时间。该文档还详细研究了睡眠终端设备网络上的活动如何影响协调器/路由器网络上的吞吐量。利用这些数据，您可以根据多网络节点在休眠网络上处理的流量以及此流量如何影响协调器/路由器网络的性能，进行有根据的设计选择。
• 请注意，即使节点在大多数网络上表现为睡眠设备，如果它也是任何一个网络上的协调器/路由器，它将无法通过暂时关闭无线电来节省能量（睡眠模式）。

1.1.2 多个睡眠终端设备网络

  A multi-network node that is a sleepy end device on all networks does not need to keep its radio always on. The node can poll with different polling rates on each network. The node is able to sleep as long as there is no activity on any network.

• 在所有网络上作为睡眠设备的多网络节点不需要始终保持在线。 节点可以在每个网络上以不同的轮询速率进行轮询。 只要任何网络上没有活动，节点就能够继续休眠。

1.2 网络发现/调试

  Commissioning refers to the process of getting devices into the network. If you have read the discussion of the network joining process in the document UG103.2: Application Development Fundamentals: Zigbee, you may recall that, unless a device is acting as coordinator for a PAN, it must request to join an existing network, and that the joining device must scan one or more channels to locate the available networks. However, as the network coordinator has several radio channels from which to choose in forming its PAN, and since the network’s PAN ID and Extended PAN are often randomized, your application generally requires some intelligence or external mechanism to assist with network discovery and commissioning. Tasks include helping ensure that the device can either join the proper network or receive the desired network settings from some external source, and ensuring that the device can be removed from the network when either the wrong network is joined by mistake or the device is being migrated to a new installation. Likewise, if you are designing a device that may act as a zigbee PAN coordinator, it is important to consider ways in which you can ease the process of network selection for devices looking to enter your coordinator’s network.
  Note: If you are designing an application for use in an official, public zigbee PRO application profile (such as Home Automation), Silicon Labs recommends that you review the latest published revision of the appropriate zigbee application profile specification (as obtained from http://www.zigbee.org) for your target design, to ensure that it meets any profile-specific requirements or best practices for commissioning.

• 调试是指将设备引入网络的过程。如果您已阅读文档UG103.2：应用程序开发基础知识：Zigbee中关于网络加入过程的讨论，您可能还记得，除非设备充当PAN的协调器，否则它必须请求加入现有网络，并且加入设备必须扫描一个或多个通道以定位可用网络。但是，由于网络协调器有多个无线电信道可供选择形成其PAN，并且由于网络的PAN ID和扩展PAN通常是随机的，因此您的应用通常需要一些智能或外部机制来协助网络发现和调试。任务包括帮助确保设备可以加入正确的网络或从某个外部源接收所需的网络设置，并确保在错误连接错误的网络或正在迁移设备时可以从网络中删除设备到新安装。同样，如果您正在设计可充当zigbee PAN协调器的设备，则必须考虑如何为希望进入协调器网络的设备简化网络选择过程。
• 注意：如果您正在设计用于官方公共zigbee PRO应用程序配置文件（例如家庭自动化）的应用程序，Silicon Labs建议您查看相应zigbee应用程序配置文件规范的最新发布版本（从http：/获得） /www.zigbee.org）针对您的目标设计，确保其符合任何特定于配置文件的要求或调试的最佳实践。

1.2.1 Simplifying Network Selection through Extended PAN ID or Channel Mask

  Although Extended PAN ID selection by the PAN’s coordinator is generally random, a proprietary network deployment may use a specific bitmask of extended PAN IDs as a way to enhance network selection for joining devices. In this model, the coordinator forms a network within this agreed-upon Extended PAN ID mask, such that joining devices could scan channels for open PANs and limit those outside of the configured Extended PAN ID range. However, this method of enhancing network selection is not feasible for devices wishing to interoperate on public zigbee PRO profiles with devices from a wide range of manufacturers. Because the public zigbee PRO application profiles do not generally limit their Extended PAN ID selection, another vendor’s device may occupy Extended PAN IDs outside of the limiting bitmask that you’ve chosen.
  Similarly, although 2.4 GHz zigbee networks can occupy any of 16 different channels, the joining device may be able to limit its mask of channels to scan. The expected network might be a proprietary design in which the coordinator has chosen to confine its channel selection to only a few channels within a preconfigured mask. Alternatively, the application profile upon which one or more endpoints of the included devices is based may require constraining the network’s channel selection to a specific set of channels. For instance, both the zigbee PRO SE and HA application profiles require that preference be given when forming a network to channels outside of the most
commonly used Wi-Fi channel allocations (channels 1, 6 and 11 in the IEEE802.11 range), which allows the joining device to confine its channel scan to zigbee channels 11, 14, 15, 19, 20, 24, and 25. Note that AFV2 uses the Network Find plugin (if enabled) to configure the channel mask for the device when joining or forming a network. If using Application Builder to configure your application, make sure to review the Channel Mask and other radio parameter settings in the configuration dialog for the Network Find plugin. If you are not using the Network Find plugin or your application is not based on AFV2, your application code needs to use its own method for ensuring that a preferred channel mask and any other preferred network parameters are enforced during scanning, joining or forming of networks.

• 尽管PAN协调器的扩展PAN ID选择通常是随机的，但是专有网络部署可以使用扩展PAN ID的特定位掩码作为增强用于加入设备的网络选择的方式。在该模型中，协调器在该商定的扩展PAN ID掩码内形成网络，使得加入设备可以扫描用于打开PAN的信道并且限制在配置的扩展PAN ID范围之外的那些。然而，这种增强网络选择的方法对于希望在公共zigbee PRO配置文件上与来自各种制造商的设备进行互操作的设备是不可行的。由于公共zigbee PRO应用程序配置文件通常不限制其扩展PAN ID选择，因此另一个供应商的设备可能会占用您选择的限制位掩码之外的扩展PAN ID。
• 类似地，尽管2.4GHz zigbee网络可以占用16个不同信道中的任何一个，但是加入设备可能能够限制其信道掩模进行扫描。预期的网络可能是专有设计，其中协调器选择将其信道选择限制在预先配置的掩码内的仅几个信道。或者，所包括的设备的一个或多个端点所基于的应用简档可能需要将网络的信道选择约束到特定的一组信道。例如，zigbee PRO SE和HA应用程序配置文件都要求在将网络形成到最多通道之外时优先考虑
• 常用的Wi-Fi信道分配（IEEE802.11范围内的信道1,6和11），允许加入设备将其信道扫描限制在zigbee信道11,14,15,19,20,24和25。请注意，AFV2使用网络查找插件（如果已启用）在连接或形成网络时配置设备的通道掩码。如果使用Application Builder配置应用程序，请确保在Network Find插件的配置对话框中查看Channel Mask和其他无线电参数设置。如果您没有使用网络查找插件或您的应用程序不是基于AFV2，您的应用程序代码需要使用自己的方法来确保在扫描，连接或形成网络期间强制执行首选通道掩码和任何其他首选网络参数。

1.2.2 允许入网的操作

  Devices looking to join a network generally only consider those PANs that are open to new devices (in other words, they permit joining), and devices must not leave their permitJoining flag permanently set, at the risk of failing zigbee PRO compliance testing for public profiles and manufacturer-specific profiles (MSPs). Therefore, devices, especially the PAN coordinator, must ensure that they can enable the permitJoining flag locally for at least some limited time when new devices need to be added to the network. This enabling generally must come from some external stimulus, which will depend on the physical capabilities of a device. If a button or serial interface is available to the device, this is usually an appropriate stimulus to enable permitJoining. However, if the device doesn’t have an external input to act as this stimulus, other methods must be considered. One possibility is to have the device enable permitJoining for a limited time when it is first powered on. Another option is to cause permitJoining to be enabled when a particular message is received by the node over the air.
  With regard to the latter method, while it is possible for the application to make a local change to its own permitJoining state through a local call to the emberPermitJoining() API or permitJoining EZSP command, it is also possible to send a standard request through the ZDO (zigbee Device Object), which is implemented intrinsically by the stack, to a zigbee node to ask it to change its permit Joining state. When a ZDO Permit Joining Request is received over the air for endpoint 0 (the ZDO) on application profile 0x0000 (the zigbee Device Profile), the stack automatically alters the permitJoining state on the device. A unicast or broadcast of this request provides a standard way to change the joining permissions of the network remotely for some or all devices, respectively. For sample code that implements this request, please refer to the emberPermitJoiningRequest() API found in the “app/util/zigbee-framework/zigbee-device-common.h” file from your EmberZNet PRO installation.
  Once the network contains at least one node within range of the joining device that permits joining, the joining device should be able to detect it as joinable through the stack’s native emberNetworkFoundHandler() / ezspNetworkFoundHandler() callback or its emberJoinableNetworkFoundHandler() callback provided by the form-and-join utilities found in app/util/common/form-and-join.h, which are used by the AFV2 architecture. (See the AFV2’s “Network Find” plugin or “Network Steering” plugin for a recommended implementation.)

• 希望加入网络的设备通常只考虑那些对新设备开放的PAN（换句话说，它们允许加入），并且设备不得永久设置permitJoining标志。因此，当需要将新设备添加到网络时，设备（尤其是PAN协调器）必须确保它们能够在本地启用permitJoining标志至少一段有限的时间。这种启用通常必须来自某些外部触发，这取决于设备物理特性。通常设备可以使用按钮或串行接口，这通常是启用permitJoining的方法。但是，如果设备没有外部输入作为触发条件，则必须考虑其他方法。一种可能性是在首次启动时让设备启用permitJoining一段有限的时间。另一种选择是当节点通过空中接收特定消息时使permitJoining被启用。
• 关于后一种方法，虽然应用程序可以通过本地调用emberPermitJoining（）API或permitJoining EZSP命令对其自己的permitJoining状态进行本地更改，但也可以通过该方法发送标准请求。 ZDO（zigbee设备对象），由栈本身实现，到zigbee节点，要求它改变其允许连接状态。当通过无线方式接收应用程序配置文件0x0000（zigbee设备配置文件）上的端点0（ZDO）的ZDO许可连接请求时，堆栈会自动更改设备上的permitJoining状态。该请求的单播或广播提供了分别针对一些或所有设备远程地改变网络的加入许可的标准方式。有关实现此请求的示例代码，请参阅EmberZNet PRO安装中“app / util / zigbee-framework / zigbee-device-common.h”文件中的emberPermitJoiningRequest（）API。
• 一旦网络包含允许加入的加入设备范围内的至少一个节点，加入设备应该能够通过堆栈的本机emberNetworkFoundHandler（）/ ezspNetworkFoundHandler（）回调或其提供的emberJoinableNetworkFoundHandler（）回调将其检测为可加入。在app / util / common / form-and-join.h中找到的表单和连接实用程序，由AFV2体系结构使用。 （有关推荐的实施，请参阅AFV2的“网络查找”插件或“网络指导”插件。）

1.2.3 避免在调试过程中出现意外后果

  Once your joining device does find a joinable network and attempts to join it, the application or the installer must determine if it is the “correct” network, meaning the intended one rather than some other, arbitrary PAN that happened to be within range and permitting
joining. The joining and subsequent authentication process, which involves the acquisition of the current NWK (network) layer encryption key for the PAN, can fail in a variety of ways, even when joining the intended network. Therefore, permanently excluding networks where a join was attempted but failure in joining/authenticating has occurred is not necessarily the best practice. Similarly, depending on the security expectations of your joining device, it may be possible for it to successfully join a network that really isn’t the correct one at all, so permanently settling into a network simply because the stack sends an EMBER_NETWORK_UP signal, indicating that the device was successfully joined and authenticated into the network, may not be sufficient either. The appropriate criteria for determining whether the attempted network is the correct one varies based on your design requirements, especially where security is concerned.
  If you are designing a device for use in a zigbee PRO SE (Smart Energy) network, a complex pre-authorization process is required before the device can successfully enter the network. See the document UG103.5: Application Development Fundamentals: Security for more information. Assuming that the requirement for pre-authorization has been met in the target network, joining the wrong network accidentally should be virtually impossible as the joining device won’t accept the NWK key delivery if it arrives unencrypted or encrypted with a different APS (Application Support) link key.
  However, even with the SE security model, the joining node may still need to account for the fact that an unreliable link or other communication problem, especially if it involves the PAN’s trust center, may cause the delivery of the NWK key from the trust center to fail, even in the correct network. Thus, if a joinable network is detected but the subsequent joining and authentication fails with EmberStatu s of EMBER_NO_NETWORK_KEY_RECEIVED (meaning the NWK key didn’t arrive successfully), EMBER_JOIN_FAILED (which could signify that the Association Response for the join wasn’t received successfully), or EMBER_NO_BEACONS (meaning that the Association Request on the chosen network failed to get an answer), you may want to retry the joining process on that PAN again either immediately or later, in case the first attempt failed due to some temporary disruption. If the joining or authentication process continues to fail on the chosen PAN, consider attempting joining a different joinable network, provided one is available to your device, as the failures may be an indication that this is simply the wrong network.
  In networks utilizing an HA (Home Automation) security model with a common, preconfigured APS link key used to pass a randomly generated NWK key, there is significant risk of joining the wrong network by accident if multiple joinable networks happen to exist within
range of the joining device, as the security settings among these networks are common to nearly all HA networks rather than being unique for each incoming node. Note that it is possible for HA networks to use a different preconfigured link key, but this key must somehow be communicated to the new node prior to its joining the network. Thus, you should take extra care in your application design to ensure that, once you enter a PAN successfully, it is really the intended one. This typically involves some kind of “join and verify” process for each available network that accepts your device, which means sending some sort of well-defined over-the-air message with an expected response to indicate joining of the correct network; this response may be another over-the-air message or may be some kind of detectable behavior by another part of the system.
  An example of each method is described in the following table, beginning when a new node joins the candidate network:

• 一旦您需要入网设备找到可加入的网络并尝试加入它，应用程序或安装程序必须确定它是否是“正确的”网络，这意味着预期的网络而不是其他任意PAN，恰好在范围内并允许入网。涉及获取PAN的当前NWK（网络）层加密密钥的加入和后续认证过程可能以各种方式失败，即使在加入预期网络时也是如此。因此，永久排除尝试加入但加入/验证失败的网络不一定是最佳做法。同样，根据加入设备的安全期望，它可能会成功加入一个不正确的网络，因此，只是因为堆栈发送EMBER_NETWORK_UP信号而永久地进入网络，表明设备已成功加入并验证到网络中，可能还不够。确定尝试的网络是否正确的适当标准因您的设计要求而异，尤其是在涉及安全性的情况下。
• 如果您正在设计用于zigbee PRO SE（智能能源）网络的设备，则在设备成功进入网络之前，需要进行复杂的预授权过程。有关更多信息，请参阅文档《UG103.5：应用程序开发基础知识：安全性》。假设在目标网络中已满足预授权的要求，则实际上不可能加入错误的网络，因为如果加密设备未加密或使用不同的APS加密，则加入设备将不接受NWK密钥传送（应用程序支持） ）链接键。
  但是，即使使用SE安全模型，加入节点仍可能需要考虑不可靠链接或其他通信问题（尤其是涉及PAN的信任中心）可能导致从信任中心传递NWK密钥的事实。即使在正确的网络中也会失败。因此，如果检测到可连接网络，但后续加入和身份验证失败，并且EBERStatu为EMBER_NO_NETWORK_KEY_RECEIVED（意味着NWK密钥未成功到达），则EMBER_JOIN_FAILED（这可能表示未成功接收到加入的关联响应）或者EMBER_NO_BEACONS（意味着所选网络上的关联请求未能得到答案），您可能希望立即或稍后再次在该PAN上重试加入过程，以防第一次尝试因某些暂时中断而失败。如果加入或身份验证过程在所选PAN上继续失败，请考虑尝试加入其他可加入网络，前提是您的设备可以使用其中一个，因为失败可能表明这只是错误的网络。
• 在使用HA（家庭自动化）安全模型的网络中，该安全模型具有用于传递随机生成的NWK密钥的公共的，预配置的APS链路密钥，如果在其中存在多个可连接网络，则存在意外加入错误网络的重大风险。
• 加入设备的范围，因为这些网络中的安全设置对于几乎所有HA网络是通用的，而不是对于每个进入节点是唯一的。请注意，HA网络可能使用不同的预配置链接密钥，但必须以某种方式将此密钥在加入网络之前传送到新节点。因此，您应该特别注意应用程序设计，以确保一旦成功进入PAN，它就是预期的。这通常涉及接受您的设备的每个可用网络的某种“加入和验证”过程，这意味着发送某种明确定义的无线消息，其具有预期响应以指示加入正确的网络;此响应可能是另一个无线消息，或者可能是系统另一部分的某种可检测行为。
• 下表描述了每个方法的示例，从新节点加入候选网络开始：

Triggering Event	Success	Exception
Example 1
节点发送 ZDO Match Descriptor Request 广播，获取当前网络中支持该clusters的结点	从多个结点接收的到ZDO Match Descriptor Response received	没有匹配到相关的cluster
Caveats:   由于此验证过程仅检测到支持所需群集的设备，因此当加入节点已进入具有与预期网络相同类型的安全模型和相同类型的群集功能的网络时，它可以成功。 例如，车库门开启器可以与车库门连接任意网络以控制但不是预期的。 如果发生这种情况，系统必须以某种方式检测条件并指示新节点离开当前网络并找到不同的网络。   只有当至少一个具有匹配服务的其他节点已加入网络时，此过程才会成功。 这引入了必须连接设备的订单的调试要求，必须将其传达给安装人员。
Example 2
步骤1：节点向网络协调器发送单播ZDO匹配描述符请求（节点ID 0x0000），尝试匹配支持ZCL识别服务器集群的设备。 步骤2：节点向匹配端点上的协调器发送ZCL Identify命令。	节点从协调器接收ZDO Match Descriptor Response 协调器以某种可检测的方式向系统标识自己的。.	结点没收到任何相应. 未在预期时间内收到Identification.
Caveats: 除了系统所需的指令之外，此方法还取决于节点何时可以访问协调器，通常情况是这样，因为协调器通常履行信任中心的角色，以便为每个新节点提供集中认证。 这种方法还需要在连接节点上提供一些系统可支持的方法，以使其能够更改当前网络。
Example 3
PAN的信任中心接收联接设备的TrustCenterJoinHandler回调	PAN的信任中心通过信任中心或某些专用用户界面（如联网PC）上的音视频操作指示来通知系统。	系统没有得到预期的指示;
Caveats: 此示例不要求加入节点的应用程序发送任何额外消息，这极大地简化了加入节点应用程序的调试设计。但是，它不依赖于PAN信任中心设备的确定性和功能。使用此方法需要与系统的预期信任中心（协调器）节点的设计者合作。

  The choice of one of the above methods, or some variant thereof, will likely depend on the capabilities of the devices in your system, the importance of multi-vendor interoperability in your design, the expected latency of the commissioning process, and the sophistication of the installers who will be commissioning your devices.
  Zigbee provides a commissioning cluster in the ZCL, which facilitates over-the-air installation of certain commissioning parameters into a device. However, as of this writing neither the HA nor SE profile requires implementation of this cluster on client or server side in its device types, nor has its use been tested as part of the zigbee interoperability test events for these profiles. Use of the commissioning cluster is only feasible in networks where you can ensure that the joining node has server-side support for the commissioning cluster, and that at least one device in the system has client-side support to send commissioning commands. Furthermore, because the commissioning cluster relies on zigbee messaging, which necessitates being in a network in the first place, you would need to design a scheme for having your device join a temporary commissioning network where a commissioning tool exists that can provide the necessary parameters. While the application framework allows for use of the ZCL’s commissioning cluster, implementation of that cluster, if desired, is the responsibility of the application developer.

• 选择上述方法之一或其中的一些变体可能取决于系统中设备的功能，多厂商互操作性在设计中的重要性，调试过程的预期延迟以及复杂程度。
• Zigbee在ZCL中提供调试集群，便于将某些调试参数无线安装到设备中。但是，在撰写本文时，HA和SE配置文件都不需要在其设备类型的客户端或服务器端实现此集群，也不会将其用作测试作为这些配置文件的zigbee互操作性测试事件的一部分。使用调试集群仅在网络中可行，在这些网络中，您可以确保加入节点对调试集群具有服务器端支持，并且系统中至少有一个设备具有客户端支持以发送调试命令。此外，由于调试群集依赖于zigbee消息传递，这需要首先进入网络，因此您需要设计一种方案，让您的设备加入临时调试网络，其中存在可提供必要参数的调试工具。虽然应用程序框架允许使用ZCL的调试集群，但如果需要，该集群的实现是应用程序开发人员的责任。

1.2.4 离网机制

  Many designers put careful thought into the network selection process and then neglect to provide a way for the system to uninstall the device from the current network and then install it into a new network. As the commissioning examples above show, enabling some way for the device to manually or automatically initiate an emberLeaveNetwork() action, and possibly find a new network after the leave completes, is often necessary to facilitate successful installation and reinstallation of zigbee devices in their intended networks.
  If this cannot be implemented in the hardware or software of the joining device itself, the ZDO’s Leave Request mechanism, which is acted on automatically by the stack, may be a viable alternative, as it allows another node in the PAN, such as the network’s controller, to instruct a device to leave the network. For sample code implementing the ZDO Leave Request command, refer to the emberLeaveRequest() API found in the “app/util/zigbee-framework/zigbee-device-common.h” file from your EmberZNet PRO installation.

• 许多设计人员仔细考虑网络选择过程，然后忽略为系统提供从当前网络卸载设备然后将其安装到新网络的方法。如上面的调试示例所示，通常需要某种方式让设备手动或自动启动emberLeaveNetwork()操作，并在l离网后找到新网络，以便于在其预期内成功加入和重新加入zigbee设备网络。
• 如果这不能在加入设备本身的硬件或软件中实现，那么由堆栈自动执行的ZDO的离开请求机制可能是一种可行的替代方案，因为它允许PAN中的另一个节点，例如网络的控制器，用于指示设备离开网络。有关实现ZDO Leave Request命令的示例代码，请参阅EmberZNet PRO安装中“app / util / zigbee-framework / zigbee-device-common.h”文件中的emberLeaveRequest（）API。