The Zigbee Stack#

Zigbee provides several separate stacks. This has been a point of confusion so the summary is as follows:

  • Zigbee 2004: was released in 2004 and supported a home control lighting profile. This stack was never extensively deployed with customers and is no longer supported.

  • Zigbee 2006: was released in 2006 and supports a single stack known as the Zigbee stack (explained below)

  • Zigbee 2007: was released in Q4 2007. It has two feature sets, Zigbee and Zigbee PRO.

The Zigbee and Zigbee PRO stacks are complete implementations of the MAC, networking layer, security services and the application framework. Devices implementing Zigbee and Zigbee PRO can interoperate by acting as end devices in the other type of network. For example, if a network is formed around a Zigbee PRO coordinator it can have Zigbee PRO routers only, but both Zigbee and Zigbee PRO end devices.

Note: The Zigbee 2004 stack is not interoperable with Zigbee 2007.

The Zigbee stack is formed around a central coordinator and uses tree addressing to establish the network.

The Zigbee PRO stack is formed around a central coordinator but uses a stochastic addressing scheme to avoid limitations with the tree. Table routing is always used and additional features are available such as:

  • Network level multicasts

  • Many-to-one and source routing

  • Frequency agility

  • Asymmetric link handling

  • PAN ID Conflict

  • Fragmentation

  • Standard or high security.

Silicon Labs does not recommend deploying systems on the Zigbee stack because the Zigbee PRO stack has a number of features that are necessary for long term network stability and reliability. The Zigbee stack is typically used for small static networks.

Note: The Zigbee 2007 specification includes updates to the Zigbee stack to allow the use of frequency agility and fragmentation on this stack. This stack remains interoperable with the Zigbee 2006 stack and therefore use of these features must be limited to those networks which can handle the complexity of some devices having these capabilities and some devices not.

Zigbee Device Object (ZDO)#

The ZDO (occupying Endpoint 0 of each node) is a stack-level entity defined by the Zigbee Networking Specification for use in network management and information gathering. This section explains how to make use of ZDO functionality in the EmberZNet PRO stack and/or EZSP. An example is described as well.

The ZDO, an entity in the stack, provides network management capabilities that nodes can use to learn about each other, about the network in general, or for managing certain stack-level functionality. Many features of the ZDO must be implemented as part of a Zigbee Certified Platform (ZCP) and are therefore available on all Zigbee/Zigbee PRO devices, making them useful as an interoperable way to gather and manage system properties on a Zigbee network. The ZDO is implemented through an OTA messaging format known as the Zigbee Device Profile.

The following basic guidelines apply to using the ZDO for network management:

  • Broadcasts requests must go to broadcast mask 0xFFFD.

  • Requests should always be sent to destination endpoint 0, with application profile ID 0x0000, as this indicates that the ZDO (intrinsic in the stack) should handle the message. The source endpoint generally corresponds to the portion of your application that is interested in the requested information.

  • Responses to ZDO requests come from source endpoint 0, to the destination endpoint corresponding to the source used for the Request.

  • If a particular ZDO request handler is not implemented in the stack, a status of EMBER_ZDP_NOT_SUPPORTED (0x84) will be returned in the response.

  • Cluster ID is used to indicate the Request or Response type being sent.

  • Most requests can be sent as unicast, broadcast or multicast, just like any other APS frame (with optional APS acknowledgment), and responses arrive in the IncomingMessageHandler like any other incoming APS message. However, certain kinds of requests, if sent as broadcasts, will not generate a response (in the interest of network bandwidth conservation). There are also certain requests that cannot be sent broadcast. For more information on these specific commands, please refer to the Zigbee core specification (document 14-0392).

  • stack/include/zigbee-device-stack.h details the frame formats for commands and responses, including which request types are supported by the EmberZNet PRO stack. Further details about the frame formats are described in the Zigbee Device Profile (ZDP) section of the Zigbee Networking Specification (Zigbee document 14-0392).

  • Utility functions (provided as source code) for generating ZDO requests and parsing certain kinds of responses can be found in app/util/zigbee``-framework/zigbee-device-library.h. (There is also an alternative version of this file for EZSP host applications.)

  • All ZDO requests and responses begin with the transaction sequence number as the first byte of the payload. This allows a request to be matched up with a particular response.

As an example, take the case of a Permit Joining ZDO transaction, which facilitates remote control of the PermitAssociation flag for one or more devices in the network.

For this particular transaction, zigbee-device-stack.h explains the following:

1. // Request: [duration:1] [permit:1]
2. // Response: [status:1]
3. #define PERMIT_JOINING_REQUEST 0x0036
4. #define PERMIT_JOINING_RESPONSE 0x8036

