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
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.
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.
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.
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).
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.
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.
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.
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.)
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:
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.
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.