For customers certifying end products with the ZigBee Alliance on application profiles built upon the ZigBee PRO or RF4CE standards, it is sometimes necessary to provide to the test house supporting documentation as proof that the underlying stack (such as our EmberZNet) stack has completed its own stack-level testing as a ZigBee Compliant Platform (ZCP).
Silicon Labs submits nearly every official GA (general availability) release of EmberZNet to a ZigBee Alliance approved test house (such as NTS, TRAC Global, or TUV) for ZCP testing. In this shared Dropbox folder, you will find the relevant compliance documents for past EmberZNet releases (on a per-platform basis) all the way back to EmberZNet 4.2.1, for every release that completed ZCP certification: https://www.dropbox.com/sh/vp4k4975wsgcckc/AAADTglGKniHjL2dJP8R00jpa?dl=0. Note that only one IC variant for each version is shown, but all supported platforms were tested for conformity (with other variants receiving compliance by similarity in most cases).
If you are looking for compliance documentation for a release older than what's here or would like to inquire about the status of a newer release not yet posted here (which generally means the compliance testing hasn't completed at the test house yet), please contact Silicon Labs technical support. You can also try going to http://old.zigbee.org/Products/CompliantPlatforms/ZigBeePROFeatureSet.aspx and doing a search with Manufacturer = "Silicon Labs, Inc.".
How to replace a Trust Center already in a network?
When attempting to replace your trust center there are a few factors to think about. The first thing to consider is what profile your device is. In this knowledge base article, we will be reviewing HA and SE.
In the Smart Energy profile, trust center replacement is referred to as Trust Center Swap-out (TCSO). Currently, TCSO is not a certifiable feature within the stack as it has never been formally verified at ZigBee Pro test events. However, we have created a plugin that can assist you in this process. This process uses CBKE for authenticating the new trust center. The plugins we have built around the trust center swap out feature are the Trust Center Backup plugin and the Trust Center Keepalive plugin. It is important to note that this TCSO may undergo changes before there is a fully tested, certifiable feature which will be released. At this point the method has not been tested with other vendors, so it may not work with all deployed devices.
The following are the descriptions provided for the two mentioned plugins.
Trust Center Backup:
This code is only for a trust center. It provides a set of APIs for importing and exporting the backup info for a Smart Energy trust center. It requires extending to hook up import/export routines into an external storage device or network, where the data may be saved to and restored from.
Trust Center Keepalive:
Ember implementation of Trust Center Keepalive. The plugin will periodically send keepalive signals to the trust center to verify that it is accessible. If the trust center fails to acknowledge a series of keepalive signals, the plugin will search for another instance of the trust center on a different channel or short PAN ID. The frequency with which the plugin sends the keepalive signals is configurable. Trust Center Keepalive is part of the optional Trust Center Swap-Out feature of Smart Energy 1.1. Devices are not required to implement this functionality. The trust center does not send keepalives, so this plugin should be disabled if the device is acting as the trust center.
The trust center backup plugin can be used as example code to assist with the storage or retrieval of backup data to and from a locally accessible POSIX filesystem.
The difficulty about trust center replacement comes in when dealing with HA. In HA, ZigBee has not provided any guidance around how this can be handled. The biggest issue that you run into with HA is that without SE certificates, an entire backup of all network-related and security-related data from the TC is needed(which is facilitated by our Trust Center Backup plugin). Also, an external storage device is needed to store and then copy it out to a new TC candidate device (overwriting the EUI64 on the new device to make it match the old one) that will serve as the replacement. Note that the TC backup operation needs to be done periodically (to preserve the latest security frame counters of the TC) unless the new TC installation will begin with an arbitrarily high NWK frame counter value and then be accompanied by a change to the NWK key (to reset the NWK frame counter).
The challenge then becomes attempting to replace the EUI64. The EUI64 of the device is initially written in the MFG tokens. These tokens are write-protected, so they cannot be overwritten. However, in the CIB block there is a token spot for the EUI64 to be written. This is a write once value, as it can only be written to if the value is cleared (all F's). If your replacement device has already had the custom EUI written to, the device itself would need to be cleared, and will not be able to be done during run time. As of 5.4, changing the EUI64 can be done with ezspSetMfgToken() on the CUSTOM_EUI_64 token, assuming that Custom EUI token hasn't already been set.
While all of the other non-volatile data needs to match the old device, it is important to note that the network frame counter must be greater than or equal to the replaced trust center's value. If it is lower, all of the messages until the frame counter grows larger than the last message the trust center sent will be ignored by the rest of the network. For the SoC platforms, you can write the stack tokens related to the NWK and APS layer frame counters directly via halCommonSetToken() for the TOKEN_STACK_NONCE_COUNTER and TOKEN_STACK_APS_FRAME_COUNTER tokens, respectively. Then you'll want to probably avoid resetting the frame counters during security initialization (just prior to joining or forming a network), and this can be done by adding EMBER_NO_FRAME_COUNTER_RESET to the bitmask passed to emberSetInitialSecurityBitmask (such as in the Application Framework's "Custom Security Init Callback"). New APIs emberSetOutgoingNwkFrameCounter() and emberSetOutgoingApsFrameCounter() were introduced in 5.4.0 to assist with restoring the security frame counters.
Sample code illustrating HA TC Replacement is available upon request.