So a Permit Joining request frame would use cluster ID 0x0036, and the response would arrive with cluster ID 0x8036. For the request parameters, the "duration" byte corresponds to the argument you would ordinarily provide to the PermitJoining call in EmberZNet PRO/EZSP (a number of seconds to allow joining, or 0x00 for always-off joining, or 0xFF for always-on joining). The "permit authentication" byte used to only be applicable when the recipient of the request was the Trust Center (TC) and controlled whether the TC should perform authentication on "certain devices" during future association requests.

However, the current Zigbee Networking Specification mandates that the permit authentication byte be 0x01, so this argument in the Permit Joining Request is no longer significant.

Permit Join Requests are typically sent as a broadcast to all routers, allowing devices to join at any router in the network after this broadcast request has been processed.

Advanced ZDO Usage#

The EmberZNet PRO stack supports a feature where the application (host MCU) can be informed about ZDO requests that the stack is handling, and/or informed about those that the stack does not handle (so that it can handle them itself), and also to give the host a chance to handle endpoint requests (instead of handling these automatically) if desired. Please see comments in the hal/ember-configuration.c file (in SoC platforms) or app/util/ezsp``/ezsp-enum.h (for NCP platforms) for descriptions of these available options, which are described as EzspConfigId values 0x26-0x28 (in EZSP) or the following configuration defines (in SoC API):

EMBER_APPLICATION_RECEIVES_SUPPORTED_ZDO_REQUESTS
EMBER_APPLICATION_HANDLES_UNSUPPORTED_ZDO_REQUESTS
EMBER_APPLICATION_HANDLES_ENDPOINT_ZDO_REQUESTS
EMBER_APPLICATION_HANDLES_BINDING_ZDO_REQUESTS

Zigbee Profiles#

Before Zigbee 3.0, application profiles, or simply profiles, sat on top of the basic Zigbee stack. These were developed to specify the OTA messages required for device interoperability. A given application profile could be certified on either the Zigbee or Zigbee PRO stack. Now, Zigbee 3.0 has introduced an all-encompassing application layer specification for defining OTA behavior for all Zigbee applications.

The following are the application profile groups that existed before Zigbee 3.0:

  • Home Automation (HA): Devices for typical residential and small commercial installations.

  • Smart Energy (SE): For utility meter reading and interaction with household devices.

  • Commercial Building Automation (CBA): Devices for large commercial buildings and networks.

  • Telecom Application (TA): Wireless applications within the telecom area.

  • Health Care (HC): Monitoring of personal health in the home or hospital environment.

  • Retail: Monitoring and information delivery in a retail environment.

  • Zigbee Light Link: Wireless control of LED lighting systems.

The Zigbee Cluster Library (ZCL) forms a generic basis for the Zigbee common application layer. This library defines common elements that are shared such as data types and allows reuse of simple devices such as on/off switch protocols between different profiles.

Application profiles defined the roles and functions of devices in a Zigbee network. Two types of application profiles were administered by the Alliance:

  • Public Application Profiles, developed by members of the Connectivity Standards Alliance so that devices from different manufacturers can interoperate.

  • Manufacturer-Specific Application Profiles, developed by product developers creating private networks for their own applications where interoperability is not required.

The Connectivity Standards Alliance now recognizes one application layer, described by the Zigbee Base Device Behavior specification, which defines roles and functions of a device in any Zigbee network. These application behaviors interoperate with any other application.

If you develop a product based upon your own private application layer specification, the Alliance requires you to make use of a unique private profile identifier to ensure the product can successfully co-exist with other products. The Alliance issues these unique private profile IDs to member companies upon request and at no charge.

An application can also be developed using the common Zigbee 3.0 application layer with private extensions for specific features from a manufacturer.

Zigbee Addressing Scheme#

The Zigbee PRO stack uses a stochastic address assignment mechanism. Under this mechanism the coordinator is still used to start the network. Each device (routers and end devices) that joins the network is given a randomly assigned address from the device it is joining. The device conducts conflict detection on this address using network level messages to ensure the address is unique. This address is then retained by a device, even if the parent address changes. A best practice is to let the stack assign the addresses.

Under Zigbee PRO, provisions are intended for a commissioning tool for setup and configuration of networks. This commissioning tool can be used to assign addresses manually. Silicon Labs does not provide a commissioning tool. If you are interested in such a tool, refer to the ZCL Commissioning cluster for information.

Extended PAN IDs#

Developers who have used stack software earlier than Zigbee 2007 should note a new and important change to PAN IDs. Zigbee has added an 8 byte extended PAN ID (EPID or XPID) to facilitate provisioning and PAN ID conflict detection. The extended PAN ID is now included in the beacon payload, following the existing 3 bytes.

The Extended PAN ID was a network parameter in Zigbee 2007 (EmberZNet 3.x and later) was used in the Zigbee and Zigbee PRO feature sets. This extended PAN ID (EPID) can be thought of as an extension of the basic, 16-bit PAN ID (PID). The EPID is a 64-bit value set for the entire network by the Zigbee Coordinator (ZC) at the time the personal area network (PAN) is formed and must not change while the PAN is operating (unlike the PID). Like the PID, all nodes within the same PAN share an EPID.

Other than the scanning and joining processes, the EPID rarely appears in transmitted Zigbee packets due to its large overhead (8 bytes) in the header. However, the EPID is used during a Network Update transaction, where a Network Manager node informs the other devices in the PAN about a PID conflict or channel change, so that nodes moving to a new channel and/or PID can rely on the consistency of the EPID as a criteria for finding the moved network.

Note that the Extended PAN ID (even if it’s zero) is saved to the non-volatile memory (as part of the tokens) once the node associates into the network, so it won't change over the lifetime of the device until the device leaves the network.

Use in Scanning / Forming / Joining Process#

The EPID will appear (along with other information such as the PID) in the beacon results seen by an Active Scan, and when a join is initiated, if the EPID is non-zero in the join request, the EPID will take precedence as the primary criteria for matching up the joiner to the joinee (16-bit PAN ID is effectively ignored). However, it’s possible that some networks (particularly older ones) may not want (or be able) to deal with EPIDs, so the EPID would be zero in the network parameters from the beacon. If the requested EPID is all zeroes during the JoinNetwork operation, only the 16-bit PAN ID will be used to match to a network for the purposes of association.

While Silicon Labs provides some sample utilities for scanning networks and parsing the results to make a determination about which one to join, this process will generally vary depending on the application design and the level of strictness desired in selecting a network. (For example, the joining device may simply want any available Zigbee PRO network; it may seek a closed network designed specifically for the application in use but may not care which closed network it chooses; or it may seek one specific closed network with specific properties, in the way that I want my laptop at home to join not just any home WiFi network, but my WiFi network in my home.)

The following guidelines apply to EmberZNet in determining the expected behavior of a Form/Join action given a particular EPID:

  • If an all-zero value is specified for extended PAN ID during FormNetwork, the stack will generate a random 64-bit value for this field.

  • If an all-zero value is specified for extended PAN ID during JoinNetwork, the stack will use the 16-bit PAN ID specified in the JoinNetwork parameters as the primary criteria for selecting a network during the join process.

  • If a non-zero value is specified for extended PAN ID during JoinNetwork, the stack will use the 64-bit extended PAN ID specified in the JoinNetwork parameters (even if 16-bit PAN ID is different) as the primary criteria for selecting a network during the join process.

Choosing an EPID#

While the PAN ID is meant to be a randomly chosen, 16-bit value, unique to each network, the EPID is often used more like the SSID field of WiFi networks to give them a user-friendly designation (which is often not so random and is either set by the manufacturer or the installer). However, Silicon Labs discourages using a fixed EPID for all deployments because (unlike the conflicts of the PAN ID) EPID conflicts cannot be resolved if they occur at runtime (because no other unique information exists to distinguish the PANs). Customers wishing to use non-random EPIDs should, at minimum, scan the network (either at the coordinator or through some external commissioning tool) and check that the new PAN's preferred EPID is not already in use by some other PAN. One approach is to use a small set of preferred EPIDs when forming PANs so that the coordinator can have alternatives if the first choice is in conflict.

OEMs creating consumer-grade products requiring customer installation (rather than by trained installers) should take particular care to ensure variety of EPIDs, as two customers living next door to each other may purchase the same product for their homes and would prefer to isolate their networks from each other. If those two neighboring homes were to each use PANs with the same EPID, network difficulties would likely arise for both users because the both homes would be considered as one network, and many network address conflicts could occur.

EPID versus PID#

Here is a quick overview of differences between the Extended PAN ID and the standard PAN ID:

  • EPID is 64 bits; PID is 16 bits.

  • EPID is usually used as stack's criteria for matching to the requested network; PID is only used for matching criteria when EPID is all 0x00 bytes.

  • EPID is only present in a few kinds of packets (beacons, Network Update messages); PID is present in almost all 802.15.4 frames (except MAC ACKs).

  • EPID is used as criteria for uniquely identifying the network and for resolving conflicts of PID; PID is used for MAC destination filtering at the radio receiver.

  • EPID may help provide some indication of the network's identity in the scan results; PID should always be completely random, so it is not as useful in determining which PAN is the "right one".

  • EPID can be any value in range of 0x0000000000000001 to 0xFFFFFFFFFFFFFFFE (all 0's and all F's are reserved values); PID can be any value in the range of 0x0000 - 0xFFFE (all F's constitute reserved value).